Agentforce Subagentの命名・Instruction書き方ガイド

どんな取り組みか

本記事では、Salesforce Agentforceのサブエージェントが意図した通りにルーティングされないという課題に対し、サブエージェントの命名、分類説明、および指示の書き方に関するベストプラクティスを解説します。Atlas Reasoning Engineがサブエージェントを選択する仕組みを理解し、設計精度を向上させることを目的としています。

使われた技術スタック

Agentforce、Atlas Reasoning Engine

実装のポイント

Atlas Reasoning Engineは、ユーザーの発言を受け取るたびに、まずstart_agent（エージェントルーター）に到達し、そこで「この発言に最適なサブエージェントはどれか」を判断してルーティングを行います。この判断には、各サブエージェントの以下の3つの要素が参照されます。

• サブエージェント名（表示名・API名）
• 分類説明（担当範囲の説明文）
• 指示（振る舞いの詳細説明）

ルーティング精度は、これらの要素とLLMの解釈の一貫性に直結します。

サブエージェントの命名と分類説明の書き方

名前はAPI名形式で一貫させる
サブエージェントの表示名とAPI名がありますが、エージェントスクリプト内でサブエージェントを参照する際は、API名形式（スペースをアンダースコアに置き換えた形）で記述することが推奨されます。例えば、「注文確認」という表示名であれば、Order_Confirmationのように英語スネークケースで記述するのが安全です。日本語名でも動作しますが、LLMとの相性を考慮すると英語名が後々融通が利きます。

分類説明は「何をするか」だけでなく「何をしないか」も書く
分類説明は、LLMがサブエージェントを選択する際の根拠となります。「〇〇の問い合わせに対応する」といった肯定的な説明に加え、「〇〇については対応しない」といった除外条件を明記することが効果的です。特に、似た役割を持つサブエージェントが複数存在する場合に重要となります。

例：注文確認サブエージェントの分類説明
良い例：「顧客が過去の注文状況を確認したい場合に使用する。返品・交換の問い合わせは扱わない。」
改善前：「注文に関する問い合わせに対応する。」
「改善前」のような曖昧な説明では、「返品したい」という発言まで注文確認サブエージェントにルーティングされる可能性があります。「しないこと」の明示は、分類精度を守る上で重要です。

指示（Instructions）の書き方コツ

関連するSalesforceオブジェクトを明示してグラウンディングする
指示の中で、参照すべきSalesforceオブジェクトとその目的を明示することで、LLMはデータの使い方を理解しやすくなります。Salesforce公式の推奨ポイントは以下の通りです。

• 関連するSalesforceオブジェクトとその目的を説明する。
• このサブエージェントは、ツールが提供するデータ以外のSalesforceデータを使用しないことを明示する。
• 顧客にIDの値を表示しないことを指示する（レコードコレクション変数にはIDが含まれるため）。

IDを顧客に見せないための指示は、エージェントがレコードIDをそのまま回答に含めてしまうミスを防ぐために重要です。

遷移アクションには go_to_ プレフィックスを使う
サブエージェントから別のサブエージェントへ遷移するアクションには、go_to_returns（返品サブエージェントへ）のようにgo_to_で始まる名前をつけることが推奨されます。これにより、LLMはそのアクションが「別のサブエージェントへのナビゲーション」であると理解しやすくなります。

例：遷移アクション名
良い例：go_to_order_confirmation
改善前：check_order_status

重要なルーティングはLLMに任せず条件式で制御する
認証が必要なサブエージェントや、特定の順序で通過させたいフローには、available whenフィルターや条件付き遷移を使用して決定論的に制御することが安全です。LLMの分類に全てを委ねる設計は、エッジケースで予期しない動作を引き起こす可能性があります。重要な経路ほど条件式で確定させ、LLMには曖昧さの許容できる分類のみを任せる設計が安定します。

つまずきポイント・注意事項

① 意図したサブエージェントが呼ばれない

原因の多くは、分類説明が曖昧であるか、似た説明を持つサブエージェントが複数存在することです。Agentforce Builderのプレビューで「インタラクションの詳細」を確認し、どのサブエージェントにルーティングされているか、LLMがどう推論したかを確認してください。また、サブエージェント数は必要最小限にすることが公式に推奨されています。最初から多数のサブエージェントを作成すると、LLMの分類精度が低下する可能性があります。少数で設計し、徐々に追加していくアプローチが安定します。

② 「従来のビルダー」と「新しいAgentforce Builder」で用語が異なる場合がある

アップデート以降、画面表示の用語が変わっている場合があります。ドキュメントによっては「トピック」が「サブエージェント」になっていない記述も残っています。名称変更のみで機能変更はないため、「トピック」と「サブエージェント」が混在していても同じものとして読み進めてください。

③ 利用可能エディションの確認

AgentforceはEnterprise Edition以上（またはAgentforce・Data 360対応のDeveloper Edition）で利用可能です。本番環境への導入前にエディション要件を確認しておくと良いでしょう。

まとめ

Atlas Reasoning Engineは、サブエージェントの「名前」「分類説明」「指示」の3要素をもとにルーティングを判断します。分類説明では「何をしないか」を明記することで精度が向上します。指示には「ツールが提供するデータ以外は使わない」「顧客にIDを表示しない」といった点を明示することが推奨されます。遷移アクション名にはgo_to_プレフィックスを使用すると意図が伝わりやすくなります。重要なルーティングはLLMに任せず、条件付き遷移やavailable whenフィルターで制御することが推奨されます。ルーティング設計は、初期設計が甘いと後々修正コストが増大するため、小さく始めて検証しながら拡張していくアプローチが実務に適しています。

出典: https://zenn.dev/pacific_creator/articles/e240a7a8e03919