Salesforce Agentforce サブエージェントと推論指示の実装ガイド

どんな取り組みか

この記事では、Salesforce Agentforceにおけるサブエージェントのルーティングが意図通りに行われないという課題に対処するための取り組みについて説明します。具体的には、サブエージェントの命名、分類説明、指示（Instructions）の書き方を公式ドキュメントのベストプラクティスに沿って整理し、設計精度を向上させることを目的としています。

使われた技術スタック

Salesforce Agentforce、Atlas Reasoning Engine、AgentScript

実装のポイント

Agentforceでは、ユーザーの発言はまずstart_agent（エージェントルーター）に到達し、Atlas Reasoning Engineが最適なサブエージェントを判断してルーティングを行います。この判断には、サブエージェント名、分類説明、指示の3つの要素が参照されます。

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

• サブエージェント名はAPI名形式（スペースをアンダースコアに置き換えた形）で一貫させることが推奨されます。例えば、表示名が「注文確認」の場合、Order_Confirmationのように英語スネークケースで記述すると、LLMとの相性が良くなります。
• 分類説明は、「何をするか」だけでなく「何をしないか」も明記することが効果的です。例えば、「注文に関する問い合わせに対応する」だけでなく、「返品・交換の問い合わせは扱わない」といった除外条件を含めることで、類似の役割を持つサブエージェント間でのルーティング精度を高めることができます。

指示（Instructions）の書き方コツ

• 関連するSalesforceオブジェクトとその目的を指示内で明示することで、LLMがデータを理解しやすくなります。
• 「このサブエージェントは、ツールが提供するデータ以外のSalesforceデータを使わないこと」や「顧客にIDの値を表示しないこと」といった制約を明示することが推奨されます。特にIDを顧客に見せない指示は、エージェントがレコードIDをそのまま回答に含めてしまうミスを防ぐために重要です。
• サブエージェント間の遷移アクションには、go_to_プレフィックス（例: go_to_order_confirmation）を使用することが推奨されます。これにより、LLMはそのアクションが別のサブエージェントへのナビゲーションであることを理解しやすくなります。
• 重要なルーティングはLLMに任せず、available whenフィルターや条件付き遷移を使用して決定論的に制御することが安全です。LLMの分類に全てを委ねる設計は、エッジケースで予期しない動作を引き起こす可能性があります。

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

• 意図したサブエージェントが呼ばれない主な原因は、分類説明の曖昧さや、似た説明を持つサブエージェントが複数存在することです。Agentforce Builderのプレビューで「インタラクションの詳細」を確認し、LLMの推論過程を把握することが重要です。また、サブエージェント数は必要最小限にすることが推奨されており、最初から多数作成するとLLMの分類精度が低下する可能性があります。
• 「従来のビルダー」と「新しいAgentforce Builder」で用語が異なる場合がありますが、機能変更はないため、「トピック」と「サブエージェント」が混在していても同じものとして扱います。
• AgentforceはEnterprise Edition以上（またはAgentforce・Data 360対応のDeveloper Edition）で利用可能です。

得られた成果や学び

ルーティング設計は、初期段階での設計精度が後々の修正コストに大きく影響します。小さく始めて、少しずつ検証しながら拡張していくアプローチが実務に適しています。重要な経路は条件式で確定させ、LLMには曖昧さの許容できる分類のみを任せる設計が安定します。

まとめ

Salesforce Agentforceのルーティング精度を高めるためには、サブエージェントの命名規則、分類説明における「しないこと」の明記、指示におけるSalesforceオブジェクトの明示と制約設定、そして遷移アクションの命名規則の遵守が重要です。また、重要なルーティングはLLMの判断に依存せず、条件式で制御することで、より安定したエージェントシステムの構築が可能になります。

出典: https://qiita.com/ubakichi_sr_mc_ai_06/items/726ba258360b79b76f0c