メインコンテンツまでスキップ

MCPとCLI・Skillsの比較と使い分け

「MCP is dead. Long live the CLI」の主張と、それに対する反論・更新を整理し、MCP と CLI、Skills、Function calling をどう使い分けるかの判断基準をまとめます。結論を先に言うと、どちらか一方が正解なのではなく、利用者・クライアント・認証と監査の要件で使い分けるのが現実的です。

1. このドキュメントで扱うこと​

  • MCP is dead の主張
  • 実務上の痛み
  • Quandri の検証
  • 反論 1: 企業利用と HTTP
  • 反論 2: 2026-07-28 で解消された論点
  • CLI が勝つ条件と MCP が必要になる場面
  • Skills との関係、Function calling との違い
  • 判断フローとハイブリッド構成

MCP is dead の主張​

Eric Holmes は 2026-02-28 の記事で、MCP は実利をもたらさず、CLI の方が優れていると主張しました。論点は次のとおりです。

論点主張
特別なプロトコルが不要LLM は man ページ、Stack Overflow、GitHub のシェルスクリプトで CLI を学習済み。gh pr view 123 と指示すれば動く。MCP でも結局、各ツールの説明と使いどころを同じように書くことになる
人間も同じコマンドで再現できるJira で LLM が予想外の動きをしても、jira issue view を自分で実行して同じ出力を確認できる。MCP のツールは LLM の会話の中にしかなく、JSON のトランスポートログを調べることになる
パイプで合成できるjq、grep、リダイレクトで巨大な結果を絞り込める。MCP では全件をコンテキストに入れるか、サーバーに絞り込みを実装するしかない
認証が既存の仕組みで足りるaws のプロファイルと SSO、gh auth login、kubectl の kubeconfig はそのまま使える。壊れたときも aws sso login のように普段どおり直せる
可動部がないローカルの MCP サーバーはプロセスで、起動と常駐が必要。CLI はディスク上のバイナリにすぎない

実務上の痛み​

設計思想の議論に加えて、日常の摩擦も挙げられています。

  • 初期化が不安定
    • MCP サーバーが立ち上がらず、クライアントを再起動することがある
  • 再認証が終わらない
    • 複数の MCP を使うと、サーバーごとに認証が必要になる。SSO や長期の認証情報を使う CLI では、一度認証すれば済む
  • 権限が粗い
    • Claude Code では MCP ツールを名前単位で許可できるだけで、読み取り専用への絞り込みや引数の制限はできない。CLI なら gh pr view は許可し、gh pr merge は承認を必須にできる

Quandri の検証​

Quandri のエンジニアリングブログは、この記事を受けて自社の環境で計測しています。

  • コンテキストの消費
  • 速度
    • 元記事の著者の計測として、Jira MCP が REST の直接呼び出しの約 3 倍遅く、初回は初期化込みで約 9.4 倍遅いという結果を引用している。MCP サーバーが LLM と API の間にプロセスを挟むことによる、構造上のオーバーヘッドだと説明されている
  • 運用方針
    • 日常の gh / psql / aws は Bash と CLI、繰り返しのワークフローは Skills、強い CLI のないサービスやチーム全体の認証・権限スコープが必要なものは MCP、と併用している。CLI が既に認証済みで使えるなら、それが最も軽い選択肢だとしている

同じブログは、Claude Code の Tool Search によってコンテキストの問題が大幅に緩和されたと追記しています。計測値は「導入前の素朴な実装」のものとして読む必要があります。

反論 1: 企業利用と HTTP​

Charles Chen は、MCP を stdio で使うなら単純な CLI の方がよいことが多いと認めたうえで、Streamable HTTP 上の MCP は組織・企業での採用の要になると主張しています。

  • MCP は HTTP の上の薄いペイロードとやり取りの形式にすぎないため、HTTP を保護する手段 (TLS、OAuth、OIDC) がそのまま使える
  • HTTP エンドポイントに適用できる可観測性とテレメトリ (OpenTelemetry、ログ) がそのまま使える
  • API サーバーを作ってきた既存のフレームワークと運用の知見で、MCP の機能を提供できる
  • スケールとロードバランスも HTTP のやり方に従える

CLI は認証が不要な用途やソロの開発者には適しますが、組織の認証・認可・可観測性・スケールが必要な場面では、運用とセキュリティの面でリスクになると述べています。

反論 2: 2026-07-28 で解消された論点​

2026-07-28 版は、指摘された運用上の痛みのいくつかに仕様レベルで答えています。

痛み2026-07-28 での変化
初期化が不安定、可動部が多いinitialize とセッションを廃止。各リクエストが自己完結し、ロードバランサー配下のどのインスタンスにも届く
初回呼び出しの遅さ初期化のやり取りがなくなる。ただし、実際の速度は測って確認する
デバッグしにくいリクエストが自己完結するため、curl で再現しやすい
再認証の摩擦Client ID Metadata Documents (CIMD) への移行、RFC 9207 の iss 検証など、認可が整理された
ゲートウェイでの制御Mcp-Method / Mcp-Name ヘッダーで、JSON を解析せずにルーティングと認可ができる

一方で、ツール定義によるコンテキスト消費と、CLI のパイプによる合成性は、依然として有効な批判です。前者はクライアント側の段階的探索や Code Mode で軽減できますが、後者はサーバー側に絞り込みを用意する必要があります。

CLI が勝つ条件​

次の 3 つが揃う場合は、CLI (と Skills) が最も軽く、確実な選択です。

  1. エージェントにシェルがある
  2. 成熟した CLI が存在する (gh、aws、kubectl、psql など)
  3. 利用者が自分のマシンで認証済みの開発者である

この条件では、LLM の学習済みの知識がそのまま使え、定義を常駐させる必要もなく、人間が同じコマンドで再現できます。Charles Chen も、ローカルの機能や、jq、curl、grep のように学習データに十分含まれるツール、認証の要らないツールには、ローカルの CLI を使うべきだとしています。

MCP が必要になる場面​

次のいずれかに当てはまる場合は、MCP が必要になります。

  • シェルのないクライアント
    • Web、デスクトップ、業務アプリなど、シェルを持たない環境や、ターミナルを使わない利用者
  • スコープと監査が必要な組織の統制
    • ツールやスコープ単位の認可、HTTP 基盤での集中的なログと可観測性
  • 複数クライアントでの共有
    • 1 つのサーバーを、クライアントごとの連携コードなしに複数のホストで使う
  • CLI が存在しないサービス
    • Web だけで提供される SaaS など
  • 状態や長時間実行のバックエンドが必要なツール
    • HTTP の裏側で状態を保持する必要があるもの
  • 本番 DB の安全なアクセス
    • Quandri は、MCP サーバーなら読み取り専用モードや危険なクエリの遮断をサーバー側で強制でき、接続文字列もサーバー内で管理できると指摘している。Skills と CLI の組み合わせでは、LLM が DROP TABLE を実行するのを止められない。ローカルの開発用や個人の DB なら、Skills と CLI で足りる

Skills との関係​

Skills は、手順や知識をまとめたフォルダー (SKILL.md と補助ファイル) です。Quandri は、MCP を「すべてのメニューを先に広げる」ことに、Skills を「必要な本だけを司書に頼む」ことにたとえています。

  • CLI の使い方を Skill に埋め込み、Skill が呼ばれたときにだけロードする。定義が常駐せず、Skill の数に比例してコンテキストが増えない
  • MCP との関係は対立ではない。Skills over MCP 拡張を使うと、サーバーが Skill を skills/list と skills/get で公開し、クライアントは Resources の仕組みで必要なときだけ内容を取得できる。サービスの説明と手順を、そのサービスの MCP サーバーと一緒に配布できる
  • MCP Prompts は、多くのホストでスラッシュコマンドから呼ぶ、Skills に近い機能。Charles Chen は、Skill ファイルを手動で同期して配る現状を、HTML や JS を手動でダウンロードして Web アプリを動かすようなものだと指摘している。ただし、ホストによる対応にはばらつきがある (Codex が MCP Prompts に未対応であることが指摘されている)

Skills over MCP は、SDK とホストの対応が進行中です。利用前に各クライアントの対応状況を確認します。

Function calling との違い​

Function calling は、1 つのアプリが、1 つの LLM プロバイダーのために、自分でツールを定義・実行する仕組みです。ツールの所有者とモデルの利用者が同じなら、MCP のサーバーとクライアントを挟むのはオーバーヘッドになります。

MCP が効くのは、ツールを提供する側と使う側が別で、複数のアプリ (ホスト) から同じツールを使いたい場合です。プロトコルが標準化されているため、アプリごとに連携コードを書く必要がありません。MCP のツールも、最終的にはホストがモデルの Function calling の形式に変換して渡すため、両者は排他的ではありません。

判断フロー​

次のフローで、最初の候補を決めます。

これは出発点です。たとえば、1 つのアプリが 1 つのプロバイダーのためだけにツールを持つなら、MCP も CLI も使わずに Function calling で済ませる選択もあります。

ハイブリッド構成​

実際には、1 つに絞らずに併用します。Quandri の例に沿うと、次のように分けられます。

用途選ぶもの
日常的に使う gh / psql / awsCLI (Bash)。コンテキストコストがなく、ターミナルでそのままデバッグできる
コミットメッセージの下書きや PR レビューなど、定型の複数ステップのワークフローSkills。呼び出されたときだけロードされる
CLI がないサービス、チーム全体で統一した認証が必要なもの、本番 DB のように統制が必要なものMCP

2. MCP と CLI の比較​

観点CLI (+ Skills)MCP
コンテキスト消費定義の常駐なし。Skill は呼び出し時のみロード定義が常駐しがち。段階的探索で軽減できる
合成性パイプ、jq、grep で中間結果を絞り込める結果が会話に入る。絞り込みはサーバー側で用意する必要がある
デバッグ人間が同じコマンドを実行して再現できるステートレス化で curl での再現が容易になったが、会話内のツールである点は変わらない
認証aws / gh / kubectl の既存プロファイルや SSO を流用OAuth 2.1 による標準的な認可。クライアントごとに認可が必要になる
権限の粒度コマンド単位の許可リストは可能だが、実行環境の権限に依存スコープ・ツール単位で制御し、サーバー側で検証できる
クライアントシェルのある環境のみシェルのない Web / デスクトップ / 業務アプリでも使える
複数クライアントでの再利用クライアントごとに連携コードが必要1 つのサーバーを複数のクライアントで共有できる
監査・可観測性ローカルの履歴に依存HTTP の基盤で集中管理できる
運用バイナリを配置するだけサーバーの運用が必要 (リモートの場合)

3. 開発者がつまずきやすいポイント​

「MCP か CLI か」の二択にしない​

議論が「MCP is dead」か「MCP は必須」かに偏りがちですが、利用者とクライアント、認証と監査の要件で使い分けるのが実務的です。Quandri のように、同じ組織の中でも gh は CLI、Slack や Linear は MCP、のように併用します。

古い計測値を現在の MCP に当てはめない​

コンテキストの消費量や、Jira MCP の速度の計測は、Tool Search や 2026-07-28 の前に取られたものです。主張の方向性は参考になりますが、数値は自分の環境で測り直します。

CLI の権限制御を過信する​

CLI なら gh pr view を許可して gh pr merge は承認を必須にできます。ただしこれはホスト側の許可リストで、実行環境の権限に依存します。MCP のツール許可はツール名単位で、引数による制限はできません。どちらの場合も、認可の本質的な制御は、読み取り専用のトークンのような、最小権限の認証情報で行います。

シェルがあるだけで CLI を選ばない​

エージェントにシェルがあっても、CLI が成熟していない、出力が人間向けで機械可読でない、認証が個人の環境に依存している、といった場合は、MCP の方が安定します。CLI を選ぶときは、--json のような機械可読な出力があるかを確認します。

CLI があるからと、本番データへのアクセスまで CLI に任せる​

psql を Skill に書けば動きますが、LLM が書き込みや破壊的なクエリを実行することを、CLI は止められません。本番の DB や共有のデータには、読み取り専用モードやクエリ検証をサーバー側で強制できる MCP、または最小権限のロールを使います。

Skills をセキュリティ境界と考える​

Skill は手順と知識を渡すもので、権限を制限する仕組みではありません。Skill の内容や、allowed-tools のような権限の付与は、信頼できない入力として扱い、ユーザーの承認の下で使います。

MCP のコンテキスト問題を放置したまま比較する​

MCP の不利は、段階的探索や Code Mode を導入していない前提のものが多くあります。比較するときは、クライアントがどの対策を取っているかを揃えます。

4. コード例​

CLI で結果を絞り込む​

パイプで絞り込めば、中間データはコンテキストに入りません。MCP では、サーバーに同等の絞り込み引数を用意する必要があります。

# 自分にレビューが求められている PR の番号とタイトルだけを取り出す
gh pr list --search "review-requested:@me" --json number,title \
  | jq -r '.[] | "\(.number)\t\(.title)"'

CLI の権限をコマンド単位で分ける (Claude Code)​

.claude/settings.json で、読み取り系は許可し、書き込み系は承認を必須にします。

{
  "permissions": {
    "allow": [
      "Bash(gh pr view *)",
      "Bash(gh pr list *)",
      "Bash(gh pr diff *)"
    ],
    "ask": [
      "Bash(gh pr merge *)"
    ]
  }
}

一方、MCP のツールはサーバーやツールの名前で許可します。mcp__<server>__<tool> の形式で、ワイルドカードも使えますが、引数による制限は書けません。

{
  "permissions": {
    "allow": [
      "mcp__github__get_*"
    ],
    "ask": [
      "mcp__github__merge_pull_request"
    ]
  }
}

CLI の使い方を Skill にまとめる​

Skill は SKILL.md の先頭に name と description を持つ YAML フロントマターを置きます。説明文だけが常駐し、本文は Skill が呼ばれたときにロードされます。

---
name: pr-review
description: Review a GitHub pull request with the gh CLI. Use when the user asks to review or summarize a PR.
---

# PR review

1. `gh pr view <number> --json title,body,files` で概要を取得する
2. `gh pr diff <number>` で差分を読む
3. 指摘は重大度順にまとめる。`gh pr merge` は実行しない

併用する構成の例 (Claude Code)​

CLI がないサービスや、統制が必要なサービスだけを MCP で接続します。日常の gh などは、そのまま CLI を使います。

# CLI のないサービスをリモート MCP として追加 (チームで共有する場合は --scope project)
claude mcp add --transport http linear https://mcp.linear.app/mcp --scope project

# 認証は /mcp から OAuth で行う。登録の確認:
claude mcp list

5. まとめ​

  • MCP is dead の論点は、特別なプロトコルが不要、人間も再現できる、パイプで合成できる、既存の認証で足りる、可動部がない、の 5 つ
  • 実務上の痛みは、初期化の不安定さ、再認証、粗い権限の 3 つ。Quandri はこれに加えて、コンテキストの消費と速度を計測した
  • 2026-07-28 版で、ステートレス化と認可の整理が進み、運用上の論点の多くは軽減された。コンテキストと合成性は依然として有効な批判
  • CLI が勝つのは、シェルがある、成熟した CLI がある、利用者が認証済みの開発者である、の 3 つが揃う場合
  • MCP が必要になるのは、シェルのないクライアント、スコープと監査が必要な統制、複数クライアントでの共有、CLI がないサービス、本番 DB の安全なアクセス
  • Skills は CLI の使い方をオンデマンドでロードする手段で、MCP と対立せず、Skills over MCP で配布もできる。Function calling は 1 つのアプリが 1 つのプロバイダーのツールを所有する場合に十分
  • 実際には併用する。日常の CLI は CLI、定型のワークフローは Skills、CLI がないものや統制が必要なものは MCP

関連ドキュメント​

参考資料​