管理画面の監査ログを後付けにしない設計

管理画面でデータ変更や権限変更ができる場合、問題が起きた後に誰が操作したか分からないと調査できません。アプリケーションログだけでは、業務上の意味が追いにくいことがあります。

すべての入力値を丸ごと保存すると、個人情報や秘密情報をログに複製してしまいます。一方で、何が変わったか分からないログでは役に立ちません。粒度の設計が必要です。

管理画面では、設定変更、権限付与、削除、インポート、承認など、後から理由を確認したい操作が多くあります。画面上の成功通知だけでは、問題が起きた時に誰が何を変えたのか追えません。

監査ログは、操作種別、対象ID、実行者、時刻、変更前後の要約、リクエストID、結果を持たせます。詳細値は必要な項目だけにし、機密性の高い値はマスクまたは保存しません。

設計では、監査ログを副作用のついでに文字列保存するのではなく、ユースケースの完了イベントとして扱います。actor、target、action、before、after、reason、request_idを持たせると、調査と表示の両方に使えます。

APIのサービス層で重要操作の直前直後にログを記録します。DBトランザクション内で業務更新と監査ログを一緒に保存するか、失敗時ログを別に残すかを操作の性質で選びます。画面には対象別の履歴を表示します。

LaravelやAPI層では、更新処理と同じトランザクション内でaudit_eventsを保存します。React側では重要操作に理由入力や確認ダイアログを用意し、操作の文脈をログへ渡します。

検証では、権限変更、削除、承認、データ修正、失敗操作のログを確認します。ログ閲覧権限がないユーザーから見えないこと、ログに不要な個人情報が含まれないことも見ます。

検証では、各重要操作で監査ログが残ること、ロール不足時に操作が拒否されること、ログ閲覧権限が制御されることを確認します。特に、bulk updateやCSV importのような一括操作は差分の残し方をテストします。

ログを細かくしすぎると保存量と確認コストが増えます。最初は重要操作に絞り、後から対象を広げる方が運用に乗りやすいです。ただし権限変更と削除は初期から残すべきです。

ログを細かく残すほど調査しやすくなりますが、保存量と情報管理の負荷が増えます。すべての変更を同じ粒度で保存するのではなく、リスクの高い操作ほど詳細にする設計が必要です。

監査ログは開発者向けログではなく、業務上の説明を支える記録です。重要操作の設計時にログ粒度を決めておくことで、問題発生時の調査が現実的になります。

監査ログは、後から責任を追及するためだけのものではありません。変更の理由と影響を説明できるようにすることで、管理画面の信頼性が上がります。