Loop in teammate / agentステップにより、Finは手順の途中で一時停止し、人間の判断を待ってから続行します。Finは選択した外部システムに通知を送信し、誰かがリクエストを確認し、決定が返されるとFinは中断したところから再開します。
スタンドアロンHITL webhookを使用するタイミング
Loop in teammate / agentステップには主に2つの用途があります:
人間の監督 — Finが進行する前に人間がレビューし承認する必要がある高リスクまたは高価値のアクション向け。例：返金や例外承認、コンプライアンスに敏感なリクエスト（例：アカウント閉鎖、データ削除）、高価値の顧客エスカレーション、善意の対応、またはポリシーで人間の署名が必要な状況。
手順のテスト — まだ構築されていないデータコネクターやバックエンドアクションの代わりに使用。人間が手動でステップを実行し、統合が準備できる前に手順全体のフローをテスト可能。
必要なもの
開始前に以下を確認してください:
少なくとも1つのLoop in teammate / agentステップを含むFin手順
Finからの通知を受信し応答できるURL（webhookエンドポイント）
設定のManage apps and integrations権限
注意：この設定にはサードパーティの開発ツールやアプリ認証情報は不要です。すべて手順エディターで直接設定します。
仕組み
顧客の会話がFin手順のLoop in teammate / agentステップに到達すると:
1. Finが会話を一時停止
一時停止前に、Finは顧客にメッセージを送信し、リクエストがレビュー中であることを知らせることができます。
Finは外部システムに通知を送信します。
Finは応答が受信されるかステップがタイムアウトするまで待機し、続行しません。
2. あなたのシステムが通知を受け取る
あなたのシステムは会話の詳細と判断に必要な情報を含む通知を受け取ります。
人間のレビュアーがリクエストを確認するか、システムが自動ロジックで応答します。
FinがLoop in teammate / agentステップに到達すると、会話の詳細と必要なアクションを含む通知を外部システムに送信します。この例では、レビュアーが2FAリセットリクエストを受け取り、顧客の本人確認を行ってから応答する指示を受けます。
3. 決定が返送される
あなたのシステムが決定をFinに返送します。
4. Finが手順を続行
Finは一時停止した箇所から再開します。
システムからの応答は後続のステップでRead attributeステップを通じて利用可能です。
結果に基づきIF/ELSE条件で分岐可能です。例：承認なら続行、拒否なら顧客にメッセージ送信。
重要：Loop in teammate / agentステップを含む手順はwebhook接続が設定されるまで公開できません。公開前に設定完了を促されます。
ステップ1：ステップの追加と設定
Train > Procedureに移動し、ステップを追加したい手順を開きます。
指示ブロックで@を入力し、Loop in teammate / agentを選択します。
ステップが手順エディターに表示されます。設定パネルで定義された応答フィールド数を示すCollectカウントと、Finが待機する時間を示すWait timeが表示されます。
設定を開くには歯車アイコンをクリック。設定パネルはAsk via webhook（webhook接続）、Response to collect（レビュアーが入力するフィールド）、Wait time（Finがタイムアウトまで待つ時間）の3セクションで構成。
Ask via webhookでConfigureをクリック。通知送信先のDelivery URLを入力し、Saveをクリックします。
Loop in teammate / agent webhookモーダルは接続後に開発者認証情報を表示します。
Response to collectで+ Addをクリックし、レビュアーが入力するフィールドを定義します。各フィールドにフォーマットと名前を付けます。例：'Rejection reason'テキストフィールドや'Approved'ブール値。
各応答フィールドはdropdown、text、boolean（true/false）のフォーマット、名前、任意の説明を持ちます。teammateがループインされると、会話上でこれらのフィールドに直接入力します。
Wait timeで、Finが応答を待つ時間を設定します。最小は1分で最大はありません。分または時間を選択可能。待機時間超過時に顧客に表示するメッセージは下の文を編集してください。
Procedureを保存します。ステップ2に進み、開発者認証情報を取得してください。webhook接続が設定されるまで手順は公開できません。
注意：Loop in teammate / agentステップのwebhook配信は唯一の配信チャネルであり、Inboxやチームへのルーティングオプションはありません。
ステップ2：開発者認証情報の取得
Loop in teammate / agent webhookモーダルでDelivery URLを保存すると、Webhook connectedが表示され、開発者に必要な3つの認証情報が明示されます。Not configuredと表示される場合は、Delivery URLが保存されているか、以前発行されたアクセストークンが期限切れまたは取り消されていないか確認してください。取り消されたトークンはFin手順の公開も妨げます。
Access token — システムがFinに返す応答を認証します。
Signing secret — 受信通知がIntercomからの正当なものであることを確認します。
Example callback URL — 会話ごとに生成される一意のURL。システムはレビュアーの決定をこのURLにPOSTして手順を再開します。
注意：これらの認証情報は、ステップ設定パネルのAsk via webhookセクションのConfigureをクリックするといつでも確認できます。Manage apps and integrations権限を持つteammateのみがこのダイアログを開けます。権限がないteammateは権限要求のプロンプトが表示されます。
ステップ3：webhookペイロードの処理
モーダルにWebhook connectedが表示されたら、Loop in teammate / agent webhookモーダルのAccess token、Signing secret、Example callback URLを統合を構築する開発者に共有します。開発者は以下のエンドポイントを構築します:
ステップ到達時にFinから通知を受け取る
リクエストをレビュアーに提示するか、自動ロジックを適用する
決定を返送し、Finが続行できるようにする
Webhookペイロード
手順がLoop in teammate / agentステップに到達すると、IntercomはDelivery URLにPOSTリクエストを送信します。ペイロードには以下が含まれます:
会話ID
Finが尋ねている質問
システムが入力すべき属性
応答を送信するためのコールバックURL
コンテキストのための最近の会話メッセージ
完全なペイロードとフィールド仕様、コールバックリクエスト形式、認証詳細、サポートされるデータ型、エラーコードについては、procedures APIリファレンスを参照してください。
スタンドアロンHITL webhookのテスト方法
Simulations（手順エディター内の自動テスト実行）を使い、実際のwebhook通知をトリガーせずにLoop in teammate / agentステップをテストします。
手順のシミュレーションを開き、Teammate input available to Finセクションを探します。レビュアーからの期待値（例：Approved: true）を追加し、シミュレーションを実行します。Finはシステムが応答したかのようにこれらの値を使用します。
注意：値を追加せずに実行すると、Finはステップをタイムアウト扱いにします。
制限事項
ワークスペースごとに1つのDelivery URLがあります。変更すると、Loop in teammate / agentステップを使用するすべてのFin手順のwebhook接続が更新されます。
待機時間が切れて応答がない場合、Finは設定したタイムアウトメッセージを顧客に送信し、手順は終了し会話はエスカレーションされます。
デフォルトのタイムアウトメッセージは「チーム」を指します。公開前に実際の設定に合わせて更新してください。
スタンドアロンHITL webhookとDeveloper Hub APIアプローチの比較
両者はHITLステップで手順を一時停止し、webhookでシステムに通知しますが、設定方法と対象ユーザーが異なります:
スタンドアロンHITL webhook：手順エディターで直接設定。Developer HubアプリやOAuthスコープ不要。ワークスペースごとに1つのDelivery URL。Finスタンドアロンワークスペース専用。webhookチャネルはスタンドアロン手順のすべてのHITLステップで自動有効化。
Developer Hub APIアプローチ：Developer Hubアプリ、Preview APIバージョン、read_conversationsおよびwrite_conversations OAuthスコープが必要。ステップごとに有効化し、Intercom InboxやSlackチャネルと併用可能。非スタンドアロンワークスペース向け。詳細はHuman-in-the-loop approvals via APIを参照。
顧客視点では両アプローチとも目立たず、システムが応答すると会話は中断なく続行します。
よくある質問
異なる手順で異なるwebhook URLを使えますか？
異なる手順で異なるwebhook URLを使えますか？
異なる手順で異なるwebhook URLは使えません。ワークスペースごとに1つのDelivery URLがあります。Loop in teammate / agentステップを使うすべてのFin手順は同じエンドポイントに通知を送ります。手順ごとにルーティングを変えたい場合は、通知に含まれる詳細を基に外部システムで処理してください。
応答を待つ間、顧客はどうなりますか？
応答を待つ間、顧客はどうなりますか？
応答待ち中、Finは会話を静かに一時停止します（待機メッセージを追加していない場合）。これはステップ設定のWait timeで設定可能です。例：「リクエストを確認中です。まもなくご連絡します。」応答が時間内にない場合、設定したタイムアウトメッセージが送信され、手順は終了し会話はエスカレーションされます。
同じ手順に複数のLoop in teammate / agentステップを追加できますか？
同じ手順に複数のLoop in teammate / agentステップを追加できますか？
はい、同じ手順に複数のLoop in teammate / agentステップを追加可能です。複数ステップで異なるポイントで人間の入力を収集できます。すべてのステップは同じワークスペースのwebhook接続を共有します。
設定後にDelivery URLを変更できますか？
設定後にDelivery URLを変更できますか？
はい、設定後にDelivery URLを変更可能です。ステップ設定パネルのAsk via webhookセクションでConfigureをクリックし、新しいURLを入力してください。変更すると、このステップを使うすべてのFin手順のwebhook接続が更新されます。
どの決定が行われたか追跡できますか？
どの決定が行われたか追跡できますか？
Intercomではこのステップで行われた決定の追跡はできません。個別の決定に関するレポートや分析機能はありません。応答のログと追跡は外部システムの責任です。