MCP に
エージェントの Context を食い尽くさせない
199 個のツール、毎ターン 40K tokens の schema コスト——五層アーキテクチャで 90% 削減するまで。
Service → SDK → CLI → MCP → Skill によって、 AI Agent が 最小限の token で最大限の仕事ができるようにします。
どんな問題に直面したのでしょうか？
三つの実際の課題から、この五層アーキテクチャが生まれました。Token の急増、MCP プロセスの増殖、Tool が多すぎて正しく選べないことです。
Token の急増
Playwright MCP は呼び出すたびに大量の token を消費します。使わない場合でも、tool schema が context window を占め、毎ターンコストが発生します。
Playwright CLI に置き換えた結果：
五層はそれぞれ何をするのでしょうか？
五層は上から順に Skill（意図のルーティング）、MCP（書き込み操作）、CLI（読み取り操作）、SDK（HTTP に触れる唯一のラッパー層）、Service（ビジネスロジック本体）です。上位層は必ず下位層を import します。
基本原則：Bug Fix は自動的に伝わります——SDK の bug を一つ直せば、CLI と MCP の両方に反映されます。 SDK 層がなければ、各利用者が HTTP + auth + error handling をそれぞれ実装することになり、保守は地獄です。
Skill ──invoke──► CLI （読み取り） / MCP （書き込み）
MCP ──import──► SDK ──HTTP──► Service
CLI ──import──► SDK ──HTTP──► Service
// SDK だけが HTTP に触れる
// SDK を変更すれば、上位の利用者すべてに変更が反映される
なぜ一層でも欠かせないのでしょうか？
| 利用者 | 最適な接続層 | 理由 |
|---|---|---|
| ほかの Core Module | Service | 同一プロセス内で services.py を直接呼び出し、overhead はゼロ |
| Python スクリプト / Notebook | SDK | プログラムからアクセスでき、error handling も完備 |
| 人間（ターミナル） | CLI | --help 見つけやすく、pipe で組み合わせられる |
| AI Coding Agent Claude Code / Codex CLI / Gemini CLI |
CLI （読み取り） / MCP （書き込み） | 読み取りを Bash に任せれば schema はゼロ。書き込みには typed input が必要 |
| スケジューラー | CLI | shell command はスケジューリングの共通言語 |
| AI ワークフロー | Skill | 高水準の意図をルーティングし、CLI または MCP を自動で選ぶ |
「CLI は overhead ゼロの万能インターフェースです。shell を実行できるものなら何でも使えますが、
MCP は MCP protocol 対応の client でしか使えません。」
どうやってここまでたどり着いたのでしょうか？
このアーキテクチャは一度に設計したものではありません。四つの段階で、その時々に行き詰まっていた課題を解決し、つなぎ合わせて今の形になりました。
Token 急増からの最初の教訓
Playwright MCP の tool schema は非常に大きく、対話の毎ターンで system prompt に注入されます。そのターンでブラウザーを使わなくても token は消費されます。Playwright CLI に置き換えたところ、token 使用量は 98% 減りました。
気づき：CLI でできることは MCP に載せるべきではありません。
複数の session を開くと起こる掛け算の災難
MCP server が 23 個まで増えると、Claude Code session を一つ追加するたびに全プロセスが比例して複製されます。3 個の session なら常駐プロセスは 69 個です。解決策は mcpproxy による集約と、読み取り操作を CLI に移すことでした。
気づき：MCP server / tool の数を減らす必要があります。
業界でもっとも徹底した tool の圧縮
Cloudflare の Code Mode では、 MCP が公開するのは 2 個の tool、：search() と execute()だけです。ほかの操作はすべてサンドボックス内でその場で記述します。tool の数と能力が反比例することを示しました。
気づき：私たちはそこまで極端にはしませんが、原則は同じです——tool は少ないほどよいのです。
使い捨て Tools — サンドボックスで補完
すべての操作に恒久的な tool が必要なわけではありません。Cloudflare Code Mode に着想を得て、バッチ操作はサンドボックス内でその場で記述し、MCP tool slot を占有しないようにします。
Cloudflare: 2 permanent tools + sandbox ですべての操作をその場で記述
現実路線: ≤10 permanent tools/server + sandbox で低頻度の操作を補完
// 共通原則：恒久的な tool は希少資源。枠を使う価値がなければ sandbox を使う
判断基準：ある操作を恒久的な tool にする価値はあるでしょうか？
→ 週に ≥ 3 回使う + パラメーターの組み合わせが複雑 + discoverability が必要 → 五層で対応
→ それ以外 → sandbox でその場で書き、使い終えたら捨てる
五層を使わないとどうなるでしょうか？
| 代替案 | 問題 | 結果 |
|---|---|---|
| Service のみ | HTTP 呼び出ししかできない | AI agent、cron、CLI の利用者が全員、自分で HTTP client を書く必要がある |
| Service + MCP | Token overhead + プロセスの増殖 | 23 servers × 3 sessions = 69 プロセス。schema が毎ターン token を消費する |
| Service + CLI | 書き込み操作に typed schema がない | LLM が誤ったパラメーターを渡し、input validation もない |
| すべて MCP 経由 | CLI の利用者を排除してしまう | Codex CLI、Gemini CLI、cron がすべて接続できない |
| 各層で HTTP を個別に実装 | 統一する SDK がない | 一か所直しても別の場所を直し忘れ、Ghost Parameter アンチパターンが増える |
Agent SDK で Tool の注入を自分で制御する
Agent SDK を使って独自 client を構築するなら、アプリケーション層でLLM の context に入れる tool schema を完全に制御できます。プラットフォームの対応を待つ必要はありません。Speakeasy の動的ツールセット方式では、同じ発想で tool を選別し、token を 96% 削減しました。
all_tools = mcp_server.tools_list() # 199 個を受け取る（protocol 層）
relevant = bm25_filter(all_tools, query) # 自分で 5 個に絞り込む
response = client.messages.create(
tools=relevant, # LLM に送るのは 5 個だけ
)
重要な違い：MCP protocol 層の tools/list はすべてのツールを返します——ここは変えられません。
一方、API の tools[]に何を入れるかは client が決めます——つまり、完全に自分で制御できます。
Claude Code のような既製の client を使う場合は、すべて詰め込まれます。独自 client なら自分で選別できます。
実装コストは実は低い
「限界コストは下がり、組み合わせやすさは長期的な利益になります——ただし、保守コストも長期にわたります。」
⚠ 五層アーキテクチャの代償
OpenCLI コミュニティの潮流の変化
オープンソースコミュニティでも CLI が標準のインターフェースになりつつあります。私たちだけが唱えている方向ではありません。
OpenCLI ウェブサイトやデスクトップアプリを標準化された CLI に変換します。CLI-Anything すべてのソフトウェアを Agent が CLI から操作できるようにすることを目指しています。「API はありますか」より「CLI はありますか」と尋ねる開発者が増えています。
理由は明快です。The New Stack の 2025 年の記事は、業界全体が Agentic CLI 時代に入っていると伝えました。AI coding tool がどれも shell を実行できるなら、CLI はツール間で共有できる最大公約数になります。
これは CLI の復活ではありません。AI 時代に CLI の価値が再発見されたのです。
199 個のツール、一つのロジック
読み取りは CLI、書き込みは MCP——199 個のツールはこの一本の境界で動き、人、スクリプト、AI が それぞれ必要なものを使えます。
Token の急増からコミュニティの潮流による検証まで、一歩ずつ課題に押されて形になりました。一か所変えれば、すべてに反映されます。
課題 1: Playwright MCP で token が急増
→ CLI で token を 98% 節約
課題 2: CC を複数開く → プロセスが比例して増える
→ mcpproxy 集約 + 読み取り操作を CLI に移す
課題 3: Tool が多すぎて LLM が正しく選べない
→ ≤10 tools/server + sandbox で補完
検証 1: Cloudflare はわずか 2 tools で IDE 全体を操作
→ 同じ原則ですが、私たちはもっと現実的に進めます
検証 2: OpenCLI コミュニティが CLI-first に移行
→ AI 時代の CLI はツール間で共有できる最大公約数
// まとめ
Service → SDK → CLI → MCP → Skill
199 個のツール、一つのロジック、三種類の利用者
まず自分の schema の請求額を計算する
上の 40K tokens は私の環境での数字です。あなたの環境では結果がまったく違うかもしれません。三つの項目を入力すると、本文で引用した二つの定数（tool schema 一つにつき約 200 tokens、業界の推奨は MCP server ごとに ≤ 10 tools）を使い、あなたの毎ターンのコストと常駐プロセス数を計算します。計算はすべてブラウザー内で行い、データはどこにも送信されません。
定数の出典はすべて本文にあります。200 tokens/schema は「8 tools × 200 tokens/schema = 1,600 tokens/turn」、プロセス数は「3 sessions × 23 MCP servers = 69 個の常駐プロセス」という線形の関係に基づきます。10 tools/server は本文で引用した業界の推奨値です。ここで計算するのは schema の常駐コストだけで、実際の I/O は含みません——実際の使用量は呼び出し方にもよります。
あなたの AI Agent にコピーする
MCP tool schema は毎ターン token を消費します。でも、あなたの tool の大半は「読み取り」です——schema はそもそも不要です。ツールが増えると schema だけで数万 token を使い、10 個を超えると LLM が間違って選ぶ確率も上がります。この記事の五層アーキテクチャは「読み取り」を CLI に移し、MCP には「書き込み」だけを残します。
以下をあなたの AI に貼り付けてください。まず現在の MCP 設定を実際に調べてもらい、そのうえで五層に照らして何を移せるか判断してもらえます。
さらに読む
以下の記事はどれも実際に読み、意思決定に影響を受けたものです。手当たり次第に集めたリストではありません。
| 記事 | 重要な理由 |
|---|---|
| Code Mode: Give Agents an Entire API in 1,000 Tokens | Cloudflare は実測で 2 個の tool だけで IDE 全体を動かし、token コストを 81% 削減しました。「tool は少ないほどよい」という原則を裏づけています |
| Your MCP Server Is Eating Your Context Window | Apideck は MCP schema が context をどう圧迫するかを分析し、代替策として CLI を提案しました——80 tokens の prompt と数万 tokens の schema の比較です |
| Advanced Tool Use — Anthropic Engineering | Anthropic は tool schema が context を占める問題を公式に認め、Tool Search によって context を 85% 削減する仕組みを導入しました |
| How We Reduced Token Usage by 100x: Dynamic Toolsets | Speakeasy の動的ツールセット方式は、input token を 96% 削減しました |
| MCPProxy — MCP Gateway | オープンソースの MCP 集約ゲートウェイ。BM25 インデックスでツールを動的に発見し、数百の server と数千の tool をサポートします |
| Welcome to the Agentic CLI Era | The New Stack が、AI coding tool が全面的に CLI へ移行する業界動向を報じました |
| OpenCLI — Universal CLI Hub | AI Agent 向けに設計された共通の CLI ハブ。ウェブサイトやデスクトップアプリを標準化された CLI に変換します |
| CLI-Anything — Making ALL Software Agent-Native | 香港大学の研究。すべてのソフトウェアを AI Agent が CLI から操作できるようにします |