googleapis.comとは何か、アプリが接続する理由
googleapis.comは、Googleが多数のアプリケーションプログラミングインターフェース（一般にAPIと呼ばれます）に使用しているドメイン名前空間です。単一のAPIではなく、一般消費者向けの通常のホームページでもありません。アドレスで有用な部分は、多くの場合、serviceusage.googleapis.comのような.googleapis.comより前にある完全なホスト名です。これは、アプリケーションが接続しようとしているサービスを識別するためです。
ブラウザの開発者ツール、ファイアウォールのログ、アプリケーションの設定、またはエラーメッセージでこのドメインを見つけた場合、名前だけで分かるのは答えの一部にすぎません。完全なホスト名、リクエストを行ったアプリケーション、該当するGoogleサービスのドキュメントも必要です。
googleapis.comの用途
Googleは、ソフトウェアが文書化されたインターフェースを通じてデータを要求したり、操作を実行したりできるようにAPIを提供しています。ウェブサイト、モバイルアプリ、サーバープログラム、コマンドラインツール、Google独自の製品はいずれも、これらのインターフェースを呼び出すことができます。
これらのインターフェースの多くは、googleapis.comで終わるサービス固有のホスト名を使用します。このパターンにより、関連するエンドポイントを認識しやすくしながら、個々のサービスを分離できます。
たとえば、Googleのドキュメントでは、Service Usage APIにserviceusage.googleapis.comが使用されています。このサービスは、Google Cloudプロジェクトが利用可能なサービスを確認し、管理するのに役立ちます。同じ親ドメインの別のホスト名では、まったく異なるAPIが提供される場合があります。
googleapis.comは、1軒の店ではなく通りの名前だと考えてください。完全なホスト名は建物の番号に近いものです。さらに、リクエストのパスとメソッドによって、アプリケーションが訪れている具体的な窓口を識別しやすくなります。
この区別により、1件のgoogleapis.comへのリクエストを見て、それがすべてのGoogle APIを表していると考える一般的な誤りを防げます。実際にはそうではありません。各サービスでは、それぞれ次の項目を定義できます。
- リソースと操作
- 認証要件
- 権限とOAuthスコープ
- リクエストとレスポンスの形式
- 使用制限と請求ルール
- 規約、プライバシー通知、データの取り扱い
アプリがgoogleapis.comに接続する理由
アプリケーションは、Google APIまたは関連する開発者サービスを必要とするときに、*.googleapis.comのホスト名へ接続します。リクエストは、地図データの読み込みなど目に見える機能を支える場合もあれば、クラウドサービスが有効になっているかの確認など、バックグラウンド処理を支える場合もあります。
親ドメインだけでは、どの機能が関係しているかは分かりません。接続を理解するには、次の4つの情報から確認します。
.googleapis.comより前のすべてを含む完全なホスト名- リクエストパスとHTTPメソッド
- リクエストを開始したページ、アプリ、拡張機能、またはプロセス
- 名前が示すサービスの公式ドキュメント
このコンテキストは、Google製品によって生成されたトラフィックと、独立した開発者によって生成されたトラフィックを区別するのにも役立ちます。サードパーティーのアプリケーションもGoogle APIの使用を選択できるため、接続先のホスト名だけでは、周辺機能をGoogleが設計したことや、そのアプリのプライバシー慣行をGoogleが管理していることの証明にはなりません。
googleapis.comは単一のAPIですか？
いいえ。このドメインは多数のAPIと開発者サービスを支えています。これを1つの製品として扱うと、その配下にあるエンドポイント間の重要な違いが見えなくなります。
Googleは、リソースとメソッドという観点からAPIを説明しています。リソースはサービスが管理する対象を表し、メソッドは実行可能な操作を表します。具体的なモデルは個々のAPIによって異なります。
GoogleはGoogle API Discovery Serviceも公開しています。これは、対応するAPIの機械可読な記述を提供します。Discoveryドキュメントにはメソッド、パラメーター、スキーマ、OAuthスコープを記述できるため、ツールがAPIを理解できます。
Discovery Serviceは、それが記述するすべてのAPIそのものではありません。提供するのはメタデータです。文書化された操作を実行するのは、サービス固有のエンドポイントです。これらの役割を分けて考えると、エラーメッセージやネットワークアクティビティを解釈しやすくなります。
認証の仕組み
すべてのリクエストが同じ認証方法を使用するわけではありません。一部の操作は公開されている場合があります。それ以外では、プロジェクト、認証済みID、特定の権限、またはユーザーによる承認が必要です。
Google APIのドキュメントには、次の3つの用語がよく登場します。
| 方法 | 通常の役割 | 証明できないこと |
|---|---|---|
| APIキー | 呼び出し元のプロジェクトまたはアプリケーションを識別する | ユーザーが非公開のアカウントデータへのアクセスを許可したことを示すものではない |
| OAuth 2.0 | 指定されたスコープ内で、アプリが委任されたアクセスを要求できるようにする | 1つのスコープの承認によって、すべての権限が付与されるわけではない |
| サービスアカウント | 人ではなくワークロードまたはアプリケーションを表す | そのアカウントにも操作に必要な権限が必要である |
APIキーは通常、呼び出し元を識別し、プロジェクト単位の制御や割り当て制限を適用するために使用されます。認証情報であるため、Googleのガイダンスに従って制限し、保護する必要があります。
OAuth 2.0は、アプリケーションがユーザーに関連付けられた承認済みアクセスを必要とする場合に使用されます。アプリは1つ以上のスコープを要求します。これらのスコープは要求されているアクセスの内容を表し、ユーザーまたは組織は承認するかどうかを決定できます。
サービスアカウントはソフトウェアを表します。各リクエストを承認する人が存在しないサーバー間通信やクラウドのワークロードで一般的に使用されます。サービスアカウントが実行できるのは、割り当てられたロールと権限で許可された操作だけです。
信頼すべき情報源はエンドポイントのドキュメントです。googleapis.comという接尾辞だけから認証情報の種類を推測しないでください。
リクエストを識別する方法
ブラウザまたはネットワークログにgoogleapis.comアドレスへの接続が表示されたとします。ブランド名から推測するのではなく、再現可能な手順を使用してください。
1. 完全なURLをコピーする
ホスト名、パス、クエリ文字列を保持します。記録をほかの人と共有する前に、トークン、APIキー、認証ヘッダー、個人データを伏せてください。
ホスト名は多くの場合、サービスの名前を示します。パスはリソースまたはメソッドを指すことがあります。GETやPOSTなどのHTTPメソッドも手掛かりになります。
2. 開始元を特定する
ブラウザの開発者ツールでは、どのスクリプトまたはページがリクエストを開始したかを確認できます。サーバーログでは、リクエストをプロセスまたはコンポーネントに関連付けられます。管理対象ネットワークでは、デバイスとアプリケーションのコンテキストによって発信元を絞り込めます。
同じAPIが、互いに無関係な複数のアプリケーションから呼び出されることがあるため、この手順は重要です。
3. ホスト名を公式ドキュメントと照合する
正確なサービスホスト名をGoogleの開発者向けドキュメントまたはクラウドドキュメントで検索します。フォーラムへの投稿や似た名前に頼るのではなく、文書化されたエンドポイントが実際に確認されたホストと一致することを確かめます。
ドキュメントには、利用可能な操作、必要な認証情報、権限、割り当て制限、エラーレスポンスが説明されているはずです。
4. 認可を確認する
リクエストがOAuthを使用している場合は、要求されたスコープを確認します。サービスアカウントを使用している場合は、そのアカウントのロールを確認します。APIキーを使用している場合は、そのキーで使用できるAPI、オリジン、またはアドレスを確認します。
認証情報は、アプリケーションに必要な範囲に制限する必要があります。機能している認証情報が、適切に制限されているとは限りません。
5. 送信されるデータを確認する
リクエストのフィールドとサービスのドキュメントを確認します。ホスト名からトラフィックの送信先は分かりますが、そのトラフィックの完全な内容や目的までは分かりません。
確認すべきプライバシー上の質問
Googleは一般的なAPI規約とプライバシー情報を公開していますが、実際のプライバシーへの影響は、サービス、操作、リクエストを行うアプリケーションによって異なります。
具体的な質問をしてください。
- どのサービス固有のホスト名がリクエストを受信するのか？
- リクエストに識別子、アカウント情報、位置情報、ファイル、その他の機密データが含まれているか？
- 呼び出し元はGoogle製品か、サードパーティーのアプリケーションか？
- どのOAuthスコープまたはクラウド権限が関係しているか？
- アプリケーション独自のプライバシー通知には何と記載されているか？
- サービスは追加の規約または保持に関する情報を公開しているか？
- より少ないデータまたはより限定的な権限でも連携機能が動作するか？
見慣れた接続先であることは、アプリケーションを確認する代わりにはなりません。独立したアプリには、APIを使用する理由とデータの取り扱い方法を説明する責任があります。
googleapis.comは安全ですか？
このドメインはGoogleのAPIインフラストラクチャに関連付けられていますが、1つのホスト名の接尾辞だけから「安全」と結論付けるのは広すぎる判断です。セキュリティは、正確なエンドポイント、呼び出し元、その認証情報、実行される操作によって異なります。
正規のAPIであっても、設計の不十分なアプリケーションから使用されることがあります。権限が広すぎる場合、有効なリクエストでも必要以上のデータが公開される可能性があります。紛らわしい類似ホスト名が使われる可能性もあるため、完全な登録ドメインとTLS接続を慎重に確認する必要があります。
完全なコンテキストを使用してください。
- ホスト名が実際に
.googleapis.comで終わり、その後ろに余分な文字列がないことを確認する。 - リクエストを行っているアプリケーションを特定する。
- 公式のGoogleドキュメントでエンドポイントを確認する。
- 要求されたスコープと権限を確認する。
- 認証情報とネットワークポリシーを実用上可能な最小範囲に制限する。
- 予期しない通信量、接続先、またはデータフィールドを調査する。
ドメイン全体を許可またはブロックすべきですか？
普遍的な答えはありません。多数のサービスが親ドメインを共有しているため、一律にブロックすると無関係なアプリケーションが動作しなくなる可能性があります。一律に許可すると、アプリケーションに必要なのが文書化された1つのホスト名だけである場合に、必要以上に広い許可となる可能性があります。
企業ネットワークでは、より限定的なルールの方が通常は理解しやすく、監査もしやすくなります。サービスのホスト名と、それを必要とする業務機能を特定してください。そのうえで、組織のセキュリティポリシーを適用し、結果をテストします。
個人用デバイスでは、まず、どのアプリまたはブラウザ拡張機能が接続を開始したかを特定します。予期しない呼び出し元を無効化または削除する方が、大規模な共有ドメインをブロックして何が動作しなくなるかを待つよりも有益な情報を得られる場合があります。
APIエラーをトラブルシューティングするときは、接続性以外も確認してください。一般的な原因には次のものがあります。
- プロジェクトでAPIが有効になっていない
- 認証情報がない、無効である、または誤って制限されている
- IDに必要なロールまたはOAuthスコープがない
- 割り当て制限または請求ルールが適用されている
- リクエストが誤ったサービス、パス、メソッド、またはリージョンを使用している
- ローカルのファイアウォール、プロキシ、またはDNSルールがホスト名をブロックしている
通常、サービスのドキュメントと返されたエラー本文を確認する方が、親ドメインだけをブラウザで開くよりも適切に診断できます。
googleapis.comを理解する必要があるのは誰ですか？
開発者は、Google API連携の設定とデバッグを行う際に理解する必要があります。管理者は、アプリケーションの依存関係を把握する際に必要です。セキュリティおよびプライバシーチームは、外部への接続、認証情報、データフローを確認する際に必要です。一般ユーザーも、エラーメッセージやプライバシーツールで目にすることがあります。
4つの対象者すべてに役立つルールは同じです。完全なホスト名を保持し、特定のサービスをコンテキストに基づいて判断してください。
要するに、googleapis.comは、多数のGoogle APIエンドポイントで共有される名前空間です。ソフトウェアがサービス固有のホスト名を通じて文書化されたGoogleサービスへアクセスできるため便利です。一方で、親ドメイン名だけでは、リクエストの目的、権限、呼び出し元、データを明らかにできないため、説明としては限定的です。それらを確認するには、正確なホスト名から公式のサービスドキュメントを参照してください。
応答の成功は安全性を保証しません。測定値は特定時点の観測結果です。