MCPをCLIで安く使い倒す！コスト削減のための賢い運用術

Model Context Protocol（MCP）をCLI（コマンドライン）経由で効率的に操作し、リソース消費や利用コストを最小限に抑える方法についてのトピックです。無駄なオーバーヘッドを削り、賢くMCPを運用するためのヒントがまとめられています。

人間が介在して承認するSotAモデルを動かしているコーディングエージェントならその通りだけど、何が実行されているか確認できない、安価なモデルで動くデプロイ済みのエージェントだと話は別だね。でもまあ、具体的な例としてはplaywright-mcp対playwright-cliが分かりやすいよ。

あはは、いい指摘だね。みんな同じことを考えてると思うよ。僕もmcpshim.devを公開したばかりなんだ。やっぱりUnixのやり方が一番だよね。

この記事には重要な文脈がいくつか欠けてるね。まず、MCPツールはすべてのリクエストで送信される。NotionのMCPを見ると、検索ツールの説明が実質的にミニチュートリアルみたいになっていて、これがそのままコンテキストウィンドウに入ってしまう。ほとんどの場合、MCPツールの読み込みは全か無か（他の方法で事前にツールを選択しない限り）だから、一般的にMCPはコンテキストをかなり圧迫する。最近VSCodeのGitHub Copilot拡張を見たらツールが20個くらいあったけど、これは多すぎる！次に、MCPツールは構成（コンポーズ）ができない。Notionの検索ツールを呼ぶと、あちら側が返すと決めたデータがドバっと送られてくるけど、それは膨大な量になる可能性がある。モデル側で処理するデータ量を決める手段がないんだ。通常、識別子やURLみたいなトークン効率の悪いデータポイントが大量に含まれたJSONダンプを受け取ることになる。一方でCLIベースのアプローチならスクリプトが書ける。コーディングアシスタントなら、最近の訓練傾向に合わせてjqやtailにツールをパイプして、データをチャンクごとに処理するのが一般的だね。エージェントでMCPを使いたいなら、MCPモデルとその重い付随機能を全部持ち込む必要がある。OAuthの処理やツールの読み込み、選択、リロードなどの管理が必要になるんだ。もっとシンプルな解決策は、システムレベルですべてを処理する単一のMCPサーバーを用意して、ツールを呼び出せる小さなCLIを持つこと。僕が別のコメントで投稿したmcpshimの場合、CLIは非常にシンプルなJSONを用いたUnixソケット経由でサーバーと通信する。実際、5行のbashコードでクライアントが作れるほどシンプルなんだ。最近のAIエージェントの多くはSKILLの使い方を知っているから、この方法は実質的に汎用的だね。だから目標はCLIツールを増やすことにある。でもサービスごとにCLIを書く代わりに、既存のMCPの上にピボット（転換）させればいい。これでコンテキストの問題がすごくエレガントに解決すると思う。

トークン使用量の安さだけでなく、精度の面でも有利だよ。最小クラスのモデルでさえ、シェルコマンドを完璧に使うための強化学習（RL）を受けている。僕のテストだと、Gemini 3 Flashは20個以上のツールを使うより、20個のコマンドがあるCLIの方がパフォーマンスが良かった。CLIはKVキャッシュの維持という点でも上手く機能する（モデルのパフォーマンスを上げるために途中でツールを変えるとKVキャッシュの恩恵が薄れるけど、CLIの--helpコマンドなら特定のコマンドのマニュアルだけを追記型で表示できるからね）。ツールをUnixライクなCLIとして書くと、モデルが複数のコマンドをパイプで繋げられるというメリットもある。ブラウザ操作については、専用のツールを使うよりも僕が書いたmini-browserをフロンティアモデルに使わせる方がずっと上手くいく。一撃でタスクをこなすための巨大なコマンドシーケンスを組み立てられるからね。

これ、Awesome CLIs/TUIsやTerminal Troveといった、CLIやTUIアプリが大量にまとめられているサイトに関連してそうだね。2026年にはCLIとUnixが再評価されるっていう、また別の予兆なんじゃないかな。

この記事って少し前のやつかな？「エージェントが動く前に全ツールカタログをJSON Schemaとしてダンプする」ってあるけど、Claude Codeみたいな最新のクライアントだと、もうそんなことはないよ。Skillsがすべてをコンテキストに放り込まずに検索できるように設計されたのと同じで、MCPツールも同じように動作できるし、実際にClaude Codeではそうなっている。Anthropicのドキュメントやエンジニアの投稿をチェックしてみるといいよ。

最近は何でも自分で安く書き直せちゃうよね。これはmcporterの書き直し版かな。個人的には書き直すならRustを使いたい。Opus 4.6なら、やりたいことを伝えればすぐに形にしてくれるし。正直、最近試したいソフトウェアのほとんどはインストールすらしないんだ。代わりにREADMEを読んで自分用のバージョンを作る。そうすれば、他の作者なら受け入れないような自分なりのこだわりや仕様を盛り込めるからね。

CloudflareのCode Mode MCPのブログ記事を読んで、すべてのMCPサーバーをsearchとexecuteという2つのMCPツールの背後に集約できるCMCPを作ってみたんだ。AnthropicのTool SearchがMCPの肥大化対策に役立つのは分かるけど、あれはClaudeに限定されちゃうからね。CMCPは今のところcodexとclaudeをサポートしているけど、他のクライアントを追加するPRも歓迎だよ。

CLIツールを使ったSkillと比較して、MCPに何か救いようのあるメリットってあるかな？現状だと後者が明らかに勝っているように見える。もしかしたらMCPの方が「自動承認」と「確認」を綺麗に分離できるのかもしれないけど、実際にそれが実装されているのは見たことがないな。

恒久的な解決策は、AIラボ側が推論コストを上げずにコンテキスト長を増やせるより良いアテンション手法を見つけることと、アカウントに恒久的にキャッシュされるシステムプロンプトを追加できるような大幅な割引（99%オフとか）を導入することだと思う。そうすれば、すべてのMCPをシステムプロンプトに組み込んでプロバイダー側に保存し、APIコストを払いすぎずに利用できるようになる。今の「オンデマンドのツール」という回避策はたまに使う分にはいいけど、将来的には同じコンテキストウィンドウ内で何十ものツールを柔軟に使い分けるエージェントが必要になるはず。だから、コンテキストウィンドウをより長く、かつ安価に使えるようにする必要があるよね。