Google API にアクセスするすべてのアプリは、Google API サービスのユーザーデータに関するポリシーに指定されているとおり、アプリの ID と目的を正確に表していることを確認する必要があります。デベロッパーと、Google およびアプリの共有ユーザーを保護するため、同意画面とアプリケーションは Google による検証が必要になる場合があります。
アプリが以下の条件をすべて満たしている場合は、検証が必要です。
- Google API Console で、アプリの構成がユーザータイプ [外部]、公開ステータス [公開済み] に設定されている。これは、アプリが本番環境にあり、Google アカウントを持つすべてのユーザーが利用できることを意味します。
- アプリのロゴや表示名を OAuth 同意画面に表示する場合。
アプリのブランド情報を確認すると、ユーザーがブランドを認識してアプリへのアクセスを許可する可能性が高くなります。また、ブランド情報を確認することで、ユーザーまたは Google Workspace 管理者がアカウントにアクセスできるサードパーティ製アプリやサービスを確認する際に、後で取り消される可能性が低くなります。自動ブランド確認プロセスは、通常、[ブランドを確認] ボタンをクリックしてから数分で完了します。結果を自動的に判断できない場合、アプリは手動審査プロセスに移行することがあります。このプロセスは通常 2 ～ 3 営業日かかります。
アプリのブランディング情報が未確認のままだと、データのリクエストに対するユーザーの信頼が低下し、ユーザーの承認が減り、後で取り消される可能性があります。
OAuth 同意画面
同意画面には、データへのアクセスをリクエストしているユーザーと、アプリがユーザーに代わってアクセスする必要があるデータの種類が表示されます（図 1 のボックス 2 を参照）。
アプリがブランド確認プロセスを経て承認されると、権限を付与するアカウントがアプリの ID とユーザーデータに関するポリシーを明確に理解する可能性が高くなります。このように明確に理解することで、アカウント所有者がリクエストを承認し、Google アカウント ページで取り消しの可能性を確認する際にアクセスを維持する可能性が高くなります。Cloud コンソールの OAuth ブランディング ページで構成したコンテンツは、次のコンポーネントに入力されます。
- アプリの名前とロゴ（図 1 のボックス 1 に表示）
- ユーザー サポートメール。アプリ名を選択すると表示されます（図 1 のボックス 2）。
- プライバシー ポリシーと利用規約へのリンク（図 1 のボックス 3）
承認済みドメイン
ブランド確認プロセスの一環として、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 サービスのユーザーデータに関するポリシーに準拠していることを確認します。
- プロジェクトに関連付けられているアカウントのオーナーと編集者のロール、OAuth 同意画面のユーザー サポートのメールアドレス、デベロッパーの連絡先情報を、Cloud コンソールで最新の状態に保ちます。これにより、チームの適切なメンバーに新しい要件が通知されます。
- Cloud コンソールの OAuth [ブランディング] ページに移動します。
- [プロジェクト セレクタ] ボタンをクリックします。
- 表示された [選択元] ダイアログで、プロジェクトを選択します。プロジェクトが見つからないが、プロジェクト ID がわかっている場合は、ブラウザで次の形式の URL を作成できます。
https://console.developers.google.com/auth/branding?project=[PROJECT_ID]
- [ブランディング] ページで、アプリ名、ロゴ、デベロッパーの連絡先情報、関連リンクなど、アプリのブランディング情報を入力します。変更内容はすべてブランディングの下書きとして保存されます。
- [Verify Branding] ボタンをクリックして、評価プロセスを開始します。自動システムによる審査は通常、数分で完了します。
- 評価が完了したら、ステータスを確認します。成功すると、ステータスが [公開準備完了] に変わります。自動確認が失敗した場合は、検出された問題を確認し、修正するか、手動審査をリクエストできます。
- [ブランディングを公開] ボタンをクリックして、新しいブランディングを公開します。
- アプリで機密性の高いスコープや制限付きスコープの確認も必要な場合は、OAuth Verification Center に移動してデータアクセスのステータスを確認し、デモ動画など、リクエストされた追加情報を提供してください。データアクセスの検証をリクエストするには、ブランディングのステータスが公開済みである必要があります。
- [スコープを追加または削除] ボタンを使用して、アプリでリクエストされるすべてのスコープを宣言します。Google ログインに必要なスコープの初期セットは、[機密性の低いスコープ] セクションに事前入力されています。追加されたスコープは、センシティブでないスコープ、センシティブなスコープ、制限付きスコープに分類されます。
- アプリの関連機能に関する関連ドキュメントへのリンクを 3 つまで指定します。
- 以降の手順で、アプリについて求められる追加情報を入力します。
ブランディングを公開するか、データアクセス リクエストを送信すると、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 ドメインの企業アカウントを持つユーザーがいるをご覧ください。