MCP使わなくてもCLIで十分じゃない？？ Claude Codeのコンテキスト戦略
1. 導入 — GitHub MCPを消した日
Claude Codeを初めてセットアップしたとき、GitHub MCPを入れた。「GitHubの操作を自然言語でできるなら便利そう」と思ったからだ。
ただ、入れたきり何も考えずに放置していた。起動するたびになぜかfailedと表示されるのを横目に、特に困ることもなくそのまま使い続けていた。
あるとき気づいた。自分がClaude CodeにGitHubの操作をさせるとき、いつも gh コマンドを使っている。PRの作成も、issueの確認も、全部CLIだ。GitHub MCPの出番が一度もない。
「あれ、これ要るのか？」
しかもMCPはツール定義がコンテキストウィンドウに常駐する。使ってないのにトークンを食っている。だったらCLIでいいんじゃないか。
消してみた。何も困らなかった。
そこからシンプルな疑問が湧いた。じゃあ、どういうときにMCPを使えばいいんだろう？ CLIとどう使い分けるのが正解なのか。調べてみたら、同じことを考えている人が結構いた。
2. MCPの仕組みとコスト
MCPを使うと、Claude Codeに外部ツールを接続できる。GitHub、Slack、データベースなど、さまざまなサービスを自然言語で操作できるようになる。便利だ。
ただし、コストがある。MCPサーバーを接続すると、そのツール定義（どんなツールがあるか、どんなパラメータを受け取るかの情報）がコンテキストウィンドウに常駐する。ツールを実際に使っていなくても、定義だけでトークンを消費し続ける。いわば、使わないメニュー表をずっとテーブルに広げているようなものだ。
これがどれくらいのコストかというと、たとえばGitHub MCPのフルセットは93ツールで約55,000トークンを消費する[1]。Claude Codeのコンテキストウィンドウはデフォルトで200Kトークン（Opus 4.6ではBetaで最大1Mトークン）だから、デフォルト設定ならGitHub MCPだけで全体の約27%を占めることになる。1Mコンテキストでも5.5%だ。小さく見えるかもしれないが、MCPサーバーは普通ひとつでは済まない。便利そうだからとあれもこれもと入れていくと、肝心の作業に使えるコンテキストがどんどん狭くなる。
一方で、同じGitHubの操作を gh CLIで行うと、消費はコマンドの入出力分だけ。スキーマの常駐コストはゼロだ。あるベンチマークでは、MCPで約145,000トークンかかった処理がCLIでは約4,150トークンで済んだという報告もある[2]。約35倍の差だ。
3. CLIが強い理由
モデルがすでに知っている
CLIの最大の強みは、モデルがすでに使い方を知っていることだ。gh, git, docker, kubectl といったツールは、学習データに大量の使用例が含まれている。スキーマ定義を渡す必要がなく、トークンコストはゼロ[3]。「PRを作って」と言えば、Claude Codeは gh pr create を自分で組み立てる。
Unix哲学との相性
CLIはパイプでコマンドを繋げられる。gh pr list | grep "draft" のように、小さなコマンドを組み合わせて複雑な操作を表現できる。この composability はLLMにとって自然だ。MCPでは一つの構造化されたAPIコールで完結させる必要があるが、CLIなら段階的に組み立てられる[3:1]。
Claude Code自身がCLIを推奨している
Claude Codeの公式ドキュメントでも、GitHubとの連携には gh CLIの使用が案内されている[4]。issueの作成、PRのオープン、コメントの読み取りなど、GitHub操作は gh コマンドで完結する設計だ。
Skills / CLAUDE.md でガイドできる
「CLIだとモデルに使い方を教えられないのでは？」という心配があるかもしれない。しかしClaude Codeには、Skills（再利用可能な指示セット）やCLAUDE.md（プロジェクトごとの設定ファイル）という仕組みがある。ここにCLIツールの使い方やワークフローを定義しておけば、MCPなしでも十分にガイドできる。
自分の場合、Google Workspace CLIの gog コマンドの使い方をSkillとして定義している。MCPサーバーを入れなくても、gog gmail list や gog cal today といったコマンドをClaude Codeが適切に使ってくれる。
枯れた技術の安心感
CLIツールは長い歴史がある。ドキュメントは豊富で、エラーが出てもStack Overflowですぐ解決策が見つかる。MCPサーバーはまだ新しいプロトコルで、接続が不安定だったりfailedになることも珍しくない（自分のGitHub MCPがまさにそうだった）。
4. それでもMCPが活きるケース
ここまでCLIの優位性を書いてきたが、MCPがダメだと言いたいわけではない。CLIでは辛い場面が確実にある。
認証が複雑なサービス
OAuthフローが必要なAPIを、毎回Bashでトークン取得から組み立てるのは現実的ではない。MCPサーバーは認証を内部で処理してくれるので、こういったサービスとの接続には素直にMCPを使う方がいい。
CLIが存在しないサービス
そもそもCLIが用意されていないサービスもある。たとえば自分が使っているContext7（ライブラリのドキュメントを検索できるMCPサーバー）は、同等のCLIツールが存在しない。Figma連携も同様だ。CLIがないなら、MCPを使うしかない。
構造化レスポンスが欲しいとき
MCPはJSON Schemaでレスポンスの型を定義できる。CLIの出力はテキストなので、モデルがパースする必要がある。複雑なデータ構造を正確に扱いたい場面では、MCPの構造化レスポンスに分がある。
Tool Searchという改善
MCPのコンテキストコスト問題に対して、Anthropicも手を打っている。Tool Searchという機能は、全ツールの定義を常駐させる代わりに、必要なツールだけを動的にロードする仕組みだ。これにより約85%のトークン削減が報告されている[5]。MCPツールの定義がコンテキストの10%を超えると自動で有効になる。
MCPのコスト問題は徐々に改善されつつある。ただ、CLIで済む場面にわざわざMCPを使う理由にはならない。
5. 自分の使い分けルール
個人的な結論として、Skills + CLIで大抵のことはどうにかなる。
Claude CodeにはSkillsやCLAUDE.mdといった仕組みがあって、CLIツールの使い方をそこに定義しておけば、MCPと同等のガイドができる。しかもコンテキストコストは圧倒的に低い。MCPがなくても、ちゃんと動く。
実際に自分の環境はこうなっている。
| ツール | 方式 | 理由 |
|---|---|---|
| GitHub | CLI (gh) |
CLIで全操作できる。MCP不要 |
| Git | CLI (git) |
言うまでもなく |
| Google Workspace | CLI (gog) + Skills |
Skillに使い方を定義してガイド |
| ドキュメント検索 | MCP (Context7) | 同等のCLIが存在しない |
| Figma連携 | MCP | CLIでの操作が現実的でない |
表を見てもらえばわかるが、MCPを使っているのはCLIが存在しないサービスだけだ。Figmaのようにそもそもコマンドラインで操作する世界ではないものや、Context7のようにCLIの代替がないもの。逆に言えば、それ以外は全部Skills + CLIで回っている。
GitHub MCPを消したことがこの記事のきっかけだったが、消した後に困ったことは一度もない。むしろ、failedの表示が消えてすっきりした。
MCPを入れる前に、まずそのサービスにCLIがあるか確認してみてほしい。あるなら、Skillsに使い方を書いてCLIで使う方がいい。MCPは「CLIがない」ときの選択肢だと思っている。
使っていないMCPサーバーが failed のまま残っていたら、一度消してみるといいかもしれない。たぶん、困らない。
-
同上。Microsoft Intuneのコンプライアンスチェック（50デバイス処理）での比較。 ↩︎
Discussion