システム監査技術者試験 のナレッジマップ
システム監査技術者試験 の主要概念 62 件と、そのつながり。上のマップでノードをクリックすると関連用語や前提をたどれます。下は全概念の索引で、定義と「前提・関連する概念」への内部リンクを掲載しています。
概念一覧（62）
内部統制
業務が適正・効率的に遂行されるよう、企業が自ら業務プロセスに組み込む仕組み・体制。不正の防止や財務報告の信頼性確保を目的とし、経営者に整備・運用の責任がある。
監査手続
監査人が監査証拠を入手するために実施する具体的な手法・作業の総称。監査計画に基づき、監査目的に応じてドキュメントレビュー法・インタビュー法・現地調査法・CAATなどの技法を組み合わせて選択し、実施結果を監査調書に記録する。
前提: 監査計画、ドキュメントレビュー法、インタビュー法、現地調査法（視察）
関連: 監査調書と査閲
システム監査
情報システムが安全・効率的に運用されているかを、独立した立場の監査人が第三者の視点で検証・評価し、改善を助言する活動。監査対象部門から独立していることが信頼性の前提。
リスクアプローチ（監査における）
監査資源が有限であることを前提に、リスクと重要性が高い領域を優先して監査計画・監査手続を組み立てる進め方。すべての業務やシステムを一律の深さで監査するのではなく、固有リスク・統制リスクの評価結果に基づき対象を選別し、リスクの高い領域ほど手続を厚くすることで監査の実効性を高める。これは監査リスク＝固有リスク×統制リスク×発見リスクの枠組みに基づき、固有・統制リスクの評価結果に応じて発見リスクを許容水準に抑えるよう監査手続の量・時期・範囲を決めることに対応する。
前提: 監査計画、監査リスク（audit risk）、統制リスク（control risk）、発見リスク（detection risk）
監査証拠（十分性と適切性）
システム監査人が監査意見を形成する根拠となる情報。十分性は証拠の量、適切性は証明力（関連性と信頼性）を指し、両者を満たして初めて監査意見の合理的な裏付けとなる。監査人自らが直接入手した証拠や被監査部門の外部から得た証拠は、被監査部門から間接的に入手した証拠より一般に信頼性が高いと判断される。
関連: 監査意見
監査意見
保証型のシステム監査において、監査人が入手した監査証拠に基づき、監査対象の内部統制やシステムの適正性・有効性について表明する結論。意見は監査人が実際に収集した監査証拠の範囲内でのみ表明されるべきであり、根拠のない断定や証拠を超えた保証はしてはならない。意見の類型には無限定適正意見・限定付適正意見・不適正意見・意見不表明があり、証拠の制約や重要な不備の有無に応じて使い分ける。
関連: 監査証拠（十分性と適切性）
監査計画
システム監査を実施する前に、監査の目的・対象範囲・実施時期・手続・体制などを定めた計画。監査資源を効果的に配分するため、リスクの大きい領域を優先する中長期計画（基本計画）と、個別監査ごとの詳細な個別監査計画に分けて策定されることが多い。
前提: システム監査
統制リスク（control risk）
内部統制が存在してもなお、重要な誤りや不正を防止または発見できないリスク。監査人は統制の整備状況・運用状況を評価してこのリスクの水準を判断し、統制リスクが高いと評価された領域では実証手続をより厚くする。固有リスクと並び、監査人にとっては「所与」として評価する対象である。
固有リスク（inherent risk）
内部統制が存在しないと仮定した場合に、業務やシステムの性質そのものから本来的に存在するリスク。取引の複雑さや金額規模、技術的な新しさなどに起因し、監査人が統制の有無とは切り離して評価する所与のリスクである。固有リスクが高い領域ほど、監査人は監査資源を重点的に配分する。
前提: 内部統制
監査調書と査閲
監査調書とは、監査人が実施した監査手続の内容や入手した監査証拠を記録した文書。監査意見の根拠を裏付ける重要な記録であり、監査終了後も一定期間保管する義務がある。査閲とは、作成された監査調書について、担当者とは別の上位者が内容の妥当性・網羅性を確認するレビュー活動であり、監査の品質を担保する仕組みの一つ。
前提: 監査証拠（十分性と適切性）、監査意見
関連: 監査手続
監査報告書
システム監査の実施結果を依頼者（経営者等）に報告する文書。監査の目的・範囲、実施した監査手続、発見事項（指摘事項）、改善勧告、監査意見を記載する。監査人は事実に基づく指摘と、実施した手続の範囲を明確に区別して記述する必要がある。
前提: 監査意見、監査手続、改善勧告（指摘事項）、システム監査
監査範囲と監査目標
監査目標は監査を通じて何を確かめるか（例：可用性の妥当性、内部統制の有効性）を示し、監査範囲は対象とする情報システム・業務プロセス・期間・拠点などの境界を示す。監査人はまず監査目標を明確にし、その達成に必要十分な監査範囲を画定したうえで監査計画を立てる。監査範囲が目標と整合していないと、結論の裏付けが不十分になる。
CAAT（コンピュータ支援監査技法）
コンピュータを利用して監査証拠の入手・分析を行う技法の総称。テストデータ法・並行シミュレーション法・ITF（統合テスト施設法）・監査モジュール法・汎用監査ソフトウェアによる全件検証などを含み、手作業では困難な大量データの検証やプログラムの処理内容そのものの検証を可能にする。
前提: 監査証拠（十分性と適切性）
関連: 汎用監査ソフトウェア、ITF（統合テスト施設法）、並行シミュレーション法、テストデータ法、監査モジュール法（組込監査モジュール）
発見リスク（detection risk）
監査人が実施する監査手続によっても、重要な不備や誤りを見逃してしまうリスク。固有リスクと統制リスクが監査人にとって所与であるのに対し、発見リスクは監査手続の種類・範囲・時期（試査の程度など）を調整することで監査人自身がコントロールできる唯一のリスクであり、固有・統制リスクが高い領域ほど発見リスクを低く抑える必要がある。
前提: 監査手続、統制リスク（control risk）、固有リスク（inherent risk）、サンプリング（統計的・非統計的、試査と精査）
ITへの対応（内部統制の要素）
J-SOX実施基準がCOSOの5要素に追加した6番目の構成要素。内部統制の目的を達成するために、業務で利用するIT環境（IT基盤・IT業務処理統制・IT全般統制）に組織が適切に対応することを指す。監査人はIT全般統制（アクセス管理・変更管理等）とIT業務処理統制の両面から評価する。
前提: IT全般統制とIT業務処理統制、変更管理統制（プログラム変更管理）、COSO（内部統制フレームワーク）、J-SOX（内部統制報告制度）
監査手続書（監査プログラム）
設定した監査目標を達成するために、どの監査手続をどのような順序・方法で実施するかを具体的に記した計画文書。担当する監査人が交代しても一定の監査品質を保つための実務上の指針となり、実施結果は監査調書として記録される。監査手続書は監査範囲・監査目標に基づいて作成される。
監査リスク（audit risk）
監査人が重要な不備を見逃し、誤った結論を報告してしまうリスク。固有リスク・統制リスク・発見リスクの積として捉えられ、監査人は固有リスクと統制リスクの評価結果に応じて監査手続の範囲や深さ（発見リスクの水準）を調整し、監査リスク全体を許容水準まで抑える。
前提: 監査手続、統制リスク（control risk）、発見リスク（detection risk）、固有リスク（inherent risk）
変更管理統制（プログラム変更管理）
プログラムやシステム設定の変更について、申請・承認・テスト・本番環境への移行・記録の各段階を統制すること。IT全般統制の中核をなし、無許可の変更や不十分なテストによる障害・不正を防止する。監査人は変更依頼から本番反映までの一連のプロセスに承認と職務分掌が組み込まれているかを検証する。
関連: IT全般統制とIT業務処理統制
J-SOX（内部統制報告制度）
金融商品取引法に基づき、上場企業の経営者が財務報告に係る内部統制の有効性を自己評価して内部統制報告書を作成し、公認会計士等による監査を受ける制度。経営者はトップダウン型のリスクアプローチに基づき、財務的重要性の高い項目から評価範囲を絞り込む。監査人は経営者評価の妥当性を検証する。
内部統制の6要素（J-SOX実施基準）
日本のJ-SOX（金融商品取引法の内部統制報告制度）の実施基準が定める内部統制の構成要素。COSOの5要素（統制環境・リスクの評価と対応・統制活動・情報と伝達・モニタリング）に、IT環境への対応を独立した要素とした「ITへの対応」を加えた6要素で構成される。監査人はこの6要素で財務報告に係る内部統制の整備・運用状況を評価する。
重要性（マテリアリティ）
監査における判断や結論に影響を与える事項の重大さの度合い。金額の大小といった量的な側面だけでなく、業務への影響度や法令遵守上の意味合いといった質的な側面も含む。監査人は重要性の判断に基づいて監査範囲や手続の深さを決定し、軽微な事項に監査資源を割きすぎないようにする。
前提: 監査範囲と監査目標
現地調査法（視察）
監査人が実際に業務現場やシステム運用の場に赴き、自らの目で状況を観察して確かめる監査技法。文書やインタビューでは把握しきれない実態（作業手順の遵守状況、物理的なアクセス管理の実施状況など）を直接確認でき、監査人自身が入手する証拠として信頼性が高い。
サンプリング（統計的・非統計的、試査と精査）
母集団の一部を抽出して監査証拠を入手する試査の手法。統計的サンプリングは確率理論に基づき客観的な基準で標本を抽出し結果を母集団に一般化できるのに対し、非統計的サンプリングは監査人の経験・判断に基づいて抽出する。母集団の一部のみを調べる試査に対し、母集団全件を調べる精査があり、リスクの大きさや汎用監査ソフトウェアの利用可否に応じて使い分ける。
前提: 監査証拠（十分性と適切性）
関連: 汎用監査ソフトウェア
システム監査基準
経済産業省が定める、システム監査人が監査業務を実施し報告する際のよりどころとなる行為規範。一般基準（監査人の要件・独立性等）、実施基準（監査計画・実施の手順）、報告基準（監査報告の作成・伝達）から構成され、監査の品質を担保する。監査人は自らの監査手続がこの基準に照らして適切かを常に検証する。
リスクアセスメント
情報資産に対する脅威と脆弱性を洗い出し、リスクを特定・分析・評価する一連のプロセス。リスクの大きさ（発生可能性×影響度）を明らかにし、以降のリスク対応の判断材料とする。ISMSのPDCAではPlanフェーズの中核。
監査人の独立性
システム監査人が被監査部門や監査対象システムの開発・運用に利害関係を持たず、公正かつ客観的に判断できる立場を保つべきという原則。外観上の独立性（第三者から見て疑念を持たれない立場）と精神上の独立性（自らの判断が影響を受けない姿勢）の両方が求められる。
前提: 精神的独立性と外観的独立性、システム監査
IT全般統制とIT業務処理統制
IT統制のうち、アクセス管理・変更管理・運用管理などシステム全体に共通する基盤的な統制がIT全般統制、個々の業務システムにおける入力・処理・出力の正確性を担保する統制（入力チェック・照合・承認など）がIT業務処理統制。IT全般統制が有効でないと、個々のIT業務処理統制の信頼性評価も揺らぐという依存関係にある。
監査の品質管理
監査業務そのものの品質を確保するための仕組み。監査調書の査閲（レビュー）、監査人から独立した立場による審査、監査基準への準拠状況の確認などを通じて、監査手続の妥当性や監査意見の根拠が十分であることを担保する。個々の監査人の判断のばらつきを抑える役割を持つ。
COSO（内部統制フレームワーク）
トレッドウェイ委員会組織委員会（COSO）が公表した内部統制の枠組み（COSOキューブ）。統制環境・リスク評価・統制活動・情報と伝達・モニタリングの5構成要素からなり、業務の有効性・効率性、財務報告の信頼性、法令遵守の3目的を達成するための基盤となる。監査人は内部統制の整備状況をこの5要素に沿って評価する。
監査モジュール法（組込監査モジュール）
本番プログラムの内部にあらかじめ監査用の処理機能（特定条件に合致する例外取引の抽出・記録など）を組み込んでおき、システムが稼働している間、継続的に監査証拠を収集するCAATの一技法。リアルタイムかつ継続的な監視が可能な一方、本番プログラムの改修を伴うため導入・保守のコストと統制が課題となる。
前提: 監査証拠（十分性と適切性）
フォローアップ
システム監査で指摘した事項について、被監査部門がどの程度改善したかを後日確認する活動。監査人は被監査部門からの改善報告を鵜呑みにせず、実際の証跡や運用状況といった監査証拠に基づいて改善の実効性を検証する必要がある。
前提: 監査証拠（十分性と適切性）、システム監査
汎用監査ソフトウェア
監査人が本番データを直接読み込み、全件抽出・並べ替え・集計・突合などを行える汎用のCAATツール。母集団全件を対象とした精査的な検証に向き、サンプリングでは発見しにくい異常値や例外パターンの網羅的な検出に利用される。特定業務に依存しない汎用性が特徴。
改善勧告（指摘事項）
監査人が発見した内部統制の不備について、その事実・原因・影響（リスク）を明らかにした上で、被監査部門に改善を促す提言。監査人はあくまで改善を勧告するにとどまり、統制の具体的な設計や実施そのものは被監査部門が行う。監査人が自ら是正策を実行すると、独立性を損なうため避けなければならない。
前提: 内部統制
助言型監査（コンサルティング）
監査対象の状況を評価したうえで、保証の表明よりも改善のための具体的な提言を行うことを主目的とする監査の形態。監査人は問題点の指摘にとどまらず、実務的な改善策を提示することが期待される。保証型監査に比べて監査人と被監査部門の協働的な色合いが強くなるため、独立性の確保に一層留意する必要がある。
関連: 保証型監査（アシュアランス）
チェックリスト法
あらかじめ監査目的に沿って作成した確認項目一覧（チェックリスト）に基づき、項目ごとに順に点検していく監査技法。確認漏れを防ぎ、監査人による判断のばらつきを抑えて網羅性と一貫性を確保できる一方、リストにない事項への気づきが得られにくい限界もある。
統制の3類型（予防統制・発見統制・是正統制）
内部統制を機能面で分類した3類型。予防統制は誤りや不正の発生を未然に防ぐ統制（承認権限の設定・職務分掌・アクセス制御など）、発見統制は発生した誤りや不正を検知する統制（証憑突合・ログ監視・例外レポートの確認など）、是正統制は発見された問題を回復し再発防止を図る統制を指す。監査人は各統制の組合せと網羅性を評価する。
前提: 内部統制
並行シミュレーション法
監査人が独自に作成した検証用プログラムに、本番システムで実際に使用された入力データをそのまま処理させ、その結果を本番システムの実際の出力と照合するCAATの一技法。本番データそのものを用いる点でテストデータ法と異なり、実運用における処理結果の正確性を検証できる。
前提: テストデータ法
システム管理基準
経済産業省が定める、情報システムの企画・開発・運用・保守を組織がどう管理すべきかを示す実践規範。監査対象（被監査部門）が遵守すべき望ましい管理の姿を示し、システム監査人はこれを監査の判断尺度として、実際の管理状況との差異を評価する。システム監査基準（監査人の行為規範）とは役割が異なる点に注意する。
テストデータ法
監査人があらかじめ想定結果を用意したテストデータを作成し、監査対象プログラム（またはその複製）に、本番データと混同しないよう試験環境で処理させて、出力結果を想定結果と比較することでプログラムの処理内容（ロジック）の正確性を検証するCAATの一技法。プログラムそのものの妥当性確認に主眼を置く。本番データを汚染しないよう試験環境で実施するのが原則で、本番稼働中の処理に監査用の擬似データを紛れ込ませるITF法とは異なる。
稼働率
システムが正常に稼働している時間の割合。稼働率＝MTBF÷(MTBF＋MTTR) で求められ、故障間隔が長く修復時間が短いほど高くなる。可用性の代表指標で、SLA の合意値（例 99.9%）としても用いる。
前提: 平均故障間隔（MTBF）
リスク対応（低減・回避・移転・受容）
リスクアセスメントの結果に基づき取る4つの対応方針。低減＝管理策の導入で発生可能性や影響度を下げる、回避＝リスクの原因となる活動自体をやめる、移転＝保険や委託で第三者にリスクを移す、受容＝許容範囲内として対策せず受け入れる。コストと効果のバランスで選択する。
関連: リスクアセスメント
変更の種別（標準・通常・緊急変更）
サービスマネジメントにおける変更を承認経路とリスクで分類した3種別。標準変更は事前承認済みの低リスクな定型変更で都度の承認が不要、通常変更はCABがリスク・影響・スケジュールを評価してから承認、緊急変更はサービス停止など切迫した事態に対しECABが迅速に承認し事後に文書化する。ITサービスマネージャは各変更を適切な種別に振り分け、標準変更を増やすことで承認の遅延と評価コストを下げつつ統制を保つ判断が求められる。
保証型監査（アシュアランス）
監査対象の情報システムや内部統制について、あらかじめ定めた基準に照らして一定の保証（結論や意見）を表明することを目的とする監査の形態。監査人は十分かつ適切な証拠に基づき、対象が基準に適合しているかどうかについて明確な結論を報告する。改善提言そのものが主目的ではない点で助言型監査と異なる。
前提: 内部統制
関連: 助言型監査（コンサルティング）
監査証跡（オーディットトレイル）
取引やシステム処理が発生してから最終的な結果に至るまでを、記録をたどることで追跡できるようにした一連の履歴。ログや伝票番号などが連鎖することで、処理の発生から集計・出力までを双方向に追跡でき、監査人は不正や誤りの原因究明、処理の正当性確認に利用する。
インタビュー法
被監査部門の担当者や責任者に質問し、業務の実態やシステムの運用状況に関する情報・証拠を収集する監査技法。担当者の説明を直接得られる利点があるが、発言のみでは証拠力が弱いため、記録の閲覧や現地調査など他の手続で裏付けを取ることが求められる。
前提: 現地調査法（視察）
平均故障間隔（MTBF）
修理して使い続けるシステムで、ある故障から次の故障までの平均稼働時間。値が大きいほど故障しにくく信頼性が高い。総稼働時間÷故障回数で算出する。
平均修復時間（MTTR）
故障が発生してから復旧するまでの平均時間。値が小さいほど早く復旧でき、保守性（メンテナンス性）が高い。総修復時間÷故障回数で算出する。稼働率＝MTBF÷(MTBF＋MTTR) の分母に含まれ、MTBF（平均故障間隔）と対にして信頼性・保守性を評価する。
前提: 稼働率、平均故障間隔（MTBF）
デザインレビュー（ウォークスルー・インスペクション）
設計成果物を関係者が検証し、誤りや問題点を早期に発見する活動。ウォークスルーは作成者が主導して成果物を説明しながら参加者が指摘する非公式なレビューで、準備負荷が軽い。インスペクションはモデレータ（進行役）のもとで参加者に役割を分担させ、チェックリストに基づき体系的に欠陥を検出・記録する公式なレビューで、検出力が高い。システムアーキテクトは対象の重要度に応じてレビュー形態を選び、後工程への欠陥流出を防ぐ。
前提: チェックリスト法
アクセスコントロールの評価
システム監査において、認証（本人確認）、認可（権限付与）、最小権限の原則、特権ID（管理者権限）の管理などアクセス統制の整備・運用状況を監査人が評価すること。付与された権限が職務内容に対して過剰でないか、権限の棚卸しが定期的に行われているかなどを検証する。
前提: システム監査
アプリケーションコントロール（IT業務処理統制）
個別の業務システムにおいて、入力・処理・出力の正確性・網羅性・正当性を確保するための統制。チェックディジットによる入力誤り検出、バッチコントロール（件数・金額の突合）、入力データの妥当性チェック、エラーの再処理管理などが含まれる。監査人は業務プロセスに組み込まれた自動化・手動の統制がリスクに対応しているかを評価する。
前提: IT全般統制とIT業務処理統制
COBIT
ISACAが策定したITガバナンス・ITマネジメントのフレームワーク。統制目標を体系的に整理し、システム監査人が統制の整備・運用状況を評価する際のよりどころ（監査規準・評価基準）として用いる。監査人は監査対象の統制がCOBITの目標に照らして十分かを判断材料にする。
前提: システム監査
ドキュメントレビュー法
規程・マニュアル・設計書・議事録・記録類などの文書を査閲し、統制の整備状況（規程等が適切に定められているか）や運用状況（記録が実際に作成・保存されているか）を確かめる監査技法。文書上の整合性は確認できるが、記載どおりに実施されているかは他の手続と組み合わせて裏付ける必要がある。
ITF（統合テスト施設法）
本番環境の中に監査用の架空の実体（ダミーの部門・取引先・口座など）をあらかじめ設け、監査人が用意した検証用データを実際の本番取引に紛れ込ませて処理させ、その結果を検証するCAATの一技法。本番運用と並行して継続的に処理の正確性を確認できるが、本番データへの影響を排除する仕組みが必要となる。
精神的独立性と外観的独立性
精神的独立性は、監査人が先入観や利害にとらわれず客観的な姿勢で判断を行う内面的な独立性を指す。外観的独立性は、第三者から見て監査人が被監査対象と特別な利害関係を持たないと認識される外形的な独立性を指す。自らが関与した業務や設計したシステムを自分で監査することは、実質的に公正でも外観的独立性を損なうため避けるべきとされる。
ITIL
ITサービスマネジメントにおけるベストプラクティスをまとめたフレームワーク。インシデント管理や変更管理などサービス運用の進め方を体系化する。最新のITIL 4（2019年）では、価値共創を中心とする「サービスバリューシステム（SVS）」と34の「プラクティス」に再構成されている（従来のプロセス群はプラクティスとして継承）。
職務分掌（内部統制における）
不正や誤りを防ぐため、承認・実行・記録・保管といった一連の業務を1人に集中させず複数人で分担させる内部統制の基本原則。
前提: 内部統制
SLAとSLM
SLA（サービスレベル合意書）は、サービス提供者と利用者の間でサービス品質の水準（稼働率や応答時間など）を取り決めた合意文書。SLM（サービスレベル管理）は、SLAの内容を継続的に監視・見直しする活動。
前提: 稼働率
情報資産
組織にとって価値がありリスクアセスメントの対象となる情報およびそれを扱う仕組み全般。顧客データや設計情報などの「情報そのもの」に加え、それを保存・処理するサーバーやPCなどの「機器」、業務プロセスも含む。台帳を作成し重要度（機密性・完全性・可用性）を評価するのが管理の出発点。
関連: リスクアセスメント
特権ID管理
システム管理者権限（root/Administrator等）を持つ特権IDを一般ユーザーIDと分離し、利用申請・承認・払い出し・利用記録（証跡）・返却までを厳格に管理する仕組み。特権ID管理製品によるパスワードの自動ローテーションやワンタイム化で、ID共有や恒久的な保持によるリスクを下げる。
前提: 監査証跡（オーディットトレイル）
残留リスク
リスク対応（低減・回避・移転）を実施した後になお残るリスク。ゼロにはできないため、経営層が許容水準内にあるかを判断し、受容するかどうかを承認する対象となる。
適用宣言書（SoA）
ISO/IEC 27001の附属書A(Annex A)に列挙された管理策のうち、どれを自組織に適用するか／除外するかとその理由を明記した文書。リスクアセスメントの結果に基づいて作成し、ISMS認証審査の中心的な確認対象になる。
前提: リスクアセスメント
CAB（変更諮問委員会）とECAB
CAB（変更諮問委員会）は通常変更のリスク・影響・スケジュールを評価し、実施可否を助言する常設の会議体で、技術・業務・利用者など関係する立場を集めて意思決定を支える。ECAB（緊急変更諮問委員会）はCABを招集する余裕がない緊急変更のために、必要な少数の権限者だけで構成し迅速に承認する小規模編成である。ITサービスマネージャはCABの付議基準と構成を設計し、緊急時にはECABへ切り替えて評価の質と速度を両立させる。