2026年10月1日時点で、Cloudflare Containersは、2026年9月30日（米国時間）の発表によりAIエージェントのサンドボックス向けに作り直されています。新しいスケジューリングポリシー「durable_object」（公開ベータ）では、サンドボックスごとのイメージとインスタンスの種類をコードが起動の時に選べるようになり、起動にかかる時間はComputeSDKの独立したベンチマークの中央値で4.049秒から648ミリ秒（6.2倍）に縮みました。同時にファイルシステムのスナップショットが公開ベータになり、Durable ObjectからContainerを直接操作するctx.container APIに新機能が集まり、その上で使う道具の集まりとしてSandbox SDK 1.0が出ています。使うにはWorkers Paidプラン（月5ドル＝約750円）が必要です。
この記事の要点（2026年10月1日時点）
- 新しいスケジューリングポリシー「durable_object」は公開ベータです。イメージとインスタンスの種類は、デプロイ時の設定ではなく
ctx.container.start()の引数で決めます - ComputeSDKのベンチマーク（100個のサンドボックスを同時に起動）で、起動の中央値は648ミリ秒、95パーセンタイルは910ミリ秒でした。以前の経路と比べて5.9〜6.4倍です
- スナップショットが保存するのはファイルシステムだけで、メモリと動いているプロセスは残りません。作成か最後の復元から30日後に期限が切れます
- Sandbox SDK 1.0は基底クラスではなく道具の集まりです。Container classと旧Sandbox classの保守は2026年12月31日までです
- 新しいポリシーでは、置き場所の地域を絞る設定（placement constraints）が使えません
対象読者：AIエージェントにコードを実行させる環境を作る開発者・PM。読み終えたらできること：今回の刷新で何が変わったかを説明でき、サンドボックスを作る最小のコードと、料金・制限・移行の注意点を確かめられます。
この記事は、Cloudflareの公式ブログ「Cloudflare Containers, rebuilt to scale agent sandboxes」（2026年9月30日）と、ContainersとSandboxの開発者向けドキュメント（多くのページが同じ9月30日に更新）を、2026年10月1日に読んで整理したものです。E2B・Daytona・Modalとの違いは、各社の公式ドキュメントを同じ日に読んで書きました。
Cloudflare Containersの刷新で何が変わったか｜以前と今回
これまでのCloudflare Containersは、アプリケーションのデプロイを単位に組み立てられていました。イメージと計算資源をデプロイの時に決め、その設定をアプリケーション全体に広げて、まとめて管理する形です。一方でエージェントの作業場は、エージェントが動いている最中にその場で作られ、タスクによって必要なイメージ・計算資源・道具・最初のファイルが変わります。数分で役目を終えることも、リクエストの合間に眠ることも、数日後に呼び戻されることもあります。今回の刷新は、この違いに合わせて、設定・起動・保存の仕組みを変えたものです。
| 項目 | 以前（defaultポリシー） | 今回（durable_objectポリシー・公開ベータ） |
|---|---|---|
| イメージとインスタンスの種類 | デプロイ時に決める（Wranglerの設定） | 実行時にコードで選ぶ（ctx.container.start()の引数） |
| 種類の違うサンドボックス | 組み合わせごとに別のアプリケーションとDurable Objectの名前空間 | 1つのDurable Objectのクラスの中で分岐する |
| イメージの更新 | アプリケーション全体のロールアウト（猶予時間や移す割合を設定） | 次の起動でイメージを選ぶ（動いているContainerは止めるまで元のイメージ） |
| 作業ファイルの保存 | 眠ると次はまっさらなディスク（イメージから起動し直す） | スナップショットで保存と復元（公開ベータ） |
| 起動の速さ（ComputeSDKのベンチマーク・中央値） | 4.049秒 | 648ミリ秒 |
| 起動する数の上限 | max_instancesで指定する |
max_instancesは使えない（アカウントの上限に数える） |
| 置き場所の地域の指定 | placement constraintsで指定できる | 使えない |
表の出典は、発表文と、ドキュメントの「Scheduling Policies」「Migrate to the Durable Object scheduling policy」です。1つのWranglerの設定に、両方のポリシーのアプリケーションを並べることもできます。全体で同じイメージを使うサービスはdefaultポリシーのまま、エージェントのサンドボックスだけをdurable_objectポリシーにする、という分け方ができます。
見落としやすいのは、新しい機能がどれもctx.containerからしか使えないことです。発表文は、durable_objectポリシー、速くなった起動、実行時のイメージとインスタンスの選択、ファイルシステムのスナップショットを「native-only」と書いています。これまでDurable Objectを包んで隠していたContainer classと旧Sandbox classは2026年12月31日まで保守され、その後も既存のデプロイは動き続けますが、更新はされません。Cloudflareはctx.containerへの移行を勧めています。
エージェントのサンドボックスに要る3つの条件と今回の対応
発表文は、エージェントがサンドボックスをどう使うかを3つにまとめています。前もって用意しておくのではなくタスクごとにその場で作ること、作ったらすぐ使えること、一時停止して再開できることです。今回の変更は、この3つに1つずつ対応しています。
| エージェント側の条件 | 今回の対応 | 中身（発表文の説明） |
|---|---|---|
| その場で作る | 実行時にイメージとインスタンスを選ぶ | Node.jsの小さなサンドボックスと、ビルド用のPythonの大きなサンドボックスを、1つのDurable Objectのクラスから並べて起動できる。新しい環境を足すのはコードの変更で、新しいデプロイは要らない |
| すぐ使える | 起動の新しい経路 | Durable Objectが動いているのと同じマシンから空きを探し、イメージやスナップショットを手元に持っているホストを優先する。用意済みの仮想マシンを戻して使い、最初のコマンドに要らないサービスを待たない |
| 一時停止と再開 | ファイルシステムのスナップショット | 作業が止まる時に作業場を保存し、再開の時にファイルを戻す。リポジトリ・入れた依存関係・ビルドのキャッシュ・設定・編集をそのまま使える |
起動をさらに縮めるために、Cloudflareが管理するシステムイメージcloudflare/debian-trixieも用意されました。中身はDebian Trixie SlimとNode.js 24.20.0 LTSです。Dockerfileを書いてビルドしてpushしなくてもLinuxのサンドボックスを起動でき、起動後にexec()でリポジトリの取得やパッケージの導入を進められます。Cloudflareがこのイメージを前もって対象のホストに用意しておくので、利用者が待っている間にイメージの取得や展開をしなくて済む、と説明されています。
発表文によると、この使われ方は、アプリを作るサービスのBase44や、クラウドでエージェントを動かすKilo Codeで見られ、Cursor Cloud Agents、Devin Outposts、OpenAI Agents API、Claude Managed Agentsとの連携でも同じです。コーディングのエージェントはリポジトリ・パッケージマネージャー・コンパイラ・テストを、評価（eval）は決まった状態から始まる環境を、強化学習は大量の環境の作成・採点・やり直しを必要とする、という整理です。
起動6倍の数字の読み方
起動の速さの数字は、ComputeSDKが公開しているBurst TTI Benchmarkの結果として発表文に載っています。100個のサンドボックスを同時に起動し、クライアントから見て操作できるようになるまでの時間（time-to-interactive）を測るものです。発表文の表は次のとおりです。
| 指標 | 以前のスケジューリング経路 | 新しいスケジューリングポリシー | 改善 |
|---|---|---|---|
| 中央値 | 4.049秒 | 648ミリ秒 | 6.2倍 |
| 95パーセンタイル | 5.839秒 | 910ミリ秒 | 6.4倍 |
| 99パーセンタイル | 6.717秒 | 1,129ミリ秒 | 5.9倍 |
出典：Cloudflare公式ブログ（2026年9月30日）。この表とは別に、Cloudflareは自社の予備的な試験の結果も書いています。1つのアカウントが6つの拠点にまたがって10万個のContainerを5.387秒で起動した、という内容です。冒頭では「予備的な試験で、数秒のうちに数十万のContainerを作れた」とも述べています。こちらは独立したベンチマークではなく、Cloudflare自身の試験の記載です。
ドキュメントの「Lifecycle of a Container」には、コールドスタートは多くの場合1〜3秒の範囲で、イメージの大きさやコードの実行時間などで変わる、という一般的な説明が残っています。648ミリ秒はベンチマークの条件での中央値なので、自分のイメージと最初のコマンドで起動時間を測ってから、利用者を待たせる時間の見積もりに使うのが安全です。
仕組み｜Durable Objectが各Containerを動かす
Cloudflare Containersでは、最初からすべてのContainerにDurable Objectが1つずつ付いています。Durable Objectは、状態を持ち、コードを実行できる制御役で、Containerのすぐ隣で動きます。WorkerはDurable Objectにリクエストを送り、Durable Objectがctx.containerを通してContainerを操作します。ドキュメントによると、Containerに届く道はこのDurable Objectだけです。
役割の分け方は、発表文の言い方では「ContainerはDurable Objectの計算資源の延長」です。ContainerがLinuxの環境を受け持ち、Durable Objectがサンドボックスの身元を表し、状態と認証情報を持つ側に立って、決まりと起動から停止までの流れを管理します。各ContainerはFirecracker microVMの中で動き、自分専用のカーネルとネットワークを持ち、そのカーネルをCloudflareのネットワーク上のほかの処理と共有しません。イメージはそのVMの中でLinuxのコンテナとして動き、linux/amd64向けに作る必要があります。隔離の方式による違いは、当サイトのAIエージェントのサンドボックス設計（gVisor比較）で扱っています。
起動が速くなった理由も、この構造にあります。以前は、Containerを起動するたびに、Cloudflare全体の制御の仕組みがアプリケーションの設定を解決し、空きを探し、置き場所を調整していました。新しいポリシーでは、起動の要求がDurable Objectから始まります。まず同じマシンで空きを探し、足りなければ同じ拠点の中で範囲を広げ、イメージやスナップショットをすでに手元に持っているホストを優先します。ホストに届いた後も、新しい仮想マシンを一から起動せず、用意済みでまだ割り当てていない仮想マシンを戻して使い、ネットワークとファイルシステムの準備を使い回します。ただし「Lifecycle of a Container」には、Durable Objectとそれに付くContainerが同じ拠点で動くとは限らない、という注記もあります。
エージェント本体をどこで動かすかは2通りです。発表文は、Anthropicが説明した「脳と手を分ける（decoupling the brain from the hands）」の考え方に触れ、エージェントのループをDurable Objectで動かしてContainerを作業場として使う形と、エージェントをContainerの中で動かしてDurable Objectが見守る形の両方を挙げています。前者では、Durable ObjectがWebSocketで利用者とやり取りし、モデルを呼び、シェルやコンパイラが要る時だけContainerを起こします。利用者やモデルを待つ間はLinuxの計算資源を止められるので、使っていないLinuxの分は払わずに済みます。発表文がこの考え方の出典として示しているのは、AnthropicのManaged Agentsについてのエンジニアリング記事です。製品としての位置づけはClaude Managed Agentsとはにまとめています。
新しいポリシーでは、Durable Objectが間に包むクラスを挟まずにContainerを直接操作します。exec()はWorkersのランタイムの中で直接動き、外へ出るリクエストの横取り、実行時のイメージとインスタンスの選択、スナップショットがすべてctx.containerに揃いました。Durable Objectのストレージ、アラーム、WebSocket、RPCと組み合わせて使えます。Durable Object Container APIのドキュメントにあるexec()の例は次のとおりです。
import { DurableObject } from "cloudflare:workers";
export class MyDurableObject extends DurableObject {
async runCommand() {
const container = this.ctx.container;
if (!container) {
throw new Error("No container is configured for this Durable Object");
}
if (!container.running) {
throw new Error("Container is not running");
}
const process = await container.exec(["node", "--version"]);
const output = await process.output();
return {
pid: process.pid,
exitCode: output.exitCode,
stdout: new TextDecoder().decode(output.stdout),
};
}
}exec()はシェルを通さずに実行ファイルを直接起動します。パイプやリダイレクトを使う時は、イメージにBashがあれば["bash", "-lc", "<COMMAND>"]のように明示して呼ぶ、とドキュメントは説明しています。
サンドボックスの作り方｜ctx.containerとSandbox SDK 1.0
ここからは、発表文とドキュメントに載っているコードだけを使って、作り方の順に見ていきます。durable_objectポリシーを使うには、Wranglerの設定でscheduling_policyをdurable_objectにし、Durable Objectが選べるイメージをimagesに並べます。発表文の例では、Node.jsとPythonの2つのイメージを宣言しています。
// wrangler.jsonc
{
"containers": [
{
"class_name": "AgentSandbox",
"scheduling_policy": "durable_object",
"images": {
"node": { "dockerfile": "./images/node/Dockerfile" },
"python": { "dockerfile": "./images/python/Dockerfile" }
}
}
],
"durable_objects": {
"bindings": [{ "name": "SANDBOX", "class_name": "AgentSandbox" }]
}
}実行時にイメージとインスタンスを選ぶ
宣言したイメージは、Durable Objectの中でthis.ctx.container.images.<名前>として使えます。タスクが届いたら、コードがそのタスクに合うイメージとインスタンスの種類を選びます。
import { DurableObject } from "cloudflare:workers";
export class AgentSandbox extends DurableObject {
async startWorkspace(workspace) {
if (this.ctx.container.running) {
return;
}
const image =
workspace.toolchain === "python"
? this.ctx.container.images.python
: this.ctx.container.images.node;
const instance =
workspace.workload === "build"
? "standard-2"
: "standard-1";
this.ctx.container.start({
image,
instance,
enableInternet: true,
});
}
}以前は別のアプリケーションと別のwrangler deployが必要だった選択が、if文1つになった、と発表文は書いています。ドキュメントの「Scheduling Policies」から、書く時に押さえる点を挙げます。
instanceに渡せるのはlite・standard-1・standard-2・standard-3・standard-4です。省略するとliteになり、basicと旧名のdev・standardは受け付けません。vcpu・memoryMib・diskMbを持つオブジェクトで、独自のサイズも指定できます- 名前付きのイメージは、1つの設定に100個まで置けます。中身はDockerfileのパスか、Cloudflareが管理するレジストリにあるダイジェスト固定の参照です。Docker Hub・Amazon ECR・Google Artifact Registryは直接指定できないため、先にCloudflareのレジストリへpushします
start()は、Containerがリクエストを受けられるようになる前に戻ります。exec()やリクエストを送る前に、準備ができたかを確かめる処理をアプリケーション側に入れます- オプションを渡す時は
enableInternetが必須です。インターネットに出る必要がなければfalseにします
Cloudflareが管理するイメージから始める
Dockerfileを用意せずに始めるなら、cloudflare/debian-trixieをそのまま起動できます。発表文の例では、メインのプロセスが終わらないよう、entrypointにsleep infinityを指定しています。
this.ctx.container.start({
image: "cloudflare/debian-trixie",
instance: "standard-2",
enableInternet: true,
entrypoint: ["/bin/sleep", "infinity"]
});イメージの入れ替えもコードで書く
durable_objectポリシーのContainerは、アプリケーション全体のロールアウトに加わりません。動いているContainerは止めるまで起動時のイメージを使い続け、次に起動する時にどのイメージを選ぶかで更新の進め方が決まります。発表文の例は、固定したイメージがあればそれを使い、なければカナリアの対象かどうかで新旧を選ぶ書き方です。
const image =
(await this.ctx.storage.get("pinned-image")) ??
(isCanary(this.ctx.id)
? this.ctx.container.images.nodeV2
: this.ctx.container.images.node);発表文は進め方の例として、Durable ObjectのIDのハッシュで新しいサンドボックスの5%だけに新しい道具を試す、作業中のプロジェクトは今のイメージに固定してタスクの途中で環境が変わらないようにする、次のセッションやスナップショットの後など区切りの良い時に移す、次の起動で選ぶイメージを戻して切り戻す、の4つを挙げています。
Sandbox SDK 1.0を使う
Sandbox SDK 1.0（npmの@cloudflare/sandbox）は、0.xとは別のライブラリです。0.xはContainersの上に作ったSandboxクラスを提供し、最初に使った時にContainerが起動する作りでした。1.0は基底クラスではなく道具の集まりで、自分で書いたDurable Objectのクラスの中でctx.containerと並べて使います。ドキュメントによると、パッケージのクラスは動いているContainerの中でexec()を通して補助のプロセスを動かすもので、Containerの起動・停止・監視はしません。Cloudflareは、0.xを作った当時はランタイムにコマンドの実行も外へ出るリクエストの横取りもスナップショットもなかったので、それらを利用者側のコードで作っていた、と経緯を説明しています。
使うための条件は3つです。Containerのイメージに補助のバイナリ/usr/local/bin/sandbox-shimを入れること（入れたパッケージと同じ版のタグのcloudflare/sandboxイメージからコピーする）、Workerに互換性フラグnodejs_compatを付けること、メソッドを呼ぶ時にContainerが動いていることです。導入のコマンドと、ドキュメントの設定例のDockerfileは次のとおりです。
npm i @cloudflare/sandboxFROM node:24-trixie-slim
COPY --from=docker.io/cloudflare/sandbox:1.0.0 /usr/local/bin/sandbox-shim /usr/local/bin/sandbox-shim
RUN mkdir /workspace
CMD ["sleep", "infinity"]Durable Objectの側では、workspaceという名前のイメージを起動し、そのContainerをパッケージのクラスに渡します。ドキュメントの例（JavaScript版）では、ファイルを扱うFilesクラスで/workspaceの中身を読みます。
import { Files } from "@cloudflare/sandbox";
import { DurableObject } from "cloudflare:workers";
const INACTIVITY_TIMEOUT_MS = 10 * 60 * 1000;
export class MyContainer extends DurableObject {
container;
files;
constructor(ctx, env) {
super(ctx, env);
const container = ctx.container;
if (!container) {
throw new Error("The container binding is not configured");
}
this.container = container;
// ctx.container stays the same object while the Durable Object runs.
this.files = new Files(container);
// A restarted Durable Object sets the timeout again.
if (container.running) {
void ctx.blockConcurrencyWhile(() =>
container.setInactivityTimeout(INACTIVITY_TIMEOUT_MS),
);
}
}
async listWorkspace() {
// Files does not start the container.
if (!this.container.running) {
this.container.start({
image: this.container.images.workspace,
enableInternet: false,
});
await this.container.setInactivityTimeout(INACTIVITY_TIMEOUT_MS);
}
return this.files.readDirectory("/workspace");
}
}1.0のクラスは、動いているContainerのファイルを読み書きするFiles、S3互換のバケットをContainerにマウントするS3Mount、ディレクトリをR2へ保存して戻すDirectoryBackupの3つです。0.xからの移行ガイドは、用意済みのイメージならstart()から最初のコマンドまでの中央値が600ミリ秒未満（0.xでは約4秒）だと書いています。ファイルを同期する、もっと上の層の環境が欲しい場合は、Dynamic WorkersとContainersを組み合わせた@cloudflare/computerがある、と発表文は案内しています。
既存のアプリケーションから移る時
すでにContainersやSandbox SDK 0.xを使っている場合は、2つの移行ガイドに決まった順番があります。
- スケジューリングポリシーは作成後に変えられません。既存のアプリケーションの
scheduling_policyは書き換えず、新しいDurable Objectのクラスと名前空間を持つ新しいアプリケーションを足して、そちらへ切り替えます - 既存のContainerとDurable Objectのストレージは移りません。defaultポリシーにはスナップショットがないため、ファイルシステムもスナップショットでは運べません。データがあるなら、移し方を先に設計します
- Container classはdurable_objectポリシーに対応していません。
extends Containerをextends DurableObjectに変えてthis.ctx.containerを直接呼び、準備の確認・リクエストの転送・眠るまでの時間など、Container classに任せていた処理を書き直します - 外部のレジストリのイメージは、先にCloudflareのレジストリへpushします。
instance_typeのdevはlite、standardはstandard-1、basicはliteかstandard-1に置き換えます
Sandbox SDK 0.xは、2026年12月31日まで不具合と安全性の修正だけを受け、新機能は入りません。その日より後も、デプロイ済みの0.xのアプリケーションは動き続け、npmのパッケージも残ります。0.xから1.0への切り替えについて、移行ガイドは「一方通行」と注意しています。クラスをdurable_objectポリシーに移すデプロイは取り消せず、その後はwrangler rollbackでも0.xのコードからContainerを起動できません。全部を1回のデプロイで移すか、1.0のクラスを0.xのクラスの横で動かして1つずつ移すかを選び、先にステージング用のWorkerで練習するよう勧めています。
なお、同じBirthday Weekに、Cloudflareは全APIを扱えるエージェント向けのCLI「cf」も公開ベータとして発表しました（発表文「Introducing cf: the agentic CLI for the entire Cloudflare API」）。Wranglerのコマンドが約280の操作だったのに対し、cfは3,000を超えるAPIの操作を対象にし、出力は既定でJSON、設定はTypeScriptのcloudflare.config.tsで書く形です。同じ発表によると、Wranglerの利用のうちエージェントによるものは直近で48%に達し、WranglerのWorkerはcf migrateで移せて、Wranglerは公開ベータが終わってから18か月、保守が続きます。ただ、Containersのドキュメントの設定例は2026年10月1日時点でwrangler.jsoncで書かれていて、Containersの設定をcloudflare.config.tsで書けるかどうかは公式に確認できていません。
ファイルシステムのスナップショット（公開ベータ）｜保存と復元
スナップショットは、動いているContainerのファイルシステムを、ある時点の状態で保存する機能です。2026年9月30日に公開ベータになり、durable_objectポリシーのアプリケーションだけで使えます。defaultポリシーでは作ることも戻すこともできません。流れは、作業場を用意する、snapshotContainer()で保存する、返ってきた値をDurable Objectのストレージに置く、次の起動でcontainerSnapshotに渡す、の4段です。
発表文の例は、作業場を保存するメソッドと、保存した作業場から起動し直すメソッドの組です。
async saveWorkspace() {
const snapshot = await this.ctx.container.snapshotContainer({
name: "project-ready",
});
await this.ctx.storage.put("workspace-snapshot", snapshot);
}
async restoreWorkspace() {
const snapshot = await this.ctx.storage.get("workspace-snapshot");
if (!snapshot) {
throw new Error("No workspace snapshot found");
}
this.ctx.container.start({
containerSnapshot: snapshot,
instance: "standard-2",
enableInternet: true,
});
}imageとcontainerSnapshotは同時に渡せません。返ってくるスナップショットの値は普通のデータなので、Durable Objectのストレージに置き、あとで別のDurable Objectから戻すこともできます。何が残り、何が残らないかは、ドキュメントの「Use snapshots」と「Sandbox lifetime」に次のように書かれています。
| 項目 | ドキュメントの記載 |
|---|---|
| 残るもの | 保存されるのはファイルシステムだけ（書き込みできるルートのファイルシステム全体）。リポジトリ・依存関係・編集した内容が戻る |
| 残らないもの | メモリ、動いているプロセス、別にマウントしたファイルシステム、/runの中のファイル。開発サーバーは戻した後に起動し直す |
| イメージとの関係 | 作った時のイメージの版に結び付き、別のイメージには持ち込めない。イメージを更新したら、新しいイメージで動くContainerから作り直す |
| 書き換え | スナップショットは書き換えられない。戻した後の変更を残すには、新しいスナップショットを作る |
| 期限 | 作成か最後の復元から30日後に期限が切れる。復元すると期限がのびる。期限を自分で決める設定はまだない |
| 大きさ | 1つ20 GBまで |
| プロセスID | 戻した後も同じプロセスIDが使われるため、ファイルに書いておいたIDが別のプロセスを指すことがある |
使い道は2つ挙げられています。1つは、1つの作業場を何度ものセッションにまたがって続けることです。利用者が作業を終えた時に保存し、翌日戻ってきた時に戻せば、環境を作り直さずに続けられます。長い作業を途中で止めて再開する設計の考え方は、長時間実行の中断と再開の設計（Checkpoint比較）でも扱っています。
もう1つは、多くのサンドボックスの共通の出発点にすることです。スナップショットは書き換えられず何度でも使えるので、同じスナップショットから複数のContainerを別々に起動できます。発表文は評価（eval）を例に挙げています。システムプロンプト・スキル・モデル・エージェントの版を変えて同じタスクを試す時、リポジトリや依存関係や入力ファイルをそろえないと結果を比べられません。1つのスナップショットから始めれば、準備の時間が減り、環境のずれが結果に混ざるのを防げます。評価を継続的に回す仕組みはAIエージェントの継続的評価とCI/CD回帰検知にまとめています。
スナップショットの保存に料金がかかるかどうかは、料金ページ（2026年8月28日更新）に記載がなく、2026年10月1日時点で公式に確認できていません。期限より長く残したいファイルは、R2のバケットに写すようドキュメントは勧めています。
料金と制限｜Workers Paidプランが前提
Containersは、Workers Paidプラン（月5ドル＝約750円）で使える機能です。料金ページの表では、Freeプランの欄は「N/A」です。動いている間だけ10ミリ秒単位で課金され、メモリとディスクは選んだインスタンスの種類の割り当て量で、CPUは実際に使った分だけで計算されます。眠った後は課金が止まります。
| 資源 | 月に含まれる量（Workers Paid） | 超えた分の単価（1ドル150円で換算） |
|---|---|---|
| メモリ | 25 GiB時間 | 1 GiB秒あたり0.0000025ドル（1 GiB時間あたり約1.35円） |
| CPU | 375 vCPU分 | 1 vCPU秒あたり0.000020ドル（1 vCPU時間あたり約10.8円） |
| ディスク | 200 GB時間 | 1 GB秒あたり0.00000007ドル（1 GB時間あたり約0.04円） |
このほか、Containerへのリクエストを受けるWorkerと、各Containerに付くDurable Objectの利用料が別にかかります。ログはWorkers Logsと同じ料金です。外へ出る通信（egress）の単価は次のとおりで、日本からの通信がどの区分に入るかは表に書かれていません。
| 地域 | 1 GBあたり | 月に含まれる量 |
|---|---|---|
| 北米・欧州 | 0.025ドル（約3.75円） | 1 TB |
| オセアニア・韓国・台湾 | 0.05ドル（約7.5円） | 500 GB |
| それ以外 | 0.04ドル（約6円） | 500 GB |
試算例（計算上の値で、計測したものではありません）として、standard-2（1 vCPU・6 GiB・12 GB）を1時間動かし、CPUを使い切ったと仮定して、月に含まれる量を超えた後の料金を計算すると次のようになります。WorkerとDurable Objectの料金は含めていません。
- メモリ：6 GiB × 3,600秒 × 0.0000025ドル＝0.054ドル（約8.1円）
- CPU：1 vCPU × 3,600秒 × 0.000020ドル＝0.072ドル（約10.8円）
- ディスク：12 GB × 3,600秒 × 0.00000007ドル＝約0.003ドル（約0.45円）
- 合計：約0.129ドル（約19円）
同じ計算で、月に含まれるメモリ25 GiB時間は、standard-2を動かし続けると約4.2時間分にあたります。エージェントのサンドボックスは、利用者やモデルを待つ間に眠らせるかどうかで料金が大きく変わります。インスタンスの種類と上限は、Limits and Instance Types（2026年9月30日更新）に次のように載っています。
| 種類 | vCPU | メモリ | ディスク | durable_objectポリシーでの指定 |
|---|---|---|---|---|
| lite | 1/16 | 256 MiB | 2 GB | できる（省略時の既定） |
| basic | 1/4 | 1 GiB | 4 GB | できない |
| standard-1 | 1/2 | 4 GiB | 8 GB | できる |
| standard-2 | 1 | 6 GiB | 12 GB | できる |
| standard-3 | 2 | 8 GiB | 16 GB | できる |
| standard-4 | 4 | 12 GiB | 20 GB | できる |
独自のサイズは、vCPUが1〜4、メモリが12 GiBまで、ディスクが20 GBまでで、1 vCPUあたり3 GiB以上のメモリが要ります。アカウント全体では、同時に使えるメモリが6 TiB、vCPUが1,500、ディスクが30 TB、イメージの保存は合計50 GBまでです。スナップショットは1つ20 GBまでです。
置き場所の地域を絞る設定（placement constraints）では、ENAM（北米東部）やAPAC（アジア太平洋）などの地域と、eu・fedrampの管轄を指定できます。ただし移行ガイドの対応表では、placement constraintsはdurable_objectポリシーのアプリケーションで「Not supported」です。データを置く地域に決まりがある用途では、2026年10月1日時点で新しいポリシーを選べません。
E2B・Daytona・Modalとの違い｜止めた時に何が残るか
エージェントのサンドボックスを選ぶ時に差が出やすいのは、止めた時に何が残るかです。各社の公式ドキュメント（2026年10月1日に取得）の記載を、同じ観点で並べました。起動の速さは測り方がそろっていないため、この表では比べていません。
| 基盤 | 止めた・保存した時に残るもの | 保存の期限（既定） | 操作の入口 |
|---|---|---|---|
| Cloudflare Containers（durable_objectポリシー） | スナップショットでファイルシステムを保存。メモリと動いているプロセスは残らない | 作成か最後の復元から30日。期限は変えられない | Durable Objectのコード（ctx.container） |
| E2B | 一時停止でファイルシステムとメモリ（動いているプロセスや読み込んだ変数）を保存。ファイルシステムだけの保存も選べる | 一時停止したサンドボックスは自動では消えない | JavaScriptとPythonのSDK |
| Daytona | 停止してもファイルシステムが残る。Linux VMとWindowsのサンドボックスは一時停止でメモリも残る（コンテナ型は一時停止がない） | 停止・一時停止・アーカイブの状態は削除するまで残る | SDK（ドキュメントの例はPython） |
| Modal | ファイルシステム・ディレクトリ・メモリの3種類のスナップショット（メモリはアルファ版） | ファイルシステムとディレクトリは既定で30日（変更や無期限も可）。メモリは7日 | SDK（Python・Go・JavaScript） |
補足すると、Daytonaのコンテナ型とGPUのサンドボックスは、既定で15分の無操作で止まり、GPUのサンドボックスは止まると削除されます。E2Bは、一時停止せずに動かし続けられる時間がPro tierで24時間、Hobby tierで1時間です。いずれも各社のドキュメントの記載です。
当社の見方：どれが優れているかではなく、止めた時に何を残したいかと、エージェントの制御をどこに置きたいかで選ぶのが現実的です。
- すでにWorkersとDurable Objectsでアプリを動かしていて、エージェントの状態・認証情報・権限をWorker側に置きたいなら、Cloudflare Containersの新しいポリシーが合います。Linuxが要らない処理はDynamic Workersに回し、1つのWorkerから両方を使えます（Cloudflareのドキュメント「Choose a sandbox environment」の使い分け）
- 動いているプロセスやメモリの中身ごと止めて、同じ状態から再開したいなら、メモリも残す仕組み（E2Bの一時停止、DaytonaのVMの一時停止、Modalのメモリのスナップショット）を持つ基盤を比べます。Cloudflareのスナップショットでは、戻した後に開発サーバーなどを起動し直します
- データを置く地域に決まりがある用途は、durable_objectポリシーでは地域を指定できないため、今のところ向きません
- GPUを使う処理は、Containersの制限ページにGPUの項目がなく、使えるかどうかを2026年10月1日時点で公式に確認できていません
3社をもっと広い観点で比べた記事は、E2B・Daytona・Modalの比較（2026年4月公開）にあります。公開後に各社の仕様が変わっているので、上の表とあわせて読んでください。
安全に使うための設計｜認証情報はサンドボックスの外に置く
Cloudflareのドキュメント「Sandbox security」は、サンドボックスの中のコードは、中に置かれたものを全部使えると考えるよう求めています。デプロイしたサンドボックスでは、すべてのプロセスがrootと同じ権限を持つため、Linuxのユーザーを分けてもファイルは守れません。信頼の最小単位はサンドボックスそのもので、利用者ごと、または仕事ごとに分けるのが基本です。
ドキュメントが挙げる例は、非公開リポジトリのクローンです。WorkerがクローンURLにトークンを入れると、Gitはそれをリポジトリの.git/configに保存します。テストと、テストが読み込む依存関係も同じ権限で動くので、どのコードでもそのトークンを読めます。スナップショットもこのファイルを保存するので、戻すとトークンも戻ってきます。まず、トークンをクローンURLに入れないことです。
勧められているのは、認証情報をサンドボックスの外に置く形です。Containerは認証情報を付けずにリクエストを送り、Worker側のアウトバウンドハンドラーが、リクエストがサンドボックスを出た後で認証情報を付けます。付けるのはHTTPSのリクエストだけにします。ハンドラーはContainerが使った方式のまま送るので、平文のHTTPに付けた認証情報は暗号化されずにインターネットを通るからです。外部のAPIのうちどこへの通信を通すかも、ハンドラーで決められます。
- アウトバウンドハンドラーを使う時は、インターネットへの接続をオフ（
enableInternet: false）にしておきます。ハンドラーが見るのはポート80のHTTPと443のHTTPSだけで、接続をオンにすると、ほかのポートへの通信は直接外へ出ます - HTTPSを横取りする
interceptOutboundHttps()を使う場合、Containerが/etc/cloudflare/certs/cloudflare-containers-ca.crtのCA証明書を信頼している必要があります - サンドボックスの名前は、リクエストがどのサンドボックスとどの保存ファイルに届くかを決めるだけで、誰が送ったかは示しません。Workerで呼び出し元を認証し、その身元から名前を作ります
- サンドボックスから返る結果・ファイル・HTTPの応答は、信頼できないコードの出力として、利用者の入力と同じように確かめます。Webのプレビューは、アプリケーションとは別のホスト名で出します
発表文は、Durable Objectが利用者の許可した範囲を覚えておき、新しく許可された認証情報を差し込む、新しい決まりを適用する、操作を記録する、といった形で、Containerの外側の安全の境界をプログラムできると書き、Cloudflare OSのGatekeeperの形に似ていると説明しています。Claude Codeで同じ問題を扱ったサンドボックスのmaskモードや、AIエージェントの認証情報の管理もあわせて読むと、設計の考え方を比べられます。
【要注意】よくある失敗パターン
新しいポリシーで起こりやすい読み違いと、設定の失敗を4つ挙げます。
失敗1：648ミリ秒を自社の待ち時間の見積もりにする
❌ 発表文の中央値648ミリ秒を、そのまま利用者の待ち時間として画面の設計や社内の約束に使う
⭕ 自分のイメージと最初のコマンドで、起動から操作できるまでを測り、95パーセンタイルや99パーセンタイルのばらつきも見てから決める
なぜ重要か：648ミリ秒は、100個を同時に起動するベンチマークの条件での値です。ドキュメントは、コールドスタートがイメージの大きさやコードの実行時間で変わると書いています。
失敗2：中で処理が動いているから止まらないと考える
❌ ビルドやテストをexec()で始め、Durable Objectに何もリクエストが来ないまま終わりを待つ
⭕ setInactivityTimeout()（最大6時間）を起動後とDurable Objectのコンストラクタの両方で設定し、長い処理はタイムアウトより短い間隔のアラームで様子を見る
なぜ重要か：「Sandbox lifetime」によると、Containerの中で動くコードは活動に数えられません。リクエストが来なければ、処理の途中でもタイムアウトで止まります。デプロイなどでDurable Objectが再起動すると、タイムアウトの設定は消えます。
失敗3：トークンをクローンURLや環境変数で中に入れる
❌ 非公開リポジトリのトークンを、クローンURLや環境変数でサンドボックスに渡す
⭕ 認証情報はWorker側に置き、アウトバウンドハンドラーでHTTPSのリクエストだけに付ける。インターネットへの接続はオフにしておく
なぜ重要か：中のコードは置かれたものを全部読めます。.git/configに残ったトークンはスナップショットにも保存され、戻すと一緒に戻ります。
失敗4：既存のアプリケーションのscheduling_policyを書き換える
❌ 動いているアプリケーションの設定でscheduling_policyをdurable_objectに変えて、そのままデプロイする
⭕ 新しいDurable Objectのクラス・バインディング・Containerの項目を足し、古い項目は戻れるように残したまま切り替える
なぜ重要か：wrangler deployは、Containerのアプリケーションを設定する前に新しいWorkerの版を出します。ポリシーの変更で失敗すると、新しいコードだけが公開され、その裏にdurable_objectのアプリケーションがない状態になる、と移行ガイドは注意しています。
よくある質問
Cloudflare Containersは無料プランで使えますか？
使えません。Containersのドキュメントには「Available on Workers Paid plan」とあり、料金ページの表でもFreeプランの欄は「N/A」です。Workers Paidプランは月5ドル（約750円）で、メモリ25 GiB時間・CPU 375 vCPU分・ディスク200 GB時間が毎月含まれます。
Cloudflare Containersの料金はいくらですか？
動いている間だけ10ミリ秒単位で課金され、含まれる量を超えた分は、メモリが1 GiB秒あたり0.0000025ドル、CPUが1 vCPU秒あたり0.000020ドル、ディスクが1 GB秒あたり0.00000007ドルです（2026年10月1日時点の料金ページ）。standard-2を1時間、CPUを使い切って動かす試算では約0.129ドル（約19円）になります。WorkerとDurable Objectの料金と、外へ出る通信の料金は別にかかります。
WorkersとContainersはどう使い分けますか？
Cloudflareのドキュメントは、コードがLinuxを前提にするかどうかで分けています。npm testのように依存関係のファイルや子プロセスが要る処理、ポートで待ち受ける開発サーバー、ネイティブのバイナリが要るコンパイラはContainerを使います。Workerが渡す決まったメソッドを呼ぶだけのコードは、Dynamic Workersで動かせます。1つのWorkerから両方を使えます。
Cloudflare ContainersでGPUは使えますか？
Containersの制限ページ（2026年9月30日更新）に並ぶのはvCPU・メモリ・ディスクで、GPUの項目はありません。GPUを使えるかどうかは、2026年10月1日時点で公式に確認できていません。
既存のContainer classやSandbox SDK 0.xはいつまで使えますか？
発表文によると、Container classと旧Sandbox classは2026年12月31日まで保守されます。その日より後も既存のデプロイは動き続けますが、更新はされません。Sandbox SDK 0.xも同じ日まで不具合と安全性の修正だけを受けます。新しい機能はctx.containerからしか使えないため、Cloudflareは移行を勧めています。
まとめ
Cloudflare Containersは、2026年9月30日の発表で、エージェントのサンドボックスをDurable Objectのコードから作り、選び、保存する形に変わりました。イメージとインスタンスの種類は起動の時に選び、起動の速さはComputeSDKのベンチマークの中央値で648ミリ秒、スナップショットはファイルシステムだけを残します。新しいポリシーとスナップショットはどちらも公開ベータで、地域の指定は使えません。
今週やることは3つです。自分のイメージで起動から最初のコマンドまでの時間を測る、認証情報をWorker側のアウトバウンドハンドラーに移せるかを確かめる、Container classやSandbox SDK 0.xを使っているなら2026年12月31日までの移行の段取りを決める。Workersの上でエージェントを組む全体像は、Cloudflare Workers AIエージェント実装ガイドを参考にしてください。社内でエージェントの実行環境や決まりを設計する段階で相談先が必要な場合は、UravationでもAIエージェントの導入を支援しています。
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）
参考・出典
- Cloudflare Containers, rebuilt to scale agent sandboxes — Cloudflare公式ブログ（2026年9月30日・参照日: 2026-10-01）
- Scheduling Policies — Cloudflare Docs（2026年9月30日更新・参照日: 2026-10-01）
- Durable Object Container API — Cloudflare Docs（2026年9月30日更新・参照日: 2026-10-01）
- Use snapshots — Cloudflare Docs（2026年9月30日更新・参照日: 2026-10-01）
- Lifecycle of a Container — Cloudflare Docs（2026年9月30日更新・参照日: 2026-10-01）
- Migrate to the Durable Object scheduling policy — Cloudflare Docs（2026年9月30日更新・参照日: 2026-10-01）
- Migrate from the Container class to the Durable Object Container API — Cloudflare Docs（2026年9月29日更新・参照日: 2026-10-01）
- Pricing — Cloudflare Docs（2026年8月28日更新・参照日: 2026-10-01）
- Limits and Instance Types — Cloudflare Docs（2026年9月30日更新・参照日: 2026-10-01）
- Placement — Cloudflare Docs（2026年8月28日更新・参照日: 2026-10-01）
- Sandboxes on Cloudflare — Cloudflare Docs（2026年9月30日更新・参照日: 2026-10-01）
- @cloudflare/sandbox — Cloudflare Docs（2026年9月30日更新・参照日: 2026-10-01）
- Migrate from Sandbox SDK 0.x — Cloudflare Docs（2026年9月30日更新・参照日: 2026-10-01）
- Sandbox lifetime — Cloudflare Docs（2026年9月30日更新・参照日: 2026-10-01）
- Sandbox security — Cloudflare Docs（2026年9月30日更新・参照日: 2026-10-01）
- Choose a sandbox environment — Cloudflare Docs（2026年9月30日更新・参照日: 2026-10-01）
- Introducing cf: the agentic CLI for the entire Cloudflare API — Cloudflare公式ブログ（Birthday Weekの発表・参照日: 2026-10-01）
- Sandbox persistence — E2B Documentation（参照日: 2026-10-01）
- Persistence — Daytona Documentation（参照日: 2026-10-01）
- Snapshots — Modal Documentation（参照日: 2026-10-01）
