CLI vs MCP——AIエージェント時代に「最古のUI」が再注目される理由
CLI vs MCP——AIエージェント時代に「最古のUI」が再注目される理由
飛書（Lark）、DingTalk、企業微信、Google、Stripe——2026年に入ってから、テック大手が次々とCLIツールをオープンソースで公開しています。
GUIの時代にCLIなんて時代逆行では？ そう思うかもしれない。でも実際は逆です。AIエージェントが実務に入り込むほど、CLIの価値が再発見されている。
理由はシンプル。CLIはAIの母語だから。
LLMの学習データには膨大なコードとターミナルログが含まれている。GUIのスクリーンショットを解釈させるより、
git commit -m "fix"と打たせる方がはるかに速く、安く、正確。MCPが「AIにツールを使わせるプロトコル」として注目を集めたけれど、CLIの方が同じことをもっとシンプルにできるケースが増えています。
この記事では、CLI復権の背景、注目のOSSプロジェクト、そしてMCPとの使い分けを整理します。
1. なぜ今CLIなのか——AIにとっての「理想のUI」
GUIは人間のために作られたインターフェースです。ボタン、ドロップダウン、ドラッグ＆ドロップ——すべて「目で見て、手で操作する」ことが前提。
でもAIエージェントには「目」も「手」もない。あるのはテキストの入出力だけ。
| 特性 | GUI | CLI |
|---|---|---|
| 入力 | マウス・タッチ・視覚的操作 | テキストコマンド |
| 出力 | 画面上のピクセル描画 | 構造化テキスト / JSON |
| エラー通知 | ダイアログ、赤い枠線 | 終了コード + stderr |
| 自動化 | 画面操作の記録・再生（脆い） | シェルスクリプト / パイプ（堅牢） |
| AI との相性 | 低い（画面認識が必要） | 高い（テキストベースで直接処理） |
CLIの出力はそのままLLMのコンテキストに流し込める。GUIの出力はスクリーンショットを撮って画像認識にかける必要がある。どっちが速いかは明白です。
自分もAIエージェントにGUI操作をさせようとして、ブラウザ自動化で散々苦労した経験があります。ボタンの位置が数ピクセルずれるだけで全部止まる。CLIに切り替えた途端、安定して動くようになって「最初からこっちでよかったじゃん」と思いました。
2. 注目のOSSプロジェクト
2.1 CLI-Anything：ソフトウェアを一行でCLI化
CLI-Anything は、任意のオープンソースソフトウェアに対してCLIラッパーを自動生成するツールです。
何ができるか：
- ソースコードを解析 → APIを洗い出し → コマンド設計 → 実装 → テスト → 公開、を自動で実行
- Draw.io、OBS Studio等のGUIアプリをコマンドライン経由で操作可能にする
- AIエージェントが
--help
で段階的にコマンドを学習できる設計
# インストール pip install cli-anything # Draw.ioのCLIラッパーを生成 cli-anything generate drawio --source ./drawio-src # 生成されたCLIを使う drawio-cli create --type flowchart --output diagram.png
ここが面白い。エージェントは最初に
--helpだけ読めばいい。全ツール定義をコンテキストに詰め込むMCPと比べて、トークン消費が最大30分の1になるとのこと。
2.2 Open CLI：Webサイトをコマンドライン化
Open CLI は、WebサイトやElectronアプリをCLIツールに変換するプロジェクト。
対応プラットフォームの例：
| サービス | CLIで何ができるか |
|---|---|
| Hacker News | 記事一覧の取得、コメントの閲覧 |
| BOSS直聘 | 求人情報の検索・フィルタ |
| Grok | チャット操作 |
| 各種Webアプリ | 裏側でブラウザを自動操作し、テキスト/JSONで結果を返す |
バックグラウンドでヘッドレスブラウザが動いて、結果だけをテキスト/JSONで返してくる。AIエージェントにとっては「APIが存在しないサービスにもCLIでアクセスできる」という意味で強力。
3. 公式CLI生態系の広がり
OSSだけでなく、公式CLIの整備も加速しています。
# GitHub CLI：リポジトリ作成からPRレビューまで gh repo create my-app --public --clone gh pr create --title "feat: add auth" --body "OAuth2対応" # Google Cloud CLI：インフラ管理 gcloud compute instances create my-vm --zone=asia-northeast1-a # Stripe CLI：決済イベントの監視 stripe listen --forward-to localhost:4242/webhook # 飛書CLI：ドキュメント操作 feishu doc list --folder "プロジェクトA"
これらの公式CLIは安定していて、APIキーによる認証も整備されている。AIエージェントが MCP経由でAPIを叩く代わりに、CLIを直接呼ぶ という選択肢が現実的になっています。
4. CLI vs MCP：構造的な違い
ここからが本題。MCPとCLIは「AIにツールを使わせる」という同じ目標に対して、まったく異なるアプローチを取ります。
MCPの仕組み
MCP（Model Context Protocol）は、LLMのコンテキストにツール定義を注入し、Function Callingで呼び出すプロトコル。
[LLMのコンテキスト] ├── システムプロンプト ├── ツール定義A（JSON Schema） ← 常に全量注入 ├── ツール定義B（JSON Schema） ← 使わなくてもトークン消費 ├── ツール定義C（JSON Schema） └── ユーザーの質問
CLIの仕組み
CLIベースでは、エージェントが必要なときだけ
--helpで使い方を調べる。
[LLMのコンテキスト]
├── システムプロンプト
├── 「shellでコマンドを実行できます」（1行だけ）
└── ユーザーの質問
→ エージェントが必要に応じて実行:
$ tool-name --help ← 必要なときだけ学習
$ tool-name subcommand -o json ← 実行して結果を取得
比較表
| 観点 | MCP | CLI |
|---|---|---|
| ツール定義のコスト | 全ツール定義を常時コンテキストに注入。ツール追加ごとにトークン消費増大 |
--helpで按需取得。未使用ツールのトークン消費ゼロ |
| デバッグ | エージェント内部のブラックボックス。人間が再現しにくい | コマンドをコピーしてターミナルに貼るだけで再現可能 |
| 組み合わせ | 1ツール1呼び出し。複雑なタスクは多ラウンド必要 | パイプ |やリダイレクト >で一行に連結可能 |
| 構造化出力 | JSON（Function Callingの戻り値） |
--output json/ --format csvで柔軟に切替 |
| エラーハンドリング | ツールごとに異なる形式。統一されていない | 終了コード + stderr の統一規約 |
| 人間のラーニング | ツール定義のJSON Schemaを読む必要がある |
man/ --helpで即座に確認 |
正直、MCPをいくつか自作した経験がありますが、デバッグの辛さは本物です。エージェントが内部で何をやっているかが見えない。同じことをCLIで実装したら、失敗したコマンドをそのままターミナルで再実行できるので、原因特定が圧倒的に速かった。
5. MCPが勝つ場面
ここまでCLIを推してきましたが、MCPには明確な利点があるケースがあります。公平に整理すると：
MCPが向いている場面：
- マルチテナント環境: 複数ユーザーの権限を統一的に管理する必要がある場合。CLIは原則として実行ユーザーの権限で動く
- クラウドプラグイン市場: Slack AppやChatGPT PluginsのようなマーケットプレイスではMCPの標準化されたインターフェースが有利
- 認証の一元管理: OAuth、APIキーのライフサイクル管理をフレームワーク側に任せたい場合
- 実行環境の制約: ターミナルアクセスがない環境（Webベースのチャットボット等）
CLIが向いている場面：
- ローカル環境での開発・自動化
- 既存のUNIXツール群との統合
- デバッグとトラブルシューティングの速度が重要
- トークンコストを最小化したい
どちらか一方が完全に勝つわけではない。現状はCLIの方が「費用対効果が高い場面が多い」という感触です。
6. 融合のトレンド：CLI ↔ MCP の相互変換
二者択一ではなく、融合が始まっています。
# MCPサーバーをCLIツールとして使えるようにするブリッジ mcp-to-cli --server github-mcp --output gh-mcp-cli # 逆に、既存CLIツールをMCPサーバーとして公開 cli-to-mcp --command "gh" --expose-as github-tools
MCPも「全ツール定義の常時注入」から「必要なときだけロードする遅延読み込み」に進化しつつある。これはまさにCLIの
--help方式を取り入れた動き。
最終的には、開発者はどちらか一方を選ぶのではなく、状況に応じて使い分ける——あるいは意識すらしなくなる方向に進むと思っています。
7. まとめ
CLIは「古い技術の再発見」ではない。AIエージェント時代に最適化された、テキストファーストなインターフェースとして正当に評価されつつある。
- トークン消費: CLI
--help
の按需学習で最大30倍削減 - デバッグ: コマンドコピペで即再現。MCPのブラックボックスとは雲泥の差
- 組み合わせ: パイプラインでワンライナー化。MCPは1ツール1往復
- ただしMCPはマルチテナント・認証一元管理で依然として優位
あなたのAIエージェントは、ツールをMCP経由で呼んでいますか？それともCLI経由ですか？ 両方使い分けているなら、どういう基準で分けているか、コメント欄で教えてください。