【緊急】MCP懐疑論が爆発！「ただのオーバーヘッド」と断じる現場エンジニアの反乱と、エージェントをハメる構造的罠『The Maze』の衝撃

【序文：熱狂の終わりの始まり】
以前、4月21日の放送で「AIエージェント開発におけるRaw Pythonへの回帰」という現象をお伝えしましたが、この動きは今、さらに深刻かつ過激なフェーズへと突入しています。今回、コミュニティの批判の矛先が向けられているのは、AnthropicがAIエージェントの標準プロトコルとして強力にプッシュしてきた「MCP（Model Context Protocol）」そのものです。2026年現在、AI開発の現場では「MCPは本当に必要なのか？」「ただのオーバーヘッドではないか？」という逆張り議論が、Hacker NewsやRedditを舞台に炎上。さらに、最新の論文ではMCPの構造的な脆弱性を突いた攻撃手法まで公開され、MCPを盲信する開発者たちに冷や水を浴びせています。

【事象の全貌と背景：標準化という名の幻滅】
事の発端は、AIエージェントに外部ツール（Google Drive、Slack、GitHubなど）を接続するための「共通言語」としてMCPが普及し始めたことにあります。当初、開発者たちは「一度MCPサーバーを書けば、あらゆるクライアントでツールが使える」という夢の汎用性に酔いしれました。しかし、実装が進むにつれ、現場のエンジニアたちはある冷酷な事実に気づき始めました。Hacker Newsの議論（Result 1）で「whoknowsidont」氏が指摘するように、「LLM自体はMCPのことなど何も知らない」のです。

実際には、MCPは単に「ツールの説明（JSON）をプロンプトのコンテキストに無理やりねじ込んでいる」だけに過ぎません。主要なLLM（ClaudeやGPT-4/5）が学習されているのは「関数呼び出し（Tool Calling）」であって、MCPという特定のプロトコルではありません。この「標準化」という美名の下に隠された、不必要な抽象化レイヤーとマーケティング主導のハイプに対し、ギークたちの怒りが爆発しているのです。

【技術的ディープダイブ：トークン浪費と構造的罠】
なぜMCPは「有害」とまで言われるのか。その技術的理由は、Anthropic自身もエンジニアリングブログで認めている「スケーリングに伴うコストとレイテンシの増大」にあります。MCPサーバーが提供するツールが増えれば増えるほど、エージェントはリクエストを一行読む前に、数十万トークンもの「ツールの説明文」を処理しなければなりません。これは純粋なコンテキスト汚染です。

さらに深刻なのが、中間結果のトークン消費です。例えばGoogle Driveから議事録をダウンロードし、Salesforceに添付するタスクを考えます。MCP経由では、エージェントは一度数万トークンの全文を自身のコンテキストに読み込み、それを再びSalesforceのツール呼び出しに書き出す必要があります。2時間の会議録であれば5万トークン以上が2回流れ、コストは跳ね上がり、ハルシネーション（情報の取り違え）のリスクも倍増します。

これに対し、前回の放送でも触れた「コード実行（Pythonスクリプト生成）」アプローチは圧倒的に効率的です。LLMに直接コードを書かせれば、中間データはメモリ内で処理され、最終結果の数十トークンだけがLLMに戻されます。Hacker Newsでの議論（Result 1）でも、「依存関係グラフをソートするタスクをMCPで行うのは無謀だが、Pythonを書かせれば1分で正確な結果が出る」という具体例が挙げられています。

また、arXivに投稿された最新論文（Result 2）は、MCPの構造的な脆弱性『The Maze（迷宮）』を暴露しました。これは「構造的攻撃」と呼ばれ、エージェントに偽の引用グラフやリンクを提示することで、無限ループや予算切れ（ステップ数上限）までエージェントを彷徨わせる手法です。実験では、GPT-4oが94.6%という驚異的な確率でこの罠にハマり、リサーチ予算の半分を無駄に浪費したことが報告されています。MCPのように「ツールが提示する情報を盲信する」プロトコルこそが、この脆弱性を助長しているのです。

【コミュニティの生々しい熱量：Brawndoと電解質】
コミュニティでの議論は、技術論を超えて哲学的な域に達しています。あるユーザーは映画『イディオクラシー』を引き合いに出し、MCPを「Brawndo（スポーツ飲料）」に例えました。「植物はBrawndoを欲しがっている。なぜなら電解質が入っているからだ。電解質とは何か？ それはBrawndoに入っているものだ」という循環論法です。つまり、「MCPは標準だから使う、標準だからMCPなのだ」という思考停止への皮肉です。

一方で、Reddit（Result 3）では、MCPを使いつつも、より軽量な「Skills」や、あらゆるモデルをClaude Codeに接続できる「Claudish」などの代替案を模索する動きが見られます。しかし、共通しているのは「重厚長大なフレームワークはもういらない」という感覚です。凄腕のエンジニアほど、Makefileやbashエイリアス、シンプルなREADME.mdをエージェントに読ませるだけで「十分だ」と断言し始めています。彼らにとって、MCPは「非エンジニアにツールを売るためのパッケージ」に過ぎず、真のパワーユーザーにとっては足枷でしかないのです。

【今後の展望とエコシステムへの影響：プロトコルの死か、進化か】
今後、AIエージェントのエコシステムはどう変化するのでしょうか。一つのシナリオは、MCPが「GraphQL」と同じ道を辿るというものです。特定のユースケース（リモートサービスの統合など）では有用ですが、万能の解決策としては否定され、よりシンプルで「コードに近い」形式に取って代わられるでしょう。Anthropicが提唱する「Skills」のように、Markdownベースで必要な時だけコンテキストに読み込まれる、よりオンデマンドな仕組みへの移行が予想されます。

また、今回のarXivの論文が示したように、今後は「エージェントの堅牢性（Robustness）」が最重要課題となります。「ツールは嘘をつくかもしれない」という前提に立ち、MCPのような疎結合なプロトコルではなく、サンドボックス内でのコード実行による「自己検証型エージェント」が主流になるはずです。2026年、私たちは「AIに何でもやらせるフレームワーク」を卒業し、「AIに正しいコードを書かせて制御する」という、より古典的かつ確実なエンジニアリングへと回帰しているのかもしれません。大手ベンダーが主導する「標準化」の波に対し、現場のエンジニアたちが突きつけたNOは、AI開発のパラダイムを再び「シンプルさ」へと引き戻そうとしています。