Google ユーザーのデータにアクセスするために Google API の使用許可を求めるアプリの場合、アプリを初めて一般公開する前に、確認プロセスを完了しなければならない場合があります。
この要件がアプリに適用されるかどうかは、主に次の 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 のポリシーに準拠し、アプリのアクションとプライバシー ポリシーでユーザーに提示した方法でのみ使用する必要があります。
- 各スコープの詳細（機密情報や制限付きステータスなど）については、API ドキュメントをご覧ください。
- アプリで使用されるすべてのスコープを Cloud コンソールのデータアクセス ページで宣言します。指定したスコープは、機密性の高いカテゴリまたは制限付きカテゴリにグループ化され、必要な追加の確認がハイライト表示されます。
- インテグレーションで使用されるデータに最適なスコープを見つけ、その用途を理解し、テスト環境で引き続きすべてが機能することを確認してから、検証のために送信する準備をします。
確認の準備の手順
Google API を使用してデータへのアクセスをリクエストするすべてのアプリは、ブランドの確認を完了するために次の手順を行う必要があります。
- アプリが確認要件の例外セクションに記載されているケースに当てはまらないことを確認します。
- アプリが、関連する API またはプロダクトのブランディング要件に準拠していることを確認します。たとえば、Google ログイン スコープのブランドの取り扱いガイドラインをご覧ください。
- Google Search Console で、プロジェクトの承認済みドメインの所有権を確認します。API Console プロジェクトに関連付けられている Google アカウントをオーナーまたは編集者として使用します。
- OAuth 同意画面のすべてのブランディング情報（アプリ名、サポートメール、ホームページの URI、プライバシー ポリシーの URI など）が、アプリのアイデンティティを正確に表していることを確認します。
アプリケーションのホームページの要件
ホームページが次の要件を満たしていることを確認してください。
- ホームページは一般公開されている必要があり、サイトのログイン ユーザーのみがアクセスできる状態ではいけません。
- 審査中のアプリとホームページの関連性が明確である必要があります。
- Google Play ストアのアプリのリスティングまたは Facebook ページへのリンクは、有効なアプリのホームページとは見なされません。
アプリケーション プライバシー ポリシーのリンクの要件
アプリのプライバシー ポリシーが次の要件を満たしていることを確認します。
- プライバシー ポリシーは、ユーザーに表示され、アプリケーションのホームページと同じドメイン内でホストされ、Google API Console の OAuth 同意画面にリンクされている必要があります。ホームページには、アプリの機能の説明と、プライバシー ポリシーおよびオプションの利用規約へのリンクが含まれている必要があります。
- プライバシー ポリシーでは、アプリケーションが Google ユーザーデータにアクセスし、それらを使用、保存、共有する仕組みを開示する必要があります。 デベロッパーによる Google ユーザーデータの使用は、公開しているプライバシー ポリシーで開示されている取り扱いに限定される必要があります。
ブランドの確認を受けるためのアプリの送信方法
Google Cloud コンソール プロジェクトを使用して、すべての Cloud コンソール リソースを整理します。プロジェクトは、プロジェクト オペレーションを実行する権限を持つ一連の関連付けられた Google アカウント、一連の有効な API、これらの API の課金、認証、モニタリングの設定で構成されます。たとえば、プロジェクトには 1 つ以上の OAuth クライアントを含めることができ、これらのクライアントで使用する API を構成し、ユーザーがアプリへのアクセスを承認する前に表示される OAuth 同意画面を構成できます。
OAuth クライアントのいずれかが本番環境に対応していない場合は、確認をリクエストしているプロジェクトから削除することをおすすめします。これは [クライアント] ページで行うことができます。
確認を送信する手順は次のとおりです。
- アプリが Google API の利用規約と Google API サービスのユーザーデータに関するポリシーに準拠していることを確認します。
- Cloud Console で、プロジェクトの関連アカウントのオーナーと編集者のロール、OAuth 同意画面のユーザー サポートのメールアドレスとデベロッパーの連絡先情報を最新の状態に保ちます。これにより、チームの適切なメンバーに新しい要件が通知されます。
- Cloud Console の OAuth の [ブランディング] ページに移動します。
- [プロジェクト セレクタ] ボタンをクリックします。
- 表示された [選択元] ダイアログで、プロジェクトを選択します。プロジェクトが見つからないが、プロジェクト ID がわかっている場合は、ブラウザで次の形式の URL を作成できます。
https://console.developers.google.com/auth/branding?project=[PROJECT_ID]
- [ブランディング] ページで、アプリ名、ロゴ、デベロッパーの連絡先情報、関連リンクなど、アプリのブランディング情報を入力します。変更内容は [下書きのブランディング] として保存されます。
- [ブランド設定を確認] ボタンをクリックして、評価プロセスを開始します。自動システムによる審査は通常数分で完了します。
- 評価が完了したら、ステータスを確認します。成功すると、ステータスが [公開準備完了] に変わります。自動検証が失敗した場合は、検出された問題を確認し、問題を修正するか、個別審査をリクエストできます。
- [ブランド設定を公開] ボタンをクリックして、新しいブランド設定を有効にします。
- アプリで機密性の高いスコープや制限付きスコープの確認も必要な場合は、OAuth の確認センターに移動して、データアクセス ステータスを追跡し、デモ動画などの追加情報を求められた場合は提供してください。データアクセスの検証をリクエストするには、ブランディングのステータスが公開済みである必要があります。
- [スコープを追加または削除] ボタンを使用して、アプリがリクエストするすべてのスコープを宣言します。Google ログインに必要なスコープの初期セットは、[機密性の低いスコープ] セクションに事前入力されています。追加されたスコープは非機密として分類されます。 sensitive, or restricted
- アプリの関連機能に関する関連ドキュメントへのリンクを 3 つまで指定します。
- 以降の手順で、アプリについて求められた追加情報を入力します。
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/calendarto 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.
ブランディングを公開するか、データアクセス リクエストを送信すると、Google の Trust & Safety チームから、必要な追加情報や完了する必要がある手順についてメールで連絡が届くことがあります。[デベロッパーの連絡先情報] セクションのメールアドレスと OAuth 同意画面のサポート メールアドレスに、追加情報の提供を求めるメールが届いていないかご確認ください。プロジェクトの [ブランディング] ページまたは [検証センター] ページで、プロジェクトの現在の審査ステータス（審査プロセスが一時停止しているかどうかなど）を確認することもできます。
適格性確認の要件の例外
アプリが以下のセクションで説明するシナリオのいずれかに該当する場合は、審査に送信する必要はありません。
個人的な利用
ユースケースの 1 つとして、アプリのユーザーが自分だけの場合や、アプリのユーザーが数人だけで、その全員が個人的に知り合いである場合が挙げられます。少数のユーザーであれば、未確認アプリの画面をスキップして、個人アカウントにアプリへのアクセス権を付与しても問題ないかもしれません。
開発、テスト、ステージングの各階層で使用されるプロジェクト
Google OAuth 2.0 ポリシーに準拠するため、テスト環境と本番環境で異なるプロジェクトを使用することをおすすめします。Google アカウントを持つすべてのユーザーがアプリを使用できるようにする場合にのみ、アプリを検証用に送信することをおすすめします。そのため、アプリが開発、テスト、ステージングの段階にある場合は、確認は必要ありません。
アプリが開発段階またはテスト段階にある場合は、[公開ステータス] をデフォルト設定の [テスト] のままにしておくことができます。この設定は、アプリがまだ開発中であり、テストユーザーのリストに追加されたユーザーのみが利用できることを意味します。アプリの開発またはテストに関与する Google アカウントのリストを管理する必要があります。
サービス所有のデータのみ
アプリがサービス アカウントを使用して独自のデータにのみアクセスし、ユーザーデータ（Google アカウントにリンクされている）にアクセスしない場合は、確認を送信する必要はありません。
サービス アカウントの概要については、Google Cloud のドキュメントのサービス アカウントをご覧ください。サービス アカウントの使用方法については、サーバー間アプリケーションに OAuth 2.0 を使用するをご覧ください。
社内専用
つまり、アプリは Google Workspace または Cloud Identity の組織内のユーザーのみが使用します。プロジェクトは組織が所有している必要があり、その OAuth 同意画面は 内部ユーザータイプ用に構成されている必要があります。この場合、アプリで組織管理者の承認が必要になることがあります。詳細については、Google Workspace のその他の考慮事項をご覧ください。
- 詳しくは、一般公開アプリと社内アプリをご確認ください。
- アプリを社内用としてマークする方法については、アプリを社内専用としてマークするにはどうすればよいですか？に関するよくある質問をご覧ください。
ドメイン全体のインストール
アプリの対象を Google Workspace または Cloud Identity 組織のユーザーのみとし、常にドメイン全体のインストールを使用する予定の場合、アプリでブランドの確認は必要ありません。ただし、アプリが制限付きスコープまたは機密性の高いスコープを使用している場合は、アプリの確認が必要です。これは、ドメイン全体のインストールにより、ドメイン管理者がサードパーティ製または内部のアプリにユーザーのデータへのアクセスを許可できるためです。組織の管理者は、ドメイン内で使用するアプリを許可リストに追加できる唯一のアカウントです。
アプリをドメイン全体のインストールにする方法については、よくある質問の別の Google Workspace ドメインの企業アカウントを持つユーザーが私のアプリケーションを使用していますをご覧ください。