Claude Code のタスク 1 件は実際いくらか

月次はタスクを隠す

月次平均は誠実な会計であり、役に立たないハンドルです。同じ開発者の同じ月の中で、タスク単位のコストは人単位の差よりずっと大きく動きます——形状次第で一桁違い、努力の差ではなく。3 つの形状がエージェントの仕事のほぼ全部を覆います：

1. 外科的バグ修正。ターン数は少なく、コンテキストはコンパクト、ファイルは既読——キャッシュが仕事の大半を担う。最も安い形状であり、エージェントを「無料に感じさせる」もの。
2. スキャフォールド新機能。ターン数は多いが、コンテキストは予測可能に成長し、安定プレフィックス（指示・規約・既存ファイル）はよくキャッシュされる。中コストで非常に予測可能。
3. 深いリファクタリングやマラソンセッション。数百ターン、コンテキストがターンごとに雪だるま式に増え、キャッシュ命中率がモデルの定価より請求額を左右する。予算が死ぬのはここです。

コンテキストの雪だるま

3 つ目の形状を高くするメカニズム：エージェントは通信上ステートレスです。15 ターン目はそれまでの会話を丸ごと再送します——システムプロンプト、読んだファイル、ツール結果まで。各ターンの入力は履歴とともに増えるので、token 単価が変わらずとも長いセッションの 1 ターンあたりコストは上昇します。境界ある小タスクに切ればコンテキストは各自 1 回だけ支払う。無限に続く 1 本のセッションは、全部を何度も支払う。セッション形状自体がコスト判断です。

同じタスクで請求が違う理由

2 人が同じリファクタリングを走っても請求は大きく違います。影響順の容疑者：キャッシュ挙動（安定プレフィックスの安価な再読 vs 揮発性プレフィックスの冷読み再支払）、セッション規律（境界ある新しいセッション vs 転がり続けるメガセッション）、モデルルーティング（全ステップ旗艦 vs 難所だけ旗艦）。これらは定価に書かれず、リクエスト毎の明細にだけ現れる——「なぜ高かった」を裁ける唯一の場所です。

タスクで計り、タスクで決める

ゲートウェイがリクエストのラベリングやプロジェクト別キーを許せば、タスクがコスト単位になります：このリファクタリングはこれだけ、この修正レーンは週これだけ。この粒度こそが前回の月次予算を守れるようにするもの——魔法の平均を争うのではなく、タスク毎の帳簿を読む。ラベリングがなければ、セッション分割＋プロジェクト別キーが実用的な代用です。