業務処理統制と全般統制の違いを金融実務で理解する

業務処理統制と全般統制の違いを金融実務で理解する

業務処理統制と全般統制の違いを正しく理解するために

IT全般統制が有効でないと、業務処理統制のサンプルテストが年1件ではなく、手作業統制と同じ25件以上に跳ね上がり、監査対応コストが数倍になることがあります。


📋 この記事の3ポイント要約
🏗️
全般統制は「土台」、業務処理統制は「個別の建物」

IT全般統制(ITGC)はシステム全体の運用環境を整える基盤。IT業務処理統制(ITAC)は各業務プロセスに直接組み込まれた個別の統制。 土台なくして建物は成り立ちません。

⚠️
全般統制が不備だと業務処理統制も無効化される

IT全般統制に不備があると、業務処理統制がどれだけ完璧でも「有効に運用されていない可能性がある」と評価されます。 J-SOX対応では評価の順番が重要です。

💡
サンプル件数の違いが監査負荷を大きく左右する

全般統制が有効であれば業務処理統制の評価サンプルは原則1件で済みます。全般統制に不備があると複数件のサンプルが必要になり、対応コストが大幅に増加します。


業務処理統制と全般統制の違い:内部統制の全体構造から理解する


金融の現場でJ-SOX(内部統制報告制度)に関わると、「IT統制」という言葉の中に複数の概念が混在していることに気づきます。その中でも特に混同されやすいのが、IT全般統制(ITGC)とIT業務処理統制(ITAC)の違いです。


内部統制の階層は「内部統制>IT統制>IT業務処理統制」という入れ子構造になっています。まず企業全体の方針を定める「内部統制」があり、その中でITに関するルールを定める「IT統制」が位置づけられます。さらにIT統制の中を細分すると、IT全社的統制・IT全般統制・IT業務処理統制の3層に分かれます。この構造を理解しておくことが、2つの統制の違いを正確に掴む出発点です。


金融機関や上場企業の実務担当者が「統制の整備が終わった」と思っていても、どの層のどの統制を整備したのかが曖昧なままでは、監査法人から指摘を受けるリスクが残ります。


構造を俯瞰する視点が大切です。
























名称 役割の概要
第1層 IT全社的統制 経営層が定めるIT戦略・ガバナンス方針
第2層 IT全般統制(ITGC) システム全体の運用・開発・管理環境の統制
第3層 IT業務処理統制(ITAC) 各業務プロセスに直接組み込まれた個別統制


業務処理統制とは何か:ITACの定義と財務報告との関係

IT業務処理統制(ITAC:Information Technology Application Control)とは、金融庁が定める「財務報告に係る内部統制の評価及び監査の基準」に基づく概念です。同基準では「業務を管理するシステムにおいて、承認された業務がすべて正確に処理・記録されることを担保するために業務プロセスに組み込まれたITに係る内部統制」と定義されています。


財務報告の信頼性は、売上データ・仕入データ・在庫データなど、各業務プロセスで生成されるデータの正確性に直接依存します。これらのデータが会計システムに流れ込み、最終的に財務諸表が作られます。つまり、入口のデータが間違えば財務諸表も間違うという単純な構造です。


つまりITACが重要です。業務ごとに「正確なデータが生成される仕組み」を組み込むことが、財務報告全体の品質を左右します。販売システムで受注金額を自動チェックするバリデーション機能も、会計システムへの自動仕訳も、すべてITACの一部です。


業務処理統制の5つの構成要素:入力・データ・出力・スプレッドシート・リスク管理

経済産業省が公表する「システム管理基準追補版(財務報告に係るIT統制ガイダンス)」では、IT業務処理統制を構成する5つの要素が示されています。それぞれを実務の文脈で理解することが重要です。


1つ目は入力管理です。データがシステムに正確に入力されることを保証するための統制で、入力マニュアルの整備・承認フローの設計・ダブルチェック体制などが該当します。経理システムへの誤った数値入力が財務諸表に直結するリスクをここでブロックします。


2つ目はデータ管理(処理統制)です。システム内でのデータの授受・保管・処理が正確かつ安全に行われているかを管理します。IPアドレス制御・不正アクセス防止機能・異常データのチェック機能が典型例です。


これが重要な要素です。


3つ目は出力管理です。財務報告書や取引明細などの出力データに改ざんや誤りがないことを担保する統制です。出力手順のマニュアル化・第三者チェック・編集制限設定などが含まれます。


4つ目はスプレッドシート管理です。ExcelやGoogleスプレッドシートには柔軟性がある反面、数式ミス・無断修正・情報漏洩のリスクが潜みます。財務データをスプレッドシートで扱う企業では、アクセス権限の設定と承認フローが欠かせません。


5つ目はリスク管理です。業務プロセスに潜むリスクを体系的に把握し、適切な統制策を講じる仕組みです。「リスクコントロールマトリックス(RCM)」を活用して、リスクと対応策をマトリックス形式で可視化することが推奨されています。


全般統制(ITGC)とは何か:業務処理統制との役割の本質的な違い

IT全般統制(ITGC:Information Technology General Control)とは、業務処理統制が「有効に機能するための環境」を保証するための統制活動です。EYの公式解説でも「複数の業務処理統制に関係する方針と手続き」と位置づけられており、特定の業務ではなくシステム全体の土台を守るものです。


IT全般統制がカバーする対象範囲は4つの領域で構成されます。



  • 🔧 システムの開発・保守に係る管理:変更管理・テスト・開発手続きの策定など

  • ⚙️ システムの運用・管理:バックアップ体制・構成管理・データ管理など

  • 🔒 アクセス管理などシステムの安全性確保:特権ID管理・多要素認証・セキュリティインシデント管理など

  • 📄 外部委託に関する契約管理:委託先のSLA定義・SOCレポート取得・定期監査など


業務処理統制が「各業務の窓口で個別に機能するフィルター」だとすれば、全般統制はそのフィルターが正しく動き続けるための「電源と設備」に相当します。電源が落ちれば、どんな高性能なフィルターも動きません。この比喩を頭に置いておくと、2つの関係が直感的に理解できます。


参考:EY「内部統制 第6回:ITに係る業務処理統制及びITに係る全般統制」 — ITに係る全般統制と業務処理統制の定義・関係・評価方法について公認会計士による権威ある解説が掲載されています。


https://www.ey.com/ja_jp/technical/corporate-accounting/commentary/internal-control/commentary-internal-control-2012-04-27


業務処理統制と全般統制の違いを図解で整理:対象・目的・評価方法の比較

2つの統制の違いを正確に押さえるには、「対象範囲」「主な目的」「評価の考え方」の3軸で比較するのが有効です。混同しやすいポイントなので、表で整理します。


































比較軸 IT全般統制(ITGC) IT業務処理統制(ITAC)
対象範囲 システム全体・IT環境全般 各業務プロセス・アプリケーション単位
主な目的 ITACが機能する環境の保証 業務データの正確・完全な処理と記録
評価サンプル 毎年整備状況・運用状況を評価 全般統制有効を前提に原則1件で評価
不備の影響 ITACの信頼性が根底から揺らぐ 該当業務プロセスの財務報告に影響
整備の順序 先に整備(ITACの前提) ITGCの後に整備・評価


整備の順序が原則です。IT全社的統制→IT全般統制→IT業務処理統制の順に対応することが、J-SOX実務の基本的な流れです。この順番を逆にして業務処理統制から先に着手してしまうと、全般統制の不備が後から発覚し、すでに完了した業務処理統制の評価をやり直すことになります。


全般統制が不備だと業務処理統制が無効化される仕組み:金融機関が注意すべきリスク

IT全般統制に不備があった場合、財務報告の重要な虚偽記載リスクに直接つながるわけではありません。


これは意外な点です。


EYの解説によると「直ちに開示すべき重要な不備とは評価されない」とされています。


しかし問題はその先にあります。


IT全般統制に不備があると、たとえITに係る業務処理統制が有効に整備されていても、「その有効な運用を継続的に維持することができない可能性がある」と判断されます。その結果として、業務処理統制の運用状況評価のサンプル件数が増え、テスト対象期間が広がり、追加手続きが求められます。


つまり監査コストが跳ね上がります。


痛いですね。


東京商工リサーチの2025年の調査では、内部統制の不備を開示した上場企業が2024年度に58社に達し、2012年度以降で最多を更新しました。IT全般統制の不備(第4位)も増加傾向にあり、特にシステム変更管理の不徹底・特権IDの管理不備・アクセスログ監視の不足が典型的な指摘事例として挙がっています。


金融機関では、与信管理システムや顧客情報管理システムが財務報告に直結する場合が多く、それらのシステムのIT全般統制が不十分であれば、業務処理統制の信頼性ごと失われます。上場金融機関のIT担当者は特に全般統制の整備状況を定期的に点検する必要があります。


参考:経済産業省「システム管理基準 追補版(財務報告に係るIT統制ガイダンス)令和6年版」 — IT全般統制・業務処理統制の評価領域や評価手続きに関する最新ガイドラインです。


https://www.meti.go.jp/policy/netsecurity/docs/secgov/2024_ZaimuHoukokuNiKakaruITTouseiGuidance.pdf


業務処理統制の評価サンプル数が「原則1件」になる条件:見落としがちな全般統制との関係

J-SOX実務を担当している人でも意外と知らないのが、業務処理統制の評価サンプル数に関するルールです。手作業による業務プロセス統制では25件程度のサンプルを収集するのが一般的です。しかしIT業務処理統制の場合は、条件を満たせば年間でたった1件のサンプルで済みます。


その条件とは「IT全般統制の評価が有効であること」です。


これが基本です。


ITシステムは一度正確に動くように設定されれば、変更が加えられない限り同じ処理を一貫して繰り返す性質があります。この「反復継続性」があるために、1件のテストで統制の有効性を確認できるという考え方が認められています。


逆に、IT全般統制に不備があると話は変わります。全般統制が信頼できない環境では、業務処理統制は「単なる手作業の業務プロセス統制」と同等に扱われます。統制の頻度に応じて複数件のサンプルを取得しなければならず、場合によっては手作業統制と同様の25件超のサンプリングが必要になることがあります。


これは使えそうな知識です。


また、過年度の評価結果を翌年度に活用できる条件として、①当該統制に変更がないこと、②統制に不具合が発生していないこと、③IT全般統制が有効に機能していること、の3要件が必要です。これを満たせば毎年同じテストを繰り返す効率化が可能になります。ただし全般統制の整備状況評価は毎年実施が必要な点に注意が必要です。


IT全般統制(ITGC)の4領域を業務処理統制との対比で理解する

IT全般統制は、金融庁・経済産業省の基準において4つの領域で構成されると定義されています。業務処理統制が「何を処理するか」という話であるのに対し、全般統制は「処理を支えるシステム環境をどう維持管理するか」という話です。


① システムの開発・保守に係る管理は、変更管理・テスト・本番リリースの承認手続きを含む領域です。プログラムへの不正な変更や未テストの修正が本番環境に入り込まないよう管理します。この管理が甘いと、業務処理統制の機能自体が気づかないうちに変わってしまうリスクがあります。


② システムの運用・管理は、バックアップ・リカバリー体制・構成管理・データ管理などを含みます。日々の運用が適切に行われているか、障害時に正確なデータが復元できるかを担保する領域です。


③ アクセス管理などシステムの安全性確保は、2025年の内部統制指摘ランキングでも第4位に入ったIT全般統制不備の中でも最も多く指摘される領域です。特権ID(管理者権限)の棚卸し・多要素認証(MFA)の導入・アクセスログの定期レビューが主な対策です。


④ 外部委託に関する契約管理は、クラウドサービスやBPOが普及した現代において重要性が増している領域です。外部委託先のSOCレポート取得・SLA(サービスレベル合意)の確認・定期的な委託先監査が求められます。外部委託先の統制不備は自社のIT全般統制の不備として評価される点に注意が必要です。


業務処理統制のテスト方法:ウォークスルーとサンプリングの具体的な進め方

IT業務処理統制の評価には、「ウォークスルー評価」と「サンプリング評価」の2つの手法が活用されます。それぞれの特徴を理解した上で、評価対象に応じて使い分けることが実務上のポイントです。


ウォークスルー評価は、実際の取引を最初から最後まで追跡し、処理の流れと統制の有効性を一連の流れとして確認する方法です。統制の整備状況を把握するのに適しており、内部統制の評価初年度や業務フローに変更があった場合に特に有効です。


サンプリング評価は、一定期間の取引データから無作為に抽出し、統制が正しく運用されているかを確認する方法です。


これが基本です。


IT業務処理統制の場合、自動化された機能については「テスト実施者自らがダミーデータを入力して機能を再現する」という方法が特徴的です。これは手作業統制のように「証憑を複数枚確認する」という方法とは異なります。


具体的なテスト例を挙げると、エディットバリデーションチェック(入力フォーマット確認機能)のテストでは、システムの受注登録画面で必須項目をブランクのまま次のページへ進もうとすると、エラーが表示されることを実際に確認します。マッチング機能のテストでは、商品マスタに存在しないコードを入力したときにシステムが受け付けないことを確認します。


テスト環境について判断が必要な場面があります。本番環境に影響のないテストは本番環境で実施する方が効率的ですが、データを直接書き込むようなテストはテスト環境を別途用意する必要があります。事前に情報システム部門や現場部門と確認を取ることが重要です。


J-SOX改訂(2024年)が業務処理統制・全般統制の評価に与えた影響

2024年4月、15年ぶりの内部統制基準改訂が施行されました。この改訂はIT統制の評価にも大きな影響を与えています。


最も影響が大きかったのは「リスクアプローチの徹底」です。従来は「売上高の3分の2」という機械的な基準で評価範囲を決定するケースが多くありましたが、改訂後はリスク評価を基に質的重要性を考慮した評価範囲の決定が必要になりました。業種・業態・過去の不備発生状況・環境変化などを踏まえて判断する必要があります。


IT全般統制に関しては、サイバーセキュリティ対応が評価対象として明確化されました。ランサムウェア攻撃の急増を背景に、セキュリティリスクへの対応状況も全般統制の評価領域として位置づけられています。クラウドサービスのセキュリティ評価や、外部委託先のSOCレポート確認もより厳しく求められるようになっています。


また、IT業務処理統制の運用状況評価については、2024年改訂前から「前年度評価結果の利用」に関する規定がありましたが、今回の改訂でクラウドサービスや外部委託システムにおける統制評価の考え方が整理されました。クラウド上のシステムで稼働する業務処理統制については、システム提供事業者のSOCレポートを取得・確認することが有効な対応策とされています。


参考:金融庁「財務報告に係る内部統制の評価及び監査の基準」(2023年4月改訂) — J-SOX実務の根拠となる基準文書です。


https://www.fsa.go.jp/singi/singi_kigyou/kijun/20191206_naibutousei_kansa.pdf


業務処理統制の構築ポイント:金融業務の現場で使える具体的なアプローチ

IT業務処理統制を実際に構築・整備する際には、いくつかの実務的な判断が必要です。まず重要なのは、業務プロセスの中に潜む財務リスクを洗い出すことから始める点です。リスクが明確になって初めて、「その リスクを手作業で対応するか、ITで対応するか」という選択が意味を持ちます。


自動化された統制機能については、多くの企業がERPや会計パッケージを導入しているため、「内部統制のためにゼロからシステム機能を開発する」必要はほとんどありません。導入済みシステムにすでに備わっているバリデーション機能・承認ワークフロー・アクセス制限などを、現行業務リスクに照らして「有効に機能しているか」を確認することが主なタスクになります。


一方、人手とシステムの処理が一体となった統制(ハイブリッド統制)については注意が必要です。この場合、システムが異常値を検知し、人がその内容を確認して押印・承認するという流れになりますが、人的な部分が形骸化してしまうと統制全体の機能が失われます。


統制を整備する際は、業務効率と統制強度のバランスが重要です。確認ステップを増やしすぎると現場が過度な負担を感じて形式的な対応になり、結果として「統制があるが機能していない」という状態に陥ります。実務に即した設計を意識することが、持続可能な内部統制の鍵です。


業務処理統制と全般統制の独自視点:スプレッドシート管理がITACの「盲点」になりやすい理由

IT業務処理統制の5要素の中で最も見落とされやすいのが、スプレッドシート管理です。多くの企業では「Excelは手作業のツールだから、IT統制ではなく手作業統制として扱えばよい」という誤解があります。


これは違います。


金融庁・経済産業省の基準では、スプレッドシートを用いた財務計算処理はIT業務処理統制の評価対象として明確に位置づけられています。特にExcelのマクロ(VBA)やGASを使った自動処理が組み込まれている場合、それはシステムによる自動処理統制と同等の扱いになります。関数の誤りやマクロのバグが財務諸表に反映されるリスクは、基幹システムのプログラムバグと本質的に変わりません。


金融機関の実務では、収益計算・与信スコアリング・時価評価などの重要な処理がExcelで行われているケースが今も少なくありません。こういった処理に対しては、①作成者とは別の担当者によるレビュー、②承認フローの設定、③アクセス権限の制限(編集者・閲覧者の区分け)、④定期的なバックアップという4つの対策が最低限必要です。


これだけ覚えておけばOKです。


また、外部委託先やコンサルタントが作成したExcelモデルを「提供されたまま使っている」ケースも要注意です。そのシートの数式が正しいかを独自に検証していなければ、入力管理・出力管理ともに不十分と評価される可能性があります。


業務処理統制・全般統制の整備を進めるための実践的なステップ

実際にIT統制を整備・改善するための手順を、実務の流れに沿って整理します。特にIPOを目指す企業や、J-SOX対応を見直したい金融業務の担当者に参考にしてもらえる内容です。


ステップ1:業務プロセスのIT依存度を把握する。まず、評価対象となる業務プロセスがどのシステムに依存しているかをマッピングします。販売・購買・在庫・会計など主要プロセスとシステムの関係図(システム関連図)を作成することが出発点です。


ステップ2:対象システムのIT全般統制を評価する。変更管理・アクセス管理・運用管理・外部委託管理の4領域を評価します。特に特権IDの棚卸しとアクセスログの確認は、監査法人から最も指摘を受けやすい箇所です。


ステップ3:業務プロセス内のITACを識別・評価する。各業務の入力・処理・出力の各段階でどのような自動統制機能が存在するかを確認し、リスクコントロールマトリックス(RCM)に反映します。スプレッドシートを使った処理が含まれる場合は忘れずに含める必要があります。


ステップ4:評価結果に基づき改善計画を立てる。不備が発見された場合は、その重要度を評価した上で改善計画書を作成します。IT全般統制の不備は業務処理統制全体に影響するため、優先的に対応します。短期での修正が困難な場合は「補完統制」を暫定的に設けることで、監査対応を継続できます。


ステップ5:PDCAで継続的にモニタリングする。内部統制は一度整備したら終わりではありません。業務変更・システム変更・組織変更のたびに文書を更新し、実態と統制の記録が一致している状態を維持することが求められます。


この継続性が最も重要です。


参考:日本公認会計士協会「財務報告に係る内部統制の監査」 — 監査人の立場からIT全般統制・業務処理統制の評価に関する実務的な考え方が整理されています。


https://jicpa.or.jp/specialized_field/2-24-nkh1-2-20240926.pdf




【日本円専用設計・2024年新紙幣/旧紙幣に対応】卓上型紙幣計数機 日本紙幣 商品券 外貨 マネーカウンター 立式 多種類偽札検知機能 日本語表記 日本語音声 【PSE認証取得】自動計算1001枚/分高速カウント デジタル表示 簡単操作 業務用 (立式紙幣計数機)