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

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

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

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

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

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

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

新しいスコープを必要とするアプリや新機能のリリース計画には、確認の完了に必要な時間を必ず考慮してください。機密性の高いスコープの確認プロセスには、最長で 10 日かかることがあります。アプリがプライベートなスコープの確認リクエストのサブセットとしてブランド確認を完了できる場合があります。

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

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

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

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

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

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

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

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

    https://console.developers.google.com/auth/branding?project=[PROJECT_ID]

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

  6. [アプリを編集] ボタンを選択します。
  7. [OAuth 同意画面] ページで必要な情報を入力し、[保存して続行] ボタンを選択します。
  8. [スコープを追加または削除] ボタンを使用して、アプリがリクエストするすべてのスコープを宣言します。Google ログインに必要なスコープの初期セットは、[機密性の低いスコープ] セクションに事前入力されています。追加されたスコープは、非機密の sensitive, or <a href="/identity/protocols/oauth2/production-readiness/restricted-scope-verification"

    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 の信頼性と安全性のチームから、必要な追加情報や完了する必要がある手順についてメールで連絡があります。追加情報のリクエストについては、[デベロッパーの連絡先情報] セクションと 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 組織のユーザーのみとし、常にドメイン全体のインストールを使用する場合は、アプリのブランド認証は不要です。ただし、アプリが 制限付きスコープまたは機密性の高いスコープを使用している場合は、 アプリの確認が必要です。これは、ドメイン全体のインストールでは、ドメイン管理者がサードパーティ製または内部のアプリケーションにユーザーのデータへのアクセスを許可できるためです。組織の管理者は、ドメイン内で使用するアプリを許可リストに追加できる唯一のアカウントです。

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