データの事故
コードの失敗は履歴から戻せます。データの失敗も復元機能があれば戻せますが、戻せる期間と単位には条件があります。この違いを知っていると、慎重になるべき場面が「コードを変える時」ではなく「本番のデータに触れる時」だと分かります。
コードは履歴、データは復元条件を確認する
コードはバージョン管理によって履歴が残り、記録した時点まで戻せます。データベースは製品によって復元の仕組みが異なります。弊社の標準であるCloudflare D1にはTime Travelがあり、保持期間内なら任意の時点へ戻せます。ただし、期間を過ぎた状態には戻せず、復元はデータベース全体を上書きします。「戻せる」と「気軽に触ってよい」は同じではありません。
だから、コードの変更はClaudeに大胆に任せられますが、本番のデータに触れる操作だけは別の扱いをします（Claudeへの権限）。
事故の型
- 条件の抜けた削除・更新。「テストデータを消して」が、条件の書き間違いで全件に及ぶ
- migration（データベース構造の変更手順。構造の観点）による項目の削除や型の変更。構造の変更は、中のデータごと消すことがある
- 開発用の初期化スクリプトが本番へ向く。「データベースをリセットして」は、接続先が本番なら本番が消える
- 自動テストが本番のデータベースへ接続したまま実行される
共通するのは、操作そのものは日常的で、接続先だけが想定と違うという形です。操作を怖がるより、接続先を確かめる方が的を射ています。
開発から本番のデータベースへ接続しない
弊社では、開発中の環境に本番データベースの接続情報を置きません。環境ごとに接続先を分け（環境の分離）、開発では開発用のデータベースだけに繋ぎます。接続情報がなければ、どんな操作の間違いも本番には届きません。「気をつける」より「届かなくする」を選んでいます。
この環境がどのデータベースに接続しているか確認して。本番に繋がるものがあれば教えて
バックアップは、戻せてはじめて成立する
バックアップは、取ることではなく戻せることに意味があります。復元の手順を一度も試していなければ、事故の当日に初めて試すことになります。何日前まで戻せるか、どの範囲が一緒に巻き戻るかを、利用中のサービスと契約で確認します。Cloudflare D1の場合はTime Travelの公式資料を参照し、事故後の別の変更まで失われないかも確認します。復旧条件と手順の確認先はCLAUDE.mdに残す前提に含めます。
このmigrationを本番に適用する前に、バックアップの状態と、失敗した時に戻す手順を確認して