開発者が期待を胸にターミナルを開いた瞬間、まだ一行も指示を入力していないにもかかわらず、AIプログラミングアシスタントがバックグラウンドで数万トークンの枠を「貪り食っている」——。この驚くべき実態が、AIコンサルティング企業Systimaの最新の実測データによって明らかになった。
Systimaのテスト結果によると、Anthropicの旗艦プログラミングツール「Claude Code」は、ユーザーからの有効な指示を受け取る前の段階で、システムプロンプトとツール説明だけで大規模言語モデルに約3万2800トークンを送信している。これに対し、オープンソースの競合ツール「OpenCode」の初期消費量はわずか6900トークンであり、Claude Codeの「空転コスト」は競合の4.7倍に達した。さらに、一般的なMCP（Model Context Protocol）サーバーや設定ファイル、プラグインをマウントした場合、この数値は7万5000トークンにまで跳ね上がるという。
このデータは、AIプログラミング分野で長らく見過ごされてきた隠れたコストを浮き彫りにしている。すなわち、ツールが強力になればなるほど、その背後にある「ブラックボックス的な処理」も重くなる可能性があるということだ。
見えないトークンの燃焼：3.3万から7.5万へ
AIプログラミングツールの隠れたオーバーヘッドを定量化するため、Systimaは厳密な対照実験を設計した。同一のコンピューターを用い、同一の基盤モデル「Claude Sonnet 4.5」を呼び出し、中継サーバーを構築して、Claude Code 2.1.207とOpenCode 1.17.18が対話前にモデルへ送信したデータパケットを傍受・集計した。
クリーンな環境下で、「OKとのみ返信せよ」という極めて簡素な命令を入力した場合、Claude Codeが送信した最初のリクエストデータ量は3万2800トークンに達した。Systimaの分析によると、システムプロンプトを除いても、Claude Codeには27種類ものツール説明が組み込まれており、この部分だけで約2万4000トークンを占めている。一方、OpenCodeに組み込まれているツールは10種類のみで、初回リクエストの総量は6900トークンに抑えられた。双方のツールをすべて無効化した場合でも、Claude Codeのシステムプロンプトは6500トークンに上り、OpenCodeの3倍以上に相当する。
この3.3万トークンという初期負荷は、単に利用料金の増加を意味するだけでなく、モデルの「思考空間」を直接的に圧迫する。Systimaは、20万トークンのコンテキストウィンドウを使用する場合、Claude Codeはコードや会話を読み込む前の段階で、すでに容量の16%を消費していると指摘する。会話が進むにつれて、システムは要約圧縮を実行せざるを得なくなり、トークン消費をさらに押し上げる構造だ。
実際の開発現場では、状況はさらに深刻になる。Systimaは、72KBのプロジェクトルールファイル（CLAUDE.md）を読み込み、MCPサーバーに接続した環境をシミュレートした。データによると、ルールファイルだけでもリクエストごとに約2万トークンが追加で積み上がる。MCPサーバーについては、小規模なインスタンスを1つ接続するごとに初期負荷が1000～1400トークン増加し、5つ接続すればさらに5000～7000トークンが追加で消費される。
SystimaがClaude Codeを指示ファイル、MCP、プラグインを含む「実用的な形態」に設定したところ、ユーザーが発話する前にモデルへ送信されたデータ量は驚異の7万5000トークンに達し、ツール数は118種類に膨れ上がり、送信データの総サイズは311KBに及んだ。Systimaの推定では、設定によって初期リクエストの負荷は概ね7万5000～8万5000トークンの間で変動するという。
常に「無駄」とは限らない：高負荷下の効率パラドックス
初期負荷が膨大であるにもかかわらず、Systimaのテストは直感に反する結論を導き出した。すなわち、最初に「コストを浪費する」ツールが、必ずしも全体の総消費量で最も高くなるとは限らないのだ。
ファイル作成とプログラム実行の連鎖テストにおいて、Claude Codeは強力な並列ツール呼び出し能力を活かし、わずか3回のリクエストでタスクを完了し、入力トークンの合計は12万1000だった。一方、OpenCodeはシングルスレッドでツールを逐次呼び出す傾向があるため、処理に9回のリクエストを要し、総入力トークンは逆に13万2000に達し、Claude Codeを上回った。Systimaの分析では、軽量ツールは単体の消費量こそ少ないものの、頻繁なやり取りによってコンテキストの再送信が繰り返されるため、長期的に見ればその差は縮まるという。
ただし、Claude Codeの「サブエージェント」機能は、名実ともにトークンのブラックホールだ。テストでは、タスクを2つのサブエージェントに分割して並列処理させたところ、各サブエージェントが独立したプロンプトとツール説明を読み込む必要があり、さらに親エージェントが結果を再度読み取る必要があるため、入力トークンの総量は直接処理した場合の12万1000から51万3000へと急増した。
「バカになった」のか「サボっている」のか？Effort機構の再考
Claude Codeの高いトークン消費の背景には、Anthropicが最近公式に明確化した「Effort（努力度）」機構も深く関係している。以前、ネット上ではClaude Codeが「バカになった」という声が集団的に噴出した。米AMDのAI責任者であるStella Laurenzo氏は、6852件のセッションログを分析し、Claudeの思考量が一時的に67%も急減したと指摘したほどだ。
中国メディア「新智元」が報じたAnthropicの公式ブログによると、問題の根本原因はモデルの知能低下ではなく、Anthropicが3月4日にレイテンシー（応答遅延）を減らすため、Claude CodeのEffortのデフォルト設定を「high」から「medium」に密かに引き下げていたことにある。その後、4月7日になってようやく、公式はデフォルト値を元に戻した。
Anthropicはこれについて明確な線引きを示している。モデルの選択（Model）が決めるのは「能力の有無」、つまり凍結された重みによって固定化された知識の境界である。一方、Effortが決めるのは「本気で取り組むかどうか」、すなわちモデルがファイルを読み込み、テストを実行し、多段階の推論を行う際の投入度合いだ。公式データによると、同一のプロンプトでも、Effortが高い場合に生成されるトークンは低い場合の7倍に達し、その差分はすべて検証と確認に費やされる。これは、中程度のモデル（Sonnetなど）であっても、高いEffortと組み合わせることで、ハイエンドモデルの低Effort時のパフォーマンスを工学的な実装面で完全に凌駕しうることを意味する。
開発者の対処法
Systimaは報告書の中で、AIエージェントの運用者は最終的な請求金額だけを見るのではなく、モデルが実際に受信したデータ量を深く記録すべきだと提言している。指示ファイルやMCPサーバーを一つずつ追加しながら負荷の変化を監視することが、コスト最適化への唯一の道だという。
同時に、Anthropicも段階的な情報開示機構を通じてコンテキストの圧迫を緩和しつつある。例えば、Claude Codeの「Skills」機能は、各スキルが起動された時に初めて具体的な内容を読み込む仕組みであり、かつリスト全体の長さはコンテキストの1%以内にハードリミットとして制限されている。これにより、トークン消費の無秩序な膨張を抑制している。
開発者にとっては、AIプログラミングの効率性に驚嘆するだけでなく、エンジニアリング予算を管理するように、トークン一つひとつの使途を緻密に管理し始める必要がありそうだ。