皆さん、最近AIエージェントの開発で「MCP（Model Context Protocol）」使ってますか？
ここ1年間くらい、MCPは「AI時代のHTTPだ！」ってもてはやされてきましたよね。私も最初は「これでAIがいろんなツールを構造化して使えるようになるのか！」と興奮して実装してみたんです。
でも実際に本番稼働させてみると、なんだか妙な違和感というか、沼にハマる感覚がありました。そして最近、海外の開発者コミュニティを見ていると、全く逆のトレンドが来ていることに気づいたんです。
そう、「MCPの使用を減らし、エージェントに直接CLI（コマンドライン）を叩かせる」 というアプローチです。
エンジニアのEric Holmes氏が自身のブログ記事（MCP is dead. Long live the CLI.）で放った、こんな尖った一言が今のトレンドを象徴しています。
"MCP is dead. Long live the CLI."（MCPは死んだ。CLI万歳）
これ、一見ただの逆張りエモートに聞こえるかもしれませんが、実際の開発現場に落とし込んでみると、決して大げさな話ではないんです。今回は、なぜ今あえて「CLIファースト」なのか、そのリアルな理由を語ってみたいと思います。
MCPの設計思想自体は美しかった
誤解のないように言っておくと、MCPのコンセプトは理にかなっています。
- 外部機能をToolとして定義する
- ToolのパラメータをSchemaで記述する
- エージェントがコンテキストとしてToolを読み込む
- エージェントがこれらのツールを呼び出してタスクを実行する
このアプローチは、構造化されていて拡張性も高く、インターフェースが標準化されるという大きなメリットがあります。アーキテクチャ図で描けば、信じられないほどクリーンです。
しかし、理論と現実のソフトウェア開発は別物なんですよね。
現場で直面する「MCPの3つの罠」
日々のワークフローにMCPを組み込むと、想定外の「負債」がたまりやすくなります。具体的に3つの問題点があります。
1. 笑えないトークンのオーバーヘッド
MCPでは、ツールをモデルに理解させるために「Schema + 説明文」を食わせる必要があります。
もしエージェントが複数のMCPサーバーに接続する場合、どうなるか。
- ツールの名前
- ツールの詳細な説明
- パラメータのJSON構造
これらがすべてコンテキストウィンドウを圧迫します。
例えば、10個のMCPサービスがあり、それぞれに5個のツールがあったとしましょう。エージェントが実作業に入る前に、数千トークンがツールの説明だけで溶けていく計算になります。推論チェーンが長くなるタスクでは、コストやパフォーマンスの観点からも無視できないオーバーヘッドです。
2. 「車輪の再発明」という苦行
多くのMCPサーバー、ぶっちゃけただのラッパーになっていませんか？
- GitHubの操作
- Dockerの管理
- ログ分析
- CI/CDのトリガー
- クラウドリソース管理
これらって、すでに私たちが毎日叩いている成熟したCLIツールが存在しますよね。
git, gh, docker, kubectl, aws, curl などです。
MCPでこれを実装しようとすると、こんな多重構造になります。
CLI -> API -> MCP Server -> Agent
レイヤーが一つ増えるごとに、メンテナンスの複雑さは跳ね上がります。なんのための効率化かわかりません。
3. Unixパイプラインの破壊
個人的に一番モヤッとするのがこれです。Unix哲学の核心は 「ひとつのことをうまくやる、小さなツールを組み合わせる（Make small tools that work together）」 こと。
CLIの神髄は、grep, jq, awk, rg, tailなどをつなぐ コンポーザビリティ（組み合わせ） にあります。
# 現場でよくやるやつ
tail -f logs/server.log | grep error | jq .
開発や運用の現場で日常的に使うこの柔軟なパイプライン化が、MCPだと「孤立した関数呼び出し」に分断されてしまいます。構造化と引き換えに、CLI特有の柔軟性を捨ててしまっているんです。
なぜAIエージェントにとってCLIが「自然」なのか？
ここで原点に立ち返ってみましょう。
現代のLLMは、CLIを叩くのがめちゃくちゃ得意です。
理由はシンプル。彼らの学習データには、膨大な量のGitHubリポジトリ、シェルスクリプト、DevOpsのドキュメント、CI/CDの設定ファイル、そしてStack OverflowのQ&Aが含まれているからです。
モデルは息をするように以下のものを理解しています。
- オプションフラグ（flags）
- パイプ処理（pipes）
- シェルのエラーメッセージ
- manページ（マニュアル）
エージェントにシェルの実行権限を与えると、驚くほどシームレスに立ち回ります。
コードを検索し、ファイルを直接編集し、テストを回して、エラーをデバッグし、コミットする。この一連のループが「ターミナルの中だけ」で完結するんです。
デバッグ効率を爆上げする「再現性の高さ」
CLIがMCPを凌駕するもう一つの決定的な強みが 「再現性（reproducibility）」 です。
もしエージェントが以下のコマンドを実行してエラーで詰まったとします。
kubectl get pods
私たち人間の開発者は、同じコマンドをコピペしてターミナルで叩くだけで、エージェントが直面している状況を100%再現できます。デバッグが超ダイレクトです。
一方、MCPの呼び出しでエラーが起きたら？
JSONのペイロードを覗き込み、ツールの実行ログを漁り、MCPサーバーのステータスを確認し…と、複雑なシステムになればなるほど、原因究明に時間を奪われます。
トレンドは「CLIファースト」なエージェントへ
最近リリースされているAIプログラミングツールを観察すると、明らかにCLI-firstな設計へと舵を切っています。
- Claude Code
- Codex CLI
- Gemini CLI
これらのツールの共通点は明確です。
- ターミナル上で直接動く
- エージェントにシェルコマンドの実行を許可している
- ローカルのファイルシステムを直接操作する
- 既存の開発ツールチェーンにそのまま乗っかる
つまり、「エージェントのために新しいツールのエコシステムを作る必要なんてなかった」 んです。彼らは、人間が何十年もかけて洗練させてきたツールをそのまま使えばいい。
典型的なCLIエージェントのワークフロー
例えば大規模なコードのリファクタリングでは：
rg "oldDeprecatedFunction" .
git diff
npm test
git commit
本番環境のデバッグ調査では：
tail -f logs/server.log
grep error
curl -v api/auth/check
docker-compose up
新しいAPIサービスの立ち上げでは：
cargo new my_api
cargo add axum sqlx
cargo watch
curl localhost:3000/health
新しいプロトコルも、新しいサーバーも、余計な抽象化レイヤーも不要です。ただそこにある既存のCLIを使うだけ。シンプルイズベストですね。
それでも、MCPが活きる場面は？
誤解しないでほしいのですが、この記事は「MCPを全部捨てろ」と言っているわけではありません。適材適所で、以下のようなシナリオではMCPの強みが間違いなく活きます。
- 企業向けSaaSの複雑な連携
- 型安全（Type-safe）が強く求められるAPI操作
- セキュリティ要件が厳格なコンプライアンス環境
- 開発者向けではない一般向けアプリケーション
こういった領域では、強固に構造化されたプロトコルが必須です。しかし、日常的な「開発者のワークフロー」においては、CLIというインターフェースがすでに最適解を出していると言わざるを得ません。
まとめ：AIは「ターミナル」を再発見した
過去数年、私たちは「AIにはAIのための新しいツールプロトコルが必要だ」と思い込んでいました。
しかし、現実はもっと地味で、そして合理的でした。
AIは新しい開発環境を発明したわけではなく、数十年前から存在する洗練されたシステム「ターミナル（Terminal）」の価値を再発見したに過ぎないのかもしれません。
組み合わせてパイプでき、デバッグが容易で、誰でも再現でき、無限に拡張できる。
回り回って、最高のインターフェースはずっと手元にあったというオチです。
皆さんのプロジェクトではMCPとCLI、どちらを主力にしていますか？ぜひ現在の構成や、開発環境で悩んでいるポイントなど、コメント欄やSNSで教えてください！色々と情報交換しましょう。
Top comments (0)