リース失効・タイムアウト・キャンセル後に残る「ゾンビ外部操作」をどう封じるか

分散したAIエージェントやワークフローでは、タスクのリース失効、heartbeat timeout、親処理のキャンセル、再割当てが起きても、古いworkerや既に送信済みの外部API操作まで同時に停止したとは限らない。ここを同一視すると、新しいworkerが処理を引き継いだ後に古いworkerが復帰し、二重更新、古い状態による上書き、重複した外部副作用を発生させる。運用上の原則は、スケジューラ上の所有権喪失と、実プロセス停止と、外部世界での副作用停止を別々の事実として扱うことである。

AWS Step FunctionsのTask timeoutやheartbeat timeoutは、ワークフローが待ち続ける時間を制限し、失敗や再試行へ遷移させるための制御である。callback task tokenやSendTaskHeartbeatも、オーケストレータ側がタスクの生存・完了を判断するための仕組みであり、既に別サービスへ送られたHTTP要求、DB更新、決済、メール送信などを物理的に取り消す一般的な仕組みではない。したがって「timeoutした」「leaseが切れた」「cancelを送った」という観測だけから、「外部副作用は発生していない」と結論してはならない。

etcdのlease/lock系プリミティブも同じ境界を示す。lease失効によって所有権を失わせることはできるが、停止していた旧workerが後で復帰する可能性は残る。etcdのrevisionやTxn Compareのような単調に進む世代・versionを利用し、保護対象のmutation境界で現在の世代と原子的に照合できれば、古いworkerによるstale writeを拒否できる。Consulのsession、check-session、check-index、CASも同種の条件付き更新を構成できる。ただし、これらが直接守れるのはその条件を検証する対象である。外部SaaSや別DBがfencing tokenを理解しないなら、ロックサービス側でleaseを失効させただけでは外部副作用を封じられない。

第一に、実行権限へ世代を持たせる。job、workflow、resourceごとに単調なgeneration、revision、epoch等を発行し、再割当て後は新世代だけをcurrentとする。旧workerが復帰した場合、重要なmutationの直前にcurrent generationを検証する。検証と更新を別々に行うとTOCTOUが残るため、保護対象が対応する場合はconditional write、transaction、compare-and-swap等で「世代確認＋更新」を原子的に行う。

第二に、fencingを検証できない外部副作用には別の防御を置く。送信前にstable logical operation IDと要求内容を永続化し、providerがidempotency keyを提供する場合はそのdocumented scope/window内で同一identity・同一parameterを使用する。結果が不明なままtimeoutした場合は、即座に別の意味のmutationを発行せず、provider operation ID、対象object、event/history、readback API等で結果をreconcileする。idempotencyや照会面が存在しない操作では、自動再試行を安全だと仮定せず、人手確認、forward recovery、containmentへ切り替える。

第三に、cancelを安全性証明に使わない。キャンセル要求は「これ以上の仕事を望まない」という制御信号であって、外部世界のeffectが存在しないことの証明ではない。worker、tool runtime、providerの各層でcancelの受理時刻、dispatch済みか、provider operation IDが発行済みか、最終readbackが何を示したかを別々に記録する。

第四に、再割当て時のauthorityを明示する。新workerへ所有権を渡した時点で旧workerのcredential自体を即時失効できない場合がある。したがって「credentialがまだ使える」ことと「このjob generationでmutationしてよい」ことを分離し、mutation境界でcurrent authority/generationを検証する。長寿命credentialだけに依存すると、stale workerが技術的には書き込み可能なまま残る。

典型的な事故経路は、Aがleaseを取得して外部処理を開始し、pauseやnetwork partitionでheartbeatを失う、オーケストレータがAを失効扱いにしてBへ再割当てする、Bが新しい状態を確定する、その後Aが復帰して古い前提のmutationを送る、という順序である。対象がgenerationを原子的に検証すればAを拒否できる。一方、対象がその仕組みを持たず、Aが既に外部要求をdispatch済みなら、lease失効だけでは要求を回収できない。

さらに重要な限界として、単に「これまで見た最大fence」を対象側に記録する方式では、新世代Bが対象へ到達する前に旧世代Aが先着した場合、Aを拒否できないことがある。再割当てと同時に旧世代を即時拒否したいなら、authority sourceとmutation boundaryをより直接結合し、current generationを対象側が照合できる設計が必要になる。

fencing tokenは、対象がtokenを比較し、その判定とmutationを一体として実行できる場合に強い。すべての外部APIがこの能力を持つわけではない。idempotency keyもproviderが定めたscope、retention、parameter matching semanticsの内側で重複effectを抑える仕組みであり、普遍的なexactly-once保証ではない。キャンセルAPIもbest-effortの場合があり、成功応答が既送信effectの不存在を意味するとは限らない。

したがって、lease、timeout、heartbeat、cancel、fencing、idempotency、reconciliationは代替関係ではなく、異なる失敗面を担当する。lease/heartbeatはownershipとliveness、fencingはstale authorityのmutation拒否、idempotencyは同一logical operationの重複抑制、reconciliationは曖昧な結果の確定を担当する。

公開情報だけでは、authority失効後に旧AI agent/workerがprovider側で有害な副作用を確定させた事例について、十分に独立検証されたproduction postmortemは限定的である。また、provider横断で利用できるfencing token標準は存在せず、外部APIが世代検証を提供するかは製品ごとに異なる。runtimeごとのcancel propagationとprovider-side effectの境界も個別検証が必要である。これらの未知を理由にlease失効やcancelをexactly-once保証へ昇格させてはならない。

リース失効・heartbeat timeout・キャンセルは、スケジューラ上の所有権や待機を終わらせるための制御であり、旧実行主体の停止や既送信の外部副作用の取消しを一般には保証しない。可能な対象では単調なgeneration/fencing tokenをmutation境界で原子的に検証し、対応しない外部副作用ではstable operation identity、providerのdocumented idempotency、結果reconciliationを組み合わせる。timeoutやcancelだけを根拠に「副作用なし」「exactly once」と表現しない。

• Enterprise AI発展拡張統合管理台帳 EA_REVISION_LEDGER: EA-506 / EA-506-R1-20261011。
• 発展・拡張調査通信（継続正本）: 1XpjZC_R1eHlIckvUaEaJ_mcj6YW6j0ihZ0b91z5vewU, marker EA-506 FORMAL RESEARCH BOUNDED UNIT 2026-10-11 17:27 JST。
• AWS Step Functions Developer Guide: Task timeout / heartbeat timeout / callback task token semantics; AWS SendTaskHeartbeat API。
• etcd documentation: leases/locks, revisions, transactions/Compare semantics and external-resource fencing boundary。
• HashiCorp Consul documentation: sessions and transaction checks (check-session, check-index, CAS)。
• Martin Kleppmann, fencing-token analysis for distributed locks and stale clients。
• Registered practitioner reproductions retained in EA-506 revision notes: stale-worker recovery and target-side fencing limits, accessed 2026-10-17。

監査上、上記の仕様資料はcontrol primitiveと境界を支持するが、特定AI製品でのproduction incident発生率や全providerでのfencing可用性を証明するものとして扱わない。