agentOS を既存バックエンドに埋め込む：WebAssembly と V8 アイソレートで動くエージェント実行基盤の見極め

サンドボックスの起動待ちを消す、という問題設定

このプロジェクトが狙うのは、エージェントを動かすたびに microVM やコンテナを起動するコストを、プロセス内の軽量 VM に置き換えることだ。README は「Runs inside your process」を最初の利点に挙げ、microVM のブートもコンテナの pull もネストした仮想化も不要だと説明している。想定読者は、すでに Node.js のバックエンドを持ち、そこにコーディングエージェントやシェル実行を組み込みたい開発者である。エージェントを別サービスとして立てるのではなく、自分のプロセスの内側で動かし、認証情報はホスト側に残したまま入出力だけを渡す、という発想になっている。README には「Warm VM creation takes single-digit milliseconds and each VM costs tens of megabytes」とあり、これが設計の出発点だ。

V8 アイソレートと WebAssembly に分かれる実行モデル

実行単位は 2 種類に分かれる。ゲストの JavaScript は V8 アイソレートで動き、コンパイル済みのツールは WebAssembly として動く。どちらも 1 つのコンパクトなランタイムの中に収まる、と README は述べている。エージェントがホストの関数を呼ぶ経路は bindings と呼ばれ、ネットワーク越しのサービス呼び出しではなく通常の JavaScript 呼び出しとして扱われる。この設計の帰結として、認証情報はホストに留まり、エージェントから見えるのは入力と出力だけになる。ファイルシステム、ネットワーク、プロセス、環境変数へのアクセスは permissions で制御され、外向きの通信のような外部に触れる能力は既定で拒否される。つまり「エージェントに何でもさせる」のではなく、許可した能力だけを通す前提の作りである。

セットアップ：npm install から 2 つのターミナルまで

導入は npm パッケージとして行う。README の Quickstart では npm install @rivet-dev/agentos @agentos-software/pi を実行し、coreutils、sed、grep、gawk、findutils、diffutils、tar、gzip といった一般的な POSIX ユーティリティは同梱される。Claude Code、Codex、OpenCode も Pi と同じ方法で追加できる。サーバー側は agentOS({ software: [pi] }) で VM を作り、setup({ use: { vm } }) の戻り値を export して registry.start() を呼ぶ。クライアント側は createClient に endpoint（例では http://localhost:6420）を渡し、client.vm.getOrCreate("my-agent") でハンドルを取得する。handle.connect() で sessionEvent を購読し、handle.openSession({ agent: "pi", env: { ANTHROPIC_API_KEY: ... } }) でセッションを開き、handle.prompt でテキストを送る。エージェントが作ったファイルは handle.readFile("/workspace/hello.js") で読み出せる。起動は npx tsx server.ts と npx tsx client.ts の 2 ターミナル構成だ。VM 内では handle.exec("node /hello.mjs") のように Node.js やシェルスクリプトも実行できる。

Rivet Actor 版と agentos-core 版という 2 つの入口

@rivet-dev/agentos は各 VM を Rivet Actor として動かし、永続化、sleep/wake、マルチプレイヤー、プレビュー URL、オーケストレーションを備える。一方、既存の Node.js アプリケーションに VM 制御だけを埋め込み、アクターランタイムを挟みたくない場合は @rivet-dev/agentos-core を使う。こちらは AgentOs.create() が VM を起動して、直接呼び出せるハンドルを返す。この 2 系統の存在は、採用時に最初に決めるべき分岐点になる。永続化や複数クライアントからの同時接続が要件なら前者、単一プロセス内で完結させたいなら後者だ。README は前者を既定の Quickstart に置きつつ、後者を「without the actor runtime」と明示して案内している。

サンドボックスの代替ではなく、併用を前提とした位置づけ

README の比較節は、agentOS を「軽量 VM がプロセス内で動くもの」、サンドボックスを「完全な Linux 環境」と対置している。サンドボックスはブラウザ、ネイティブバイナリ、開発サーバーを必要とする用途に向く。そして「You don't have to choose」と書き、sandbox mounting を通じてオンデマンドでフルサンドボックスを起動し、そのファイルシステムをマウントする構成を案内している。ここは採用判断で見落とされやすい。agentOS 単体でサンドボックスを置き換えられるのは、POSIX ユーティリティと Node.js、および対応エージェントで足りる範囲に限られる。ブラウザのヘッドレス実行やネイティブ拡張のビルドが必要になった時点で、この境界に当たる。

ベンチマーク数値の読み方と、プレビュー段階という制約

README はコールドスタート p50 で 4.8 ms（E2B 440 ms、92x）、p95 で 5.6 ms（950 ms、170x）、p99 で 6.1 ms（3,150 ms、516x）という数値を掲げる。メモリはフルのコーディングエージェント構成で約 131 MB、単純なシェルコマンドで約 22 MB、比較対象は Daytona の最小インスタンス約 1,024 MB。コストはセルフホスト前提で、Hetzner ARM の単純シェルで 254x から 1,738x といった差が示される。ただしこれらはすべてプロジェクト自身の計測であり、README の注記によれば 2026 年 3 月 30 日時点で最速・最安のサンドボックス事業者と比較したもの、計測機は Intel i7-12700KF、コストは 1 エージェント 1 サンドボックス、ホスト稼働率 70% を仮定している。第三者の検証ではない点は差し引いて読むべきだ。もう 1 つ明確な制約として、README は「agentOS is in preview and the API is subject to change」と書いている。リリース履歴も v0.2.19、v0.2.19-rc.1、v0.2.20-rc.1 と 0.x 系が続いており、RC が並ぶ進め方である。

Apache-2.0 と、運用側に残るコスト

ライセンスは Apache-2.0 で、README も「Open source: Apache 2.0 licensed」と明記している。ソースの入手と改変、再配布の条件はこのライセンスに従う。ただしライセンスが許す範囲と、実際に動かし続けるコストは別である。README はデプロイ先として、ローカルの npx rivetkit dev、マネージドな Rivet Cloud、自前ホストの 3 つを示す。Rivet Cloud を選べばインフラ運用は移せるが、セルフホストを選べば VM を動かすホストの管理は自分に残る。コスト表が前提にしている 70% の稼働率も、実際のトラフィック次第で上下する。アップグレード面では、プレビュー中の API が変わりうると README が明言している以上、バージョン固定とリリースノートの確認が前提になる。v0.2.19 から v0.2.20-rc.1 まで日付が近く、追随の頻度は低くない。

編集部の結論

既存の Node.js バックエンドを持ち、エージェントに自前の関数を直接呼ばせたいチームには向いている。逆にブラウザやネイティブバイナリ、開発サーバーを丸ごと動かしたい用途では、README 自身がサンドボックス併用（sandbox mounting）を案内しており、単体では代替にならない。採用前に確認すべきは、プレビュー段階の API がどのリリースでどこまで変わるか、permissions の既定値（外向き通信が拒否される点）が自分のワークロードと衝突しないか、そして @rivet-dev/agentos と @rivet-dev/agentos-core のどちらを使うかである。前者は Rivet Actor として永続化や sleep/wake を伴い、後者はアクターランタイムなしで AgentOs.create() から直接ハンドルを扱う。

公式情報源

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. rivet-dev/agentos on GitHub