AI 生成コードやユーザーごとのコードを VM 単位で隔離して動かす Lambda MicroVMs の仕組みと始め方を整理する。2026年10月の追加リージョンに日本は含まれない。
14リージョン Lambda MicroVMs を使えるリージョン数 2026年10月22日の AWS 告知。香港・マレーシア・タイ・スペインの4つを追加した後の合計
AWS は2026年10月22日付の告知で、Lambda MicroVMs の提供先に4リージョンを加えた。追加されたのは Asia Pacific (Hong Kong)、Asia Pacific (Malaysia)、Asia Pacific (Thailand)、Europe (Spain) で、これで合計14リージョンになる。今回の追加に東京・大阪は入っていない。
ただし告知の本文には14リージョンの内訳が並んでいない。東京や大阪が以前からの10リージョンに含まれているかどうかは、この告知だけでは判断できない。AWS 自身も、最新の提供状況は「AWS Capabilities by Region」のページで確かめるよう案内している。日本のリージョンで使えるかを知りたいなら、まずそこを見ることになる。
告知の説明では、Lambda MicroVMs は「serverless compute primitive」で、ユーザーが書いたコードや AI生成コードを実行するためのものだ。特徴として挙げられているのは3つある。
想定される用途として、AI コーディングアシスタント、対話型の開発環境、脆弱性スキャナーが名指しされている。どれも「誰かが持ち込んだ、中身を信用できないコード」を動かす場面だ。
告知が強調しているのは、隔離・速度・状態保持のどれかを諦めずに済むこと、そして仮想化の基盤を自分で管理しなくてよいことである。ユーザーやジョブごとに専用の隔離環境を渡す設計を、自前の VM 管理なしで組めるという位置づけになる。
始め方は2段階で説明されている。まず手元の Dockerfile から MicroVM イメージを作り、次にそのイメージから MicroVM を起動する。コンテナイメージをすでに持っているチームなら、出発点は同じファイルだ。
起動した MicroVM には、ユーザーやジョブごとに専用の HTTPS URL が付く。この URL は HTTP/2、gRPC、WebSocket に対応している。エディタ風の UI と長時間の双方向通信をやり取りする開発環境や、gRPC でジョブを投げるスキャナーのような構成を、プロトコルを変えずに載せられることになる。
操作の入口は Lambda コンソール、AWS CloudFormation、AWS CDK の3つに加え、Agent Toolkit for AWS 経由でエージェント型の開発ツールからも扱える。IaC で管理しているチームは、CloudFormation か CDK に寄せるのが自然だろう。具体的なリソース定義や API の形は告知には載っておらず、開発者ガイドが参照先として示されている。
AWS は今回の拡大の狙いを、エンドユーザーの近くで動かしてレイテンシとデータ所在地（data residency）の要件を満たしやすくすることだと説明している。香港、マレーシア、タイ、スペインにユーザーやデータを抱えるサービスなら、その国・地域の中で MicroVM を動かせる選択肢が増えたことになる。
日本向けのサービスでは事情が違う。データを国内に置く必要がある場合、今回の4リージョンはその要件を満たさない。東京か大阪が既存の提供先に入っていればそちらを使えるが、入っていなければ、日本国内でのデータ保持が条件の案件にはまだ載せられない。どちらなのかは上で触れたリージョン一覧のページ次第で、ここでは断定しない。
採用を考えるなら、次の順で確かめると手戻りが少ない。
AI生成コードをどこで実行するかは、エージェントを組むチームにとって避けて通れない設計判断になっている。隔離の単位を VM まで上げつつ状態も残したい、という要件に対して、AWS がマネージドの答えを出しているのが Lambda MicroVMs だ。日本からの利用可否は、まずリージョン一覧で確定させてから比較に入りたい。
