概要

統合パスを選択する

ニーズに最適なパスを選択します。

パス	最適な用途	詳細
Universal Commerce Protocol（UCP）	販売者と小売業者。	UCP ドキュメント
標準のアカウントのリンク	スマートホーム、テレビ、YouTube。	Google ドキュメント

アカウントのリンクを使用すると、Google アカウント所有者は迅速、シームレス、安全にサービスに接続できます。Google アカウントのリンクを実装して、プラットフォームのユーザーデータを Google アプリやサービスと共有することもできます。

安全な OAuth 2.0 プロトコルを使用すると、ユーザーの Google アカウントをプラットフォームのアカウントに安全にリンクできるため、Google アプリケーションやデバイスからサービスにアクセスできるようになります。

ユーザーは、アカウントをリンクしたり、リンクを解除したり、あるいは、必要に応じて Google アカウントのリンクを使って、プラットフォームで新しいアカウントを作成したりできます。

ユースケース

Google アカウントのリンクを実装する理由としては、次のようなものがあります。

プラットフォームのユーザーデータを Google アプリやサービスと共有する。
Universal Commerce Protocol（UCP）を使用して、Google ショッピングと AI サーフェス（検索、Gemini）を統合する。
Google TV を使用して動画や映画のコンテンツを再生する。
Google Home アプリと Google アシスタントを使用して、 Google スマートホームのコネクテッドデバイスを管理、制御する（「OK Google, ライトをつけて」）。
会話型アクションを使用して、ユーザーがカスタマイズした Google アシスタントのエクスペリエンスと機能を作成する（「OK Google, いつものスターバックスを注文して」）。
Google アカウントを特典パートナーアカウントにリンクしたユーザーが、YouTube で対象のライブ配信を視聴して特典を獲得できるようにする。
登録時に、 Google アカウントのプロフィールから同意を得て共有されたデータを使用して、新しいアカウントに事前入力する。

機能と要件

次のマトリックスは、各リンクフローのサポートと推奨事項を定義しています。

リンクフロー	標準の機能	UCP の機能
アプリ切り替え	推奨	推奨
合理化されたリンク	推奨	推奨
OAuth リンク	必須（代替）	必須（代替）
OAuth 2.1	推奨	推奨

エージェント型開発（MCP と UCP）

大規模言語モデル（LLM）と AI エージェントでは、ユーザーデータにアクセスするための堅牢な認証が必要です。Google アカウントのリンクは、次のような新しいパラダイムをサポートしています。

Model Context Protocol（MCP）: GAL はセキュリティハンドシェイクとして機能します。エージェントは OAuth 2.1 トークンを使用して、MCP サーバーツールを安全にクエリします。
Universal Commerce Protocol（UCP）: ショッピングエージェントがユーザープロフィールと支払いベクトルに安全にアクセスできるようにします。
必要なデータのみを共有するカスタムスコープを定義してユーザーのプライバシーを強化し、データの使用方法を明確に定義してユーザーの信頼を高めます。
アカウントのリンクを解除すると、プラットフォームでホストされているデータやサービスへのアクセス権を取り消すことができます。オプションのトークン取り消しエンドポイントを実装すると、Google が開始したイベントと同期できます。また、クロスアカウント保護（RISC）を使用すると、プラットフォームで発生したリンク解除イベントを Google に通知できます。

アカウントのリンクフロー

Google アカウントのリンクフローは 3 つあり、すべて OAuth ベースです。OAuth 2.0 準拠の認可エンドポイントとトークン交換エンドポイントを管理または制御する必要があります。

アカウントへの関連付けプロセスでは、アカウント所有者のアカウントをリンクしてデータを共有することへの同意を得た後、個々の Google アカウントのアクセストークンを Google に発行します。

OAuth リンク

これは、リンクのためにユーザーをウェブサイトに送信する OAuth リンクフローです。ユーザーはウェブサイトにリダイレクトされ、アカウントにログインします。ログインすると、ユーザーはサービス上のデータを Google と共有することに同意します。この時点で、ユーザーの Google アカウントとサービスがリンクされます。

OAuth リンクは、認証コードとインプリシット OAuth フローをサポートしています。サービスは、暗黙的フロー用の OAuth 2.0 準拠の認可エンドポイントをホストする必要があります。また、認可コードフローを使用する場合は、認可エンドポイントとトークン交換エンドポイントの両方を公開する必要があります。

図 1 。OAuth リンクを使用したユーザーのスマートフォンでのアカウントのリンク

OAuth ベースのアプリ切り替えリンク（「アプリ切り替え」）

リンクのためにユーザーをアプリ に送信する OAuth フロー。

OAuth ベースのアプリ切り替えリンクは、ユーザーが確認済みの Android または iOS モバイルアプリと Google のプラットフォームの間を移動して、提案されたデータアクセス変更を確認し、プラットフォームのアカウントを Google アカウントにリンクすることに同意する際に、ユーザーをガイドします。アプリ切り替えを有効にするには、サービスが OAuth リンクまたは OAuth ベースの Google でログインのリンクを認可コードフローを使用してサポートしている必要があります。

アプリ切り替えは、Android と iOS の両方でサポートされています。

仕組み:

Google アプリは、ユーザーのデバイスにアプリがインストールされているかどうかを確認します。

アプリが見つかった場合、ユーザーはアプリに「切り替え」られます。アプリは、Google とアカウントをリンクするための同意をユーザーから収集し、Google サーフェスに「切り替え」ます。
アプリが見つからない場合、またはアプリ切り替えアカウントへの関連付け中にエラーが発生した場合、ユーザーは合理化されたリンクフローまたは OAuth リンクフローにリダイレクトされます。

図 2 。アプリ切り替えを使用したユーザーのスマートフォンでのアカウントのリンク

OAuth ベースの合理化されたリンク（「合理化」）

OAuth ベースの Google でログインの合理化されたリンクは、OAuth リンクの上層に Google でログインを追加します。これにより、ユーザーは Google サーフェスを離れることなくアカウントへの関連付けを完了できるため、摩擦や離脱を減らすことができます。 OAuth ベースの合理化されたリンクは、Google でログインと OAuth リンクを組み合わせることで、シームレスなログイン、アカウント作成、アカウントのリンクを実現し、最高のユーザーエクスペリエンスを提供します。サービスは、OAuth 2.0 準拠の認可エンドポイントとトークン交換エンドポイントをサポートする必要があります。また、トークン交換エンドポイントは JSON Web Token（JWT）アサーションをサポートし、 check、 create、および get インテントを実装する必要があります。

仕組み:

Google はユーザーアカウントをアサートし、この情報をデベロッパーに渡します。

データベースにユーザーのアカウントが存在する場合、ユーザーは Google アカウントをサービスのアカウントに正常にリンクします。
データベースにユーザーのアカウントが存在しない場合、ユーザーは Google が提供するアサートされた情報を使用して新しいサードパーティアカウントを作成するか、別のメールアドレスでログインしてリンクすることを選択できます（これには、OAuth リンクを使用してサービスにログインする必要があります）。

図 3 。合理化されたリンクを使用したユーザーのスマートフォンでのアカウントのリンク

どのフローを使用すればよいですか？

すべてのフローを実装して、ユーザーが最適なリンクエクスペリエンスを得られるようにすることをおすすめします。合理化されたフローとアプリ切り替えフローでは、ユーザーが非常に少ない手順でアカウントへの関連付けプロセスを完了できるため、リンクの摩擦が軽減されます。OAuth リンクフローは労力が最も少なく、最初に始めるのに適しています。その後、他のリンクフローを追加できます。

トークンを操作する

Google アカウントのリンクは、OAuth 2.0 業界標準に基づいています。

アカウント所有者のアカウントをリンクしてデータを共有することへの同意を得た後、個々の Google アカウントのアクセストークンを Google に発行します。

トークンの種類

OAuth 2.0 では、トークンと呼ばれる文字列を使用して、ユーザーエージェント、クライアントアプリケーション、OAuth 2.0 サーバー間で通信を行います。

アカウントのリンク時に使用できる OAuth 2.0 トークンには、次の 3 種類があります。

認証コード 。アクセストークンと更新トークンに交換できる有効期間の短いトークン。セキュリティ上の理由から、Google は認証エンドポイントを呼び出して、1 回限りのコードまたは有効期間の非常に短いコードを取得します。
アクセストークン 。ベアラーにリソースへのアクセス権を付与するトークン。このトークンが失われた場合に発生する可能性のある漏洩を制限するため、有効期間は通常 1 時間程度に制限されています。
更新トークン 。アクセストークンの有効期限が切れたときに新しいアクセストークンと交換できる有効期間の長いトークン。サービスが Google と統合されている場合、このトークンは Google によってのみ保存および使用されます。Google はトークン交換エンドポイントを呼び出して、更新トークンをアクセストークンと交換します。このアクセストークンは、ユーザーデータへのアクセスに使用されます。

トークンの処理

クラスタ化された環境やクライアントとサーバー間の交換では、トークンを使用する際に競合状態が発生し、複雑なタイミングとエラー処理のシナリオが生じる可能性があります。次に例を示します。

新しいアクセストークンのリクエストを受け取り、新しいアクセストークンを発行します。同時に、有効期限が切れていない以前のアクセストークンを使用して、サービスのソースへのアクセスを求めるリクエストを受け取ります。
更新トークンの返信が Google に届いていない（または届かない）間に、以前に有効だった更新トークンが Google からのリクエストで使用されます。

リクエストと返信は、クラスタで実行されている非同期サービス、ネットワークの動作などにより、任意の順序で到着したり、まったく到着しなかったりする可能性があります。

Google とデベロッパーのトークン処理システム内およびシステム間で、即時かつ完全に一貫した共有状態を保証することはできません。有効期限が切れていない複数の有効なトークンが、短期間にシステム内またはシステム間で共存する可能性があります。ユーザーへの悪影響を最小限に抑えるため、次のことを行うことをおすすめします。

新しいトークンが発行された後でも、有効期限が切れていないアクセストークンを受け入れる。
更新トークンのローテーションの代替手段を使用する。
複数のアクセストークンと更新トークンを同時に有効にする。セキュリティ上の理由から、トークンの数とトークンの有効期間を制限する必要があります。

メンテナンスと停止の処理

メンテナンス中や計画外の停止中に、Google が認証エンドポイントまたはトークン交換エンドポイントを呼び出してアクセストークンと更新トークンを取得できない場合があります。

エンドポイントは、503 エラーコードと空の本文で応答する必要があります。この場合、Google は失敗したトークン交換リクエストを一定期間再試行します。Google が後で更新トークンとアクセストークンを取得できる場合、失敗したリクエストはユーザーに表示されません。

ユーザーが開始したアクセストークンのリクエストが失敗すると、エラーが表示されます。暗黙的な OAuth 2.0 フローを使用している場合、ユーザーはリンクの失敗を再試行する必要があります。

推奨事項

メンテナンスの影響を最小限に抑えるための解決策は数多くあります。検討すべきオプションをいくつかご紹介します。

既存のサービスを維持し、新しく更新されたサービスにリクエストを限定的にルーティングします。想定どおりの機能が確認されたら、すべてのリクエストを移行します。
メンテナンス期間中のトークンリクエストの数を減らします。
- メンテナンス期間をアクセストークンの有効期間よりも短くします。
- アクセストークンの有効期間を一時的に延長します。
  1. トークンの有効期間をメンテナンス期間よりも長くします。
  2. アクセストークンの有効期間の 2 倍の時間待機して、ユーザーが有効期間の短いトークンを有効期間の長いトークンと交換できるようにします。
  3. メンテナンスを開始します。
  4. トークンリクエストに対して 503 エラーコードと空の本文で応答します。
  5. メンテナンスを終了します。
  6. トークンの有効期間を通常に戻します。

永続的なリンク

永続的なリンクは、安定した統合のためのコア要件です。これにより、一時的なネットワーク障害や定期的な認証情報の更新が発生した場合でも、ユーザーアカウントのリンクが維持されます。

永続的なリンクを実装するには、「スライディングウィンドウ」アプローチを使用します。ローテーションするのではなく、既存の更新トークンの有効期限を延長します（RFC 6749 セクション 6 を参照）。これにより、新しい更新トークンが発行されても Google が正常に受信または保存されない場合に発生する可能性のある競合状態や意図しないリンク解除を防ぐことができます。

Google に登録する

アカウントのリンクを有効にするには、OAuth 2.0 の設定の詳細と認証情報を共有する必要があります。詳しくは、登録をご覧ください。