こんな方へ特におすすめ エヴァンゲリオンが好きな方 ローカルLLM（ Ollama ）や Raspberry Pi で、何か動くものを作ってみたい方 LangGraph でマルチエージェントを試したい方 概要 こんにちは。サイオステクノロジーのはらちゃんです！ 今回はOSCの展示ブース用開発として、『新世紀エヴァンゲリオン』の意思決定コンピュータ MAGI を、Raspberry Pi 3台 + ローカルLLM（Ollama）で再現してみました。 ―― 3体の人格が別々のマシンで議論し、多数決で結論を出す その設計や速度チューニング、実機を立ち上げる過程でハマった落とし穴まで、実務にも通じる知見をまとめていきます。 背景 MAGI は、3つの独立したコンピュータ Melchior・Balthasar・Casper が、それぞれ異なる人格で同じ議題を判断し、多数決で結論を出す合議システムです。 これをただの1プログラムで再現するのは簡単です。 でも、それだと何かが違う。「 1エージェント = 1台の独立コンピュータ 」という原作の設定を、そのまま物理的に再現できないだろうか？ 武井さん の協力の元、Raspberry Pi を3台並べることにしました。とはいえ、非力な Raspberry Pi でLLMなんてまともに動くのか、と最初は半信半疑でした。 結論から言うと、役割を割り切って軽量モデルとチューニングを重ねれば、合議AIは十分に動きます。 システム構成｜3台の Pi + 母艦 役割分担はシンプルです。 各Pi は、ただの推論バックエンド。Ollama が待ち受けているだけで、人格ごとのプログラムは書きません。 母艦（オーケストレータ） となる1台のPCが、合議の進行・集計・画面表示を担当します。今回は PC上の WSL2 で Flask + LangGraph を動かしました。 ブラウザ / kiosk UI       ▲ ▼   SSEで投票をリアルタイム配信 母艦 — Flask + LangGraph（合議・集計）       ▲ ▼   イーサネット（各Piのollama :11434） +-----------------+-----------------+-----------------+ | Pi1 Melchior | Pi2 Balthasar | Pi3 Casper | | Ollama | Ollama | Ollama | +-----------------+-----------------+-----------------+ どのPiがどの人格かは、母艦の `.env` にある 各Piの固定IPだけ で決まります。人格ごとの特別なコードは無く、role名で接続先を引くだけ。この割り切りのおかげで、Pi側は「モデルを入れて待ち受ける」だけで済みます。 合議フロー｜LangGraphで組む2ラウンド投票 合議の本体は LangGraph の StateGraph です。1回目で全会一致なら即確定、意見が割れたら「討論」を挟んで再投票する、という2ラウンド構成にしました。 prepare ：開始を通知 3体を並列実行 ：Melchior / Balthasar / Casper が同時に投票（fan-out） 1回目集計 ：賛成が2票以上なら「可決」 分岐 ：全会一致ならそのまま確定。割れたら 討論 → 再投票 → 再集計 finalize ：評決を確定して配信 ここでは「アイス食べたい」をテーマにしています。2:1で可決されました。 各人格には異なる「観点」を与えています。 Melchior ：論理性・合理性・整合性を最重視 Balthasar ：人間要因・感情・受容性を重視 Casper ：現実性・リスク・実務性を重視 ここでは「アイス食べたい」をテーマにしています。クリックで理由が表示されます。 実装のキモ｜小さいモデルに「JSONだけ」返させる 各人格への問い合わせは1つの関数に集約しています。小さいモデルを安定させるコツは、 出力をJSONに固定する こと。 format="json" と temperature=0 を指定し、 role / reason / vote の3項目だけを返させます。 必ずJSONのみで返してください: { "role": "{role}", "reason": "80字以内で簡潔に（必ず日本語で）", "vote": "approve or reject" } 返ってきた文字列は、 ```json のコードフェンスを剥がし、最初の {` から最後の `} までを抜き出してからパースします。理由が80字を超えたら、途中で切れないよう「最後の句読点」で丸める。小さいモデルは文字数指示を守りきれないので、この後処理は必須でした。 Raspberry Pi で待たせない3つの速度チューニング 非力なPiで素直にLLMを動かすと、1票に何十秒もかかります。体感速度を詰めるために効かせた工夫が主に3つ。 1. コンテキスト長を絞る 対応： num_ctx を既定の 4096 から 1024 へ。 根拠： 投票プロンプトは数百字なので、大きな窓は無駄にメモリと時間を食うだけ。 2. 生成トークン数を制限する 対応： num_predict = 128 。 根拠： 理由は80字上限なのでこれで十分。 出力が短いほど速い。 3. モデルをRAMに常駐させる 対応： keep_alive = -1 ＋ 起動時に一度空打ちして先読み。 根拠： 初回質問のコールドロード待ちを消せる。 OLLAMA_NUM_CTX=1024 # 4096 → 1024 OLLAMA_NUM_PREDICT=128 # 理由は80字で足りる OLLAMA_KEEP_ALIVE=-1 # モデルをRAMに常駐 このほか、3体を 並列実行 （直列の約1/3の時間）し、最終要約は LLMを使わず定型文 で組み立てて呼び出しを1パス削減しています。 モデル選定｜0.5Bの罠を、プロンプトで直す 速度優先でまず qwen2.5:0.5b を使ったところ、奇妙な出力に遭遇しました。 理由には「適切だ」と書いてあるのに、投票は reject となっている、つまり reason と vote が食い違うのです。 原因は集計バグではなく、モデルの出力そのものの矛盾でした。しかも当初のプロンプトは vote を reason より先に書かせていたため、モデルは先に投票を決め打ちしてから、後付けで理由を書いていたのです。 そこで、JSONの並びを reason → vote に変更し、「理由を先に書き、それに一致する投票を選べ／矛盾してはならない」と明示。0.5Bのままでも矛盾が大きく減りました。 最終的に qwen2.5:1.5b に上げると、投票と理由の整合性が安定します。おまけに、 num_ctx=1024 のままでも約1300字の長文議題を破綻なく処理できました。 課題｜本当に時間を溶かしたのはネットワークとOllama 正直、アーキテクチャよりも実機3台の立ち上げのほうが遥かに大変でした。同じ轍を踏む人のために残しておきます。 Wi-Fiが突然切れる GUIから静的IPを設定したらWi-Fiが切断。プロファイルからパスワード（PSK）が抜け落ちていました。 解決： プロファイルを削除して nmcli device wifi connect で作り直す。静的化も nmcli でパスワードごと一括指定するのが確実です。 （今回の構成としてはインターネット不要なのでここはスキップできちゃいます。） Ollamaのサービスが壊れる unit is masked → ディレクトリ欠落 → ssh: no key found と、1台だけドミノでおかしくなりました。 解決： 中途半端に直すより、 完全に削除してから install.sh で入れ直す のが最短でした。 母艦からPiに届かない Ollamaの既定は 127.0.0.1 待ち受けで、他マシンから見えません。 解決： OLLAMA_HOST=0.0.0.0:11434 を設定して再起動。 ss -tlnp | grep 11434 で待ち受けが 0.0.0.0 になっているか必ず確認しましょう。 検証｜「意見が割れる議題」で試す 多数決システムの見どころは、票が割れて「討論→再投票」が発動する瞬間です。だから 論理・感情・現実の3視点が対立する議題 を選びます（例：「AIに人事評価を任せるべきか」「延命治療を中止すべきか」）。 面白かったのは頑健性で、 音声入力の変換ミスで議題が多少崩れていても 、3体とも妥当な結論に収束しました。むしろ本番では、コンテキスト長よりも 音声認識の精度のほうが実害リスクが大きい という気づきが得られました。 母艦を起動して [warmup] done が出て、3体の投票がそろい評決が返ってくれば成功です！ ここでは「残業を法律で全面禁止すべき」をテーマにしています。 まとめ 「 Raspberry Pi でLLMなんて動くの？」という半信半疑から始めましたが、役割を割り切って設計し、チューニングを重ねることで、合議AIはしっかり動きました。 MAGI = 3つの人格が多数決で決める合議システム。 「1人格 = 1台の Raspberry Pi 」 を物理的に再現。 構成は 3台のPi（Ollama）+ 母艦（Flask + LangGraph） 。役割は .env のURLだけで振り分けるシンプル設計。 非力なPiでも、 コンテキスト長・生成量・モデル常駐 の3点を絞れば実用的な速度で動く。 小さいモデルの「投票と理由の矛盾」は、 プロンプトの並び替え という小さな工夫で大きく改善できた。 一番の敵はAIではなく ネットワークとサービス管理 。ここを乗り越えれば合議AIは立ち上がる。 今回はイベント会場に向けて軽量・高速に特化させましたが、精度を重視し他のモデルを試していきたいと考えています。 今後も、こうした個人開発を通して得られた知見を、皆さんに共有していきたいと思います！ 宣伝 生成AIを活用する開発として、自分専用のRAGを作ることもやりました。興味がある方はぜひのぞいてみてください。 RAGの作り方｜LlamaIndexで簡単2ステップ RAGの育て方｜LlamaIndexでペルソナ設計 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 32人がこの投稿は役に立ったと言っています。 The post ラズパイ3台でエヴァのMAGIを作る｜ローカルLLMで動く合議AIシステム first appeared on SIOS Tech Lab .

本記事は、2026 年 6 月 22 日に公開された Run isolated sandboxes with full lifecycle control: AWS Lambda introduces MicroVMs を翻訳したものです。翻訳は Solutions Architect の齋藤 拓巳が担当しました。 本日、AWS Lambda MicroVMs を発表します。これは AWS Lambda 内の新しいサーバーレスコンピューティングプリミティブで、ユーザーや AI が生成したコードを分離されたステートフルな実行環境で実行できます。 仮想マシンレベルの分離、ほぼ瞬時の起動と再開、環境のライフサイクルと状態の直接制御が可能で、インフラストラクチャの管理や複雑な仮想化技術の専門知識は不要です。 Lambda MicroVMs は Firecracker を基盤としています。これは、月間 15 兆回を超える Lambda 関数の呼び出しを支えてきた軽量仮想化技術と同じものです。 この機能が求められる背景 ここ数年、新しい種類のマルチテナントアプリケーションが登場しています。これらのアプリケーションはすべて、エンドユーザーごとに専用の実行環境を提供し、アプリケーション開発者が書いていないコードを安全に実行する必要があるという共通点を持っています。AI コーディングアシスタント、インタラクティブなコード環境、データ分析プラットフォーム、脆弱性スキャナー、ユーザー提供のスクリプトを実行するゲームサーバーなどがこのパターンに該当します。現在この機能を構築するには、難しい選択を迫られます。仮想マシンは強力な分離を提供しますが、起動に数分かかります。コンテナは数秒で起動しますが、カーネル共有アーキテクチャのため、信頼できないコードを安全に封じ込めるには大規模なカスタムのセキュリティ強化が必要です。Functions as a Service はイベント駆動型のリクエスト・レスポンスワークロードに最適化されていますが、ユーザーとのインタラクション間で環境の状態を保持する必要がある長時間実行のインタラクティブセッション向けには設計されていません。その結果、開発者はパフォーマンスと分離のトレードオフを受け入れるか、エンドユーザーに低レイテンシーの体験を提供しながら分離された実行を実現するために、カスタム仮想化インフラストラクチャの構築と運用に多大なエンジニアリングリソースを投資するかの選択を迫られます。これは深い専門知識を必要とし、本来構築しようとしているプロダクトからエンジニアリング時間を奪う取り組みです。 Lambda MicroVMs は、まさにこのギャップを埋めるために専用設計されています。 各 MicroVM は、単一のエンドユーザーまたはセッションに対して独自の分離された環境を提供し、高速に起動し、セッションの間メモリとディスクの状態を保持し、ユーザーが離席した際には低コストのアイドル状態に一時停止します。 同じ Firecracker テクノロジーが既に AWS Lambda Functions の基盤となっているため、このスタックを大規模に運用してきたサービスの運用成熟度をそのまま活用できます。 試してみましょう まず、AWS Lambda コンソールに移動すると、左側のナビゲーションメニューに Lambda MicroVMs が表示されるようになっています。最初に MicroVM イメージを作成する必要があります。 Flask ウェブアプリとその Dockerfile を zip ファイルにパッケージ化し、 Amazon Simple Storage Service (Amazon S3) バケットにアップロードしました。 Flask API – app.py import logging from flask import Flask, jsonify app = Flask(__name__) logging.basicConfig(level=logging.INFO) @app.route("/") def hello(): app.logger.info("Received request to hello world endpoint") return jsonify(message="Hello, World!") if __name__ == "__main__": app.run(host="0.0.0.0", port=5000) Dockerfile FROM public.ecr.aws/lambda/microvms:al2023-minimal RUN dnf install -y python3 python3-pip && dnf clean all WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY app.py . EXPOSE 5000 CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"] 以下のコマンドを使用して MicroVM イメージを作成しました。 aws lambda-microvms create-microvm-image \ --code-artifact uri= --name \ --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \ --build-role-arn 上の画像のように、AWS コンソールで MicroVM Image を作成することもできます。 コマンドを実行すると、Lambda が zip を取得し、Dockerfile を実行し、アプリケーションを初期化して、実行中のディスクとメモリの状態の Firecracker スナップショットを取得しました。 ビルドログは /aws/lambda/microvms/ 配下の Amazon CloudWatch にリアルタイムでストリーミングされ、イメージの準備が完了すると、 Amazon Resource Name (ARN) とバージョン番号とともにコンソールに表示されました。 aws lambda-microvms run-microvm \ --image-identifier arn:aws:lambda:::microvm-image:my-image \ --execution-role-arn arn:aws:iam:::role/MicroVMExecutionRole \ --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}' 起動は AWS コンソールまたは CLI からも行えます。 ここでは、イメージ ARN と、15 分間操作がないと自動的にサスペンドし、次のリクエストを受信すると自動的にレジュームするよう設定したアイドルポリシーを渡しました。 ネットワークの設定は不要です。 Lambda は MicroVM に一意の ID を割り当て、専用のエンドポイント URL を返し、新しい MicroVM を起動します。この MicroVM はスナップショットからレジュームされるため、Flask アプリはすでに実行された状態になっています。 実際、起動が完了した瞬間には Flask アプリはすでに動作していました。 たった 1 回の API 呼び出しで、完全に初期化されブートストラップされたコンピューティング環境が手に入ります。 トラフィックを送信するために、CLI で短期間有効な認証トークンを生成し、 X-aws-proxy-auth ヘッダーを使用して通常の HTTPS リクエストに添付しました。 リクエストはすぐに Flask アプリに到達しました。 その後、MicroVM をサスペンドのしきい値を超えてアイドル状態にしたところ、MicroVM はサスペンドされ、メモリとディスクの状態がスナップショットとして保存されました。 次に別のリクエストを送信すると、アプリケーションの状態が完全に保持されたまま再開されました。 クライアント側からは、一時停止が発生したことはまったくわかりませんでした。 仕組み 内部的には、Lambda MicroVMs は、これまで単一の AWS コンピューティングサービスでは同時に提供されていなかった 3 つの機能を実現しています。 1 つ目は、Firecracker による仮想マシンレベルの分離です。 各セッションは専用の MicroVM で実行され、ユーザー間でカーネルやリソースが共有されることはありません。 そのため、あるユーザーが提供した信頼されていないコードはそのユーザーの実行環境内に封じ込められ、他の環境や基盤システムへのアクセスはできません。 2 つ目は、高速な起動と再開です。 このモデルは「イメージを作成してから起動する」方式です。Dockerfile と Amazon S3 に zip アーティファクトとしてパッケージ化されたコードを提供して MicroVM Image を作成すると、Lambda が Dockerfile を実行し、アプリケーションを初期化し、実行中の環境のメモリとディスクの状態の Firecracker スナップショットを取得します。 そのイメージから起動される後続のすべての MicroVM は、コールドブートではなく事前に初期化されたスナップショットから再開されるため、起動とアイドル状態からの再開の両方でほぼ瞬時の起動レイテンシーを実現します。 数ギガバイト規模のインタラクティブセッションでも、エンドユーザーが快適に操作できるほど素早くオンラインに復帰します。 3 つ目は、ステートフルな実行です。 実行中の MicroVM は、ユーザーのセッション全体を通じてメモリ、ディスク、実行中のプロセスを保持します。 アイドル期間中、MicroVM はメモリとディスクの状態をそのまま維持したままサスペンドでき、トラフィックが到着すると再開されます。 インストール済みのパッケージ、ロード済みのモデル、作業中のファイルセットは、ユーザーがセッションを再開した際にすぐに利用可能です。 MicroVM は最大 8 時間の合計実行時間をサポートし、設定可能なアイドル時間の後に自動的にサスペンドできるため、数分で完了するソフトウェア脆弱性スキャン、数時間実行されるデータ分析アプリケーション、長時間のアイドル期間を伴うインタラクティブなコーディングセッションなど、多様なプロダクトを簡単に構築できます。 Lambda MicroVMs は事前に初期化されたスナップショットから起動されるため、初期化時に一意のコンテンツを生成したり、ネットワーク接続を確立したり、一時的なデータをロードしたりするアプリケーションでは、互換性のためにサービスが提供するフックとの統合が必要になる場合があります。 Lambda MicroVMs は AWS Lambda 内の新しいリソースであり、独自の API を備えています。 Lambda Functions は引き続きイベント駆動型のリクエスト・レスポンスワークロードに最適な選択肢であり、Lambda MicroVMs はマルチテナントアプリケーション向けに特化して構築されています。具体的には、各エンドユーザーやセッションに対して、ユーザーまたは AI が生成したコードを実行するための独立した分離環境を提供する必要があるアプリケーションに適しています。 この 2 つは互いを補完する関係にあります。 イベント駆動型のバックボーンに Lambda Functions を使用しているアプリケーションは、信頼できないコードを分離して実行する必要があるステップで Lambda MicroVMs を呼び出すことができます。 お客様がアプリケーションを持ち込み、サービスが実行環境を提供します。 提供開始 AWS Lambda MicroVMs は、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (東京) の各 リージョン で本日より利用可能です。ARM64 アーキテクチャ上で、MicroVM あたり最大 16 vCPU、32 GB のメモリ、32 GB のディスクを提供します。 アイドル状態の MicroVM は、API 呼び出しによる明示的なサスペンド、またはライフサイクルポリシーによる自動サスペンドが可能で、完全な状態を保持したまま高速に再開できるため、実行コストを削減できます。 料金の詳細は AWS Lambda の料金ページ をご覧ください。 開始するには、 AWS Lambda コンソール にアクセスするか、 Lambda MicroVMs 製品ページ で詳細をご確認ください。 ドキュメントについては、 Lambda MicroVMs デベロッパーガイド を参照してください。 著者について Micah Walter Micah Walter は、ニューヨーク市地域およびその他の地域のエンタープライズのお客様を支援するシニアソリューションアーキテクトです。クラウドへの移行のあらゆる段階で、エグゼクティブ、エンジニア、アーキテクトに対してアドバイスを行っており、サステナビリティと実践的な設計に深く注力しています。余暇には、アウトドアや写真撮影、家中を走り回る子どもたちを追いかけて楽しんでいます。 翻訳者について 齋藤 拓巳 ソリューションアーキテクトとして幅広いお客様の AWS 導入支援を担当しています。AWS Lambda や Amazon API Gateway などのサーバレスのサービスが好きです。

2026 年 6 月 22 日、私たちは AWS Lambda 内の新しいサーバーレスコンピュートプリミティブである AWS Lambda MicroVMs を発表しました。これは、ユーザーまたは AI によって生成されたコードを、分離されたステートフルな実行環境で実行できるようにするものです。仮想マシンレベルの分離、ほぼ瞬時の起動および再開、そして環境のライフサイクルと状態に対する直接的な制御を得ることができ、インフラ管理や複雑な仮想化技術に関する専門知識は不要です。Lambda MicroVMs は  Firecracker によって支えられており、これは毎月 15 兆回以上の Lambda 関数呼び出しを支えている軽量仮想化技術と同じものです。 なぜこの機能が求められるのか ここ数年で、新しいクラスのマルチテナントアプリケーションが登場しており、それらはすべて共通して「各エンドユーザーに専用の実行環境を提供し、アプリケーション開発者が書いていないコードを安全に実行する」という要件を持っています。AI コーディングアシスタント、インタラクティブなコード実行環境、データ分析プラットフォーム、脆弱性スキャナー、そしてユーザー提供スクリプトを実行するゲームサーバーなどがこのパターンに該当します。現在、このような機能を構築するには難しい選択を迫られます。仮想マシンは強力な分離を提供しますが、起動に数分かかります。コンテナは数秒で起動できますが、共有カーネル構造のため、信頼できないコードを安全に隔離するには大幅な追加の強化が必要です。Function as a Service はイベント駆動型のリクエスト・レスポンス型ワークロードに最適化されていますが、ユーザー操作間で環境状態を保持する必要がある長時間のインタラクティブセッションには適していません。その結果、開発者はパフォーマンスと分離性のトレードオフを受け入れるか、あるいは低遅延な体験を提供しつつ分離実行を実現するために、カスタム仮想化基盤を構築・運用するための大規模なエンジニアリングリソースを投入するかの選択を迫られます。これは高度な専門知識を要求する取り組みであり、本来構築しようとしているプロダクト開発からエンジニアリング時間を奪ってしまいます。 Lambda MicroVMs はまさにこのギャップを埋めるために設計されています。各 MicroVM は、単一のエンドユーザーまたはセッションに対して専用の隔離環境を提供し、迅速に起動し、セッション期間中はメモリとディスク状態を保持し、ユーザーが離席すると低コストのアイドル状態へと一時停止します。同じ Firecracker 技術がすでに AWS Lambda 関数を支えているため、同サービスが大規模運用で培ってきた運用成熟度をそのまま継承できます。 試してみましょう 私はまず AWS Lambda コンソールにアクセスし、左側のナビゲーションメニューに新しく表示された「Lambda MicroVMs」を開きました。最初に MicroVM Image を作成する必要があります。 Flask Web アプリとその Dockerfile を zip ファイルにまとめ、それを Amazon Simple Storage Service (Amazon S3) バケットへアップロードしました。 私の Flask API – app.py import logging from flask import Flask, jsonify app = Flask(__name__) logging.basicConfig(level=logging.INFO) @app.route("/") def hello(): app.logger.info("Received request to hello world endpoint") return jsonify(message="Hello, World!") if __name__ == "__main__": app.run(host="0.0.0.0", port=5000) 私の Dockerfile FROM public.ecr.aws/lambda/microvms:al2023-minimal RUN dnf install -y python3 python3-pip && dnf clean all WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY app.py . EXPOSE 5000 CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"] MicroVM イメージを作成するために、以下のコマンドを使用しました。 aws lambda-microvms create-microvm-image \ --code-artifact uri=<path/to/s3/artifact.zip> --name <VM_image_name> \ --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \ --build-role-arn <IAM role ARN> 上記のように、AWS コンソールから MicroVM Image を作成することも可能です。コマンドを実行すると、Lambda は zip を取得し、Dockerfile を実行してアプリケーションを初期化し、実行中のディスクおよびメモリ状態を Firecracker スナップショットとして取得します。ビルドログはリアルタイムで Amazon CloudWatch にストリーミングされ、ロググループは /aws/lambda/microvms/<image-name> に記録されます。イメージの準備が完了すると、その Amazon リソースネーム (ARN) とバージョン番号がコンソールに表示されます。 aws lambda-microvms run-microvm \ --image-identifier arn:aws:lambda:<region>:<acct>:microvm-image:my-image \ --execution-role-arn arn:aws:iam::<acct>:role/MicroVMExecutionRole \ --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}' 起動は AWS コンソールまたは CLI からも実行できます。私はイメージ ARN とアイドルポリシーを指定しました。このポリシーでは、15 分間操作がない場合に自動的にサスペンドし、次のリクエストで自動的に再開するよう設定されています。ネットワーク設定は不要でした。Lambda は MicroVM に一意の ID を割り当て、専用のエンドポイント URL を返し、私の Flask アプリがすでに起動した状態の新しい MicroVM を開始しました（スナップショットから復元されたためです）。起動が完了した時点で、私の Flask アプリはすでに稼働していました。完全に初期化済みのコンピュート環境を得るまで、API コールはわずか 1 回です。 トラフィック送信のために、CLI で短時間有効な認証トークンを生成し、それを X-aws-proxy-auth ヘッダーとして通常の HTTPS リクエストに付与しました。リクエストはただちに私の Flask アプリへ到達しました。その後、Micro VM をアイドル状態のまましばらく放置すると、しきい値を超えた時点でサスペンドされ、メモリとディスクの状態はスナップショットとして保存されました。その後再びリクエストを送信すると、アプリケーションの状態を完全に保持したまま再開されました。クライアント側から見ると、停止は一切発生していないように見えます。 仕組み 内部的には、Lambda MicroVMs はこれまで単一の AWS コンピュートサービスでは提供されていなかった 3 つの能力を統合しています。第 1 は仮想マシンレベルの分離であり、これは Firecracker によって実現されています。各セッションは専用の MicroVM 内で実行され、カーネルやリソースはユーザー間で共有されません。そのため、あるユーザーが提供した信頼できないコードはその実行環境内に閉じ込められ、他の環境や基盤システムへアクセスすることはできません。第 2 は高速な起動および再開です。この仕組みは「イメージ→起動（image-then-launch）」モデルです。MicroVM Image は、DockerfileとAmazon S3 にパッケージされた zip アーティファクトを指定して作成されます。Lambda は Dockerfile を実行し、アプリケーションを初期化した後、その実行状態（メモリおよびディスク）を Firecracker スナップショットとして取得します。このイメージから起動されるすべての MicroVM は、コールドブートではなく事前初期化済みスナップショットから復元されるため、起動およびアイドル復帰の両方がほぼ瞬時に行われます。数 GB 規模のインタラクティブセッションであっても、ユーザーにとって十分に応答性のある速度で復帰します。第 3はステートフル実行です。実行中の MicroVM は、ユーザーセッション中にメモリ・ディスク・実行中プロセスの状態を保持します。アイドル状態では MicroVM はサスペンドされ、メモリとディスク状態を維持したまま保存され、トラフィック再開時に復元されます。インストール済みパッケージ、ロード済みモデル、作業中ファイルセットは再開時にそのまま利用可能です。MicroVM は最大 8 時間の総実行時間をサポートし、アイドル状態は設定可能な時間で自動サスペンドできます。これにより、数分で完了する脆弱性スキャン、数時間実行されるデータ分析アプリケーション、長時間アイドルを含むインタラクティブ開発環境など、多様なユースケースを容易に構築できます。MicroVM は事前初期化スナップショットから起動されるため、初期化時にユニークなデータ生成、ネットワーク接続、または一時データのロードを行うアプリケーションは、互換性のためサービス提供のフックとの統合が必要になる場合があります。 Lambda MicroVMs は AWS Lambda 内の新しいリソースであり、専用のAPI 体系を持ちます。Lambda 関数はイベント駆動型のリクエスト／レスポンス処理に最適であり、Lambda MicroVMs はユーザーまたはセッションごとに隔離された実行環境で信頼できないコードを実行する必要があるマルチテナントアプリケーション向けに設計されています。両者は相互に補完関係にあります。イベント駆動のバックエンドには Lambda 関数を使用し、隔離実行が必要な処理には Lambda MicroVMs を呼び出す構成が可能です。アプリケーションはそのまま持ち込み、実行環境はサービス側が提供します。 今すぐご利用いただけます AWS Lambda MicroVMs は現在、米国東部 (バージニア北部・オハイオ)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (東京) リージョン で利用可能です。アーキテクチャは ARM64 に対応し、MicroVM あたり最大 16 vCPU、32GB メモリ、32GB ディスクをサポートします。アイドル状態の MicroVM は API による明示的停止、またはライフサイクルポリシーによって自動的にサスペンドでき、実行コストを削減しつつ状態を保持したまま高速再開が可能です。料金の詳細は AWS Lambda 料金ページ を参照してください。 開始するには AWS Lambda コンソール にアクセスするか、 Lambda MicroVMs 製品ページ をご覧ください。ドキュメントは Lambda ドキュメント（Developer Guide） を参照してください。 原文は こちら です。