Fin Procedureが期待通りに会話を解決しない場合、組み込みの検査ツールを使ってFinの意思決定ロジックを調査できます。このガイドを使い、フローが逸れた箇所と指示の改善方法を特定しましょう。
学べること
Finの思考と会話イベントを使ってProcedureの失敗をデバッグします。
誤ったProcedureトリガー、順序外のステップ、分岐失敗などの一般的な問題を診断します。
認証失敗やデータ欠落を含むData connectorのエラーをトラブルシュートします。
シミュレーションを使って本番前に修正を検証します。
会話デバッガーへのアクセス方法
Finが特定のアクションを取った理由を理解するには、まず会話スレッド内で技術的な可視性を有効にする必要があります。
特定の会話をInboxで開きます。
会話ヘッダー右上の三点アイコンをクリックします。
会話イベントを表示を選択します。
ヒント: キーボードショートカット⌘ + E（Mac）またはCtrl + Shift + E（Windows）でこの表示を切り替えられます。
「Finの思考」の検査
会話イベントが表示されると、Procedure中にFinが取った各ステップの理由が見えます。Finの意思決定プロセスを追跡するには、会話タイムラインのFinの思考イベントを探してください。これらのイベントはFinがメッセージ送信やアクション実行前に考えた内容を要約しています。
より詳細を見るには、Fin Thoughtsをクリックし、もっと見るをクリックします。これにより以下が表示されます:
現在のステップ: Finが実行していた特定のProcedureステップ。
意図の解釈: Finが顧客のリクエストをどのように理解したか。
ロジックパス: Finがステップをスキップしたり、前のステップに戻ったり、特定の分岐に進んだ理由。
重要: 本記事はFin Proceduresのトラブルシューティングのみを扱います。「Finの思考」タイムラインとデバッガーはProcedureがトリガーされた場合のみ利用可能です。標準会話でFinが予期しない回答をした場合、これらのツールは会話イベントに表示されません。
一般的なProcedureの失敗
Finが期待通りに動作しない場合、多くは指示の表現やロジックの分岐方法に原因があります。
Procedureが全くトリガーされない
以下の番号付き失敗を確認する前に、まず基本を確認してください:
Procedureが公開されているか確認: 下書きのProcedureは顧客にトリガーされません。エディターでステータスがPublishedになっていることを確認してください。
Simple Deployが有効か確認: Simple Deployがオフの場合、FinはProcedureを実行しません。Fin AI Agent > Deploy > ChatでFinが有効になっているか確認してください。
ターゲットオーディエンスを確認: 一般的なミスは、顧客がLeadなのにUsersをターゲットにしていること（またはその逆）です。「When to use this procedure」セクションでオーディエンスボタンをクリックし、正しいオーディエンスタイプとチャネルが選択されているか確認してください。
優先度の高いworkflowsがないか確認: アクティブなworkflowsはFinがProcedureの意図を評価する前に実行されます。workflowsを見直し、FinがProcedureをトリガーする前に会話を妨げているものがないか確認してください。
トリガー条件の範囲を見直す: 条件が狭すぎるとFinが有効な顧客メッセージにマッチしません。「When to use this procedure」の説明を確認し、トリガーすべきメッセージ（ポジティブ例）とトリガーすべきでないメッセージ（ネガティブ例）を追加してください。
注意: Slackは選択可能なチャネルとして表示されることがありますが、Procedureトリガーは現在Slack会話ではサポートされていません。
1. Finが誤ったProcedureをトリガーする
問題: Finが顧客のリクエストに合わないProcedureを開始します。
解決策: 「When to use this procedure」の指示を見直してください。ポジティブ例とネガティブ例を使い、Finが似た意図を区別できるようにします。新しいProcedureが既存の公開Procedureと似たトリガー条件を共有する場合、公開済みの方が優先されることがあります。テスト中に新しいProcedureを分離するには、既存Procedureのオーディエンス条件を調整してテストユーザーを除外するか、新Procedureのトリガーをあなただけが送るユニークなフレーズに絞ってください。会話デバッガーのFin's thoughts > Expand thoughtsで実際にどのProcedureが起動したか確認できます。
2. ステップの順序がずれている
問題: Finが前提条件のステップをスキップしたり、早すぎる解決に進んだりします。
解決策: 自然言語の指示に曖昧さがないか確認してください。特定のデータに依存するステップがある場合、「[データ]が提供された場合のみ進む」と明確に指示してください。
3. 分岐ロジックの失敗
問題: Finが「Else」の経路をたどるべきところを「If」の経路に進みました。
解決策: 条件を検査してください。自然言語で分岐している場合は、明確に言い換えてみてください。複雑なロジック（例：日付計算）には、Pythonコードブロックを使い厳密な決定ルールを適用することを検討してください。
4. Help Centerコンテンツが優先される
問題: 顧客の意図がProcedureのトリガー条件に明確に合致しているのに、FinがProcedureを実行せずHelp Centerから回答しています。
解決策: FinがProcedureを実行せずHelp Centerの回答を優先する場合、設定に応じて2つの方法があります。まずオプション1を試し、問題が続く場合はオプション2に進んでください。
オプション1: Procedure Switchingを有効にする
Agentic Switchは、会話中に顧客の意図が変わったとFinが検知した場合、現在のProcedureから別のライブProcedureに自動で切り替える設定です。元のProcedureに固定されたりHelp Center回答に戻ったりしません。有効にすると:
Finは会話とすべてのライブProcedureトリガー説明を見直し、切り替えが顧客にとって有益か判断します。
複数のProcedureが該当する場合、Finは最適なものを選ぶために確認質問をすることがあります。
切り替え元のProcedure（Finが切り替え出る方）のみ設定をオンにすればよいです。
@Switchコマンドは手動切り替えにも使えます。
有効にするには: Fin AI Agent > Train > Procedures > Settings > Agentic Switch
オプション2: 競合するHelp Centerコンテンツを削除または更新する
Agentic Switchを有効にしても問題が解決しない場合、最も確実な修正方法は、Finが手順を実行する代わりに表示しているHelp Centerコンテンツを削除または更新することです。Finは関連するトピックに適切なHelp Centerの回答がある場合、デフォルトでそちらを参照します。つまり、記事が手順と同じ意図をカバーしている場合、Finは手順を起動せずに直接その記事から回答することがあります。
競合するコンテンツを特定するには:
Inboxで会話を見つけ、Finの考えを開きます。
応答経路にHelp Centerの記事への参照がないか確認します。
競合する記事を削除するか、顧客にサポートへ連絡するよう案内するように更新し、Finが手順へルーティングするようにします。
例: ある会社には返金リクエストを処理する手順があり、注文番号を収集し、適格性を確認し、自動的に返金を処理します。また、「返金を受けるには？」というタイトルのHelp Center記事があり、返金ポリシーを説明しています。顧客が「返金を希望します」とメッセージを送ると、FinはHelp Centerの記事を見つけ、手順を起動せずにポリシーの説明で回答します。この場合、記事を「返金を希望する場合はチャットを開始し、アシスタントが案内します」と更新することで、競合する回答を削除し、顧客を手順へ誘導します。
5. 手順が完了前に停止または終了する
問題: 手順が特定のステップに達して停止するか、すべての期待されるステップを完了せずに終了状態に移行します。
解決策: これは通常、Finが手順内の現在位置を追跡する能力を混乱させる設計パターンが原因です。以下を確認してください。
冗長な「すぐに次のステップへ進む」指示: 複数のステップに「すぐに次のステップへ進む」などの指示があると、Finは既に完了したステップを再評価し、前進しないことがあります。これらの指示を削除し、Finが自然な流れで手順を進めるようにしてください。
ステップジャンプの指示: 「ステップ2に戻る」や「検証ステップを繰り返す」などのフレーズは、Finがステップ間をループし前進しない原因となります。各ステップは明確な前進経路を持つよう設計してください。
重複する条件ロジック: 2つの条件が同時に真と評価される場合、Finは予測不能に分岐したり停止したりします。条件は相互排他的であることを確認し、任意の時点で真となる分岐は1つだけにしてください。
サブ手順が続行せずに終了する: サブ手順が完了しても、メイン手順に次に何をするかの明確な指示がない場合、Finはサブ手順の終了を全体の終了とみなすことがあります。サブ手順を呼び出すステップに「サブ手順完了後、[次のステップ名]へ進む」という明示的な指示を追加してください。
会話デバッガーのFinの考え > もっと見るを使い、手順が予期せず終了した時点の正確なステップを特定してください。
データコネクタのトラブルシューティング
このセクションは、手順内で実行されるデータコネクタ固有の障害を扱います。コネクタが単独テストでは動作するが、ライブ手順実行中に失敗する場合はここから始めてください。
テストでは動作するがライブ手順で失敗するコネクタ
問題: コネクタは単独テストに合格するが、ライブ実行中に失敗します。
解決策: これは通常、以下のいずれかが原因です。
認証情報: キーをローテーションした後に再保存および再公開してください。トークン値に末尾のスペースなどの隠れた文字がないか確認してください。
権限: 外部システムの最近のセキュリティ変更によりアクセスが削除されている可能性があります。
IP許可リスト: IntercomのアウトバウンドIPが含まれていることを確認してください。現在の範囲についてはアカウントマネージャーにお問い合わせください。
重要: コネクタがあなた側で変更していないのに動作しなくなった場合、外部APIプロバイダー（例：Shopify、Stripe）がエンドポイントを更新または廃止していないか確認してください。
401および403認証エラー
401 Unauthorized: トークンが欠落、期限切れ、または不正です。Intercomは自動的に1回リトライします。更新が試みられたかどうかはLogsタブで確認してください。
403 Forbidden: トークンは有効ですが権限がありません。外部システムの権限を確認してください。
OAuth users: トークンを削除して再作成する代わりに、Reauthenticateボタンを使用してください。
コネクタがトリガーされていないように見える
ログを確認してください: Settings > Integrations > Data connectors > Logsに移動します。ログエントリがなければ、そのステップはスキップされた可能性があります。前の分岐ロジックを確認してください。
会話イベントを確認してください: Inboxの任意のエラーイベントからLogsを選択し、詳細を確認します。
コネクタはデータを返すがFinは使用しない
Finの考えを使って、Finがコネクタの応答をどのように解釈したかを確認してください。
ステップの指示をより明確にしてください：「@connector_nameを使って回答してください—knowledge baseの内容は使わないでください。」
応答が空またはnullかどうかを確認してください。使用可能なデータが見つからない場合、Finは他の情報源にフォールバックすることがあります。
Finは1ターンにつき1つのコネクタのみ呼び出します: 手順で複数のコネクタ呼び出しが必要な場合、それぞれを独立したステップにしてください。Finは会話の1ターンにつき1つのツール呼び出ししか処理できず、1つのステップ指示内で複数のコネクタ呼び出しを連鎖させることはできません。
重要: Finは1ターンにつき1つのコネクタ呼び出ししか処理できません。したがって、MCPサーバーが同じSSEストリームで2つの別々の応答を返す場合、Finは最初の応答を確実に使って回答を構築できません。
コネクタが手順エディタに表示されない
問題: データコネクタは公開され設定済みですが、手順エディタ内のステップに追加しようとすると表示されません。
解決策: 以下のチェックを順に行ってください。
コネクタがライブに設定されていることを確認: Settings > Integrations > Data connectorsに移動し、コネクタのステータスを確認してください。ドラフトのコネクタは手順エディタに表示されません。
少なくとも1つのアクションが設定されていることを確認: アクションが定義されていないコネクタは、ライブでも手順エディタの選択肢に表示されません。
役割の権限を確認: 一部の役割はSettingsでコネクタを表示できますが、手順エディタ内にはアクセスできません。両方のアクセス権があるか確認してください。
ページをリフレッシュ: 手順エディタは最近公開されたコネクタを反映するためにハードリフレッシュが必要な場合があります。Macは⌘ + Shift + R、WindowsはCtrl + Shift + Rを使用してください。
Fin Supportに連絡: 上記で解決しない場合は、コネクタ名とワークスペースの詳細を添えてFin Supportにお問い合わせください。一部のワークスペース構成では、手順エディタ内でコネクタを利用可能にするための手動ステップが必要です。
自動実行モードでコネクタが失敗する
問題: データコネクタは顧客に促すことなく自動的に実行されるよう設定されていますが、ライブ会話中に静かに失敗します。Finはエスカレーションするか予期しない応答を返し、会話にはエラーが表示されません。
解決策: 自動実行モードでは、コネクタのステップが失敗してもFinはスキップして手順を続行できません。コネクタがエラーを返すと、Finはそのステップ全体を解決不能とみなし、人間にエスカレーションするかデフォルト動作にフォールバックします。
これを処理する方法は2つあります:
外部APIを修正してフォールバック値を返す: データが利用できない場合（例：注文が見つからない404エラー）にエラーを返す代わりに、Finが処理できる空またはデフォルトの結果を返すようAPIを設定してください。これはFinが常に処理可能な何かを受け取るため、最も信頼できる修正方法です。
コネクター呼び出しの後に条件ステップを追加します：コネクターの
status_code出力を使用して、コネクターが失敗した場合に優雅なメッセージまたは制御されたエスカレーションパスに分岐します。設定方法はこの記事の「Advanced failure handling with status_code」を参照してください。
コネクター出力が会話属性に反映されない
問題：データコネクターステップが実行され期待されるデータを返しますが、その値が会話属性として表示されず、後続の手順でアクセスできません。
解決策：会話属性は会話開始時に設定され、手順実行中にリアルタイムで更新できません。手順内で実行されるコネクターは、会話中に会話属性に新しい値を書き戻すことはできません。
実際に意味すること：
後続のステップでコネクター出力を直接使用する：コネクターが返すデータは手順内のステップ出力として利用可能です。
@connector_name出力構文を使って後続のステップ指示で参照してください。値は手順内でアクセス可能ですが、Inboxの会話属性には表示されません。会話属性にデータを永続化するには：代わりにHandoff to workflowステップを使用し、ワークフロー内で属性値を設定してください。手順はハンドオフ後に再開しないため、ハンドオフ前にフローを完了するよう計画してください。
データコネクターがUPDATEではなくREADに設定されている
問題：手順は実行されますが、データコネクターステップが実行されているように見えても顧客入力を収集または保存しません。
解決策：該当ステップのデータコネクターアクションタイプを確認してください。READは既存の保存値を確認するだけで、顧客に入力を促したり新しいデータを保存したりしません。UPDATEは顧客から入力を収集し属性に保存します。顧客から情報（例：メールアドレス、注文番号、問い合わせ理由）を収集する場合は、アクションタイプをUPDATEに切り替えてください。
Advanced failure handling with status_code
データコネクター呼び出しで返されるstatus_codeは出力属性として公開されます。これをCondition stepで参照して特定のHTTPレスポンスコードで分岐し、単一の成功/失敗分岐に頼るのではなく、Finが異なる失敗シナリオを正確に処理できるようにします。
例えば、404（リソースが見つからない）を500（サーバーエラー）とは異なるメッセージにルーティングしたり、特定のエラーコードが返された場合のみ人間のエージェントにエスカレーションしたりできます。
ヒント：How to write code conditions for Fin Proceduresで、status_codeをCondition stepで使うコード例を参照してください。
シミュレーションで修正を検証する
Procedureをライブに設定する前に、Simulationsを使って修正を検証してください。
プレビューとシミュレーションの違い — どちらを使うべき？ プレビューは顧客向けの全体体験を表示します。Procedureがライブ中にプレビューを使うと、ステップメッセージが実際の顧客に見える可能性があります。SimulationsはバックグラウンドでProcedureを実行し、顧客向け出力はありません。ライブ前のロジック検証とトリガーマッチングに最も安全な方法です。
Procedureエディターに移動し、Testをクリックします。
失敗シナリオでAIが顧客役を演じるSimulationを実行します。
合否結果とAIの判断を確認し、ロジックが信頼できることを確認します。
よくある質問
会話デバッガーは標準のFin会話で機能しますか？
会話デバッガーは標準のFin会話で機能しますか？
いいえ、「Fin’s thoughts」タイムラインとデバッガーはProcedureがトリガーされた場合にのみ利用可能です。Finが標準会話で予期しない回答をした場合、これらのツールは利用できません。代わりにInboxの会話イベントを確認してください。
データコネクターログはどのくらい保存されますか？
データコネクターログはどのくらい保存されますか？
データコネクターの応答ログはデフォルトで7日間保存されます。ワークスペースで拡張ログが有効な場合は14日間に延長されます。Settings > Integrations > Data connectors > Logsでアクセス可能です。
Simulationsを使ってデータコネクターの応答をテストできますか？
Simulationsを使ってデータコネクターの応答をテストできますか？
はい — Simulationsはデータコネクターステップを含む完全なProcedureを実行し、ライブ前にコネクターの動作を検証する最も信頼できる方法です。
なぜWorkflowによってProcedureがブロックされるのですか？
なぜWorkflowによってProcedureがブロックされるのですか？
WorkflowsはFinがProcedureの意図を評価する前に実行されます。同じ会話トリガーに対してWorkflowがアクティブな場合、FinがProcedureをマッチングする前に会話をルーティングする可能性があります。これを修正するには、重複するトリガーのアクティブなworkflowsを確認し、Procedureを利用可能にしたいworkflowパスでLet Fin Handleブロックが正しく設定されていることを確認してください。
なぜProcedureが予期せず人間にハンドオフされるのですか？
なぜProcedureが予期せず人間にハンドオフされるのですか？
Procedureが人間にハンドオフされる方法は2つあります：
デフォルトのエスカレーション動作 — Finは組み込みロジックに基づき自動的にエスカレーションします：顧客が明確に人間と話したいと要求した場合、Finが強いフラストレーションや怒りを検出した場合、または顧客が繰り返しループに陥った場合。これはProcedureの設定に関係なく常に発動します。
設定されたハンドオフ — Procedureの特定のポイントで追加したHandoff to teamステップ、または特定のシナリオでFinにハンドオフを指示するProcedure固有のガイダンス。
ハンドオフが予期せず発生した場合は、会話デバッガーのFin’s thoughtsを使ってどのタイプがどのステップで発動したかを確認してください。
なぜProcedure内でEscalation Guidanceが発動しないのですか？
なぜProcedure内でEscalation Guidanceが発動しないのですか？
Escalation GuidanceはデフォルトでProcedure内には適用されません。ProcedureのGuidanceパネルで明示的に有効にする必要があります：
Procedureを開き、Instructionsエディター右上の設定ホイールをクリックし、Guidanceをクリックします。
適用したいワークスペースレベルのガイダンスカテゴリを選択します。Handover and escalationを含みます。
Finは選択したワークスペースガイダンスと、あなたが作成したProcedure固有のカスタムガイダンスを組み合わせます。
注意：Finのデフォルトエスカレーション動作（顧客が人間を求める、フラストレーション検出、繰り返しループ）は、Guidance設定に関係なくProcedure内で常に発動します。GuidanceパネルはワークスペースレベルのEscalation GuidanceとEscalation Rulesのみを制御します。
Handoff to teamとHandoff to workflowの違いは何ですか？
Handoff to teamとHandoff to workflowの違いは何ですか？
両方のステップはProcedureを終了しますが、会話のルーティング方法が異なります：
Handoff to team — Procedureを終了し、会話を人間のチームメンバーに引き継ぎます。会話はLet Fin handle （Let Fin handleブロック）ステップ後にDeploy workflowで設定されたエスカレーションパスに従います。
Handoff to workflow — Procedureを終了し、既に構築済みの特定の再利用可能なWorkflow（例：満足度調査や専門家ルーティングフロー）に会話を渡します。Workflow完了後、Procedureは再開しません。
ProcedureのハンドオフはFin Outcomeとして課金されますか？
ProcedureのハンドオフはFin Outcomeとして課金されますか？
Fin Procedureは会話が次のいずれかの方法で終了した場合にのみFin Outcomeとして課金されます：
解決 — 顧客がFinが問題を解決したことを確認するか、Finの回答後に追加の支援を求めない場合。
Procedure Handoff — Finが設定されたHandoffステップやProcedure固有のガイダンスを通じてチーム、チームメンバー、またはworkflowにハンドオフする場合。
どちらの場合も、$0.99が課金されます。Finが実行したステップ数や顧客の質問数に関係なく、会話ごとに一度だけ課金されます。
注意：Procedureが完了しなかった場合、これらの結果に達せずに終了した場合、顧客がいつでも人間と話したいと要求した場合、またはFinのデフォルトエスカレーション動作やワークスペースレベルのエスカレーションルールによって会話が終了した場合は課金されません。
詳細については、Understanding Fin Outcomesをご覧ください。
私のProcedureは会話の途中で止まります—タイムアウトの可能性はありますか？
私のProcedureは会話の途中で止まります—タイムアウトの可能性はありますか？
はい。ProceduresはWorkflow内のLet Fin Handleブロック内で実行され、そのブロックにはデフォルトの非アクティブタイムアウトがあります。お客様の応答がそれより長くかかると、Procedureが完了する前にブロックが閉じることがあります。これを修正するには、Workflow設定でLet Fin Handleブロックを開き、非アクティブタイムアウトを会話の予想時間に合わせて延長してください。
Guidanceを使ってProcedureをトリガーできますか？
Guidanceを使ってProcedureをトリガーできますか？
いいえ。GuidanceはFinの応答や動作を制御しますが、Procedureを開始したり会話をProcedureにルーティングしたりすることはできません。両者は別システムです：GuidanceはFinのトーンやエスカレーションルールを形作り、Proceduresは特定の意図が一致したときにFinが従うステップバイステップのworkflowsを定義します。
会話の途中でProcedureを切り替えるには、元のProcedure内で@Switchコマンドを使うか、Procedure設定でAgentic Switchを有効にしてください（この記事の「4. Help Center content taking priority」を参照）。
Finにお客様の発言に基づいてデータコネクタを呼び出すか特定のフローを実行するかを賢く判断させたい場合は、そのロジックをGuidanceではなくProcedureに組み込んでください。
私のコード条件が分岐しません—どうやってデバッグしますか？
私のコード条件が分岐しません—どうやってデバッグしますか？
コード条件は構文エラーがある場合や、会話コンテキストに存在しないデータパスにアクセスしようとした場合に静かに失敗します。Finはエラーを直接表示せず、単にElseブランチをたどるか停止します。診断方法は以下の通りです：
Inboxで会話を開き、Show conversation eventsを有効にしてください（上記の「Accessing the conversation debugger」を参照）。
Fin's thoughtsで、条件の入力としてFinが受け取った値を確認してください。値が
nullまたはundefinedの場合、コード内のデータパスが間違っています。以下の一般的なデータアクセスパターンを確認してください： • Customer type:
inputs["user"]["role"]—"user"または"lead"を返します • Connector output: コネクタのレスポンススキーマから正確なフィールド名を使用してください • Conversation attribute:inputs["conversation"]["attribute_name"]Procedureに追加する前にPythonインタプリタでコードブロックをテストしてください。これにより、ライブ会話を実行せずに構文エラーを即座に検出できます。
条件が評価されても誤ったブランチにルーティングされる場合は、コードブロックに
print()文を追加してFinが受け取っている実際の値をログに記録してください。出力は会話イベントに表示されます。