はじめに
企業では、さまざまな情報システムが利用されています。
例えば、
会計システム
人事システム
販売管理システム
顧客管理システム
社内ネットワーク
クラウドサービス
などです。
しかし、システムが動いているからといって、
問題なし！
とは限りません。
例えば、
アクセス権限は
適切に設定されている？
重要なデータは
バックアップされている？
障害が発生したときの
復旧手順はある？
システムの変更は
適切に承認されている？
ルールどおりに
運用されている？
といったことも確認する必要があります。
そこで登場するのが、
システム監査（System Audit）
です。
今回は、
システム監査
│
├─ システム監査の枠組み
│ ├─ システム監査とは
│ ├─ システム監査の流れ
│ └─ システム監査基準
│
├─ システム監査の実施
│ ├─ 予備調査
│ ├─ 本調査
│ └─ 評価・結論
│
└─ 情報システムの監査性
という流れで学んでいきましょう。
システム監査の枠組み
1. システム監査とは
システム監査とは、
情報システムに関するリスクへの対応が適切に行われているかなどを、独立した立場から点検・評価し、必要に応じて改善を促す活動
です。
例えば、
会社
│
├─ システムを開発
├─ システムを運用
└─ セキュリティ対策
↓
システム監査
↓
適切に行われている？
というイメージです。
2. なぜシステム監査が必要なのか
システムを開発・運用している担当者自身が、
自分たちの運用は
完璧です！
と言っても、それだけでは十分とは限りません。
本人たちが気付いていない問題が存在する可能性があります。
例えば、
バックアップは取っている
でも……
復元できるか確認していない
というケースです。
また、
退職した社員の
アカウントが残っている
変更作業の
承認記録が残っていない
管理者権限を
多くの人が持っている
といった問題が見つかることもあります。
そこで、
客観的な立場から情報システムやその管理状況を確認する
ことが重要になります。
3. システム監査人
システム監査を行う人を、
システム監査人
といいます。
システム監査人には、
客観性や独立性
が重要です。
例えば、
自分が設計したシステム
↓
自分で監査
↓
「問題ありません！」
では、客観的な評価が難しくなる可能性があります。
そのため、
監査対象から独立した立場で、公正かつ客観的に判断する
ことが重要です。
4. システム監査人は「作業担当者」ではない
ここは試験でも重要です。
監査で問題が見つかったとします。
例えば、
監査結果
「退職者のアカウントが
削除されていない」
この場合、監査人が勝手に、
アカウントを
削除しておきました！
とするのが監査の役割ではありません。
監査人は、
問題を発見
↓
評価
↓
指摘・改善提言
↓
監査対象部門などが対応
という立場です。
つまり、
監査人は自ら業務を改善する担当者ではなく、評価して改善を促す立場
と考えましょう。
システム監査の流れ
5. システム監査はどう進む？
システム監査は、大まかには、
監査計画
↓
予備調査
↓
本調査
↓
評価
↓
監査意見・結論
↓
監査報告
↓
必要に応じてフォローアップ
という流れで進みます。
いきなりシステムを調べ始めるのではなく、
何を、どのような方法で監査するのか
を計画したうえで調査します。
6. 監査計画
まず、
監査計画
を作成します。
例えば、
監査目的
→ 情報セキュリティ管理状況を確認する
監査対象
→ 社内の顧客管理システム
監査期間
→ 10月1日〜10月31日
監査方法
→ 資料確認・ヒアリング・現場確認
といった内容を決めます。
つまり、
何のために？
何を？
いつ？
どうやって？
を決める段階です。
システム監査基準
7. システム監査基準とは
システム監査を行うときには、
システム監査基準
という重要な考え方があります。
システム監査基準は、
システム監査を適切に実施するための基本的な事項を示すもの
です。
監査人が好き勝手な方法で監査するのではなく、一定の考え方に基づいて監査を実施するための基準になります。
8. 監査では客観性が重要
例えば監査人が、
なんとなく危なそうなので
問題ありです
と判断しても、説得力がありません。
監査では、
基準
＋
事実
＋
監査証拠
↓
客観的な評価
という考え方が重要です。
つまり、
「私はこう思う」ではなく、「確認した事実・証拠に基づくとこう評価できる」
という形で判断します。
システム監査の実施
9. 予備調査とは
監査計画を作成したら、監査対象について調査していきます。
まず行われるのが、
予備調査
です。
予備調査では、
本格的な調査を行う前に、監査対象の概要や状況を把握する
ことが目的です。
10. 予備調査では何をする？
例えば、
組織図
業務フロー
システム構成図
運用手順書
社内規程
過去の障害記録
過去の監査結果
などを確認します。
担当者へヒアリングすることもあります。
例えば、
監査人
「このシステムは
どんな業務で使いますか？」
担当者
「顧客情報の管理に使います」
といった形です。
11. なぜ予備調査が必要なのか
いきなり細かいところまで調査すると、
何が重要なの？
どこにリスクがある？
何を重点的に見る？
が分からなくなります。
そこで予備調査によって、
監査対象を理解
↓
リスクの高い部分を把握
↓
重点的に確認する項目を決定
↓
本調査
と進めます。
🍯 予備調査は「いきなり犯人を探す」のではなく、「まず現場の地図を作る」イメージです。
本調査
12. 本調査とは
本調査では、
予備調査などをもとに、監査対象について具体的な証拠を収集し、実際の管理状況を詳しく確認する
ことになります。
例えば、
アクセス権限一覧を確認
ログを確認
承認記録を確認
設定内容を確認
担当者へ質問
実際の運用状況を観察
などを行います。
13. 質問するだけでは不十分
例えば監査人が、
監査人
「バックアップしていますか？」
担当者
「はい！毎日しています！」
と聞いたとします。
これだけで、
問題なし！
と判断するのは危険です。
そこで、
バックアップログ
実行履歴
設定内容
復元テスト記録
などを確認します。
つまり、
担当者の説明だけではなく、裏付けとなる証拠を確認する
ことが重要です。
監査証拠
14. 監査証拠とは
監査による判断の根拠になる情報を、
監査証拠
といいます。
例えば、
システムログ
アクセス記録
申請書
承認記録
契約書
設定ファイル
議事録
担当者へのヒアリング結果
などです。
15. なぜ監査証拠が重要なのか
例えば、
このシステムは
セキュリティ対策が
できていません！
と監査人が報告したとします。
当然、
なぜそう判断したの？
と聞かれます。
そこで、
確認した事実
↓
監査証拠
↓
評価
↓
監査結果
という関係が重要になります。
監査人の感覚ではなく、
十分かつ適切な監査証拠に基づいて判断する
必要があります。
評価・結論
16. 調査した結果を評価する
本調査で監査証拠を集めたら、その結果を評価します。
例えば、
社内ルール
「退職時にアカウントを削除する」
↓
監査証拠
「退職者5人のアカウントが残っている」
↓
評価
「アカウント管理が
適切に実施されていない」
という形です。
つまり、
あるべき状態
↕
実際の状態
を比較して問題点を明らかにします。
17. 監査の結論
監査人は調査・評価した結果に基づいて、
監査意見や結論
をまとめます。
例えば、
問題点
↓
退職者アカウントが残っている
リスク
↓
不正アクセスに利用される可能性
改善提言
↓
退職手続とアカウント削除を連携させる
という形です。
そして、監査結果を監査報告書などとして関係者へ報告します。
18. 改善提言
システム監査では、問題点を見つけるだけでなく、
必要に応じて改善のための提言を行う
ことも重要です。
例えば、
問題
「アクセス権限の
定期確認がない」
↓
改善提言
「半年ごとに
アクセス権限を棚卸しする」
といった形です。
ただし、
改善策を実施する責任は監査対象側にあります。
監査人自身が業務の責任者として改善作業を実施するわけではありません。
19. フォローアップ
監査で改善を求めても、
報告書を出したから
終わり！
では十分ではありません。
必要に応じて、
改善提言
↓
改善計画
↓
改善活動
↓
フォローアップ
↓
ちゃんと改善された？
と確認します。
これをフォローアップといいます。
情報システムの監査性
20. 監査性とは
ここまで見てきたように、システム監査では、
ログ
記録
証拠
処理履歴
などを確認します。
そこで重要になるのが、
監査性（Auditability）
です。
監査性とは、
情報システムの処理や管理状況について、後から追跡・検証し、監査できる性質
と考えると分かりやすいです。
21. 監査性が低いシステム
例えば、ある重要なデータが変更されていたとします。
しかし、
誰が変更した？
→ 分からない
いつ変更した？
→ 分からない
変更前は何だった？
→ 分からない
なぜ変更した？
→ 記録なし
だったらどうでしょうか。
これでは、
後から正しく処理されたか確認できません。
つまり、監査性が低い状態です。
22. 監査性が高いシステム
一方、
ユーザー
→ Yamada
操作
→ 顧客情報変更
日時
→ 2026/10/08 15:32
変更前
→ A
変更後
→ B
承認者
→ Tanaka
のような記録が残っていれば、
誰が？
いつ？
何を？
どのように？
適切な承認を受けた？
を後から確認できます。
つまり、
処理を追跡・検証できる
ということです。
23. ログと監査証跡
監査性を確保するうえで重要なのが、
ログ（Log）
や、
監査証跡（Audit Trail）
です。
監査証跡とは、
システム上の処理や操作を後から追跡できるように残された記録
です。
例えば、
ログイン
↓
データ参照
↓
データ変更
↓
承認
↓
ログアウト
という一連の記録が残っていれば、
何が起きたのかを後からたどる
ことができます。
24. 監査性を確保する仕組み
監査性を高めるためには、例えば、
- アクセスログを記録する
- 操作履歴を記録する
- 変更履歴を保存する
- 承認記録を残す
- ログを適切な期間保存する
- ログが勝手に改ざんされないよう保護する
- 日時を正確に記録する
といった仕組みが重要です。
例えばログが残っていても、
利用者が自由に
ログを書き換えられる
のであれば、証拠としての信頼性が低くなってしまいます。
25. 「ログがある＝監査性が高い」ではない
ここも重要です。
単に、
ログを取っています！
だけでは十分ではありません。
例えば、
誰が操作したか分からない
必要な操作が記録されていない
時刻がずれている
ログがすぐ削除される
ログを自由に改ざんできる
のであれば、監査に利用しにくいですよね。
そのため、
必要な情報が正確に記録され、適切に保存・保護され、後から追跡できること
が重要です。
26. システム監査の全体像
今回の内容をまとめると、
情報システム
↓
システム監査
│
├─ 監査計画
│ └─ 何を・なぜ・どう調べる？
│
├─ 予備調査
│ └─ 監査対象を理解する
│
├─ 本調査
│ └─ 詳細に確認する
│ ↓
│ 監査証拠
│
├─ 評価
│ └─ 基準と実態を比較する
│
├─ 結論
│ ├─ 監査意見
│ └─ 改善提言
│
├─ 監査報告
│
└─ フォローアップ
└─ 改善状況を確認する
そして、この監査を適切に行えるようにするため、
情報システム
│
├─ ログ
├─ 操作履歴
├─ 変更履歴
├─ 承認記録
└─ 監査証跡
↓
後から追跡・検証できる
↓
監査性
が重要になります。
まとめ
この記事で覚えること
- システム監査では、情報システムに関する管理状況などを独立した立場から点検・評価する
- システム監査人には客観性や独立性が重要
- 監査人は自ら改善作業を行う担当者ではなく、評価して改善を促す立場
- システム監査は、監査計画・予備調査・本調査・評価・結論・報告などの流れで進める
- システム監査基準は、システム監査を適切に実施するための基本的な事項を示す
- 予備調査では、監査対象の概要や状況を把握する
- 本調査では、具体的な監査証拠を収集して詳細に確認する
- 監査証拠は、監査人が評価・結論を導くための根拠となる
- 評価では、基準やあるべき状態と実際の状態を比較する
- 必要に応じて改善提言を行い、その後フォローアップを行う
- 監査性とは、情報システムの処理や管理状況を後から追跡・検証できる性質
- ログや監査証跡は監査性を確保するために重要
- ログは残すだけでなく、正確性・保存・保護なども重要
🍯 はちみつメモ
システム監査は「独立した立場から、証拠を集めて、客観的に評価する」と覚えよう。流れは「計画 → 予備調査 → 本調査 → 評価・結論 → 報告」。そして監査人は問題を自分で直す人ではなく、問題を指摘して改善を促す人。監査性は「後から誰が・いつ・何をしたか追えるか」がポイント！