MCPの値段を比べる前に、エージェントの構成を見る。
同じ仕事をAIに頼んでも、使う道具の渡し方が変わるだけで、消費トークンと完了率が大きく動くことがあります。
2026年8月9日に公開された比較研究は、MCPとCLIの単純な勝敗よりも、モデルの周りにある実行基盤の差が重要だと示しました。
CLIのみの比較で、完了1件あたりの入力トークンに見えた差
同じ構成でMCPとCLIを対応させたときの比率
MCP側で未完了ランに使われた支出の割合
「MCPとCLIのどちらが安いか」ではなく、「このエージェントに、どの形で道具を渡すと仕事が安定するか」と考えると、研究の数字が実務に近づきます。
まず、3つの言葉をそろえる。
この研究を読むとき、MCP、CLI、エージェントの構成という3つの言葉を分けて考える必要があります。
道具を共通の窓口で渡す仕組み
Model Context Protocolの略です。AIアプリケーションが、外部の検索、ファイル操作、APIなどを、決まった形式で発見して呼び出せるようにします。
動的な発見と共通化に向くコマンドとして道具を渡す方法
Command Line Interfaceの略です。AIエージェントがシェルからコマンドを実行し、その標準出力や終了コードを結果として受け取ります。
既知の操作を短く渡しやすいモデルの周りにある実行基盤
モデルにプロンプトを送り、ツールを実行し、結果を戻し、失敗を扱う一連のプログラムです。ここでは「構成」と呼びます。
今回の主役はここ大事な区別。 MCPとCLIは道具を渡すインターフェースです。構成は、そのインターフェースをモデルにどう見せ、どう実行するかを含む周辺の仕組みです。
比較は、ひとつの仕事を54個のセルに分けた。
研究チームは、非公開のGitHubリポジトリを使うひとつのソフトウェア作業を固定しました。課題は、Issueを探し、ブランチを作り、パッチを適用し、コミットし、プルリクエストを開き、ファイル数を報告する6操作です。
「できました」を信じない。
完了したかどうかは、エージェントの自己申告ではなく、リポジトリの状態を読み直して4条件で確認しました。
- 正しいブランチが存在する
- 指定されたパッチが適用されている
- コミットが存在する
- プルリクエストと報告値が正しい
FACT 対象はClaude Code、OpenAI Codex、qwen-code、Hermes、opencode、pi、Tauの7構成です。モデルはGPT系、GLM系、Qwen系、ローカルモデル、Sonnet系の5種類が使われています。
数字が示したのは、プロトコルの値札ではない。
研究の中心的な発見は、同じ仕事を完了するまでに必要な入力トークンが、構成によって大きく変わることでした。トークンはAPI料金そのものではありませんが、同じモデルと料金体系なら、コストの強い手がかりになります。
完了1件あたりの入力トークン中央値
研究の主行列における中央値です。モデルの組み合わせや構成の実装も異なるため、すべての環境にそのまま当てはまる価格表ではありません。
CLIだけでも、28倍の差が出た。
CLIのみの比較では、piの14,660トークンに対し、qwen-codeは297,649トークンでした。ただし、この比較はMCPを除けば構成が同じになるという意味ではありません。
直接比較の比率は、0.43倍から29倍。
同じ構成でMCP利用とCLI利用を対応させた13組では、MCPのほうが少ない組も多い組もありました。9組は、同じ条件での実行ぶれの範囲内でした。
失敗数は同じで、失敗コストが違った。
MCP側もCLI側も19回中3回が未完了でした。ただし未完了ランに使われた支出は、MCP側が12.9%、CLI側が2.2%でした。
指示より、実行環境が使い方を決めた。
研究では、MCPを使うように促す指示と、CLIを使うように促す指示も試しました。しかし、21ランの観察では、MCPだけを使ったものが6、シェルだけを使ったものが6、両方を使ったものが6、ツールを使わなかったものが3でした。
もうひとつの観察。 一部の実行では、割り当てられた接続方式ではなく、直接GitHub HTTPを使いました。ベンチマークで「何を用意したか」と「実際に何を使ったか」を分けて測る重要性が見えます。
開発者が持ち帰る、3つの判断軸。
成熟したCLIがあるなら、まず短い経路を測る。
操作が固定され、終了コードや出力を検証しやすいなら、CLIは候補になります。呼び出し回数、返却ログ、再試行を先に計測してください。
発見と共通化が必要なら、MCPを測る。
接続先が増え、ツールの説明やスキーマを共通形式で扱いたいなら、MCPの価値は単価だけでは決まりません。初期のスキーマ量と、実際に選ばれたツールを記録します。
方式を変える前に、周辺の差分を固定する。
モデル、システム指示、ツール説明、返却形式、再試行、認証、観測方法が変わると、MCPとCLIだけの比較ではなくなります。
自分の環境で最初に取る4つの数字
- 01完了した仕事あたりの入力トークン
- 02未完了ランに使ったトークンと時間
- 03用意したツールと、実際に使ったツール
- 04再試行を含む完了率
この研究から、言い過ぎてはいけないこと。
LIMIT 01対象はGitHubを使うひとつのソフトウェア作業で、すべての業務やサービスを代表するものではありません。
LIMIT 02公式MCPサーバーと成熟したCLIという、今回の環境に固有の条件があります。
LIMIT 03構成ごとにモデルや実装が異なり、MCPとCLIの効果だけを完全に分離できたわけではありません。
LIMIT 04したがって、今回の最も堅い示唆は「MCPかCLIかの普遍的な勝者」ではなく、「構成を含めて測定しないと、方式の評価を誤る」です。