Anthropic がなぜ「MCP ツール直接実行」ではなく「コード生成」を提案したか?
昨年 Anthropic が MCP (Model Context Protocol) を発表して以来、LLM と外部システムを連携させるための標準プロトコルとして爆発的に普及してきました。
しかし、実運用が進むにつれて、MCP のいくつかの課題も浮き彫りになってきました。特にレイテンシの増加と、大量のツール定義や中間結果のやり取りによるトークン消費の増大です。
この課題への回答として、Anthropic は新たなアプローチを提案しています。それが 「Agent Skills と 「コード生成によるツール操作 です。
従来の MCP vs 新しいアプローチ
これまでの MCP エージェントは、ツールを「直接実行」していました。
例えば「データベースからユーザーを検索し、その注文履歴を取得して、合計金額を計算する」というタスクを考えてみましょう。
従来の MCP(ツール直接実行)
LLM とシステムの間で、何度も往復(ピンポン)が発生します。
-
LLM:
search_users(name="Alice")を呼び出したい -
System: 実行結果
[{id: 1, name: "Alice"}]を返す -
LLM:
get_orders(user_id=1)を呼び出したい -
System: 実行結果
[{id: 101, amount: 5000}, ...]を返す - LLM: 合計は...と計算する
この方式では、ステップごとに LLM の推論が必要で時間がかかり、すべての中間結果(検索された全データなど)がコンテキストに含まれるため、トークンを大量に消費します。
新しいアプローチ(コード生成 + Skills)
LLM はツールを直接呼ぶのではなく、「ツールを扱うコード」を生成して一括実行します。
-
LLM: 以下のコードを生成して実行したい
user = search_users(name="Alice")[0] orders = get_orders(user_id=user.id) total = sum(o.amount for o in orders) print(total) -
System: コードを実行し、結果
15000だけを返す
LLM の推論は「コードを書く」という 1 回だけで済みます。中間データ(orders の中身など)はコード実行環境のメモリ上に留まり、LLM のコンテキスト(プロンプト)を汚染しません。
重要な概念:段階的情報開示 (Progressive Disclosure)
このアプローチの核にあるのが 「段階的情報開示 (Progressive Disclosure)」 という考え方です。
LLM にとって、すべての情報を一度に見せることは必ずしも良くありません。情報過多はハルシネーションの原因になり、コストも嵩みます。
コード生成アプローチでは、必要な情報(最終結果)だけをコンテキストに戻すことが可能になります。
また、頻繁に使用するロジックを Skills として定義し、再利用可能なコンポーネントとしてエージェントに提供することで、プロンプトに含まれるツール定義の記述量も削減できます。
メリットと副次的効果
- トークン削減: 中間結果を LLM に渡さないため、コンテキストウィンドウを節約できます。
- レイテンシ改善: 往復回数が減り、処理が高速化します。
- セキュリティ: 生成されたコードはサンドボックス内で実行されるため、機密データが LLM の学習データに含まれたり、外部に漏れたりするリスクを制御しやすくなります。
課題と展望
もちろん課題もあります。
エージェントの挙動がよりダイナミックになるため、何が起きたかの追跡(Observability) が難しくなります。従来のツール実行ログのように単純な履歴だけでなく、生成されたコードとその実行状態をどう可視化・管理するかが重要になります。
また、エージェントが小さな間違いを含むコードを生成し、それが予期せぬ副作用を引き起こすリスクもあります。これに対しては、「Skills」として安全なビルディングブロックを提供し、エージェントにはゼロからコードを書かせるのではなく、信頼できるパーツを組み合わせさせるアプローチが有効でしょう。
Anthropic のこの提案は、LLM エージェントが「チャットボット」の枠を超え、実世界の複雑なタスクをこなす「エンジニア」のように振る舞うための重要なステップと言えるでしょう。
Discussion