AgentENV解説｜Firecracker microVMをforkして並列実行するE2B互換のエージェント基盤

AIエージェントに実際のコードを実行させるとき、環境をどう用意するかは「1つを安全に起動する」問題として語られがちだ。だが強化学習（RL）でエージェントを訓練する側から見ると、問題の形が変わる。同じ環境を何千何万と並べ、待機中のコストを限りなくゼロに近づけ、途中状態から何本にも枝分かれさせる必要が出てくる。2026年7月23日に公開されたkvcache-ai/AgentENV（AENV）は、この後者の問題を正面から扱うRust製のOSSだ。READMEは自らを「Kimi K3のagentic RL学習を支える基盤」と説明している。

エージェント基盤全体の中でどこに位置するツールなのかは、AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証で整理している。本記事はそのうち「エージェントを走らせる土台」の側を、AgentENVの一次資料（README・同梱ドキュメント・ソースコード）から読み解く。

AgentENVとは｜Kimi K3のagentic RL学習を動かすサンドボックス基盤

AgentENVは、AIエージェント向けの自ホスト型サンドボックスランタイムだ。1つのサンドボックスは独立したLinuxカーネル・ファイルシステム・ネットワークスタックを持つFirecracker microVMであり、コンテナのようにホストのカーネルを共有しない。

開発元のkvcache-aiは、限られたVRAMで巨大MoEモデルを動かす推論最適化で知られるラボで、当サイトでもKTransformers解説｜24GB VRAMでDeepSeek-R1級MoEを動かすCPU/GPUヘテロ推論として扱っている。推論側の最適化を手がけてきた同じラボが、今度はエージェントを学習させる側の環境基盤を出してきた、という位置づけになる。

リポジトリの実測値

2026年7月28日時点でGitHub APIから取得した実測値は次のとおり。

公開から5日でv0.1.0という段階であり、成熟したプロダクトではない。この記事で扱うのは「完成度」ではなく設計の中身である点を先に断っておく。

設計の出発点は「待機中を安くする」

同梱ドキュメントが挙げる設計目標は4つある。

・多様な環境を横に並べる：多数のFirecracker環境を複数マシンにまたがって走らせ、OCI互換イメージをoverlaybd経由でオンデマンドに読み込む
・待機中の環境を安くする：スナップショットを土台にした環境は起動・再開が高速で、待機中はCPUとメモリを解放できる
・スナップショットとforkを標準装備する：走行中の環境を複数の独立したサンドボックスへ分岐させ、スナップショットはS3互換ストレージや共有分散ファイルシステムへ永続化する
・時間が経っても性能と密度を保つ：ublkによるI/Oとホストページキャッシュの共有、メモリバルーニングによる高オーバーコミットの維持

forkとスナップショット｜走行中のサンドボックスを最大16個へ分岐させる

AgentENVの機能で最も特徴的なのがforkだ。一般的なサンドボックスOSSは「起動」「停止」「破棄」を提供するが、AgentENVは走行中の状態をそのまま複製して枝分かれさせる操作を一級市民として持つ。

サンドボックスのライフサイクルには、Forking と Snapshotting が独立した状態として定義されている。

Snapshotting と Forking の矢印がどちらも Running へ戻っている点が重要で、親のサンドボックスは分岐後も生き続ける。スナップショット取得時も Running → Snapshotting → Running と遷移し、取得が終われば走行を継続する。取得に失敗した場合、回復可能な失敗ならサンドボックスは走行したままエラーだけが呼び出し元へ返り、安全に再開できないところまでランタイムが変更された致命的な失敗ならサンドボックスは破棄される、と挙動が分けられている。

forkの境界線

forkはHTTP APIで呼ぶ。count に分岐数を渡す。

curl -X POST \
  -H 'X-API-Key: test-key' \
  -H 'Content-Type: application/json' \
  -d '{"count": 3}' \
  http://127.0.0.1:8000/sandboxes/<sandbox-id>/fork

ここで制約をぼかさずに書いておく。forkの上限は16個、かつ同一ノード内に限られる。fork中は元のサンドボックスが短時間pauseされ、複製の取得後にRunningへ戻る。子はすべて親のファイルシステム・メモリ・リソース構成を引き継ぐ。

この上限は、AgentENVを「RLのロールアウトを分岐させる基盤」として見るときの境界そのものだ。1つの中間状態から16通りの続きを試すのは1回のAPI呼び出しで済むが、それ以上に広げたい場合や、分岐先を複数ノードへ散らしたい場合は、fork単体では足りずスナップショットを介した設計が必要になる。

スナップショットが土台になっている

ドキュメントはスナップショットを「唯一の永続的なランタイム基本要素」と位置づけ、他の概念がその上に乗ると説明する。

・テンプレートはスナップショットとして保存され、テンプレートIDはそれを指す別名にすぎない
・サンドボックスはスナップショットからのresumeとして起動する
・走行中のサンドボックスは新しいスナップショットを産み、後の再利用や分岐の起点になる

つまり「テンプレート」「pause/resume」「fork」は別々の機能ではなく、スナップショットという1つの仕組みの見せ方が3通りあるという構造になっている。CLIから触るとこうなる。

# 走行中サンドボックスの状態を名前付きで保存
aenv snapshot create <sandbox-id> --name my-checkpoint

# 保存した状態から新しいサンドボックスを起動
aenv start my-checkpoint

# 一時停止と再開（状態は保たれる）
aenv pause  <sandbox-id>
aenv resume <sandbox-id>

pauseが捉えるのは走行中VMのメモリスナップショットと書き込み可能なファイルシステム層のディスクスナップショットの2つで、resumeすると実行中のプロセスや開いたネットワーク接続を含めて中断地点から再開する、とドキュメントは説明している。

待機中を安くする仕掛け

すべてのサンドボックスにはTTLがあり、満了時の挙動を選べる。既定はpause（状態を保って一時停止）で、autoPause: false を渡すとkill（完全に削除）になる。この既定値の選択は「待機中の環境を安くする」という設計目標をそのまま反映している。使われなくなった環境を捨てるのではなく、資源だけ解放して状態は残す方向に倒してある。

overlaybdとublkで、ディスク容量を超えるイメージをオンデマンドに読む

ここがAgentENVで最も作り込まれている部分で、リポジトリの実装量もストレージ層に集中している。狙いは単純で、ノードのローカルディスクを「保管場所」ではなく「上限つきキャッシュ」として扱うことだ。

overlaybd：LSMTベースの階層イメージ形式

overlaybdは、ログ構造化マージツリー（LSMT）を土台にした階層イメージ形式だ。各レイヤーファイルはヘッダー／トレーラー（マジック LSMT\0\1\2、UUID、フラグ、インデックスとデータのオフセット）と、16バイトのセグメントマッピング配列で構成される。マッピングはビット単位で詰め込まれており、オフセットに50ビット、長さに14ビットといった具合に割り当てられている。

レイヤーは下に読み取り専用の圧縮済みレイヤーを積み、最上段に書き込み可能なupper層を1つ置く。読み出しはセグメントインデックスを使って上から下へ探索し、要求されたブロック範囲のマッピングを最初に持っていたレイヤーがデータを返す。上位レイヤーで未マッピングの範囲は下位へ落ちる。書き込みはすべてupper層へ追記される。

圧縮はzstd（レベル3）で、ランダムアクセス用のジャンプテーブルとCRC32Cチェックサムを併せ持つ。バックエンドは差し替え可能で、io_uringのpread/pwriteを使うローカルファイル、OCIレジストリからのリモート取得、tarアーカイブ読み出しが実装されている。

ublk：ユーザー空間でブロックデバイスを提供する

overlaybdのイメージをVMから普通のブロックデバイスとして見せる役目がublkだ。Linuxカーネルのublkドライバを使い、/dev/ublkbN を生やす。デバイス生成はio_uringの UringCmd で /dev/ublk-control に ADD を送るところから始まり、カーネルがデバイスIDを払い出して制御用とブロック用のデバイスノードを作り、キューごとのワーカースレッドが起動する。カーネルはmmapされたI/Oディスクリプタ配列へブロックI/Oを投げ、ユーザー空間側が非同期に処理する。

ゼロコピー用のバッファはカーネル6.8以降で使える仕組みに依存している。AgentENVがカーネル6.8以降を要求する理由の一端はここにある。

ublkデバイスの所有権とio_uringの制御は uvm-ublk-daemon という専用プロセスに切り出され、ノード本体とはUnixドメインソケットで会話する。ノード側はライフサイクルの指揮に専念し、デバイスIDの払い出しはデーモン側で行う、という分業になっている。

オンデマンド読み込みの設定

共有ストレージからのオンデマンド読み込みは設定ファイルで有効化する。POSIXFSとOSS（S3互換）の2系統がある。

[snapshot]
repository_backend = "posix_fs"

[backend.posix_fs]
snapshot_store = "/mnt/aenv-snapshots"

[image.cache.remote_blocks]
max_size_gb = 100

ドキュメントはストレージ回線について「最低1Gbps、10Gbps以上を強く推奨」と明記している。ローカルディスクをキャッシュとして扱う設計は、裏を返せばキャッシュミス時のコストがネットワークに乗るということで、回線要件はこの設計の代償にあたる。

メモリスナップショットの復元をublkでやる、という選択

技術的に一番おもしろいのはここだ。VMのメモリスナップショットを復元する実装として、AgentENVはuserfaultfdではなくublk上のoverlaybdデバイスを使っている。

resume時、積み重なったメモリレイヤーから読み取り専用のublkデバイスを作り、それをFirecrackerにファイルバックエンドのメモリとして渡す。Firecrackerはこのブロックデバイスをmmapし、最初の書き込み時に匿名メモリへコピーオンライトする。元のデバイスは書き換えられない。

この作りの効き目は共有にある。同じスナップショットから起動する複数のサンドボックスが、参照カウントで1つのメモリublkデバイスを共有する。結果としてLinuxのページキャッシュが全サンドボックスで再利用され、同一テンプレートから同時に大量起動したときのI/Oが大きく減る。「同じ環境を何千と並べる」という設計目標に対して、ストレージ層から直接効かせにいく設計になっている。

pause側では、Firecrackerネイティブの差分スナップショットが疎な mem.bin（内部的にmincoreで存在するページを判定する）を作り、それをoverlaybdレイヤーへ変換する。過去のスナップショットの親レイヤーが積み重なって、階層化されたメモリイメージができあがる。

スナップショットの三層構造と、複数ノードへのスケールアウト

保存場所は3つに分かれている

スナップショットの保存を1つのストアとして考えると混乱する、とドキュメントは注意を促し、3つの層に分けて説明している。

・ビルダー作業域：1回のビルドを実行する間だけ使う一時領域。ビルダーの実装詳細であり、永続的な記録ではない
・コミット済みスナップショットリポジトリ：ビルドが公開された後の永続状態。テンプレートAPIが包んでいる唯一の正
・ノードローカル実行キャッシュ：起動直前に、コミット済みスナップショットから導出される実行用の入力

永続記録は2つのファイルに分かれる。snapshot.json にはビルド時に焼き込まれたランタイム設定（環境変数、作業ディレクトリ、ユーザー、公開ポート、ボリューム、ラベル）と、rootfs・追加ドライブ・メモリそれぞれのoverlaybdレイヤー参照が入る。レイヤー参照は内容ダイジェストで重複排除された管理レイヤーか、外部OCIレジストリの参照のいずれかを取る。firecracker-manifest.json にはレイヤー一覧では表せない起動時メタデータ（メモリやrootfsの仮想サイズなど）が入る。

一方で upper.data upper.index mem_image.json などはコミットされない。どれが永続でどれが導出物かを取り違えるとバックアップ設計を間違えるため、この線引きは運用側が最初に押さえるべき情報だ。

複数ノードは gateway と scheduler が前段に立つ

複数ノードで動かす場合、HTTPリバースプロキシのgateway（:8080）とgRPCのscheduler（:9090）が複数のAgentENVノード（:8000）の前に立つ。gatewayはサンドボックスIDで振り分け、新規作成ならschedulerがノードを選び、既存ならschedulerに問い合わせて所有ノードを引く。振り分け戦略はラウンドロビン（既定）とランダム。ノード発見は設定に列挙する静的方式と、Kubernetesの EndpointSlice を監視する方式がある。Kubernetesでは特権DaemonSetとして各ホストに1つずつ配置され、/dev/kvm とネットワーク名前空間の操作権を得る。

補助的な仕組みとして、ノード間でスナップショット成果物をやり取りするP2P転送層がある。既定は無効で、有効化するとiroh（およびiroh-blobs）を使ってスナップショットの成果物やoverlaybdレイヤーをノード間で直接配る。取得に成功したノードは自らも配布側として名乗り出るため、成果物がクラスタ内へ広がっていく作りだ。ただしこれはあくまで高速化の補助経路で、コミット済みスナップショットリポジトリが正である、という関係は変わらない。

AgentENVと既存のAIエージェント サンドボックスの違い｜E2B互換APIで何が変わるか

隔離のためにmicroVMを使う、という発想自体は新しくない。当サイトでもCubeSandbox解説：60ms起動MicroVMでAIエージェントを安全実行するTencentの設計思想でTencent Cloud製の実装を、AIO Sandbox入門：AIエージェント実行環境をDocker1つで構築する方法でDockerコンテナ1つに機能を詰める方向の実装を扱っている。コンテナとフルVMの中間を狙う設計思想や、E2B互換APIで移行障壁を下げるアプローチは、これらと共通している。

AgentENVがそれらと分かれるのは、関心が「1つの環境をどう隔離するか」ではなく「大量の環境をどう安く維持し、どう分岐させるか」に寄っている点だ。fork、三層のスナップショット管理、ディスク容量を超えるイメージのオンデマンド読み込み、同一スナップショット由来のメモリ共有は、いずれも数を並べたときに初めて意味が出る機能である。

比較表の「一般的なmicroVM型」「Dockerコンテナ型」は方式の傾向をまとめたもので、個別製品の優劣を示すものではない。用途が「1タスクごとに使い捨ての安全な実行環境が欲しい」であれば、forkや共有ストレージ連携は使われないまま複雑さだけが残る。逆に「同じ中間状態から多数の続きを試したい」なら、これらの機能が効いてくる。

E2B互換API

AgentENVはE2B互換のHTTP APIを公開している。ドキュメントによれば、環境変数 E2B_API_URL を自分のサーバーへ向ければ、標準のE2B Python / TypeScript SDKがコード変更なしで動作するとされている。ノード側のエンドポイントも POST /sandboxes、GET /sandboxes/{id}、POST /sandboxes/{id}/pause、POST /sandboxes/{id}/resume といったE2B互換の形をとる。

操作用のCLIも用意されており、テンプレートの取得からサンドボックスの起動・接続・停止までを一通り扱える。

# OCIイメージをテンプレートとして取り込む
aenv pull docker.io/library/ubuntu:latest --name ubuntu

# サンドボックスを起動して対話シェルに入る
aenv start ubuntu

# 一度きりのコマンド実行と、走行中サンドボックスの一覧
aenv exec <sandbox-id> ls -la /
aenv ls

なお、上の実行結果のとおり CLI 単体は macOS でも起動する。公式リリースには aenv-darwin-aarch64 と aenv-darwin-x86_64 が含まれており、手元のMacからLinuxサーバーを操作する使い方が想定されている。README のCLIリファレンスには記載が無いが、実バイナリにはローカルのDockerfileからテンプレートを構築する build サブコマンドも存在した。

テンプレートを経由せず、OCIイメージを直接ブロックデバイスへ変換して起動するコールドスタート（aenv start --cold ubuntu:24.04）もある。この場合のルートファイルシステム仮想サイズは、現行のリサイズツールが1GiB単位で動く都合上、明示するなら1024MiB以上かつ1024の倍数である必要がある。

AgentENV導入前に確認する制約と、リポジトリのベンチマークが測っているもの

動作要件と、置き場所の制約

読者にとって最初の問いは「自分の環境で使えるのか」だろう。答えははっきりしている。

・Linuxカーネル6.8以降と /dev/kvm へのアクセスが必須。macOSやWindowsでサーバーは動かない
・公式インストールスクリプトはUbuntu 24.04を前提とする。他ディストリビューションはDockerまたはソースビルドの経路になる
・ネスト仮想化が使えないマネージドKubernetesでは動かない。特権DaemonSetとして /dev/kvm に触れる必要がある
・操作用の aenv CLI だけはLinuxとmacOS（x86_64 / arm64）向けに配布されているため、CLIは手元、サーバーは別Linuxホストという構成は取れる

セットアップはインストールスクリプトかDockerを選ぶ。

# Ubuntu 24.04：サーバーとCLIを入れてsystemdサービスとして起動
curl -fsSL https://raw.githubusercontent.com/kvcache-ai/AgentENV/main/scripts/install.sh | sudo bash
sudo systemctl start aenv

そして運用上いちばん重要な制約が認可の不在だ。READMEは警告ブロックとして「AgentENVは現時点で認可をサポートしていない。APIを公開ネットワークへ晒すな。信頼されたネットワーク内か、適切なネットワーク制御を伴う認可プロキシの背後でのみ動かせ」と明記している。クイックスタートでAPIキーに dummy を入力させる手順も、この段階の実装であることを示している。自ホスト型のサンドボックスは「エージェントに任意コードを実行させる場所」そのものなので、ここは省略できない。

なお、サンドボックス単位の外向き通信は制御できる。作成時に allowInternetAccess で全面遮断するか、CIDR・IP・ドメインパターンによる許可リストと拒否リストを渡す方式で、許可が拒否に優先する。走行中のサンドボックスに対して後から更新することもできる。これはネットワーク層の話であり、API自体の認可とは別問題である点に注意したい。

リポジトリのベンチマークは何を測る作りになっているか

公称値が再現できない以上、代わりに確認できるのは「プロジェクトが何を測ろうとしているか」だ。リポジトリには4本のベンチマークが同梱されており、うち2本がスナップショットとストレージを対象にしている。

スナップショット側のベンチマークには、次の測定項目が定義されている。

注目したいのは3点ある。まず snapshot_creation_1gdisk と snapshot_creation_1gmem は、ベンチマーク内でゲストに対し実際に1GiBのファイル書き込みとメモリ確保を行ってから取得時間を測る作りになっている。READMEの「ディスクを激しく変更した状態でも100ms未満」という主張に対応する測定項目が、実際にコードとして存在することは確認できる。

次に snapshot_resume と snapshot_resume_cold の関係が興味深い。両者の計測ループはコード上まったく同一で、違いは「同じスナップショットから起動したインスタンスを1つ生かしたままにしておくか否か」だけである。前者にはコード中に「メモリublkデバイスは少なくとも1つハンドルが生きている間は共有されるため、これでhotなテンプレート経路を測る」という趣旨のコメントが添えられている。

つまりこの2項目は、先に触れた参照カウントによるメモリデバイス共有が効いている状態と、効いていない状態の差をそのまま測るために置かれている。設計上の主張と測定項目が一対一で対応しているわけだ。なお、公称の再開時間がこのどちらを指すのかはドキュメントからは判別できない。

そして concurrent_resume は50並列をバリアで同期して一斉に開始し、合計時間を並列数で割って1件あたりの値を出す作りになっている。これは「同一スナップショットからの大量同時起動でページキャッシュが共有される」という設計の狙いを、そのまま測定に落とし込んだ項目といえる。

ストレージ側のベンチマークは、順次読み出し（1MiB／128KiB）とランダム読み書き（4KiB）をキュー深度1〜64で変えた6ケースで構成される。既定のデバイスサイズは32MiB、フル実行時は1GiBに切り替わる。

現時点でどう位置づけるか

公開から5日、v0.1.0、コントリビューター5人という段階を踏まえると、いま本番のエージェント基盤を丸ごと載せ替える対象ではない。一方で、ストレージ層の作り込み（LSMT形式の自前実装、ublkデーモンの分離、userfaultfdからの乗り換え）は短期間で書けるものではなく、社内で動いていたものが公開された可能性が高い。実際にリリース資産のダウンロード数を見ると、Linux向けCLIとサーバーtarballに限られ、公開直後の試用が始まったばかりの状態が読み取れる。

評価するなら、まずは単一ノードで aenv pull → aenv start → aenv pause / resume → fork までを一通り触り、自分のワークロードでforkの16分岐という上限が足りるかを確かめるのが現実的だ。共有ストレージ連携と複数ノードは、その先の検討事項になる。

まとめ

AgentENVは、AIエージェントのサンドボックスを「1つ安全に起動する」問題ではなく「大量に安く維持し、走行中の状態から分岐させる」問題として設計したRust製OSSだ。要点を整理する。

・forkが一級市民：走行中サンドボックスを最大16個・同一ノード内で分岐でき、親は分岐後も走り続ける
・スナップショットが土台：テンプレートもpause/resumeもforkも、単一のスナップショット機構の別の見せ方として実装されている
・ローカルディスクはキャッシュ：overlaybd＋ublkにより、イメージ総量がノードのディスク容量を超えても成立する。代償として共有ストレージ回線に10Gbps以上が推奨される
・メモリ復元がublkベース：userfaultfdではなくublk上のoverlaybdを使い、同一スナップショット由来のサンドボックス間でメモリデバイスを参照カウント共有する。大量同時起動時のI/O削減を狙った設計
・E2B互換：E2B_API_URL の差し替えで既存のE2B SDKコードが動くとされる
・制約は明確：Linux 6.8+ と /dev/kvm が必須、認可機構は未実装で公開ネットワーク禁止、複数ノード制御プレーンはプロトタイプ

公称値の50ms／100msは魅力的だが、測定条件が示されておらず結果も公開されていない。同梱ベンチマークが「何を測る作りになっているか」までは確認できるので、導入を検討するなら自分のハードウェアでそれを回すところから始めるのが確実だ。

参照ソース

・kvcache-ai/AgentENV — GitHubリポジトリ（README・ソースコード・benches/・v0.1.0 リリース）
・AgentENV 公式ドキュメント（Getting Started / Concepts / Internals / Deployment / E2B integration）
・Firecracker — 公式リポジトリ（microVM・スナップショット機構の一次情報）
・ublk — Linuxカーネル公式ドキュメント（ユーザー空間ブロックデバイスドライバ）