ITAC_過年度証拠は使える？自動化された情報処理統制（ITAC)で“変更なし”を立証する方法
- ITAC
- 2026.01.16更新
期中に運用評価（統制テスト）を実施した場合でも、「その時点で有効だった」だけでは足りません。監査（あるいはJ-SOX評価）としては、テスト実施後から期末までの間に統制が重要な変更を受けていないか、そして残余期間（期末まで）も有効に運用されていると言えるだけの追加証拠が必要かを検討します。これは、過年度の監査証拠を今年度に流用する（ロールフォワード／過年度依拠）場合も同じで、前回の監査終了後に重要な変更が起きていないことを裏付けなければ、過年度の結論をそのまま使うことはできません。
1. なぜ「残余期間」の確認が必要なのか（期中テストの落とし穴）
例えば、4月〜6月にアクセス権の棚卸し統制をテストして「有効」と結論づけたとしても、7月に人事異動で権限付与プロセスが崩れたり、9月にシステム更改で設定が変わったりすれば、期末時点では統制が有効ではない可能性があります。
そのため、期中で監査証拠を入手した場合は、
- テスト実施以降に重要な変更がないか
- 期末までの間に追加で何を確認すべきか（追加テストが必要か）
を検討します。
同様に、前年にテストした結果を今年も使いたい場合は、前年の監査終了後から今年の期末までに、統制の前提が変わっていないこと（重要な変更がないこと）を確認する必要があります。
2. 自動化された情報処理統制は「過年度依拠しやすい」—ただし条件付き
「自動化された情報処理統制」は、ITアプリケーションに組み込まれた統制です。代表例は次のようなものです。
- 入力チェック（必須項目、上限下限、形式チェック）
- 承認ワークフロー（承認なしでは起票できない制御）
- マスタ照合（存在しない取引先コードを入力できない）
- 自動計算（外貨換算、消費税計算、減価償却など）
これらは、プログラムや設定が変わらない限り、処理が一貫して同じ結果になるという特徴があります。だからこそ、一定の条件を満たせば、過年度に取った監査証拠（統制テスト結果）を今年も活用できる余地があります。
ただし、それが許容されるのは概ね次の2条件が揃う場合です。
- 関連するIT全般統制（ITGC）が有効であること （特に変更管理・アクセス管理が弱いと、「気づかないうちに変わっている」リスクが高くなる）
- 当該自動化統制に関係するプログラム（または設定）が変更されていないことを確認できること
3. 「変更がない」ことはどう確かめる？（実務手順と具体例）
監査人（評価者）はいきなり技術的検証から入るのではなく、通常は次の順で進めます。
ステップ①：まずは質問で確認する
まず、業務担当者や情シスに対して「前年（または運用評価実施時点）から変更はありましたか？」と確認します。
ただし、質問だけでは証拠として弱いので、次のステップが必要になります。
ステップ②：裏付け（客観的証拠）を取る
裏付け方法は、システムがパッケージか、自社開発・アドオンを含むERPかで実務が変わります。
4. ケース別：変更有無の確認方法
ケース1：市販の簡易パッケージを「カスタマイズなし」で利用している場合
この場合は比較的確認がしやすく、実務では次のような手続が有効です。
- バージョン情報の確認
前期末と当期のバージョンを比較し、更新の有無を把握します。 - リリースノート（変更内容の記録）の確認
ベンダーが提供するリリースノートには、追加・修正された機能が記載されていることが多いので、 それを確認することで「統制に影響する変更が入っていないか」の心証を得られる場合があります。 - 注意点：バージョンが同じでも、設定変更で統制が変わることがある
例えば、
・承認フローの閾値（◯円以上で部長承認）を変更した
・入力チェック条件（郵便番号チェックON/OFF）を切り替えたなど、環境設定だけで自動化統制の挙動が変わることがあります。 このため、バージョン確認に加えて 主要設定の変更履歴や権限者の変更操作ログ を確認する、といった配慮が必要です。
ケース2：自社開発ソフト、またはアドオン開発されたERPを利用している場合
自社開発やERPアドオンがある場合、統制に関係するプログラムを特定し、該当プログラムが変更されていないことを直接確認するアプローチが中心になります。
- 統制に関係するプログラム（モジュール）を特定する
例：売上計上の自動仕訳を作る処理、承認ワークフロー、入力チェックロジック、インターフェース処理、など - 最終更新日・変更履歴をシステム上で確認する
例えば、対象プログラムの最終更新日が運用評価実施日より前であり、以後更新がないことを確認できれば、
「テスト後に統制が変わっていない」と判断しやすくなります。 - 重要ポイント：プログラム特定の網羅性が命
“本当にその統制に影響するプログラムを漏れなく特定できたか”が結論の信頼性を左右します。
このため、ERPや開発構造を理解したIT専門家の関与が必要になる場面が増えます。 - 注意点：「変更がない」こと自体が適切かも検討する
例えば、OSの保守期限が切れているのに更新していない、適用すべきセキュリティパッチが未適用、という状況では、
「変更がない＝良い」とは言えません。
変更の有無だけでなく、保守・脆弱性対応が適切かという観点も合わせて考慮する必要があります。
まとめ：過年度依拠のカギは「ITGC」と「変更なしの裏付け」
自動化された情報処理統制は一貫性があるため、条件が整えば過年度の監査証拠を活用しやすい領域です。
しかし、その前提はあくまで、
- 関連するITGCが有効であること
- 統制に影響するプログラムや設定が変更されていないことを、客観的に確認できること
- 期中〜期末の残余期間も踏まえ、必要に応じて追加証拠を取ること
です。
この整理ができていると、ロールフォワードの設計がブレず、テスト過多や手戻りを避けながら、監査で通る合理的な評価が可能になります。