- 公開日
AIへ渡した情報は、元の入力だけでなく、会話履歴、保存した要約、検索用の索引、ログ、キャッシュなどに残る場合があります。どこに残るかは、実際のサービスと連携構成によって違います。まず情報の性質と利用目的を分類し、渡す範囲を絞ったうえで、各保存先の目的、閲覧権限、保持条件、削除の確認方法を追います。元データの削除だけで、すべてのコピーが消えたとは判断しません。
分類はラベルを付けるためではない
情報分類の目的は、その情報を誰が、何に、どの条件で使ってよいかを判断することです。公開情報、社内限りの情報、個人に関する情報、接続用の秘密などでは、入力前に確認する内容が変わります。組織に既存の区分があるなら、それと対応させ、AI用に別名を付けただけで管理を終えないようにします。
「顧客問い合わせ」という一つの文書にも、製品の一般的な質問、個人の連絡先、契約固有の条件が混ざることがあります。文書全体を一つのラベルで片付けず、処理に必要な項目を見ます。AIに回答案を作らせたいだけなら、宛先のメールアドレスが不要な場合もあります。
必要最小限の範囲は、短い文章にすることと同じではありません。判断に必要な製品の版や発生条件を削れば、回答が成立しなくなります。一方、目的に関係しない連絡先や履歴を残せば、後の保存先まで管理対象が広がります。必要な情報と、必要でない識別情報を分けることが出発点です。
分類だけで入力許可が決まるわけでもありません。実際のサービスを使ってよいか、誰のアカウントで、どこへ送られ、連携先が何を受け取るかを確認します。「社内資料だからよい」「公開情報だから条件はない」といった単一の判断にしません。
一件の問い合わせを最後まで追う
架空の問い合わせQ1を使って考えます。内容は、顧客名、連絡先、製品の版、発生したエラー、サポート契約の区分です。目的は、担当者が確認するための回答案を作ることとします。実在の顧客情報を入力した例ではありません。
この用途では、製品の版とエラーの内容が回答の材料になります。連絡先は送信担当者が後で管理できるなら、AIへの入力から外します。契約区分は案内できる支援の範囲に関わる場合だけ必要な形で渡します。顧客名を仮の識別子へ置き換えても、他の情報から個人を識別できる可能性があるため、それだけで匿名化済みとは扱いません。
入力後、アプリケーションが会話履歴を保存し、回答案を下書きとして残し、後の検索用にメモを登録する構成だと仮定します。この時点で、Q1の元データとは別に管理する対象が増えています。実際のシステムにその機能がなければ該当する行は不要ですが、確認せずに「保存されない」とは判断しません。
| 段階 | この例で扱うものと目的 | 確認する保持・削除条件 |
|---|---|---|
| 入力 | 回答案に必要な製品版とエラー | 入力先、利用できる情報、送信する項目 |
| 会話・下書き保存 | 担当者の確認と修正 | 保存先、閲覧者、保持の起点と終了条件 |
| 検索用登録 | 後の問い合わせ対応への参照 | 登録範囲、アクセス権、元データとの対応 |
| ログ | 障害調査と操作結果の確認 | 記録項目、閲覧権限、別の保持条件 |
| キャッシュ | 処理結果の再利用 | 更新・失効条件、削除対象との対応 |
| 削除・失効 | 不要な通常利用を終える | 対象一覧、処理結果、残る例外と確認先 |
この表は保存先の棚卸しの例で、すべてのAI製品が同じ場所に同じ期間保存するという説明ではありません。利用者の画面に見える履歴と、連携アプリやサービス側で管理される記録も分けて確認します。自分の画面から消えたことだけでは、別の管理者が扱う保存先まで確認したことにはなりません。
検索用のコピーとログは目的が違う
検索拡張生成、RAGは、関連資料を検索してAIの回答に使う構成です。文書を小さな単位に分け、検索用の表現や索引を作ることがあります。Embeddingは、その検索に用いる数値表現です。これらを導入している場合、元の文書と派生物の対応を保持しておくと、更新や削除の対象を追えます。
OWASPのRAGセキュリティ指針は、元文書の削除や権限変更を、派生する断片、Embedding、索引、キャッシュへ反映する管理を扱っています。同指針はEmbeddingを匿名化されたデータとして扱わないよう注意しています。検索用の派生物だから機密性がなくなるとはみなさず、参照できる利用者や元データとの関係を管理します。
ログは、検索用の知識とは別の目的で保持される記録です。障害の原因や操作結果を確かめるために必要でも、問い合わせ本文を毎回すべて複製する必要があるとは限りません。OWASP Logging Cheat Sheetは、イベント情報を記録する一方で、秘密や不要な機微情報をログへ直接残さない設計を示しています。
Q1の処理なら、問い合わせの識別子、処理時刻、使用した資料版、結果の区分で調査できる部分があります。詳しい内容を保存する必要がある場合は、目的とアクセス権を定めます。通常のログを削除しても、調査時に書き出したコピーやデバッグ用の記録が残ることがあるため、それらも棚卸しの対象です。
保持の条件と削除の完了を分ける
保持期間は、単に「何日」と記すだけでは不足することがあります。入力から数えるのか、問い合わせ完了からなのか、最後に利用した時点からなのかで終了時点が変わるためです。法令、契約、監査、サービスの仕様などによる条件がある場合は、それぞれを確認し、同じ期間が全保存先へ適用されると推測しません。
Q1の対応が終わり、通常利用の目的がなくなったとします。担当者は元データだけでなく、会話履歴、下書き、検索登録、キャッシュへの対応を確認します。ログやバックアップに別の保持条件があるなら、その対象と理由、誰が確認するかを記録します。本稿は具体的な保存日数や個別の削除義務を決めるものではありません。
たとえば削除後の検索でQ1が出なくなっても、それだけでは保存領域から消去されたことまでは分かりません。検索対象からの除外結果と、保存先の削除処理の結果を別々に確認します。逆に旧版が検索されるなら、どの登録やキャッシュが返したのかを調べ、削除対象の対応を見直します。
削除要求を出した状態、サービスが受け付けた状態、削除処理が完了した状態は分けます。確認可能な結果や仕様に照らして、消えた範囲と残る範囲を示します。バックアップの扱いが確認できないなら「全コピー削除済み」と言わず、未確認の保存先として残します。
また、削除と失効は同じとは限りません。検索対象から外しただけなら、新たな回答への利用は止まっても、記録の保存自体は続く場合があります。調査用に制限して保持することと、通常の回答へ利用することを区別し、利用停止の確認をデータ消去の証明に置き換えません。
「モデルの学習に使われない」という条件を確認するときも、会話履歴、ログ、連携先の保存、削除方法を別々に調べます。学習利用の説明だけを根拠に、それ以外の保存がすべてないとは判断しません。詳細は実際に使うプランや機能の公式資料、契約、管理設定で確認します。
同じ作業でも必要な管理は変わる
Q1を実顧客の問い合わせとして扱う場合と、個人に結び付かない架空の研修用データとして扱う場合を比べます。後者なら実顧客への影響や連絡先の削除確認は対象外にできることがあります。ただし、保存先、版、利用権限などの基本的な管理まで省いてよいことにはなりません。
実顧客情報を複数のサービスや検索基盤へ渡す場合は、派生先の追跡や権限管理の負担が増えます。必要のない検索登録や長期保存を増やさないことは、後から管理する対象を絞る設計になります。ただし、負担を減らすために必要な監査記録まで無条件に消すのではなく、目的ごとに扱いを決めます。
まず一件のデータについて、入力先から削除までの対応表を作ると、未確認の保存先が見つけやすくなります。分からない行は空欄のまま放置せず、確認担当と資料を定め、重要な条件が不明なら入力や連携の範囲を絞ります。データの分類、権限の制御、保存期間の運用、削除の確認をつなぐことで、何をAIへ渡してよいかを入力後の扱いまで含めて判断できます。
AIへ渡す前に個人情報を目的に必要な項目へ絞る方法は「個人情報をAIへ渡す前に、目的に必要な項目へ絞る」で解説しています。
発明やノウハウをAIに入力する前の確認は「発明・ノウハウをAIへ入力する前に、秘密性と入力許可を確かめる」、学習利用をオフにしたときに変わる範囲は「AIの学習利用をオフにすると何が変わるか、設定の範囲を確認する」で解説しています。
