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

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

アプリが次の条件をすべて満たしている場合は、確認が必要です。

  • Google API Consoleでは、アプリの構成はユーザータイプ [External] に設定されています。これは、Google アカウントを持つすべてのユーザーがアプリを利用できることを意味します。
  • アプリケーションで OAuth 同意画面にロゴまたは表示名を表示させたい場合。

検証済みのブランド情報を含めると、ユーザーがブランドを認識してアプリへのアクセス権を付与する可能性が高まります。検証済みのブランド情報により、ユーザーまたは Google Workspace 管理者がアカウントにアクセスできるサードパーティ製のアプリやサービスを確認した場合の取り消し数も減ります。OAuth 同意画面のブランド確認プロセスには通常、確認のための送信から 2 ~ 3 営業日かかります。

ブランド確認の申請を提出できないと、データ リクエストに対するユーザーの信頼が損なわれ、ユーザー承認の回数が減り、その後の取り消しの増加につながる可能性があります。

図 1 のボックス 2 でハイライト表示されているように、同意画面には、誰がデータへのアクセスをリクエストしているかと、アプリがユーザーに代わってアクセスする必要があるデータの種類が表示されます。

アプリがブランド検証プロセスを通過して承認を受けると、権限を付与したアカウントによって、アプリケーションの ID とユーザーデータに関するポリシーが明確に理解される可能性が高くなります。このように明確に理解しておくと、アカウント所有者が Google アカウント ページで取り消しの可能性を確認する際に、リクエストを承認し、アクセス権を維持する可能性を高めることができます。OAuth Consent Screen page に構成した API Console のコンテンツにより、次のコンポーネントが入力されます。

  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 など)が、アプリの ID を正確に表していることを確認します。

アプリのホームページの要件

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

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

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

アプリのプライバシー ポリシーが以下の要件を満たしていることをご確認ください。

  • プライバシー ポリシーは、アプリケーションのホームページと同じドメイン内でホストされ、 Google API Consoleの OAuth 同意画面にリンクされている必要があります。ホームページには、アプリの機能の説明に加えて、プライバシー ポリシーへのリンクと、任意で利用規約へのリンクを記載する必要があります。
  • アプリが Google のユーザーデータにアクセスする方法、そのデータを使用、保存する方法、または共有する方法を、プライバシー ポリシーで開示する必要があります。 Google ユーザーデータの使用は、公開されているプライバシー ポリシーで開示されている用途に限定する必要があります。

検証を受けるためにアプリを送信する方法

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

本番環境用の準備が完了していない OAuth クライアントがある場合は、確認をリクエストしているプロジェクトから削除することをおすすめします。これは Google API Consoleで行います。

適格性確認のために送信する手順は次のとおりです。

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

    https://console.developers.google.com/apis/credentials/consent?project=[PROJECT_ID]

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

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

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

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

適格性確認の要件の例外

アプリを以下のセクションに記載するシナリオで使用する場合は、審査のために送信する必要はありません。

個人的な利用

1 つのユースケースとしては、アプリのユーザーが 1 人だけの場合や、アプリを使用しているユーザーが個人的に知られている数人のみの場合が挙げられます。デベロッパーもユーザーも限られた人数でも、未確認のアプリ画面を進めて個人アカウントにアプリへのアクセス権を付与しても問題ないかもしれません。

Development、Test、Staging の各階層で使用されるプロジェクト

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 組織のユーザーのみをターゲットにし、常にドメイン全体にインストールする予定の場合、アプリの確認は必要ありません。これは、ドメイン全体にインストールすることで、ドメイン管理者が、ユーザーのデータへのアクセス権をサードパーティおよび内部アプリケーションに付与できるためです。組織管理者のみが、アプリを許可リストに追加してドメイン内で使用できるようになります。

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