プライベートなスコープの確認

アプリで Google API を使用して Google ユーザーのデータにアクセスする権限をリクエストしている場合、アプリを初めて一般公開する前に確認プロセスを完了しなければならないことがあります。

この要件がアプリに適用されるかどうかは、主に次の 2 つの要因によって決まります。

  1. アクセスするユーザーデータの種類（公開プロフィール情報、カレンダーのエントリ、ドライブ内のファイル、特定の健康＆フィットネス データなど）。
  2. 必要なアクセス権限のレベル（読み取り専用、読み取りと書き込みなど）。

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

機密性の高いスコープの例としては、Google カレンダーに保存されている予定の読み取り、Google コンタクトへの新しい連絡先の保存、YouTube 動画の削除などがあります。使用可能なスコープとその分類の詳細については、アプリが呼び出す API エンドポイントのリファレンス ドキュメントと、API 用に公開されている関連する認可ガイドをご覧ください。

このような機能を提供するために必要なユーザーデータへのアクセス権は、最小限のアクセス権を必要とするスコープをリクエストする必要があります。たとえば、データを読み取るだけのアプリは、API とその関連エンドポイントに限定されたスコープが使用可能な場合は、コンテンツの読み取り、書き込み、削除へのアクセスをリクエストしてはなりません。Google API から受け取ったデータは、API のポリシーに準拠し、アプリのアクションとプライバシー ポリシーでユーザーに提示する方法でのみ使用する必要があります。

アプリのリリース計画や、新しいスコープを必要とする新機能のリリース計画に、確認の完了に必要な時間を必ず含めてください。通常、デリケートな範囲の確認プロセスは 3 ～ 5 営業日で完了します。アプリは、プライベートなスコープの確認リクエストのサブセットとしてブランド確認を完了できる場合があります。

機密性の高いスコープについて

プライベート データにかかわるスコープは、Google アカウントがアクセス権を付与する前に、Google による審査を受ける必要があります。Google Workspace 組織管理者は、機密性の高いスコープへのアクセスを制限して、組織が信頼できると明示的にマークしていない OAuth クライアント ID によるアクセスを防ぐことができます。

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

  • アプリで使用しているスコープまたは使用するスコープを確認します。既存のスコープの使用状況を確認するには、アプリのソースコードで、認可リクエストとともに送信されるスコープを確認します。
  • リクエストされた各スコープがアプリ機能の目的のアクションに必要であり、その機能を提供するために必要な最小限の権限を使用していることを確認します。Google API の場合、通常、プロダクトの Google Developer ページに、エンドポイントのリファレンス ドキュメントが用意されています。このドキュメントには、エンドポイントの呼び出しに必要なスコープや、エンドポイント内の特定のプロパティが記載されています。アプリが呼び出す API エンドポイントに必要なアクセス スコープの詳細については、それらのエンドポイントのリファレンス ドキュメントをご覧ください。
  • Google API から受け取ったデータは、API のポリシーに準拠し、アプリのアクションとプライバシー ポリシーでユーザーに提示した方法でのみ使用する必要があります。
  • 各スコープの詳細（ sensitive or restricted ステータスなど）については、API ドキュメントをご覧ください。
  • アプリで使用されるすべてのスコープを、 の で宣言します。 指定したスコープは、機密性の高いスコープまたは制限付きスコープのカテゴリにグループ化され、必要な追加の確認がハイライト表示されます。
  • 統合で使用されるデータに一致する最適なスコープを見つけ、その用途を理解し、テスト環境ですべてが機能することを再度確認してから、検証のために送信する準備をします。
テーブルに、API の名前、機密性の高いスコープの 1 つ、スコープの内容の説明が表示されます。
図 1. 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 のユーザーデータへのアクセス、およびそれらの使用、保存、共有の方法を開示する必要があります。 Google のユーザーデータの使用は、公開しているプライバシー ポリシーで開示されている方法に限定する必要があります。

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

プロジェクトは、すべての リソースを整理します。プロジェクトは、プロジェクト オペレーションを実行する権限を持つ関連付けられた 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. Prepare a detailed justification for each requested sensitive scope, as well as an explanation for why a narrower scope isn't sufficient. For example: "My app will use https://www.googleapis.com/auth/calendar to show a user's Google calendar data on the scheduling screen of my app. This lets users manage their schedules through my app and sync the changes with their Google calendar."

    2. 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 its 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 scope that you request.
  11. 指定したアプリ構成で検証が必要な場合は、検証用にアプリを送信できます。必須項目に入力し、[送信] をクリックして確認プロセスを開始します。

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

適格性確認の要件の例外

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

個人的な利用

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

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

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

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

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

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

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

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

社内専用

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

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

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

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