一部の Google API（ 機密性の高いスコープや 制限付き スコープを受け入れる API）には、ユーザーデータへのアクセス権をリクエストするアプリに対する要件があります。 制限付きスコープに関するこれらの 追加要件 では、アプリが許可されたアプリケーション タイプであることを証明し、追加の審査を受ける必要があります。この審査には、セキュリティ評価が含まれる場合があります。
API 内で制限付きスコープが適用されるかどうかは、アプリで関連する機能を提供するために必要なアクセス権のレベル（読み取り専用、書き込み専用、読み取りと書き込みなど）によって異なります。
OAuth 2.0 を使用して Google アカウントからこのデータへのアクセス権を取得する場合は、アクセスするデータの種類と必要なアクセス権のレベルを指定するために、スコープと呼ばれる文字列を使用します。 アプリが 機密性の高い スコープや 制限付き スコープをリクエストする場合は、アプリの使用が 例外の 対象とならない限り、確認プロセスを完了する必要があります。
制限付きスコープは、機密性の高いスコープよりも数が少なくなっています。OAuth API の確認に関するよくある質問には、機密性の高いスコープと制限付きスコープの現在のリストが記載されています。これらのスコープは Google ユーザーデータへの幅広いアクセスを提供するため、Google アカウントからスコープをリクエストする前に、スコープの確認プロセスを完了する必要があります。この要件について詳しくは、 Google API サービスのユーザーデータに関するポリシー と 特定の API スコープの追加要件 、またはプロダクト固有の Google デベロッパー ページ をご覧ください。制限付きスコープのデータをサーバーに保存または送信する場合は、 セキュリティ評価を完了する必要があります。
制限付きスコープについて
アプリが制限付きスコープをリクエストし、 例外の対象とならない場合は、Google API サービスのユーザーデータに関するポリシーの 特定の API スコープの追加要件 、またはプロダクトの Google デベロッパー ページのプロダクト固有の要件を満たす必要があります。これには、 より広範な審査プロセスが必要です。
スコープの使用状況を把握する
- アプリで使用しているスコープ、または使用する予定のスコープを確認します。既存のスコープの使用状況を確認するには、 アプリのソースコードで、認可リクエストとともに送信されるスコープを確認します。
- リクエストされた各スコープが、アプリの機能の目的のアクションに必要であり、機能を提供するために必要な最小権限を使用していることを確認します。通常、Google API には、エンドポイントを呼び出すために必要なスコープや、エンドポイント内の特定のプロパティを含む、エンドポイントに関するリファレンス ドキュメントがプロダクトの Google デベロッパー ページに用意されています。アプリが呼び出す API エンドポイントに必要なアクセス スコープについて詳しくは、それらの エンドポイントのリファレンス ドキュメントをご覧ください。 For example, for an app that only uses Gmail APIs to occasionally send emails on a user's behalf, don't request the scope that provides full access to the user's email data.
- Google API から受け取ったデータは、API のポリシーに準拠し、アプリのアクションとプライバシー ポリシーでユーザーに提示する方法でのみ使用する必要があります。
- 各スコープの詳細（ステータスの可能性 など）については、API ドキュメントをご覧ください。
- アプリで使用するすべてのスコープを、Cloud Console の [データアクセス] ページで宣言します。 指定したスコープは、機密性の高いカテゴリまたは制限付き カテゴリにグループ化され、必要な追加の確認がハイライト表示されます。
- 統合で使用するデータに最適なスコープを見つけて、その使用方法を把握し、 テスト環境ですべてが正常に動作することを再確認してから、確認を申請する準備をします。
アプリや新しいスコープを必要とする新機能のリリース計画には、確認を完了するのに必要な時間を考慮してください。これらの追加要件の 1 つは、アプリがサーバーから、またはサーバーを介して Google ユーザーデータにアクセスする場合、またはアクセスできる場合です。このような場合、システム は Google が承認した独立した第三者評価者による年次のセキュリティ評価を受ける必要があります。そのため、制限付きスコープの確認プロセスには数週間かかる可能性があります。前回の承認済み OAuth 同意画面の確認以降にブランディング情報が 変更された場合は、まず ブランディングの確認 ステップを完了する必要があります。通常、これには 2 ～ 3 営業日かかります。
許可されるアプリケーション タイプ
特定のアプリケーション タイプは、各プロダクトの制限付きスコープにアクセスできます。アプリケーション タイプは、プロダクト固有の Google デベロッパー ページ（Gmail API ポリシーなど）で確認できます。
アプリケーション タイプを把握して判断するのは、お客様の責任です。 ただし、アプリのアプリケーション タイプが不明な場合は、アプリの確認を申請する際に [使用する機能] の質問でオプションを選択しないこともできます。その場合、Google API の確認チームがアプリケーション タイプを判断します。
セキュリティ評価
Google ユーザーの制限付きデータへのアクセスをリクエストし、サードパーティ サーバーから、またはサードパーティ サーバーを介してデータにアクセスできるすべてのアプリは、Google が任命したセキュリティ評価者によるセキュリティ評価を受ける必要があります。この評価は、Google ユーザーデータにアクセスするすべてのアプリが、データを安全に処理し、ユーザーのリクエストに応じてユーザーデータを削除する機能を備えていることを確認することで、Google ユーザーのデータを安全に保つために役立ちます。
セキュリティ評価を標準化するために、 App Defense Alliance と クラウド アプリケーション セキュリティ評価フレームワーク（CASA）を使用しています。
前述のように、確認済みの制限付きスコープへのアクセスを維持するには、評価者の評価文書（LOA）の承認日から少なくとも 12 か月ごとに、アプリのコンプライアンスを再確認し、セキュリティ評価を完了する必要があります。 アプリに新しい制限付きスコープを追加した場合、以前のセキュリティ評価に含まれていない場合は、追加のスコープを対象とするためにアプリの再評価が必要になることがあります。
アプリの再認証が必要な場合は、Google 審査チームからメールが届きます。この年次の違反措置についてチームの適切なメンバーに通知されるようにするには、Cloud Console プロジェクトにオーナーまたは編集者として追加の Google アカウントを関連付けます。また、Google Cloud コンソール の OAuth ブランディング ページで指定されているユーザー サポートとデベロッパーの連絡先メールアドレスを最新の状態に保つことも重要です。
確認の準備手順
Google API を使用してデータへのアクセスをリクエストするすべてのアプリは、ブランディングの確認を完了するために次の手順を 行う必要があります。
- アプリが 確認要件の例外セクションのユースケースに当てはまらないことを確認します。
- アプリが、関連する API または プロダクトのブランディング要件に準拠していることを確認します。たとえば、ブランディング ガイドライン を Google ログイン スコープでご覧ください。
- Google Search Console でプロジェクトの 承認済みドメインのオーナー権限を確認します 。API Console プロジェクトに関連付けられている Google アカウントを オーナーまたは編集者として使用します。
- OAuth 同意画面のすべてのブランディング情報（アプリ名、サポート メール、ホームページの URI、プライバシー ポリシーの URI など）が、アプリのアイデンティティを正確に表していることを確認します。
アプリケーションのホームページの要件
ホームページが次の要件を満たしていることを確認します。
- ホームページは一般公開されており、サイトにログインしている ユーザーのみがアクセスできる状態ではない必要があります。
- 審査中のアプリとの関連性が明確である必要があります。
- Google Play ストアのアプリのリスティングや Facebook ページへのリンクは、有効なアプリケーションのホームページとは見なされません。
アプリケーションのプライバシー ポリシーのリンクの要件
アプリのプライバシー ポリシーが次の要件を満たしていることを確認します。
- プライバシー ポリシーはユーザーに表示され、アプリケーションのホームページと同じドメイン内でホストされ、Google API Console の OAuth 同意画面にリンクされている必要があります。ホームページには、アプリの機能の説明と、プライバシー ポリシーおよびオプションの利用規約へのリンクを含める必要があります。
- プライバシー ポリシーでは、アプリケーションにおける Google のユーザーデータへのアクセス、およびそれらの使用、 保存、共有の方法を開示する必要があります。 The privacy policy must comply with the Google API Services User Data Policy and the Limited Use requirements for restricted scopes. Google のユーザーデータの使用は、公開している プライバシー ポリシーで開示されている方法に限定する必要があります。
- Review example cases of privacy policies that don't meet the Limited Use requirements.
ブランディングの確認を申請する方法
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]
[PROJECT_ID] は、使用するプロジェクト ID に置き換えます。
- [ブランディング] ページで、アプリ名、ロゴ、デベロッパーの連絡先情報、関連リンクなど、アプリのブランディング情報を入力します。加えた変更はすべて [下書きのブランディング] として保存されます。
- [Verify Branding] ボタンをクリックして、評価プロセスを開始します。通常、自動システムによる審査は数分で完了します。
- 評価が完了したら、ステータスを確認します。成功すると、 ステータスが [公開準備完了] に変わります。自動確認 が失敗した場合は、検出された問題を確認し、修正するか、個別審査を リクエストできます。
- [Publish branding] ボタンをクリックして、新しいブランディングを公開します。
-
アプリで機密性の高いスコープや制限付き スコープの確認も必要な場合は、OAuth [Verification Center] に移動して [データアクセス ステータス] を確認し、デモ動画など、リクエストされた追加情報を提供します。データアクセスの確認をリクエストするには、ブランディングのステータスが公開されている必要があります。
- [スコープを追加または削除] ボタンを使用して、アプリがリクエストするすべてのスコープを宣言します。
[**機密性の高いスコープ以外**] セクションには、Google ログインに必要なスコープの初期セットが事前入力されています。追加されたスコープは、機密性の高いスコープ以外として分類されます。
<a href="/identity/protocols/oauth2/production-readiness/sensitive-scope-verification"
sensitive, or restricted。
- アプリの関連機能に関する関連ドキュメントへのリンクを 3 つまで指定します。
-
以降の手順で、アプリに関する追加情報を提供します。
- Ensure your app complies with the Additional requirements for specific API scopes, which includes undergoing an annual security assessment if your app accesses restricted scope Google users' data from or through a third-party server.
- Ensure your app is one of the allowed types specified in the Limited Use section of the Additional requirements for specific API scopes page.
- If your app is a task automation platform, your demonstration video must showcase how multiple API workflows are created and automated, and in which directions user data flows.
-
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 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 and restricted scope that you request.
- If you use multiple clients, and therefore have multiple OAuth client IDs, show how the data is accessed on each OAuth client.
- Select your permitted application type from the "What features will you use?" list.
- Describe how you will use the restricted scopes in your app and why more limited scopes aren't sufficient.
ブランディングを公開するか、データアクセス リクエストを送信すると、Google の Trust & Safety チームから、必要な追加 情報や完了する必要がある手順についてメールで連絡が届くことがあります。メールアドレスを [デベロッパーの連絡先情報] セクションと OAuth 同意画面のサポートメールアドレスで確認し、追加情報のリクエストがないか確認してください。プロジェクトのブランディング ページまたは確認 センター ページで、プロジェクトの現在の審査ステータス（回答を待っている間、審査プロセスが一時停止しているかどうかなど）を確認することもできます。
確認要件の例外
アプリが次のセクションで説明するシナリオで使用される場合は、 審査を申請する必要はありません。
個人的な利用
ユースケースの 1 つは、アプリのユーザーが自分だけの場合、またはアプリを使用するユーザーが数名で、全員が個人的に知っている場合です。 自分と少数のユーザーは、未確認アプリの画面を進み、個人アカウントにアプリへのアクセス権を付与しても問題ない場合があります。
開発、テスト、ステージングの各階層で使用されるプロジェクト
Google OAuth 2.0 ポリシーに 準拠するため、テスト環境と本番環境で異なるプロジェクトを使用することをおすすめします。Google アカウントを持つすべてのユーザーがアプリを利用できるようにする場合は、アプリの確認を申請することをおすすめします。 そのため、アプリが開発、テスト、ステージングの段階にある場合は、確認は必要ありません。
アプリが開発段階またはテスト段階にある場合は、 [公開ステータス] をデフォルト設定の [テスト] のままにできます。この設定は、アプリがまだ開発中であり、テストユーザーのリストに追加したユーザーのみが 利用できることを意味します。アプリの開発またはテストに関与する Google アカウント のリストを管理する必要があります。
1
サービスが所有するデータのみ
アプリがサービス アカウントを使用して独自のデータにのみアクセスし、ユーザー データ（Google アカウントにリンクされている）にアクセスしない場合は、確認を申請する必要はありません。
サービス アカウントの詳細については、 Google Cloud のドキュメントのサービス アカウントをご覧ください。サービス アカウントの使用方法については、 サーバー間アプリケーションに OAuth 2.0 を使用する をご覧ください。
社内専用
これは、アプリが Google Workspace または Cloud Identity 組織のユーザーのみによって使用されることを意味します。プロジェクトは組織が所有し、OAuth 同意画面 は [**内部**] ユーザー タイプ用に構成する必要があります。この場合、アプリには組織管理者の承認が必要になることがあります。詳しくは、Google Workspace の追加の考慮事項をご覧ください。
- 詳しくは、 一般公開アプリと 社内アプリをご確認ください。
- アプリを社内用としてマークする方法については、よくある質問 アプリを社内専用としてマークする方法 をご覧ください。
ドメイン全体のインストール
アプリが Google Workspace または Cloud Identity 組織のユーザーのみを対象とし、常に ドメイン全体の インストールを使用する場合は、アプリのブランディングの確認は必要ありません。ただし、アプリが 制限付きスコープまたは機密性の高いスコープを使用する場合は、 アプリの確認が必要です。これは、ドメイン全体のインストールにより、ドメイン 管理者がサードパーティ製アプリと内部アプリにユーザーのデータへのアクセス権を付与できるためです。組織 管理者は、ドメイン内で使用するアプリを許可リストに追加できる唯一のアカウントです。
アプリをドメイン全体のインストールにする方法については、よくある質問 アプリケーションに 別の Google Workspace ドメインの企業アカウントを持つユーザーがいます。をご覧ください。