同じような事故を起こさないように。
僕らの150万円が何かしら意味があったと思えるようにみんなに読んでもらえると嬉しいです！！！🥺
とりあえずこれをやっておけ
- Claude Teamの組織月間利用上限設定（当然）
- Claude Code Review の per-service limit
- Claude Code Review のトリガーを push ごとから1回に変更
- クレカの決済ログを流せるなら特定のチャンネル流して軽く見ておく（今回はこれで気づいた）
- ガードレールとハーネスの運用を徹底する
Claude Teamの組織月間利用上限設定
https://claude.ai/admin-settings/usage から
enterpriseだと月次だけではなくもっと細かく設定できるので活用していただくと良さそうです。
Claude Code Review の per-service limit
https://claude.ai/admin-settings/usage から
Claude Code Review のトリガーを push ごとから1回に変更
https://claude.ai/admin-settings/usage から
何が起きたのか
平穏な土曜日の夕方、違和感が組織内を走ります。
Claude Code Reviewに150万円垂れ流れていました。😇
なぜ起きたのか
結論を先に書いておくと以下のことが起こっていました。
Claude Code Review が走る
↓
レビューコメントが付く
↓
AI エージェント（Codex/Claude等）が対応要否を判断する
↓
AI エージェントが必要なら修正して commit / push する
↓
push をトリガーに Claude Code Review がまた走る
↓
Stacked PR の後続にも rebase / force push が走る
↓
後続 PR でも Claude Code Review が走る
↓
以下♾️
僕たちの開発しているリポジトリでは、Claude Code Review を導入しており、GitHub の PR に対して自動でコードレビューしてくれるようになっています。 また、今回は比較的大規模な変更を、AI エージェントを用いて複数の PR に分け、上流 PR から下流 PR へ順番に直列で積む形で進めていました。（一連の PR をまとめて Stacked PR と呼びます） そして、Claude Code Review はトークン使用量に基づいて請求が発生する従量課金です。
Stacked PR
feat/branch-1 (PR 1)
↓
feat/branch-2 (PR 2)
↓
feat/branch-3 (PR 3)
↓
…
↓
feat/branch-N (PR N)
後から振り返るとこのレビューの平均コストは $25.81/review かっていました😱
Anthropic 公式ブログでも、Code Review は深いレビューを目的にしており、Claude Code GitHub Action のような軽量な選択肢より高くなると説明されていますがまさかここまでとは....
今回は大規模な変更を行うべく、ローカルで複数のAI エージェントを利用しながら複数の Stacked PR を作成していました。これらの PR を作成したタイミングで、まず Claude Code Review が実行されます。 通常であればレビュー内容をチェックして対応するか否かの判断を行いますが、この時は最終的なチェックを人間がやる前提のもと、一次対応として AI エージェントにレビュー対応をする/しないの判断まで委ねて修正を行うように依頼してしまっていました。
問題の深掘り
1. 複雑な機能を複数の Stacked PR で進めていた
今回の作業は比較的大きめな変更でした。
1つの PR に全てを詰め込むとレビューが難しく、リリース順序なども踏まえて複数の PR に分割していました。 PR 分割自体は間違っていませんでした。問題は、それが直列の Stacked PR だったことです。
Stacked PR では、上流 PR を修正すると、後続 PR もその変更を取り込む必要があります。 つまり、上流を push すると、後続にも rebase / push が波及します。
この構造は、Claude Code Review が push ごとにトリガーされる設定と相性が良くありませんでした。
2. レビュー対応を AI に丸任せていた
push のたびにレビューが走り、レビューコメントも増えていたため、AI エージェントに次のような作業を任せていました。
- 未解決レビューコメントを確認する
- 対応するか、見送るか判断する
- 対応する場合は修正してローカルでテストを通す
- commit / push する
- レビューコメントに返信して resolve する
- push 後しばらく追加レビューを監視する
自分が動作確認、レビューする段階では、AI の指摘対応まで一通り完了している状態にしたかった、というのが元々の狙いでした。
レビューコメントへの対応方針について、最終的な判断を人間が下すようにしていれば、防げた可能性が高かったです。
3. 業務終了後も動いたままだった
業務終了後も上記のプロセスを実行して監視をしていましたが、少なくとも業務終了時には止めるべきでした。 ここは完全に反省点です。
ローカルの AI エージェントはサブスクで使っていたため、今この瞬間に API コストが増えているという感覚が薄かったです。 一方で、GitHub 側で動いている Claude Code Review は Anthropic の組織利用量を消費していました。 Anthropic Console 上では、対象リポジトリの平均コストが $25.81/review と表示されていました。このコスト感を見誤っていたのも反省ポイントの一つです。
ローカルの体感コストと、実際に課金されているコストにズレがある状況で、従量課金の AI が長時間実行される状態を作り出してしまいました。
何が良くなかったか
1. push ごとに高額レビューが走る設定を軽く見ていた
今回は、Anthropic Console 側の設定でレビューが push ごとに動く設定でした。
push ごとにレビューされる機能は、便利ではありますが、変更のたびに頻繁に指摘がつくケースもあるため、トリガーは慎重に検討するのが良さそうです。
2. Stacked PR と自動レビューの相性を見誤った
Stacked PR は PR を分割する際に、レビュー可能な単位に分けられる有効な手段です。
ただし、上流の PR を直すと後続 PR に rebase が必要になります。 そして後続 PR へ push すると、そこでもレビューが走ってしまいました。
1 PR ならレビューが1回で済むものが、Stacked PR では N 個の PR に波及し、その分だけレビューが実行されます。
3. AI に判断して修正して pushまで任せた
レビューコメントの整理や局所的な修正に AI を使うのはとても便利です。しかし、今回は権限を渡しすぎました。
レビューコメントを見て、対応して、push して、また監視するというループは、人間の明示的な確認を挟んで操作すべきでした。
4. 組織上限を最後の砦にしてしまっていた
結果的には組織上限付近まで到達して、そこで異常に気づきました。
上限があったこと自体は良かったです。ただし、$10,000 は最後の砦としては高すぎました。
また、追加利用が有効だったことや反映タイミングの影響もあり、組織月間累計コストはあっという間にほぼ1日で $10,000 超 まで到達していました。もっと手前で止まるガードレールが必要でした。
まとめ
Claude Code Review で1日で150万円を溶かしてしまいました。今は返金リクエストを送っております。
原因は、Claude Code Review が push ごとにトリガーされる設定のまま、AI エージェントによる修正・push と Stacked PR の rebase 連鎖が重なり、レビューと修正のループを作ってしまったことです。
今回は、AI を使った開発の利便性を取りすぎて、安全性やコスト面のガードレールが疎かになっていました。
今まではAIをとにかく使わせるフェーズだったので各種エージェント比較的安価での提供でしたが、もう良さを知った僕らからしっかりビジネスとしてお金をとってくるフェーズになると思います。
僕たちは今、まさにAI時代の開発組織を再発明をするプロダクトを作っています。 https://supateam.com/ この経験をしっかり活かします。
