# AI Data／Memory Lifecycle専門編 CURRENT_STATUS: UNKNOWN OBSERVATION: SPEC_ONLY FRESHNESS: UNKNOWN PAGE_TYPE: reference CANONICAL_URL: /tools/ea-064-ai-data-memory-lifecycle CLAIM_IDS: none EVIDENCE_IDS: EVD-EA-064-URL-2ACA780AF5AA, EVD-EA-064-URL-464C77F21263, EVD-EA-064-URL-E51F0E399A8F, EVD-EA-064-URL-E1D8694DCCFC, EVD-EA-064-URL-C9D674FF5EF1, EVD-EA-064-URL-CFB8F2CA4245, EVD-EA-064-URL-7C4686E15F54, EVD-EA-064-URL-48E2615E119F, EA-064-R11-RESEARCH, EA-064-R11-WEB-READBACK UNKNOWN_IDS: EA-064-UNKNOWN-01, EA-064-UNKNOWN-CURRENTNESS OPS_IDS: none ## Summary 「Enterprise AIのmemory lifecycleは『覚える／忘れる』の二値ではない。session/raw event、派生summary、durable memory、revision、retrieval index、application state、logなどに別々のretentionとdelete semanticsが存在し得る。delete/resetを運用要件にする場合は、対象scopeとartifact、期待される残存期間、確認方法を分離して記録する。API上の404やagentの非想起だけから、全派生物・backup・物理媒体までの消去を断定しない。」 ## Current judgment - VERIFIED_SPEC: “memory”はprovider内でも単一artifactではない。OpenAIはabuse log/application state、Googleはcurrent Memory/revision、AWSはraw event/session summary等を別レイヤとして扱う。よってEnterprise AI Coreはartifact classごとにlifecycleを追う必要がある。 - VERIFIED_SPEC: deleteは即時・全面消去と同義ではない。Google Memory Bankは親memory削除後もrevisionを最大48時間参照・rollback可能。OpenAIでも一部stateful objectは削除後server deletionまで30日とされる。 - VERIFIED_SPEC: TTLの作用範囲と更新規則は製品固有。Googleではupdate/generateがexpirationを再計算し得る。AWS AgentCoreではretention設定変更が既存eventへ遡及しない。したがって「retentionを30日に変更したから既存dataも30日以内に消える」とは一般化できない。 - INFERENCE: summarization/extraction/consolidationは派生data生成である。raw sessionを削除してもderived summary/fact/revision/indexが連鎖削除されるかは個別仕様または実測で確認すべきである。 - PROPOSAL: Coreに `AI Memory Lifecycle Matrix / Artifact Deletion Graph` を置き、少なくとも artifact_type / source / derived_from / scope(user, session, agent, org) / store / create_time / update_time / TTL / retention_rule / delete_method / delete_requested_at / logical_inaccessibility_at / expected_purge_at / residual_window / external_copy / evidence を管理する。 - PROPOSAL: “reset”は曖昧語として禁止せず、必ずdestructive scope manifestを伴わせる。reset対象にsession、durable memory、revision、vector/index、files、logs、tool/MCP downstream stateのどこまでを含むかを明示する。 ## Scope Enterprise AI Core / provider mapping / organization overlay / governance / privacy / security / audit / implementation / benchmark。model-weight unlearningそのものは本Packetの主対象外とし、application/session/memory artifactの削除からweight-level unlearningを推論しない。 ## Confirmed - VERIFIED_SPEC: “memory”はprovider内でも単一artifactではない。OpenAIはabuse log/application state、Googleはcurrent Memory/revision、AWSはraw event/session summary等を別レイヤとして扱う。よってEnterprise AI Coreはartifact classごとにlifecycleを追う必要がある。 - VERIFIED_SPEC: deleteは即時・全面消去と同義ではない。Google Memory Bankは親memory削除後もrevisionを最大48時間参照・rollback可能。OpenAIでも一部stateful objectは削除後server deletionまで30日とされる。 - VERIFIED_SPEC: TTLの作用範囲と更新規則は製品固有。Googleではupdate/generateがexpirationを再計算し得る。AWS AgentCoreではretention設定変更が既存eventへ遡及しない。したがって「retentionを30日に変更したから既存dataも30日以内に消える」とは一般化できない。 - INFERENCE: summarization/extraction/consolidationは派生data生成である。raw sessionを削除してもderived summary/fact/revision/indexが連鎖削除されるかは個別仕様または実測で確認すべきである。 - PROPOSAL: Coreに `AI Memory Lifecycle Matrix / Artifact Deletion Graph` を置き、少なくとも artifact_type / source / derived_from / scope(user, session, agent, org) / store / create_time / update_time / TTL / retention_rule / delete_method / delete_requested_at / logical_inaccessibility_at / expected_purge_at / residual_window / external_copy / evidence を管理する。 - PROPOSAL: “reset”は曖昧語として禁止せず、必ずdestructive scope manifestを伴わせる。reset対象にsession、durable memory、revision、vector/index、files、logs、tool/MCP downstream stateのどこまでを含むかを明示する。 ## UNKNOWN - EA-064-UNKNOWN-01: - provider横断で利用できるreset/forgetting completeness証明schemaは未確認。 - backup/replica/low-level purgeの多くはpublic APIから直接観測不能で、契約・内部control evidenceが必要になり得る。 - raw source削除がderived summary/embedding/indexへtransitive deleteされる条件はproduct別に未確定。 - deletionと同時進行のmemory generation/consolidation、eventual consistency中のrace behaviorは未検証。 - external MCP/tool/third-party memoryへの派生data削除は各第三者policy/API依存。 - EA-064-UNKNOWN-CURRENTNESS: 外部根拠の再確認日がcanonical body/control-planeで確定していないため、currentnessはUNKNOWNとして保持する。日付を推測補完しない。 ## Evidence - EVD-EA-064-URL-2ACA780AF5AA (RESEARCH): author/org: OpenAI — https://developers.openai.com/api/docs/guides/your-data - EVD-EA-064-URL-464C77F21263 (RESEARCH): author/org: Google Cloud — https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/memory-bank/revisions - EVD-EA-064-URL-E51F0E399A8F (RESEARCH): author/org: Google Cloud — https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/memory-bank/setup - EVD-EA-064-URL-E1D8694DCCFC (RESEARCH): author/org: Amazon Web Services — https://docs.aws.amazon.com/bedrock/latest/userguide/agents-configure-memory.html - EVD-EA-064-URL-C9D674FF5EF1 (RESEARCH): author/org: Amazon Web Services — https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory-create-a-memory-store.html - EVD-EA-064-URL-CFB8F2CA4245 (RESEARCH): author/org: NIST — https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf - EVD-EA-064-URL-7C4686E15F54 (RESEARCH): author/org: Ramaswamy Chandramouli (NIST), Eric A. Hibbard (Samsung Semiconductor) / NIST — https://csrc.nist.gov/pubs/sp/800/88/r2/final - EVD-EA-064-URL-48E2615E119F (RESEARCH): author/org: Md Nayem Uddin, Kumar Shubham, Eduardo Blanco, Chitta Baral, Gengyu Wang / Findings of ACL 2026 — https://aclanthology.org/2026.findings-acl.1337/ - EA-064-R11-RESEARCH (RESEARCH): EA-064 監査済みresearch / canonical revision binding - EA-064-R11-WEB-READBACK (IMPL): EA-064 Web body identity / canonical readback ## Failure / limits APIの404、listからの消失、agentが回答しなくなったことは、それぞれlogical deletion / retrieval absence / behavioral forgettingの証拠であり、物理媒体・backup・replica・派生物までの消去を単独では証明しない。 ## Failure / limits 逆にstorage objectを削除しても、同じfactが別session、summary、revision、RAG corpus、tool/MCP、human-authored profile等に残ればagentは再び同内容を取得し得る。 ## Failure / limits provider public docsはtenant固有legal hold、契約、safety exception、backup内部実装を完全には証明しない。 ## Failure / limits NIST SP 800-88r2はmedia sanitization基準であり、SaaS APIのdelete endpointにそのまま適用できるとの証拠ではない。ここでは「削除成功≠media sanitization」の境界根拠として使用。 ## Failure / limits Memora/FAMAはbehavioral memory correctnessを測るbenchmarkで、provider storage deletionやregulatory erasure保証へ外挿しない。 ## Failure / limits model-weight training/unlearningはapplication memory lifecycleとは別問題。本Packetからweight-level消去を推論しない。 ## Failure / limits multi-artifact lifecycle、providerごとのretention/delete差、delete後残存window、behavioral forgettingとstorage deletionの分離、bounded residual TEST_PROFILEまで確立したため、本EAの先行採集は一旦停止。次回は未調査最小EAへ進む。 --- ## Practice OpenAI ZDR/MAMはeligible customer向け承認制で、endpoint/capabilityごとにZDR適格性が異なる。safety/legal例外もあり得る。 ## Practice Google Memory Bankはproject/API/IAM/region等の要件を持つ。revision/TTL semanticsは現行Memory Bank固有であり他Google productへ一般化しない。 ## Practice AWS Bedrock memoryは対応model/RegionとmemoryId等の設定に依存。AgentCore MemoryとBedrock Agents session-summary memoryを同一実装として扱わない。 ## Practice organization retention、legal hold、regulated workload契約はprovider defaultより優先・追加され得るため、公開docだけでtenant実挙動を確定しない。 ## Practice 現行主要providerにはTTL、delete/purge、revision、retention期間、ZDR等の個別primitiveが既に実装されている。一方、provider-neutralに「このresetで全派生memoryと残存surfaceが消えた」と表現・証明する共通schema/standardは本RUNで確認できていない。Core実装はprovider adapterが各artifactをLifecycle Matrixへ写像する方式が現実的。 ## Practice RESEARCH: Memora/FAMAは、最新memory stateに対してobsolete/deleted informationを使わないかを測る有力なbehavioral forgetting評価である。 PROPOSAL TEST_PROFILE（未実施・synthetic data only）: ## Practice synthetic canary factをraw session/eventへ投入し、summary/long-term memory/revision/indexが生成されたIDと時刻を記録。 ## Practice TTL、retention、revision設定、provider/API revisionを記録。 ## Practice scoped delete/resetを実施し、即時にget/list/search/retrieve/semantic recallを確認。 ## Practice providerが明示するrecovery/purge window後に同一検査を再実施。 ## Practice exposedであればrevision、derived summary、vector/index、file、audit/log、tool/MCP downstream storeも別々に確認。 ## Practice paraphraseを含むnegative recall testでobsolete fact再利用を測る。ただしnegative recallはstorage erasure証明とはしない。 ## Practice deletion request ID、completion、expected residual window、各surfaceの結果をevidenceとして保存。 ## Practice 長期memoryはpersonal/sensitive contextの保持期間とblast radiusを増やす。stale/obsolete memoryの再利用もprivacy・correctness riskになる。 AUDIT: delete/resetはscope、resource ID、artifact class、provider/API revision、request/operation ID、request/completion time、expected residual window、verification結果を残す。監査log自体のretention/minimizationも別管理する。 ## Practice 将来本文ではEA-063 Privacy Engineeringと接続しつつ、privacy原則ではなく「実装・運用としての寿命管理」に独立節を置く。 ## Practice provider mappingはOpenAI=endpoint別application-state/abuse-log/ZDR、Google=Memory/Revision/TTL/recovery window、AWS=SESSION_SUMMARY retentionとAgentCore raw-event expiryを別表にする。 ## Practice Core用 `AI Memory Lifecycle Matrix / Artifact Deletion Graph` の採否を監査する。 ## Practice reset/deletion手順には上記synthetic TEST_PROFILEを添え、認証tenantで必要な場合のみ後続Workが安全審査後に実施する。 ## Practice 2026年以降のmemory APIは変動が速いため、公開後アップデート時には各providerのretention/delete/revision/ZDR文言を必ず再確認する。 ## Practice Raw session/events, summaries, durable memory, revisions, vector/index state, files/application state, logs and third-party state can have independent lifecycle semantics. Delete/reset, TTL expiry, behavioral forgetting and storage sanitization are not synonyms. Negative recall is not storage-erasure proof. AWS Bedrock user-guide/API storageDays discrepancy remains explicit. ## WHY_THIS_MATTERS_TO_UPDATE Enterprise AIの「memory」は単一ストアではない。raw conversation/session event、要約、抽出fact、長期memory、revision、embedding/vector index、application state、abuse/audit log、backup/replica、外部tool/MCP側stateなどが別ライフサイクルを持ち得る。したがって「memoryを消した」「resetした」を一語で扱うと、active read pathから消えただけなのか、派生物・revision・ログ・復旧用コピーまで消えたのかを誤認する。本項は、remember/forgetの機能説明ではなく、生成から残存検証までをartifact別に管理する運用層を追加するための証拠棚である。 ## SCOPE_ROUTING Enterprise AI Core / provider mapping / organization overlay / governance / privacy / security / audit / implementation / benchmark。model-weight unlearningそのものは本Packetの主対象外とし、application/session/memory artifactの削除からweight-level unlearningを推論しない。 ## CLAIM_OR_RESEARCH_QUESTION 1. Enterprise AIのdata/memory lifecycleは、create/ingest → derive/extract/summarize → persist → retrieve/use → update/consolidate → expire/TTL → logical delete/reset → recovery/replica purge → residual verificationの複数段階として扱うべきか。 2. delete/resetはどのartifactを対象とし、どの時点で何が不可視・削除・回復不能になるのか。 3. TTL、論理削除、behavioral forgetting、storage sanitizationは同義ではないことを、現行provider仕様と研究でどこまで確立できるか。 4. 後続Workが安全に「忘却」を検証するためのprovider-neutral TEST_PROFILEはどう設計すべきか。 ## EVIDENCE TABLE 1) source class: official product documentation exact title: Data controls in the OpenAI platform author/org: OpenAI canonical URL: https://developers.openai.com/api/docs/guides/your-data publication/update/access date: update date not stated / accessed 2026-09-14 version/release/API revision/model ID: current API data-controls documentation as-of 2026-09-14 supporting locator: “Types of data stored with the OpenAI API”; “Data retention controls for abuse monitoring”; “Storage requirements and retention controls per endpoint”; endpoint-specific notes for Responses / Assistants / Threads / Vector Stores / Files evidence label: VERIFIED_SPEC + PRODUCT_VOLATILE relation: support + limit + availability gate finding: abuse monitoring logsとapplication stateは別カテゴリ。標準abuse monitoringは最大30日。ZDR/MAMは承認制で、ZDRはResponses/Chat Completionsのstoreをfalse扱いにする一方、ZDR非適格endpoint/capabilityはapplication stateを保持し得る。Conversations等はuntil deleted、Assistants/Threads/Vector Stores等はuntil deletedかつ削除後server deletionまで30日と記載。Filesはmanual deleteまたはexpires_afterを持つ。画像/fileの一部safety例外やRemote MCP第三者ポリシーも存在。 2) source class: official product documentation exact title: Memory revisions | Gemini Enterprise Agent Platform | Google Cloud Documentation author/org: Google Cloud canonical URL: https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/memory-bank/revisions publication/update/access date: accessed 2026-09-14 version/release/API revision/model ID: current Agent Platform Memory Bank documentation as-of 2026-09-14 supporting locator: “Lifecycle of a memory and its revisions”; “Memory deletion”; “Revision expiration” evidence label: VERIFIED_SPEC + PRODUCT_VOLATILE relation: support + counter/limit finding: Memory BankはMemoryとimmutable MemoryRevisionを分離し、revisionは既定で有効。Memory削除時、現行Memory resourceは消えるがdelete mutationのrevisionが作られ、child revisionsは親削除後最大48時間参照できrollbackも可能。通常のrevision TTLは既定365日。active object deletionとhistorical state消去は同一時点ではない。 3) source class: official product documentation exact title: Set up Memory Bank | Gemini Enterprise Agent Platform | Google Cloud Documentation author/org: Google Cloud canonical URL: https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/memory-bank/setup publication/update/access date: accessed 2026-09-14 version/release/API revision/model ID: Agent Platform SDK example google-cloud-aiplatform>=1.111.0; current docs as-of 2026-09-14 supporting locator: “Time to live (TTL) configuration”; Memory Bank configuration examples evidence label: VERIFIED_SPEC + PRODUCT_VOLATILE relation: support + limit finding: TTL未設定ならcreated/updated memoryは自動expireしない。TTLはcreate/update/generate等のoperation別に設定でき、update時に新しいexpirationへ更新され得る。revisionとcurrent memoryにも別寿命が存在する。 4) source class: official product documentation exact title: Enable agent memory author/org: Amazon Web Services canonical URL: https://docs.aws.amazon.com/bedrock/latest/userguide/agents-configure-memory.html publication/update/access date: accessed 2026-09-14 version/release/API revision/model ID: current Amazon Bedrock Agents documentation as-of 2026-09-14 supporting locator: Memory duration / memoryConfiguration / storageDays / memoryId note evidence label: VERIFIED_SPEC + PRODUCT_VOLATILE relation: support + availability gate finding: Bedrock Agent memoryはSESSION_SUMMARY型、retention 1–365日、既定30日。memoryIdをinvoke時に指定しないturnはmemoryへ保存されない。model/Region availability gateあり。 5) source class: official product documentation exact title: Create a memory store (AgentCore Memory) author/org: Amazon Web Services canonical URL: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory-create-a-memory-store.html publication/update/access date: accessed 2026-09-14 version/release/API revision/model ID: current AgentCore Memory documentation as-of 2026-09-14 supporting locator: event retention / eventExpiryDuration evidence label: VERIFIED_SPEC + PRODUCT_VOLATILE relation: support + limit finding: raw eventのshort-term memory expiryは最大365日。eventExpiryDurationはwrite時にeventごとへ適用され、設定変更は将来eventにのみ作用し、既存eventは元のexpirationを保持する。retention設定変更のretroactive effectを仮定できない。 6) source class: standard/guidance exact title: NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0 author/org: NIST canonical URL: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf publication/update/access date: 2020-01-16 / accessed 2026-09-14 version/release: Version 1.0 supporting locator: data action/data processing definitions; CT.PO-P2; CT.PO-P4; CT.DM-P4/P5/P8/P9 evidence label: VERIFIED_SPEC relation: context + support finding: data lifecycleをcollectionからdisposalまで扱い、retention/logging/generation/transformation/use/disclosure/transmission/disposalをdata actionに含める。削除・破壊・log・技術的対策のtest/assessmentまでpolicy対象とする基礎。 7) source class: standard/guidance exact title: Guidelines for Media Sanitization author/org: Ramaswamy Chandramouli (NIST), Eric A. Hibbard (Samsung Semiconductor) / NIST canonical URL: https://csrc.nist.gov/pubs/sp/800/88/r2/final publication/update/access date: 2025-09-26 final / accessed 2026-09-14 version/release: NIST SP 800-88 Rev.2 supporting locator: abstract; media sanitization program; distributed/cloud propagation; sanitization outcome/evidence guidance evidence label: VERIFIED_SPEC relation: context + limit finding: sanitizationはtarget dataへのaccessを一定労力でinfeasibleにする概念で、分散/cloudでは複数system/organizationへdataが伝播し得る。削除APIの成功をmedia-level sanitization証明へ外挿してはならず、期待結果とevidenceを定める必要がある。 8) source class: primary research paper exact title: From Recall to Forgetting: Benchmarking Long-Term Memory for Personalized Agents author/org: Md Nayem Uddin, Kumar Shubham, Eduardo Blanco, Chitta Baral, Gengyu Wang / Findings of ACL 2026 canonical URL: https://aclanthology.org/2026.findings-acl.1337/ publication/update/access date: July 2026 / accessed 2026-09-14 version/release: Findings ACL 2026; DOI 10.18653/v1/2026.findings-acl.1337 supporting locator: abstract; Forgetting-Aware Memory Accuracy (FAMA); benchmark comparison and evaluation sections evidence label: RESEARCH relation: support + counter/limit finding: Memoraはmemory mutation/deletion後のobsolete/invalid memory再利用を評価し、FAMAは有効memoryの利用だけでなく無効化・削除済みmemoryへの依存を罰する。複数memory agentでobsolete informationの再利用が観測された。ただしこれはbehavioral forgetting評価であり、storage purgeの証明ではない。 ## FINDINGS - VERIFIED_SPEC: “memory”はprovider内でも単一artifactではない。OpenAIはabuse log/application state、Googleはcurrent Memory/revision、AWSはraw event/session summary等を別レイヤとして扱う。よってEnterprise AI Coreはartifact classごとにlifecycleを追う必要がある。 - VERIFIED_SPEC: deleteは即時・全面消去と同義ではない。Google Memory Bankは親memory削除後もrevisionを最大48時間参照・rollback可能。OpenAIでも一部stateful objectは削除後server deletionまで30日とされる。 - VERIFIED_SPEC: TTLの作用範囲と更新規則は製品固有。Googleではupdate/generateがexpirationを再計算し得る。AWS AgentCoreではretention設定変更が既存eventへ遡及しない。したがって「retentionを30日に変更したから既存dataも30日以内に消える」とは一般化できない。 - INFERENCE: summarization/extraction/consolidationは派生data生成である。raw sessionを削除してもderived summary/fact/revision/indexが連鎖削除されるかは個別仕様または実測で確認すべきである。 - PROPOSAL: Coreに `AI Memory Lifecycle Matrix / Artifact Deletion Graph` を置き、少なくとも artifact_type / source / derived_from / scope(user, session, agent, org) / store / create_time / update_time / TTL / retention_rule / delete_method / delete_requested_at / logical_inaccessibility_at / expected_purge_at / residual_window / external_copy / evidence を管理する。 - PROPOSAL: “reset”は曖昧語として禁止せず、必ずdestructive scope manifestを伴わせる。reset対象にsession、durable memory、revision、vector/index、files、logs、tool/MCP downstream stateのどこまでを含むかを明示する。 ## LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE - APIの404、listからの消失、agentが回答しなくなったことは、それぞれlogical deletion / retrieval absence / behavioral forgettingの証拠であり、物理媒体・backup・replica・派生物までの消去を単独では証明しない。 - 逆にstorage objectを削除しても、同じfactが別session、summary、revision、RAG corpus、tool/MCP、human-authored profile等に残ればagentは再び同内容を取得し得る。 - provider public docsはtenant固有legal hold、契約、safety exception、backup内部実装を完全には証明しない。 - NIST SP 800-88r2はmedia sanitization基準であり、SaaS APIのdelete endpointにそのまま適用できるとの証拠ではない。ここでは「削除成功≠media sanitization」の境界根拠として使用。 - Memora/FAMAはbehavioral memory correctnessを測るbenchmarkで、provider storage deletionやregulatory erasure保証へ外挿しない。 - model-weight training/unlearningはapplication memory lifecycleとは別問題。本Packetからweight-level消去を推論しない。 ## AVAILABILITY_GATES - OpenAI ZDR/MAMはeligible customer向け承認制で、endpoint/capabilityごとにZDR適格性が異なる。safety/legal例外もあり得る。 - Google Memory Bankはproject/API/IAM/region等の要件を持つ。revision/TTL semanticsは現行Memory Bank固有であり他Google productへ一般化しない。 - AWS Bedrock memoryは対応model/RegionとmemoryId等の設定に依存。AgentCore MemoryとBedrock Agents session-summary memoryを同一実装として扱わない。 - organization retention、legal hold、regulated workload契約はprovider defaultより優先・追加され得るため、公開docだけでtenant実挙動を確定しない。 ## IMPLEMENTATION_STATE 現行主要providerにはTTL、delete/purge、revision、retention期間、ZDR等の個別primitiveが既に実装されている。一方、provider-neutralに「このresetで全派生memoryと残存surfaceが消えた」と表現・証明する共通schema/standardは本RUNで確認できていない。Core実装はprovider adapterが各artifactをLifecycle Matrixへ写像する方式が現実的。 ## BENCHMARK_OR_EVAL RESEARCH: Memora/FAMAは、最新memory stateに対してobsolete/deleted informationを使わないかを測る有力なbehavioral forgetting評価である。 PROPOSAL TEST_PROFILE（未実施・synthetic data only）: 1. synthetic canary factをraw session/eventへ投入し、summary/long-term memory/revision/indexが生成されたIDと時刻を記録。 2. TTL、retention、revision設定、provider/API revisionを記録。 3. scoped delete/resetを実施し、即時にget/list/search/retrieve/semantic recallを確認。 4. providerが明示するrecovery/purge window後に同一検査を再実施。 5. exposedであればrevision、derived summary、vector/index、file、audit/log、tool/MCP downstream storeも別々に確認。 6. paraphraseを含むnegative recall testでobsolete fact再利用を測る。ただしnegative recallはstorage erasure証明とはしない。 7. deletion request ID、completion、expected residual window、各surfaceの結果をevidenceとして保存。 ## SECURITY/PRIVACY 長期memoryはpersonal/sensitive contextの保持期間とblast radiusを増やす。stale/obsolete memoryの再利用もprivacy・correctness riskになる。 AUDIT: delete/resetはscope、resource ID、artifact class、provider/API revision、request/operation ID、request/completion time、expected residual window、verification結果を残す。監査log自体のretention/minimizationも別管理する。 ## COST 長期保存、revision、index、backup、定期purge、残存検証にはstorage/operation/evaluation costがある。保持しない設計はprivacyだけでなくcost controlにもなる。 ## OPERABILITY asynchronous deletion、eventual consistency、recovery grace window、TTL refresh、non-retroactive config変更を運用runbookへ組み込む。reset完了通知を単一booleanに縮約しない。 ## SAFE_WORDING_FOR_FUTURE_BOOK 「Enterprise AIのmemory lifecycleは『覚える／忘れる』の二値ではない。session/raw event、派生summary、durable memory、revision、retrieval index、application state、logなどに別々のretentionとdelete semanticsが存在し得る。delete/resetを運用要件にする場合は、対象scopeとartifact、期待される残存期間、確認方法を分離して記録する。API上の404やagentの非想起だけから、全派生物・backup・物理媒体までの消去を断定しない。」 ## UPDATE_WORK_HANDOFF - 将来本文ではEA-063 Privacy Engineeringと接続しつつ、privacy原則ではなく「実装・運用としての寿命管理」に独立節を置く。 - provider mappingはOpenAI=endpoint別application-state/abuse-log/ZDR、Google=Memory/Revision/TTL/recovery window、AWS=SESSION_SUMMARY retentionとAgentCore raw-event expiryを別表にする。 - Core用 `AI Memory Lifecycle Matrix / Artifact Deletion Graph` の採否を監査する。 - reset/deletion手順には上記synthetic TEST_PROFILEを添え、認証tenantで必要な場合のみ後続Workが安全審査後に実施する。 - 2026年以降のmemory APIは変動が速いため、公開後アップデート時には各providerのretention/delete/revision/ZDR文言を必ず再確認する。 ## OPEN_UNKNOWN - provider横断で利用できるreset/forgetting completeness証明schemaは未確認。 - backup/replica/low-level purgeの多くはpublic APIから直接観測不能で、契約・内部control evidenceが必要になり得る。 - raw source削除がderived summary/embedding/indexへtransitive deleteされる条件はproduct別に未確定。 - deletionと同時進行のmemory generation/consolidation、eventual consistency中のrace behaviorは未検証。 - external MCP/tool/third-party memoryへの派生data削除は各第三者policy/API依存。 ## STOP_CONDITION multi-artifact lifecycle、providerごとのretention/delete差、delete後残存window、behavioral forgettingとstorage deletionの分離、bounded residual TEST_PROFILEまで確立したため、本EAの先行採集は一旦停止。次回は未調査最小EAへ進む。 --- ## AUDITED_BOUNDARY Raw session/events, summaries, durable memory, revisions, vector/index state, files/application state, logs and third-party state can have independent lifecycle semantics. Delete/reset, TTL expiry, behavioral forgetting and storage sanitization are not synonyms. Negative recall is not storage-erasure proof. AWS Bedrock user-guide/API storageDays discrepancy remains explicit. NEXT: /agent/start.json STOP: This is a knowledge projection, not an execution order.