エージェントメモリの削除要請対応設計—

長期メモリを持つエージェントを全社展開すると、いずれ「私に関する記録を消してほしい」という要請が届く。メモリ、ベクトルDB、会話ログ、トレース、評価用データセットのどこに本人の情報が残っているかを即答できなければ、期限内の対応は成立しない。削除は後付けでは実装できず、書き込み時点の設計で決まる。

本記事はAIエージェントガバナンスの技術統制を扱う。メモリの基本設計はエージェントのメモリアーキテクチャ、ログの保全は監査ログのスキーマと改ざん防止を参照してほしい。

削除要請で何が問われるのか

GDPR第17条は、不要になった個人データや違法に処理されたデータなど6つの根拠で、管理者に遅滞ない消去を求めます。日本の個人情報保護法第35条も利用停止等を定めます。

GDPR第17条1項は、目的に対して不要になった場合、同意の撤回、第21条に基づく異議、違法な処理などを消去の根拠に挙げる。同条3項には例外があり、法的請求の確立・行使・防御に必要な場合や、法令上の義務を履行する場合は消去義務が及ばない。

日本の個人情報保護法第35条は、保有個人データが違反して取り扱われている場合などに本人が利用停止等を請求できるとし、理由があるときは違反是正に必要な限度で遅滞なく対応するよう求める。多額の費用を要する場合は代替措置で足りる例外もある。

技術チームが押さえるべき点は2つある。

要請の対象は「メモリのファイル」ではなく、個人データが載りうるすべての保存場所である
例外（法的保存義務、法的請求への備え）に該当するデータは消さずに利用を制限する、という分岐が必要になる

法的な適用判断は法務部門の仕事であり、エンジニアリングは「どこに何があるか」を機械的に答えられる状態を作る。

エージェント基盤でデータが残る場所はどこか

個人データが残る場所は、メモリストア、ベクトルDB、会話ログ、トレース、評価データセット、バックアップの6層です。層ごとに消去手段が異なります。

Claude のメモリツールは、Claude が /memories 配下のファイル操作を要求し、アプリケーション側が実行するクライアントサイド設計である。保存先は利用者側の基盤で決まり、/memories は実ストレージ（ユーザー別ディレクトリやDBのキー）に対応づけるプレフィックスにすぎない。公式ドキュメントも、メモリ有効期限として長期間アクセスのないファイルの定期削除を挙げている。つまり、削除の責任は実装側にある。

層	例	消去の難所
メモリストア	`/memories` 配下のファイル、KVS	本人別に引ける構造でなければ検索不能
ベクトルDB	要約・埋め込み	元文書との対応表がないと特定できない
会話ログ	入出力の全文	監査要件と衝突する
トレース	スパン属性、ツール引数	属性にPIIが混入しやすい
評価データ	ゴールデンデータセット	本番ログ由来の転記が残る
バックアップ	スナップショット	即時消去が困難

消去できる構造を書き込み時にどう作るか

削除を実装可能にする条件は、書き込み時に本人識別子とデータ分類タグを必ず付与することです。後から全文検索で探す設計は、漏れが避けられません。

実装の要点は次の通り。

主体キーを必須にする: メモリへの書き込みハンドラで subject_id（本人を一意に指す内部ID）を強制し、パスを /memories/{tenant}/{subject_id}/... のように構造化する。パス検証は公式の注意どおり、/memories 外への到達を防ぐ正規化とあわせて実装する
書き込み前フィルタ: Claude は機微情報の書き込みを通常は拒むが、保証にはならない。公式も、強い保証が必要なら書き込み前に機微データを除去する検証を勧めている。ハンドラ側で検出・マスクする
派生物の台帳: 要約、埋め込み、評価転記など派生データは source_ids を持たせ、元データ消去時に連鎖削除できるようにする
保持期間の既定値: TTL を最初から付け、期限切れを定期ジョブで消す

``json { "memory_id": "m_8f21", "subject_id": "s_c0a1", "tenant": "acme-jp", "classification": "personal", "derived_from": ["conv_551", "conv_562"], "created_at": "2026-10-01T09:00:00Z", "expires_at": "2027-04-01T09:00:00Z", "legal_hold": false }``

legal_hold が真のデータは消去せず、利用を停止（エージェントの検索対象から除外）する。これが前節の「消さずに制限する」分岐である。

削除要請をどんな手順で処理するか

処理は受付、本人確認、探索、判定、実行、証跡の6段階です。GDPR第12条3項は原則1か月以内の回答を求めるため、探索を自動化しないと期限を守れません。

受付と本人確認: 他人の記録を消す誤削除は、削除漏れと同等の事故になる。本人確認を通してから subject_id に解決する
探索: 6層すべてを subject_id と derived_from でクエリする。層ごとの結果件数を記録する
判定: 法務が legal_hold や例外該当を判断する。判断理由は台帳に残す
実行: メモリストアは delete 相当の操作、ベクトルDBは該当ベクトルの削除と再インデックス、ログは該当エントリのトークナイズ解除（鍵削除によるクリプトシュレッディング）を使う
エージェントへの反映: 実行中のセッションにキャッシュされたメモリを無効化する。消した記録を次のターンで再度参照する事故を防ぐ
証跡: 「何を、いつ、どの層から消したか」を、個人データを含まない形で監査ログに残す

ハッシュチェーン型の監査ログは改ざん防止の都合上、エントリを物理削除できない。ログ本体に個人データを直接置かず、subject_id への参照だけを置き、対応表を消すことで実質的な切り離しを行う設計が現実的である。

モデル本体や学習データへの要請はどう扱うか

EDPB意見28/2024は、AIモデルが匿名と言えるには個人データ抽出の可能性が無視できる程度でなければならないとします。事業者が運用する範囲では、まず推論基盤側のデータを確実に消します。

EDPBの意見28/2024（2024年12月採択）は、AIモデルの匿名性を個別に評価するとし、攻撃やクエリによる個人データ抽出の確率が重要でないほど低いことを求める。また、開発時に違法に処理された個人データは、後続の処理の適法性に影響しうるとも整理している。

基盤モデルの提供元が学習したデータは、利用企業が個別に消去できる範囲にない。企業が管理できるのは、自社で保持するメモリ、検索インデックス、ログ、ファインチューニングデータである。モデル調達時には、提供元の学習データ方針とデータ保持条件をモデル調達とベンダーリスクの技術評価で確認しておく。

規模別の運用上の留意点

大規模運用では、テナントごとに探索対象と保持期間が異なります。要請処理を基盤の共通機能として提供し、各チームに個別実装させない方針が有効です。

数十のエージェントが各自のメモリ実装を持つ組織では、探索APIの規格化が最優先となる。エージェント登録時に「個人データを保持する層」を申告させる
マルチテナント環境では、tenant を探索条件に必須化し、越境削除を防ぐ。分離設計はマルチテナントのエージェント分離設計が前提になる
要請件数と処理日数をKPIとして可視化し、期限超過をアラートにする
全社規模のAI統制の設計は、大企業向けのRDEで支援している

参考

まとめ

削除要請への対応力は、メモリの書き込み設計でほぼ決まる。主体キー、分類タグ、派生物の台帳、TTL、legal_hold の5点を最初から備えれば、6層の探索と連鎖削除を自動化できる。ログ側は個人データを直接持たせず参照だけにして、監査性と消去を両立させる。

Kuuは、エージェント基盤の記録設計と運用統制を大企業向けに支援している。要請対応の棚卸しから始める場合は、RDEまでお問い合わせください。

エージェントメモリの削除要請対応設計——消去対象の棚卸し