はじめに：なぜ今、システム監査が重要なのか

企業のIT依存度が高まる中、システム監査の重要性は年々増しています。経済産業省の調査によると、国内企業の約87%が「基幹業務システムなしでは事業継続が不可能」と回答しており、システムの信頼性確保は経営課題そのものと言えます。

本記事では、システム監査を初めて担当する方から、より効率的な監査手法を模索しているベテランの方まで、実務で即活用できる監査手順を体系的に解説します。計画立案から報告書作成まで、各フェーズで押さえるべきポイントを具体例とともに紹介していきます。

システム監査とは何か：基本概念の整理

システム監査の定義と目的

システム監査とは、情報システムのリスクに対するコントロール（統制）が適切に整備・運用されているかを、独立した立場から客観的に評価する活動です。経済産業省が公開している「システム監査基準」では、以下の3つの目的が示されています。

1. 信頼性：システムが正確に、安定して稼働しているか
2. 安全性：情報資産が適切に保護されているか
3. 効率性：経営資源が有効に活用されているか

近年は、これらに加えて**コンプライアンス（法令遵守）やガバナンス（統治）**の観点も重視されるようになっています。

内部監査と外部監査の違い

システム監査は実施主体によって大きく2種類に分けられます。

実務では、内部監査で発見した問題点を改善した上で、外部監査を受けるというサイクルが一般的です。

システム監査の全体フロー：8つのステップ

システム監査は、一般的に以下の8つのステップで進行します。各ステップの所要期間は、監査対象の規模や複雑さによって変動しますが、中規模システム（利用者500〜1000名程度）を想定した目安も併せて記載します。

1. 監査計画の策定（1〜2週間）
2. 予備調査の実施（1〜2週間）
3. 監査手続書の作成（1週間）
4. 本調査の実施（2〜4週間）
5. 監査証拠の評価（1週間）
6. 監査調書の作成（1週間）
7. 監査報告書の作成（1〜2週間）
8. フォローアップ（継続的）

以下、各ステップを詳しく解説していきます。

ステップ1：監査計画の策定

監査計画書に含めるべき要素

監査計画書は、監査活動の「設計図」となる重要なドキュメントです。以下の項目を必ず含めましょう。

基本情報

• 監査テーマ・目的
• 監査対象システム・業務範囲
• 監査期間（開始日〜終了日）
• 監査チームの構成と役割分担

監査アプローチ

• 準拠する基準（システム監査基準、COBIT、ISO 27001等）
• 重点監査項目
• 採用する監査技法
• サンプリング方針

リソース計画

• 必要工数（人日）の見積もり
• 予算（外部専門家の活用等）
• 必要なツール・環境

リスクアプローチに基づく計画立案

限られたリソースで効果的な監査を行うには、リスクアプローチの採用が不可欠です。これは、リスクの高い領域に監査資源を集中させる考え方です。

リスク評価の観点（例）

これらの要因を点数化し、総合スコアの高いシステムを優先的に監査対象とします。

実務ポイント：監査計画は経営層の承認を得ることで、監査活動への協力を組織全体に周知する効果があります。承認プロセスを省略しないようにしましょう。

ステップ2：予備調査の実施

予備調査の目的

予備調査は、本調査を効率的に進めるための情報収集フェーズです。監査対象システムの概要を把握し、重点的に調査すべき領域を特定します。

予備調査で収集すべき情報

システム概要に関する情報

• システム構成図（ネットワーク図、サーバー構成図）
• 業務フロー図
• データフロー図（DFD）
• システム仕様書、運用手順書

管理体制に関する情報

• 組織図、職務分掌
• IT関連規程・手順書一覧
• 委託先一覧と契約内容

運用状況に関する情報

• インシデント報告一覧（過去1〜2年分）
• 変更管理記録
• アクセスログの保存状況
• バックアップ実施記録

予備調査の実施方法

予備調査では、主に以下の方法で情報を収集します。

1. ドキュメントレビュー：既存文書の閲覧・分析
2. ヒアリング：IT部門責任者、システム管理者へのインタビュー
3. ウォークスルー：実際のオペレーションの観察

実務ポイント：予備調査の段階で現場とのコミュニケーションを十分に取ることで、本調査時の協力を得やすくなります。「監査は敵ではなく、改善のパートナー」という姿勢を示しましょう。

ステップ3：監査手続書の作成

監査手続書とは

監査手続書は、本調査で実施する具体的な監査手続を文書化したものです。「何を」「どのように」「どこまで」確認するかを明確にします。

監査手続書の構成要素

1. 監査項目（何を確認するか）

例：「アクセス管理」「変更管理」「バックアップ管理」など

2. 監査要点（どのような観点で確認するか）

例：アクセス管理の場合

• 最小権限の原則が適用されているか
• 定期的なアカウント棚卸が実施されているか
• 退職者のアカウントが速やかに削除されているか

3. 監査技法（どのような方法で確認するか）

主な監査技法には以下があります。

4. サンプリング基準

全件確認が現実的でない場合、サンプリングを行います。

• 統計的サンプリング：母集団から無作為に抽出
• 非統計的サンプリング：監査人の判断で抽出（リスクの高い取引等）

一般的な目安として、母集団100件に対して25件程度のサンプル、250件以上の場合は25〜60件程度が実務でよく使われます。

監査手続書のサンプル

監査項目：アクセス管理
監査要点：退職者のアカウント削除が適時に行われているか

監査手続：
1. 過去6ヶ月間の退職者リストを人事部門から入手する
2. 対象システムのアカウント一覧を取得する
3. 退職者リストとアカウント一覧を突合し、残存アカウントの有無を確認する
4. 残存アカウントがある場合、削除遅延の理由をヒアリングする

サンプリング：退職者全員（全数調査）
判断基準：退職日から5営業日以内に削除されていること

ステップ4：本調査の実施

本調査の進め方

本調査は、監査手続書に基づいて実際に監査証拠を収集するフェーズです。効率的に進めるためのポイントを解説します。

調査開始前のキックオフミーティング

本調査開始時には、被監査部門の責任者を含めたキックオフミーティングを実施します。以下の内容を共有しましょう。

• 監査の目的と範囲
• 調査スケジュール
• 必要な資料・システムアクセス権
• 連絡窓口の確認

日次での進捗管理

本調査中は、監査チーム内で日次ミーティングを実施し、以下を確認します。

• 当日の実施予定と前日の完了状況
• 発見事項の共有
• 追加で必要な資料・ヒアリングの有無
• スケジュールの遅延リスク

主要な監査領域と確認ポイント

IT全般統制（ITGC）の監査

IT全般統制は、システム全体に共通する基盤的なコントロールです。

1. アクセス管理

• ユーザーIDの発行・変更・削除手続の整備状況
• 特権ID（管理者権限）の管理状況
• パスワードポリシーの設定状況（文字数、複雑性、有効期限等）
• アクセスログの取得・保管状況

2. 変更管理

• 変更要求から本番適用までの承認フロー
• テスト環境での検証実施状況
• 本番移行手順の整備状況
• 緊急変更時の事後承認プロセス

3. 運用管理

• ジョブスケジュールの管理状況
• 異常検知時の対応手順
• インシデント管理プロセス
• バックアップ・リストアの実施状況

4. 開発管理

• 開発標準・コーディング規約の整備状況
• セキュリティレビューの実施状況
• 受入テストの実施状況

業務処理統制（アプリケーション統制）の監査

業務処理統制は、個別のアプリケーションに組み込まれたコントロールです。

入力統制

• 入力データのバリデーションチェック
• 重複入力の防止機能
• 入力担当者と承認者の分離

処理統制

• 計算ロジックの正確性
• マスターデータの整合性チェック
• エラーハンドリングの適切性

出力統制

• 出力帳票の配布先管理
• 機密情報の出力制御
• 出力データの改ざん防止

監査証拠の収集

監査証拠は、監査意見の根拠となる重要な資料です。以下の特性を満たす証拠を収集しましょう。

監査証拠の特性

• 十分性：結論を導くのに必要な量があるか
• 適切性：目的に合致した内容か
• 信頼性：情報源は信頼できるか

証拠の信頼性の序列（高い順）

1. 監査人が直接確認した事実
2. 外部から入手した文書
3. 内部で作成された文書（承認済み）
4. 内部で作成された文書（承認なし）
5. 口頭での説明

実務ポイント：監査証拠は必ずコピーを取得し、日付・入手元・入手方法を記録しておきましょう。後から「言った・言わない」のトラブルを防げます。

ステップ5：監査証拠の評価

発見事項の分類と重要性の判断

収集した監査証拠を分析し、発見事項を以下の観点で評価します。

1. コントロールの整備状況

• 規程・手順書は存在するか
• 内容は十分か（漏れ・矛盾はないか）

2. コントロールの運用状況

• 規程・手順書どおりに運用されているか
• 証跡は残されているか

3. 逸脱の重要性評価

発見した問題点は、その影響度によって分類します。

根本原因の分析

発見事項に対しては、表面的な現象だけでなく、根本原因を分析することが重要です。

5つのなぜ（5 Whys）による分析例

現象：退職者のアカウントが3ヶ月間削除されていなかった

• なぜ？→ IT部門に削除依頼が届いていなかった
• なぜ？→ 人事部門からの通知が遅れた
• なぜ？→ 退職者情報の連携ルールが不明確だった
• なぜ？→ 人事・IT間の連携手順が文書化されていなかった
• なぜ？→ 業務分掌の定義時に連携業務が考慮されていなかった

→ 根本原因：部門間連携業務の定義・文書化の不備

ステップ6：監査調書の作成

監査調書とは

監査調書は、監査の実施過程と結果を記録した一次資料です。監査報告書の根拠資料となり、将来の監査の参考資料としても活用されます。

監査調書に含める内容

必須項目

• 監査項目・監査要点
• 実施した監査手続の内容
• 入手した監査証拠（またはその参照先）
• 発見事項と結論
• 実施日・実施者の署名

品質管理のための項目

• レビュー者の確認署名
• レビュー時の指摘事項と対応内容

監査調書作成のポイント

1. 第三者が読んでも理解できる記述

監査調書は、作成者以外の人が読んでも、何をどのように確認し、どのような結論に至ったかが分かるように記述します。

悪い例 「アクセス管理について確認した。問題なし。」

良い例 「アクセス管理について、以下の手続を実施した。

1. 2026年1月〜3月の退職者15名のリストを人事部から入手
2. 対象システムのアカウント一覧（2026年4月1日時点）をシステム管理者から入手
3. 両者を突合した結果、15名全員のアカウントが削除されていることを確認
4. 削除タイミングを確認した結果、14名は退職日から5営業日以内、1名は8営業日後であった 結論：軽微な遅延が1件あったものの、重大な問題は認められない。」

2. 証拠との紐付け

監査調書には、関連する証拠資料の参照番号を必ず記載します。これにより、後から検証可能な状態を維持できます。

ステップ7：監査報告書の作成

監査報告書の構成

監査報告書は、監査結果を被監査部門および経営層に伝えるための公式文書です。以下の構成が一般的です。

1. 表紙
2. 目次
3. 監査概要
   - 監査目的
   - 監査範囲
   - 監査期間
   - 監査チーム
4. 総合評価
5. 指摘事項の概要（サマリー）
6. 指摘事項の詳細
   - 発見事項の内容
   - リスク・影響
   - 推奨する改善策
   - 被監査部門の見解・改善計画
7. 改善状況一覧（前回指摘事項のフォローアップ結果）
8. 添付資料

指摘事項の記載方法

指摘事項は、以下の「4点セット」で記載するのが効果的です。

1. 条件（Condition）：現状はどうなっているか 2. 基準（Criteria）：本来どうあるべきか 3. 原因（Cause）：なぜそうなったか 4. 影響（Consequence）：放置するとどうなるか

記載例

■ 指摘事項：特権IDのパスワード管理の不備

【条件】
サーバー管理用の特権ID（root、Administrator）のパスワードが、
IT部門の5名で共有されていることが判明した。パスワードは、
部門共有フォルダ内のExcelファイルに平文で記載されていた。

【基準】
当社「情報セキュリティ規程」第12条では、「特権IDは個人に
付与し、パスワードは暗号化して保管すること」と定められている。

【原因】
サーバー台数の増加に伴い、個人ごとのID付与が運用負荷に
なっていた。また、パスワード管理ツールの導入が検討されて
いたが、予算確保ができていなかった。

【影響】
・不正アクセスが発生した場合、行為者の特定が困難
・内部不正のリスク増大
・監査法人によるIT統制評価での不備指摘の可能性

【推奨する改善策】
1. 特権IDの個人付与への移行（短期）
2. パスワード管理ツールの導入（中期）
3. 特権IDの使用状況のモニタリング強化（並行実施）

【重要度】高
【改善期限】2026年6月末

報告会の実施

監査報告書の提出だけでなく、報告会を実施することで、指摘事項の背景や改善の重要性を直接伝えられます。

報告会の参加者（推奨）

• 経営層（担当役員）
• 被監査部門の責任者
• IT部門の責任者
• 監査チーム

報告会でのコミュニケーションポイント

• 良かった点（ポジティブな発見）も必ず伝える
• 指摘は「攻撃」ではなく「改善提案」として伝える
• 改善の優先順位と期限を明確にする
• 被監査部門の質問・意見に丁寧に対応する

ステップ8：フォローアップ

フォローアップの重要性

監査は報告書の提出で終わりではありません。指摘事項が適切に改善されているかを確認するフォローアップが不可欠です。フォローアップなき監査は「やりっぱなし」であり、監査の価値を大きく損なうことになります。

フォローアップの方法

1. 改善計画書の入手

監査報告後、被監査部門から改善計画書を入手します。計画書には以下を含めます。

• 指摘事項ごとの改善内容
• 責任者
• 完了予定日
• 必要なリソース

2. 定期的な進捗確認

改善期限までの間、定期的（月次等）に進捗を確認します。

3. 改善完了の検証

改善完了の報告を受けたら、実際に改善されているかを検証します。文書の改訂であれば改訂版の確認、運用変更であれば証跡の確認を行います。

4. 次回監査計画への反映

改善が完了しない項目や、新たに発見したリスクは、次回の監査計画に反映します。

よくある質問（FAQ）

Q1：監査未経験者がシステム監査を担当することになりました。最初に何をすべきですか？

**A1：**まず、以下の3つのステップで準備を進めることをお勧めします。

ステップ1：基準・ガイドラインの理解

経済産業省の「システム監査基準」と「システム管理基準」を一読しましょう。全て暗記する必要はありませんが、監査の目的や基本的な考え方を理解することが重要です。

ステップ2：過去の監査資料の確認

社内に過去の監査報告書や監査調書があれば、それらを読むことで実際の監査イメージをつかめます。特に、監査手続書は実務で即活用できる参考資料になります。

ステップ3：OJTでの経験蓄積

可能であれば、最初は経験者の監査に同行し、インタビューの進め方や証拠収集の方法を学びましょう。最初から単独で完璧な監査を行う必要はありません。

また、「システム監査技術者試験」の参考書は、体系的な知識習得に役立ちます。資格取得を目指さなくても、学習教材として活用する価値があります。

Q2：被監査部門が非協力的な場合、どう対応すべきですか？

**A2：**被監査部門の非協力は、多くの監査人が経験する課題です。以下のアプローチを試してみてください。

1. 監査の目的を正しく伝える

被監査部門が非協力的になる原因の多くは、「監査＝あら探し」という誤解です。監査の目的が「組織のリスク低減と業務改善の支援」であることを丁寧に説明しましょう。

2. 経営層からのトップダウン

監査計画の段階で経営層の承認を得ていれば、その事実を伝えることで協力を得やすくなります。それでも改善しない場合は、監査責任者から経営層に状況を報告し、対応を依頼することも選択肢です。

3. 負担の軽減

被監査部門の本業が繁忙期である場合、監査対応が負担になっている可能性があります。可能な範囲でスケジュールを調整したり、資料要求を効率化したりする配慮も必要です。

4. 小さな成功体験を作る

監査で発見した改善点が、実際に被監査部門の業務効率化やリスク低減につながった事例を共有することで、監査への信頼感を醸成できます。

Q3：システム監査と情報セキュリティ監査は何が違うのですか？

**A3：**両者は重複する部分が多いですが、主に以下の点で異なります。

システム監査

• 目的：情報システムの信頼性・安全性・効率性の評価
• 対象：情報システム全般（開発、運用、管理）
• 準拠基準：システム監査基準、COBIT等
• 特徴：ITガバナンス、業務効率性も評価対象

情報セキュリティ監査

• 目的：情報資産の機密性・完全性・可用性の評価
• 対象：情報セキュリティマネジメント
• 準拠基準：情報セキュリティ監査基準、ISO 27001等
• 特徴：セキュリティリスクに特化した深い評価

実務では、両者を明確に分離せず、「情報システムに関する監査」として包括的に実施するケースも多くあります。どちらの基準を主に準拠するかは、監査の目的や組織の方針によって決定します。

まとめ：効果的なシステム監査のために

本記事では、システム監査の手順を計画から報告書作成、フォローアップまで解説しました。最後に、効果的なシステム監査を実現するための重要ポイントをまとめます。

5つの成功要因

1. リスクベースのアプローチ

限られたリソースを有効活用するため、リスクの高い領域に監査資源を集中させましょう。全てを均等