こんな場面を想像してほしい。AIプログラミングアシスタントを開き、確認のために「OK」の二文字を入力する。その二文字を——AIがその二文字を実際に「見る」前に——バックグラウンドで約33,000トークンもの計算枠を黙って消費していたとする。同じような機能を持つ別のツールなら、同じ状況で約7,000トークンしか使わなかった。
これは比喩でも、概算でもない。Systima のチームが Anthropic の API インタフェースにログのプロキシ層を挟み、毎回のリクエストの生データを逐一記録して得た実測の結論だ。彼らはブログで実験手法と生の数値を公開しており、その記事は Hacker News で400を超える推薦と200以上のコメントを集めた。
本稿では、専門外の読者にも分かる言葉で、この数字の背景にある三つの話を取り上げたい。AIプログラミングツールは「あなたの言葉を見る前」にいったい何をしているのか。なぜサブエージェントが本当のトークンの穴（ブラックホール）なのか。そして、従量課金というビジネスモデルがそこでどのような役割を果たしているのか。
トークンとは何か。なぜ「ガソリン」のようにあっという間に燃えるのか
具体的な数字に入る前に、一つの重要な概念を説明しておく。token（トークン）は、AIがテキストを処理するときの最小の計量単位と捉えればよい。これは「一文字」ではなく、英語なら約0.75単語、中国語なら1〜2文字に相当する。従量課金のAIサービスを使うとき、トークンを一つ処理するごとに課金が発生する。
AIプログラミングツールは、普通のAIチャットとは異なる。ウェブ版の Claude とチャットする場合、届くのは基本的にあなたの質問そのものだ。しかしAIプログラミングツールは、質問の他に大量の「準備作業」を余分に差し込む必要がある——AIに「自分が何者で、どのツールを呼べるか」「あなたのプロジェクトにはどんなルールがあるか」「現在の作業ディレクトリはどこか」「OSの環境情報は何か」などを伝えるためだ。
この余分な内容は「ハーネス・オーバーヘッド（harness overhead）」と呼ばれる。問題は、このハーネスの大きさに巨大な差があることだ。
33,000対7,000：「OK」と答える一回の請求書の比較
Systima の実験設計は非常にシンプルだ。二つのAIプログラミングツール——Anthropic 公式の Claude Code と、オープンソースの OpenCode——に、同じ最も単純なタスク「OK」と返答させる。
Claude Code は「OK」の二文字を読む前に、APIに約33,000トークンを送信していた。その内訳はこうだ。システムプロンプト（「あなたは何者で、どうすべきか」をAIに伝える）が約6,500トークン、27個のツール定義（ファイル読み書き、コマンド実行、サブエージェント管理、スケジュールタスク……）が約24,000トークン、そして注入されるリマインダーブロック（タスク状態、利用可能なスキル一覧、現在の環境情報）が約2,000トークン。
一方 OpenCode は約7,000トークンしか使わなかった。システムプロンプトが約2,000トークン、10個のツール定義が約4,800トークン。余分なリマインダーブロックはなく、構造は極めて簡素だ。
ここで見落としやすい細かい点がある。この33,000トークンは「一度払えば終わり」ではない。AIプログラミングツールの動作モデルでは、対話の各ラウンド——モデルとの往復ごと——にこれらのハーネス内容を再送しなければならない。つまり、タスクでAIと10往復やり取りするなら、ハーネスだけで330,000トークンを消費し、実際のコードや対話はそこには含まれない。
キャッシュは本来お金を節約するはずだが、Claude Code はそれを台無しにした
AIサービス事業者は通常「プロンプトキャッシュ」と呼ばれる仕組みを提供している。連続するリクエストで大部分の内容が変化していなければ、再計算するのではなく、極めて安い価格でキャッシュから読み出せる。これはコストを抑えるための重要な手段だ。
しかし Systima は決定的な違いを発見した。OpenCode のリクエストのプレフィックスは毎回バイト単位で完全に同じだ。つまりキャッシュへの書き込みは一度で済み、以降の読み出しはすべて10分の1の価格で課金される。それに対し Claude Code は、同じタスクの連続するリクエストの中で数万トークンものキャッシュを繰り返し書き直しており、同じタスクでのキャッシュ書き込み回数は OpenCode の54倍だった。
キャッシュの書き込みは読み出しよりずっと高価だ。言い換えれば、ユーザーが請求書の数字が膨らむのを見る最大の理由は、ツールがキャッシュを効率よく使えていないことにある。
本番環境の本当の請求書：33Kから85Kへ
上の33,000はまだ「何も身につけていない」状態——プロジェクト設定も、プラグインも、追加ツールもない。では本当の本番環境はどうなっているのか。
Systima は「積み上げ実験」を行った。まず空のプロジェクトでテストし、次第に実際の開発シナリオの設定を加えていった。
第一歩として、72KBのプロジェクト指示ファイル（AGENTS.md や CLAUDE.md。コード規約をAIに伝えるもの）を置いた。これだけで各リクエストに約20,000トークンが追加された。
第二歩として、5つの軽量な MCP サーバー（メールの読み書き、タスク管理、データベース検索などをAIに可能にする）を接続した。これでさらに約5,000〜7,000トークンが加わった。
累計すると、実際の開発環境では、Claude Code はユーザーの質問を読む前にすでに75,000〜85,000トークンを消費している。OpenCode も同様の積み上げで膨らむが、出発点が低いため絶対値はなお管理可能な範囲だ。
サブエージェント：本当のトークンの穴
ハーネスの消費が「燃費が悪い」だとすれば、サブエージェントは「タンクに穴が空いている」ようなものだ。
サブエージェントは Claude Code の重要な機能の一つだ。タスクが複雑なとき、メインエージェントは複数の「分身」を並行して動かし、各サブエージェントが独立してコードを読み、問題を分析し、結果を返す。一見効率的だが、その代償は驚くべきものだ。
Systima は同じタスクで比較した。直接実行では121,000トークンを消費した。それを二つのサブエージェントで並行実行に変えると、消費は513,000トークンに暴騰——元の4.2倍だ。
なぜこれほど差が出るのか。各サブエージェントは独立した作業単位だからだ。それぞれに（メインよりは簡素だが）独自のシステムプロンプトがあり、独自のツールセットがあり、コンテキストを理解するためにプロジェクトファイルを再読み込みする必要がある。サブエージェントがタスクを終えると、その対話記録全体がメインエージェントに「飲み込まれて」参照される。これは、二人に資料調べを頼んだら、二人とも答えを持ち帰るだけでなく、めくったすべての原本を詰めた一箱分を持ち帰ってくるようなものだ。
HN にいたユーザーの経験はさらに極端だ。「Claude Code にそこそこ大きなタスクを与えたら、即座に7つのサブエージェントを立ち上げた。予算が尽きるまで、どのサブエージェントもタスクを完了しなかった。5時間後に再試行しても同じ結果だった」と彼は書いている。同じタスクをメインエージェントで順次実行すれば、まったく問題なかったという。
Anthropic のビジネスモデルのジレンマ
ここまで読むと、自然な疑問が浮かぶ。これは設計上の欠陥か、それともビジネスモデルの必然か。
Anthropic の API はトークン単位で課金される。Claude Code は公式ツールとして、そのトークン消費が大きければ大きいほど Anthropic の収入は増える。しかしそれが必ずしも「意図的な設計」とは限らない——むしろ構造的なインセンティブと言うべきだ。収入がユーザーのトークン消費量に依存しているとき、オープンソースコミュニティのようにハーネスを削る強い動機は働かない。
OpenCode が7,000トークンという「床」を実現できたのは、大きくはそれがオープンソースプロジェクトだから——その設計目標に API 収入の最大化は含まれていない。一方 Claude Code の27個のツール、多重のリマインダーブロック、サブエージェントの完全な誘導メカニズムは、どの設計判断にも「機能がより豊富」という正当な理由がある。しかしこれらの「より豊富な機能」が積み重なると、ユーザーの請求書は副産物としてのしかかる。
とはいえ Claude Code が勝つときもある
公平を期すと、Systima のテストでも Claude Code に有利なシナリオが一つ見つかっている。
複数ステップの操作を要するタスク（コードを書き、テストを実行し、エラーに応じて修正し、再テストする）では、Claude Code の総消費はかえって OpenCode より低かった。理由は、Claude Code が複数のツール呼び出しを一回のリクエストにまとめて処理するのに対し、OpenCode は一つのツール呼び出しにつき一ラウンドのリクエストを走らせるからだ。Claude Code は各ラウンドの土台が重いが、OpenCode はまとめる能力がないために土台のオーバーヘッドを9回も重複して払い、結果的に総勘定は多くなった。
この発見は微妙な事実を浮き彫りにしている。ツールのトークン効率は、土台がどれだけ軽いかだけでなく、ワークフローをどう編成するかにもかかっている。土台は重いがまとめられるか、土台は軽いが繰り返し走らせるか、どちらが優れているかは具体的なタスク次第だ。
これが普通のユーザーに意味すること
コードを書かない人なら、これは「プログラマーの問題」だと思うかもしれない。実際には、AIツールが「チャット」から「仕事」へと移行するにつれ、この従量課金モデルはすべての利用者に影響する。
Cursor で一行のコードを直すときも、Claude Code でAIにバグ修正を頼むときも、その裏では同じような物語が起きている。大量のシステム指示が繰り返し送信され、サブエージェントがバックグラウンドで旋風のように生まれ消え、キャッシュが繰り返し書き直される——そして請求書は、これらの見えない動作の中でこっそり積み上がっていく。
Systima の実験は、これまでブラックボックスの中に隠されていた数字を陽の下に引きずり出した。利用者として、これらの数字の存在を知ること自体が、情報という意味でのエンパワーメントなのだ。
あるいは、もっと率直に言えばこうだ。次に API の請求書を見たとき、その数字のうち本当に自分が使ったのはほんの一部に過ぎない、ということをあなたは知っているはずだ。
参考リンク：
- Systima: Claude Code vs OpenCode Token Overhead
- HN ディスカッション (item?id=48883275)