Cloudflare Containersとは？AIエージェントのサンドボックスを動かす手順と料金【2026年10月時点】

Cloudflare Containersは、Cloudflare Workersのアプリからコンテナを起動し、任意の言語やLinuxのツールを動かすためのサーバーレスなコンテナ基盤です。2026年9月30日にはCloudflare公式ブログで大きな刷新が発表され、起動の中央値が4.049秒から648ミリ秒へ縮みました。イメージとインスタンスサイズをコードの中で選べるようになり、AIエージェントにコードを実行させるサンドボックスの置き場所として使いやすくなっています。

この記事では、WorkerとDurable Objectからコンテナを制御する構造、雛形からデプロイまでの手順、ctx.containerでサンドボックスを動かすコード、スナップショット、インスタンスタイプ別の料金試算、旧Containerクラスからの移行、受託開発で採用するかどうかの線引きまでを扱います。Workers本体の料金や対応言語は、Cloudflare Workersの料金・無料枠と対応言語をまとめた記事で整理しています。

まとめ：Cloudflare Containersを採用する条件と見送る条件

結論から書きます。セッション単位で隔離したLinux環境を短時間だけ立ち上げ、使い終わったら止める処理なら、Cloudflare Containersは有力な選択肢です。逆に、常時起動のWebサーバーやGPUを使う推論、データベースのような状態を抱えるサービスを載せる基盤としては選びません。

• 構造：Workerがリクエストを受け、コンテナごとに1つあるDurable Objectが起動・停止・通信を制御する
• 2026年9月の刷新：durable_objectポリシー（パブリックベータ）で、イメージとインスタンスを実行時に選べるようになった
• サンドボックス用途：cloudflare/debian-trixieならDockerfile無しで起動でき、exec()でコマンドを流せる
• 料金：Workers Paidプランが前提。メモリとディスクは割り当て量、CPUは実使用量で10ミリ秒単位に課金される
• 移行：旧ContainerクラスとSandboxクラスの保守は2026年12月31日まで

ContainersとWorker・Durable Objectの制御構造

Containersのドキュメントは、用途として3つを挙げています。CPUコアやメモリ、ディスクを多く使う処理、ファイルシステム全体やLinuxらしい環境を必要とするアプリ、既存のコンテナイメージとして配られているツールです。Workers単体はV8 isolateの中で動くため、ネイティブのバイナリを呼んだりファイルを自由に書いたりはできません。isolateの分離の仕組みはV8 Isolateの分離設計と起動時間を実測した記事で扱っています。

Containersは、Workers単体では扱えないこれらの処理を担う基盤です。各コンテナには専用のDurable Objectが1つ付き、Workerはそのスタブを経由してコンテナへ処理を渡します。Sandboxのドキュメントでは、Containersの説明は、任意のLinuxイメージを動かすmicroVMという位置付けです。プロセスの分離だけでなく、仮想マシンの境界で区切られる前提で設計できます。

2026年9月30日の刷新で起動中央値が648ミリ秒になった経緯

刷新前は、イメージとインスタンスサイズの組み合わせごとに、別のアプリケーション、別のDurable Objectの名前空間、個別のwrangler deployが必要でした。Node.js用とPython用のサンドボックスを両方持つだけで、デプロイ単位が2つに分かれていたわけです。

新しいdurable_objectポリシーでは、この選択がコードの分岐に変わりました。起動時間は、ComputeSDKが公開する同時100台起動のベンチマークで、中央値が4.049秒から648ミリ秒、95パーセンタイルが5.839秒から910ミリ秒、99パーセンタイルが6.717秒から1129ミリ秒へ短くなったと公式ブログは伝えています。値はクライアントから操作可能になるまでの時間で、Cloudflareが引用した外部ベンチマークです。自社の処理で測り直す前提で読んでください。

defaultとdurable_objectのスケジューリングポリシーの違い

スケジューリングポリシーのページによると、2つのポリシーは用途で分かれます。ベータ扱いなのはdurable_objectだけで、省略時はdefaultになります。

ポリシーは後から切り替えられません。別のポリシーを使うには新しいContainerアプリケーションを作る必要があり、既存のアプリを消すと実行中のインスタンスもすべて消えます。サンドボックス用途で始めるなら、最初からdurable_objectを指定しておくほうが手戻りがありません。

containers-template作成とwrangler deployの手順・確認

前提はWorkers Paidプランの契約と、手元で起動しているDockerです。Get startedのページは、wrangler deployを実行する時点でDockerが動いている必要があると書いており、docker infoで起動を確かめてから進めます。

Docker起動の確認とnpm create cloudflareで雛形を作る作業

公式の雛形からWorkerとコンテナの組を作り、そのままデプロイできます。雛形に含まれるDockerfileを自社のアプリ用に書き換える場合、命令の書き方はDockerfileの主要命令とベストプラクティスを解説した記事を参照してください。

# Dockerが動いているかを確認する
docker info

# Workerとコンテナの雛形を作る
npm create cloudflare@latest -- --template=cloudflare/templates/containers-template

# Workerのアップロード、イメージのビルドとpush、コンテナの更新をまとめて行う
npx wrangler deploy

デプロイ時には、DockerでイメージをビルドしてCloudflareのレジストリへpushし、ネットワーク上のコンテナを更新します。初回のビルドとpushが最も時間を食い、2回目以降はキャッシュされたレイヤーが再利用されます。

初回デプロイ後の数分待ちとwrangler containers listの確認

つまずきやすいのは初回デプロイの直後です。ドキュメントは、初回デプロイ後は数分待ってからコンテナへのリクエストを試すよう書いています。WorkerのURLが応答していても、コンテナの準備が終わらず呼び出しが失敗することがあるためです。

# アカウント内のコンテナと状態を一覧で見る
npx wrangler containers list

# Cloudflareのレジストリにあるイメージを一覧で見る
npx wrangler containers images list

デプロイ直後のエラーをコードの不具合と取り違えると、無駄な調査が増えます。状態が準備中のうちは待ち、一覧で稼働を確認してから疎通を試すのが確実です。

AIエージェントのサンドボックスをctx.containerで実装する設定例

ここからが刷新の本題です。Durable Object Container APIでは、Durable Objectの中からthis.ctx.containerを直接呼び、起動、コマンド実行、ポートへの転送、停止を書きます。以前のようにラッパーのクラスを継承する必要はありません。

wrangler.jsoncでイメージを複数宣言し実行時に切り替える設定

設定ファイルではscheduling_policyにdurable_objectを指定し、imagesに名前付きでイメージを並べます。キーの名前がそのままthis.ctx.container.imagesのプロパティになり、名前付きイメージは最大100個まで宣言できます。

// wrangler.jsonc（公式ブログの例をもとに、Node.js用とPython用の2イメージを宣言）
{
  "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のmigrations設定は雛形が生成したものをそのまま残す
}

起動時にはstart()にimageとenableInternetを渡します。instanceは省略でき、その場合は最小のliteになります。ビルド用はstandard-2、対話用はstandard-1のように、処理の重さで分けられるのが新方式の利点です。

cloudflare/debian-trixieの起動とexec実行手順

Cloudflareが用意したcloudflare/debian-trixieは、Debian Trixie SlimとNode.js 24.20.0 LTSを含むシステムイメージです。各ホストへ事前に配られているため、起動時にイメージの取得を待ちません。次の例は、セッションIDごとに1つのサンドボックスを割り当て、AIエージェントが生成したコマンドを中で実行して結果を返すものです。

// src/index.js
import { DurableObject } from "cloudflare:workers";

export class AgentSandbox extends DurableObject {
  async run(cmd) {
    const c = this.ctx.container;
    if (!c.running) {
      c.start({
        image: "cloudflare/debian-trixie",
        instance: "standard-1",
        // 生成コードを動かすため、外部への通信は既定で閉じておく
        enableInternet: false,
        entrypoint: ["/bin/sleep", "infinity"],
      });
      // 操作が30分無ければ止めて課金を抑える（単位はミリ秒、最大6時間）
      await c.setInactivityTimeout(30 * 60 * 1000);
    }
    // execはシェルを起動しないため、パイプ等を使うならbash -lcを明示する
    const proc = await c.exec(["bash", "-lc", cmd], { cwd: "/root" });
    const out = await proc.output();
    const dec = new TextDecoder();
    return {
      exitCode: out.exitCode,
      stdout: dec.decode(out.stdout),
      stderr: dec.decode(out.stderr),
    };
  }
}

export default {
  async fetch(request, env) {
    // 例: {"sessionId":"user-42","cmd":"node --version"} をPOSTする
    const { sessionId, cmd } = await request.json();
    const stub = env.SANDBOX.getByName(sessionId);
    return Response.json(await stub.run(cmd));
  },
};

注意点は2つあります。1つ目は、start()が準備完了を待たずに戻ることです。起動直後のexec()が失敗する場合に備え、本番ではリトライか準備確認の処理を挟みましょう。2つ目は、exec()が非ゼロの終了コードでも例外にならない仕様で、exitCodeを見て成否を判定する処理を自分で書く必要があります。外部へのHTTP通信を許すときは、interceptOutboundHttps()で通信をWorker側の処理へ回し、許可した宛先だけ通す設計にできます。

snapshotContainerで作業環境を保存し次のセッションで復元する

依存パッケージの導入に数分かかる環境を毎回作り直すと、起動の速さが帳消しになります。スナップショットのガイドにあるsnapshotContainer()は、実行中コンテナの書き込み可能なルートファイルシステムを保存する機能で、パブリックベータです。

// AgentSandbox クラスに追加するメソッド
async saveWorkspace() {
  // 依存の導入まで済んだ状態を保存し、Durable Objectのストレージに控える
  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: false,
  });
}

スナップショットは変更されず、同じものから複数のコンテナを独立に起動できます。評価用に同じ初期状態の環境を何十個も並べる使い方に向いています。制限のページでは、サイズの上限が20GB、保持期間は作成か最後の復元から30日です。30日以上使わないプロジェクトの環境は消える前提で、再構築の手順もコードに残しておきます。

インスタンスタイプ6種とvCPU・メモリ・ディスク課金の実額試算

料金のページによると、課金は10ミリ秒単位で、リクエストが届くか手動で起動した時点から、スリープするまで続きます。メモリとディスクは選んだインスタンスタイプの割り当て量で、CPUは実際に使った分だけで計算されます。無料プランでは使えません。

単価は、メモリが1GiB秒あたり0.0000025ドル、CPUが1vCPU秒あたり0.000020ドル、ディスクが1GB秒あたり0.00000007ドルです。Workers Paidの月額5ドルには、メモリ25GiB時間、CPU375vCPU分、ディスク200GB時間が含まれます。

standard-1を1時間動かした場合の従量料金と無料枠の消化ペース

単価から計算すると、standard-1を1時間起動したままにした場合、メモリは4GiB×3,600秒で0.036ドル、ディスクは8GB×3,600秒で約0.002ドルです。CPUを割り当ての0.5vCPUまで使い切ると0.036ドルが加わり、合計は1時間あたり約0.074ドルになります。同じ計算でstandard-2は約0.129ドルです。ここにWorkersとDurable Objectsの料金が別途かかり、各コンテナに専用のDurable Objectが付く点も見積もりに入れます。

含まれる枠で見ると、メモリ25GiB時間はstandard-1の約6.25時間分しかありません。1日に数回、短いタスクを流す検証なら月額の範囲に収まりますが、セッションを開いたまま放置すると数日で枠を超えます。setInactivityTimeoutで止める時間を短く設定することが、料金を抑える一番の手段です。外向きの通信料は北米と欧州が1GBあたり0.025ドル（月1TBまで含む）、それ以外の地域は0.04〜0.05ドル（月500GBまで含む）です。

同時実行1,500vCPUやイメージ総量50GBなどアカウント上限の確認

既定のアカウント上限は、同時に動かせるメモリが6TiB、vCPUが1,500、ディスクが30TBです。standard-1ならメモリの上限が先に効き、単純計算で約1,536台まで同時に起動できる量です。多くの用途ではこれで足ります。先に詰まりやすいのは、アカウント全体で50GBというイメージ保存量のほうでしょう。

イメージ1つの大きさはインスタンスのディスク容量が上限なので、liteで動かすなら2GB以内に収める必要があります。言語ごと・顧客ごとにイメージを増やす設計なら、古い版を消す手順を先に決めておくと安心です。上限はアカウントチームかサポートへの申請で引き上げを相談できます。

旧Containerクラスから移行する作業と2026年12月31日の保守期限

公式ブログによると、これまでのContainerクラスとSandboxクラスの保守は2026年12月31日までです。期限後も既存のデプロイは動きますが、更新は届きません。新機能はctx.container経由でしか提供されないため、継続して使うアプリは移行の計画が要ります。

extends ContainerをDurableObjectへ書き換える置き換え対応表

移行ガイドの基本は、基底クラスをcloudflare:workersのDurableObjectに変えることです。クラス名、Worker名、バインディング、イメージ、既存のマイグレーションタグは変えないため、Durable Objectの新しいマイグレーションは要りません。

表のalarmはDurable Objectのalarmを指します。ポートの準備確認を自分で書く点が、移行で最も工数のかかる箇所です。旧クラスは自動で待っていたため、移行後に起動直後のリクエストが失敗するようになったら、ここを疑います。

受託開発でCloudflare Containersを採用する条件と見送る場面

ここからは判断です。起動の速さだけで選ばず、処理の寿命と状態の置き場所で決めます。次の3条件がそろうなら、Cloudflare Containersで組んで構いません。

• 処理が短命で区切れる：1つのセッションやジョブが終われば止めてよく、常時起動を前提にしない
• 入口がWorkersにある：認証やルーティングをWorkersで受け、コンテナはその背後で動く処理だけを担う
• 状態を外へ出せる：成果物はR2やDurable Objectのストレージへ置き、コンテナのディスクを保存先として扱わない

見送る場面は2つです。第一に、GPUで推論するモデルを載せたい場合です。インスタンスタイプは最大4vCPU・12GiBで、GPU付きの型はありません。第二に、データベースやキューのように長時間動き続け、ディスクに状態を持つサービスです。こうした処理は既存のクラウドのコンテナ基盤に残し、イベント駆動の短い処理ならAWS Lambdaの仕組みと料金体系をまとめた記事で扱う構成のほうが素直に動きます。

Docker Cloud Sandboxes・gVisor・AWS Lambdaの比較軸

AIエージェントのサンドボックスとして比べる相手は、Docker Cloud Sandboxesです。Dockerの製品は、手元のDocker Sandboxesで動かしていた環境をクラウドへ移せる点が強みで、開発者個人の作業環境に近い位置にあります。詳しくはDocker Cloud SandboxesでAIエージェントを隔離実行する手順の記事で使い方と手順を確認してください。Cloudflare Containersは、自社のWebサービスの中に、利用者ごとのサンドボックスを組み込む用途で強みが出ます。

自社のKubernetesクラスタでサンドボックスを持つ選択肢もあります。その場合はランタイムの隔離を自前で設計することになり、gVisorでコンテナを隔離する仕組みとrunc・Kataの比較記事がランタイムを選ぶ際の判断材料です。運用要員を割けない体制なら、隔離と起動をCloudflareに任せられるContainersのほうが総工数は小さく済みます。

エージェントにコードを実行させる設計は、どの環境で動かすかに加えて、何を許可し、結果をどう検証するかまで決めないと事故につながります。サンドボックスの選定から権限設計、エージェント本体の実装まで一体で進めたい場合は、一創のAIエージェント開発で相談を受け付けています。

よくある質問

Cloudflare Containersを検討するときによく出る疑問を、2026年10月時点の公式ドキュメントに沿って整理しました。

Cloudflare Containersは無料プランでも使えますか？

使えません。料金のページでは無料プランの欄がN/Aになっており、ドキュメントの冒頭にもWorkers Paidプランで利用可能と書かれています。Workers Paidは月額5ドルで、メモリ25GiB時間、CPU375vCPU分、ディスク200GB時間が含まれます。検証程度ならこの範囲に収まることが多いものの、コンテナを止め忘れると超過しやすい点に注意してください。

Cloudflare ContainersとCloudflare Workersはどう使い分けますか？

Workersで済む処理はWorkersに残すのが基本です。WorkersはV8 isolateで動くため起動が軽く、料金も安く収まる仕組みです。Linuxのバイナリを呼ぶ処理、ファイルシステムを自由に使う処理、Workersのメモリ上限に収まらない処理だけをContainersへ切り出します。リクエストの入口はWorkerのまま、必要な場面でDurable Object経由にコンテナを起動する構成が想定されています。

Sandbox SDKとCloudflare Containersの関係は何ですか？

Sandbox SDK（@cloudflare/sandbox）は、Containersの上で信頼できないコードを動かすためのユーティリティ群です。刷新後の1.0では基底クラスではなく、自作のDurable Objectの中でctx.containerと併用する部品という位置付けに変わりました。ファイル操作やプレビュー用URL、R2のマウントなどを自前で書かずに済ませたい場合に使います。

コンテナは東京など特定の地域に固定できますか？

2026年10月時点のドキュメントでは、地域を指定してコンテナを置く方法は確認できませんでした。どの拠点で起動するかはCloudflare側が決める前提で設計することになります。データの保存場所に契約上の制約がある案件では、コンテナに個人情報を残さない設計にするか、別の基盤を選ぶ判断が必要です。

ローカル環境でコンテナを動かして開発できますか？

できます。ローカル開発のガイドによると、npx wrangler devでWorkerと一緒にコンテナを手元で動かせます。手元でもDocker互換のエンジンが必要です。durable_objectポリシーはWrangler 4.136.0以降、cloudflare/debian-trixieのローカル実行は4.141.0以降が条件です。非rootユーザーの権限などローカルと本番で異なる点も書かれているため、本番相当の環境で起動とスナップショットの復元を一度は確かめてください。サンプルは公式のcontainers-demosにまとまっています。

関連記事

• CloudflareでMCPサーバーを構築・公開する方法｜Workersリモートデプロイと認証・ポータル：エージェントが呼ぶツールをWorkersで公開する手順を確認できます
• Cloudflare OSとは：社内AIエージェント基盤の仕組みとローカル起動・デプロイ手順：Cloudflare上でエージェント基盤を組む全体像を押さえられます
• Kata Containersとは？軽量VMで隔離するセキュアコンテナの仕組みとgVisor・runc比較・導入判断：microVMで隔離するコンテナの考え方を自前運用の側から比べられます
• AIエージェントフレームワークとは？主要8種の比較・動作コード・選定基準：サンドボックスを呼び出す側のフレームワークを選ぶ材料になります
• Cloudflare Python Workersとは？FastAPIをエッジで動かす手順とパッケージ制約：コンテナを使わずにPythonをWorkersで動かす選択肢を確認できます