推計コストの4割強はサブエージェントだった｜Claude Code のログを親と子に分けて実測（子の6割強は Opus）

こんな人向けです

• Claude Code でサブエージェント（Agent ツール、.claude/agents/、ワークフロー）を使い始めた

• 「サブエージェントに出すと節約になる」と聞いたが、自分のログで親と子がそれぞれどれだけ使っているかを確かめたい

• 子に任せた作業が、どのモデルで、どれくらい動いているのかを知らない

• Claude Code の実測記事（1.5万ターン）を読んで、サブエージェント側の数字も知りたい

結論とデータ

Claude Code の前回記事（直近14日に更新されたセッションのログ、約1.5万ターン、2,034セッション）では、サブエージェントのログを集計の対象外にしていました。今回は、前回と同じ重み付けと文脈の定義を使い、期間は各ターン自身の時刻で直近14日に絞る厳密な方法に変えたうえで、親セッションとサブエージェントを分けて数えました（親だけなら8,403ターン）。

• 対象：自分の Claude Code の利用ログ。ターン自身の時刻で直近14日（2026-09-10 08:28 JST 以降）に絞った厳密版

• 規模：15,101ターン（うちサブエージェント 6,698ターン）、1,988セッション

• 集計日時：2026-09-24 08:28 JST（Codex の記事に載せた Claude Code の厳密版の数字は同日 01:11 の集計です。その後に増えたターンを含むため、親だけの数字も少し異なります）

この記事の「推計コスト」は、各ターンのトークン数に API の単価の比（入力1、キャッシュ読み0.1、キャッシュ書き1.25、出力5）で重みを付けて足し上げた相対値です。請求額でも、サブスクリプションの利用上限の計算式でもありません。モデルごとの単価の差は入れていません（全モデル同じ重み）。キャッシュ読みの比は多くのモデルで0.1ですが、公式の料金表では Opus 5.5 が0.05、Fable 5.1 が0.025です。この記事ではどのモデルも0.1で統一しています。前回の記事と同じ定義です。

また、この重みはキャッシュの保持時間による書き込み単価の差も入れていません。公式ドキュメントでは、サブスクリプションのプラン内で使う場合、親（メイン会話）は1時間キャッシュ、子は5分キャッシュで、1時間キャッシュの書き込みのほうが単価が高いとされています。この差を入れると、子の割合はこの記事の数字より小さくなります。また、文脈の長いターンほどキャッシュ読みが多いので、40万超の区分の割合もこの重み付けに左右されます。

わかったことは3つです。

1. サブエージェントは推計コストの4割強を占めていた

• サブエージェントのターン：全体の44.4%

• サブエージェントの推計コスト：全体の43.4%

• 1ターンあたりの推計コスト：親を1とすると、子は0.96

この集計だけでは、委譲で総量が減ったかどうかはわかりません。わかるのは、推計コストの4割強が子の側で発生していて、子の1ターンの推計コストは親の1ターンとほぼ同じ（0.96倍）だったことです。

2. 子の側では、40万超の長い文脈がほとんど育っていなかった

1ターン時点の文脈サイズ（入力＋キャッシュ読み＋キャッシュ書き）の分布です。

• 親セッション：40万トークン以上がターンの18.2%、親の推計コストの48.9%

• サブエージェント：40万トークン以上がターンの1.0%、子の推計コストの2.5%

• サブエージェントの文脈は、ターンの70.6%が5万〜20万トークンに収まっていた（中央値は約12万）

フォーク以外の子は、親の会話履歴を持たない新しい文脈から始まり、親には結果だけを返します（例外は、親の会話をまるごと引き継ぐ「フォーク」です。対話セッションではフォークモードが既定で有効で、Claude が必要と判断したときにフォークを使います。また、SendMessage で再開した子は、前回の履歴を保ったまま続きを進めます）。そのため、Claude Code の前回記事で推計コストの約6割（59.3%）を占めていた40万超の長い文脈が、子の側ではほとんど育っていませんでした（ターンの時刻で厳密に絞った今回の集計では、親の推計コストの48.9%がこの区分です）。サブエージェントの効き目は、単価を下げることよりも、親の会話を膨らませないこと＝文脈の防波堤にあるのではないか、というのが今回の読みです（推論です。委譲しなかった場合と比べた実験ではありません）。

なお、中央値だけを見ると子（約12万）のほうが親（約9万）より大きくなっています。子はシステムプロンプトとツール定義を読み込んだ状態で始まり、ファイルを読みながら進むので、「子は小さい」とは限りません（推論です。親の中央値は、5万未満の短いターンが45.9%あることで下がっています）。

3. 子の6割強が Opus で動いていた

サブエージェントのターンをモデル別に見ると、次のとおりでした。

• Opus 5.5：44.7%（子の推計コストの46.6%）

• Opus 5：18.1%（同 25.9%）

• Sonnet 5：33.6%（同 24.5%）

• Fable 5.1：3.3%（同 2.8%）

• Haiku 4.5：0.3%（同 0.3%）

自分では「検索・確認は Haiku、定型の実装は Sonnet に出す」というルールを書いていたのに、実際には子のターンの6割強が Opus でした。ワークフローの各段など、呼び出し側でモデルを指定しない子が、親と同じモデルで動く場面が多いためだと考えています（推論です。この記事の集計では、呼び出しごとの指定の有無までは数えていません）。

もう一つ、上位5セッションが占める推計コストは、親だけで数えると62.1%、子を含めると72.8%に上がりました。ワークフローのように子を大量に動かすセッションに、推計コストがさらに集中しています。

まとめ：この集計から言えるのは、推計コストの4割強が子の側で発生していたこと、そして子の文脈は40万超までほとんど育っていなかったことです。サブエージェントで総量が減ったかどうかは、この集計ではわかりません。なお、推計コストはモデルごとの単価の差を入れていないので、子のモデルを軽くした効果はこの数字には表れません。実際の利用枠では、子のモデル指定と、渡す仕事の切り方が効く余地があると考えています（推論です。効果は測っていません）。

この先の有料部分に載せているもの

• 自分のログを親と子に分けて数える手順：実行方法、出力の読み方、判定の目安（私の運用ルール）

• 設定テンプレート：軽い調査用（haiku）と定型実装用（sonnet）のサブエージェント定義、CLAUDE.md に書く委譲ルール、週1回の確認

• 集計スクリプトの全文：cc_subagent_split.py（Python の標準ライブラリだけで動き、集計値だけを出力します。外部には何も送信しません）

• 集計方法と限界：親と子の分け方、重複の扱い、推計コストの定義