Audit log design

Purpose

「何が起きたか分からない」インシデント対応不能の状態を防ぐ。 記録すべきイベント・項目・保持・保護を設計し、追跡可能性と説明責任を確保する。

Use When

• 重要操作（決済・権限変更・削除）の記録を設計するとき
• インシデント対応・不正検知の備えを作るとき
• 「後で誰がやったか追えるか」を確認したいとき
• auth-boundary-check の後に認証・権限イベントの記録を設計するとき

Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

• 対象操作: 監査したい操作・イベント
• 追跡目的: 不正検知 / 障害調査 / 説明責任 のどれか
• 保持要件: どれだけの期間・粒度で保持するか
• 既存ログ: 現在どのようなログがあるか（ない場合は「なし」）

Output Contract

以下の順で出力すること。順序を変えない。

1. 論点: 監査ログで最も重要な記録対象は何か
2. 根拠: その論点をそう判断した理由
3. 監査ログ設計表: イベント / 記録項目 / 保持 / 保護
4. 含意: ログ設計が示す調査可能性・運用負荷
5. 改善案: 記録の過不足・保護・検索性の改善
6. 代替案: 別のログ方式（構造化ログ / 専用監査基盤）
7. 判断材料: ログ設計の確定に必要な人間の確認事項

Review Lens

• 目的妥当性: 記録が追跡目的を達成できるか
• 範囲の過不足: 記録しすぎ（コスト・PII 混入）／不足がないか
• 中長期リスク: ログ自体が改ざん・肥大化しないか
• LAB全体との整合性: LMS / 自動化 / B2B 展開の監査要件と整合するか
• 非エンジニア理解可能性: 何を追跡できるかを関係者に説明できるか
• 他LLM移植耐性: 判断が特定ログ基盤の前提に依存していないか

Instructions

1. 監査対象イベント（誰が・何を・いつ）を列挙する
2. 各イベントの記録項目を「5W1H」で過不足なく定義する
3. ログに PII・秘密情報が不要に混入しないか確認する
4. 改ざん防止（追記専用・署名）と保持期間を設計する
5. 検索・調査のしやすさ（構造化・相関 ID）を確認する
6. 不明な要件は推測せず、確認事項として明示する

Guardrails

• ログに PII・パスワード・トークンを生のまま記録しない
• 「全部記録」でコスト・ノイズを増やしすぎない
• ログの改ざん可能な設計を「監査」と呼ばない
• ログ設計の最終確定は人間に委ねる

LAB Cross-Check

観点	状態	備考
自動化フロー	—	自動化処理の実行も監査対象に含めたか
データ / 認証 / ログ	—	認証失敗・権限変更を記録しているか
実装 / 運用フロー	—	ログを誰が・いつ確認する運用があるか
非エンジニア理解可能性	—	追跡できる範囲を関係者に説明できるか
会員共有 / 再利用耐性	—	ログ設計が他機能にも転用できるか
他LLM移植耐性	—	判断が特定ログ基盤に依存していないか

状態は OK / 注意 / NG / 対象外 で記入すること。

Handoff Notes

施工AI（Claude Code / Cursor 等）へ渡す前に以下を確定させること。

• 要件: 記録イベント・項目・保持・保護の仕様
• 成功条件: 必要なときに追跡できると判断する基準
• 失敗条件: ログ欠落・改ざんを検知する基準
• 実行範囲: 追加してよいログ出力・保存先
• 影響範囲: ログ追加が波及するパフォーマンス・コスト
• ロールバック方針: ログ設定変更が問題を起こした場合の戻し方
• コスト比較: ログ方式ごとの保存・運用コスト

Further Reading

• auth-boundary-check skill — 監査すべき認証・権限イベント
• pii-handling-review skill — ログへの PII 混入の防止
• monitoring-alert-design skill — ログを使った異常検知
• glossary.md — PII 等の用語定義