LLMアプリのログ設計：プロンプトと応答を残す範囲・伏せる情報・保存期間

先に押さえる前提：モデル提供元の保持と自社ログは別物

提供元がデータをどう扱うかと、自社が何を保存するかは、別々に設計します。

たとえばOpenAIのAPIでは、不正利用監視ログは既定で最大30日保持され、承認を受けた対象顧客はZero Data Retentionなどの制御を利用できます。エンドポイントや機能ごとに扱いが異なり、Responses APIではstoreの設定によってアプリケーション状態の保持も変わります。詳細はOpenAIのデータ管理ガイドを確認してください。

ここで注意したいのは、提供元側の設定を厳しくしても、自社のアプリログに本文を書いていれば、そこに個人情報は残るという点です。学習に使われない設定と、自社ログからの漏えいを防ぐ話は別問題です。

リスクの整理には、OWASPのLLM02: Sensitive Information Disclosureが役立ちます。個人情報、認証情報、事業上の機密が対象として挙げられ、対策にはマスキングや匿名化、アクセス制御、保持ポリシーによる露出期間の限定、機微なやり取りの監査ログが含まれます。

日本で個人情報を扱う場合、ログに氏名やメールアドレスが含まれれば、個人情報として取り扱う必要が生じることがあります。個人情報保護委員会は、2023年6月2日にプロンプト入力を伴う生成AIサービス利用の注意喚起を公表しています。個別のケースが適法かどうかは、この記事では判断できません。必要なら法務や専門家に確認してください。

記録項目の判断表：残す／伏せる／残さない

次の表は、LLMアプリでよく出る項目の振り分け案です。

• リクエストID、タイムスタンプ、扱い：残す、方法・理由：障害時の突き合わせに必須
• ユーザーID、扱い：残す（仮名化）、方法・理由：内部IDやハッシュ。メールアドレスそのものは使わない
• モデル名・バージョン、temperatureなどのパラメータ、扱い：残す、方法・理由：再現調査に必要で、個人情報を含まない
• プロンプトテンプレートのIDと版、扱い：残す、方法・理由：本文ではなく版で追えるようにし、本文はコード管理に任せる
• トークン数、遅延、終了理由、エラーコード、扱い：残す、方法・理由：コストと品質の監視に使う
• ツール／関数呼び出しの名前と成否、扱い：残す、方法・理由：引数の中身は別扱い（下の行）
• ツール呼び出しの引数・戻り値、扱い：伏せる、方法・理由：検索語や顧客IDが入りやすい。必要な項目だけ通す許可リスト方式にする
• ユーザー入力の本文、扱い：伏せる、方法・理由：氏名、連絡先、番号類をマスク後、短期保存。または長さ・言語・分類ラベルだけ残す
• モデル応答の本文、扱い：伏せる、方法・理由：入力の内容を引用することがあるので、入力と同じ基準でマスクする
• RAGで取得した文書の本文、扱い：伏せる、方法・理由：文書ID・チャンクID・スコアだけ残し、本文は元の保管場所で参照する
• ユーザー評価（👍👎）、再生成の有無、扱い：残す、方法・理由：品質改善の手がかりになる
• APIキー、Authorizationヘッダ、Cookie、セッショントークン、扱い：残さない、方法・理由：ログに出す理由がない。ヘッダ出力は許可リストで制限する
• パスワード、カード番号、マイナンバー等、扱い：残さない、方法・理由：入力段階で検知してログ前に落とす
• 添付ファイル・画像の中身、扱い：残さない、方法・理由：ファイルIDとサイズ、種別だけ残す

「伏せる」は、保存前にマスクして短期間だけ保持するか、サンプリングして保持するという意味です。全量保存は避けます。

伏せる処理の置き場所

マスキングは、ログを書く直前の1か所にまとめます。ログ出力ごとに個別に処理すると、新しい機能で漏れが出ます。ログ用の関数を1つ用意し、そこを必ず通す構成が管理しやすいです。

正規表現でマスクできるのは、メールアドレスや電話番号のような型のあるものだけです。氏名や住所、自由記述の機密は取りこぼします。そのため、マスクを過信せず、保存期間を短くして補います。

保存期間の決め方：目的から逆算する

期間は「念のため1年」ではなく、目的から決めます。手順は次の3つです。

1. ログの利用目的を書き出します。 障害調査、品質改善、課金・利用量の確認、セキュリティ監査などです。
2. 目的ごとに、必要な最短期間を決めます。 「問い合わせから何日で調査に着手するか」から考えます。
3. 本文を含むログは、その中で最短の目的に合わせます。 長く必要なものは、本文を落としたメタデータで持ちます。

説明用の例（実際の数字は自社の事情で決めてください）：

• 短期、内容：マスク済みの入出力本文、保存期間の例：7〜14日
• 中期、内容：メタデータ、評価、エラー、保存期間の例：90日程度
• 長期、内容：課金・監査に必要な最小限の記録、保存期間の例：契約や会計上の要件に従う
• 例外、内容：不具合報告のあった事例、保存期間の例：調査完了まで隔離して保存し、終了後に削除

期間を決めたら、保存先に自動削除（TTLやライフサイクル設定）を入れます。手動の運用に頼ると、削除は先送りされます。バックアップや検索用の複製にも同じ期間が及ぶかも確認してください。

もう一点、ユーザーから削除を求められる場合に備え、仮名化したユーザーIDで本文ログを引ける構造にしておきます。ログがバラバラの場所にあると、削除対応で苦労します。

現場で使える：ログ項目レビューの依頼文

設計案を生成AIにレビューさせる場合は、実際のログではなく、架空の値を入れたスキーマを渡します。以下は説明用のテンプレートで、実行して効果を確かめたものではありません。

あなたはLLMアプリのログ設計をレビューする担当です。
以下のログ項目一覧（値はすべてダミー）を、
「残す／伏せる／残さない」の3つに分類してください。
各項目に、理由と、伏せる場合の具体的な処理方法（例：マスク、ID化、
サンプリング）を付けてください。

前提：
- 用途：社内FAQチャットボット（顧客の問い合わせ内容が入る可能性あり）
- ログの利用目的：障害調査、品質改善
- 本文の保存期間の上限：14日

ログ項目：
（ここにフィールド名と、ダミーの例を列挙）

出力：表形式。最後に、見落としやすい項目を3つ挙げてください。

AIの回答はたたき台にとどめます。最終的な振り分けは、ログの閲覧者と削除の運用を知っている人が確認してください。

公開前の点検リスト

• 本番のログを検索し、メールアドレスやトークンらしき文字列が本当に残っていないか確認します。
• ログの閲覧権限が、開発者全員に開いていないか見直します。
• 外部のログ基盤やエラー監視サービスに送られる情報も、同じ表で点検します。
• 提供元の保持期間やプランの条件は変わりうるので、定期的に公式ドキュメントで確認します。