Cloudflare Containersのスナップショット、既存アプリは作り直しが必要

AIエージェントにコードを書かせて試す作業場や、顧客ごとのビルド環境をCloudflare Containersで動かすと、眠ったコンテナは次の起動時にイメージの状態から始まります（文書の表現では「All disk is ephemeral by default」）。依存パッケージの入れ直しから毎回やり直すことになります。作業途中のファイルを残したまま止めて、あとで同じ状態から再開できれば、待ち時間も無駄な実行時間も減らせます。その手段として、2026年9月30日付のCloudflareの変更履歴で、コンテナのファイルシステムを保存して戻すスナップショットのAPIが公開ベータになりました。

ところが、このスナップショットは今あるContainersアプリに設定を1行足せば使える機能ではありません。同じ日に公開ベータになった durable_object というスケジューリングポリシー（コンテナのイメージと大きさをどこで決めるかの方式）のアプリでしか使えず、そのポリシーは既存アプリでは変更できないためです。

本記事では、公式ドキュメントと変更履歴の原稿を確認し、wrangler 4.151.2 で新しいポリシーの設定と型を確かめました。既存アプリを移すかを決める開発責任者向けに、条件・上限・移行の手間を整理します。

スナップショットは新しいポリシーのアプリだけ

スナップショットのガイドには、次の注意書きがあります。

Snapshots are only supported by Container applications that use the durable_object scheduling policy. Applications that use the default scheduling policy cannot create or restore snapshots.

scheduling_policy を書いていない既存のContainersアプリは、すべて default ポリシーです。2つのポリシーの違いを、スケジューリングポリシーの文書から抜き出すと次のようになります。

項目	`default`	`durable_object`（公開ベータ）
イメージと大きさの指定	Wranglerの設定で、アプリ全体に1つ	コードの `ctx.container.start()` で、起動ごとに選ぶ
イメージの更新	Cloudflareがロールアウトで全体に適用	起動中のコンテナは元のイメージのまま。止めて起動し直すかはコードが決める
`max_instances`	使える	使えない（アカウントの上限に数えられる）
スナップショット	使えない	使える
想定する用途（文書の記載）	同じイメージ・大きさで動かすサービス	サンドボックス、エージェントの環境など

durable_object ポリシー専用に、Cloudflareが管理する cloudflare/debian-trixie イメージ（Debian Trixie slim上のNode.js 24.20.0）も用意され、登録なしで起動できます。

利用にはWorkers Paidプラン（月額5米ドル）が必要で、料金の文書ではFreeプランは「N/A」です。課金は稼働中の10ミリ秒単位です。スナップショットの保存自体の料金は、料金の文書に記載が見当たりませんでした（2026年10月20日時点）。同じ日の発表のブログ記事は、新しいポリシーで起動が6倍以上速くなったとしています。根拠として、第三者（ComputeSDK）のベンチマークで100個を同時に起動したときの中央値が4.049秒から648ミリ秒になった結果を載せています。編集部は起動時間を測っていません。

保存されるのはファイルだけ

スナップショットで何が戻るかは、Durable Object Container APIの文書に書かれています。snapshotContainer() が保存するのは「writable root filesystem」（書き込めるルートのファイルシステム）で、メモリ、実行中のプロセス、別にマウントしたファイルシステムは含みません。スナップショットから起動したコンテナは、エントリーポイントを最初から実行し直します。

Cloudflare Containersのスナップショットに含まれるもの・含まれないものと条件の図。含まれるのは書き込めるルートのファイルシステム。メモリ、実行中のプロセス、別にマウントしたファイルシステムは含まれず、起動時にエントリーポイントを実行し直す。条件はdurable_objectポリシー、作成時と同じイメージ、最大20GB、作成か最後の復元から30日

エージェントの作業を再開するには、ファイル以外の状態（起動していた開発サーバーなど）をアプリ側で立ち上げ直す処理が要ります。ほかに文書で確認できた条件は次のとおりです。

同じイメージでしか戻せない: スナップショットは作成元のイメージの版に結び付き、別のイメージには持ち込めません。イメージを更新したら、新しいイメージで動くコンテナから取り直します
上限と保持期間: 1つのスナップショットは最大20GB。作成か最後の復元から30日で消え、復元するたびに30日が延びます。保持期間は今のところ変えられません
一覧を取るAPIがない: Workerから使えるAPIには一覧の取得がありません。返された id を、Durable Objectのストレージなどに自分で保存しておきます
変更できない: スナップショットは不変で、復元後の変更を残すには取り直します
動いているときだけ取れる: 止まっているコンテナで呼ぶとエラーになります

手元で設定と型を確かめた

ここからは編集部の検証環境（Linux、Node.js v22.22.0、wrangler 4.151.2、@cloudflare/workers-types 5.20261019.1、TypeScript 5.9.3）で確かめた結果です。Cloudflareのアカウントへのデプロイはしていないため、スナップショットを実際に取って戻す動作は確認していません。

まず、durable_object ポリシーのコンテナを1つだけ定義した設定で wrangler deploy --dry-run を実行すると、「AgentComputer (durable_object)」と表示されて正常に終わりました。そこに default ポリシーで使っていた項目を足すと、設定の検査で止まります。

✘ [ERROR] Processing b.jsonc configuration:
    - Unsupported fields for Durable Object-managed Containers in containers: "max_instances". Only "name", "class_name", "scheduling_policy", "images", "observability", "ssh", "authorized_keys", and restricted "unsafe" settings are supported.

instance_type を足しても同じ形のエラーでした。名前付きイメージにDocker Hubの docker.io/library/node:24-slim を書くと、Cloudflareの管理レジストリのダイジェスト固定の参照（registry.cloudflare.com/…@sha256:…）にするよう求められました。

次に、保存と復元を書いたDurable Objectを tsc --strict で型検査しました。

import { DurableObject } from "cloudflare:workers";

export class AgentComputer extends DurableObject {
  // 型の上では ctx.container は省略可能（Container | undefined）
  private get c(): Container {
    const c = this.ctx.container;
    if (!c) throw new Error("no container attached");
    return c;
  }

  async save(): Promise<void> {
    const snap = await this.c.snapshotContainer({ name: "after-install" });
    await this.ctx.storage.put("snap", snap); // 一覧APIがないので id を自分で保存する
  }

  async resume(): Promise<void> {
    const snap = await this.ctx.storage.get<ContainerSnapshot>("snap");
    if (snap) {
      this.c.start({ containerSnapshot: snap, enableInternet: false, instance: "standard-2" });
      return;
    }
    this.c.start({ image: "cloudflare/debian-trixie", instance: "standard-2", enableInternet: false });
  }
}

このコードは型検査を通りました。image と containerSnapshot を同時に渡すと型エラーになり、文書の「同時に指定できない」と一致しました。公式の例は this.ctx.container をそのまま使っていますが、strictな型検査では省略可能な型のため、存在を確かめる一手間が必要でした。

文書と型の定義で食い違う点も2つありました。型の上では snapshotContainer() の引数は省略できますが、文書には「throws a TypeError when options is omitted」とあり、名前を付けないときも {} を渡すよう書かれています。また、型は instance に "basic" を許しますが、スケジューリングポリシーの文書は実行時に basic を受け付けないとしています。どちらも型検査では見つからないため、文書の記載に合わせて書いておくのが安全です。

既存アプリを移すかの判断（編集部の提案）

移行の手順は、公式の移行ガイドにまとまっています。要点は「ポリシーは作成後に変えられない」「新しいDurable Objectのクラスと名前空間で別のアプリを作り、トラフィックを切り替える」の2つです。ガイドは、既存のコンテナもDurable Objectのストレージも引き継がれないと明記しています。default ポリシーではスナップショットを取れないため、ファイルをスナップショットで運ぶこともできません。

@cloudflare/containers の Container クラスは durable_object ポリシーに対応していないため、継承しているアプリは、ポートの待ち合わせやリクエストの転送などの処理を ctx.container で書き直します。既存の設定の scheduling_policy だけを書き換えてデプロイすると、新しいWorkerが公開された後に失敗する、という注意もガイドにあります。

なお、発表のブログ記事は、Container クラスと従来のSandboxクラスの保守を2026年12月31日までとしています。それ以降も既存のデプロイは動きますが、クラスは更新されません。新しいポリシーやスナップショットは ctx.container からしか使えず、ブログは ctx.container への移行を勧めています。

以上から、編集部は次のように整理しました。

スナップショットが要らない常駐サービスは、今は移さない: 同じイメージで動くAPIは default のロールアウトや max_instances が使え、durable_object は公開ベータです。ファイルを残すだけなら、文書が紹介するFUSEでR2などに置く方法もあります。ただし Container クラスを継承している場合は、上記の保守期限があります。公式の「Migrate from the Container class to the Durable Object Container API」ガイドには、Durable Objectのクラス名やバインディングを変えずに ctx.container へ書き換える手順があるため、ポリシーの移行とは分けて計画できます
エージェントの作業場や利用者ごとの環境を新しく作るなら、最初から durable_object で作る: 後から移すと名前空間とデータの移し替えが発生します
移す場合は、利用者（サンドボックス）単位で切り替える: ガイドの例のように、どの名前空間を使っているかを記録して振り分けます。リクエストごとに振り分けると、同じサンドボックスのコンテナが2つ動いて状態が分かれる恐れがあるとガイドは注意しています

エージェントの実行環境の選び方はCloudflare Sandboxesの記事、状態をGit互換のストレージに置く方法はCloudflare Artifactsの記事、デプロイを戻す操作の注意はwrangler rollbackの記事で整理しています。

まとめ：まず確かめること

まずは、自社のContainersアプリの設定に scheduling_policy: "durable_object" があるかを確認してください。なければ、スナップショットを使うには新しいアプリを作ることになります。そのうえで、戻したいのがファイルだけで足りるのか、プロセスの状態まで要るのかを書き出すと、移す価値を判断できます。

2026年10月20日に、cloudflare/cloudflare-docs（production）の変更履歴の原稿2件（2026-09-30）とContainersの文書（スナップショット、スケジューリングポリシー、Durable Object Container API、上限、料金、イメージ管理、移行ガイド）、wrangler の CHANGELOG を確認し、公開前に developers.cloudflare.com の各ページと発表のブログ記事（2026-09-30）で記載を照合しました（資料調査）。編集部の検証環境（Linux、Node.js v22.22.0）で、wrangler 4.151.2 の deploy --dry-run による設定の検査と、@cloudflare/workers-types 5.20261019.1 での型検査を行いました（実機検証）。Cloudflareへのデプロイ、スナップショットの作成・復元、起動時間、スナップショットの保存料金は確認していません。

Cloudflare上でのAIエージェントの実行環境づくりや、既存のコンテナ構成の見直しは、グリームハブの開発・AI・自動化のご相談で承っています。使い方や移行の範囲によって進め方が変わるため、お問い合わせからご相談ください。

記事を検索

Cloudflare Containersのスナップショット、既存アプリは作り直しが必要

スナップショットは新しいポリシーのアプリだけ

保存されるのはファイルだけ

手元で設定と型を確かめた

既存アプリを移すかの判断（編集部の提案）

まとめ：まず確かめること

参考資料

自社での進め方を、具体的に。

Cloudflare Containersのスナップショット、既存アプリは作り直しが必要

スナップショットは新しいポリシーのアプリだけ

保存されるのはファイルだけ

手元で設定と型を確かめた

既存アプリを移すかの判断（編集部の提案）

まとめ：まず確かめること

参考資料

次に読むなら

100万個のサンドボックスの話から、AIの実行環境の線を引く

Docker Cloud Sandboxesの隔離・権限・料金

DB更新と出荷依頼を同時に確定 Spanner queues

AIエージェントに本番DBを読ませる — AlloyDB新プレビュー

社内MCPサーバーの入口を1つに — MCP server portals

Cloudflareの新CLI「cf」ベータ、Wranglerからどこまで移すか

エージェントは待っている時間が長い — AXが置き直した前提

社内AIにゲートウェイを1枚挟むか — APIキーが増える前に

自社での進め方を、具体的に。