2026年6月、AWSがAIエージェントのための実行環境を発表しました。新製品のはずなのに、仕様を読むほど見覚えのある部品が増えていきます。マイクロVM、スナップショット、ゼロスケール。どれもサーバーレスの世界で十年かけて磨かれてきた道具です。そういった蓄積の上に新しい需要が降ってきた、ここから、この本は始まります。
2026年6月22日、AWSの発表フィードに一件の新製品が流れました。AWS Lambda MicroVMs——公式ブログの見出しには「完全なライフサイクル制御を備えた、隔離されたサンドボックスを実行する」とあります1。要約すると、こうです。エージェントが生成したコードやツール呼び出しを、セッションごとに隔離されたマイクロVMの中で動かす。環境は初期化済みのスナップショットから起動する。使われていないあいだは環境ごと眠らせて課金を止め、次のリクエストが来たら続きから目を覚まさせる。接続は環境ごとの専用エンドポイントで受ける。この数年で急速に立ち上がった「AIエージェントの実行環境」という需要への、Lambdaブランドからの回答です。
あなたがエージェントを作っているなら、この発表が解く問題に説明は要らないはずです。モデルにコードを書かせ、実行し、結果を見せてまた書かせる。このエージェントループには、最初の日から「モデルが返してきたコードを、どこで動かすか」という課題がありました。手元のDockerで済ませてきたか、SDK付属のサンドボックスに任せてきたか。本番のコンテナに相乗りさせている、タイムアウトを伸ばして凌いでいる、試し書きのつもりの環境に本物の資格情報が置いてある——そんな現場は珍しくありません。動くには動く。ただ、どこかその場しのぎの感触も残っています。多くの現場で、実行環境は「あとで考える」のままです。
その「どこで」に、クラウド最大手が専用のサービスで答えました。しかもAWSにはすでにAgentCore Runtimeがあり、今回そこへLambdaの名を冠したもう一つの実行環境が並びました2。一社の中にさえ複数の答えが並ぶ——エージェントの実行環境は、各社が競って整備する主戦場になっています。
この発表をサーバーレスを長く追いかけてきた人間の目で読むと、別の感想が浮かび上がります。主要な部品の多くが、既存の系譜へ接続できるのです。セッションごとの隔離を担うマイクロVMは、Lambdaが多数の利用者を一つの物理基盤へ安全に相乗りさせるために開発した仮想化技術の系譜(第4章)。スナップショットからの起動は、コールドスタート短縮の技術として実用化済み(第2章)。使われないときに眠って課金が止まるのは、ゼロまで縮むというサーバーレスの原点そのもの。目新しさは、組み合わせ方と宛先にあります。既視感には、根拠がありました。
ここで少しだけ昔話にお付き合いください。計算機の歴史には、「持っているように振る舞う」技術の長い系譜があります。物理メモリより広く見せる仮想記憶、一台の計算機を何台にも見せる仮想マシン。ソフトウェアの歴史は、実行環境を「所有するもの」から「借りるもの」とすることでその効率を上げてきた歴史でもあります。物理サーバは仮想マシンに割られ、仮想マシンはコンテナに割られ、実行の単位は細かく、寿命は短くなっていきました。2010年代半ばのFaaS(Function as a Service)で、この流れは一つの極点に達します。関数を書いて預ければ、リクエストが来た瞬間にだけ実行環境が存在し、終われば消える。サーバの数を数えなくてよい世界です。その先には機能の実装ごと預けるフルマネージドサービスの世界が広がり、「自分で書くコード」は本当に価値を生み出す部分へと薄くなっていきました。サーバーレスと呼ばれるようになったこの設計思想は、突き詰めれば、実行環境を所有せず、必要な瞬間だけ借り、使った分だけ払うことで、それ以外の全てをクラウド側でうまくやってもらう、というものです。
この世界を成立させるために、サーバーレスの分野では十年がかりで様々な課題を解いてきました。他人同士が同じ物理基盤を分け合う、速く作れて強い隔離。初期化の待ち時間を消す、環境の複製と起動の高速化。使われないときにゼロまで縮み、押し寄せれば一斉に増える采配。いつ消えてもよいように、状態を外へ出す規律。どれも「借りた環境で他人と相乗りする」という選択の帰結です。
そして2020年代の半ば、AIエージェントが現れました。負荷は断続的で予測がつかず、モデルの応答を待つ長い沈黙と、ツール実行の短い爆発が交互に来るという、これまでのソフトウェアとまた違った特徴があります。一人の利用者が同時に十の作業を走らせる日もあれば、深夜まで誰も来ない日もあります。実行されるコードは、人間がレビューしたものとは限りません。セッションごとに、他の利用者のデータと決して混ざらない壁が求められます。環境そのものは使い捨てでよいのに、会話は何日も続くことがあります。問い合わせに答えるアシスタントなら、利用者が返信を打つ数十秒のあいだ、環境は何もしていません。それでも、五分後に届く次のメッセージは、さっきの会話の続きとして扱われなければなりません。この要件の列を、前の段落で挙げた課題の列と見比べてください。エージェントが実行環境に求める特性は、サーバーレスが十年かけて解いてきた課題と、よく似た形をしています。
エージェントのために様々なサービスを急ごしらえで作り直したのではなく、エージェントという需要が、磨き上げられていた技術を見つけ出し、その真上に着地した、本書ではそう捉えています。エージェントが見つけたサーバーレス。この考えが、本書全体の出発点です。本書では、この現象を「サーバーレスの再発見」と呼びます。「エージェント向け新製品」を一つずつ追いかけなくても、サーバーレスという考え方を通して足元の原理を一度つかめば、製品が入れ替わっても地図は使い回せる。本書が賭けているのは、その一点です。
この出発点には、もう一つのねらいがあります。この分野の知恵は、見かけよりずっと古くから蓄積されているということです。リトライと重複の扱い、隔離の強さの選び方、状態を外に出す規律、従量課金との付き合い方——サーバーレスの運用者たちが十年分の実践から身につけてきた作法は、そのままエージェントの実行環境に通用します。エージェント基盤を「歴史のない新分野」と見るのはもったいない、これまで別の名前で呼ばれていただけです。本書の仕事は、その蓄積をエージェント開発者の言葉へ翻訳し、あらためてあなたの手元に届け直すことです。
サーバーレス技術の再発見は、AWSだけでなく同じ需要を持つ主要クラウド各社で起きています。Google CloudはKubernetesの上にGKE Agent Sandboxを載せました。隔離を担うのは、ユーザー空間でカーネルを装うgVisorの系譜です3。MicrosoftはAzure Container Appsのdynamic sessionsをエージェントのコード実行に差し出しました。隔離に使われているのはHyper-Vの仮想化です4。エッジのisolateランタイムで知られるCloudflareは、コンテナ型のSandboxesを投入しました5。そしてAWSのLambda MicroVMs——Firecrackerのスナップショットとsuspend/resumeを、セッション単位のエージェント実行に組み替えたものです。
出発点は、マイクロVM、Kubernetesとユーザー空間カーネル、ハイパーバイザで隔離したセッションプール、エッジから呼ぶコンテナと、各社それぞれです。それでも四社は、同じ方向へ進みました。人間のレビューを経ないコードを、利用者や仕事の単位で隔離する。ホストを利用者に管理させず、APIから環境を割り当てる。断続的な仕事に合わせて、使われない計算資源を基盤へ返す。そして、利用者が扱う論理的なセッションと、計算を担う実体としての環境を切り離す。異なる系譜が同じ選択圧を受けて似た形質を獲得する——生物学の言葉を借りれば収斂進化です。模倣で足並みを揃えたというより、エージェントが持ち込んだ隔離、突発性、長い待ち、OSごとの道具という要求が、別々の実装を同じ方向へ曲げたと本書は読みます。
【図序-1 別々の入口から、同じ部屋へ——共通する方向と異なる実行モデル】
同じ方向ではあっても、四社の実行モデルは異なります。AWSはMicroVMを明示的な資源として見せ、起動、休止、再開、終了という状態を利用者に操作させます。メモリとディスクを保ったまま同じ環境を再開する答えです。Google CloudはサンドボックスをKubernetesの宣言的な資源とClaim Modelに組み込み、gVisorとPod snapshotで既存の基盤を拡張します。Microsoftは準備済みの環境をプールから識別子へ割り当て、クールダウン後には破棄します。次に同じ識別子が来ても、続きは外部の状態から組み立て直す答えです。CloudflareはSandbox IDをDurable Objectとして保ちながら、その下のコンテナはアイドル後に止め、次回は初期状態から建て直します。Workersから呼べるAPIと論理的な宛先を残し、計算環境は交換可能にする答えです。
この四つの実行モデルの奥に、各社がそれぞれの製品へ持ち込んだ考え方があります。ライフサイクル全体を操作できる資源として差し出すか、既存の資源モデルへ組み込むか、プールの内側へ隠すか、論理IDだけを安定させるか。もっとも、一社の思想は一枚岩とは限りません。同じ会社が用途ごとに複数の答えを持つからこそ、社名より先に、製品が利用者へ見せた境界と隠した境界を読みます。正解はどれか一つに定まりません。同じ方向がサーバーレスの輪郭を描き、違う答えが各社の設計思想を映します。共通点だけを見れば製品差を見失い、差だけを見れば、なぜ同じ時期に同じ種類の製品が現れたかを見失います。クラウド各社の違いと類似点に注目してきた「めもおきば」6ではおなじみの視点です。本書でも、この二つを必ず対にしていきます。四つの答えは、実体をどこまで見せて保ち、どこから論理IDだけを残して交換可能にするかという一本の連続した軸の上に並んでいます。二択にせず、その間を読むところに、技術選定の面白さが詰まっています。
この四つをどう見比べ、あなたのプロダクトにどれを選ぶか、この問いに一冊かけてこたえていきます。選定の規準と手順は第5章で扱います。四つのどれかを名指しで推すことはしません。あなたの要件を言葉にする道具のほうが、推薦一つより長持ちするからです。各サービスの状態遷移、保持するもの、対応リージョン、上限、料金は変化が速いため、〔付録 A-RUNTIME-03〕で参照するデジタル付録に置きました。ここでは、共通する方向と異なる答えを、一枚の地図にしておきます。
ここまで「再発見」と一括りに呼んできましたが、収束の中身をよく見ると、二種類の再利用が混ざっています。本書はこの二つを、全章で使うラベルとして区別します。
- 〔再発見〕——原理も実装もそのまま、需要の文脈だけが変わったもの。
- 〔再発明〕——原理は同型だが、エージェントの要件に合わせて形・実行モデル・課金が作り替えられたもの。
どちらでもない純粋な新規要素には、ラベルを付けません。定義はここだけです。以降は、見出しやキーフレーズの直後に添えて使います。
たとえば、まず、スナップショットからの環境起動。これはFaaSがコールドスタートという課題を解くために実用化した技術で、初期化を済ませた環境の複製を保存しておき、リクエストのたびにそこから環境を立ち上げます(第2章)。MicroVMsの起動は、この仕組みをそのまま使っています。原理も実装も変わっていない。変わったのは使う理由だけです。「関数の初回応答を速くする」から、「エージェントのセッションを瞬時に立てる」へ。これが〔再発見〕です。あなたがコールドスタートについて知っていることは、そのまま通用します。
同じ技術のもう一つの側面を見ます。suspend/resume、これはアイドルになった環境をメモリごと眠らせて課金を止め、次のリクエストで続きから再開させる仕組みです。土台は同じスナップショット技術です。しかし「実行中の環境を一時停止し、状態を保ったまま課金だけ止める」というのは、関数を使い捨てるFaaSにはなかった実行モデルです。環境が再利用された結果として状態が残っていることはあっても、あくまで状態が保存されていることを保証してきませんでした。会話には続きがあるというエージェントの事情に合わせて、技術の形と課金モデルが作り替えられている。これが〔再発明〕です。原理への理解は流用できますが、実行モデルは新しいので読み直しが要ります。
このように、同じスナップショットという土台が、角度によって〔再発見〕にも〔再発明〕にも見えたことに注意してください。ラベルの効用は分類そのものではなく、あなたの既存知識がどこまで通用するかの目印にあります。〔再発見〕なら手持ちの知識がそのまま効く。〔再発明〕なら原理は効くが、提供仕様、そしてなにより料金表はしっかり読み直さなくてはいけません。
〔再発見〕を新技術だと思えば、十年分たまっていた集団知を活用できず、車輪を作り直すことになります。〔再発明〕をただの焼き直しだと侮れば、課金の単位、上限、「再開」の意味をふるい前提をもとに読んでしまい、請求書か障害で気づくはめになります。新しい発表を見たら、まずどちらなのかを考え、「既存の運用が乗るのか」「仕様から読み直すのか」と出発点が変わるわけです。
本書は、AIエージェントを作れる人のための、実行環境の本です。SDKやフレームワークでループを組み、クラウドへデプロイできる。ただ、Firecrackerが何を守り、環境が消えたとき何が残るかは、まだ「プラットフォームにお任せ」している——そのくらいの距離感を想定しています。Kubernetesの運用経験も、特定のクラウドとの契約も前提にしません。プロンプトの書き方、ループの組み方、フレームワークの選び方は扱いません。そこは、すでにあなたの領分です。
あなたが、自分のAIエージェントプロダクトに必要な特性を言葉にし、〔再発見〕と〔再発明〕を見分け、エージェントに任せる範囲を決め、それを支える実行環境を、根拠を示して設計できるようになることを本書は目指しています。製品群の共通点から長く使える原理を取り出し、差異から提供者の設計思想と実行モデルを読む。技術選定の理由を説明でき、実行後の記録から確かめ直せたら、格好良いじゃないですか。
「自分の言葉で規定する」とは、たとえばこういうことです。うちのエージェントに必要な隔離はどの強さか。セッションの再開は、どこまで待たせてよいか。会話の記憶はどこに置き、実行環境が消えたら何が残るべきか。ツールの実行結果は、誰が検分してから外の世界に作用してよいか。障害のとき、会話はどこまで巻き戻ってよいか。——製品の比較表を眺める前に、要求の側を自分の言葉で名指しできること。名前のない要求は、設計もできず、任せる相手にも伝わりません。それが設計の出発点であり、各章はその名付けの語彙を一つずつ増やしていきます。この到達点に達したかは、読み終えたときにあなた自身に採点してもらいます。巻末には、一章一問の17問による出荷判定と、証拠が空だったときに各章末の問いへ戻る道を置きました。
これを一行に圧縮すると、「良き境界」がみちびく、任せられるAIエージェント基盤の作り方です。安全のための境界と、仕事を委ねるための信頼は、しばしば対立軸として語られます。壁を厚くすれば不便になり、便利にすれば危うくなる、と。本書の立場は逆です。良い境界を引けたときにだけ、本当に任せられる。第II部を本書の心臓部に据えたのは、そのためです。
もう一つだけ、全体を貫く原則を先取りします。「機械が書いたコードは、見ず知らずの他人のコードとして扱う」。なぜセッションごとに壁が要るのか。なぜ実行環境に長命な資格を持たせてはならないのか。第4章から、この一文を境界設計へ落としていきます。
本書では、特定のSDKやフレームワークのチュートリアル、コンソールの操作手順、料金や上限の最新値、プロンプト技法やモデル評価の網羅的な手引き、そういった具体的な話は扱いません。一方、評価結果をリリースや外部作用の許可へどう結び、あとから判断を再構成できる記録をどう残すかは、実行基盤の設計課題として扱います。本書が扱うのは、賢さが安全に発揮され、その結果を検証できる「場所」です。製品の名前は変わりますが、構造は残ります。構造をつかめば、手順は自分で導けます。
計算・ネットワーク・ストレージという技術レイヤーの分類は、辞書には便利ですが、いまあなたがどこで困っているかまでは教えてくれません。そこで本書は、エージェントプロダクトの成長を五つの段階に分けました。
【図序-2】現在地マップ——五つの成長段階と、対応する部・章
動かす(第I部・第1〜3章)。作り捨て、コールドスタートと復元、モデルの置き場所。ローカルでは動くのに、デプロイすると遅い・不安定・課金が読めない——心当たりがあれば、ここからです。
他人に使わせる(第II部・第4〜6章)。サンドボックス、テナントの壁、短命な実行に与える短命な身元を扱います。「社内で好評だったから外に出したい」の直前が、実はいちばん危険な瞬間です。
落とさない(第III部・第7〜10章)。状態、再送と重複、ワークフロー、耐久実行。深夜に一度だけ失敗したタスクの原因を、翌朝に説明できない——その心細さに答える部です。
信頼される(第IV部・第11〜14章)。観測とコスト、決定証跡、AIサプライチェーン、長期実行のデリバリ。「この操作は、誰が、何を根拠に、どの版へ許したのか」に記録から答えられることが入口です。
賭けを管理する(第V部・第15〜17章)。ロックインに値札を付け、主権という考え方を分解し、電力と炭素という物理まで降りていきます。「モデルはいつでも乗り換えられる」「リージョンを選べば主権は満たせる」「使わなければ電力もゼロになる」、そういった幻想を、提供条件と測定境界で確かめます。
どの段階から読み始めても構いません。明日にも他人の書いたコード——人間のでも、機械のでも——を動かすなら、第4章と第5章を先に。失敗の調査で眠れない夜が続いているなら、第7〜10章から。利用料の急増に驚いた直後なら第11章、判断の説明を求められているなら第12章が最短です。順に読めば、プロトタイプが信頼されるプロダクトへ育つ道のりを追えます。
ただし、五つの段階はきれいな一方通行では進みません。一部はまだ「動かす」なのに、先に公開した機能は「他人に使わせる」の課題に直面している——そんな歪んだ現在地のほうが、むしろ普通です。図序-2は、開発が進むたびに立ち返る地図として使ってください。
全章で使う方位磁針を渡しておきます。どの段階の判断も、最後には同じ一本の軸に帰着します。どこまでをプラットフォームに任せ、どこからを自分の手元に残すか。任せきる側には各社のサーバーレス基盤があり、いちばん手元に引き取った側には、基盤ごと自分で持つセルフホストがあります。軸の上の位置に優劣はなく、任せる側が現代的で偉いわけでも、セルフホスト側が硬派で正しいわけでもない。設計力とは、壊れたときに何が起きるかを予測したうえで、位置を意識して選べているかどうかです。たとえば会話の記憶を、プラットフォームのメモリ機能に任せるか、自前のデータストアで持つか(第7章)。答えは「どちらが現代的か」ではなく、あなたのプロダクトが本当に失いたくないものから導きます。本書で繰り返し確かめるのは、思い切り任せる場所と手放さない場所の配置です。
本書は二層でできています。紙の本文には、十年もつと筆者が判断した原理だけを置きます。対応リージョン、上限、料金、製品の顔ぶれ——揮発しやすい具体値は本文に書かず、オンラインで更新し続けるデジタル付録に隔離しました。本文中の〔付録 A-RUNTIME-01〕のようなID付きの印は「最新の数字はデジタル付録で」という参照です。本というシステムにも、状態の置き場所の設計があります。変わらないものを紙に、変わるものを更新できる場所に。たとえば本章に出てきたMicroVMsなら、対応リージョンや上限、眠っているあいだの課金の扱いといった「今日の答え」は〔付録 A-RUNTIME-01〕が持ちます。本文が持つのは、「なぜ眠らせるという実行モデルが生まれたか」という、もっと寿命の長い答えです。
エージェントの実行環境は、執筆中にも更新され続けています。四社の顔ぶれや仕様は、あなたが読む頃には変わっているかもしれません。揮発するものを構造から切り離す二層構成は、この変化速度に対する、本というメディアの防御です。最新だった数字も、印刷した瞬間から古び始めます。古びた数字は、ないよりも悪い判断材料になります。アクセス方法と更新方針は巻末の「デジタル付録の歩き方」へ。脚注は一次情報と筆者の寄り道、ID付きの付録参照は揮発する数字、と役割を分けました。
それでは、サーバーレス技術が描く「良き境界」を楽しんでください！ まずは、いま動いているプロトタイプの足元で、何が起きているのかを見ていきましょう。
Footnotes
-
AWS What's New「AWS Lambda MicroVMs」(2026年6月22日)および開発者ガイド。見出しの主語がサンドボックスで、Lambdaは述語に回っています——この語順に、製品の性格がよく表れています。起動・休止・再開・終了の状態と最新仕様は〔付録 A-RUNTIME-01〕へ。〔出典 S-0001, S-0002〕 ↩
-
Amazon Bedrock AgentCoreの実行系(AgentCore Runtime)。2025年にすでに登場していました。MicroVMsとの位置づけ——マネージドなエージェント基盤か、VMそのものか——の整理は〔付録 A-RUNTIME-02〕に置きます。〔出典 S-0003〕 ↩
-
Google CloudのGKE Agent Sandbox。プレビューは2025年11月(KubeCon NA)、一般提供は2026年5月です。隔離はgVisorを用い、SandboxのCRDとClaim Model、Pod snapshotで環境を宣言・保存・復元します。仕様は〔付録 A-RUNTIME-03〕へ。〔出典 S-0004, S-0005〕 ↩
-
MicrosoftのAzure Container Apps dynamic sessions。一般提供は2024年11月です。Hyper-Vで隔離した準備済み環境をプールから割り当て、クールダウン後はセッションを破棄して資源を片づけます。仕様とFoundry Agent Serviceとの連携は〔付録 A-RUNTIME-03〕へ。〔出典 S-0006〕 ↩
-
CloudflareのSandboxes(Sandbox SDK)。同社のコンテナ基盤の上に構築され、Sandbox IDはDurable Objectとして存在します。コンテナがアイドルで止まると状態は失われ、次の要求では新しいコンテナが起動します。仕様は〔付録 A-RUNTIME-03〕へ。〔出典 S-0007, S-0008〕 ↩
-
本書は「サーバーレスを支える技術」シリーズ(めもおきば)の系譜にありますが、前著の知識は前提にしません。直近版は第4版(2022年)です。〔出典 S-0009〕 ↩