本番 Firestore の誤削除対策 — 防ぐ設定と、起きた後の復旧手順

事前対策チェックリスト(優先度順)

1. PITR(ポイントインタイムリカバリ)を今すぐ有効化する — 過去7日の任意時点に戻れる公式機能。事故の後からは有効化できないので、 読み終わったらすぐ設定してください(Google Cloud コンソール → Firestore → 設定)
2. IAM を最小権限にする — 日常的にデータを見るだけのメンバーには roles/datastore.viewer(読み取り専用)を。編集権限(datastore.user 以上)は本当に書く人だけに
3. 本番と開発でGoogleアカウント(またはプロジェクト)を分ける — 「開発のつもりで本番を開いていた」が事故原因の定番です
4. 定期バックアップを自動化する — gcloud firestore export を Cloud Scheduler で日次実行(バックアップ方法まとめ参照)
5. 手動オペレーション用のツールにガードを入れる — 後述
6. 削除ではなく論理削除(deletedAt)をアプリの設計に入れる
7. 操作ログを残す — 「誰が・いつ・何を消したか」が追えないと、 復旧範囲の特定に時間がかかります

「手動オペレーション」こそ最大のリスク

アプリからの書き込みはコードレビューとテストで守られますが、人間がコンソールや GUI で直接触る瞬間には何の守りもありません。 筆者が開発している Firescope(Firestore GUI クライアント)は、 この瞬間を守るために作られています。

• すべての書き込みが「確認 → 自動バックアップ → 実行 → 操作ログ」のパイプラインを強制通過(バイパス経路なし)
• 接続に「本番」ラベルを付けると、破壊的操作にはプロジェクトIDのタイプ入力が必須に(AWS のリソース削除方式)
• 閲覧だけのメンバーには読み取り専用モードの接続を配布
• 誤削除しても、直前の自動スナップショットから差分を見ながらワンクリック復元

事故が起きた直後にやること(復旧手順)

1. 書き込みを止める — 影響範囲が広がる前に、関連するバッチ・Functions を一時停止
2. PITR が有効なら — 削除直前の時点を指定して読み取り、失われたドキュメントを 書き戻す(7日以内)
3. gcloud のバックアップがあるなら — 別プロジェクト(または別コレクション)に import して、そこから必要なドキュメントだけ書き戻す。本番へ直接 import すると現在のデータが上書きされるので注意
4. GUI ツールのスナップショットがあるなら — Firescope の場合は操作ログから該当操作を開き、その時点のバックアップから復元
5. 何もない場合 — アプリのログ・BigQuery エクスポート・クライアント側キャッシュ など、データの断片が残っている場所を洗い出して手動復旧(最も高くつくパターンです)

まとめ

対策の本質は「人間の注意力に頼る箇所を減らす」ことです。 PITR と定期バックアップで「戻れる状態」を作り、IAM と読み取り専用で「消せる人」を減らし、 手動オペレーションにはガードとスナップショットのあるツールを使う。 この3層が揃うと、誤削除は「ヒヤリ」で済む事象になります。