thinkyou0714 Purpose
「何が起きたか分からない」インシデント対応不能の状態を防ぐ。 記録すべきイベント・項目・保持・保護を設計し、追跡可能性と説明責任を確保する。
Use When
- 重要操作（決済・権限変更・削除）の記録を設計するとき
- インシデント対応・不正検知の備えを作るとき
- 「後で誰がやったか追えるか」を確認したいとき
- auth-boundary-check の後に認証・権限イベントの記録を設計するとき
Inputs
以下を準備すること。不足している場合は推測せず、不足を明示する。
- 対象操作: 監査したい操作・イベント
- 追跡目的: 不正検知 / 障害調査 / 説明責任 のどれか
- 保持要件: どれだけの期間・粒度で保持するか
- 既存ログ: 現在どのようなログがあるか（ない場合は「なし」）
Output Contract
以下の順で出力すること。順序を変えない。
- 論点: 監査ログで最も重要な記録対象は何か
- 根拠: その論点をそう判断した理由
- 監査ログ設計表: イベント / 記録項目 / 保持 / 保護
- 含意: ログ設計が示す調査可能性・運用負荷
- 改善案: 記録の過不足・保護・検索性の改善
- 代替案: 別のログ方式（構造化ログ / 専用監査基盤）
- 判断材料: ログ設計の確定に必要な人間の確認事項
Review Lens
- 目的妥当性: 記録が追跡目的を達成できるか
- 範囲の過不足: 記録しすぎ（コスト・PII 混入）／不足がないか
- 中長期リスク: ログ自体が改ざん・肥大化しないか
- LAB全体との整合性: LMS / 自動化 / B2B 展開の監査要件と整合するか
- 非エンジニア理解可能性: 何を追跡できるかを関係者に説明できるか
- 他LLM移植耐性: 判断が特定ログ基盤の前提に依存していないか
Instructions
- 監査対象イベント（誰が・何を・いつ）を列挙する
- 各イベントの記録項目を「5W1H」で過不足なく定義する
- ログに PII・秘密情報が不要に混入しないか確認する
- 改ざん防止（追記専用・署名）と保持期間を設計する
- 検索・調査のしやすさ（構造化・相関 ID）を確認する
- 不明な要件は推測せず、確認事項として明示する
Guardrails
- ログに PII・パスワード・トークンを生のまま記録しない
- 「全部記録」でコスト・ノイズを増やしすぎない
- ログの改ざん可能な設計を「監査」と呼ばない
- ログ設計の最終確定は人間に委ねる
LAB Cross-Check
| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | 自動化処理の実行も監査対象に含めたか |
| データ / 認証 / ログ | — | 認証失敗・権限変更を記録しているか |
| 実装 / 運用フロー | — | ログを誰が・いつ確認する運用があるか |
| 非エンジニア理解可能性 | — | 追跡できる範囲を関係者に説明できるか |
| 会員共有 / 再利用耐性 | — | ログ設計が他機能にも転用できるか |
| 他LLM移植耐性 | — | 判断が特定ログ基盤に依存していないか |
状態は OK / 注意 / NG / 対象外 で記入すること。
Handoff Notes
施工AI（Claude Code / Cursor 等）へ渡す前に以下を確定させること。
- 要件: 記録イベント・項目・保持・保護の仕様
- 成功条件: 必要なときに追跡できると判断する基準
- 失敗条件: ログ欠落・改ざんを検知する基準
- 実行範囲: 追加してよいログ出力・保存先
- 影響範囲: ログ追加が波及するパフォーマンス・コスト
- ロールバック方針: ログ設定変更が問題を起こした場合の戻し方
- コスト比較: ログ方式ごとの保存・運用コスト
Further Reading
auth-boundary-checkskill — 監査すべき認証・権限イベントpii-handling-reviewskill — ログへの PII 混入の防止monitoring-alert-designskill — ログを使った異常検知- glossary.md — PII 等の用語定義