9月19日、AWSが「Running self-hosted AI agent sandboxes with AWS Lambda MicroVMs」と題した記事を公開した。この記事では、AWS Lambda MicroVMsを使ってAIエージェントのツール実行を安全に隔離するセルフホスト型サンドボックスの設計・実装方法について詳しく紹介されている。
なぜ「サンドボックス」が必要なのか
AIエージェントがシェルコマンドを実行し、データベースに接続し、ファイルを書き換える——そういった用途が実際の開発現場に浸透しつつある。このとき問題になるのがセッション間の分離だ。
記事が提示する具体例が分かりやすい。「アナリティクスDBの遅いクエリを10件見つけ、インデックスを改善して、結果をテストしろ」という1タスクだけで、ライブDBへの接続・コード生成・実行という3つのツール呼び出しが発生する。これが50人の開発者で同時に走れば、各セッションが独立したクレデンシャル・ファイルシステム・ネットワーク境界を必要とする。分離が不十分なままだと、クレデンシャルや状態がセッションをまたいで漏れるリスクが生じる。
クラウドベンダーが提供するマルチテナントのサンドボックスを使う手もあるが、それではネットワークやガバナンスの制御を手放すことになる。e2bやModal、Daytona等の外部サンドボックスサービスも同様に、実行環境がベンダーのインフラ上に置かれるため、VPCポリシーや既存IAMロールとの統合に制約が生じやすい。自社のAWSアカウント内に閉じたセルフホスト型サンドボックスを構築することで、ガバナンスを維持しつつエージェントの実行環境を柔軟に制御できる——それが今回の主題だ。
Lambda MicroVMsの3つの特性
AWS Lambda MicroVMsは、Firecrackerによる仮想化をベースにしたサーバーレスコンピュート環境で、最大8時間稼働するAmazon Linux VMをプログラムから起動・停止・再開できる。エージェントサンドボックス用途に適した3つの特性が挙げられている。
- VMレベルの分離：各セッションが独立したFirecracker VMで動作する。フルVMほどのリソースオーバーヘッドや起動時間を必要とせず、セッション間の干渉がハードウェア仮想化レベルで防がれる。
- スナップショットからの起動：Lambda SnapStartと同様に、事前キャプチャしたメモリ・ディスクスナップショットからブートするため、アプリケーション初期化をスキップして即座に利用可能な状態になる。
- 再プロビジョニングなしの4倍スケール：実行中のMicroVMのCPU・メモリを最大4倍（0.25 vCPU/0.5GBから4 vCPU/8GBまで）に拡張できる。重いデータ変換処理が発生しても、VMを作り直さずにリソースを追加できる。
アーキテクチャ：Webhookで起動し、使い捨てるVM
記事の核心はイベント駆動の参照アーキテクチャにある。エージェントオーケストレーションサービス（ここではAnthropic Claude Managed Agents※）からのWebhookを受け取り、1セッション1 MicroVMを起動し、完了後に破棄する設計だ。
※ Anthropic Claude Managed Agentsは、Anthropicが提供するエージェントセッション管理サービス。元記事における正式名称をそのまま使用している。
セッション実行の流れは以下のとおり：
- オーケストレーションサービスがセッションをキューに入れ、
session.status_run_startedWebhookをAmazon API Gatewayへ送信する - ランチャー（Lambda関数）がAWS Systems Manager Parameter Storeから取得した署名シークレットでWebhook署名を検証し、不正・リプレイリクエストをここで弾く
- 検証通過後、ランチャーが
RunMicrovmを呼び出し、セッションIDと環境キーのARN参照をペイロードとして渡す。Amazon DynamoDBでWebhookイベントIDの重複排除を行い、リトライによる二重起動を防ぐ - MicroVMがFirecrackerスナップショットから起動し、
/runライフサイクルフックでディスパッチを受け取る。ワーカーがParameter Storeから環境キーを取得し、セッションをクレームしてツール呼び出しを実行。完了後にterminate-microvmを呼んで自己終了する
クレデンシャルの境界が明確に設計されている点も重要だ。ランチャーはWebhook署名シークレットにしかアクセスできず、MicroVM側は環境キーにしかアクセスできない。どちらのコンポーネントも両方のシークレットを持たない。
# signing_secret はParameter Store等から取得する（コード中にハードコードしない）
signing_secret = get_signing_secret_from_parameter_store() # Verify webhook before spending compute
if not verify_signature(raw_body, headers, signing_secret):
return {"statusCode": 401, "body": "invalid signature"}
// MicroVM worker: /run ライフサイクルフック
case "run": {
const envelope = JSON.parse(rawBody);
const dispatch = JSON.parse(envelope.runHookPayload);
res.writeHead(200); // フックをすぐにACK
res.end();
const key = await fetchParameter(dispatch.session.ENVIRONMENT_KEY_PARAM_NAME);
await pollAndHandleSession(dispatch.session.ANTHROPIC_SESSION_ID, key);
await terminateMicroVm(envelope.microvmId);
}
コスト構造
記事ではコストモデルも明示している。セッションがアクティブでない間はMicroVMが一切稼働しない。費用はMicroVMの実行時間、API Gatewayのリクエスト、Parameter Store APIコール、ランチャーLambdaの実行分のみで、アイドル時のコンピュートコストは発生しない。
なお、ポーリング型（always-on）のワーカーパターンはこのアーキテクチャに向かないと記事は明言している。セッション間にアイドルが生じると自動サスペンドが働いてポーリングループが壊れるためだ。Webhookトリガー型を使うべきとされている。
デプロイは4ステップ
参照実装はaws-samplesで公開されており、AWS SAMでインフラを定義している。
sam build && sam deployでコントロールプレーン（Lambda、API Gateway、WAF WebACL、DynamoDB、Parameter Store）を展開- Claude ConsoleでWebhookエンドポイントを登録し、署名シークレットと環境キーをParameter Storeに格納
build-image.shでDockerfileとワーカーコードをパッケージしてS3にアップロード、MicroVMイメージを作成（Firecrackerスナップショットが生成される）- テストセッションを作成して検証スクリプトで動作確認
AIコーディングエージェントを使っている場合は、Agent Toolkit for AWS（AWSが提供するエージェント向けツールキット。各種AWSサービスをエージェントのスキルとして呼び出せるようにするOSSライブラリ）にLambda MicroVMsのスキルが含まれており、エージェント自身にサンドボックス環境のプロビジョニングを任せることもできるとされている。また、AWSが2025年に発表したAIネイティブIDE Kiro（仕様駆動の開発フローを持つIDEで、エージェントモードでのツール実行を前提に設計されている）との組み合わせも言及されており、Claude CodeやCursor等のエージェント環境からも同様に利用できる。
詳細はRunning self-hosted AI agent sandboxes with AWS Lambda MicroVMsを参照していただきたい。
