エージェントはローカル、検証はMicroVM — Lambda MicroVMsでつくるServerless CI

コーディングエージェントは、ソースコードだけでなく、依存関係の追加、ビルド、テスト、サーバープロセスの起動まで扱うようになりました。
開発者としては、エージェントをローカルで動かし、経過を確認しながら指示を加えたい。
一方、依存関係や任意プロセスを伴う生成結果は、開発者端末とは分離した環境で検証したい。
この「対話しながら作る」と「独立した環境で確かめる」の両立が課題です。
汎用runnerへ検証対象ごとのツールを積み増せば環境管理が複雑になり、変更ごとに専用Imageを作ると構築待ちが生じます。

本セッションでは、エージェントをMicroVM上で動かすのではなく、エージェントがローカルで作った成果物をCIが変更ごとのAWS Lambda MicroVMsで再実行するServerless CIを提案します。
そのために、更新頻度の異なる「検証環境」と「エージェントの成果物」を分離します。
OS、ランタイム、ビルドツール、テスト実行機能は、バージョン管理したMicroVM Imageとして再利用します。
一方、成果物の取得先、ハッシュ値、実行条件はjob入力としてCIから渡します。
CIは変更ごとにMicroVMを払い出し、artifactを照合してビルド・テストを実行し、結果回収後に環境ごと破棄します。
これにより、エージェントとの対話性を維持したまま、変更のたびにImageを増やすことなく、再現性が高く独立した検証環境を用意できます。

何をMicroVM Imageへ含め、何をjob入力に残すか、Imageをどの条件で更新するかを中心に、継続利用するImageをIaCで管理し、一時MicroVMをCIから払い出す構成、ライフサイクルフック、結果回収とMicroVMの終了までを、実AWS上のプロトタイプに基づいて解説します。

すべてのテストをMicroVMへ移すことが目的ではありません。
通常のCIで十分な検証と、独立した環境が有効な検証を見極める基準も示します。
エージェントとの対話性と、生成結果を独立して検証する実行環境を両立するための設計知を共有します。

Transcript

1. エージェントはローカル、検証はMicroVM - Lambda MicroVMsでつくるServerless CI 藤岡 敦史 @fujioka_aa ForgeVision, Inc. https://www.forgevision.com/
2. 自己紹介 藤岡 敦史 @fujioka_aa フォージビジョン株式会社 シニアエンジニア スキル ✓ インフラ(AWS, サーバーレス) ✓ バックエンド(Python, Node.js) ✓ AI(Bedrock, Codex) 著書 AWS認定 DevOpsエンジニア プロフェッショナル テキスト 2
3. 今日 話すこと/話さないこと 話すこと ✓ ✓ ✓ ✓ エージェントをローカルで扱う際の課題 開発サイクルにおけるMicroVMsの位置付け・扱い CI でMicroVM を効率的に回すための手法 既存CIで十分な場合と、MicroVMを追加すると効果的な場合の 判断材料・基準 話さないこと ✓ フルVM、コンテナ、WASM などとの比較検討 ✓ VM上での、パッケージやコードに対する、スキャン・診断の手法 ※ ✓ どの開発現場にも、そのまま適用できる正解パターン ※ What to do when you receive an alert（Socket, 2026.06） 3
4. AIエージェントの役割は広がり続けている コード 生成 依存関係 の追加 ビルド・ テスト サーバー 起動 ここまでやるのが、開発現場で一般的になってきている 4
5. AIエージェントの役割は広がり続けている コード 生成 依存関係 の追加 ビルド・ テスト サーバー 起動 依存関係の追加やコード実行まで 行うことで生じるリスク (Ex. 意図しないファイル操作・外部通信) 5
6. リスクへのカウンターはあるが... モデルへの制御 環境による制限 AGENTS.mdやruleによる誘導 ファイルへのアクセス権限など、 操作権限の制限 プロンプトや指示による、 危険な行動の禁止・抑制 通信の遮断・制限、 実行環境の分離 モデルへの制御は導入しやすいが、制御のみで完全にリスクを 抑えるのは難しい。環境による制限も必要（制御と制限の相互補完） How we contain Claude across products (Anthropic, 2026.05) 6
7. 安全な実行環境とは エージェントをリモートで実行させる潮流もある （Ex. ヘッドレス実行、自律的なロングラン） ただ開発現場では、ローカルでのニーズも強い ✓ ファーストステップでの利用 ✓ ローカルならではの対話・作業のしやすさ ✓ 相対的にコスパ良くなりがち 対話や実装はローカルで行いつつ、リスクある 依存関係の追加やコード実行などを別環境へ移せないか？ 7
8. 開発現場での実用的なバランスを図るために ① ローカルの対話性・利便性は保ちたい ② 手元の状態に依存せずに動くことも確かめたい、かつ 端末への影響は限定したい ③ そのために、変更のたびに不要な環境構築や待ち時間を 増やしたくない 分離環境は どこが良い？ ローカル・分離 環境の境界は？ どうやって効率的 にビルド・検証 できる？ 8
9. AWS Lambda MicroVMs Lambdaの使い勝手と同様に、セッション/ジョブごとに独立した 実行環境(MicroVM)が割り当てられる アプリ、ユーザーランド、Linuxカーネ ルをMicroVM イメージとして作成。 高速に起動可能 Lambda MicroVMs Dockerfileで定義した環境を構築 AWSマネージド な基盤/仮想化 MicroVMごとに独立した カーネル、ファイルシステム、 ネットワーク名前空間など ※以下を元にイメージ図を作成 AWS Lambda MicroVMs core concepts Announcing Lambda MicroVMs: serverless compute environments with VM-level isolation and near-instant startup 9
10. Lambda MicroVMsのCIへの活用 CIとしてLambda MicroVMsで、 依存関係の導入・ビルド・テスト・起動確認を実施 ローカル端末への影響を限定 ローカルでのコーディングエージェントとのインタラクティブな開発は残し、 未確認の変更は、VM上で実行・確認する 起動したアプリのチェック 専用HTTPSエンドポイントが払い出されることで、スムーズに確認 検証環境を保持しての、迅速な中断&再開（Suspend/Resume） 検証作業を柔軟に中断&再開できる（中断時はコンピューティング料金がゼロ） 不要になったVMの削除（Termination） 削除して常にフレッシュなVMを使用。時限式での自動削除も可能 10
11. 補足：既存CIとの関係性 既存のCIの実行環境も、ジョブ単位で 環境が分離、削除される HTTPSエンドポイントの払い出しや、 迅速な中断&再開に有効 (外からの応答チェック、 中断&再開ありの継続的な追加調査 など) GitHub-hosted runner CodeBuild Lambda MicroVMs ローカル検証や既存CIランナーは無くならない。 CI実行環境の選択肢にLambda MicroVMsが加わり、 それぞれの役割・特徴に応じて使われる 11
12. MicroVMを含めた開発サイクル クラウド へのデ プロイ コーディ ング プッシュ ビルド テスト フィードバック 監視& 運用 結合 テスト デバッグ リリース ローカル開発(インナーループ) クラウドへのデプロイ〜運用 (アウターループ) 12
13. MicroVMを含めた開発サイクル MicroVMでの、 マージ前の簡易検証 (短いアウターループ) コーディ ング VMへ プッシュ &ラン クラウド へのデ プロイ プッシュ ビルド テスト フィードバック デバッグ ローカル開発(インナーループ) 監視& 運用 結合 テスト 応答 チェック リリース クラウドへのデプロイ〜運用 (アウターループ) 13
14. MicroVMを含めた開発サイクル MicroVMで確認済みの依存&コードと、リスク の小さいものは、従来通りローカルで動かす コーディ ング MicroVMでの、 マージ前の簡易検証 (短いアウターループ) VMへ プッシュ &ラン プッシュ ビルド テスト フィードバック デバッグ ローカル開発(インナーループ) 応答 チェック リスク疑いあれば、ローカルよりも 先にMicroVMで動かす Ex.依存関係更新(npmパッケージ追加)、 特定のコード実行（ファイル操作） 14
15. MicroVMを含めた開発サイクル MicroVMでの、 マージ前の簡易検証 (短いアウターループ) コーディ ング VMへ プッシュ &ラン プッシュ ビルド MicroVM リスクをMicroVMに移しつつ、 ローカルでのエージェントを使っ た対話的な開発サイクル テスト フィードバック デバッグ ローカル 応答 チェック ローカル開発(インナーループ) 15
16. ローカル実行できる条件 インナーループ（ローカルでの短いサイクル）で扱う実行・スコープは、 それぞれの影響を把握してリスクを許容できるかによって判断する 影響範囲の限定・把握 影響範囲の限定・把握 可能 ◦ 不可 × 変更内容 影響範囲はどこか？ 計算や文字列処理の ロジック変更 ✓ 処理結果を利用する後続処理 （書き込みなど） ローカル 一時ファイルの作成・削除 ✓ 対象のファイル / ディレクトリ ローカル MicroVM ビルド設定やコマンドの 変更 ✓ 生成物、作業領域、コマンド から呼び出される処理 ローカル MicroVM 外部APIアクセスの追加 ✓ 送信データ、接続先の状態・ 情報 MicroVM 新規/未確認の依存関係・ パッケージを追加 ✓ 導入時や処理実行時にアクセ スするファイルや接続先 MicroVM 16
17. プロト：Node.jsアプリ ＋ MicroVM サーバーレスCI より具体的にイメージするために、プロトタイプとして、 Node.jsアプリを MicroVMサーバーレスCIでビルド・検証する構成 を例に インナーループ ローカル Zipを アップロード GitHub Actions で起動 GitHubリポジトリ S3バケット ビルド・テスト create-microvm-image GitHub-hosted runner HTTPS接続 して検証 ローカル Lambda MicroVMs run-microvm 短い アウターループ GitHub Actions 17
18. プロト：Node.jsアプリ ＋ MicroVM サーバーレスCI Q. リスクを踏まえて、ローカルからMicroVMに移した 場合でも開発効率は落としたくない どこのプロセスを工夫できる?? 18
19. 共通イメージ / ジョブによる変更成果物の反映 A. イメージ作成とジョブ実行 を組み合わせて効率化を図る ジョブ(変更したコードや依存関係) ソース、テスト、lockfile、 ポート番号、Argvなどパラメータ MicroVMイメージ(共通利用するもの) OS、ランタイム、共通ツール(bashなど)、 Handler（ジョブの変更成果物を 受けるハンドラ） ペイロードに、ジョブごと の変更成果物を注入!! & aws lambda-microvms run-microvm \ Handlerで変更を --image-identifier <created-image-arn> \ ハンドリング・反映 --run-hook-payload ‘{“key”:”value”, ・・・}’ aws lambda-microvms create-microvm-image \ --name ci-vm-image-name \ --code-artifact '{"uri":"s3://<bucket-name>/<zip-filename>"}' \ --base-image-arn <image-arn> \ --build-role-arn <build-execution-role-arn> Lambda MicroVMs 19
20. プロト：Node.jsアプリ ＋ MicroVM サーバーレスCI Dockerfileやソースコードを 作成&アップロード Dockerfile（抜粋） FROM node:22-alpine RUN apk add --no-cache bash curl procps tar # パッケージ追加 COPY dist/handler.js ./handler.js # 変更成果物を受け付けるハンドラの配置 CMD [“npm”, “start”] # メインアプリ&ハンドラの起動 共通設定(Ex. OS、ランタイム、ハンドラ など)を変更したい場合のみ、 イメージは再作成する 20
21. プロト：Node.jsアプリ ＋ MicroVM サーバーレスCI 起動ジョブ実行時に、 変更成果物を指定する 起動コマンドにPayload(変更成果物・実行指示 など)を付与 runHookPayload: { “artifact”: { “s3Key”: “artifact/app-v1-123456.zip”, # 変更したソースコード イメージを作り直さず “sha256”: “1a2b....8h9i”, に変更を反映！ }, “job”: { “argv”: [“build”, “test”, “xxxxxx”] # イメージに配置済みのハンドラに渡す引数 } (テスト・検証ステップをコントロール) } 21
22. プロト：Node.jsアプリ ＋ MicroVM サーバーレスCI MicroVMが払い出すTokenを 使用してHTTPSアクセス & 簡易検証 aws lambda-microvms create-microvmauth-token \ -- <対象のMicroVM> \ -- <トークン有効期限> \ -- <許可ポート番号> ユニットテストだけでなく、セキュアに エンドポイントからの簡易検証もできる のが、Lambda MicroVMsのメリットの1つ ローカル GitHub Actions 22
23. プロト：Node.jsアプリ ＋ MicroVM サーバーレスCI 検証済みのVM環境は 削除（Terminate）または 中断（Suspend） ケース例： GitHub Actionsによる自動検証 変更差分を指 定してrunmicrovm ビルド& テスト実行 エンドポイント に対する簡易 検証 検証結果をS3 へ保存 検証済みVMを terminate ジョブ実行時にクリーンなMicroVMを 払い出して検証する。 不要になったら削除 or 中断 23
24. Lambda MicroVMs の活用ポイント 1. フィードバック ループ 2. ジョブ実行後の 記録保持 3. 仕組みによる VM環境Termination 4. CI実行環境の 選定・基準 24
25. 1. 早いフィードバックを追求する開発サイクルは変わらない 短い アウターループ フィードバック サイクル MicroVM マージ前の簡易検証 インナーループ ローカル エージェントとの対話的 な開発・テスト フィードバック サイクル アウターループ クラウド・プレビュー環境 外部結合・デプロイの検証 分離環境(MicroVM)でアプリを起動して 軽くチェックできる、より短いフィードバックサイクルを組める 25
26. 2. ジョブIDを軸とした、検証結果の記録 ✓ 変更成果物を反映するジョブのIDを軸として、 入力〜終了までの情報をセットで記録・保管する（=証拠チェーンの作成） ✓ VM環境自体は削除しつつ、後からトレースできる状態に Job ID lifecycle.json 状態遷移、履歴情報 input.json 入力、環境情報 handler.js handler-result.json ジョブを受け付けたハンドラの実行結果 ジョブを受け付けたハンドラスクリプト test-report.html テストの実行結果レポート probe.json HTTPSアクセスによる外部応答結果 cleanup.json 終了、残存チェック 26
27. 3. 起動したMicroVMのTermination Lambda MicroVMs を不要に起動させ続けない、かつ MicroVM削除前に証拠チェーンは記録・保管する ケース①： 簡易検証が失敗した場合 変更差分を指 定してrunmicrovm ビルド& テスト実行 エンドポイント に対する簡易 検証 検証NGならば、 suspendしてVM を中断 検証OKならば、 結果をS3へ検証NG 保存 エラーを含め た結果をS3へ 保存 検証済みVMを terminate Resumeして 手動で 原因調査 ✓ エラーしても、記録も環境も残す ✓ Suspend/Resumeで必要時のみアプリ(VM)を稼働 27
28. 3. 起動したMicroVMのTermination Lambda MicroVMs を不要に起動させ続けない、かつ MicroVM削除前に証拠チェーンは記録・保管する ケース②：CIの意図しない中断 変更差分を指 定してrunmicrovm ビルド& テスト実行 エンドポイント 検証OKならば、 検証済みVMを GitHub Actionsの意図しない中断 に対する簡易 結果をS3へ terminate 検証 保存 起動したMicroVMが残り続けてしまう。 不要なコストを発生させないためにVMを削除したい ジョブ起動時にMicroVMの最大残存時間を指定する ことで、時間超過したらVM削除が自動発火 ✓ 最大残存時間やフックで、 時間超過により 削除や記録を実行 削除開始 ✓ カスタマイズ性が必要 削除フックで、 S3へ結果を 保存 VM削除完了 28
29. 4. 既存CIとの使い分け、判断基準 実現したいこと 引き受ける環境管理 変更ごとに検証環境を起動 イメージ・handlerの保守 共通イメージ、ジョブによる変更 ジョブの取り回しをメンテナンス 起動後のアプリを外から確認 検証のシナリオ・合否判定の管理 VMごとのHTTPS接続 導入判断 テストに加えてセットで実施・検証 状態を保持して調査を中断・再開 記録や終了の管理 中断・再開を含めた検証フロー CIが止まっても、結果を記録 & VMを削除 ✓ 既存CIで品質・効率が満たせればそのまま ✓ VM単位での接続・再開が有効であったり、環境管理の 負担が許容できればMicroVMの導入検討を 29
30. まとめ 1 ① 対話と分離 ローカルでエージェントと対話しながら開発する利便性 を維持しつつ、未確認の実行はMicroVMに分離する ② 不変と動的 イメージは使い回して、変更成果物はジョブで注入。 再現性と効率性のバランスを取ったサーバーレスCI の構築 ③ 適材適所 既存CI・プレビュー環境との役割差異や、 導入リターン、運用負荷を踏まえて、現場に適用する 30
31. ご清聴ありがとうございました 藤岡 敦史 @fujioka_aa ForgeVision, Inc. https://www.forgevision.com/