AIエージェント

durable execution とは：AIエージェントを中断から再開する仕組み

2026/10/11

🤖 AIが執筆しています

エンジンは、記録のある呼び出しに保存した結果を返して実行を再生する

エンジンが解く問題は、再開後に完了済みの仕事を繰り返さないことである。そのために、モデル呼び出しとツール呼び出しを一つずつ記録の単位にする。この単位を、Lambda はステップ、Temporal はアクティビティと呼ぶ。

再開は再生（replay）で行う。再生とは、コードを先頭から実行し直し、記録のある呼び出しでは実行せず、記録した結果を返す動作である。AWS の開発者ガイドは、再生では「コードは先頭から動き、完了したチェックポイントは飛ばして保存済みの結果を使う」と説明する²。Pydantic の Lambda 向けの文書は、モデル呼び出し、関数ツール、MCP の呼び出し、動的ツールセットの解決を、それぞれステップとして記録し、再開した実行は「すでに払った仕事を繰り返す代わりに」最後に完了したステップから続くと書く³。

Temporal も再生で回復する。文書は、それを働かせる鍵を、アプリケーションを二つに分けることに置く⁴。同じ入力で再実行すれば同じように動く決定的な部分をワークフロー、入出力を含む任意の処理をしてよい部分をアクティビティと呼び、ワークフローのコードからは入出力を外すよう求める。Pydantic AI では、モデル呼び出し、入出力を伴うツール呼び出し、MCP サーバーとのやり取りがアクティビティになり、それらを調整するエージェントのループがワークフローに入る⁴。再生のたびにワークフローが同じ呼び出しを同じ順序で出すことが、記録した結果を正しい呼び出しへ返す条件になる、というのは本稿の整理である。

実行の再開を、アプリの処理からエンジンへ移す動きが広がっている

背景で述べた保存と読み戻しの処理について、AWS は、複数ステップの処理を作る開発者がこれまで取った方法として、独自の状態管理ロジックの実装と、外部のオーケストレーションサービスの組み込みの二つを挙げる⁵。いまは、エージェントのフレームワークが、モデル呼び出しとツール呼び出しを単位にして記録をエンジンへ任せる。

この方向には、AWS と Pydantic が動いている。AWS は 2025-12-02 に US East (Ohio) で Lambda durable functions の一般提供を始めた⁵。2026-09-10 には Pydantic AI との統合を発表し、チェックポイントとやり直しの処理を利用者が書かずに済むと説明した⁶。Pydantic は Temporal と AWS の両方と統合を共同で保守し¹、durable execution を任意のエンジンにつなぐ安定したビルダーを公開した⁷。旧来の TemporalAgent は非推奨にして、TemporalDurability へ寄せている⁴。

記録をどこに置くかで、運用の負担が分かれる

Temporal では、Temporal Server が実行の進行を追跡し、状態を内部のデータベースに保存する。ワークフローとアクティビティはワーカーが動かし、実際のアプリケーションではワーカーを別のサービスとして動かすこともある⁴。Lambda では記録を Lambda が持ち、利用者はサーバーを管理しない⁶。実行は最長で 1 年続き、待機の間は計算料金がかからない²。人の承認や外部の完了を長く待つ処理では、この性質が効く。

どちらのエンジンでも、機能を付けただけでは実行は記録されない。Temporal ではワークフローの中で動かした実行だけが記録される⁴。Lambda では、durable_agent_handler か run_durable を通った実行だけが記録され、agent.run_sync で直接呼ぶと、警告なしに記録のない実行になる³。

どちらを選ぶかは、チームが既に持つ基盤に加え、並列のツール実行、画面への配信、記録の量の要件で決まる（後の節で扱う）。Temporal はサーバーとワーカーを用意する代わりに、画面への配信や大きなデータの扱いを設定で広げられる。Lambda は運用を AWS に任せ、統合が切り替える逐次のツール実行と、配信の経路がないことを受け入れる。

記録の直前に落ちた副作用はもう一度動くので、冪等にする

冪等とは、同じ操作を繰り返しても、結果が一度だけ行った場合と変わらない性質を指す。AWS は、Lambda と Pydantic AI の統合が、再開時に顧客へ二重に課金するような副作用を避けるのに役立つと発表で書く⁶。それが効くのは、記録が書かれた呼び出しまでである。ステップは実行したあとで記録されるので、Pydantic の文書は、ツールの副作用と記録の間で中断すると再開時にツールが再実行されると書く³。Temporal でも、アクティビティが途中で失敗すると先頭から再実行される⁴。

再試行も同じ呼び出しを繰り返す。Lambda の SDK は既定で各呼び出しを最大 6 回、Temporal はモデル呼び出しを回数の上限なく試す³⁴。Pydantic AI やモデル提供元のクライアントの再試行と重ねると回数が掛け算になるので、どちらの文書も片方を切るよう求める³⁴。再試行を切っても記録の直前の中断は残るので、課金のような副作用には、注文ごとの冪等キーを相手に渡し、同じキーの 2 回目を相手の側で無視させる設計が要る。これはエンジンを替えても利用者が書く。

実行の形を変える変更は、実行中のものと版を分けて配備する

Lambda は、記録を呼び出しの到達順で対応づける。ツールや MCP サーバーの追加と削除、イベントハンドラーの追加、モデルの変更でステップの数や順序が変わると、旧版で始まった実行が壊れる。エージェントやツールセットの改名も、記録の名前を変える。実行は開始時に公開されていた版に固定されるので、新しい版を公開し、旧版の実行が終わるのを待つ³。

Temporal でも、エージェントの名前やツールセットの id を変えると、実行中のワークフローが壊れる⁴。実行の履歴を変える更新は、実行中のワークフローを終わらせてから入れるか、ワーカーのバージョニングか新しいタスクキューで入れると文書は書く⁴。どちらのエンジンでも、実行中のものと互換性のない変更を入れる手順を、運用に持つことになる。

並列のツール、画面への配信、記録の量は、エンジンと統合で違う

並列のツール実行では、Pydantic AI の Lambda 統合が、ステップを到達順で識別するために、記録する実行の中ではツール呼び出しを一つずつ実行する設定に切り替える³。Lambda の SDK 自体は並列の操作を持つ⁸。Temporal 向けの文書は、ツールを逐次へ切り替える記述を持たず、ツールのファンアウトが N 個のアクティビティを出す場合のペイロードの注意を書く⁹。並列の実行時の振る舞いは、本稿では確かめていない。

画面へのトークン配信では、Lambda の durable execution は完了時に値を一つ返すので、実行中に呼び出し元へ配信する経路がない³。Temporal は Workflow Streams で実時間の配信ができるが、往復ごとに約 100ms の遅延があり、モデル呼び出しが再試行されるとイベントが重複して届く⁴。

記録の量には、どちらのエンジンにも実行あたりの上限がある。Temporal は一つの実行のイベント履歴を 51,200 イベントか 50 MB までとし¹⁰、データ一件の既定の上限は 2MB である。次のモデル呼び出しに渡す履歴がこの上限を超えると、実行はエラーにならず無期限に再試行される⁹。Lambda は、実行全体で 3,000 操作と累積 100 MB の状態を上限にし、Pydantic の文書は大きなツール結果の代わりに S3 のキーなどの参照を返すよう勧める¹¹。

本稿は二つのエンジンを動かしておらず、本文の数値は各社の文書の記述に基づく。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。