ブランドの確認のためを送信する

Google API にアクセスするすべてのアプリは、Google の API サービスのユーザーデータに関するポリシーで指定されているとおりに、自身の身元と意図を正確に表していることを確認する必要があります。デベロッパーと Google およびアプリの共有ユーザーを保護するために、同意画面とアプリケーションを Google で確認する必要が生じる場合があります。

アプリが以下の条件をすべて満たしている場合は、検証が必要です。

  • Google API Consoleでは、アプリの構成はユーザータイプが [外部] に設定されています。つまり、Google アカウントを持っているユーザーであれば誰でもアプリを使用できます。
  • アプリケーションのロゴまたは表示名を OAuth 同意画面に表示したい。

確認済みのブランド情報を含めると、ユーザーがブランドを認識してアプリへのアクセスを許可する可能性が高まります。また、確認済みのブランド情報があると、ユーザーや Google Workspace 管理者がアカウントにアクセスできるサードパーティ製アプリやサービスを確認する際に、後で取り消しが行われる可能性が低くなります。通常、OAuth 同意画面のブランドの確認プロセスには、確認を申請してから 2 ~ 3 営業日かかります。

ブランド認証の申請を提出しないと、ユーザーがデータのリクエストを信頼しなくなり、ユーザーの承認数が減少し、後で取り消しが増える可能性があります。

同意画面では、誰がデータへのアクセスをリクエストしているのかと、どのような種類のデータへのアクセスがアプリに許可されるのかがユーザーに示されます(図 1 のボックス 2 を参照)。

アプリがブランド確認プロセスを完了して承認されると、権限を付与するアカウントがアプリの ID とユーザーデータのポリシーを明確に理解する可能性が高くなります。この明確な説明により、アカウント所有者が Google アカウント ページで取り消し候補を確認する際に、リクエストを承認してアクセスを維持する可能性が高まります。 Cloud Console の OAuth Branding page で構成したコンテンツは、次のコンポーネントに入力されます。

  1. アプリの名前とロゴ(図 1 のボックス 1 に示すとおり)
  2. ユーザー サポートのメールアドレス(図 1 のボックス 2 に示すように、アプリ名を選択すると表示されます)
  3. プライバシー ポリシーと利用規約へのリンク(図 1 のボックス 3)
番号付きラベルは、承認済みのブランド情報を含むプロジェクトの OAuth 同意画面のさまざまな機能を示しています。
図 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 を使用してデータへのアクセスをリクエストするすべてのアプリは、ブランドの確認を完了するために次の手順を行う必要があります。

  1. アプリが確認要件の例外セクションに記載されているケースに当てはまらないことを確認します。
  2. アプリが、関連付けられている API またはプロダクトのブランディング要件に準拠していることを確認します。たとえば、Google ログイン スコープのブランドの取り扱いガイドラインをご覧ください。
  3. Google Search Console 内で、プロジェクトの承認済みドメインの所有権を確認します。 API Console プロジェクトに関連付けられている Google アカウントをオーナーまたは編集者として使用します。
  4. OAuth 同意画面のすべてのブランディング情報(アプリ名、サポートメール、ホームページの URI、プライバシー ポリシーの URI など)が、アプリのアイデンティティを正確に表していることを確認します。

アプリケーションのホームページの要件

ホームページが次の要件を満たしていることを確認してください。

  • ホームページは一般公開されている必要があり、サイトのログイン ユーザーのみがアクセスできる状態であってはなりません。
  • 審査中のアプリとホームページの関連性が明確である必要があります。
  • Google Play ストアのアプリの掲載情報や Facebook ページへのリンクは、有効なアプリのホームページとは見なされません。

アプリケーション プライバシー ポリシーのリンクの要件

アプリのプライバシー ポリシーが次の要件を満たしていることを確認します。

  • プライバシー ポリシーは、ユーザーが確認できるように、アプリケーションのホームページと同じドメイン内でホストされ、 Google API Consoleの OAuth 同意画面でリンクされている必要があります。ホームページには、アプリの機能の説明と、プライバシー ポリシーおよびオプションの利用規約へのリンクを含める必要があります。
  • プライバシー ポリシーでは、アプリケーションにおける Google のユーザーデータへのアクセス、およびそれらの使用、保存、共有の方法を開示する必要があります。 Google のユーザーデータの使用は、公開しているプライバシー ポリシーで開示されている方法に限定する必要があります。

確認を受けるためのアプリの送信方法

Google Cloud Console プロジェクトは、すべての Cloud Console リソースを整理します。プロジェクトは、プロジェクト オペレーションを実行する権限を持つ一連の関連付けられた Google アカウント、一連の有効な API、これらの API の請求、認証、モニタリングの設定で構成されます。たとえば、プロジェクトには 1 つ以上の OAuth クライアントを含めることができ、それらのクライアントで使用する API を構成したり、ユーザーがアプリへのアクセスを承認する前に表示される OAuth 同意画面を構成したりできます。

OAuth クライアントのいずれかが本番環境に対応していない場合は、確認をリクエストしているプロジェクトから削除することをおすすめします。これは Clients pageで行えます。

確認を送信する手順は次のとおりです。

  1. アプリが Google API の利用規約Google API サービスのユーザーデータに関するポリシーに準拠していることを確認します。
  2. Cloud Consoleで、プロジェクトの関連アカウントのオーナーと編集者のロール、OAuth 同意画面のユーザー サポートのメールアドレスとデベロッパーの連絡先情報を最新の状態に保ちます。これにより、チームの適切なメンバーに新しい要件が通知されます。
  3. Cloud ConsoleOAuth 検証センターに移動します。
  4. [プロジェクト セレクタ] ボタンをクリックします。
  5. 表示された [選択元] ダイアログで、プロジェクトを選択します。プロジェクトが見つからないが、プロジェクト ID がわかっている場合は、ブラウザで次の形式の URL を作成できます。

    https://console.developers.google.com/auth/branding?project=[PROJECT_ID]

    [PROJECT_ID] は、使用するプロジェクト ID に置き換えます。

  6. [アプリを編集] ボタンを選択します。
  7. OAuth 同意画面のページで必要な情報を入力し、[保存して続行] ボタンを選択します。
  8. [スコープを追加または削除] ボタンを使用して、アプリがリクエストするすべてのスコープを宣言します。Google ログインに必要なスコープの初期セットは、[機密性の低いスコープ] セクションに事前入力されています。追加されたスコープは非機密( sensitive, or restricted)として分類されます。
  9. アプリの関連機能に関する関連ドキュメントへのリンクを 3 つまで指定します。
  10. 以降のステップで、アプリに関する追加情報の入力を求められます。

  11. 指定したアプリ構成で検証が必要な場合は、アプリを検証用に送信できます。必須項目に入力し、[送信] をクリックして確認プロセスを開始します。

アプリを送信すると、Google の Trust & Safety チームから、必要な追加情報や完了する必要がある手順についてメールで連絡があります。追加情報の提供のお願いについては、[デベロッパーの連絡先情報] セクションのメールアドレスと OAuth 同意画面のサポート メールアドレスをご確認ください。プロジェクトの OAuth 同意画面ページで、プロジェクトの現在の審査ステータスを確認することもできます。たとえば、回答をお待ちしている間、審査プロセスが一時停止しているかどうかを確認できます。

適格性確認の要件の例外

アプリが以下のセクションで説明するシナリオのいずれかに該当する場合は、審査に提出する必要はありません。

個人的な利用

ユースケースの 1 つは、アプリのユーザーが自分だけの場合や、アプリのユーザーが数人だけで、その全員が個人的に知り合いである場合です。少数のユーザーであれば、未確認アプリの画面をスキップして、個人アカウントにアプリへのアクセス権を付与しても問題ないかもしれません。

開発、テスト、ステージングの各階層で使用されるプロジェクト

Google OAuth 2.0 ポリシーに準拠するため、テスト環境と本番環境に別々のプロジェクトを用意することをおすすめします。Google アカウントを持つすべてのユーザーがアプリを使用できるようにする場合は、アプリの確認を送信することをおすすめします。そのため、アプリが開発、テスト、ステージングの段階にある場合は、確認は必要ありません。

アプリが開発段階またはテスト段階にある場合は、[公開ステータス] をデフォルト設定の [テスト] のままにしておくことができます。この設定は、アプリがまだ開発中であり、テストユーザーのリストに追加されたユーザーのみが利用できることを意味します。アプリの開発またはテストに関与する Google アカウントのリストを管理する必要があります。

テスト中のアプリが Google で確認されていないことを示す警告メッセージ。
図 2. テスター警告画面

サービス所有のデータのみ

アプリがサービス アカウントを使用して独自のデータにのみアクセスし、ユーザーデータ(Google アカウントにリンクされている)にアクセスしない場合は、確認を送信する必要はありません。

サービス アカウントの概要については、Google Cloud のドキュメントのサービス アカウントをご覧ください。サービス アカウントの使用方法については、サーバー間アプリケーションに OAuth 2.0 を使用するをご覧ください。

社内専用

つまり、アプリは Google Workspace または Cloud Identity の組織内のユーザーのみが使用します。プロジェクトは組織が所有している必要があり、その OAuth 同意画面は 内部ユーザータイプ用に構成されている必要があります。この場合、アプリで組織管理者の承認が必要になることがあります。詳細については、Google Workspace に関するその他の考慮事項をご覧ください。

ドメイン全体のインストール

アプリの対象を Google Workspace または Cloud Identity 組織のユーザーのみとし、常にドメイン全体のインストールを使用する場合は、アプリの確認は必要ありません。これは、ドメイン全体のインストールにより、ドメイン管理者がサードパーティ製または内部のアプリケーションにユーザーのデータへのアクセスを許可できるためです。組織の管理者は、ドメイン内で使用するアプリを許可リストに追加できる唯一のアカウントです。

アプリをドメイン全体のインストールにする方法については、FAQ の別の Google Workspace ドメインの企業アカウントを持つユーザーが私のアプリケーションを使用していますをご覧ください。