第6章：ログ設計が出発点

この章で分かること

  • なぜ「AIの前にログ」なのか
  • 最低限そろえたい項目と、無いときに起きる症状
  • severity / event code / stacktrace / 相関ID の実務ルール
  • PII・秘密を書かないためのチェック
  • 導入前に潰すべきアンチパターン
たとえ話

防犯カメラが真っ暗だと、優秀な捜査官（AI）でも追えません。
起点記事も「error定義とstacktraceが入口」と結論しています [S02]。OWASPも目的に沿った一貫ログを勧めています [S07]。

観測の入口が崩れていると、監視もAIも止まります。ログ改修は地味ですが、AI予算より先に効く投資です。

1. AI導入前に直す9項目

  1. 画面メッセージと内部ログを分ける（画面にstacktraceを出さない）
  2. 例外を握りつぶさない
  3. error / warn / info の基準表を作る
  4. event code を付ける
  5. 構造化する（JSON等）
  6. PII・秘密・APIキーを書かない [S07]
  7. trace_id / request_id をサービス間で運ぶ [S03]
  8. version / commit を残す
  9. 時刻をタイムゾーン付きで揃える

2. 良い例／悪い例

同じ失敗でも、残す情報が違う
悪い例:
  ERROR failed user=hanako@example.com

よい例:
  timestamp, service, version, severity=error,
  event_code=ORDER_CREATE_FAILED, trace_id,
  user_hash, exception_type, stacktrace

3. 項目が無いと誰が困るか

欠落症状困る人
stacktrace原因コードに辿れない開発、AI修復
trace_idサービス横断ができない運用、SE
versionデプロイ相関が検証できない運用、PM
severity基準アラートが泣く／沈黙運用
PIIマスクAI経路で漏洩全員、特にセキュ

4. severity の決め方（例）

レベル意味（例）通知
errorユーザー影響またはデータリスクが眼前即時の候補
warn劣化の兆候。放置するとerror化しうる集約・勤務時間など
info正常系の節目。探索用原則ページしない
運用担当者severity定義を監視ルールと揃える
PG空catch・stack捨て・PII出力をレビューで弾く [S02]
SE例外処理・ログ出力・マスキングの設計基準を整備する [S02]
PMログ改修を「AI前提の必須」としてスケジュールする
経営層AI予算の一部を観測品質に回す判断をする

5. 現場適用：1スプリント改修パック

  1. 主要APIのerrorに version と trace_id を必須化
  2. 空catchをlintで禁止
  3. severity定義をWikiに1枚置く
  4. PIIサンプルをログ検索で1回監査する

ふりかえり

  • 最近のerrorに version と trace_id があるか
  • PIIが平文で混ざっていないか
  • severity基準表がチームで共有されているか