会計システムや販売管理システム、ERP の利用が進むにつれて、財務報告に係る内部統制の多くがシステムの中に組み込まれるようになりました。こうしたシステムによる統制を IT業務処理統制（ITAC）と呼びます。ITAC は、正しく評価すれば手作業の統制よりも少ない工数で有効性を確認できる一方で、「どこまでが自動統制なのか判断がつかない」「手作業の統制と同じように多数のサンプルをテストしている」「システムから出力したレポートの信頼性を確認していない」といった課題もよく見られます。本記事では、内部統制報告制度（J-SOX）の評価を担当する方に向けて、ITAC の基本と自動統制の種類、評価手順とテスト方法、評価を効率化するための考え方をチェックリストとあわせて解説します。
ITAC（IT業務処理統制）とは
IT業務処理統制とは、業務を管理するシステムにおいて、承認された業務がすべて正確に処理、記録されることを確保するために業務プロセスに組み込まれた IT に係る内部統制です。財務報告に係る内部統制の評価及び監査に関する実施基準では、IT業務処理統制の例として次のようなものが挙げられています。
- 入力情報の完全性、正確性、正当性等を確保する統制
- 例外処理（エラー）の修正と再処理
- マスタ・データの維持管理
- システムの利用に関する認証、操作範囲の限定などアクセスの管理
実務では、ITAC を「システムが自動的に実行する統制（自動統制）」と、「システムが出力した情報を使って人が行う統制（IT依存の手作業統制）」に分けて考えると整理しやすくなります。後者は統制そのものは手作業ですが、使用するレポートや一覧が正確かつ網羅的であることが前提になるため、その情報の信頼性も評価の対象になります。
自動統制の主な種類
自動統制にはさまざまな形態があります。代表的な種類と評価のポイントを整理すると次のとおりです。
| 種類 | 統制の例 | 主な評価のポイント |
|---|---|---|
| 入力チェック（エディットチェック） | 必須項目の未入力や、日付・金額の形式誤りを登録できない | チェックの設定内容と、異常な入力が実際に拒否されるか |
| 自動計算 | 数量×単価による請求金額の計算、減価償却費の計算 | 計算ロジックが正しく、期中に変更されていないか |
| 照合（マッチング） | 発注・検収・請求の 3 点照合で、不一致の場合に支払を保留する | 照合の条件と許容差の設定、不一致時の処理 |
| 承認ワークフロー | 金額に応じて承認者が自動的に決まり、承認前は次工程に進めない | 承認ルートの設定が権限規程と整合しているか、承認を回避できないか |
| アクセス制限・職務分離 | 仕訳の起票者と承認者を同一人物にできない | 権限設定と、同一人物による処理を防ぐ制御 |
| インターフェース | 販売管理システムから会計システムへの仕訳の自動連携 | 連携データの件数・金額の一致、エラー時の処理 |
| 自動仕訳・自動転記 | 売上計上時の仕訳の自動生成 | 仕訳パターン（勘定科目の設定）の正確性 |
自社の RCM（リスクコントロールマトリクス）に記載された統制が、本当にシステムで強制されているのか、それとも担当者の運用に委ねられているのかを見極めることが、評価の最初のステップになります。たとえば「システム上で承認する」と書かれていても、承認なしで次工程に進める設定であれば、それは自動統制ではなく手作業の統制として評価する必要があります。
ITAC 評価の全体像
ITAC の評価は、概ね次の流れで進めます。
- 統制の識別: 業務記述書や RCM から、システムに依拠している統制を洗い出し、自動統制か IT 依存の手作業統制かを区分する
- 統制の仕様の把握: システムの設定画面、仕様書、IT 部門や業務部門へのヒアリングにより、統制がどのように実装されているかを把握する
- 整備状況の評価: 統制の設計が、対応するリスクを十分に低減できるものかを確認する
- 運用状況の評価: 統制が評価対象期間を通じて設計どおりに機能しているかを確認する
- ITGC との関係の確認: 統制の継続的な有効性を支える IT全般統制（ITGC）の評価結果を確認する
このうち 5 の確認が、ITAC 評価の効率を大きく左右します。評価の実施にあたっては、業務部門、IT 部門、評価者の役割分担を事前に決めておくと円滑に進みます。統制の仕様は IT 部門やシステムのベンダーが最もよく把握している一方、統制がどのリスクに対応しているのかは業務部門の理解が欠かせません。評価者は両者の情報をつなぎ、統制の記述とテスト手続に落とし込む役割を担います。
ITGC の評価の進め方については「ITGC（IT全般統制）評価の実務」で詳しく解説しています。
自動統制のテスト方法
自動統制は、同じ条件の処理に対して常に同じ結果を返すという性質があります。そのため、手作業の統制のように多数のサンプルを抽出するのではなく、統制が想定するパターンごとに、設計どおりに機能することを確かめるテストが中心になります。
設定内容の確認（インスペクション）
システムの設定画面やマスタ、パラメータを閲覧し、統制が意図どおりに設定されているかを確認します。たとえば承認ワークフローであれば、金額区分ごとの承認者の設定が権限規程と一致しているか、承認をスキップできる設定になっていないかを確認します。設定画面の写しを証拠として残す場合は、対象システム、画面名、取得日時が分かるようにしておきます。
テストデータによる確認
テスト環境や本番環境で、統制が働くべきデータを実際に入力し、システムが期待どおりに反応するかを確認する方法です。入力チェックであれば、必須項目を空欄にしたデータや、上限を超える金額のデータを登録しようとして、エラーになることを確認します。テスト環境を使う場合は、テスト環境の設定やプログラムが本番環境と同一であることを別途確認する必要があります。
再実施・再計算
システムが実行した処理を、評価者が独立して再計算・再実施し、結果が一致するかを確認する方法です。自動計算や照合の統制で用いられます。対象となる取引を選び、システムの計算結果と評価者の計算結果を比較します。全件のデータを入手できる場合は、データ分析ツールを使って全件を再計算することも可能です。全件分析の手法については「CAATによる全件テストの進め方」も参考にしてください。
パターンごとのテスト件数
自動統制のテストでは、統制が想定する条件の組合せ（パターン）ごとに少数の取引を確認するのが一般的です。たとえば 3 点照合であれば、「すべて一致する場合」「数量が一致しない場合」「金額が許容差を超える場合」といった条件ごとに、システムが正しく処理を分岐させることを確認します。重要なのは件数よりも、正常系と異常系の両方のパターンを網羅しているかどうかです。
テストパターンの設計例（3 点照合）
パターンの設計は、統制の仕様から「システムが分岐する条件」を洗い出すことから始めます。3 点照合の統制を例に、テスト手続の記載例を示します。
| No. | テストパターン | 入力・選定するデータ | 期待する結果 |
|---|---|---|---|
| 1 | 発注・検収・請求がすべて一致 | 数量・単価・金額が一致する取引 | 照合済となり、支払対象に計上される |
| 2 | 検収数量が発注数量より少ない | 分割納品で一部のみ検収済の取引 | 不一致として支払保留になる |
| 3 | 請求金額が許容差の範囲内で相違 | 端数処理による差額がある取引 | 許容差内として照合済になる |
| 4 | 請求金額が許容差を超えて相違 | 単価が発注と異なる請求 | 不一致として支払保留になる |
| 5 | 保留を解除して支払う | 保留中の取引 | 解除権限を持つ者のみが解除でき、解除履歴が残る |
No.5 のように、例外処理の経路もパターンに含めることが重要です。照合の仕組みが正しくても、保留を誰でも解除できるのであれば、統制は容易に回避できてしまいます。テスト手続書には、パターンごとに「期待する結果」を事前に記載し、実施後に「実際の結果」と「結論」を記入する形式にすると、レビューもしやすくなります。
証拠として残す内容
自動統制のテストでは、手作業の統制に比べて証拠の形が多様になるため、何を残せば第三者が結論を検証できるかを意識します。一般的には、テストしたパターンの一覧、入力したデータと期待した結果、実際にシステムが返した結果（エラーメッセージや処理結果の画面の写しなど）、確認した設定画面の写しを、取得日時とあわせて保存します。テストを IT 部門の担当者に操作してもらう場合は、評価者が立ち会い、操作の内容と結果を直接確認したことを記録しておきます。
システム出力レポートの信頼性の確認
IT 依存の手作業統制では、担当者が確認に使うレポートや一覧が正確かつ網羅的でなければ、統制が有効とはいえません。たとえば、滞留債権一覧を見て回収状況を確認する統制があっても、一覧に一部の債権が表示されていなければ、確認の対象から漏れてしまいます。
レポートの信頼性を確認する際は、次のような観点で手続を検討します。
- レポートが標準機能で出力されるものか、独自に作成された（カスタマイズされた）ものか
- 抽出条件やパラメータが、統制の目的に照らして適切に設定されているか
- レポートの件数・合計金額が、元のデータ（会計帳簿やシステムのテーブル）と一致するか
- レポートのロジックが期中に変更されていないか（変更管理の対象になっているか）
- 担当者が Excel などで加工している場合、その加工の過程で誤りが生じていないか
実務では、次のような手順でレポートの信頼性を確認することが多くあります。
- 統制の担当者が実際に使用したレポートを入手し、出力日時と抽出条件（パラメータ）を確認する
- 同じ条件でレポートを評価者の立会いのもとで再出力する、またはシステムのテーブルから同じ条件でデータを抽出する
- レポートの件数・合計金額と、元データや会計帳簿の残高を照合する
- 元データから数件を選んでレポートに含まれていることを確認し、逆にレポートから数件を選んで元データと内容が一致することを確認する
- カスタマイズされたレポートの場合は、抽出ロジックの仕様書や変更履歴を確認する
評価調書には、「滞留債権一覧（出力日○月○日、条件：期日経過 30 日以上）の件数・金額が、売掛金補助元帳の期日経過 30 日以上の残高と一致することを確認した」のように、確認した対象と結果を具体的に記載します。
特に、表計算ソフトで作成した管理表や計算シートを統制に使っている場合は、数式の保護、変更履歴、作成者以外によるチェックなど、利用者側で必要な統制が整っているかも確認の対象になります。
ITGC との関係と評価の効率化
自動統制は、一度正しく設定されれば、プログラムや設定が変更されない限り同じように機能し続けます。そのため、変更管理やアクセス管理などの ITGC が有効に機能していることを前提に、評価の効率化を図ることができます。
実施基準では、IT を利用した内部統制について、IT全般統制が有効に整備・運用されている場合には、前年度の評価結果を継続して利用できる場合がある旨が示されています。この考え方を適用する場合は、次の点を確認しておく必要があります。
- 前年度に当該自動統制を評価し、有効と判断した記録があること
- 当年度に、関連するプログラムや設定の変更がないこと（変更管理の記録やシステムの変更履歴で確認）
- 関連する ITGC が当年度も有効であること
逆にいえば、ITGC に不備がある場合は、自動統制が期中を通じて同じように機能していたと判断することが難しくなります。その場合は、対象期間の複数時点で自動統制をテストする、期中の変更の有無を個別に確認するなど、追加の手続が必要になることがあります。ITAC の評価を効率化するうえでも、ITGC の品質を高めておくことが重要です。
なお、J-SOX 2024 改訂では、IT全般統制の運用評価を複数会計期間に一度とする取扱いについて、特定の年数を機械的に適用せず、IT 環境の変化等を踏まえて慎重に判断することが明確化されました。自動統制について前年度の評価結果を利用する場合も、同様にシステムの変更状況を踏まえて判断し、その根拠を文書化しておくことが大切です。
評価でつまずきやすいポイント
ITAC の評価で実務上つまずきやすいポイントと、その対応をまとめます。
- 統制の仕様が分からない: 導入時の仕様書が残っていない、担当者が交代しているといった場合は、設定画面の確認とテストデータによる確認を組み合わせて仕様を把握し、その結果を統制の記述として文書化する
- パッケージ・SaaS の標準機能: カスタマイズしていない標準機能であっても、自社で設定するパラメータ（承認金額の区分、照合の許容差など）は自社で確認する必要がある
- テスト環境と本番環境の差異: テスト環境で確認する場合は、両環境の設定が一致していることを示す証拠を入手する
- 手作業による上書き: 自動統制を担当者が手作業で解除・上書きできる機能がある場合は、その権限者と利用状況も確認する
ITAC 評価チェックリスト
評価の準備と実施状況を確認するためのチェックリストです。自社の評価手続書に合わせて調整してご活用ください。
- RCM 上の IT に関係する統制を、自動統制と IT 依存の手作業統制に区分したか
- 自動統制が実際にシステムで強制されている（回避できない）ことを確認したか
- 統制の設定内容（パラメータ・マスタ）を閲覧し、規程と整合していることを確認したか
- 正常系と異常系の両方のパターンでテストを行ったか
- テスト環境を使った場合、本番環境との同一性を確認したか
- 統制に使うレポートの網羅性と正確性を、元データとの突合などで確認したか
- 表計算ソフトによる加工がある場合、その正確性を確認したか
- 関連する ITGC（変更管理・アクセス管理）の評価結果を確認したか
- 前年度の評価結果を利用する場合、変更がないことの根拠を文書化したか
- 自動統制を手作業で解除・上書きできる権限者と、その利用状況を確認したか
不備が見つかった場合の対応
ITAC のテストで統制が設計どおりに機能していないことが分かった場合は、次の観点で影響を検討します。
- 不備の性質: 設定の誤り、統制の回避が可能な設計、期中のプログラム変更による機能停止など、不備の原因を特定します
- 影響を受けた期間と取引: いつから不備が生じていたのかを変更履歴などで特定し、その期間に処理された取引の範囲を把握します。自動統制の不備は、同じ条件の取引すべてに影響するため、影響範囲が広くなりやすい点に注意します
- 補完する統制の有無: 月次の照合や上位者によるレビューなど、同じリスクに対応する他の統制が有効であれば、不備の影響が低減されている可能性があります
- 虚偽記載の有無の確認: 影響を受けた取引をデータ分析で抽出し、実際に誤った処理が生じていないかを確認します
不備の是正後は、修正された設定やプログラムが本番環境に正しく反映されていることを、変更管理の記録とあわせて確認し、是正後の期間について改めてテストを行います。不備の評価と開示すべき重要な不備の判断については、J-SOX の評価全体の中で検討する必要があるため、早い段階で監査人と情報を共有しておくことが望まれます。
よくある質問
Q. 自動統制のテストは、毎年 1 件だけで十分なのでしょうか。
A. 自動統制はパターンごとに少数の取引でテストするのが一般的ですが、「1 件で十分」と一律に決まっているわけではありません。統制が想定する正常系・異常系のパターンをすべて網羅しているか、関連する ITGC が有効か、前年度からの変更がないかといった条件を満たしたうえで、各パターンのテスト件数を決めます。ITGC に不備がある場合は、期中の複数時点でテストするなどの追加手続を検討します。
Q. SaaS の標準機能として提供されている自動統制は、どう評価すればよいですか。
A. 標準機能の処理ロジック自体については、事業者の SOC1 報告書などで、プログラム変更や処理の正確性に関する統制を確認する方法があります。一方で、承認金額の区分や照合の許容差など、自社で設定するパラメータは自社で確認が必要です。SOC報告書の読み方は「クラウド・SaaS利用時の内部統制とSOC報告書の読み方」で解説しています。
Q. システムの入れ替えがあった年度は、どのように評価すればよいですか。
A. 新システムで稼働する自動統制は、前年度の評価結果を利用できないため、改めて整備・運用評価を行います。あわせて、旧システムから新システムへのデータ移行が正確かつ網羅的に行われたかを確認することも重要です。移行時の件数・金額の照合記録や、移行後の残高の突合結果を入手し、評価の記録に残します。期中に入れ替えた場合は、旧システムの稼働期間についても評価が必要かを検討します。
Q. 自動統制と手作業統制が組み合わさっている場合は、どう扱いますか。
A. 例えば、システムが不一致を自動検知し、担当者がその一覧を確認して対応する統制は、自動の検知部分と手作業の対応部分に分けて評価します。検知の部分は自動統制としてパターンごとにテストし、対応の部分は手作業の統制としてサンプルで運用状況を確認します。手作業の部分で使う一覧については、レポートの信頼性の確認も必要です。
まとめ
ITAC の評価では、まず RCM 上の統制が本当にシステムで強制されているのかを見極め、自動統制と IT 依存の手作業統制を区分することが出発点になります。自動統制は、例外処理の経路を含めた正常系・異常系のパターンを設計し、パターンごとの少数のテストで有効性を確認でき、ITGC が有効であれば前年度の評価結果を活用できる場合もあります。一方で、統制に使うレポートの信頼性や、手作業による上書きの有無といった論点も見落とさないようにする必要があります。不備が見つかった場合は、影響を受けた期間と取引の範囲、補完する統制を踏まえて影響を評価し、是正後の再テストまで行います。本記事のテストパターンの設計例とチェックリストを参考に、自社の ITAC 評価の手順と文書化の状況を点検してみてください。
