2026.11.05 IPO

IT全般統制（ITGC）とは：4領域の統制項目・評価手続と不備の扱いを実施基準で解説

IT全般統制（ITGC）は、会計システムや販売管理システムの自動処理を「毎回同じように正しく動く」状態に保つための統制で、J-SOXの評価では業務処理統制より先に確かめられます。この記事では、経済産業省が2024年12月に公表したシステム管理基準追補版と実施基準をもとに、開発・保守、運用・管理、アクセス管理、外部委託の4領域で求められる統制項目を具体的に整理する構成です。評価のサンプル件数、不備が「開示すべき重要な不備」になる境目、IPO準備での整え方、システムを発注するときに仕様へ書く要件まで扱います。

まとめ：IT全般統制の要点と、IPO準備企業が最初に固める4つの統制

IT全般統制は、プログラムとデータの信頼性を守る仕組みです。評価の対象は財務報告に関わるシステムとそのIT基盤に絞られ、社内のIT全体ではありません。

実務で最初に押さえるのは次の4つです。本番環境へのプログラム移送を承認済みの変更だけに限ること、退職者や異動者のIDを直ちに止めること、特権IDの利用者と期間を限定してログを点検すること、クラウドや開発会社への委託分を保証報告書や質問書で確かめること。この4つが崩れると、業務処理統制が正しく設計されていても有効と認められません。

IPO準備企業は、上場後3年間は内部統制報告書の監査証明が免除される場合があっても、経営者評価と報告書の提出は残ります。直前期までに規程と運用記録をそろえ、新しいシステムを発注する段階で統制要件を仕様に入れておくと、後からの作り直しを避けられます。

IT全般統制（ITGC）の定義と、IT全社的統制・業務処理統制との関係

ITGCの位置づけは、内部統制の6つの基本的要素のうち「ITへの対応」の中にあります。内部統制全体の枠組みは内部統制の4つの目的と6つの基本的要素で整理しているので、ここではITGCに絞って説明します。

実施基準によるITGCの定義と「業務処理統制が有効に機能する環境」の意味

実施基準はITGCを「業務処理統制が有効に機能する環境を保証するための統制活動」と定め、通常は複数の業務処理統制に関係する方針と手続を指すとしています。経済産業省のシステム管理基準追補版（令和6年12月25日）は、この範囲を「財務報告に係る情報とその情報を処理するプログラムとデータに係る信頼性」に絞り込むと明記しています。

具体的には、新規プログラムと保守後のプログラムがテストと承認を経て本番に移ること、旧システムからの移行データも同じ過程を通ること、運用で未承認の処理が防がれること、アクセス権が承認済みの者だけに設定されることを求めます。販売管理システムの与信チェックが正しく組まれていても、誰でも本番のプログラムを書き換えられる状態なら、その与信チェックは信頼できません。ITGCが守っているのはこの前提です。

IT全社的統制・ITGC・ITACの3層構造と評価を進める順番

IT統制は3層で考えると整理しやすくなります。最上位のIT全社的統制はIT戦略、規程、データ区分といったグループ共通の方針で、その下にITGC、さらにその上で動く個々の自動処理がIT業務処理統制（ITAC）です。ITACの具体例と評価方法はITAC（IT業務処理統制）とITGC・ITDMの違いで詳しく扱っています。

評価は上の層から進めます。追補版は、IT全社的統制が有効で複数拠点が同じ方針で運用されていれば、一部拠点の評価で範囲を絞り込める可能性があるという説明です。逆に全社的統制に不備があれば、ITGCとITACを評価する店舗や拠点の数を増やすことになります。規程を先に整える理由はここにあります。

IT全般統制の4領域と、追補版が挙げる統制項目の具体的な中身

追補版は4領域ごとに評価対象となる統制項目を例示しています。競合の解説では領域名で止まりがちですが、監査で実際に確かめられるのは次の各項目です。

開発・保守の統制：テストと承認を経た本番移行が中核となる手続と証跡

開発・保守の項目は、開発・保守に関する手続の策定、ソフトウェアの開発・調達、IT基盤の構築、検証（テスト）の4つです。追補版は、開発業務ではユーザー部門が参画したテストが実施されているか、保守業務では変更管理が適切に実施されているかを評価するよう求めています。

監査で見られる証跡は、変更依頼票、テスト結果とユーザー部門の承認記録、本番移送の実施記録の3つがつながっているかです。開発者が自分の判断で本番に反映できる運用は、記録が残っていても不備と判断されやすい形です。

運用・管理の統制：ジョブ実行・バックアップ・障害対応の記録と確認事項

運用・管理の項目は、運用管理に関する手続の策定、構成管理と変更管理（ソフトウェアとIT基盤の保守）、データ管理です。追補版の表現では「適切なデータを適切なプログラムで処理し、信頼できる処理結果を得るための統制」が対象になります。

月次の締め処理や請求データの夜間バッチが異常終了したとき、誰がどう再実行し、結果を誰が確認したかが記録に残っているかが問われます。障害対応でデータベースを直接修正した場合、その承認と修正内容の記録は特に厳しく見られます。追補版のIT基盤質問書が「障害によるDB直接修正の有無」を独立した項目にしているのはこのためです。

アクセス管理の統制：ID登録削除・特権ID・認証ログの点検と記録保管

安全性の確保は、アクセス管理等のセキュリティ対策、サイバーセキュリティフレームワークの構築、情報セキュリティインシデントの管理で構成されます。追補版の第Ⅳ章は、職務の変更や離職があれば直ちにアクセス権を解除すること、長期間使われていないIDを点検して削除し記録を保管すること、特権IDは担当者と利用期間を限定することを個別の項目として挙げています。

認証の成功と失敗についても、記録を残して保管することが必要です。人事システムの入退社情報とIDの発行・停止を連動させる考え方はIGA（IDライフサイクル管理）の仕組みで解説しています。手作業で棚卸しする場合も、四半期ごとなど頻度を決めて記録を残すことが評価の前提になります。

外部委託の統制：委託先を評価する質問書・往査・保証報告書の3方式の使い分け

外部委託の項目は、委託先との契約、サービスレベルの定義と管理、契約に基づく委託先の管理です。追補版は委託先の内部統制を評価する方法として、質問書や確認書を送る方式、直接往査する方式、委託先の内部統制に関する保証報告書を入手して確認する方式の3つを示しています。

保証報告書の国内基準は日本公認会計士協会の保証業務実務指針3402（最終改正2023年3月16日）で、基準日時点のデザインを見る「タイプ1」と、特定期間の運用状況まで見る「タイプ2」があります。期間を通じた運用状況の有効性まで確かめられるのはタイプ2だけです。セキュリティ全般を対象とするSOC2との違いはSOC2の5基準とType1・Type2の違いを参照してください。

IT全般統制の評価手続：整備状況と運用状況の確かめ方とサンプル件数

評価は「どのシステムを対象にするか」を決め、次に整備状況と運用状況を確かめる順で進みます。

評価範囲の決め方：事業拠点ではなくアプリとIT基盤で線を引く

ITの評価範囲は、内部統制の評価範囲に含まれる業務プロセスと、それを支えるアプリケーションとIT基盤から決まります。追補版は、IT基盤が別の子会社のデータセンターやクラウドサービスで運用されている場合、その子会社の売上高に関係なく評価範囲に含めると例示しています。

売上規模で拠点を選ぶ発想のままだと、共通基盤を運用する小さな情報システム子会社が漏れます。追補版は、範囲について外部監査人と事業年度の早い時期に協議するよう勧めています。期末に不備が見つかると是正の時間が残らないためです。

自動化統制の運用テストを1件で済ませる条件と前年度結果の継続利用

手作業の統制は頻度に応じたサンプル件数で運用状況を確かめます。追補版の付録1が示す例は次のとおりです。

統制の実施頻度	サンプル件数	許容逸脱件数
1日につき多数・日次	25件	0件
週次	5件	0件
月次・四半期次	2件	0件
年次	1件	0件

自動化された統制は扱いが変わります。関連するITGCが有効と判断できれば、業務処理統制ごとに必要な検証は1件です。さらに、前年度に不備が無い、評価時点から変更が無い、障害やエラーが発生していない、の3条件を満たすと記録すれば、前年度の評価結果を継続して使えます。ITGCが有効であることが評価工数を減らす前提になっている点が、この規定の要点です。なお2023年4月の意見書は、一定の頻度で評価する運用について特定の年数を機械的に適用すべきでないと明確にしました。改訂全体はJ-SOX改訂ポイントの実務解説で整理しています。

IT全般統制の不備が「開示すべき重要な不備」になる場合とならない場合

ITGCの不備は、それだけで直ちに開示すべき重要な不備になるわけではありません。追補版は判断の分かれ目を例で示しています。

補完で救える不備：変更管理の文書不足と受入テストと同等の機能テスト

システム変更の文書化が十分でなくても、プログラム受入テストと同等の機能テストを実施して業務処理統制が有効に機能していると確認できれば、不備とみなさなくてよい場合があるとされています。ITGCの不備は財務報告の虚偽記載に直接つながるとは限らないためです。

ただし、この救済は年度末に一度だけ通用する手当てだと考えてください。機能テストで補うには変更のたびに検証の手間がかかり、翌年度も同じ状態なら外部監査人の見方は厳しくなります。文書化の手順を是正する計画と組み合わせて使うのが現実的です。

救えない不備：DB直接修正と共有特権IDで業務処理統制が崩れる型

重要な不備につながる典型は、業務処理統制が組み込まれていても、ファイルやデータベースへのアクセス管理が不十分でデータを改ざんできる状態です。追補版はこの場合、容易に改ざんされない対策を追加してITGCを機能させる必要があるとしています。

現場でよく見るのは、保守ベンダーと社内担当が1つの管理者IDを共有し、障害対応のたびに本番データを直接書き換えている形です。誰が何を変えたか特定できないため、承認ワークフローや入力チェックがあっても、その結果を信頼できません。共有IDの廃止と作業ログの取得は、他の統制より優先して直してください。

IPO準備でIT全般統制を整える順番と、上場後3年の監査免除の扱い

IPO準備では、上場後の最初の経営者評価に間に合わせるため、ITGCの運用記録を上場前から積み上げておく必要があります。全体の工程はIPO・上場準備の進め方（N-3期からの全体像）にまとめています。

規程・IT基盤質問書・RCMの3文書を整える順番と担当の分け方

最初に作るのはIT関連規程（システム管理規程、アクセス管理規程、外部委託管理規程）です。次に、追補版の付録2-1にある「IT基盤質問書」の形式で、システムごとの開発形態、本番移送用IDの概数、DB修正権限の概数、利用クラウドサービス名、外部委託先を一覧にします。最後に、リスクと統制を対応させたリスクコントロールマトリクス（RCM）を作ります。

規程は情報システム部門、質問書はシステムごとの担当者、RCMは内部監査や経理と分担すると進めやすくなります。質問書を埋めた時点で、移送権限を持つ人数やDB修正権限の多さといった是正対象が見えてきます。

新規上場後3年間の監査証明免除の対象と、免除後も残る経営者評価

金融商品取引法第193条の2第2項第4号により、規模が内閣府令の基準に達しない上場会社等は、上場から3年を経過する日までに提出する内部統制報告書について公認会計士等の監査証明を受けなくてよいとされています。大規模な会社はこの免除の対象外です。

免除されるのは監査証明であって、経営者による評価と内部統制報告書の提出は残ります。上場後に重要な不備を開示すれば株価と信用に響くため、監査が無い期間でもITGCを緩める理由にはなりません。制度全体の要件はJ-SOX（内部統制報告制度）の対象企業と3点セットで確認できます。

システム開発・改修の発注時に仕様書へ明記するIT全般統制の要件

ITGCの不備の多くは、システムを作った後に統制を後付けしようとして生まれます。発注の段階で要件に入れておけば、運用で補う手間はかなり減ります。

発注仕様に書く5項目：環境分離・移送権限・変更履歴・ID棚卸し・ログ

財務報告に関わる業務システムを開発会社へ発注するときは、次の5項目を仕様書に明記しておくと、ITGCの評価で求められる証跡が最初から残ります。

開発・検証・本番の環境分離と、本番移送を実行できるIDの限定
変更依頼からテスト・承認・移送までの履歴をチケットで追える運用
人事データと連動したIDの発行・停止と、四半期ごとの棚卸し画面
特権IDの貸出申請と、操作ログの取得・改ざん防止
保守委託先の作業範囲と、障害時のDB修正手順・承認者の取り決め

承認操作の証跡として残すべきログ項目はワークフローシステムの操作ログ取得と監査証跡で具体的に整理しています。一創では、IPO準備企業向けに統制要件を織り込んだ業務システムの開発と改修をIPO準備・内部統制システム支援として受託しています。

作り込みが過剰になる場面：無改変パッケージとSaaSで任せる判断

すべてを自社開発で作り込む必要はありません。追補版は、パッケージソフトウェアを機能変更せずに使う場合はリスクを限定して評価できるとしています。会計や経費精算を標準機能のSaaSで済ませ、委託先からタイプ2の保証報告書を毎年受け取れるなら、開発・保守領域の統制を自前で持つ範囲は大きく減ります。

逆に、パッケージへ独自機能を追加した場合はこのリスク限定が使えません。売上計上や原価計算のロジックを大きく作り込むなら、上の5項目を備えた開発体制を前提にしてください。年間の変更が数件しかない小規模なシステムに、大企業向けの変更管理ツールを入れるのは過剰です。チケットと承認記録が残る運用で足ります。

よくある質問

IT全般統制について、IPO準備や監査対応の担当者から寄せられやすい質問をまとめました。

IT全般統制とIT業務処理統制はどちらを先に整備すべきですか？

先に整えるのはIT全般統制です。業務処理統制（入力チェックや自動計算など）は、プログラムが勝手に変更されず、データが改ざんされないという前提があって初めて信頼できます。ITGCが有効と判断されれば、自動化された業務処理統制は1件の検証で足り、条件を満たせば前年度の評価結果も継続利用が可能です。順番を逆にすると、業務処理統制の評価をやり直す手間が増えます。

クラウドサービスを使っていればIT全般統制は不要ですか？

不要にはなりません。クラウド上のIT基盤も評価範囲に入り、追補版は外部委託の管理として契約、サービスレベル、委託先の統制の確認を求めています。実務では委託先の保証報告書（保証業務実務指針3402のタイプ2や米国のSOC1）を入手し、対象期間と除外事項を確かめる手順です。加えて、利用者側で行うべき統制（ID管理や権限設定）は自社に残ります。

IT全般統制の4領域で監査に最も指摘されやすいのはどこですか？

指摘が集中しやすいのはアクセス管理と変更管理です。退職者IDの停止漏れ、共有の管理者ID、開発者による本番環境への直接反映、障害対応時のDB直接修正の記録不足が典型です。いずれも記録さえ残せば防げる不備が多いため、ID棚卸しと移送記録の運用から着手すると効果が出やすくなります。

中小規模のIPO準備企業ではIT全般統制の文書をどこまで作ればよいですか？

最低限、IT関連規程、システムごとのIT基盤の概要（追補版のIT基盤質問書の項目が目安）、リスクコントロールマトリクスの3つが必要です。対象システムが会計・販売・購買の数本で、パッケージを無改変で使っているなら、開発・保守領域の記述は短くて構いません。範囲と粒度は早い時期に監査法人とすり合わせてください。

IT全般統制のローテーション評価は何年ごとに行えばよいですか？

決まった年数はありません。2023年4月の意見書は、ITを利用した統制を一定の頻度で評価する運用について、特定の年数を機械的に適用すべきでないと明確にしました。IT環境の変化を踏まえて経営者が判断し、必要に応じて監査人と協議します。システムの入れ替えや大きな改修があった年は、ローテーションの対象外でも評価に含めるのが妥当です。