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 サービスは、リクエストを受信した後、次の要件を満たすレスポンスを送信する必要があります。

  • レスポンスは、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 と統合するために使用できる、事前定義されたカスタム テンプレートが用意されています。

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

Webhook サービスの要件

Webhook サービスは、次の要件を満たす必要があります。

認証

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 トークン [サービス エージェント認証] セクションで ID トークンを選択すると、認証にサービス エージェントの 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 サーバーに渡すことができます。

サービス エージェントの 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 はまた、Google クライアント ライブラリまたは Node.js 用 Google 認証ライブラリなどのオープンソース ライブラリを使用して、必要に応じてトークンを検証できます。

Webhook が 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 を認証するために必要な手順は次のとおりです。

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

HTTPS 証明書の検証

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

環境特有の Webhook

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

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

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

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

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

コンソール

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

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: 未承認
  • 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)システムなど)、ウェブフックのタイムアウトを許容ウィンドウの半分(2.5 ~ 4 秒など)に設定して、両方の試行に予算を割り当てます。

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

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

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

Cloud Run の使用

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

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

  1. 次のアドレスを含む 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
  2. Webhook 関数がエージェントとは異なるプロジェクトにある場合は、Cloud Run リソース プロジェクトの Dialogflow CX サービス エージェント サービス アカウントに Cloud Run 起動元または Cloud Functions 起動元の IAM ロールを付与する必要があります。

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

コンテナ化された 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 を設定するには、次のようにします。

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

  2. 次のアドレスを含む Dialogflow CX サービス エージェントのサービス アカウントが、エージェント プロジェクト用に存在している必要があります。

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

    Service Directory が配置されているプロジェクトの Dialogflow CX サービス エージェント サービス アカウントに、次のロールを付与します。

    • servicedirectory.viewer
    • servicedirectory.pscAuthorizedService

    また、Service Directory が Dialogflow CX エージェントとは異なるプロジェクトにある場合は、Dialogflow CX エージェントをホストするプロジェクトの Dialogflow CX サービス エージェント アカウントに servicedirectory.viewer ロールを付与する必要があります。

  3. Webhook を作成するときに、Service Directory サービス、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 の入門ガイドをご覧ください。