「MCPは死んだ、CLIに栄光あれ」— Playwright CLI が出した結論と、それでもMCPが生き残る理由

@swarm_ai_cloud 氏のポストが、@hiroki_daichi 氏が紹介した「MCP is dead. Long live the CLI」という記事に対して、Playwright CLI の登場を根拠に「結論が出た」と指摘しています。

今年1月、PlaywrightがCLIを出したことで結論出ましたね。

2026年2月、Eric Holmes の「MCP is dead. Long live the CLI」がHacker Newsのトップに上がり、85ポイント・66コメントを集めました。LLM にとって MCP は不要で、CLI で十分だという主張です。そして1月に Microsoft が Playwright CLI をリリースしたことで、この議論に具体的なデータが加わりました。

Eric Holmes の主張 — MCP は何の利益ももたらさない

Holmes の記事は5つの論点で MCP の不要性を訴えています。

論点	主張
LLM に特別なプロトコルは不要	何百万もの man ページと Stack Overflow で訓練済み。CLI とドキュメントを渡せば十分
CLI は人間も使える	問題発生時に同じコマンドを人間が実行してデバッグできる。MCP は JSON ログの解読が必要
合成可能性	`jq`、`grep`、パイプで自由に組み合わせ可能。MCP サーバーの返すデータは固定
認証は解決済み	`aws`、`gh`、`kubectl` は人間とエージェントの両方で動作する
可動部品がない	CLI バイナリにバックグラウンドプロセスは不要。MCP サーバーは初期化で落ちることがある

Holmes が特に強調したのは、MCP の実運用上の痛みです。

不安定な初期化: Claude Code を再起動しないと MCP サーバーが起動しないことが何度もあった
認証の冗長さ: MCP は認証に余計な仕様を持ち込んでいる
権限のオールオアナッシング: MCP ツールは名前でのホワイトリストしかできず、読み取り専用やパラメータ制限ができない

Playwright CLI — データで証明された CLI の優位性

2026年1月、Microsoft は Playwright MCP サーバーの「CLI モード」をリリースしました。これが MCP vs CLI の議論に決定的なデータを提供しています。

アーキテクチャの根本的な違い

MCP 方式:
  ブラウザ → アクセシビリティツリー → LLM のコンテキストウィンドウに直接注入
  （毎回のインタラクションで全ページ状態を転送）

CLI 方式:
  ブラウザ → YAML スナップショット → ディスクに保存 → ファイルパスだけ返す
  （エージェントは必要な時だけ読み込む）

MCP はブラウザの状態をLLMのコンテキストウィンドウに毎回ストリーミングします。CLI は状態をディスクに YAML として保存し、エージェントにはファイルパスだけを返します。

トークン消費量の比較

指標	MCP	CLI	差
典型的なセッション	約114,000トークン	約27,000トークン	4倍削減
ステップあたりの追加コスト	約1,000トークン以上	コマンド文字列のみ	10倍以上の差
長時間セッション	一部報告で約145,000トークン	約4,150トークン	35倍削減

コンテキスト汚染問題

MCP の最大の問題はコンテキスト汚染です。

MCP で 10 ステップ実行した場合:
  ステップ1のページ状態 + ステップ2のページ状態 + ... + ステップ10のページ状態
  → 過去のステップの古い要素が残り続け、エージェントが混乱する

CLI で 10 ステップ実行した場合:
  最新のスナップショットファイルのみ
  → 常にクリーンなコンテキスト

MCP では各ステップで約1,000トークン以上のページ構造が蓄積し、10ステップ目には過去のページ状態が残り続けます。エージェントが異なるページの要素を混同し、判断品質が低下します。

CLI ではスナップショットが上書きされ、エージェントは常に最新の状態だけを参照します。実用的なセッション長は MCP の5〜10ステップに対し、CLI は50ステップ以上を維持できます。

GitHub MCP を外した実験 — 93ツールで55,000トークン

Playwright だけでなく、GitHub でも同様の結果が報告されています。

Zenn の記事では、著者が GitHub MCP を削除し、gh CLI だけで運用した経験を共有しています。

比較項目	GitHub MCP	`gh` CLI
常駐コスト	93ツールで約55,000トークン	ゼロ
出力の効率	ベンチマークで約35倍非効率	コマンド出力のみ
安定性	サーバーが “failed” 状態になることがある	枯れた技術で安定
学習コスト	MCP 固有の知識が必要	学習データに大量に存在

著者の結論は明快です。

Skills + CLI で大抵のことはどうにかなる。むしろ MCP サーバーが常に “failed” 状態でも機能に影響なし。

CLI が圧倒する5つの理由

複数の記事と実践報告を統合すると、CLI が優位な理由は5つに集約されます。

1. LLM は CLI をすでに知っている

LLM は gh、git、docker、kubectl、terraform などのコマンドを大量の学習データから理解しています。MCP のツール定義を教える必要がありません。

2. Unix の合成可能性

1
2
3
4
# CLI: Terraform の状態からEC2インスタンスを抽出
terraform state list | grep aws_instance | xargs -I{} terraform state show {}

# MCP: 専用のツールを実装する必要がある

パイプ、jq、grep でデータを自由に変換できます。MCP サーバーが返すデータ形式は固定で、冗長な場合でもトークンを消費します。

3. デバッグが人間と同じ

CLI コマンドは人間がターミナルで再現できます。MCP のJSON-RPC 通信のデバッグは、プロトコルレベルの知識が必要です。

4. 認証が既存インフラを使える

gh auth login、aws sso login、gcloud auth login など、既存の認証フローがそのまま使えます。MCP は独自の OAuth 2.1 + PKCE を要求します。

5. 状態管理が不要

CLI バイナリはステートレスです。MCP サーバーは起動・接続・再接続の管理が必要で、初期化の失敗が頻繁に報告されています。

それでも MCP が必要なケース

「MCP は死んだ」は過激な表現ですが、実際には MCP が必要な場面は残っています。

CLI が存在しないサービス

サービス	CLI の有無	MCP の必要性
GitHub	`gh` CLI あり	不要
AWS	`aws` CLI あり	不要
Figma	CLI なし	必要
Notion	CLI なし	必要
Slack	限定的な CLI	場合による

エンタープライズ要件

監査ログ: 厳格な入力検証とアクセス記録が必要な本番環境
権限管理: OAuth 2.1 による細粒度のスコープ制御
動的ツール発見: 大規模マルチテナント環境でのツール一覧管理

標準化の進展

2025年12月、Anthropic は MCP を Linux Foundation の新設 Agentic AI Foundation（AAIF）に寄付しました。AWS、Google、Microsoft、OpenAI、Bloomberg、Cloudflare がプラチナメンバーとして参加しています。

MCP は「AI エージェントの USB-C」として、エンタープライズ向けの標準プロトコルという位置づけに進化しています。CLI が個人開発者やパワーユーザーに最適な一方、MCP は「CLI が存在しない世界」と「企業の統制が必要な世界」で生き残ります。

判断フローチャート

ツールと対話したい
  ├── CLI が存在する？
  │     ├── はい → CLI を使う（gh, aws, kubectl, terraform...）
  │     └── いいえ → API が存在する？
  │           ├── はい → MCP サーバーを使う（Figma, Notion...）
  │           └── いいえ → WebFetch / スクレイピング
  │
  └── エンタープライズ要件がある？
        ├── 監査ログ必須 → MCP（OAuth 2.1 + スコープ制御）
        ├── マルチテナント → MCP（動的ツール発見）
        └── 個人/チーム開発 → CLI 優先

まとめ

Eric Holmes の主張は正しい: 実運用では CLI が MCP より圧倒的に効率的。LLM は CLI をすでに知っており、特別なプロトコルは不要
Playwright CLI が決定的なデータを出した: MCP の114,000トークンに対し、CLI は27,000トークン。4倍から最大35倍のトークン削減
コンテキスト汚染が MCP の最大の弱点: MCP は古いページ状態を蓄積し、5〜10ステップで判断品質が低下する。CLI は常にクリーン
GitHub MCP も外せる: 93ツールで55,000トークンの常駐コスト。gh CLI で十分に代替可能
CLI が勝つ理由は5つ: 学習済み、合成可能、デバッグ容易、認証解決済み、状態管理不要
MCP が生き残る場面: CLI が存在しないサービス（Figma、Notion）、エンタープライズの監査・権限要件、マルチテナント環境
MCP は標準化へ進化中: AAIF への寄付で「エージェント時代の USB-C」としてエンタープライズ標準の道を歩む。CLI と MCP は競合ではなく、対象ユーザーの住み分け

「MCPは死んだ、CLIに栄光あれ」— Playwright CLI が出した結論と、それでもMCPが生き残る理由#

Eric Holmes の主張 — MCP は何の利益ももたらさない#

Playwright CLI — データで証明された CLI の優位性#

アーキテクチャの根本的な違い#

トークン消費量の比較#

コンテキスト汚染問題#

GitHub MCP を外した実験 — 93ツールで55,000トークン#

CLI が圧倒する5つの理由#

1. LLM は CLI をすでに知っている#

2. Unix の合成可能性#

3. デバッグが人間と同じ#

4. 認証が既存インフラを使える#

5. 状態管理が不要#

それでも MCP が必要なケース#

CLI が存在しないサービス#

エンタープライズ要件#

標準化の進展#

判断フローチャート#

まとめ#

参考#