AI利用ログに残す項目と残さない情報

この記事で分かること

AI利用ログに残すべきメタデータ
ログへ複製しない方がよい情報
JSON Lines形式の匿名化・仮名化ログ例
保管期間、アクセス権、削除を設計する手順

注意： 入力や出力を全文保存すると、ログ自体が個人情報・営業秘密・認証情報を集めた新しい機密データになります。「監査のため」という理由だけで無期限に全文を残さないでください。

先に結論

AI利用ログの目的は、会話をすべて再現することではありません。誰が、どの承認済み用途で、どの種類の情報を扱い、どのモデルや設定を使い、何を実行し、誰が承認したかを追跡できれば、多くの監査と事故調査に対応できます。

入力・出力の本文は原則として業務システム側へ置き、AIログには分類、参照ID、ハッシュ、結果、承認を記録します。本文が必要な例外では、目的、閲覧者、保管期間を別途承認します。

AI利用記録を最小化して監査へつなぐ流れ 記録目的を先に定め、項目を最小化し、承認を追跡したうえで期限到来時に削除する流れを示す。

公式資料から分かることと編集部の判断

NIST AI RMF 1.0は、AIリスクをGovern、Map、Measure、Manageの4機能で継続的に扱う任意の枠組みです。生成AI向けのNIST AI 600-1では、テスト・評価・検証の履歴を保つ文書保持方針、AIシステムの棚卸し、インシデント対応、継続監視などが例示されています。

個人情報保護委員会は、個人情報を生成AIへ入力する際に利用目的の範囲を確認し、サービスの規約やプライバシーポリシーを踏まえて判断するよう注意喚起しています。

これらは「すべての会話全文を保存せよ」と求めるものではありません。以下は、追跡可能性とデータ最小化を両立するためのAI活用ナビの実装案です。

最初にログの目的を4つまでに絞る

ログ項目は、目的から逆算します。

事故調査：どのデータ区分が、どの外部サービスや機能へ渡ったかを確認する。
承認確認：送信、公開、削除などを誰が承認したかを確認する。
運用品質：失敗率、差し戻し、禁止用途の発生を把握する。
再現補助：モデル、設定、参照資料の版を特定する。

「将来使うかもしれない」は保存目的として広すぎます。利用目的を説明できない項目は収集しません。

残す項目

区分	推奨項目	目的
識別	event_id、trace_id、時刻	一連の処理を追跡する
利用主体	仮名化した利用者ID、部署・役割	責任範囲を確認する
用途	承認済みuse_case_id、業務システム名	禁止用途や目的外利用を確認する
AI条件	ベンダー、モデル識別子、設定版	変更前後を比較する
入力	データ区分、件数、サイズ、参照ID、必要時のハッシュ	本文を複製せず対象を特定する
出力	出力区分、採用・修正・却下、参照ID	業務上の扱いを確認する
操作	ツール名、操作種別、対象区分、成否	外部作用を追跡する
承認	要否、判断、承認者ID、時刻、理由コード	人の判断を説明する
運用	エラーコード、ポリシー判定、削除予定日	障害・保持を管理する

利用者IDをハッシュ化しただけでは、同じ人物の行動を結び付けられるため、必ずしも匿名情報にはなりません。対応表や追加情報と組み合わせて個人を識別できる場合は、仮名化された識別子として慎重に管理します。

原則として残さない情報

プロンプト、添付、出力の全文
氏名、住所、電話番号、メールアドレスなどの直接識別子
要配慮情報や人事評価の詳細
パスワード、セッショントークン、秘密鍵、認証用URL
顧客データやソースコードの無加工コピー
モデルの内部推論を称する長文
URLのクエリ部分などに含まれる秘密情報
監査目的に不要な端末情報や位置情報

禁止語の検出結果を残す場合も、該当本文ではなく「credential_pattern_detected」のような理由コードにします。

JSON Lines形式のログ例

1行が1イベントになるJSON Linesは、追記、転送、期間指定の削除を設計しやすい形式です。次は架空データです。

{"schema_version":"1.0","event_id":"evt_01JX7A","trace_id":"trc_8f21","occurred_at":"2026-07-29T03:15:22Z","actor_id":"usr_p_7c91","actor_role":"support_editor","use_case_id":"faq-draft-v2","system":"support-portal","provider":"approved-ai-vendor","model_id":"model-family-2026-07","policy_version":"ai-policy-4.2","input":{"classification":"internal","record_count":3,"bytes":4820,"source_ref":"kb:article:1842@v7","content_stored":false},"output":{"classification":"internal","destination":"draft_only","decision":"edited","content_stored":false},"tool":{"action":"create_draft","target_ref":"ticket:T-1048","result":"success"},"approval":{"required":true,"decision":"approved_after_edit","reviewer_id":"usr_p_2ab4","reason_code":"FACTS_VERIFIED"},"retention":{"delete_after":"2027-01-29"}}
{"schema_version":"1.0","event_id":"evt_01JX7B","trace_id":"trc_8f22","occurred_at":"2026-07-29T03:18:10Z","actor_id":"usr_p_a514","actor_role":"analyst","use_case_id":"unregistered","policy_version":"ai-policy-4.2","input":{"classification":"restricted","content_stored":false},"output":{"decision":"blocked","content_stored":false},"tool":{"action":"none","result":"not_executed"},"approval":{"required":false,"decision":"not_applicable","reason_code":"USE_CASE_NOT_APPROVED"},"retention":{"delete_after":"2026-10-27"}}

本文の代わりにsource_refを使う場合、参照先にもアクセス制御と保持期限が必要です。ハッシュを使う場合は、元データの存在確認には役立っても、内容復元や正当性を保証するものではない点に注意します。

導入手順

1. イベント単位を決める

会話単位ではなく、生成、ツール要求、承認、実行、削除を別イベントにします。同じtrace_idで結び付けると、どこで止まったか確認できます。

2. 収集前にマスキングする

ログ基盤へ送った後で消すのではなく、発生元で秘密や本文を落とします。例外的に本文を保存する経路は、通常ログと別の保管場所・権限にします。

3. 保管期間を目的別に決める

すべてを同じ期間にしないでください。次は法定期間ではなく、検討開始用の例です。

ログ	保管例	見直し条件
ブロック・エラーの運用ログ	90日	障害分析が完了したら短縮
通常利用の監査メタデータ	180日	監査周期と整合させる
重大操作の承認記録	1年	契約・法令・社内規程を優先
調査中の事故ログ	事案終了まで保全	終了後に通常ルールへ戻す

4. 権限を分離する

一般管理者が会話内容を自由に検索できる構成を避けます。運用担当、監査担当、事故対応担当へ必要な範囲だけ付与し、閲覧と出力も記録します。

5. 期限削除を自動化し、結果を検証する

delete_afterを基に削除ジョブを実行し、稼働系、検索インデックス、分析コピー、バックアップの扱いを定義します。削除件数、失敗件数、最古レコードの日付を定期確認します。

期待結果と確認方法

次のテストを検証環境で行います。

ダミーの氏名、メールアドレス、秘密文字列を入力します。
通常生成、ブロック、承認、差し戻し、ツール失敗を一度ずつ発生させます。
ログにevent_id、用途、データ区分、判断、結果、削除予定日があるか確認します。
ダミー本文や秘密文字列がログ検索で見つからないことを確認します。
権限のない利用者がログを閲覧・出力できないことを確認します。
期限を短くした試験レコードが削除され、検索結果や派生テーブルにも残らないことを確認します。

必要なメタデータは見つかり、秘密の本文は見つからない状態が成功です。

失敗しやすい点・利用条件・安全上の注意

デバッグ設定で一時的に全文ログが有効になったままになる
アプリでは消しても、監視サービスや分析基盤へコピーが残る
URL、例外メッセージ、ツール引数から秘密が漏れる
仮名IDを匿名情報と誤認し、広い閲覧権限を与える
改ざん防止を理由に、削除不能な場所へ個人情報を無期限保存する
モデル名だけを残し、システム指示やポリシーの版を識別できない

事故調査で本文保全が必要になった場合は、通常ルールを黙って停止せず、対象、理由、保全開始日、解除条件、承認者を記録します。

AI活用ナビの判断

AI活用ナビの判断： AI利用ログは「全文を多く残すほど安全」ではありません。標準ログはメタデータ中心とし、本文保存は対象事案と期間を限定した例外にする設計を推奨します。

監査可能性は、本文量よりも、用途ID、データ区分、モデル・ポリシー版、操作、承認、削除予定日が一貫して記録されているかで決まります。

確認日と公式情報

確認日：2026年7月29日

NIST AI Risk Management Framework：AI RMF 1.0、Playbook、生成AIプロファイルへの案内を確認。AI RMF 1.0は改訂作業中と表示されています。
NIST AI 600-1：文書保持、システム棚卸し、インシデント対応、監視に関する推奨事項を確認。
生成AIサービスの利用に関する注意喚起等：個人情報の利用目的とサービス条件の確認に関する注意点を確認。

保持期間は業種、法令、契約、就業規則、事故対応方針で変わります。本記事の期間例をそのまま法定期間として使用しないでください。

PRIMARY SOURCES