はじめに
設定したサブエージェントが、思い通りにルーティングされない。AgentforceのAgentScriptに触り始めて最初にぶつかった壁がここでした。
サブエージェントの名前や指示をなんとなく書いただけでは、Atlas Reasoning Engineは意図した通りには動きません。
この記事では、サブエージェントの命名・分類説明・指示（Instructions）の書き方を、公式ドキュメントのベストプラクティスに沿って整理します。
Agentforce管理者やSIerコンサルタントの方が、ルーティングがズレる原因を理解し、設計精度を上げるための内容です。
Atlas Reasoning Engineはどうやってサブエージェントを選ぶか
Agentforceでは、ユーザーの発言が届くたびに、まず start_agent（エージェントルーター） と呼ばれる起点サブエージェントに到達します。ここでAtlas Reasoning Engineが動き、「この発言にはどのサブエージェントが最適か」を判断してルーティングします。
このときLLMが参照するのが、各サブエージェントの3つの要素です。
- サブエージェント名（表示名・API名）
- 分類説明（このサブエージェントが何を担当するかの説明文）
- 指示（このサブエージェントがどう振る舞うべきかの詳細説明）
正直、「名前を適当につけても動くだろう」と思っていました。でも実際に試してみると、名前と説明の一貫性がルーティング精度に直結すると感じています。
サブエージェントの命名と分類説明の書き方
名前は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が賢く判断してくれるはず」という期待が先に立つからです。でも使い込んでみると、重要な経路ほど条件式で確定させ、LLMには「曖昧さの許容できる分類」だけを任せる設計が安定するという感触があります。
つまずきポイント・注意事項
① 意図したサブエージェントが呼ばれない
原因の多くは、分類説明が曖昧か、似た説明を持つサブエージェントが複数存在することです。まずAgentforce Builderのプレビューで「インタラクションの詳細」を確認し、どのサブエージェントにルーティングされているか・LLMがどう推論したかを見てください。
また、サブエージェント数は必要最小限にすることが公式に推奨されています。最初から多数のサブエージェントを作ると、LLMの分類精度が下がります。まず少数で設計し、徐々に追加していくアプローチが安定します。
② 「従来のビルダー」と「新しいAgentforce Builder」で用語が異なる場合がある
2026年4月のアップデート以降、画面表示の用語が変わっています。ドキュメントによっては「トピック」が「サブエージェント」になっていない記述も残っています。名称変更のみで機能変更はないため、「トピック」と「サブエージェント」が混在していても同じものだと割り切って読み進めてください。
③ 利用可能エディションの確認
Agentforceは Enterprise Edition以上（またはAgentforce・Data 360対応のDeveloper Edition）で利用可能です。本番環境への導入前にエディション要件を確認しておくと、後で驚くことがありません。
まとめ
- Atlas Reasoning Engineは、サブエージェントの名前・分類説明・指示の3要素をもとにルーティングを判断する
- 分類説明は「何をするか」だけでなく**「何をしないか」**も明記することで分類精度が上がる
- 指示には「ツールが提供するデータ以外は使わない」「顧客にIDを表示しない」を明示するのが推奨
- 遷移アクション名に
go_to_プレフィックスをつけると遷移の意図が伝わりやすくなる - 重要なルーティングはLLMに任せず、条件付き遷移や
available whenフィルターで制御する
ルーティング設計は「地味だけど後になって効いてくる」領域だという印象を持っています。最初の設計が甘いと、エージェント数が増えるにつれてどんどん修正コストが膨らみます。小さく始めて、少しずつ検証しながら拡張していくのが、実務では合っているように感じます。
AI×資格学習・Salesforce業務活用の情報をnoteでも発信しています。