aillmopssecurity
LLM可観測性（Observability）最小ログ設計チェックリスト｜AIアプリの監査証跡を残す（2026）
|
5 min read
AIアプリ/自動化のための「最小で効くログ」をチェックリスト化。デバッグ、コスト管理、インシデント対応に必要な証跡を残しつつ、秘密情報や機密データをログに残さない。
目次
AIアプリに必要な“最小ログ”は？（デバッグできて監査も通る形）
結論（Conclusion）
AIアプリが「原因不明」になりがちなのは、ログが足りないのではなく“要点がズレている”ことが多い。 最小で効く可観測性はこれ。
- 1リクエストに1つの request_id/trace_id
- 何が起きたかの短いタイムライン（入力、検索、ツール、出力）
- リクエストごとのコストと遅延
- 原則：秘密情報や生の機密データはログに残さない
ログだけで1件の事故をE2Eで再現できれば、すでに十分強い。
背景（Explanation）
AIアプリはモデル呼び出し単体ではない。 実際はパイプライン。
- 入口（フォーム、チャット、Webhook）
- 検索（RAG）
- ツール呼び出し（API、DB）
- 出力
必要な答えはだいたいこれ。
- どの入力が引き金？
- どのルートが動いた？
- 何を検索した？
- どのツールを呼んだ？
- いくらかかった？
- 悪用/漏えいの兆候はある？
ログは“証跡”であって、二次被害の原因になってはいけない。
実務手順（Practical Guide）
手順1：監査で説明できる“物語”を定義する（5分）
1リクエストについて、ログで最低この流れが追えるべき。
- request received
- guardrails applied（検証/制限）
- retrieval（RAG）
- tool calls
- response returned
この物語がつながらないと、デバッグも説明責任も崩れる。
手順2：最小イベントスキーマを作る（10分）
すべてのイベントに共通で入れる。
- timestamp
- request_id（または trace_id）
- user_id/account_id（可能なら）
- route（どのハンドラ）
- environment（prod/staging）
イベント例：
- request.start
- guardrails.applied
- rag.retrieve.start / rag.retrieve.end
- tool.call.start / tool.call.end
- llm.call.start / llm.call.end
- response.sent
手順3：コストと遅延を記録する（5分）
LLM呼び出し単位で：
- model
- tokens_in, tokens_out
- latency_ms
- provider_request_id（取れるなら）
リクエスト単位で：
- total_latency_ms
- total_llm_cost_estimate（概算でOK）
これがないと、コスト暴騰や悪用の検知が遅れる。
手順4：“生データ”ではなく“要点”をログに残す（5分）
原則：
- 生プロンプト、生ドキュメント、生レスポンスをログに残さない
代わりにメタデータを残す。
- input_source（form/email/webhook）
- input_size_bytes（または文字数）
- retrieved_doc_ids（本文ではなくID）
- tool_name + status_code
- output_size_bytes
デバッグのために必要なら：
- 非prodでのサンプリング
- レダクション
- 短い保持期間
手順5：漏えい検知のシグナルを1つ入れる（5分）
どれか1つ。
- outbound destinationの異常
- outbound payload sizeの異常
- auth失敗の連続
- アカウント単位のtokenスパイク
“静かな漏えい”を“見える事故”に変える。
落とし穴（Pitfalls）
- 生プロンプト/機密ドキュメントをログに残してしまう
- request_idがなく事故の再構成ができない
- ツール呼び出しがログに出ない（最も危険な部分）
- prod/stagingが混ざる
- コストを見ずに請求で気づく
チェックリスト（Checklist）
- [ ] すべてのリクエストに request_id/trace_id がある
- [ ] すべてのイベントに timestamp + request_id + route + environment が入る
- [ ] ログだけで1リクエストをE2Eで再構成できる
- [ ] ガードレール判断がログに残る（制限/ブロック等）
- [ ] RAGの検索イベントが残る（start/end）
- [ ] 取得ドキュメントはIDだけ残る（本文は残さない）
- [ ] ツール呼び出しが残る（ツール名、時間、結果）
- [ ] LLM呼び出しで model/tokens/latency が残る
- [ ] リクエスト単位の遅延が残る
- [ ] リクエスト単位のコスト概算が残る
- [ ] 秘密情報と生の機密入力はログに残さない
- [ ] 保持期間ポリシーがある（簡易でも）
FAQ
1) デバッグのためにプロンプト全文をログに残すべき？
prodではデフォルトでNO。メタデータとID中心にし、必要ならレダクション/サンプリング/短期保持で対応。
2) 最初に入れるべき項目は？
request_id/trace_id。これがないとイベントがつながらない。
3) セキュリティにも効く？
効く。ツール呼び出し、outbound先、tokenスパイクを追えると、悪用や漏えいが見える。
内部リンク（Internal links）
- Hub: AI開発
- 関連記事：
免責
一般的なセキュリティ/運用の注意喚起です。