アプリが 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 Developers ページにリファレンス ドキュメントがあります。これには、エンドポイントまたは特定のプロパティを呼び出すために必要なスコープが含まれています。アプリが呼び出す 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 サービスのユーザーデータに関するポリシーに準拠していることを確認します。
- プロジェクトに関連付けられているアカウントのオーナーロールと編集者ロール、OAuth 同意画面のユーザー サポートメールとデベロッパーの連絡先情報を、Cloud コンソールで最新の状態に保ちます。これにより、チームの適切なメンバーに新しい要件が通知されます。
- Cloud コンソールの OAuth の [ブランディング] ページに移動します。
- [プロジェクト セレクタ] ボタンをクリックします。
表示された [選択元] ダイアログで、プロジェクトを選択します。プロジェクトが見つからないが、プロジェクト ID がわかっている場合は、ブラウザで次の形式の URL を作成できます。
https://console.developers.google.com/auth/branding?project=[PROJECT_ID]
[PROJECT_ID] は、使用するプロジェクト ID に置き換えます。
[ブランディング] ページで、アプリ名、ロゴ、デベロッパーの連絡先情報、関連リンクなど、アプリのブランディング情報を入力します。変更内容はブランディングの下書きとして保存されます。
[Verify Branding] ボタンをクリックして、評価プロセスを開始します。自動システムによる審査は通常、数分で完了します。
評価が完了したら、ステータスを確認します。成功すると、ステータスが [公開準備完了] に変わります。自動検証が失敗した場合は、検出された問題を確認して修正するか、手動審査をリクエストできます。
[ブランディングを公開] ボタンをクリックして、新しいブランディングを公開します。
アプリで機密性の高いスコープや制限付きスコープの確認も必要な場合は、OAuth 確認センターに移動してデータアクセスのステータスを追跡し、デモ動画などのリクエストされた追加情報を提供します。データアクセス検証をリクエストするには、ブランディング ステータスが公開済みである必要があります。
[スコープを追加または削除] ボタンを使用して、アプリがリクエストするすべてのスコープを宣言します。Google ログインに必要なスコープの初期セットは、[機密性の低いスコープ] セクションに事前入力されています。追加されたスコープは、非機密、機密、制限付きに分類されます。
アプリの関連機能に関する関連ドキュメントへのリンクを 3 つまで指定します。
以降の手順で、アプリに関する追加情報を入力します。
- リクエストされた機密スコープごとに詳細な理由を準備し、より狭いスコープでは不十分な理由を説明します。例: 「このアプリは、
https://www.googleapis.com/auth/calendarを使用して、アプリのスケジュール画面にユーザーの Google カレンダーのデータを表示します。これにより、ユーザーはアプリでスケジュールを管理し、変更を Google カレンダーと同期できます。」 - ユーザーがリクエストされたスコープへのアクセスを開始して許可する方法を完全に実証し、許可された機密性の高いスコープと制限付きスコープがアプリ内でどのように使用されるかを詳細に示す動画を準備します。動画を YouTube Studio にアップロードし、[公開設定] を [限定公開] に設定します。[YouTube リンク] 欄にデモ動画へのリンクを入力する必要があります。
- ユーザーが体験する OAuth 権限付与プロセスを英語で表示します。これには、同意フローと、Google ログインを使用する場合はログインフローが含まれます。
- OAuth 同意画面にアプリ名が正しく表示されていることを示す。
- OAuth 同意画面のブラウザのアドレスバーに、アプリの OAuth クライアント ID が正しく含まれていることを示します。
- データがどのように使用されるかを示すには、リクエストする機密性の高いスコープごとに有効になる機能を示します。
- リクエストされた機密スコープごとに詳細な理由を準備し、より狭いスコープでは不十分な理由を説明します。例: 「このアプリは、
ブランディングを公開するか、データアクセス リクエストを送信すると、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 ドメインの企業アカウントを持つユーザーがいるをご覧ください。