Durable 実行／処理の流れ Replay for AI

Durable Executionは長時間のAgent workflowのstate/progressをdurable history/checkpointへ残し、failure後に復元・継続する実行方式です。ただし外部API・tool・payment・email・database mutation等のside effectがexactly-onceになることを意味しません。

replay型runtimeではworkflow/orchestrator decision codeをdeterministicに保ちます。現在時刻、random、network、LLM推論、tool/API I/Oをorchestrator内から直接再評価せず、runtimeが履歴へ記録できるtimer、activity、step、side-effect primitive等へ隔離します。LLM outputもnondeterministic external computationとして扱い、model ID、request parameters、tool schema version、resultまたはdecision artifactをdurable boundaryへ残します。

completed activity/step resultがdurableに記録済みならreplayはresultを再利用できます。一方、external side effect完了とcompletion recordの間にcrash windowがある場合、activity/stepはretryされ得ます。stable operation ID/idempotency key、resource-version precondition、status query/readback、reconciliationを外部operation側にも設計します。

製品名だけでexecution guaranteeを推定しません。TemporalはEvent History replayでstateを再構築し、nondeterminismをWorkflow Task failure原因として扱います。Microsoft Durable Task/Durable Functionsもevent sourcing/replayのためorchestrator determinismを要求します。AWS Step FunctionsはStandard、Asynchronous Express、Synchronous Expressでsemanticsが異なり、Redriveのfailed Taskは再scheduleされ得ます。DBOSはordinary stepとdurable transactionを区別します。

workflow start、Signal/Update、webhook、human approvalにはstable request/message/approval IDを付与し、tenant、principal、operation type、target resource、input fingerprint/versionへbindします。approvalは自然言語だけをstateにせず、approval ID、approver identity、scope、resource version、policy version、expiryをdurableに記録します。

open workflowが存在する状態でcodeを更新すると旧Event Historyと新codeのreplay compatibilityが問題になります。既存executionを無条件に最新codeへ流さず、runtime固有のversioning/deployment routing/patch/migration mechanismを固定します。model、prompt、tool schema、policyもversioned dependencyとして記録します。

timeout/cancellationはexternal side effectのrollback証明ではありません。external systemが既にcommitしている場合はstatus query/readbackでauthoritative outcomeを確認し、必要ならcompensation/reconciliationへ進みます。

Event History/checkpointのretention、archival、history size limit、execution ID reuse、redrive/recovery windowを事前に確認します。history消失後に最初からworkflowを再実行してside effectを復元せず、authoritative external stateとoperation IDsからreconciliationします。

durable historyにはprompt、model output、tool arguments、approval、resource identifiersが残る可能性があります。secret/PIIを最小化し、encryption、access control、tenant isolation、retention、archival locationを固定します。長時間wait後には必要に応じcurrent authorization/resource preconditionを再評価します。

external side effect後completion record前crash、checkpoint後response前crash、duplicate start/message、open execution中のcode/model変更、cancellation race、approval重複、history retention/redrive expiryをfault injectionします。duplicate side effect、recovery latency、retry count、nondeterminism failure、stuck workflow、history growth、replay latency、reconciliation countを別metricとして記録します。

worker crash、runtime outage、checkpoint failure、activity completion ambiguity、retry amplification、duplicate start/message、nondeterministic code、LLM/model drift、incompatible deployment、cancellation race、compensation failure、history growth/expiry、tenant collision、stale authorization、history内PII/secret、external resource version drift、誤ったmanual replay pointを想定します。

2026-10-05時点のTemporal、Microsoft Durable Task、AWS Step Functions、DBOS、AWS Lambda durable executionの現行documentationとbounded local replay fixtureに基づきます。production durable runtime、LLM、tool/API mutationは未実施です。

Durable Executionはworkflow state/progressをfailure後に復元・継続しますが、外部side effectのexactly-onceを自動保証しません。replay対象codeをdeterministicに保ち、LLM/API I/Oをdurable activity/step境界へ隔離し、未checkpoint実行のretryを前提にidempotency・precondition・readback/reconciliationを設計してください。

対象Agent runtime、durable engine/version、workflow type、history store/retention/archival、worker deployment/versioning、LLM persistence policy、tool idempotency/status API、approval semantics、cancellation/compensation、tenant/auth binding、DR、history limits、SLO/cost、data residency/audit retentionは未確認です。

durable orchestrationをexternal exactly-onceと分離し、replay determinism、activity/step retry、versioning、message identity、retention/recoveryを監査可能な境界として固定します。