Anthropic提唱のMCP不要論：LLMが直接APIを叩く開発への移行

• 事実と背景：2024年11月リリースのMCPは、モデル進化に伴いContext Bloat（文脈肥大化）を引き起こすボトルネックと化した。
• 技術的変革：LLMのコード実行能力向上により、MCPラッパーを排してCLIの–helpや直接HTTP APIを操作する構成へシフト。
• 現場への影響：無駄なMCPサーバーを廃止し、Accept: text/markdownなどの標準ネゴシエーションを活用したAPI設計への移行が必要。

深夜の障害対応中、開発者が直面するのはスパゲッティコードの解読だけではない。最近のAIエージェント開発の現場で我々エンジニアを苦しめているのは、エージェントに良かれと思って与えた大量のツール定義が引き起こす「Context Bloat（文脈肥大化）」という名のデッドロックだ。プロンプトのトークン上限は上がり続けているものの、膨大なJSON Schemaがコンテキストウィンドウを無駄に圧迫し、本当に必要なモデルの推論能力を削ぎ落としてしまう現象に、私自身も深い強い危機感を抱かざるを得ない。

振り返れば、Anthropicが2024年11月25日に「Model Context Protocol（MCP）」を発表した当時、そのアーキテクチャは彗星のごとく現れた救世主に見えた。当時のLLM（Claude 3.5 SonnetやGPT-4oクラス）はまだ外部環境との自律的な接続において危うさを残しており、外部データベースやSaaS機能と安全に通信するための統一インターフェース（MCP）が必要不可欠だったのだ。MCP普及の波は凄まじく、2025年12月9日にAnthropicがMCPをLinux Foundation傘下の「Agentic AI Foundation」へ寄贈する頃には、業界標準としての地位を確立したかのように見えた。

しかし、MCPエコシステムが「MCP産業複合体」とも呼ぶべき肥大化を遂げるにつれ、我々は本末転倒な技術的負債を抱え込むことになった。開発者はGitHubやSlack、Jiraなどの外部サービスごとに専用のMCPサーバーを立ち上げ、ローカル環境やクラウド環境で何十ものサーバーを並行稼働させるようになった。その結果、モデルが1回の推論を行うたびに、各ツールが提供する巨大なスキーマ群がプロンプトへ強制注入され、モデルの思考精度が低下するという皮肉な事態が発生したのである。ComposioやMintMCP、Pipedreamといったプラットフォームがツール選択の最適化や認証の一元管理という対症療法を提示したものの、これらは「賢くないモデル」を前提に作られた過剰な中間レイヤーに過ぎなかったのだと、私は考えている。

我々エンジニアが直面している最大の地殻変動は、ミドルウェアの進化ではなく「LLMそのものの推論・実行能力の爆発的進化」である。Claude Codeに代表される最新のエンジニアリング指向モデルや、自律的ターミナル操作の精度向上は、従来の前提を根底から覆した。モデルは今や、与えられたAPIの仕様を理解するために静的なMCPスキーマを必要としない。ターミナル環境へのアクセス権さえあれば、コマンドに --help フラグを付けて実行し、その場で出力されたマニュアルを自律的に解釈してコマンドを組み上げることができるのだ。

この技術的転換点を鮮やかに象徴するのが、Cloudflareが2025年9月26日に発表した「Code Mode」である。CloudflareはMCPをそのまま使うのではなく、安全なサンドボックス環境内でLLMに複数のAPI呼び出しやツール操作を統合する「実行可能なJavaScript/Pythonスクリプト」を直接記述させ、それをまとめて実行する手法を提示した。毎回MCPサーバーと往復しながら状態を管理する無限ループのような通信を排し、コードとしてロジックをカプセル化して一括実行する方が、ネットワークレイテンシの観点でもトークン消費量の観点でも遥かに効率的であることは火を見るより明らかだ。

世の中に存在するほとんどのリモートサービス向けMCPサーバーの実体は、既存のREST APIやgRPC、CLIツールの薄いラッパーに過ぎない。モデルが未見のWeb APIドキュメントを自力で読み込み、curl や自作スクリプトを用いて直接認証・データ取得を完結できるようになった現在、重厚長大化したMCPサーバーというミドルウェアを介在させる必然性はどこにあるのだろうか。我々は「過去のモデルの愚かさ」を前提に構築された過飾な中間層を今すぐ脱ぎ捨てるべき時を迎えている。

MCPという独自プロトコルの迷宮から抜け出した先にあるのは、まったく新しい技術ではなく、我々が30年以上磨き上げてきた「Webの標準プロトコル（HTTP）」の再発見である。エージェントがサービスを利用するために必要なのは、新奇なプロトコルではなく、エージェントにとって最適化されたデータ構造と既存の堅牢なHTTPメカニズムの組み合わせだ。下表は、従来のMCP主導型アーキテクチャと、今後主流となる直接HTTP/CLI連携アプローチの技術特性を比較したものである。

現在、先進的なWebエコシステムで急速に広がりを見せているのが、HTTPのコンテンツネゴシエーション機能を活用した「エージェント・フレンドリーなWeb」の構築だ。クライアントが Accept: text/markdown ヘッダーを送信することで、サーバー側は過剰なHTMLタグや装飾を削ぎ落とした、モデルが最も理解しやすいMarkdown形式のテキストを直接返却する仕組みが定着しつつある。

さらに興味深いトレンドとして、VercelのエンジニアであるMalte Ubl氏が提唱し、ShopifyのCEOであるTobi Lütke氏が自社ドキュメントへの即時導入を決断した Accept-Language ヘッダーの応用例が挙げられる。エージェントがリクエスト時の Accept-Language に Python や TypeScript といった優先プログラミング言語を指定することで、サーバー側は汎用的な説明を省き、その言語に特化したコード例やSDK仕様のみをピンポイントでレスポンスする。独自プロトコルを新規構築せずとも、HTTP規格の枠組みを正しく使うだけで、エージェントの処理精度と通信効率は飛躍的に向上するのだ。

MCPという過剰なミドルウェアの時代が終わりを迎える中で、我々ソフトウェアエンジニアやシステムアーキテクトは、自らの開発現場でどのような処方箋を講じるべきなのだろうか。過去のパラダイムに固執し、動かなくなったMCPサーバーのデバッグに深夜まで追われるような不毛な労力からは、今すぐ脱却しなければならない。

まず行うべき実践的なアプローチは、現在運用しているMCPサーバーのスクラップ＆ビルドだ。安全なコンテナ環境やターミナルアクセス権限をエージェントに与え、既存のCLIツールやdocumentedなREST APIを直接叩かせる構成へ切り替えること。これだけで、コンテキストウィンドウの消費量は劇的に削減され、エージェントの推論速度と自律性は見違えるほど向上する。もちろん、CLIが返却する巨大なJSONやXMLデータがトークンを圧迫するという課題は残るが、それは jq や軽量なパイプライン処理スクリプトをエージェント自身に書かせることで容易に回避可能だ。

そして、自社プロダクトやAPIを提供する側に立つエンジニアへの処方箋は、新規のMCPサーバーを開発・公開するのをやめ、自社のWebサーバーを「エージェント対応（Agent-Ready）」に改修することである。Accept: text/markdown への対応や、コンテキストを最小化するレスポンスヘッダーのサポートこそが、これからのAI時代における真のAPI標準となる。

最後に、我々技術コミュニティ全体に痛烈な問いを投げかけたい。我々は「昨日の賢さレベル」で作られた複雑なプロトコルや枠組みに縛られ、最新モデルが持つ潜在能力を自ら箱に閉じ込めてはいないだろうか？ 過去の過渡期に生まれた技術に盲従するのをやめ、Webの原点であるシンプルで堅牢なプロトコルへ回帰する準備は、もう整っているはずだ。