AIコーディングエージェントは外部ツール — GitHub、データベース、クラウドプロバイダー、ビルドシステム — と対話する必要がある。2つのアプローチが台頭している：CLIツールにシェルアウトするか、Model Context Protocol（MCP）を使うか。
どちらも中身では同じAPIを呼んでいる。違いはエージェントがどう呼び出すかだ。そしてその違いには実際のアーキテクチャ上の意味がある。
エージェントは開発者と同じようにシェルコマンドを実行する：
利点：
LLMは数十億のCLI例で訓練されている。git、curl、grep、jq、awsを熟知している。モデルは新しいスキーマを学ぶ必要がない — すでにこの言語をネイティブに話している。
CLIツールはUnixパイプで自然にチェーンする。gh pr list | jq '.[] | .title' | grep "fix"のようなものが1回のLLMコールで実行される。設計上、合成可能だ。
スキーマの読み込みがないのでコンテキストウィンドウの無駄がない。エージェントは作業を始める前にツールの説明を読み込む必要がない。
欠点：
シェルエスケープは悪夢だ。1つのクォートミスでコマンドが失敗するか、もっと悪いことに — 意図しないことをする。出力のパースは脆い。エージェントは機械の消費用に設計されていない人間が読めるテキストをパースしなければならない。
認証は共有される。CLIエージェントは単一のトークンまたは認証情報セットを継承する。全員の認証情報をローテーションせずに1人のユーザーのアクセスを取り消すことはできない。
すべてのコマンドが新しいプロセスを生成する。永続的な接続もセッション状態もない。ステートフルなワークフローではエージェントがコール間のコンテキストを手動で追跡する必要がある。
Model Context Protocolはエージェントとツールの間に構造化されたインターフェースを定義する：
利点：
構造化された入出力。シェルエスケープなし、テキストパースなし。レスポンスはエージェントが直接扱える型付きJSONだ。
ユーザーごとのOAuth。MCPは各ユーザーが独自のトークンを持つ適切な認証フローをサポートする。1人のユーザーのアクセスを取り消しても他のユーザーに影響しない。
永続セッション。MCPはコネクションプーリング付きの常駐サーバーを維持する。ステートフルなワークフローが自然 — サーバーがコール間のコンテキストを維持する。
エンタープライズガバナンスが組み込み。構造化された監査ログ、アクセス取り消し、モニタリング — すべてプロトコルの一部で、後付けではない。
欠点：
完全なJSONスキーマ（ツール名、説明、パラメータ型）が作業開始前にコンテキストウィンドウに読み込まれなければならない。50のツールを持つサーバーでは、エージェントが何かをする前に数千トークンが消費される。
ネイティブなチェーンがない。各ツールコールは別々のラウンドトリップ。エージェントが逐次的にコールをオーケストレーションしなければならない — pipeに相当するものがない。
モデルはMCPスキーマにランタイムで初めて出会う。訓練されたCLIパターンとは異なり、MCPは新しいサーバーごとにインコンテキスト学習を必要とする。
| 次元 | CLI | MCP |
|------|-----|-----|
| トークンコスト | 低い — スキーマ読み込みなし | 高い — 完全なスキーマがコンテキストに |
| ネイティブな知識 | 数十億の例で訓練済み | カスタムJSON、ランタイムで学習 |
| 合成可能性 | Unixパイプ、単一コール | 個別にオーケストレーション |
| マルチユーザー認証 | 共有トークン、全か無か | ユーザーごとのOAuth |
| ステートフルセッション | コマンドごとに新しいプロセス | 永続接続 |
| 監査とガバナンス | ~/.bash_history | 構造化ログ、アクセス制御 |
| エラーハンドリング | 終了コード + stderr | 型付きエラーレスポンス |
| セットアップの複雑さ | ゼロ — ツールは既にインストール済み | サーバーのデプロイが必要 |
CLIが勝つとき：
grep | sort | head）MCPが勝つとき：
実際には、最良のエージェントセットアップは両方を使う。CLIは素早く合成可能なタスクに — モデルの訓練データが流暢さを与える。MCPはガバナンスが重要な構造化されたマルチユーザーワークフローに。
開発者のローカルマシン：
→ CLIエージェント（速い、合成可能、セットアップゼロ）
チームの共有エージェントプラットフォーム：
→ MCPサーバー（認証、監査、ガバナンス）
本番自動化：
→ 構造化モニタリングとアクセス制御付きMCP
これを二択として扱うのが間違いだ。CLIとMCPはスタックの異なるレイヤーで異なる問題を解決する。
CLIは流暢さのために、MCPはガバナンスのために。両方使え。
— blanho
どのアーキテクチャも1つの問題を解決し、3つの新しい問題を生む。コミットする前に誰も教えてくれないことがここにある。
Netflixの問題なんか抱えてない。3人の開発者と1つのPostgresデータベースがあるだけだ。
プロンプトを打つ、AIがコードを書く。シンプルでしょ？裏では5つのシステムが互いに言い争ってる。
# エージェントがこれらのコマンドを直接実行
gh pr list --state open --json title,number
aws s3 ls s3://my-bucket/
kubectl get pods -n production -o json
docker ps --format '{{.Names}}: {{.Status}}'# 3つのツールをチェーンするワンライナー — オーケストレーション不要
gh api repos/org/repo/pulls --jq '.[].title' | sort | head -5{
"tool": "github.list_pull_requests",
"parameters": {
"repo": "org/repo",
"state": "open",
"limit": 5
}
}{
"result": {
"pull_requests": [
{"number": 42, "title": "Fix auth bug", "author": "alice"},
{"number": 43, "title": "Add caching", "author": "bob"}
]
}
}