制限付きスコープの検証

特定の Google API（ 機密または 制限付き のスコープを許可する API）には、ユーザーデータへのアクセス権をリクエストするアプリに対する要件があります。これらの制限付きスコープの追加要件では、アプリが許可されたアプリケーション タイプであることを証明し、追加の審査（セキュリティ評価を含む）に提出する必要があります。

API 内の制限付きスコープの適用性は、アプリで関連する機能を提供するために必要なアクセスの程度（読み取り専用、書き込み専用、読み取りと書き込みなど）によって大きく異なります。

OAuth 2.0 を使用してこのデータにアクセスする権限を Google アカウントから取得する場合は、スコープと呼ばれる文字列を使用して、アクセスするデータの種類と必要なアクセス権を指定します。アプリが機密性の高いスコープまたは 制限付きスコープをリクエストする場合は、アプリの使用が 例外に該当しない限り、確認プロセスを完了する必要があります。

制限付きスコープは、機密性の高いスコープに比べて数が少なく、 OAuth API 確認に関するよくある質問に、機密性の高いスコープと制限付きスコープの最新のリストが記載されています。これらのスコープは Google ユーザーデータへの幅広いアクセス権を付与します。Google アカウントからスコープをリクエストする前に、スコープの確認プロセスを完了する必要があります。この要件について詳しくは、Google API サービスのユーザーデータに関するポリシーと特定の API スコープに関する追加要件、または プロダクト固有の Google デベロッパー ページをご覧ください。制限付きスコープのデータをサーバーで保存または送信する場合は、セキュリティ評価を完了する必要があります。

制限付きスコープについて

アプリが制限付きスコープをリクエストしていて、例外の対象とならない場合は、Google API サービスのユーザーデータに関するポリシーの特定の API スコープの追加要件、またはプロダクトの Google デベロッパー ページに記載されているプロダクト固有の要件を満たす必要があります。この場合、より詳細な審査プロセスが必要になります。

スコープの使用状況を把握する

  • アプリで使用しているスコープまたは使用するスコープを確認します。既存のスコープの使用状況を確認するには、アプリのソースコードで、認可リクエストとともに送信されるスコープを確認します。
  • リクエストされた各スコープがアプリ機能の目的のアクションに必要であり、その機能を提供するために必要な最小限の権限を使用していることを確認します。Google API の場合、通常、プロダクトの Google Developer ページに、エンドポイントのリファレンス ドキュメントが用意されています。このドキュメントには、エンドポイントの呼び出しに必要なスコープや、エンドポイント内の特定のプロパティが記載されています。アプリが呼び出す API エンドポイントに必要なアクセス スコープの詳細については、それらのエンドポイントのリファレンス ドキュメントをご覧ください。 For example, for an app that only uses Gmail APIs to occasionally send emails on a user's behalf, don't request the scope that provides full access to the user's email data.
  • Google API から受け取ったデータは、API のポリシーに準拠し、アプリのアクションとプライバシー ポリシーでユーザーに提示した方法でのみ使用する必要があります。
  • 各スコープの詳細（ sensitive or restricted ステータスなど）については、API ドキュメントをご覧ください。
  • アプリで使用されるすべてのスコープを、 の で宣言します。 指定したスコープは、機密性の高いスコープまたは制限付きスコープのカテゴリにグループ化され、必要な追加の確認がハイライト表示されます。
  • 統合で使用されるデータに一致する最適なスコープを見つけ、その用途を理解し、テスト環境ですべてが機能することを再度確認してから、検証のために送信する準備をします。

アプリのリリース計画や、新しいスコープを必要とする新機能のリリース計画に、確認の完了に必要な時間を必ず含めてください。これらの追加要件の 1 つは、アプリがサーバーからまたはサーバー経由で Google ユーザーデータにアクセスする場合、またはアクセスする機能を備えている場合に発生します。このような場合、システムは Google が承認した独立した第三者評価機関による年次セキュリティ評価を受ける必要があります。このため、制限付きスコープの確認プロセスが完了するまでに数週間かかることがあります。なお、すべてのアプリでまずブランドの適格性確認の手順を完了する必要があります。この手順は、前回の OAuth 同意画面の適格性確認の承認以降にブランド情報が変更されている場合は、通常 2 ～ 3 営業日かかります。

許可されているアプリケーション タイプ

特定のアプリケーション タイプは、各サービスの制限付きスコープにアクセスできます。アプリケーションの種類については、プロダクト固有の Google デベロッパー ページ（Gmail API ポリシーなど）をご覧ください。

アプリの種類を理解し、決定するのはパブリッシャー様の責任となります。ただし、アプリのアプリケーション タイプが本当に不明な場合は、アプリの検証を送信する際に [使用する機能] の質問でオプションを選択しないでください。Google API の審査チームがアプリケーションの種類を決定します。

セキュリティの評価

Google ユーザーの制限付きデータへのアクセスをリクエストし、サードパーティ サーバーからまたはサードパーティ サーバー経由でデータにアクセスできるすべてのアプリは、Google が任命したセキュリティ評価者によるセキュリティ評価を受ける必要があります。この評価は、Google ユーザーデータにアクセスするすべてのアプリが、データを安全に処理し、ユーザーのリクエストに応じてユーザーデータを削除する機能を備えていることを確認することで、Google ユーザーのデータを安全に保つために役立ちます。

セキュリティ評価を標準化するために、 App Defense Alliance と クラウド アプリケーション セキュリティ評価フレームワーク（CASA）を使用しています。

前述のとおり、検証済みの制限付きスコープへのアクセスを維持するには、評価者の評価文書（LOA）の承認日から少なくとも 12 か月ごとに、アプリのコンプライアンスの再検証とセキュリティ アセスメントの完了が必要です。アプリに新しい制限付きスコープが追加された場合、追加のスコープが以前のセキュリティ評価に含まれていなかった場合は、追加のスコープを対象にアプリを再評価する必要がある場合があります。

アプリの再認定が必要な時期になると、Google の審査チームからメールが届きます。この年次施行について、適切なチームメンバーに通知されるようにするには、 プロジェクトにオーナーまたは編集者として追加の Google アカウントを関連付けます。また、Google OAuth で指定されているユーザー サポートとデベロッパーの連絡先メールアドレスを最新の状態に保つこともできます。

確認の準備手順

Google API を使用してデータへのアクセスをリクエストするすべてのアプリは、次の手順に沿ってブランドの確認を完了する必要があります。

  1. アプリが確認要件の例外に記載されているケースに当てはまらないことを確認します。
  2. アプリが、関連する API またはプロダクトのブランディング要件に準拠していることを確認します。たとえば、Google ログイン スコープのブランドの取り扱いガイドラインをご覧ください。
  3. Google Search Console で、プロジェクトの承認済みドメインの所有権を確認します。 API Console プロジェクトにオーナーまたは編集者として関連付けられている Google アカウントを使用します。
  4. OAuth 同意画面のすべてのブランディング情報（アプリ名、サポートメール、ホームページの URI、プライバシー ポリシーの URI など）が、アプリのアイデンティティを正確に表していることを確認します。

アプリケーションのホームページの要件

ホームページが次の要件を満たしていることを確認してください。

  • ホームページは一般公開されている必要があります。サイトにログインしているユーザーだけがアクセスできるものではいけません。
  • 審査対象のアプリとホームページとの関連性が明確である必要があります。
  • Google Play ストアでのアプリの掲載情報や Facebook ページへのリンクは、有効なアプリのホームページとは見なされません。

アプリケーション プライバシー ポリシーのリンクの要件

アプリのプライバシー ポリシーが次の要件を満たしていることを確認します。

  • プライバシー ポリシーは、ユーザーに表示され、アプリのホームページと同じドメイン内でホストされ、 Google API Consoleの OAuth 同意画面にリンクされている必要があります。ホームページには、アプリの機能の説明と、プライバシー ポリシーと利用規約（任意）へのリンクを含める必要があります。
  • プライバシー ポリシーでは、アプリケーションにおける Google のユーザーデータへのアクセス、およびそれらの使用、保存、共有の方法を開示する必要があります。 The privacy policy must comply with the Google API Services User Data Policy and the Limited Use requirements for restricted scopes. Google のユーザーデータの使用は、公開しているプライバシー ポリシーで開示されている方法に限定する必要があります。
  • Review example cases of privacy policies that don't meet the Limited Use requirements.

アプリを送信して確認を受ける方法

プロジェクトは、すべての リソースを整理します。プロジェクトは、プロジェクト オペレーションを実行する権限を持つ関連付けられた Google アカウント、有効な API のセット、それらの API の課金、認証、モニタリングの設定で構成されます。たとえば、プロジェクトに 1 つ以上の OAuth クライアントを含め、それらのクライアントが使用する API を構成し、アプリへのアクセスを承認する前にユーザーに表示される OAuth 同意画面を構成できます。

いずれかの OAuth クライアントが本番環境に対応していない場合は、確認をリクエストしているプロジェクトから削除することをおすすめします。これは で行うことができます。

確認を送信する手順は次のとおりです。

  1. アプリが Google API の利用規約と Google API サービスのユーザーデータに関するポリシーに準拠していることを確認します。
  2. プロジェクトに関連付けられているアカウントの所有者と編集者のロール、および OAuth 同意画面のユーザー サポート用メールアドレスとデベロッパーの連絡先情報を で最新の状態に保ってください。これにより、新しい要件が適切なチームメンバーに通知されるようになります。
  3. OAuth に移動します。
  4. [プロジェクト セレクタ] ボタンをクリックします。

  5. 表示された [選択元] ダイアログで、プロジェクトを選択します。プロジェクトが見つからないものの、プロジェクト ID がわかっている場合は、次の形式でブラウザで URL を作成できます。

    ?project=[PROJECT_ID]

    [PROJECT_ID] は、使用するプロジェクト ID に置き換えます。

  6. [アプリを編集] ボタンを選択します。
  7. [OAuth 同意画面] ページで必要な情報を入力し、[保存して続行] ボタンを選択します。
  8. [スコープを追加または削除] ボタンを使用して、アプリがリクエストするすべてのスコープを宣言します。Google ログインに必要な最初の一連のスコープの設定は、[機密性なしのスコープの設定] セクションに事前入力されています。追加されたスコープは、非機密の sensitive, or restrictedとして分類されます。
  9. アプリの関連機能に関する関連ドキュメントへのリンクを 3 つまで指定します。

  10. 次の手順で、アプリに関する追加情報を提供します。

    1. Ensure your app complies with the Additional requirements for specific API scopes, which includes undergoing an annual security assessment if your app accesses restricted scope Google users' data from or through a third-party server.
    2. Ensure your app is one of the allowed types specified in the Limited Use section of the Additional requirements for specific API scopes page.
    3. If your app is a task automation platform, your demonstration video must showcase how multiple API workflows are created and automated, and in which directions user data flows.

    4. Prepare a video that fully demonstrates how a user initiates and grants access to the requested scopes and shows, in detail, the usage of the granted sensitive and restricted scopes in the app. Upload the video to YouTube Studio and set Visibility as Unlisted. You need to provide a link to the demonstration video in the YouTube link field.

      1. Show the OAuth grant process that users will experience, in English. This includes the consent flow and, if you use Google Sign-In, the sign-in flow.
      2. Show that the OAuth consent screen correctly displays the App Name.
      3. Show that the browser address bar of the OAuth consent screen correctly includes your app's OAuth client ID.
      4. To show how the data will be used, demonstrate the functionality that's enabled by each sensitive and restricted scope that you request.
      5. If you use multiple clients, and therefore have multiple OAuth client IDs, show how the data is accessed on each OAuth client.
    5. Select your permitted application type from the "What features will you use?" list.
    6. Describe how you will use the restricted scopes in your app and why more limited scopes aren't sufficient.
  11. 指定したアプリ構成で検証が必要な場合は、検証用にアプリを送信できます。必須項目に入力し、[送信] をクリックして確認プロセスを開始します。

アプリを送信すると、Google の Trust & Safety チームから、必要な追加情報や完了する必要がある手順についてメールで連絡があります。[デベロッパーの連絡先情報] セクションのメールアドレスと、OAuth 同意画面のサポート用メールアドレスで、追加情報の提供をリクエストしているかどうかを確認します。プロジェクトの OAuth 同意画面ページで、プロジェクトの現在の審査ステータス（Google が回答を待機している間に審査プロセスが一時停止されているかどうかなど）を確認することもできます。

適格性確認の要件の例外

以下のセクションで説明するシナリオでアプリを使用する場合は、審査のためにアプリを送信する必要はありません。

個人的な利用

たとえば、アプリのユーザーが自分だけの場合や、アプリが少数のユーザー（全員が自分と面識があるユーザー）によって使用されている場合などです。開発者自身と少数のユーザーであれば、未確認アプリの画面を進めて、個人アカウントにアプリへのアクセス権を付与しても問題ない場合があります。

開発、テスト、ステージング ティアで使用されるプロジェクト

Google OAuth 2.0 ポリシーに準拠するために、テスト環境と本番環境に異なるプロジェクトを用意することをおすすめします。Google アカウントを持つすべてのユーザーがアプリを使用できるようにする場合にのみ、アプリの確認を送信することをおすすめします。そのため、アプリが開発フェーズ、テストフェーズ、ステージング フェーズにある場合は、確認は必要ありません。

アプリが開発フェーズまたはテストフェーズにある場合は、[公開ステータス] をデフォルトの [テスト] のままにしておきます。この設定は、アプリがまだ開発中であり、テストユーザーのリストに追加したユーザーのみがアプリを使用できることを意味します。アプリの開発やテストに関連する Google アカウントのリストを管理する必要があります。

テスト中のアプリが Google で確認されていないことを示す警告メッセージ。
図 1. テスターの警告画面

サービス所有のデータのみ

アプリがサービス アカウントを使用して独自のデータにのみアクセスし、（Google アカウントにリンクされた）ユーザーデータにアクセスしていない場合は、確認のために送信する必要はありません。

サービス アカウントの詳細については、Google Cloud のドキュメントのサービス アカウントをご覧ください。サービス アカウントの使用方法については、サーバー間アプリケーションに OAuth 2.0 を使用するをご覧ください。

社内専用

つまり、このアプリは Google Workspace または Cloud Identity の組織内のユーザーのみが使用できます。プロジェクトは組織が所有している必要があります。また、OAuth 同意画面は内部ユーザータイプ用に構成する必要があります。この場合、アプリに組織管理者の承認が必要になることがあります。詳細については、Google Workspace に関するその他の考慮事項をご覧ください。

ドメイン全体のインストール

アプリで Google Workspace または Cloud Identity の組織のユーザーのみをターゲットにし、常にドメイン全体のインストールを使用する場合は、アプリの確認は必要ありません。これは、ドメイン全体にインストールすると、ドメイン管理者がサードパーティ製アプリケーションと内部アプリケーションにユーザーデータへのアクセスを許可できるためです。ドメイン内で使用するためにアプリを許可リストに追加できるのは、組織管理者のアカウントのみです。

アプリをドメイン全体のインストールにする方法については、よくある質問の 私のアプリには、別の Google Workspace ドメインのエンタープライズ アカウントを持つユーザーがいますをご覧ください。