ITパスポート 令和6年度 問55：system_auditに関する問題

答えは c です。

システム監査とは、会社のITが「危ないところ（リスク）にちゃんと対策できているか」を、外側のチェック役が確かめること。そして、その確認を通して会社の目標達成に役立つことがゴールです。

cの「リスクに適切に対応しているか評価して、組織の目標達成に寄与する」がまさにそれ。

👉 覚え方：システム監査＝「ITのリスク対策をチェックして、会社の役に立つ」。

ほかの選択肢：a システムの用途を分析して要件を決める＝開発の最初の仕事／b 施設や環境を管理・活用する＝ファシリティ（設備）の話／d 知識や技法をプロジェクトに使う＝プロジェクトマネジメントの話。

なぜこれが正解か

正解は c。システム監査の目的は、独立かつ専門的な立場の監査人が、情報システムに係るリスクに適切に対応（コントロール）できているかを評価し、その結果を通じて組織体の目標達成に寄与すること。cの記述がこの定義に一致する。

各選択肢の解説

• a：システムの用途を分析して要件を明らかにする＝要件定義（システム開発の上流工程）の説明。
• b：施設・環境を企画・管理・活用する＝ファシリティマネジメントの説明。
• d：知識・スキル・ツール・技法をプロジェクトに適用して要求を満たす＝プロジェクトマネジメントの説明。

覚え方・ひっかけ注意

システム監査のキーワードは「独立した立場」「リスクへの対応の評価」「組織目標への寄与・改善の助言」。監査は“作る・運用する”側ではなく“チェックして役立てる”側。a（作る）・b（設備運用）・d（進める）はいずれも被監査側の業務であり、評価する立場ではない点で区別する。

理論的背景

システム監査の目的はITパスポートシラバス・システム監査基準（経済産業省、2023年改訂版）によって明確に定義されており、正解cは「情報システムに係るリスクに適切に対応しているかどうかを評価することによって、組織体の目標達成に寄与すること」である。この定義の核心は「リスク対応の適切性評価（手段）→組織目標達成への寄与（目的）」という目的手段の二層構造にある。

システム監査基準（2023年）の定義を引用すると「システム監査は、組織体の保有するリスクの管理状況を確認し、及び組織体の目標達成に向けてリスク管理の改善を促進するために行う検討及び評価活動」とされる。3つのキーワード：①「独立した立場（監査人の独立性）」、②「リスク対応の適切性評価（客観的評価活動）」、③「組織体の目標達成への寄与（最終目的）」がシステム監査を他の活動と区別する。

4択の識別を整理する：aは「システム要件分析・明確化」→開発フェーズのシステム要件定義活動、bは「施設・環境の企画・管理・活用」→ファシリティマネジメントの定義、cは正解のシステム監査の目的、dは「プロジェクトの要求事項を満足させる」→プロジェクトマネジメントの目的（PMBOKのプロジェクト定義に近い）。各選択肢がそれぞれ異なる管理概念を代表しており、精緻な識別力が問われる設問設計。

実務での使われ方

システム監査の実務は「計画→実施→報告→フォローアップ」の4フェーズで進行する。計画フェーズでは監査テーマの選定・監査計画書の作成・リスクベース監査アプローチ（重要リスクに監査資源を集中）が実施される。実施フェーズでは監査手続き（インタビュー・文書レビュー・統制テスト・データ分析）が実行される。報告フェーズでは監査調書の作成・監査報告書の起案・経営者へのレポーティングが行われる。フォローアップでは改善提案の実施状況確認・再評価が行われる。

近年の変化として「継続的監査（Continuous Auditing：CA）」が台頭している。従来の年次監査に加えて、ERP・GRC（Governance Risk Compliance）ツールのデータをリアルタイム分析することで異常・リスクシグナルを継続的に検出するアプローチである。特に金融機関・大手製造業のITリスク管理では、AIベースの監査分析ツール（ACL・IDEA・Galvanize）が使われ始めている。

試験での位置づけ

システム監査の目的はITパスポートの「システム監査」サブカテゴリ最基礎問題として出題される。本問の4選択肢は「開発管理（a）・ファシリティマネジメント（b）・システム監査（c）・プロジェクトマネジメント（d）」という異なる管理概念を代表する選択肢で構成されており、各概念の明確な識別が求められる。

「システム監査」という名称から「システムを監視・管理すること」という誤解を持つ受験者が、bのファシリティマネジメント（施設管理）やaのシステム要件定義を誤選択するパターンが見られる。「監査（Audit）」は「独立した立場での客観的評価・検証」であり、「管理（Management）」や「開発（Development）」とは根本的に異なる活動であることを理解することが正答への鍵。

基本情報技術者ではシステム監査基準の「監査人の独立性（監査対象組織から独立）」「監査の証拠収集手続き」「監査報告書の宛先・内容」「フォローアップ監査の役割」が詳細に問われる。情報処理安全確保支援士ではセキュリティ監査（ISO/IEC 27007・27008に基づくISMS監査）との接続が問われる。

選択肢の発展補足

aの「システム要件の明確化」との混同の構造：「開発すべきシステムの具体的な用途を分析し、システム要件を明らかにする」は要件定義エンジニアの業務記述として正確。システム監査が「既存システムのリスク対応を評価する」後ろ向きの活動なのに対し、要件定義は「これから作るシステムを定義する」前向きの開発活動。監査の「評価」と開発の「定義」は活動の時制（既存vs新規）と性格（評価vs構築）が対照的に異なる。

bのファシリティマネジメントとの識別：「情報システムが設置されている施設とその環境を総合的に企画・管理・活用」は物理的インフラ管理の定義。「施設と環境」という物理的対象がFMを、「リスク対応の評価」という抽象的・組織的対象がシステム監査を示す。FMとシステム監査はともに「情報システムに関わる管理活動」という大分類では同列だが、守備範囲（物理環境vs組織統制）が異なる。

dのプロジェクトマネジメントとの識別：「知識・スキル・ツール・技法をプロジェクト活動に適用してプロジェクトの要求事項を満足させる」はPMBOKのプロジェクトマネジメント定義（PMBOK第7版：「価値デリバリーシステムの中でステークホルダーの意図する成果を達成する」）に近い記述。PMはプロジェクトという「有期的・独自的業務」の管理、システム監査は継続的・定期的な「評価・検証活動」という性格の差が識別根拠となる。