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