はじめに — 「デプロイしたら壊れた」にどう備えるか
Cloudflareのサーバーレスエッジコンピューティング基盤を本番環境として運用していると、いつか必ず「デプロイしたらサービスが壊れた」「データベースの更新で想定外の影響が出た」という状況に直面します。
重要なのは、問題が起きないようにすることではなく、問題が起きたときに迅速に復旧できることです。SRE（Site Reliability Engineering）の基本原則では、100%の可用性は目指しません。代わりに、エラーバジェット（許容される障害の範囲）を定義し、その範囲内で変更速度と信頼性のバランスを取ります。
本記事では、Cloudflareの主要サービスそれぞれについて、バックアップの取得方法、障害時のロールバック手順、復旧時間の目安を解説します。この知識は、AIツールの承認ゼロ運用においても「問題が起きても元に戻せる」という安全保証の基盤になります。関連する設計思想はClaude Codeの承認プロンプトをゼロにする、セキュリティリスクの評価はAIコーディングツールの承認ゼロ運用を支えるセキュリティ設計で解説しています。
Cloudflare Workers — 100バージョンのロールバック
Cloudflare Workersは、デプロイのたびにバージョンを自動的に保存し、直近100バージョンまで保持します（2025年9月に10から100に拡大）。問題のあるデプロイを検知したら、即座に以前のバージョンに戻すことができます。
ロールバック手順
まず、デプロイ履歴を確認します。
wrangler deployments list
このコマンドは直近10件のデプロイを表示します。各デプロイにはバージョンIDが付与されており、このIDを指定してロールバックを実行します。
wrangler rollback [VERSION_ID] --message="障害対応: v1.2.3にロールバック"
ロールバックは数秒で完了し、即座にグローバルに反映されます。
注意点
Workersのロールバックはコードのみを対象とし、KV、D1、Durable Objectsなどの状態（ステート）はロールバックされません。つまり、データベースのスキーマ変更とコード変更を同時にデプロイした場合、コードだけを戻してもデータベースは変更後の状態のままです。この不整合に注意が必要です。
また、ロールバック先のバージョンと現在のバージョンの間でDurable Object Migrationsが実行されている場合、ロールバックは失敗します。
D1データベース — Time Travelによるポイントインタイムリカバリ
Cloudflare D1は、Time Travelと呼ばれるポイントインタイムリカバリ機能を提供しています。有料プランでは過去30日間、無料プランでは過去7日間の任意の時点にデータベースを復元できます。
復元手順
特定の時点にデータベースを復元するには、タイムスタンプを指定します。
wrangler d1 time-travel restore my-database --timestamp="2026-03-20T10:30:00Z"
Unix タイムスタンプでの指定も可能です。
wrangler d1 time-travel restore my-database --timestamp=1711108200
復元前に、その時点のデータベース状態を確認することもできます。
wrangler d1 time-travel info my-database --timestamp="2026-03-20T10:30:00Z"
SQLエクスポートによる手動バックアップ
Time Travelに加えて、SQLファイルへのエクスポートも可能です。
wrangler d1 export my-database --remote --output=backup-20260320.sql
特定のテーブルのみ、スキーマのみ、データのみのエクスポートも指定できます。
wrangler d1 export my-database --remote --table=users --output=users-backup.sql
wrangler d1 export my-database --remote --no-data --output=schema-only.sql
wrangler d1 export my-database --remote --no-schema --output=data-only.sql
エクスポートしたSQLファイルからの復元は以下のコマンドで実行します。
wrangler d1 execute my-database --remote --file=backup-20260320.sql
注意点
Time Travelによる復元は破壊的操作であり、データベースの現在の状態を指定時点の状態で上書きします。復元前に現在の状態をエクスポートしておくことを推奨します。また、エクスポート中はデータベースへの読み書きがブロックされます。
Cloudflare Pages — 無制限のデプロイ履歴
Cloudflare Pagesは、すべてのデプロイ履歴を保持しており、任意のデプロイにロールバックできます。ダッシュボードからの操作とAPIからの操作の両方に対応しています。
ダッシュボードからのロールバック
Cloudflareダッシュボード → Pages → プロジェクト選択 → Deployments → 対象のデプロイ → 三点メニュー → 「Rollback to this deployment」を選択します。
APIからのロールバック
curl -X POST "https://api.cloudflare.com/client/v4/accounts/{account_id}/pages/projects/{project_name}/deployments/{deployment_id}/rollback" \
-H "Authorization: Bearer {api_token}"
ロールバックは成功した本番ビルドのみが対象であり、プレビューデプロイは対象外です。復旧は即座に反映されます。
R2オブジェクトストレージ — バージョニング未対応への対策
R2は2026年3月現在、オブジェクトバージョニングをサポートしていません。削除したオブジェクトの復元機能もないため、誤ってオブジェクトを削除した場合は復旧できません。
この制約への対策としては、別バケットへの定期バックアップが最も現実的です。Workersのスケジュールトリガーを使い、重要なオブジェクトを定期的にバックアップ用バケットにコピーする仕組みを構築できます。
Object Lifecycle Managementを活用して、オブジェクトの有効期限ルールを設定することも可能ですが、これはバージョニングの代替にはなりません。
KV — 運用上の位置づけを理解する
Cloudflare KVはバージョニングやバックアップ機能を持ちません。Workers のバージョンロールバック時にもKVの状態は変化しません。
KVは設計上、キャッシュライクな一時データに適したストレージです。セッションデータ、一時的な設定値、キャッシュなど、消失しても再生成可能なデータの格納に使用すべきです。永続化が必要なデータはD1に格納し、Time Travelによる復旧保証を得ることを推奨します。
復旧時間の目安（RTO）
各サービスの障害復旧にかかる時間の目安を以下にまとめます。
Workers のコードロールバックは、wrangler rollback コマンドの実行から数秒で完了します。グローバルへの反映もほぼ即座です。本番環境でデプロイ後に問題を検知した場合、最も迅速に復旧できる手段です。
Pagesのデプロイロールバックも同様に即座に完了します。ダッシュボードからの操作でもAPI経由でも、数秒でロールバックが反映されます。
D1のTime Travel復元は、データベースのサイズに応じて数秒から数分かかります。小規模なデータベース（数十MB以下）であれば数秒で完了しますが、大規模なデータベースでは数分を要する場合があります。
D1のSQLファイルからの復元は、ファイルサイズとSQL文の数に応じて5-15分程度かかります。復元中はデータベースへのアクセスがブロックされるため、メンテナンスウィンドウの設定を推奨します。
Gitリポジトリの復旧は、git reflog によるコミット特定と git reset による復元で5分以内に完了します。reflogは90日間保持されます。
定期バックアップの設計
本番環境の信頼性を高めるために、以下の定期バックアップ運用を推奨します。
日次バックアップとして、D1データベースの全テーブルをSQLファイルにエクスポートし、ローカルストレージまたはバックアップ用R2バケットに保存します。
デプロイ前バックアップとして、マイグレーションやスキーマ変更を含むデプロイの前に、現在のデータベース状態をエクスポートします。Time Travelがあるとはいえ、明示的なバックアップは復旧の確実性を高めます。
Git リモートの常時同期として、ローカルの変更は定期的にリモートリポジトリにプッシュします。ローカル環境の障害時にもコードを保全できます。
Cloudflareのインフラ基盤についてはCloudflare無料プランでここまでできるで概要を解説しています。Workersの基礎知識はCloudflare Workers完全入門ガイドも参考になります。また、Cloudflare Workers + Email Routing + Brevoで実現するメール送受信基盤も、同じCloudflare基盤上でのインフラ運用事例として参考にしてください。