AI注目記事のキュレーターページ

モデルコンテキストプロトコル（MCP）ツールが期待通りに機能しない場合、その原因はプロトコル自体ではなく、ツール設計にあることが多いです。多くのチームは既存のAPIをそのまま公開し、エージェントに残りを任せることから始めます。これはエージェントシステムや生成AIコーディングツールへのAPI拡張の自然な方法ですが、単純なユースケースでは機能することもありますが、しばしばそうではありません。ツールを大規模言語モデル（LLM）やエージェントシステムの動作に合わせて設計しなければ、失敗したツールコールや不正なパラメータ値、コンテキストを無駄にするリトライが発生し、パフォーマンスが低下するリスクがあります。この記事では、MCPツール設計がどこで間違っているのか、そして実践的なコンテキストエンジニアリングアプローチでどのように修正できるかを示します。

失敗の背後には主に2つの問題があります。1つ目は膨張です。ツール定義は、ツールが使用されるかどうかにかかわらず、すべてのコールでLLMのコンテキストに読み込まれます。複数の接続されたMCPサーバーは、ユーザーが1つの質問をする前にかなりのコンテキストを消費する可能性があります。コンテキストが満たされると、LLMの推論能力が低下し、セッションが生産的でなくなることがあります。2つ目は混乱です。推論が低下すると、LLMは不適切な選択をし、間違ったツールを呼び出し、不正確なパラメータを選択します。その後のリトライは、膨張をさらに悪化させます。ツール間の意味的類似性、選択肢の多さ、あいまいな命名も混乱を助長します。一般的な解決策は、ツールの説明を明確な定義、自然言語マッピング、使用例で豊かにすることです。これにより混乱は軽減されますが、追加するすべてのものは膨張を悪化させ、解決しようとしている問題をさらに複雑にするリスクがあります。

このパターンは一般的です。エージェントは予期しない選択をし、コンテキストは予想より早く満たされ、セッションはすぐに役に立たなくなります。膨張と混乱に対処することは、コンテキストエンジニアリングの問題です。コンテキストエンジニアリングは、LLMが何をいつ見るかを形作り、モデルがより良い結果を出すようにします。これらの1つまたは両方を改善することは、複雑なバランスを取る作業です。以下のセクションでは、これらの問題に対処するためのアプローチとトレードオフを探ります。具体的にするために、MCPプロトコルを使用してシミュレートされたK-12コンテンツ検索APIを公開するいくつかの例を構築しました。これらをローカルで実行し、Kiro CLIを使用して相互作用し、違いを自分で比較します。