対象試験と出題頻度
指摘事項は、基本情報技術者・応用情報技術者の午前問題で出題されるテーマです。
システム監査の一連の流れ（計画→実施→報告→フォローアップ）のうち「報告」の核心にあたる用語で、「監査報告書に何を書くべきか」「監査調書やフォローアップとの違い」を区別できるかが繰り返し問われます。
対象試験と頻度の詳細
基本情報技術者
応用情報技術者
★★★☆☆
ランクB（標準）覚えておくと有利
用語の定義
システム監査の勉強をしていると、「指摘事項って、監査で見つけた問題を全部書けばいいの？」とつまずきがちです。実はそこに大きな落とし穴があります。
指摘事項（Audit Findings）とは、一言で言うと
「監査で見つけた不備のうち、残ったリスクの大きさを評価して「改善が必要」と判断し、監査報告書に書く事項」
のことです。
イメージとしては、「健康診断の再検査通知」です。
健康診断では血圧・血糖値・視力など膨大な項目を測りますが、通知書に「再検査が必要」と赤字で書かれるのは、放っておくと健康に影響が出る項目だけです。誤差の範囲や問題なしの項目はわざわざ通知されません。
指摘事項も同じで、監査人が気づいた事実をすべて報告書に並べるのではなく、「このまま放置すると組織にとって危ない」とリスクで判断したものだけを抜き出して書きます。
📊 指摘事項の基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Audit Findings |
| 記載先 | 監査報告書 |
| 判断基準 | 残存リスクの大きさ（重要度・緊急度） |
| 根拠基準 | システム監査基準（経済産業省・令和5年改訂） |
解説
システム監査人は、業務の現場でルールどおりに運用されているかを調べ、気づいた事実を「監査調書」という作業記録にすべて書き留めます。
ここまでの段階では、良い点も悪い点も含めた生のデータの集まりです。
しかし、その記録を経営層へそのまま提出しても役に立ちません。
何が本当に危ないのかが埋もれてしまうからです。そこで監査人は、見つけた不備を「残存リスク（=対策をしても残っている危険度）」でふるいにかけ、改善が必要なものだけを選び出します。この選び出された結果が指摘事項です。
「すべての不備＝指摘事項」ではない
ここが最大のポイントです。経済産業省のシステム監査基準（令和5年）にも、「監査調書に記載された不備の全てを監査報告書における指摘事項とする必要はない」と明記されています。
誤差程度のものや、すでに対策済みでリスクが小さいものは、あえて報告書には載せません。
▼ 不備から指摘事項へ絞り込まれる流れ
▲ 上にいくほど件数は多く、下にいくほど厳選される（ピラミッド型）
指摘事項・改善提案・フォローアップの関係
指摘事項は単独では完結しません。
改善提案とフォローアップとセットで、監査の「報告以降」を構成します。役割の違いを正確に押さえておきます。
| 用語 | 何を指すか | 誰が主体か |
|---|---|---|
| 監査調書 | 監査の実施過程や発見した事実をすべて記録した作業文書 | システム監査人 |
| 指摘事項 | 改善が必要と判断し監査報告書に記載する不備 | システム監査人 |
| 改善提案 | 指摘事項に対して監査人が示す改善の方向性・助言 | システム監査人 |
| フォローアップ | 改善提案が実行されているかを監査人が後日モニタリングすること | システム監査人 |
※ 改善そのものを実行する責任は被監査部門にあり、監査人は支援にとどまる点に注意。
💡 覚えるのはこの3点だけ
・指摘事項＝不備の中から「残存リスクが大きく改善が必要」と選んだもの
・調書の不備を全部書く必要はない（厳選する）
・記載先は監査報告書。改善の実行責任は被監査部門にある
では、この知識が実際の問題でどう問われるかを見ていきます。
試験ではこう出る！
この用語は、具体的な状況を提示して「どれを監査報告書に書くべきか」を選ばせる事例型が主流です。単純な暗記では解けず、リスクの大小を自分で判断させてくる点が特徴です。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| FE H30秋 午前 問58 |
ISMS内部監査の結果、監査人が指摘事項として記載すべき状況を選ぶ問題。 | ・正解は「リスクアセスメント後にリスク受容基準を決めた」（手順が逆＝不備） ・手順どおりの運用はすべて不正解 |
| AP R4秋 午前 問58 |
上記FE H30秋 問58と同一の流用問題。 | ・FEとAPで同じ問題が出回る典型例 ・「正常な運用＝指摘不要」を見抜けるかが鍵 |
| AP R6秋 午前 問60 |
改善提案の実施状況をモニタリングする活動を選ぶ問題。 | ・正解は「フォローアップ」 ・指摘事項と混同させる選択肢が並ぶ |
📝 ひっかけ選択肢の典型パターン
パターン1：「正常な運用」を指摘事項に見せかける
「手順どおり許可していた」「規定どおり報告していた」という問題のない状況を選択肢に並べ、慌てて選ばせる手口。ルール違反でなければ報告書に書く必要はない。
パターン2：報告以降の用語と混同させる
「改善計画の策定（=被監査部門の役割）」「実施状況のモニタリング（=フォローアップ）」を、指摘事項の説明にすり替えてくる。主体が監査人か被監査部門かで切り分ける。
得点ラインはここまでです。指摘事項の優先順位付け（重要改善／通常改善の区分）まで細かく覚える必要はありません。
【確認テスト】理解度チェック
Q. システム監査における「指摘事項」の説明として、最も適切なものはどれでしょうか？
- A. システム監査人が、監査報告書に記載した改善提案の実施状況を後日収集し、改善の進み具合をモニタリングすること。
- B. 監査の実施過程で発見した事実を、良い点・悪い点を問わずすべて記録した作業用の文書のこと。
- C. 監査で発見した不備のうち、残存リスクの大きさを評価して改善が必要と判断し、監査報告書に記載する事項のこと。
正解と解説を見る
正解：C
解説：
指摘事項は、発見した不備の中から残存リスクで「改善が必要」と判断したものを監査報告書に記載するものなので、Cが正しい説明です。
選択肢Aはフォローアップの説明です。改善提案の実施状況をモニタリングする活動であり、報告書を提出した「後」の工程にあたるため、指摘事項そのものとは別物です。選択肢Bは監査調書の説明です。発見した事実を全件記録する作業文書であり、ここから絞り込んだ結果が指摘事項になるため、両者を混同しないよう注意が必要です。
よくある質問（FAQ）
Q. 指摘事項と「改善勧告（改善提案）」はどう違いますか？
指摘事項が「何が問題か（事実と評価）」を示すのに対し、改善勧告は「ではどう直すべきか（解決の方向性）」を示すものです。助言型のシステム監査では、重要な指摘事項に対して改善勧告をセットで記載し、フォローアップ実施時までに解決すべき目標として扱います。試験では両者が同じ報告書内の別パートとして登場するため、役割で区別しておくと混乱しません。
Q. 軽微な不備でも、念のため全部報告書に書いた方が安全では？
いいえ、それは適切ではありません。経営層が本当に対処すべき重大なリスクが、些末な事項に埋もれて見えなくなるためです。システム監査基準でも調書の不備をすべて記載する必要はないとされており、優先順位を付けて重要なものに絞ることが監査人の専門的判断とされています。「全件報告＝丁寧」ではない点が実務の勘所です。
Q. 指摘事項を出す前に、被監査部門へ内容を確認しなくていいのですか？
確認します。報告書を最終版にする前に、監査人は被監査部門と事実確認（事実誤認がないかのすり合わせ）を行うのが原則です。これは指摘内容を取り下げるための交渉ではなく、誤った前提で指摘して信頼性を損なうのを防ぐ手続きです。事実を確定させたうえで指摘事項を確定させる、という順序になります。
Q. 監査人は、指摘した内容が改善されたか最後まで責任を持つのですか？
改善を「実行する」責任は被監査部門にあります。監査人の役割は、改善が適切かつ適時に進んでいるかを情報収集して見届けるフォローアップまでで、自ら改善作業を行うわけではありません。監査人が改善まで手を下すと、自分の仕事を自分で監査する利益相反になり、独立性が損なわれてしまうためです。
