このページは 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 のモビリティサービスを使用するプロジェクトを特定し、モビリティ請求先アカウントをそのプロジェクトに提供する必要があります。モビリティユースケースが関連付けられていないプロジェクトでは、現在使用している通常の Google Maps Platform 請求先アカウントを引き続き参照する必要があります。モビリティの請求先アカウントを取得するには、Google またはパートナーを通じてモビリティディールを締結する必要があります。以下に、請求先アカウントがスキーマ全体にどのように適合するかと、可能なさまざまな設定を示します。

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

料金に関しては、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 リクエスト数に基づいて費用が計算されます。モビリティサービスの場合、請求対象のモビリティ取引の量（完了したルートまたはタスク（集荷ではなく配送））に基づいて課金されます。これは契約の締結前に定義されます。ライドシェアリング会社やフードデリバリー会社の場合、乗車や配達の完了が成功指標となります。これは [ルート] にマッピングされます。タスクは、荷物を確実に配達する必要がある物流会社や小売店に使用されます。

モビリティをご利用のお客様は、移動や配達の実行時に Google Maps Platform プロダクトも使用していることを Google は認識しています。そのため、モビリティの請求先アカウントを使用している場合は、同じモビリティユースケース内で事前定義された上限が尊重されている限り、無料で 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 プロジェクトを追加で作成する必要があります。それ以前は、おそらく開発環境では単一環境です

要件

次のことができる、味方の人物。

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

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

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

プロジェクトの作成

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

プロジェクトの構成

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

[自分] 適切なモビリティの関連付けを含むサービスアカウントの作成特定と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）が含まれているかどうかを確認する - 詳しくはこちらをご覧ください。
ルート（またはタスク）が適切に報告されているかどうかを確認する。これは、使用しているモビリティパッケージによって異なります。
- モビリティスターターと最適化、または 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:*

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

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

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

請求先アカウントの構成

すべてのシステムで出張やタスクが適切にレポートされるようになり、統合エラーも発生しなくなった場合は、ウェルカムレターの一部として受け取った請求先アカウント（このドキュメントの前のセクションで説明したもの）をプロジェクトで参照するようにしましょう。

注: マップパートナーと連携している場合は、この時点でパートナーがサポートを提供できるため、以下の手順を自分で行う必要はありません。Google と直接連携していて、一部の地域ではそれが難しい場合は、次の手順を行ってください。

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

Google Cloud コンソール（https://console.cloud.google.com）を開きます。
本番環境で使用する新しいプロジェクトを選択します。
そのプロジェクトの [お支払い] セクションに移動します。ショートカットとして、次のリンクにアクセスします。https://console.cloud.google.com/billing
お支払い >[請求先アカウントを管理] をクリックします。 <ph type="x-smartling-placeholder">
</ph>
実際のプロジェクトは上記とは異なる場合があります。
お支払いとご請求 >その他アイコンをクリックします。横にある [請求先アカウントを変更] を選択します。 <ph type="x-smartling-placeholder"></ph>
<ph type="x-smartling-placeholder"></ph>
お支払い >ウェルカムレターで受け取った請求先アカウントコードをプルダウンリストから選択します。次に、[アカウントを設定] をクリックします。
プロジェクトは新しい請求先アカウントにリンクされます。

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

請求レポート

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

注: マップパートナーをご利用の場合は、そのパートナーと協力して、必要なお支払い情報が確実に提供されるようにしてください。

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

ここで念頭に置く必要がある主な設定は、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。