新しいステップをFin Procedureに追加すると、指示ステップがデフォルトのステップになります。指示ステップは最も強力で、Finが自然言語で実行する一貫した作業単位を定義できます。
指示ステップの機能
指示ステップを実行する際、デフォルトでFinは以下のツールにアクセスできます:
指示ステップ内でこれらのツールを使うには、単に@を入力して検索メニューを開きます。
カテゴリ | ツール | 説明 |
ロジックとフロー制御 | @Condition | 分岐ロジック（IF / ELSE）を追加します。 |
| @Run sub-procedure | 共通のフローを再利用したり、メインフローから隠したい複雑なフローを使えます。 |
| @Create sub-procedure | 現在のエディターから直接新しいネストされたフローを作成します。 |
データ操作 | @Read attribute | Finに特定のIntercomデータを手続きのコンテキストに取り込むよう指示します。これにはPeopleの詳細（名前やユーザーロールなど）、Company情報、Conversationの詳細（現在のチャネル、言語、添付ファイルの有無など）、またはTemporaryカスタム属性が含まれます。例：@read name と入力して顧客の名前で挨拶します。 |
| @Update attribute | Finに任意のintercom属性を@updateするよう指示できます。 |
| @Create attribute | 必要な属性がまだ存在しない場合、その場で新しい属性を作成します。 |
知識とコンテキスト | @Look up content | FinにHelp Centerや外部knowledge baseで特定の情報を検索させます。 |
| @Use data connector (Call an API endpoint) | @use data connectorを使うとFinはそのAPIエンドポイントにアクセスします。1ステップあたり1つのdata connectorの使用に最適化してください。 |
| @Create data connector | 現在のエディターから直接新しいネストされたフローを作成します。 |
ルーティングと終了 | @End | 手続きを即座に終了し、Finに戻します。 |
| @Handoff to team | 会話をチームまたはチームメイトに引き継ぎます。これはDeployセクションで定義されたFinブロックに従うワークフローのエスカレーションパスに従います。 |
| @Switch procedure | 現在の手続きを終了し、別の手続きを即座に開始します。これは一方向の遷移です。Finは現在のProcedureを離れ、新しいProcedureに即座に入りますが、新しいProcedureが終了しても元のProcedureには戻りません。@SwitchはProcedureの引き継ぎとはみなされず、解決状態も変更しません。対象ProcedureのIDに直接遷移し、会話がそのProcedureの対象かどうかの再評価は行いません。これにより、会話中に更新された属性に基づくコンテンツターゲティングを即座に適用できます。会社や顧客の属性を更新し、その新しい属性値に対応したProcedureに@Switchすると、そのProcedureが即座に実行され、最初からその対象に合っていたかのようにコンテンツターゲティング、指示、知識が適用されます。 |
会話アクション | @Add note | inboxのチームメイト向けのメモとして表示される事前定義メッセージを追加します。 |
| @Tag | Finが会話に動的にタグを適用できるようにします。 |
注意：
一般的に、“@”で始まらない機能はサポートされていません。例えば、Finはメール送信、電話発信、タグ削除はできません。
「別の手続きに移動」「メモを追加」「顧客のOTPを確認」などの自然言語コマンドは避け、サポートされているツールを使ってください。
ベストプラクティス
指示を書く際の2つの大きな設計原則があります
1つの指示ステップは意味のある作業単位を表すべきです
関連するアクションを一貫して組み合わせた、よく設計された少数のステップが、多数の小さなステップより優れています。同時にステップは大きすぎてはいけません。目安として、1ステップあたりのdata connector呼び出しは1回に制限し、update attributeやタグの数も必要最低限に減らしてFinの実行速度を上げましょう。
❌ 効果が低い例：
Step 1 - @read Email.
Step 2 - Ask for email if it's not there.
Step 3 - @use get_subscription_details
Step 4 - Send a reply listing every API field.
✅ より効果的で構造化された例：
@read email. If it is not known, ask the user for their email before continuing. Then @use get_subscription_details and reply asking the user what they need help with. Include the user's current plan, plan status, and next renewal date in your reply.
シンプルで明確に保つ
Finが混乱せずに指示を理解できるよう、常にシンプルで明確に保つよう最適化してください。文脈のない人間が理解できない指示は、Finも理解できません。
具体的でわかりやすい動詞を使いましょう。日常的な動詞（尋ねる、確認する、送る、更新する、エスカレートする）でステップを書き、抽象的または形式的な動詞（検証する、確かめる、実行する、促進する）は避けてください。
❌ 効果が低い例 - 注文番号や追跡番号が何か不明確：
Collect the customers order number: Collect the customers order number and make sure it is valid and not a tracking number.
✅ よく構造化されたステップ - 注文番号の形状と顧客が提供できない場合の対応をFinに伝える：
Collect the customers order number:
If they provided a number but it is longer than 11 characters excluding the # at the start of the number, then let them know that it may be a tracking number and ask them for the order number again.
If the customer can not provide their order number do not continue @Escalate:Support team
確認ステップは必要な箇所だけに追加する
すべてのステップで確認メッセージが必要なわけではありません。取り消しが難しい操作（注文のキャンセル、サブスクリプションの更新やキャンセルなど）の直前に確認ステップを設けてください。情報収集や表示のみのステップでは、余計なやり取りは省略できます。見つけた内容を表示し、誤りがあれば顧客に訂正してもらいましょう。取り消しが難しい操作の直前に一度だけ、明確に確認してください。