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

プロジェクトの構成

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

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

お支払い設定

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

[お客様] 契約の署名と履行後に 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"
jsonPayload.response.type="TASK_TYPE_LOG_DELIVERY"
```
エントリが表示された場合は、バックエンドシステムがタスクを 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] で、プルダウンリストからウェルカムレターに記載されている請求先アカウントコードを選択します。[SET ACCOUNT]（アカウントを設定）をクリックします。
プロジェクトは新しい請求先アカウントにリンクされます。

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

請求レポート

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

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

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

ここで注意すべき主な設定は、SKU 別の [グループ条件] フィルタです。このフィルタでは、前述のとおり、超過があったかどうかなど、乗車とタスクの詳細情報や、使用されている場合は他の API の詳細情報も表示されます。

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

運用開始プラン

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

また、多くの場合、すべてのトラフィックがモビリティユースケースに属するわけではありません。これは、店舗検索、カーブサイドピックアップ、その他の内部ソリューションの場合に当てはまります。これらのトラフィックはモビリティの請求先アカウントとは別に管理する必要があるため、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 のモビリティテクノロジーを使用することで、企業は請求プロセスが正確かつ効率的であることを確信できます。これにより、コストを削減できるだけでなく、情報に基づいたビジネス上の意思決定に必要なデータと分析情報も得られます。また、このようなシステムが提供する透明性により、企業は費用を明確に把握し、予算管理を改善できます。

次のアクション

Google Cloud コンソールで請求先アカウントを設定します。
お支払い全般について詳しくは、
- モビリティサービスの商用ドキュメント
- プロジェクトの課金の有効化、無効化、変更 bookmark_border。