はじめに
SREホールディングス株式会社にて、ソフトウェアエンジニアをやっております、叶です。
要件定義から実装・テストまでの開発フローをAI化するため、Claude専用の「ドキュメント駆動開発ツール」を自作しました。品質と再現性のためにタスクを細かく分け、1タスクずつ実行し、別エージェントでレビューする ── 設計としては“真っ当”なはずでした。
ところが請求を開くと、成果物（出力）はわずか21%。半分以上が「コンテキストの読み直し」に消えていました。このコスト爆発を実データで解剖し、なぜチャット利用時の数倍ものコストがかかったのか、原因を調査し、思い知らされた教訓を共有します。
対象読者
- AIエージェント／オーケストレーションツールを自作している人 ── 「タスク分割×並列」「自動レビューでループ」のコスト挙動を知りたい。
-
claude -pを CI・バッチで回している人 ── 単発実行を多数走らせたときに、課金がどこで膨らむか把握したい。 - Claudeの請求が想定より高くて困っている人 ── 「そんなに使っていないのに高い」の正体を、トークンとキャッシュの観点で理解したい。
1. 何を作ったか
要件定義 → 基本設計 → 詳細設計 → 実装 → テスト を、すべて「タスク」として扱うClaude専用のアプリケーションです。
- フェーズはドキュメント:各フェーズの成果物（設計書など）を生成タスクとして作り、前フェーズから次フェーズを生成する。
- 実装はタスクDAG:設計から実装タスクを分解し、依存関係に従って実行する。1機能=1〜数タスク。
-
証跡主義(Proof of work):実行ごとにログ・proof・レビュー結果・失敗原因を記録する。ボードが監査証跡になる。
ポイントは実行モデル：各タスクは独立した claude -p プロセスとして起動し、終わると消える。実装には別エージェントのレビューが走り、不合格なら差し戻して再実行。1機能のために、独立プロセスが何度も立ち上がる ── これが後述する爆発の根です。
2. 事件 ── 出力はコスト全体のわずか21%
ある実装フェーズの実測値です。合計コストは $72.83（12タスク・1,070ターン）。チャット比で、同じ使用量でも体感の出力量が1/6に落ちていました。
ここで注目すべきは内訳が歪なこと。 出力はわずか21%。キャッシュ読込が51% を占め、92.1Mトークンは出力(750K)の約123倍。「考える/読む」ために流し込んだコンテキストが、成果物の100倍以上あるということです。
3. コスト構造のおさらい ── トークン×キャッシュの“重み”
Claudeのコストは、積み重なるトークン数に『キャッシングの割引率』を掛け合わせたものです。
ここに、今回の事件を理解する鍵が2つあります。
- 読込は激安（×0.10）：だから92.1Mトークン読んでも「たった」$37で済む。
- 書込は激高（×1.25）＝ 読込の12.5倍：書込はわずか3.7M（読込の4%）なのに、コストは$19.94（読込の53%）にもなる。
つまり 「初めて流し込む固定コンテキスト(初回送信)＝cold start」が cache_write（×1.25） で一番高い。一度載れば5分以内(TTL)は 1/10（×0.10）で読めます。
4. 犯人 ── claude -p は呼び出すたびに“cold start”
claude -p は動作モードのフラグで、Claude Codeを非対話で一度だけ実行して結果を出力し終了する“ワンショット”です。
問題は「ワンショット＝毎回まっさら」であること
- 筆者のツールは各タスクを
claude -p <プロンプト> --model <model>で起動し、-c/--continueも-r/--resumeも付けていない。→ タスクごとに会話履歴ゼロの cold start。 - 別プロセスの
claude -p間で共有されるキャッシュは「システム＋ツール定義」の接頭辞（数千トークン）だけ。CLAUDE.md・設計書・スキル・タスク本文は、毎回 cache_write(×1.25) で作り直し。
つまり1タスクの消費はこうなります。
1回の claude -p 実行 ≈
(システム + ツール定義 + CLAUDE.md + 注入コンテキスト) ← cold な cache_write(×1.25)
+ (タスク本文)
+ (エージェントループ中のファイル探索・読込・リトライ) ← ここで read が積み上がる
+ (出力)
この固定オーバーヘッドを毎タスク ×1.25 で焼き直す ── これが cache_write 27%（$19.94）の正体です。
チャットとの決定的な差
対話チャットは 1つのwarm session で機能をまるごと作ります。CLAUDE.mdも設計書も共通基盤も履歴に残り、2回目以降は 読込(×0.10) で再利用。固定コストは最初の1回だけ。
一方このツールは実装フェーズを12タスクに割り、それぞれ別プロセスで cold start。「最初に1回確立して暖かく使い回す」というチャットの経済を、構造的に捨てていました。
5. なぜチャットなら数分の一で済むのか ── “warm session”の経済
| 対話チャット | このツール | |
|---|---|---|
| コンテキスト | 1つのwarm sessionを最後まで再利用 | タスクごとに別プロセス＝cold start |
| 固定コスト(CLAUDE.md等) | 最初の1回だけ書込、以降は読込(×0.10) | 毎タスク書込(×1.25)で焼き直し |
| パターンの定着 | 規約や実装の型を1回確立→以降は直前を真似て安く量産 | 各タスクが規約から型を毎回再導出→失敗→差し戻し |
| 手戻り | 人が「テスト忘れてる」と1会話で指摘→同一文脈で即修正 | レビュアーが冷たく差し戻し→新プロセスが全部読み直して再実装 |
| 上限 | 人がループを止める | 規定回数まで自動再実行（収束しない案件も焼き続ける） |
チャットが安いのは賢いからではなく「一度温めた文脈を捨てない」から。 逆に、タスク独立・証跡主義・自動レビューという“良い設計”が、ことごとく cold start を増やす方向に働いていました。
6. 対策 ── 切れる無駄と、設計上消えないコスト
原因を「設計上の必然」と「純粋な無駄」に分けるのが出発点でした。
設計上の必然
フェーズ別ドキュメント生成、タスク独立、独立レビュー、proof記録。これらは監査証跡型ツールの価値そのもので、消すと製品が別物になります。
純粋な無駄（削減対象）
- 差し戻し常連ルールの事前チェック：却下が集中する規約をタスク冒頭に明示し、合格済みの同種ファイルを“手本”として指す。チャットの「直前の実装を真似る」経済を cold start 内に再現する狙い。
- 再実行を“最小修正モード”化：差し戻し時は「前回実装を差分で読み、指摘箇所だけ直す。再scaffold・全体再実装は禁止」。50〜68会話の焼き直しを15〜25会話に圧縮。
さらに踏み込むなら --resume(前回の会話履歴を再送) でタスクを“warm session”として繋ぐ 案もありますが、万能薬ではありません。会話が5分以内・他プロセスに割り込まれず・連続で走らないと、成長した全履歴を cache_write で焼き直し、かえって高くつく。
まとめ
- 自作ツールの実装フェーズは対話チャット比およそ3〜6倍だった。内訳はキャッシュ読込51% / 書込27% / 出力21%。
- コストはトークン×キャッシュ単価で決まる。読込は×0.10と安いが、書込は読込の12.5倍。だから「初回に固定コンテキストを焼き込む cold start」が一番高い。
- 爆発の要因は、
claude -pの毎回cold start（warm sessionの不在）。 - 対策は 「規約の事前注入＋手本提示」「再実行の最小修正化」、条件付きで 「セッション継続」。ただし監査証跡型の必然コストは消えない。
ドキュメント駆動・タスク分解・証跡主義は、品質と再現性に一定の効果が期待できる設計アプローチの一つだと考えています。しかしAIエージェントのコストは「賢さ」より 「文脈をどれだけ温め直しているか」 で決まる ── それを請求額で思い知らされた、という話でした。
本記事は筆者の実運用データと公開情報・公式ドキュメントに基づく解説です。料金・上限・仕様は変更される場合があります。最新情報は https://support.claude.com を参照してください。
Discussion