変更要約: 初版（第5章・s1-s3）
5.3システム監査と内部統制
監査プロセス（監査計画・実施・報告・フォローアップ）、監査証拠（十分性・適切性）と監査技法（ヒアリング・ドキュメントレビュー・現地調査・CAAT）、内部統制（IT統制＝IT全般統制と業務処理統制・職務分掌）、可監査性、監査人の独立性を学びます。
システム監査は、独立した第三者の立場から情報システムが組織の目的に沿って適切に統制されているかを評価する活動です。応用情報では、監査プロセスの各工程の役割、内部統制（特にIT全般統制と業務処理統制の違い、職務分掌）、そして監査人の独立性（自己監査の禁止）が理解を問う形で繰り返し出題されます。
5.3.1監査プロセスと監査証拠・監査技法
- システム監査のプロセス＝監査計画（対象範囲・監査項目・スケジュールの策定）→監査の実施（証拠収集・評価）→監査報告（指摘事項・改善勧告を経営者に報告）→フォローアップ（指摘事項が改善されたか事後確認）の4段階で進みます。フォローアップまで含めて初めて監査サイクルが完結する点が重要です。
- 監査証拠は十分性（quantity・量的な裏付けの充分さ）と適切性（quality・証拠としての質の高さ・関連性と信頼性）の両方を満たす必要があります。量が多くても質の低い証拠だけでは監査意見の根拠として不十分です。監査技法＝ヒアリング（聞き取り）・ドキュメントレビュー（規程・記録の確認）・現地調査（現場の実地確認）・CAAT（コンピュータ支援監査技法）（ツール/ソフトウェアでログ・データを機械的に分析）を目的に応じて組み合わせます。
5.3.2内部統制：IT全般統制・業務処理統制・職務分掌
- 内部統制＝組織の業務が適正に遂行されるよう、組織自らが構築・運用する仕組み全般（不正防止・業務の有効性・財務報告の信頼性・法令遵守などを目的とする）。IT統制はこのうちITに関わる部分で、IT全般統制と業務処理統制（IT業務処理統制）に大別されます。
- IT全般統制＝特定の業務処理に限らずIT環境全体を横断的に支える統制（アクセス管理、システム開発・変更管理、運用管理、外部委託管理など）。業務処理統制（IT業務処理統制）＝個別の業務アプリケーションに組み込まれた統制（入力チェック、承認機能、エラー検知、自動計算の正確性など）。IT全般統制が有効に機能していない場合、個々の業務処理統制の信頼性の前提そのものが揺らぐという階層関係（全般統制が個別統制の土台）を理解します。
- 職務分掌＝1人の担当者に権限や作業が集中しないよう、業務を複数の担当者・役割に分離する内部統制の代表例（例：申請者と承認者を別人にする）。主目的は権限の集中を避け不正・ミスを防止することで、業務効率化はむしろトレードオフとして生じ得ます。
「監査プロセス＝計画→実施→報告→フォローアップ」「監査証拠＝十分性(量)と適切性(質)の両方が必要」「IT全般統制＝IT環境全体横断、業務処理統制＝個別アプリケーションに組込み」「職務分掌＝権限分離による不正・ミス防止（効率化が主目的ではない）」が最頻出です。IT全般統制と業務処理統制の対象範囲（横断的か個別的か）を取り違える誤答パターンが典型的です。
ある企業の経費精算システムのシステム監査を例に、プロセスと内部統制のつながりを追ってみます。監査計画の段階で、監査人は「経費承認プロセスに不正防止の統制が機能しているか」を監査項目に設定し、対象範囲とスケジュールを決めます。ここで重要なのは誰を監査人に選ぶかで、このシステムを開発した当のエンジニアが監査人になれば自己監査となり独立性が損なわれるため、開発・運用に関与していない別の人物を監査人に選任します。監査の実施段階では複数の監査技法を組み合わせて証拠を集めます。まずドキュメントレビューで経費承認規程を確認し、「申請者と承認者は別人でなければならない」という職務分掌のルールが規程上明記されているかを確認します。次にヒアリングで経費精算担当者に、規程どおりの運用が実際になされているかを尋ねます。さらにCAATでシステムのログを分析し、「申請者と承認者が同一人物になっている取引」を機械的に検出します。調査の結果、ある期間、承認者欄が空欄のまま処理された取引が多数見つかったとすると、これは業務処理統制（承認機能というアプリケーションに組み込まれた統制）が形骸化していたことを示す重大な指摘事項になります。さらに深掘りすると、そもそもこのシステムの変更管理（IT全般統制の一部）が緩く、承認欄を必須項目にする改修が長期間放置されていたことが判明したとすると、個別の業務処理統制の不備の根本原因が、より上位のIT全般統制の弱さにあるという構造が見えてきます。この場合、ログが申請者・承認者・処理日時を正確に記録し追跡可能だったからこそ問題を検出できたのであり、これはシステムの可監査性の高さの表れです。監査報告の段階でこの指摘事項と改善勧告（承認欄の必須化などのシステム改修）を経営者に報告し、フォローアップの段階で実際に改修され職務分掌が機能する状態に戻ったかを事後確認して、監査サイクルが完結します。
| 統制の種類 | 対象範囲 | 具体例 |
|---|---|---|
| IT全般統制 | IT環境全体を横断的に支える | アクセス管理・変更管理・運用管理 |
| 業務処理統制 | 個別の業務アプリケーションに組込み | 入力チェック・承認機能・自動計算の正確性 |
ひっかけ： 「システムを開発したエンジニア自身がそのシステムを監査するのが最も効率的で望ましい」は誤りです。開発の当事者が監査人になる自己監査は独立性を損なうため避けるべきです。また「職務分掌の主目的は業務を効率化することである」も誤り＝主目的は権限の集中を避け不正・ミスを防止することで、効率化はむしろトレードオフとして生じ得ます。さらに「業務処理統制はIT環境全体を横断的に支える統制であり、IT全般統制は個別アプリケーションに組み込まれた統制である」も誤り＝範囲が逆で、正しくはIT全般統制＝横断的、業務処理統制＝個別アプリケーション組込みです。
5.3.3この節のまとめ
- システム監査のプロセス＝監査計画→実施→報告→フォローアップ。監査証拠は十分性（量）と適切性（質）の両方が必要
- IT全般統制＝IT環境全体を横断的に支える統制、業務処理統制＝個別アプリケーションに組込みの統制。全般統制が個別統制の土台という階層関係
- 職務分掌＝権限・作業の分離で不正/ミス防止（効率化が主目的ではない）。監査人の独立性＝監査対象から独立した客観的立場（自己監査は不可）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 自社の経費精算システムを開発したエンジニアBが、そのシステムのシステム監査の監査人を務めることになった。この体制について最も適切な指摘はどれか。
Q2. システム監査で、アクセス管理・変更管理・運用管理などIT環境全体を横断的に支える統制と、経費精算アプリケーションの承認機能のように個別の業務アプリケーションに組み込まれた統制とを区別したい。前者を指す用語はどれか。
Q3. システム監査人が、監査対象システムのアクセスログを専用ツールで機械的に分析し、承認者フィールドが空欄のまま処理された取引を検出した。この証拠収集方法に該当する監査技法はどれか。