翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ツールスコープ
ツールの開発には、細粒度と粗粒度の 2 つのアプローチがあります。
粒度
きめ細かなアプローチでは、API、アクション、またはクエリごとにツールを作成します。たとえば、Git リポジトリclose_issueの create_issue、get_issueadd_label、assign_issue、、 ツールを作成できます。これにより、LLM は各 API をきめ細かく呼び出し、必要に応じて各 API をオーケストレーションできます。次のプロンプトを考慮してください。「クエリは部分的な結果のみを返します」という製品サービスの問題を作成し、バグと高優先度としてラベル付けして、Alice に割り当てます。」 次の図は、tool-per-APIアプローチがこのプロンプトにどのように応答するかを示しています。
この方法では、システムプロンプトと登録されたすべてのツール定義が、呼び出しごとに LLM に提供されます。これにより、追加のコンテキストが消費され、各ツール呼び出しは LLM への個々の呼び出しを表すため、レイテンシーペナルティが発生します。また、ワークフロー内でのエラー処理の複雑さも増します。
粗粒度
粗粒度またはワークフロー駆動型のアプローチは、ワークフロー指向のツールです。このツールは、API 構造よりもend-to-endユーザーインテントに焦点を当てています。tool-per-APIの代わりに、多くの APIs1 つあります。前の Git リポジトリの例を使用して、エージェントによって 1 回呼び出されるcreate_and_setup_issueツールを作成できます。ツール実装は、ツールに提供されたパラメータに基づいて、問題を作成し、ラベルを追加し、ユーザーに割り当てます。次の図は、粗粒度のアプローチが同じプロンプトをどのように処理するかを示しています。
このアプローチは、すべての複雑さが LLM レイヤーからどのように隠されているかを示しています。ツール実装内にオーケストレーションロジックが埋め込まれている場合、シーケンシャルステップ、ログ記録、再試行ロジック、サーキットブレーカー、レート制限はすべて、ツール内で決定的に実行されます。ワークフロー駆動型のアプローチにより、LLM は適切なパラメータを使用して正しいツールを簡単に呼び出すことができます。Amazon EC2 APIs など、一部の RunInstances API がすでにワークフローインテントを提供している可能性があることに注意してください。このような場合、tool-per-APIがワークフロー指向の設計を提供する場合があります。
ただし、ツールも粗すぎる可能性があります。単一のワークフローツールがあまりにも多くのことをしようとし、可能なパラメータが多数ある場合、LLM はツールを正しく使用する方法についての推論に苦労する可能性があります。また、パラメータの選択とエラー処理でチャレンジを作成することもできます。したがって、ツール開発は、ユーザーのインテントに沿ったバランスを取り、1 つのツールで機能が少なすぎたり多すぎたりしないようにする必要があります。一般的に発生するオペレーション (3 つ以上の API コールなど) をバンドルする完全なユーザーワークフローを中心にツールを設計することをお勧めします。また、8 つ以上のパラメータを超えるツールを分解するか、複数の個別のユーザーインテントを処理することをお勧めします。実際のプロンプトで テストして、エージェントが各ツールを正しく使用できることを確認します。
決定論的なツールとして簡単にカプセル化できない複雑で動的なワークフローがある場合は、agent-as-toolパターンの使用を検討してください。プライマリエージェントがワークフロー内の複雑なタスクをオーケストレーションしようとする代わりに、専門エージェントはツールとして機能します。これらのタイプのツールは、高度な意思決定と分岐を実装でき、決定論的なコードでは簡単に管理できないエラーを処理してロジックを再試行できます。これは Agent2Agent (A2A) プロトコル
まず、最も一般的なユーザーワークフローをマッピングしてワークフロー分析を開始し、各エージェントが必要とするコア機能を特定することをお勧めします。これにより、実行可能な最小限のツールセットが確立されます。大規模な MCP サーバーの開発経験に基づいて、以下のプラクティスをお勧めします。これらのプラクティスが競合する場合は、ユーザーのインテントとワークフローに優先順位を付けます。
MCP ツールスコープのベストプラクティス
-
ユーザーストーリーを考え、一般的なオペレーションをバンドルする – ツールは、複数のオペレーションのオーケストレーションを必要とせずに、ユーザーとのやり取りを完了するように直接マッピングする必要があります。ワークフローに通常 3 つ以上の個別の呼び出しが必要な場合は、それらを 1 つのツールに結合します。これにより、LLM の認知負荷を軽減し、ツール呼び出しの数を最小限に抑え、タスクの完了に必要なコンテキストの消費とレイテンシーを減らし、精度とレイテンシーを向上させます。
-
パラメータを 8 以下に制限する – ツールが 8 つのパラメータを超える場合は、複数のツールに分解します。LLMs複雑さが増すにつれてパラメータの選択に苦労します。
注記
バンドルオペレーションで 8 つ以上のパラメータが必要な場合は、厳密なパラメータ制限よりもワークフローの簡素化の方が価値があるため、パラメータ数よりもバンドルを優先します。
-
読み取りオペレーションと書き込みオペレーションを分離する – データを読み取って変更するためのさまざまなツールを提供します。この分離により、エージェントが破壊的になり得るオペレーションを実行しているときが明確になり、さまざまな認可ポリシーが有効になり、情報収集中の意図しない変更のリスクが軽減されます。
-
適切なデフォルトを提供する – LLM が個々のリクエストに固有のパラメータのみを指定する必要があるようにツールを設計します。デフォルトは、LLM が説明する必要がある情報を最小限に抑えることで、パラメータの複雑さを軽減し、ツール選択の精度を向上させます。
-
決定論的な実行を優先する – 可能な場合は、ツールの実行と出力を決定します。決定論的ツールは信頼性が高く、テストが容易です。インテリジェントなオーケストレーション、分岐ロジック、高度なエラー処理を必要とする複雑なワークフローで、決定論的なコードでは簡単に管理できない場合は、特殊なエージェントをツールとして使用することを検討してください。ただし、このパターンは複雑になるため、選択的に使用してください。
