開発はMCPではなくCLIの方がいいのでは？

はじめに

最近、Claude Code と Claude Desktop を併用して、コードを書いたり、仕様を書いたり、タスク起票（チケット作成）をしていました。その中で、Claude Code はMCPをほぼ使わない一方、Claude Desktop はMCPに強く依存していると思い、メモがてら整理をしたいと思います。

CLIとClaude codeと相性がいい?

結論相性がいいと思います。

Claude Codeはterminalへアクセスできるため、コマンドを直接実行できます。
そのためGitHubやnpmなどの使い方さえLLMが理解できれば、特別なステップを挟まずプロンプトに沿って実行できます。

対してMCPは、ツールの確認・ツールの使用など複数のステップが発生します。

後述しますが、これのせいでトークンを余計に消費します。

なので、スピードやトークン、の観点で言えば抜群にCLIの方が良いです。

MCPはなぜ辛い？

Anthripicの公式ページをみると以下がありました

• https://www.anthropic.com/engineering/code-execution-with-mcp

ツール定義がコンテキストを圧迫する

多くのMCPクライアントは、接続しているMCPサーバのツール定義（名前・説明・引数スキーマ等）をLLMのコンテキストに直接載せた状態で推論させます。
そのため、接続ツールが増えるほど「リクエスト本文とは無関係な固定コスト」として、ツール定義ぶんのトークンを毎回（またはセッション開始時に）支払う構造になりがちです。

開発用途だと、DB・ログ・CI・クラウド・チケット管理…とツールが増やしていくと、結果として「本題に入る前にコンテキストが太る」「time to first token が遅くなる」「コストが上がる」が起きやすい、という辛さがあります。

当然LLMの性能の劣化します。

中間結果がLLMを往復してトークンを食う

複数ツールを連鎖させるとき、典型的には

1. ツールAを呼ぶ

2. 返ってきた結果（ときに巨大）をLLMが受け取る

3. その結果をもとにツールBを呼ぶ（=LLMが結果を“読み直して”次の入力を組み立てる）

というループになります。
このとき中間結果がそのままコンテキストに流れ込み、さらに次のツール呼び出しのために同じ情報を再度参照・再記述することになり、余分なトークン消費・遅延・転記ミスの温床になります（大きいログ、長いドキュメント、巨大JSONなどで顕著）。

Anthropicが提示している解決策

上の問題意識に対して、Anthropicは以下のような緩和策を提示しています。

• コード実行でMCPにアクセスする（中間処理を実行環境側でやり、LLMに戻す情報を最小化する／必要なツールだけオンデマンドで読む）
  https://www.anthropic.com/engineering/code-execution-with-mcp

• 実行時にツール検索して必要なものだけロードする（定義の一括注入を避ける）
  https://platform.claude.com/docs/ja/agents-and-tools/tool-use/tool-search-tool

ただし重要なのは、これらは「MCPという仕様が自動的に解決してくれる」というより、MCPクライアント／エージェント実装側の工夫で“辛さを抑える”アプローチだという点です。
つまり、環境によっては依然として「ツール定義の注入」「中間結果の往復」が起き、開発用途ではコスト・速度・安定性の面で辛さが残り得ます。

MCPが効くケース

一方で、MCPが有利な場面もあります。

まず権限管理です。Claude Desktopではtool単位で許可を出せますし、Claude CodeでもJSONのallow toolで管理できます。ただし、これはMCPの仕様そのものではなく、MCPをサポートするクライアント側の機能です。そのため、環境によっては同等の管理ができないケースがあります。自分はチケットを起票する際に、誤って削除するのが怖いので、delete 系はoffにしてます。

次にGUIとの親和性です。非エンジニアには、CLIの存在など知らないので、そういったツールに組み込む場合はMCP一択です。最近はMCP Appsのように、GUIでLLMと対話し、その中でMCPを使う体験が出てきています。AppsでUIを差し込み、対話体験を向上できる点は、CLIにはない価値です。

最後に、CLIが提供されていないサービスとの連携です。たとえば自分はLLMでタスク分解してLinearに登録していますが、Linearは公式CLIを提供していません。このような場合、MCPでタスクやプロジェクト登録を行えるのは実用的です。

MCPでも価値がある「汎用ツール」

個人的に、価値があるMCPは「3rd partyサービスと連携すること」そのものではなく、LLMの汎用的な操作を拡張するものだと思っています。

CLIで代替できる連携（例: GitHub操作、npm実行、DB操作など）は、環境さえ整っていればClaude Code + terminalで十分に回せることが多いです。一方で、LLMが苦手な領域（最新情報への追従、巨大なコードベースの俯瞰、成果物の実体験的な検証など）を補うツールは、MCPとして提供される価値が残りやすいと感じます。

Context7：学習データが古い問題を回避する

LLMは学習データのカットオフがあるため、ライブラリやサービスの仕様変更に追従できないことがあります。Context7のように最新のドキュメントを参照できる仕組みがあると、この弱点をかなり実務的にカバーできます。

たとえば「最近追加されたオプションを使った設定例が欲しい」「破壊的変更後の推奨パターンを知りたい」といった場面で、モデルの記憶に頼らず“今の一次情報”に寄せて回答・実装を進められるのが強いです。

Serena：プロジェクト全体の構造理解と参照効率を上げる

実務の開発では、単発のファイル編集よりも「この変更はどこに影響するか」「似た実装はどこにあるか」「責務の境界はどこか」といった全体構造の把握がボトルネックになりがちです。

Serenaのようにプロジェクト全体の構造理解を助け、効率的な参照を支援してくれるツールは、LLMの“探索コスト”を下げてくれます。結果として、無駄な読み戻しや見当違いの修正が減り、トークン消費や手戻りの削減にもつながります。

Playwrightなど：LLMに「目」を与えて成果物を検証する

LLMはテキスト上で正しそうなことを言えても、実際のUI/挙動が正しいかは別問題です。Playwrightのようにブラウザ操作・画面確認ができる手段があると、LLMが成果物をユーザー視点で検証できるようになります。

たとえば「ボタンが押せない」「表示崩れがある」「導線が意図と違う」といった問題は、コードやログだけでは気づきにくいことがあります。こうした“最後の確認”を自動化できるのは、開発フロー全体で見るとかなり大きい価値です。

MCP vs CLI 比較（token使用量/権限管理/認証管理/GUI向け）

観点	CLI	MCP
token使用量	実行対象（コマンド）と入出力が明確になりやすく、抑えやすい	ツール数と参照の仕方次第で増える可能性がある
権限管理	実行環境/3rd partyの権限で管理する(githubのmerge 権限など)	クライアントが対応していれば tool 単位で管理できる（ただしクライアント依存）
ユーザ	基本的に開発者向け	非エンジニア向け

結論

まとめてみると、MCPの課題をMCPの仕様拡張ではなく、その外部で解決しようとしてるのが辛みを助長してる気がします。

mcpの設定ファイルはclaudeはjsonですが、codexはtomlですし、tool searchもclaudeの機能であってmcpのものではないんですよね。

開発用途であれば、まずCLIを選ぶのが良いです。一方で、Context7/Serenaのような低レイヤーのMCPツールには価値があります。

また、GUIでの対話体験を重視するなら、MCP（MCP Apps等）が有効ですし、今後の発展もあるかと思います。

それでは良いCLIライフを