AWS Lambda MicroVMsが登場 — AIエージェントのコード実行サンドボックスを徹底解説
はじめに
AWS Lambda が MicroVMs という新しいコンピュート基本要素（プリミティブ）を発表した。一言でいえば「ユーザーや AI が生成したコードを、VM レベルで隔離されたステートフルな環境で実行するためのサーバーレス基盤」だ。これまで Lambda は「ステートレスなイベント駆動の関数実行」が前提だったが、MicroVMs はそこから明確に踏み出し、最大 8 時間稼働・状態保持・ライフサイクル制御という、これまで自前の EC2 や Kubernetes で組んでいた領域に正面から踏み込んでくる。
なぜ今これが出てきたのか。答えは「AI エージェント」だ。LLM が生成したコードを安全に実行する場所をどう用意するかは、いま最もホットなインフラ課題になっている。本記事では MicroVMs の技術的な仕組みを整理し、E2B / Modal / Cloudflare といった先行サンドボックスとの違い、そしてエンジニアがどう使い分けるべきかを掘り下げる。
ニュースの詳細 — 何が発表されたか
AWS Lambda MicroVMs は、従来の Lambda 関数とは設計思想が根本的に異なる。AWS 公式の発表では、以下のスペックと挙動が明示されている。
- 隔離モデル: 各 MicroVM は専用の仮想マシンとして起動し、カーネルもリソースも他セッションと共有しない（コンテナ型の Lambda 関数とは別物）
- 状態保持: メモリ・ディスク・実行中プロセスをセッションをまたいで維持できる
- 稼働時間: 1 インスタンスあたり最大 8 時間
- リソース上限: 最大 16 vCPU / 32 GB メモリ / 32 GB ディスク、アーキテクチャは ARM64
- アイドル自動停止: 一定時間（公式デモでは 15 分）アクセスがないと自動でサスペンドし、リクエスト到来時に自動再開する
操作は専用の API で行う。create-microvm-image で Dockerfile と S3 上の成果物からイメージを作り、run-microvm で事前初期化されたスナップショットから起動する。AWS が想定するユースケースとして、AI コーディングアシスタント、インタラクティブなコード実行環境、データ分析プラットフォーム、脆弱性スキャナ、ユーザー製スクリプトを動かすゲームサーバーが挙げられている。提供リージョンは US East（バージニア北部・オハイオ）、US West（オレゴン）、欧州（アイルランド）、そして アジアパシフィック（東京） だ。
技術的な背景 — 「Image-then-launch」とFirecracker
MicroVMs の肝は 「イメージ化してから起動する（image-then-launch）」 という起動モデルにある。通常のコンテナやVMは起動のたびにブートとアプリ初期化のコールドスタートを払う。MicroVMs はこれを回避する。まず Lambda 側で Dockerfile を実行し、アプリケーションを初期化したうえで、走っている状態のメモリとディスクをスナップショットする。以降の起動は、このスナップショットからの「復帰（resume）」になるため、数 GB 規模のインタラクティブセッションでも near-instant で立ち上がる。
この高速復帰を支えているのが Firecracker だ。Firecracker は AWS が開発した軽量仮想化技術で、すでに月間 15 兆回超の Lambda 関数呼び出しを支える実績がある。コンテナの起動速度に近い軽さと、ハードウェアレベルの VM 境界を両立しているのが特徴で、「untrusted code（信用できないコード）を安全に動かす」という要件に対する事実上の業界標準になりつつある。
ここで重要なのは「隔離モデルの選択」だ。サンドボックスの隔離手法は大きく分けて2系統ある。
- microVM 系（Firecracker など）: サンドボックスごとに独立カーネルを持つ。ハードウェアレベルの VM 境界で隔離する。
- gVisor 系: Google 製のユーザー空間カーネルがシステムコールを傍受し、ホストカーネルへ到達させない。
どちらも通常のコンテナ隔離より強固だが、メカニズムが違う。MicroVMs は前者を採る。つまり AWS は「信用できないコードの実行」に対して、最も保守的で堅い隔離を選んだということだ。
競合との比較 — サンドボックス戦国時代に殴り込む
AI エージェント向けのコード実行サンドボックスは、2026 年時点ですでに群雄割拠だ。代表的なプレイヤーと特徴を整理すると、MicroVMs の立ち位置が見えてくる。
- E2B: サンドボックスを Firecracker microVM 内で実行。untrusted code 実行に特化した専業プレイヤー。隔離モデルは MicroVMs と同系統。
- Modal: gVisor ベースの隔離。サンドボックス単体ではなく、推論・学習・バッチ処理まで含む広いプラットフォームの一部として提供。
- Cloudflare Sandboxes: 50ms 未満のコールドスタートを謳う最速クラス。グローバルネットワーク上でユーザーの近くでコードを動かせるのが強み。
つまり MicroVMs は「Firecracker による堅い隔離」という点では E2B と真っ向勝負になる。E2B が専業の身軽さで先行してきた領域に、AWS が「IAM・VPC・S3・CloudWatch といった既存エコシステムへのネイティブ統合」と「インフラ管理ゼロ」を武器に殴り込む構図だ。すでに AWS 上にワークロードを持つチームにとって、別ベンダーのサンドボックスを契約せずに同等の隔離を得られる意味は大きい。逆に、レイテンシ最優先なら Cloudflare、AWS 外で学習・推論まで一気通貫したいなら Modal、という棲み分けは当面残るだろう。
エンジニアへの影響 — どう使い、どこに気をつけるか
実務へのインパクトは、大きく3つの方向で考えられる。
第一に、AI エージェント・AI コーディング製品を作る人にとっては、自前で Firecracker クラスタを運用する選択肢が一気に現実味を失う。「LLM が吐いたコードを 1 ユーザー 1 環境で安全に走らせる」という、これまで最もインフラ運用がしんどかった部分を、run-microvm 一発に置き換えられる。マルチテナント前提の設計（テナントごとに隔離環境を払い出す）とも噛み合う。
第二に、状態保持と 8 時間稼働は、従来の Lambda では不可能だったワークロードを開ける。長時間のデータ分析セッション、対話的な REPL、ビルド環境、ユーザーごとに状態を持つゲームサーバーなど、「関数」では無理だったものが「サーバーレスのまま」実現できる。アイドル自動停止により、状態を保ったままコストを抑えられるのも実運用上は効く。
一方で注意点もある。ARM64 限定なので、x86 前提のバイナリやネイティブ依存があると素直には載らない。リソース上限（16 vCPU / 32 GB）を超える重い処理には不向きで、そこは EC2 や ECS の領分だ。そしてコストは公式の料金ページ参照とされており、VM レベル隔離・長時間稼働である以上、通常の Lambda 感覚で見積もると面食らう可能性がある。PoC の段階でアイドル停止の閾値と課金モデルを必ず確認しておきたい。
まとめ
- AWS Lambda MicroVMs は、Firecracker による VM レベル隔離・状態保持・最大 8 時間稼働を備えた新しいサーバーレス基本要素。
- 「image-then-launch」のスナップショット起動で、数 GB のセッションでも near-instant に復帰する。
- 主戦場は AI エージェントの「untrusted code 実行」で、隔離手法では E2B と同系統、レイテンシの Cloudflare、広さの Modal と棲み分けが進む。
- ARM64 限定・リソース上限・課金モデルが採用判断の分かれ目になる。
AI が生成したコードを「どこで安全に動かすか」は、エージェント時代のインフラの核心だ。その答えを AWS が自社エコシステムに統合してきたことで、サンドボックスの選択は「専業ベンダー vs クラウド純正」という新たな構図に入った。自分のワークロードがどの軸（隔離の堅さ・レイテンシ・既存基盤との統合）を最重視するかが、今後の選定の決め手になる。
今日のその他のニュース
- OpenAI が次世代モデル「GPT-5.6 Sol」をプレビュー公開（HN 353pt）。ChatGPT では 6/12 に GPT-5.2 系が提供終了し既存会話は 5.5 系へ自動移行済みで、モデルの世代交代が一段と加速している。
- Claude Code の Skill で SLO 対応を自動化した実例（はてブ 132users）。Uzabase がインシデント対応ワークフローを Skill 化し、AI による運用自動化の具体的効果を示した好事例。
- メインフレーム離脱プロジェクトの 7 割超が失敗（Gartner 調査、はてブ 65users）。原因はレガシーコード変換における生成 AI の能力の過大評価で、AI の現実的な限界を冷静に見る視点として話題に。