一部のサービスと機能は名前を変更中です。生成ハンドブックとフロー機能も、単一の統合コンソールに移行されます。

Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

Webhook

Webhook は、ビジネスロジックのホストや、他のサービスの呼び出しを行うサービスです。Webhook では、セッション中に Dialogflow の自然言語処理で抽出されたデータを使用することで、動的レスポンスの生成、収集したデータの検証、バックエンドでのアクションのトリガーが可能になります。

Webhook は、標準 Webhook またはフレキシブル Webhook のいずれかになります。標準の Webhook では、リクエストフィールドとレスポンスフィールドは Dialogflow CX によって定義されます。フレキシブル Webhook では、リクエストフィールドとレスポンスフィールドを自分で定義します。

$request.webhook_status_code リクエストパラメータを使用して、Webhook 呼び出しの HTTP ステータスコードにアクセスすることもできます。

標準 Webhook

標準 Webhook では、Dialogflow CX で定義されたリクエストメッセージとレスポンスメッセージを使用します。リクエストメッセージには、セッションに関する多くの詳細情報が含まれています。たとえば、現在のアクティブなページ、最近一致したインテント、セッションパラメータ値、エージェント定義のレスポンスがすべて含まれています。

標準 Webhook リクエスト

Webhook でのフルフィルメントが呼び出されると、Dialogflow CX は Webhook サービスに HTTPS POST Webhook リクエストを送信します。このリクエストの本文は、セッションに関する情報を含む WebhookRequest JSON オブジェクトです。

一部の統合では、WebhookRequest.payload フィールドに追加情報が入力されます。たとえば、Dialogflow CX Phone Gateway の統合では、エンドユーザーの呼び出し元 ID を提供します。

詳しくは、WebhookRequest（V3）または WebhookRequest（V3Beta1）のリファレンスドキュメントをご覧ください。

標準 Webhook レスポンス

Webhook サービスはリクエストを受け取ると、次の要件を満たすレスポンスを送信する必要があります。

応答は設定されたタイムアウト時間内に発生する必要があります。ウェブフックリソースの作成。
レスポンスは 64 KiB 以下にする必要があります。

詳しくは、WebhookResponse（V3）または WebhookResponse（V3Beta1）のリファレンスドキュメントをご覧ください。

標準 Webhook リソース設定

次の表に、標準 Webhook の Webhook リソース設定を示します。

X	項目
表示名	Webhook のコンソールに表示される名前。
Webhook タイムアウト	Dialogflow CX が Webhook サービスに HTTP リクエストを送信するとき、この設定は会話ターン全体ではなく、個々のリクエスト試行のタイムアウト（秒単位）を制御します。試行がタイムアウトした場合や、一時的なエラーで失敗した場合、Dialogflow CX は自動的に 1 回再試行します。この再試行により、エラーが返されるまでの合計ターンアラウンド時間が、構成されたタイムアウト値の 2 倍になることがあります。再試行後にタイムアウトが発生すると、Dialogflow CX によって webhook.error.timeout イベントが呼び出されます。詳細については、自動再試行をご覧ください。
タイプ	プライベートネットワークアクセスに Service Directory を使用する場合は「Service Directory」、それ以外の場合は「Generic Web Service」に設定します。
webhook URL	Webhook サービスの URL アドレスを指定します。
サブタイプ	Standard に設定します。
環境特有の Webhook	環境特有の Webhook を指定できます。
認証	認証セクションをご覧ください。
カスタム CA 証明書	これはカスタム CA 証明書をアップロードするために使用されます。

フレキシブル Webhook

フレキシブル Webhook では、リクエスト HTTP メソッド、リクエスト URL パラメータ、リクエストメッセージとレスポンスメッセージのフィールドを自分で定義します。リクエストは、選択したパラメータ値のみを指定し、レスポンスはパラメータのオーバーライド値のみを指定できます。セッションパラメータ値以外の情報を伝達する必要はほとんどないため、エージェントと Webhook 間のインターフェースが簡素化されます。また、リクエストメッセージとレスポンスメッセージには必要なものだけが含まれ、さまざまなシナリオに一意の Webhook メッセージを指定できるため、Webhook の実装も簡素化されます。

フレキシブル Webhook リクエスト

エージェントの Webhook リソースを作成する際に、Webhook リクエストに対し、以下を指定できます。

Webhook サービスに送信される Webhook リクエストに使用される HTTP メソッド。
Dialogflow CX が URL を使用して Webhook サービスに送信するセッションパラメータ値。
方式として POST、PUT、PATCH のいずれかを選択した場合、リクエストの JSON 本文を通じて Dialogflow CX が Webhook サービスに送信するセッションパラメータ値。

リクエスト URL または JSON 本文を使用してセッションパラメータ値を送信するには、パラメータ参照を使用します。パラメータ参照を URL エスケープしたり、引用符で囲んだりする必要はありません。実行時に、Dialogflow CX は必要に応じてパラメータ値を URL エスケープします。リストまたは複合値は JSON として指定されます。

JSON 本文でパラメータ参照を使用する場合は、パラメータのタイプに関係なく、参照を引用符で囲む必要があります。パラメータが実際に数値スカラー、リスト、複合値である場合、Dialogflow CX は、実行時にリクエストを送信するときに引用符を削除して、パラメータのデータ型を保持します。文字列スカラー型は、引用符で囲まれたままになります。数値スカラー、数値、または複合値が文字列値内で参照されている場合（例: "This is a number: $session.params.size"）、パラメータは文字列として扱われます（"This is a number: 3"）。

たとえば、次のようにして、fruit と size のセッションパラメータ値をリクエスト URL に指定できます。

https://your-webhook-service.com/handler?f=$session.params.fruit&s=$session.params.size

また、次のようにして、リクエスト JSON 本文に指定できます。

{
  "fruitParameter": "$session.params.fruit",
  "sizeParameter": "$session.params.size"
}

フレキシブル Webhook レスポンス

エージェントの Webhook リソースを作成する際に、Dialogflow CX が実行時に Webhook レスポンスの特定のフィールドに設定する必要があるセッションパラメータを指定できます。

回答は次の制限を満たす必要があります。

レスポンスは、Webhook リソースを作成するときに構成したタイムアウト内で実行する必要があります。この制限時間を超えると、リクエストがタイムアウトになります。
レスポンスのサイズは 64 KiB 以下でなければなりません。

スカラーフィールド、リストフィールド、複合フィールドを指定するには、次の形式を使用します。

$.fully.qualified.path.to.field

たとえば、次の JSON レスポンスについて考えてみましょう。

{
  "routes" : [
    {
      "legs" : [
        {
          "distance" : {
            "text" : "2,064 mi",
            "value" : 3321004
          }
        }
      ]
    }
  ]
}

「value」フィールドを指定するには、次のものを使用します。

$.routes[0].legs[0].distance.value

フレキシブル Webhook リソース設定

次の表に、フレキシブル Webhook の Webhook リソース設定を示します。

X	項目
表示名	Webhook のコンソールに表示される名前。
Webhook タイムアウト	Dialogflow CX が Webhook サービスに HTTP リクエストを送信するとき、この設定は会話ターン全体ではなく、個々のリクエスト試行のタイムアウト（秒単位）を制御します。試行がタイムアウトした場合や、一時的なエラーで失敗した場合、Dialogflow CX は自動的に 1 回再試行します。この再試行により、エラーが返されるまでの合計ターンアラウンド時間が、構成されたタイムアウト値の 2 倍になることがあります。再試行後にタイムアウトが発生すると、Dialogflow CX によって webhook.error.timeout イベントが呼び出されます。詳細については、自動再試行をご覧ください。
タイプ	プライベートネットワークアクセスに Service Directory を使用する場合は「Service Directory」、それ以外の場合は「Generic Web Service」に設定します。
webhook URL	Webhook サービスの URL アドレスを指定します。これには、セッションパラメータへの参照を配置することができます。
サブタイプ	[フレキシブル] に設定します。
メソッド	Webhook リクエストの HTTP メソッドを設定します。
リクエストの本文	前述のように、リクエストの JSON 本文を指定します。
レスポンスの構成	前述のように、レスポンスフィールドに設定する必要があるセッションパラメータを指定します。
環境特有の Webhook	環境特有の Webhook を指定できます。
認証	認証セクションをご覧ください。
カスタム CA 証明書	これはカスタム CA 証明書をアップロードするために使用されます。

事前定義されたカスタムテンプレートを使用する

Dialogflow には、柔軟な Webhook を Salesforce CRM と統合するために使用できる、事前定義されたカスタムテンプレートが用意されています。

[管理] タブに移動し、[Webhook] を選択して、[作成] をクリックします。
[サブタイプ] で [フレキシブル] を選択します。
[定義済みのテンプレートを使用して構成] をクリックします。
[統合タイプ] メニューで、[Salesforce] を選択します。
[API 名] メニューで、API 名を選択します。テンプレートは、選択した API 名に基づいて Webhook フォームを自動的に入力します。
1. パラメータに基づいて、必要に応じて次のフィールドを手動で構成します。
  - Webhook URL
  - メソッド
  - リクエストボディ JSON
  - レスポンスの構成
2. 必要な OAuth フィールドは、[認証] セクションでハイライト表示されます。
[保存] をクリックします。

Webhook サービスの要件

ウェブフックサービスは、以下の要件を満たす必要があります。

HTTPS リクエストを処理します。HTTP はサポートされていません。コンピューティングまたはサーバーレスコンピューティングソリューションを使用して Google Cloud で Webhook サービスをホストしている場合は、HTTPS によるサービス提供に関するドキュメントをご覧ください。その他のホスティングオプションについては、ドメインの SSL 証明書を取得するをご覧ください。
Webhook サービス URL が一般公開されていることを確認します。ただし、Cloud Run リソースとしてホストされている場合、または Service Directory Webhook としてアクセスされている場合は除きます。
標準 Webhook またはフレキシブル Webhook セクションで説明されているとおりに、リクエストとレスポンスを処理します。
エージェントが Service Directory のプライベートネットワークアクセスと統合されていない場合、Webhook 呼び出しはサービス境界外となり、VPC Service Controls を有効にするとブロックされます。Service Directory は制限付きエンドポイントをサポートしています。詳細については、Service Directory をご覧ください。

認証

Webhook サービスを保護して、自分または Dialogflow CX エージェントのみがリクエストを作成できるようにします。これは、Webhook リソースを作成または編集するときに構成します。Dialogflow CX は次の認証メカニズムをサポートしています。

X	項目
認証ヘッダー	Webhook の設定では、必要に応じて HTTP ヘッダーの Key-Value ペアを指定できます。指定した場合、Dialogflow CX によって Webhook リクエストに HTTP ヘッダーが追加されます。通常は、`authorization` のキーを持つ単一のペアを指定します。ヘッダー値は、静的レスポンスメッセージの場合と同様に、セッションパラメータ参照とシステム関数の解析をサポートしています。`authorization` ヘッダーに静的認証情報を使用する場合は、Secret Manager を使用して認証情報を指定することをおすすめします。
ユーザー名とパスワードによる基本認証	Webhook の設定では、必要に応じてログインユーザー名とパスワードの値を指定できます。指定された場合、Dialogflow CX は webhook リクエストに認証 HTTP ヘッダーを追加します。このヘッダーの形式は `"authorization: Basic <base 64 encoding of the string username:password>"` です。Secret Manager を使用してユーザー名とパスワードを指定することをおすすめします。
サードパーティの OAuth	Dialogflow CX が OAuth システムからのアクセストークンを交換して認証 HTTP ヘッダーに追加するように、サードパーティの OAuth 構成を指定できます。クライアント認証情報フローのみがサポートされています。Secret Manager を使用してクライアントシークレットを指定することをおすすめします。
サービスエージェントのアクセストークン	販売終了。
サービスアカウント	認証にはサービスアカウントを使用できます。これは、他の Google Cloud API へのアクセスに使用できます。
サービスエージェントの ID トークン	[Service agent authentication] セクションで [ID token] を選択すると、認証にサービスエージェントの ID トークンを使用できます。これにより、Cloud Run リソースにアクセスできます。
相互 TLS 認証	相互 TLS 認証のドキュメントをご覧ください。

サードパーティの OAuth

Dialogflow CX は、サードパーティの OAuth プロバイダからアクセストークンを収集し、Webhook リクエストを行うときに認証 HTTP ヘッダーに追加します。

次の表に、サードパーティ OAuth のリソース設定を示します。

X	項目
クライアント ID	OAuth トークンをリクエストするときに使用するクライアント ID。
クライアントシークレット	OAuth トークンをリクエストするときに使用するシークレット。Secret Manager を使用してクライアントシークレットを指定することをおすすめします。
OAuth エンドポイント URL	OAuth トークンをリクエストするために使用する URL。
OAuth スコープ	OAuth トークンで使用できるスコープのカンマ区切りのリスト。

トークンを受け取るために OAuth エンドポイント URL に送信されるリクエストには、Webhook リクエスト用に構成されたカスタムリクエストヘッダーは含まれません。OAuth エンドポイント URL のクエリ文字列内のパラメータとして、カスタム情報を OAuth サーバーに渡すことができます。

注: 同じ Dialogflow CX エージェント内で同じクライアント ID、エンドポイント URL、スコープを使用する限り、同じ Dialogflow CX サーバーでリクエストが行われ、トークンの有効期限が切れていない限り、Webhook リクエストにサードパーティの OAuth トークンが再利用されます。高可用性を実現するため、エージェントは OAuth トークンキャッシュを共有しない複数の個々のサーバーにデプロイされます。サードパーティ OAuth トークンを使用するソリューションをデプロイする場合は、エージェントがサードパーティ OAuth プロバイダに送信するリクエストの量を管理するために、API プロキシの実装を慎重に検討してください。

サービスエージェントの ID トークン

Dialogflow CX は、Dialogflow CX サービスエージェントを使用して ID トークンを生成できます。このトークンは、Dialogflow CX が Webhook を呼び出すときに認可 HTTP ヘッダーに追加されます。

Cloud Run 起動元ロール（roles/run.invoker）を付与すると、ID トークンを使用して Cloud Run リソースにアクセスできます。

service-agent-project-number@gcp-sa-dialogflow.iam.gserviceaccount.com

Cloud Run リソースが同じリソースプロジェクト内にある場合、これらを呼び出すための追加の Identity and Access Management（IAM）権限は必要ありません。

ID トークンの生成に使用されるオーディエンスは、クエリパラメータを除く webhook URL 全体です。Cloud Run を使用している場合は、この URL が Cloud Run オーディエンスでサポートされていることを確認してください。

たとえば、Webhook URL が次のようになっているとします。

https://myproject.cloudfunctions.net/my-function/method1?query=value

の場合、次の URL をカスタムオーディエンスに含める必要があります。

https://myproject.cloudfunctions.net/my-function/method1

Webhook は、Node.js 用 Google 認証ライブラリなどの Google クライアントライブラリまたはオープンソースライブラリを使用して、必要に応じてトークンを検証することもできます。

ウェブフックが Cloud Run でホストされ、ロードバランサ経由でアクセスされる場合は、ロードバランサの URL をカスタムオーディエンスとして Cloud Run に追加します。カスタムオーディエンスの詳細については、サービスにカスタムオーディエンスを設定するをご覧ください。

サービスアカウント

サービスアカウントは、サポートされている Google API への Webhook リクエストの認証に使用できます。

まだサービスアカウントがない場合は、サービスアカウントを作成します。

サービスアカウントはプリンシパルであるため、他のプリンシパルと同様に、ロールを付与することでプロジェクト内のリソースにアクセスできます。サービスアカウントのメールアドレスは、Webhook リクエストの Authorization ヘッダーで送信されるアクセストークンを生成するために使用されます。

サービスアカウントを使用するように Webhook を構成するには、次の権限が必要です。

roles/iam.serviceAccountUser

トークンを生成するには、Dialogflow サービスエージェントに次の権限が必要です。

roles/iam.serviceAccountTokenCreator

また、サービスアカウントには、Webhook をホストするサービスにアクセスする権限も必要です。

Secret Manager の認証

認証ヘッダー、ユーザー名とパスワードによる基本認証、サードパーティの OAuth を使用する場合は、Secret Manager を使用して認証情報をシークレットとして保存できます。シークレットを使用して Webhook を認証する手順は次のとおりです。

シークレットがない場合は、シークレットを作成します。
新しいシークレットに対する Secret Manager のシークレットアクセサー（roles/secretmanager.secretAccessor）ロールを Dialogflow サービスエージェントに付与します。
認証情報をクリップボードにコピーします。
シークレットに新しいシークレットバージョンを追加し、認証情報をシークレット値として貼り付けます。
- 認証ヘッダーを使用する場合は、Bearer <YOUR_CREDENTIAL> と入力します。
- 基本的なユーザー名とパスワードの認証を使用する場合は、<YOUR_USERNAME>:<YOUR_PASSWORD> と入力します。
- 末尾の改行文字は省略します。
追加したシークレットバージョンの名前をコピーします。名前の形式は projects/<var>PROJECT_ID</var>/secrets/<var>SECRET_ID</var>/versions/<var>VERSION_ID</var> です。
Webhook の編集画面を開きます。
認証設定を構成します。
- 認証ヘッダーを使用する場合は、新しいシークレットバージョンリクエストヘッダーを作成します。[Key] フィールドに「Authorization」と入力し、[Secret version] フィールドにシークレットバージョン名を貼り付けます。
- 基本ユーザー名とパスワード認証の場合は、[基本認証] の [シークレットバージョン] をクリックし、シークレットバージョン名を [シークレットバージョン] フィールドに貼り付けます。
- サードパーティ OAuth を使用する場合は、[サードパーティ OAuth] の [シークレットバージョン] をクリックし、シークレットバージョン名を [シークレットバージョン] フィールドに貼り付けます。
[保存] をクリックします。

HTTPS 証明書の検証

Dialogflow CX はデフォルトで Google のデフォルトのトラストストアを使用して HTTPS 証明書を検証します。Google のデフォルトのトラストストアで認識されない証明書（自己署名証明書やカスタムルート証明書など）を HTTPS サーバーに使用する場合は、カスタム CA 証明書をご覧ください。

環境特有の Webhook

環境を使用して本番環境を開発環境から分離している場合は、Webhook を環境特有に構成できます。Webhook リソースごとに、環境固有の URL と認証の設定を指定できます。

この構成により、Webhook コードの更新を本番環境にデプロイする前に安全に開発してテストできます。

Webhook リソースを作成または編集する

Webhook サービスを実行したら、接続と認証の情報を含むエージェントに Webhook リソースを作成します。Webhook リソースの設定はいつでも編集できます。

Webhook リソースを作成または編集するには:

コンソール

Dialogflow CX コンソールを開きます。
プロジェクトに移動します。
エージェントを選択します。
[管理] タブをクリックします。
[Webhooks] をクリックします。
[作成] をクリックするか、編集する既存の Webhook を選択します。
標準の Webhook リソース設定またはフレキシブル Webhook リソース設定を構成します。
[保存] をクリックします。

API

Webhook リソースの作成については、Webhook タイプの create メソッドをご覧ください。Webhook リソース（環境特有の設定を除く）の編集については、Webhook タイプ用の patch メソッドまたは update メソッドをご覧ください。

Webhook リファレンスのプロトコルとバージョンを選択:

プロトコル	V3	V3beta1
REST	Webhook リソース	Webhook リソース
RPC	Webhook インターフェース	Webhook インターフェース
C++	WebhooksClient	利用できません
C#	WebhooksClient	利用できません
Go	WebhooksClient	利用できません
Java	WebhooksClient	WebhooksClient
Node.js	WebhooksClient	WebhooksClient
PHP	利用不可	利用できません
Python	WebhooksClient	WebhooksClient
Ruby	利用不可	利用できません

Webhook の環境固有の設定を編集する方法については、Environment タイプの patch メソッドまたは update メソッドをご覧ください。

環境リファレンスのプロトコルとバージョンを選択:

プロトコル	V3	V3beta1
REST	環境リソース	環境リソース
RPC	環境インターフェース	環境インターフェース
C++	EnvironmentsClient	利用できません
C#	EnvironmentsClient	利用できません
Go	EnvironmentsClient	利用できません
Java	EnvironmentsClient	EnvironmentsClient
Node.js	EnvironmentsClient	EnvironmentsClient
PHP	利用不可	利用できません
Python	EnvironmentsClient	EnvironmentsClient
Ruby	利用不可	利用できません

Webhook エラー

Webhook サービスで Webhook リクエストの処理中にエラーが発生した場合、Webhook コードは次のいずれかの HTTP ステータスコードを返します。

400: 不正なリクエスト
401: Unauthorized（未承認）
403: 禁止
404: 見つかりません
500: サーバーエラー
503: サービス利用不可

エラー状況が次のいずれかの場合、Dialogflow CX は Webhook エラーまたはタイムアウトの組み込みイベントを呼び出し、通常どおり処理を続けます。

レスポンスのタイムアウトを超過しました。
エラーステータスコードを受信しました。
レスポンスが無効です。
Webhook サービスを利用できません。

インテント検出 API 呼び出しによって Webhook サービス呼び出しがトリガーされた場合、インテント検出レスポンスの queryResult.webhookStatuses フィールドには Webhook ステータスの情報が含まれます。

自動再試行

Dialogflow CX は、特定の Webhook エラーに対してリクエストを自動的に再試行して、堅牢性を高めます。自動再試行はデフォルトで有効になっており、無効にすることはできません。

Dialogflow CX は、リクエストタイムアウト、ネットワーク接続の切断、5xx 範囲の HTTP ステータスコード（500 Server fault や 503 Service unavailable など）など、一時的な障害に対して 1 回の再試行を実行します。HTTP ステータスコード 404 Not found などのクライアントエラーは、再試行なしですぐに失敗します。

累積レイテンシとタイムアウトの予算設定

Dialogflow CX は一時的な障害を 1 回再試行するため、応答しない Webhook エンドポイントがあると、Dialogflow CX がエラーを返すまでに、構成されたタイムアウト値の最大 2 倍の累積ターンアラウンドタイムが発生する可能性があります。たとえば、デフォルトの 5 秒のタイムアウト設定では、応答しないエンドポイントは最初の試行で 5 秒後にタイムアウトし、再試行でさらに 5 秒後にタイムアウトします。これにより、Dialogflow CX が webhook.error.timeout イベントハンドラや sys.no-match-default イベントハンドラなどのエラーハンドラを呼び出すまでに、合計レイテンシが約 10 秒になります。

アーキテクチャに厳格なアップストリームレイテンシ制限がある場合（10 秒のタイムアウトウィンドウの後に通話を終了するテレフォニーシステムや自動音声応答（IVR）システムなど）、Webhook タイムアウトを許容ウィンドウの半分（2.5 ～ 4 秒など）に設定して、両方の試行の予算を立てます。

再試行のベストプラクティス

Webhook サービスで再試行を効果的に処理するには:

重複するリクエストを安全に処理するには、Webhook サービスロジックにべき等性またはリクエストの重複排除を実装します。
Webhook オペレーションが構成されたタイムアウトよりも長くかかる場合は、フォールバックメッセージを含む HTTP ステータスコード 200 OK レスポンスをすぐに返し、長時間実行されるタスクを非同期で処理します。

Cloud Run の使用

Dialogflow CX は Cloud Run と統合されているため、セキュアなサーバーレス Webhook を作成できます。エージェントと同じプロジェクトに存在する Cloud Run リソースを作成する場合は、[サービスエージェント認証] を選択し、認証構成で [ID トークン] を選択して、エージェントが Webhook を安全に呼び出せるようにします。

次の 2 つの状況では、この統合を手動で設定する必要があります。

次のアドレスを含む Dialogflow CX サービスエージェントのサービスアカウントが、エージェントプロジェクト用に存在している必要があります。
```
service-agent-project-number@gcp-sa-dialogflow.iam.gserviceaccount.com
```
この特別なサービスアカウントと関連付けられた鍵は通常、プロジェクトの最初のエージェントを作成するときに自動的に作成されます。2020 年 11 月 1 日より前にエージェントを作成した場合は、この特別なサービスアカウントの作成をトリガーできます。
1. プロジェクトの新しいエージェントを作成します。
2. 次のコマンドを実行します。
```
gcloud beta services identity create --service=dialogflow.googleapis.com --project=agent-project-id
```
Webhook 関数がエージェントとは異なるプロジェクトにある場合は、Cloud Run リソースプロジェクトの Dialogflow CX Service Agent サービスアカウントに Cloud Run 起動元または Cloud Functions 起動元の IAM ロールを提供する必要があります。

次に、[Auth configuration] セクションで [Service Agent Auth > ID Token] を選択します。

コンテナ化された Webhook と Go ezcx フレームワークの使用

Go を使用してコンテナ化された Webhook を実装するには、Go ezcx フレームワークをご覧ください。このフレームワークにより、Webhook の作成に必要な手順の多くが簡素化されます。

内部トラフィック専用の Cloud Run の使用

エージェントが同じプロジェクトまたは同じ VPC Service Controls 境界内にある場合、同じプロジェクトまたは同じ VPC Service Controls 境界内の Virtual Private Cloud（VPC）ネットワークからの内部トラフィックを受け入れるように構成された Cloud Run リソースを Webhook として使用できます。

サービスディレクトリを使用したプライベートネットワークアクセス

Dialogflow CX は Service Directory プライベートネットワークアクセスと統合されたため、VPC ネットワーク内の Webhook ターゲットに接続できます。これにより、トラフィックが Google Cloud ネットワーク内に保持され、IAM と VPC Service Controls が適用されます。

プライベートネットワークをターゲットとする Webhook を設定するには、次のようにします。

サービスディレクトリのプライベートネットワーク構成に従って、VPC ネットワークとサービスディレクトリエンドポイントを構成します。

注: Dialogflow CX は Service Directory の情報を 90 秒間キャッシュに保存します。つまり、Service Directory エンドポイントを更新すると、変更が反映されるまでに 90 秒かかります。
次のアドレスを含む Dialogflow CX サービスエージェントのサービスアカウントが、エージェントプロジェクト用に存在している必要があります。
```
service-agent-project-number@gcp-sa-dialogflow.iam.gserviceaccount.com
```
Service Directory があるプロジェクトの Dialogflow CX サービスエージェントのサービスアカウントに、次のロールを付与します。
- servicedirectory.viewer
- servicedirectory.pscAuthorizedService
さらに、サービスディレクトリが Dialogflow CX エージェントとは別のプロジェクトにある場合は、Dialogflow CX エージェントをホストするプロジェクトで、Dialogflow CX サービスエージェントアカウントにservicedirectory.viewerロールを付与する必要があります。

Webhook の作成時に、サービスディレクトリサービス、URL、オプションの認証情報を指定します。

コンソール

サービスディレクトリ Webhook のスクリーンショット。

API

Webhook タイプの serviceDirectory フィールドをご覧ください。

Webhook リファレンスのプロトコルとバージョンを選択:

プロトコル	V3	V3beta1
REST	Webhook リソース	Webhook リソース
RPC	Webhook インターフェース	Webhook インターフェース
C++	WebhooksClient	利用できません
C#	WebhooksClient	利用できません
Go	WebhooksClient	利用できません
Java	WebhooksClient	WebhooksClient
Node.js	WebhooksClient	WebhooksClient
PHP	利用不可	利用できません
Python	WebhooksClient	WebhooksClient
Ruby	利用不可	利用できません

問題のトラブルシューティングを行う場合、非公開稼働時間チェックを設定することで Service Directory が正しく構成されていることを確認できます。

サンプルとトラブルシューティング

詳細については、Webhook の入門ガイドをご覧ください。

フルフィルメント

生成ツール

Webhook コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

標準 Webhook

標準 Webhook リクエスト

標準 Webhook レスポンス

標準 Webhook リソース設定

フレキシブル Webhook

フレキシブル Webhook リクエスト

フレキシブル Webhook レスポンス

フレキシブル Webhook リソース設定

事前定義されたカスタム テンプレートを使用する

Webhook サービスの要件

認証

サードパーティの OAuth

サービス エージェントの ID トークン

サービス アカウント

Secret Manager の認証

HTTPS 証明書の検証

環境特有の Webhook

Webhook リソースを作成または編集する

コンソール

API

Webhook エラー

自動再試行

累積レイテンシとタイムアウトの予算設定

再試行のベスト プラクティス

Cloud Run の使用

コンテナ化された Webhook と Go ezcx フレームワークの使用

内部トラフィック専用の Cloud Run の使用

サービス ディレクトリを使用したプライベート ネットワーク アクセス

コンソール

API

サンプルとトラブルシューティング

Webhook

事前定義されたカスタムテンプレートを使用する

サービスエージェントの ID トークン

サービスアカウント

再試行のベストプラクティス

サービスディレクトリを使用したプライベートネットワークアクセス