AIエージェントのデータ保持設計｜5つの決め方

はじめに

AIエージェントを導入すると、会話の本文だけでなく、プロンプト、モデルの応答、ツールの引数と結果、添付ファイル、実行トレースが蓄積される。便利な一方で、「とりあえず全部残す」は運用開始後に問題になりやすい。

長く残せば調査しやすい。しかし、個人情報や機密情報が含まれる可能性も長く残る。短く消せば漏えい時の影響は小さくなるが、事故調査や品質改善に必要な証跡まで失う。

AIエージェントのデータ保持設計は、保存期間を一つ決める作業ではない。データの種類、利用目的、閲覧者、削除方法を分け、業務上の必要性とリスクを釣り合わせる仕事である。

AIエージェントのデータを4種類に分ける

最初に、保存されるものを一つの「ログ」と呼ばない。少なくとも次の4種類に分ける。

1つ目は会話・状態データだ。ユーザーの入力、エージェントの応答、スレッド、メモリ、アップロードファイルが含まれる。次回の実行に必要な状態と、単なる履歴を分ける。

2つ目は実行トレースだ。実行ID、モデルの呼び出し、ツール呼び出しの順番、引数、結果、レイテンシ、エラーなどである。障害調査には重要だが、入力と出力の全文を含めるかは別に決める。

3つ目は監査証跡だ。誰が、どの権限で、どの対象へ、何を実行し、承認されたかを示す。業務上の責任や変更履歴を説明するためのもので、開発者向けの詳細トレースとは目的が違う。

4つ目は評価・改善用データだ。正解例、失敗例、評価結果、匿名化したサンプルなどを含む。改善のために残したいデータでも、元の顧客情報を無期限にコピーしてよい理由にはならない。

Microsoft Foundryの公式資料でも、エージェントの状態データとトレースの保存先・保持設定は別の論点として説明されている。会話状態を削除しても診断トレースが残る、またはその逆が起こり得る。種類を分けて台帳にすることが出発点だ。

保持期間を決める5つの判断

1. 何のために残すか

「将来役立つかもしれない」ではなく、利用目的を一文で書く。例えば、会話データは問い合わせへの継続対応、実行トレースは障害調査、監査証跡は業務上の事後確認、評価データは品質改善という具合だ。

一つのデータを複数目的で使うなら、目的ごとに必要な粒度を分ける。障害調査に実行IDとツール名だけが必要なら、顧客の本文まで長期保存しない。目的がなくなった複製は、原本と同じ期間を残す理由がない。

2. どの情報を最小限にするか

NISTの生成AIプロファイルは、データの収集・保持方針を設け、個人を特定できる情報の漏えいリスクを扱うことを推奨している。ログにも最小限収集の原則を適用する。

保存前に、次のように分ける。

• 常に必要: 実行ID、時刻、結果、エラー分類、対象ID
• 条件付きで必要: ツールの引数、応答の要約、参照文書のID
• 原則保存しない: パスワード、アクセストークン、カード番号、不要な会話全文
• 期限を短くする: 個人情報を含む入力、添付ファイル、デバッグ用の詳細ペイロード

本文を保存する場合も、マスキング済みの検索用データと、アクセス制限した原本を分離する。ログを増やすことが品質向上とは限らない。調査に必要な証拠を、再現可能な参照IDで結ぶ設計が重要だ。

3. 誰が見られるかを決める

保存期間だけ決めても、誰でも閲覧できればリスクは減らない。運用担当者は成否とエラー分類、セキュリティ担当者は操作と権限、監査担当者は承認と変更履歴を見るなど、役割ごとに閲覧範囲を分ける。

テナントや顧客が複数ある場合は、検索時の境界も受入条件にする。別テナントの実行IDを知っていても参照できないこと、ログを閲覧した事実自体も記録されることを確認する。

ツールの引数に顧客データが入る場合、開発環境へコピーしない。開発者が本番トレースを見られることと、モデル改善用データへ転用できることは同じではない。利用目的と権限を結びつける。

4. 削除の起点と例外を決める

削除は「保存期間を過ぎたら消す」だけでは足りない。アカウント解約、契約終了、本人からの請求、業務案件の完了、インシデント対応終了など、削除を始める起点を列挙する。

一方、法令や契約、係争対応のために一時保全が必要な場合もある。保全の開始者、対象、期限、解除者を記録し、例外を無期限の保管へ変えない。削除済みかを確認できる最小限のメタデータだけ残す方法もある。

削除は論理削除だけでよいのか、バックアップや検索インデックス、ベクトルストアまで対象にするのかを確認する。Microsoftの公式FAQでも、会話やアップロードファイルなどの状態データは明示的に削除するまで残るサービスがあると説明されている。サービスの初期設定を自社方針と取り違えない。

5. どう検証するかを決める

方針は、実際に消えることを試して初めて運用条件になる。最低限、次のテストを用意する。

• 保持期限を過ぎた会話と添付ファイルが検索結果から消える
• トレースのマスキング対象が原本・バックアップ・エクスポートに残らない
• 削除済みの実行IDから別テーブルの本文が復元できない
• 保全中のデータは消えず、解除後に通常の削除へ戻る
• 別の担当者やテナントから検索できない
• 削除ジョブの成功・失敗・再実行が監査証跡に残る

削除ジョブが失敗したときに、未削除を成功扱いにしないことも大切だ。対象件数、失敗理由、再試行、完了時刻を残す。データ保持の受入テストは、保存機能のテストではなく、保存しない機能のテストでもある。

規制・標準の資料をそのまま期限にしない

EU AI Actの第12条は、高リスクAIシステムについて、ライフサイクルを通じた自動イベント記録と、目的に応じた追跡可能性を求める。ログを残す必要があるケースはあるが、すべてのAIエージェントに同じ保存期間を定める条文ではない。

同規則では、提供者や導入者の管理下にあるログの6か月保存が別の条文で扱われる。対象業務、役割、適用法令を確認してから、自社の保持期間へ落とす必要がある。

NISTの資料も、AIログに一律の保存年数を示すものではない。保持義務、調査の必要性、プライバシーリスク、削除可能性を踏まえて方針化する位置づけだ。公的資料の数字を、そのまま全社のデフォルト値にしない。

要件定義から運用までの成果物

AIエージェントを発注・開発するときは、保持方針を別紙の運用ルールで終わらせない。業務ごとに次の成果物をつなぐ。

監査証跡の項目設計は、AI社員の作り方｜監査ログで残す7項目も参考になる。実行の成否だけでなく、依頼主体、権限、根拠、承認、結果をつなぐ考え方だ。

また、AIエージェントの受入テストと保持・削除のテストを組み合わせれば、動くことだけでなく、残る情報と消える情報まで検収できる。

Atsumellの視点

AIエージェントの導入では、できることを増やす話が先行しやすい。しかし、顧客データを扱う仕事ほど「何を残さないか」を先に決めたほうが、運用責任とコストを説明しやすい。

保持期間は、セキュリティ部門だけの設定値ではない。業務の完了条件、顧客との契約、法務上の保全、障害調査、評価改善を一つのデータフローに置き、誰がいつ削除を確認するかまで決める。

業務フロー、権限、実行ログ、削除条件がまだ分かれているなら、AtsumellではAI業務整理ツール「Kakusill」を使って仕様化を支援している。まずは一つの業務を選び、4種類のデータと5つの判断を保持台帳に書き出すところから始めよう。