耐久性のあるエージェント — Replay vs Snapshot (Trigger.dev Eric Allam)

AI Engineer Code Summit (NYC) 2026/05/10

Eric Allam / エリック・アラム · 11:00 「30 年間、我々はステートレスコンピュートをバックエンドインフラの核としてきた。エージェントが、この移行を『ステートフルコンピュート』へ強制してる」

AI Engineer Code Summit (NYC、 2026/05 開催)。約 16 分。 Trigger.dev 共同創業者 Eric Allam による、 30 年のバックエンドインフラ史を 16 分で総括し、エージェント時代の新パラダイムを提案するセッション

動画は 30 年間のバックエンドインフラ史 → 現代の課題 → 解決策の提案という構造で、「耐久性のあるエージェント」を実装するための 2 つのアプローチ (Replay vs Snapshot) を体系化する。業界全体に対する「インフラパラダイムシフトの宣言」として読める、学術的にも実装的にも重要な資料。

Eric の主張を一言で要約: エージェント = セッション ≠ トランザクション。過去 30 年のバックエンドは「ステートレスコンピュート + DB の状態」だったが、エージェントは長期間 (数日 → 数週間) 続くセッションで、ローカルマシン状態を保持する必要がある。これは 30 年来初めての、バックエンドインフラの根本的パラダイムシフトだ、という主張。

着眼点

30 年のバックエンド史 — CGI (1993) からエージェントまで (00:42 - 04:30)

Eric の歴史総括が秀逸:

1993: CGI — HTTP リクエストごとに新プロセスをフォーク、完全にステートレス
PHP / LAMP スタック: プロセスは再利用するが、原則は「request + DB = response」、状態は DB に
「Shared Nothing」アーキテクチャ: コンピュート層はステートレス、状態は DB のみ。 Ruby on Rails、 Node.js、サーバーレス、すべて同じ
10-15 年前: ワークフロー / 耐久実行エンジン: Replay モデルの発明 — 各 side effect を step でラップしてキャッシュ。 send email、 charge credit card、等を冪等に
2023: LLM 登場 — 当初は workflow の 1 step として整合
2024+: Tool calling、 Agent loop — 「コードが LLM を制御する」から「LLM がコードを制御する」への反転

30 年間の積み重ねを 5 分で総括した上で、「では Replay モデルで Agent Loop は durable にできるか?」を問う構造。

「Replay モデルは Agent には機能しない」 (05:53 - 07:15)

Eric の核心的主張。 Replay モデルで Agent を durable にすると:

各 LLM コールが step、各ツールコールが step として journal に記録される
Resume 時に function 全体を再実行、 step は cache から取得
Agent loop が成長するにつれて log がどんどん大きくなる
システムの根本的限界に当たる — entry 数か、 entry サイズか

決定的な観察: 「Replay は durable transactions を提供する、でも Agent はトランザクションじゃない、セッションや」 (06:58 - 07:15)。 multi-step workflow は start + end があるが、 session はユーザーが望む限り続く、という構造的違い。「 METR によると、エージェントが意味のある仕事をできる時間は 4-7 ヶ月ごとに 2 倍。今は数時間、すぐに数日、数週間になる」 (06:33)。

2 つの状態 — Context + Execution (07:27 - 09:30)

Eric の解決策フレーミング。「エージェントには 2 つの半分がある」:

(1) Context (コンテキスト): システムメッセージ、ユーザーメッセージ、ツールコール、ツール結果、アシスタント応答 — LLM の入出力すべて。これは append-only log で durable にできる、任意のプリミティブ (DB、オブジェクトストレージ、分散ファイルシステム) で扱える。

(2) Execution (実行): GitHub repo を clone した状態、パッケージインストール済み、データセットがメモリにある、 dev server 起動中、 sandboxed sub-process。「これを log で durable にすることは無理」 (08:53)。

解決策: Snapshot and Restore。「実行状態を recreate するのではなく、マシンを snapshot、シャットダウン、 disk に保存、ユーザーメッセージ来たら restore」 (09:20)。 turn 間の durability、ユーザーがランチに行ってる間マシンを走らせる必要なし。そしてエラー復旧の手段にもなる。

Snapshot/Restore の系譜 — IBM 1966 → CRIU (2011) → Firecracker (10:30 - 14:30)

Eric の技術史。「これは新しくない、 IBM mainframe (1966) には既に checkpoint/restore があった。数時間の高額なジョブを失敗時に最初からやり直したくなかったから」 (11:08)。

段階:

2011: CRIU (Checkpoint/Restore In Userspace) : ユーザー空間でプロセスを suspend/restore、プロセスに「parasite」を注入してメモリダンプ。 Trigger.dev は 2024 年に導入、数百万 snapshot/restore を実行
2025+: Firecracker microVM : マシン全体を snapshot、ピックアップ。 Trigger.dev が 2025 年に移行、デフォルト 512MB マシンを 14MB 圧縮 snapshot に

技術的工夫: 「Seekable compression — Restore 時にメモリページ全部を decompress せず、必要部分だけ。そして層化 snapshot」 (13:42)。結果: snapshot が 1 秒未満、 restore が数百ミリ秒。

「fcrun」 — まもなく OSS 化される Firecracker CLI (14:28 - 15:30)

Trigger.dev が内製した fcrun (もしくは fc-run)。 Docker 風 CLI で、 Firecracker VM でコンテナを実行 + snapshot/restore できる。「Alpine が超高速で起動、 snapshot も超高速、 VM の fork も超高速」 (15:10)。

ベンチマーク: 「VM が Internet と対話可能になるまでの時間 (TTI)、 15,000 VM starts per minute、 30 FPS のビデオレンダリングに匹敵」 (15:30)。まもなく OSS 化予定。業界が「エージェント実行環境の標準」を取りに行く動きの中心の 1 つ。

「ステートレス → ステートフルコンピュート」という業界パラダイムシフト (11:00)

Eric の最も大きな主張: 「30 年間、我々はステートレスコンピュートをバックエンドインフラの核としてきた。そして agents が、この移行を強制してる — stateful compute へ」 (11:00)。

これは Karpathy の Software 3.0 や Boris Cherny の「印刷機の比喩」と並ぶ、業界パラダイムシフトの宣言。 Karpathy は「プログラミング言語の変化」、 Boris は「職業の変化」、 Eric は「インフラの変化」。 3 人とも「我々は新しい時代の入口にいる」と独立に主張してる構図。

関連記事

Granola: 一発で決めようとするな — 同じ Code Summit、 LLM 機能の Product Engineer 視点
Tavoon: A Piece of Pi — コーディングエージェントを自社プロダクトに埋め込む建築論
Karpathy: Software 3.0 — 業界パラダイムシフトの理論
Boris Cherny: 印刷機の比喩 — 同じパラダイムシフトの職業視点

重要な引用

「30 年間、ステートレスコンピュートがバックエンドインフラの核。 agents がこれを stateful compute へ強制してる」 (11:00)
「Replay は durable transactions を提供する、でも Agent はトランザクションじゃない、セッションや」 (06:58)
「エージェントには 2 つの半分: Context (LLM 入出力) と Execution (マシン状態)」 (07:27)
「Context は append-only log で durable、 Execution は snapshot/restore で durable」 (10:00)
「IBM mainframe (1966) には既に checkpoint/restore があった、高額なジョブを失敗時に再実行したくなかった」 (11:08)
「METR によると、エージェントが意味のある仕事をできる時間は 4-7 ヶ月ごとに 2 倍」 (06:33)
「Firecracker microVM の 512MB マシンを 14MB 圧縮 snapshot に」 (13:42)
「15,000 VM starts per minute、 30 FPS のビデオレンダリングに匹敵」 (15:30)

出典

Two Roads to Durable Agents — AI Engineer 公式 (YouTube)

関連リソース:

エリック・アラム

Eric Allam

Trigger.dev 共同創業者 / CTO / 「stateful compute」提唱者

用語集

Trigger.dev: 背景バックグラウンドジョブやワークフロー、エージェントを本番でデプロイ・運用するためのプラットフォーム。「durable execution」 (耐久性のあるコード実行) を Node.js / TypeScript エコシステムで提供。過去数年間で「ワークフロー → AI エージェント」への移行を内側から見てきた立場の会社。
Replay モデル: Temporal / Inngest / Trigger.dev v1 などで採用される、ワークフロー実行モデル。各副作用 (side effect) を「step」でラップ、ステップごとに実行結果をジャーナルにキャッシュ。失敗時の再実行で、既に実行済みのステップはスキップする (deterministic replay)。ステートレスコンピュートの上に耐久実行を実装。
Snapshot / Restore モデル: Eric が提案する代替パラダイム。マシン全体 (メモリ、ファイル、プロセス) を snapshot して停止、後で restore してピックアップ。 Replay と違い「実行状態をすべて保存」するため、 GitHub repo clone 済み・ Pip install 済みなどの重い状態も維持できる。
CRIU (Checkpoint/Restore In Userspace): 2011 年に開発された Linux のプロセス checkpoint/restore ツール。ユーザー空間からプロセスのメモリ・ファイルディスクリプタ・状態をすべてダンプして、後で復元できる。 Trigger.dev も 2024 年に導入してミリオン単位の snapshot/restore を実行。
Firecracker microVM: AWS が開発した、サーバーレス用の軽量仮想マシン。 Lambda や Fargate の基盤。起動が高速 (数十 ms)、隔離が強い (KVM + minimal OS)、メモリ snapshot 可能。 Trigger.dev が CRIU から移行した理由は、「プロセスではなくマシン全体」を snapshot できるから。
fcrun: Trigger.dev が内製した、 Firecracker VM 用の Docker 風 CLI。 OSS 化予定。コンテナを Firecracker VM で実行 + snapshot/restore できる。「VM が Internet と対話可能になるまで」が 15,000 VM/分。
METR: エージェント能力測定の研究機関。「AI エージェントが意味のある仕事をできる時間 (time horizon)」が 4-7 ヶ月ごとに 2 倍になってる、という観察を出版。現在 (2026/05) は数時間レベル、数年内に数日 → 数週間に伸びる予測。

comment is stripped from the HTML output. */}