IT全般統制（ITGC）とは、会計システムや基幹システムといった業務システムが正しく動くための「土台」を整える内部統制の仕組みです。アクセス管理や変更管理、システム運用、外部委託の管理などをまとめて指し、財務報告の信頼性を支えます。

→ダウンロード：IT活用のリスク管理を強化できる内部統制対策ガイドブック

上場企業や上場準備企業では、J-SOX（内部統制報告制度）の評価対象として避けて通れません。一方で「専門用語が多く、何から手をつければよいか分からない」「監査法人の指摘に言われるまま対応している」という声も多い領域です。この記事では、4つの領域・評価の進め方・チェックリスト・監査で指摘されやすい点までを、実務の順番に沿って整理します。

IT全般統制（ITGC）とは

IT全般統制とは、企業が使うITシステム全体が安全かつ適切に機能する状態を保つための管理の仕組みです。英語のIT General Controlsを略してITGCとも呼びます。個々の業務システムが正しく動く前提として、そのシステムが動くサーバーやネットワーク、開発・変更の手順、アクセス権限などが適切に管理されている必要があります。この土台部分を担うのがIT全般統制です。

目的は、システム障害や不正アクセス、設定ミス、委託先管理の不備といったリスクを抑え、最終的に財務報告などの企業情報の正しさを守ることにあります。セキュリティ対策はその一部であって、すべてではありません。ITの力で日々の業務や決算がルールどおりに回り続ける状態をつくることが、IT全般統制の狙いです。

内部統制のなかでのIT全般統制の位置づけ

IT全般統制は、内部統制の一部であるIT統制（ITに係る統制）の土台にあたります。IT統制は大きくIT全般統制とIT業務処理統制（ITAC）の2つに分かれ、IT全般統制が崩れていると、その上で動く業務処理統制も信頼できなくなります。たとえば売上を自動計算する仕組みが整っていても、誰でもプログラムを書き換えられる状態であれば、計算結果そのものを信用できません。

IT業務処理統制（ITAC）との違い

IT全般統制とIT業務処理統制の違いは、統制が効く範囲にあります。IT全般統制はシステム全体の土台（アクセスや運用など）を対象にし、IT業務処理統制は個々の業務アプリケーションの中で処理が正しく行われるか（入力チェックや自動計算など）を対象にします。両者は次のように整理できます。

▼ IT全般統制とIT業務処理統制の違い

観点	IT全般統制（ITGC）	IT業務処理統制（ITAC）
対象	システム全体の土台（基盤・環境）	個別の業務アプリケーションの処理
具体例	アクセス権限の管理、プログラム変更の承認、バックアップ	入力値のチェック、金額や消費税の自動計算、二重入力の防止
評価の単位	システム基盤・管理プロセス単位	業務プロセス・取引単位
関係	ITACが正しく働く前提（土台）	ITGCの上で個別処理の正しさを担保

IT全般統制を構成する4つの領域

IT全般統制は、大きく4つの領域で構成されます。システムの開発・保守（変更管理）、システムの運用・管理、アクセス管理を含むシステムの安全性確保、外部委託に関する契約の管理の4つです。それぞれで「よくある統制活動」を押さえると、自社で何を整えるべきかが見えてきます。

▼ IT全般統制の4領域と主な統制活動

領域	目的	よくある統制活動
①開発・保守の管理（変更管理）	システムの変更を正しく反映する	変更の申請・承認、テストの実施と記録、開発環境と本番環境の分離
②運用・管理	システムを安定して動かし続ける	定期的なバックアップ、ジョブ（バッチ処理）の監視、障害発生時の対応手順、台帳管理
③アクセス管理（安全性の確保）	許可された人だけが使える状態にする	IDの発行・変更・削除、権限の最小化、特権IDの制限とログ監視、定期的な権限の棚卸し
④外部委託の契約管理	委託したIT業務の品質と統制を保つ	委託先の選定基準、SLAでの責任範囲の明確化、委託先の統制状況の定期評価

4つの領域は、役割で2つに大別すると理解しやすくなります。開発・保守（変更管理）と運用・管理は、「変更とその後の運用で事故を起こさない」ための領域です。無断でプログラムを書き換える、テストせずに本番へ反映する、バックアップを取っていないといった状態は、そのままデータの欠落や誤りに直結します。だからこそ、変更には申請と承認、運用には監視と復旧手順を組み込みます。

アクセス管理と外部委託の管理は、「使える人と、任せる先を絞る」ための領域です。強い権限を持つIDが野放しになっていたり、委託先がどんなセキュリティ体制かを把握していなかったりすると、不正やミスの入り口になります。権限は職務に応じて最小限にし、委託先は契約と定期的な確認で統制下に置くのが基本です。なお、4つ目の領域は解説によって「外部委託」とする場合と「ITインフラ（物理・環境）の管理」を含めて整理する場合があります。自社の環境に合わせて、サーバーやネットワークの管理まで対象に含めるかを判断してください。

なぜIT全般統制が必要なのか（J-SOXと財務報告の信頼性）

IT全般統制が必要な最大の理由は、財務報告の信頼性を担保する土台になるからです。会計データの多くがITシステムで処理される現在、システムの土台が崩れていれば、出力される財務情報そのものが信用できなくなります。

上場企業はJ-SOX（内部統制報告制度）により、財務報告に係る内部統制を整備・評価する義務があります。IT全般統制はその評価対象に含まれ、ここに重要な不備が見つかると、財務報告全体の信頼性に疑義が生じ、監査意見にも影響しかねません。経済産業省が公表する「システム管理基準 追補版（財務報告に係るIT統制ガイダンス）」でも、財務報告に関わるITの統制が整理されています。

統制の不備は、影響の大きさで段階的にとらえられます。軽微な「不備」にとどまるか、財務報告の信頼性に重要な影響を与える「開示すべき重要な不備」に当たるかで、対応の優先度が変わります。IT全般統制の不備は、その上で動く個々の業務処理の信頼性まで揺るがすため、単独の小さな問題に見えても影響範囲が広がりやすい点に注意が必要です。発見した不備は放置せず、是正の計画と期限をセットで管理します。

IT全般統制の対象システムと評価範囲の決め方

IT全般統制の対象は、財務報告に重要な影響を与えるシステムから優先して絞り込むのが基本です。すべてのシステムを同じ深さで評価するのは現実的でないため、会計・販売・購買など、財務数値の生成や集計に直結するシステムを中心に範囲を決めます。

範囲を決めるときは、そのシステムが財務報告にどう影響するか、扱う金額や取引の重要性はどの程度か、手作業による補正がどれだけ介在するかといった観点で見ていきます。対象が広がりすぎると運用が回らず、狭すぎると統制の抜けが生じるため、影響度に応じたメリハリが要点です。

具体的には、会計システムや販売管理、購買管理など、仕訳や売上・仕入の金額を生み出すシステムは対象になりやすい代表例です。一方で、社内告知用のポータルのように財務数値を直接生まないシステムは、対象から外れることが多くなります。判断に迷うのは、表計算で作った集計ファイルや、基幹システムと会計システムをつなぐ連携処理です。金額の確定や転記に関わるなら、たとえ補助的なツールでも対象に含めて検討するのが安全です。

IT全般統制の構築・評価のステップ

IT全般統制は、ルールを整える「整備」と、整えたルールが守られているかを確かめる「運用評価」の2段階で進めます。大きな流れは、現状把握、リスクと統制の洗い出し、文書化、整備状況評価、運用状況評価、改善という順番です。

RCMと3点セットで統制を文書化する

統制の文書化では、リスクコントロールマトリックス（RCM）と、いわゆる3点セット（業務記述書・フローチャート・RCM）がよく使われます。RCMは、想定されるリスクと、それを抑える統制を一覧で対応づけた表です。どのリスクに、どの統制が、どう効いているかを1枚で見渡せるため、整備状況評価と運用状況評価の出発点になります。

整備状況評価では、ルールが設計として備わっているかを確認します。続く運用状況評価では、そのルールが実際に守られているかを、記録やサンプルで検証します。たとえばアクセス権限の付与なら、一定期間の付与申請をいくつか抽出し、承認の記録がそろっているかを確かめます。評価で大切なのは、口頭の説明ではなく、申請書や承認ログ、変更履歴といった証跡が残っていることです。証跡がなければ、ルールどおり運用していても「確かめられない」と判断されてしまいます。

IT全般統制のチェックリスト（評価項目の例）

IT全般統制の評価項目は、4領域ごとに「何を確認するか」を一覧化すると抜け漏れを防げます。ここでは、自社の現状確認にそのまま使える評価観点の例を領域別に整理します。実際の項目は対象システムや監査人の方針によって調整してください。

▼ IT全般統制チェックリスト

領域	主なチェック項目（例）
開発・保守（変更管理）	変更は申請・承認のうえで実施されているか／テスト記録は残っているか／開発環境と本番環境は分離されているか／緊急変更にも事後承認の手順があるか
運用・管理	バックアップは定期取得・保管されているか／ジョブ（バッチ）の実行結果は監視されているか／障害対応の手順とエスカレーションが定められているか
アクセス管理	IDの発行・変更・削除に承認があるか／権限は職務に応じて最小化されているか／特権IDの利用は制限・記録されているか／アクセス権限の棚卸しを定期的に実施しているか
外部委託の契約管理	委託先の選定基準があるか／契約で責任範囲（SLA）が明確か／委託先の統制状況を定期的に確認しているか

IT全般統制で監査に指摘されやすいポイントと対策

IT全般統制で指摘が集中しやすいのは、アクセス管理、とくに特権IDと権限の棚卸しです。退職者のIDが残っていた、強い権限を持つIDの利用記録がない、権限の見直しが年1回も行われていない、といった点は監査で繰り返し問われます。指摘されてから慌てないために、典型的な指摘と対策を先に押さえておきましょう。

▼ IT全般統制で指摘されやすい点と対策

指摘されやすい点	背景	対策の方向性
特権IDの利用が記録されていない	強い権限の操作が後から追えない	特権IDの利用を申請制にし、操作ログを取得・定期確認する
退職者・異動者のIDが残っている	削除・変更の手順が運用されていない	IDの発行から削除までを承認フロー化し、定期的に棚卸しする
権限が職務に対して過大	付与時のチェックがなく積み上がる	職務に応じた最小権限に整理し、付与時と棚卸し時に確認する
ルールはあるが守られていない	整備だけで運用評価が形だけ	運用状況をサンプルで検証し、記録を残す

アクセス管理と並んで問われやすいのが、変更管理です。プログラムや設定の変更が、申請と承認を経ずに本番環境へ反映されていないか。テストの記録が残っているか。障害対応などの緊急変更について、事後でも承認する手順が決められているか。これらは「変更が正しく管理されている」と示すための基本で、記録が欠けていると、変更そのものが妥当でも統制としては認められません。

特権IDとアクセス権限の棚卸しを仕組みにする

アクセス管理は、「申請・発行」「権限の見直し」「棚卸し」「ログ監視」の4つを定期サイクルで回すと統制が安定します。とくに棚卸しは、対象を全システムに広げると形だけになりがちです。財務に影響の大きいシステムから優先し、誰がどの権限を持つかを定期的に突き合わせる運用にすると、無理なく続けられます。

統制を形骸化させない運用設計

統制が形骸化する主な原因は、現場の手間に対してルールが重すぎることです。厳格すぎる手順は守られなくなり、かえって統制の空洞化を招きます。承認や記録の一部を仕組み（システム）に肩代わりさせ、人が判断すべきところに集中できるようにすると、運用は続きやすくなります。統制と業務効率は対立させず、両立を前提に設計するのが現実的です。

クラウド・SaaS時代のIT全般統制

クラウドやSaaSを使う場合、IT全般統制の重心は「外部委託の管理」に移ります。自社で持つシステムが減る一方、業務を支える機能をベンダーに委ねるため、委託先が信頼できるかをどう確かめるかが論点になります。自社サーバーを運用していた頃は、アクセス管理も変更管理も自社の手の内にありました。SaaSではその多くがベンダー側に移るため、自社で直接統制できる範囲は狭まり、代わりに「ベンダーの統制をどう確認するか」という間接的な統制の比重が増します。

SaaSの利用統制とSOCレポート・委託先管理

ここでいうSOCレポート（System and Organization Controls）とは、クラウド事業者などの受託会社の内部統制が適切に整備・運用されているかを、独立した第三者の監査人が評価して報告する書類です。米国公認会計士協会（AICPA）が定めた枠組みで、日本でも日本公認会計士協会の保証業務実務指針に沿った同種の報告書（受託業務に係る内部統制の保証報告書）が用いられています。自社で直接確認できないベンダー側の統制を、第三者の評価を通じて確かめられるのが利点です。 出典：日本公認会計士協会「保証業務実務指針3402 受託業務に係る内部統制の保証報告書に関する実務指針」（最終確認日：2026年7月7日）

SaaSを評価するときは、ベンダーがどんな統制を効かせているかを示す資料（SOCレポートなど）を確認できるかが判断材料になります。SOCレポートに含まれない部分は自社側の統制で補う必要があります。契約でサービスレベルや責任範囲を明確にし、ベンダーのセキュリティ体制や認証（ISMSなど）の取得状況を定期的に確認する運用にしておくと、外部委託の統制が成立します。

SOCレポートにはいくつか種類があり、内部統制の評価でよく参照されるのは、財務報告に関連する統制を扱うものと、セキュリティや可用性などを扱うものです。前者は委託先の統制が財務報告にどう関わるかを確かめるのに、後者はセキュリティ面の確認に向きます。どちらが入手できるか、評価対象期間がいつかを確認し、自社の評価範囲と突き合わせて使い分けます。レポートが入手できないサービスでは、その分だけ自社側で代替の確認を行う前提で選定するのが現実的です。

スプレッドシート依存の統制リスク

見落とされがちなのが、表計算ソフトへの依存です。スプレッドシートは手軽な反面、誰がいつ何を変えたかを追いにくく、統制が効きにくいという弱点があります。関数の上書きや行の挿入で集計がずれても気づきにくく、承認も「メールで合意」のように記録が分散しがちです。重要な集計や承認を表計算に頼っている業務は、入力・承認・記録が仕組みとして残るシステムへ移すことで、業務処理統制まで含めて整えやすくなります。

経理業務の内部統制をクラウドで効かせるには

経理領域は、IT全般統制と業務処理統制の両方が問われる現場です。証憑（領収書や請求書）の真正性、申請から承認までの流れ、誰がどこまで操作できるかの権限、そして操作の記録。これらを手作業や表計算ではなく、記録の残るクラウドに載せ替えることが、経理の統制を効かせる近道になります。

本記事の整理として、経費精算や請求書受領、契約管理といった支出まわりのクラウドは、IT全般統制そのもの（IDアクセス基盤や変更管理の仕組み）を置き換えるものではありません。一方で、経理の業務処理統制と、その前提になる証憑・承認・権限・ログを効かせる役割を担えます。手作業や表計算で回している経理業務を統制の観点で見ると、課題とクラウド化の効果は次のように整理できます。

▼ 経理業務の統制観点｜手作業・表計算の課題とクラウド化の効果

統制の観点	手作業・表計算での課題	クラウドで効かせると
証憑の真正性	紙やファイルの差し替え・改ざんに気づきにくい	電子保存とタイムスタンプで真正性を担保
承認	口頭やメールで記録が分散し、誰が承認したか追いにくい	条件に応じた承認フローで承認者と日時が残る
権限（職務分掌）	担当者がすべて操作でき、けん制が効かない	役割に応じた権限設定でアクセスを制限
記録・証跡	変更履歴が残らず、後から検証できない	操作の記録が残り、評価時に証跡を示せる

たとえばTOKIUM経費精算では、条件に応じて承認フローが自動で分岐し、規程に反する疑いのある経費には自動でアラートが点灯します。領収書などの証憑の入力は、AIとオペレーター（プロスタッフ）が代行する仕組みで、担当者の手入力を介さずにデータ化できます。アクセス面ではIPアドレス制限やSAML認証に対応し、電子帳簿保存法のスキャナ保存にも対応してタイムスタンプで証憑の真正性を担保します。承認・権限・記録・証憑の保存を仕組みとして残せるため、経理まわりの統制を運用しやすくなります。また、TOKIUMは電子帳簿保存法のスキャナ保存ソフト法的要件認証（JIIMA認証）を取得し、タイムスタンプを標準で備えます。プライバシーマークとISMS（ISO/IEC 27001）も取得しています。出典：TOKIUM経費精算 機能ページ／公式サイト（最終確認日：2026年7月7日）

さらに、経理の入力や確認といった工程そのものをAIエージェントとBPO（業務代行）に委ねる進め方もあります。手入力や目視確認を担当者が抱え込むと、ミスや属人化が統制上の弱点になりがちですが、これらの定型業務を外部の仕組みに切り出すことで、担当者は内容の判断やチェックに集中できます。委託先が自社の統制（ISMSなどの認証取得）のもとで運用していれば、前述の外部委託の管理の観点とも整合し、統制を保ったまま業務負荷を下げられます。たとえばTOKIUMのAI Agentic BPOは、定型的な処理はAIエージェントが自律的に行い、例外的なケースだけをオペレーターが確認する設計で、経理のノンコア業務を統制下に置いたまま効率化します。 出典：AI Agentic BPO（TOKIUM）（最終確認日：2026年7月7日）

以下の動画で解説しているのでぜひご覧ください。

ベンダー自身がISMSなどの認証を取得していることは、前述の外部委託の管理（委託先評価）の観点でもプラスに働きます。クラウドに任せる範囲が広がるほど、委託先がどんな統制を効かせているかが重要になるためです。

押さえておきたいのは、こうしたクラウドが担えるのは経理まわりの統制であって、IT全般統制の全領域を代替するものではない、という点です。社内システム全体のアクセス基盤や変更管理は、引き続き自社のIT全般統制として整える必要があります。経費精算や請求書受領、契約管理のように、証憑と承認が密に絡む経理業務から統制を仕組み化していくと、無理なく実効性を高められます。

AI Agentic BPOのサービス詳細はこちら
導入のご相談・お問い合わせはこちら

IPO準備におけるIT全般統制の留意点

上場準備では、IT全般統制を早い段階から整備し、運用実績を積んでおくことが重要です。整備したルールは、一定期間にわたって運用された記録がなければ評価の対象になりません。直前に着手すると運用実績が足りず、評価が間に合わない事態を招きます。会計や販売など財務に直結するシステムから優先して整え、運用を回しながら改善していく進め方が現実的です。

まとめ｜IT全般統制は土台づくりと運用の継続がカギ

IT全般統制は、4つの領域（開発・保守、運用、アクセス管理、外部委託）を整え、整備したルールを運用し続けることで、財務報告の信頼性を支えます。まずは財務に影響の大きいシステムから対象を絞り、評価項目を一覧化して現状を確認するところから始めると、無理なく進められます。クラウドやSaaSを使う場面では、委託先の統制をどう確かめるかが新たな論点になります。

経理まわりでは、証憑・承認・権限・記録を仕組みとして残せるクラウドに載せ替えることが、統制を効かせる現実的な一歩です。内部統制やJ-SOXの全体像は、関連記事もあわせて確認してみてください。

IT全般統制に関するよくある質問

IT統制とIT全般統制の違いは何ですか？

IT統制は、ITに関わる内部統制全体を指す広い言葉です。その中にIT全般統制（システムの土台に関する統制）とIT業務処理統制（個別業務の処理に関する統制）が含まれます。IT全般統制は、IT統制のうち土台部分を担う一区分という関係です。

IT全般統制は必要ですか？

上場企業や上場準備企業では必要です。J-SOX（内部統制報告制度）で財務報告に係る内部統制の評価が求められ、IT全般統制はその対象に含まれます。重要な不備があると財務報告の信頼性に影響するため、財務に関わるシステムを使う企業ほど整備が欠かせません。

IT全般統制（ITGC）とは何ですか？

ITGCは、業務システムが安全かつ適切に機能する状態を保つための土台となる統制です。開発・保守（変更管理）、運用・管理、アクセス管理、外部委託の管理の4領域で構成され、最終的に財務報告の信頼性を支えます。

IT全般統制の範囲（対象）はどう決めますか？

財務報告に重要な影響を与えるシステムから優先して決めます。会計・販売・購買など財務数値に直結するシステムを中心に、扱う金額や取引の重要性を踏まえて対象を絞り込みます。広げすぎず、抜けも作らないバランスが要点です。