メインコンテンツにスキップ

Fin手順の構築

ステップ、ツール、ガイダンスを使って構造化され信頼性の高いFin手順を作成する方法。

対応者:Dawn Perrott

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の草案を作成させる

すでにプロセスが頭にあるか文書化されている場合、これが最速の方法です。

  1. Let AI draft your procedureを選択します。

  2. 開始点の選択肢1:プロセスを説明する、または選択肢2:テンプレートを選ぶ

    • オプション1:プロセスを説明する:自然言語でプロセスを書き込むか、既存のステップバイステップの指示や標準作業手順書(SOP)をテキストボックスに直接貼り付けます。Finが自動的に適切なprocedure形式に構成します。含めるattributesData Connectorsを選択できます。すべてを渡すのではなく特定のコネクターを選択可能で、attributesは単なるプレースホルダーではなくコンテキストとして機能します。

    • オプション2:テンプレートを選ぶ:業界別テンプレート(例:SaaS、Ecommerce、Fintech、Gaming)を選び、「サブスクリプションのキャンセルまたは一時停止」などの一般的なシナリオを選択します。含めるattributesData Connectorsを選択できます。すべてを渡すのではなく特定のコネクターを選択可能で、attributesは単なるプレースホルダーではなくコンテキストとして機能します。

      注意:Let AI draft your procedureの説明フィールドには5,000文字の制限があります。

  3. 続行をクリックします。Finは入力を分析し、過去の顧客との会話既存のドキュメントData Connectorsを検索してワークスペースのコンテキストに基づいて草案を作成します。

  4. Finが特定のロジックや指示を具体化できるように、明確化の質問に答えます。これらは任意ですが、提供するとより正確な草案が得られます。

  5. Finが草案を生成するとフィードバックモーダルが表示されます。Keepを選択して草案を承認、Clearで破棄してやり直し、Try againで再生成します。

ヒント:すでにステップバイステップの指示や文書化されたプロセスがある場合は、Option 1: Let AI draft your procedureを使いましょう。既存の指示を貼り付けるだけで、Finが適切なprocedure形式に構成します。手動で各ステップをフォーマットする必要はありません。まずユースケースの草案を作成し、ライブ前に設定すべきData Connectorsを特定することもできます。

オプション2:ゼロから作成

Procedureを手動で作成したい場合にこの方法を使います。

  1. Create from scratchを選択します。

  2. procedureに名前を付け、エディターに入り手動でステップを追加し始めます。

Finにこのprocedureを使うタイミングを伝える

エディターの上部にWhen to use this procedureセクションがあります。これはFinにこのProcedureをいつ利用するか正確に伝えるために重要です。Finが意図した時だけ起動するように、明確なトリガーロジックと高品質な会話例を提供する必要があります。これら2つの要素が信頼性を高め、誤検知を減らします。

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ボタンをクリックします。

  • 使用する場合:このprocedureが適切なフレーズやシナリオの例を提供します。

  • 使用しない場合:誤トリガーを防ぐため、類似するが無関係な問い合わせの例を提供します。

これらの例は、AIが「パスワードリセット」と「一般的なログインポリシー情報」を区別するために重要です。

procedureに指示を追加する

procedureが起動したときにFinに何をすべきかinstructionsで伝えられます。これに加え、条件やツールなどの決定論的コントロールを追加して、Finに外部データへのアクセスや属性の更新などの権限を与えることも可能です。

  • Stepsがフローを定義します。新しい行で@を入力して追加します。

  • ツールはFinに権限を与えます(APIの確認など)。Instructionステップ内で@を入力して追加します。

機能

機能内容

使用タイミング

指示

デフォルトのブロック。自然言語の指示。

ほぼすべてに使用可能。「顧客にメールアドレスを尋ねてください。」

条件

分岐ロジック(IF / ELSE)を追加します。

フローを大きく変える主要で相互排他的なパスに使用します。小さな変化や軽微な説明には、分岐ではなく自然言語の指示を使い、手順を簡潔に保ち、FinのAIがより自然に会話を処理できるようにします。

サブ手順を実行

サブ手順を実行します。

共通のフロー(例:「Verify Identity」)を再利用したり、メインフローから隠したい複雑なフローに使います。

ワークフローに引き継ぎ

手順を終了し、ユーザーをWorkflowに渡します。

既に作成した再利用可能なWorkflow(複雑な引き継ぎフロー、満足度調査、専門的なルーティングパスなど)に引き継ぐために使用します。

終了

手順を即座に終了し、Finに戻します。各終了ステップにはカスタムメッセージを設定可能で、空欄にするとメッセージなし、デフォルトを保持も可能です。

特定の目標や条件が満たされたら手順を停止し、Finが手順を続けないようにします。

データコネクタを呼び出す

接続されたアプリ(Shopify、Stripeなど)からライブデータを取得します。

ステップ内で注文状況や残高を確認する際に使用。

属性を読み取る

既存の顧客データを参照します。

ステップ内でユーザーのプランやIDを確認するために使用。

属性を更新する

顧客から得た情報を属性に保存します。

ステップ内で後で使うために回答を記憶します。

チームに引き継ぐ

意図的に会話をチームまたはチームメイトに引き継ぎます。

ステップ内でボットが問題を解決できない場合に使用。

重要:

  • ネスト禁止: Conditionステップを他のCondition内にネストできません。

  • 単一ロジックタイプ: 1つのステップ内でコード条件と自然言語条件を混在させることはできません。

  • 未対応属性: 日付や小数などの属性は条件で参照できません。

サブ手順

  • 再利用: 同じ親手順内でサブ手順を複数回再利用できます。

  • スコープ: サブ手順は現在ローカルで、他の無関係な手順から呼び出せません。

Workflowsへの遷移

  • 一方向の引き継ぎ: Finが顧客をWorkflowに渡すと、手順は終了します。

  • 再開なし: Workflow完了後も手順は再開しません。


データコネクタの操作

属性のスコープ

データコネクタの出力は手順内のステップ出力として利用可能ですが、Inboxの会話属性には表示されません。コネクタの返却値を会話属性に保持するには、Handoff to workflowステップを使い、Workflow内で属性を設定してください。手順は引き継ぎ後に再開しません。

常にコネクタの失敗を処理する

各データコネクタ呼び出し後にCondition stepを追加し、エラーや空の応答を処理します。フォールバックがないと、Finはコネクタが静かに失敗した場合に予期せずエスカレーションする可能性があります。一般的な失敗パターンと高度なエラー処理にstatus_codeを使う方法はTroubleshooting Fin Procedures and Data connectorsを参照してください。

注意: 2026年3月12日より、設定されたハンドオフ(@handoff 使用)は成功したProcedureハンドオフ結果として課金されます。Fin Outcomesと課金について詳しくはこちら。Finのデフォルトのエスカレーション動作(顧客が人間を求める、フラストレーション検出、繰り返しループ)、ワークスペースレベルのEscalation RulesやGuidance、または完了しなかったProcedureについては課金されません。


@Look up content

@Look up content ツールは、Procedureの会話中にFinにHelp Centerまたは外部knowledge baseで特定の情報を検索させます。これにより、静的テキストの代わりに最新のサポートコンテンツを参照するようFinに指示できます。

対応コンテンツタイプ

  • 公開記事

  • プライベート記事(AI Agent対応)

  • アップロードされたドキュメント

  • インポートまたは同期されたコンテンツソース

  • ウェブ同期ドキュメント

  • コンテンツスニペット

重要な要件:

  • コンテンツソースがまだ同期されてアクティブであることを確認してください。

  • 記事がAI agent対応であることを確認する:公開記事を利用可能にするには、Knowledgeに移動し、記事を開き、詳細パネルで以下を切り替えます。

    • Fin AI Agent: この設定により、AIは顧客対応時に記事を使用できます。既存のオーディエンスルールも自動的に尊重されます。

使用例

Ecommerce

返品や返金のProcedureで、最新の返品ポリシーをフローにハードコーディングする代わりにFinに参照させることができます。

Eligibility

内部の適格性記事を使って、ユーザーが割引、返金、特定プログラムの対象かどうかFinが判断できるようにします。


ハンドオフとエスカレーション

Procedureがハンドオフで終了するとき、何がトリガーになったかを理解することが重要です。

ハンドオフのトリガー方法

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

  • 設定されたハンドオフ — Procedureの特定のポイントでHandoff to teamステップを追加したり、特定のシナリオでFinにハンドオフさせるProcedure固有のガイダンスを書いたりしています。これは意図的な結果です。

  • デフォルトのエスカレーション動作 — Finは組み込みロジックに基づき自動的にエスカレーションします:顧客が明確に人間と話したいと要求したとき、Finが強いフラストレーションや怒りを検出したとき、または顧客が繰り返しループに陥ったとき。これはProcedureの設定に関係なく常に発動します。

Procedure内でのワークスペースガイダンスの適用

Procedure実行中にFinが顧客とどのようにやり取りするかについて具体的なガイダンスを与えます。ガイダンスを有効にするには、Fin Procedureを開き、Settings > GuidanceInstructionsエディタの右上隅でクリックします。

ワークスペースレベルのガイダンスはProcedure内で自動的には適用されません。ProcedureのGuidanceパネルで明示的に有効にする必要があります。

  • コミュニケーションスタイル

  • コンテキストと明確化

  • ハンドオーバーとエスカレーション

  • その他のガイダンス

カスタムガイダンス

このProcedureにのみ適用されるカスタムのProcedure固有ガイダンスも作成できます。Finは選択したワークスペースレベルのガイダンスと組み合わせて使用します。例:「顧客が最初に言及しない限り、返金については決して話題にしない。」


終了メッセージの設定

デフォルトでは、Procedure終了時にFinは「他にお手伝いできることはありますか?」と送信します。このメッセージは各Endステップごとにカスタマイズ可能で、グローバルデフォルトを設定したり、空にして何も送信しないこともできます。

各Endステップには設定可能なメッセージがあります。Endピルをクリックするとサイドパネルが開き、リッチテキストや@attributeメンションを使ってカスタムメッセージを書けます。

Procedureが自然に完了したとき(Endステップに到達しなかった場合)のデフォルトメッセージを設定するには、ProcedureのSettingsダイアログを開き、End messageタブに移動します。

注意:終了メッセージは自動ローカライズに対応しています。ワークスペースの許可言語に翻訳され、用語集設定を尊重し、顧客の会話ロケールで提供されます。


チャネルを選択

Web、iOS、Android、Facebook、WhatsApp、Instagram、SMS、Email、Slackなど特定のチャネルでProcedureを実行するには、Procedureエディタ内のAudience targeting設定を使用します。Channelsドロップダウンメニューで希望のチャネルが選択されていることを確認してください。

特定のオーディエンス向けにProcedureを実行するには、Procedureエディタ内のAudience targeting設定を使用します。Audiencesドロップダウンメニューで希望のチャネルが選択されていることを確認してください。


AI Procedureレビュー

Procedureを公開する前に、AIレビュアーを使って実際の顧客会話で問題を引き起こす可能性のある設定ミスを検出します。ProcedureエディタでReviewをクリックして分析を実行してください。

レビュアーは具体的で実行可能な提案を含む問題を指摘します。例:

  • 不足しているツール:Procedureに追加されていないツール(例:@Handoff to team)を参照しているステップを指摘します。

  • 壊れたステップ参照:存在しないか到達不能なステップへの参照を検出します。

  • ロジックと条件の問題:属性が設定される前に読み取る条件や、信頼性の低い自然言語条件を特定し、コード条件を推奨します。

  • 未処理のelseブランチ:フォールスルーのelseブランチが考慮されておらず、予期しない動作を引き起こす可能性がある場合にフラグを立てます。

ヒント:シミュレーションの前にAIレビューアーを実行して、設定の問題を早期に修正しましょう。レビューアーはビルド時の問題を検出し、シミュレーションはライブの会話フローを検証します。


手順をテストして検証する

手順をライブに設定する前に、意図した通りに動作することを確認する必要があります。エディター上部のTestボタンをクリックして、2つのテスト方法にアクセスしてください。

プレビュー

Previewタブでは、顧客としてFinと対話できます。会話のトーン、挨拶、全体の流れを把握するのに役立ちます。

シミュレーション

Simulationsタブでは、指示内の異なるロジックパスを自動的にテストできます。これにより、手順を実際の顧客に公開する前にFinが意図通りに動作することを確認できます。

PreviewとSimulationsの違い — どちらを使うべき? Previewは顧客向けの完全な体験を表示します。手順がライブ中に使用すると、実際の顧客にメッセージが表示される可能性があります。Simulationsはバックグラウンドで手順を実行し、顧客向けの出力がないため、ライブ前のロジック検証に最も安全な方法です。

シミュレーションタイプを選択してください:

  • ハッピーパス:FinのAIが標準的なシナリオを自動提案し、すぐに始めて機能の動作を確認できます。

  • カスタムシミュレーションも作成可能:特定のシナリオを作成して、エッジケースや技術的統合をテストできます。以下を定義してください:

    • コンテキスト:開始する顧客メッセージと会話の進行方法を設定します。

    • モックデータ:カスタム入力とモックData Connectorの応答を定義し、Finがライブデータ(例:Stripeからの「Payment Failed」応答)をどのように処理するかをシミュレートします。

    • 成功基準:トリガーされるべきツールや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コマンドで手動切り替えも可能です。

こちらの回答で解決しましたか?