あるClaudeユーザーが、/loop コマンド1つで一晩のうちに約6,000ドル分の利用枠を溶かした体験談をRedditに投稿した。原因は「PRをチェックして」という30分おきのループを夜のあいだ放置したことだという。本記事ではその投稿に書かれている事実関係を整理し、なぜそこまで課金額が膨らんだのか、そして読者が同じ事故を避けるために原文から導ける対策のみを抜き出して紹介する。元記事はRedditのr/ClaudeAIに投稿されたもので、コミュニティの反応も踏まえつつ要点だけを取り扱う。
何が起きたのか
投稿者は前夜、自分の開いているPRを30分おきに確認させる /loop コマンドをClaude（claude-opus-4-7）にセットし、そのまま忘れて就寝。翌朝、Anthropicから「Claude usage limitを使い切った」というメールが届いて初めて異変に気付いたとされる。原文では次のように記述されている。
It ran 46 times over 26 hours, unattended, overnight, on claude-opus-4-7. Two sessions — the loop and a long analytics session I had left open — together burned through roughly $6,000 before I woke up.
26時間のあいだに46回ループが走り、放置されていたこのループと、別に開きっぱなしだった「long analytics session」の2つを合わせて、起床時には約6,000ドル相当の利用が積み上がっていたと書かれている。投稿者によれば、Anthropicのダッシュボードはレポーティングに数日のラグがあるため、上限メールが届くまで気付くことができなかったという。後日のEditでは、loopは単一セッションではなくローカルとVM上の複数セッションで並行稼働していたことも補足されている。
なぜ起きたか／何が問題か
原文の説明によれば、Claude APIは毎回の呼び出しで「会話履歴の全体」をリクエストに乗せる。Turn 1では数百トークンで済む内容も、Turn 46では約80万トークンまで膨らむ。コンテキストウィンドウはあくまで上限であって、毎ターン送られたぶんは毎ターン課金される、という整理だ。
これを安くする仕組みが prompt caching で、直近に送った履歴は12.5×の割引で再利用される。ただし投稿者によれば、キャッシュエントリは約5分の非アクティブで失効する。原文には「以前は1時間だった」との注記もあるが、現時点の正確な仕様はAnthropic公式の記載が一次情報になる点には留保しておきたい。ここに /loop 30m が噛み合うと最悪のパターンになる、と投稿者は説明する。
Loop fires → history gets cached → 30 minutes pass → cache expires. Loop fires again → cache is gone → must re-cache the entire conversation from scratch at the expensive write rate.
ループ間隔（30分）がキャッシュ寿命（約5分）を超えてしまうため、毎回キャッシュは死んでいる。そのうえで反復ごとに自身の出力も会話に積み重なるので、次の再キャッシュ対象はさらに大きくなる。投稿者の例では、20時間経過時点で会話は約80万トークンに達しており、各反復は「80万トークンを書き込みレートで再キャッシュする」コストを払っていた。実際のPR確認応答そのものは、これに比べれば誤差レベルだったという。
なお投稿者は本来 hooks を使うべきだったと認めつつ、勤務先がセキュリティ上の理由で外部MCPをブロックしているため取りにくい選択肢だったとEditで補足している。トップコメントが指摘する「LLMにインフラをやらせるな、cronやWebhookやGitHub ActionsでLLMを呼べ」という主旨も、この後悔と同じ方向を向いている。
読者がどう守るか
原文に書かれている対策だけを並べる。元記事に存在しないフラグやコマンドはここでは追加しない。
- /loop には停止条件をつける。 原文では例として「
/loop 30m check my PRs — stop when all are merged or after 3 hour」のように、条件を満たしたらClaude自身がループを終わらせる書き方が紹介されている。 - 無人で走らせるタスクは Opus ではなく Sonnet。 原文では Opus は出力トークン単価でおよそ5倍高いとされ、PRポーリング程度のタスクは Sonnet で十分とされている。
- ダッシュボードをリアルタイム予算計として信用しない。 投稿者によれば Anthropic のダッシュボードは数日ラグがあり、急増が見えた頃にはすでに支出済みで、限度額到達メールが唯一のリアルタイム信号になり得ると書かれている。
- 長寿命セッションは「キャッシュで安くなる」とは限らない。 5分以上の隙間がある自動呼び出しでは、生かし続けたセッションほど「成長し続ける履歴全体」を毎回再キャッシュする側に回る。原文では「新しいセッションを起こす方が安いことが多い」とまとめられている。
- max_turns はループの回数制限ではない。 原文によれば max_turns は1反復内のツールコール連鎖をキャップするものであり、ループの起動回数には影響しない。
/loopに対する組み込みの期限は7日後の自動削除のみと書かれている。 - loop はメイン会話の中で動く点に注意。 同じセッションを使い続けたまま loop を開始すると、ループ実行ごとに必要以上のキャッシュ読み書きが乗ると指摘されている。
投稿者自身がEditで「bashスクリプト経由でClaudeを叩く」案を真剣に検討すると述べている点も併せて押さえておきたい。コメント側では「Anthropicアカウント設定でハードな支出上限を設定せよ」という助言も挙がっているが、設定画面の挙動・項目名は元記事に明示されていないため、ここでは事実として書ける範囲に留める。
まとめ
- 長時間放置の
/loopは、ループ間隔・成長する履歴・キャッシュ失効が掛け算になり、想定外の課金を生み得る。 - 本記事の数字（46回・26時間・約6,000ドル・約80万トークン）はあくまで投稿者の自己申告であり、Anthropic公式の内訳ではない点には留意する。
- 守りの基本は「停止条件をつける」「無人タスクはSonnet」「新セッションで起こす」「ダッシュボードに頼り切らない」の4点に集約される。
実装家視点で言うと、この事故の本質は「LLMをインフラそのものとして動かしてしまった」ことに尽きる。30分おきにPRを見るだけならcronやGitHub Actionsで状態を取り、変化があったときだけClaudeに判断を投げる形に切り分けるのが筋で、原文のEditでも本人がその方向へ歩み寄っている。便利な /loop ほど、停止条件と「課金時計が動いている」という自覚を一緒に渡しておきたい。
元記事: https://www.reddit.com/r/ClaudeAI/comments/1t11mmy/i_accidentally_burned_6000_of_claude_usage/
コメント