Cloudflare Sandbox SDK 1.0：実行状態・snapshot・移行の境界

sandboxには状態、権限、寿命がある

Cloudflareは2026年9月30日にSandbox SDK 1.0を告知した。agentやcode executionのサービスで重要なのは、SDKの番号が上がったことだけではない。sandboxを所有するDurable Objectへ運用の中心を寄せる点である。告知によれば、そのclassはcontainerを開始するときにimageとinstance sizeを選び、停止時期を決め、commandの入出力をstreamし、preview portをWorker側で扱える。

ここで先に問うのは「どのDurable Objectがこの実行をresume、inspect、stop、publishしてよいか」である。containerは匿名の一時directoryではない。filesystemには未完のbuild、生成物、cache、廃棄すべき入力があり得る。previewはnetworkに届くcapabilityになり得る。outbound requestは外部systemに触れ得る。これらを一語で「agent sandbox」と呼ぶと、別々に検証すべき境界が消える。

1. 1認証済みtask
2. 2所有Durable Object
3. 3imageとinstanceの選択
4. 4container実行

1. 1container filesystem
2. 2immutable snapshot handle
3. 3明示的restore
4. 4新しい実行

1. 1preview port
2. 2Workerのhostnameと認証
3. 3許可されたviewer

1. 1task完了またはidle policy
2. 2stop判断
3. 3snapshot保持または破棄記録

既存のCloudflare基礎章はroute-to-bindingの権限とdeployの証拠を説明している。この更新が補うのは、動いている実行環境自身の状態遷移とrecoveryの契約である。Workerのdeployが成功しても、どのfilesystemをresumeしたか、internet accessを有効にしたか、古いsandboxが残っているかは証明されない。

SDKの提供開始とbeta機能を分ける

9月30日の記事はSandbox SDK 1.0 is available と述べる。同時にcontainer snapshotとdurable_object scheduling policyをpublic betaと明記する。これを「Sandbox 1.0の全てがGA」と言い換えてはいけない。package versionの提供、runtime featureのbeta status、特定accountでの利用可否は別の事実である。

scheduling policyの告知は、application全体の一つの設定ではなく、Durable Objectがruntimeでimageとinstance sizeを選べると説明する。また、この方式のinstanceは独立したlifecycleを持ち、application-wide image rolloutには参加しないとされる。これはrelease reviewを変える。imageをdeployしただけでは、実行中の環境がrestartや置換されたとは限らない。taskごとにimage reference、instance、owner object、終了理由を記録する。この記事からcapacity、隔離強度、uptime、account availabilityを推測しない。

同じ告知はcontainer開始時のenableInternetを明示的な選択として示す。これは便利なdefaultではなくauthority decisionとして扱う。checked-in sourceとlocal compilerだけが必要なbuildと、allowlistしたartifact registryへ接続するtaskではoutbound boundaryが異なる。一次資料は普遍的なegress policyを定めない。application側でpolicyを決め、害のないdeny caseで確かめる。

snapshotはrecovery inputであり、書き換えるworkspaceではない

別のsnapshot更新は、point-in-timeのcontainer filesystemを保存・restoreするpublic-beta APIを説明する。snapshotはdurable_object scheduling policyを使うContainer applicationに限られ、immutableである。したがってrestore後にfilesystemを変えても、過去のcheckpointを黙って更新できない。その変化を保存するには新しいsnapshotが必要になる。

bareなsnapshot handleだけでなく小さなstate ledgerを持つ。checkpointごとにtask ID、owner、source revisionまたはinput digest、image reference、作成時刻、restore目的、retention判断、許可したpolicyを残す。secret値はsnapshot record、source repository、preview URL、agent-visible logへ書かない。必要ならsecretの名前だけを設計に記す。SDK記事はoutbound requestをWorker codeで扱いcredentialとbindingをWorkerに残せると説明するが、全applicationが正しく分離できている証明ではない。

snapshotもreproducible buildの証拠ではない。filesystem stateは残しても、user authorization、input provenance、network effect、imageの挙動、そのstateを作ったcommandを識別しない。restoreしたrunにはrestoredという状態を付け、artifact公開や外部actionの前にfresh runと同じoutput checkとauthorization checkを通す。

状態を動かす前にmigrationをrehearseする

SDK 1.0の記事は0.x applicationが継続して動き、2026年12月31日までbug/security fixを受けると述べる。同時に既存classを新policyへ移す操作はone-wayであり、rehearsalを勧めている。one-wayは本番taskで即座に移行してよいという意味ではなく、移行前に観察すべき性質である。

実際のmigrationの前にdisposable fixtureを作る。次はofflineで未実行の計画用fixtureであり、command例でもCloudflare account設定済みの証拠でもない。

fixtureの状態	確かめること	合格時の観測
snapshotなしの新owner	選んだimage、size、明示的network policyで開始する	run recordにownerと設定が残る
終了したdisposable task	checkpointを作る	source/input identityとsnapshot handleが記録される
restoreしたcheckpoint	害のないoutput fileを変更して再checkpointする	二つ目は新handleで、一つ目は古い状態のまま
未認可viewer	preview hostnameを要求する	Worker側の認証が拒否する
migration rehearsal	本番ではない使い捨ての状態を使い、対象の1.0 classだけを隔離して試す	不可逆な移行の前に、対象状態と中止・不採用の条件を記録する

このfixtureはcontainerが完全なsecurity boundaryである、previewが安全である、snapshotがどのfile classを含む・除く、と主張しない。実装前にcurrent documentationとaccount termsを読む。実際に使うimage、outbound host、storage mount、preview authentication、command policy、retention period、deletion pathをそのまま試験対象にする。

実装後に測るもの

最初の本番問いは「agentが終えたか」ではない。taskがauthorizeされていたか、どのexecution stateを使ったか、snapshotがnewかrestoredか、どのnetwork policyだったか、outputが固有のvalidationを通ったかを残す。start/recovery failureとstale checkpoint rejectionはmodelやbuildのsuccessと別に測る。別principal、期限切れauthorization、変更されたinput digest、拒否すべきpreview requestでrestoreを試す。

9月30日の資料はCloudflareのrelease signalであり、独立したsecurity evaluationやperformance measurementではない。それでもowner、image、instance、network policy、snapshot、restore、retention、stop、migrationという具体的な語彙を与える。アプリケーションは各状態遷移を認可して観測可能にし、policy classの移行を不可逆な操作として扱う必要がある。