月末の締め処理が終わった夜、売上計上を担当する経理担当者が監査法人のITチームから質問を受けました。「受注金額と出荷数量から請求額を自動計算していますね。この計算ロジックが正しいことを、どう確かめていますか」。担当者は少し考えてから答えました。「毎月、上長が請求一覧を確認しています」。
この会話には、J-SOXのIT統制評価で最も混同されやすい論点が詰まっています。自動計算そのものはシステムに組み込まれた統制（ITAC）ですが、上長の確認はシステムの出力を人が見る統制です。さらに、その自動計算が1年間ずっと正しく動いていたと言えるかどうかは、プログラムを勝手に変えられない仕組み（ITGC）に依存しています。
本記事では、ITACとITGCの違いを実施基準の定義から整理し、自動統制を効率よく、しかし根拠を持って評価する手順を、架空のモデルケースと記入例で解説します。
この記事の要点
- ITAC（IT業務処理統制）は業務プロセスに組み込まれた統制、ITGC（IT全般統制）はそれが働く環境を守る統制です。実施基準は、ITGCが有効でもそれだけでITACの有効性は結論づけられないとしています
- 自動化されたITACは、ITGCが有効であることを前提に、1件（または少数）のテストで評価できるのが一般的です。根拠は「意図的に手を加えない限り同じように動く」というプログラムの性質です
- システムが出力した帳票を人が確認する統制は「IT依存の手作業統制」であり、帳票（IPE）の完全性・正確性の確認が欠かせません
- 自動統制の過年度評価の継続利用には、変更なし・障害なし・関連ITGCが有効、の3条件の確認と記録が必要です
ITACとITGCとは何か：定義と生まれた背景
実施基準の定義
金融庁「財務報告に係る内部統制の評価及び監査に関する実施基準」（以下、実施基準）は、ITに対する統制活動を「全般統制と業務処理統制の二つ」に分け、「両者が一体となって機能することが重要」としています。
ITAC（IT Application Controls、ITに係る業務処理統制）は、実施基準によれば「業務を管理するシステムにおいて、承認された業務が全て正確に処理、記録されることを確保するために業務プロセスに組み込まれたＩＴに係る内部統制」です。具体例として次の4つが挙げられています。
- 入力情報の完全性、正確性、正当性等を確保する統制
- 例外処理（エラー）の修正と再処理
- マスタ・データの維持管理
- システムの利用に関する認証、操作範囲の限定などアクセスの管理
ITGC（IT General Controls、ITに係る全般統制）は「業務処理統制が有効に機能する環境を保証するための統制活動」で、システムの開発・保守、運用・管理、アクセス管理などの安全性確保、外部委託契約の管理が例示されています。ITGCそのものの詳しい評価方法やクラウド利用時の論点はITGC（IT全般統制）とは？クラウド時代の評価ポイントとSOC報告書の見方で解説しています。
なぜ2種類に分けるのか
二つに分ける理由は、統制が守ろうとしている対象が違うからです。ITACは「個々の取引」を守ります。受注金額が上限を超えたら登録できない、同じ請求書番号は二重登録できない、といった統制は、取引1件ごとに働きます。
ITGCは「プログラムとデータそのもの」を守ります。受注上限チェックのロジックを誰かが書き換えたら、ITACは静かに無効化されます。この書き換えを防ぐのが変更管理であり、書き換えられる人を限定するのがアクセス管理です。ITACが取引の番人なら、ITGCは番人の持ち場を守る警備体制にあたります。
手作業でもITACになりうる
意外に知られていないのは、実施基準がITACを「手作業により実施することも可能」としている点です。例えばエラーリストを担当者が確認して修正・再処理する統制は、手作業によるITACです。一方で実施基準は、自動化されたITACは手作業のものより「無効化が難しくなる」としつつ、「過信せずに」無効化のリスクを完全に防ぐことは困難だという視点を持つよう求めています。
ITACの種類と具体例
主なITACの類型
実務でよく見られるITACを類型ごとに整理すると、次のようになります。テスト方法の欄は、内部監査部門が評価する際の一般的な手続です。
| 類型 | 具体例 | 関連するアサーション | 一般的なテスト方法 |
|---|---|---|---|
| 入力チェック（エディットチェック） | 必須項目、桁数、日付範囲、与信限度超過のブロック | 正確性、正当性 | 設定画面の閲覧、テスト環境での誤入力の再実施 |
| 自動計算 | 請求額＝単価×数量、減価償却費、為替換算 | 正確性、評価 | 1件の取引をシステム外で再計算して照合 |
| 自動照合 | 発注・検収・請求の三者照合（スリーウェイマッチ）、許容差の判定 | 実在性、正確性 | 許容差の設定値確認、差異ありの取引でブロックされることの確認 |
| インターフェース | 販売システムから会計システムへの仕訳連携、件数・金額のコントロールトータル | 網羅性、正確性 | 連携元と連携先の件数・金額照合、エラー時の処理確認 |
| マスタ管理 | 単価マスタの変更権限、変更履歴 | 正確性 | 変更権限者一覧の閲覧、変更履歴のサンプル検証 |
| システム上の職務分離 | 起票者と承認者を同一にできない設定、承認権限の金額区分 | 正当性 | ロール設定の閲覧、同一ユーザーで承認できないことの再実施 |
| 帳票・レポート | 年齢調べ表、滞留在庫リスト | 評価、網羅性 | 抽出条件と計算ロジックの確認（IPEとして後述） |
「統制」と「機能」を区別する
ITACを識別するときに陥りやすいのが、システムの全機能を統制として列挙してしまうことです。RCM（リスク・コントロール・マトリクス）に載せるべきは、財務報告の虚偽記載リスクに対応する機能だけです。例えば「画面の背景色を部門ごとに変える」機能は統制ではありませんが、「与信限度を超えた受注を登録できない」は売掛金の評価リスクに対応する統制です。
判断に迷ったら、「この機能が働かなかったら、財務諸表のどの数字がどう間違うか」を一文で書いてみてください。書けなければ統制として識別する必要はない可能性が高く、書ければRCMに載せる候補になります。RCMへの記載方法はRCMの記入例｜統制の網羅性を確認する5つの観点をご覧ください。
ITACとITGCの依存関係をどう評価するか
依存関係のマッピング
自動化されたITACの評価を効率化できるかどうかは、そのITACが依存するITGCが有効かどうかで決まります。そのため、評価の最初に「どのITACが、どのシステムの、どのITGCに依存しているか」をマッピングします。
実施基準は、ITGCは通常、業務システムを支援するIT基盤を単位として構築すると述べています。したがって、マッピングは「ITAC→システム→IT基盤→ITGC（領域別）」の順につなげていきます。
ITGCに不備があった場合の考え方
ITGCに不備が見つかっても、直ちに関連するITACすべてが無効になるわけではありません。考えるべきは「その不備によって、期間中にITACが変更された、または迂回された可能性があるか」です。例えば、変更管理で承認記録のない本番移行が見つかった場合、次のような対応が考えられます。
- 期間中の変更履歴を全件確認し、該当ITACのプログラムが変更されていないことを示す
- 期末時点でITACを再テストし、あわせて期中の複数時点でもテストする
- ITACの結果を人が確かめる補完的な統制（例：月次の売上分析）が有効に運用されていることを確認する
どの対応で十分かは、不備の内容とITACの重要性によって変わります。最終的な判断は自社と監査人で協議することになりますが、「ITGC不備の影響範囲を特定し、代替的な証拠で埋めた」という記録が残っていることが評価の出発点です。
依存関係マッピングの記入例
架空のモデルケースとして、卸売業B社（販売管理システムと会計システムを利用）のマッピング表を示します。
| ITAC番号 | 統制の内容 | システム | IT基盤 | 依存するITGC | ITGC評価結果 | ITACの評価方針 |
|---|---|---|---|---|---|---|
| S-AC-01 | 与信限度超過の受注ブロック | 販売管理 | 社内仮想基盤 | CHG-01〜03、ACC-01〜04 | 有効 | 1件テスト（超過/非超過各1件） |
| S-AC-02 | 請求額の自動計算 | 販売管理 | 社内仮想基盤 | CHG-01〜03、ACC-01〜04 | 有効 | 1件テスト（値引・税区分の組合せごと） |
| S-AC-03 | 売上仕訳の自動連携 | 販売→会計 | 社内仮想基盤／クラウド会計 | CHG-01〜03、OPS-01、SOC1 | 有効（CUEC 1項目要改善） | 期中2時点で件数・金額照合 |
| P-AC-01 | 三者照合と許容差判定 | 購買管理 | クラウド会計 | SOC1、自社ACC-05 | 有効 | 設定値確認＋差異あり1件の再実施 |
表の「ITACの評価方針」列が、ITGCの評価結果に応じて変わっている点に注目してください。S-AC-03はCUECに改善事項があるため、1件テストで済ませず、複数時点での照合を加えています。
自動統制の評価手順と「1件テスト」の根拠
なぜ1件で足りるのか
手作業の統制は、担当者の体調や繁忙度によって実施の質がぶれます。だからこそ、日次の手作業統制では一定数のサンプルを抽出して、期間を通じた運用を確かめます。サンプル数の考え方は内部監査のサンプル数はなぜ25件？で詳しく解説しています。
自動化された統制は、同じ条件の入力に対して常に同じ処理を行います。実施基準も、ITを利用した内部統制は「一貫した処理を反復継続する」ため、整備状況が有効と評価された場合には、ITGCの有効性を前提に、監査人においても「サンプル数を減らし、サンプルの対象期間を短くするなど」運用状況の検討作業を減らすことができるとしています。実務で「テスト・オブ・ワン（1件テスト）」と呼ばれる手法の根拠はここにあります。
ただし「1件」はあくまで条件の組み合わせごとの1件です。値引ありと値引なし、課税と非課税、円建てと外貨建てで処理ロジックが分岐するなら、分岐ごとにテストが必要です。
テストケース設計の記入例
架空のモデルケースとして、B社の「請求額の自動計算（S-AC-02）」のテストケースを示します。分岐条件を先に洗い出し、それぞれに本番の実例を1件ずつ割り当てる形です。
| ケース | 分岐条件 | 選定した実例 | 期待結果 | 実際の結果 |
|---|---|---|---|---|
| 1 | 値引なし・標準税率・円建て | 7月度請求 No.10234 | 単価×数量＋税額が請求額と一致 | 一致 |
| 2 | 率値引あり・標準税率 | 8月度請求 No.10871 | 値引後金額で税額計算 | 一致 |
| 3 | 軽減税率品目を含む混在 | 9月度請求 No.11302 | 税率区分ごとに端数処理 | 一致 |
| 4 | 外貨建て | 10月度請求 No.11655 | 請求日の為替マスタのレートで換算 | 一致 |
| 5 | 上限超の値引率入力 | テスト環境で再実施 | エラー表示で登録不可 | 登録不可を確認 |
分岐条件の洗い出しには、システムの仕様書や設定画面に加え、システム部門へのヒアリングが欠かせません。仕様書が古い場合は、実際の取引データを条件別に集計し、想定していない組み合わせがないかを確かめると漏れを防げます。
評価の6ステップ
| ステップ | 実施内容 | 成果物 |
|---|---|---|
| 1. 統制の理解 | 仕様書、設定画面、担当者への質問で、統制が「何を」「どの条件で」行うかを把握 | 統制記述（RCMの該当行） |
| 2. 分岐の特定 | 処理ロジックの分岐条件（区分、閾値、例外）を洗い出す | テストケース一覧 |
| 3. ITGCとの紐づけ | 依存するITGCとその評価結果を確認 | 依存関係マッピング |
| 4. テストの実施 | 本番データの実例を再計算・再実施、またはテスト環境で検証（本番と同一であることの確認が必要） | テスト記録、画面キャプチャ |
| 5. 期間を通じた有効性の確認 | ITGC有効を根拠に期間全体へ結論を拡張。ITGCに不備があれば代替手続 | 結論の根拠メモ |
| 6. 結論と記録 | 評価結果、例外、判断理由を記載 | 評価調書 |
ステップ4でテスト環境を使う場合は、テスト環境のプログラムが本番環境と同一であることを確かめる必要があります。この確認が抜けると、テスト環境でどれだけ正しく動いても本番の評価にはなりません。
過年度の評価結果を継続利用する3条件
実施基準は、自動化された内部統制が過年度に有効と評価された場合、次の3点を確認・評価したうえで、その結果を記録することで評価結果を継続して利用できるとしています。
- 評価された時点から内部統制が変更されていないこと
- 障害・エラー等の不具合が発生していないこと
- 関連する全般統制の整備及び運用の状況を確認及び評価した結果、全般統制が有効に機能していると判断できること
現行の実施基準は、この継続利用に一定の複数会計期間に一度の頻度で運用状況のテストを実施する方法も含まれると注記しています。そのうえで2023年の改訂により、この方法は「ＩＴ環境の変化を踏まえて慎重に」判断し、必要に応じて監査人と協議すべきであり、「特定の年数を機械的に適用すべきものではない」ことが明確化されました。米国のPCAOB監査基準AS 2201にも、同様の考え方として自動化統制のベンチマーキングが付録で示されています。
継続利用の記録には、変更がないことを示す証拠（プログラムの変更履歴、バージョン情報など）と、障害記録の確認結果を添付します。「変更がないと担当者から聞いた」だけでは、条件1の証拠として弱いと考えてください。
IT依存の手作業統制とIPEの確認
「システムの帳票を人が見る」統制の構造
冒頭の場面で上長が行っていた「請求一覧の確認」は、ITACでも純粋な手作業統制でもなく、システムが出力した情報に依存する手作業統制（IT依存の手作業統制）です。この統制の有効性は二つの要素に分解できます。一つは人のレビューが適切に行われたか、もう一つはレビューに使った帳票が完全かつ正確か、です。
後者の帳票を、実務ではIPE（Information Produced by the Entity、企業が作成した情報）と呼びます。帳票の抽出条件が誤っていて一部の取引が漏れていれば、上長がどれだけ丁寧に見ても、見ていない取引の誤りは発見できません。
IPEの確認方法
IPEの完全性・正確性は、帳票の種類によって確かめ方が変わります。
| 帳票の種類 | 確認のポイント | 手続例 |
|---|---|---|
| 標準帳票（パッケージ標準） | 標準機能のまま使っているか、パラメータ設定が適切か | 出力条件の画面確認、総額を会計残高と照合 |
| カスタム帳票（アドオン） | 抽出ロジックが意図どおりか、変更管理の対象か | ロジックの確認、件数・金額を元データと照合、変更管理ITGCとの紐づけ |
| 利用者がその都度作成する抽出結果（クエリ、表計算加工） | 抽出条件と加工過程が再現できるか | 抽出条件の記録確認、再実行による一致確認 |
特に表計算ソフトで加工した資料は、ITGCの保護が及ばないため、統制の実施者自身が作成過程を記録しておく必要があります。全件データを使った照合の方法はデータ分析監査（CAAT）入門が参考になります。
評価調書の記入例
| 項目 | 記載内容（架空のモデルケース） |
|---|---|
| 統制番号・内容 | S-MC-05 月次で経理課長が売掛金年齢調べ表をレビューし、90日超の債権について営業部に回収見込みを確認する |
| 統制の種類 | IT依存の手作業統制 |
| 使用するIPE | 売掛金年齢調べ表（販売管理システムのカスタム帳票R-12） |
| IPEの確認 | 3月末分の帳票合計を会計システムの売掛金残高と照合し一致。抽出ロジックを仕様書と照合し、年齢区分の計算が請求日基準であることを確認。R-12は変更管理（CHG-01〜03）の対象で、期中の変更なし |
| レビューの確認 | サンプル2か月分（月次統制）で、課長の確認印、90日超債権への照会メール、回答内容の記録を確認 |
| 結論 | 有効 |
よくある失敗と対策
失敗1：自動統制を手作業統制と同じ件数でテストしている
自動計算を25件ずつ再計算している例は珍しくありません。件数を増やしても分岐条件を網羅していなければ意味は薄く、工数だけがかかります。対策は、件数ではなく分岐条件を軸にテストケースを設計することです。
失敗2：ITGCとの紐づけがないまま1件テストで済ませている
1件テストで期間全体を結論づけられるのは、ITGCが有効だからです。依存関係のマッピングがなく、ITGCの評価結果を参照していない調書では、1件テストの結論に根拠がありません。
失敗3：IPEの確認を省略している
帳票を使うレビュー統制で、レビューの証跡（確認印など）だけを見て有効と判断するケースです。帳票の完全性・正確性を確かめた記録がなければ、監査人から追加手続を求められる可能性があります。
失敗4：システムの機能をすべて統制として識別している
統制の数が増えるほど評価工数は膨らみます。財務報告リスクとの対応を一文で説明できないものはRCMから外し、評価の焦点を絞ります。
失敗5：過年度評価の継続利用で3条件の証拠を残していない
「前年有効だったので今年も有効」とだけ記載した調書は、実施基準の条件を満たしていません。変更履歴と障害記録を確認した事実を必ず記録します。
よくある質問
Q1. パッケージソフトをそのまま使っている場合もITACの評価は必要ですか？
必要です。ただし実施基準は、監査人の手続について、販売されているパッケージ・ソフトウェアをそのまま利用するような比較的簡易なシステムを有する企業の場合には、ITGCに重点を置く必要があることに留意するとしています。パッケージの標準機能は設定値の確認が中心になり、自社でカスタマイズした部分やパラメータ設定の変更管理に評価の重点が移ります。
Q2. システム上の権限設定（職務分離）はITACですか、ITGCですか？
実施基準はITACの例に「システムの利用に関する認証、操作範囲の限定などアクセスの管理」を挙げており、業務上の権限設定（例：起票者と承認者を分ける）はITACとして扱うのが一般的です。一方、ユーザーIDの付与・削除の手続や特権IDの管理はITGCのアクセス管理です。詳しくはアクセス管理の監査手順で解説しています。
Q3. テスト環境で検証した結果を本番の評価に使えますか？
使える場合がありますが、テスト環境と本番環境のプログラム・設定が同一であることを確認した証拠が必要です。本番データの実例で再計算できる統制は、本番の実例を使うほうが証拠力は高くなります。
Q4. ITGCに不備があると、ITACの評価はすべてやり直しですか？
すべてが無効になるわけではありません。不備の影響を受けるITACを特定し、期間中に変更がなかったことの確認、複数時点での再テスト、補完的な統制の確認などの代替手続を検討します。どこまで行うかは自社と監査人の判断によります。
まとめ
ITACは取引を、ITGCはITACが働く環境を守る統制です。自動統制を1件のテストで評価できるのは、プログラムが一貫して動くという性質と、それを守るITGCの有効性がそろっているからです。この構造を理解すると、テストの件数を減らせる場面と、減らしてはいけない場面の区別がつくようになります。
次の一歩として、自社のRCMに載っている自動統制とIT依存の手作業統制に「依存するITGC」「使用するIPE」の列を加えてみてください。ITGC側の現状はITGC簡易診断で、アクセス管理・変更管理・運用管理・システム開発の4領域から把握できます。関連記事としてITGC（IT全般統制）とSOC報告書の見方、J-SOX 3点セットの作り方もあわせてご覧ください。
IT統制の評価設計について支援が必要な場合は、お問い合わせからご相談ください。
参考資料
- 金融庁 企業会計審議会「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）」（2023年4月7日）https://www.fsa.go.jp/news/r4/sonota/20230407/20230407.html
- 金融庁「内部統制報告制度に関するQ&A」
- 経済産業省「システム管理基準 追補版（財務報告に係るIT統制ガイダンス）」（2024年12月25日）
- 日本公認会計士協会 財務報告内部統制監査基準報告書第1号「財務報告に係る内部統制の監査」
- PCAOB「AS 2201: An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements」
