我不小心在 Claude 上花了 150 萬日圓：防止 AI 帳單災難的關鍵設定

為防止類似事故再次發生。

如果大家都能讀到這篇文章，讓我們那 150 萬日圓花得有意義，我會很開心的！🥺

現在該做的事

• 設定 Claude Team 組織每月用量上限（很明顯的）
• 為 Claude Code Review 設定每項服務的限制
• 將 Claude Code Review 的觸發條件從「每次推送」改為「一次」
• 如果可以將信用卡交易紀錄串流到特定頻道，就稍微留意一下（這次就是這樣發現的）
• 徹底實施防護措施與限制

Claude Team 組織每月用量限制設定

來自 https://claude.ai/admin-settings/usage

在 Enterprise 方案中，可以設定比每月更細緻的限制，所以值得善加利用。

Claude Code Review 每項服務限制

來自 https://claude.ai/admin-settings/usage

將 Claude Code Review 觸發條件從「每次推送」改為「一次」

來自 https://claude.ai/admin-settings/usage

發生了什麼事

在一個平靜的週六夜晚，一股不安的氣氛籠罩了整個組織。

150 萬日圓正被源源不絕地注入 Claude Code Review。😇

為什麼會發生

直接說結論，情況是這樣的：

Claude Code Review 執行

↓

新增審查意見

↓

AI Agent（Codex / Claude 等）判斷是否需要修正

↓

AI Agent 進行修正，並在必要時提交 / 推送

↓

因推送觸發，Claude Code Review 再次執行

↓

Rebase / force push 傳播到後續的 Stacked PR

↓

Claude Code Review 也在後續的 PR 上執行

↓

無限循環 ♾️

在我們開發的儲存庫中，我們引入了 Claude Code Review，它會自動審查 GitHub PR 的程式碼。此外，這次我們使用 AI Agent 來處理相對大規模的變更，方法是將它們拆分為多個 PR，並從上游到下游線性堆疊。（這一系列 PR 稱為 Stacked PR）。而且，Claude Code Review 是根據 token 使用量計費的服務。

Stacked PR

feat/branch-1（PR 1）

↓

feat/branch-2（PR 2）

↓

feat/branch-3（PR 3）

↓

…

↓

feat/branch-N（PR N）

回顧起來，這些審查的平均成本是每次 $25.81 美元 😱

即使在 Anthropic 官方部落格中，也說明了 Code Review 旨在進行深度審查，因此會比 Claude Code GitHub Action 等輕量級選項更昂貴，但我從未想過會這麼多……

這次，為了進行大規模變更，我們在本地同時使用多個 AI Agent 建立了多個 Stacked PR。Claude Code Review 在這些 PR 建立時執行。通常，人類會檢查審查內容並決定是否處理，但這次，我們假設人類會做最終檢查，因此將主要回應——包括是否處理審查的判斷——都委託給了 AI Agent。

深入探討問題

1. 使用多個 Stacked PR 進行複雜功能開發

這項任務涉及相對較大的變更。我們將其拆分為多個 PR，因為把所有內容放在一個 PR 中會使審查變得困難，也需要考慮發布順序。拆分 PR 本身並非錯誤。問題在於它們是線性的 Stacked PR。

在 Stacked PR 中，如果你修正了上游 PR，下游 PR 必須納入這些變更。換句話說，推送到上游會導致 rebase / push 傳播到下游。

這種結構與 Claude Code Review 設定為每次推送都觸發的特性不相容。

2. 完全將審查回應交給 AI

由於每次推送都會執行審查，且審查意見不斷增加，我們將以下任務分配給了 AI Agent：

• 檢查未解決的審查意見
• 決定要處理還是跳過
• 如果要處理，就修正並通過本地測試
• 提交 / 推送
• 回覆審查意見並將其標記為已解決
• 推送後監控一段時間，看是否有新的審查

最初的目標是，在我執行操作檢查和審查時，AI 對建議的回應已經完成。

如果我們確保由人類對審查意見的回應策略做出最終決定，很可能可以防止這種情況發生。

3. 下班後它仍在持續運作

即使在下班後，我也在執行並監控上述流程，但我至少應該在工作結束時停止它。這是一個完全的反思點。

由於我是以訂閱方式使用本地 AI Agent，所以對 API 成本正在即時增加的感覺很薄弱。另一方面，在 GitHub 端執行的 Claude Code Review 則在消耗 Anthropic 組織的使用量。在 Anthropic Console 上，目標儲存庫的平均成本顯示為每次審查 $25.81 美元。低估這種成本感受也是反思點之一。

我創造了一種情況，即按用量計費的 AI 被長時間執行，而感知到的本地成本與實際帳單成本之間存在落差。

哪裡出了問題

1. 對昂貴審查的「每次推送觸發」設定掉以輕心

這次，Anthropic Console 的設定是每次推送都執行審查。雖然每次推送都審查的功能很方便，但每次變更都可能產生頻繁的建議，因此應仔細考慮觸發條件。

2. 誤判 Stacked PR 與自動審查的相容性

Stacked PR 是將 PR 拆分為可審查單元的有效方法。然而，修正上游 PR 需要對下游 PR 進行 rebase。而推送到下游 PR 也會觸發那裡的審查。原本一個 PR 一次審查，在 Stacked PR 中會傳播到 N 個 PR，並且會執行相應數量的審查。

3. 將判斷、修正和推送都委託給 AI

使用 AI 來整理審查意見或進行本地修正非常方便。然而，這次我們賦予了它過多的權限。看到審查意見、處理它、推送、然後再次監控的這個循環，應該在明確的人類確認下操作。

4. 將組織限制作為最後一道防線

結果，用量達到了接近組織限制的程度，我們才在那裡注意到異常。有設定限制本身是好的。然而，10,000 美元作為最後一道防線實在太高了。此外，由於啟用了額外用量以及結算時間的影響，累積的每月組織成本幾乎在一天內就超過了 10,000 美元。我們需要能在更早階段就停止的防護措施。

總結

我在一天內用 Claude Code Review 燒掉了 150 萬日圓。我目前正在發送退款請求。原因是，在 Claude Code Review 設定為每次推送都觸發的情況下，AI Agent 的修正 / 推送以及 Stacked PR 的 rebase 鏈結合起來，形成了審查和修正的循環。

這次，我們過度利用了 AI 驅動開發的便利性，卻忽略了安全性和成本防護措施。到目前為止，還處於讓我們隨意使用 AI 的階段，因此各種 Agent 的提供價格相對低廉，但我認為我們現在正進入一個階段，既然我們已經體會到好處，他們就會像做生意一樣好好地從我們這裡收費。

我們正在為 AI 時代重塑開發組織。https://supateam.com/ 我們一定會善用這次經驗。