LLMアプリに何を保存する？会話・ログ・評価データのプライバシー設計
LLMアプリは、利用者が入力した会話だけを扱うわけではない。検索した社内文書、道具へ渡した引数、モデルの回答、評価用の複製、監視ログ、キャッシュにも同じ情報が残り得る。チャット画面から履歴を消しても、別の保存先に複製が残れば削除は完了していない。
必要なのは「AIに個人情報を入れない」という注意書きだけではない。どのデータを、何の目的で、どこへ送り、いつ消すかを、処理経路ごとに決めることである。
最初にデータの流れを一本につなぐ
利用者の入力から最終回答までの流れを書き出す。少なくとも、画面、アプリのサーバー、モデル提供者、検索索引、外部道具、監視基盤、分析、評価データ、バックアップを確認する。
各場所について、次の項目を記録する。
- 受け取るデータと送信先
- 処理の目的
- 全文、抜粋、識別子、集計値のどれを保存するか
- 保存期間と削除方法
- 閲覧できる役割
- 他のデータと結び付けられる識別子
モデルAPIだけを確認しても不十分である。エラー追跡サービスが入力全文を保存したり、RAGの索引へ原文が複製されたり、評価ツールへ会話を再送したりする経路がある。データの入口と複製先を一枚で追える状態にする。
保存する前に目的を一つずつ問う
「後で役立つかもしれない」は保存目的にならない。会話を継続するため、障害を調べるため、品質を評価するため、不正利用へ対応するためでは、必要な項目と期間が違う。
会話の継続には直近の文脈が必要でも、分析には全文が不要な場合がある。障害調査では実行ID、構成版、エラー分類で足りるかもしれない。品質評価では匿名化した少数の標本と、人が付けたラベルだけを残せる場合がある。
NIST Privacy Frameworkは、データのライフサイクル、削除、監査ログを方針に沿って管理し、ログにもデータ最小化を取り入れる考え方を示している。収集できる最大量ではなく、目的を達成できる最小量から設計する。
会話履歴とモデル提供者の保存を分ける
アプリが表示する履歴、アプリ側のデータベース、モデルAPI側の保存は別である。画面上の履歴をオフにしても、APIの不正利用監視ログや、会話状態を持つ機能の保存条件が同じとは限らない。
利用するAPIについて、学習への利用、監視ログ、アプリケーション状態、キャッシュ、ファイル、会話オブジェクトの保存条件を機能ごとに確認する。OpenAIのAPI資料でも、不正利用監視ログとアプリケーション状態を分け、エンドポイントや機能によって保持条件と削除方法が異なることを示している。
設定名だけで安全だと判断しない。保存しない設定が、すべての機能と添付データへ適用されるとは限らない。組織の契約、選んだエンドポイント、storeなどの要求時設定、利用する補助機能を一覧にして確認する。
提供者の条件は変わり得るため、記事や設計書へ日付と確認元を残す。法令や契約上の要件がある場合は、一般的な開発資料だけで判断せず、組織の担当者へ確認する。
ログは本文なしでも役に立つ
デバッグのために入力と回答をすべて保存すると、監視基盤が機密情報の大きな複製先になる。まず本文を含まない運用指標を設計する。
例えば、実行ID、時刻、モデルとプロンプトの版、入出力のトークン数、処理時間、状態コード、道具名、文書ID、ガードレール判定、費用区分を記録できる。これだけで、遅延、失敗率、構成別の変化、重複操作の多くを調べられる。
本文が必要な場合は、対象環境、標本率、閲覧権限、保持期間を限定する。メールアドレスや電話番号を伏せても、自由記述には住所、病歴、契約内容、固有の出来事などが残る。正規表現だけで匿名化が完了したと考えず、人の確認や再識別可能性を含めて評価する。
識別子をハッシュに置き換えても、同じ人の行動を長期間結び付けられるなら匿名とは限らない。調査に継続識別が必要かを確認し、目的ごとに別の短期識別子を使う方法を検討する。
評価データは本番ログのコピーにしない
本番の失敗を評価セットへ戻すことは品質改善に役立つが、会話全文をそのまま開発用フォルダへ複製すると、アクセス範囲と保持期間が広がる。
評価例には、失敗を再現するために必要な最小入力、期待する振る舞い、分類、元データの利用条件を持たせる。固有名詞や数値が本質でなければ、意味を保った架空値へ置き換える。文書の権限が重要な例では、実文書をコピーせず、同じ権限構造を持つ試験用データを作る。
元の会話を削除したとき、派生した評価例をどう扱うかも決める。元データとの対応を完全に切るのか、削除要求を伝播できる識別子を保持するのかは、利用目的と方針によって異なる。どちらを選んだかを記録する。
合成データを使えば常に安全になるわけではない。実データを元にモデルへ合成させる過程で、元の内容を外部へ送り、出力に固有情報が残る可能性がある。生成前の最小化と生成後の確認が必要だ。
RAGと埋め込みにも削除経路を作る
文書をRAGへ取り込むと、原本のほかに、分割した断片、埋め込み、メタデータ、検索キャッシュ、バックアップができる。原本の閲覧権限を変更しても、索引側の権限と削除が追従しなければ古い情報が検索される。
原本ID、版、断片ID、索引版を対応付け、原本の更新・削除・権限変更を各複製へ伝える。削除後は代表質問で取得されないことを確認する。埋め込みだけを見て個人情報ではないと断定せず、元データとの対応や再利用範囲を管理する。
検索ログにも質問、文書名、得点が残る。本文を保存しない場合でも、文書IDから機密プロジェクトへの関心を推測できる可能性がある。ログの閲覧権限は、原文書の権限と無関係に広げない。
外部道具へ渡すデータを絞る
エージェントがメール、カレンダー、顧客管理、検索を使うと、会話内容が別のサービスへ送られる。モデルへ道具の全データを見せず、操作に必要な項目だけをアプリ側で選ぶ。
例えば年齢条件の確認なら、生年月日そのものではなく条件を満たすかという結果だけで足りる場合がある。NISTのデータ最小化に関する資料も、完全な属性値ではなく派生した判定値を使う例を示している。
道具の応答も最小化する。顧客検索で一覧全体を返すのではなく、利用者が指定し権限確認した一件だけを返す。エラーへ認証情報や内部の要求本文を含めない。外部送信の前には、送信先、内容、目的を確定し、必要なら人の承認を取る。
保持期間は削除できる仕組みとセットにする
「90日保存」と文書に書いても、自動削除がなく、バックアップや評価用コピーが残れば実施したことにならない。保存先ごとに期限を設定し、削除処理の成功件数と失敗を監視する。
削除対象には、主データ、索引、キャッシュ、添付、ログ、分析テーブル、評価用コピー、バックアップを含める。バックアップを即時に個別削除できない設計なら、復元時に削除状態を再適用する手順と、最終的に消える期限を定める。
保持期間はすべて同じである必要はない。会話状態、障害調査用メタデータ、請求集計、匿名化した品質指標を目的別に分ける。期限を延ばす場合は、新しい目的とアクセス範囲を改めて承認する。
定期的に、設計書の保存先と実際のシステムを照合する。使わなくなったテスト環境、個人のダウンロード、古い評価ファイルは、正式なデータベースより見落とされやすい。
LLMアプリのプライバシー設計は、モデルへ送る文章だけの問題ではない。会話からログ、検索、道具、評価、バックアップまでの複製を追い、目的ごとに最小化し、アクセスと削除を実装することが中心である。保存しない判断も、必要な観測性を保ちながら設計できる。