MCPは死んだのか？

2026年5月30日原文(quandri.io)

概要

MCP（Model Context Protocol） は、LLMと外部ツールを接続する仕組みだが、 コンテキスト消費量・信頼性・CLI/APIとの重複 が課題
Claude Codeの「Tool Search with Deferred Loading」 導入で、コンテキスト問題は大幅に改善
それでも パフォーマンス・デバッグ・設計上の問題 は残る
CLIファースト戦略 や Skillsパターン が現実的な代替案
用途や状況でMCP/CLI/Skillsを使い分け るのが現場での最適解

MCPの問題点と現状

MCP（Model Context Protocol） は、LLMとGitHub、Linear、Notion、Slackなどの外部ツールを接続するプロトコル
2024年後半の登場以来、「AIエコシステムのUSB-C」 と称賛されてきたが、実運用では評価が分かれる
主な課題 は「コンテキスト消費量」「運用信頼性の低さ」「既存CLI/APIとの重複」

問題1：コンテキストウィンドウの圧迫

MCPツール定義 がコンテキストウィンドウ（LLMの作業領域）を大量消費
レストランの例え ：テーブルに10冊のメニュー（ツール定義）が常時並び、料理（実作業）のスペースが減る
実測では 4サーバー接続時、10.5%のコンテキスト がツール定義だけで埋まる
特にLinear は42ツール定義で約12,800トークン消費。実際に使うのはごく一部でも全定義が常時ロード
- Linear: 42ツール、約12,807トークン
- Notion: 14ツール、約4,039トークン
- Slack: 12ツール、約3,792トークン
- Postgres: 9ツール、約438トークン

問題2：運用信頼性の低さ

初期化失敗・再認証要求・プロセス管理 など、運用負荷が高い
毎回外部サーバー経由 でAI応答が遅くなる
MCPサーバーのクラッシュ やセッション中断も発生しやすい
権限管理の不透明さ も課題
パフォーマンス比較 ：Jira MCPはREST API直接利用の3倍遅く、初回は9.4倍遅い（全てのMCPサーバーに共通する構造的問題）

問題3：CLI/APIとの重複

CLIやAPI は人間もLLMも同じコマンドを使え、デバッグも容易
MCPはLLM会話内に限定され、自由度が低い
インストールコスト もCLIは既に導入済みが多いが、MCPはサーバー構築や認証管理が必要
トークン消費比較（Linear Issue Lookup）
- CLI：コマンド＋レスポンスで約200トークン
- MCP：ツール定義＋レスポンスで約12,957トークン（CLIの約65倍）

代替案：CLIファースト戦略とSkillsパターン

CLIファースト戦略 ：CLI→API→ドキュメントの順でLLMに提供
- 既存CLIならコンテキスト消費ゼロ、デバッグ容易、パイプライン構築も自由
Skillsパターン ：必要なときだけツール定義をロード
- MCPが「全メニューを常に広げる」のに対し、Skillsは「必要な本だけ司書に頼む」方式
- コンテキスト消費が必要最小限で済む
CLI使用法をSkillsに埋め込み、CLIファースト戦略と組み合わせるのが最も効率的
- 例：Linear Issue Lookup SkillにcurlコマンドとAPIエンドポイント、認証方法を記載
- 必要時のみロード、42ツール定義を常時保持不要

MCPの使い所とデータベース運用

MCPが有効なケース
- CLIが存在しないサービス（Web専用SaaS等）
- 非開発者ユーザー（ターミナルを使わない層）
- リアルタイム双方向通信が必要な場合
データベースは状況次第
- LLMはSQLやMongoDBクエリを既に習得、スキーマとCLI使用法をSkillsで補完可能
- MCPはクエリ安全性（read-only enforced等）や認証情報保護で有利
- ローカル開発や個人用DB→Skills＋CLIが軽快
- 本番DBやチーム共有→MCPによる安全管理が推奨

現場での最適な使い分け（Quandri事例）

Bash＋CLI ：日常的に使うツール（gh、psql、aws等）はこれ一択。コンテキスト消費ゼロ、柔軟性・デバッグ性抜群
Skills ：コミット作成やPRレビュー等、繰り返し手順化できるワークフロー
MCP ：CLIが弱いサービス（Slack、Linear、Notion）、チーム単位の認証・権限管理が必要な場合
状況に応じて柔軟に選択、CLIがあれば原則それを優先

結論

MCPをSkills＋CLIで置き換えることで、約21,000トークンのコンテキスト削減・運用トラブル減・デバッグ性向上 を実現
必要なツールだけ、必要な時だけロード し、CLI手順をSkillsに埋め込むのが現時点の最適解
MCPは今後進化する可能性もあるが、現状はSkillsが優勢

測定方法

実際に稼働中のMCPサーバーからツール定義（JSONスキーマ）を抽出
トークン数は「約4文字＝1トークン」換算で推計
全サーバーの合計値はサンプル平均から外挿

Hackerたちの意見

思い出せなくて自分を叱りたいけど、すごく良い記事があったんだ。MCPは、統一された安全な内部ユーティリティAPIへのアクセスが、内部のエージェントツールを使う非技術者に与えられると、組織レベルで機能するって提案してたんだよ。ワークフローをスキルとしてコード化して、インスタンス間で共有するべきだし、コンテキストに応じたAPIアクセスが必要なものはMCPを使うべきだね。

└

その通り！Runlayerみたいな会社は、まさにこの理由で急成長してる。中央制御プレーンがないと、MCPは地雷原みたいなもんだよ。

└

これのこと？ https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/

└

これはAPIを保護するための権限を使う代わりなの？だって、APIには何らかの権限メカニズムが必要な気がするんだけど。

└

でも、エージェントがAPIに直接アクセスするのと比べて、MCPの利点って何なの？

記事には日付が書いてないけど、遅延ツール読み込みが最近の更新だって書いてある。遅延ツール読み込みは2025年11月に追加されたんだって：https://www.anthropic.com/engineering/advanced-tool-use だから、この数字は少なくとも7ヶ月古いよ。なんで今これが投稿されてるの？

└

遅延ツール読み込みはMCPの一部じゃないよ。これはClaude APIの特別なパラメータで、他のほとんどのLLM APIはサポートしてない。

└

+1 まだこれについて話してる人がいるなんて、マジで信じられない。もう古い話だよ。遅延ツール読み込み、大きなコンテキスト、プロンプトキャッシングのおかげで、2026年は2025年とは全然違う。あと、「CLIがトークンを節約する」って議論は、CLIを使う第一歩が「--help」を実行することだと考えると、成り立たないよ。問題は残る：そのものを呼び出す方法がパラメトリックメモリにないなら、コンテキストに入ってなきゃいけない。

└

それよりも古いね、GPT-4oが現行だって意味だから。

これAIが書いたの？MCPは基本的に特定のフィールドがいくつか必要なJSON RPCに過ぎないと思う。JSON RPCには懸念があるけど、LLMがインターフェースするための「サービス発見」レイヤーが必要だよね。それはウェブサイトやデスクトップアプリ、バックエンドサービスなどで利用できる必要がある。CLIはこれらのシステムがインターフェースする場所の一つに過ぎない。MCPを何に置き換えても、異なる通信プロトコルやツール発見のための異なるフィールドを指定しても、似たような形になると思うよ。

└

それがコンテキストを比較的永続的に占有する方法で、いいインストール/アンインストールや発見機能がないのが問題なんだ。「スキル」はすべてMCPに基づくべきで、オンデマンドで読み込まれ、人間やAIが非常に簡単に管理できて発見できるようになれば、うまくいくと思う。適用の仕方を考えると、範囲が狭すぎたんだよね。もしその上に何かレイヤーを追加すれば、復活する可能性もあるかも。

私はOpenAIでChatGPTアプリストアやCodexプラグイン、MCPに関するチームを運営してるんだ。この「MCPは死んだ」って投稿が見落としてるのは、MCPがトランスポートプロトコルとして使われるかどうかは実際には全く関係ないってこと。MCPが死んでない理由は、実際に地球上のほぼすべての会社がMCPサーバーを構築してるからなんだ。私たちはそれらの会社とやり取りしてるから知ってるよ。ほとんどの会社にはCLIがないし、外部APIすら持ってないところも多い！それでも、みんなMCPサーバーを作ってるんだ。だからMCPは死んでないどころか、今まで以上に重要なんだよ。もしかしたら、すべてのMCPサーバーを内部でCLIに変えるかもしれないし、コードモードを使うかもしれないし、ツール検索を実装するかもしれない。どれも重要なポイントに対する実装の詳細に過ぎないんだ。私たちのAIエージェントが、そうでなければアクセスできなかったサービスにアクセスできるようになることが大事なんだよ。それが重要なんだ。だから、MCPはモデルが直接コミュニケーションするためのレイヤーとして死んでるのか？もしかしたら、そうかもしれないし、そうじゃないかもしれない。MCPはプロトコルとして死んでるのか？全然そんなことないよ、真実からは程遠い。 [0]: ただ、Codexアプリのコンピュータとブラウザの使用機能が、この発言を以前よりもかなり弱くしてるのは確かだね。まだ試してないなら、ぜひ試してみて。驚くほどすごいから。

Hacker Newsで議論の続きを見る

ハクソク