Claude Codeを使い込んでいる開発者の間で、ある流れが生まれています。
MCPサーバーからCLIツールへの乗り換えです。
Redditの開発者コミュニティで、このテーマが大きな議論を呼びました。
本記事では、その議論の中身を整理していきます。
なぜCLIが支持を集めているのか。
そして、MCPにもまだ出番があるのか。
この2点を軸に考えてみましょう。
MCPへの期待と現実のギャップ
MCP（Model Context Protocol）は、Claude Codeと外部サービスを接続する仕組みです。
GitHub、Stripe、データベースなど、さまざまなサービスとClaudeをつなげられます。
理論上は魅力的なアプローチでしょう。
ところが、実際に使い込んだ開発者たちは次々と壁にぶつかっています。
認証が突然切れる。
パラメータの受け渡しでClaudeがミスをする。
タイムアウトも頻発する。
ある投稿者は、マルチエージェント構成で不動産業務を自動化していました。
しかし、夜間にトークンのリフレッシュが失敗。
翌朝にはすべてが止まっていた、と報告しています。
では、問題の本質は何か。
MCPは、Claudeと外部サービスの間に抽象レイヤーを追加します。
この抽象レイヤーこそ、信頼性が最も求められる箇所です。
そこに不安定さが入り込むと、ワークフロー全体が崩れてしまうのです。
なぜCLIとClaudeの相性が良いのか
「Claudeはターミナルで生まれ育ったようなものだ」と表現した開発者がいました。
少し大げさかもしれません。
しかし、的を射ています。
Claudeの学習データには、膨大な量のシェルスクリプトやドキュメントが含まれているはずです。
Stack Overflowの回答やGitHubのイシューも同様でしょう。
つまり、CLIのフラグやオプションを「すでに知っている」わけです。
エッジケースへの対処法も含めて。
MCPの場合はどうか。
Claudeは毎回、カスタムインターフェースの使い方を学び直す必要があります。
一方CLIなら、既存の知識をそのまま生かせる。
この差は想像以上に大きいのです。
あるコメントでは、CLIがMCPに勝る理由を3つに整理していました。
1つ目は、状態の明示性です。
gh pr list –json title,stateを実行すれば、GitHubの現在の状態がそのまま返ってきます。
一方、MCPの呼び出しが失敗するとどうなるか。
何が起きたのかを、抽象レイヤー越しに推測するしかありません。
2つ目は、監査のしやすさです。
ripgrep | jq | gh pr createのようなパイプラインなら、データの流れを誰でも追えます。
しかし、MCPの連鎖呼び出しだと話が変わる。
Claudeが本当にファイルを読んだのか。
それともハルシネーションなのか。
その判断が難しくなるのです。
3つ目は、障害時の振る舞いです。
CLIのコマンドがタイムアウトしたとしましょう。
パイプラインの次の段階で、すぐにそれを検知できます。
しかし、MCPがタイムアウトした場合は違います。
Claudeは自分がどの状態にいるのか、把握できなくなってしまうのです。
開発者が実際に使っているCLIスタック
Reddit上で多くの開発者が、実際のCLI構成を共有していました。
順に見ていきましょう。
GitHub CLI（gh） は、最も支持を集めたツールの一つです。
PRの作成、イシュー管理、コード検索に対応しています。–jsonフラグと–jqを組み合わせれば、出力の加工も自在。
Claudeはこれらのコマンドを巧みに連鎖させます。
イシュー作成からPRのレビュー依頼まで、一気に実行できるとのことでした。
Stripe CLI は、Webhookのテストやイベントのトリガーに使われていました。
ログの監視にも対応しています。
–output jsonによるエージェント向けの出力が好評です。
決済フローの手動監視から解放されたという声も上がっていました。
Vercel CLI は、デプロイや環境変数、ドメイン管理に活躍しています。
トークンベースの認証に対応しており、ブラウザを開く必要がありません。
これが大きな利点でしょう。
Supabase CLI は、ローカル開発環境の構築に使われています。
データベース管理やEdge Functionsの操作にも対応。
Claudeの理解度が特に高いツールとして挙げられていました。
Neon CLI は、PostgreSQLのブランチ管理用です。
Claudeがブランチを作成し、マイグレーションをテストする。
終わったらブランチを削除する。
本番環境を壊すリスクなしに、この流れを実現できます。
Sentry CLI は、リリース管理やソースマップの処理を担います。
ログの確認にも使えます。
スタックトレースをコピペする必要はもうありません。
Claudeが直接エラーを診断できるようになったそうです。
ripgrepは別途インストール不要
興味深い事実が、複数のコメントで指摘されていました。
Claude Codeの組み込みGrepツールは、内部的にripgrepを使っているというのです。
あるユーザーが、Claude Code内部のシステム記述を共有していました。
それによると、Grepツールはripgrepベースで構築されています。
そのため、別途インストールする必要はありません。
ただし、注意点もあります。
Claudeがbashコマンドとしてgrepを実行する場合と、組み込みGrepツールを使う場合。
この2つは別物です。
最大限のパフォーマンスを求めるなら、組み込みツールを使うのがよいでしょう。
CLIがなければ作ればいい
最も高い支持を集めたコメントの一つが、こんな提案でした。
「サービスにCLIがなければ、Claudeに作らせればいい」と。
あるチームの実績は印象的です。
Slack、Bitbucket、Google Docs、Google Sheets、Google Slides、Harvest。
これらすべてのCLIを、Claude Codeで構築したというのです。
最初の一つだけは手間がかかります。
OAuth認証の共通基盤を作る必要があるからです。
しかし、二つ目以降は共通部品を再利用できます。
そのため、簡単に量産できると述べていました。
具体的なワークフローも共有されていました。
- まずplan-modeで実装計画を策定する
- 次に、作業を並列実行可能なウェーブに分割する
- サブエージェントに実装を任せる
- 最終的にQAウェーブでテストを行う
この流れだったようです。
「CLI自作」という選択肢の存在が、CLIアプローチの柔軟性を象徴しているのかもしれません。
それでもMCPが必要な場面はある
CLI支持派が多数を占めた議論でした。
しかし、MCPの存在意義を指摘する声も一定数ありました。
まず、非技術者への対応です。
CLIはClaude Codeを使う開発者には最適でしょう。
しかし、Claude DesktopやClaude Webを使う非技術者には向きません。
そうした人たちにとって、MCPは依然として主要な接続手段です。
ある開発者はこう語っていました。
「自分はCLIに移行した。でも、家族や技術に詳しくない友人にはMCPが必要だ」と。
次に、セキュリティの観点です。
CLIツールは、ローカル環境に広範なアクセス権を持ちます。
一方、リモートホストされたMCPサーバーは、アクセス範囲を限定しやすい。
企業環境での認証情報の管理にも、OAuthベースのMCPが向いているケースがあるでしょう。
そして、CLIが存在しないサービスとの統合です。
たとえば、MindManagerやPower BIデスクトップ版のようなCOM自動化。
こうしたシステムには、CLIパスがそもそも存在しません。
MCPが薄いラッパーとして機能する唯一の手段だとする意見もありました。
ハイブリッドアプローチという現実解
議論を通じて浮かび上がったのは、「ハイブリッドアプローチ」です。
CLI一辺倒でもなく、MCP一辺倒でもありません。
中核となる開発ツール（gh、Vercel、Stripe、Supabaseなど）にはCLIを使う。
そして、特定の用途に限ってMCPを併用する。
たとえば、Context7はリアルタイムでドキュメントを取得するツールです。
Playwrightはブラウザ自動化に使います。
これらはMCP経由で動かし、日常的な開発作業はCLIで回す。
そんな組み合わせが紹介されていました。
なお、Context7もPlaywrightも、最近はCLI版をリリースしています。
PlaywrightのCLI版は、MCP版の完全な書き直しとのこと。
同等の機能を備えているそうです。
ツール側もCLIファーストの流れに対応し始めた兆しと言えるかもしれません。
エージェントに適したCLIの条件
最後に、あるコメントが整理していた条件を紹介しておきます。
「AIエージェントと相性の良いCLI」には、どんな特徴が必要なのか。
まず、構造化出力のサポートです。
–jsonや–format jsonのようなフラグがあると、Claudeは出力を正確にパースできます。
人間向けのテキストから値を抽出するより、はるかに安定するでしょう。
次に、非対話モードの存在です。
「本当に実行しますか？」という確認プロンプトは、エージェントとの相性が悪い。
–yesフラグのようなバイパスが欠かせません。
そして、APIキーや環境変数による認証への対応です。
ブラウザを開いてOAuthフローを踏むタイプのCLIは、自動化に向きません。
最後に、パイプ出力時のANSIエスケープコードの除外です。
カラー出力は人間には見やすいでしょう。
しかし、エージェントにとっては邪魔になります。
まとめ
Claude Codeのエコシステムにおいて、MCPからCLIへの移行は明確なトレンドになりつつあります。
背景にあるのは、Claudeがターミナルコマンドを深く理解しているという事実です。
加えて、CLIの持つ透明性や信頼性も大きな要因でしょう。
ただし、MCPがすべての場面で不要になったわけではありません。
非技術者向けのインターフェースや、セキュリティ要件が厳しい企業環境。
CLIパスが存在しないサービスへの統合。
こうした場面では、MCPが依然として有効です。
この議論から得られる最大の教訓は、ツール選択を二者択一で考えないことでしょう。
CLIを基盤に据えつつ、MCPを必要な箇所にピンポイントで使う。
この現実的なハイブリッド構成が、現時点での最適解と言えそうです。
