外部状態正本を使うAI定期実行の要再確認 資料内の該当箇所／cursor 以前の状態へ戻す操作境界

長時間・定期実行するAI処理では、会話履歴やモデル内部の記憶ではなく、外部STATEを再開位置の正本にする設計が有効である。ただし、外部STATEを置いただけでは再開安全性は成立しない。保存されたcursorやlocatorが、どの対象・どのrun・どの世代に属する値かを失うと、古い実行が新しい進捗を上書きしたり、別の対象へ位置値を誤適用したり、rollback後に既処理範囲を再実行したりする。

主要な境界は三つに分けて扱う必要がある。第一はcursor／locatorのidentity境界である。cursorは単なる数値や行番号ではなく、対象object・stream・partition・logical job・run/attempt・owner generation等と結合して解釈する。Kafkaのconsumer offsetがpartitionと結び付いて管理され、古いconsumerがgeneration/epoch検査でfenceされるように、外部STATEでもstate_object_identity、cursor、generationまたはowner epoch、last committed runを一体として扱う必要がある。mutableなpathや名前だけをlocatorにすると、同名差替え後に古い対象を継続しているのか、新しい対象へ進んだのかを判定できない。

第二はpersisted-state schemaの互換性境界である。task bodyのversionや研究revisionのIDは、永続STATE自体のschema identityとは別物である。列や状態値の意味が変わったとき、旧rowを構文上読めたとしても、semantic migrationが正しいとは限らない。未知のstatus値を旧readerが丸めたり、OPEN_UNKNOWNやprovenance locatorを削除したりすれば、parseは成功しても監査可能性や未解決事項が失われる。migrationでは、少なくとも旧stateのbefore-image、schema identity、migration identity、compatibility result、post-migration readback、旧stateを使ったrestore/replay testを保持する。downgradeがlossyなら、その事実と失われるfieldを明示する。未知または新しいschemaを黙ってcoerceするより、互換性未確認として拒否する方が安全である。

第三は外部副作用の境界である。STATEを巻き戻しても、既に作成されたcandidate package、queue entry、repository変更、deployment、publication、外部API操作などは自動的には巻き戻らない。cursor commitと外部副作用が異なるtransaction domainにある場合、cursorを先に進めればcrash後に副作用を飛ばす可能性があり、副作用を先に実行すればcrash/retryで重複する可能性がある。transactional outboxはlocal stateとeffect intentを同一transactionへ入れることでこの窓を縮められるが、下流deliveryまで一般的なexactly-onceにするものではない。外部effect側にはidempotency key、deduplication、transaction、または明示的なreconciliationが別途必要になる。

rollbackは通常の進捗更新と同一視しない。offset resetやdisaster recoveryのように、rollback自体が正当な運用操作である場合もある。その場合はoperator intent、対象identity、rollback前state、適用するgeneration、再処理範囲を明示し、通常runのstale writeと区別する。遅延した旧runがrollback後または新run開始後に戻ってきても、generation/epoch preconditionで拒否できることが重要である。

実装上は、外部STATE recordへlogical_job_id、state_object_identity、state/schema identity、cursorまたはcheckpoint、owner/run generation、last_committed_run_id、必要なprovenanceを束縛し、更新をcompare-and-set相当のprecondition付きにする。再開時は「保存値が存在する」ことではなく、対象identity・schema compatibility・owner generation・外部effectのauthoritative readbackが現在の世界と整合していることを確認する。長時間runでは、同じlogical jobを継続することと、同じrun instanceを継続することも分離する。

failureとして典型的なのは、cursorだけを保存して対象identityを保存しない、owner epochなしで旧runのwriteを許す、処理完了前にcursorをcommitして未処理範囲を飛ばす、処理完了後もcommitせずretryで重複する、schema変更後に旧readerが新しい意味を黙って捨てる、state rollbackを外部effect rollbackと誤認する、といったケースである。特に「このeffect IDは未処理か確認してから外部APIを呼び、その後に完了を記録する」というcheck-then-actだけでは、並行duplicate attemptが同時に未処理判定を通過できるため十分ではない。

適用境界として、すべての外部STATE storeやschedulerが同じCAS、transaction、delivery保証を持つわけではない。Google Docsのrevision-aware write controlのようにstale revisionを拒否できる仕組みは存在するが、そのrevision IDを永続STATE schema versionとして流用できるとは限らない。またschedulerのscheduled timeやcron式だけからexactly-onceやmutual exclusionを推論してはならない。保証は具体的なstate store、scheduler、effect providerの契約単位で確認する。

外部STATEは再開の正本になり得るが、それだけで安全にはならない。cursorは対象identityとgenerationに結び付け、stale writerを拒否する。task-body versionや業務revision IDをpersisted-state schema identityの代替にしない。migrationのparse成功をsemantic correctnessと同一視しない。STATE rollbackを既発生の外部副作用の取消しとみなさない。exactly-onceは、実証されたtransactional/idempotency境界についてのみ主張する。

TASK-EA-RESEARCH／EA_MASTER／EA_REVISION_LEDGERに対するauthoritativeなpersisted-state schema identityとmigration compatibility bindingは、確認済み正本群では見つかっていない。compaction/tombstoneとdowngrade compatibility、lossy migration後に最低限保持すべきlineage/provenance、各external-effect provider固有のidempotency/transaction semanticsも未確定である。これらは不存在と断定せず、実在する正本または具体的provider契約で確認されるまでOPENとして扱う。

EA-1005 Evidence Packet 2026-10-23（AWS Step Functions Redrive、Temporal Event History/Continue-As-New、Kafka/Confluent offset・generation、Google Docs revision-aware write control、AWS/Microsoft transactional outbox/idempotent consumer、Flink state compatibility/savepoint、Kubernetes storage-version migration、およびlive TASK-EA-RESEARCH / EA_MASTER / EA_REVISION_LEDGER readbackを統合）。