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

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

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

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

コンセプト

このセクションでは、Google マップの請求と、利用可能なさまざまな設定に関する基本情報を説明します。多くの状況では、正しい方法も間違った方法もありません。どのような結果を目指すかによって異なります。

このドキュメントでは、Google Cloud プロジェクトについて詳しく説明します。これは、Google マッププロダクトが Google アカウントを通じて利用できるからです。つまり、このドキュメントで説明する構成は、Google Cloud プロジェクトで作成されます。

請求先アカウント

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

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

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

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

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

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

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

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

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

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

料金について説明すると、Google Maps Platform にはさまざまな割引があります。これらの割引は、マップパートナーを通じて、または一部のシナリオでは Google から直接利用できます。これらの階層はボリュームベースであるため、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 リクエスト数に基づいて計算されます。モビリティサービスの場合、請求対象のモビリティ取引の量（完了したルートまたはタスク（集荷ではなく配送））に基づいて課金されます。これは契約の締結前に定義されます。ライドシェアリング会社やフードデリバリー会社の場合、乗車や配達の完了が成功指標となります。これはルートにマッピングされます。タスクは、荷物を確実に配達する必要がある物流会社や小売店に使用されます。

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

たとえば、フードデリバリー会社の場合、1 回の配達が完了するたびに 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 プロジェクトを追加で作成する必要があります。それまでは、開発環境という単一の環境しか存在しないことがほとんどです。

要件

お客様の側で以下のことができる人

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

新しいプロジェクトを設定して課金を構成する手順は次のとおりです。

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

プロジェクトの作成

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

プロジェクトの構成

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

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

お支払い設定

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

[お客様] 契約の締結後に Google からメールで送信される利用開始レターに、モビリティの請求先アカウント ID が記載されていることを確認します。重要: ウェルカムレターは、契約の注文フォームに記載されている技術担当者と財務担当者に送信されます。プロジェクトチームと連携して、メールを受け取った可能性のあるユーザーを特定し、そのユーザーに請求先アカウント ID（ハイフンで区切られた一連の文字と数字）を尋ねます。
[お客様] Google またはパートナーと連携して、課金の検証が実施されていることを確認します。これは、お客様のシステムがすでに、ルートまたはタスクを Google に適切に報告していることを意味します。詳しくは、次のセクションをご覧ください。
[お客様] Cloud コンソールを使用して Google Cloud プロジェクトを新しい請求先アカウントにポイントします。このドキュメントの請求先アカウントの構成のセクションをご覧ください。

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

お支払い情報の確認

請求の検証は、正しく請求されるようにするために重要です。誤って API を実装し、請求額の増加や報告の不足につながることもあります。

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

Google Maps Platform API へのリクエストのリクエストヘッダーに tripId（または taskId）が含まれているかどうかを確認する - 詳しくはこちらをご覧ください。
ルート（またはタスク）が正しく報告されているかどうかを確認します。これは、使用しているモビリティパッケージによって異なります。
- モビリティの Starter と Optimize、または Accelerate（ルートベース）: 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 Cloud コンソール（https://console.cloud.google.com）を開きます。
本番環境で使用する新しいプロジェクトを選択します。
そのプロジェクトの [お支払い] セクションに移動します。ショートカットとして、次のリンクにアクセスします。https://console.cloud.google.com/billing
[お支払い] > [請求先アカウントを管理] をクリックします。

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

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

請求レポート

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

注: Maps パートナーと連携している場合は、必要な関連する請求情報が提供されていることを確認してください。

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

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

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

立ち上げ計画

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

また、多くの場合、すべてのトラフィックがモビリティのユースケースに該当するわけではありません。店舗検索、店頭受け取り、その他の内部ソリューションがその例です。トラフィックはモビリティの請求先アカウントとは別に保持されるため、これらのリンク先は Google Maps Platform の請求先アカウントにする必要があります。

実装に関するポリシーに準拠することが重要です。

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

したがって、Google Maps Platform の請求先アカウントを指すシステムと、モビリティの請求先アカウントを指すシステムを把握する必要があります。複数のプロジェクトがあり、それぞれが適切な請求先アカウントを参照していることはよくあります。

たとえば、現在、使用量上限に基づき、すべてのルート / タスクに 10 件の地図変換リクエストが含まれているとします。移行に数か月かかる場合、最初の 1 か月で 10 万件のルート / タスクを報告すると、Geocoding API を 100 万回呼び出すことができます。ただし、ビジネスで 500 万件の地図座標変換リクエストを行った場合、その差額（400 万件）が超過として報告される可能性があります。次の 2 つの方法があります。

報告するルート / タスクの量を増やし（段階的な導入計画を加速）、上限を引き上げます。この場合、1 か月あたり 50 万件のルート / タスクを報告する必要があります。
上限を引き上げる交渉は、前述のように契約交渉の際に行います。
Geocoding API リクエストを Google Maps Platform API に転送すると、割引率の高い階層を利用できるため、超過分よりも低い料金で利用できます。

ビジネスの規模や複雑さ、ユースケースに応じて費用見積もりが複雑になる場合があります。既存のプロジェクトを使用して本番環境のリリースに向けて準備する最善の方法を決定するには、パートナーまたは Google の担当者にご相談ください。

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

まとめ

結論として、請求先アカウントを適切に設定することは、料金の予測可能性と透明性を確保するために不可欠です。クラス最高の位置情報サービスが組み込まれた Google のモビリティテクノロジーを使用すると、企業は課金プロセスの精度と効率性を高めることができます。これにより、費用を削減できるだけでなく、十分な情報に基づいてビジネス上の意思決定を行うために必要なデータと分析情報を提供できます。また、このようなシステムの透明性により、企業は費用を明確に把握できるため、予算管理が改善されます。

次のアクション

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