データ移行で効くAI記憶の保存期限｜続きから動ける運用設計
データ移行では、旧形式を早く消すほど整理できたように見えます。しかし、変換結果の検証やrollbackが終わる前に旧記憶を失えば、欠損の原因も元の値も追えません。反対に「念のため」で全量を残し続けると、検索時に旧データが現行値として混ざります。保存期限は削除日ではなく、移行の各段階で何を、なぜ、どこに残すかを決める運用です。
移行データを同じ期限で扱わない
移行時に生まれる情報には、現行データ、変換前snapshot、変換ログ、除外一覧、検証結果、一時backupがあります。現行データは業務上の保持規則に従い、snapshotはrollback期間、変換ログは監査と障害解析、除外一覧は取りこぼし回収まで必要です。目的が違うものへ一つの「三十日保存」を当てると、早すぎる削除か不要な長期保持が起きます。
各記憶へ、作成日、保存目的、通常検索へ出す期間、保管場所、見直しtrigger、判断担当を付けます。期限が来た時のactionも、削除、匿名化、archive、検索対象外化、延長審査に分けます。期限切れを即時完全消去と同義にしないことが重要です。
dual-read期間は旧と新を区別して残す
旧形式と新形式を並行で読む期間は、値の一致だけでなく件数、schema、checksum、除外理由を比較します。AI記憶には「旧」「新」「比較結果」を別Entityとして記録し、新しい時刻だから正本という選び方を避けます。差分がある行は、空値で通さず未解決として一覧化します。
検索結果へ旧形式が出る場合は、履歴であることと適用期限を明示します。旧データを通常検索から外しても、rollback担当が参照できる保護領域には残せます。便利さのために両方を同じindexへ入れると、移行後もAIが旧項目名や旧値を回答へ混ぜます。
保存終了の条件を工程に結び付ける
「移行完了後に削除」では終点が曖昧です。変換件数一致、除外理由の承認、代表照合、利用者側readback、次回自然処理の成功、rollback期限の終了など、観測できる条件へ分けます。工程が一つ未完なら、必要な証拠だけ保持し、無関係な一時物は別に整理できます。
たとえば変換ログは照合完了から九十日、元snapshotは二回の自然処理成功とOwner確認まで、テストfixtureは個人情報を除いて恒久保存、といった違いを許します。数字は案件の契約や法令に合わせて決め、一般例をそのまま採用しません。
期限台帳に入れる八項目
- 対象データのIDとschema版
- 保存目的と利用できる範囲
- 保管場所とアクセス権
- 作成者または生成した処理
- 見直し日または終了trigger
- 期限到来時のaction
- 延長を決められる担当者
- 削除・archive後の確認方法
台帳へsecret本文や移行対象の個人情報を複製せず、対象IDと保管先の参照を置きます。削除receiptも値そのものではなく、対象範囲、件数、実行時刻、確認結果を記録します。
一時backupを無期限の保険にしない
障害に備えたbackupは重要ですが、保管先と終了条件がなければ次の容量不足や情報混在の原因になります。作成時に、どの障害へ戻すためのものか、いつ見直すか、誰が本採用または削除を決めるかを固定します。別deviceにあることだけで復元可能とはみなしません。
期限前に実復元を試し、必要な鍵、schema、手順、checksumが揃うか確認します。復元できないbackupを長期保持しても復旧可能性は上がりません。一方、検証前に削除すればrollback手段を失うため、期限は容量目標ではなく復旧条件へ結びます。
削除時は依存と派生物を先に確認する
元データだけ消しても、検索index、cache、変換済み派生、分析表に残ることがあります。反対に元snapshotを削除したことで、現行データの由来が説明できなくなる場合もあります。削除候補から参照されるCurrent、job、手順書、監査証拠を列挙し、対象と対象外を固定します。
結果不明の削除はblind retryしません。対象件数、残存、処理receipt、保管先を読み、完了済み範囲と未完了を分けます。広いdirectoryやglobを使わず、固定した対象一覧とchecksumに一致するものだけを扱います。
移行後のreadbackで保存期限を閉じる
新形式が読めるだけでは不十分です。件数、必須項目、除外、文字化け、重複、利用者側表示、次回の増分処理を確認します。問題がなければ期限台帳の状態を「rollback待機」「archive可能」「削除可能」へ進めます。エラーが消えたことを、旧データ不要の証明にしません。
期限延長には理由、新しい期限、承認者を必須にします。「念のため」は理由になりません。未解決差分があるなら、その差分と必要証拠を限定して延長し、移行全体の一時データをまとめて残し続けないようにします。
よくある質問
新システムが動いたら旧データを削除してよいですか？
変換照合、利用者側確認、次回自然処理、rollback期限を先に確認します。動作一回だけでは取りこぼしや長期的な互換性を証明できません。
期限切れデータは必ず完全削除しますか？
目的に応じ、通常検索から外す、権限を狭めてarchiveする、匿名化する、削除するを選びます。法令や契約上の保持がある場合はそれを優先します。
backupの保持期間は長いほど安全ですか？
復元でき、アクセスが限定され、見直しが動く場合に限ります。未検証のbackupを増やすと、古い値の混入や漏えい範囲を広げることがあります。
参照した一次資料
OpenClawのMemory文書は、利用者が確認・編集できるMarkdown記憶を案内しています。W3C PROV-Oは情報、活動、主体と、生成・利用・派生の関係を表現する語彙を定義しています。NIST AI RMF 1.0はGovern、Map、Measure、Manageでリスク管理を整理し、継続的な見直しに使える枠組みを示しています。
保持と削除の条件は、対象データ、契約、法令、復旧要件によって異なります。この記事は法的助言や特定製品の保存仕様を断定するものではありません。
あわせて読みたい
AIと記憶の関係を研究する実録から、エージェントメモリーズ開発秘話まで。記憶を持つAIのつくり方を綴っています。
ほかの記事を読む Agent Memoriesを見る