AI長期作業・状態管理専門編

Enterprise AI Core / implementation / interoperability / governance / operability / benchmark

長期作業を「長い会話」「長いcontext window」「session memory」だけで説明すると、process crash、再起動、モデル・コード更新、human-in-the-loop、外部toolの副作用、履歴圧縮、複数workerへのhandoff時に、どこから何を再開すべきかが曖昧になる。現行の主要agent runtimeはcheckpoint/session/durable workflowを実装している一方、それぞれが保存するstateの意味と再実行境界は異なる。将来版では「記憶量」ではなく、復旧可能性・正本性・副作用安全性・version境界を別軸として扱う必要がある。

数日〜数週間のAI作業を安全に継続・再開するには、どの状態を永続化し、checkpoint/session/compaction/正本をどう分離し、resume時の二重実行・状態ドリフト・履歴圧縮による情報欠落・外部環境との不整合をどう制御すべきか。

• 「長期状態」は一枚ではない。少なくとも次の6面を分離する設計が必要である（PROPOSAL / INFERENCE）。
• A. CANONICAL_ARTIFACT_STATE: 文書・コード・台帳・成果物など、人間と後続工程が参照する正本。
• B. EXECUTION_STATE: 現在node/step、checkpoint、pending work、retry/attempt、interrupt/approval状態。
• C. CONVERSATION_SESSION_STATE: 会話履歴、tool call history、session/thread identity。
• D. DERIVED_CONTEXT_STATE: summary、compaction、retrieved memory、working set。正本から導出される圧縮・選択状態。
• E. EXTERNAL_ENVIRONMENT_STATE: 外部DB/SaaS/file/repo/tenant等、agent外で実際に変化した状態と副作用。
• F. CONTROL_PROVENANCE_STATE: run ID、source/version、model/tool/runtime version、last successful checkpoint、next action、ownership/lock、handoff metadata。
• checkpointは「保存したから安全」ではない。LangGraphはresume/replayで未完了taskやnodeが再実行され得るため、外部副作用はidempotentにするか、一意operation ID・既実行確認・transaction boundaryで重複を防ぐ必要がある。これは一般的な長期agent設計へ移植できるCore原則である（VERIFIED_SPEC→PROPOSAL）。
• session memoryとdurable executionは別物である。OpenAI Agents SDK Sessionは主に会話履歴をrun間で維持する層であり、永続backendを選べるが、会話履歴があること自体は外部環境、副作用、正本、workflow positionの整合を保証しない（VERIFIED_SPEC + INFERENCE）。
• durable workflowも無制限ではない。Temporal型のevent-history/replay方式は長時間停止・復旧に強い一方、履歴・payloadの成長、determinism、worker/runtime version、continue-as-new等の運用境界を持つ。長期化では「永続化」と同時に「履歴をどう世代交代させるか」が必要になる（VERIFIED_SPEC）。
• compactionは正本ではなくDERIVED_CONTEXT_STATEとして扱うのが安全である（INFERENCE / PROPOSAL）。OpenAIのcompactionは長い履歴を縮約して後続contextとして利用できるが、APIが返す圧縮表現と、人間が監査可能な原履歴・成果物は用途が違う。圧縮結果だけを唯一の正本にすると、後から省略情報を復元・監査できない。
• AgentRewindは長期agentの回復点を「agent contextだけ」でなく「controlled environment」と整合させる必要性を実験的に支持する。ファイル、repo、DB等を触るagentでは、context checkpointだけ巻き戻して外部世界を巻き戻さないと状態分岐が起きる（RESEARCH）。
• memory精度自体も別評価軸である。LongMemEvalはmulti-session/temporal update/abstentionを独立能力として扱い、長期履歴で精度低下を示す。したがって「保存されている」と「正しく思い出せる」は分離しなければならない（RESEARCH）。
• handoffは文章要約だけでは不足する。最低限 CANONICAL_POINTERS / ACTIVE_GOAL / COMPLETED_BOUNDARY / PENDING_ACTION / LAST_SAFE_CHECKPOINT / EXTERNAL_SIDE_EFFECTS / VERSION_SET / OPEN_UNKNOWN / RESUME_INVARIANTS を機械可読または定型形式で残すべきである（PROPOSAL）。
• resume時には「何を再生成してよいか」と「再生成してはいけないもの」を分ける。正本artifactや外部side effectをLLMが推測で再構築するのではなく、保存済みidentity/versionを読んで差分だけ再開する。summary/compactionは再生成可能、canonical artifactとcommit/transaction事実は再生成不可という分類が有効（PROPOSAL）。

将来本文では、長期agentのresume条件を次のacceptance contractとして置ける。 - IDENTITY: task/run/thread/session/projectのidentityが衝突せず、resume対象が一意。 - CANONICALITY: 正本artifactとderived summary/compactionを区別できる。 - POSITION: last completed bounded stepとnext actionが確定している。 - SIDE_EFFECT_SAFETY: 既実行の外部操作を二重適用しない。 - VERSION_COMPATIBILITY: workflow/schema/model/tool/runtime version差分を検出できる。 - PROVENANCE: 重要claim/artifactのsourceと生成・変更originを追跡できる。 - RECOVERY: process/worker再起動後も保存backendから必要stateを再取得できる。 - AUDITABILITY: resume前後のstate transitionを後から説明できる。

• checkpointがあっても、checkpoint後に外部副作用だけ成功し保存前にprocess crashすると、retryで二重適用する可能性がある。exactly-onceを安易に主張せず、idempotency/transaction/reconciliationを設計する。
• replay型runtimeではworkflow codeの非決定性や途中version変更が復旧を壊し得る。LangGraph Functional APIもtask/interrupt順序変更やtask外のtime/random/network callをcompatibility riskとして明示する。
• conversation/session persistenceはworkflow durabilityと同義ではない。MemorySessionのようなprocess-local実装はprocess終了で消える。
• compaction/truncation/summaryはactive contextを延命するが、元履歴と同等の監査証跡・完全情報を保証するものとして扱わない。OpenAI APIにもcontext超過時に古い項目を落とすtruncation modeが存在するため、意図しない情報落ちを監視する必要がある。
• 長期memory benchmarkの成績を、外部副作用を伴う数週間のagent workflowの信頼性へ外挿しない。LongMemEvalはmemory QA、AgentRewind/MettleBenchは特定のlong-horizon engineering/recovery設定であり、全製品保証ではない。
• event/workflow historyも無限ではない。Temporal reference architectureは長い会話でhistoryを世代交代させるcontinue-as-new等を前提にする。
• model update、tool/API schema変更、permission変更、外部データ更新、human editはcheckpoint外のドリフト源。resume時にversion/ETag/revision/permissionを再確認しない設計では「保存済みstateは正しいが世界が変わった」事故が残る。

• LangGraph: checkpointer + stable thread_idが必要。checkpointer無しではdurable resumeを期待できない。backend、encryption、TTL、deployment形態は別途選定。
• OpenAI Agents SDK: persistent session backendが必要。MemorySession等のin-memory層は本番長期stateの代替にならない。OpenAI-hosted conversation、SQLite/Redis/SQLAlchemy/MongoDB等で保持場所・retention・可用性が変わる。
• OpenAI compaction: Responses/Agents SDKの対応経路・model/API挙動に依存するためPRODUCT_VOLATILE。公開時はcurrent endpoint、compatible model、retention/data controlsを再確認。
• Temporal: Temporal Service/Cloudとworker、deterministic Workflow、Activity boundaryが前提。SDK/server compatibility、event history、payload size、retention、namespace/security設定がgate。
• 共通: model/tool/runtime version、storage schema、credential/permission、external system revision、正本artifact revisionがresume compatibility gateになる。

• LangGraph: v1系でpersistence/checkpoint/thread/durable execution/HITLが実装済み。2026-09-13確認時、langgraph 1.2.11がrelease list上の現行core releaseとして確認できる（PRODUCT_VOLATILE）。
• OpenAI Agents SDK: v0.22.2時点でpersistent Session、resume、複数backend、encrypted session、compaction wrapper、atomic/idempotent history transaction interface等を確認（PRODUCT_VOLATILE）。
• Temporal: durable executionは成熟したworkflow runtimeとして実装済み。Python SDK 1.30.0をcurrent release anchorとして確認。AI reference architectureではLLM/tool I/OをActivityへ隔離する実装パターンが明示される（PRODUCT_VOLATILE）。
• 「正本artifact」と「agent runtime state」を自動統合する単一標準は今回の証拠では確立できない。ここはEnterprise AI Core側の設計規約として定義する領域（UNKNOWN→PROPOSAL）。

• LongMemEvalは長期memoryを extraction / multi-session reasoning / temporal reasoning / knowledge update / abstention に分解して測る。memory qualityのacceptance test候補。ただしworkflow durabilityは測らない。
• AgentRewindのMettleBenchはlong-horizon engineering assignmentでpartial progressとtask completionを測り、agent contextとcontrolled environmentを合わせたcheckpoint recoveryの有効性を検証する。runtime全般の保証ではないが、context-only recoveryの弱点を検討する一次研究として有用。
• 将来のenterprise acceptance testでは、model品質benchmarkとは別にRECOVERY TESTを設けるべき（PROPOSAL）。例: (a) checkpoint直後kill→resume、(b) tool成功・checkpoint失敗→retry、(c) human edit後resume、(d) model/tool version変更後resume、(e) compaction後に未解決constraint recall、(f) stale handoffからの再開拒否、(g)正本revision競合。

• persistenceを有効にするとprompt、tool result、checkpoint、memory等が保持データになる。LangGraph standaloneはcheckpoint encryption/TTLを提供し、OpenAI Agents SDKはEncryptedSession+TTLを提供する。TemporalもWorkflow historyへLLM I/Oを保存する設計ではpayload encryptionが重要。存在する機能と各organizationで有効な設定は分離して確認する。 AUDIT:
• runtime event history/checkpoint traceは強い監査素材になり得るが、正本artifactのrevision historyを置き換えるものではない。双方をrun/revision IDで結ぶ設計が安全（INFERENCE / PROPOSAL）。

• 長期化はhistory storage、checkpoint I/O、replay、compaction、再評価、trace retentionの費用を増やす。一方、failure時の全再実行を減らす。普遍的な損益分岐点は今回確立せず、workload-specific（INFERENCE / UNKNOWN）。

• node/taskの粒度がcheckpoint頻度と再実行量を左右する。細かいboundaryは復旧範囲を狭めるが、storage/trace overheadを増やすため、bounded unit単位でcheckpointする設計が妥当（VERIFIED_SPEC→PROPOSAL）。

「長期作業型AIを成立させる鍵は、巨大なcontext windowを一つ保持することではない。実務では、成果物の正本、実行checkpoint、会話session、圧縮・要約された作業context、外部システムの副作用、run/version/provenanceを別の状態として管理し、再開時にそれらの整合を確認する必要がある。checkpointやsessionは復旧を助けるが、外部副作用の二重実行、schema/model/tool更新、圧縮による情報欠落まで自動的に解決するわけではない。長期作業では『保存できるか』に加えて『同じ仕事を安全に再開できるか』『何が正本か』『何を再実行してよいか』を設計・試験する。」

• Enterprise AI Coreへ「LONG-RUN STATE PLANES」と「RESUME INVARIANTS」を横断原則候補として渡す。
• provider mappingでは各製品について STATE_SCOPE / STORAGE_OWNER / CHECKPOINT_GRANULARITY / RESUME_ID / INTERRUPT_HITL / COMPACTION / RETENTION / ENCRYPTION / IDEMPOTENCY_PRIMITIVE / VERSION_MIGRATION / AUDIT_EXPORT / CANONICAL_ARTIFACT_LINK を比較する。
• long-context/memory章とは統合しすぎない。memory qualityとexecution durabilityを独立軸にする。
• human handoff章ではsummary本文だけでなくmachine-readableなresume contractを要求する。
• live testは未実施。後続Workで必要なら安全なTEST_PROFILEとして、ローカル/検証環境のmock side effectを使うkill-resume・duplicate prevention・stale revision conflict試験を設計する。

• 各providerのmanaged agent runtimeが、2026-09-13時点でどこまでworkflow checkpoint、external side-effect reconciliation、schema migration、audit exportをnative保証するかは本Packetでは横断確定していない。
• compaction前後のconstraint preservationを数日〜数週間・artifact更新・tool副作用込みで比較する共通benchmarkは今回確立できない。
• model/tool/runtime更新をまたぐin-flight run migrationの互換性は製品・version依存で、個別Mappingが必要。
• tenant固有retention/encryption/data residency/backup設定はpublic docsだけでは確定できない。

• 長期作業のstate分離、checkpoint/resumeの実装実在性、idempotency/replay failure envelope、compaction境界、memory benchmark、aligned context+environment recovery、安全な将来本文表現まで一次資料＋一次研究で閉じたためEA-036はBOUNDED_CLOSE。
• 上記OPEN_UNKNOWNはprovider Product Mappingまたは将来の専用live-test/eval packetへ送る。EA-036を同じclaim/sourceで再採集しない

---

OpenAI Agents SDK current Sessions docs still distinguish persistent session memory from server-managed continuation and support resuming interrupted RunState with the same backing session; current compaction behavior includes stale-history protection. Temporal current AI reference architecture still requires nondeterministic LLM/tool/API/database I/O in Activities because Workflow code replays from history. Exact LangGraph/OpenAI/Temporal release numbers in the 2026-09-13 packet are historical anchors and must be refreshed rather than published as timeless versions.