AWS Lambda MicroVMsは、AWS自身の表現によれば、ユーザーまたはAIが生成したコードを隔離されたstatefulな環境で実行するために構築された、新しいserverlessのプリミティブだ。注目すべきは2番目の言葉だ。今回のローンチは、本当のところfunctionの話ではない。AIのagentが書いたばかりのコードを安全に実行する場所を与えることが主題であり、AWSが「ユーザーまたはAI」と先頭に掲げた事実が、これが誰のためのものかを物語っている。

agentを作っているなら、すでにこの壁にぶつかっているはずだ。モデルがコードを書く。そして、それをどこかで実行しなければならない。信頼できないモデル生成コードを自分のインフラ上で動かすことは、誰もが過小評価する部分であり、まさにMicroVMsが肩代わりするために設計された部分だ。

agentが実際に抱えるsandbox問題

能力のあるagentは、ただ答えるだけではない。スクリプトを書き、実行し、結果を読み、反復する。code interpreter、データ分析agent、自律的なコーディングツール、これらはすべて一つの問いに生死を懸けている。そのコードはどこで実行されるのか?

素朴な答えはどれも悪い。自分のアプリケーションプロセス内で実行すれば、敵対的またはバグだらけの生成が一つあるだけで、ホストをダウンさせたり別のユーザーのデータを読み取ったりできる。共有コンテナで実行すれば、コンテナはkernelを共有するため、kernelの脆弱性一つでテナント間の侵害が起きる。自前のVMフリートを構築すれば、スタックの中で最も難しく、最も差別化につながらないインフラを運用する羽目になる。モデル生成コードは、定義上、信頼できないコードだ。礼儀正しい境界ではなく、本物の隔離境界が必要だ。

MicroVMsがagentの形にフィットする理由

Lambda MicroVMsは、agentが実際にどう振る舞うかと、3つの軸で噛み合う。

敵対的な出力に対しても持ちこたえる隔離

各セッションは、それぞれ独自のFirecracker MicroVMで実行される。kernelを共有せず、リソースを共有せず、ある環境から別の環境やホストへの経路もない。あなたのagentが、ユーザーのプロンプトから言語モデルが生成したコードを実行するとき、これこそが「agentが何か変なことをした」と「agentがプラットフォームを侵害した」の間に欲しい境界だ。prompt injectionを受けて流出や破壊を企てるagentも、使い捨てのVMの中に封じ込められる。

マルチステップなタスクに合致するstate

agentの作業がワンショットで終わることはまずない。パッケージをインストールし、データセットをロードし、中間ファイルを書き、3ステップ後にそれらに戻ってくる。MicroVMは、セッションをまたいでメモリ、ディスク、実行中のプロセスを保持し、モデルが考えている間やユーザーが席を外している間の長い休止中も、そのstateを保ったままsuspendでき、その後ほぼ瞬時にresumeできる。ロード済みのモデルや作業中のファイルセットは、単にそのまま残っている。これは、すべてのツール呼び出しごとに新しいコンテナを再ブートストラップするよりも、はるかに良いフィットだ。

インタラクティブに感じられるほど速い起動

すべてのMicroVMは、コールドブートではなく、事前に初期化されたFirecracker snapshotからresumeするため、数ギガバイトのセッションでも素早く戻ってくる。人間がカーソルの点滅を見つめているインタラクティブなagentにとって、snapshotからのresumeとコールドコンテナの起動の差は、使えるか見捨てられるかの差だ。セッションは最大8時間まで実行でき、長い分析や延々と続くコーディングセッションも余裕でカバーする。

AWSはruntimeだけでなく、agentループ全体を構築している

MicroVMのローンチは単独で来たわけではない。AWSは同時にagent setup guideも出荷した。これは、コーディングagent、Claude Code、Codex、Cursor、Kiro、Copilot、Windsurf、OpenCodeを、plugin、agent skill、MCP Serverを通じてserverless開発に結びつけるものだ。この2つを併せて読むと、戦略は明確だ。agentがserverlessアプリケーションの構築を手伝い、MicroVMsはそれらのagentが生成するコードを安全に実行できる場所になる。AWSは、コードを書くagentと、それを実行するsandboxという、ループの両端を握ろうとしている。

これが解決しないこと

隔離は境界であって、頭脳ではない。MicroVMは、モデル生成コードがsandboxから脱出するのを止める。だが、agentが箱の中で愚かだが許可された何かをすることや、影響範囲を箱の外まで広げられる認証情報を渡されることは、何一つ止めない。本物のシークレットをマウントしたり、sandboxに広範なIAMロールを渡したりすれば、injectされたプロンプトが正規のAPI呼び出しを通じて与える損害に対して、VMの境界は無関係になる。sandboxが到達できる範囲は、それを隔離するのと同じくらい厳密にscopeを絞ること。runtimeは簡単な方の半分だ。agentへの最小権限は、依然としてあなたの責任のままだ。

まとめ

agentブームのほとんどの間、生成されたコードが実際にどこで実行されるかというruntimeの問いは、ガムテープで答えられてきた。ここにコンテナ、あそこにロックダウンされたプロセス、余裕のあるチームには自作のVMプール。Lambda MicroVMsは、それをVMレベルの隔離、statefulなセッション、snapshot速度のresumeを備えたマネージドなプリミティブに変え、API呼び出しとして公開する。それは、agentが何を決めるかという点で、agentを賢くも安全にもしない。だが、agentが書くコードに、周囲のすべてを巻き込んで倒すことのない実行場所を与える。そして本番agentにとって、それが足りなかったピースだった。

次に読む

同じローンチのserverlessとインフラ視点での解説、ライフサイクル、CLI、通常のLambdaとの位置づけについては、ercan.cloudのフィールドノートを参照してほしい。AI、AWS、プラットフォーム関連のコンサルティングについて、あるいはただ挨拶するだけでも、ercanermis.comから始めてほしい。

参考資料