リリース前のチェックリスト

Google Cloud Console でのクライアント ID の管理場所

プレミアムプランのクライアント ID 管理機能は、サポートポータルから、マップの [サービスアカウント] セクションにある [認証情報] ページの Cloud Console に移行します。

注: 現在、Google Maps Platform プレミアムプランは、新規お申し込みまたは新規お客様のご利用を受け付けていません。

チームが必要なリソースにアクセスできるようにする

Google Maps Platform プレミアムプランのウェルカムレターを安全な場所に保管する

重要な理由: ウェルカムレターは、Google Maps Platform プレミアムプランのスターターキットであり、おそらく最初に必要となるキットです。ここには、Google Cloud Console のプロジェクト ID、クライアント ID、秘密暗号化キーなどの重要な情報が含まれています。この情報は、プレミアムプランの使用を開始する際に必要となります。また、Google Maps API で技術的な問題が発生した場合に、プレミアムプランのサポートチームに連絡するために必要な情報もすべて記載されています。

Google Cloud Console を使用する

重要な理由: Google Cloud Console では、使用状況レポート、ニュースフィード、デベロッパー向けリソースなどの情報にアクセスできます。さらに重要なのは、開発中やリリース時に技術的な問題が発生した場合、このサポートポータルからプレミアムプランのサポートチームにサポートケースを提出できることです。

リリース前に、アプリケーションのメンテナンスを担当するすべてのデベロッパーが Cloud Console にアクセスできるようにしてください。Cloud Console にアクセスすると、技術的な問題が発生した際に、チームのメンバーからサポートに問い合わせることができるようになるだけでなく、サポートチームから問い合わせ元組織の適切な関係者に連絡することも可能になります。たとえば、アプリケーションの停止につながる異常なトラフィックや動作が見つかったとします。このような場合、サポートチームから問題が発生した組織への連絡が必要になることがあります。サポートチームから適切なデベロッパーに連絡を取れるかどうかによって、アプリケーションの停止という予期せぬ結果を招くか、停止を避けることができるかの分かれ目になることがあります。

通知メールの配信登録を行う

重要な理由: Maps API 全体の開発と変更に関する最新情報を確実に把握できるよう、以下の通知メールの配信登録を行うことをおすすめします。

google-maps-platform-notifications: Google Maps Platform API とウェブサービスに関する技術的な最新情報、サービス停止に関する通知、プラットフォームの機能に関するお知らせ（毎月 3〜5 件）を提供しています。
google-maps-js-api-v3-notify: Google Maps JavaScript API の新しいリリース（年間最大 4 件のメッセージ）を提供しています。

サポートホットラインにいつでも連絡できるようにする

1-877-355-5787（アメリカ国内のお客様）、+1 404-978-9282（アメリカ以外のお客様）

重要な理由: このホットラインはサポートへの電話での連絡手段です。各国への電話番号は、PIN と併せて Cloud Console で確認できます。サポートホットラインはサポートチームに技術的な問題を報告するために利用できますが、利用は運用環境が停止する場合と、サービスを利用できない場合に限られています。優先度レベルは、以下のドキュメントで定義されています。

アプリケーションを最適化する

Google Maps Platform サービスにアクセスできるようにファイアウォールを設定する

重要な理由: Google Maps Platform サービスではさまざまなドメインを使用します。中には *google.com ドメインに属していないドメインもあります。制限が厳しいファイアウォールに保護されている場合、各 Maps API サービスが使用するドメインへのアクセスを許可することが重要です。このようなドメインへのアクセスをファイアウォールが許可しない場合、API リクエストが失敗し、アプリケーションが停止する可能性があります。詳しくは、Maps API によって使用されるドメインの完全なリストをご確認ください。

これらのドメインに関連付けられた IP アドレスは静的なものではありません。そのため、IP アドレスでのファイアウォール制限の管理はおすすめしません。

注: Google Maps Platform サービスは、着信トラフィックと発信トラフィックにポート 80（http）と 443（https）を使用します。これらのサービスは、GET、POST、PUT、DELETE、HEAD の各リクエストも必要とします。API とユースケースに応じて、これらのポート経由のトラフィックを許可し、リクエストを許可するよう、ファイアウォールを設定します。

正しい SSL ホスト名で API を読み込む

重要な理由: Maps API を SSL 経由で読み込むアプリは、従来のホスト名である https://maps-api-ssl.google.com ではなく、https://maps.googleapis.com から読み込む必要があります。

Maps JavaScript API で使用する SSL ドメインを承認する

重要な理由: Maps JavaScript API を SSL ドメインで使用する場合は、明示的に HTTPS ドメインを承認して、リクエストが拒否されないようにすることが大切です。なお、http://yourdomain.com を承認しても、SSL の同等の機能の https://yourdomain.com が自動的に有効になるわけではありません。[クライアント ID] セクションまでスクロールして、Cloud Console で承認済みドメインのリストを確認します。SSL ドメインでのクライアント側 API の使用に関連するエラーのトラブルシューティングを行うには、ページの要素が HTTP 経由で読み込まれるかどうかをチェックします。詳しくは、承認のトラブルシューティングのガイドをご覧ください。

API の適切なバージョンを選択する

重要な理由: アプリケーションを開発する前に、すでに非推奨となっている API のバージョンを確認することが大切です。サポート対象のバージョンの API を対象に開発を進めておけば、サポートを終了したバージョンが利用できなくなった後の工程にかかる開発時間とコストを削減できます。

特に、Maps JavaScript API で使用される API のバージョニングスキームを理解し、環境内で不適切なバージョンの API を誤って使用しないことも重要です。

たとえば、開発環境やテスト環境では、試験運用版の API を使用するのが適していても、本番環境では試験運用版を使用しないことを強くおすすめします。SLA は安定したバージョンの API のみに適用されるため、本番環境では安定したバージョンのみを使用してください。

詳しくは、Maps JavaScript API のバージョンに関するガイドをご覧ください。

クライアント側とサーバー側との設計の選択

重要な理由: クライアント側のアプローチとサーバー側のアプローチのどちらを選択するかによって、アーキテクチャが決まります。そのため、アプリケーションの安定性と拡張性にとってはこの選択が極めて重要になります。全般的に見て、レコードの処理前後はオフラインにする（アプリケーションの外部で処理する）場合は、サーバー側のアプローチを使用します。これに対して、アプリケーションの中でユーザーと対話する（ユーザーが送信するリクエストをリアルタイムで処理する）部分にはクライアント側のアプローチを使用します。

クライアント側のアプローチを使用すべき状況で代わりにサーバー側のアプローチを採用すると、割り当て超過を引き起こし、アプリケーションが機能しなくなります。サーバー側の呼び出しを使用するアプリケーションを設計またはリリースする前に、ジオコーディング戦略に関するドキュメントを確認することを強くおすすめします。

割り当ての使用状況を最適化する

重要な理由: アプリケーションが割り当てを消費する方法（Maps API クレジット）を理解すると、支払う費用を削減できます。たとえば、Maps JavaScript API を使用している場合、アプリケーションは地図の読み込みごとに Maps API クレジットを消費します。プレミアムプランの使用レートと使用制限に関するガイドをご覧ください。

ウェブサービスの割り当て使用状況を管理する

重要な理由: デフォルトでは、共有ウェブサービスの割り当てが 1 日あたり 100,000 回の無料リクエストに設定されています。API ごとに細分化された割り当ての詳細については、使用制限のドキュメントをご覧ください。割り当てに関する問題が発生した場合は、Cloud Console で割り当てを確認するか、サポートケースを登録してください。

サービスをリリースする前に、割り当て関連のさまざまなエラー（例: OVER_QUERY_LIMIT、User Rate Limit Exceeded）を理解し、割り当て超過になった場合にこのようなエラーに対応できるよう、アプリケーションに適切なロジックを設定しておくことが重要です。まずは、使用制限に関するよくある質問をご確認ください。各 API から返されるステータスコードの情報は、該当する API のデベロッパーガイドをご確認ください。たとえば、Directions API のステータスコードに関するガイドがあります。これらの概念を理解してから実装すると、アプリケーションが許容割り当てを超えたり、Google によってブロックされたり、機能を停止する可能性が大幅に減少します。

アプリでロードテストを実行する

重要な理由: アプリケーションのロードテストを使用すると、Maps API の割り当てを超えずに大量のリクエストを処理できるようになります。

実際の Google サービスに対してロードテストを行うと、アプリケーションに許容されている割り当てを超過し、Google によってブロックされることになります。Google Maps Platform では、非常に大量のリクエストを処理できます。2012 年には、「サンタを追いかけよう」が毎秒 1,600,000 件のリクエストを処理しました。したがって、Google サービスに対してロードテストを実行する必要はありません。代わりにアプリケーションのロードテストを行って、アプリケーションが Maps API の割り当てを超過することなく、大量のリクエストを処理できることを確認します。例: Geocoding API の割り当てが 20 QPS（1 秒あたりのクエリ数）の場合、アプリケーションのロードテストでは、Geocoding API に 20 QPS を送信しなくても、600 QPS を処理できるかをチェックする必要があります。

これを安全に実現するには、ロードテストをモック（疑似）API に対して実施します。モック API とは、Google Maps Platform を関与させずに、大量のリクエストを受け入れて有効なレスポンスを返すことができるサービスです。そのため、Google Maps Platform によってブロックされるリスクなしでアプリケーションのロードテストを実行できます。

小規模な Google App Engine アプリケーションとして実装されるモック API のサンプルをご覧ください。このサンプルを独自の App Engine アプリケーションにアップロードし（appengine.google.com で登録後）、maps.googleapis.com にではなく、そのアプリケーションでリクエストを実行することもできます。

デフォルト（無償版）の App Engine の割り当ては、通常、アプリケーションのロードテストを十分に実行できるよう、Maps API ウェブサービスの割り当てを大幅に超えています。アプリケーションで、レスポンスの圧縮を有効にする適切な User-Agent ヘッダーを設定していることを確認してください。この設定は、帯域幅を効果的に使用するために重要です。特に、書式なしテキスト（JSON/XML）のレスポンスを大量に処理する App Engine アプリケーションでは重要です。App Engine アプリケーションに多くの割り当てが必要な場合、課金を有効にすることも可能ですが、めったに必要になることはありません。

アプリケーションのライセンスを標準ライセンスからプレミアムライセンスに移行する

API のリクエストにクライアント ID または API キーを含める

重要な理由: アプリケーションで行える最も重要なことの一つは、API リクエストに、クライアント ID（gme-yourclientid）または API キー（例: AIzaSyBdVl-cTICSwYKrZ95SuvNw7dbMuDt1KG0）を含めることです。クライアント ID または API キーによって、リクエストを Google Maps Platform のプレミアムプランのリクエストとして識別します。

プレミアムプラン専用の機能を活用するには、アプリケーションにクライアント ID または API キーを含める必要があります。テクニカルサポートを受けるため、およびアプリケーションが SLA の対象になるようにするためにも、クライアント ID または API キーを含めることが必要になります。

ほとんどの API では、クライアント ID または API キーのどちらを使用するかを選択できます。クライアント ID は、組織のプライマリ連絡先宛てに届くウェルカムレターに記載されています。独自の API キー、または Google Cloud Console でキーを生成できます。

詳しくは、認証と承認のガイドをご覧ください。

API のリクエストに API キーまたはクライアント ID の一方は含めても両方は含めない

重要な理由: Maps JavaScript API を正しく読み込む、または他の Google Maps API にリクエストを送信するには、クライアント ID か API キーのいずれか（両方ではなく）を含める必要があります。クライアント ID を使用する場合は、key パラメータをすべて削除する必要があります。リクエストにクライアント ID とキーの両方が含まれていると、予期しない動作やエラーが発生する可能性があります。

API ごとにプレミアムプランリクエストの形式を正しく設定する方法について詳しくは、認証と承認に関するガイドをご覧ください。

クライアント ID の使用時にドメインを Maps JavaScript API で使用できるよう承認する

重要な理由: 未承認のサイトではクライアント ID を使用できないようにするため、Maps JavaScript API では、クライアント ID を使用するすべてのサイトのすべてのドメインでサポートチームを承認する必要があります（クライアント ID ではなく API キーを使用する場合、URL 登録は必要ありません）。クライアント ID の使用が承認された URL と、クライアント ID を使おうとしているサイトが一致しない場合、サイトはそのクライアント ID で API を使用できません。ドメインはいつでも承認できます。リリース前に必ずすべてのサイトのドメインを承認するようにしてください。

Cloud Console で承認済みドメインのリストを確認するには、[認証情報] ページに移動して [クライアント ID] セクションをクリックします。

承認の問題については、ケースを登録する前に承認のトラブルシューティングに関するガイドを確認することをおすすめします。

クライアント ID の使用時は、秘密暗号化キーで生成した署名を使ってウェブサービスリクエストに署名する

秘密暗号鍵は、リクエストが信頼されるソースから発行されたことを Google に伝える署名を生成するために使用します。ウェブサービス API では、認証にクライアント ID を使用している場合、デジタル署名をリクエストに追加することが求められます。これにより、リクエストの上位にセキュリティのレイヤが追加され、クライアント ID に関連付けられた割り当てが適切に保護されます。暗号鍵（vNIXE0xscrmjlyV-12Nj_BvUPaw= など）は、組織の連絡先担当者宛てに届くウェルカムレターに記載されています。

注: 暗号鍵は署名の生成に使用されます。署名自体がリクエストに追加されることはありません。暗号化キーは ATM の暗証番号に似ています。アカウントにアクセスする際の認証手段として利用するものであり、広く共有したり、信頼できないソースに知らせたりするべきではありません。適切に署名されていないプレミアムプランのウェブサービスリクエストは、サーバーによって拒否されるため、リリース前にアプリケーションがリクエストに適切に署名することが重要です。認証と承認に関するガイドをご覧ください。

アプリケーションの使用状況を追跡する

重要な理由: プレミアムプランをご利用のお客様は、実行されたリクエスト、消費されたクレジット、返されたエラーなど、アプリケーションの使用状況に関する詳細なレポートにアクセスできます。レポートに関するガイドをご覧ください。

channel は省略可能なパラメータです。このパラメータを使ってアプリケーションごとに個別のチャネルを割り当て、クライアント ID でアプリケーションの使用状況を追跡できます。channel パラメータをクライアント ID に登録する必要はありません。channel パラメータを API リクエストに追加するだけで、実装してから 1～2 日後にサポートポータルの使用状況レポートに、チャネルごとの使用状況の結果の表示が始まります。チャンネルの実装先と使用状況の集計方法はユーザーが決めます。アプリケーションの使用状況を追跡するためにアプリケーションで channel パラメータを統合するかどうかは、リリース前に判断してください。

channel パラメータは次の形式を使用する必要があります。

ASCII 英数字の文字列にする必要があります。
ピリオド（.）、アンダースコア（_）、ハイフン（-）の各文字を使用できます。
channel パラメータでは大文字と小文字が区別されません。大文字および大文字小文字混合の channel パラメータは、小文字の同等のものに統合されます。たとえば、CUSTOMER チャネルの使用状況は、customer チャネルの使用状況と結合されます。

クライアント ID ごとに最大 2,000 個のチャネルを個別に実装できます。

channel パラメータを使用するには、クライアント ID を渡すために使用される client パラメータとともにリクエスト URL に含めます。

channel パラメータはアプリケーションごとに静的に割り当てる値にする必要があることに注意してください。パラメータを動的に生成したり、個人ユーザーを追跡するために使用してはいけません。