MCPのツール定義だけでコンテキストウィンドウの55,000トークン以上を消費する。この問題に対し、APIプラットフォームのApideckが「CLIベースのAIエージェントインターフェース」を提案し、Hacker Newsで126ポイント・107コメントの議論を巻き起こしました。
MCPサーバーのスキーマ定義がLLMのコンテキストを圧迫する問題は、AIエージェント開発者の間で広く認識されていた課題です。Apideck CLIはこの問題に対し「プログレッシブ・ディスカバリー」というアプローチで80トークンのシステムプロンプトに置き換えるという解決策を示しました。
この記事でわかること
- MCPサーバーがコンテキストウィンドウを圧迫する具体的な仕組み
- Apideck CLIの技術アーキテクチャと80トークンの秘密
- MCP vs CLIのトークン消費・コスト比較（ベンチマーク付き）
- Hacker Newsコミュニティの賛否両論
- MCPとCLIの使い分け指針
MCPのコンテキスト消費問題とは
MCP（Model Context Protocol）サーバーは、ツール定義のJSONスキーマをそのままLLMのコンテキストウィンドウに読み込む。各ツールの名前、説明、パラメータスキーマ、列挙型の定義を含めると、1ツールあたり550〜1,400トークンを消費する。50以上のエンドポイントを持つAPIでは、ユーザーのメッセージを処理する前に50,000トークン以上がスキーマで埋まる計算だ。
Apideckのブログ記事では、3つのMCPサーバーを同時に接続したところ、200,000トークンのコンテキストウィンドウのうち143,000トークン（72%）がツール定義で消費されたと報告している。残りの57,000トークンでは複雑な推論を行う余地がほぼ残されない。
Apideck公式ブログからの引用
“55,000 tokens of tool definitions are sitting in the context window. That’s over a quarter of Claude’s 200k limit. Gone.”
「55,000トークンのツール定義がコンテキストウィンドウに居座っている。Claudeの200k制限の4分の1以上が、消えた。」
Apideck CLIの仕組み
Apideck CLIの核心は「プログレッシブ・ディスカバリー」にある。MCPが全ツール定義を事前にロードするのに対し、CLIはエージェントが必要なときに --help コマンドで段階的に情報を取得する。システムプロンプトにはCLIの存在と基本的な使い方だけを記述し、わずか約80トークンで済む。
トークン消費の比較
| アプローチ | トークン数 | タイミング |
|---|---|---|
| OpenAPIスペック全体 | 30,000〜100,000+ | 最初のメッセージ前 |
| MCPツール定義 | 10,000〜50,000+ | 最初のメッセージ前 |
| CLIシステムプロンプト | 約80 | 最初のメッセージ前 |
| CLI –helpコール | 50〜200 | 必要なときだけ |
技術的には、Apideck CLIはGoで書かれた単一の静的バイナリで、起動時にOpenAPIスペックをパースしてコマンドツリーを動的に生成する。libopenapi ライブラリを使用し、コード生成なしでAPIスペックからCLIコマンドを自動構築する仕組みだ。ソースコードは GitHub で公開されている。
セキュリティ面でも違いがある。MCPではDELETE操作の制御をプロンプトベースの指示に頼るが、CLIでは --force フラグなしではDELETE操作がバイナリレベルでブロックされる。プロンプトインジェクションでは回避できない構造的な安全性が確保される。
ベンチマーク：MCP vs CLI
セキュリティ企業Scalekitが実施した75回のヘッドトゥヘッド比較（Claude Sonnet 4使用）で、CLIはMCPより4〜32倍トークン効率が良いという結果が出た。
最もシンプルなタスク
リポジトリの言語チェック
32倍
CLI: 1,365トークン / MCP: 44,026トークン
月間コスト比較
同一タスク群の実行
17倍
CLI: $3.20/月 / MCP: $55.20/月
さらに注目すべきは信頼性の差だ。MCP経由の呼び出しでは25回中7回（28%）がTCPタイムアウトで失敗したのに対し、CLIはローカル実行のためリモートサーバーへの接続障害が発生しない。バイナリがローカルで動作し、直接APIにHTTPSコールを行うアーキテクチャが、この安定性の差を生んでいる。
HNの反応──CLI派の声
Hacker Newsでは126ポイント・107コメントを集め、MCPの現状に不満を持つ開発者から強い共感を得た。
“We built a unified API with a large surface area and ran into a problem when building our MCP server: tool definitions alone burned 50,000+ tokens before the agent touched a single user message.”
「大規模な統合APIを構築してMCPサーバーを作ったところ、ツール定義だけで50,000トークン以上を消費した。エージェントがユーザーのメッセージに触れる前に。」 ── Apideck開発者自身による問題提起。実体験に基づく具体的な数字がコミュニティの共感を集めました。
“I ran into this exact problem building a MCP server. 85 tools in experimental mode, ~17k tokens just for the tool manifest before any work starts.”
「まさにこの問題にぶつかった。85ツールの実験モードで、作業開始前にツールマニフェストだけで約17,000トークン。」 ── 別の開発者も同様の問題を報告。ツール数が増えるほど深刻化する構造的な課題であることが裏付けられました。
“All you need is ‘composability’. UNIX solved this with files and pipes for data, and processes for compute. AI agents are solving this with sub-agents for data, and ‘code execution’ for compute.”
「必要なのは”合成可能性”だ。UNIXはファイルとパイプで解決した。AIエージェントもサブエージェントとコード実行で同じ方向に進んでいる。」 ── CLIアプローチがUNIX哲学の延長線上にあるという視点。技術的な正統性を主張するコメントです。
HNの反応──MCP派の反論
一方で「MCPを捨てるのは早計」という反論も相当数あった。特にMCPコア開発者を含む技術者からの指摘は説得力がある。
“The debate around ‘MCP vs. CLI’ is somewhat pointless to me personally. Use whatever gets the job done. MCP is much more than just tool calling – it also happens to provide a set of consistent rails for an agent to follow.”
「”MCP vs CLI”の議論は個人的にはやや無意味だ。仕事を片付けるものを使えばいい。MCPはツール呼び出しだけではなく、エージェントが従うべき一貫したレールを提供している。」 ── MCPコアメンテナーによる冷静な見解。MCPの価値はスキーマだけにあるのではないという重要な指摘です。
“The trend is obviously towards larger and larger context windows. We moved from 200K to 1M tokens being standard just this year. This might be a complete non issue in 6 months.”
「トレンドは明らかにコンテキストウィンドウの拡大だ。今年だけで200Kから1Mが標準になった。6ヶ月後にはまったく問題にならないかもしれない。」 ── コンテキストウィンドウが拡大すれば、MCPのトークン消費問題は自然解消するという見方。
“I’m getting tired of everyone saying ‘MCP is dead, use CLIs!’. Yes, MCP eats up context windows, but agents can also be smarter about how they load the MCP context in the first place. The problem with tossing it out entirely is that it leaves a lot more questions for handling security.”
「”MCPは死んだ、CLIを使え！”という声にはうんざりだ。MCPがコンテキストを食うのは事実だが、エージェント側でロード方法を賢くすればいい。MCPを完全に捨てると、セキュリティの扱いに多くの未解決問題が残る。」 ── 12件の返信が付いた人気コメント。CLIに移行してもセキュリティの課題は消えないという反論です。
“While I generally prefer CLI over MCP locally, this is bad outdated information. The major harnesses like Claude Code + Codex have had tool search for months now.”
「ローカルではCLIの方が好きだが、この記事の情報は古い。Claude CodeやCodexのような主要なハーネスには、数ヶ月前からツール検索機能がある。」 ── 記事の前提自体に疑問を呈する指摘。主要なAIツールは既にツール定義の動的ロードを実装済みだという反論です。
MCPとCLIの使い分け
Apideck自身もブログ記事で「MCP、コード実行、CLIは補完的なツールだ。MCPを万能として扱うことが間違い」と述べている。この議論の本質は「どちらが優れているか」ではなく「どの場面でどちらを使うか」にある。
CLIが適する場面
- API表面積が大きい（50+エンドポイント）
- ローカル環境での対話的な操作
- コスト効率を重視する用途
- 破壊的操作の構造的な制御が必要
MCPが適する場面
- サービス間の自律的な連携
- エンタープライズ向けの認証・権限管理
- ストリーミングやリアルタイム通信
- エコシステム全体の標準化
HNコメントでも指摘されたように、CLIの「プログレッシブ・ディスカバリー」にはトレードオフがある。 --help を呼ぶたびにラウンドトリップが発生し、レイテンシが増加する。コストを下げる代わりに速度を犠牲にしている側面があり、リアルタイム性が求められる用途ではMCPの方が有利だ。
Aitly編集部の見解
EDITORIAL
Apideck CLIの提案は「MCPキラー」ではなく「MCPが苦手な領域の現実的な代替手段」として理解すべきだ。
MCPのコンテキスト消費問題は確かに深刻だが、HNコメントで複数の開発者が指摘したように、Claude CodeやCodexは既にツール検索（動的ロード）を実装している。コンテキストウィンドウも200Kから1Mへ拡大した。Apideckのベンチマークが示す「72%消費」という数字は、最悪ケースの静的ロードシナリオであり、現在の主要ツールの実装とは乖離がある。
それでもCLIアプローチの価値は大きい。トークン効率4〜32倍、月額コスト17倍の差は無視できない。特に大量のAPI呼び出しを行うバッチ処理や、コスト意識の高いスタートアップにとって、CLIは合理的な選択肢になる。
MCPコアメンテナーのdend氏が「仕事を片付けるものを使えばいい」と述べたのが、この議論の最も冷静な結論だろう。MCPかCLIかの二者択一ではなく、API表面積・コスト要件・リアルタイム性の3軸で使い分ける時代に入っている。
よくある質問
参考リンク
※ この記事の情報は2026年3月17日時点のものです。Hacker Newsのポイント数・コメント数は変動する場合があります。
※ 記事内のHacker Newsコメントの翻訳はAitly編集部によるものです。
