先に結論
InstaVM は、単発の sandbox より 状態を持った agent 実行基盤 として見ると分かりやすいサービスです。
見るべき差分は 4 つあります。
- agent ごとに isolated microVM を持てる
- persistent session や long-running agent を前提にしている
- browser と desktop runtime まで同じ基盤で扱える
- 料金が base fee と秒課金に分かれていて、volume も別で効く
要するに、短い code execution だけなら過剰です。
一方で、同じ環境を保ったまま agent を動かす、browser を触らせる、app を外に出す、といった運用を考えているなら候補に入ります。
sandbox provider の横比較から入りたい人は、AIエージェント向けSandbox比較：Modal / E2B / Daytona / OpenSandbox の違い も先に見ておくと、InstaVM がどこで重く、どこで刺さるかが見えやすいです。
何が出てきたのか
InstaVM は公式サイトで、AI agents 向けの isolated microVM runtime を前面に出しています。
説明の中心は、単に安全な実行箱を渡すことではありません。runtime、storage、networking、secrets、policy までまとめて持つ agent 用の実行基盤 として打ち出しています。
そのため、同じページでも一時 sandbox だけでなく、persistent long-running sessions、checkpoint and clone、named volumes、share URL、custom domain まで並んでいます。
この並びを見ると、主語は「1回実行して終わる sandbox」ではなく、状態を保ったまま動き続ける agent や app です。
一番大きいのは persistent session 前提なこと
InstaVM でまず見るべきなのは、persistent session を正面から出している点です。
公式説明では、VM を生かしたままファイル、パッケージ、状態を次の呼び出しへ引き継げます。checkpoint で途中状態を保存し、restore や clone で再開や分岐もできます。
ここが普通の一時 sandbox と違います。
短い code execution だけなら、毎回きれいな環境で起動して終える方が運用は楽です。ところが、複数ステップの ticket workflow、長い調査、agent-hosted app、MCP サービスのように、同じ環境を育てる仕事 では persistent session の方が自然です。
OpenAI 系の agent 実行基盤と見比べたいなら、OpenAI Agents SDK sandbox provider 比較｜E2B vs Daytona vs Modal vs Runloop vs Vercel どれを選ぶべきか も役立ちます。InstaVM はその中でも、一時実行より stateful 運用に寄っています。
安全性は egress と secrets の設計で見る
microVM と言われると、つい isolation の強さだけ見がちです。
ただ、導入判断で先に見るべきなのは、agent に何を見せず、どこへ出してよいか です。
InstaVM の公開情報では、dedicated kernel、filesystem、network stack に加えて、default-deny outbound traffic、domain と CIDR の allowlist、proxy-based secret injection を案内しています。
特に分かりやすいのは secret 周りです。説明では、agent 自身は API key を直接見ず、proxy が request 時に注入します。prompt injection などで agent が崩れても、資格情報そのものを広く持たせない設計です。
安全性の話をするとき、isolated microVM という言葉だけで終えるのは危険です。実際に効くのは、egress をどこまで絞れるか、package manager をどう扱うか、secret を平文で持たせないか、といった運用面です。
browser と desktop runtime を同じ基盤で扱える
もう 1 つ大きいのは、browser と desktop runtime まで同じ流れで持てることです。
公式サイトでは、full Linux desktop、browser、terminal、sudo access、noVNC による human takeover、screenshots と recordings を案内しています。
これは browser automation や computer use を本番寄せで回したいチームには分かりやすい利点です。
別サービスで browser session を足すのではなく、VM 自体を browser や desktop を含む作業環境として扱える からです。agent が画面を操作し、必要なときだけ人が引き継ぐ流れも作りやすくなります。
同じ論点を coding agent 側から見たいなら、Cursor cloud agent development environments vs Codex vs GitHub Copilot｜実行環境・監査・複数repo運用で選ぶ もつながります。InstaVM は IDE ではなく runtime 側の基盤です。
料金は秒課金より volume と同時実行数が効きやすい
pricing page で確認できる料金は比較的読みやすいです。
2026-05-21 時点の公開情報では、Free は $0 base で $50 credit 付き、Pro は $100/mo base、Enterprise は個別見積もりです。compute は両プラン共通で、vCPU が 1 秒あたり $0.000014、RAM が 1GB あたり 1 秒 $0.0000045 です。
加えて、Free と Pro はどちらも 10GB の volume を含み、追加の allocated volume storage は 1GB-hour あたり $0.0002 です。
ここで先に気にしたいのは、秒課金そのものより persistent volume と同時実行数 です。
- Free は同時 5 VM
- Pro は同時 100 VM
- Browser sessions は Free が月 100、Pro が月 5,000
- Free の egress は既知の package manager と AI APIs 中心
- Pro は unrestricted egress か granular allowlist が使える
つまり、単に安い sandbox を探す話ではありません。状態保持を多く使うか、browser session が多いか、egress を細かく制御したいかで、Free と Pro の境界が変わります。
どんなチームに向いているか
InstaVM が向くのは、次の 3 パターンです。
1. stateful agent を持ちたいチーム
同じ VM を保ったまま、調査、修正、再実行を続けたいチームです。毎回ゼロから環境を作るより、状態が残る方が速い仕事に向きます。
2. browser や desktop 操作まで入るチーム
API 呼び出しだけでは終わらず、管理画面、検証画面、社内ツールを agent に触らせたいチームです。必要なら人が途中で乗り込める運用も作りやすいです。
3. app や service をそのまま外へ出したいチーム
share URL や custom domain を使って、VM 上の app や internal tool をそのまま公開する流れを作りたいチームです。sandbox と deployment が分かれすぎている構成より扱いやすい場面があります。
逆に、すぐ飛びつかなくてよいケース
短い task を大量に投げるだけなら、InstaVM はやや重い選択です。
たとえば、一回限りの code execution、短い eval、数十秒の変換処理が中心なら、persistent session、desktop runtime、share URL まで抱える必要はありません。
また、運用境界を決めずに導入するのも危険です。
- どの agent に browser や sudo を渡すのか
- secret を proxy 注入に寄せるのか
- egress allowlist をどこまで絞るのか
- volume を誰が掃除するのか
この 4 つが曖昧なままだと、機能が多いぶん運用も散りやすくなります。
導入前に先に確認したいこと
最後に、InstaVM を試す前に見ておきたい項目を絞るとこうなります。
- 本当に persistent session が必要か
- browser と desktop runtime を本番で使う予定があるか
- egress を allowlist で絞る運用を作れるか
- volume と同時実行数を踏まえた月額の上限を置けるか
- Claude Code、Codex、Cursor からの deploy 導線を実際に使うか
この順で見ると、launch の派手さに引っ張られにくくなります。
まとめ
InstaVM は、isolated microVM を前面に出しつつ、実態は stateful agent と browser runtime を含む実行基盤 として出てきたサービスです。
単発 sandbox の延長で見ると重く感じますが、persistent session、checkpoint and clone、named volumes、share URL まで一体で扱いたいチームには噛み合います。
まず見るべきなのは、microVM という名称ではありません。自分たちの agent 運用が、単発実行なのか、状態を保つ長い仕事なのか です。そこが後者なら、InstaVM は試す理由があります。