管理画面の操作ログ設計：誰が何を変えたかを追える仕組みづくり

管理画面の操作ログは、「何かあったときに見るもの」と後回しにされがちですが、実際に必要になるのはいつも突然です。顧客から「登録した住所が勝手に変わっている」と問い合わせが来たとき、取引先のセキュリティチェックで「管理者の操作履歴を保管していますか」と聞かれたとき、誤って大量のデータが削除されたとき。その瞬間に「誰が、いつ、何を、どう変えたか」を答えられるかどうかは、設計段階で決まっています。

この記事は、管理画面や業務システムを発注・企画する立場の方に向けて、操作ログの設計を実務的に整理したものです。操作ログを何に使うのか、どの項目を記録すべきか、どの操作を対象にするか、保存期間と保管方法、閲覧画面の作り方、改ざんへの備えまでを順に説明します。

結論を先に言えば、操作ログは「誰が・いつ・どこから・何に対して・何をして・どう変わったか」の六つを、用途に合わせた粒度で残すことが基本です。そして、記録することと同じくらい「必要なときに探せること」が重要です。記録だけしていても、検索できなければ調査には使えません。

操作ログは何のために残すのか

操作ログの設計を始める前に、用途を整理しておく必要があります。用途によって、残すべき項目も保存期間も変わるからです。

ここで区別しておきたいのは、操作ログと、サービスの利用状況を分析するためのイベントログの違いです。イベントログは「利用者がどの機能をどれだけ使っているか」を分析するためのもので、多少の欠損があっても集計上は問題になりません。一方、操作ログは一件一件の記録が証拠として意味を持つため、確実に残り、後から変更されないことが求められます。分析用のログの設計については プロダクトのイベントログ設計 で扱っています。

また、監査の観点で残す記録は一般に 監査ログ と呼ばれます。管理画面の操作ログは、監査ログの中心的な構成要素だと考えると位置づけが分かりやすくなります。

記録すべき項目：6つの基本要素

操作ログの一件ごとに記録すべき項目は、次の六つを基本にします。

誰が（操作者）

操作したユーザーの識別子と、その時点のロールを記録します。ユーザー名だけでなく、変わらない内部IDを残すのがポイントです。名前は変更されることがあるからです。代理操作や、システム管理者による「なりすまし表示」の機能がある場合は、本来の操作者と代理の対象者の両方を記録します。

いつ（日時）

サーバー側の時刻で、秒単位以上の精度で記録します。タイムゾーンを明示しておくと、海外拠点や複数のサーバーがある場合でも混乱しません。

どこから（接続元）

IPアドレスや利用した端末の情報（ブラウザの種類など）を記録します。不正アクセスの調査では、普段と違う場所からの操作かどうかが重要な手がかりになります。ただし、これらの情報も個人に関する情報として扱われる場合があるため、取り扱いのルールは社内の方針や専門家の意見を踏まえて決めてください。

何に対して（対象）

操作の対象となったデータの種類とIDを記録します。「顧客ID 1234」「請求書ID 5678」のように、後から対象を特定できる形にします。一覧画面での一括操作の場合は、対象となった全件のIDを残すか、少なくとも条件と件数を残します。

何をして（操作の種類）

作成、更新、削除、閲覧、出力、承認、権限変更、ログインなど、操作の種類を記録します。操作の種類はあらかじめ一覧として定義し、自由記述にしないことが、後で検索・集計するうえで大切です。

どう変わったか（変更内容）

更新の場合は、変更前と変更後の値を項目単位で記録します。これがあるかどうかで、調査のしやすさが大きく変わります。「顧客情報を更新した」だけでは、何が変わったのか分かりません。「住所：A → B」と残っていれば、問い合わせにもすぐ答えられます。

ただし、パスワードやクレジットカード番号などの秘匿すべき情報は、変更前後の値をそのまま記録してはいけません。「変更あり」とだけ残すなど、マスキングのルールを決めておきます。

どの操作を記録対象にするか

すべての操作を細かく記録すると、データ量が膨らみ、肝心のときに探しにくくなります。一方で、記録が足りないと調査に使えません。優先度を付けて対象を決めるのが現実的です。

閲覧の記録は判断が分かれる部分です。機微な個人情報や、取引先の重要情報を扱う画面では、閲覧の記録を求められることがあります。逆に、社内の在庫一覧の閲覧まで記録しても使い道はほとんどありません。扱う情報の性質と、取引先や社内規程からの要求をもとに判断してください。

操作ログ設計の手順

ここからは、操作ログを設計する具体的な手順を示します。

1. 用途を決める：問い合わせ対応、監査、不正対策、取引先への説明など、主な用途を二つか三つに絞ります。用途が決まると、残すべき項目と保存期間の議論がしやすくなります。
2. 対象の操作を一覧にする：管理画面の機能一覧をもとに、上の表の優先度で記録対象を決めます。権限設計で作った権限表があれば、操作の種類はそこから拾えます。
3. 記録する項目と形式を決める：六つの基本要素をどの形式で残すか、変更前後の値をどこまで残すか、マスキングの対象を決めます。
4. 保存期間と保管場所を決める：用途ごとに必要な期間を整理し、期間に応じて保管場所を分けるかを決めます。
5. 閲覧の方法と権限を決める：誰が、どの画面で、どんな条件でログを検索できるかを決めます。
6. 改ざん対策と監視を決める：ログの削除・変更をどう防ぐか、異常な操作をどう検知するかを決めます。
7. 運用ルールを文書化する：ログの確認を誰がどの頻度で行うか、調査依頼の手順、開示の判断を文書にします。

権限の整理がまだの場合は、先に 管理画面の権限設計 を進めると、操作の種類の洗い出しがスムーズになります。

保存期間と保管方法の考え方

保存期間は、用途と、法令や契約上の要求から決まります。会計や取引に関わる記録、個人情報の取り扱いに関する記録などは、法令や業界のガイドライン、取引先との契約で一定期間の保管が求められる場合があります。具体的な期間は業種や扱う情報によって異なり、制度の改正もあるため、最新の情報を公的機関や専門家に確認したうえで決めてください。

保管方法については、次のように段階を分けて考えると、費用と使いやすさのバランスが取りやすくなります。

• 直近の期間：管理画面からすぐに検索できる場所に保管する。問い合わせ対応や日々の調査に使う。
• 中期の期間：検索に少し手間がかかってもよいが、必要なときに取り出せる場所に保管する。
• 長期の期間：監査や法令対応のために保管し、通常は参照しない。安価な保管先に移し、取り出し手順を決めておく。

ログは日々増え続けるため、保管場所を分けないとデータベースが肥大化し、管理画面そのものの動作が遅くなることがあります。どの時点で古いログを移動・削除するかを、最初から仕組みとして組み込んでおくのが安全です。保存期間を過ぎたログを確実に削除することも、個人情報の取り扱いの観点では重要です。

ログの閲覧画面と改ざん対策

閲覧画面で必要な検索条件

記録したログを活用できるかどうかは、閲覧画面の使いやすさで決まります。最低限、次の検索条件で絞り込めるようにしておくと、多くの調査に対応できます。

• 期間（日時の範囲）
• 操作者
• 操作の種類
• 対象のデータ（顧客IDなど）

特に便利なのが、データの詳細画面から「このデータの変更履歴」を直接見られる機能です。問い合わせを受けた担当者が、ログの画面で条件を組み立てなくても、顧客の詳細画面を開くだけで「いつ誰が住所を変えたか」を確認できます。

ログの閲覧そのものにも権限が必要です。ログには操作者の情報や変更前の値が含まれるため、誰でも見られる状態にしてはいけません。管理者や監査担当など、閲覧できるロールを限定し、ログを閲覧したこと自体も記録しておくと、より厳格な運用になります。

改ざん対策と異常の検知

操作ログは、管理者自身の不正を調べるためにも使われます。そのため、管理者がログを削除・変更できてしまう設計では、監査上の意味が薄れます。

一般的な対策としては、次のようなものがあります。

• 管理画面からはログを削除・編集する機能を作らない
• ログを業務データとは別の保管先に書き込み、書き込み専用の権限で扱う
• 一定期間ごとにログを変更できない保管先へ複製する
• ログの記録そのものが失敗した場合に、検知して通知する

異常の検知については、最初から高度な仕組みを作る必要はありません。「短時間に大量のデータを出力した」「業務時間外に権限を変更した」「ログインの失敗が続いている」といった、分かりやすい条件で通知するだけでも、早期発見につながります。障害や事故が起きたときの対応の流れは システム障害対応フロー で整理しています。

実装方式の選び方と開発会社に確認すべきこと

操作ログの実装には、大きく分けていくつかの方式があります。発注側が技術の詳細まで理解する必要はありませんが、方式によって記録できる内容や後からの拡張性が変わるため、考え方だけは押さえておくと開発会社との会話がスムーズになります。

アプリケーションの処理の中で記録する方式

画面からの更新処理の中で、変更前後の値を取得してログに書き込む方式です。「どの画面で、どの業務操作として行われたか」まで記録できるのが利点です。一方で、記録の処理を各機能に組み込む必要があるため、新しい機能を追加するたびに記録漏れが起きないよう、共通の仕組みとして作っておくことが重要です。

データベースの変更を検知して記録する方式

データベース側でデータの変更を検知し、自動的に記録する方式です。画面を通さない変更（バッチ処理や直接の修正）も漏れなく記録できるのが利点ですが、「どの業務操作だったか」という文脈は残りにくくなります。

外部のログ管理サービスに送る方式

記録したログを外部のログ管理サービスに送り、検索や保管を任せる方式です。検索や長期保管の仕組みを自前で作らずに済む一方、サービスの利用料が継続的にかかり、ログに含まれる個人情報の取り扱いも確認が必要です。

実際には、これらを組み合わせることが多くなります。開発会社には、次の点を確認しておくと安心です。

• 新しい画面や機能を追加したとき、記録漏れを防ぐ仕組みになっているか
• 画面を通さない変更（バッチ処理、データ修正、外部連携）も記録されるか
• ログの記録に失敗したとき、業務処理を止めるのか、続行して通知するのか
• 保管量が増えたときの費用と性能の見込み

最後の「記録に失敗したときの扱い」は見落とされがちですが重要です。厳格な監査が求められる操作では、記録できなければ操作自体を止める方が安全な場合もあります。一方、業務を止められない処理では、続行したうえで記録の失敗を確実に通知する設計にします。どちらにするかは操作の重要度で決めましょう。

具体例：人材紹介会社の求職者管理画面

架空の一般例として、求職者の個人情報を扱う人材紹介会社の管理画面を考えてみます。キャリアアドバイザー、営業、事務、管理者が使い、取引先企業からも定期的にセキュリティに関する確認を受けている、という状況です。

この会社では、用途を「求職者からの問い合わせ対応」「個人情報の持ち出し防止」「取引先への説明」の三つに絞りました。そのうえで、求職者情報の作成・更新は変更前後の値を残し、履歴書ファイルのダウンロードと一覧のCSV出力は必ず記録して、一日の件数が一定を超えたら管理者に通知する仕組みにしました。求職者の詳細画面の閲覧も記録対象にしましたが、一覧画面の検索は対象外にしています。

閲覧画面は、求職者の詳細画面に変更履歴のタブを設け、アドバイザーが自分で確認できるようにしました。一方、全体のログ検索は管理者だけに限定しています。取引先からの質問には、記録対象、保存期間の方針、閲覧権限を一枚の資料にまとめて回答できるようになりました。こうした質問への備え方は 取引先のセキュリティチェックシートへの対応 も参考になります。

操作ログ設計のチェックリスト

• 操作ログの主な用途を二つか三つに絞ったか
• 誰が・いつ・どこから・何に対して・何をして・どう変わったかを記録するか
• 代理操作やなりすまし表示のときに、本来の操作者が分かるか
• パスワードなど秘匿すべき値のマスキングを決めたか
• ログイン、権限変更、削除、一括更新、出力を必ず記録対象にしたか
• 閲覧を記録するかどうかを、扱う情報の性質から判断したか
• 保存期間を、法令・契約・社内規程を確認したうえで決めたか
• 古いログの移動と削除が仕組みとして組み込まれているか
• ログの閲覧権限を限定したか
• 管理画面からログを削除・変更できない設計になっているか
• 記録の失敗や異常な操作を検知して通知できるか

よくある失敗とその避け方

失敗1：「更新しました」しか残っていない 変更前後の値がないと、問い合わせへの回答も、誤操作からの復旧もできません。最初から項目単位の差分を残す設計にしておきましょう。後から追加するのは、既存の画面すべてに手を入れることになり、思った以上に手間がかかります。

失敗2：ログが多すぎて探せない 画面を開くたび、一覧を表示するたびに記録していると、肝心の更新操作が埋もれてしまいます。記録対象に優先度を付け、検索条件で絞り込めるようにしておくことが大切です。

失敗3：システムの処理による変更が記録されない バッチ処理や外部連携による自動の更新が記録されていないと、「誰も操作していないのにデータが変わった」という調査が長引きます。システムによる変更も、操作者を「システム」や「連携名」として記録しましょう。

失敗4：ログの保管費用を見込んでいない ログは確実に増え続けます。保管先の容量や費用が運用後に問題になることがあるため、保存期間と保管方法は開発時に決め、運用費用の見積もりにも含めておく必要があります。

よくある質問

Q. 操作ログは自社開発せず、既存のサービスで済ませられますか？

クラウドサービスの監査機能やログ管理のサービスを使えば、ログインやインフラ側の操作は記録できます。ただし、「顧客の住所をAからBに変えた」のような業務データの変更内容は、アプリケーション側で記録しないと残りません。両者を組み合わせるのが一般的です。

Q. 操作ログがあれば、データを元に戻せますか？

変更前の値が残っていれば、手作業や簡単な仕組みで元に戻すことは可能です。ただし、操作ログはバックアップの代わりにはなりません。大規模な誤削除からの復旧には、別途バックアップの仕組みが必要です。

Q. 社員の操作を記録することに問題はありませんか？

業務システムの操作記録は、多くの会社で内部統制や情報管理の目的で行われています。ただし、記録の目的や範囲を社内規程で明確にし、従業員に周知しておくことが望ましいです。具体的な取り扱いは、社内の規程や専門家の意見を踏まえて判断してください。

Otsumuに相談できること

利用者が少なく、扱う情報も社内の業務データが中心であれば、既製の管理画面の仕組みや、使っているフレームワークの変更履歴の機能を有効にし、この記事のチェックリストで記録対象と保存期間を決めるだけでも十分なことがあります。まずは「何のために残すのか」を社内で決めることから始めてください。

一方で、個人情報や取引先の重要情報を扱う、取引先からセキュリティに関する確認を受ける、管理者が複数いて内部の不正にも備えたい、といった状況では、記録対象、保管方法、改ざん対策、閲覧権限をまとめて設計する必要があります。既存の管理画面に後から操作ログを追加する場合も、影響範囲の見極めが重要です。

Otsumuでは、用途の整理から、権限設計と一体になった操作ログの設計、閲覧画面の実装、取引先への説明資料の準備まで支援しています。構想から開発、運用まで一気通貫で関わるため、作って終わりではなく、実際に調査で使えるログを目指します。管理画面の開発については 管理画面開発 のページをご覧ください。

いまのシステムで何が記録されているか分からない、という段階でも構いません。30分の無料相談 で状況をお聞かせください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01