昨日まで正しかった金額が、今日見ると違う。最後に更新した人は分かっても、何を変更したのかが残っていない。こうした確認に時間がかかる場合は、入力欄を増やす前に、どの操作をどこまで記録するかを考えてみましょう。
変更履歴は内容の確認、監査ログは操作の追跡に使う
呼び方や機能の範囲は製品によって違います。この記事では、レコードの値がどう変わったかをたどる情報を『変更履歴』、ログインや出力、権限変更なども含めた操作の記録を『監査ログ』として整理します。
| 記録の例 | 確かめたいこと |
|---|---|
| 見積金額の変更前と変更後 | どの数字を直したか |
| 承認・差し戻し・取消 | 誰の判断で状態が変わったか |
| 権限の追加・削除 | 誰がアクセス範囲を変えたか |
| データの一括出力 | いつ、誰が、何を出力したか |
画面に『最終更新者』が一人表示されるだけでは、その前の変更は追えません。どこまでさかのぼる必要があるのか、実際に調べたくなった場面から考えてみましょう。
操作と対象を結び付け、結果まで残す
記録を集めるだけでは、探すときに役立たないことがあります。『何かを更新した』ではなく、どの対象に、どの操作を行い、成功したか失敗したかまで結び付けます。次は設計を相談するための項目例です。
| 項目 | 記入例(架空) |
|---|---|
| 日時とタイムゾーン | 2026-10-27 10:15 日本時間 |
| 操作したアカウント | 営業担当Aの個別アカウントID |
| 対象と操作 | 見積Q-1024の金額変更 |
| 変更内容 | 数量2→3、金額は再計算 |
| 処理結果 | 成功/権限不足で失敗 |
| 関連情報 | 一括処理の受付番号、変更理由 |
共有アカウントでは、記録に残る名前と実際に操作した人を区別できません。個別アカウントで使う運用とセットで考える必要があります。ただし、個別アカウントの記録があっても、本人が操作したことを絶対に証明できるという意味ではありません。
残すものと、記録に入れない情報を決める
OWASPのログ設計資料では、パスワードやアクセストークンなどをそのまま記録しないこと、ログの閲覧権限を制限することが説明されています。業務の入力内容を何でも履歴にコピーすればよい、というわけではありません。
顧客の住所や相談内容などを扱う場合は、変更された項目名だけでよいか、値の一部を隠すか、限られた担当者だけが見られる必要があるかを検討します。業務上必要な確認と、記録から情報が広がるリスクを両方考えます。
保存期間にも全業務で共通の正解はありません。契約や社内規程、扱う情報の要件、調査に必要な期間を確認し、過ぎた記録の削除や保管場所も決めます。必要な期間を満たす前に消えることと、理由なく永久に残すことの両方を避けましょう。
履歴の閲覧と、元に戻す機能は別に確認する
履歴を見られても、ワンクリックで元に戻せるとは限りません。戻す機能がある場合も、その後に追加された出荷や請求との整合性をどう保つかが課題になります。
確認したい例
受注数量を3から2へ戻したい。ただし、すでに3個を出荷済み。この場合、数量の巻き戻しだけでなく、出荷・請求の訂正までどの手順で行うかを決める。
バックアップと復旧も、履歴の閲覧とは目的が異なります。全体障害から復旧するのか、一件の誤入力を訂正するのかを分け、どの機能と運用で対応するか確認してください。
試作では「記録されたか」と「探せるか」を試す
- 通常の入力・変更・取消を行い、対象の履歴から内容をたどれる
- 一括取り込みでも、実行者と対象の範囲が分かる
- 権限のない利用者は、履歴やログを閲覧・変更できない
- 管理担当者が、日付・対象・操作者で必要な記録を探せる
- 記録の削除や保存の仕組みが、決めた運用と合っている
画面操作だけでなく、CSV取り込みや連携処理から行った変更も対象に含まれるか確認します。記録があることに加え、担当者が必要な時間で見つけられることまでを試しておくと、運用後の調査に使いやすくなります。
調べたい場面から、残す記録を逆算する
誰が何を変えたか、という疑問に答えるには、個別アカウント、対象と操作の記録、必要な範囲の変更内容、閲覧と保存のルールが必要です。SHISAKUBAで試作する場合は、『前回、調べるのに困った変更』を一つ例にすると、どの画面に何を残すべきかを具体的に検討できます。
参考にした公式資料
2026年10月27日確認。本文中の記入例・チェック項目は、業務を検討するために作成した例です。
まずは無料で試作してみませんか?
「どんなアプリになるか見てみたい」という方へ。
費用・仕様が固まっていなくても、お気軽にご相談ください。
最短1週間でプロトタイプをご提案します。