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