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