アプリが Google API を使用して Google ユーザーのデータにアクセスする権限をリクエストする場合、アプリを初めて一般公開する前に確認プロセスを完了しなければならないことがあります。
この要件がアプリに適用されるかどうかは、主に次の 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 Console の [データアクセス] ページで宣言します。 指定したスコープは、機密性の高いカテゴリまたは制限付き カテゴリにグループ化され、必要な追加の確認がハイライト表示されます。
- 統合で使用するデータに最適なスコープを見つけて、その使用方法を把握し、 テスト環境で引き続きすべてが機能することを確認してから、確認のために送信する準備をします。
確認の準備手順
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 サービスのユーザーデータに関するポリシーに準拠していることを確認します。
- プロジェクトに関連付けられたアカウントのオーナーと編集者のロール、OAuth 同意画面のユーザー サポート メールアドレス、デベロッパーの連絡先情報を Cloud Console で最新の状態に保ちます。これにより、新しい要件がチームの適切なメンバーに通知されます。
- Cloud Console の [OAuth ブランディング] ページに移動します。
- [プロジェクト セレクタ] ボタンをクリックします。
-
表示された [選択元] ダイアログで、プロジェクトを選択します。プロジェクトが見つからないがプロジェクト ID がわかっている場合は、ブラウザで次の形式で URL を作成できます。
https://console.developers.google.com/auth/branding?project=[PROJECT_ID]
[PROJECT_ID] は、使用するプロジェクト ID に置き換えます。
- [ブランディング] ページで、アプリのブランディング情報（アプリ名、ロゴ、デベロッパーの連絡先情報、関連リンクなど）を入力します。変更内容は [ブランディングのドラフト] として保存されます。
- [Verify Branding] ボタンをクリックして、評価プロセスを開始します。通常、自動システムによる審査は数分で完了します。
- 評価が完了したら、ステータスを確認します。成功すると、 ステータスが [公開準備完了] に変わります。自動確認 が失敗した場合は、検出された問題を確認し、修正するか、個別審査を リクエストできます。
- [Publish branding] ボタンをクリックして、新しいブランディングを公開します。
-
アプリで機密性の高いスコープや制限付き スコープの確認も必要な場合は、OAuth [Verification Center] に移動して [データアクセス ステータス] を確認し、デモ動画など、リクエストされた追加情報を提供します。データアクセスの確認をリクエストするには、ブランディングのステータスが公開されている必要があります。
- [**スコープを追加または削除**] ボタンを使用して、アプリがリクエストするすべてのスコープを宣言します。Google ログインに必要なスコープの初期セットは、[**機密性の低いスコープ**] セクションに事前入力されています。追加されたスコープは、機密性の低いスコープ、
sensitive, or
<a href="/identity/protocols/oauth2/production-readiness/restricted-scope-verification"
restrictedに分類されます。
- アプリの関連機能に関する関連ドキュメントへのリンクを 3 つまで指定します。
-
以降の手順で、アプリに関する追加情報がリクエストされた場合は、その情報を提供します。
- 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." -
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.
- 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.
- Show that the OAuth consent screen correctly displays the App Name.
- Show that the browser address bar of the OAuth consent screen correctly includes your app's OAuth client ID.
- To show how the data will be used, demonstrate the functionality that's enabled by each sensitive scope that you request.
- 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
ブランディングを公開するか、データアクセス リクエストを送信すると、Google の Trust & Safety チームから、必要な追加 情報や完了する必要がある手順についてメールで連絡が届くことがあります。追加情報のリクエストについては、[デベロッパーの連絡先情報] セクションのメールアドレスと、OAuth 同意画面のサポートメールをご確認ください。プロジェクトの [ブランディング] ページまたは [確認センター] ページで、プロジェクトの現在の審査ステータス（回答を待っている間、審査プロセスが一時停止しているかどうかなど）を確認することもできます。
確認要件の例外
アプリが次のセクションで説明するシナリオで使用される場合は、審査のために送信する必要はありません。
個人的な利用
アプリのユーザーが自分だけの場合や、アプリを使用するユーザーが数名で、 全員が個人的に知り合いである場合です。自分と少数のユーザーは、未確認アプリの画面を進み、個人アカウントにアプリへのアクセス権を付与しても問題ないかもしれません。
開発、テスト、ステージングの各階層で使用されるプロジェクト
Google OAuth 2.0 ポリシーに 準拠するため、テスト環境と本番環境で異なるプロジェクトを使用することをおすすめします。Google アカウントを持つすべてのユーザーがアプリを利用できるようにする場合にのみ、アプリの確認申請を送信することをおすすめします。 そのため、アプリが開発、テスト、ステージングの段階にある場合は、確認は必要ありません。
アプリが開発段階またはテスト段階にある場合は、 [公開ステータス] をデフォルト設定の [**テスト**] のままにできます。この設定は、アプリがまだ開発中であり、テストユーザーのリストに追加したユーザーのみが 利用できることを意味します。アプリの開発またはテストに関与する Google アカウント のリストを管理する必要があります。
2
サービス所有のデータのみ
アプリがサービス アカウントを使用して独自のデータにのみアクセスし、ユーザー データ（Google アカウントにリンクされている）にアクセスしない場合は、確認のために送信する必要はありません。
サービス アカウントとは何かについては、 サービス アカウント（Google Cloud のドキュメント）をご覧ください。サービス アカウントの使用方法については、 サーバー間アプリケーションに OAuth 2.0 を使用する をご覧ください。
社内専用
これは、アプリが Google Workspace または Cloud Identity 組織のユーザーのみによって使用されることを意味します。プロジェクトは組織が所有し、その OAuth 同意画面 は [**内部**] ユーザー タイプ用に構成する必要があります。この場合、アプリには組織管理者の承認が必要になることがあります。詳しくは、Google Workspace の追加の考慮事項をご覧ください。
- 詳しくは、 一般公開アプリと 社内アプリをご確認ください。
- アプリを社内用としてマークする方法については、よくある質問 アプリを社内専用としてマークする方法 をご覧ください。
ドメイン全体のインストール
アプリが Google Workspace または Cloud Identity 組織のユーザーのみを対象とし、常に ドメイン全体の インストールを使用する場合は、アプリのブランド確認は必要ありません。ただし、アプリが 制限付きスコープまたは機密性の高いスコープを使用する場合は、 アプリの確認が必要です。これは、ドメイン全体のインストールにより、ドメイン 管理者がサードパーティ製アプリと内部アプリにユーザーのデータへのアクセス権を付与できるためです。組織 管理者は、ドメイン内で使用するアプリを許可リストに追加できる唯一のアカウントです。
アプリをドメイン全体のインストールにする方法については、よくある質問 アプリケーションに 別の Google Workspace ドメインの企業アカウントを持つユーザーがいます。をご覧ください。