AI Data／Memory Lifecycle専門編

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別に管理する運用層を追加するための証拠棚である。

Enterprise AI Core / provider mapping / organization overlay / governance / privacy / security / audit / implementation / benchmark。model-weight unlearningそのものは本Packetの主対象外とし、application/session/memory artifactの削除からweight-level unlearningを推論しない。

• 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の複数段階として扱うべきか。
• delete/resetはどのartifactを対象とし、どの時点で何が不可視・削除・回復不能になるのか。
• TTL、論理削除、behavioral forgetting、storage sanitizationは同義ではないことを、現行provider仕様と研究でどこまで確立できるか。
• 後続Workが安全に「忘却」を検証するためのprovider-neutral TEST_PROFILEはどう設計すべきか。

• 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第三者ポリシーも存在。

• 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消去は同一時点ではない。

• 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にも別寿命が存在する。

• 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あり。

• 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を仮定できない。

• 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対象とする基礎。

• 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を定める必要がある。

• 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の証明ではない。

• 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のどこまでを含むかを明示する。

• 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消去を推論しない。

• 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実挙動を確定しない。

現行主要providerにはTTL、delete/purge、revision、retention期間、ZDR等の個別primitiveが既に実装されている。一方、provider-neutralに「このresetで全派生memoryと残存surfaceが消えた」と表現・証明する共通schema/standardは本RUNで確認できていない。Core実装はprovider adapterが各artifactをLifecycle Matrixへ写像する方式が現実的。

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として保存。

長期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も別管理する。

長期保存、revision、index、backup、定期purge、残存検証にはstorage/operation/evaluation costがある。保持しない設計はprivacyだけでなくcost controlにもなる。

asynchronous deletion、eventual consistency、recovery grace window、TTL refresh、non-retroactive config変更を運用runbookへ組み込む。reset完了通知を単一booleanに縮約しない。

「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・物理媒体までの消去を断定しない。」

• 将来本文では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文言を必ず再確認する。

• 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依存。

multi-artifact lifecycle、providerごとのretention/delete差、delete後残存window、behavioral forgettingとstorage deletionの分離、bounded residual TEST_PROFILEまで確立したため、本EAの先行採集は一旦停止。次回は未調査最小EAへ進む。

---

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.