クロードコードがプロンプトを読む前に33,000トークンを送信; オープンコードは7,000トークンを送信

2026年7月13日原文(systima.ai)

概要

Claude Code は OpenCode と比較して圧倒的に多くのトークンを消費し、キャッシュ効率も悪い
システムプロンプトやツールスキーマなどの ベースライン負荷 が非常に大きい
設定ファイルやサブエージェント の追加により、トークン消費がさらに加速
一部タスクではClaude Codeが有利 な場合もあるが、総じてコスト・レイテンシが高い
プロダクション運用 やEU AI Act対応では、どの程度トークンが消費されているかの把握が必須

Claude CodeとOpenCodeのトークン消費・キャッシュ効率比較

同一モデル・同一マシン・同一タスク でClaude CodeとOpenCodeを比較検証
Claude Codeは 1行返信タスク でも約33,000トークン（システムプロンプト、ツールスキーマ等）を消費
- OpenCodeは約7,000トークンで済む
キャッシュ効率 ：
- OpenCodeはリクエストプレフィックスが毎回同一で、キャッシュが有効
- Claude Codeは毎回数万トークンのプロンプトキャッシュを書き換え、最大54倍のキャッシュトークンを消費
キャッシュ書き込みは高額課金 対象で、Claude Code利用時は使用量ダッシュボードが急上昇

設定ファイル・MCPサーバ・サブエージェントの影響

72KBのAGENTS.mdやCLAUDE.md を投入すると、1リクエストごとに平均20,000トークン追加
- 5台のMCPサーバでさらに5,000～7,000トークン増加
- 実際の運用では 最初のリクエスト前に75,000～85,000トークン 消費
サブエージェント によるファンアウトでは、タスク直接実行時121,000トークン→2サブエージェント利用時は513,000トークンに急増
- 各サブエージェントが独自のブートストラップコストを持ち、親エージェントが全トランスクリプトを消費

タスクごとの詳細測定

単純な1行返信タスク ：
- Claude Code：約32,800トークン
- OpenCode：約6,900トークン
ツールなしでの純粋なハーネス ：
- Claude Code：約6,500トークン
- OpenCode：約2,000トークン
1ツールタスク（ファイル要約） ：
- Claude Code：6リクエスト、約199,000トークン
- OpenCode：4リクエスト、約41,000トークン
マルチステップタスク（write-run-test-fixループ） ：
- Claude Code：一括バッチで処理し約121,000トークン
- OpenCode：シリアル処理で約132,000トークン
- リクエスト回数×ベースライン が総消費量を決定

トークン消費の主な乗数要素

設定ファイル（AGENTS.md/CLAUDE.md） ：1ファイルで2万トークン追加
MCPサーバ ：1台あたり1,000～1,400トークン、5台で約5,000～7,000トークン追加
フレームワークテンプレート ：テンプレートサイズ×リクエスト回数分だけ加算
サブエージェント ：サブエージェント数×ブートストラップコスト分だけ大幅増
拡張思考（Extended thinking） ：出力課金が5倍、履歴に蓄積されるためさらに消費増

実運用での教訓と注意点

Claude Codeは極めて非効率なキャッシュ戦略 と大きなハーネストークン負荷を持つ
OpenCodeは軽量な設計 でキャッシュ効率も良好
設定ファイル名やMCPサーバの認識 など、実際の挙動を境界で必ず確認
トークン消費のボトルネック はサブエージェントや重い設定ファイルに集中
EU AI Actなどの規制下 では、送信データの実測・記録が不可欠

まとめ

Claude Codeのプロンプト・キャッシュ戦略はコスト増大要因
OpenCodeはシンプル・効率的な設計でコスト抑制に有利
運用時は設定・サブエージェント・キャッシュ挙動を必ず実測・検証
トークン消費の見積もり・管理はプロダクションAI運用の最重要ポイント

Hackerたちの意見

これは大きなシステムプロンプトに限った話じゃないよ。コーディングエージェントも、ちょっとしたリクエストでもツールを使うのがどんどん積極的になってる。テストしてみたら、「Hey」や「commit」みたいなプロンプトで、30回以上ツールを呼び出すこともあったよ。トークンインフレが本当に起きてるみたいで、簡単なタスクに使うトークンの数がどんどん増えてる。

└

Opusがコメントの誤字を直して、テストやリンティングを始めるとイライラすることがよくあるんだ。たいていは、現在の変更をスタッシュして、すべてのテストが通ってたか事前にチェックするために始めるんだよね。自分のルールが「すべての変更はテストで確認する」って言ってるから、ちょっと自分を責める部分もあるけど、AIの「I」があるってことは、果物サラダにトマトを入れないことくらいは知ってると思うんだけど…

└

「“Hey”や“commit”みたいなプロンプトが時々30回以上のツールコールを引き起こすことがある。これは、過去の会話や他のコンテキストを探して、何をしてほしいのかを理解するのに時間がかかるからだって。もっと明確なプロンプトの方がいい。」

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

└

もし本当にカスタマイズしまくりのミニマルエージェントが欲しいなら、piはスキップして（「ミニマル」なpi-coderパッケージには130以上の依存関係があるから）自分で書いた方がいいよ。いろいろ学べるし、そんなに難しくない。別のLLMに手伝ってもらって始めることもできるしね。

└

このミニマリズムに関連してるかもしれないけど、PiにはLLMが効率的に機能するために必要なツールがほとんど付いてないんだ。真っ白な状態が基本だってのは分かるけど、何でも追加できるとしても、ちょっと白すぎると思う。

└

読んでみたけど、毎回システムプロンプトの呼び出しで日付とコマンドを設定すると、キャッシュが無効になるのか気になるな。日が変わったり、ルートディレクトリが変わった場合にだけキャッシュが無効になるんじゃないかな。技術的には、そんなに頻繁には起こらないと思うけど。

└

ここでこのコメントを探してたんだ = )

ローカルモデルを試してた初期の頃、Claude Codeに接続するとすごくうまくいったんだけど、めっちゃ遅かったんだ。mitmproxyを使って（Claudeが手伝ってくれたけどね）Claude Codeの最初のシステムプロンプト全体をキャプチャしたら、JSONが162kもあった。これがきっかけで、PiやOpenCode、Hermesを試すようになったんだ。

└

これ面白いね。今、Claude Codeの新しいセッションを始めて、/contextを実行すると、以下のようになる: Opus 4.8 (1Mコンテキスト) claude-opus-4-8[1m] 23k/1mトークン (2%) カテゴリ別の推定使用量システムプロンプト: 3.9kトークン (0.4%) システムツール: 13.9kトークン (1.4%) カスタムエージェント: 235トークン (0.0%) メモリファイル: 28トークン (0.0%) スキル: 4.9kトークン (0.5%) メッセージ: 8トークン (0.0%) コンパクトバッファ: 3kトークン (0.3%) 空きスペース: 974k (97.4%) 4kトークンは15-20kBだよ。それをgistに貼ってほしいけど、敏感なデータが含まれてるかもしれないから、君が見ているのはシステムプロンプトだけじゃないと思う。

仕事でcloude codeを使わざるを得ないけど、いい解決策はただ --system-prompt "" を使って終わらせることだね。他のハーネスも使わせてくれたらいいのに。

└

こんなことができるなんて知らなかった。前後の影響についての分析はあるの？実際の使用における効果のチャートを見てみたいな。

Hacker Newsで議論の続きを見る

ハクソク