zerobootが解こうとしている問題

2026年3月17日のShow HNで、zeroboot というサンドボックス基盤が紹介された。この投稿はHacker Newsでクロール時点303 points、69 commentsを記録した。低レイヤのインフラ案件としては十分強い反応だ。その背景には、コードエージェントやツール利用型assistantが増えるほど、隔離された実行環境をどれだけ速く立ち上げられるかが、モデル推論自体と同じくらい重要になってきた事情がある。

zerobootの主張はかなり明確だ。単なる“container風の隔離”ではなく、各sandboxがハードウェア強制のメモリ隔離を持つ実際のKVM virtual machineだという。READMEによれば、まずFirecrackerベースのテンプレートVMを起動し、メモリとCPU状態を一度スナップショットする。その後のsandboxは、そのスナップショットメモリをcopy-on-writeでマッピングし、保存済み状態を復元して作る。公開値としては、spawn latency p50が0.79 ms、p99が1.74 ms、sandbox当たりメモリが約265 KB、Pythonのfork+execが約8 msとされている。

ベンチマーク表が示すもの

READMEのフックは比較表にある。zerobootはE2B、microsandbox、Daytonaより低い起動遅延と小さいメモリ使用量を主張し、1,000 concurrent forksを815 msで処理したとも記している。もちろんこれはプロジェクト自身の測定であり、READMEも現状をproduction-hardenedではなくworking prototypeと説明しているため、絶対値として断定的には扱えない。それでも方向性は重要だ。エージェントシステムは、従来型VMワークフローよりもはるかに高頻度で、短命で、かつ安全な実行環境を必要とするからだ。

設計上の面白さ

このプロジェクトの面白さは、速度と隔離モデルの両立を狙っている点にある。containerは高速だがkernelを共有し、full VMは強く隔離できる反面、起動が遅い。zerobootはsnapshot forkingでこのトレードオフをエージェント用途に十分近づけられると主張している。特に同じruntimeを何度も再利用するコードエージェントでは、この考え方はかなり実務的だ。PythonとTypeScript向けSDKもあり、self-hostとmanaged APIの両方を想定している。

一方で、制約も明確に書かれている。userspace PRNGの再seedが必要になる点、single-vCPU設計、fork内部にnetworkingがないこと、テンプレート更新にフル再スナップショットが必要なことなどだ。つまり、あらゆる安全実行問題の万能解ではない。しかし、高速で隔離された短時間計算を大量に回したいコードエージェントには十分魅力的であり、それがHacker Newsで注目された理由でもある。

原典: zeroboot README。コミュニティ議論: Hacker News。

#firecracker

Show HN: zeroboot、AI agent向けにサブミリ秒KVMサンドボックスを提案