監査ログのUI設計：誰が何を変え、何が不明なのかを伝える

監査ログの画面は、権限のある人が出来事をたどれるようにするものです。誰が、何を変更し、どの対象に影響し、いつ起こり、成功したのかを確認できる必要があります。「設定を更新しました」という1行だけでは、完了した変更、変更の試行、バックグラウンド処理の違いが分かりません。

再利用できるデータテーブルのコンポーネントはレイアウトの土台になりますが、ログにはイベントごとの項目定義も必要です。アイコン、重大度の色、詳細パネルを選ぶ前に、各項目の意味と、システムが実際に裏付けられることを決めます。

ログで答えたい問いから始める

架空のサポートアプリを考えます。管理者は、新しい問い合わせの振り分け先がGeneralからBillingへ変わった理由を調べています。振り分けルールRR-17が変更されたようです。ここで役立つ問いは「今日のイベントは何件か」ではなく、「記録されたどの操作がこのルールを変え、何を変更したか」です。

デザインには、違いを明確にした2つのイベントを使います。

• 2026年10月6日14:08:12 UTC、管理者MinaがRR-17の振り分け先をGeneralからBillingへ変更した。変更は成功した。
• 14:09:03 UTC、Routing automationがRR-17の更新を試みた。処理は失敗し、振り分け先はBillingのままだった。

2つ目を、もう一度変更に成功したように読ませてはいけません。また、2つ目の失敗が最初の変更を取り消すわけでもありません。すべての行を同じ長さの短文にすることより、この違いが分かることが重要です。

実行者、操作、対象を分けた行を作る

「Minaが振り分けルールRR-17を変更」のような短い文は、一覧を読み取る入口になります。補足項目で結果と時刻を示し、詳細画面で許可された変更内容とイベント番号を示します。すべての生データ属性を一覧に押し込まないようにします。

ここに登場する名前、ID、出来事は、設計のために用意した架空のものです。実際のログでは、実行者が人、サービスアカウント、自動処理のどれかは情報源によって決まります。すべてのイベントに人物のアバターを使うのではなく、その違いを示します。

GitHubの組織監査ログのドキュメント（英語）は、実行者、操作、影響を受けた文脈、時刻を分ける具体例です。検索条件が定義されていることからも、UIが提供するフィルターは元のイベントデータで確実に扱えるものに合わせるべきだと分かります。存在しない無制限の検索機能を約束してはいけません。

イベントの記録で裏付けられる変更だけを示す

EV-2041で役立つ詳細は、「振り分け先がGeneralからBillingに変わった」という短い内容です。項目名を一度示し、変更前と変更後の値にラベルを付け、色なしでも方向が分かるようにします。狭い画面では「変更前」「変更後」を縦に並べても、両方のラベルを保持します。

現在のレコードと無関係なスナップショットを比較して、以前の値を作り上げてはいけません。イベントに「ルールが更新された」としか記録されていないなら、どの詳細が取得できないかを示します。現在の状態は「今どうなっているか」、イベントの詳細は「その操作について何が記録されたか」に答えるものです。入れ替えて使うことはできません。

自動処理の失敗イベントでは、試みた操作と記録された失敗理由を、適切な詳しさで示します。確定していない変更案を、説明なしに「変更後」と表示しないでください。情報源に値があり、閲覧者にも開示できるなら、「要求された変更」という別のラベルが役立つことがあります。

変更の詳細では、空、削除済み、不明、閲覧制限も区別します。空文字列は正しい値かもしれません。「記録なし」はイベントにデータがないこと、「閲覧制限」はその人が値を見られないことです。すべてをダッシュで表すと、分かっていないことまで確定したように見せてしまいます。

調査に必要な時刻と範囲を明示する

「2分前」のような相対表示は新しさを把握するのに役立ちますが、調査には正確な時刻が必要です。日付、時刻、タイムゾーンを、アクセス可能で到達しやすい場所に用意します。マウスでしか開けないツールチップを、正確な時刻を知る唯一の手段にしないでください。

取り込みに遅延が起こり得るなら、イベントが起きた時刻とログが受信した時刻を分けます。標準の並べ替えと、同時刻の場合の順序を決めます。今届いたイベントが、時系列ではもっと前に入る場合もあります。表示順だけで2つの変更の因果関係を証明できるかのような見せ方は避けます。

フィルターの近くに、選択中の期間と対象のタイムゾーンを示します。「今日」は、地域の異なる同僚同士では別の範囲になり得ます。厳密な境界を使う場合は、終端を含むかどうかを実装仕様に記録し、利用者には読んで理解できる期間を表示します。

イベントを開いて一覧に戻っても、フィルターを維持します。可能なら結果内の位置も保持し、EV-2041を調べるたびに検索をやり直させないようにします。新しいイベントが届いても、読んでいる行を突然動かさないようにします。

イベント行から役立つ詳細までを設計する

Pixsoのファイルに、サポートアプリのイベント表と、EV-2041の詳細パネルを隣り合わせで作ります。RR-17、Mina、14:08:12 UTC、General → Billingを両方で一致させます。後に起きた自動更新の失敗は、アイコンだけを変えるのではなく、異なる結果を持つ別の行にします。

選択した行とパネル内のイベントの対応を分かりやすくします。狭い画面では、詳細を専用画面にして明確な戻り方を設けた案も試します。どの操作が振り分け先を変更し、後の試行は成功したかを、レビュー担当者に尋ねます。行の色から推測しなければ答えられないなら、文言を改善します。

Pixsoで監査イベントと詳細画面を設計する →

履歴がないことを「何も起きなかった」に変えない

イベント一覧が空になる理由は一つではありません。条件に合うイベントがない、期間が保持範囲外である、閲覧権限がない、情報源から届いていない、読み込みに失敗した、といった状態があります。それぞれに違う説明が必要です。

「この条件に一致するイベントはありません」は、利用可能な範囲で検索に成功した後に限って適切です。保持期限の問題なら、完全な空の履歴に見せるのではなく、取得できる期間を説明します。データを取得できない場合は、活動がなかったと断言せず、対応している復帰操作を案内します。

制限された画面でも、件数、フィルター候補、一見無害なプレビューを通じて、非公開リソースの存在や識別情報を漏らしてはいけません。見せる内容を権限モデルと一致させます。権限UXのガイドは、リソースが存在しない場合と、現在の利用者にはアクセスできない場合の区別を扱っています。

情報が多いほどよい証拠になるとは限らない

OWASPのログ記録チートシート（英語）は、記録の目的を区別し、調査に役立つイベント属性を挙げています。同時に、パスワード、アクセストークン、機微な個人情報など、通常は直接記録すべきでないデータも示しています。差分を視覚的に豊かに見せることは、その値を含める理由にはなりません。

詳細とエクスポートにも同じ制限を適用します。表で隠した項目をCSVダウンロードで開示しては、保護になりません。マスキングが適切な場合は、元の値が空だったと誤解させず、閲覧が制限されていると示します。対象者ごとに何を見られるかは、セキュリティとデータの担当者が定めます。

履歴と復元の操作も区別します。ルールが変更されたというログがあっても、安全にワンクリックで戻せるとは限りません。その後さらに変更されている可能性があり、以前の振り分け先に戻すには権限と現在の状態の検証が必要な場合があります。実際に対応しているときだけ、許可された管理操作へつなぎます。

画面から何を確かめられるかで評価する

RR-17について、管理者は成功した変更を特定し、許可された変更前後の値を読み、後の失敗を区別し、調べた期間と範囲を説明できる必要があります。取得できない詳細も認識し、推測で埋めないようにします。

読みやすいログだけで、完全性、不変性、法令適合性を証明することはできません。それらは収集、保存、アクセス、運用の制御に依存します。画面が果たす役割は、もっと限定的で、それでも重要です。システムが実際に持つ証拠を、人が正しく読み取れるようにします。