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」の説明を確認し、トリガーすべきメッセージ（ポジティブ例）とトリガーすべきでないメッセージ（ネガティブ例）を追加してください。
競合するEscalation GuidelineまたはEscalation Ruleがないか確認：顧客のメッセージがEscalation GuidelineやEscalation Rule（Fin AI Agent > Train > Escalations）にもマッチする場合、エスカレーションが優先されます。FinはProcedureのトリガー条件が同等かそれ以上に適合していても、人間に引き継ぎProcedureをトリガーしません。Escalation GuidanceとEscalation Rulesの文言を見直し、Procedureトリガーと重複する表現（例：同じエラーコードやフレーズ）を避けるため、Escalation Guidelineにもポジティブ・ネガティブ例をProcedureトリガーと同様に追加してください。

注意：Slackは選択可能なチャネルとして表示されることがありますが、現在Slack会話でのProcedureトリガーはサポートされていません。

Finが誤ったProcedureをトリガーする

問題：Finが顧客のリクエストに合わないProcedureを開始する。

解決策：「When to use this procedure」の指示を見直してください。ポジティブ例とネガティブ例を使い、Finが類似の意図を区別できるようにします。新しいProcedureが既存の公開Procedureと似たトリガー条件を持つ場合、公開済みの方が優先されることがあります。テスト中に新しいProcedureを分離するには、既存Procedureのオーディエンス条件を調整してテストユーザーを除外するか、新しいProcedureのトリガーをあなただけが送るユニークなフレーズに絞ってください。会話デバッガーのFin's thoughts > Expand thoughtsで実際にどのProcedureが起動したか確認できます。

ステップの順序がずれている

問題：Finが前提条件のステップをスキップしたり、早すぎる解決に進む。

解決策：自然言語の指示に曖昧さがないか確認してください。特定のデータに依存するステップは「[データ]が提供された場合のみ進む」と明示してください。

分岐ロジックの失敗

問題：Finが「Else」の経路をたどるべきところを「If」の経路をたどるべきだった。

解決策：Conditionsを検査してください。自然言語で分岐している場合は、明確になるよう言い換えを試みてください。複雑なロジック（例：日付計算）には、Pythonコードブロックを使い厳密な決定ルールを適用することを検討してください。

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が切り替える元のProcedure）のみ設定をオンにすればよい。
- @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が手順にルーティングするようにします。

例：ある会社には返金リクエストを処理する手順があります。注文番号を収集し、適格性を確認し、自動的に返金を処理します。また、「How do I get a refund?」というタイトルのHelp Center記事があり、返金ポリシーを説明しています。顧客が「返金を希望します」とメッセージを送ると、FinはHelp Centerの記事を見つけて手順を起動する代わりにポリシーの説明で回答します。この場合、記事を「返金を希望する場合はチャットを開始してください。アシスタントが案内します」と更新することで競合する回答を排除し、顧客を手順に誘導します。

手順が完了前に停止または終了する

問題：手順が特定のステップに達して停止するか、すべての期待されるステップを完了せずに終了状態に移行します。

解決策：これは通常、Finが手順内の現在位置を追跡する能力を混乱させる設計パターンが原因です。以下を確認してください：

冗長な「すぐに次のステップへ進む」指示：複数のステップに「すぐに次のステップへ進む」などの指示があると、Finは既に完了したステップを再評価し、前進しないことがあります。これらの指示を削除し、Finがフローに基づいて自然に手順を進めるようにしてください。
ステップジャンプの指示：「ステップ2に戻る」や「検証ステップを繰り返す」などのフレーズは、Finがステップ間をループし前進しなくなる原因となります。各ステップは明確な前進経路が一つだけになるよう設計してください。
重複する条件ロジック：二つの条件が同時に真と評価される場合、Finは予測不能に分岐したり停止したりします。条件は相互排他的であることを確認し、任意の時点で真となる分岐は一つだけにしてください。
サブ手順が続行せずに終了する：サブ手順が完了しても、メイン手順に次に何をするかの明確な指示がない場合、Finはサブ手順の終了を全体のフロー終了とみなすことがあります。サブ手順を呼び出すステップに「サブ手順完了後、[次のステップ名]に進む」という明示的な指示を追加してください。

会話デバッガーのFinの思考 > もっと見るを使って、手順が予期せず終了した時点の正確なステップを特定してください。

属性タイプの不一致による保存失敗

問題：会話属性への応答保存時に手順が失敗します。

解決策：保存しようとしている値と属性タイプが一致しているか確認してください。例えば、会話中に収集した顧客の応答が文字列の場合、対象属性も文字列タイプでなければなりません。同名のリストタイプ属性を使うと保存に失敗します。修正するには、手順を正しい属性に参照するよう更新するか、Settings > Data > Conversationsで属性タイプを変更してください。

モバイル（iOS）でのProceduresの問題

モバイル（iOS）では、Proceduresに追加の要件があります：

Usersのみ：ProceduresはモバイルでUsersにのみトリガーされます。手順のオーディエンス設定に関わらず、LeadsやVisitorsには実行されません。
iOSチャネルをターゲットにする必要があります：「この手順を使用するタイミング」セクションでiOSをチャネルとして選択してください。Webのみ選択されている場合、モバイルで手順はトリガーされません。
Procedureは公開済みである必要があります：ドラフトのProceduresはモバイル顧客に提供されません。
FinがiOSで展開されているか確認してください：ProceduresはiOSチャネルでFinが稼働している必要があります。Fin AI Agent > Deploy > ChatでSimple Deployが有効か、または該当するworkflow内にiOSをターゲットにしたLet Fin Handleブロックがアクティブか確認してください。
優先度の高いworkflows：同じ会話トリガーでiOS上で動作するworkflowがあると、Finが手順の意図を評価する前に会話を横取りする可能性があります。iOSチャネルのアクティブなworkflowsの重複を確認してください。

Procedures内のデータコネクタのトラブルシューティング

このセクションはProcedures内で動作するデータコネクタ特有の失敗について説明します。コネクタが単独テストでは動作するが、ライブのProcedure実行中に失敗する場合はここから始めてください。

テストでは動作するがライブのProcedureで失敗するコネクタ

問題：コネクタは単独テストに合格しますが、ライブ実行中に失敗します。

解決策：通常、以下のいずれかが原因です：

認証情報：キーをローテーションした後に再保存および再公開してください。トークン値に末尾の空白などの隠れた文字がないか確認してください。
権限：外部システムの最近のセキュリティ変更によりアクセスが削除されている可能性があります。
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 に移動し、コネクタのステータスを確認してください。ドラフトのコネクタはprocedure editorに表示されません。
少なくとも1つのアクションが設定されていることを確認：アクションが定義されていないコネクタは、ライブであってもprocedure editorのオプションに表示されません。
役割の権限を確認：一部の役割はSettingsでコネクタを表示できますが、procedure editor内でアクセスできない場合があります。両方のエリアにアクセス権があることを確認してください。
ページをリフレッシュ：procedure editorは、最近公開されたコネクタを反映するためにハードリフレッシュが必要な場合があります。Macでは⌘ + Shift + R、WindowsではCtrl + Shift + Rを使用してください。
Finサポートに連絡：上記のいずれも解決しない場合は、コネクタ名とワークスペースの詳細を添えてFinサポートにお問い合わせください。一部のワークスペース設定では、procedure editor内でコネクタを利用可能にするための手動ステップが必要です。

自動実行モードでコネクタが失敗する

問題：データコネクタは自動的に実行されるよう設定されていますが、ライブ会話中に静かに失敗します。Finはエスカレーションするか予期しない応答を返し、会話にはエラーが表示されません。

解決策：自動実行モードでは、Finは失敗したコネクタステップをスキップして手続きを続行できません。コネクタがエラーを返すと、Finはそのステップ全体を解決不能とみなし、人間にエスカレーションするかデフォルト動作に戻ります。

これを処理する方法は2つあります：

外部APIを修正してフォールバック値を返す：データが利用できない場合（例：注文が見つからない場合の404）にエラーを返す代わりに、Finが処理できる空またはデフォルトの結果を返すようAPIを設定してください。これが最も信頼性の高い修正方法です。
コネクタ呼び出し後に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）ではありません。

コネクタの出力が会話属性に反映されない

問題：データコネクタステップは実行され期待されるデータを返しますが、その値が会話属性として表示されず、後続の手続きステップでアクセスできません。

解決策：会話属性は会話開始時に設定され、手続き実行中にリアルタイムで更新できません。手続き内で実行されるコネクタは、会話属性に新しい値を書き戻すことができません。

実際の意味は次の通りです：

後続のステップでコネクタ出力を直接使用：コネクタが返すデータは手続き内のステップ出力として利用可能です。@connector_name出力構文を使って後続のステップ指示で参照してください。値は手続き内でアクセス可能ですが、Inboxの会話属性には表示されません。
会話属性にデータを永続化するには： Handoff to workflowステップを使い、ワークフロー内で属性値を設定してください。手続きはハンドオフ後に再開しないため、ハンドオフ前にフローを完了するよう計画してください。

データコネクタがUPDATEではなくREADに設定されている

問題：手続きは実行されますが、データコネクタステップが実行されているにもかかわらず、顧客入力が収集または保存されません。

解決策：該当ステップのデータコネクタアクションタイプを確認してください。READは既存の保存値を確認するだけで、顧客に入力を促したり新しいデータを保存したりしません。UPDATEは顧客から入力を収集し属性に保存します。顧客情報（例：メールアドレス、注文番号、問い合わせ理由）を収集する場合は、アクションタイプをUPDATEに切り替えてください。

status_codeによる高度な失敗処理

データコネクタ呼び出しで返されるstatus_codeは出力属性として公開されます。Condition stepでこれを参照し、特定のHTTPレスポンスコードに基づいて分岐させることで、Finが異なる失敗シナリオをより正確に処理できます。

例えば、404（リソース未検出）を500（サーバーエラー）とは異なるメッセージにルーティングしたり、特定のエラーコードが返された場合のみ人間のエージェントにエスカレーションしたりできます。

ヒント： Fin Proceduresのコード条件の書き方を参照し、status_codeをCondition stepで使うコード例を確認してください。

シミュレーションで修正を検証

Procedureをライブに設定する前に、Simulationsを使って修正を検証してください。

プレビューとシミュレーションの違い — どちらを使うべき？ プレビューは顧客向けの全体体験を表示します。Procedureがライブ中にプレビューを使うと、ステップメッセージが実際の顧客に見える可能性があります。シミュレーションはバックグラウンドでProcedureを実行し、顧客向け出力はありません。ライブ前のロジック検証とトリガーマッチングに最も安全な方法です。

Procedure editorに移動し、Testをクリックしてください。
失敗シナリオでAIが顧客役を演じるSimulationを実行してください。
合否結果とAIの判断を確認し、ロジックが信頼できることを確かめてください。

よくある質問

会話デバッガーは標準のFin会話で機能しますか？

いいえ、「Fin’s thoughts」タイムラインとデバッガーはProcedureがトリガーされた場合のみ利用可能です。標準会話でFinが予期しない回答をした場合、これらのツールは利用できません。代わりにInboxの会話イベントを確認してください。

データコネクタのログはどのくらい保存されますか？

データコネクタの応答ログはデフォルトで14日間保存されます。ワークスペースにより厳しいデータセキュリティ要件がある場合、Intercomはリクエストに応じて7日間に短縮可能です。サポートチームにお問い合わせください。ログはSettings > Integrations > Data connectors > Logsでアクセスできます。

Simulationsを使ってデータコネクタの応答をテストできますか？

はい、Simulationsはデータコネクタステップを含むProcedure全体を実行するため、ライブ前にコネクタの動作を検証する最も信頼できる方法です。

なぜWorkflowによってProcedureがブロックされるのですか？

WorkflowsはFinがprocedure intentを評価する前に実行されます。同じ会話トリガーに対してWorkflowがアクティブな場合、Finがprocedureをマッチングする前に会話がルーティングされる可能性があります。これを修正するには、重複するトリガーのアクティブなworkflowsを確認し、procedureを利用可能にしたいworkflowパスでLet Fin Handleブロックが正しく設定されていることを確認してください。

なぜProcedureが予期せず人間にハンドオフされたのですか？

Procedureが人間にハンドオフされる方法は2つあります：

デフォルトのエスカレーション動作 — Finは組み込みのロジックに基づいて自動的にエスカレーションします：顧客が明確に人間と話したいと要求した場合、Finが強いフラストレーションや怒りを検出した場合、または顧客が繰り返しのループに陥った場合です。これは、Procedureの設定に関係なく常に発動します。
設定されたハンドオフ — Procedureの特定のポイントに追加したHandoff to teamステップ、または特定のシナリオでFinにハンドオフを指示するProcedure固有のガイダンスです。

ハンドオフが予期しない場合は、会話デバッガーのFin's thoughtsを使って、どのタイプがどのステップで発動したかを確認してください。

ProcedureとEscalation Guidelineの両方が同じ顧客メッセージに一致した場合はどうなりますか？

エスカレーションが優先されます。顧客のメッセージがProcedureのトリガー条件とEscalation Guideline（またはEscalation Rule）の両方に一致する場合、FinはProcedureを実行する代わりに人間にハンドオフします。これは、Procedureのトリガーがメッセージにより近いまたは具体的な一致であっても同様です。これはFinが競合する意図を解決する一般的なルールであり、Procedureごとに設定できるものではありません。

例えば、「API Error」のケース作成リクエストを処理するために作られたProcedureは、Escalation Guidelineも「API Error」という言葉に基づいている場合、顧客がAPIエラーを説明してもトリガーされません。Escalation Guidelineが優先され、Procedureは実行されません。

Escalation Guidelineが意図せずProcedureを上書きするのを防ぐには？

Escalation GuidelineがProcedureのトリガー条件と重複しないように絞り込みます：

Fin AI Agent > Train > Escalationsを開き、Escalation GuidanceとEscalation Rulesを見直して、Procedureのトリガーと同じメッセージに一致する可能性のある表現を確認してください。
Escalation Guidelineに、具体的な肯定例（エスカレーションすべき）と否定例（エスカレーションすべきでない—代わりにProcedureを実行すべき）を追加し、Procedureの「このProcedureを使う場合」セクションを洗練するのと同様に調整してください。
両方が同じ狭いフレーズ（例えば特定のエラーコード）に基づいている場合は、Escalation Guidelineをケース作成スタイルのメッセージを除外するように言い換えるか、Procedureのトリガー条件をより具体的にして重複をなくしてください。

会話デバッガーのFin's thoughtsを使って、特定のメッセージに対してエスカレーションが発動したかProcedureが発動したかを確認してください（「会話デバッガーへのアクセス」を参照）。

なぜEscalation GuidanceがProcedure内で発動しないのですか？

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の違いは何ですか？

両方のステップはProcedureを終了しますが、会話のルーティング方法が異なります：

Handoff to team — Procedureを終了し、会話を人間のチームメイトに引き継ぎます。その後、会話はLet Fin handleステップ後に設定されたDeploy workflowのエスカレーションパスに従います。
Handoff to workflow — Procedureを終了し、既に作成した特定の再利用可能なWorkflow（例えば満足度調査や専門家ルーティングフロー）に会話を渡します。Workflow完了後にProcedureは再開しません。

ProcedureのハンドオフはFin Outcomeとして課金されますか？

Fin Procedureは会話が次のいずれかで終了した場合にのみFin Outcomeとして課金されます：

解決 — 顧客がFinが問題を解決したことを確認するか、Finの回答後に追加の支援を求めない場合。
Procedure Handoff — Finが設定されたHandoffステップやProcedure固有のガイダンスを通じてチーム、チームメイト、またはWorkflowにハンドオフする場合。
どちらの場合も、会話ごとに$0.99が課金されます。Finが実行したステップ数や顧客の質問数に関係なく、1回だけの課金です。

注意：Procedureが完了しなかった場合、これらの結果に達せずに終了した場合、顧客がいつでも人間と話したいと要求した場合、またはFinのデフォルトエスカレーション動作やワークスペースレベルのエスカレーションルールで会話が終了した場合は課金されません。

詳細はUnderstanding Fin Outcomesをご覧ください。

Procedureが会話の途中で停止します—タイムアウトの可能性はありますか？

はい。ProcedureはWorkflow内のLet Fin Handleブロック内で実行され、そのブロックにはデフォルトの非アクティブタイムアウトがあります。顧客の応答がそれを超えると、Procedureが完了する前にブロックが閉じる可能性があります。これを修正するには、Workflow設定でLet Fin Handleブロックを開き、非アクティブタイムアウトを会話の予想時間に合わせて延長してください。

Guidanceを使ってProcedureをトリガーできますか？

いいえ。GuidanceはFinの応答や動作を制御しますが、Procedureを開始したり会話をProcedureにルーティングしたりすることはできません。両者は別システムです：GuidanceはFinのトーンとエスカレーションルールを形作り、Procedureは特定の意図に一致したときにFinが従うステップバイステップのワークフローを定義します。

会話の途中でProcedureを切り替えるには、元のProcedure内で@Switchコマンドを使うか、Procedure設定でAgentic Switchを有効にしてください（この記事の「4. Help Center content taking priority」を参照）。

Finに顧客の発言に基づいてデータコネクターを呼び出したり特定のフローを実行したりする判断をさせたい場合は、GuidanceではなくProcedureにそのロジックを組み込んでください。

コード条件が分岐しません—どうやってデバッグしますか？

コード条件は構文エラーがある場合や、会話コンテキストに存在しないデータパスにアクセスしようとした場合に静かに失敗します。Finはエラーを直接表示せず、単にElseブランチをたどるか停止します。診断方法は以下の通りです：

Inboxで会話を開き、Show conversation eventsを有効にします（「会話デバッガーへのアクセス」を参照）。
Fin's thoughtsで、条件の入力としてFinが受け取った値を確認します。値がnullまたはundefinedの場合、コード内のデータパスが間違っています。
よくあるデータアクセスパターンを確認してください： • メールアドレス：inputs["user"]["email"] — 顧客のメールアドレスがあれば返します。なければNone • コネクター出力：コネクターのレスポンススキーマの正確なフィールド名を使用 • 会話属性：inputs["conversation"]["attribute_name"]
Procedureに追加する前にPythonインタープリターでコードブロックをテストしてください。これにより、ライブ会話を実行せずに構文エラーを即座に検出できます。
条件が評価されても誤ったブランチにルーティングされる場合は、コードブロック内にprint()文を追加してFinが受け取っている実際の値をログに記録してください。出力は会話イベントに表示されます。

注意：顧客タイプ（user vs. lead）は現在Procedure属性として利用できません。顧客タイプで分岐する必要がある場合は、Finステップの前にWorkflowでType条件を使用してください。

Finの手順とデータコネクタのトラブルシューティング