AIが書いたコードを安全に実行する「AWS Lambda MicroVMs」とは？
生成AIにコードを書かせること自体は、もう珍しくありません。少し難しいのは、その次です。
AIが作ったコードを、そのままサーバーで実行してよいのでしょうか。
意図せず大量のCPUを使うかもしれません。ファイルを消す、秘密情報を読む、外部へ勝手に通信するといった処理が混ざる可能性もあります。悪意がなくても、生成されたコードが安全とは限りません。
だからといって、実行のたびに専用サーバーや仮想マシンを用意すると、起動時間も運用負担も増えます。
この間を埋めるために、AWSは2026年6月、「AWS Lambda MicroVMs」を発表しました。利用者やジョブごとに独立した小さな仮想マシンを割り当て、AIやユーザーが作ったコードを隔離して動かすためのサーバーレスな実行環境です。
名前にはLambdaと付いていますが、従来のLambda Functionsとは使い方がかなり違います。
AIが作るコードには、実行場所が必要になる
一般的な生成AIは、文章としてコードを返すだけなら、こちらの環境を直接操作しません。危険が現実になるのは、そのコードへ実行権限を渡したときです。
たとえば、AIエージェントに次のような仕事を任せる場面を考えてみます。
プログラムを生成し、テストまで行う
データ分析用のPythonコードを実行する
Gitリポジトリを取得してビルドする
Webアプリを一時的に起動する
脆弱性を調べるツールを動かす
これらは、コードを提案するだけでは終わりません。パッケージを追加し、ファイルを作り、コマンドを実行し、場合によってはネットワークへ接続します。
複数の利用者が同じ実行環境を共有していると、ある処理の不具合が別の利用者へ影響する可能性があります。利用者ごとに環境を分ければ影響範囲は狭められますが、今度は大量の環境を素早く起動・停止する仕組みが必要です。
Lambda MicroVMsは、この「分離したいが、仮想マシンの基盤までは管理したくない」という用途を狙っています。
Lambda MicroVMsは“小さなLambda関数”ではない
MicroVMは、Micro Virtual Machineの略です。通常の仮想マシンより小さく素早く扱える一方、コンテナより強い分離境界を持たせやすい実行環境を指します。
Lambda MicroVMsでは、利用者、セッション、ジョブなどの単位で専用のMicroVMを作成します。各MicroVMはAmazon Linux 2023を実行し、独立したOS環境として扱われます。基盤には、通常のAWS Lambdaでも使われている仮想化技術「Firecracker」が採用されています。
ここで少し紛らわしいのが、従来のLambda Functionsとの違いです。
Lambda Functionsは、イベントやAPI呼び出しを受けて関数を実行する仕組みです。実行時間は1回につき最大15分で、環境が再利用される場合はあるものの、その状態が次回まで残るとは限りません。アクセス量に応じた横方向のスケーリングもAWS側が行います。
対してLambda MicroVMsは、1人の利用者や1つのジョブに専用環境を割り当てる設計です。自分のアプリケーションを起動し、ポートを待ち受け、同じ環境へ複数回接続できます。作成、休止、再開、終了といったライフサイクルは、利用側がAPIやアイドルポリシーで制御します。
| | Lambda Functions | Lambda MicroVMs |
|---|---|---|
| 主な用途 | API、イベント処理、データ変換 | AI・ユーザー生成コード、対話型環境 |
| 実行単位 | 関数の呼び出し | 利用者、セッション、ジョブごとの環境 |
| 状態 | 次の呼び出しまで残る保証はない | 休止中もメモリとディスクの状態を保持 |
| 最大時間 | 1回の呼び出しは最大15分 | 1つのMicroVMは最大8時間 |
| スケーリング | AWSが呼び出しに応じて自動調整 | 利用側がMicroVMを作成・終了する |
| 接続方法 | 関数呼び出しやイベント連携 | MicroVMごとの専用HTTPSエンドポイント |
Lambda Functionsの上位版という関係ではありません。処理の形が違うため、使い分けるサービスです。
あらかじめ環境を作り、スナップショットから起動する
Lambda MicroVMsを動かす流れは、次のようになります。
アプリケーションとDockerfileをZIP形式にまとめ、Amazon S3へ置く
Lambda APIからMicroVMイメージを作成する
AWSがアプリケーションを初期化し、メモリとディスクの状態をスナップショットとして保存する
実行が必要になったら、`run-microvm`でスナップショットからMicroVMを起動する
処理が終わったら休止するか、不要なら終了する
スナップショットは、初期化済みの実行環境を保存したものです。起動のたびにOSや依存パッケージを最初から準備するのではなく、準備済みの状態から立ち上げます。この仕組みによって、VMレベルの分離と短い起動時間を両立させています。
各MicroVMには専用のHTTPSエンドポイントが割り当てられます。HTTP/1.1とHTTP/2に加え、WebSocket、gRPC、Server-Sent Eventsにも対応しています。ブラウザ上の開発環境や、AIエージェントとの対話を続ける用途を想像すると、単発の関数呼び出しだけではない理由が見えてきます。
休止しても、作業状態を残せる
対話型の環境では、CPUを常に使うとは限りません。利用者がコードを読んでいる間や、AIが次の指示を待っている間は、処理が止まっています。
Lambda MicroVMsは、アイドル状態になった環境を休止できます。休止中はメモリとディスクの状態が保存され、再開後も作業を続けられます。自動再開を有効にしていれば、専用エンドポイントへ通信が届いた時点で再開させることもできます。
ただし、永続的なサーバーとして置いておく仕組みではありません。1つのMicroVMが実行または休止状態で存在できる時間は最大8時間です。長期間残す必要があるデータは、S3やデータベースなど、別の永続ストレージへ保存する設計が必要です。
再開時には、外部サービスとの接続が切れている可能性もあります。AWSのベストプラクティスでは、`/resume`というライフサイクルフックで認証情報を更新し、ネットワーク接続やキャッシュの状態を確認するよう案内されています。
停止していた処理が、何事もなかったように続くとは限りません。状態を残せることと、外部接続まで完全に保存できることは別です。
VMレベルの隔離は、何でも許可してよいという意味ではない
Lambda MicroVMsの中心にあるのは隔離です。利用者やジョブごとに環境を分けることで、問題のあるコードが別の処理へ与える影響を抑えます。
それでも、「MicroVMへ入れたから安全」と考えるのは危険です。コードからAWS APIへアクセスできるなら、実行ロールの権限範囲で操作できます。外部ネットワークへの通信を許せば、情報を送信される可能性も残ります。大量のMicroVMを終了し忘れれば、費用の問題になります。
実際の設計では、少なくとも次の制御が必要です。
実行ロールへ必要最小限のIAM権限だけを与える
ビルド用ロールと実行用ロールを分ける
認証トークンを短時間で失効させる
トークンから接続できるポートを限定する
機密データへ接続する場合は、VPC経由の外向き通信を使う
アイドル時間と最大実行時間を設定し、不要な環境を自動終了する
CPU、メモリ、ネットワーク、実行数の上限を監視する
各エンドポイントへの接続には、MicroVMとポート、有効期限にひも付いたJWE形式の認証トークンが必要です。AWSは15〜30分程度の短い有効期限と、利用するポートだけへの限定を推奨しています。
また、イメージ作成時にUUIDや秘密値を生成して、そのままスナップショットへ含める設計も避ける必要があります。同じイメージから起動した複数の環境が、同一の値を持ってしまう可能性があるためです。利用者固有の値は、MicroVM起動後の`/run`フックで生成します。
隔離は一枚の盾ではありません。IAM、認証、通信制御、時間制限を重ねることで、ようやく実行基盤として形になります。
どんなサービスに向いているのか
AWSは、Lambda MicroVMsが適する例として、次の用途を挙げています。
AIが生成したコードを試すサンドボックス
ブラウザから使う対話型の開発環境
利用者がスクリプトを実行するデータ分析サービス
複数利用者向けのCI/CD実行環境
脆弱性診断やセキュリティスキャン
AIエージェントの評価・学習環境
利用者が作ったスクリプトを動かすゲームサーバー
共通しているのは、「外部から渡されたコードを動かす」「処理ごとに隔離したい」「数分から数時間は状態を保ちたい」という点です。
反対に、画像をリサイズする、S3へのアップロードをきっかけに処理する、短いAPIへ応答するといった用途なら、従来のLambda Functionsのほうが自然です。常時稼働する一般的なWebサーバーや、8時間を超えて動き続ける処理なら、ECS、EKS、EC2なども比較対象になります。
新しいから採用するのではなく、実行単位を「関数」にしたいのか、「利用者専用の環境」にしたいのかで考えると整理しやすくなります。
料金とスケーリングにも独特の考え方がある
Lambda MicroVMsでは、起動中のベースラインとなるCPU・メモリに対して秒単位で料金が発生します。処理が増えたときは、設定したベースラインの最大4倍まで垂直方向に拡張でき、ベースラインを超えて実際に利用した追加リソースにも課金されます。
休止中はコンピューティング料金が発生しませんが、保存されたスナップショットにはストレージ料金がかかります。使わなくなったMicroVMを終了し、古いイメージも削除する運用が必要です。
標準クォータでは、1アカウント・1リージョンあたり、実行中MicroVMへ割り当てられるメモリの合計は400GBです。2GB構成なら200台分に相当します。ただし、新しいAWSアカウントでは初期クォータが小さい場合があります。増枠できる項目ではありますが、短時間に大量の環境を起動するサービスでは、起動APIのレート制限も含めて事前に確認したほうがよいでしょう。
東京リージョンでも利用できる
2026年7月18日時点で、Lambda MicroVMsは次の5リージョンで提供されています。
米国東部（バージニア北部）
米国東部（オハイオ）
米国西部（オレゴン）
アジアパシフィック（東京）
欧州（アイルランド）
AWSマネジメントコンソール、AWS CLI、CloudFormation、CDKから利用できます。新しいサービスなので、採用時には対象リージョン、料金、クォータ、対応アーキテクチャ、周辺ツールの対応状況を改めて確認する必要があります。
AIにコードを書かせるなら、実行環境まで設計する
AIがコードを書けるようになると、目立つのは生成精度です。しかし、サービスとして提供する段階では「どこで実行するか」「何へアクセスできるか」「失敗したとき、どこまで影響するか」のほうが厄介です。
Lambda MicroVMsは、その問題に対して、利用者やジョブごとに使い捨て可能な仮想マシンを用意するという答えを出しています。短時間で起動し、不要な間は休止し、終われば捨てる。従来のLambda Functionsより環境を直接扱えますが、その分だけライフサイクル管理も利用側へ戻ってきます。
AI生成コードを安全に実行するための完成品ではありません。隔離された実行場所を作るための部品です。
この区別は、かなり大きいと思います。AIエージェントへ任せる範囲が広がるほど、生成モデルだけでなく、その周囲に置く実行基盤の設計が問われるからです。
※この記事は2026年7月18日時点のAWS公式情報を基にしています。提供リージョン、料金、クォータ、仕様は変更される可能性があります。実際の採用時には、最新の公式ドキュメントと利用するAWSアカウントのService Quotasを確認してください。
