Google Maps APIs for Work リリース前のチェックリスト

このページは、以前の Maps APIs for Work または Maps API for Business ライセンスのユーザーのみを対象にしています。このページの内容は、2016 年 1 月から利用可能になった新しい Google Maps APIs Premium Plan のユーザーには適用されません。

  1. チームが必要なリソースにアクセスできるようにする
    1. Google Maps APIs for Work ウェルカム レターの受信
    2. Google Cloud Support Portal へのアクセスと使用を許可する
    3. 関連通知フィードを購読する
    4. サポート ホットラインにいつでも連絡できるようにする
  2. アプリケーションの最適化
    1. Google Maps APIs サービスにアクセスできるようにファイアウォールを設定する
    2. SSL 経由で API を読み込む
    3. クライアント側 Maps API を SSL ドメインで使用する
    4. API の適切なバージョンの選択
    5. ページビュー使用状況を最適化する
    6. クライアント側とサーバー側の設計: ユースケースに適した設計を選択する
    7. ウェブサービスの割り当てと管理
    8. ロードテスト
  3. 無償版から Google Maps APIs for Work の実装に移行する
    1. ドメインの承認
    2. クライアント ID の統合
    3. 暗号化キーを使用してウェブサービス リクエストに署名する
    4. アプリケーションの使用状況と Channel パラメータを追跡する
    5. サポートが終了したパラメータを API リクエストから削除する

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

Google Maps APIs for Work ウェルカム レターの受信

重要な理由: ウェルカム レターは Google Maps APIs for Work の Starter Kit で、おそらく最初に必要となるキットです。ここにはクライアント ID や暗号化キーなどの重要な情報が含まれています。この情報は、Google Maps APIs の使用を開始するときに必要です。また、Google Cloud Support チームに問い合わせるために必要な情報もすべて含まれています。この情報は、Google Maps APIs で技術的な問題が発生した場合に必要になります。

Google Cloud Support Portal へのアクセスと使用を許可する

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

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

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

Google Cloud Support Portal アカウントを申請する

関連通知フィードを購読する

重要な理由: Google Maps APIs 全体の開発や変更に遅れないよう、関連通知フィードを購読することをお勧めします。以下で説明されているように、Google Geo Developers Blog や、使用している API に関連する通知 Google グループを購読します。

https://developers.google.com/maps/faq#notify

使用中または使用予定の API の通知グループを今すぐ購読してください。次の RSS フィードも購読できます。

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

この RSS フィードでは、Google Maps APIs サポートチームから最新情報を受け取ることができます。

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

1-877-355-5787(米国内のユーザー)、+1 404-978-9282(米国外のユーザー)

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

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

アプリケーションの最適化

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

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

  1. Google Cloud Support Portal にログインします。
    サポートポータルの利用は Google Maps APIs Premium Plan、以前の Google Maps APIs for Work、または Google Maps for Business ライセンスを所有するユーザーに限定されています。
  2. [Resources] タブに移動します。
  3. Google Maps APIs ファミリによって使用されるドメインのリストを選択します。
  4. アプリケーションからこのリストに示されたドメインへのアクセスを許可します。

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

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

SSL 経由で API を読み込む

重要な理由: Maps JavaScript APIウェブサービス API、またはイメージ API を SSL 経由で読み込むアプリケーションは、以前のホスト名 https://maps-api-ssl.google.com ではなく、https://maps.googleapis.com から読み込む必要があります。

クライアント側 Maps API を SSL ドメインで使用する

重要な理由: クライアント側 API を SSL ドメインで使用する場合、HTTPS ドメインを明示的に承認して、リクエストが拒否されないようにすることが重要です。http://yourdomain.com を承認しても、同じドメインで SSL を使用する https://yourdomain.com は自動的には有効にならないことに注意してください。Google Cloud Support Portal で承認済みのドメインのリストを確認するには、左側のナビゲーション メニューから [Maps: Manage Client ID] リンクを選択します。SSL ドメインでのクライアント側 API の使用に関連するエラーのトラブルシューティングを行うには、まずページの要素が HTTP 経由で読み込まれるかどうかをチェックします。また、Google Maps APIs for Work の実装の承認のトラブルシューティングに関する記事もご覧ください。

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

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

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

https://developers.google.com/maps/documentation/javascript/versions

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

ページビュー使用状況を最適化する

重要な理由: サイトで Google Map を常時表示しなくても、支払いが生じるのには理由があります。ページビューを効果的に使用するベスト プラクティスとして、実際にマップを表示するページに Maps API を非同期に読み込むことをお勧めします。これにより、アプリケーションが利用する購入済みページビューの数が大幅に少なくなります。API を読み込むページが更新されるたびに、ページビューが追加されることに注意してください。そのため、API を読み込むサイトでは、確実に必要な場合のみページを更新するようアプリケーションを設計することをお勧めします。

クライアント側とサーバー側の設計: ユースケースに適した設計を選択する

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

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

ウェブサービスの割り当てと管理

重要な理由: デフォルトでは、ウェブサービスの割り当ては、割り当て 1 つにつき、24 時間あたり 100,000 回のクエリに設定されています。API ごとに細分化された割り当ての詳細については、使用制限に関するドキュメントをご覧ください。お使いのクライアント ID で利用できる割り当て量を確認するには、サポートケースを提出します。サービスをリリースする前に、割り当て関連のさまざまなエラー(例: OVER_QUERY_LIMITUser Rate Limit Exceeded)を理解し、割り当て超過になった場合にこのようなエラーに対応できるよう、アプリケーションに適切なロジックを設定しておくことが重要です。まずは、Google Maps APIs ウェブサービスの使用制限に関する記事をご覧ください。これらの概念を理解してから実装すると、アプリケーションが許容割り当てを超えたり、Google によってブロックされたり、機能を停止する可能性が大幅に減少します。

ロードテスト

重要な理由: 実際の Google サービスに対してロードテストを行うと、アプリケーションに許容されている割り当てを超過し、Google によってブロックされることになります。

Google Maps APIs は非常に大量のリクエストにサービスを提供できます。2012 年には、「サンタを追いかけよう」で 1 秒あたり 1,600,000 回のリクエストにサービスを提供しました。したがって、Google サービスに対してロードテストを実行する必要はありません。代わりにアプリケーションのロードテストを行って、アプリケーションが Maps API の割り当てを超過することなく、大量のリクエストを処理できることを確認します。たとえば、Google Maps Geocoding API の割り当てが 20 QPS(1 秒あたりのクエリ数)だとします。この場合、アプリケーションのロードテストを行って、アプリケーションが 20 QPS を超えて Google Maps Geocoding API に送信することなく、600 QPS を処理できることを確認します。

これを安全に実現するには、ロードテストをモック(疑似) API に対して実行します。モック API とは、Google Maps APIs を必要としないで、大量のリクエストを受け入れて有効なレスポンスを返すサービスです。したがって、Google Maps APIs によってブロックされる危険を伴わずに、アプリケーションのロードテストを実行できます。

小さな Google App Engine アプリケーションとして実装されるこのモック API の例については、https://github.com/googlemaps/js-v2-samples/blob/gh-pages/mock_maps_apis/ をご覧ください。このモック API を独自の App Engine アプリケーションにアップロードし(https://appengine.google.com/ で登録後)、アプリケーションから maps.googleapis.com にではなく、この API にリクエストを送信できます。

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

API を無償版から Google Maps APIs for Work ライセンスに移行する

ドメインの承認

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

Google Street View Image APIGoogle Static Maps API は、クライアント側またはサーバー側のいずれかの形式で使用でき、どちらもページビューを伴います。そのため、これらの API では、暗号化キーを使用してリクエストに署名すること、およびこれらの API を使用するすべてのドメインを承認することが必要になります。これにより、アプリケーションが ToS に沿って適切に課金、サポートされ、SLA の対象になります。

Google Cloud Support Portal で承認済みのドメインのリストを確認するには、左側のナビゲーション メニューから [Maps: Manage Client ID] リンクを選択します。

承認の問題については、ケースを提出する前に、Google Maps APIs for Work の実装の承認に関するトラブルシューティングの記事を確認することをお勧めします。

クライアント ID の統合(例: &client=gme-yourclientid

重要な理由: アプリケーションで行える最も重要なことの 1 つは、リクエストに '&client=gme-yourclientid' を含めることです。一意のクライアント ID は、組織のプライマリ連絡先宛てに届くウェルカム レターに記載されています。クライアント ID によって、リクエストが Google Maps APIs for Work のリクエストであることが特定されます。Google Maps APIs for Work 固有の機能のメリットを得るためには、アプリケーションにクライアント ID を含める必要があります。テクニカル サポートを受けるため、およびアプリケーションが SLA の対象になるようにするためにも、クライアント ID を含めることが必要になります。

暗号化キー(例: vNIXE0xscrmjlyV-12Nj_BvUPaw=)を使用してウェブサービス リクエストに署名する

重要な理由: 秘密暗号化キーは、リクエストが信頼されるソースから発行されたことを Google に伝える署名を生成するために使用します。暗号化キーは、組織のプライマリ連絡先宛てに届くウェルカム レターに記載されています。ウェブサービスでは、Google Maps APIs for Work のユーザーとして暗号化キーを使用してリクエストに署名することが求められます。これにより、リクエストの上位にセキュリティのレイヤが追加され、クライアント ID に関連付けられた割り当てが適切に保護されます。

注: 暗号化キーは、署名の生成に使用されます。署名自体がリクエストに追加されることはありません。暗号化キーは ATM の暗証番号に似ています。アカウントにアクセスするための認証手段として使用されるため、信頼できないソースへの公開や提示は避けてください。適切に署名されていない Google Maps APIs for Work ウェブサービス リクエストは、サーバーによって拒否されるため、リリース前にアプリケーションがリクエストに適切に署名することが重要です(注: v2 Google Maps Geocoding API は現状署名を必要としません)。URL の署名については、次のドキュメントをご覧ください。

https://developers.google.com/maps/premium/previous-licenses/webservices/auth

アプリケーションの使用状況と Channel パラメータを追跡する

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

https://developers.google.com/maps/premium/previous-licenses/clientside/quota#reporting

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

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

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

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

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

サポートが終了したパラメータを API リクエストから削除する(例: '&key=ABQIAAAA…' パラメータ)

重要な理由: Google Maps JavaScript API を正しく読み込むには、クライアント ID を含める必要があります。また、key パラメータをすべて削除することも必要です。クライアント ID とキーの両方をリクエストに含めると、そのリクエストは失敗します。

API ごとに Google Maps APIs for Work リクエストの形式を正しく設定する方法の完全な情報については、Google Maps APIs for Work ガイド(https://developers.google.com/maps/premium/previous-licenses/)をご覧ください。