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が表示されます。
gear iconをクリックしてステップの設定を開きます。設定パネルはAsk via webhook（webhook接続）、Response to collect（レビュアーが入力するフィールド）、Wait time（Finがタイムアウトまで待つ時間）の3セクションで構成されています。
Ask via webhookの下でConfigureをクリックします。通知を受け取るwebアドレスである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分で最大はありません。分または時間を選択できます。待機時間超過時にFinが顧客に伝えるメッセージは下の欄で編集可能です。
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つの配信URLがあります。変更すると、Loop in teammate / agentステップを使用するすべてのFin手順のwebhook接続が更新されます。
待機時間が切れて応答がない場合、Finは設定したタイムアウトメッセージを顧客に送信し、手順は終了し会話はエスカレーションされます。
デフォルトのタイムアウトメッセージは「チーム」を指します。公開前に実際の設定に合わせて更新してください。
スタンドアロンHITL webhookとDeveloper Hub APIアプローチの比較
両者はHITLステップで手順を一時停止し、webhookでシステムに通知しますが、設定方法と対象ユーザーが異なります。
スタンドアロンHITL webhook：手順エディターで直接設定。Developer HubアプリやOAuthスコープは不要。ワークスペースごとに1つの配信URL。Fin Standaloneワークスペース専用。スタンドアロン手順のすべてのHITLステップでwebhookチャネルが自動的に有効になります。
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つの配信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ではこのステップで行われた判断の追跡はできません。個別の判断に関するレポートや分析機能はありません。応答のログと追跡は外部システムの責任です。