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

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

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

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

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

Google Cloud サポート ポータルを使用する

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

https://google.secure.force.com/

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

Google Cloud サポート ポータル アカウントをリクエストする

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

重要な理由: Maps API 全体の開発や変更に遅れないよう、以下の通知メールの配信登録を行うことをおすすめします。

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

関連通知フィードの配信登録の行う

重要な理由: Maps API の開発や変更に関する最新情報を確実に把握できるよう、関連する通知フィードの配信登録を行うことをおすすめします。詳細については、よくある質問をご覧ください。

Google Maps Premier API のお知らせ: サービス停止、更新、サービス通知に関する次の RSS フィードの配信登録を行うこともできます。

http://google.force.com/services/xml/MapsRSS

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

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

重要な理由: このホットラインは、Google Cloud サポート ポータルへの電話での連絡手段です。サポート ホットラインの電場番号を確認できるように、こちらのページをブックマークに登録してください。サポート ホットラインはサポートチームに技術的な問題を報告するために利用できますが、利用は運用環境が停止する場合と、サービスを利用できない場合に限られています。優先度レベルは、以下のドキュメントで定義されています。

https://support.google.com/googlecloud/answer/184028

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

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

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

  1. Google Cloud サポート ポータルにログインします。
    サポート ポータルは、Google Maps Platform プレミアム プランのお客様と、以前の Google Maps API for Work または Google Maps for Business のライセンスをお持ちのお客様のみご利用いただけます。
  2. [リソース] タブに移動します。
  3. Google Maps Platform ファミリーで使用されるドメインのリストを選択します(直接リンク)。
  4. アプリケーションからこのリストに示されたドメインへのアクセスを許可します。

これらのドメインに関連付けられた 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 を管理] リンクをクリックすると、Google Cloud サポート ポータルで承認済みドメインのリストを確認できます。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 ごとに細分化された割り当ての詳細については、使用制限のガイドをご覧ください。プロジェクトで利用できる割り当て量を確認するには、サポートケースを登録してください。

サービスをリリースする前に、割り当て関連のさまざまなエラー(例: OVER_QUERY_LIMITUser 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 Platform 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 を使用できません。ドメインはいつでも承認できます。リリース前に必ずすべてのサイトのドメインを承認するようにしてください。

左側のナビゲーション メニューの [マップ: クライアント ID を管理] リンクをクリックすると、Google Cloud サポート ポータルで承認済みドメインのリストを確認できます。

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

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