2026.09.14 / Agent Memories

データ移行で効くAI記憶のアクセス範囲｜続きから動ける運用設計

AIメモリーを新しい基盤へ移行する時、最も危険なのはコピーの失敗だけではありません。旧環境では分離されていた個人、部署、顧客の情報が、新環境で広く検索できる状態になることがあります。移行成功を「件数が一致した」で終えると、アクセス範囲の拡大を見逃します。

この記事では、データ移行を棚卸し、変換、検証、切り替え、旧環境の終了という五段階に分け、各段階で誰が何を読めるかを固定します。対象はファイル型メモリー、検索索引、ベクトルDB、会話から生成した要約です。実際の権限方式は製品ごとに異なるため、概念を自社のアクセス制御へ置き換えてください。

移行前に「データ」と「見える範囲」を二列で棚卸しする

ファイル名やレコード数だけでなく、所有者、対象ユーザー、共有先、機密区分、保持期限を並べます。たとえば同じプロジェクト名でも、経営層だけの決定、全員向け手順、個人の下書きは範囲が異なります。一つのフォルダにあるという理由で同じ権限を付けません。

棚卸し結果には「移行する」「移行しない」「確認待ち」を付けます。所有者や根拠が不明なデータを新環境へ先に運ぶと、後から削除範囲を特定できません。確認待ちは隔離し、検索対象へ入れないのが安全です。

旧権限から新権限への対応表を作る

旧環境のグループ名をそのまま新環境へ写すのではなく、意味を比較します。「member」が旧環境では閲覧のみ、新環境では編集可能ということがあります。ユーザー、グループ、サービスアカウント、管理者の四種類について、読み取り、書き込み、削除、共有、エクスポートを表にします。

対応が一意に決まらない権限は、より狭い側へ仮配置し、所有者の確認後に広げます。移行の都合で全員を一時管理者にする方法は避け、必要な処理だけを行う移行専用権限を作ります。

移行担当のアクセスは期間と処理へ限定する

移行ツールは大量データを扱うため、日常運用より強い権限を持ちがちです。専用アカウントに対象データ、実行時間、接続元、操作種類の制限を付けます。作業終了後に無効化する時刻も先に決め、個人の常用アカウントへ恒久権限を追加しません。

秘密情報をログへ出さず、件数、レコードID、要約値、失敗理由だけを記録します。エラー調査で本文が必要な場合は、対象一件、承認者、閲覧期限を残します。全件ダンプをチャットやチケットへ貼ることは禁止します。

変換後の検証環境を本番利用者から隔離する

ステージングへコピーしたデータが、通常のAI検索から見える状態は危険です。ネットワーク、アカウント、検索索引を本番から分け、検証用の架空ユーザーで照合します。実データを使う場合も、閲覧できる担当を最小化し、検証終了日を設定します。

検証では件数と内容に加え、拒否されるべき検索を試します。別部署の固有語、退職者のID、非共有プロジェクト名を入力し、結果が返らないことを確認します。許可テストだけではアクセス漏れを見つけられません。

検索索引の継承で境界が消えないか確認する

本文ファイルに正しい権限があっても、索引が全データを一つへまとめると検索結果から漏れる場合があります。チャンクごとに所有者とアクセス属性が付くか、検索時に認可が適用されるか、キャッシュへ古い権限が残らないかを確認します。

権限変更後の利用者で再検索し、以前見えた情報が出ないことを試します。索引更新の遅延があるなら、その間の安全策を決めます。更新完了まで検索を対象領域だけ外す、正本参照へ切り替えるなど、全サービス停止より狭い代替を選びます。

切り替えは一部利用者から段階的に行う

最初に内部の少人数へ読み取りのみで開き、正しい記憶が見えることと、見えてはいけない記憶が出ないことを確認します。次に訂正や新規保存を一件試し、旧環境へ二重に書かれないかを見ます。成功条件を満たしてから対象を広げます。

切り替え中は、どちらを正本にするかを一つに固定します。両方へ自由に書ける期間を長くすると、更新順と削除状態が競合します。結果不明の同期は再実行せず、両側の版と処理台帳を照合します。

ロールバックでも権限を巻き戻す

データだけ旧環境へ戻し、新環境で追加した権限や移行アカウントを残すと、アクセス範囲は復旧していません。戻し方には、正本の切り替え、検索経路、DNSや接続設定、移行権限、検証コピー、監査ログの扱いを含めます。

ロールバック後は、代表ユーザー三種類で許可検索と拒否検索を再実行します。移行中に受け付けた訂正・削除要求も回収し、どちらの環境にも反映されたか確認します。

旧環境の終了は削除前に保留期間を置く

新環境が動いた直後に旧データを消すと、欠損を見つけても戻せません。読み取り専用の保留期間を置き、次の定常実行、利用者からの訂正、監査結果を確認します。保留期間中も旧環境のアクセスを広げず、終了担当と期限を決めます。

削除が承認されたら、本文、索引、キャッシュ、一時エクスポート、移行用資格情報を対象別に処理します。何を削除し、何を法的・監査上保持するかを記録し、単にサーバーを停止しただけで完了としません。

一次資料と現在の版

OpenClawのMemory overviewは、記憶ファイルと検索索引を別の要素として説明し、由来付きのインポートや検索対象を扱います。移行時に本文と検索面を別々に検証する参考になります。W3C PROV-Oは、旧データ、新データ、変換活動、担当主体の派生関係を表すために利用できます。

NIST AI Risk Management Frameworkは、AIシステムのライフサイクル全体でリスクを統治・把握・測定・管理する考え方を示します。本記事の参照版は2023年のAI RMF 1.0です。NISTはAI RMF 1.0を現在改訂中としているため、移行計画では1.0と将来の改訂版を混同せず、確認日と採用版を明示します。

よくある質問

移行期間だけ全担当者を管理者にしてもよいですか？

推奨しません。対象データ、操作、期間を限定した移行専用権限を使い、終了時に無効化します。管理者権限が必要な例外は一件ずつ記録します。

件数と要約値が一致すれば移行成功ですか？

不十分です。所有者、共有範囲、期限、検索時の認可、拒否されるべき問い合わせを確認し、実際の利用者権限で表示を試します。

旧環境はいつ削除できますか？

新環境の定常利用、訂正・削除、次回自動処理、アクセス境界を確認し、欠損回収と戻し方が不要になった後です。保持義務がある記録は別に扱います。