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

Google Maps Platform のセキュリティに関するガイダンス
コレクションでコンテンツを整理必要に応じて、コンテンツの保存と分類を行います。

Google Maps Platform の API と SDK を使用するアプリとプロジェクトは、API キーまたは（サポートされている場合）OAuth 2.0 を使用して認証する必要があります。

このベストプラクティスでは、Maps Platform へのアクセスを保護する方法について説明します。

OAuth 2.0 を使用してサーバー間トラフィックを承認する場合は、API ドキュメントで OAuth のトピックをご覧ください。詳しくは、サーバーサイドアプリに OAuth を使用するをご覧ください。

キーにアプリケーションと API の制限をかけるだけでなく、Google Maps Platform の各プロダクトに固有のセキュリティ対策があれば実施しましょう。たとえば Maps JavaScript API を利用する場合、後続の推奨されるアプリケーション制限と API 制限セクションを参照してください。

すでに使用中の API キーを扱う際は、この後の使用中の API キーに制限を適用する場合以下の推奨事項をご確認ください。

Maps Static API と Street View Static API でサポートされているデジタル署名について詳しくは、デジタル署名ガイドをご覧ください。

推奨されるベストプラクティス

以下、Google Maps Platform の各 API、SDK、およびサービスにおける、API のセキュリティに関するベストプラクティスを紹介します。セキュリティの強化と不正使用による料金発生の防止にご活用ください。

使用中の API キーを制限またはローテーションする場合

API キーを変更する前に、API キーの使用状況をチェックしましょう。本番環境のアプリですでに使用されているキーに制限を追加する場合はこのステップが特に重要です。
キーを変更した後は、必要に応じてすべてのアプリをアップデートし、新しい API キーに移行させます。
API キー��不正使用されておらず、不正使用も行われていない場合は、ご自分のペースでアプリを複数の新しい API キーに移行させていくことも可能です。この場合、元の API キーはトラフィックが 1 種類だけになるまでそのままにしておき、その後はアプリケーション制限によって各 API キーのトラフィックをその 1 種類に制限します。API キーは、意図しないサービス中断を引き起こすことなく、単一タイプのアプリケーション制限で安全に制限できます。

詳しい手順については、複数の API キーを使った運用に移行するをご覧ください。

使用状況の推移をモニタリングしましょう。旧 API キーの制限や削除を行うのは、個々の API、プラットフォームタイプ、ドメインが旧 API キーを使用しなくなったことを確認できてからにします。詳細については、レポートとモニタリングと指標をご覧ください。
すでに API キーの不正使用が発生している場合は、より迅速に API キーを移行して安全を確保し、悪用を阻止する必要があります。Android / iOS アプリの場合、ユーザーがアプリをアップデートするまでキーの交換は反映されません。ウェブページまたはサーバーサイドアプリでのキーの更新や置き換えははるかに単純ですが、それでも、これらのキーを更新したり置き換えたりする場合には、慎重に計画し、迅速に作業を行うことが求められます。

詳しくは、API キーの不正使用に対応するをご覧ください。

詳細

推奨されるアプリケーション制限と API 制限

API キーの制限

API キーにはいつでも、1 種類のアプリケーション制限と 1 つ以上の API 制限をかけることをおすすめします。各 API、SDK、JavaScript サービスで推奨される制限の種類は、後続の推奨されるアプリケーション制限と API 制限でご確認いただけます。

アプリケーションの制限: 該当 API キーの使用を、特定のプラットフォーム（Android または iOS アプリケーション、クライアントサイドアプリケーションの場合は特定のウェブサイト、ウェブサービス REST API 呼び出しを行うサーバーサイドアプリの場合は特定の IP アドレスまたは CIDR サブネット）に限定できます。

API キーのアプリケーション制限は、許可するプラットフォームを指定する形で適用します（複数可）。適用後は、指定したソースからのリクエスト以外は許可されなくなります。

注: アプリケーション制限をかけると、その API キーは他のプラットフォームでは使用できなくなります。たとえば Android アプリのみに制限した API キーは、iOS、ウェブサービス、JavaScript API では使用できません。
API 制限: 該当 API キーを使用できる Google Maps Platform の API、SDK、サービスを限定します。API 制限をかけると、指定した API や SDK からのリクエスト以外は許可されなくなります。同じ API キーに適用する API 制限の数に上限はありません。指定可能な API のリストには、該当プロジェクトで有効化されている API がすべて含まれます。

重要: API 制限で指定（許可）する API や SDK が、その API キーに適用済みのアプリケーション制限のタイプに対応していることを確認しましょう。たとえば、アプリケーション制限で iOS に限定してある API キーでは、iOS で利用可能な API を許可する必要があります。

API キーのアプリケーション制限の設定

Google Cloud コンソールの Google Maps Platform の [認証情報] ページを開きます。
制限をかける API キーを選択します。
[API キーを編集] ページで、[キーの制限] の下の [アプリケーションの制限の設定] を選択します。

いずれかの制限タイプを選択し、制限リストに沿って必要な情報を指定します。

制限タイプ	説明
ウェブサイト	リファラー（リクエスト元）ウェブサイトを 1 つまたは複数指定します。共通でサポートされる URI スキームは `https` と `http` です。他のスキームは、プライバシー上の理由から、送信リクエストで「Referer」ヘッダーを送信しないため、正しく動作する保証はありません。リファラーは必ず、プロトコルスキーム、ホスト名、必要ならポート名を含めた完全な文字列で指定してください（例: `https://google.com`）。ワイルドカード文字を使って、サブドメインを一括で許可すること��可能です。��と��ば `https://*.google.com` と指定すれば、末尾が `.google.com` のサイトをすべて許可できます。許可するリファラーをフルパス（例: `https://google.com/some/path`）で指定する際は注意が必要です。ほとんどのウェブブラウザでは、プライバシー上の理由から、クロスオリジンリクエストのパスが削除されます。
IP アドレス	IPv4 または IPv6 のアドレス、あるいは CIDR 表記のサブネットを、1 つまたは複数指定します。指定する IP アドレスは、Google Maps Platform のサーバーが観測するソースアドレスと一致している必要があります。ネットワークアドレス変換を使用している場合、このアドレスは通常、ご使用のマシンの公開 IP アドレスに対応します。
Android アプリ	許可する Android アプリケーションのそれぞれについて、Android パッケージ名（`AndroidManifest.xml` ファイルより）と SHA-1 署名証明書フィンガープリントを追加します。署名証明書フィンガープリントの取得に Play アプリ署名を使用している場合は、API プロバイダを利用するをご覧ください。独自の署名鍵を管理している場合は、アプリで自己署名を行うを確認するか、ビルド環境の説明書をご参照ください。
iOS アプリ	許可する iOS アプリケーションのそれぞれについて、バンドル ID を追加します。

アプリケーション制限の推奨事項については、推奨されるアプリケーション制限をご覧ください。

[保存] を選択します。

API キーの API 制限を設定する

Google Cloud コンソールの Google Maps Platform の [認証情報] ページを開きます。
制限をかける API キーを選択します。
[API キーを編集] ページの [API の制限] 欄で、以下を行います。
- [キーを制限] を選択します。
- [Select APIs] プルダウンを開き、アプリケーションが該当 API キーを使ってアクセスできるようにする API や SDK をすべて選択します。
目的の API または SDK がリストにない場合、まず有効化する必要があります。詳しくは、1 つ以上の API または SDK を有効にするにはをご覧ください。
[保存] を選択します。

このステップを終えると、指定した制限内容は API キーの定義の一部となります。適切な情報を入力してから [保存] をクリックし、API キーの制限を保存してください。詳細については、目的の API または SDK のドキュメントで API キーの取得についてのガイドをご覧ください。

推奨される API 制限については、推奨される API 制限をご覧ください。

API キーの使用状況をチェックする

すでに作成済みの API キーに制限をかける場合や、制限をかけるにあたってキーが使用している API を確認したい場合は、API キーの使用状況をチェックします。この手順では、該当 API キーが使用されているサービスと API メソッドを確認することができます。Google Maps Platform のサービス以外でも使用が見られる場合は、詳しく調べましょう。意図しない使用を防ぐため、制限の追加が必要となることもあります。API キーに適用するべき API 制限とアプリケーション制限の種類を判断する際は、Cloud コンソールで Google Maps Platform の Metrics Explorer を使用すると便利です。

該当 API キーを使用している API を特定する

API キーを使用している API を特定するには、このセクションで解説するレポート群を使用します。これらのレポートでは以下が可能です。

API キーがどのように使用されているか確認する
想定外の使用を検出する
使用していないキーを安全に削除できるか調べる。API キーの削除については、使用していない API キーを削除するをご覧ください。

API 制限を適用する際は、これらのレポートを使えば、許可する API の一覧を作成することや、自動提案された API キー制限を検証することが可能です。推奨される制限について詳しくは、推奨される制限を適用するをご覧ください。Metrics Explorer の使用方法について詳しくは、Metrics Explorer でグラフを作成するをご覧ください。

Google Cloud コンソールの Metrics Explorer に移動します。
ログインして、チェックしたい API キーのプロジェクトを選択します。
API の種類に応じて、Metrics Explorer の適切なページを開きます。
- Maps Embed API 以外の API を使用する API キーの場合: Metrics Explorer の該当ページ
- Maps Embed API を使用する API キーの場合: Metrics Explorer に移動します。
各 API キーを調べます。方法は次のとおりです。
1. [フィルタを追加] を選択します。
2. ラベル欄で「credential_id」を選択します。
3. 値の欄で、調べたいキーに対応する値を選択します。
4. 該当 API キーが使用されている API をメモし、想定外の使用でないことを確認します。
5. 終わったら、追加したフィルタ行の末尾にある（フィルタを削除）を選択して削除し、元の状態に戻します。
他にもキーがある場合は、同様の手順を繰り返します。
キーに API 制限をかけて、使用されている API だけを許可します。
不正使用が見つかった場合は、API キーの不正使用に対応するをご覧ください。

適用するべきアプリケーション制限のタイプを Metrics Explorer で選ぶ

API キーの調査が終わり、想定の Google Maps Platform サービス以外では該当キーが使われないよう必要なアクションを済ま��たら、次はアプリケーション制限も正しいものが適用されていることを確認しましょう。

API キーに対して、推奨される API キー制限が自動提案されている��合、適用します。詳しくは、自動提案された API キー制限を適用するをご覧ください。

推奨される API キー制限の自動提案が行われていない場合は、Metrics Explorer のレポートで確認できる platform_type に応じて、適用するべきアプリケーション制限のタイプを判断します。

Google Cloud コンソールの Metrics Explorer に移動します。
ログインして、チェックしたい API のプロジェクトを選択します。
Metrics Explorer の該当ページを開きます。
各 API キーを調べます。方法は次のとおりです。
1. [フィルタを追加] を選択します。
2. ラベル欄で「credential_id」を選択します。
3. 値の欄で、調べたいキーに対応する値を選択します。
4. 終わったら、追加したフィルタ行の末尾にある（フィルタを削除）を選択して削除し、元の状態に戻します。
他にもキーがある場合は、同様の手順を繰り返します。
該当 API キーの platform_type を確認できたら、そのプラットフォームタイプに応じたアプリケーション制限を適用します。

PLATFORM_TYPE_JS : ウェブサイト指定型のアプリケーション制限をかけます。

PLATFORM_TYPE_ANDROID : Android アプリ指定型のアプリケーション制限をかけます。

PLATFORM_TYPE_IOS : iOS アプリ指定型のアプリケーション制限をかけます。

PLATFORM_TYPE_WEBSERVICE : 適切に制限するためには、IP アドレス指定型のアプリケーション制限が必要な可能性があります。

Maps Static API と Street View Static API に関する推奨事項については、Static Web API の使用を保護するをご覧ください。

Maps Embed API の推奨事項については、Maps Embed API を使ったウェブサイトをご覧ください。

API キーが複数のプラットフォームタイプを使用している場合: 単一の API キーではトラフィックのセキュリティを十分に確保できません。複数の API キーを使った運用に移行する必要があります。詳しくは、複数の API キーを使った運用に移行するをご覧ください。

アプリごとに個別の API キーを使用

各キーの使用範囲を限定する運用方法です。この方法なら、ある API キーが不正使用されても、そのキーだけを削除またはローテーションすればよく、他の API キーを更新する必要はありません。API キーはプロジェクトごとに最大 300 個まで作成できます。詳細については、API キーの制限をご覧ください。

各アプリケーションと API キーを 1 対 1 で対応させるのがセキュリティ上は理想的ですが、アプリケーション制限のタイプが共通であれば、制限をかけたキーを複数のアプリで使用することも可能です。

自動提案された API キー制限を適用する

一部のプロジェクトオーナー、編集者、API キー管理者に対しては、まだ制限をかけられていない API キーについて、Google Maps Platform の使用状況とアクティビティに応じて Google Cloud コンソールが推奨する具体的な API キー制限が提案されます。

自動提案がある場合、Google Maps Platform の [認証情報] ページに事前入力済みのオ��ョン��て表示されます。

自動推奨でサポートされている Google Maps Platform API と SDK

Maps JavaScript API（Directions Service（従来版）、Distance Matrix Service（従来版）、Elevation Service、Geocoding Service、Place クラス、Place Autocomplete ウィジェット（新規）、Place Autocomplete Data API、Places Library、Places Service、Place Autocomplete ウィジェットを含む）
Maps Static API と Street View Static API
Maps Embed API
Maps SDK for Android、Places SDK for Android、Navigation SDK for Android
Maps SDK for iOS、Places SDK for iOS、Places Swift SDK for iOS、Navigation SDK for iOS

提案が表示されなかったり完全なものではなかったりする原因

最適化案が表示されない理由

Google Maps Platform サービス以外で（も）API キーを使用している、または自動推奨機能でまだサポートされていない Maps Platform サービスを使用している。

他のサービスで使用している場合は、次の手順を必ず行ってから、提案を適用してください。
1. Google Cloud コンソールの Metrics Explorer に表示される API の使用法が適切であることを確認します。
2. 許可が必要な API のリストに不足しているサービスを手動で追加します。
3. API リストに追加したサービスに対して不足しているアプリケーション制限を手動で追加します。追加したサービスに異なるタイプのアプリケーション制限が必要な場合は、複数の API キーへの移行を参照してください。
該当 API キーがクライアントサイドの SDK または API で使用されていない。
該当 API キーを使用しているアプリまたはウェブサイトが低ボリュームで、過去 60 日間に利用が発生していない。
ごく最近作成した新しいキーである、または新しいアプリにごく最近デプロイしたキーである。この場合、何日か待てば提案内容も更新されます。
該当 API キーを使用しているアプリケーションが複数あり、必要となるアプリケーション制限のタイプが一致していない、または同じ API キーを使用しているアプリやウェブサイトの数が多すぎる。どちらの場合も、複数のキーを使った運用に切り替えるのがベストプラクティスです。詳しくは、複数の API キーを使った運用に移行するをご覧ください。

不完全な最適化案が表示される理由

該当 API キーを使用しているアプリまたはウェブサイトが低ボリュームで、過去 60 日間に利用が発生していない。
新しい API またはサービスで既存のキーの使用をごく最近開始したため、API キー制限の自動推奨パイプラインが更新された使用状況指標をまだ処理していない。使用状況の指標が反映されるまで数日かかることがあります。

他のサービスで使用している場合は、次の手順を必ず行ってから、提案を適用してください。
1. Google Cloud コンソールの Metrics Explorer に表示される API の使用法が適切であることを確認します。
2. 許可が必要な API のリストに不足しているサービスを手動で追加します。
3. API リストに追加したサービスに対して不足しているアプリケーション制限を手動で追加します。追加したサービスに異なるタイプのアプリケーション制限が必要な場合は、複数の API キーへの移行を参照してください。
4. 不正使用など、キーを緊急に制限する必要がある場合を除き、推奨事項が反映されるまで 1 ～ 2 日待つこともできます。
  
  ヒント: 緊急の場合は、API キーの不正使用に対応するをご覧ください。

提案がグラフに表示されていない原因

アプリまたはウェブサイトが送信したトラフィックバーストが非常に短かった。この場合、[グラフ] ビューから [表] または [両方] に切り替えて、このように短い場合でも使用状況が表示されるようにします。詳しくは、グラフの全凡例の表示 / 非表示を切り替える方法をご覧ください。
トラフィックが Maps Embed API で発生している。該当 API キーを使用している API を特定するで手順をご確認ください。
アプリまたはウェブサイトからのトラフィックが、Google Cloud コンソールの Metrics Explorer で使用できる期間外のものである。

自動提案された制限を適用する方法

Google Cloud コンソールの Google Maps Platform の [認証情報] ページを開きます。
表示されていれば、[推奨される制限事項を適用] 選択します。

注: 推奨される制限が表示されていない場合は、API キーの API 制限を設定するを参照して、適切な制限をかけます。
[API の使用状況を確認] を選択して、API キーが使用されているサービスを確認します。Google Maps Platform サービス以外のサービスの場合は、一時停止して上記の提案手順に沿って手動で使用状況を確認してください。自動提案された API キー制限を適用するセクションの冒頭にあるトラブルシューティング手順を参照してください。
事前入力されている制限の内容が、該当 API キーを使用する予定のウェブサイトおよびアプリと合致しているか確認します。

ベストプラクティス: 使用するサービスと関係のないアプリケーション制限または API 制限があれば、記録を取ったうえで削除しましょう。想定外の依存関係があり、削除によって問題が生じた場合は、必要なアプリケーション制限または API 制限を追加し直します。
- アプリ、ウェブサイト、または API が提案に明らかに含まれていない場合は、手動で追加するか、提案が更新されるまで数日待ってください。
- 提案についてさらにサポートが必要な場合は、サポートにお問い合わせください。
[適用] を選択します。

提案内容を適用後にアプリケーションが不承認となった場合の対応

制限を適用した後にアプリまたはウェブサイトが不承認となった場合、API レスポンスのエラーメッセージ内で、追加する必要のあるアプリケーション制限を見つけます。

クライアントサイドの SDK と API

ブラウザと WebView ベースのアプリ

最新のブラウザでは通常、プライバシー上の理由から、クロスオリジンリクエストの Referer ヘッダーを削除します。多くの場合、Origin まで削除されます。ただし、正確な動作は、ホストサイトに適用されている referrer-policy によって異なり、ユーザーのブラウザとバージョンによっても異なる場合があります。

コンテンツの読み込みに不透明な URI スキームまたはローカル URI スキームを使用するウェブアプリケーションでは、通常、レンダリングブラウザまたはウェブビューが送信呼び出しから Referer ヘッダーを完全に削除します。これにより、ウェブサイトの制限付きの API キーを使用したリクエストが失敗する可能性があります。

詳しくは、ブラウザベースのアプリをサーバーでホストするをご覧ください。

ブラウザとウェブビューベースのアプリのトラブルシューティング手順:

Maps JavaScript API の場合、アプリケーションを承認する方法については、ブラウザのデバッグコンソールをご覧ください。

特殊な URI スキームは部分的にサポートされています。必要な参照元を承認した後も、アプリケーションの一部が特殊な URI スキームで機能しない場合は、アプリケーションをリモートでサーバーにホストし、HTTPS（または HTTP）経由で読み込む必要があります。

特殊な URI スキームについてサポートが必要な場合は、サポートにお問い合わせください。
他の Maps Platform API は通常、API エラーレスポンスで認証が必要な参照元を返します。これは、クライアントが拒否されたリクエストとともにこの情報を送信したことを前提としています。

特殊な URI スキームはサポートされていません。

Android アプリ

Android Debug Bridge（adb）または Logcat を使用する

iOS アプリ

ログメッセージを表示するをご覧ください。

ウェブサービスを直接呼び出すアプリ

クライアントサイドの Google Maps Platform SDK を使用せずに、Maps Platform HTTPS REST API または gRPC エンドポイントを直接呼び出すアプリの場合は、以下をご覧ください。

Android アプリと iOS アプリ

Android または iOS のアプリが、利用可能な Google Maps Platform クライアント SDK を使用せずに Maps Platform サービスを直接呼び出す場合は、Android アプリと iOS アプリでトラブルシューティングのヒントを確認し、クライアントサイドのウェブサービス呼び出しを保護するでモバイルユースケースの最新のセキュリティに関するベストプラクティスを確認してください。

アプリが Maps Platform API のエラーレスポンスをログに記録している場合は、認証に関する問題のトラブルシューティングに、上記のクライアントサイド SDK の手順も役立つ場合があります。

サーバーサイドアプリ

API キーを使用するサーバーサイドアプリケーションは、IP アドレスの制限によって保護するのが最適です。キーに IP アドレスの制限を適用していて、サービスが Google Maps Platform API エラーレスポンスをログに記録している場合は、システムログで詳細を確認してください。エラーレスポンスには、承認が必要なサーバー IP アドレスが含まれます。

ブラウザまたは WebView ベースのアプリ

Maps Static API、Street View Static API、および最近の Google Maps Platform API はリファラ制限もサポートしますが、ウェブブラウザまたはウェブビューでは、クロスオリジンリクエストに対して Referer ヘッダーが Origin に制限される可能性があり、ローカルにアクセスされたリソースや、HTTP や HTTPS 以外のプロトコルで提供されるリソースなど、ヘッダーが送信されない可能性もあります。

アプリケーションで Maps JavaScript API を使用できない場合や、ウェブサイトの制限が機能しない場合は、ブラウザベースのクライアントサイドアプリケーション内から Google Maps Platform ウェブサービス呼び出しを安全に行う方法については、クライアントサイドのウェブサービス呼び出しを保護するをご覧ください。

API の制限を確認する

必要な API 制限を確認するには、該当 API キーを使用している API を特定するを参照してください。

適用するべき制限の判断が難しい場合:

現在の制限を後で参照できるようにメモします。
制限を一時的に削除し、問題を調査します。API キーの使用状況をチェックするの手順を使用すると、使用状況の推移を確認できます。
必要であればサポートにお問い合わせください。

使用していない API キーを削除する

API キーを削除する際は、まずそのキーが本番環境で使用されていないことを確認しましょう。正常なトラフィックがない場合は、キーを削除しても問題ないことが見込まれます。詳しくは、API キーの使用状況をチェックするをご覧ください。

API キーを削除するには:

Google Cloud コンソールの Google Maps Platform の [認証情報] ページを開きます。
削除する API キーを選択します。
ページ上部の [削除] ボタンを選択します。
[認証情報の削除] 画面で、[削除] を選択します。

API キーの削除が反映されるまでには数分かかることがあります。削除が反映されると、以降その API キーを使ったトラフィックはすべて拒否されます。

API キーのローテーションは注意深く行う

API キーをローテーションすると、古いキーのすべての制限を含む新しいキーが作成されます。カウントダウン中は新旧どちらのキーも使用できるため、この期間を利用してアプリを新キーに移行させることが可能です。

API キーをローテーションする前に:

まずは、API キーに制限をかけるの説明に沿って、API キーの制限を試みます。
アプリケーション制限のタイプの不一致により API キーに制限をかけることができない場合は、複数の新しい（制限をかけた）キーを使った運用に切り替えます（複数の API キーを使った運用に移行するを参照）。この方法なら、新 API キーへの移行とロールアウトのスケジュールを能動的にコントロールできます。

上記の提案を行うことが不可能で、不正使用を防ぐために API キーをローテーションする必要がある場合は、次の手順を行います。

Google Cloud コンソールの Google Maps Platform の [認証情報] ページを開きます。
ローテーションする API キーを開きます。
ページ上部の [キーを回転] を選択します。
必要に応じて、API キー名を変更します。
[作成] を選択します。
新しいキーを使用するようにアプリケーションを更新します。

新しいキーを使用するようにアプリケーションを更新したら、新しい API キーページの [前のキー] セクションにある [前のキーを削除] ボタンをクリックして古いキーを削除します。

複数の API キーへの移行

1 つの API キーを複数のアプリで使用する運用から、アプリごとに固有のキーを使用する運用へ移行するには、以下を行います。

新しいキーを必要とするアプリを特定する:
- ウェブアプリの場合、コードはすべて直接管理下にあるため、アップデートは最も簡単です。全ウェブアプリのキーをアップデートできるよう計画を立てましょう。
- モバイルアプリの場合は、ユーザーがアプリをアップデートするまで新キーへの切り替えが完了しないため、難度が大きく上が��ます。
新しいキーを作成して制限をかける: アプリケーション制限と API 制限（少なくとも 1 つ）の両方を追加します。詳細については、推奨されるベストプラクティスをご覧ください。
新しいキーをアプリに追加する: モバイルアプリの場合、新 API キーを使った更新版アプリへのアップデートを全ユーザーが完了するまで待つことになるため、このステップには何か月もかかる可能性があります。

クライアントサイドとサーバーサイドの使用量を別のプロジェクトに分割する

サーバーサイドアプリケーションと、エンドユーザーデバイスで実行されているクライアントサイドアプリケーションの両方から Google Maps Platform サービスを呼び出す必要がある場合は、使用量を 2 つのプロジェクトに分割することをおすすめします。

このアプローチでは、クライアントサイドプロジェクトのほとんどの Google Maps Platform サービスに適切な分単位のユーザーごとの割り当て上限を適用できるため、すべてのエンドユーザーが互いに影響を与えることなく、プロジェクト全体の割り当てを公平に利用できま��。

ただし、ユーザーごとの割り当ての制限は、クライアントサイドアプリケーションとサーバーサイドアプリケーションの両方に影響するため、サーバーサイドジョブにも高帯域幅が必要な場合は、このユースケース用に別のプロジェクトを設定し、ユーザーごとの割り当て上限を高くするか、上限を設定しないでください。

未使用のサービスを無効にする

プロジェクトで未使用のサービスを有効にしたままにしないでください。この方法は、特にすべての公開 API キーを制限していない場合、不正使用に対して脆弱です。ベストプラクティスとして、プロジェクトでサービスはアプリケーションで必要になった場合にのみ有効にします。

キーに API 制限を追加すると、承認されていないサービスでの使用を防ぐことができますが、API 制限はその特定のキーにのみ適用されます。プロジェクトにリンクされているすべてのキーでサービスの不正使用を防ぐため、プロジェクトレベルでサービスを無効にします。

クライアントサイド SDK を使用する

提供されている��ライアントサイドの Google Maps Platform SDK を使用する場合は、API キーに適切な制限を適用して、サービスの使用を保護できます。

クライアントサイド SDK を使用すると、サポートされている Maps Platform API サーフェスで Firebase App Check などの高度なセキュリティメカニズムも導入できます。詳しくは、App Check を使用して API キーを保護するをご覧ください。

プラットフォームでクライアントサイドの SDK を使用できない場合は、クライアントサイドのウェブサービス呼び出しを保護するをご覧ください。

さまざまなプラットフォームで利用可能なクライアントサイドの Google Maps Platform SDK については、推奨されるアプリケーション制限と API 制限をご覧ください。

Static Web API の使用を保護する

Static Web API（Maps Static API、Street View Static API など）は、ウェブサービスの API 呼び出しと似ています。

どちらも呼び出しは HTTPS REST API を使って行い、通常はサーバーで API リクエスト URL を生成します。ただし Static Web API は、JSON レスポンスを返すのではなく、生成された HTML コード内に埋め込み可能な画像を生成します。さらに重要なのは、Google Maps Platform のサービスを呼び出すのが主にエンドユーザーのクライアントであり、サーバーではない点です。

デジタル署名を使用する

ベストプラクティスとして、API キーを運用する際はデジタル署名も併用しましょう。また、署名なしのリクエストを 1 日あたり何件まで許可するべきか確認し、それに応じて署名なしリクエストのクォータ（割り当て）を調整します。

デジタル署名について詳しくは、デジタル署名ガイドをご覧ください。

署名シークレットを保護する

Static Web API を保護するため、API の署名シークレットをコードやソースツリーに直接埋め込むことや、クライアントサイドアプリケーションで公開することは避けてください。署名シークレットの安全を確保するため、次のベストプラクティスを守りましょう。

ウェブページの配信時、またはモバイルアプリからのリクエストに応じて、Maps Static API と Street View Static API の署名済みリクエスト URL をサーバーサイドで生成します。

静的なウェブコンテンツの場合、Cloud コンソールで Google Maps Platform の [認証情報] ページに表示される「今すぐ URL に署名」ウィジェットを使用できます。

動的ウェブコンテンツについては、使用可能な URL リクエスト署名のコードサンプルをご覧ください。

ヒント: モバイルデベロッパーは、署名付きリクエストの生成にセキュアなプロキシサーバーを使用できます。
署名シークレットはアプリケーションのソースコードやソースツリーの外に格納すること。署名シークレットやその他の機密情報は、環境変数か別個に保存されるインクルードファイルに入れておけば、コードを共有しても共有ファイルに含まれてしまう心配はありません。署名シークレットやその他の機密情報をファイルに格納する場合は、署名シークレットがソースコード管理システム内に入ってしまわないよう、該当ファイルはアプリケーションのソースツリーの外に置きましょう。GitHub のような公開型のソースコード管理システムを使用する場合は、特に注意する必要があります。

ウェブサービス API キーを保護する

クライアントサイドアプリから Google Maps Platform API とサービスを安全に使用するには、クライアントサイド SDK を使用するとクライアントサイドのウェブサービス呼び出しを保護するをご覧ください。

API キーは、アプリケーションのソースコードやソースツリーの外に格納しましょう。API キーやその他の機密情報は、環境変数か別個に保存されるインクルードファイルに入れておけば、コードを共有しても共有ファイルに含まれてしまう心配はありません。これは特に、GitHub などの公開ソースコード管理システムを使用する場合に重要です。

ウェブサービス API キーが誤って使用されないようにするには、Maps Platform で使用するキーに API 制限を適用することをおすすめします。さらに、ウェブサービスキーにIP アドレスの制限を適用すると、キーが誤って漏洩した場合でも、他の送信元 IP アドレスからの不正使用を防ぐことができます。

サーバーサイドアプリに OAuth を使用する

OAuth 2.0 は、アクセス権の委任に関するオープンスタンダードです。

OAuth 2.0 プロトコルは、エンドユーザーがアプリケーションに自分の代わりに個人データにアクセスすることを許可するユースケースをサポートしていますが、Maps Platform での OAuth 2.0 の想定されるユースケースは、デベロッパーが一時的なアクセストークンを使用して、Google Cloud プロジェクトのサービスアカウントに代わって API を呼び出すことをアプリケーションに許可することです。サービスアカウントの権限が必要です。

��ービスアカウントには非常に広範な権限が付与される可能性があるため、デベロッパーの信頼できるサーバーサイドアプリケーションと Google の Maps Platform サーバー間のサーバー間呼び出しを承認するには、OAuth 2.0 を使用することをおすすめします。

エンドユーザーのデバイスで実行されるクライアントサイドアプリケーションの場合は、API キーなどの他の認証方法をおすすめします。

OAuth 2.0 を使用してサーバー間トラフィックを承認する場合は、API ドキュメントで OAuth のトピックをご覧ください。

たとえば、Address Validation API の OAuth トピックは次のとおりです。

クライアントサイドのウェブサービス呼び出しを保護する

クライアントサイドの SDK が利用できない場合は、以下の推奨事項をご覧ください。

プロキシサーバーを使用する

安全なプロキシサーバーを使用すると、API キー、署名シークレット、Google Cloud サービスアカウントを不正なユーザーに公開することなく、クライアントサイドアプリケーションから Google Maps Platform ウェブサービスエンドポイントを操作するための信頼できるソースが提供されます。

要点:

*   Construct your Google Maps Platform requests on the proxy server.
    **Don't** allow clients to relay arbitrary API calls using the proxy.

*   Post-process the Google Maps Platform responses on your proxy server.
Filter out data that the client doesn't need.

プロキシサーバーの使用方法の詳細については、代理実行: Google Data API クライアントライブラリとプロキシサーバーの併用をご覧ください。

モバイルウェブサービスの直接呼び出しを保護する

クライアントサイドアプリに安全なプロキシサーバーを設定できない場合は、次の手順でアプリケーションを保護します。

HTTP ヘッダーを使用する:
- Android: X-Android-Package と X-Android-Cert の HTTP ヘッダーを使用します。
- iOS: X-Ios-Bundle-Identifier HTTP ヘッダーを使用します。
対応するアプリケーション制限を Android キーまたは iOS キーに追加します。

重要: Android と iOS のアプリケーションの制限は、以前の Google Maps Platform サービスでは完全にサポートされていない場合があります。
モバイルアプリから Google Maps Platform REST API ウェブサービスに直接呼び出しを行うことを検討する前に、Android または iOS のアプリケーション ID が正しくないリクエストが拒否されることを確認してください。

テスト対象のエンドポイントで Android と iOS のアプリケーション制限がサポートされていない場合は、モバイルクライアントと Google Maps Platform ウェブサービスエンドポイントの間に安全なプロキシサーバーを使用することを強くおすすめします。

Android アプリに関するヒント:

Android アプリを Google Maps Platform サービスと統合する前に、アプリケーション ID（パッケージ名）の形式が正しいことを確認してください。詳しくは、Android ドキュメントのアプリモジュールを設定するをご覧ください。
アプリから X-Android-Package を直接渡すには、Context.getPackageName() を使用してプログラムで検索します。
アプリから X-Android-Cert を直接渡すには、アプリ署名証明書に必要な SHA-1 フィンガープリントを計算します。このフィンガープリントは PackageInfo.signingInfo からアクセスできます。

重要: 署名証明書の SHA-1 ダイジェストを渡し、ヘッダーを設定するときに、区切り文字や接頭辞を使用せずに、結果の 20 バイトのダイジェストを Base16（16 進数）エンコードされた文字列に変換します。00112233445566778899AABBCCDDEEFF00112233。
Google Cloud コンソールを使用して Android アプリケーションを承認する場合、UI では SHA-1 フィンガープリントがコロンで区切られた文字列であることを前提としています。00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33ただし、gcloud ツールと API キー API では、区切り文字のない 16 進数文字列が想定されています。

iOS アプリに関するヒント:

iOS アプリを Google Maps Platform サービスと統合する前に、バンドル ID の形式が正しいことを確認してください。
通常、iOS アプリを承認する際は、X-Ios-Bundle-Identifier ヘッダーでメインバンドルのバンドル ID を常に渡す必要があります。

詳細については、API キーを管理すると API キーを使用して API にアクセスするをご覧ください。

ブラウザ��ースのアプリをサーバーでホストする

Apache Cordova などのフレームワークを使用すると、WebView 内で実行されるマルチプラットフォームハイブリッドアプリを簡単に作成できます。ただし、API キーのウェブサイトの制限が正しく機能する保証はありません。ウェブアプリが、管理し、承認したウェブサイトから HTTP または HTTPS を使用して読み込まれる場合を除きます。

バンドルされたリソース、ハイブリッドアプリケーション内からローカルに読み込まれたリソース、ローカルファイルの URL を使用してアクセスされたリソースでは、多くの場合、ウェブビューを動かすブラウザエンジンが Referer ヘッダーの送信を省略するため、参照元ベースの認可が機能しません。これを回避するには、ウェブアプリケーションをクライアントサイドではなくサーバーサイドでホストします。

モバイルアプリの場合は、ウェブベースの SDK を使用する代わりに、利用可能なネイティブの Google Maps Platform Android SDK と iOS SDK の使用を検討してください。

App Check を使用して API キーを保護する

一部の Maps SDK と API では、Firebase App Check と統合できます。App Check は、正当なアプリ以外のソースから送信されたトラフィックをブロックすることで、アプリから Google Maps Platform への呼び出しを保護します。これは、構成証明プロバイダの��クンをチェックすることで行われます。アプリを App Check と統合すると、悪意のあるリクエストから保護されるため、不正な API 呼び出しに対して料金が発生することはありません。

App Check の統合手順:

API キーの不正使用に対応する

API キーの不正な使用を検出した場合は、問題に対応するため以下を行います。

キーに制限をかける: 同じキーを複数のアプリで使用していた場合は、複数の API キーを使った運用に切り替え、アプリごとに固有の API キーを使用するようにしましょう。詳しくは、以下をご覧ください。
Places SDK または Maps JavaScript API を使用している場合は、App Check を使用して API キーを保護することもできます。
キーの交換またはローテーションは、次の条件を満たす場合にのみ行います。
- 制限できない、またはすでに制限されているキーの不正使用を検出し、App Check が適用されない。
- アプリケーションからの正当なトラフィックに影響する可能性がある場合でも、より迅速に API キーを移行して安全を確保し、不正使用を停止する必要があります。
前に、API キーのローテーションは注意深く行うを読んでください。
問題が解決しない場合やサポートをご希望の場合は、サポートにお問い合わせください。

推奨されるアプリケーション制限と API 制限

以下の各セクションでは、Google Maps Platform の各 API、SDK、サービスについて、適切と考えられるアプリケーション制限と API 制限を示しています。

推奨される API 制限

API 制限に関する次のガイドラインは、すべての Google Maps Platform サービスに適用されます。

API キーは使用する API のみを許可するように制限するのが原則ですが、以下は例外です。

アプリで Places SDK for Android または Places SDK for iOS を使用している場合は、使用している SDK のバージョンに応じて、Places API（新規）または Places API を許可します。¹
Maps JavaScript API を使用するアプリの場合は、必ず同 API をキーで許可します。

以下の Maps JavaScript API サービスを使用する場合は、それぞれ対応する API も許可します。

サービス	API の制限
ルートサービス（従来版）	Directions API（以前のバージョン）
距離行列サービス（従来版）	Distance Matrix API（以前のバージョン）
高度サービス	Elevation API
ジオコーディングサービス	Geocoding API
Place クラス、Place Autocomplete ウィジェット（新規）、Place Autocomplete Data API	Places API（新版）²
プレイスライブラリ、プレイスサービス、プレイスオートコンプリートウィジェット	Places API²

¹ 詳しくは、Places SDK for Android と Places SDK for iOS のドキュメントをご覧ください。

² Places API（新版）と Places API のどちらを承認する必要があるか不明な場合は、Maps JavaScript API のドキュメントをご覧ください。

例:

Maps SDK for Android と Places SDK for Android を使用している場合、API 制限で Maps SDK for Android と Places API（新規）を許可します。
ウェブサイトで Maps JavaScript API 高度サービスと Maps Static API を使用している場合、API 制限で次の API をすべて許可します。
- Maps JavaScript API
- Elevation API
- Maps Static API

推奨されるアプリケーション制限

ウェブサイト

Maps JavaScript API サービス、Maps Static API、または Street View Static API を使用するウェブサイト、または HTTPS REST API または gRPC を介して最新の Google Maps Platform サービスを直接呼び出すウェブサイトの場合は、ウェブサイトのアプリケーション制限を使用します。

¹ モバイルアプリの場合は、ネイティブの Maps SDK for Android と Maps SDK for iOS の使用を検討しましょう。

² モバイルアプリの場合は、ネイティブの Places SDK for Android と Places SDK for iOS の使用を検討しましょう。

³ Static Web API の使用を保護するもご覧ください。

Maps Embed API を使ったウェブサイト

Maps Embed API 自体は料金のかからない API ですが、他のサービスでの不正使用を防ぐため、使用する API キーには制限をかけましょう。

ベストプラクティス: Maps Embed API 用の API キーを別個に作成し、API 制限で Maps Embed API だけを許可します。この制限によってキーを十分に保護し、Google の他のサービスで不正使用されることを防止できます。Maps Embed API キーを使用できる場所を完全に制御するには、ウェブサイトのアプリケーションの制限も適用することをおすすめします。

Maps Embed API を単独の専用 API キー��運用するのが難しい場合は、既存のキーに ウェブサイト アプリケーション制限をかけて保護します。

ウェブサービスを使用するアプリとサーバー

ウェブサービスと API キーを併用する、信頼できる企業内部ネットワークのサーバーとクライアントサイドアプリの場合は、IP addresses アプリケーション制限を使用します。

次の API を使ったアプリやサーバーで使用:

⁴ モバイルアプリの場合は、Navigation SDK の使用を検討してください。

⁵ モバイルを安全に使用するには、セキュアなプロキシサーバーを使用します。

⁶ クライアントサイドアプリケーションの場合は、プラットフォームが提供するネイティブの位置情報サービスを使用することを検討してください。たとえば、ウェ��ブラウザの W3C Geolocation、Android の LocationManager または Fused Location Provider API、iOS の Apple Core Location フレームワークなどです。

⁷ モバイルアプリの場合は、ネイティブの Places SDK for Android と Places SDK for iOS を使用することをおすすめします。

⁸ クライアントサイドで安全に使用するには、安全なプロキシサーバーを使用します。

Android アプリ

Android アプリでは、Android apps 型のアプリケーション制限を使用します。次の SDK を使ったアプリで使用:

また、Secrets Gradle プラグインを使用して、Android マニフェストに保存するのではなく、ローカルファイルからシークレットを挿入することで、API キーが誤ってバージョン管理にチェックインされないようにします。

iOS アプリ

iOS アプリでは、iOS apps 型のアプリケーション制限を使用します。次の SDK を使ったアプリやサーバーで使用:

Google Maps Platform のセキュリティに関するガイダンス コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

推奨されるベスト プラクティス

API キー使用時に共通の推奨事項

クライアントサイド アプリの追加の推奨事項

Static Web API 群を使ったウェブサイトまたはクライアントサイド アプリでの追加の推奨事項

ウェブサービスを使用するサーバーサイド アプリでの追加の推奨事項

使用中の API キーを制限またはローテーションする場合

詳細

API キーの制限

API キーのアプリケーション制限の設定

API キーの API 制限を設定する

API キーの使用状況をチェックする

該当 API キーを使用している API を特定する

適用するべきアプリケーション制限のタイプを Metrics Explorer で選ぶ

アプリごとに個別の API キーを使用

自動提案された API キー制限を適用する

自動推奨でサポートされている Google Maps Platform API と SDK

提案が表示されなかったり完全なものではなかったりする原因

最適化案が表示されない理由

不完全な最適化案が表示される理由

提案がグラフに表示されていない原因

自動提案された制限を適用する方法

提案内容を適用後にアプリケーションが不承認となった場合の対応

クライアントサイドの SDK と API

ウェブサービスを直接呼び出すアプリ

API の制限を確認する

使用していない API キーを削除する

API キーのローテーションは注意深く行う

複数の API キーへの移行

クライアントサイドとサーバーサイドの使用量を別のプロジェクトに分割する

未使用のサービスを無効にする

クライアントサイド SDK を使用する

Static Web API の使用を保護する

デジタル署名を使用する

署名シークレットを保護する

ウェブサービス API キーを保護する

サーバーサイド アプリに OAuth を使用する

クライアントサイドのウェブサービス呼び出しを保護する

プロキシ サーバーを使用する

モバイルウェブ サービスの直接呼び出しを保護する

ブラウザ��ースのアプリをサーバーでホストする

App Check を使用して API キーを保護する

API キーの不正使用に対応する

推奨されるアプリケーション制限と API 制限

推奨される API 制限

推奨されるアプリケーション制限

ウェブサイト

Maps Embed API を使ったウェブサイト

ウェブサービスを使用するアプリとサーバー

Android アプリ

iOS アプリ

関連情報

Google Maps Platform のセキュリティに関するガイダンス
コレクションでコンテンツを整理必要に応じて、コンテンツの保存と分類を行います。

推奨されるベストプラクティス

クライアントサイドアプリの追加の推奨事項

Static Web API 群を使ったウェブサイトまたはクライアントサイドアプリでの追加の推奨事項

ウェブサービスを使用するサーバーサイドアプリでの追加の推奨事項

サーバーサイドアプリに OAuth を使用する

プロキシサーバーを使用する

モバイルウェブサービスの直接呼び出しを保護する