Anthropicの最新ブログ:MCPは死なず、我々が蘇らせた。

MCPは死んだ。CLI万歳。

2ヶ月前、Eric HolmesはMCPの終焉を定義した。LLMはもともとコマンドラインの扱いに長けており、プロトコルのような余計な層を被せるのは蛇足だというのだ。

なぜなら、MCPにはトークンコスト、サーバー起動のハングアップ、OAuth認証の繰り返されるポップアップ、オール・オア・ナッシングな権限設定...といった問題が山積していたからだ。Ericのこの見解には、ほぼ全員が強く同意していた。

そして今週、Anthropicは長文のブログを公開した。『Building Agents That Reach Production Systems with MCP(MCPで本番システムに到達するエージェントを構築する)』。このタイトルは直接的ではないが、翻訳するとこうなる。

「君たちの批判は正しかった。我々は修正し、MCPが本来何をすべきかを明確にした。」

Anthropicのブログイメージ図

EricがMCPの死を宣告した理由、それらは間違っていない

大規模モデルはCLIを生来使いこなせるので、MCPなど不要だ。

CLIコマンドが失敗しても、ターミナルで同じコマンドを実行すれば同一の出力が見られる。しかしMCPがエラーを吐いた場合、ログの状況は全く予測できない。

CLIには成熟したUnixパイプ連携機能もある。grep | jq | awk これは非常に強力で、MCPサーバーが容易に再現できるものではない。

CLIパイプラインの概念図

しかしAnthropicは言う、「君は半分しか見えていない」と

Anthropicはエージェントが外部システムに接続する経路を三つに分類した:

直接API呼び出し:単純なシナリオなら問題ない。しかし十数もの統合を積み重ねると、M×Nの組み合わせ爆発に誰も耐えられなくなる。

CLI:ローカル環境では確かに強力だ。だが致命的な制約がある。クラウド上のエージェント、モバイル端末、ウェブブラウザ上には、シェルが存在しないのだ。

MCP:標準化されたプロトコル。認証、サービスディスカバリ、リッチセマンティクスを内蔵。本番稼働するクラウドエージェントのために用意されている。

鍵は二番目の点にある。

エージェントがあなたのターミナル内でのみ動くなら、例えばClaude Codeがローカルでコードを書く手助けをするなら、CLIこそが最適解であり、議論の余地はない。しかし、エージェントがクラウド上で動くとしたら?ブラウザ内で動くとしたら?スマートフォンの中で動くとしたらどうか?

Claudeには現在、Cowork(クラウドコラボレーション)とManaged Agents(管理されたエージェント)がある。これらはあなたのMacのターミナルの中にはいない。それらは外部システムと接続するための標準化された方法を必要としている。そしてCLIはこれらの環境では全く動かない。

MCPはCLIを代替するために来たのではない。CLIの届かない場所をカバーするために来たのだ。

この位置付けが整理されれば、これまでの議論の大部分は自動的に解消される。

技術的改善点

今回、AnthropicはMCPに関するいくつかの改善策を提示した。

ツール検索(Tool Search)—— ツールのオンデマンドロード

これまでMCPが最も批判されてきた問題の一つ:サーバーがたくさんのツールを登録し、全スキーマをコンテキストウィンドウに詰め込むため、ツールが増えるとトークンが爆発的に増加する。

新しい方式はオンデマンド検索だ。ユーザーの意図に基づき、必要なツールだけを動的にロードし、無関係なものは一切ロードしない。

ツール検索の仕組みを示す図

これにより得られた成果:ツール定義のトークン消費が85%以上削減された。

プログラム的ツール呼び出し(Programmatic Tool Calling)—— サンドボックスで処理してから返す

もう一つの痛点:エージェントがツールを呼び出した後、生のJSONを全量コンテキストに戻すため、大量のゴミ情報がトークンを占有していた。新方式では、コードサンドボックスでまずフィルタリングと集計を行い、モデルには有用な情報だけを渡す。

これにより得られた成果:複雑なワークフローにおけるトークン消費が約37%削減された。

プログラム的ツール呼び出しの概念図

スキル + MCP = シェル

スキルはエージェントに「どうやるか」(プロセス知識)を教え、MCPはエージェントに「何を使うか」(ツール接続)を提供する。両者はプラグインとしてパッケージ化され配布される。

スキルとMCPの連携プラグイン図

例えば、Kubernetes運用プラグインの場合:スキルにはトラブルシューティングのフローとベストプラクティスが記述され、MCPはkubectlツールを提供する。エージェントはそれをインストールするだけで稼働できる。

将来的には、MCPサーバー自身がスキルをバンドルし、クライアントは接続するだけで自動的に操作知識を獲得できるようになるだろう。

月間3億回のダウンロード。これで「死んだ」と言えるか?

ブログの中で一つの数字が挙げられていた。MCPは現在、月間3億回以上ダウンロードされている

MCPのダウンロード統計を示すグラフ

これだけ批判されながらも、利用者は増え続けている。

つまるところ、事実は確かにそうだ。CLIはローカルシナリオでは確かに快適だが、あなたのエージェントがクラウドに上がる必要があり、クロスプラットフォームである必要があり、十数ものSaaSと連携する必要があるなら、MCP以外に、標準化された選択肢としてより良いものはない。

これはかつてのREST対GraphQLの論争に少し似ている。GraphQLが出た当初も「HTTPで十分じゃないか、なぜこんなに複雑にするんだ?」と批判された。結果はどうだ?複雑なシナリオでは、いまだに使われ続けている。

最後に

結果論から見れば、「MCP is dead」という論争は良いことだった。なぜなら、それがAnthropicに自らの位置付けを明確にさせる原動力となったからだ。

MCPは万能ではなく、クラウド上の本番稼働エージェントのための標準化された接続レイヤーなのだ。

ローカルシナリオでは、CLIを適切に使えばいい。誰も止めはしない。

ある技術的解決策がコミュニティから猛烈に疑問視されることは、必ずしも悪いことではない。少なくとも、誰にも使われないまま独りよがりに開発を進めるよりは、ずっとましだ。

関連記事

分享網址
AINews·AI 新聞聚合平台
© 2026 AINews. All rights reserved.