FinのProcedureが期待通りに会話を解決しない場合、組み込みの検査ツールを使ってFinの意思決定ロジックを調査できます。このガイドを使い、フローが逸れた箇所と指示の改善方法を特定しましょう。

学べること

Finの思考と会話イベントを使ってProcedureの失敗をデバッグします。
誤ったProcedureトリガー、順序外のステップ、分岐失敗などの一般的な問題を診断します。
認証失敗やデータ欠落を含むData connectorエラーをトラブルシュートします。
シミュレーションを使って本番前に修正を検証します。

会話デバッガーへのアクセス方法

Finが特定のアクションを取った理由を理解するには、まず会話スレッド内で技術的な可視化を有効にする必要があります。

特定の会話をInboxで開きます。
会話ヘッダー右上の三点アイコンをクリックします。
会話イベントを表示を選択します。

ヒント: キーボードショートカット⌘ + E（Mac）またはCtrl + Shift + E（Windows）でこの表示を切り替えられます。

「Finの思考」の検査

会話イベントが表示されると、Procedure中にFinが取った各ステップの理由が見えます。Finの意思決定プロセスを追跡するには、会話タイムラインのFinの思考イベントを探してください。これらのイベントは、Finがメッセージ送信やアクション実行前に考えた理由を要約しています。

より詳細を見るには、Finの思考をクリックし、もっと見るをクリックします。これにより以下が表示されます：

現在のステップ：Finが実行していた特定のProcedureステップ。
意図の解釈：Finが顧客のリクエストをどのように理解したか。
ロジックパス：Finがステップをスキップしたり、前のステップに戻ったり、特定の分岐に進んだ理由。

Finが顧客のメッセージに対してProcedureを検討したが実行しなかった場合、会話タイムラインに「[Procedure名]がFinにより検討され拒否された」イベントが通常のトリガーイベントと共に表示されます。展開してFinがProcedure開始を拒否した理由を読み取れます。

注意：この記事はFinのProcedureのトラブルシューティングのみを扱います。「Finの思考」タイムラインとデバッガーはProcedureがトリガーされた場合にのみ利用可能です。標準会話でFinが予期しない回答をした場合、これらのツールは会話イベントに存在しません。

一般的なProcedureの失敗

Finが期待通りに動作しない場合、多くは指示の表現やロジックの分岐方法に原因があります。

Procedureが全くトリガーされない

以下の番号付き失敗を確認する前に、まず基本を確認してください：

Procedureが有効になっているか確認：無効なProcedureは顧客に対してトリガーされません。エディターでAvailabilityピルがサービスに対して有効となっていることを確認してください。
Finがデプロイされているか確認：Simply DeployセクションでFinが有効になっていない、またはワークフロー内の「Let Fin handle」ステップがライブでない場合、FinはProcedureを実行しません。
対象オーディエンスを確認：よくあるミスは、顧客がLeadなのにUsersをターゲットにしている（またはその逆）ことです。「このProcedureを使う時」セクションでオーディエンスボタンをクリックし、正しいオーディエンスタイプとチャネルが選択されているか確認してください。
優先度の高いworkflowsがないか確認：アクティブなworkflowsはFinがProcedureの意図を評価する前に実行されます。workflowsを見直し、FinがProcedureをトリガーする前に会話を横取りしているものがないか確認してください。
トリガー条件の範囲を見直す：条件が狭すぎるとFinが有効な顧客メッセージにマッチしません。「このProcedureを使う時」の説明を確認し、トリガーすべきメッセージ（ポジティブ例）とトリガーすべきでないメッセージ（ネガティブ例）を追加してください。
競合するEscalation GuidelineまたはEscalation Ruleがないか確認：顧客のメッセージがEscalation GuidelineまたはEscalation Rule（Fin AI Agent > Train > Escalations）にもマッチする場合、エスカレーションが優先されます。FinはProcedureをトリガーせず人間に引き継ぎます。Procedureのトリガー条件が同等かそれ以上に適合していても同様です。Escalation GuidanceとEscalation Rulesを見直し、Procedureのトリガーと重複する表現（例：同じエラーコードやフレーズ）を確認し、Procedureトリガーと同様にポジティブ例とネガティブ例をEscalation Guidelineに追加して、両者が同じメッセージで競合しないようにしてください。

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

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

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

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

ProcedureトリガーのデバッグにFin Operatorを使用する

Fin Operatorの会話デバッグは、特定の会話でProcedureに何が起きたか正確に教えてくれます。Operatorに会話を尋ねると、各Procedureがトリガーされた、拒否された、既に実行中、検討されなかった、またはより適合するProcedureやEscalation Guidelineに負けたかを報告し、該当するケースの修正案を提案します。

ProcedureトリガーのレビューにFin Operatorを使用する

Fin OperatorにProcedureのトリガー（「このProcedureを使う時」の説明と例）をレビューまたは作成させると、Procedureが発火しない主な2つの原因を指摘します。顧客が自分で言えない条件（例：顧客が知らない内部アカウントステータス）で表現されていること、そして広範なトリガー説明に対して矛盾する狭いトリガークローズが例と合わないことです。

順序外のステップ

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

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

分岐ロジックの失敗

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

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

Help Centerコンテンツが優先される

問題：顧客の意図がProcedureのトリガー条件に明確に合致しているにもかかわらず、FinがProcedureを実行せずHelp Centerから回答する。

解決策：FinがProcedureを実行せずHelp Centerの回答を優先する場合、設定に応じて2つの方法があります。まずオプション1を試し、問題が続く場合はオプション2に進んでください。

オプション1: Procedureスイッチングを有効にする
Agentic Switchは、顧客の意図が会話中に変わったと検出した場合に、Finが現在の手順から別のライブ手順に自動的に切り替えることを可能にする手順ごとの設定です。元の手順に固定されたり、Help Centerの回答に戻ったりする代わりに、切り替えを行います。有効にすると:
- Finは会話とすべてのライブ手順トリガーの説明を確認し、切り替えが顧客にとってより良いサービスになるタイミングを判断します
- 複数の手順が適用可能な場合、Finは最適なものを選択するために確認の質問をすることがあります
- 設定が必要なのは、切り替え元の手順（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記事を見つけてポリシー説明で回答し、手順を起動しません。この場合、記事を「返金を希望する場合はチャットを開始してください。当社のアシスタントが案内します」と更新することで、競合する回答を排除し、顧客を手順に誘導できます。

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

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

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

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

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

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

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

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

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

モバイル（iOS）では、Proceduresに追加要件があります。ある質問に対してProcedureが検討されたが拒否された場合、Batchテストで「[Procedure名]は実際の顧客会話で検討されたが拒否された」と回答の横に表示されます。Show reasoningをクリックすると、Finが起動しなかった理由がわかります。

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

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

このセクションは、Procedure内で実行されるデータコネクタに特有の失敗を扱います。コネクタが単独テストに合格するがライブ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は最初の応答を信頼して回答を構築できません。

コネクタが手順エディタに表示されない

問題：データコネクタは公開および設定されていますが、手順エディタ内のステップに追加しようとすると表示されません。

解決策：以下のチェックを順に実施してください：

コネクタがライブに設定されていることを確認： 設定 > Integrations > Data connectors に移動し、コネクタのステータスを確認してください。ドラフト状態のコネクタは手順エディタに表示されません。
少なくとも1つのアクションが設定されていることを確認：アクションが定義されていないコネクタは、ライブ状態でも手順エディタのオプションとして表示されません。
役割の権限を確認：一部の役割は設定でコネクタを表示できますが、手順エディタ内にはアクセスできません。役割が両方のエリアにアクセスできることを確認してください。
ページをリフレッシュ：手順エディタは最近公開されたコネクタを反映するためにハードリフレッシュが必要な場合があります。⌘ + Shift + R（Mac）またはCtrl + Shift + R（Windows）を使用してください。
Finサポートに連絡：上記で解決しない場合は、コネクタ名とワークスペースの詳細を添えてFinサポートにお問い合わせください。一部のワークスペース設定では、手順エディタ内でコネクタを利用可能にするための手動ステップが必要です。

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

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

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

この問題には2つの対処方法があります：

外部APIを修正してフォールバック値を返す：データが利用できない場合（例：注文が見つからない場合の404）にエラーを返す代わりに、Finが処理できる空またはデフォルトの結果を返すようAPIを設定してください。これが最も信頼性の高い修正方法です。
コネクタ呼び出し後に条件ステップを追加：コネクタのstatus_code出力を使い、コネクタ失敗時に適切なメッセージや制御されたエスカレーション経路に分岐させます。この設定方法はこの記事の「status_codeによる高度な失敗処理」を参照してください。

コネクタは404を返すか、実行されているように見えてもコンタクト属性が書き込まれない

問題：コネクタはトリガーされているように見え（ログには実行済みと記録）、404エラーを返しますが、コンタクト属性が書き込まれていません。すべてのコネクタは正しく設定されているように見えます。

解決策：これはほぼ間違いなくリクエストURL内の無効な属性ピルが原因です。URLパラメータの1つが実行時に空の値に解決され、URLが不正になります。

最も一般的な原因：属性が手動で{{Attribute Name}}と入力され、属性インサーターから選択されていないことです。エディタは{{...}}のテキストを有効な属性と見た目が同じピルに変換しますが、識別子が実際の属性に対応していない場合、実行時に空に解決されリクエストURLが無効になります。

これを修正するには：

コネクタを開き、リクエストURLと本文に属性ピルがないか確認してください。
手動で入力されたピルを削除し、属性インサーターのピッカーから正しい属性を選択して置き換えてください。
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は出力属性として公開されます。条件ステップでこれを参照し、特定のHTTP応答コードに基づいて分岐させることで、Finが異なる失敗シナリオを単一の成功/失敗分岐に頼らず正確に処理できます。

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

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

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

手順をライブに設定する前に、シミュレーションを使って修正を検証してください。

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

手順エディタに移動し、テストをクリックしてください。
失敗シナリオでAIが顧客役を演じるシミュレーションを実行してください。
合否結果とAIの判断を確認し、ロジックが信頼できることを確認してください。

よくある質問

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

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

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

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

シミュレーションを使ってデータコネクタの応答をテストできますか？

はい — シミュレーションは、Data connectorのステップを含む完全なProcedureを実行するため、ライブ前にconnectorの動作を検証する最も信頼できる方法です。

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

WorkflowsはFinがprocedureの意図を評価する前に実行されます。同じ会話トリガーに対して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）の両方にマッチした場合、Procedureのトリガーがより近いまたは具体的なマッチであっても、FinはProcedureを実行せず人間に引き継ぎます。これはFinが競合する意図を解決する一般的なルールであり、Procedureごとに設定できるものではありません。

例えば、「API Error」のケース作成リクエストを処理するProcedureがあっても、Escalation Guidelineが「API Error」言語に基づいている場合はEscalation Guidelineが優先され、Procedureは実行されません。

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

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

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

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

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

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

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

Procedureの引き継ぎはFin Outcomeとして課金されますか？

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

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

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

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

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

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

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

いいえ。GuidanceはFinの応答や動作を制御しますが、Procedureを開始したり会話をProcedureにルーティングしたりすることはできません。両者は別システムです：GuidanceはFinのトーンやエスカレーションルールを形作り、Proceduresは特定の意図がマッチしたときに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 • Connector出力: connectorのレスポンススキーマの正確なフィールド名を使用 • 会話属性: inputs["conversation"]["attribute_name"]
Procedureに追加する前にPythonインタープリターでコードブロックをテストしてください。これにより、ライブ会話を実行せずに構文エラーを即座に検出できます。
条件が評価されているが誤ったブランチにルーティングされる場合は、コードブロック内にprint()文を追加してFinが実際に受け取っている値をログに記録してください。出力は会話イベントに表示されます。

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