めもおきば 技術同人誌と記事のアーカイブ
About

Digital Appendix

『AIエージェントが見つけたサーバーレス』のデジタル付録

A-RUNTIME-06 版 0.12.1

エージェントサンドボックスの実行粒度

エージェントサンドボックスの実行粒度

対象本文

第4章4.3〜4.6が扱う「隔離技術の共有面」「何を一回の実行と数えるか」「持続する作業空間と交換可能な実行面の分離」を、2026年時点の製品へ重ねた比較です。製品の機能を排他的に分類する表ではありません。 同じ基盤が短命コマンドと長命セッションの両方を扱うため、「設計の重心」は公式APIとライフサイクルから読んだ本書の解釈です。

収集方法

2026年7月12日にCloud Run Sandboxesの発表、リリースノート、公式ガイド、CLIリファレンスと、既存四社の検証台帳A-22〜A-25を照合しました。Cloudflare Sandbox SDKはGA記事、Architecture、Lifecycle、Sessions、Outbound traffic、Container runtime、directory backup/restoreも再確認しました。2026年8月5日に@cloudflare/computerの公式ブログ(2026-08-03)と公式リポジトリREADMEを照合しました(検証台帳A-37)。2026年8月9日にCloud Runの発表ブログとリリースノートを再照合し、2026年8月5日の全リソース対応を追記しました。発表ブログの日付は2026年7月9日と10日が併存するため、一方を正しい発表日として固定しません(検証台帳A-28)。提供者ごとに条件の違う性能値は横並びにせず、公式APIとライフサイクルから実行粒度を比較します。

現在の答え

六つの実装を、実行粒度で読む

基盤APIで前に出る単位既定のライフサイクルと状態隔離の土台本書から見た重心
Google Cloud Run Sandboxes(Public Preview)既存Cloud Runサービス内から呼ぶコマンド。sandbox doのほか、名前付きサンドボックスへのrun/execもあるdoは作成→実行→削除。一時overlayは削除時に失われ、tarの入出力やbind mountで必要なファイルだけ渡せる。切り離した長時間プロセスも可能Cloud Run第2世代環境が前提。内側のサンドボックス実装方式は公開資料で特定されていないCommand/Task寄り。親アプリケーションから見ると、隔離境界を持つサブプロセスに近い
AWS Lambda MicroVMs専用エンドポイントを持つマイクロVM環境スナップショットから起動し、セッションをsuspend/resumeできるFirecrackerマイクロVMセッション/実行環境。ライフサイクルを持つ環境そのものを借りる
Google GKE Agent SandboxKubernetes上のSandboxオブジェクトPod Snapshotsと組み合わせて状態を保存・再開できるgVisorをネイティブ対応、ほかのランタイムも差し替え可能セッション/クラスタ上の実行環境。配置と運用の制御をKubernetes側に残す
Azure Container Apps dynamic sessionsプールから割り当てられるセッションクールダウン後に破棄し、次回はプールから別環境を割り当てるHyper-V隔離セッション。暖めた環境のプールで割り当てを速くする
Cloudflare Sandboxes(GA)Durable Objectの識別子に結びついた名前付きsandbox。exec()、per-task、per-sessionの使い分けがある稼働中はファイル・プロセス・実行文脈を保持。アイドル停止後のコンテナ状態は失われるため、必要なディレクトリはbackup/restoreや外部ストレージへ出す専用Linuxコンテナ。現行Architecture文書は各sandboxをVMベースで隔離すると説明Command〜Workspace。一回のコマンドから端末、開発サーバ、ファイル監視まで同じAPI面で扱う
Cloudflare Computer(Early Preview)Workspace——Durable Object内のSQLiteを正本とする仮想ファイルシステム。実行は共通のexecからWorkspaceが正本として持続し、実行バックエンドは最初の利用時に遅延接続。containerにはFUSEでWorkspaceを投影し、変更を正本へ同期Dynamic Worker上のisolate(shell/JavaScript)と、Linuxコンテナの併用。独自バックエンドも登録可能Workspace/Computer。作業空間を正本に置き、実行面を仕事に応じて交換する

上の「重心」は能力の上限ではありません。Cloud Runは名前付きの長時間sandboxを動かせますし、Cloudflareは一回きりのコマンドを実行後すぐ破棄できます。違いがよく出るのは、最短のサンプルと、状態を持たせたいときに追加で何を指定するかです。

2026年8月5日の更新: Cloud Runのリリースノートは、ジョブとワーカープールを含むすべてのリソースでサンドボックスを使えるようになったことをPreviewとして案内しています。上の表の「APIで前に出る単位」と「隔離の土台」は、この更新の前、サービスの内側から呼ぶ形を前提にした記述です。紙面(初版第1刷、2026年8月7日入稿)も同じ前提で書いています。

Cloudflare Computer——Workspaceと交換可能な実行面

2026年8月3日にEarly Previewとして公開された@cloudflare/computerは、Sandbox SDKとは抽象化の主語が異なります。「論理的に何が残るか」「状態の正本はどこか」「実行面をどう選ぶか」で並べると、次のようになります。

基盤/抽象化論理的に残る単位実行面状態の正本バックエンド選択提供状態
Cloudflare Sandbox SDKSandbox ID(Durable Object)Cloudflare Container稼働中のcontainer。必要な永続状態はbackup/restoreや外部ストレージへ出すsandbox作成時の構成GA
Cloudflare ComputerWorkspace(仮想ファイルシステム)isolate shell、isolate JavaScript、container。独自バックエンドも登録可能Durable Object内のSQLite共通execのbackend指定。エージェント利用ではツール説明を通じてモデルが選ぶEarly Preview。API不安定・本番利用非推奨
Cloud Run Sandboxesコマンド、または名前付きsandbox既存Cloud Runインスタンス内のsandboxコマンドの入出力、または名前付きsandboxの稼働中状態呼び出し側がAPI経路を選ぶPublic Preview

安定して読める構造

揮発情報として管理するもの

Cloud Run SandboxesとCloudflare Sandbox SDK——host-firstとsandbox-first

Cloud Run Sandboxesは、すでに動いているCloud Runインスタンスをスケール・課金・資源割り当ての単位に保ち、その内側へ実行境界を差し込みます。本書ではこの向きをhost-firstと呼びます。親アプリケーションから見た「安全なfork/exec」は、実装方式ではなく、危険なsubprocess.run()を境界付きの実行へ置き換える利用感の比喩です。

Cloudflare Sandbox SDKは、IDを持つsandboxを取得し、その内側でコマンド、ファイル、プロセス、公開サービスを扱います。本書では、境界そのものをシステムの主語にするこの向きをsandbox-firstと呼びます。Durable Objectの論理IDが残ることと、稼働中コンテナのファイル・プロセス・shell状態が残ることは別の実行モデルです。

軸Cloud Run SandboxesCloudflare Sandboxes
呼び出し関係host-first。同じCloud Runインスタンス内の親アプリケーションがCLIをローカルに呼ぶ。sandboxは親に割り当てられたCPUとメモリを共有するsandbox-first。WorkerがDurable Objectを介して、名前付きの専用コンテナを操作する。sandboxの識別子とライフサイクルが第一級に見える
最短経路sandbox doが一時sandboxの作成、コマンド実行、削除をまとめるgetSandbox(id)で環境を得てexec()する。初回参照で起動し、同じIDへの後続呼び出しは同じ稼働中環境へ届く
長時間実行--detachで名前付きsandboxを残し、sandbox execで追加コマンドを送れるstartProcess()、PTY、公開URL、ファイル監視、永続コード文脈を同じsandboxで扱う
ファイル親コンテナのrootfsは既定で読み取り専用。書き込みは一時tmpfs overlayで、削除時に失われる。tarまたはbind mountで明示的に橋を架ける稼働中のLinuxファイルシステムは読み書き可能。コンテナ停止時には失われるため、backup/restoreやbucket mountを使う
出口と資格親の環境変数・Secret・メタデータサーバへは既定で到達できず、外向き通信も既定拒否。必要なコマンドだけ明示的に開くinternet accessは既定で許可。enableInternet = false、host allowlist/denylist、出口proxyによる資格注入を組み合わせられる
保存対象現行のtar/snapshot操作が保存するのは変更されたファイルシステム。メモリや実行中プロセスの復元ではない2026年4月のGA記事はVMレベルsnapshotを「今後数週間で展開」とし、将来のメモリ状態保存も予告した。確定済みとして扱えるのはディレクトリのbackup/restoreまでで、現行提供状況は再確認が必要
課金の見え方sandboxは親Cloud Runインスタンスの割当資源上で動き、機能利用の追加premiumはないと発表ブログが説明Active CPU Pricingを採り、アイドルCPUを課金対象から外すとGA記事が説明。単価と各資源の扱いは入稿直前に再確認する

ここから「Cloud Runは安全なfork/exec、CloudflareはAPIで操作する一時的なLinuxホスト」という対比が導けます。ただし、これは公式の製品定義ではなく、境界の置き場所と設計の重心をつかむための比喩です。Cloud Runにも長命モードがあり、Cloudflareにも一回のexec()、per-task sandbox、明示的な破棄があるという但し書きを外すと、比較はすぐ不正確になります。

ネットワークの違いも、この主語から読めます。Cloud Runが先に問うのは「この一回の命令に通信が必要か」です。Cloudflareが先に問うのは「このLinux環境の通信を、外側のWorkerがどのポリシーで仲介するか」です。前者は単純なdeny-by-default、後者は既定では開きながら、宛先制御と資格注入をプログラムできる境界です。

状態の寿命——statefulかstatelessかで分けない

Cloud Runは、親rootfsの読み取り専用参照、一時overlay、tar入出力、mountを使い、次の実行へ渡す状態を明示します。Cloudflareは、コンテナがactiveな間はファイル、プロセス、shell session、環境変数を保持します。しかし、既定では10分の非活動後にコンテナが停止し、次の要求ではfresh containerが起動するため、実行時状態は失われます。keepAlive、directory backup/restore、bucket mountは、この既定へ別の寿命を足す機能です。

したがって比較軸は、状態があるかどうかではありません。状態の寿命をコマンドの入出力へ結びつけるか、sandboxの稼働期間へ結びつけるかです。Cloudflareの論理IDを、メモリ・プロセス・ファイルシステムの永続性と読み替えません。

実行粒度——CommandからWorkspaceまでの連続体

粒度境界と状態の単位Cloud Run SandboxesCloudflare Sandbox SDK
Command一つのコマンドが終われば破棄sandbox doが最短経路exec()後にdestroy()する短命利用
Taskビルドや検証など一つの仕事名前付きsandboxへ複数のexecを送り、完了後に破棄per-task IDでbuild、pipeline、background jobを対応付ける
Session一人または一会話の対話期間detachしたsandboxを親インスタンスの寿命内で再利用per-session IDや明示sessionでshell状態を整理する
Workspace長時間の作業場と外部状態長命processは可能だが、親Cloud Runインスタンスの資源・寿命から独立しないkeepAlive、公開port、file watch、外部storageを組み合わせる

この表も能力の排他分類ではありません。どちらのサービスを選ぶかより先に、あなたの仕事がどの粒度で境界、状態、資格、ネットワークを共有してよいかを決めます。

既知の未知

一次資料

変更履歴

付録索引へ戻る / 書籍サポートへ戻る