会話型アクションのサポートは 2023 年 6 月 13 日に終了しました。詳細については、
会話型アクションの廃止をご覧ください。
アカウント リンクタイプを選択する（Dialogflow）
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
アクションに最適なアカウント リンクタイプは、ユーザー エクスペリエンスが最もシンプルで、アプリケーションやビジネスのニーズに適合するタイプです。リンクタイプの選択は、主に次の要因によって決まります。
- 音声によるアカウントの作成を許可するかどうか
- ユーザーが Google 以外のアカウントでサービスにログインできるようにするかどうか
- サービスが機密情報（クライアント シークレット）を保存できるかどうか
理想的なアカウントのリンクの種類を判断する手順は次のとおりです。
- 優先するログインタイプを特定するセクションの質問を検討してください。
- ディシジョン ツリーを参照して、リンクタイプを選択してください。
- 選択した最初のタイプに対応するセクションに移動して、動作をさらに絞り込みます。
使用するログインタイプを指定する
ディシジョン ツリーを参照する前に、以下の点について検討してください。
- すべてのユーザーが Google アカウントを持っていると思いますか？
- アクションのターゲットがアシスタントのみの場合、すべてのユーザーが Google アカウントを持っていると考えられます。アクションがアシスタント以外のプラットフォームをターゲットにしている場合、すべてのユーザーが Google アカウントを持つとは限りません。
- サービスにすでにユーザーがいる場合、一部のユーザーは Google アカウントを持っていないか、Google アカウントでサービスにログインしていない可能性があります。
- OAuth を実装している場合、Google プロトコルをサポートするように拡張できますか？
- Google プロトコルをサポートするには、トークン交換エンドポイントに
intent=get 機能と intent=create 機能を追加できる必要があります。この機能により、Google はユーザーがバックエンドにすでに存在するかどうかを確認し、サービスで新しいアカウントを作成するようにリクエストできます。
以下のディシジョン ツリーに沿って、自分とユーザーにとって最適なアカウント リンクのタイプを特定します。
リンクタイプを選択したら、以下の対応するセクションに進んで仕組みの詳細を確認し、アクションでのアカウントのリンクの仕組みを決定します。
OAuth と Google ログイン
OAuth と Google ログイン（GSI）のリンクタイプは、OAuth ベースのアカウント リンクに加えて GSI を追加します。これにより、GSI の利点（Google ユーザー向けの音声ベースのリンクなど）がもたらされるとともに、Google 以外のアカウントでサービスに登録したユーザーもアカウント リンクが可能になります。このリンクタイプは、Google ユーザーにとっては負担の少ないフローで、Google 以外のユーザーもフォールバックできます。そのため、このリンクタイプはエンドユーザーにとって特にメリットがあります。OAuth と GSI のリンクタイプの仕組みについては、OAuth と Google ログインのコンセプト ガイドをご覧ください。
OAuth と Google ログインのリンクタイプを絞り込む
アクションで OAuth と GSI のアカウント リンクタイプを使用する場合は、Actions Console で以下の質問への回答を指定して、その動作を定義します。
ウェブサイトでのアカウントの作成のみを許可しますか？
通常は、音声によるアカウント作成を有効にして、審査されていないデバイスのユーザーが別のデバイスに転送しなくてもアカウントを作成できるようにしてください。音声によるアカウントの作成を許可しない場合、アシスタントはユーザー認証用に指定したウェブサイトの URL を開き、ユーザーをスマートフォンに誘導して、アカウントのリンクフローを続行します。
ただし、次のいずれかに該当する場合は、音声によるアカウントの作成を許可しないでください。
- アカウント作成フローを完全に制御する必要がある。たとえば、アカウントの作成時やその他の種類の通知の際に、利用規約をユーザーに表示する必要があります。
- すでにアカウントを持っているユーザーがそのアカウントでログインするようにします。たとえば、ポイント プログラムを提供していて、アカウントで獲得したポイントが失われないようにするには、ユーザーが既存のアカウントを引き続き使用できるようにすることをおすすめします。
認可コードフローと暗黙的フローのどちらを使用するか
認可コードフローと暗黙的フローは、認可コードフローが 2 つ目のエンドポイント（トークン交換エンドポイント）を必要とする点で異なります。このエンドポイントは、更新トークンを使用して、ユーザーに再ログインを要求せずに有効期間の短い新しいアクセス トークンを生成します。
逆に、暗黙的フローを使用すると、有効期間の長いアクセス トークンが Google に返されますが、通常は再生成する必要はありません。認証コードと暗黙的フローの詳細については、OAuth と Google ログインのコンセプト ガイドをご覧ください。
アクションはより安全であるため、認可コードフローを使用することをおすすめします。ただし、サービスで機密情報（クライアント シークレット）を保存できない場合は、代わりに暗黙的フローを使用してください。たとえば、シングルページ アプリケーション（SPA）などの公開クライアントには、暗黙的フローを使用する必要があります。
上記の決定ポイントを検討したら、次のディシジョン ツリーを参照してください。
Google ログイン
GSI リンクタイプでは、アクションは会話中にユーザーの Google プロフィールへのアクセスをリクエストし、プロフィール情報を使用して、ユーザーがサービスのバックエンドに存在するかどうかを確認できます。ユーザーが存在しない場合は、Google プロフィール情報を使用してシステムに新しいアカウントを作成できます。
GSI では、音声によるアカウントの作成を有効にする必要があります。これにより、ユーザーは音声でフローを完了できるようになります。GSI について詳しくは、Google ログインのコンセプト ガイドをご覧ください。
OAuth
OAuth リンクタイプの場合、ユーザーは標準の OAuth 2 フローでログインします。OAuth リンクタイプは、業界標準の OAuth 2.0 フロー（暗黙的なコードフローと認可コードフロー）の 2 つをサポートしています。
OAuth リンクタイプ自体はおすすめしません。ユーザーがスクリーニングされていないデバイスを使用している場合、ログイン プロセスを完了するために、ユーザーを音声から画面へ転送する必要があるためです。OAuth 2 サーバーの既存の実装があり、ID トークンからの自動リンクとアカウント作成のための Google のプロトコルをサポートするようにトークン交換エンドポイントを拡張できない場合は、このフローの使用を検討してください。詳細については、OAuth のコンセプト ガイドをご覧ください。
フローを改善する
アクションで OAuth アカウント リンクタイプを使用する場合は、Actions Console で次の質問への回答を指定して、その動作を定義する必要があります。
認可コードフローと暗黙的フローのどちらを使用するか
OAuth リンクタイプは、業界標準の OAuth 2.0 フロー（暗黙的なコードフローと認可コードフロー）の 2 つをサポートしています。認可コードフローと暗黙的フローでは、認可コードフローでは 2 つ目のエンドポイントであるトークン交換エンドポイントが必要になります。このエンドポイントは、更新トークンを使用して、ユーザーに再ログインを要求せずに有効期間の短い新しいアクセス トークンを生成します。
逆に、暗黙的フローを使用すると、有効期間の長いアクセス トークンが Google に返されますが、通常は再生成する必要はありません。認可コードと暗黙的フローの詳細については、OAuth のコンセプト ガイドをご覧ください。
アクションはより安全であるため、認可コードフローを使用することをおすすめします。ただし、サービスで機密情報（クライアント シークレット）を保存できない場合は、代わりに暗黙的フローを使用してください。たとえば、シングルページ アプリケーション（SPA）などの公開クライアントには、暗黙的フローを使用する必要があります。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-07-26 UTC。
[null,null,["最終更新日 2025-07-26 UTC。"],[[["\u003cp\u003eThis guide helps you choose the best account linking type for your Google Action based on factors like user experience and security needs.\u003c/p\u003e\n"],["\u003cp\u003eThree main linking types are discussed: OAuth and Google Sign-In (recommended), Google Sign-In, and OAuth.\u003c/p\u003e\n"],["\u003cp\u003eEach type has different features and considerations, such as whether to allow voice account creation or use authorization code versus implicit flow.\u003c/p\u003e\n"],["\u003cp\u003eDecision trees and further details are provided to refine your chosen linking type for optimal implementation within your Action.\u003c/p\u003e\n"],["\u003cp\u003eOAuth and Google Sign-In offer a combined approach for both Google and non-Google user accounts, providing a smoother experience.\u003c/p\u003e\n"]]],[],null,["# Choose your account linking type (Dialogflow)\n\nThe optimal account linking type for your Action is one that provides the\nsimplest experience for your users and fits the needs of your application or\nbusiness. Choosing your linking type is mostly dependent on the following\nfactors:\n\n- Whether you want to allow account creation via voice\n- Whether you want users to be able to sign in to your service with a non-Google account\n- Whether or not your service can store confidential information (i.e., a client secret)\n\nTo figure out your ideal account linking type, follow these steps:\n\n1. Consider the questions in the [Identify your preferred sign-in type](#identify_your_preferred_sign-in_type) section.\n2. Consult the decision tree to choose your linking type.\n3. Navigate to the section that corresponds to the initial type you chose to further refine how it works.\n\nIdentify your preferred sign-in type\n------------------------------------\n\nBefore you consult the decision tree, consider the following questions:\n\n- **Do you expect all your users to have a Google account?**\n - If your Action only targets the Assistant, then you can expect all your users to have a Google account. If your Action targets platforms beyond the Assistant, you cannot expect all your users to have a Google account.\n - If your service already has existing users, it's likely that some don't have a Google account or didn't sign into your service with a Google account.\n- **If you have an OAuth implementation, can it be extended to support Google\n protocol?**\n - To support Google protocol, you need to be able to add the `intent=get` and `intent=create` functionality to your token exchange endpoint. This functionality allows Google to check if the user already exists in your backend and make a request to create a new account on your service, respectively.\n\nFollow the decision tree below to identify the account linking type that's\noptimal for you and your users:\n\nOnce you select a linking type, continue to the corresponding section\nbelow to learn more about how it works and make further decisions about how\naccount linking works in your Action.\n\n### OAuth and Google Sign-In\n\nThe OAuth and Google Sign-In (GSI) linking type adds GSI on top of OAuth-based\naccount linking, which provides the benefits of GSI (for example, voice-based\nlinking for Google users) while also enabling account linking for users who\nregistered to your service with a non-Google account. This linking type is\nespecially advantageous for end users because it provides a low-friction flow\nfor Google users with a fallback for non-Google users. For more information\nabout how the OAuth and GSI linking type works, see the\n[OAuth and Google Sign-In concept guide](/assistant/df-asdk/identity/gsi-oauth-concept-guide).\n\n#### Refine the OAuth and Google Sign-In linking type\n\nWhen you use the OAuth and GSI account linking type in your Action, you specify\nthe answers to the following questions in the Actions console to define how\nit works:\n\n1. **Do you want to enable voice account creation or only allow account\n creation on your website?**\n\n Generally, you should enable account creation via voice so that\n users on a non-screened device can create an account without having to\n transfer to another device. If you do not allow account creation via voice, the\n Assistant opens the URL to the web site that you provided for user\n authentication and directs the user to a phone to continue the account\n linking flow.\n\n However, you should not allow account creation via voice if any of the\n following applies:\n 1. *You need full control of the account creation flow.* For example, you may need to show your terms of service to the user during account creation or some other type of notice.\n 2. *You want to ensure that users who already have an account with you\n sign in with that account.* For example, you may want users to continue using their existing accounts if you offer a loyalty program and don't want the user to lose the points accrued on their account.\n2. **Do you want to use the authorization code flow or implicit flow?**\n\n The authorization code flow and implicit flow differ in that the\n authorization code flow requires a second endpoint, the *token exchange*\n endpoint. This endpoint uses *refresh tokens* to generate new, short-lived\n access tokens without prompting the user to sign in again.\n\n Conversely, if you use the implicit flow, you return a long-lived access\n token to Google that usually does not need to be re-generated. For more\n information about the authorization code and implicit flows, see the\n [OAuth and Google Sign-In concept guide](/assistant/df-asdk/identity/gsi-oauth-concept-guide).\n\n Google recommends using the **authorization code flow** in your Action\n because it is more secure. However, use the **implicit flow** instead if\n your service can't store confidential information (i.e., a client secret).\n For example, you must use the implicit flow for public clients like\n single-page applications (SPAs).\n\nAfter considering these decision points, consult the following decision tree:\n\n### Google Sign-In\n\nWith the GSI linking type, your Action can request access to your user's Google\nprofile during a conversation and use the profile information to check if the\nuser exists in your service's backend. If the user doesn't exist, they can\ncreate a new account in your system using their Google profile information.\n\nFor GSI, you must enable account creation via voice, which lets the user\ncomplete the entire flow over voice. For more information about GSI, see the\n[Google Sign-In concept guide](/assistant/df-asdk/identity/gsi-concept-guide).\n\n### OAuth\n\nWith the OAuth linking type, the user signs in with the standard OAuth 2 flow.\nThe OAuth linking type supports two industry-standard OAuth 2.0 flows:\nthe *implicit* and *authorization* code flows.\n\nGoogle does not recommend the OAuth linking type by itself because it requires transferring\nthe user from voice to screen to complete the sign-in process if the user is on\na non-screened device. You can consider using this flow if you have an existing\nimplementation of an OAuth 2 server, and you cannot extend the token exchange\nendpoint to add support for Google's protocols for automatic linking and\naccount creation from an ID token. For more information, see the\n[OAuth concept guide](/assistant/df-asdk/identity/oauth-concept-guide).\n\n#### Refine the flow\n\nWhen you use the OAuth account linking type in your Action, you must\nspecify the answer to the following question in the Actions console to define\nhow it works:\n\n1. **Do you want to use the authorization code flow or implicit flow?**\n\n The OAuth linking type supports two industry-standard OAuth 2.0 flows:\n the *implicit* and *authorization* code flows. The authorization code flow\n and implicit flow differ in that the authorization code flow requires a\n second endpoint, the *token exchange* endpoint. This endpoint uses\n *refresh tokens* to generate new, short-lived access tokens without prompting\n the user to sign in again.\n\n Conversely, if you use the implicit flow, you return a long-lived access\n token to Google that usually does not need to be re-generated. For more\n information about the authorization code and implicit flows, see the\n [OAuth concept guide](/assistant/df-asdk/identity/oauth-concept-guide).\n\n Google recommends using the **authorization code flow** in your Action\n because it is more secure. However, use the **implicit flow** instead if\n your service can't store confidential information (i.e., a client secret).\n For example, you must use the implicit flow for public clients like\n single-page applications (SPAs)."]]
