Claude Code CLI環境でMCPは必要か？
Claude Code（CLI版）を使っていて、ふと疑問が浮かんだ。CLIから直接curlやCLIツールでAPIを叩けるのに、MCP（Model Context Protocol）サーバーを間に挟む意味はあるのか。
答えは「場合による」。Chrome DevTools MCPを例に、使い分けの基準を整理する。
MCPの役割を誤解していた
MCPは「ブラウザ環境のClaude Webがローカルリソースにアクセスできないから存在する代替手段」ではない。LLMがツールとして構造的に呼び出せる標準インターフェースを提供するプロトコルだ。
Claude Webでのリモートアクセス用途は確かにユースケースの一つだが、本質はそこではない。
CLI環境でMCPが不要なケース
REST APIやCLIツールが充実しているサービスでは、直接叩いた方が柔軟で網羅性が高い。
| サービス | 直接アクセス手段 | MCPを使わない理由 |
|---|---|---|
| GitHub | gh CLI | 全APIをカバー。MCPは一部のみラップ |
| Google Cloud | gcloud CLI | 同上 |
| 一般的なREST API | curl / 専用CLI | 1リクエストで完結。MCPは薄いラッパーに過ぎない |
MCP側がAPIの全機能を網羅していないことが多く、「MCPにはないけどAPIには存在する機能」にぶつかる。直接叩く方が制約が少ない。
Chrome DevTools MCPが有利な理由
Chrome DevTools Protocol（CDP）は、REST APIとは性質が異なる。
1. ステートフルなプロトコル
CDPはWebSocket接続を維持し、セッション管理が必要。curlで1リクエスト投げて終わりではない。ページの選択状態、接続の維持、イベントの購読など、状態を持ち続ける必要がある。
2. プロトコルが複雑
CDPには数百のドメインとメソッドがある。正しいシーケンスで呼ばないと動かない。たとえば、スクリーンショットを撮るだけでも：
- WebSocket接続を確立
- ターゲット（タブ）を選択
Page.enableでページイベントを有効化Page.captureScreenshotを呼ぶ- Base64エンコードされた画像をデコード
3. MCPが状態管理を吸収してくれる
MCP経由なら、この複雑さがすべて隠蔽される：
mcp__chrome-devtools__new_page(url: "http://localhost:3000")
mcp__chrome-devtools__take_screenshot()
mcp__chrome-devtools__click(selector: "#submit-btn")
接続管理、セッション追跡、データのエンコード/デコードをMCPサーバーが処理する。自前でWebSocketクライアントを書く必要がない。
判断基準
MCPを使うかどうかは、対象プロトコルの性質で判断できる。
| 判断軸 | MCPなし（直接アクセス） | MCPあり |
|---|---|---|
| プロトコル | ステートレス（REST） | ステートフル（WebSocket等） |
| 1回のリクエストで完結するか | する | しない |
| CLIツールの充実度 | 高い | 低い・存在しない |
| 認証管理 | シンプル（トークン等） | OAuth等で面倒 |
MCPが不要
- REST APIに対応するCLIツールが存在する
- 1回のHTTPリクエストで完結する
- APIの全機能を使いたい
MCPが有利
- ステートフルなプロトコル（CDP、LSP等）で状態管理が必要
- 認証フロー（OAuth）をMCPに任せたい
- 自前でクライアントを実装するコストが高い
まとめ
「CLIなのにMCP使うの？」という疑問は自然だが、MCPの価値はAPI呼び出しの代行ではなく、複雑なプロトコルの状態管理を吸収することにある。Chrome DevTools MCPは、その恩恵が分かりやすい典型例だ。
逆に、ghで事足りるGitHub操作にMCPを挟むのは、ただの間接層が増えるだけで得るものがない。