Google API にアクセスするすべてのアプリは、 Google の API サービスのユーザーデータ に関するポリシーで指定されているとおり、自身の身元と意図を正確に表していることを確認する必要があります。デベロッパーと Google とアプリの共有ユーザーを保護するために、同意画面とアプリケーションを Google で確認する必要が生じる場合があります。
アプリが次の条件をすべて満たしている場合は、確認が必要です。
- Google API コンソールで、アプリの構成がユーザータイプ [外部]、公開ステータス [公開済み] に設定されている。これは、アプリが本番環境にあり、Google アカウントを持つすべてのユーザーが利用できることを意味します。
- アプリの OAuth 同意画面にロゴまたは表示名を表示したい。
アプリのブランド情報を確認すると、 ユーザーがブランドを認識してアプリへのアクセスを許可する可能性が高まります。ブランド情報が確認されていると、ユーザーまたは Google Workspace 管理者がアカウントにアクセスできるサードパーティ製アプリやサービスを 確認する際に、後で取り消されることが少なくなる可能性があります。[ブランドを確認] ボタンをクリックすると、通常、自動ブランド確認プロセスが数分で完了します。結果を自動的に判断できない場合は、アプリが手動審査プロセスを受けることがあります。通常、このプロセスには 2 ～ 3 営業日かかります。
アプリのブランディング情報が確認されないままだと、ユーザーがデータのリクエストを信頼しなくなる可能性があります。その結果、ユーザーの承認が減り、後で取り消されることが増える可能性があります。
OAuth 同意画面
同意画面では、誰がデータへのアクセスをリクエストしているのかと、どのような種類のデータへのアクセスがアプリに許可されるのかをユーザーに知らせます（図 1 のボックス 2）。
アプリがブランド確認プロセスを経て承認されると、権限を付与するアカウントがアプリケーションの ID とユーザーデータ ポリシーを明確に理解できる可能性が高まります。明確に理解することで 、アカウント所有者がリクエストを承認し 、Google アカウント ページで取り消し候補を確認する際にアクセスを維持する可能性が高まります。Cloud Console の [OAuth ブランディング] ページで構成したコンテンツは、次の要素に反映されます。
- アプリ名とロゴ（図 1 のボックス 1）
- アプリ名を選択した後に表示されるユーザー サポートのメールアドレス（図 1 のボックス 2）
- プライバシー ポリシーと利用規約へのリンク（図 1 のボックス 3）
図 1.OAuth 同意画面のモックアップ。
承認済みドメイン
ブランド確認プロセスの一環として、Google は、アプリケーションの OAuth 同意画面と認証情報に関連付けられているすべてのドメインの確認を義務付けています。パブリック サフィックスで登録できるドメイン コンポーネント（「最上位のプライベート ドメイン」）を
確認していただくようお願いしています。たとえば、アプリケーションのホームページが https://sub.example.com/product に設定されている OAuth 同意画面では、アカウント所有者に example.com ドメインの所有権を確認するよう求められます。
OAuth 同意画面エディタの [承認済みドメイン] セクションには、[アプリのドメイン] セクションの URI で使用されている最上位のプライベート ドメインを含める必要があります。これらのドメインには、アプリのホームページ、プライバシー ポリシー、利用規約が含まれます。[承認済みドメイン] セクションには、「ウェブ アプリケーション」OAuth クライアント タイプで承認されているリダイレクト URI または JavaScript 生成元も含まれている必要があります。
Google Search Console を使用して、承認済みドメインの所有権を確認します。ドメインの オーナー権限を持つ Google アカウントは、その承認済みドメインを使用する API Console プロジェクトに 関連付ける必要があります。Google Search 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 サービスのユーザーデータに関するポリシーに準拠していることを確認します。
- Cloud Console で、プロジェクトに関連付けられたアカウントのオーナーと編集者のロール、OAuth 同意画面のユーザー サポートのメールアドレス、デベロッパーの連絡先情報を最新の状態に保ちます。これにより、新しい要件がチームの適切なメンバーに通知されます。
- Cloud Console の [OAuth ブランディング] ページに移動します。
- [プロジェクト セレクタ] ボタンをクリックします。
- 表示された [選択元] ダイアログで、プロジェクトを選択します。プロジェクトが見つからないがプロジェクト ID がわかっている場合は、ブラウザで次の形式で URL を作成できます。
https://console.developers.google.com/auth/branding?project=[PROJECT_ID]
- [ブランディング] ページで、アプリ名、ロゴ、デベロッパーの連絡先情報、関連リンクなど、アプリのブランディング情報を入力します。加えた変更は [未公開のブランディング] として保存されます。
- [ブランドを確認] ボタンをクリックして評価プロセスを開始します。通常、自動システムによる審査は数分で完了します。
- 評価が完了したら、ステータスを確認します。成功すると、ステータスが [公開の準備ができました] に変わります。自動確認が失敗した場合は、検出された問題を確認して修正するか、個別審査をリクエストできます。
- [ブランディングを公開] ボタンをクリックして、新しいブランディングを公開します。
- アプリで機密性の高いスコープや制限付きスコープの確認も必要な場合は、OAuth [確認センター] に移動して [データアクセス ステータス] を確認し、デモ動画など、リクエストされた追加情報を提供します。データアクセスの確認をリクエストするには、ブランディングのステータスが [公開済み] になっている必要があります。
- [スコープを追加または削除] ボタンを使用して、アプリがリクエストするすべてのスコープを宣言します。[機密性の高いスコープ以外] セクションには、Google ログインに必要なスコープの初期セットが事前入力されています。追加されたスコープは、機密性の高いスコープ以外として分類されます sensitive, or restricted。
- アプリの関連機能に関する関連ドキュメントへのリンクを 3 つまで入力します。
- 以降の手順で、アプリに関する追加情報を入力します。
ブランディングを公開するか、データアクセス リクエストを送信すると、Google の Trust & Safety チームから、必要な追加情報や完了する必要がある手順についてメールで連絡が届くことがあります。[デベロッパーの連絡先情報] セクションと OAuth 同意画面のサポートメールアドレスで、追加情報のリクエストを確認してください。プロジェクトの [ブランディング] ページまたは [確認センター] ページで、プロジェクトの現在の審査ステータスを確認することもできます。たとえば、回答を待っている間、審査プロセスが一時停止しているかどうかを確認できます。
確認要件の例外
アプリが次のセクションで説明するシナリオで使用される場合は、審査のために送信する必要はありません。
個人的な利用
アプリのユーザーがデベロッパーのみの場合や、アプリを使用するユーザーが少数で、全員がデベロッパーと個人的に知り合いである場合です。デベロッパーと少数のユーザーは、未確認アプリの画面を進み、個人アカウントにアプリへのアクセスを許可しても問題ないかもしれません。
開発、テスト、ステージングの階層で使用されるプロジェクト
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 ドメインの企業アカウントを持つユーザーがいますをご覧ください。