Cloudflare Containers を再設計、起動中央値 648ms へ — 旧 Container / Sandbox クラスは 2026-12-31 まで

要約

Cloudflare は 2026-09-30、Containers のアーキテクチャをエージェント用サンドボックスのスケールを前提に再設計しました。あわせて Sandbox SDK 1.0 が公開されています。Birthday Week 2026 の発表の1つです。

性能の数字が具体的です。

ComputeSDK による第三者ベンチマークで、起動時間の中央値が4秒強から 648ms へ改善しました。約6.2倍です。さらにバースト試験では、6拠点にわたり 100,000 コンテナを 5.387 秒で起動しています。

この数字が意味することを、用途から説明します。

エージェントにコードを実行させる構成では、サンドボックスの起動時間がそのまま応答時間に乗ります。 「このスクリプトを実行して結果を見せて」という依頼に対し、起動に4秒かかれば、ユーザーは4秒待ってから処理が始まるのを待つことになります。648ms なら、体感として「すぐ始まった」の範囲に入ります。

同時起動の数字は、別の問題に効きます。 多数のユーザーがそれぞれのサンドボックスを必要とする構成では、ピーク時に大量の起動が同時に発生します。 従来はここで待ち行列ができました。

新機能は4つあります。

1つ目、durable_object スケジューリングポリシー。 サンドボックスごとのイメージとインスタンス種別を、デプロイ時ではなく実行時に選べるようになりました。従来は、環境ごとに別アプリ・別デプロイを用意する必要がありました。 「Python 環境と Node 環境を両方提供したい」というだけで、2つのアプリを管理することになっていました。これが1つのアプリで済みます。

2つ目、ファイルシステムのスナップショット（パブリックベータ）。 作業環境を保存・復元できます。エージェントがセッションを跨いでセットアップをやり直さずに済むようになります。

この機能の価値は、依存関係のインストール時間を考えると明確です。 エージェントに作業させるたびに npm install や pip install から始めるのは、時間もコストも無駄です。一度整えた環境をスナップショットとして保存し、次回はそこから始めるという構成が可能になります。

3つ目、既製のシステムイメージ。 cloudflare/debian-trixie（Debian Trixie Slim + Node.js 24.20.0 LTS）が用意され、独自 Dockerfile なしで起動できます。 試すまでの手数が減ります。

4つ目、Sandbox SDK 1.0。 自前で定義した Durable Object クラスから、サンドボックスを直接管理できます。 制御できる範囲は広く、イメージとサイズの決定、スナップショット、ライフサイクル管理（タスク完了やユーザーの活動状況を基準に終了タイミングを開発者が決める）、コマンド実行（入出力のストリーミング、シグナル処理、ブラウザからのターミナル接続）、ポートプレビューへの独自ホスト名と認証、そして外向きリクエストを Worker 側のコードで処理して資格情報とバインディングを保護する構成が含まれます。

最後の点は、セキュリティ設計として重要です。 サンドボックス内で動くコード（エージェントが生成したコードを含む）に資格情報を渡さず、外部通信は Worker 側で代行する。 エージェントが生成したコードを実行する構成では、コードが資格情報を読める状態にしないことが前提になります。

アーキテクチャの変更点。 各コンテナは引き続き Durable Object に紐づきますが、再設計で Durable Object が開発者体験の表側に出ました。 そして、新機能は従来クラスではなく ctx.container 経由でのみ利用できます。

そして、期限です。

旧 Container クラスと旧 Sandbox クラスは、2026-12-31 までメンテナンスされます。 以降は、既存のデプロイは動作し続けますが、更新は提供されません。 Sandbox SDK 0.x についても、バグ修正とセキュリティ修正は 2026-12-31 までとされています。段階移行と一括移行の両方に対応した移行ガイドが用意されています。

何が変わったか

• 起動時間の中央値が4秒強から 648ms へ（ComputeSDK の第三者ベンチマーク、約6.2倍）
• 6拠点で 100,000 コンテナを 5.387 秒で起動（バースト試験）
• durable_object スケジューリングポリシー: イメージとインスタンス種別を実行時に選択可能（従来は環境ごとに別アプリ・別デプロイが必要）
• ファイルシステムのスナップショット（パブリックベータ）: 作業環境の保存・復元
• 既製システムイメージ cloudflare/debian-trixie（Debian Trixie Slim + Node.js 24.20.0 LTS）: 独自 Dockerfile 不要
• Sandbox SDK 1.0: 自前の Durable Object クラスからサンドボックスを制御
  • イメージ / サイズの決定、スナップショット、ライフサイクル管理
  • コマンド実行（入出力ストリーミング、シグナル処理、ブラウザからのターミナル接続）
  • ポートプレビューへの独自ホスト名と認証
  • 外向きリクエストを Worker 側で処理し、資格情報とバインディングをサンドボックスへ渡さない
  • 同一 Durable Object 内でエージェントを動かし、サンドボックス操作をツールとして提供
• 新機能は ctx.container 経由でのみ提供（従来クラスからは使えない）
• 期限: 旧 Container / 旧 Sandbox クラスのメンテナンスは 2026-12-31 まで（以降は既存デプロイは動作するが更新なし）
• 期限: Sandbox SDK 0.x へのバグ・セキュリティ修正も 2026-12-31 まで

業務インパクト（一般企業向け）

Cloudflare Containers または Sandbox SDK を使っている組織には、期限付きの作業が発生しました。2026-12-31 です。残り3か月です。

まず、期限の性質を正確に読んでください。 2026-12-31 を過ぎても、既存のデプロイは動作し続けます。 サービスが止まるわけではありません。止まるのは「更新」です。

これは「動いているから放置してよい」という意味ではありません。 公式が明記しているのは、Sandbox SDK 0.x へのバグ修正とセキュリティ修正も 2026-12-31 までという点です。つまり 2027-01-01 以降は、セキュリティ修正が提供されません。

サンドボックスは、信頼できないコードを実行する場所です。 エージェントが生成したコード、ユーザーが投稿したコード、外部から渡されたスクリプト。この種の実行環境にセキュリティ修正が来なくなる状態を、意図して選ぶ組織は少ないはずです。 期限の重みは、ここにあります。

移行の優先度の付け方を書きます。

最優先は、信頼できないコードを実行している構成です。 セキュリティ修正の停止が直接のリスクになります。次が、新機能を使いたい構成です。 スナップショットや実行時のイメージ選択は ctx.container 経由でのみ提供されるため、旧クラスのままでは使えません。 最後が、内部用途で安定稼働しているものです。これは期限内に移せば十分です。

移行作業の見積もりについて。 公式は段階移行と一括移行の両方に対応した移行ガイドを用意しています。段階移行が可能ということは、全部を一度に切り替える必要がないという意味です。 3か月あれば、本番トラフィックの一部から順次移すという進め方が取れます。

新機能を前提にした設計の見直しも、同時に検討する価値があります。

実行時のイメージ選択は、アプリの構成を単純にします。 現在、環境ごとに別アプリを用意している組織は、移行を機に統合できます。 管理対象のデプロイが減ることは、それ自体が運用コストの削減です。

スナップショットは、コスト構造に効きます。 エージェントの実行ごとに依存関係をインストールしている構成では、その時間がそのまま課金対象です。 スナップショットから始めれば、この分が消えます。実行回数が多い構成では、削減幅が大きくなります。

「外向き通信を Worker 側で代行する」構成は、セキュリティ審査の観点で重要です。

エージェントが生成したコードを実行する構成を社内で通すとき、最も問われるのは「そのコードが何にアクセスできるか」です。 サンドボックス内に API キーがあれば、生成されたコードがそれを使えることになります。意図しない外部送信を防ぐ手段がありません。

資格情報を Worker 側に置き、サンドボックスからの外向き通信を Worker が代行する構成なら、「サンドボックス内のコードは資格情報を読めない」と説明できます。 これは審査を通しやすい設計です。移行の際に、この構成へ寄せる価値があります。

最後に、起動時間の改善をどう評価するかについて。

648ms という数字は、エージェント機能の UX を変える水準です。 4秒の待ちは「遅い」と認識されますが、648ms は処理の一部として埋もれます。 これまで「起動が遅いから」という理由で見送っていた機能設計が、再検討の対象になります。

具体的には、「毎回新しいサンドボックスを作る」という設計が選べるようになります。 起動が遅い環境では、サンドボックスを使い回す設計（状態が残る、前の実行の影響を受ける）を選ばざるを得ませんでした。起動が速ければ、毎回作って捨てる方が安全です。 セキュリティと再現性の両面で望ましい設計が、性能の改善によって現実的になりました。

副業・個人活用視点

個人開発でエージェント機能を作る場合、この更新は実装のハードルを下げます。

「コードを実行できる AI ツール」を個人で作ろうとすると、実行環境が最大の難所です。 自分のサーバーで実行すれば、生成されたコードにサーバーを好きにされます。 Docker で隔離しても、コンテナからの脱出やリソースの食い尽くしへの対策が必要です。 この部分を自力で安全に作るのは、個人の工数では現実的ではありません。

マネージドなサンドボックスを使うのが、ほぼ唯一の現実的な選択です。 そして起動が 648ms で、既製イメージがあり、Dockerfile も不要なら、着手までの距離がかなり短くなります。

cloudflare/debian-trixie の存在は、個人開発では特に大きいです。 Dockerfile を書いてビルドしてプッシュする工程は、初めてやると半日かかります。 それが不要なら、週末で試せる範囲に入ります。

スナップショットは、個人の予算で効きます。

従量課金で動かしていると、依存関係のインストール時間が毎回課金されます。 個人のプロジェクトでは、この種の無駄が月の請求額を押し上げる主因になりがちです。 一度整えた環境を保存して再利用できれば、実行あたりのコストが下がります。 無料枠の範囲で動かせるかどうかの境界が変わる可能性があります。

受託・支援の文脈では、2026-12-31 という期限が案件になります。

Cloudflare Containers または Sandbox SDK を使っているシステムを納品している場合、移行作業が必要です。 これは明確な作業範囲と期限がある仕事です。「セキュリティ修正が 2026-12-31 で止まります」は、顧客へ説明しやすい理由です。

提案の組み立て方。 (1) 現状の利用箇所を洗い出す（旧 Container / 旧 Sandbox クラスを使っている箇所）。(2) 信頼できないコードを実行している箇所を特定し、優先度を付ける。 (3) 段階移行の計画を出す。 (4) 移行と同時に、資格情報を Worker 側へ寄せる構成へ改める。

4番目を提案に含めることが、差別化になります。 単なる移行作業は、公式の移行ガイドに沿った作業であり、価格競争になります。 「移行と同時にセキュリティ設計を改善する」という形にすれば、作業ではなく設計の提案になります。

学習の観点では、「起動が速くなると設計の選択肢が変わる」という因果を押さえる価値があります。

性能改善は、たいてい「同じことが速くなる」と理解されます。 しかし実際には、遅さが理由で選べなかった設計が選べるようになるという形で効きます。

今回の例では、「毎回作って捨てる」設計です。 起動が遅い前提では、使い回しを選ぶしかありませんでした。使い回しは、前の実行の状態が残るため、デバッグが難しく、セキュリティ上も望ましくありません。 それでも性能のために選んでいた妥協です。

この構造は、他の場面でも繰り返されます。 「起動が速くなったからサーバーレスが選べる」「デプロイが速くなったから小さく分割できる」。性能の数字を見たとき、「何が速くなったか」ではなく「どの妥協をやめられるか」を考える習慣が、設計判断の質を上げます。 個人開発では妥協の積み重ねが負債になりやすいため、この視点は特に効きます。