Claude Codeはプロンプトを読むだけで33kトークンを消費？OpenCodeとの徹底比較で分かった衝撃の事実

ある直感から始まった検証です。普段は「OpenCode」を使っているのですが、Meridianの不具合により、しばらくの間「Claude Code」の使用を余儀なくされました。その際、OpenCodeを使っていた時よりも、明らかに利用料金メーターの上がり方が早いことに気づきました。

これが最初のきっかけですが、客観的なデータを得るために小規模な調査を行いました。

調査方法はシンプルです。AIコーディングツール（Claude CodeとOpenCode）とAnthropicのエンドポイントの間にロギングを挟み、すべてのリクエストと返却される使用量ブロックをキャプチャしました。

（最後に一点だけ補足事項がありますが）検証の結果、Claude Codeのキャッシュ戦略やハーネスのトークン使用効率は、OpenCodeと比較して非常に非効率であるという結論が明確に出ました。

これは大規模なシステムプロンプトだけの話じゃないよ。コーディングエージェントのハーネスも、些細なリクエストに対してツールを過剰に使うようになってきている。「Hey」や「commit」といったプロンプトで、時には30回以上のツール呼び出しが発生することさえあるんだ：https://quesma.com/blog/the-true-cost-of-saying-hi-to-an-ai-agent/ トークンのインフレはかなり深刻。単純なタスクで消費されるトークン数がどんどん増え続けているよ。

それに、piエージェントならもっと少ないよ。エージェントのシステムプロンプト全体はここで見られる：https://github.com/earendil-works/pi/blob/main/packages%2Fcoding-agent%2Fsrc%2Fcore%2Fsystem-prompt.ts

ローカルモデルの実験を始めた当初、Claude Codeと組み合わせたら「すごく」うまくいくんだけど、とにかく遅いっていうのが難点だった。mitmproxyを使って（Claudeに手伝ってもらって設定したんだけど）Claude Codeの初期システムプロンプトを全部キャプチャしてみたら、JSONだけで（さっき再確認したけど）162kbもあったよ。これがきっかけでPiやOpenCode、Hermesを試すようになったんだ。

仕事でClaude Codeを使うことを強制されてるけど、--system-prompt "" を使って何も指定しないようにするのが今のところ一番いい解決策だね。他のハーネスも選べるようにしてほしいよ。

Claude Codeがこれほど多くのトークンを消費するのは、単純にAnthropicがその方が儲かるからだし、ユーザーをサブスクリプションに縛り付けたいからだと思うよ。実際、サブスクリプションの権利を他のコーディングエージェントでは使えないようにしているのがその証拠だよね。ちなみに自分はpiを使ってる。

Claudeを半年使った後、最近Codexに乗り換えたよ。Codexの方がオープンな感じがするし、モデルが何をしているのか追いやすい。承認フローのUXも良くて、全体的に透明性が高い気がする。乗り換えコストもほぼゼロだったしね。2月頃からClaudeがシステムプロンプトを含めて不透明になってきたのが気に入らないんだ。33kっていうのは多すぎるよ。

トークンを一番食うのはサブエージェントだよ。以前、Claude Codeに結構重めのタスクを投げたら、いきなり7個もサブエージェントを立ち上げて、一つも完了しないうちに予算を使い切っちゃったんだ。5時間後に同じことを試しても結果は同じ。メインのエージェントだけで逐次実行させれば全く問題なかったのに。サブエージェントが非効率なのは通信やオーケストレーションのせいなのか、それともAnthropicが「企業アカウントならトークン課金でも痛くも痒くもないだろう」と考えて、トークン消費の多いユーザーから儲ける手段としてあえてそうしてるのか、どっちなんだろうね。

更新情報：PUSH_AXの鋭いコメントを受けて、「これは業者Aが33,000ドル、業者Bが7,000ドルで見積もりを出したようなもの。私たちが測定すべきは、本当にそこなのか？」という内容を考慮し、ブログ記事を以下のようにアップデートする予定：1) より詳細なタスク内容の追加。2) 定性的な結果比較。3) 入出力の再現手順の公開（できるだけ早急に）。

結局のところ重要なのはプロンプトのサイズそのものじゃない。そうでなければPi（やその派生）が最も低コストなエージェントということになるはずだからね。重要なのはプロンプトの効率性だ。プロンプトの最小化と効率性が混同されがちだけど、そうは言ってもCCは機能に対して肥大化しすぎているように見える。さらに重要なのはツールの品質。ツールがバグだらけだと何度もやり取りが発生して、貪欲法で得たはずの節約分がすべて吹き飛んでしまうんだ。数ヶ月前、7つのエージェントで8つのタスクのベンチマークを実行したよ（データやトレースは https://github.com/dirac-run/dirac にある）。自分の関わっているツールだから中立とは言えないけど、データは再現可能だし役に立つはず。特にリファクタリング系のタスクでは（ハッシュアンカーやAST解析が強みを発揮するため）Diracがかなり良い結果を出している。

デフォルトで大量のスキルが追加されるけど、プロジェクトによっては全く必要ないものも多いよ。