情報区分に応じたAIメモリの保持期限とTTL

AIメモリの保持は、すべての記憶へ同じTTLを付けるだけでは管理できません。情報区分、利用目的、元データの版、保持の根拠、起算点、派生物、保持例外を対応させ、期限到達、提供停止、削除指示、実削除、backupの失効を分けて確認します。TTLは製品の削除・失効機構であり、組織が定める保持要件全体と同じものではありません。

WeaviateのTTL資料は、collection単位でcreation time、last update time、指定DATE propertyを起点に期限を設定する構成を説明しています。期限切れobjectは背景処理で削除され、未削除の期限切れobjectをqueryから除外する設定は任意です[S1]。したがって期限を設定した事実、検索から消えた事実、削除された事実を区別し、背景処理の稼働と実設定を確認します。

Amazon S3 Object Lockはobject versionへretention periodとlegal holdを独立して適用します。legal holdは明示的に解除するまで続き、どちらかが有効であれば一方の解除や期限切れだけで保護は終わりません。またversionを指定しないDELETEが成功応答を返してdelete markerを作っても、保護された旧versionは残り得ます[S2]。これはobject storageの仕様であり、AIメモリの全派生物へ自動伝播する保持機構を示すものではありません。

以下は本項が提案する管理項目です。具体的な保持年数・日数は、対象組織の決定を確認して設定します。

同じ本文でも目的や権限が異なれば適用条件が変わります。モデルによる自動分類だけで保持を確定せず、分類元、policy版、判定理由、確認主体を残します。分類不能な記憶を無期限保存へ流さず、収集・提供をどこまで許すかを既定policyで定めます。短い期限を機械的に選べばよいとも限らず、保持義務と削除要求が競合する場合は根拠を確認して解決します。

creation timeを起点にする期限と、最終更新を起点にする期限では結果が異なります。後者では、要約更新やmetadata修正が期限の延長につながる構成が考えられます。利用目的と無関係な再保存で寿命を延ばしてよいかを決め、必要なら元の業務イベントや固定期限を別fieldに持たせます。製品ごとの更新時刻の実装は確認が必要です。

派生要約を新しく作ったという理由だけで、元の記憶の保持制限を解除しません。source_id、source_revision、作成・更新・業務イベント時刻、policy版、effective_expiryを結び付けます。複数の入力から生成するmemoryでは、単純に最新の作成日時や最大TTLだけを採用せず、各入力の利用条件を照合します。導いた期限が矛盾する場合は、混合出力をそのまま利用へ戻しません。

保持例外は対象のartifactとversion、理由、権限、開始時刻、見直し条件、解除主体を記録します。例外があることと、誰でも閲覧できることは別です。通常の回答からは除外して保全だけを続けるなど、提供範囲と保存範囲を分ける必要があります。

S3のlegal holdとretention periodのように、複数の保護条件が独立して存在する場合、一つの解除だけを削除許可とみなしません。S3の現在資料には、event holdの解除イベントを起点に保持期間を計算するvariable retentionも説明されています[S2]。解除が即時削除可能を意味しない例です。これをlegal holdと同じ機能名・同じ時間計算として扱いません。

解除後は、その時点のpolicy、他の保持条件、対象version、削除要求を照合し直します。解除処理と削除処理、削除後readbackを別操作として記録し、期限切れ案件が解除待ちのまま滞留していないかを確認します。人の判断が必要な保全条件を、TTL workerが無条件に上書きしてはいけません。

元memoryの期限を要約、vector、index、cache、export、評価データへどう適用するかを決めます。保存先が異なる場合は、それぞれの削除機構と保持例外を確認し、原文だけの削除成功を全体完了としません。lineageがない範囲は保持・削除のどちらも完全に追跡できないため、未確認として残します。

backupには作成時点、対象集合、保持期限、復元権限を結び付けます。古いbackupを戻した場合に期限切れ・削除済み・訂正済みの記憶が再導入されないよう、復元後に現在のpolicyと失効記録を再適用します。保全対象がbackupにあるからといって、同じデータを通常の検索に出してよいことにはなりません。暗号消去や物理消去の証拠は、TTLの実行記録とは別に扱います。

保持マニフェストにはtenant、artifact/version、情報区分、利用目的、policy版、起算点、期限、保全条件、例外の責任者、派生先、削除状態、証拠locatorを持たせます。期限切れ候補の発見、提供停止、削除投入、処理結果、再読込を分け、失敗件数と期限超過を観測します。これは提案schemaであり、製品に共通実装されている保証ではありません。

version付き保存先では、現在のkeyへのアクセスができないことだけで旧versionの削除を判断しません。S3のdelete markerと保護versionの違いはこの確認が必要な具体例です[S2][S3]。他製品も同じAPIや保持modeを持つと仮定せず、対象製品の実際の操作単位と権限を使います。

失敗は、分類なしの無期限保存、元目的と無関係なTTL延長、期限切れobjectを返す設定、削除worker停止、例外解除後の削除忘れ、保護versionを残したmarker作成、派生物だけの残留、復元による再導入です。逆に、短いTTLの一括適用による必要証拠の消失も失敗です。保持と削除のいずれも、対象と根拠を特定して実行します。

TTLやObject Lockは有効な製品機構ですが、目的や情報区分を組織に代わって決める機能ではありません。S3の保持保護は、期限切れobjectをqueryから隠すWeaviateの設定とも異なります。保護が存在することを削除不能の一般論へ広げず、また解除可能な権限があることを組織の削除承認と混同しません。法令や契約への適合判断は、この技術仕様の確認だけでは確定しません。

架空データでcreation/update/固定期限の違い、未分類、複数目的、派生要約、保全中の削除、保全解除、背景削除停止、旧version、backup復元を確認します。正常保持と正常削除の両方を正例にし、すべてを消す・すべてを残すだけの試験にしません。本RUNでは実storeでのTTL、S3保護変更、cross-store削除を実施していません。

対象組織の分類・目的・保持根拠、適用期間、例外の承認権限、製品版・実設定、派生物とbackupへの伝播、削除遅延、復元後の再適用、実機試験、独立した保持・削除事故は未確認です。普遍的な保持期間や全保存先にわたる原子的な削除は主張しません。

「指定したpolicy版・対象version・保持条件について、提供範囲、期限、例外、削除状態を照合した」とします。「TTLが切れた」「holdを外した」「DELETEが200だった」を、全体の消去完了の代用にしません。

対象版、起算点、policyの優先関係、保全条件、解除権限、削除結果が不明なら保持・削除の完了を宣言しません。競合する条件を推測で短縮・延長しません。

EA-517-R1-20261012と継続Doc 1XpjZC_R1eHlIckvUaEaJ_mcj6YW6j0ihZ0b91z5vewUのEA-517節を継承。2026-10-18に一次資料を再確認。旧研究の保持原則を維持し、現行S3資料のevent hold/variable retentionとlegal holdを区別しました。

• [S1] Weaviate Time to live (TTL)、起算点、任意のquery除外、背景削除: https://docs.weaviate.io/weaviate/manage-collections/time-to-live
• [S2] AWS S3 Locking objects with Object Lock、version、retention periods、legal holds、variable retention、delete動作: https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
• [S3] AWS S3 Object Lock considerations、lock情報の権限、Lifecycle、delete marker: https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-managing.html