IT全般統制と業務処理統制とは？ 内部統制・アクセス管理・監査証跡を実例で理解する

1. そもそも内部統制とは何か

内部統制は、会社が業務を適切に進めるため、経営者・管理者・従業員が整備し運用する仕組みです。不正や誤りをゼロにする魔法ではありません。人的ミス、共謀、経営者による無効化、コスト上の制約などの限界を理解し、合理的な保証を目指します。

財務報告を例にすると、誤った売上計上や二重支払、架空の仕入先への送金、承認を経ないマスタ変更などがリスクです。業務規程を作るだけではなく、入力・承認・記録・照合の各段階でリスクを抑える必要があります。

2. ITへの対応：なぜ2種類に分けるのか

システムの設定、ソフトウェアの変更、運用基盤の障害は、多くの業務に同時に影響します。一方、個々の取引には、金額・取引先・承認者・入力内容など、その業務ならではの条件があります。そのため「共通基盤を支える統制」と「業務に埋め込まれた統制」を分けて評価します。

3. 全般統制の4つの代表領域

代表的な分類として、開発・保守、運用管理、アクセス管理などの安全性確保、外部委託管理があります。以下の項目は組織のIT環境にまたがるため、複数の業務システムに影響します。

4. 業務処理統制の4つの代表領域

業務処理統制は、承認された業務が正確かつ漏れなく処理・記録されることを支えます。実装場所はWeb画面、API、バッチ、データベース制約などさまざまです。

5. IDとパスワードはなぜ統制になる？

ログイン画面が単に表示されることと、適切な利用者だけが必要な業務に進めることは異なります。認証（本人確認）と認可（権限判断）を分け、操作の前にチェックし、拒否と承認の記録を残します。認証機能を特定の業務アプリケーションに組み込み、そのシステムへの不正な利用を制限することは、業務処理統制として位置付けられる例があります。

ただし実務では、全社共通の認証基盤、アプリケーション独自のアクセス制御、特権管理を複合的に設計するため、特定の製品や機能が常に一方に分類されるわけではありません。リスクと統制目的、評価単位で分類します。ID・パスワードのみで十分と決めつけず、リスクに応じて多要素認証、再認証、セッション管理も検討します。

6. 認証・認可・職務分掌（SoD）

ロールベースアクセス制御（RBAC）だけでは、同じ担当者が申請ロールと承認ロールを兼務できてしまうことがあります。職務分掌は「1人の担当者が申請と承認を両方できない」という取引単位の制約まで設計する必要があります。また、権限変更自体の承認や定期棚卸は全般統制の重要な仕事です。

7. 自動統制と手動統制を組み合わせる

自動統制は毎回同じ条件で高速に検証できる利点があります。一方、ルールの設定ミスや改ざんがあれば、誤った判定が大量に再現されます。手動統制では例外判断やリスク評価ができますが、判断のばらつきや見落としが生じます。両者を補完させます。

8. 二重支払を防ぐ設計を考える

支払データはネットワーク再送や画面の二度押し、夜間バッチの再実行によって重複する可能性があります。業務処理統制として伝票番号の一意性チェックや冪等キー、突合せを採用します。チェックの結果として処理を拒否した場合は、その理由を記録し、正当な例外を人が再処理できる運用も必要です。

-- 例：同じ請求書を二重登録させない制約
CREATE TABLE payments (
  payment_id BIGINT PRIMARY KEY,
  supplier_id BIGINT NOT NULL,
  invoice_no VARCHAR(64) NOT NULL,
  amount DECIMAL(12,2) NOT NULL CHECK (amount > 0),
  UNIQUE (supplier_id, invoice_no)
);

-- DB制約に加えて、アプリ側でも認可と
-- 承認の検証、操作ログ記録を行う。

9. システム監査では何を確認するのか

設計書に「承認必須」と書いてあっても、システムが実際に条件を強制しているとは限りません。設計（整備）と運用（有効に働いていたか）を分けて、対象期間中の設定、証跡、再現テストなどを確認します。

10. IT全般統制が弱いと業務処理統制の評価にどう影響する？

例えば注文金額の自動計算が正しいことを一度テストしても、誰でも本番の計算プログラムを書き換えられるなら、対象期間を通じてその統制に依拠できるとは限りません。変更管理、運用管理、アクセス管理などの全般統制をあわせて評価する必要があります。ITACの各統制が直ちに無効となるわけではなく、影響範囲・代替的な手続・補完統制を個別に検討します。

11. 財務報告とJ-SOXの関係

日本の内部統制報告制度は、財務報告の信頼性を確保するため、対象企業が内部統制の整備・運用を評価し、報告する枠組みです。「J-SOX」と呼ばれることがあります。2023年には関連する基準・実施基準が改訂されました。ITGCとITACの分類は、システムを単に安全にするだけでなく、信頼できる財務データが作られるかという観点でも重要です。

12. 「内部統制」と「セキュリティ対策」の重なり

MFA、最小権限、ログ保護、変更管理などはセキュリティ上も内部統制上も役に立ちます。ただし脅威の範囲が同じとは限りません。例えば不正ログイン対策を強化しても、権限を持つ担当者による架空支払は防げないため、職務分掌や明細照合、例外検知などの業務統制が必要です。

13. 現場で使える導入手順

1. 業務フローと重要データ（売上、債権、支払先、残高など）を洗い出す。
2. 誤り・不正のリスクと、守りたい取引の性質（正確性・網羅性・承認など）を定義する。
3. 共通基盤はITGC、各業務はITACの責任者・統制内容を対応付ける。
4. 自動制御を実装し、例外時の承認・再処理と証跡の保全を設計する。
5. 設計を試験し、継続的に権限棚卸・変更レビュー・例外分析を行う。

14. 覚え方：目的・対象・証拠で区別する

現場では境界が重なるケースもあります。単純に「ログインはITAC、アクセス管理はITGC」と丸暗記するのではなく、組織共通の運用環境を整えるものか、それとも業務システム内の取引が正しく処理されるかを直接検証するものかを確かめると判断しやすくなります。

15. よくある質問

16. 実践ラボ：支払申請・承認の統制を動かす

利用者、金額、同一伝票、ログイン状態、承認分離の設定を変更して、統制の有無で業務処理がどう変わるかを確認しましょう。統制を無効にして通過させる操作は教育用のシミュレーションであり、実システムへの操作ではありません。

17. まとめ

IT全般統制（ITGC）は開発・運用・アクセス管理・委託先管理などの共通環境を支え、IT業務処理統制（ITAC）は取引ごとの入力・承認・処理・記録を守ります。システムの認証や承認チェックは業務処理統制の例となり得ますが、全社的な権限管理手続や研修とは作用点が異なります。何のリスクを、どの処理で、どんな証拠をもって抑えるかで考えることが本質です。