Google Maps Platform の API や SDK を使用するアプリおよびプロジェクトでは、不正な利用や料金発生を防ぐため、API キーまたは（サポートされている場合）OAuth を使用する必要があります。API キーを使用する場合、最大限に保護できるよう、作成と同時に API キーに制限をかけましょう。このベスト プラクティスでは、制限をかける方法を解説します。
キーにアプリケーションと API の制限をかけるだけでなく、Google Maps Platform の各プロダクトに固有のセキュリティ対策があれば実施しましょう。たとえば Maps JavaScript API を利用する場合、後続の推奨されるアプリケーション制限と API 制限セクションを参照してください。
すでに使用中の API キーを扱う際は、この後の使用中の API キーを制限または再生成する場合以下の推奨事項をご確認ください。
デジタル署名について詳しくは、デジタル署名ガイドをご覧ください。
推奨されるベスト プラクティス
以下、Google Maps Platform の各 API、SDK、およびサービスにおける、API のセキュリティに関するベスト プラクティスを紹介します。セキュリティの強化と不正使用による料金発生の防止にご活用ください。
API キー使用時に共通の推奨事項
Static Web API 群を使ったウェブサイトでの追加の推奨事項
ウェブサービスを使ったアプリでの追加の推奨事項
iOS / Android 向けモバイル アプリケーションでの追加の推奨事項
ウェブサービスまたは Static Web API 群を使ったモバイルアプリを保護する
使用中の API キーを制限または再生成する場合
API キーを変更する前に、API キーの使用状況をチェックしましょう。すでに使用中のキーに制限を追加する場合はこのステップが特に重要です。
キーを変更した後は、必要に応じてすべてのアプリをアップデートし、新しい API キーに移行させます。
API キーの不正使用が実際に発生している状況でなければ、ご自分のペースでアプリごとに新しい API キーに移行させていくことも可能です。この場合、元の API キーはトラフィックが 1 種類だけになるまでそのままにしておき、その後はアプリケーション制限によって各 API キーのトラフィックをその 1 種類に制限します。詳しい手順については、複数の API キーを使った運用に移行するをご覧ください。
使用状況の推移をモニタリングしましょう。旧 API キーの制限や削除を行うのは、個々の API、プラットフォーム タイプ、ドメインが旧 API キーを使用しなくなったことを確認できてからにします。詳しくは、レポートとモニタリングについての記事と指標データについての記事をご覧ください。
すでに API キーの不正使用が発生している場合は、より迅速に API キーを移行して安全を確保し、悪用を阻止する必要があります。Android / iOS アプリの場合、ユーザーがアプリをアップデートするまでキーの交換は反映されません。JavaScript またはウェブサービスによるアプリの場合、キーの更新と交換はずっとシンプルですが、それでも注意深い計画とすばやい作業が必要となることがあります。
詳しくは、API キーの不正使用に対応するをご覧ください。
API キーに制限をかける
API キーにはいつでも、アプリケーション制限と API 制限（1 つ以上）をかけることをおすすめします。各 API、SDK、JavaScript サービスで推奨される制限の種類は、後続の推奨されるアプリケーション制限と API 制限でご確認いただけます。
アプリケーション制限: 該当 API キーの使用を、特定のプラットフォーム（Android または iOS アプリケーション、クライアントサイド アプリケーションの場合は特定のウェブサイト、ウェブサービス REST API 呼び出しを行うサーバーサイド アプリの場合は特定の IP アドレスまたは CIDR サブネット）に限定できます。
API キーのアプリケーション制限は、許可するプラットフォームを指定する形で適用します（複数可）。適用後は、指定したソースからのリクエスト以外は許可されなくなります。
API 制限: 該当 API キーを使用できる Google Maps Platform の API、SDK、サービスを限定します。API 制限をかけると、指定した API や SDK からのリクエスト以外は許可されなくなります。同じ API キーに適用する API 制限の数に上限はありません。指定可能な API のリストには、該当プロジェクトで有効化されている API がすべて含まれます。
API キーのアプリケーション制限を設定する
Google Cloud コンソールの Google Maps Platform の [認証情報] ページを開きます。
制限をかける API キーを選択します。
[API キーを編集] ページで、[キーの制限] の下の [アプリケーションの制限の設定] を選択します。
![[API キーを編集] ページ](https://developers.google.cn/static/maps/images/editAPIkey.png?authuser=8&hl=ja)
いずれかの制限タイプを選択し、制限リストに沿って必要な情報を指定します。
制限タイプ 説明 ウェブサイト リファラー（リクエスト元）ウェブサイトを 1 つまたは複数指定します。 - 共通でサポートされる URI スキームは
httpsとhttpです。 - リファラーは必ず、プロトコル スキーム、ホスト名、必要ならポート名を含めた完全な URI で指定してください（例:
https://google.com）。 - ワイルドカード文字を使って、サブドメインを一括で許可することも可能です。たとえば、
https://*.google.comと指定すると、末尾が.google.comのすべてのサイトからのリクエストを受け入れます。www.domain.com を指定した場合、ワイルドカード付きの www.domain.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 を追加します。 おすすめのアプリケーション制限は、推奨されるアプリケーション制限でご確認いただけます。
- 共通でサポートされる URI スキームは
[保存] を選択します。
API キーの API 制限を設定する
Google Cloud コンソールの Google Maps Platform の [認証情報] ページを開きます。
制限をかける API キーを選択します。
[API キーを編集] ページの [API の制限] 欄で、以下を行います。
[キーを制限] を選択します。
[Select APIs] プルダウンを開き、アプリケーションが該当 API キーを使ってアクセスできるようにする API や SDK をすべて選択します。
目的の API または SDK がリストにない場合、まず有効化する必要があります。詳しくは、1 つ以上の API または SDK を有効にするにはをご覧ください。
![[API キーを編集] ページで API に制限をかけている様子](https://developers.google.cn/static/maps/images/editAPIkey-restrict.png?authuser=8&hl=ja)
[保存] を選択します。
このステップを終えると、指定した制限内容は 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 キー制限を検証することが可能です。自動提案される制限について詳しくは、自動提案された 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 キーを調べます。方法は次のとおりです。
[フィルタを追加] を選択します。
ラベル欄で「
credential_id」を選択します。値の欄で、調べたいキーに対応する値を選択します。
該当 API キーが使用されている API をメモし、想定外の使用でないことを確認します。
終わったら、追加したフィルタ行の末尾にある （フィルタを削除）を選択して削除し、元の状態に戻します。
他にもキーがある場合は、同様の手順を繰り返します。
キーに 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 キーを調べます。方法は次のとおりです。
[フィルタを追加] を選択します。
ラベル欄で「
credential_id」を選択します。値の欄で、調べたいキーに対応する値を選択します。
終わったら、追加したフィルタ行の末尾にある （フィルタを削除）を選択して削除し、元の状態に戻します。
他にもキーがある場合は、同様の手順を繰り返します。
該当 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 キーについて、Google Maps Platform の使用状況とアクティビティに応じて Google Cloud コンソールが推奨する具体的な API キー制限が提案されます。
自動提案がある場合、Google Maps Platform の [認証情報] ページに事前入力済みのオプションとして表示されます。
提案が表示されなかったり完全なものではなかったりする原因
Google Maps Platform サービス以外で（も）API キーを使用している。他のサービスで使用している場合は、次の手順を必ず行ってから、提案を適用してください。
Google Cloud コンソールの Metrics Explorer に表示される API の使用法が適切であることを確認します。
許可が必要な API のリストに不足しているサービスを手動で追加します。
API リストに追加したサービスに対して不足しているアプリケーション制限を手動で追加します。追加したサービスに異なるタイプのアプリケーション制限が必要な場合は、複数の API キーへの移行を参照してください。
該当 API キーがクライアントサイドの SDK または API で使用されていない。
該当 API キーを使用しているアプリまたはウェブサイトが低ボリュームで、過去 60 日間に利用が発生していない。
ごく最近作成した新しいキーである、または新しいアプリにごく最近デプロイしたキーである。この場合、何日か待てば提案内容も更新されます。
該当 API キーを使用しているアプリケーションが複数あり、必要となるアプリケーション制限のタイプが一致していない、または同じ API キーを使用しているアプリやウェブサイトの数が多すぎる。どちらの場合も、複数のキーを使った運用に切り替えるのがベスト プラクティスです。詳しくは、複数の 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 については以下のとおりです。
- Maps JavaScript API を使ったアプリ: ブラウザのデバッグ コンソールを確認する
- Android アプリ: Android Debug Bridge（adb）または Logcat を使用する
- iOS アプリ: Viewing Log Messages を参照する
必要な API 制限を確認するには、該当 API キーを使用している API を特定するを参照してください。
適用するべき制限の判断が難しい場合:
- 現在の制限を後で参照できるようにメモします。
- 制限を一時的に削除し、問題を調査します。API キーの使用状況をチェックするの手順を使用すると、使用状況の推移を確認できます。
- 必要であればサポートにお問い合わせください。
使用していない API キーを削除する
API キーを削除する際は、まずそのキーが本番環境で使用されていないことを確認しましょう。正常なトラフィックがない場合は、キーを削除しても問題ないことが見込まれます。詳しくは、API キーの使用状況をチェックするをご覧ください。
API キーを削除するには:
Google Cloud コンソールの Google Maps Platform の [認証情報] ページを開きます。
削除する API キーを選択します。
ページ上部の [削除] ボタンを選択します。
[認証情報の削除] 画面で、[削除] を選択します。
API キーの削除が反映されるまでには数分かかることがあります。削除が反映されると、以降その API キーを使ったトラフィックはすべて拒否されます。
API キーの再生成は注意深く行う
API キーを再生成すると、元のキーに適用されていた制限をすべて引き継いだ新しいキーが作成されます。同時に 24 時間のカウントダウンが開始し、この期間を過ぎると元の API キーは削除されます。
カウントダウン中は新旧どちらのキーも使用できるため、この期間を利用してアプリを新キーに移行させることが可能です。カウントダウンが終わると、元の API キーを使用しているアプリは動作しなくなります。
API キーを再生成する前に:
まずは、API キーに制限をかけるの説明に沿って、API キーの制限を試みます。
アプリケーション制限のタイプの不一致により API キーに制限をかけることができない場合は、複数の新しい（制限をかけた）キーを使った運用に切り替えます（複数の API キーを使った運用に移行するを参照）。この方法なら、新 API キーへの移行とロールアウトのスケジュールを能動的にコントロールできます。
上記の提案を行うことが不可能で、不正使用を防ぐために API キーを再生成する必要がある場合は、次の手順を行います。
Google Cloud コンソールの Google Maps Platform の [認証情報] ページを開きます。
再生成したい API キーを開きます。
ページ上部の [キーを再生成] を選択します。
[キーを交換] を選択します。
注: 再生成したキーは、必要であれば元のバージョンにロールバックすることができます。ロールバックに時間制限はありません。
再生成したキーをロールバックする手順
Google Cloud コンソールの Google Maps Platform の [認証情報] ページを開きます。
ロールバックしたい API キーを開きます。
[以前のキーに戻す] を選択します。
表示されたダイアログで、[キーを元に戻す] を選択します。
ロールバックを行うと、それまで「新しい」バージョンだったキーが「前のキー」となり、24 時間のカウントダウンが終わると無効化されます。再びキーの再生成を行うまでは、この 2 つのキー値を相互に切り替えることが可能です。
キーの再生成を行うと、無効化されているその時点の「旧キー」は上書きされます。
複数の API キーを使った運用に移行する
1 つの API キーを複数のアプリで使用する運用から、アプリごとに固有のキーを使用する運用へ移行するには、以下を行います。
新しいキーを必要とするアプリを特定する:
- ウェブアプリの場合、コードはすべて直接管理下にあるため、アップデートは最も簡単です。全ウェブアプリのキーをアップデートできるよう計画を立てましょう。
- モバイルアプリの場合は、ユーザーがアプリをアップデートするまで新キーへの切り替えが完了しないため、難度が大きく上がります。
新しいキーを作成して制限をかける: アプリケーション制限と API 制限（少なくとも 1 つ）の両方を追加します。詳しくは、推奨されるベスト プラクティスをご覧ください。
新しいキーをアプリに追加する: モバイルアプリの場合、新 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 の署名シークレットをコードやソースツリーに直接埋め込むことや、クライアントサイド アプリケーションで公開することは避けてください。署名シークレットの安全を確保するため、次のベスト プラクティスを守りましょう。
リクエストの署名はクライアントではなくサーバーサイドで行うこと。クライアントサイドで JavaScript を使って署名を行ってしまうと、その処理はすべてのサイト訪問者に公開されます。このため、動的生成画像を扱う際、Maps Static API や Street View Static API の署名済みリクエスト URL の生成は、ウェブページ配信時にサーバー側で行う必要があります。静的なウェブ コンテンツの場合、Cloud コンソールで Google Maps Platform の [認証情報] ページに表示される「今すぐ URL に署名」ウィジェットを使用できます。
署名シークレットはアプリケーションのソースコードやソースツリーの外に格納すること。署名シークレットやその他の機密情報は、環境変数か別個に保存されるインクルード ファイルに入れておけば、コードを共有しても共有ファイルに含まれてしまう心配はありません。署名シークレットやその他の機密情報をファイルに格納する場合は、署名シークレットがソースコード管理システム内に入ってしまわないよう、該当ファイルはアプリケーションのソースツリーの外に置きましょう。GitHub のような公開型のソースコード管理システムを使用する場合は、特に注意する必要があります。
ウェブサービスを使ったアプリで API キーを保護する
API キーは、アプリケーションのソースコードやソースツリーの外に格納しましょう。API キーやその他の機密情報は、環境変数か別個に保存されるインクルード ファイルに入れておけば、コードを共有しても共有ファイルに含まれてしまう心配はありません。これは特に、GitHub のような公開ソースコード管理システムを使用する場合に重要です。
ウェブサービスまたは Static Web API 群を使ったモバイルアプリで API キーと署名シークレットを保護する
モバイルアプリを保護するため、セキュアなキーストアかセキュアなプロキシ サーバーを使用しましょう。
API キーや署名シークレットをセキュアなキーストアに格納する: これにより、API キーやその他の機密データをアプリケーションから直接スクレイピングするのが難しくなります。
セキュアなプロキシ サーバーを使用する: プロキシ サーバーは、適切な Google Maps Platform API と通信するための信頼できるソースとして機能します。プロキシ サーバーの使用方法の詳細については、代理実行: Google Data API クライアント ライブラリとプロキシ サーバーの併用をご覧ください。
Google Maps Platform のリクエストをプロキシ サーバー上で構築します。 クライアントがこのプロキシ経由で任意の API 呼び出しをリレーすることは、許可しないでください。
Google Maps Platform のリクエストの後処理をプロキシ サーバー上で行います。クライアントが必要としないデータは除外しましょう。
App Check を使用して API キーを保護する
一部の Maps SDK と API では、Firebase App Check と統合できます。App Check は、正当なアプリ以外のソースから送信されたトラフィックをブロックすることで、アプリから Google Maps Platform への呼び出しを保護します。これは、構成証明プロバイダのトークンをチェックすることで行われます。アプリを App Check と統合すると、悪意のあるリクエストから保護されるため、不正な API 呼び出しに対して料金が発生することはありません。
App Check の統合手順:
API キーの不正使用に対応する
API キーの不正な使用を検出した場合は、問題に対応するため以下を行います。
キーに制限をかける: 同じキーを複数のアプリで使用していた場合は、複数の API キーを使った運用に切り替え、アプリごとに固有の API キーを使用するようにしましょう。詳しくは、以下をご覧ください。
キーに制限をかけることができない場合にのみ、キーを再生成してください。再生成する前に、API キーの再生成は注意深く行うセクションを最後までお読みください。
問題が解決しない場合やサポートをご希望の場合は、サポート窓口にお問い合わせください。
推奨されるアプリケーション制限と API 制限
以下の各セクションでは、Google Maps Platform の各 API、SDK、サービスについて、適切と考えられるアプリケーション制限と API 制限を示しています。
推奨される API 制限
API 制限に関する次のガイドラインは、Google Maps Platform 全体に当てはまります。
API キーは使用する API のみを許可するように制限するのが原則ですが、以下は例外です。
Places SDK for Android または Places SDK for iOS を使用するアプリの場合は、Places API を許可します。
Maps JavaScript API を使用するアプリの場合は、必ず同 API をキーで許可します。
以下の Maps JavaScript API サービスを使用する場合は、それぞれ対応する API も許可します。
サービス API 制限 ルートサービス（Maps JavaScript API） Directions API 距離行列サービス（Maps JavaScript API） Distance Matrix API 高度サービス（Maps JavaScript API） Elevation API ジオコーディング サービス（Maps JavaScript API） Geocoding API プレイス ライブラリ（Maps JavaScript API） Places 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 または Static Web API を使ったウェブサイト
Maps JavaScript の各サービスや Static Web API 群を使ったウェブサイトの場合、Websites 型のアプリケーション制限を使用します。
次の JavaScript サービスおよび API を使ったウェブサイトで使用:
1 モバイルアプリの場合は、ネイティブの Maps SDK for Android と Maps SDK for iOS の使用を検討しましょう。
2 ウェブサービスまたは Static Web API 群を使ったモバイルアプリを保護するもご覧ください。
Maps Embed API を使ったウェブサイト
Maps Embed API 自体は料金のかからない API ですが、他のサービスでの不正使用を防ぐため、使用する API キーには制限をかけましょう。
ベスト プラクティス: Maps Embed API 用の API キーを別個に作成し、API 制限で Maps Embed API だけを許可します。この制限によってキーを十分に保護し、Google の他のサービスで不正使用されることを防止できます。
Maps Embed API を単独の専用 API キーで運用するのが難しい場合は、キーに Websites 型のアプリケーション制限をかけて保護します。
ウェブサービスを使用するアプリとサーバー
ウェブサービスを使ったアプリやサーバーでは、IP addresses 型のアプリケーション制限を使用します。
次の API を使ったアプリやサーバーで使用:
3 モバイルアプリの場合は、ネイティブの Places SDK for Android と Places SDK for iOS の使用を検討しましょう。
Android アプリ
Android アプリでは、Android apps 型のアプリケーション制限を使用します。次の SDK を使ったアプリやサーバーで使用:
また、Secrets Gradle プラグインを使用して、Android マニフェストに保存するのではなく、ローカル ファイルからシークレットを挿入することで、API キーが誤ってバージョン管理にチェックインされないようにします。
iOS アプリ
iOS アプリでは、iOS apps 型のアプリケーション制限を使用します。次の SDK を使ったアプリやサーバーで使用: