AIエージェントに接続するMCPサーバーが増えるほど、コストと遅延が比例して膨らんでいく。Anthropicのエンジニアチームは2025年11月の公式ブログで、ある実装の変更だけでトークン消費を150,000から2,000に削減できたと報告した。変更点は1つだ。すべてのMCPツール定義を起動時にコンテキストへ読み込む代わりに、ファイルシステム上に配置してエージェント自身が必要なときだけ読む方式に切り替えた。

この記事でわかること：

  • なぜ従来のMCPクライアント設計がスケールしなくなったのか
  • Anthropicが提案する「ファイルシステム as コード API」の仕組み
  • VercelとManusが同時期に同じ方向へ向かっている理由
  • 新しいアプローチで生まれる課題と注意点
Code execution with MCP: building more efficient AI agents
Learn how code execution with the Model Context Protocol enables agents to handle more tools while using fewer tokens, r…
www.anthropic.com

従来のMCPクライアントが抱えるトークン問題

MCPはAIエージェントと外部ツールを繋ぐオープンプロトコルだ。2024年11月のリリース後、急速に普及し、今では数千のMCPサーバーが存在する。しかし普及に伴って構造的な問題が表面化してきた。

問題の原因は2つある。まずツール定義の量だ。現在の一般的なMCPクライアントは接続しているすべてのサーバーのツール定義を起動時にコンテキストウィンドウへ一括読み込みする。Google DriveやSalesforceなど数十のサーバーに接続すると、その時点でツール定義だけで数万〜数十万トークンを消費する。モデルはユーザーのリクエストを読む前に膨大な定義を処理しなければならない。

次に中間結果の問題だ。たとえばGoogle Driveから会議の議事録を取得してSalesforceのレコードに添付する場合、従来の方式では議事録のテキストがコンテキストを2回通過する。最初にGDriveから取得した結果として、次にSalesforceへ書き込む引数として。2時間の会議の議事録なら50,000トークン以上がこの往復で消費される。

ファイルシステムをコードAPIとして使う

Anthropicが提案する解決策は、MCPサーバーのツールをコンテキストへ直接注入するのではなく、ファイルシステム上のTypeScriptファイルとして配置する方法だ。

servers/
├── google-drive/
│   ├── getDocument.ts
│   └── index.ts
├── salesforce/
│   ├── updateRecord.ts
│   └── index.ts

エージェントはタスクを受け取ると、まず ./servers/ ディレクトリを参照してどんなサーバーが使えるかを確認する。次に現在のタスクに必要なツールファイルだけを読み、TypeScriptコードとして実行する。先ほどの議事録転送は次のコードになる。

import * as gdrive from './servers/google-drive';
import * as salesforce from './servers/salesforce';

const transcript = (await gdrive.getDocument({ documentId: 'abc123' })).content;
await salesforce.updateRecord({
  objectType: 'SalesMeeting',
  recordId: '00Q5f000001abcXYZ',
  data: { Notes: transcript }
});

このアプローチで何が変わるかというと、中間データが実行環境の中だけで流れてモデルのコンテキストを通過しなくなる。エージェントが見るのは明示的にログや返り値として出力したものだけだ。Anthropicの計測では、すべてのツール定義を一括読み込みしていた場合の150,000トークンが2,000トークンまで落ちた。98.7%の削減だ。Cloudflareも同じアプローチを独自に検討し「Code Mode」と命名して同様の効果を確認している（参考）。

VercelとManusが同じ方向へ向かった理由

この動きはAnthropicだけではない。VercelとManusが同時期に独自の経路で同じ結論に達している点が興味深い。

Vercelは「ベクトルDBなし」を核心的な価値として打ち出した知識エージェントのテンプレートをオープンソースで公開した。エージェントはFirecrackerサンドボックス内でファイルシステム上の知識ベースを grep・find・cat で直接検索する。ベクトル検索と異なり結果が完全に決定論的で、同じクエリは常に同じ結果を返す。Vercelの計測では、sales call要約タスクのコストが1回$1.00から$0.25に下がった（参考）。

Manusはコンテキストエンジニアリングに関する公式ブログで「ファイルシステムは究極のコンテキスト」と明確に表現している。Manusのエージェントはコンテキストウィンドウに収めきれない情報をファイルパスとして保存し、必要なときに自分で読みに行く。この方式を「可逆圧縮」と呼んでいる。コンテンツ自体は失われず、参照パスだけがコンテキストに残る。ファイルシステム上への書き出しにより、100:1という極端な入出力トークン比が緩和される。

Tursoが開発するAgentFSはこの方向性をさらに推し進め、SQLiteバックエンドでPOSIX互換の仮想ファイルシステムを実装している。エージェントからは通常のファイルパスに見えるが、背後はSQLiteテーブルなので同じデータをSQLでも直接クエリできる。GitHubでは3,100スターを集め現在最も活発なエージェントファイルシステムプロジェクトになっている。

なぜ今この方向性が主流になりつつあるのか

背景には3つの条件が同時に成熟したことがある。

第一に、LLMはファイルシステム操作が得意だ。大量のコーディングタスクで訓練されているため、ls・grep・cat・findといった操作は追加のファインチューニングなしに自然に実行できる。これはツール定義を専用フォーマットで注入するよりも馴染みのある操作だ。

第二に、コンテキストのコスト構造が無視できなくなった。Claude Sonnetのキャッシュ済み入力は$0.30/MTok、未キャッシュは$3.00/MTokで10倍の差がある。ツール定義を何万トークンも毎回読み込む設計は、コストの大部分をここで使い切る。

第三に、LLMの注意機構と相性が良い。Anthropicが「Progressive Disclosure（段階的開示）」と呼ぶ考え方で、エージェントは最初にサーバー名だけ確認し、必要になったらツール定義を読み、さらに必要なら詳細ファイルを読む。コンテキストに最初から全情報を詰め込まないため、モデルの注意が必要な情報に集中しやすくなる。

注意点と残る課題

ファイルシステムアプローチには未解決の課題もある。

ひとつは「パス幻覚」と呼ばれる問題だ。エージェントが期待するパスが存在しない場合、LLMはそのファイルが存在するかのように振る舞ったり、新しいファイルを作成したりする傾向がある。ベクトル検索では語義的に近い内容を見つけられるが、ファイルシステムは正確なパスが必要なため、スキーマ変更に対して脆弱になる。

次にガベージコレクションの問題がある。ベクトル記憶では古い情報は自然に検索で上がりにくくなるが、ファイルシステムに書き込んだファイルは明示的に削除しない限り残り続ける。エージェントが長期間稼働するとスクラッチパッドや中間状態ファイルが蓄積し、何を削除すべきかを判断する仕組みが別途必要になる。

セキュリティも重要な懸念点だ。ファイルシステムへのアクセス権限と組み合わさると攻撃面が広くなる。2026年1月に報告されたClawHavoc事例では、悪意あるSkillがエージェントの環境変数ファイルやSSH鍵を読み取るという実被害が確認されている。

Vercelは純粋なbashとファイルシステムでは限界があることも正直に開示している。構造化クエリ（たとえば「先月売上が最も高い顧客は誰か」）では、SQLの正答率が100%なのに対しbash+ファイルシステムは53%しかなく、かつ7倍のトークンと6.5倍のコストがかかったと検証結果で示している（参考）。構造化データの取り扱いにはSQLが依然として必要で、ファイルシステムアプローチとの使い分けが求められる。

MCPとファイルシステムは対立しない

このトレンドをめぐってMCPが「格下げされた」という解釈も出ているが、Anthropicの公式ブログには「MCPは基盤プロトコル」と明記されている。MCPをファイルシステムに置き換えるのではなく、接続層（認証・サービス発見・通信）としてMCPを維持しながら、その上にファイルシステムを実行層として重ねる設計だ。

現在収束しつつある構成は3層になっている。最下層が接続層（MCP）で認証とリモートアクセスを担う。中間層が状態層（AgentFSのようなSQLiteバックのファイルシステム）でエージェントが慣れ親しんだファイルシステムインターフェイスを提供する。最上層が行動層（SkillsやTypeScriptコード）でエージェントの振る舞いを定義する。

Anthropicは同じ時期に、Agentスキルの設計としてもファイルシステムベースのアプローチを公開した。名前とdescriptionだけを最初に読み込み、マッチしたときに完全なSKILL.mdを読み、実際に必要になったときだけ付属ファイルを読む3段階の遅延読み込みだ。これはツール定義の遅延読み込みと同じ原理を、エージェントの行動定義にも適用したものだ。

コンテキストコストが運用コストの最大要因になった時点で、この転換は不可避だった。ファイルシステムは文字数制限のないコンテキストとして機能し、エージェント自身が必要な情報を引っ張る仕組みは、開発者が「何が必要か」を事前に予測する負担を大幅に減らす。