Claude Code Proを日常的に使っている方なら、心当たりがあるのではないでしょうか。
週の半ばで突然「今週の上限に達しました」と告げられる、あの脱力する瞬間です。
海外のClaude関連コミュニティで、この問題への一つの解として注目を集めた投稿があります。
タイトルを意訳するなら「Claude Codeに1コール2セントの相棒をつけたら、Pro上限に当たらなくなった」。
本記事では、この投稿と800を超えるコメントの議論を整理します。
そして、その発想と実践のポイントをご紹介します。
発端：毎週水曜には上限に到達していた
投稿者は、典型的な悩みを抱えていました。
Claude Code Proに加入しています。
それなのに、毎週水曜日にはその週の上限を使い切ってしまうのです。
会話の圧縮、簡単な作業はSonnetに切り替える、プロンプトを短く絞る。
一通り試したそうです。
しかし、根本的な解決には至りませんでした。
そこで彼が思いついたのが、「Claudeに格安の同僚をつける」という発想でした。
要点はこうです。
Claudeの知能を本当に必要とする作業と、そうでない作業を切り分ける。
たとえば、大量のファイルを読んで状況を把握する作業や、決まり切ったボイラープレートを生成する作業。
これらは必ずしもClaudeの高度な推論を要しません。
そこで、こうした「単純労働」を外部の安価なモデルに振るCLIスクリプトを用意しました。
Claudeはbashツール経由でそれを呼び出すだけ。
判断と指示はClaudeが行い、手を動かすのは別のモデル。
そんな分業の構図です。
CLAUDE.mdに書くルーティングルールが核心
この仕組みを成り立たせているのが、CLAUDE.mdに記述されたルーティングルールです。
どのような場面で外部モデルへ委譲し、どのような場面でClaude本体に処理させるか。
これを文章で明示しておきます。
ルールがなければ、Claudeはすべてを自分で抱えてトークンを浪費するか、何でもかんでも外に投げて品質を落とすか、どちらかに振れてしまいます。
3週間ほど運用した結果として、投稿者は次のような数字を共有していました。
- 週次上限に一度も到達せず
- 外部モデル側の合計支出は0.38ドル
- あるドキュメント更新作業のトークン消費が約5000から約200まで減少
月20ドルのプランに、追加で支払うのが0.38ドル。
これで週末まで持ちこたえられるなら、コストパフォーマンスとしては悪くありません。
なぜHaikuに任せるのでは駄目なのか
コメント欄では、当然の疑問がすぐに投げかけられました。
「同じことをHaikuにやらせれば済むのでは？」と。
ところが、ここには見逃しやすい落とし穴があります。
HaikuもAnthropicのモデルです。
そのため、Claude Code内でHaikuを呼び出してもAnthropic側の使用枠を消費してしまうのです。
本来の目的は「Anthropicに請求されるトークンを減らす」こと。
それを実現するなら、まったく別のプロバイダに送るほうが筋が通ります。
加えて、Haikuの挙動には少しクセがある、という声も複数見られました。
印象的だったのは、Haikuにチャットセッションのタイトル付けを任せたユーザーの体験談です。
気づくとブランチに見覚えのないコミットが追加されていました。
原因を追ったところ、Haikuはタイトル付けという本来の役割を忘れていたのです。
そして、セッション内で議論されていた問題を勝手に「解決」しはじめていた、というわけです。
タイトラーが自我に目覚めた、とコミュニティでは半ば伝説のように語られていました。
軽量モデルが軽量タスクに常に向くとは限らない。
設計時に覚えておきたい視点です。
「安い同僚」候補：どのモデルが向くか
委譲先のモデル選びをめぐっては、コメント欄が一番盛り上がっていました。
投稿者が採用したのはKimi K2.5です。
しかし、コミュニティで多くの支持を集めていたのはDeepSeek v4 Flashでした。
Kimiは単純な作業でも考え込みすぎる傾向があるそうです。
その結果、無駄なトークンを使ってしまう、という声が目立ちました。
一方のDeepSeekは余計な思考を挟みません。
与えられた仕事を素直にこなしてくれるという評価です。
別のアプローチもあります。
手元のミニPCでOllamaを動かす方法です。
ファイルスキャンやリント、テスト実行といった処理をローカルモデルに任せます。
Claude Codeはアーキテクチャ判断や複雑な実装に専念させる、という分業になります。
セキュリティの観点で気になる人もいるでしょう。
中国系モデルへの懸念については、OpenRouter経由でアクセスする方法が紹介されていました。
OpenRouter上のDeepSeek v4 Proは、シンガポールやアメリカのプロバイダがホスティングしているケースもあります。
そのため、必ずしも中国国内で推論が走るわけではない、という指摘です。
完全な保証ではありません。
それでも、判断材料の一つにはなります。
CLIスクリプトかMCPか、実装方式の選択
実装の方式についても興味深いやり取りがありました。
投稿者の構成はPythonスクリプト群とbashツールというシンプルなものです。
一方、MCP（Model Context Protocol）を使うべきという意見も挙がっています。
MCPを採用する利点として、いくつかが挙げられていました。
- 型付きのツール契約
- 長時間稼働するプロセス
- 安全ガードの一元化
- 構造化されたJSONレスポンス
プレフィックスキャッシュの恩恵まで考慮すると、コスト面でもさらに有利だ、という主張です。
ただし、CLIスクリプトには独自の良さがあります。
「とにかく単純で誰でも書ける」点です。
たとえば「research-this.py」のような小さなスクリプトを用意します。
そして、Claudeには「コードを調べたいときはこれを使って」と一言添えるだけ。
スクリプト自体もClaudeに書かせれば、立ち上げのハードルは驚くほど低いわけです。
どちらが正解かは状況によります。
チームで標準化したいならMCP、個人で素早く始めたいならCLIスクリプト。
そんな住み分けが現実的でしょう。
コストの先にある「一貫性」の問題
このスレッドで個人的に最も興味を引かれたのが、コスト削減の先を見据えたコメントでした。
複数のモデルが同じコードベースを触りはじめます。
すると、コストよりもむしろ「一貫性」が難しい課題になる、という指摘です。
あるモデルが採用した設計方針を、別のモデルが理解しないまま書き換えてしまう。
セッションをまたぐうちに、暗黙のルールが少しずつ崩れていく。
スケール時に表面化するのは、こうしたドリフトの問題だ、というわけです。
これへの対処として、興味深い運用も紹介されていました。
XML構造で厳密に指示を与える方法です。
そして、ルールと停止条件を毎回「契約」として渡します。
広めの依頼をすると、モデルは勝手に解釈して走り出してしまう。
だからこそ、契約を明示しておくことが重要だ、という考え方です。
コスト削減は出発点です。
その先には、ガバナンスという壁が控えています。
複数エージェント時代の現場感を捉えた良い視点だと感じました。
自分で試すときの実践ヒント
この発想を自分の環境で試したい人のために、議論を踏まえたポイントをいくつか挙げておきます。
まず、CLAUDE.mdの設計に時間を惜しまないこと。
コミュニティ内でも次のように語られていました。
「ルーティングロジックこそ本質で、ここが甘いとトークンを浪費するか品質を落とすかのどちらかになる」。
具体的な切り分けの粒度はこんなイメージです。
「200ファイルのリポジトリを読む」ような作業は外部モデルへ。
「このテストが落ちる原因を推論する」ような作業はClaude本体へ。
この水準で言語化しておきたいところです。
次に、外部モデルの出力をClaudeに戻すときの「形」を意識してください。
生のテキストを丸ごと渡すのではありません。要点をまとめた要約や構造化されたデータとして返すのです。
これだけでClaude側のコンテキスト消費はかなり抑えられます。
最後に、検証の習慣を持ってください。
安価なモデルは間違えることもあります。
重要な処理を任せる前に、小さな範囲で動かして出力品質を確かめておく。
この一手間が後のトラブルを防いでくれるはずです。
まとめ
Claude Codeの週次上限に頭を抱える人にとって、「外部の安価なモデルに下請けをさせる」という発想は、極めて実用的な選択肢の一つです。
月20ドルのプランを最後まで使い切るために、追加で支払うのが0.38ドル程度。
コスト感覚としても十分受け入れやすい水準でしょう。
このパターンの本質は「節約」ではありません。
「適材適所」にあります。
高い知能が要る場面ではClaudeを使い、そうでない場面は別の手段に任せる。
この切り分けを言語化したCLAUDE.mdこそが、戦略の中核を成しているわけです。
複数のAIエージェントが連携する時代に、誰がどの役割を担うのか。
それをあらかじめ設計しておく姿勢が、これからは不可欠になりそうです。
今回ご紹介したコミュニティの議論は、その一歩目を考える素材として読み応えのある内容でした。
