業務システムを開発するとき、
「ログイン履歴だけ残しておけばよい」
「エラーが起きたときに確認できるログがあれば十分」
「監査が入ってから必要なログを考えればよい」
と考えていないでしょうか。
システムログには、障害調査のためのログだけでなく、
- 誰がログインしたか
- 誰がデータを変更したか
- 誰が権限を変更したか
- 誰が承認したか
- 誰がデータを出力したか
など、業務上の操作を確認するためのログがあります。
監査や内部統制、セキュリティ調査などでは、
誰が・いつ・何に対して・何をしたのか
を後から確認できることが重要です。
例えば顧客情報が変更されていた場合、
変更日時：2026年7月30日 15:32
操作ユーザー：user123
対象：顧客ID 10025
操作：電話番号変更
変更前：03-XXXX-1111
変更後：03-XXXX-2222
という情報が残っていれば、変更経緯を追跡できます。
一方、
「更新されました」
というログだけでは、監査や調査に十分利用できない場合があります。
そのためシステム開発では、
何を記録するか → どのくらい保存するか → 誰が確認できるか → ログ自体をどう守るか
まで含めて設計することが重要です。
この記事では、監査対応で準備したいログの種類、記録する項目、保存・検索・権限・改ざん防止まで、業務システムの設計ポイントを具体的に解説します。
監査対応におけるログとは
監査対応で利用するログとは、システム上で発生した操作や状態変化を後から確認するための記録です。
例えば、
- ログイン
- ログアウト
- データ登録
- データ変更
- データ削除
- 承認
- 差し戻し
- 権限変更
- CSV出力
- ファイルダウンロード
などを記録します。
単に、
「システムにアクセスした」
という情報だけではありません。
業務システムでは、重要な操作について、
誰が何をしたのかを追跡できる状態
を作ることがポイントです。
こうした履歴は「監査ログ」「操作ログ」「監査証跡」などと呼ばれることがあります。
監査ログとシステムログは目的が違う
システム開発では、さまざまなログを扱います。
例えば、
アプリケーションログ
アプリケーションの処理状況を記録します。
エラーログ
システムエラーや例外を記録します。
アクセスログ
Webサーバーなどへのアクセスを記録します。
操作ログ・監査ログ
ユーザーが行った業務操作を記録します。
例えば、
APIでエラーが発生した原因を調査したい
という場合は、アプリケーションログやエラーログを確認します。
一方、
誰がこの契約情報を変更したのか
を確認したい場合は、操作ログ・監査ログが必要です。
目的が異なるため、監査対応では業務操作を追跡できるログを別途設計することが重要です。
監査対応で準備したい主なログ
業務システムでは、次のようなログを検討します。
1．ログイン・ログアウト履歴
まず基本となるのが認証に関するログです。
例えば、
- ユーザーID
- ログイン日時
- ログアウト日時
- 成功・失敗
- 接続元IPアドレス
- 利用端末に関する情報
などを記録します。
特に、
いつ誰がシステムへアクセスしたのか
を確認するために利用します。
2．ログイン失敗履歴
成功したログインだけでなく、失敗も重要です。
例えば、
2026/07/30 10:00 ログイン失敗
2026/07/30 10:01 ログイン失敗
2026/07/30 10:02 ログイン失敗
と短時間に大量の失敗があれば、不正アクセスの兆候を確認する材料になります。
必要に応じて、
- 失敗回数
- 対象アカウント
- 接続元
- 発生時間
などを確認できるようにします。
3．データ登録履歴
新しいデータを作成した場合の履歴です。
例えば、
顧客登録
契約登録
社員登録
申請登録
などです。
最低限、
- 誰が
- いつ
- 何を登録したか
を確認できるようにします。
4．データ変更履歴
監査対応で特に重要になりやすいログです。
例えば、
契約金額が100万円から200万円へ変更された
場合、
- 更新日時
- 更新者
- 対象データ
- 変更項目
- 変更前
- 変更後
を記録します。
単に「更新」というログだけでは、
何が変更されたのか
を確認できません。
重要なデータについては変更前後を残す方法を検討します。
5．データ削除履歴
データ削除は影響の大きい操作です。
例えば、
- 顧客削除
- 契約削除
- 申請削除
- ファイル削除
などです。
削除したデータそのものが消えてしまうと、後から調査できなくなる場合があります。
そのため、
- 削除したユーザー
- 削除日時
- 対象データ
- 削除理由
などを記録する方法があります。
また、データベースから即座に完全削除するのではなく、論理削除を利用する設計もあります。
6．権限変更履歴
非常に重要ですが、見落とされやすいログです。
例えば、
一般ユーザー
↓
管理者
へ変更された場合です。
権限変更によって、
- 全データ閲覧
- CSV出力
- ユーザー管理
- データ削除
などが可能になる場合があります。
そのため、
誰が
誰の権限を
いつ
何から何へ変更したか
を記録します。
7．ユーザー作成・無効化履歴
例えば、
- 新規アカウント作成
- アカウント停止
- アカウント再有効化
- アカウント削除
などです。
退職者のアカウントが残っていないか確認するときにも利用できます。
8．承認・差し戻し履歴
申請・稟議・契約などでは、
誰が承認したか
を確認できる必要があります。
例えば、
申請
↓
課長承認
↓
部長承認
↓
完了
という場合です。
記録する情報として、
- 承認者
- 承認日時
- 対象申請
- 承認・差し戻し
- コメント
などがあります。
9．CSV出力履歴
顧客管理や名簿管理などでは特に重要です。
画面で1件ずつ情報を見ることと、
1万件をCSVへ出力すること
では影響が大きく異なります。
そのため、
- 出力者
- 出力日時
- 出力対象
- 件数
- 検索条件
などを記録する方法があります。
10．ファイル閲覧・ダウンロード履歴
機密性の高いファイルを扱う場合、
- 契約書
- 人事資料
- 個人情報
- 経営資料
などを誰が閲覧・ダウンロードしたか記録することがあります。
すべてのファイルで必要とは限りません。
情報の重要度に応じて判断します。
11．マスタ変更履歴
例えば、
- 商品マスタ
- 顧客区分
- 税率
- 承認ルート
- ステータスマスタ
などです。
マスタ変更は複数の業務データへ影響することがあります。
そのため、重要なマスタでは変更履歴を残します。
12．システム設定変更履歴
例えば、
- セキュリティ設定
- 通知設定
- 外部連携設定
- 権限ロール
- 認証設定
などです。
管理者しか操作できない機能であっても、管理者の操作自体をログに残すことが重要です。
監査ログに記録したい基本項目
操作ログを設計するときは、最低限次の情報を検討します。
誰が
ユーザーを識別する情報です。
例えば、
- ユーザーID
- 社員番号
- アカウントID
などです。
氏名だけでは、同姓同名や氏名変更があるため、内部的には一意なIDを記録する方が管理しやすくなります。
いつ
操作日時です。
例えば、
2026-07-30 14:25:32
のように記録します。
複数システムを横断して調査する場合は、タイムゾーンの扱いも統一しておくことが重要です。
何に対して
対象データです。
例えば、
顧客ID：10025
契約ID：C000123
申請ID：A000500
などです。
何をしたか
例えば、
- CREATE
- UPDATE
- DELETE
- APPROVE
- REJECT
- EXPORT
- DOWNLOAD
などです。
日本語で、
登録
編集
削除
承認
と表示しても構いません。
どう変わったか
変更操作の場合、
変更前
変更後
を記録します。
例えば、
ステータス
申請中 → 承認済み
という情報です。
どこから操作したか
必要に応じて、
- IPアドレス
- 端末情報
- ブラウザ
などを記録します。
ただし、収集する情報自体にも管理上の配慮が必要です。
必要性を確認した上で記録します。
【例】監査ログのデータ項目
例えば、操作ログを次のような構造で管理します。
| 項目 | 内容 |
|---|---|
| 操作日時 | 2026/07/30 14:25:32 |
| ユーザーID | user123 |
| 操作 | UPDATE |
| 対象 | CUSTOMER |
| 対象ID | 10025 |
| 項目 | telephone |
| 変更前 | 03-XXXX-1111 |
| 変更後 | 03-XXXX-2222 |
| IPアドレス | xxx.xxx.xxx.xxx |
このような情報があれば、
誰がこの値を変更したのか
という質問に回答しやすくなります。
すべての操作を同じ粒度でログに残す必要はない
ログは多ければ多いほどよいわけではありません。
例えば、
- 一覧画面を開いた
- タブを切り替えた
- 検索ボタンを押した
まで永久に保存すると、ログ量が大量になる可能性があります。
一方、
- 個人情報の閲覧
- 契約金額変更
- 権限変更
- CSV出力
は重要度が高い場合があります。
そのため、
操作の重要度に応じて記録するログを決める
ことが重要です。
監査ログを設計する7ステップ
STEP1｜監査・調査で確認したいことを整理する
まず、
後から何を確認できる必要があるのか
を整理します。
例えば、
- 誰がログインしたか
- 誰が顧客情報を変更したか
- 誰が申請を承認したか
- 誰がCSVを出力したか
などです。
STEP2｜重要なデータを整理する
例えば、
- 顧客情報
- 社員情報
- 契約
- 売上
- 請求
- 申請
などです。
すべてのデータを同じ重要度で扱う必要はありません。
STEP3｜重要な操作を整理する
例えば、
閲覧
登録
変更
削除
承認
出力
などです。
特に影響の大きい操作を洗い出します。
STEP4｜記録項目を決める
基本は、
誰が
いつ
何に
何をしたか
です。
必要に応じて、
変更前後
IPアドレス
件数
などを追加します。
STEP5｜保存期間を決める
ログをいつまで保存するか決めます。
保存期間については、
- 法令
- 契約
- 社内規程
- セキュリティ要件
- 監査要件
などによって変わります。
一律に決めるのではなく、対象業務に必要な期間を確認します。
STEP6｜閲覧権限を決める
監査ログには、
誰が何をしたか
という重要な情報が含まれます。
そのため、
一般ユーザー
→ 閲覧不可
管理者
→ 一部閲覧
監査担当
→ 必要範囲を閲覧
など、ログ自体の権限管理も必要です。
STEP7｜検索・出力方法を決める
ログが大量にあっても検索できなければ監査対応で利用しにくくなります。
例えば、
- 期間
- ユーザー
- 操作
- 対象ID
- 操作種類
などで検索できるようにします。
【コピペ用】監査ログ設計チェックシート
基本情報
システム名：
対象業務：
利用人数：
管理者：
記録するログ
ログイン成功：
ログイン失敗：
ログアウト：
データ登録：
データ変更：
データ削除：
承認：
差し戻し：
CSV出力：
ファイルダウンロード：
権限変更：
ユーザー作成：
ユーザー無効化：
マスタ変更：
システム設定変更：
基本項目
ユーザーID：
操作日時：
操作種類：
対象データ：
対象ID：
変更前：
変更後：
IPアドレス：
端末情報：
ログ検索
期間：
ユーザー：
対象：
操作種類：
対象ID：
保存
保存期間：
保存場所：
バックアップ：
削除方法：
権限
ログ閲覧：
ログ検索：
ログ出力：
ログ削除：
運用
監査担当：
定期確認：
異常検知：
インシデント調査：
ログは一般ユーザーが変更できないようにする
監査ログで重要なのが、操作した本人が自由にログを削除・変更できないことです。
例えば、
管理者が顧客データを変更
↓
同じ管理者が操作ログを削除
できる状態では、監査証跡としての信頼性が低下します。
そのため、
業務データを操作する権限
と、
監査ログを管理する権限
を分けることがあります。
特に重要なシステムでは、ログ自体をアプリケーションとは別の保存先へ送る方法も検討します。
ログの改ざん防止を考える
監査ログには、
記録されている内容を信用できること
も重要です。
例えば、
- 一般ユーザーから更新不可
- アプリケーション管理者でも簡単に削除できない
- 別のログ基盤へ転送する
- バックアップする
- ログ変更自体も記録する
などの方法を検討します。
必要なレベルはシステムの重要度によって異なります。
ログの保存期間はどう決める？
ログの保存期間について、
「とりあえず永久保存」
とするのは必ずしも適切ではありません。
ログ量が増えると、
- ストレージ費用
- 検索性能
- バックアップ量
- 管理対象データ
も増えます。
一方、短期間で削除すると必要な調査ができない可能性があります。
そのため、
- 監査上必要な期間
- 社内規程
- 契約要件
- 法令上の要件
- インシデント調査に必要な期間
を確認して決めます。
例えば、
ログA：1年間
ログB：3年間
ログC：より長期
など、ログ種類によって保存期間を変える方法もあります。
ログに個人情報や機密情報を残しすぎない
変更履歴を残すからといって、すべての入力値を無条件にログへ出すのは注意が必要です。
例えば、
- パスワード
- 認証用秘密情報
- クレジットカード情報
- APIキー
など、ログへ残すべきではない情報があります。
また個人情報についても、
本当に変更前後の値まで保存する必要があるか
を確認します。
例えば、
電話番号が変更されたこと
だけ確認できれば十分なのか、
変更前の電話番号まで保存する必要があるのか
で設計は異なります。
ログも情報資産であるため、必要以上に機密情報を記録しないことが重要です。
CSV出力ログは特に検討したい
顧客管理・名簿管理などでは、CSV出力は情報持ち出しにつながりやすい操作です。
例えば、
顧客10,000件をCSV出力
した場合です。
ログとして、
出力日時
出力者
出力件数
検索条件
を記録しておけば、
誰が大量のデータを出力したか
を後から確認できます。
必要に応じて、
一定件数を超える出力
↓
管理者へ通知
といった仕組みも考えられます。
権限変更ログも重要
権限管理では、
現在誰が管理者か
だけでなく、
誰がその人を管理者にしたのか
も重要です。
例えば、
2026/07/30 14:00
操作：権限変更
実行者：admin01
対象：user123
変更前：一般ユーザー
変更後：管理者
というログです。
権限変更はシステム全体への影響が大きいため、通常のデータ変更とは分けて確認できるようにする方法があります。
承認履歴はデータ変更履歴と分けて考える
申請システムでは、
ステータスが
申請中
↓
承認済み
へ変更されたことだけ記録するより、
承認者：部長A
承認日時：7月30日 15:00
判断：承認
コメント：問題なし
と承認行為そのものを履歴として残す方が分かりやすくなります。
特に、
- 稟議
- 経費
- 契約
- 購買
などでは、誰が判断したのかが重要です。
操作ログ画面を作ると監査対応しやすい
ログをデータベースに保存していても、確認するたびにエンジニアへSQLを依頼する状態では運用しにくくなります。
必要に応じて、
操作ログ一覧
期間：2026/07/01〜2026/07/31
ユーザー：田中
操作：UPDATE
のように検索できる管理画面を作ります。
例えば、
- 日時
- ユーザー
- 操作
- 対象
- 詳細
を一覧表示します。
これにより、管理者や監査担当者が自分で確認しやすくなります。
監査ログと通知を組み合わせる
ログは、
後から確認する
ためだけに利用するとは限りません。
重要な操作が発生したときに通知することもできます。
例えば、
管理者権限付与
↓
管理責任者へ通知
顧客情報1万件CSV出力
↓
セキュリティ担当へ通知
ログイン失敗が大量発生
↓
管理者へ通知
といった仕組みです。
ログを蓄積するだけではなく、リスクの高い操作を検知する用途にも利用できます。
クラウドサービスのログも確認する
業務システムでは、自作したWebアプリケーションだけでなく、
- クラウド
- データベース
- 認証サービス
- ストレージ
- SaaS
など複数サービスを利用することがあります。
例えばアプリケーション側にログがなくても、クラウド側でアクセス履歴を確認できる場合があります。
そのため、
システム全体でどこに何のログが保存されているか
を整理することが重要です。
監査対応でログを準備するときによくある失敗
失敗1｜エラーログだけ残す
エラー調査はできますが、
誰が業務データを変更したか
を確認できません。
操作ログは別に考えます。
失敗2｜「更新した」という情報だけ残す
何を変更したのか分からない場合があります。
重要項目では変更前後も検討します。
失敗3｜ログイン履歴だけで十分だと思う
ログインしたことと、その後何を操作したかは別です。
重要操作も記録します。
失敗4｜CSV出力を記録しない
大量データを持ち出せる操作です。
情報の重要度によってログ対象とします。
失敗5｜管理者ならログを削除できる
ログの信頼性を損なう可能性があります。
ログ管理権限を分離する方法を検討します。
失敗6｜保存期間を決めていない
ログが無制限に増えたり、逆に必要なログが早期削除されたりします。
保存ルールを決めます。
失敗7｜検索できない
大量のログがあっても必要な情報を探せなければ監査対応に時間がかかります。
検索条件を設計します。
失敗8｜機密情報をそのままログへ出す
パスワードなど、本来保存すべきでない情報までログに残さないようにします。
監査対応のログに関するよくある質問
監査ではどんなログを確認されますか？
監査の種類や対象業務によって異なります。
一般的には、
- ログイン
- データ変更
- 権限変更
- 承認
- 重要データの出力
など、重要操作について誰が何をしたか確認できる状態が求められることがあります。
実際に必要なログは、適用される監査基準・契約・社内規程などを確認して決める必要があります。
変更前のデータも保存する必要がありますか？
すべてのデータで必須とは限りません。
重要なデータについて、変更経緯を後から確認する必要がある場合に検討します。
閲覧履歴も残すべきですか？
扱う情報によります。
機密情報や重要な個人情報では、誰が閲覧したかまで記録する場合があります。
一般的な情報まで全件保存するとログ量が増えるため、重要度に応じて判断します。
ログは何年間保存すればよいですか？
一律の期間はありません。
対象となる監査・業務・契約・法令・社内規程などによって決めます。
ログをCSVで出力できるようにした方がよいですか？
監査資料として提出・分析する必要がある場合は便利です。
ただしログ自体にも機密情報が含まれる場合があるため、出力権限を制限します。
一般ユーザーにも自分の操作履歴を見せるべきですか？
業務によります。
一般ユーザー向けの履歴と、管理者・監査担当向けの監査ログを分ける方法もあります。
hiro-dev-labでは監査ログ・操作履歴の設計から相談できます
hiro-dev-labでは、Webシステムの開発だけでなく、どの操作をログへ残すべきか整理する段階から相談できます。
例えば、
- 業務フロー整理
- 重要データの整理
- 操作ログ要件整理
- ログイン履歴
- データ変更履歴
- 承認履歴
- 権限変更履歴
- CSV出力履歴
- ファイルダウンロード履歴
- ログ検索画面
- ログ閲覧権限
- 保存期間の整理
- 要求整理
- 業務要件・機能要件整理
- Webシステム設計・開発
などです。
例えば、
誰が顧客情報を変更したか確認できるようにしたい
管理者権限を変更した履歴を残したい
CSV出力した人を確認できるようにしたい
監査を見据えて操作ログを設計したい
という場合でも、
重要な業務 → 重要なデータ → 重要な操作 → 必要なログ → 保存・検索方法
の順番で整理できます。
まとめ｜監査対応のログは「誰が・いつ・何をしたか」を後から説明できるようにする
監査ログを設計するとき、
「ログをたくさん残しておけばよい」
という考え方だけでは十分ではありません。
まず、
- 何の操作を確認する必要があるのか
- 誰が操作したか特定できるか
- いつ操作したか分かるか
- どのデータに対する操作か分かるか
- 何が変更されたか分かるか
- どのくらい保存する必要があるか
- ログ自体を誰が閲覧・変更できるか
を整理します。
特に業務システムでは、
- ログイン
- データ登録
- データ変更
- データ削除
- 承認・差し戻し
- 権限変更
- CSV出力
- ファイルダウンロード
などを検討します。
そして重要なのは、
障害調査用のログと、業務操作を追跡する監査ログを混同しないこと
です。
例えば、
「システムがエラーになった原因」
を調べるログと、
「誰が契約金額を変更したのか」
を調べるログでは、必要な情報が異なります。
監査対応を考えるなら、
誰が・いつ・何に対して・どの操作を行い・必要であれば何が変わったのか
まで確認できる状態を目指します。
「監査に備えてどのログを残せばよいか分からない」
「操作履歴を後から確認できるようにしたい」
「権限変更やCSV出力も記録したい」
という場合は、まずシステム内で『後から説明できなければ困る操作』を一覧化するところから始めてみてください。