Claude Code 安全運用研修／モジュール 6（公開版）

モジュール 6: 事故対応と復旧

事故は起きる前提で備える。報告と復旧の手順、checkpoint、PITR、そして復旧が不能になる条件を学びます。

このモジュールの到達目標。 事故が起きた時に、誰に・どう報告し・どう戻すかの手順を自社の運用に組み込める。checkpoint と file backup で復旧の備えを作り、復旧が不能になる条件を理解して、事前に塞げる。

これは研修の公開のモジュールです。そのまま読んで手を動かせます。モジュール 1〜モジュール 5に続く、研修の最後の実技のモジュールです（全体の構成はカリキュラム）。

1. 予防と復旧は別の備え

モジュール 1〜5 は予防（事故を起こさない層）でした。このモジュールは復旧（事故が起きた後の損失を最小化する層）です。予防の層をすり抜けた操作や、予防の対象外の事故は必ず起こりえます。だから、起きる前提で復旧の備えを作ります。

復旧で大事なのは2つです。第一に、事前の備え（checkpoint や backup が無ければ戻せません）。第二に、復旧が不能になる条件を知ること（バックアップの無いデータベースは、消えたら戻りません）。

2. 実際の事故を読む

抽象論ではなく、番号で辿れる実際の報告で学びます。

worktree の自動の片付けが、10日分の未コミットの作業を消した（#46444）

何が起きたか: worktree の自動の片付けが、警告なしで10日分の未コミットの作業を永久に削除した。
なぜ起きたか: 未コミットの作業は git の履歴に無いため、片付けで消えると戻せない。
何が止めた／戻せたはずか: 編集ごとの自動の checkpoint（auto-checkpoint）と、編集の前の backup（file-edit-backup）。こまめに履歴に残っていれば復旧できる。

文脈の圧縮で、git 管理下のファイルの編集が黙って巻き戻った（#34674）

何が起きたか: context の compaction の際に、git 管理下のファイルの編集が黙って巻き戻った。
何が戻せたはずか: 編集ごとに checkpoint の commit を作る auto-checkpoint。git log と git cherry-pick で戻せる。

本番のデータベースが消え、バックアップが無く戻せなかった（#27063）

何が起きたか: 破壊的なコマンドで本番のデータベースが消え、バックアップが無かったため復旧が不能だった。
なぜ戻せなかったか: データベースには git のような履歴が無い。バックアップと時点の復旧（PITR）が事前に無ければ、消えたデータは戻らない。

3. 演習: 復旧の備えを作り、戻し方を確認する

実際に復旧の備えを入れ、戻せることを確認します。所要およそ15分。

手順 1. 復旧の備えの hook を入れる

cc-safe-setup（無料・MIT）が、編集の前の backup と編集ごとの checkpoint の hook を入れます。

npx cc-safe-setup

これで file-edit-backup（編集の前にファイルを ~/.claude/file-backups/ へ退避）と auto-checkpoint（編集ごとに軽量の checkpoint の commit）を含む hook が入ります。

手順 2. 編集の前に backup が作られることを実機で確認する

file-edit-backup は、ファイルが上書きされる前に、時刻つきの backup を退避します。次のように確かめます。

# 重要なファイルへの編集の直前に backup が作られる
echo '{"tool_name":"Write","tool_input":{"file_path":"'"$HOME"'/important.txt"}}' \
  | ~/.claude/hooks/file-edit-backup.sh

# 退避された backup を確認する（時刻つきで残る）
ls ~/.claude/file-backups/

退避された backup（元のファイル名に時刻が付いたもの）が一覧に出れば、編集の前の備えが効いています。上書きで失っても、ここから前の版を戻せます。

手順 3. 戻し方を確認する

事故の種類ごとに、戻し方が違います。

ファイルの上書き: ~/.claude/file-backups/ の時刻つきの backup から戻す。
編集の巻き戻りや消失: git reflog で直前の状態を探し、git checkout や git cherry-pick で戻す（auto-checkpoint の commit が残っていれば確実）。
worktree の作業の消失: git reflog と git fsck --lost-found で、片付けで失った commit を探す（コミット済みなら多くは戻せる、未コミットは戻せないことがある）。
データベースの破壊: バックアップと時点の復旧（PITR）から戻す。バックアップが無ければ戻りません（#27063）。

正直な限界。 復旧は、事前の備えがあって初めて可能です。未コミットの作業、バックアップの無いデータベース、退避の前に消えたファイルは、戻せないことがあります。だから、最良の事故対応は予防（モジュール 1〜5）であり、復旧はその次の防衛線です。

4. 連絡と運用への組み込み

誰に・どう報告するかを事前に決める（事故の連絡の経路、影響範囲の確認、止血の担当）。事故の時に手順を探さない。
本番のデータベースに、バックアップと時点の復旧（PITR）があるかを事前に確認する（無いと #27063 のように戻せない）。
auto-checkpoint と file-edit-backup を全員の baseline に入れる（モジュール 5 の配布の仕組みで強制する）。
事故が起きたら、原因を tasks/lessons.md のような記録に残し、検知可能なルール（hook）に変換する。「気をつける」は対策にならない。

研修の全体のまとめ

これで実技の6モジュールが揃いました。削除とデータ破壊（1）、機密と認証情報（2）、費用と利用枠（3）、サブエージェントと auto モード（4）、組織の baseline と CI（5）、事故対応と復旧（本モジュール）。研修の全体（約12時間）では、これらを自社の技術スタックと運用に合わせて、手を動かしながら学びます。

研修のカリキュラム全体を見る法人での実施・費用の相談

本モジュールは公開版です。引用した事故はすべて番号で辿れる実際の報告で、演習で使う hook はすべて cc-safe-setup（無料・MIT）に実在します。file-edit-backup が編集の前に backup を作ることは作者が実機で検証しています。復旧が常に可能だとは書いていません。個人での利用は無料のままです。