【Claude Code】AIコードレビューの請求額を見て青ざめた話—情シスが今すぐ設定すべき5つのガードレール

▼ ある会社で起きた「1日150万円」の事故

ある会社で、Claude Code Reviewの利用料金が1日で約150万円（$10,000超）に達する事故が起きた。

土曜日の夕方、クレジットカードの決済通知で異変に気づいた。確認したところ、Claude Code Reviewのトークン消費が暴走していた。

何が起きていたのか。端的に言うと、AIコードレビューとAIエージェントが無限ループを作ってしまった。

しかもこの会社では、大規模な変更をStacked PR（直列に積んだ複数のPR）で進めていた。上流のPRを修正すると、後続PRにもrebaseが走り、そのたびにレビューがトリガーされる。1件あたりの平均レビューコストは$25.81。これが数十回、数百回と繰り返された。

業務終了後もAIエージェントが動き続けていたため、気づいたときにはすでに手遅れだった。

▼ そもそもClaude Code Reviewとは何か

Claude Code Reviewは、AnthropicがGitHub連携で提供するAIコードレビュー機能だ。PRに対して複数のAIエージェントが並列でレビューを実行し、ロジックエラー、セキュリティ脆弱性、リグレッションバグなどを検出する。

ポイントは、従量課金であること。Claude CodeのサブスクリプションやClaude Code GitHub Action（無料・軽量）とは別の課金体系で、トークン使用量に基づいて請求が発生する。

料金の目安

Anthropicの公式ドキュメントでも、Code Reviewは「深いレビュー」を目的としており、GitHub Actionのような軽量な選択肢よりコストが高くなると明記されている。自分でも検証したところ、ある程度の規模のPRだと1回$20前後は普通にかかる印象だ。

3つのトリガーモード

Claude Code Reviewには、レビューが走るタイミングを制御する3つのモードがある。

▼ なぜ150万円まで膨らんだのか

この事故を分解すると、4つの要因が重なっている。

要因1：Stacked PRと「After every push」の相性の悪さ

Stacked PR（直列に積んだ複数のPR）は、コードレビューしやすい単位にPRを分割する有効な手法だ。ただし、上流のPRを修正すると後続PRにrebaseが必要になり、そのたびにpushが発生する。

「After every push」が設定されていると、1つのPRを直したつもりが、N個のPRでレビューが走る。これだけでコストがN倍になる。

要因2：AIエージェントに「判断→修正→push」まで任せた

レビューコメントへの対応をAIエージェントに丸任せしていた。具体的には、未解決コメントの確認→対応要否の判断→修正→テスト→commit/push→コメント返信→追加レビューの監視、という一連の流れをすべてAIに委ねていた。

人間が「pushする前に確認する」というゲートを挟んでいれば、ループは止まっていた。

要因3：ローカルと課金の体感がずれていた

ローカルのAIエージェントはサブスクリプション（月額固定）で使っていたため、「今コストが増えている」という感覚が薄かった。一方で、GitHub側で動いているClaude Code Reviewは従量課金だ。このローカルの体感コストとクラウドの実コストのズレが、異常に気づくのを遅らせた。

要因4：組織上限が「最後の砦」になってしまっていた

組織の月間利用上限は$10,000に設定されていた。上限があったこと自体は良かったが、$10,000は「最後の砦」としては高すぎた。1日で上限に達するまで止まらなかったわけで、もっと手前に小さなガードレールが必要だった。

▼ 情シスとして今すぐ設定すべきガードレール

この事故を他人事にしないために、情シスとして最低限やるべき設定を整理する。Claude Code Reviewを使っていなくても、AIツールの従量課金全般に通じる話だ。

ガードレール1：組織の月間利用上限を適切に設定する

claude.ai/admin-settings/usage から設定できる。これは最も基本的なガードレールだが、上限金額の設定が甘いと意味がない。

ガードレール2：Code Reviewのper-service limitを設定する

claude.ai/admin-settings/usage から、Claude Code Review単体の月間上限を設定できる。組織全体の上限とは別に、サービス単位でキャップをかけることで、特定サービスの暴走が他のサービスの利用枠を食い潰すのを防げる。

ガードレール3：トリガーを「After every push」から変更する

同じく管理画面から、レビューのトリガーモードをリポジトリごとに変更できる。特別な理由がない限り「Once after PR creation」に設定するのが安全だ。

ガードレール4：クレカの決済ログを監視する

今回の事故では、クレジットカードの決済通知で異常に気づいた。これは偶然ではなく、有効な監視手段だ。

SaaSの利用料金はクレジットカード決済が基本なので、決済ログをSlack等の特定チャンネルに流しておくと、異常な課金にすぐ気づける。Anthropicの管理画面だけでなく、決済レイヤーでも監視しておくことで、二重のセーフティネットになる。

ガードレール5：AIエージェントに「pushの権限」を安易に渡さない

これは情シスというよりエンジニアリング側の話だが、組織のルールとして定めておくべきポイントだ。

AIエージェントにコードの修正を任せること自体は問題ない。ただし、「修正→テスト→commit→push」まで一気通貫で任せると、従量課金サービスとの組み合わせでループが発生するリスクがある。「pushの前に人間が確認する」というゲートを必ず挟むルールを設ける。

▼ これはClaude Code Reviewだけの話ではない

この事故はClaude Code Reviewで起きたが、本質的には「従量課金のAIサービス × 自動化 × 監視不足」の組み合わせで起きた事故だ。

同じ構造のリスクは、他のAIサービスでも発生しうる。

AIツールの導入を推進する情シスこそ、この手のコストリスクを理解し、導入時にガードレールをセットで設計する必要がある。ツールを入れて終わりではなく、「暴走したときに止まる仕組み」まで含めて導入設計だ。

▼ まとめ

• ▶ Claude Code Reviewで1日150万円のコスト事故が実際に発生している
• ▶ 原因は「pushごとのトリガー × AIエージェントの自動修正 × Stacked PRの連鎖」による無限ループ
• ▶ 情シスとして最低限やるべきは、月間上限の適切な設定・per-service limit・トリガー変更・決済ログ監視の4点
• ▶ これはClaude Code Reviewだけの話ではなく、従量課金AIサービス全般に共通するリスク構造
• ▶ AIツールを導入するなら「暴走したときに止まる仕組み」まで含めて設計する

AIの活用を推進する立場だからこそ、「便利だから入れましょう」だけでは不十分だ。ガードレールとハーネスの設計をセットで考えることが、AIツール時代の情シスの仕事になる。