HTTP Request
HTTP Request は、会話の途中で外部システムと構造化データをやり取りしたいときに使います。
Consultation Desk の例では、最初から必須ではありません。まず front-door の routing が安定してから、「今この外部アクションを実行したい」と明確に言える段階で追加します。
よくある使い方:
- callback に同意したユーザーの lead を CRM に作成する
- 予約システムの空き枠を確認する
- 確定した intake 情報を内部 workflow に送る
HTTP Request が向いている場面
適している:
- 外部システムに安定した HTTPS endpoint がある
- 必要なのが構造化された request / response である
- いつ呼び出すべきかを明確に説明できる
適していない:
- 情報を
Knowledge Baseに整理すべき場合 - API 契約がまだ固まっていない場合
- 送信前に人の確認が必要な場合
手順 1: 何をする request なのかを 1 つに絞る
まずは business action を 1 つに絞ります。
良い例:
Create Callback LeadCheck Appointment Availability
弱い例:
CRM Integration
1 つのツールで 1 つの仕事にした方が、汎用 request よりもテストとデバッグがしやすくなります。
手順 2: HTTP Request を追加する
Editor の Tools で Add Tool を押し、HTTP Request を選びます。
Display Name には技術用語ではなく、運用上の動作名を書いてください。後から設定を見返したときに、このツールの役割がすぐわかります。
手順 3: Method と URL を先に決める
まず HTTP Method と Request URL を設定します。
- URL は
https://を使います - URL にユーザー識別子が必要な場合は
{{user.email}}、{{user.id}}、{{user.external_id}}を使えます
endpoint も具体的にします。callback lead を作るなら、その専用 endpoint に向ける方が安全です。
手順 4: 本当に必要な認証と payload だけを入れる
次に endpoint が本当に必要とする項目だけを設定します。
AuthenticationHeadersQuery ParametersRequest Body（UI ModeまたはText Mode）
payload は小さく保ちます。下流システムで使わない項目まで送らないようにしてください。
手順 5: When to Use を狭く書く
API の設定だけでなく、いつ呼ぶかのルールも同じくらい重要です。
例:
Use this request only after the user agrees to a human callback and you have collected their preferred contact details. Send the callback request to the CRM so the operations team can follow up.
この書き方が良いのは、次の 3 点が揃っているからです。
- 会話のどの段階で呼ぶか
- その時点で何が揃っているべきか
- 外部 request の運用目的
手順 6: 発火する経路と発火しない経路を両方試す
発火する例:
はい、明日の午後に折り返しをお願いします。
発火しない例:
まだ比較中です。
確認すること:
- 意図した経路でだけ request が走るか
- payload に想定した項目だけが入っているか
- 次のステップが決まる前にデータを送っていないか
運用のコツ
- 1 request = 1 business action を基本にする
- ツール名は API ベンダー名ではなく動作名にする
When to Useと payload の前提を揃える- 不可逆または高リスクな action は、早すぎる自動送信ではなく人の確認を残す
よくある間違い
HTTP Request を何でも屋にしてしまう
目的と契約が曖昧な request は壊れやすくなります。
flow が固まる前に外部送信してしまう
ユーザーがまだ検討中なら、外部システムを呼ぶべきではありません。
使うかどうかわからない項目まで全部送る
項目を増やしても integration は賢くなりません。デバッグが難しくなるだけです。