持続可能なエージェントへの二つの道：リプレイ対スナップショット

AI エージェントの未来は「リプレイ」か「スナップショット」か？持続可能性を高める二つの道

AI エージェントが単なる一時的なタスク実行から、数日単位で継続する複雑なセッションへと進化するための鍵は、従来のワークフローエンジン由来のアプローチと、新しい仮想マシン技術の使い分けにあります。Trigger.dev の共同創設者であるエリック・アラム氏は、エージェントを本番環境で持続可能にするための二つの主要なアプローチ、「リプレイモデル」と「スナップショットモデル」を解説し、その限界と可能性を明らかにしました。

30 年の歴史が築いた「ステートレス」の壁とリプレイモデルの限界

過去 30 年間のバックエンドインフラは、CGI や PHP、そしてサーバーレスに至るまで、「ステートレス（状態を持たない）」な計算を基本原則としてきました。HTTP リクエストが来るとプロセスが起動し、処理して応答を出せば消えるというこのモデルでは、計算層に状態を保持せず、すべてデータベースに依存します。

このパラダイムは、メール送信や画像リサイズのような単純な非同期タスクには完美でしたが、複雑なマルチステップワークフローや、エラー発生時の回復（リトライ）が必要になる場面では限界が見えてきました。そこで登場したのが「リプレイモデル」です。

すべての副作用をステップとしてラップし、実行時にキャッシュされるようにします。

このアプローチでは、すべての操作をログ（ジャーナル）として記録し、エラー発生時にはその時点まで戻って再実行します。これにより、クレジットカードの二重課金などの問題を避けつつ、失敗から回復する耐久性を実現しました。LLM が登場した当初も、エージェントは単なるワークフローのステップとしてこの枠組みに収まっていました。

しかし、AI エージェントが「トランザクション」ではなく「セッション」として振る舞うようになると、リプレイモデルには根本的な課題が生じます。エージェントとの対話が長引くにつれ、LLM の呼び出しやツール実行のログが肥大化し、システムが機能しなくなる限界に直面します。

エージェントはトランザクションではなく、セッションのようなものです。ユーザーが望む限り続きます。

現在、意味のある作業ができるエージェントの持続時間は数時間程度ですが、将来的には数日単位での動作が求められます。リプレイログを無限に積み重ねることは現実的ではないため、新しいアプローチが必要不可欠でした。

エージェントの「二つの半分」：文脈と実行状態の分離

エリック氏は、エージェントの耐久性を第一原理から考える際、それを「文脈（コンテキスト）」と「実行状態（実行レイヤー）」という二つの半分に分解すべきだと提案します。

1. 文脈: システムメッセージ、ユーザーのやり取り、ツール呼び出しの結果など、LLM に送受信されるすべての情報。これは追加専用ログとして保存すれば、既存のデータベースやオブジェクトストレージで十分に耐久性を保てます。
2. 実行状態: ファイルシステムの作成、メモリ内のデータセット、サブプロセスの実行など、エージェントが実際に「機械」として動作している部分の状態。

文脈はログで管理できますが、ファイルシステムやメモリ上の複雑な状態をログだけで再現するのは困難です。特に開発サーバーを動かしたり、外部リポジトリをクローンしたりする際、リアルタイムでマシンを稼働し続けるのはコストが高すぎます。

ログを使ってそれを耐久性のあるものにするのは実際にはできません。

そのため、実行状態の管理には「スナップショットと復元」が不可欠となります。ユーザーが次のメッセージを送るまでの待ち時間（例えばランチタイムや長時間の処理）に、マシンを停止して状態を保存し、再開時に復元することで、コストを抑えつつ複雑な動作を維持できるのです。

Firecracker と FC Run：スナップショット技術の実用化

「スナップショット」自体は新しい概念ではありません。1960 年代の IBM メインフレームや、2011 年の CRIU（Linux プロセスのスナップショット技術）など、過去にも試みられてきました。しかし、CRIU はプロセス単位でのチェックポイントに限定され、ファイルシステムの状態が完全にキャプチャできない場合や、コンテナとの互換性において遅延が生じるなどの課題がありました。

Trigger.dev が提案するのは、マイクロVMであるFirecrackerを活用したアプローチです。これにより、仮想マシン全体をスナップショットとして扱えるようになります。

素朴な方法ではスナップショットサイズが巨大になりがちですが、独自の圧縮技術で約 14 メガバイトまで削減しました。

デフォルトの VM サイズ（例：512MB）に対して、実際には使用されていないメモリ領域を排除し、シーク可能な圧縮技術を適用することで、スナップショットサイズを劇的に小さくしています。これにより、ネットワーク転送コストやストレージコストを大幅に削減できます。

さらに、復元時は必要な部分だけをデコンプレッションする仕組みを採用しており、数百ミリ秒以内での復元を実現しました。これは、Docker に似た CLI ツール「FC Run（F-Crun）」としてオープンソース化される予定です。このツールを使えば、Docker コマンドを差し替えるだけで、Firecracker VM のスナップショット作成と高速復元が可能になります。

結論：ステートフルな計算への移行

リプレイモデルはトランザクションの耐久性には優れていますが、長期化するエージェントセッションには不向きです。一方、スナップショット技術は、ファイルシステムやメモリ状態を含む完全なコンテキストを維持し、数日単位の複雑な作業を可能にします。

これら二つの技術を組み合わせることで、エラーから回復でき、コードのバージョンを超えて持続するエージェントの実現が可能になります。

文脈ログによる「リプレイ」と、実行状態のスナップショットによる「復元」を併用することで、AI エージェントは単なるタスク実行ツールから、人間のように長期間にわたって自律的に動作し続けるパートナーへと進化します。これは、エンタープライズレベルでのエージェント運用を現実的なものにする基盤技術であり、開発者体験を劇的に向上させる可能性を秘めています。