Claude Codeのコスト管理｜本番運用でAPI課金事故を防ぐ仕組み
手元で対話的に使う分には料金はほぼ問題にならない。事故が起きるのは「自動化・常駐・複数エージェント」が揃ったとき。当社が実際に踏んだ課金事故と、その後に組み直した仕組みを、数字込みで公開します。
Radineer 編集部 ・ 自社の Claude Code 本番運用に基づく解説（2026 年 5 月時点）
Claude Code のコスト管理とは、AI エージェントが自律的に実行するトークン消費・API 呼び出し・常駐プロセスの費用を、上限設計と監視で事故レベルに膨らませないための運用設計を指す。事故は「自動化」「常駐」「複数エージェント」の 3 つが揃ったときに起きる。
なぜ課金は「自動化した瞬間」に跳ねるのか
対話的に Claude Code を触っているうちは、コストは体感できる範囲に収まる。自分が Enter を押した回数しか動かないからだ。
問題は、業務に組み込んで人が見ていない時間に動かし始めたときに起きる。どれも「設定をひとつ間違えただけ」で起きて、請求が見えるのは月末。そのときには手遅れになっている。
- ループが止まらず同じ処理を回し続ける
- 1 ジャンルの自動化を 10 ジャンルに横展開したら呼び出しが 10 倍になる
- 複数エージェントを並列で走らせて、それぞれが重い処理を抱える
- 従量課金のクラウド側（サーバーレス）が裏で別途加算される
当社が実際に出した課金事故
恥を承知で実額を出す。一次情報の価値はここにある。
① 有料 API の過剰呼び出しで約 34 万円。自動化処理が API を想定以上の頻度で叩き続け、気づいたときには数十万円が溶けていた。「単価は小さいから大丈夫」という油断と、呼び出し回数に上限を置いていなかったことが原因。
② サーバーレスの従量課金で約 1,160 ドル。これは Claude 本体ではなく、ホスティング側（自動スケール機能）が想定外に課金された事故。AI 処理そのものでなくても、AI を動かす土台が従量課金だと同じように跳ねる。
③ 環境変数の欠落で 52,039 回の再起動。常駐プロセスが設定ファイルを読めずに落ち続け、5 万回以上リスタートを繰り返していた。「落ちたら止まる」のではなく「落ちたら無限に再試行する」設計が事故を増幅させた。
この 3 件で得た結論はシンプルだ。従量課金は、上限を物理的に塞がない限り必ず事故る。
課金が膨らむ典型 4 パターン
共通点は「1 回の単価は小さいが、回数か並列度で掛け算される」こと。コスト管理は単価交渉ではなく、回数と並列度の上限設計が本質になる。
| パターン | 何が起きるか | 跳ね幅 |
|---|---|---|
| ターン数の暴走 | 1 タスクの試行回数(max-turns)が無制限／高すぎ、延々と試行錯誤 | 中〜大 |
| 横展開の掛け算 | 1 ジャンルの自動化を全ジャンルにコピーし呼び出しが倍々 | 大 |
| 並列エージェント | 複数エージェントが各自重い処理を同時実行 | 大 |
| 土台の従量課金 | サーバーレス／DB の自動スケールが裏で加算 | 中〜特大 |
コストを止める仕組み（4 層）
当社が事故後に組んだ防御は 4 層になっている。上から順に効く。
第 1 層・定額 CLI に寄せる：最も効いたのは、従量課金の API から定額の CLI 運用に主軸を移したこと。トークン単価で課金される経路を業務の主動線から外すだけで「月末に怯える」状態が構造的に消えた。
第 2 層・トークンそのものを削る：コマンド出力やログをそのまま AI に渡すとトークンを浪費する。当社は開発操作をプロキシ経由で要約・フィルタし、60〜90% のトークン削減を実現している。
第 3 層・呼び出し予算と監視：自律処理には呼び出し回数の予算（コールバジェット）を持たせ、本番に流す前に少量で試すカナリア実行で異常を検知する。結果はキャッシュで共有し重複させない。
第 4 層・サーキットブレーカ：一定の閾値を超えたら処理自体を止める遮断機を入れる。再試行は無制限ではなく回数制限つきにする。前述の 5 万回再起動は、この設計があれば数十回で止められた。
料金形態別・どこで事故るか
業務に常駐させるなら「定額 CLI ＋上限設計」が本命。従量 API は天井が見えないので、使うなら短期・小規模・予算上限つきに限る。
| 運用形態 | 課金モデル | 事故リスク | 向いている用途 |
|---|---|---|---|
| 対話的に CLI を手動操作 | 定額 | 低 | 個人・検証 |
| API 従量で自動化 | トークン従量 | 高（回数の天井がない） | 短期・小規模に限定すべき |
| 定額 CLI を常駐自動化 | 定額 | 中（暴走ループ・再起動） | 業務常駐の本命 |
| サーバーレス上で AI 処理 | 計算量従量 | 特大（裏で加算） | 上限設定を必ず併用 |
事故を防ぐ導入 3 ステップ
- 課金経路を 1 枚に棚卸す。Claude 本体だけでなく、ホスティング・DB・外部 API まで「従量課金が走っている箇所」を全部書き出す。見えない加算が最も危ない。
- 各経路に物理的な上限を置く。試行回数の上限、呼び出し予算、サーバーレスの自動スケール停止、再起動回数の制限。「気をつける」ではなく設定で塞ぐ。
- 少量カナリアで流してから本番。自動化は必ず小さく試し、想定の呼び出し回数と一致するか確認してから全量に上げる。
よくある落とし穴
- 「単価が安いから大丈夫」：単価ではなく回数 × 並列度で見る。掛け算を甘く見ると 34 万円が溶ける。
- AI のコストだけ見る：土台のサーバーレス／DB の従量課金が本体より高くつくことがある。
- 再起動を無制限にする：落ちたら無限に再試行する設計は、事故を増幅する装置になる。
- 月末まで請求を見ない：日次でコストを見える化しないと、気づいたときには手遅れ。
よくある質問
Claude Code は個人で使うと月いくらかかる？
対話的に手元で使う範囲なら定額プランで収まり、事故リスクは低い。料金が問題になるのは自動化・常駐・並列運用に踏み込んだとき。
API 従量と定額 CLI、業務で使うならどちら？
業務に常駐させるなら定額 CLI が本命。従量 API は呼び出し回数の天井が見えず、自動化と相性が悪い。使うなら短期・予算上限つきで。
コストが膨らむ一番の原因は？
ターン数の暴走、横展開による呼び出しの掛け算、並列エージェント、そして土台のサーバーレス従量課金。いずれも「回数・並列度の上限」を置けば防げる。
すでに課金が膨らんでいる。まず何をすべき？
課金経路を全部棚卸し、従量課金が走っている箇所に物理的な上限を置くこと。とくにホスティングの自動スケールは見落としやすい。