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

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

新しい Google マッププロジェクトを本番環境に実装する前に、使用しているプロダクトに対して適切な料金を支払えるように、設定が正しいことを確認する必要があります。このドキュメントでは、請求の透明性（請求書が発行される前に使用状況を確認できる）と、Google のプロダクトを使用できるようにするための適切なプロジェクト設定について説明します。

このプロセスは比較的簡単ですが、マップパートナーと連携して、プロジェクトが正しく移行されるようにすることもできます。

コンセプト

このセクションでは、Google マップの課金に関する基本的な情報と、さまざまな設定について説明します。多くの状況では、どちらが正しいということはありません。どのような結果を達成しようとしているかによって異なります。

このドキュメントでは、Google Cloud プロジェクトについて詳しく説明します。これは、Google マッププロダクトがこのプラットフォームを通じて利用できるためです。つまり、このドキュメントで説明する構成は Google Cloud プロジェクトで行われます。

請求先アカウント

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

モビリティの場合、特別な請求先アカウントがプロビジョニングされます。この請求先アカウントは、ライドシェア、配達、ロジスティクスなどのモビリティ関連のユースケースでのみ使用することを目的としています。

1 つの請求先アカウントを複数の Google Cloud プロジェクトで使用することも、1 つのプロジェクトで使用することもできます。

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

具体的なユースケース（モビリティユースケースなど）
請求書を分ける
割引は、この単一プロジェクトのボリュームに基づいて行われます

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

同じユースケース
使用量を集計して割引階層を活用する
単一の請求書

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

前述のように、1 つの請求先アカウントで複数のプロジェクトを指定できます。プロジェクトが複数ある場合は、モビリティサービスを使用するプロジェクトを特定し、モビリティの請求先アカウントにリンクする必要があります。モビリティユースケースが関連付けられていないプロジェクトは、現在使用している通常の Google Maps Platform 請求先アカウントを引き続き使用する必要があります。モビリティ請求先アカウントを取得するには、Google またはパートナーを通じてモビリティディールに署名する必要があります。以下に、請求先アカウントがスキーマ全体にどのように適合するかと、さまざまな設定の可能性を示します。

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

料金についてですが、Google Maps Platform では、マップパートナー経由または一部のシナリオで Google と直接契約することで、さまざまな割引が利用できます。これらの階層は使用量ベースであるため、プロダクトの使用量が多いほど料金が安くなります（割引は各 SKU に個別に適用されます）。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 Maps Platform プロダクトも使用していることを認識しています。したがって、モビリティ請求先アカウントを使用している場合は、同じモビリティユースケース内で事前定義された上限が守られている限り、Google Maps Platform を無料で呼び出すことができます。

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

月末に、システムで報告された（i）完了した乗車またはタスクの数と、（ii）事前に設定された上限を超える Google Maps Platform API 呼び出しの量（「超過分」）に基づいて請求書が生成されます。Google の上限は、市場で必要とされていると広く認識されているものに沿って設定されています。

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

試験運用と評価

お客様は、契約に署名する前に、Google Maps Platform の請求先アカウントでモビリティサービスの小規模なパイロット（概念実証、評価）を期間限定で実施できます。トライアルを実施する場合は、Google マップパートナーまたは Google の担当者にお問い合わせください。

試験運用期間中は、前述のとおり、契約がまだ締結されていないため、モビリティ請求先アカウントはご利用いただけません。つまり、Google Maps Platform プロダクトが使用されるたびに課金されますが、モビリティ固有のプロダクトは課金されません。つまり、試験運用期間中は、請求はタスクまたは乗車に基づくものではないため、この期間中は使用制限が適用されません。

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

まとめ

パイロット / 開発フェーズ: 一般公開されている Google Maps API のみ課金対象となります。一般公開されていない API と SDK は、プロジェクトでモビリティ課金アカウントが使用されるまで料金が発生しません。Google では、作成された新しい請求先アカウントごとに、Google Maps Platform の各 SKU の無料枠を提供しています。評価期間中の制御された環境では、これで十分です。
本番環境フェーズ: 走行距離またはタスクごとに料金が請求されます。Google Maps Platform に関連する費用は、使用量が契約の使用制限（上限）を超えた場合にのみ発生します。その場合は、超過分を支払うことになります。超過料金は、こちらで定義されているとおりに請求されます。

モバイル請求先アカウントに移行する方法

本番環境に移行する場合は、通常、QA（品質保証）や本番環境などのさまざまな環境を表す追加の Google Cloud プロジェクトを作成する必要があります。それまでは、おそらく開発環境という 1 つの環境しかありません。

要件

次のようなことができる、あなたの味方になってくれる人:

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

次の手順に沿って、新しいプロジェクトを設定し、その課金を構成します。

新しいプロジェクトの設定

プロジェクトの作成

[ユーザー] 新しい環境ごとに Google Cloud コンソールで新しい GCP プロジェクトを作成します。たとえば、本番環境、ステージング、品質保証などです。
[パートナーまたは Google チーム] モビリティプロダクトにアクセスできるように、新しいプロジェクトを許可リストに追加します。Google またはパートナーの営業担当者と連携し、前の手順で作成したプロジェクト ID を提供します。
[ユーザー] プロジェクトの重要な連絡先を更新します。この手順は、必要に応じて Google サポートチームがプロジェクトの適切な担当者に連絡できるようにするために非常に重要です。

プロジェクトの構成

前の手順で作成したプロジェクトについて、Google Cloud コンソールで次の操作を行います。

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

お支払い設定

ここでは、Google と直接（該当する場合）またはパートナー様を通じて契約を締結済みであることを前提としています。これは、次の手順で使用する Mobility 請求先アカウントをウェルカムレターで受け取るための前提条件です。

[お客様] 契約の署名と実行後に Google からメールで送信される利用開始レターの一部として、モビリティ請求先アカウント ID が届いているかどうかを確認します。重要: 契約の注文フォームに記載されている技術担当者と財務担当者に、ウェルカムレターが送信されます。プロジェクトチームと協力して、誰が受け取った可能性があるかを把握し、そのユーザーに請求先アカウント ID（ハイフンで区切られた一連の文字と数字）の提供を依頼します。
[お客様] Google またはパートナーと協力して、請求の検証が実行されていることを確認します。つまり、お客様のシステムがすでに Google に乗車またはタスクを適切に報告していることを確認します。詳細については、次のセクションをご覧ください。
[ユーザー] Cloud Console を使用して、Google Cloud プロジェクトを新しい請求先アカウントに関連付けます。このドキュメントの請求先アカウントの構成セクションをご覧ください。

一般的な請求の詳細については、こちらとこちらをご覧ください。

お支払い情報の確認

請求の検証は、請求が正しく行われるようにするために重要です。API の実装が誤っていると、請求額が増加したり、レポートの数値が過少になったりすることがあります。

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

Google Maps Platform API へのリクエストのヘッダーに tripId（または taskId）が含まれているかどうかを確認します。詳しくは、こちらをご覧ください。
乗車（またはタスク）が正しく報告されているかどうかを確認します。これは、使用されているモビリティパッケージによって異なります。
- Mobility Starter、Optimize、Accelerate（Trip Based）: ReportBillableEvent API との統合が必要です。つまり、乗車が正常に完了するたびに、この API へのリクエストを行う必要があります。この処理が正しく行われているかどうかを確認するには、こちらの手順に沿って操作する必要があります。
- Mobility 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:*

問題のあるすべてのログエントリが一覧表示されます。次に例を示します。

Cloud Logging を使用したエラーのクエリ — **Cloud Logging を使用してエラーをクエリする**

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

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

請求先アカウントの構成

すべてのシステムで乗車またはタスクが正しく報告され、統合エラーが存在しない場合は、プロジェクトを、ウェルカムレターで受け取った請求先アカウント（このドキュメントの前のセクションで説明）にリンクします。

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

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

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

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

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

請求レポート

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

注: Google マップパートナーと連携している場合は、必要な関連する請求情報が提供されるよう、パートナーと協力して対応してください。

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

ここで注意すべき主な設定は、SKU でグループ化するフィルタです。このフィルタを使用すると、前述のように、超過料金が発生したかどうかなど、乗車とタスクの詳細情報や、使用されている場合は他の API の詳細情報が表示されます。

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

立ち上げプラン

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

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

実装ポリシーを遵守していただくことが重要です。

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

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

たとえば、使用制限に従って、すべての Trip / Task に 10 件の Geocoding リクエストが含まれているとします。移行に数か月かかる場合、最初の月に 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 コンソールで請求先アカウントを設定します。
お支払い全般について詳しくは、
- モビリティサービスの商用ドキュメント
- プロジェクトの課金の有効化、無効化、変更 bookmark_border。