Fin Proceduresは、複雑な問い合わせを処理する際にFinを導く明確で繰り返し可能なフローを設計できます。Stepsで構造を定義し、ToolsでFinの能力を拡張し、Guidanceで動作を形作ります。
情報収集、分岐ロジック、外部システムへの接続、チームメイトへの引き継ぎなど、Proceduresは会話の開始から終了までFinの処理を完全にコントロールできます。
注意：Proceduresを作成するには「can manage workspace data」の権限が必要です。
ヒント：コミュニティエキスパートやIntercomソリューションアーキテクトとProcedures Meetup Office Hoursでつながりましょう。隔週開催のこのセッションでは、Fin ProceduresやData connectorsの設定と最適化に役立つ実践的なリアルタイムサポートとライブQ&Aを提供します。
始める
新しいFin Procedureを作成するには、ワークスペースのFin AI Agent > Train > Proceduresに移動します。
+ 新しいprocedureをクリックし、希望の作成方法を選択します。
オプション1：AIにprocedureの草案を作成させる
すでにプロセスが頭にあるか文書化されている場合、これが最速の方法です。
Let AI draft your procedureを選択します。
開始点の選択肢1：プロセスを説明する、または選択肢2：テンプレートを選ぶ。
オプション1：プロセスを説明する：自然言語でプロセスを書き込むか、既存のステップバイステップの指示や標準作業手順書（SOP）をテキストボックスに直接貼り付けます。Finが自動的に適切なprocedure形式に構成します。含めるattributesとData Connectorsを選択してください。すべてを渡すのではなく特定のコネクターを選べます。attributesは単なるプレースホルダーではなくコンテキストとして機能します。
オプション2：テンプレートを選ぶ：業界別テンプレート（例：SaaS、Ecommerce、Fintech、Gaming）を選び、「サブスクリプションのキャンセルまたは一時停止」などの一般的なシナリオを選択します。含めるattributesとData Connectorsを選択してください。すべてを渡すのではなく特定のコネクターを選べます。attributesは単なるプレースホルダーではなくコンテキストとして機能します。
注意：Let AI draft your procedureの説明欄は5,000文字制限があります。
続行をクリックします。Finは入力内容を分析し、過去の顧客との会話、既存のドキュメント、Data Connectorsを検索してワークスペースのコンテキストに基づいて草案を作成します。
Finが特定のロジックや指示を具体化できるように、明確化の質問に答えてください。これらは任意ですが、提供するとより正確な草案が得られます。
Finが草案を生成するとフィードバックモーダルが表示されます。Keepを選択して草案を承認、Clearで破棄してやり直し、Try againで再生成します。
ヒント：すでにステップバイステップの指示や文書化されたプロセスがある場合は、オプション1：Let AI draft your procedureを使いましょう。既存の指示を貼り付けるだけで、Finが適切なprocedure形式に構成します。手動で各ステップをフォーマットする必要はありません。使用例を先に作成して、ライブ前に必要なData Connectorsを特定することもできます。
オプション2：ゼロから作成する
Procedureを手動で作成したい場合にこの方法を使います。
Create from scratchを選択します。
procedureに名前を付け、エディターに入り手動でステップを追加し始めます。
注意：procedureタイトルに特殊文字（例：'|'）を使用しないでください。保存時にバックエンドエラーが発生する可能性があります。標準の英数字を使い、タイトルは明確で説明的にしてください。
Finにこのprocedureを使うタイミングを伝える
エディターの上部にWhen to use this procedureセクションがあります。これはFinにこのProcedureをいつ利用すべきか正確に伝えるために重要です。Finが意図した時だけ起動するように、明確なトリガーロジックと高品質な会話例を提供する必要があります。これら2つの要素が信頼性を高め、誤検知を減らします。
注意：説明欄は256文字制限です。保存失敗を防ぐため簡潔にしてください。
1. 「When to use this Procedure」ロジックを書く
このprocedureを開始すべき（および開始すべきでない）正確なタイミングを説明します。強力なトリガーは具体的な条件と除外を含みます。
高品質なトリガーロジックの例：
このprocedureを起動するタイミング：顧客がソフトウェアの不具合や予期しない動作を報告したときにこのprocedureを起動します。
含む条件（トリガーする場合）：
顧客が特定の技術的問題やエラーを説明している。
顧客が機能の故障を述べている。
顧客がbug、グリッチ、または不具合について言及している。
除外条件（トリガーしない場合）：
顧客が新機能をリクエストしている。
顧客がアカウント関連の質問（例：パスワードリセット）をしている。
明確で包括的なトリガーは、Finが正しい顧客の意図に対してprocedureを起動し、無関係な問い合わせで誤作動しないようにします。
procedureのトリガー動作の仕組み
Finはすべての顧客メッセージを評価し、procedureのトリガー説明に合致するか判断します。会話が始まっただけでprocedureが開始されるわけではありません。Finが顧客の意図がprocedureの目的に合致すると確信したときに開始します。テスト時は「When to use this procedure」の指示に明確な意図を表すメッセージを送り、短く曖昧な開始メッセージは避けてください。
2. Finを例でトレーニングする
ロジックを書いたら、Finに会話例を提供します。
Train Fin on examplesボタンをクリックします。
When to use：このprocedureが適切なフレーズやシナリオの例を提供します。
When NOT to use：誤トリガーを防ぐため、類似するが無関係な問い合わせの例を提供します。
これらの例は、AIが「パスワードリセット」と「一般的なログインポリシー情報」を区別するために重要です。
procedureに指示を追加する
手順がトリガーされたときにFinに何をするかをinstructionsで指示できます。これらの指示に加えて、条件や外部データへのアクセス、属性の更新を可能にするツールなど、Finにより多くの権限を与える決定論的な制御も追加できます。
Stepsはフローを定義します。新しい行で@を入力して追加します。
ToolsはFinに権限を与えます（APIのチェックなど）。Instructionステップ内で@を入力して追加します。
機能 | 機能の説明 | 使用タイミング |
指示 | デフォルトのブロック。自然言語の指示。 | ほぼすべてに使用可能。「顧客にメールアドレスを尋ねる。」 |
条件 | 分岐ロジック（IF / ELSE）を追加します。 | フローを大きく変える主要で相互排他的なパスに使用します。小さな変化や軽微な明確化には、分岐ではなく自然言語のInstructionsを使ってください。これにより手順がシンプルになり、FinのAIがより自然に会話を処理できます。例えば、WhatsAppとWebで異なるメッセージを送るためにcurrent channelで分岐したり、leadsとusersを区別するためにuser roleで分岐したりします。 |
サブ手順の実行 | サブ手順を実行します。 | 共通のフロー（例：「Verify Identity」）を再利用したり、メインフローから隠したい複雑なフローを使う場合に。 |
workflowへの引き継ぎ | 手順を終了し、ユーザーをWorkflowに渡します。 | 複雑な引き継ぎフロー、満足度調査、専門的なルーティングパスなど、すでに作成した再利用可能なWorkflowに引き継ぐために使用します。 |
終了 | 手順を即座に終了し、Finに戻します。各終了ステップには設定可能な終了メッセージがあり、カスタムメッセージを書くか、空欄にして何も送らないか、デフォルトのままにできます。 | 特定の目標や論理条件が満たされたら手順を停止し、Finが手順を続けないようにします。 |
データコネクタを呼び出す | 接続されたアプリ（Shopify、Stripeなど）からライブデータを取得します。 | ステップ内で注文状況や残高を確認する必要があるとき。 |
属性を読み取る | 既存の顧客データを参照します。 | ステップ内でユーザーのプランやIDを確認するために。 |
属性を更新する | 顧客から得た情報を属性に保存します。 | ステップ内で後で使うために回答を記憶するために。 |
チームに引き継ぐ | 意図的に会話をチームまたはチームメイトに引き継ぎます。 | ステップ内でボットが問題を解決できないとき。 |
Webhookを待つ | 手順を一時停止し、外部システムからのコールバックを待ってからFinが再開します。手順実行ごとに一意のコールバックURLを生成します。 | ステップ内で非同期にリクエストを処理するサードパーティシステムと統合するとき—例えば、本人確認、支払い承認、または承認Workflows。オープンベータで利用可能：アクセスを希望する場合はアカウントチームに連絡してください。 |
重要:
ネスト禁止: Conditionステップを他のCondition内にネストできません。
単一ロジックタイプ: 1つのステップ内でコードと自然言語の条件を混在させることはできません。
未対応属性: 日付や小数などの属性は現在条件で参照できません。
サブ手順
再利用: 同じ親手順内でサブ手順を複数回再利用できます。
スコープ: サブ手順は現在ローカルで、他の無関係な手順から呼び出せません。
Workflowsへの遷移
一方向の引き継ぎ: Finが顧客をWorkflowに渡すと、手順は終了します。
再開なし: Workflowが完了しても手順は再開しません。
データコネクタの操作
属性のスコープ
データコネクタの出力は手順内のステップ出力として利用可能ですが、Inboxの会話属性には表示されません。コネクタの返却値を会話属性に永続化するには、Handoff to workflowステップを使い、Workflow内で属性を設定してください—引き継ぎ後は手順は再開しません。
常にコネクタの失敗を処理してください。
すべてのData Connector呼び出しの後にCondition stepを追加して、エラーや空の応答を処理します。フォールバックがない場合、connectorが静かに失敗するとFinが予期せずエスカレートする可能性があります。一般的な失敗パターンと高度なエラー処理にstatus_codeを使用する方法については、Troubleshooting Fin Procedures and Data connectorsを参照してください。
Connectorの入力設定はFinが顧客に尋ねる内容を決定します
Data Connectorが必須入力フィールド（例：Order ID）で構成されている場合、Finはconnector呼び出しを実行する前に顧客にその情報を提供するよう促します。Finが尋ねる特定のフィールドは、手順の指示ではなくconnectorの入力設定によって決まります。
Connector呼び出しと応答の使用
注意：Finが顧客に送信する最終回答で応答データが使用されない場合でも、connector呼び出しが実行されることがあります。これはFinが最終的に異なる経路を取るロジックを評価しているときに発生します。connectorの応答が表面化するかどうかに関係なく、connectorの失敗に対するエラー処理を必ず追加してください。
詳細はこちら：
注意：2026年3月12日以降、設定されたhandoffs（@handoffを使用）は成功したProcedure handoffの結果として課金されます。Fin Outcomesと課金について詳しくはこちら。Finのデフォルトのエスカレーション動作（顧客が人間を求める、フラストレーション検出、繰り返しループ）、ワークスペースレベルのEscalation RulesやGuidance、または完了しなかったProcedureについては課金されません。
@Look up content
@Look up contentツールは、Procedureの会話中にFinにHelp Centerや外部knowledge baseで特定の情報を検索させます。これにより、静的なテキストを使う代わりに、最新のサポートコンテンツを参照するようFinに指示できます。
対応コンテンツタイプ
公開記事
プライベート記事（AI Agent対応）
アップロードされたドキュメント
インポートまたは同期されたコンテンツソース
Web同期ドキュメント
コンテンツスニペット
重要な要件：
コンテンツソースがまだ同期されてアクティブであることを確認してください。
記事がAI agent対応であることを確認する：公開記事を利用可能にするには、Knowledgeに移動し、記事を開き、詳細パネルで以下を切り替えます。
Fin AI Agent：この設定により、AIは顧客に応答する際に記事を使用できます。既存のオーディエンスルールも自動的に尊重されます。
注意：Content Lookupは記事からテキストコンテンツのみを取得します。記事内の画像はFinに返されないため、Finは応答で画像を渡すことができません。
使用例
Ecommerce
返品や返金の手順で、最新の返品ポリシーをフローにハードコーディングする代わりにFinに参照させることができます。
Eligibility
内部の適格性記事を使用して、ユーザーが割引、返金、または特定のプログラムの対象かどうかをFinが判断するのを支援します。
Handoffとエスカレーション
Procedureがhandoffで終了するとき、何がそれを引き起こしたかを理解することが重要です。
Handoffのトリガー方法
Procedureが人間にhandoffする方法は2つあります：
Configured handoff — Procedureの特定のポイントでHandoff to teamステップを追加したり、特定のシナリオでFinにhandoffさせるProcedure固有のガイダンスを書いたりしています。これは意図的に設計された結果です。
Default escalation behavior — Finは組み込みのロジックに基づいて自動的にエスカレートします：顧客が明確に人間と話したいと要求したとき、Finが強いフラストレーションや怒りを検出したとき、または顧客が繰り返しループに陥ったときです。これはProcedureの設定に関係なく常に発動します。
Procedure内でのワークスペースガイダンスの適用
Procedureを実行中にFinが顧客とどのようにやり取りするかについて具体的なガイダンスを与えます。ガイダンスを追加するには、Fin Procedureを開き、エディターのInstructionsの上に直接表示されるGuidanceセクションまでスクロールします。
ワークスペースレベルのガイダンスはProcedure内で自動的には適用されません。General Fin guidanceドロップダウンで明示的に選択する必要があります。
コミュニケーションスタイル
コンテキストと明確化
引き継ぎとエスカレーション
その他のガイダンス
カスタムガイダンス
Custom guidanceフィールドにProcedure固有のカスタムガイダンスを書くこともできます。これはこのProcedureのみに適用されます。Finはこれを選択したワークスペースレベルのガイダンスと組み合わせます。例：「顧客が最初に言及しない限り、返金については決して持ち出さない。」
注意：Procedure内でワークスペースガイダンスを使用する際は、次の3点に注意してください：
ガイダンスは加算的であり、上書きではありません。ワークスペースガイダンスが有効な場合、Finはあなたが書いたProcedure固有のガイダンスと組み合わせます。どちらか一方が他方をキャンセルすることはなく、両方が同時に適用されます。
広範なワークスペースルールはProcedureの途中でトリガーされることがあります。ワークスペースガイダンスはFinが各応答を生成する際に評価されるため、広範なルールはProcedureが意図したよりも早く顧客に情報を共有することがあります。ルールがProcedureのコンテキスト外でのみ適用されるべき場合は、オーディエンス条件で範囲を狭めるか、そのロジックを明示的なステップとしてProcedureに移動してください。
Finの組み込みエスカレーションは常に適用されます。 Finのデフォルトのエスカレーション動作は、顧客が人間を求めたり、強い不満や怒りを表現したり、繰り返しのループに陥った場合にトリガーされ、ガイダンス設定に関係なく手順内で常に適用されます。これは、ワークスペースレベルのEscalation GuidanceおよびEscalation Rulesとは別で、これらはガイダンスパネルで明示的に有効にする必要があります。
終了メッセージを設定する
デフォルトでは、Finは手順が終了すると「他にお手伝いできることはありますか？」と送信します。このメッセージは各Endステップごとにカスタマイズ可能で、グローバルデフォルトを設定するか、空にして何も送信しないこともできます。
各Endステップには設定可能なメッセージがあります。Endピルをクリックするとサイドパネルが開き、リッチテキストや@attributeメンションを使ってカスタムメッセージを作成できます。
手順が自然に完了したとき（Endステップに到達しなかった場合）のデフォルトメッセージを設定するには、手順の設定ダイアログを開き、終了メッセージタブに移動してください。
注意：終了メッセージは自動ローカリゼーションに対応しており、ワークスペースの許可された言語に翻訳され、用語集設定を尊重し、顧客の会話ロケールで提供されます。
チャネルを選択する
Web、iOS、Android、Facebook、WhatsApp、Instagram、SMS、Email、Slackなど特定のチャネルで手順を実行するには、手順エディター内のAudience targeting設定を使用します。Channelsドロップダウンメニューで希望のチャネルが選択されていることを確認してください。
特定のオーディエンス向けに手順を実行するには、手順エディター内のAudience targeting設定を使用します。Audiencesドロップダウンメニューで希望のチャネルが選択されていることを確認してください。
手順をテストして検証する
手順を公開する前に、意図した通りに動作するかを検証する必要があります。エディター上部のTestボタンをクリックすると、2つのテスト方法にアクセスできます。
プレビュー
Previewタブでは、顧客としてFinと対話できます。会話のトーン、挨拶、全体の流れを把握するのに役立ちます。
シミュレーション
Simulationsタブでは、指示内の異なるロジックパスを自動的にテストできます。これにより、手順を実際の顧客に公開する前にFinが意図した通りに動作することを確認できます。
PreviewとSimulationsの違い — どちらを使うべき？ Previewは顧客向けの完全な体験を表示します。手順がライブ中に使用すると、メッセージが実際の顧客に表示される可能性があります。Simulationsはバックグラウンドで手順を実行し、顧客向けの出力がないため、ライブ前のロジック検証に最も安全な方法です。
シミュレーションタイプを選択してください：
ハッピーパス：FinのAIが標準的なシナリオを自動提案し、すぐに始めて機能の動作を確認できます。
カスタムシミュレーションも作成可能：特定のシナリオを作成して、エッジケースや技術的統合をテストできます。以下を定義してください：
コンテキスト：開始時の顧客メッセージと会話の進行方法を設定します。
モックデータ：カスタム入力とモックData Connectorの応答を定義し、Finがライブデータ（例：Stripeの「支払い失敗」応答）をどのように処理するかをシミュレートします。
成功基準：どのツールがトリガーされるべきか、Finが提供すべき情報など、期待する正確な結果を指定します。
実行してレビュー：
シミュレーションを実行して、Finがステップを実行し、モックAPIをトリガーし、ロジックに従う様子を確認します。
合格：シミュレーションはすべての定義された基準を満たしました。
不合格：シミュレーションは失敗しました。シミュレーションをクリックして、Finが指示からどこで逸脱したかを正確に確認してください。
結果に満足したら、Set liveをクリックして手順を顧客に公開してください。
詳細はこちら： 手順のバージョン管理と公開では、公開ライフサイクル、手順の状態、バージョン履歴、ロールバック、バージョンノート、停止について説明しています。
手順間を賢く切り替える
Agentic Switchは手順で利用可能です。有効にすると、Finは顧客の意図が変わり、別の手順の方が顧客の状況に適していると判断した場合、現在の手順から別のライブ手順に自動的に切り替えることができます。
変化する顧客ニーズに自動適応：
Finは会話とProcedure Trigger Descriptionsを確認し、手順を切り替えた方が顧客にとってより良い場合を判断します。
必要に応じて明確化の質問をする：
複数の手順が顧客の状況に適している場合、Finは明確化の質問をして曖昧さを解消し、最適な選択肢を選ぶことがあります。
Help Centerが優先されます：
Finは顧客の質問に対応する際、Agentic SwitchよりもHelp Centerのコンテンツを優先し続けます。
注意：手順で有効にすると、Finはこの手順から他のライブ手順に切り替えることができます。移動先の手順はAgentic Switchを有効にしている必要はありません。@Switchコマンドを使って手動で手順を切り替えることも可能です。