「社員が生成AIで何をしているのか確認できるようにしたい」
「AIが間違った回答をしたとき、原因を追跡できるようにしたい」
「RAGがどの文書を参照したのか記録したい」
「AIエージェントが実行した処理を監査できるようにしたい」
企業で生成AIを本格的に利用するようになると、重要になるのが生成AIのログ管理です。
例えばAIが、
顧客情報を検索
↓
過去の問い合わせを取得
↓
回答案を生成
↓
CRMを更新
したとします。
問題が発生した場合、
誰が実行したのか
AIへ何を依頼したのか
どのデータを参照したのか
どのAIモデルを使ったのか
どのToolを実行したのか
人が承認したのか
が分からなければ、原因調査が難しくなります。
そのため企業向けAIシステムでは、
AIを利用できる
だけではなく、
AIが何をしたのか
後から確認できる
ことが重要です。
経済産業省の「AI事業者ガイドライン 第1.2版」でも、AIを一度導入して終わるのではなく、運用状況を継続的に確認しながらリスク管理・ガバナンスを行う考え方が示されています。
この記事では、生成AIシステムで残しておきたいログ、RAG・AIエージェント特有のログ、保存期間、個人情報への配慮、監査方法まで解説します。
生成AIのログ管理とは
生成AIのログ管理とは、
誰が
いつ
どのAI機能を
どのように利用し
どのような結果になったか
を記録・管理することです。
通常のWebシステムでも、
ログイン
データ更新
エラー
APIアクセス
などのログを残します。
生成AIシステムでは、さらに、
利用モデル
プロンプト
AI出力
RAG検索結果
Tool実行
人による承認
など、AI特有の情報が追加されます。
なぜ生成AIではログ管理が重要なのか
主な理由は5つあります。
1．問題発生時の原因調査
例えば、
AIが間違った契約内容を回答した
場合です。
原因として、
AIモデルが誤回答した
RAGが違う文書を取得した
古い文書を参照した
ユーザーの質問が曖昧だった
システム側から間違ったデータを渡した
などが考えられます。
ログがあれば、どの段階で問題が発生したか確認できます。
2．情報漏えいの調査
例えば、
権限のない社員に
人事情報が表示された
という問題が発生した場合、
誰が
何時に
何を質問し
どの文書が検索され
何が回答されたか
を確認する必要があります。
3．AI精度の改善
例えば問い合わせAIで、
回答が使えなかった
ケースだけを集めれば、改善材料になります。
4．利用状況の把握
例えば、
月間利用者数
部署別利用数
AI機能別利用数
API利用量
を確認できます。
5．監査・ガバナンス
企業として、
AIがどのように利用されているか
を説明できる状態にします。
NISTのAI RMFも、AIリスクを組織として継続的に管理し、AIシステムの設計・導入・利用・評価を通じて状況を把握する枠組みを示しています。
生成AIログは3種類に分けて考える
ログを一つにまとめて考えるより、
アプリケーションログ
AI実行ログ
監査ログ
に分けると整理しやすくなります。
アプリケーションログ
通常のWebシステムと同じログです。
例えば、
APIエラー
ログイン
処理時間
HTTPステータス
DBエラー
などです。
AI実行ログ
AIがどのような処理を行ったか記録します。
例えば、
モデル
プロンプト
AI出力
RAG検索結果
Tool実行
Token使用量
処理時間
です。
監査ログ
重要な操作を後から追跡するためのログです。
例えば、
ユーザー追加
権限変更
APIキー作成
設定変更
重要データ更新
AIによるTool実行
などです。
OpenAIのAPI Platformにも組織管理向けのAudit Logs APIがあり、ユーザー・プロジェクト・APIキー・サービスアカウントなどの作成・変更・削除といった管理イベントを監査できます。これはAPIのプロンプト・回答などを記録するアプリケーションログとは別のものです。
生成AIシステムで残しておきたいログ
実際には、次のような情報を検討します。
1．ユーザー情報
最低限、
user_id
を記録します。
例えば、
user_id:
sales_001
です。
氏名そのものではなく、内部ユーザーIDを利用する方法もあります。
これによって、
誰がAIを利用したか
を確認できます。
2．実行日時
2026-07-30 10:32:15
のような時刻です。
問題が発生した場合、
いつ起きたか
を追跡できます。
タイムゾーンも統一しておくと管理しやすくなります。
3．利用したAI機能
例えば、
customer_summary
email_draft
internal_search
invoice_extraction
などです。
単に、
AIを利用した
ではなく、
どのAI機能を利用したか
を記録します。
4．利用モデル
例えば、
model:
model-A
です。
生成AIではモデルを変更すると結果も変化する可能性があります。
そのため、
同じ質問なのに
以前と回答が違う
場合、モデル変更が原因か確認できます。
5．プロンプトバージョン
企業システムでは、ユーザー入力だけでなくシステム側のプロンプトも利用します。
例えば、
prompt_version:
customer-summary-v12
とします。
プロンプトを、
v11
↓
v12
へ変更した後に精度が低下した場合、比較できます。
6．ユーザー入力
例えば、
ABC社との過去の商談を要約して
です。
ただし、
すべての入力を
そのまま永久保存する
必要はありません。
個人情報や機密情報が含まれる可能性があるため、後述する保存方針を決めます。
7．AI出力
例えば、
ABC社は2026年4月から
在庫管理システム導入を検討しています。
という回答です。
AI出力を保存すると、
どの回答が問題だったか
を確認できます。
ただし出力にも個人情報・機密情報が含まれる可能性があります。
8．実行結果
例えば、
status:
success
または、
status:
error
です。
エラーなら、
timeout
rate_limit
invalid_input
tool_error
なども残します。
9．処理時間
例えば、
latency_ms:
2350
です。
生成AIは通常APIよりレスポンス時間が長くなる場合があります。
ログを集計すると、
平均2秒
↓
最近5秒になっている
などの変化を検出できます。
10．利用量・Token数
API型AIなら、
input_tokens
output_tokens
などを記録するとコスト分析に利用できます。
例えば、
feature:
document_summary
平均入力:
20,000 tokens
と分かれば、
長すぎる文書を
そのままAIへ渡している
ことに気付けます。
AIログの基本例
例えば次のようなイメージです。
{
"request_id": "req_abc123",
"user_id": "sales_001",
"timestamp": "2026-07-30T10:32:15+09:00",
"feature": "customer_summary",
"model": "model-A",
"prompt_version": "v12",
"status": "success",
"input_tokens": 4250,
"output_tokens": 620,
"latency_ms": 2350
}
実際にはシステム要件に応じて項目を増減します。
request_id・trace_idを付ける
特におすすめなのが、
request_id
または、
trace_id
です。
例えば一回のAI処理で、
Web画面
↓
バックエンド
↓
RAG
↓
生成AI
↓
CRM API
と複数システムを通るとします。
すべてに同じ、
trace_id:
trace_00123
を付けます。
すると、
このAI回答が
どのAPI処理とつながっていたか
を追跡できます。
RAGでは何をログに残す？
RAGでは通常のAIログだけでは不十分です。
重要なのが、
何を検索したか
です。
例えば社員が、
経費精算の期限は？
と質問します。
RAGが、
経費規程2026.pdf
社員マニュアル.pdf
を検索したとします。
最低限、
検索クエリ
取得文書ID
取得チャンクID
検索スコア
文書バージョン
などを記録します。
RAGログの例
query:
経費精算の期限は？
retrieved_documents:
- expense-policy-2026.pdf
- employee-manual.pdf
top_chunks:
- expense-policy-2026:chunk_32
- employee-manual:chunk_105
これによって、AIが間違えた場合、
正しい文書を検索したが
AIが誤回答した
のか、
そもそも検索結果が間違っていた
のかを切り分けられます。
文書バージョンも残す
例えば、
経費規程2025
経費規程2026
が存在した場合です。
回答時に、
document_version:
2026-04-01
などを記録しておけば、
古い規程を参照していた
ことを確認できます。
AIエージェントではTool実行ログが重要
AIエージェントでは、
質問
↓
AI
↓
Tool選択
↓
実行
が行われます。
例えば、
ABC社への返信メールを作って
という依頼から、
get_customer
get_contract
get_inquiry_history
を実行したとします。
この場合、
どのToolを
どの順番で
どの引数で
実行したか
を記録します。
Tool実行ログの例
Tool:
get_customer
Input:
customer_id = ABC001
Result:
success
次に、
Tool:
get_contract
Input:
customer_id = ABC001
Result:
success
です。
更新系Toolでは変更前後を残す
例えばAIエージェントがCRMを更新する場合です。
Tool:
update_customer_status
Before:
proposal
After:
contracted
とします。
さらに、
approved_by:
user_001
も記録します。
Human in the Loopの承認ログ
AIが重要な操作を実行する場合、
AIが提案
↓
人が承認
↓
実行
という構成があります。
この場合、
誰が承認したか
いつ承認したか
何を承認したか
を残します。
例えば、
action:
send_email
approved_by:
sales_manager_01
approved_at:
2026-07-30 10:35:21
です。
後から、
AIが勝手に送信したのか
人が承認したのか
を判断できます。
プロンプト全文は保存するべき？
これはケースによります。
すべて保存すれば調査しやすくなります。
一方、
顧客氏名
メールアドレス
契約情報
社内機密
などが含まれる可能性があります。
そのため、
デバッグしやすさ
と、
情報管理リスク
のバランスを考えます。
方法1．全文保存
メリット：
問題を再現しやすい
デメリット：
個人情報・機密情報が
ログへ蓄積される
方法2．マスキングして保存
例えば、
山田太郎さんの契約を確認して
を、
[PERSON]の契約を確認して
とします。
方法3．メタデータだけ保存
例えば、
input_length:
3520
input_hash:
xxxx
feature:
customer_summary
だけ記録します。
高い機密性が必要なシステムではこの方法もあります。
ログに残してはいけない情報
原則として、
パスワード
APIキー
アクセストークン
秘密鍵
クレジットカード情報
などをログへ出さないようにします。
例えば、
Authorization:
Bearer sk-xxxx
をそのままHTTPログへ残してはいけません。
個人情報も必要最小限にする
例えばユーザーを識別したいだけなら、
山田太郎
ではなく、
user_12345
で十分かもしれません。
ログには、
業務上必要な情報だけ
を残すことが重要です。
ログを誰でも閲覧できる状態にしない
AIログには機密情報が含まれる可能性があります。
そのため、
一般社員
開発者
AI管理者
セキュリティ管理者
で閲覧範囲を分けます。
例えば、
一般社員
→ 自分の利用履歴
AI運用担当
→ AI性能・エラー
セキュリティ担当
→ 監査ログ
システム管理者
→ インフラログ
とします。
ログ保存期間を決める
ログは、
とりあえず永久保存
にしないことも重要です。
例えば、
アプリケーションログ
→ 30〜90日
AI評価ログ
→ 180日
重要な監査ログ
→ 1年以上
など、目的に応じて設定します。
これは一例であり、実際には、
社内規程
法令
契約
業界ルール
監査要件
に応じて決定します。
外部AIサービス側の保持期間と、自社側のログ保存期間も分けて考える必要があります。
例えばOpenAI APIでは、データ保持設定や利用機能によって異なりますが、標準のabuse monitoring logsについて最大30日の保持が説明されています。一方、API Platformの監査ログは管理イベント用の別ログであり、自社の長期保持要件がある場合には自社システムへエクスポートして保持することが推奨されています。
「AIサービスのログ」と「自社ログ」は別物
外部AIサービスにログ機能があるから、
自社ではログ不要
とは限りません。
AI提供会社が持っているのは、
APIリクエスト
管理イベント
AIサービス内での利用履歴
などです。
一方、自社で必要なのは、
どの社員が
どの業務で
どの顧客データを使い
どの社内APIを呼び
どの処理を承認したか
です。
つまり、
AIベンダー側ログ
+
自社アプリケーションログ
の両方を考えます。
ログをSIEMへ連携する
利用規模が大きくなると、
生成AIログ
認証ログ
クラウドログ
業務システムログ
をSIEMなどへ集約する方法があります。
例えば、
大量のAIリクエスト
通常と異なる時間帯の利用
権限エラーの急増
大量のファイル検索
などを検知します。
OpenAIのEnterprise向けCompliance Platformでも、ログをSIEM等へ取り込み、セキュリティ監視やコンプライアンス対応に利用する考え方が案内されています。
AIログから確認したいKPI
ログは監査だけでなく改善にも利用できます。
例えば、
月間AI利用者数
AI利用回数
部署別利用
機能別利用
成功率
エラー率
平均レスポンス時間
AI出力採用率
人による修正率
平均Token数
API費用
です。
AI利用回数だけ見ない
例えば、
月10万回AIを利用
していても、業務改善につながっているかは分かりません。
そこで、
AI実行ログ
と、
業務KPI
を組み合わせます。
例えば、
問い合わせAI利用
↓
月5,000件
↓
平均対応時間
10分 → 4分
と確認します。
ログからAI精度を改善する
例えばAI回答に、
Good
Bad
ボタンを付けます。
Badになった処理について、
質問
AI回答
検索文書
モデル
プロンプトバージョン
を確認します。
すると、
RAG検索が悪い
プロンプトが悪い
データが不足している
モデルが合っていない
などを分析できます。
モデル変更前後もログで比較する
例えば、
モデルA
↓
モデルB
へ変更したとします。
ログを使って、
回答採用率
エラー率
平均処理時間
API費用
を比較できます。
生成AIシステムはモデルの変更で挙動が変化する可能性があるため、ログによる継続的な評価が重要です。
NISTのAI RMFとGenerative AI Profileも、AIを導入時だけ評価するのではなく、利用・評価を通じた継続的なリスク管理を重視しています。
生成AIログのシステム構成例
例えば企業向けRAGなら、
社員
↓
AI画面
↓
認証
↓
バックエンド
↓
RAG検索
↓
生成AI
↓
回答
とします。
同時に、
ログDB
├─ user_id
├─ timestamp
├─ request_id
├─ AI機能
├─ model
├─ prompt_version
├─ retrieved_document
├─ latency
├─ token_usage
└─ status
を保存します。
AIエージェントなら
社員
↓
AIエージェント
↓
Tool A
↓
Tool B
↓
人が承認
↓
Tool C
に対して、
Trace
├─ ユーザー入力
├─ AI判断
├─ Tool A実行
├─ Tool B実行
├─ 承認
├─ Tool C実行
└─ 最終回答
として、一つのtrace_idで追跡できるようにします。
生成AIログ管理の導入手順
STEP1．ログを取る目的を決める
例えば、
セキュリティ
障害調査
AI精度改善
コスト管理
監査
です。
目的によって必要なログが変わります。
STEP2．記録項目を決める
例えば最初は、
request_id
user_id
timestamp
feature
model
status
latency
token_usage
程度から始められます。
STEP3．機密情報を分類する
入力全文を保存するか
AI出力を保存するか
個人情報をマスキングするか
を決めます。
STEP4．RAG・Toolのログを追加する
RAGなら、
参照文書
AIエージェントなら、
Tool実行
を残します。
STEP5．アクセス権限を設計する
誰がログを閲覧できるか決めます。
STEP6．保存期間を決める
監査・セキュリティ・コスト・個人情報を踏まえて決めます。
STEP7．ダッシュボードを作る
例えば、
利用数
エラー率
平均コスト
平均レスポンス
部署別利用
を可視化します。
STEP8．定期的にレビューする
例えば月次で、
異常利用
エラー増加
費用増加
低評価回答
権限エラー
を確認します。
生成AIログ管理のチェックリスト
基本ログ
□ request_idがある
□ user_idを記録している
□ 実行日時を記録している
□ AI機能を記録している
□ モデルを記録している
□ prompt versionを記録している
AI実行
□ 成功・失敗を記録している
□ 処理時間を記録している
□ Token利用量を記録している
□ エラー内容を確認できる
RAG・AIエージェント
□ RAGの参照文書を追跡できる
□ 文書バージョンを確認できる
□ Tool実行を記録している
□ Tool入力を確認できる
□ 人による承認を記録している
セキュリティ
□ APIキーをログに残していない
□ 個人情報を必要以上に保存していない
□ ログ閲覧権限を設定している
□ ログ保存期間を決めている
生成AIログ管理でよくある失敗
何もログを残さない
問題発生時に原因を追跡できません。
プロンプトと回答だけ保存する
RAGやAIエージェントでは、
参照文書
Tool実行
承認
も重要です。
すべて全文保存する
ログ自体が大きな情報漏えいリスクになる可能性があります。
APIキーまでログに出力する
認証情報は必ず除外します。
モデル名を記録しない
モデル変更後の挙動差を分析できません。
prompt versionを記録しない
どのプロンプトで生成された回答なのか分からなくなります。
ログを保存するだけで見ない
定期的に、
エラー
費用
異常利用
AI精度
を確認します。
生成AIログ管理に関するよくある質問
プロンプトはすべて保存した方がよいですか？
必ずしも必要ありません。
原因調査には便利ですが、個人情報・機密情報がログへ蓄積する可能性があります。
用途に応じて、
全文保存
マスキング
メタデータのみ
を選択します。
AIの回答も保存した方がよいですか？
AI精度改善や問題調査には有効です。
ただし回答にも機密情報が含まれる可能性があるため、保存期間・閲覧権限を決めます。
RAGでは何をログに残せばよいですか？
最低限、
質問
参照した文書ID
チャンクID
文書バージョン
AI回答
などを追跡できると原因分析しやすくなります。
AIエージェントでは何が重要ですか？
Tool実行ログです。
どのToolを
どの引数で
どの順番で
誰の権限で
実行したか
を追跡できるようにします。
AIログは何年間保存すべきですか？
一律では決められません。
利用目的、業界、法令、社内規程、セキュリティ要件によって決定します。
必要以上に長期間保存しないことも重要です。
ChatGPTなどのサービス側のログだけでは足りませんか？
独自業務システムと連携している場合は不足する可能性があります。
例えば、
どの顧客情報を取得したか
どのToolを実行したか
誰が承認したか
は自社システム側でしか把握できない場合があります。
hiro-dev-labの生成AI・ログ管理を考慮したシステム開発
hiro-dev-labでは、生成AIを企業システムへ組み込む際に、運用・監査を考慮したシステム開発を支援しています。
例えば、
- 生成AIの利用ログ
- ユーザー別AI利用履歴
- RAGの参照文書ログ
- AIエージェントのTool実行ログ
- Human in the Loopの承認履歴
- AI APIの利用量・コスト管理
- エラー・処理時間の記録
- OpenAI APIなどを利用したAI機能
- MCPによる社内システム連携
- Python・TypeScriptによるAIシステム開発
- 既存WebシステムへのAI機能追加
などを検討できます。
例えば、
ユーザー
↓
AI
↓
RAG検索
↓
社内API
↓
回答
という処理を、
trace_id
↓
ユーザー
↓
検索文書
↓
AIモデル
↓
Tool実行
↓
最終回答
として追跡できる構成にします。
生成AIのログ管理は「すべて記録すること」が目的ではない
生成AIログというと、
プロンプトも
回答も
検索結果も
全部保存する
と考えがちです。
しかし、ログそのものに機密情報が蓄積すれば、新しいセキュリティリスクになります。
重要なのは、
なぜログが必要なのか
を最初に決めることです。
例えば、
障害調査
→ request_id・エラー・処理時間
コスト管理
→ model・token usage
RAG改善
→ 質問・取得文書
監査
→ user・Tool実行・承認
AI品質改善
→ prompt version・回答評価
と、目的ごとに必要な情報が異なります。
企業向け生成AIシステムでは、
1．ログの目的を決める
↓
2．必要な項目を決める
↓
3．request_id・trace_idを付ける
↓
4．RAG・Tool実行も追跡する
↓
5．個人情報・機密情報を最小化する
↓
6．ログ閲覧権限を設定する
↓
7．保存期間を決める
↓
8．定期的に監視・分析する
という流れで設計します。
生成AIを本番業務へ組み込むほど、
「何が起きたのかを後から説明できること」
の重要性は高まります。
「生成AIを社内システムへ導入したい」
「RAGの検索結果まで追跡できるようにしたい」
「AIエージェントのTool実行を監査したい」
「AIの利用状況・APIコスト・エラーをまとめて管理したい」
このような段階からでも、お気軽にお問い合わせください。
生成AI・AIシステム開発について相談する