MCP is Dead — MCPの何が問題で、何が生き残るのか

「MCPはゴミだ」——Y Combinator CEOのGarry Tanが、そう言い放ちました。

MCPとは、Model Context Protocolの略。AnthropicがClaude Code向けに設計した、AIと外部ツール（Gmail、GitHub、データベースなど）をつなぐための標準プロトコルです。2024年後半に発表され、瞬く間にAI開発者の間に広まりました。OpenAI、Google、Microsoft、AWSも採用。Linux Foundation傘下に入り、業界標準になるかと思われていました。

ところが2026年に入り、風向きが変わっています。

「MCP is dead. Long live the CLI」——開発者のEric Holmesはそう宣言しました。コミュニティでは「MCPは銀の弾丸ではなかった」という認識が広がりつつあります。

自分はClaude Codeで10以上のMCPサーバーを同時接続して日常的に運用しています。serena（コード解析）、Playwright（ブラウザ操作）、Gmail、Google Analytics、context7（ドキュメント検索）。この記事自体、MCPを使った自動パイプラインで拾ったネタから生まれています。

だからこそ見えるものがあります。MCPの何が本当に問題で、何がそれでも生き残るのか。

問題1: トークン膨張——最大の実害

MCPの最も深刻な問題は、使うだけでAIの「思考容量」を食いつぶすことです。

AIにはコンテキストウィンドウという制約があります。人間でいえば、一度に考えられる情報量の上限のようなもの。MCPサーバーを接続すると、そのサーバーが提供するツールの仕様書（スキーマ）が、AIの会話に自動で注入されます。

たとえばGmailのMCPサーバーを接続すると、「メール検索」「メール取得」「ラベル一覧」といったツールの定義が、使う前から会話の中に埋め込まれます。1つのサーバーだけなら大した量ではありません。でも、4つ接続すると67,000トークンが消費されます。

これがどれくらいかというと、ちょっとした短編小説1冊分です。AIがまだ何も考え始めていない段階で、です。

MCPGAUGEという研究では、MCPサーバーを使うと入力トークンが3.25倍から最大236.5倍に増加し、AIの精度が平均9.5%低下すると報告されています。Claude Codeの公式リポジトリでも「MCPツールがコンテキストの50%を消費する」という問題が報告されました（Issue #13717）。

Anthropicは後からTool Search機能を追加し、51,000トークンから8,500トークンへ46.9%の削減を実現しました。改善は進んでいます。しかし根本的な構造——「接続するだけでスキーマが注入される」——は変わっていません。

自分のCLAUDE.mdにも、早い段階で「MCPは必要なものだけ有効化する」というルールを追加していました。10以上接続していると、使わないツールの定義だけでコンテキストが圧迫されて、長い会話の後半で前半の指示を忘れる事故が起きていたからです。経験則として体感していた問題に、研究が数字を与えてくれた形です。

問題2: ダブルホップ遅延

MCPは「AIとツールの間にサーバーを挟む」アーキテクチャです。つまり、AIがGmailのメールを取得したいとき、直接Gmail APIを叩くのではなく、まずMCPサーバーに依頼し、MCPサーバーがGmail APIを叩き、結果をMCPサーバー経由で返す。2段階のネットワーク往復が発生します。

1つの操作なら気にならないかもしれません。でもAIは1つの問いに対して何十回もツールを呼びます。メール20通を処理するなら、検索→取得→分類を繰り返します。そのたびに2段階の往復が積み重なる。体感では「なんか遅いな」というレベルですが、バッチ処理では明確にボトルネックになります。

問題3: デバッグの困難さ

CLIツールなら、コマンドを1つ叩いて出力を確認できます。curl でAPIを叩いて、レスポンスを jq で整形して、意図どおりの結果が返ってきているか確認する。壊れたら、どこで壊れたかが見える。

MCPツールはそうはいきません。ツール呼び出しはAIの会話の内部でしか実行されません。独立して動作確認することが難しい。問題が起きたとき、AIが間違った入力を送ったのか、MCPサーバーのハンドラにバグがあるのか、外部APIが変わったのか。切り分けにはJSON-RPCトランスポートのログを解析する必要があります。

これはDXとして明確に退化しています。

問題4: セキュリティの重大欠陥

ここまでは「使い勝手が悪い」という話でした。セキュリティの問題はもっと深刻です。

公開されているMCPサーバー119台を対象にした調査で、全台が認証なしでアクセスを許可していることが判明しました。さらに43%にコマンドインジェクションの脆弱性が見つかっています。

2026年4月時点で、リスクのあるサーバーは約20万台に達しているとの推計もあります。Anthropicはこの状況について「想定された動作」として仕様変更を拒否しました。

つまり、セキュリティはMCPサーバーの作者に完全に委ねられている状態です。npmパッケージのセキュリティ問題と構造が似ています。利便性とリスクが、エコシステムの規模に比例して膨らんでいく。

問題5: 合成可能性の欠如

Unixの設計思想に「小さなプログラムをパイプでつなぐ」という原則があります。curl でデータを取って、jq で加工して、grep でフィルタする。各ツールは単機能で、組み合わせて複雑な処理を実現する。

MCPツールにはこの合成可能性がありません。あるMCPツールの出力を、別のMCPツールの入力に直接渡す仕組みがない。すべてAIを経由する必要があります。AIが中間者として毎回介在するので、処理がリニアになり、パイプラインのような効率的な連結ができません。

CLIなら1行で書ける処理が、MCPだとAIが何往復もする必要がある。これが「MCP is dead. Long live the CLI」という声の背景です。

それでもMCPは死んでいない

ここまで問題を並べました。ではMCPは使い物にならないのか。

結論を先に言うと、「死んではいないが、万能の地位は失った」が正確な評価です。

まず事実として、MCPはLinux Foundation傘下に入り、OpenAI、Google、Microsoft、AWS、Cloudflareが採用しています。エコシステムとしての勢いは健在です。死んだプロトコルにビッグテックは乗りません。

そしてMCPが不可欠なユースケースは確かに存在します。

リアルタイムな双方向通信が必要なケース。たとえばPlaywrightを使ったブラウザ操作。ページ遷移のたびにスナップショットを取得し、状態に応じて次のアクションを決める。この「状態を保持しながら対話する」パターンは、ステートレスなCLIコマンドでは実現が難しい。

認証状態の管理が必要なケース。Gmail MCPは一度OAuth認証を通せば、以降のセッションで再認証なしにメールを操作できます。CLIスクリプトでこれをやると、トークン管理のコードを自分で書く必要があります。

複雑なスキーマを持つAPIのケース。Google AnalyticsのようにAPIの引数が多岐にわたる場合、MCPサーバーが引数の組み立てを隠蔽してくれるのは実用的です。

自分の運用でも、Playwright・Gmail・Google Analyticsはまだ明確にMCPの方が便利で、CLIに移行する気はありません。一方、ファイル操作やgit操作のような単発コマンドは、最初からCLI（Bash）で十分です。

これからの使い分け

MCPは「銀の弾丸」から「選択肢の一つ」に降格しました。ではどう使い分けるのか。

この判断基準は「状態を持つか」と「合成可能性が必要か」の2軸で整理できます。状態を持ち、単独で完結する操作はMCP向き。状態を持たず、他のツールと組み合わせたい処理はCLI向き。

読者がいま取るべきアクション

もしあなたがMCPサーバーを5つ以上接続しているなら、まず「本当に常時接続が必要か」を見直してください。使わないMCPサーバーの接続を外すだけで、トークン消費が劇的に減り、AIの応答精度が上がります。

もしMCPサーバーの自作を検討しているなら、「CLIスクリプトで代替できないか」を先に考えてください。シェルコマンドで完結するならそちらの方がデバッグしやすく、合成可能で、トークンコストもゼロです。

MCPが向いている領域は明確に存在します。問題は、MCPが「とりあえずの正解」として選ばれすぎていたことです。技術選定に銀の弾丸はありません。それはMCPも例外ではなかった、という当たり前の話に、業界がようやく追いついたのだと思います。