この記事は2026年3月時点の情報に基づいている。
Claude Codeを寝てる間に放置する。1日1回だけチェックする。それを2ヶ月やった。
108時間。無人。結果は「想定より50倍多い失敗」だった。
事故リスト(実際に起きたもの全部)
事故1: rm -rf src/
CCが「クリーンな状態にします」と宣言してrm -rf ./src/を実行した。
ゲームプロジェクトのソースコード。2週間分の作業。1回目はgit backupから復元できた。2回目は2時間分が消えた。バックアップの間隔が空いていた。
事故2: APIコスト暴走
サブエージェントがAPIを叩くループに入った。1時間で$8。気づいたのは翌朝。月の予算の4%が1時間で消えた。
事故3: 無限エラーループ
「修正→確認→同じエラー→修正→確認→同じエラー」を20回繰り返した。ログを見て背筋が凍った。CCは毎回「修正しました」と報告していた。嘘ではない。ただ同じ場所を直し続けていただけだった。
事故4: main直push
レビューなし。テストなし。mainブランチに直push。気づいたのは翌日、別のセッションで差分を見たとき。
事故5: コンテキスト消失→同じ作業を最初から
:::details 初心者向け: コンテキスト(context window)とは
AIが一度に「覚えていられる」情報量の上限です。人間で言えば「机の上に広げられる書類の量」に近い。机がいっぱいになると古い書類を片付けないと新しい書類を広げられない。AIも同じで、会話が長くなると古い内容を忘れます。これが「コンテキスト消失」です。
:::
context windowが満杯になると、CCは前の作業を忘れる。文字通り忘れる。そして同じタスクを最初から始める。3時間かけて作ったものを、自分で上書きした。
事故6: 全文消失(Zenn記事2回)
APIで記事を更新するとき、GETで既存データを取得せずにPUTした。本文が空のJSONで上書きされた。公開済みの記事が白紙になった。これが2回起きた。
事故7: Watchdog暴走
アイドル検知のウォッチドッグが、レート制限に達した後も15秒ごとに「RATE_LIMIT」ログを吐き続けた。ログファイルが膨れ上がった。監視するはずのシステムが、監視対象より問題を起こした。
全部「設定の問題」だった
事後に見返すと、パターンがあった。
Claude Codeの初期設定は「人間が横にいる」前提で作られている。人間がいなくなった瞬間、安全装置がない状態になる。
身近な例えで言うと、車のオートパイロットに近い。高速道路(=定型タスク)ではうまく走るが、工事現場や歩行者の飛び出し(=想定外のエラー)には対応できない。ハンドルから手を離すなら、衝突防止センサー(=hook)やレーンキープ(=CLAUDE.mdのルール)を先に付ける必要がある。
rm -rfをブロックするhookがない。エラーループを検知して止める仕組みがない。コンテキストが消えても作業を引き継げるファイルがない。APIのGET→PUT手順を強制するガードがない。
逆に言えば、これらを1つずつ追加していけば、事故は防げる。
最初に入れるべき安全装置3つ
1. 危険コマンドブロック(PreToolUse hook)
:::details 初心者向け: PreToolUseフックとは
Claude Codeがコマンドを実行する「直前」に自動で走るチェック処理です。フック(hook)のスクリプトが「危険だ」と判定すると、コマンドの実行をキャンセルできます。下のJSONを ~/.claude/settings.json に書くだけで有効になります。
:::
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "bash ~/.claude/hooks/branch-guard.sh"
}
]
}
]
}
}
exit 2を返すとCCのツール実行がキャンセルされる。rm -rf、git reset --hard、git push --forceをここで止める。
2. エラーループ検知
同じエラーが3回続いたら別の方法を試すか、pending_for_human.mdに記録して別タスクに移る。これはCLAUDE.mdに書く。
:::details 初心者向け: CLAUDE.mdとは
プロジェクトのルートに置くテキストファイルで、Claude Codeへの「ルールブック」です。ここに書いたルールはClaude Codeが毎回自動的に読み込みます。「エラーは3回まで」「mainにpushするな」といったルールを書いておくと、AIがそれに従って行動します。
:::
エラー対応は最大3回まで自力で調査、修正する。
進展が止まったら pending_for_human.md に記録し、別タスクへ移る。
3. コンテキスト消失対策(mission.md)
compact後に作業状態を引き継ぐファイルを作る。CCが「何をやっていたか」を自分で書き残す。
compact後の継続に備え、必要な作業状態は mission.md に残す。
この3つだけで、事故の7割は防げた。
残りの3割と、その先
残りの3割——APIガード、コスト監視、ウォッチドッグの設計、コードレビューの自動化——は、もう少し複雑になる。
108時間で起きた全事故を分類して、チェックリスト化して、具体的な対処法をまとめた本を書いた。
第0章(はじめに)と第1章(Health Check)は無料で読める。事故リストの全貌と、最初に何をチェックすべきかがわかる。
6月15日の billing 変更との関係
本記事の108時間の無人の運用は、 内部で claude -p または Agent SDK の呼び出しの経路を活用する場合、 2026年6月15日の Anthropic の課金の経路の分割の対象に該当する可能性が高い。
Anthropic の公式の billing 文書で articulate された変更:
claude -p(一回完結の経路) と Claude Agent SDK の呼び出しは、 対話の Claude Code とは別の credit bucket (Pool 2) に route される予定。
Pool 2 への分離は2026年6月15日に実施されます。 自動の作業の経路を業務で運用する利用者は、 6月15日の前に次の3件の確認を推奨:
- 自分の plan の Pool 2 の月額の credit の上限 (Pro: $20、 Max 5x: $100、 Max 20x: $200)
- 自動の起動の頻度 × 1回あたりの平均トークン × 並列の数の見積もり
- 月額の credit の枯渇の経路 (extra usage の有効化の有無の判定)
無料の見積もりの道具:
- June 15 Pool 2 Estimator — 過去30日の使用量から6/15以後の月額の予測
-
June 15 Readiness Audit — 10問で readiness の score (0-100) を取得
詳細な決定の枠組みは Migration Playbook 第2版 (19米ドル、 241頁、 5/22発売) で、 留まる / 切り替える / 混在 の3経路の判定の入力。
関連記事
- Anthropic公式「Skills完全ガイド」を読んだら、自分のSKILL.mdのトークン消費を40%減らせ
- Claude Code Agent Teamsで複数エージェントを並列稼働させる方法
- 寝てる間にAIが仕事を終えていた——テキストファイル1枚で実現する自律型開発
- Claude CodeのPreToolUseフックで危険な操作を自動ブロックする
安全装置なしの自律稼働は、シートベルトなしの高速道路だ。できるけど、やるべきではない。
自分のトークン消費パターンを確認したい方へ
Token Checkupで5つの質問に答えるだけでトークン消費の診断ができる。Hook Selectorで最適なhookセットも分かる。
📖 トークン消費に困っているなら → Claude Codeのトークン消費を半分にする——800時間の運用データから見つけた実践テクニック(¥2,500・はじめに+第1章 無料)
📖 AIで事業を回す実体験を全記録 → Claude Code×個人事業 800時間の全記録(¥800・第2章まで無料)
📖 非エンジニアがClaude Codeで事業を回した全記録(¥800) — $800のAIコストで¥6,000を稼ぐまでの失敗と改善。第2章まで無料
⚠️ CVE-2026-21852(2026年4月公開): プロジェクト内.claude/settings.json経由でAPIキー窃盗。対策: npx cc-safe-setup(ユーザーレベル設定で免疫)→ 詳細
⚠️ Opus 4.7緊急情報(2026年4月17日)
Opus 4.7のauto mode安全分類器がOpus 4.6にハードコードされている問題が発覚。3日間で23件以上のデータ損失。さらにv2.1.100以降、APIコールごとに約20,000トークンが見えない場所で追加課金されている問題も判明(#46917、GitHub上196件のリアクション)(50GB永久消失含む)。4倍のトークン消費も報告されている。対策: npx cc-safe-setup --opus47(Survival Guide / Safety Scanner)
📖 過去の事故の総括 (Postmortems): 本記事の 108 時間の事故の続編で、 4 月から 5 月の運用の事故の総括は Postmortems、 Gumroad、 4,350 円 に納めています (試し読みの Gist - Incident #1: Cache TTL silent regression)。 108 時間の事故は本書の章 3 の中の自律運用の節と直接の補完の関係。
📚 月次の事故事例の継続の更新 (Safety Lab): 5 月以降の事故の継続は Safety Lab、 Ko-fi、 ¥500 / 月 で配信。 月額の購読で、 毎月の事故事例の構造化された解説の段が届きます。
📚 関連商品 (2026 年 5 月 22 日発売): 本記事の「108 時間の事故」 の系統の継続の証拠を整理した Claim-Verify Handbook (Gumroad、 19 米ドル、 130 件の事例 = 本文 15 件 + 付録 D 115 件、 14 件の防衛の手順、 2026 年 5 月 18 日朝の取得) と、 移行の判断の枠組みの第 2 版を組み込んだ Migration Playbook 第 2 版 (Gumroad、 19 米ドル、 第 1 版の購入者は無償の更新)。 本記事の安全装置の話の延長として、 130 件の事例の構造を確認する手引き。
🔎 副の作業者の沈黙の失敗の事例集 (試し読み、 6 月発売予定): 直近 7 日間の anthropics/claude-code の起票の場で 36 件の副の作業者と機能の包と MCP の失敗の様式を発見、 5 系統で整理した 試し読みの Gist (無料、 9,200 字、 JP)。 自律の運用で副の作業者を使う場合の境界の崩壊の予防の合図。 同記事の 108 時間の事故の系統の延長。
この記事の安全装置を「事故が起きた後の復旧」まで広げたい方へ
108 時間の無人運用で私が学んだのは、 事故は 0 にはできないが、 取り返しのつかない事故は 0 にできる、 ということでした。 深夜にファイルを 2 回消した時も、 /rewind の巻き戻しでコードが消えた時も、 アップグレードの後にセッションが空に見えた時も——どれも手元のディスクに作業は残っていて、 取り戻し方を知っていれば戻せました。
その「起きた後にどう取り戻すか」を、 診断 19 点から 85 点までの全工程としてまとめたのが Anthropic 公式ガイドにない事故防止 (Zenn、 ¥800、 第 3 章まで無料) です。 月ごとに新しい事故の章が増え、 一度買えば追加の課金なしで届きます (最新は 2026-06-15 に追加した「アップグレードの後にセッションが空に見える」章)。 まず無料の 3 章で、 自分の現在地を確かめてください。