チームが実際に守れる AI コーディング予算の立て方

人頭上限が真っ先に破綻する

フラットな一人あたり上限は、誰もが最初に試して最初に失敗する予算です。理由は構造的です：エージェントのコストは人ではなく課題で変動します。同じ開発者が、数百ターンの大規模リファクタリングやキャッシュ効率の悪いコードベースという理由だけで、平常の 5 倍使う週があり得ます。上限が罰するのはワークロードであって人ではない——標準的な三つの破綻パターンが続きます：

1. 上限が重い課題を絞め殺す——道具を買った理由だったまさにその仕事を。
2. 軽いユーザーには一度も効かない——平均は無意味になり、財務はその行全体を信じなくなる。
3. 執行がスプレッドシートに落ち、数週間遅れ——お金は既に使い切られ、議論は既に腐っている。

人頭でなくワークロードに予算を割く

エージェントコストを実際に決める 3 変数——ターン数、再送コンテキスト、キャッシュ命中率——をチーム規模で配分に使います：

1. 平均でなく実形状から 1 人あたり月額をモデル化：日次ターン × コンテキストサイズ × キャッシュ挙動。2 週間の実測はどの業界ベンチマークより勝る。
2. 頭数でなくプロジェクトやタスク種別で配分：定型保守と高度なアーキテクチャ作業は別レーンに。振り分け自体が最大の誠実な節約。
3. 上限は実測形状の 80 パーセンタイルに——平常週で当たる上限は誰も尊重しない。

計量が起こる場所で執行する

スプレッドシートで執行される予算は願望です。リクエストはどこかで既に計量されています——モデル、トークン、キャッシュヒット、費用、リクエストごとに。ならば予算も同じ場所に置くべきです：黙って超過する代わりに到点で絞る Key 別クォータ、全行ではなく異常のみのアラート、請求書と突き合わせできる組織レベルの合計。課金する仕組みが予算を執行する仕組みでもあるとき、予算は争いの種でなくなります。

週 15 分のレビュー

週 1 回、3 つの質問で予算は生き続けます：キャッシュ命中率のトレンドは平坦か、下滑か？どの Key・プロジェクトが最も動き、ワークロードは本当に変わったか？正当な理由で上限に当たりそうな人に、先に割り当てを調整すべきか？これは会議ではなく、3 列の明細を一目見ること——四半期の消防演習を丸ごと置き換えます。