変更要約: 初版（第5章・s1-s5）
5.5システム監査
システム監査のプロセス（監査計画・監査の実施・監査報告・フォローアップ）、監査証拠・監査技法（ヒアリング・ドキュメントレビュー・現地調査・コンピュータ支援監査技法）、内部統制（IT統制・職務分掌）、可監査性、そして監査人の独立性を学びます。
システム監査は、情報システムが組織の目標に沿って適切に整備・運用されているかを、開発や運用の当事者とは異なる立場から検証する活動です。「誰が・何を根拠に・どう検証するか」という監査の型と、監査を成立させる前提である内部統制と独立性の考え方を押さえます。
5.5.1監査プロセスと監査証拠・監査技法
- システム監査のプロセス＝監査計画（対象範囲・監査項目・スケジュールの策定）→監査の実施（証拠収集・評価）→監査報告（結果を監査報告書として経営者等に報告）→フォローアップ（指摘事項が改善されたか事後確認）という順で進みます。
- 監査証拠＝監査人が結論を導くための客観的な根拠資料（議事録・ログ・帳票・設定ファイル等）。監査人はこの証拠に基づいて監査意見を形成するため、証拠の十分性（量）と適切性（質）の両方が求められます。
- 監査技法＝証拠を収集する具体的な方法。ヒアリング（インタビュー法）＝担当者への聞き取り。ドキュメントレビュー（チェックリスト法）＝規程やマニュアル等の文書を確認。現地調査（視察法）＝実際の作業現場を訪れて確認。コンピュータ支援監査技法（CAAT）＝監査人がツール・ソフトウェアを用いてログやデータを分析する技法。目的や対象に応じて複数の技法を組み合わせます。
5.5.2内部統制・可監査性・監査人の独立性
- 内部統制＝組織が業務の適正・有効性、財務報告の信頼性、法令遵守などの目標を達成するために、組織内に整備・運用する仕組み全般。IT統制＝内部統制のうちIT（情報システム）に関わる部分で、全般統制（システム全体に共通する統制。アクセス管理・変更管理等）と業務処理統制（個別業務システムに組み込まれた統制。入力チェック等）に大別されます。
- 職務分掌＝1人の担当者に権限や作業が集中しないよう、業務を複数の担当者・役割に分離する内部統制の代表的な仕組み。例えば「取引の申請者」と「承認者」を別の人物にすることで、不正やミスを1人だけでは完結できないようにします。権限の集中は不正リスクを高めるため、職務分掌はIT統制・業務統制を問わず広く要求されます。
- 可監査性＝システムが監査（証拠収集・検証）を行いやすい構造になっているかという性質。ログが十分に記録され、処理の過程が追跡可能であるほど可監査性が高いとされます。監査人の独立性＝監査人が監査対象の業務・組織から独立した立場で、利害関係にとらわれず客観的に評価できることを指します。自らが開発・運用した対象を自分で監査すること（自己監査）は独立性を損なうため避けるべきとされます。
「監査プロセス＝計画→実施→報告→フォローアップ」「監査証拠は十分性と適切性の両方が必要」「職務分掌＝権限や作業を複数人に分離し不正・ミスを防ぐ」「監査人の独立性＝監査対象から独立した客観的立場、自己監査は不可」が最頻出です。自分が開発したシステムを自分で監査する「自己監査」を独立性の問題として認識できるかが典型的な出題ポイントです。
ある企業の経費精算システムに対するシステム監査を例に、一連の流れを追ってみます。まず監査計画の段階で、監査人は「経費精算の承認プロセスに不正防止の統制が機能しているか」を監査項目に定め、対象範囲とスケジュールを決めます。ここで重要なのが監査人の選定で、もしこのシステムの開発を担当したエンジニア自身が監査人になってしまうと、これは自己監査にあたり独立性が損なわれるため、開発・運用に関与していない別の要員が監査人として選ばれます。監査の実施段階では、複数の監査技法を組み合わせて証拠を集めます。まず経費精算の承認規程をドキュメントレビューで確認し、「申請者と承認者は別人でなければならない」という職務分掌のルールが規程上定められているかを確かめます。次に経理部門の担当者にヒアリングを行い、実際の運用で規程通りに運用されているかを聞き取ります。さらにコンピュータ支援監査技法（CAAT）を用いて、システムのログを分析し、「同一人物が申請者と承認者を兼ねている取引が存在しないか」を機械的に検出します。もし調査の結果、ある特定の期間だけ承認者フィールドが空欄のまま処理が通っていた取引が多数見つかったとすると、これは職務分掌の統制が形骸化していたという重大な指摘事項になります。この場合、ログが正確に記録され取引ごとに申請者・承認者・日時が追跡できたからこそ問題を検出できたのであり、これは可監査性が高いシステムであったことの裏返しでもあります。監査報告の段階では、この指摘事項と改善勧告（承認者フィールドを必須項目にするシステム改修等）を監査報告書としてまとめ経営者に報告し、その後のフォローアップで実際にシステム改修が行われ、職務分掌が機能する状態に戻ったかを再確認して、一連の監査サイクルが完結します。
| 工程 | 内容 |
|---|---|
| 監査計画 | 対象範囲・監査項目・スケジュールの策定 |
| 監査の実施 | ヒアリング/ドキュメントレビュー/現地調査/CAATで証拠収集・評価 |
| 監査報告 | 指摘事項・改善勧告を監査報告書として経営者に報告 |
| フォローアップ | 指摘事項が改善されたか事後確認 |
ひっかけ： 「システムを開発したエンジニア自身がそのシステムを監査するのが最も効率的で望ましい」は誤りです。開発の当事者が監査人になる自己監査は独立性を損なうため避けるべきです。また「職務分掌の目的は業務を効率化することである」も誤り＝職務分掌の主目的は権限の集中を避け不正・ミスを防止することで、効率化はむしろトレードオフとして生じ得ます。さらに「監査証拠は量さえ多ければ十分性・適切性を満たす」も誤り＝十分性（量）と適切性（質）は別の観点であり、量が多くても質の低い証拠だけでは監査意見の根拠として不十分です。
5.5.3この節のまとめ
- システム監査のプロセス＝監査計画→実施→報告→フォローアップ。監査証拠は十分性（量）と適切性（質）の両方が必要
- 監査技法＝ヒアリング・ドキュメントレビュー・現地調査・CAAT（機械的なログ/データ分析）を目的に応じて組み合わせ
- 職務分掌＝権限・作業の分離で不正/ミス防止（IT統制の代表例）。監査人の独立性＝監査対象から独立した客観的立場（自己監査は不可）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 自社の会計システムを開発したエンジニアAが、そのシステムのシステム監査の監査人を務めることになった。この体制について最も適切な指摘は？
Q2. 経費精算システムにおいて、申請者と承認者が同一人物になれないよう業務を分離する統制の仕組みは何と呼ばれるか？
Q3. システム監査人が、監査対象システムのアクセスログを専用ツールで機械的に分析し、承認者フィールドが空欄のまま処理された取引を検出した。この証拠収集方法に該当する監査技法は？