Lambda MicroVMsリリース同日に公開されたスキルで、一意性問題を考慮したコード生成を試してみた

はじめに

2026年6月22日、AWSはLambda MicroVMsを発表しました。Firecracker microVM内でコンテナを実行するサーバーレスコンピュート環境で、VMレベルの分離・高速起動・最大8時間のサスペンド/レジュームを提供します。

https://aws.amazon.com/jp/about-aws/whats-new/2026/06/aws-lambda-microvms/

同日、AWS公式リポジトリ agent-toolkit-for-aws にもLambda MicroVMsスキルが追加されました。AIエージェント向けに、このサービス固有の設計知識を構造化したリファレンス群です。

https://github.com/aws/agent-toolkit-for-aws/tree/main/skills/specialized-skills/serverless-skills/aws-lambda-microvms

Lambda MicroVMsはスナップショットからの起動、ライフサイクルフック、サスペンド/レジュームなど独自の概念が多く、スキルの有無で開発体験が大きく変わります。

この記事では、このスキルの構成を紹介し、スキルの有無でコード生成品質がどう変わるかを実証します。

Lambda MicroVMs スキルの構成

agent-toolkit-for-awsは、AWSサービスに特化したAIエージェント向けのスキル集を提供するGitHubリポジトリです。各スキルは SKILL.md（概要・判断基準・典型ワークフロー・制約事項）と references/（サービス固有の詳細リファレンス群）で構成されます。

Lambda MicroVMsスキルは以下のファイルで構成されています。

aws-lambda-microvms/
├── SKILL.md
└── references/
    ├── getting-started.md
    ├── lifecycle-model.md
    ├── snapshots-and-uniqueness.md
    ├── networking.md
    ├── iam-and-security.md
    └── troubleshooting.md

https://github.com/aws/agent-toolkit-for-aws/tree/main/skills/specialized-skills/serverless-skills/aws-lambda-microvms

SKILL.md の読みどころ

SKILL.mdにはAIエージェントの「判断力」となる情報が集約されています。

description（冒頭） — AIがスキルを選択するかどうかの判断材料です。Lambda MicroVMsが適するユースケース（AIサンドボックス、マルチテナントCI、ゲームサーバー等）が列挙されています。

When to use / Choose something else — Lambda MicroVMsと通常のLambda関数、ECS/EKSの使い分け基準が明確に記載されています。AIがアーキテクチャ提案時に適切なサービスを選択するための判断基準になります。

Typical workflow — イメージ作成からトークン発行までの全体像がCLIコマンド付きで示されています。

Known constraints — イメージがサイズ固定であること、認証トークンの最大TTLが60分であることなど、設計時の制約が記載されています。ランタイムフックのタイムアウトは最大60秒です。

Security considerations — Confused Deputy対策、スナップショット一意性、ネットワーク分離、最小権限の実行ロールなど、セキュリティ上の留意点がまとめられています。

スキルをAIエージェントに渡す方法

スキルを活用するには、AIエージェントのコンテキストに読み込ませます。主な方法は以下のとおりです。

• Kiro — Knowledge Baseにリポジトリまたはファイルを追加
• Claude（API） — system promptにスキル内容を含める
• Amazon Q Developer — カスタマイズ設定で参照
• GitHub Copilot — リポジトリに配置するか、カスタムinstructionsに含める

SKILL.mdだけでも効果はありますが、references/ 内のリファレンスも合わせて渡すとより正確な生成が得られます。今回の検証では、Kiro CLIのヘッドレスモードでプロンプト先頭に snapshots-and-uniqueness.md の内容を付与する形で渡しました。

検証: スナップショット一意性問題の回避コード生成

背景: スナップショット一意性問題とは

Lambda MicroVMsは同一スナップショットから複数VMを起動するため、スナップショット作成時に保持された値がVM間で重複する問題があります。詳細は以下の記事で検証しています。

https://dev.classmethod.jp/articles/lambda-microvms-snapshot-random-uuid-duplication/

検証方法

Kiro CLIのヘッドレスモード（--no-interactive）で以下の共通プロンプトを使用し、スキルなし/ありの2パターンで各3回コード生成を実行しました。

共通プロンプト:

Lambda MicroVMs で Flask アプリを作ってください。
以下の要件:
- セッション ID をアプリ起動時に生成してメモリに保持
- リクエストごとにランダムなトークンを返す
- GET /session でセッション ID を返す
- GET /token でランダムトークンを返す
- Dockerfile も作成（ベース: public.ecr.aws/lambda/microvms:al2023-minimal）
- コードのみ出力（説明不要）

スキルありの場合は、上記プロンプトの前に snapshots-and-uniqueness.md を付与しました。

検証環境:

• Kiro CLI + Claude Sonnet 4（--model claude-sonnet-4）— 各パターン3回
• Claude Code + Opus 4.8（claude -p --model opus）— 各パターン3回（追試）

結果: スキルなし（3回とも同一パターン）

import uuid
import secrets
from flask import Flask, jsonify

app = Flask(__name__)
session_id = str(uuid.uuid4())  # ❌ グローバルスコープ（ビルド時）で生成

@app.route('/session')
def get_session():
    return jsonify({'session_id': session_id})

@app.route('/token')
def get_token():
    return jsonify({'token': secrets.token_hex(16)})

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080)

session_id がモジュールロード時（= スナップショット取得時）に固定されるため、全MicroVMが同じsession_idを共有します。/run フックの存在自体を知らないため、session_id の一意性問題に対する回避策が講じられていません。

結果: スキルあり（代表例: Run 1）

import os
import secrets
from flask import Flask, jsonify

app = Flask(__name__)

# セッションIDは/runフック後に生成
session_id = None

@app.route('/session')
def get_session():
    return jsonify({'session_id': session_id})

@app.route('/token')
def get_token():
    return jsonify({'token': secrets.token_hex(16)})

@app.route('/run', methods=['POST'])
def run_hook():
    global session_id
    # スナップショット復帰後にユニークなセッションIDを生成
    session_id = secrets.token_hex(8)
    return '', 204

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=int(os.environ.get('PORT', 8080)))

スコアリング

各回の素点: スキルあり 5/5, 5/5, 4/5（Run 3 は /run 内生成ではあるものの、期待した secrets 系APIではなく uuid4() を使用したため -1）。スコアは5観点の達成数（各1点、⚠️は0.5点）を試行ごとに算出し、3回平均をとりました。

考察

スキルなしの場合、モデルは「Flaskアプリを作る」という一般的な知識で応答し、Lambda MicroVMsのスナップショット起動という特殊性を考慮できませんでした。

スキルありの場合、3回とも /run フックを正しく実装し、スナップショット一意性問題を回避しています。snapshots-and-uniqueness.md に記載された以下の記述が影響した可能性があります。

Generate it in /run. This hook fires once after run (post-snapshot resume) and is the canonical place to create per-VM unique state.

この記述を含むリファレンスがコンテキストにあることで、モデルはフック内で一意値を生成するパターンを選択しやすくなったと考えられます。

追試: Claude Code (Opus 4.8) での検証

モデルを変えた場合にも同様の傾向が見られるかを確認するため、Claude Code（Opus 4.8）でも同一プロンプトで追試しました。

スキルなし（Opus）: 3回ともグローバルスコープで生成。今回の検証では secrets.token_hex を使うケースが見られましたが、/run フックは一度も実装されませんでした。

スキルあり（Opus）: 3回とも満点。/run フック + secrets.token_hex に加え、threading.Event で /run 完了までリクエストをブロックする実装まで含まれていました。

# Opus 4.8 スキルあり（代表例）— /run 完了待機付き
_session = {"id": None, "microvmId": None}
_session_ready = threading.Event()

@app.route("/run", methods=["POST"])
def run_hook():
    payload = request.get_json(silent=True) or {}
    _session["id"] = secrets.token_hex(16)
    _session["microvmId"] = payload.get("microvmId")
    _session_ready.set()
    return jsonify({"status": "ok", "sessionId": _session["id"]})

@app.route("/session", methods=["GET"])
def get_session():
    _session_ready.wait()  # /run 完了まで待機
    return jsonify({"sessionId": _session["id"]})

モデル能力が高いほどスキルあり時の精度は上がりますが、今回の検証では、スキルなしの場合どちらのモデルも一意性問題を回避できませんでした。少なくともこの検証範囲では、スキル（ドメイン知識）の有無が生成結果に大きく影響した可能性が示唆されます。

注意事項

• AIの生成結果は試行ごとにブレます。今回の結果は「スキルがあると安全なコード生成の確度が上がる」ことを示すものであり、必ずこうなるとは限りません
• スキルなしでも安全なコードが出る可能性はあります。しかし今回の検証（2モデル × 各3回 = 計6回）ではスキルなしで /run フックが実装されることは一度もありませんでした
• 実際のプロダクション利用では、AI生成コードに対して /run フックの実装やスナップショット一意性の観点でレビューすることを推奨します

まとめ

Lambda MicroVMsのリリース同日に、agent-toolkit-for-awsにはAIエージェント向けのLambda MicroVMsスキルも追加されていました。このスキルは、スナップショット起動やライフサイクルフックなど、MicroVM固有の設計知見をAIエージェントに渡すための仕組みです。

今回の検証では、snapshots-and-uniqueness.md をコンテキストに含めることで、全試行で /run フック内にセッションID生成処理が実装され、今回の評価観点ではスナップショット一意性問題を回避できていました。スキルなしの場合はいずれもグローバルスコープでセッションIDを生成しており、MicroVM固有の一意性問題は考慮されませんでした。

新しいサービスをAIエージェントと使う際は、「まず公式スキルを渡してからコード生成する」ことで、サービス固有の落とし穴を踏みにくくできます。コード生成だけでなく、既存コードのレビューやトラブルシュートにも活用できそうです。

参考リンク

• agent-toolkit-for-aws リポジトリ
• Lambda MicroVMs スキル
• snapshots-and-uniqueness.md