ドキュメントとコードの突き合わせを1回実行したところ、85のエージェントが動き、API価格で換算すると約$26かかりました。85すべてが最も高価なモデルで動いていましたが、誰もそのモデルを選んでいません。スクリプトにモデルの指定がなく、エージェントがセッションのモデルをそのまま使ったためです。Claude Code トークン節約の手がかりを探すため、この実行と別の3回分のログを読み解きました。モデルの回答にはほとんどお金がかかっていません。費用の大半は、エージェントが自分のコンテキストを何度も読み直すことに消えていました。
workflowについての記事はこれで2本目です。workflowとは何か、どう起動するか、どんな制限があるかは、Claude Code workflowの最初の記事で書きました。この記事で扱うのは、計測した数字と、それを受けて自分のスクリプトに入れた変更だけです。
要点：
- モデルの回答は実行費用の約2%です。65〜84%はコンテキストのキャッシュ書き込みに使われています。
- 最も高いのは検出結果の再検証で、実行費用の50〜78%を占めます。
- 誰も選んでいないモデルが、最大の費用項目でした。役割ごとにモデルを割り当てたところ、コミット1件のレビューが$3.20から$1.23に下がりました。
- 新しいコミットがない状態での再実行は1セント未満です。小さなエージェントが1つだけ状態を確認して終了します。
- 基準となるタスク集がないと、節約額は正しく測れません。私の手元にはまだなく、これが最大の未解決事項です。
計測の方法#
workflowの各エージェントにはログがあります。~/.claude/projects/<プロジェクト>/<セッション>/subagents/workflows/wf_*/agent-*.jsonl です。モデルの応答を記録したエントリごとに message.usage というフィールドがあり、入力トークン、キャッシュ読み取り、キャッシュ書き込み、出力が入っています。これらをステージごとに合計し、2026年11月6日時点のAPI価格を掛けました。
| モデル | 入力 | キャッシュ書き込み（5分） | キャッシュ読み取り | 出力 |
|---|---|---|---|---|
| Opus 5.5 | $4 | $5 | $0.20 | $20 |
| Sonnet 5.5 | $2 | $2.50 | $0.10 | $10 |
| Haiku 5.5（プロンプト10万トークンまで） | $0.10 | $0.125 | $0.01 | $0.50 |
価格は100万トークンあたりです。サブスクリプションでは実行ごとの課金はありませんが、同じトークンがプランの上限を消費するため、比率は変わりません。
注意点が1つあります。ログの出力トークンは1リクエストあたり30〜100と、不自然に少なくなっています。モデルの思考分が記録されていないようです。そのため出力の割合は下限の推定値です。ただし結論は変わりません。出力を10倍に見積もっても、費用の20%未満にとどまります。
Claude Code トークン節約の前に確認したい、消費の行き先#
同じブランチで4回実行しました。エージェントはすべてOpus 5.5です。
| 実行 | エージェント数 | リクエスト数 | ≈ $ | 再検証の割合 |
|---|---|---|---|---|
| ブランチ全体のレビュー（60ファイル） | 58 | 379 | 14.2 | 66% |
| コミット1件のレビュー（4ファイル） | 10 | 57 | 3.2 | 50% |
| ドキュメントとコードの突き合わせ、ページ修正 | 85 | 349 | 26.1 | 78% |
| ビルドとテストが通るまで | 1 | — | ≈ 0.1 | — |
仕組みは単純です。エージェントは約5万トークンのコンテキストを持って始まります。システムプロンプト、ツール、CLAUDE.md、メモリ、タスクです。CLAUDE.md とメモリだけで、タスクの1行目に入る前に1.1〜1.3万トークンになります。その後エージェントは5〜8回リクエストを送り、リクエストのたびにそれまでのコンテキストとツールの結果をすべて運びます。おおまかには、エージェント数 × エージェントあたりのリクエスト数 × コンテキストの大きさ × モデルの単価です。4つの掛け算の項は、どれも小さくできます。
キャッシュが効かない場合もあります。Opus 5.5ではキャッシュ読み取りが$0.20、書き込みが$5で、25倍の差があります。レビューでは、検証側のエージェントが隣のエージェントのキャッシュにある共通プレフィックスを読んでいて、最初のリクエストの書き込み量の中央値はゼロでした。ドキュメントの突き合わせでは、検証役76体がそれぞれ自分のプレフィックス（3.2万トークン）をゼロから書き込んでいました。同じ内容を76回キャッシュに置くためだけに、$26のうち約$12が使われた計算です。
この実行でキャッシュが共有されなかった理由は、結局わかっていません。workflowのドキュメントによると、エージェント同士がキャッシュを読み合えるのは、モデル、effortレベル、エージェントの種類、ツール、レスポンスのスキーマ、作業ディレクトリがすべて一致する場合だけです。workflowのエージェントのキャッシュは、サブスクリプションでも5分で切れます。
再検証は高く、しかも無駄になりやすい#
「1つのエージェントが見つけ、別のエージェントが反証を試みる」という構成は、workflowで一番優れた仕組みです。同時に、最も費用がかかります。検出結果ごとに、独自のコンテキストを持つ検証役が起動するからです。
ドキュメントの突き合わせでは、検証役が76件の不一致のうち36件、47%を反証しました。このステージの費用の半分近くは、存在しない不一致を取り除くために使われたことになります。確認済みの検出1件あたりの費用は、どの実行でも$0.9〜1.2と同じ水準でした。
そこから出てくる結論は、最初は意外に見えます。検証役を増やすより、探索を厳しくするほうが安くつきます。探索役にページからの一字一句そのままの引用と、読んだコードの行を必ず添えさせれば、検証にかかる前の時点で、実在しない不一致が減ります。
外部の研究も同じ方向を示しています。プレプリントRefute-or-Promoteでは、10人のレビュアーが存在しないOpenSSLの脆弱性を満場一致で「確認」し、それを潰したのは1回の実証テストでした。比較実験ではなく1件の事例です。それでも、10のエージェントが同意しても事実とは限らない、という教訓は明確です。CodeX-Verifyでは、検証役を1つ足すたびに上積みが小さくなりました。精度の向上は+14.9、次が+13.5、その次が+11.2ポイントです。
スクリプトに入れた変更#
変更は5つです。それぞれ掛け算の項のどれかに効きます。
すべてのエージェントにモデルを明示する。 ドキュメントによれば、モデルを指定しないエージェントはセッションのモデルで動きます。そこで各スクリプトの冒頭に表を置き、実行時に上書きできるようにしました。
const M = {
scope: 'haiku',
find: A.thorough ? 'opus' : 'sonnet',
verify: A.thorough ? 'opus' : 'sonnet',
state: 'haiku',
...(A.models || {}),
}Haiku 5.5のキャッシュ書き込みは$0.125で、Opusの$5と比べて40分の1です。変更されたファイルの洗い出しなどの下調べと、状態の記録をHaikuに任せています。探索と検証はSonnetです。Opusはリリース前の実行と、1か所の例外に残しました。サードパーティコードの監査で、インストールスクリプトを読む工程です。悪意あるフックを見逃したときの損失は、どんなトークン代より大きいからです。機械的な作業と、軽微な検出の検証には effort: 'low' を指定しました。
重複は検証の前に統合する。 3人のレビュアーが、別の角度から同じバグを見つけることはよくあります。ファイルが同じで行番号の差が3行以内なら、その検出は1回だけ検証します。上限を超えた軽微な検出は検証せず、ログに書き込んだうえで別のリストに回します。切り捨てが黙って行われないようにするためです。
検証役は事実を持ってくる。 呼び出し、スタックの上位にある条件、コマンドの出力、一字一句そのままの引用などです。事実がなければ、その検出は却下します。
`Keep a finding only with evidence — what you found and where ` +
`(file:line or command output). No evidence → reject.`3票での多数決は、リリース前の実行で重大な検出に対してだけ残しました。
新しい部分だけを検証する。 レビューは、最後に検証したコミットを .git の中のファイル（git rev-parse --git-path change-review-state.json）に保存します。そのためコミットには含まれません。次の実行は lastReviewedSha..HEAD を見て、変更のないファイルの未解決の検出は引き継ぎます。全体実行はpull requestの前、rebaseの後、プロンプトを変えた後に行います。そのためスクリプトにはプロンプトのバージョン番号があります。CodeRabbitの差分レビューや、CIで影響を受けるテストだけを選ぶ方法も、同じ考え方です。
全体実行はやめませんでした。理由があります。その日いちばん重大なバグを見つけたのは、まさに全体実行でした。クライアント、サービス、設定という3つのファイルにまたがるバグで、1ファイルずつ見る差分実行では気づけなかったはずです。
早期終了。 前回の実行から何も変わっていなければ、下調べの後、スクリプトはすぐに結果を返し、レビュアーを1つも起動しません。
同じリポジトリでの結果です。
| 実行 | エージェント数 | リクエスト数 | モデル | ≈ $ |
|---|---|---|---|---|
| コミットのレビュー、旧スクリプト | 10 | 57 | Opus | 3.20 |
| コミットのレビュー、新スクリプト | 10 | 40 | Haiku + Sonnet | 1.23 |
| 同上、新しいコミットなしで再実行 | 1 | 2 | Haiku | < 0.01 |
品質の比較は厳密ではありません。旧スクリプトはレビュー指摘を反映する前のコミットを見ていて、新スクリプトは反映後を見ています。検出内容も異なり、確認できた件数は3件と2件です。ただ、量は同じなので費用は比較できます。4〜6ファイル、10エージェントです。
もう1つの変更は、お金ではなく「検証→修正」のループに関するものです。私の翻訳スクリプトでは、修正エージェントが最後に変更を入れていて、その変更を誰も読み返していませんでした。今は修正の後に、effort: 'low' のSonnetによる短い再検証を入れています。ループは検証で終わらせるべきです。そうしないと、最後の変更が未確認のままコミットに入ります。
まだ確かめていないこと#
- 基準となるタスク集がありません。 既知のバグがあった過去のpull requestを30〜50件と、意図的に仕込んだバグが数件必要です。それがなければ、Opusと比べてSonnetが微妙な指摘をどれだけ見逃すのか、言い切れません。
- ドキュメント突き合わせでキャッシュが共有されなかった理由は不明です。1回の実行で最大$12にあたります。
- 1.1万〜1.3万トークンの共通ルール（21 KBの
CLAUDE.mdとメモリ）は、いまもすべてのエージェントに読み込まれます。コストに関するドキュメントは、CLAUDE.mdを200行より短く保ち、特殊なルールは必要なときに読み込まれるスキルに移すよう勧めています。まだ手をつけていません。 - 節約額の見積もりは、レビューの計測を除いてすべて計算であり、実測ではありません。
ドキュメントの突き合わせについて補足します。最大の問題は、実行のたびに全ページを丸ごと検証していることです。次の一手は、変更されたファイルに紐づくページだけを突き合わせることです。ページをコードに紐づけて、古くなったことをページ自身が知らせるようにする方法は、コード内のドキュメントアンカーの記事で書きました。
保存済みのworkflowがあるなら、まず次のコマンドを1つ実行してください。grep -n "agent(" ~/.claude/workflows/*.js です。出力の中でオプションに model がない呼び出しは、おそらくセッションのモデルで動いています。
