- 1 📌 5秒でわかる：この記事の内容
- 2 はじめに
- 3 MCPで実際に起きた問題（実体験）
- 4 なぜMCPは重いのか（技術的背景）
- 5 【2026年アップデート】Tool Search Tool による改善
- 6 実際にやりたいことって限定的だった
- 7 代替案: CLI + Skills という選択肢
- 8 実装例1: Playwright MCP → html-screenshot CLI
- 9 実装例2: RAGもどき – blog-scraper CLI
- 10 MCPが向いているケース vs CLIが向いているケース
- 11 付録: メンテナンスコストの話
- 12 まとめ
- 13 参考リンク
- 14 おわりに
📌 5秒でわかる：この記事の内容
やったこと：
- MCPを使って挫折した経験を共有
- 代替手段としてCLI + Skillsパターンを実践
- トークン消費を65%削減しつつ、同等の機能を実現
得られるもの：
- MCPが向いているケース/向いていないケースの判断基準
- CLI + Skillsの具体的な実装例（html-screenshot、blog-scraper）
- 段階的アプローチ「最初はCLI、複雑になったらMCP」
対象読者：
- Claude Codeを使って開発している人
- MCPを導入したけどイマイチだった人
- トークン消費を抑えたい人
📚 関連記事
- 図解作成が驚くほど楽に！Claude SkillでSVG自動生成
→ html-screenshot CLIの実装背景 - HTMLでブログ記事を保存してる奴、全員Markdownにしろ。AIが読みにくいでしょうが！
→ blog-scraper CLIの実装詳細
はじめに
ども！仕事量とAIのトークンリミットを見比べながら仕事をしている龍ちゃんです。
最近ちょっとトークン消費を抑えることを考えながら、実装を組み込んだり改善したりといろいろやっています。んで最近MCPを使うシーンでためらいが生まれてきたので、思いのたけを書いていこうと思います。
結論から言うと、「開発者目線でのMCPって、用途によっては不必要だったんや」 という話です。
MCPって高機能すぎるんですよね。ちょこっとほしい機能のために導入すると、オーバーヘッドがすごい。だったらAIにシンプルなCLIツールを開発させて、Skillで使い方を教え込んだほうが爆速で簡単じゃない？ って思うようになりました。
この記事で伝えたいこと：
- MCPは万能じゃない（用途による）
- シンプルな用途ならCLI + Skillsで十分
- 最初からMCPを導入するのはオーバーエンジニアリングかも
【2026年1月追記】 この記事で共有する失敗体験は2025年中頃のものです。その後、Tool Search Tool（トークン消費を最大85%削減）やMCP Apps（会話内でUIをレンダリング）などの改善がありました。詳細は後述の「【2026年アップデート】Tool Search Tool による改善」セクションで補足しています。それでも、シンプルな用途にはCLI + Skillsが適しているという本質的な結論は変わっていません。
MCPで実際に起きた問題（実体験）
Notion MCP での挫折
Notion MCPを試してみたんですが、正直しんどかったですね。
何が起きたか：
- 実行待機時間がやたら長い
- トークン消費量が多い
- トークンだけ消費して、結果何も得られないことがある
特に最後のやつがきつかったです。ファイルの特定をするのに、大元から検索して、特定→検索→特定→見つからない…みたいな。これって自分のNotionがAIフレンドリーな設計になっていない問題もあるかもしれないけど、とにかく重い。
やりたいことは新規ページ作成だけなのに、すんごく重い。
これなら自前でコピペしたほうが早いってなりましたね。
Playwright MCP での挫折
Playwright MCPも試しました。ブラウザ操作をAIにやらせたくて。
何が起きたか：
- 時間を食って結果何も得られないことがある
- タイムアウト問題が頻発
- サイズ調整がミスって意図していないものが取れる
ただスクショを取りたいだけなのに、待ち時間がストレスでした。すぐほしいのに、MCPの接続やらブラウザ起動やらで待たされる。
正直に言うと、MCPを経由するメリットが感じられなかったんですよね。
なぜMCPは重いのか（技術的背景）
僕の実体験だけだと「お前の環境が悪いんじゃ」って言われそうなので、技術的な背景も調べてみました。
ツール定義のトークン消費
MCPの一番の問題は、起動時にツール定義を全部ロードすることです。
コミュニティでも報告されている問題として（単一のMCPサーバーの場合）：
- MCPツールの定義だけで13,000〜18,000トークンを消費
- 一方、同等の機能をCLIで実現すると225トークン程度
- つまり約80倍のトークン差
“Just like a lot of meetings could have been emails, a lot of MCPs could have been CLI invocations”
（会議の多くがメールで済んだように、MCPの多くはCLI呼び出しで済んだ）
— MCP vs CLI: Benchmarking Tools for Coding Agents
これ、めっちゃ刺さる言葉ですよね。
接続の不安定性
Notion MCPやPlaywright MCPのGitHub Issuesを見ると、接続問題の報告がたくさんあります：
- 認証成功後の再接続失敗
- 間欠的な接続切断
- タイムアウト（Playwrightは5秒で切れる）
MCPサーバーが安定していないと、問題が起きたときに見る先が増えるんですよね。自分のコードなのか、MCPサーバーなのか、接続なのか…。これがどうにも困る。
【2026年アップデート】Tool Search Tool による改善
ここまでMCPの問題点を書いてきましたが、公平を期すために最新情報も共有しておきます。
2026年1月、Anthropicは「Tool Search Tool」という機能をリリースしました。これはMCPの「重い」問題を大幅に緩和するものです。
Tool Search Tool とは
従来のMCPは起動時にすべてのツール定義をロードしていました。Tool Search Tool は、これを遅延ロード（Lazy Loading） に変更します。
- 起動時: 軽量な検索インデックスだけをロード
- 実行時: 必要なツールだけをオンデマンドで取得
効果
Anthropicの公式ベンチマークによると（50以上のMCPツールを使う環境で）：
| 指標 | 従来のMCP | Tool Search Tool |
|---|---|---|
| 起動時トークン | 77,000〜134,000 | 8,700 |
| 削減率 | – | 最大85%削減 |
これにより、コンテキストの95%を保持できるようになったとのこと。
使い方
Claude Code の設定で有効化できます（2026年1月時点ではデフォルトで有効）。
じゃあMCPでいいじゃん？
…と思うかもしれませんが、僕がCLI + Skillsを推す理由は変わっていません。
理由：
- Tool Search Tool でも接続不安定性は解決しない – Notion MCP の認証問題、Playwright MCP のタイムアウトは別問題
- デバッグの複雑さは変わらない – 問題が起きたときに見る先が多いのは同じ
- シンプルな用途にはオーバースペック – 「HTMLをPNGに変換したいだけ」に MCP は依然として重い
結論: Tool Search Tool は素晴らしい改善ですが、シンプルな用途にはCLI + Skillsのほうが予測可能で扱いやすいという本質は変わりません。
実際にやりたいことって限定的だった
ここで気づいたんですよね。僕がMCPでやりたかったことって、実はめっちゃ限定的だったってことに。
- Notionでやりたかったこと → 新規ページ作成だけ
- Playwrightでやりたかったこと → HTMLをPNGに変換するだけ
がっつりナレッジを吸い出して管理するとか、複雑なブラウザ操作をするとか、そんな高機能な要件ってそんなにないんですよ。
複雑な要件 vs シンプルな要件：
| 要件 | 向いているアプローチ |
|---|---|
| マルチエージェント調整 | MCP |
| 複雑なステート管理 | MCP |
| セキュアなアクセス層が必要 | MCP |
| データの取得だけ | CLI |
| データの追加だけ | CLI |
| 単純な変換処理 | CLI |
シンプルな用途にMCPを使うのは、釘を打つのにブルドーザーを持ってくるみたいなものだったんですよね。
代替案: CLI + Skills という選択肢
アプローチ
僕が採用したアプローチはこれです：
- ローカルでAIにCLIツールを開発させる
- Skill / Slash Commandで使い方を教え込む
これだけ。めっちゃシンプル。
なぜこれが爆速で簡単か
理由1: トークン消費の違い（80倍差）
MCPはツール定義だけで13,000トークン以上消費するけど、CLIなら数百トークンで済みます。
理由2: 起動時ロードなし（SkillsのProgressive Disclosure）
Skillsは必要なときだけ読み込まれるんですよね。MCPみたいに起動時に全部ロードしない。
“GitHub’s official MCP on its own famously consumes tens of thousands of tokens of context”
（GitHubの公式MCPだけで、数万トークンのコンテキストを消費することで有名だ）
— Simon Willison
理由3: 柔軟性と制御性
自分で作ったCLIなので、問題が起きても原因特定が早い。MCPサーバーのバグなのか接続問題なのか悩まなくていい。
実装例1: Playwright MCP → html-screenshot CLI
このリポジトリでの実例
Playwright MCPを使わず、ローカルCLIツール html-screenshot で代替しました。
Playwright MCP だと…
❌ 起動時にツール定義をロード（トークン消費）
❌ ブラウザ操作の各ステップでやり取り
❌ タイムアウト・サイズ調整の問題
CLI + Skill だと…
uv run html-screenshot --file input.html --output output.png --width 1280 --height 720
これだけ。1コマンドで完結。
Skills定義
.claude/skills/html-to-png/SKILL.md:
---
name: html-to-png
description: HTMLをPNGに変換して
allowed-tools: Read, Bash
---
# HTML to PNG Converter
## CLI: html-screenshot
### 基本コマンド
uv run html-screenshot --file input.html --output output.png
### オプション
| オプション | 説明 | デフォルト |
|-----------|------|----------|
| --width | 幅 (px) | 1280 |
| --height | 高さ (px) | 720 |
| --force | 上書き | False |
ポイント: MCPの「ブラウザ操作」という複雑な機能は不要。「HTMLをPNGに変換する」というシンプルな用途なら、CLIツール1本で十分なんですよね。
詳細は 図解作成が驚くほど楽に！Claude SkillでSVG自動生成 を参照してください。
実装例2: RAGもどき – blog-scraper CLI
やりたいこと
既存ブログ記事をAIに読み込ませたい（RAGもどき）。
MCPアプローチだと…
❌ Web取得MCPでHTML取得
❌ トークン大量消費（生HTML: 35,420トークン）
❌ 毎回ネットワーク通信
CLI + Skillsアプローチ:
# 1回スクレイピングしてローカル保存
uv run blog-scraper https://tech-lab.sios.jp/archives/50103
# 結果: docs/data/blog/tech-lab-sios-jp-archives-50103.md
トークン削減効果
| 段階 | トークン数 | 削減率 |
|---|---|---|
| 生HTML（ページ全体） | 35,420 | – |
| ↓ ContentCompressor | 15,680 | 55.7% |
| ↓ Markdown変換 | 12,440 | 20.7% |
| 累積削減 | – | 64.9% |
ポイント:
- MCPで毎回Web取得するより、1回CLIでスクレイピング → ローカル保存が効率的
- トークン65%削減 + オフライン参照可能
- 「ベクトルストア不要、人間が関連記事を選択」という割り切り
詳細は HTMLでブログ記事を保存してる奴、全員Markdownにしろ。AIが読みにくいでしょうが！ を参照してください。
MCPが向いているケース vs CLIが向いているケース
ここまで読むと「MCPダメじゃん」って思うかもしれないけど、MCPが向いているケースもあるんですよね。
| 観点 | MCP向き | CLI + Skills向き |
|---|---|---|
| 要件の複雑さ | 複雑なロングタスク | シンプルな操作 |
| 操作内容 | マルチエージェント調整 | データ取得/追加 |
| ステート | 複雑なステート管理 | ステートレス |
| セキュリティ | セキュアアクセス層必要 | ローカル完結 |
| メンテナンス | 外部がメンテしてくれる | 自分でメンテ |
MCPが向いているケース：
- ✅ 複雑なワークフローをAIに自律的に実行させたい
- ✅ 複数のAIエージェントを連携させたい
- ✅ セキュアなアクセス層が必要（エンタープライズ向け）
- ✅ 【NEW】MCP Apps を使いたい（後述）
【2026年1月】MCP Apps と Interactive tools の登場
2026年1月、MCPに「MCP Apps」という新機能が追加されました。これは会話の中でUIをレンダリングできる機能です。
さらに同時期、Claudeに「Interactive tools」機能がリリースされ、以下のアプリが会話内で直接操作可能になりました：
- Amplitude: 分析チャートをインタラクティブに操作
- Figma: テキストからフローチャートやガントチャートを生成
- Asana: チャットからプロジェクト・タスクを直接作成
- Slack: メッセージ検索、ドラフト作成、書式設定プレビュー
- その他: Box、Canva、Clay、Hex、monday.com（Salesforceも近日対応予定）
これはMCPの強みです。CLI + Skillsでは実現できない領域ですね。
ただし、この機能はClaude Code（開発者向け）というより、Claude Web/デスクトップ（ビジネスユーザー向け） の色が強い印象です。Asanaでタスク管理、Slackでメッセージ作成…といった、非エンジニアのワークフロー向けですね。
「HTMLをPNGに変換したい」「CLIツールを使いたい」 という開発者のシンプルな用途には、依然としてCLI + Skillsのほうが軽量で扱いやすいです。
CLIが向いているケース：
- ✅ やりたいことがシンプル（取得/追加/変換）
- ✅ トークン消費を抑えたい
- ✅ 動作の予測可能性がほしい
付録: メンテナンスコストの話
MCPの利点: 外部がメンテしてくれる
公平に言うと、MCPにはメンテナンスを外部に任せられるという利点があります。
- 基盤となるAPI/サービスが変わったら、MCPサーバーの開発者がメンテしてくれる
- 自分でAPIの変更を追いかけなくていい
- コミュニティの恩恵を受けられる
でもCLIツールを選ぶ理由
それでもCLIを選ぶ理由は、利用可否の安定性です。
- MCPサーバーの接続問題・認証問題に振り回されない
- ローカルで完結するので「動かない」がない
- 問題が起きても自分のコードなので原因特定が早い
段階的アプローチの提案
僕が提案したいのは、段階的アプローチです。
フェーズ1: まずCLIツールで始める
↓ 要件がシンプルなうちはこれで十分
フェーズ2: 要件が複雑になってきたら...
- ステート管理が必要になった
- マルチエージェント連携が必要になった
- セキュアなアクセス層が必要になった
↓
フェーズ3: いい加減MCPの導入を検討しよう！
ポイント：
- 最初からMCPを導入するのはオーバーエンジニアリング
- 要件が育ってからMCPに移行しても遅くない
- CLIで作った知見はMCP移行時にも活きる
まとめ
この記事では、MCPに挫折した経験と、代替手段としてのCLI + Skillsについて共有しました。
本記事のポイント
✅ MCPは万能じゃない
用途によってはオーバーヘッドが大きすぎる（Tool Search Toolで改善されたが、接続問題やデバッグの複雑さは残る）
✅ シンプルな用途ならCLI + Skillsで十分
予測可能性、接続問題なし、デバッグしやすい
✅ MCPは進化している
Tool Search Tool（トークン85%削減）、MCP Apps（会話内UI）など改善が続いている
✅ 段階的アプローチがおすすめ
最初はCLI、複雑になったらMCP（Tool Search Tool有効）、さらに高度ならMCP Apps
Before/After 比較
| 指標 | MCP（従来） | MCP（Tool Search） | CLI + Skills |
|---|---|---|---|
| トークン消費 | 13,000〜18,000 | 8,700程度 | 225〜数百 |
| 接続安定性 | 不安定な場合あり | 不安定な場合あり | ローカル完結 |
| デバッグ | 複雑 | 複雑 | シンプル |
| 向いている用途 | 複雑なワークフロー | 複雑なワークフロー | シンプルな操作 |
次のステップ
- 自分のMCP利用状況を見直してみる
- シンプルな用途はCLI化を検討
- 複雑になったらMCPに移行
参考リンク
公式ドキュメント
関連記事
- 図解作成が驚くほど楽に！Claude SkillでSVG自動生成
- HTMLでブログ記事を保存してる奴、全員Markdownにしろ。AIが読みにくいでしょうが！
- Claude Code Skillの登録と実践！プロジェクト固有の処理を自動化する方法
おわりに
ここまで読んでいただき、ありがとうございました！
MCPって「AIの未来！」みたいに言われてるけど、現時点では用途を選ぶんですよね。複雑な要件には向いてるけど、シンプルな用途には重すぎる。
僕の場合自分の環境をサクッと便利にしたいというところから派生して、「ちょこっとデータを取得したい」「ちょこっと変換したい」 くらいの要件がほとんどだったので、CLI + Skillsで十分でした。むしろそのほうが快適。
もちろん、要件が複雑になってきたらMCPを検討します。でも最初からMCPを導入するのはオーバーエンジニアリングだったなって、今は思っています。
質問や感想は、コメント欄でお待ちしております。また、Twitterのほうもよろしくお願いします！
