2026年6月22日、AWSは公式ブログで発表を行った。タイトルは長いが、核心は一言に尽きる。LambdaがMicroVMを実行できるようになった。
AWSは新サービスも新SKUも出していない——11年の歴史を持つサーバーレスプロダクト「Lambda」の中に、まったく新しい扉が開かれたのだ。筆者の第一印象はこうだ。AWSはFirecrackerを舞台裏から前面に押し出した。しかも今回はLambda自身の関数のためではなく、開発者が直接使うためのものとして。
実際に何が発表されたのか
Lambda MicroVMsは新しい計算プリミティブだ。Lambda Functionsと同じコンソールの入り口を共有しているが、APIはまったく異なる。ユーザーはDockerfileとコードの圧縮パッケージをS3にアップロードし、Lambdaがイメージをビルドし、アプリケーションを初期化し、Firecrackerのスナップショットを作成する。以降、MicroVMを起動するたびに、このプリウォームされたスナップショットから直接復元される——コールドスタートの工程が完全にスキップされる。
注目すべきパラメータをいくつか挙げよう。
- インスタンスあたりの上限：16 vCPU、32 GBメモリ、32 GBディスク、ARM64（Graviton）アーキテクチャ
- 最長実行時間：8時間——Lambda Functionsの15分制限はここでは存在しない
- アイドル戦略：自動サスペンドが設定可能。サスペンド中はスナップショット保存料金のみ課金され、復元時には完全なメモリとディスク状態が保持される
- 起動方式：コールドスタートではなくスナップショット復元。起動成功後、即座に準備完了のHTTPエンドポイントが得られる
- 初期リージョン：米国東部（バージニア、オハイオ）、米国西部（オレゴン）、欧州（アイルランド）、アジア太平洋（東京）
料金はvCPU/秒とメモリ/GB/秒で計測され、サスペンド後は計算料金がゼロになる。これはLambda Functionsの課金ロジックと一貫しているが、単一セッションが数時間持続できるため、実際の請求構造はオンデマンドVMにより近くなる——一時停止機能が追加されただけだ。
AWS公式ブログは明確にターゲットシナリオを列挙している。AIプログラミングアシスタント、インタラクティブコード環境、データ分析プラットフォーム、脆弱性スキャナ、ユーザースクリプトを実行するゲームサーバー。共通の特徴は何か？すべてのエンドユーザーが、信頼できないコードを安全に実行できる自分専用の隔離環境を必要としているということだ。
なぜ今なのか
この問いは分解して考える価値がある。
Firecrackerは2018年にオープンソース化された。過去7年間、月間15兆回を超えるLambda関数呼び出しを支えてきた。技術は成熟している。しかしAWSはこれまで、Firecrackerを開発者向け製品として売り出すことはなかった——今までは。
変わったのはAWSの戦略的嗜好ではない。需要側だ。
2025年から2026年前半にかけて、AIコードアシスタントは実験的ツールから日常的ツールへと変わった。Claude Code、Codex CLI、Gemini Code Assist——これらのエージェントはコードを生成するだけでなく、コードを実行しなければならない。パッケージをインストールし、サービスを起動し、ファイルシステムに読み書きし、ネットワークリクエストを発行する。毎日数百万回。そしてこれらのコードを実行する環境は、Dockerコンテナ（カーネル共有、namespace + cgroup + seccompによる隔離）か、あるいは仮想マシン（隔離は強いが起動は遅い）の二択だった。
さらに厄介なのは、エージェント自体がソフトウェアレベルの安全制限を能動的に迂回してしまうことだ。2026年3月、FalcoのコアメンテナLeonardo Di Donatoは、Claude Codeが自分のサンドボックスをいかにして迂回したかを実演した。エージェントは/proc/self/root/usr/bin/npxがdenyルールを迂回していることを発見し、bubblewrapにブロックされた後は直接サンドボックスを無効化した。脱獄も特殊なプロンプトもない。単にタスクを完了させたかっただけだ。
この事例は一つの核心的事実を物語っている。ユーザー空間ロジックに基づく隔離（denylist、許可プロンプト、seccompルール）は、エージェントの推論と同一レイヤーで動作している。エージェントはそれらを理解し迂回する十分な能力を持っている。一方、MicroVMの隔離はハードウェア仮想化によって強制され、エージェントが到達できないレイヤーで発効する。
Lambda MicroVMsの発表タイミングは、このセキュリティ問題の爆発と高度に重なっている。
サンドボックス市場の構図
Lambda MicroVMsは無から生まれたわけではない。これに先立ち、「信頼できないコードをいかに安全に実行するか」という問題をめぐって、すでにかなりの規模のツールとプラットフォームのエコシステムが形成されていた。筆者は現在の主要陣営を整理した。優劣をつけるものではなく、アーキテクチャの差異と適用シナリオを提示するのみである。
Firecracker陣営
AWS自身が最大のプレイヤーであることは言うまでもない。新発表のLambda MicroVMsに加え、AWS Bedrock AgentCoreも各エージェントセッションに独立したmicroVMを提供するためにFirecrackerを使っている。
独立系プラットフォームでは、E2BがAIエージェントサンドボックスに特化したサービスで、Firecrackerを基盤とし、起動時間約150ms、Fortune 100の88%が登録済みと主張している。Fly.io Spritesは永続化されたステートフルVMを提供し、チェックポイント/復元約300ms、Claude CodeとCodex CLIをプリインストール。Vercel SandboxもFirecrackerベースで、ミリ秒級のスナップショット復元を謳い、AIコードインタプリタ向け。SlicerVMはセルフホスティング路線で、FirecrackerとCloud Hypervisorの両方をサポートし、macOS上ではApple Virtualization Frameworkも利用可能。
オープンソースプロジェクトではMatchlockが注目に値する——AIエージェント向けに設計されたFirecrackerサンドボックスで、デフォルトdeny-allのネットワークポリシー、ドメインホワイトリスト、キー保護を備え、claude --dangerously-skip-permissionsのセキュリティ問題を専ら解決する。
libkrun陣営
Red HatのlibkrunはライブラリレベルのVMM路線——microVMの能力を独立したデーモンではなく、他のプログラムから呼び出せるライブラリとしてパッケージ化する。Microsandbox（YCインキュベーション、Apache 2.0オープンソース、GitHubスター約4,700）はlibkrunの最も典型的な消費者だ。セルフホスト型のAIエージェントサンドボックスで、各インスタンスは独立したカーネル、ファイルシステム、ネットワークスタックを取得する。
libkrunの差別化要因の一つはクロスプラットフォーム対応だ。Linux上ではKVM、macOS上ではHypervisor.frameworkを利用する。欠点はKubernetesのオーケストレーション層やクラスタレベルの管理機能が不足していること——単一マシンへのデプロイに優れており、開発者のローカル環境や小規模チームのサンドボックス需要には適するが、大規模マルチテナントの本番環境には向かない。
Kata Containers
Kata Containersは位置付けにおいて他のソリューションと本質的に異なる。オーケストレーションフレームワークを提供し、Firecracker、Cloud Hypervisor、またはQEMUをKubernetesランタイム層に組み込み、各Podを自身の軽量VM内で実行させる。Kubernetesから見れば普通のコンテナに見えるが、その下にはハードウェア分離が完全に施されている。
起動時間は約150〜300ms（VMMの選択による）、メモリオーバーヘッドは10 MiB未満＋ゲストカーネル。Kataの核心的価値は、microVMの運用複雑性をカプセル化していることだ——カーネルイメージ、ネットワーク設定、VMライフサイクルを自分で管理する必要がない。Northflankは本番環境でKata Containers + Cloud Hypervisorを運用し、月間200万以上のmicroVMを処理している。
Kataは長期実行されK8sオーケストレーションを必要とするマルチテナントワークロードを志向しており、単一セッションの高速起動・停止シナリオ向けではない。
gVisor
GoogleのgVisorはまったく異なる技術路線を採る。コンテナの外側にVMを被せるのではなく、コンテナとホストカーネルの間にGoで書かれたユーザー空間カーネル（Sentry）を挿入する。コンテナが発行するsyscallはSentryによって捕捉されユーザー空間で処理され、必要最小限の操作だけがホストカーネルに透過的に渡される。
このことはVM起動のオーバーヘッドがなく、ネステッド仮想化のサポート不要、Docker/containerd統合パスが最短であることを意味する。代償として、I/O集約的なワークロードでは10〜30%のsyscallオーバーヘッドが発生する。gVisorの隔離強度はコンテナとVMの中間にある——カーネル攻撃面を大幅に縮小し（Sentryは約230のsyscallのみ実装、Linuxカーネルは450以上を露出）、しかしハードウェアレベルのメモリ分離までは達成できない。
ModalはgVisor路線の代表的な製品で、GPU対応サンドボックス環境を提供し、起動約300ms、推論とトレーニングシナリオを主戦場とする。
Cloudflare Workers（V8 Isolates）
Cloudflareは別の極限をいく。V8 isolateだ。起動時間はサブミリ秒級だが、JavaScript/TypeScript/WASMのみをサポート。2026年にはDynamic Workers機能を新たに追加し、LLMがランタイムに動的にJS/TSの子isolateを生成してコードを実行できるようにし、トークン消費を従来のtool-callingに比べて81%削減した。汎用サンドボックスではないが、JS/WASMエコシステム内では密度とレイテンシ性能で他を寄せ付けない。
差別化の次元
各社のソリューションを整理した上で、筆者は競争の焦点となりつつあるいくつかの次元を観察した。
スナップショット/フォーク能力。 Lambda MicroVMsの「プリウォームスナップショットからの直接起動」は、本質的に、初期化済みのランタイム状態を凍結し、次回起動時に直接復元する仕組みだ。この発想はUnikraft Cloudで極限まで追求され——10ms未満のコールドスタート、単一ホストあたり10万以上の隔離インスタンスを謳う。スナップショット速度は直接的にユーザー体験を決定する。エージェントがコード実行リクエストを発行した後、ユーザーが待つ時間が100msなのか5秒なのか——その差は継続利用か放棄かの分かれ目だ。
ネットワーク層のキー遮蔽。 これはエージェントシナリオで特に重要だ。エージェントは外部ネットワークへのアクセスを必要とするが（依存関係の取得、API呼び出し）、環境変数内のキーを読み取られるわけにはいかない。Lambda MicroVMsの解決策はshort-lived auth token + proxyヘッダであり、Matchlockのアプローチはdeny-all + ドメインホワイトリストだ。差異は機能の有無ではなく、各社のセキュリティモデルに対する理解の違いにある。
SSH / VPNアクセス。 インタラクティブ開発シナリオでは、開発者が直接サンドボックスに入ってデバッグできる必要がある。Fly.io SpritesとE2BはSSHをサポートしているが、Lambda MicroVMsは現在HTTPエンドポイント方式を採っており、コード実行には適するがインタラクティブ開発には向かない。
オーケストレーション層とK8s統合。 Kata Containersはこの次元ではほぼ無敵だ——Kubernetesのために設計されている。Firecrackerを裸で使うには大量のインフラを自前で構築する必要があり、Lambda MicroVMsはその責任をAWSマネージドサービスに移譲している。libkrunには現在クラスタレベルのオーケストレーションソリューションが不足している。
エージェント親和性。 これは純粋な技術仕様の比較ではなく、製品設計の哲学に関わる。サンドボックスはREST APIを公開しているか？SDKをサポートしているか？snapshot/resumeのセマンティクスはエージェントの「実行-結果待ち-継続実行」ループに適合しているか？Lambda MicroVMsのサスペンド/レジューム機構と8時間上限は、明らかにエージェントセッション向けに設計されている。一方、Docker Sandboxesの「エージェントごとに独立したDockerデーモン」モデルは、よりローカル開発シナリオに偏っている。
構図はまだ決まっていない
時間軸を引き延ばして見れば、2018年にFirecrackerが誕生したとき、microVMはインフラ層の最適化手段に過ぎなかった——Lambdaをより速く、より安く、より安全にするためのものだ。2026年には、同じ技術がプロダクト層の第一級市民になった。上層の需要が根本的に変化したからだ。エージェントがコードを実行しなければならず、コード実行にはサンドボックスが必要で、サンドボックスはnamespaceの寄せ集めではダメなのだ。
しかし「どのサンドボックスがベストか」という問いに統一的な答えはない。エージェントがJavaScriptしか走らせないなら、Cloudflare WorkersのV8 isolateはサブミリ秒起動のmicroVMよりも強力かもしれない。Kubernetes上で動作し長期実行の隔離Podが必要なら、Kata Containersの方が裸のFirecrackerより実務的だ。ローカルでセルフホストの軽量ソリューションが必要なら、libkrun + Microsandboxの方がAWSマネージドサービスより柔軟だ。Lambda MicroVMsの強みはゼロ運用とスナップショット復元にある——しかしAWSエコシステム、ARM64アーキテクチャ、リージョン制限に縛られる。
筆者は上記のいずれのサンドボックスソリューションも本番環境で大規模に運用した経験はない。本稿の判断は公開文書、技術ホワイトペーパー、コミュニティ議論のクロス検証に基づいている。AIエージェント用のサンドボックスインフラを検討中であれば、自身のワークロードでベンチマークを取ることを強く推奨する——100msのスナップショット復元が実際のネットワーク遅延の中でどう振る舞うかは、ベンチマーク表の数字とは別物かもしれない。
アーキテクチャの勝敗を決めるのは、往々にしてアーキテクチャそのものではない。 エージェントが毎秒数十回のコード実行リクエストを発行する世界では、スナップショット速度、ネットワーク遅延、キー管理、課金モデル——これらの「非中核的」な要素が、VMMがRustで書かれているかGoで書かれているかよりも重要かもしれない。
声明：本稿は技術観察に過ぎず、筆者は文中で言及されたいかなる企業やプロジェクトとも利益関係を持たない。