一部の Google API（ 機密または 制限付き のスコープを受け入れる API）には、消費者データへのアクセス権限を求めるアプリの要件があります。これらの制限付きスコープの追加要件では、アプリは、許可されたアプリケーション タイプであることを実証し、セキュリティ評価を含む追加審査に提出する必要があります。
API 内の制限付きスコープの適用範囲は、アプリで関連機能（読み取り専用、書き込み専用、読み取りと書き込みなど）を提供するために必要となるアクセス権の度合いに大きく依存します。
OAuth 2.0 を使用して Google アカウントからこのデータにアクセスする権限を取得するには、スコープと呼ばれる文字列を使用して、アクセスするデータの種類と必要なアクセス権の範囲を指定します。アプリが機密性の高いスコープまたは 制限付きのスコープをリクエストする場合、アプリの使用が 例外に該当する場合を除き、検証プロセスを完了する必要があります。
制限付きのスコープは、機密性の高いスコープに比べて数が少なくなります。 Verification 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 のポリシーに準拠し、アプリのアクションとプライバシー ポリシーでユーザーに提示する方法でのみ使用する必要があります。
- 各スコープの詳細（ sensitive or restricted ステータスの可能性など）については、API ドキュメントをご覧ください。
- API Consoleの OAuth 同意画面の設定スコープ ページで、アプリで使用するすべてのスコープを宣言します。指定したスコープはデリケートなカテゴリまたは制限付きのカテゴリにグループ化されるため、追加で必要な確認手続きが明確になります。
- 統合で使用されているデータに最適なスコープを見つけ、その用途を理解して、テスト環境ですべてが機能することを再確認してから、検証を受ける準備をします。
アプリのリリース計画や、新しいスコープを必要とする新機能に対して検証を完了するために必要な時間を考慮してください。これらの追加要件の一つは、アプリがサーバーとの間で、またはサーバー経由で Google ユーザーデータにアクセスする、またはその機能を備えている場合に適用されます。このような場合、システムは Google が承認した独立した第三者評価機関から年に 1 回、セキュリティ評価を受ける必要があります。このため、制限付きスコープの検証プロセスが完了するまでに数週間かかることがあります。すべてのアプリは、最初にブランドの確認手順を完了する必要があります。最後に承認された OAuth 同意画面の確認以降にブランド情報が変更された場合、通常 2 ～ 3 営業日かかります。
許可されるアプリケーションの種類
特定のアプリケーション タイプでは、各プロダクトの制限付きスコープにアクセスできます。アプリケーションの種類は、サービス固有の Google デベロッパー ページ（Gmail API ポリシーなど）で確認できます。
アプリのタイプを把握して決定するのは、デベロッパーの責任です。ただし、アプリのタイプに確信が持てない場合は、検証用にアプリを送信する際に [どの機能を使用しますか？] の質問でオプションを選択しないでください。Google API の検証チームがアプリケーションの種類を決定します。
セキュリティの評価
Google ユーザーの制限付きデータへのアクセスをリクエストし、サードパーティのサーバーを介してデータにアクセスする機能を備えたアプリはすべて、Google が選定したセキュリティ評価機関によるセキュリティ評価を受ける必要があります。この評価では、Google のユーザーデータにアクセスするすべてのアプリで、データを安全に処理し、ユーザーのリクエストに応じてユーザーデータを削除する機能が実証されていることを確認することで、Google ユーザーのデータを安全に保つことができます。
Google では、セキュリティ評価を標準化するために、 App Defense Alliance と Cloud Application Security Assessment Framework（CASA）を利用しています。
前述のように、検証済みの制限付きスコープへのアクセスを維持するには、評価機関による評価書（LOA）の承認日から少なくとも 12 か月ごとに、アプリのコンプライアンスを再検証し、セキュリティ評価を完了する必要があります。アプリが新しい制限付きスコープを追加した場合、そのスコープが以前のセキュリティ評価に含まれていなかった場合、追加のスコープをカバーするためにアプリの再評価が必要になることがあります。
アプリの再認定が必要になった時点で Google 審査チームからメールが届きます。この年次適用についてチームの適切なメンバーに通知されるように、プロジェクトのオーナーまたは編集者として追加の Google アカウントを API Console プロジェクトに関連付けます。また、Google API Console OAuth Consent Screen pageで指定されているユーザー サポートとデベロッパーの連絡先メールアドレスを最新の状態にしておくこともおすすめします。
適格性確認の準備手順
Google API を使用してデータへのアクセスをリクエストするアプリはすべて、ブランドの確認を完了するために次の手順を行う必要があります。
- アプリが検証要件の例外に記載のユースケースに該当しないことを確認します。
- 関連する API やプロダクトのブランド要件にアプリが準拠していることを確認します。たとえば、Google ログイン スコープのブランディング ガイドラインをご覧ください。
- プロジェクトの承認済みドメインの所有権を、Google Search Console 内で確認します。オーナーまたは編集者として、 API Console プロジェクトに関連付けられている Google アカウントを使用します。
- OAuth 同意画面に表示されているすべてのブランド情報（アプリ名、サポートメール、ホームページの URI、プライバシー ポリシーの URI など）が、アプリの ID を正確に表していることを確認します。
アプリのホームページの要件
ホームページが次の要件を満たしていることを確認してください。
- ホームページは公開され、サイトのログイン ユーザーのみがアクセスできるものである必要があります。
- ホームページと審査中のアプリの関連性を明確にする必要があります。
- 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 API Console プロジェクトによって、すべての API Console リソースがまとめられます。プロジェクトは、プロジェクト オペレーションを実行する権限を持つ一連の関連する Google アカウント、有効な一連の API、それらの API の請求、認証、モニタリングの設定で構成されます。たとえば、プロジェクトに 1 つ以上の OAuth クライアントを追加し、それらのクライアントで使用する API を構成できます。また、ユーザーがアプリへのアクセスを承認する前に表示される OAuth 同意画面を構成できます。
本番環境用の準備が完了していない OAuth クライアントがある場合は、確認をリクエストしているプロジェクトから削除することをおすすめします。これは Google API Consoleで行います。
適格性確認のために送信する手順は次のとおりです。
- アプリが Google API の利用規約と Google API サービスのユーザーデータ ポリシーに準拠していることを確認します。
- API Consoleで、プロジェクトに関連付けられたアカウントのオーナーと編集者のロール、および OAuth 同意画面のユーザー サポートメールとデベロッパーの連絡先情報を最新の状態に保ってください。これにより、新しい要件が通知された場合にチームの適切なメンバーに通知されます。
- API ConsoleOAuth Consent Screen pageに移動します。
- [プロジェクト セレクタ] ボタンをクリックします。
-
表示された [選択元] ダイアログで、プロジェクトを選択します。プロジェクトが見つからなくても、プロジェクト ID はわかっている場合は、ブラウザで次の形式の URL を作成できます。
https://console.developers.google.com/apis/credentials/consent?project=[PROJECT_ID]
[PROJECT_ID] は、使用するプロジェクト ID に置き換えます。
- [Edit App] ボタンを選択します。
- OAuth 同意画面ページで必要な情報を入力し、[保存して次へ] ボタンを選択します。
- [スコープの追加と削除] ボタンを使用して、アプリによって要求されるすべてのスコープを宣言します。Google ログインに必要なスコープの初期セットは、[機密でないスコープ] セクションに事前入力されています。追加されたスコープは、機密性の低い 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 同意画面のサポートメールアドレスで、追加情報のリクエストがないことを確認します。また、プロジェクトの OAuth 同意画面を表示して、プロジェクトの現在の審査ステータス（Google が回答を待つ間、審査プロセスが一時停止されているかどうかなど）を確認することもできます。
適格性確認の要件の例外
アプリを以下のセクションに記載するシナリオで使用する場合は、審査のために送信する必要はありません。
個人的な利用
1 つのユースケースとしては、アプリのユーザーが 1 人だけの場合や、アプリを使用しているユーザーが個人的に知られている数人のみの場合が挙げられます。デベロッパーもユーザーも限られた人数でも、未確認のアプリ画面を進めて個人アカウントにアプリへのアクセス権を付与しても問題ないかもしれません。
Development、Test、Staging の各階層で使用されるプロジェクト
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 ドメインの企業アカウントを持つユーザーがアプリケーションを使用していますをご覧ください。