このページは Cloud Translation API によって翻訳されました。

Google Maps Platform とモビリティの請求ガイド

新しい Google マッププロジェクトを本番環境に実装する前に、使用するプロダクトに対して適切な料金を支払うように、設定が正しいことを確認しておく必要があります。このドキュメントでは、（i）請求書の生成前に使用量を確認できるように請求の透明性を確保し、（ii）適切なプロジェクトを設定することで、お客様が Google プロダクトを安心して使用できるようにするためのさまざまな側面について説明します。

これは比較的簡単なプロセスですが、マップパートナーがお客様と連携してお客様のプロジェクトが適切に移行されるよう支援いたします。

概念

このセクションでは、Google マップの課金に関する基本情報と、さまざまな設定について説明します。多くの場合、正解か不正解もありません。それは、達成しようとしている結果の種類によって異なります。

このドキュメントでは、Google Cloud プロジェクトについて詳しく説明します。これは、Google マップのさまざまなサービスを利用できるためです。このドキュメントで説明する構成は、Google Cloud プロジェクトで作成されることを意味します。

請求先アカウント

現在 Google マッププロダクトを使用しているすべての企業には、それぞれ Google Cloud プロジェクトが関連付けられています。このプロジェクトには請求先アカウントが構成されている必要があります。請求先アカウントは、Google マップのすべての利用状況を記録し、その利用状況に基づく毎月請求書を作成する責任を負います。

モビリティの場合は、特別な請求先アカウントがプロビジョニングされます。この請求先アカウントは、ライドシェアリング、配送、物流などのモビリティ関連のユースケースでのみ使用されます。

単一の請求先アカウントは、複数の Google Cloud プロジェクトまたは 1 つのプロジェクトで使用できます。

同じ請求先アカウントを指す単一のプロジェクト:

特定のユースケース（モビリティのユースケース）
個別の請求書
割引は、この単一プロジェクトに基づくボリュームに対して行われます

同じ請求先アカウントを指す複数のプロジェクト:

同じユースケース
使用量を集計することで割引ティアを利用できる
単一の請求書

請求先アカウントの詳細やその他の関連情報については、こちらのリンクをご覧ください。

前述のように、1 つの請求先アカウントが複数のプロジェクトを指すことができます。複数のプロジェクトがある場合は、Google のモビリティサービスを使用するプロジェクトを特定し、そのプロジェクトがモビリティの請求先アカウントを参照するようにする必要があります。モビリティのユースケースが関連付けられていないプロジェクトは、現在使用している通常の Google Maps Platform 請求先アカウントを引き続き参照する必要があります。モビリティの請求先アカウントを取得するには、Google またはパートナーを通じてモビリティディールを締結する必要があります。スキーマ全体における請求先アカウントの位置付けと、考えられる各種設定を以下に示します。

Cloud リソース、請求先アカウント、請求書の生成

料金についてお話しすると、Google Maps Platform にはさまざまな割引レベルがあり、マップパートナーを通じて利用したり、状況によっては Google から直接利用したりできます。これらのティアはボリュームベースであるため、Google プロダクトの使用量が増えるほど、お支払い額が削減されます（割引は各 SKU に個別に適用されます）。Google の課金システムでは、Google プロダクトの呼び出しに使用された認証情報に基づいてプロジェクトを識別します。この認証情報には、API キーまたはサービスアカウント（一部のモビリティ API）があります。

API キー

Google Maps Platform API は、API キーを使用して認証されます。Google は、この API キーに基づいて、対応する Google Cloud プロジェクトの請求先アカウントを特定し、利用を行います。

Geocoding API へのリクエストの例:

https://maps.googleapis.com/maps/api/geocode/json?place_id=ChIJeRpOeF67j4AR9ydy_PIzPuM&key=YOUR_API_KEY

JWT

一部の API では、URL に Google Cloud プロジェクト ID が必要であり、JWT を使用して認証します。そのため、請求が適切に行われるように、適切なシステムで正しい認証方法を使用することが重要です。

Fleet Engine API へのリクエストの例:

curl -X GET \ https://fleetengine.googleapis.com/v1/providers/project_id/deliveryVehicles/vehicle-1234 \
  -H 'authorization: Bearer eyJ0eXAiOi...' \
  -H 'cache-control: no-cache' \
  -H 'content-type: application/json' \
  -d '{
    "lastLocation": {
        "location": {
            "latitude": 37.432,
            "longitude": -122.094
        },
        "updateTime": "2022-11-13T17:55:00Z"
    }
}'

費用

Google Maps Platform では、費用は API リクエストの量に基づいて計算されます。モビリティサービスについては、正常に完了した移動またはタスク（ピックアップではなく配送）である請求対象のモビリティトランザクションの量に基づいて請求します。これは契約に署名する前に定義されます。配車サービスやフードデリバリー会社の場合、配車または宅配が成功指標です。これは Trip にマッピングされます。タスクは、荷物の配達が必要な物流会社や小売業者に使用されます。

Google は、モビリティのお客様が出張や配達の際に Google Maps Platform プロダクトも使用していることを認識しています。そのため、モビリティの請求先アカウントを使用している場合、同じモビリティユースケース内で事前定義された上限を遵守する限り、Google Maps Platform を無料で呼び出すことができます。

たとえば、食品宅配会社の場合、移動が成功するたびに Geocoding API を 10 回呼び出すことができます。これらの上限について詳しくは、モビリティドキュメントの使用制限をご覧ください。上限を変更する場合は、契約の修正が必要となるため、具体的なニーズについては Google またはパートナーの担当者にご相談ください。

月末に、（i）システムで報告された成功した移動またはタスクの数、および（ii）事前に設定された上限を超える Google Maps Platform API 呼び出しの量（「超過」）に基づいて、請求書が生成されます。Google の制限は、市場で広く必要とされているものと一致しています。

こちらで、モビリティの請求に関する公式ドキュメントをよくお読みください。

試験運用と評価

お客様は、契約に署名するまでの限られた期間、Google Maps Platform の請求先アカウントでモビリティサービスの小規模なパイロット（概念実証、評価）を実施できます。試験運用の実施を希望される場合は、マップパートナーまたは Google の担当者にご相談ください。

前述のように、パイロットフェーズ中はモビリティ請求先アカウントは契約にまだ署名されていないため、利用できません。つまり、Google Maps Platform プロダクトが使用されるたびに課金されますが、モビリティ固有のプロダクトでは課金されません。つまり、パイロットフェーズでは、課金はタスクベースやルートベースでないため、このフェーズ中は使用制限は適用されません。

試験運用が正式に本番環境にリリースされたら、契約に基づいて支払いを行う必要があります。

まとめ

パイロット / 開発フェーズ: 一般公開されている Google Maps API に対してのみ課金されます。一般公開されていない API と SDK については、プロジェクトでモビリティの請求先アカウントが使用されるまで料金は発生しません。新しく作成された請求先アカウントには、Google Maps Platform API の 200 ドル分のクレジットが提供されます。管理された環境での評価期間中は、これで十分です。
生産フェーズ: 移動またはタスクごとに課金されます。Google Maps Platform に関連する費用が発生するのは、使用量が契約の使用量上限（「上限」）を超えた場合のみです。超過分については自己負担となります。超過料金については、こちらの定義に従って課金されます。

モビリティの請求先アカウントに移行する方法

本番環境に移行する場合、通常は、QA（品質保証）や本番環境など、さまざまな環境を表すために、他の Google Cloud Platform（GCP）プロジェクトをいくつか作成する必要があります。それまでは開発環境は 1 つだけだったはずですが、

要件

パートナー様側の担当者:

Google Cloud で請求先アカウントを管理します。通常、これは請求先アカウント管理者またはプロジェクトオーナーが行います。
契約の署名後に生成されたウェルカムレターに記載されている新しい請求先アカウント ID へのアクセス権。
ルートまたはタスクが報告される本番環境に対応する Google Cloud プロジェクトへのアクセス権。

以下では、新しいプロジェクトの設定に必要な手順と、これらの新しいプロジェクトで課金を設定する方法について説明します。

新しいプロジェクトのセットアップ

プロジェクトの作成

[お客様] 新しい環境（本番環境、品質保証など）用の新しい GCP プロジェクトの作成。これは Google Cloud コンソールから行います。こちらの直接リンクをご覧ください。
[パートナーまたは Google チーム] モビリティプロダクトにアクセスするには、このプロジェクトを許可リストに登録する必要があります。手順については、Google またはパートナーの営業担当者にお問い合わせください。前のステップで作成したプロジェクト ID を指定します。
[あなた] プロジェクトの重要な連絡先を更新します。これは、Google サポートチームがお客様側の適切な担当者に連絡できるようにするために非常に重要です。

プロジェクト構成

以下の手順は、前の手順で作成したプロジェクトの Google Cloud コンソールで行う必要があります。

[あなた] サービスアカウントの作成。適切なモビリティ ID とアクセス管理（IAM）のロール（トリップベースとタスクベース）を、開発環境で、または必要に応じてより構造化されたアクセス権の分離で関連付けます。このセクションをご覧ください。
[あなた] API キーの作成 - 開発環境で行うか、必要に応じてより構造化されたアクセスの分離（プロダクトごと、ドメインごとなど）を行います。
[お客様] 「Local Rides and Deliveries」などの API と、その他の必要な Google Maps Platform API（Geocoding、Autocomplete、Address Validation など）を有効にする。
[あなた] 割り当て: 特定の API で QPS（秒間クエリ数）の引き上げが必要な場合は、チケットを作成してサポートを受けてください。方法については、こちらをご覧ください。値上げが必要な理由を記載したビジネス上の正当な理由を追加する必要があります。事前定義された割り当てについては、こちらをご覧ください。
[あなた] 開発環境の認証情報を使用して開発したシステムがある場合、それらのシステムが、作成した新しいプロジェクト用に作成された新しい認証情報を参照できることを確認します。これには、バックエンドシステムとフロントエンドシステムが新しい認証情報（API キー、サービスアカウントなど）を指すこと、それぞれの環境で正しいプロジェクト ID が使用されることの確認が含まれます。

お支払い設定

ここでは、お客様がすでに Google と直接（該当する場合）またはパートナーを通じて契約を締結していることを前提としています。これは、次のステップで使用するウェルカムレターでモビリティの請求先アカウントを受け取るための前提条件です。

[お客様] 契約に署名して署名した後に Google からメールで送信されるウェルカムレターの一部として、モビリティ請求先アカウント ID が受信されたかどうかを確認します。重要: ウェルカムレターは、契約の注文フォームに記載されている技術担当者と財務担当者の連絡先に送信されます。プロジェクトチームと協力して、メールを受信した可能性のあるユーザーを確認し、そのユーザーから請求先アカウント ID を入手してもらってください。請求先アカウント ID は、ハイフンで区切られた文字と数字で構成されたものです。
[お客様] Google またはパートナーと協力して、請求の検証が行われるようにします。これは、お客様のシステムですでに Trips または ToDo リストが適切に Google に適切に報告されていることを意味します。詳しくは次のセクションで説明します。
[自分] Cloud コンソールを使用して、Google Cloud プロジェクトで新しい請求先アカウントを指すようにします。詳しくは、このドキュメントの請求先アカウントの構成セクションをご覧ください。

請求全般について詳しくは、こちらとこちらをご参照ください。

請求の検証

請求の検証は、請求が正しく行われていることを確認するために重要です。場合によっては、企業が API を誤って実装し、請求額の増加や過小報告につながることがあります。

請求の検証は次の手順で構成されます。

Google Maps Platform API へのリクエストで、リクエストヘッダーに tripId（または taskId）が含まれているかどうかを確認します。詳しくは、こちらをご覧ください。
ルート（またはタスク）が適切にレポートされているかどうかを確認する。これは、使用しているモビリティパッケージによって異なります。
- モビリティスターター / オプティマイズ、または Accelerate（ルートベース）: ReportBillableEvent API との統合が必要です。つまり、ルートが正常に完了したら、必ずこの API へのリクエストを行う必要があります。これが適切に行われているかどうかを確認するには、こちらで説明されている手順に沿って操作してください。
- モビリティ Accelerate（タスクベース）: API 呼び出しによって課金をトリガーする必要はありません。配信タスクのタスク結果が [SUCCEEDED] に設定されると、この処理が自動的に行われます。そのため、タスクの結果を FAILED または SUCCEEDED のいずれかに適切に設定することが非常に重要です。カスタマーエンジニア（パートナー様または Google）が連携して、実装が適切に行われたことを確認します。Cloud Logging で次の Cloud Logging クエリを実行すると、タスクが正しく更新されているかどうかを確認できます。
```
resource.type="fleetengine.googleapis.com/DeliveryFleet"
jsonPayload.@type="type.googleapis.com/maps.fleetengine.delivery.log.v1.UpdateTaskLog"
jsonPayload.request.task.taskOutcome="TASK_OUTCOME_LOG_SUCCEEDED"
```
エントリが表示された場合は、バックエンドシステムでタスクが SUCCEEDED に適切に設定されていることを意味します。

注: ただし、実際に完了したルートやタスクの数が、報告された通話の数と一致しているかどうかを確認することは重要です。請求イベントが報告されても、実際に完了した移動やタスクの合計とは一致しない（過少報告）。

統合の健全性

本番環境への移行が成功すると、課金が正常に機能しているだけでなく、API の実行の失敗も保証されます。モビリティサービスに関しては、Fleet Engine（Local Rides and Deliveries API）との統合が適切に実装されていることを確認することが重要です。

これを行うには、Cloud Logging を開き、次のクエリを使用します。

jsonPayload.errorResponse.code:*

問題のあるログエントリがすべて表示されます。次の例をご覧ください。

そうした問題は、BigQuery などの他の Cloud プロダクトにエクスポートできます。指標とアラートは、Cloud Logging のクエリに基づいて構成できます。

Cloud Logging クエリからの指標作成 — **Cloud Logging クエリからの指標の作成**

これらは Google Cloud プロダクトであるため、追加費用が発生する場合があります。詳しくは、パートナーまたは Google 担当者にお問い合わせください。

請求先アカウントの構成

すべてのシステムで [ルート] または [タスク] が適切に報告され、統合エラーが存在しない場合は、このドキュメントの前のセクションで説明されたウェルカムレターの一部として受け取った請求先アカウントにプロジェクトを指定します。

注: Maps パートナーと連携している場合は、この時点でサポートを受けることができます。以下の手順を単独で行う必要はありません。Google と直接連携している場合（一部の地域では対応不可）は、以下の手順に沿ってご対応ください。

その手順は次のとおりです。

Google Cloud コンソール（https://console.cloud.google.com）を開きます。
本番環境で使用する新しいプロジェクトを選択します。
プロジェクトの [お支払い] セクションに移動します。ショートカットで次のリンクにアクセスできます: https://console.cloud.google.com/billing
[お支払い] > [請求先アカウントを管理] をクリックします。

実際のプロジェクトは、上記とは異なる場合があります。
[お支払い] で、作成済みの本番環境プロジェクトの横にあるその他アイコンをクリックし、[請求先アカウントを変更] を選択します。
[お支払い] > [請求先アカウント] で、ウェルカムレターで受け取った請求先アカウントコードをプルダウンリストから選択します。[アカウントを設定] をクリックします。
プロジェクトは新しい請求先アカウントにリンクされます。

重要: これ以降、このプロジェクトで報告されたすべてのルートまたはタスクは、前述のとおりに請求されます。請求の検証がまだ行われていない場合は、まだ請求先アカウントをリンクしないでください。
新しいお支払い方法を追加したら、[概要] > [お支払いの概要]、[お支払い設定] に移動して、情報が正しいかどうかを確認します。ご請求とお支払いの更新について詳しくは、こちらのリンクをご覧ください。
請求に関する問題については、billingのサポートケースを送信するか、パートナーまたは Google の担当者にご相談ください。

請求レポート

請求レポートは、プロジェクトにリンクされている請求先アカウントに関連付けられた費用を把握するのに役立ちます。

注: Maps Partner をご利用の場合は、そのパートナーと協力して、必要なお支払い情報が提供されていることをご確認ください。

プロジェクトにリンクされた請求先アカウントを開き、[レポート] を選択します。その後、次のフィルタセットを使用できます。

ここで念頭に置くべき主な設定は、SKU によるグループ条件フィルタです。このフィルタには、前述のとおり、トリップとタスク、その他の API（使用した場合）の詳細情報（超過料金の有無など）が表示されます。

レポート情報は毎日更新されます。当日の情報が必要な場合は、Cloud Logging のクエリを使用して、その日に発生した請求対象イベントの数を確認できます。詳しくは、前のセクションをご覧ください。

立ち上げプラン

重要なポイントは、立ち上げ計画です。ビジネスの性質によっては、すべてのトラフィックがモビリティプロジェクトに移行されないことがよくあります。たとえば、すべての支店、フランチャイズ、店舗、オフィスなどに新しいソリューションをロールアウトするのに時間がかかる企業もあります。この場合、トラフィックの一部が古いシステムを使用し、トラフィックの一部が新しいプロジェクトに送られます。

また、多くの場合、すべてのトラフィックがモビリティのユースケースに該当するわけではありません。そのようなユースケースは、店舗検索、ピックアップ、その他の社内ソリューションに当てはまります。トラフィックはモビリティの請求先アカウントとは別に管理する必要があるため、これらのアカウントは Google Maps Platform の請求先アカウントを指す必要があります。

導入に関するポリシーを遵守することが重要です。

移動ベースモデル - 「オンデマンド配車と配達ソリューションは、オンデマンドの商用配車および配達サービスで使用することを目的としています。このようなサービスには、通常（a）特定の目的地への配車を依頼する消費者（または特定の物品の配達）と、（b）リクエストに合致したドライバー、サービスを完了するために車両を運転する消費者が含まれます。」
タスクベースのモデル - 「Google Maps Platform のラストワンマイルフリートソリューションは、商用のラストワンマイル配送とファーストワンマイルの集荷サービスで使用することを目的としています。このようなサービスには、通常、（a）お客様が所有または契約する配送車両、（b）事前に計画されたルートに基づく配送、（c）配送の実施をサポートする運用チームを持つ配送センターのネットワーク、（d）荷物を追跡して受け取る消費者が含まれます。」

そのため、どのシステムが Google Maps Platform の請求先アカウントを指す必要があるか、どのシステムがモビリティの請求先アカウントを指す必要があるかを理解する必要があります。複数のプロジェクトを所有し、それぞれが正しい請求先アカウントを指すのが一般的です。

たとえば、現在は使用制限に従い、すべてのルート / タスクに 10 件のジオコーディングリクエストが含まれているとします。移行に数か月かかり、最初の月に 10 万件の移動 / タスクの報告を開始する場合、Geocoding API を 100 万回呼び出すことができます。しかし、ビジネスの 500 万のジオコーディングをリクエストした場合、その差（400 万）は超過として報告される可能性があります。次の 2 つのオプションがあります。

Google に報告する移動 / タスクの数を増やした（立ち上げプランを加速する）ため、上限が引き上げられます。この場合、1 か月あたり 50 万の移動 / タスクを報告する必要があります。
前述のとおり、契約交渉時に上限を引き上げるための交渉を行います。
Geocoding API リクエストを Google Maps Platform API に指定すると、割引率が高くなり、超過料金よりも安くなります。

費用の見積もりはビジネスの規模と複雑さによって異なり、ユースケースが複雑になる場合があることは承知しています。既存のプロジェクトを使用して本番環境へのリリースを準備するのに最適な方法を判断するには、パートナーまたは Google の担当者にご相談ください。

まとめると、適切な立ち上げ計画を作成するには、次の手順が必要になります。 1. モビリティに関連するユースケースと実装ポリシーに従わないユースケースを特定します。 2. 関連するユースケースとそのボリュームに対して、現在どの Google Maps Platform API が使用されているかを確認します。3.モビリティソリューションの実装後も Google Maps Platform API が引き続き必要かどうかを確認します。たとえば、到着予定時刻の計算は Fleet Engine で自動的に行われ、Directions API ではもう計算する必要がなくなる可能性があります。 4. モビリティのユースケースをお客様側の新しいモビリティプラットフォームに完全に移行するのに要する時間を特定します。5. ユースケースをサポートするうえで、この使用制限で十分かどうかを再度確認します。 6. モビリティのユースケースにおいて、すべての Google Maps Platform リクエストをモビリティの請求先アカウントに集約できる転換点を特定する。

おわりに

結論として、請求先アカウントを適切に構成することは、料金の予測可能性と透明性のために不可欠です。最高水準の位置情報サービスを取り入れた Google のモビリティテクノロジーを使用することで、企業は、正確な請求処理を安心かつ効率的に行うことができます。これにより、費用を削減できるだけでなく、十分な情報に基づいてビジネス上の意思決定を行うために必要なデータと分析情報が得られます。さらに、このようなシステムが提供する透明性により、企業は支出を明確に把握できるため、より優れた予算管理につながります。

次のアクション

GCP コンソールで請求先アカウントを設定します。
一般的な課金の詳細については、以下をご覧ください。
- モビリティサービスの商用ドキュメント
- プロジェクトの課金を有効化、無効化、または変更する。