
2026/05/30 7:56
MCP が終わったのか?
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
Claude Code の最近のアップデート、特に**「遅延読み込みによるツール検索(Tool Search with Deferred Loading)」により、文脈使用量が 85% 以上大幅に削減され、「文脈の膨張(context bloat)」という歴史的課題が実効的に解決されました。かつては接続された MCP サーバーが莫大な文脈を消費しており(例:Linear 単独で未使用のツール定義に約 12,800 トークンを費やす)、これにより応答速度が遅くなり、安定性の問題が生じていました。完全な置換が必要とは限りませんが、戦略的なハイブリッドアプローチが現在では最適です。既存の CLI コマンド(
、gh
など)や呼び出し時にのみ読み込まれる「スキル(Skills)」をローカルワークフローまたは日常タスクに活用することで、より高い効率性と人間と機械のパリティを実現できます。この「必要なものだけをロードする」という戦略により、大量のツールセットを事前に読み込ませた場合と比較して、セッションあたり約 21,000 トークンの文脈使用量を削減します。業界全体は MCP をプロダクション環境**に限定して利用すべきであり、そこで標準化されたチーム認証およびクエリの安全性が必須となるべきです。一方、個人開発やローカル開発には CLI やスキルを用いて速度と文脈容量を最大化するべきです。psql
本文
MCP の行方:CLI が勝利した理由と Quandri の検証結果
📌 更新情報
本記事が執筆・計測されている以降、以下の変更点が発生しています。
- Claude Code は「Deferred Loading(遅延読み込み)」付きの Tool Search を導入
- メリット: MCP ツールのスキーマがオンデマンドで読み込まれるため、コンテキスト使用量が 85% 以上削減
- 現状: コンテキスト肥大化の問題は大幅に解消されているが、パフォーマンスやアーキテクチャに関する本質的な議論は有効
🔍 MCP が抱える根本的な問題
MCP(Model Context Protocol)は LLM と外部ツールを接続するプロトコルですが、開発者からはその実用性が再評価されています。
結論のまとめ (TL;DR)
- 🚫 コンテキストを大量消費
- ⚠️ 信頼性が低い
- 🔄 既存の CLI や API と機能重複している
問題点 1:コンテキストウィンドウを飲み込み尽くす
LLM の「机」であるコンテキストウィンドウに、ツール定義だけで膨大なスペースが消費されます。
【レストランのアナロジー】
- テーブル上に 10 のメニュー(ツール定義) が広げられる
- 実質的な食事(作業)を入れる余地がない
- 毎回注文ごとにメニューを取り出す必要あり
計測結果:Quandri スタックでのツール定義サイズ
接続した全サーバーの合計で、10.5% のコンテキストを消費します。
| MCP サーバー | ツール数 | 推定文字数 | 推定トークン数 |
|---|---|---|---|
| Linear | 42 | ~51,229 | ~12,807 |
| Notion | 14 | ~16,156 | ~4,039 |
| Slack | 12 | ~15,168 | ~3,792 |
| Postgres | 9 | ~1,755 | ~438 |
| 合計 | 77 | ~84,308 | ~21,077 |
モデルごとの消費率
ツール定義は常時ロードされるため、実際に使わないツールを含めて容量を圧迫します。
| モデル | コンテキストサイズ | 使用率 |
|---|---|---|
| Claude | 200,000 トークン | 10.5% |
| GPT-4o | 128,000 トークン | 16.5% |
Linear サーバー単体でも約 13K トークンを占めます。
など一部機能のみ使っても、すべてのツール定義(42 件)がロードされるのが問題です。get_issue
問題点 2:運用信頼性が低い
| 問題項目 | 詳細 |
|---|---|
| 初期化失敗・再認証 | 別プロセスを維持する必要があるため、頻発 |
| 応答速度が遅い | 外部サーバーとの往復(Round Trip)が発生するため |
| セッション中のクラッシュ | MCP サーバープロセスが不安定になる場合がある |
| 不明瞭な権限 | ツールの実際の実行範囲が不透明 |
パフォーマンスベンチマーク
MCP は単一呼び出しでも 3 倍、初期化を含む最初の呼び出しでは 9.4 倍 も遅いです(Jira 比較による)。これは API 間のプロセスオーバーヘッドが原因で、特定のツールだけでなく Linear や Notion などのアーキテクチャにも共通します。
問題点 3:既存の CLI/API と機能重複
CLI や API を使えば、MCP の機能を代替できるケースが多く、その上で以下のような明確な劣化が見られます。
| 側面 | CLI / API | MCP |
|---|---|---|
| 人間・機械間での整合性 | 人間も LLM も同じコマンド使用可能 | 会話コンテキスト内のみの利用 |
| 組み合わせ可能性 | , , で自由結合可 | サーバーの戻り形式に縛られる |
| デバッグ | ターミナルで即座に再現・調査可 | 会話ログのみでの対応 |
| 学習データ | man ページなど既存データ利用可 | 個別のツール定義が必要 |
| インストールコスト | 既導入のケースが多い | サーバー設定・認証・プロセス管理が必要 |
トークン消費量の比較(Linear Issue 検索)
- CLI アプローチ: ~200 トークン
- プロンプト (~50) + レスポンス (~150)
- MCP アプローチ: ~12,957 トークン
- ツール定義 (~12,807) + ツール呼び出し (+レスポンス)
➡️ MCP は CLI に比べて約 65 倍のトークンを消費します。
💡 代替案:CLI と Skills の組み合わせ
MCP が抱える「全メニューを広げる」問題に対して、以下のアプローチを提案します。
代替案 1: CLI 優先戦略
LLM はすでに man ページや StackOverflow を学習済みであるため、情報源を
の順序で利用し、ツール定義によるコンテキスト消費をゼロにします。CLI → API → ドキュメント
メリット:
- ✅ コンテキスト消費がゼロ
- ✅ 人間と AI が同じインターフェース(デバッグ容易)
- ✅ パイプライン処理が可能
代替案 2: Skills(スキル)パターンの採用
MCP が「全ツールを常時ロード」するのに対し、Skills は必要な時だけロードする仕組みです。
| 側面 | MCP | Skills |
|---|---|---|
| 読み込み時間 | 接続時点で全てロード | オンデマンドロード |
| コンテキスト消費 | 常に占有中 | 利用時のみ占有 |
| スケーラビリティ | サーバー数増で圧力増加 | スキル数と比例せず制御可 |
実装例:Linear Issue Lookup Skill
必要なコマンドのみをコンテキストに含めます。
curl -s -H "Authorization: Bearer $LINEAR_TOKEN" \ -H "Content-Type: application/json" \ -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' \ https://api.linear.app/graphql
構成要素:
- API:
https://api.linear.app/graphql - 認証:
(環境変数)$LINEAR_TOKEN - 処理: JSON (
で解析)、GraphQL クエリjq - 効果: 42 つのツール定義を持ち歩く必要がない
📊 ダイヤナイズ:データベースと MCP のあり方
データベースについては「状況による」となります。LLM は SQL や NoSQL の知識を既に持っており、スキーマを与えればクエリ生成が可能です。
Postgres Skill の例(CLI 埋め込み)
- 接続:
psql -h localhost -d myapp ... - テーブル構造: スキルに明示
- メリット: リスト軽・高速・ミスの修正が容易
推奨アプローチと判断基準
| シナリオ | 推奨 | 理由 |
|---|---|---|
| ローカル開発 / プライベート DB | スキル+CLI | ライト、高速、リカバリー容易 |
| 本番環境 DB / チーム共有 | MCP | セーフティガードレール必須。サーバーレベルでのクエリ検証が必要 |
MCP がまだ必要なケース
- 🛡️ セキュリティ: サーバー側で Read-Only 強制や危険クエリブロックが可能(CLI では
などを実行してしまうリスクあり)DROP TABLE - 🔐 認証管理: プロンプト漏洩を防ぎ、内部で認証情報を安全に管理したい場合
注意点:
多くのケースで MCP は 「オーバエンジニアリング」 です。SaaS のランディングページに「MCP 対応」と書くことが流行っていますが、安定性やコンテキスト消費などの実用面は保証されていません。ユーザーが接続した瞬間にツール定義が読み込まれ、初期化失敗やクラッシュを引き起こします。
🚀 Quandri での運用方針
我々は状況に応じて最適なアプローチを選択し、単一の解を強制しません。
-
bash + CLI: 既に使っているツール(
,gh
,psql
など)aws- コンテキストコストはゼロ
- ターミナル内でのフルデバッグが可能
-
Skills: 反復的なマルチステップタスク(コミット作成、PR レビュー)
- オンデマンドロードで効率的
-
MCP: CLI が存在しないサービスや、チーム全体で厳格な権限管理が必要な場合
- Slack, Linear, Notion など
- 本番 DB アクセスなど
結論
「知識を与えること」が重要なのは、「全てを接続すること」よりも重要です。
既存の CLI をラップする Skills で MCP を置き換えることで、以下の成果を得ました。
- 🚀 コンテキスト容量: 約 21K トークン の解放
- 🔧 ワークフロー: 初期化失敗の排除
- 🐞 デバッグ: 本来の場所であるターミナルでの継続的対応
必要なツールだけを、必要になる時だけロードし、CLI 使い方を組み込んだままにしましょう。MCP が将来的に進化するかもしれませんが、現時点では 「Skills」が勝利 です。