AIの利用ログ・監査ログの残し方｜「なぜこう答えた？」に後から答える設計
月曜の朝、上司からこんなメッセージが届きます。
「お客様から、問い合わせ窓口のAIに"返品はできません"と言われたって連絡が来てる。うちは返品できるよね？ 何を聞かれて、何て答えたのか見せてもらえる？」
管理画面を開いて、ログを探します。でも、残っているのは「200 OK」と処理時間だけ。お客様が何を書いたのかも、AIが何を返したのかも、そのときどのプロンプトで動いていたのかも、分かりません。
「たぶん、こういう流れだったと思います」としか言えない。この、足元が見えない心細さ。AI機能を本番に出した人なら、一度は想像したことがあるはずです。
先に言っておくと、ここで記録が足りなかったのは、あなたの手落ちとは限りません。AI機能は、ふつうのログ設計の感覚のままだと、肝心なところが残らない作りになりやすいんです。この記事では、AIの利用ログ・監査ログを「後から説明できる」最小限の形で残す設計を、一緒に整理します。
結論：AIの利用ログ・監査ログは、1回のAI呼び出しごとに①誰が・いつ（呼び出しの身元）②何を渡したか（入力と、プロンプト・モデルの版）③何が返ったか（出力と、止めた・ぼかした等の結果）④人がどうしたか（採用・修正・却下）の4点を、同じIDでつないで残します。あわせて、残さないもの（パスワード・不要な個人情報）と、誰が見られるか・いつ消すかを先に決めておきます。全部を完璧にしなくて大丈夫です。まずは「プロンプトとモデルの版」と「人がどうしたか」の2つを今のログに足すだけで、「なぜこう答えた？」に答えられる場面がぐっと増えます。
一度に全部そろえなくて大丈夫です。 まずは、いまのAI機能の呼び出し1回ぶんで、何が残っていて、何が残っていないかを見てみるところから始めましょう。
AIの利用ログが「残っているのに、たどれない」のはなぜか
ふつうのWebアプリなら、「同じ入力なら同じ結果」が前提です。だから、エラーと処理時間さえ残っていれば、あとは手元で再現して原因を追えます。
AI機能は、この前提が崩れます。
- 同じ入力でも、答えが変わる：AIの出力にはゆらぎがあります。手元で同じ質問を投げても、あの日と同じ答えが返るとは限りません。詳しくはAIの回答が日によって変わる｜再現性のなさと付き合う型へ。
- 答えを決める材料が、コードの外にある：プロンプト（AIへの指示文）、参照させた社内文書、モデルの版。どれかが変われば答えも変わりますが、これらはアプリのログに出てこないことが多いです。
- 最後に決めたのが、AIなのか人なのか分からない：AIの下書きを担当者が直して送ったのか、そのまま送ったのか。ここが残っていないと、責任の線が引けません。
つまり、AI機能でたどれなくなる原因は、ログの「量」ではなく「何で答えが決まったか」が残っていないことにあります。障害調査のためのアプリログ（AIにログ出力の不足を指摘させる）や、効果を測るための集計ログ（AI機能の効果測定）とは、少し目的が違うんです。
ここで言う監査ログは、「あの1件について、あとから第三者に説明できる記録」のこと。犯人探しの道具ではなく、チームとお客様を守るための記録だと考えてください。
具体例——こんな場面で、記録の有無が分かれる
たとえば、こんな場面です。
- 問い合わせ窓口のAIが、誤った案内をした：お客様に何を返したかが残っていれば、すぐ訂正の連絡ができます。残っていなければ、「おそらく」で謝るしかありません。
- 社内の規程検索ボットが、古い規程を答えた：どの文書を参照して答えたかが残っていれば、「改訂前の文書が検索対象に残っていた」と原因まで届きます。
- AIの下書きをもとに、見積もりメールが送られた：担当者が直したのか、そのまま送ったのかが分かれば、「AIの誤り」なのか「確認の手順」の問題なのかを、落ち着いて切り分けられます。
- プロンプトを先週直した：それ以降に回答の雰囲気が変わったと言われたとき、どの版のプロンプトで答えたかが残っていれば、前後を比べられます。
どれも、大きな事故になる前の小さな「あれ？」です。記録があれば、その「あれ？」を数十分で閉じられます。記録がないと、何日も「たぶん」が続きます。
残す項目は「誰が・何を渡し・何が返り・人がどうしたか」の4点
AIの1回の呼び出しごとに、次の4点を残します。ポイントは、4点を同じID（リクエストID）でつなぐことです。別々の場所に残っていても、IDでつながっていれば1本の線としてたどれます。
① 誰が・いつ（呼び出しの身元）
- リクエストID（この1回を指す番号）
- 日時（タイムゾーンも含めて）
- 利用者のID（名前やメールアドレスではなく、社内の利用者IDで十分なことが多いです）
- どの画面・どの機能から呼ばれたか（「問い合わせ窓口」「規程検索」など）
② 何を渡したか（入力と、答えを決めた材料）
- 利用者の入力（後述の「残さないもの」は伏せたうえで）
- プロンプトの版（プロンプト本文をそのまま毎回残すより、版番号を残して本文は別で管理するほうが扱いやすいです。管理の始め方は本番プロンプトのバージョン管理へ）
- モデル名と版（提供元がモデル名に日付や版を含めている場合は、それもそのまま）
- 温度などの主な設定値
- 参照させた文書の識別子（RAG（社内文書を検索してAIに渡す仕組み）を使っているなら、どの文書のどの版を渡したか）
③ 何が返ったか（出力と結果）
- AIの出力（利用者に見せた形のまま）
- 結果の種類：ふつうに回答した／回答を断った／タイムアウトした／安全フィルタで止めた、など
- 使ったトークン数（AIが処理した文字量の単位）と処理時間
④ 人がどうしたか（採用・修正・却下）
- 担当者がAIの出力をそのまま採用したか、直したか、使わなかったか
- 直した場合は、最終的に外へ出した内容（または、その記録の場所）
- 確認した人の利用者ID
①〜③は、AIを呼び出す処理の前後で自動で残せます。④だけは、画面のボタン（「この下書きを使う」「直して送る」「使わない」）と記録を結びつけるひと手間が要ります。ただ、ここがあるかどうかで、「AIが間違えた」と「確認の流れで漏れた」を分けられるかが決まります。手間に見合う、いちばん効く1行です。
残さないもの・見られる人・消す時期を先に決める
ログは、たくさん残すほど安心……とは限りません。AIの入力欄には、利用者が思いがけないものを貼りつけます。残したログそのものが、守るべき情報の置き場所になるからです。
だから、残す項目と同じくらい、次の3つを先に決めておきます。
- 残さないもの：パスワード、APIキー、クレジットカード番号などは、ログに書く前に伏せ字にします（マスキング）。個人情報も、調査に要らないものは残しません。どこまでをAIに渡してよいかの線引きは社内データをAIに渡す前の線引きにまとめています。
- 見られる人：監査ログは、ふつうのアプリログより閲覧できる人を絞ります。あわせて、監査ログを誰が見たかも記録しておくと、あとで説明しやすくなります。
- 消す時期：保存期間を決めて、過ぎたら自動で消えるようにします。社内規程や契約、業界のルールで保存期間が決まっている場合は、それに合わせます。決まっていなければ、法務や情報システムの担当と相談して決めましょう。ここは開発者がひとりで抱えなくていい部分です。
もうひとつ、利用者への伝え方も忘れずに。「入力内容は品質向上と問い合わせ対応のために一定期間記録します」のように、記録していることを利用規約や画面の注意書きで伝えておくと、後から気まずくなりません。文言は、法務や担当部署と一緒に決めてください。
AIに設計の抜けを確認してもらうプロンプト
いまのログ設計に抜けがないか、AIに壁打ちしてもらうのもひとつの手です。設計の要点だけを渡して、4点の観点で足りないものを挙げてもらいます（実際のログデータや個人情報は貼らずに）。
社内向けの業務システムに、AIの回答機能を組み込んでいます。
後から「この1件で、AIが何を受け取り、何を返し、人がどうしたか」を
説明できるよう、利用ログ・監査ログの項目を見直したいです。
【いま残している項目】
- リクエストID、日時、利用者ID、HTTPステータス、処理時間
【前提】
- 利用者の入力には、個人情報が含まれることがある
- プロンプトはリポジトリで版管理している
- AIの出力は、担当者が確認してから外部に送る
次の4つの観点で、足りない項目と、残さないほうがよい項目を挙げてください。
1. 誰が・いつ 2. 何を渡したか 3. 何が返ったか 4. 人がどうしたか
最後に、保存期間とアクセス権について、関係部署に確認すべき論点を挙げてください。返ってきた案は、そのまま採用せず、自分たちの業務で本当に後から見る場面があるかで1つずつ選びます。保存期間などの決めごとは、AIの答えを結論にせず、社内の担当と決めてください。
明日からやること（まずこの3つ）
- 呼び出し1回ぶんのログを、実際に開いて眺める：上の4点のうち、残っているもの・残っていないものに印をつけます。10分あれば終わります。
- 「プロンプトの版」と「モデル名」を1行足す：AIを呼び出す処理の直前に、版とモデル名をログへ出すだけです。いちばん小さな変更で、いちばん「なぜ？」に効きます。
- 伏せ字にするものを、チームで3つだけ決める：パスワード、APIキー、カード番号など。ログに書く前に伏せる処理を入れる場所も、あわせて決めます。
「人がどうしたか（④）」は、画面の改修が要るので、次のスプリントの候補にメモしておくくらいで十分です。
AIの利用ログ・監査ログ設計チェックリスト
全部に○が要るわけではありません。いまのAI機能に関係するところだけで大丈夫です。
① 誰が・いつ
- 1回の呼び出しごとにリクエストIDを振り、4点の記録をそのIDでつないでいるか
- 日時はタイムゾーンを含めて残しているか
- 利用者は、名前ではなく利用者IDで残しているか
- どの画面・機能からの呼び出しかが分かるか
② 何を渡したか
- プロンプトの版番号を残しているか
- モデル名と版を残しているか
- 参照させた文書（RAGの検索結果）の識別子と版を残しているか
- 入力は、伏せるべきものを伏せてから残しているか
③ 何が返ったか
- 利用者に見せた形のまま、AIの出力を残しているか
- 回答・拒否・タイムアウト・フィルタ停止などの結果の種類を区別しているか
- トークン数と処理時間を残しているか
④ 人がどうしたか
- 担当者が採用・修正・却下のどれをしたかを残しているか
- 外に出した最終版と、確認した人が分かるか
⑤ 守り方
- 監査ログを見られる人を絞り、閲覧の記録も残しているか
- 保存期間を決め、過ぎたら自動で消えるようにしているか（期間は社内の担当と合意済みか）
- 記録していることを、利用者に伝えているか
この記事のまとめ
AI機能は、同じ入力でも答えが変わり、答えを決める材料がコードの外にあります。だから、ふつうのログのままだと、いちばん聞かれる「なぜこう答えた？」に答えられません。
残すのは、誰が・何を渡し・何が返り・人がどうしたかの4点。それを同じIDでつなぐ。そして、残さないもの・見られる人・消す時期を、先に決めておく。全部を一度にそろえなくても、プロンプトの版とモデル名を1行足すだけで、明日からの「たぶん」はひとつ減ります。
ログの設計は、目立たない仕事です。うまくいっている間は、誰にも気づかれません。 でも、いつか「あの1件、何があったの？」と聞かれた日に、あなたが残した1行が、お客様とチームを守ります。まずは今日、ログを1回ぶん開いてみるところから始めてみましょう。
よければ、こちらも
- AI機能の効果測定｜導入後に見るログと指標の設計
- AIにログ出力の不足を指摘させる｜障害調査で困らない設計
- 本番プロンプトのバージョン管理｜変更で壊さない運用の始め方
- 社内データをAIに渡す前の線引き｜情報漏えいを防ぐ型
- AI機能の応答品質を継続監視する｜劣化に気づく評価の仕組み
- AI活用の失敗を上に報告する｜責められず次へ繋ぐ伝え方