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

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 デベロッパー ページにあります。このドキュメントには、エンドポイントまたはその中の特定のプロパティを呼び出すために必要なスコープが含まれています。アプリが呼び出す API エンドポイントに必要なアクセス スコープの詳細については、それらのエンドポイントのリファレンス ドキュメントをご覧ください。
  • Google API から受け取ったデータは、API のポリシーに準拠し、アプリのアクションとプライバシー ポリシーでユーザーに提示した方法でのみ使用する必要があります。
  • 各スコープの詳細（ sensitive or restricted ステータスなど）については、API ドキュメントをご覧ください。
  • アプリで使用されるすべてのスコープを Cloud Consoleの Data Access page で宣言します。指定したスコープは、機密性の高いカテゴリまたは制限付きカテゴリにグループ化され、必要な追加の確認が強調表示されます。
  • インテグレーションで使用されるデータに最適なスコープを見つけ、その用途を理解し、テスト環境で引き続きすべてが機能することを確認してから、検証のために送信する準備をします。
テーブルには、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 Cloud Console プロジェクトは、すべての Cloud Console リソースを整理します。プロジェクトは、プロジェクト オペレーションを実行する権限を持つ一連の関連付けられた Google アカウント、一連の有効な API、これらの API の請求、認証、モニタリングの設定で構成されます。たとえば、プロジェクトには 1 つ以上の OAuth クライアントを含めることができ、それらのクライアントで使用する API を構成したり、ユーザーがアプリへのアクセスを承認する前に表示される OAuth 同意画面を構成したりできます。

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

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

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

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

    https://console.developers.google.com/auth/branding?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 同意画面ページで、プロジェクトの現在の審査ステータスを確認することもできます。たとえば、回答をお待ちしている間、審査プロセスが一時停止しているかどうかを確認できます。

適格性確認の要件の例外

アプリが以下のセクションで説明するシナリオのいずれかに該当する場合は、審査に提出する必要はありません。

個人的な利用

ユースケースの 1 つは、アプリのユーザーが自分だけの場合や、アプリのユーザーが数人だけで、その全員が個人的に知り合いである場合です。少数のユーザーであれば、未確認アプリの画面をスキップして、個人アカウントにアプリへのアクセス権を付与しても問題ないかもしれません。

開発、テスト、ステージングの各階層で使用されるプロジェクト

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

アプリをドメイン全体のインストールにする方法については、FAQ の別の Google Workspace ドメインの企業アカウントを持つユーザーが私のアプリケーションを使用していますをご覧ください。