IT全般統制（ITGC）とは｜業務処理統制との違い

承認ルートを正しく組みました。金額で承認者が切り替わり、不在時は代理に回り、履歴も残ります。

ここで1つ質問です。その承認ルートの設定を、誰が変更できますか。 そして、変更したことは記録に残りますか。

この2つに答えられないとき、承認ルートがどれだけ正しくても統制としては成立していません。基準が、それをはっきり書いています。

全般統制が有効に機能しない場合には、適切な内部統制（業務処理統制）を組み込んだとしても、その有効性が保証されなくなる可能性がある。

IT統制は2層です。上に業務処理統制があり、それを支える土台として全般統制がある。土台が崩れていれば、上に何を載せても保証されません。

本記事では、両者の定義と具体例を原文で確認し、承認ワークフローのどこがどちらに当たるのかを整理します。

この記事の要点

基準は「ＩＴに対する統制活動は、全般統制と業務処理統制の二つからなり…両者が一体となって機能することが重要」としている
業務処理統制は、承認された業務が全て正確に処理・記録されることを確保するために業務プロセスに組み込まれた統制
全般統制（ITGC）は、業務処理統制が有効に機能する環境を保証するための統制活動。複数の業務処理統制に関係する方針と手続
全般統制が機能しないと、業務処理統制の有効性は保証されない。承認ルートが正しくても、誰でも設定を変えられるなら成立しない
全般統制はＩＴ基盤を単位として構築する。基盤が分かれていれば、基盤ごとに必要
外部委託に関する契約の管理も全般統制に含まれる。SaaSを使う側の責任は消えない

IT統制は2つに分かれる

基準の原文です。

ＩＴに対する統制活動は、全般統制と業務処理統制の二つからなり、完全かつ正確な情報の処理を確保するためには、両者が一体となって機能することが重要となる。

「ＩＴへの対応」は内部統制の6つの基本的要素の1つで、その中の統制活動がこの2つに分かれます。枠組み全体での位置づけは内部統制とは｜4つの目的と6つの基本的要素で整理しています。

ＩＴに係る業務処理統制

ＩＴに係る業務処理統制とは、業務を管理するシステムにおいて、承認された業務が全て正確に処理、記録されることを確保するために業務プロセスに組み込まれたＩＴに係る内部統制である。

基準が挙げる具体例は次のとおりです。

入力情報の完全性、正確性、正当性等を確保する統制
例外処理（エラー）の修正と再処理
マスタ・データの維持管理
システムの利用に関する認証、操作範囲の限定などアクセスの管理

基準は、これらが「手作業により実施することも可能であるが、システムに組み込むことにより、より効率的かつ正確な処理が可能となる」としています。ITでなければならない統制ではなく、ITに載せると効率が上がる統制という位置づけです。

ＩＴに係る全般統制（ITGC）

ＩＴに係る全般統制とは、業務処理統制が有効に機能する環境を保証するための統制活動を意味しており、通常、複数の業務処理統制に関係する方針と手続をいう。

具体例は4つ挙げられています。

システムの開発、保守に係る管理
システムの運用・管理
内外からのアクセス管理などシステムの安全性の確保
外部委託に関する契約の管理

複数の業務処理統制に関係するという点が、両者を分ける基準です。個別の業務に組み込まれているのが業務処理統制、その環境全体を保証するのが全般統制です。

なぜ土台のほうが効くのか

基準は、ITを使った統制の性質を次のように説明しています。

ＩＴを利用した情報システムにおいては、一旦適切な内部統制（業務処理統制）を組み込めば、意図的に手を加えない限り継続して機能する性質を有している

ここだけ読むと、ITに載せれば安心だという話に見えます。続きが重要です。

例えば、その後のシステムの変更の段階で必要な内部統制が組み込まれなかったり、プログラムに不正な改ざんや不正なアクセスが行われるなど、全般統制が有効に機能しない場合には、適切な内部統制（業務処理統制）を組み込んだとしても、その有効性が保証されなくなる可能性がある。

ITの統制は、組み込んだ瞬間がいちばん強く、そこから変更のたびに弱くなり得るということです。手作業の統制は人が毎回判断するため劣化が見えますが、システムの統制は設定が書き換わった瞬間に静かに無効化されます。

だから基準は、対応として次の2つを挙げています。

① システムの開発又は変更に際して、当該システムの開発又は変更が既存のシステムと整合性を保っていることを十分に検討するとともに、開発・変更の過程等の記録を適切に保存する ② プログラムの不正な使用、改ざん等を防止するために、システムへのアクセス管理に関して適切な対策を講じる

変更の記録とアクセス管理。この2つが全般統制の中核です。

承認ワークフローに当てはめる

自社のワークフローを、2層に分けて並べてみます。

層	対象	具体例
業務処理統制	1つの申請が正しく処理されるか	金額による承認ルートの分岐／入力必須項目のチェック／承認者マスタの中身／二重申請の検知
全般統制	その仕組み自体が守られているか	承認ルートの設定を誰が変更できるか／変更の履歴が残るか／管理者アカウントの棚卸／退職者のID削除／提供事業者との契約管理

導入検討で比較されるのは、ほぼ上の行だけです。機能一覧に載るのも上の行です。しかし評価で問われるのは下の行で、ここは製品の機能というより運用設計の問題になります。

とくに次の3点は、製品を決めたあとに必ず詰めてください。

管理者権限を持つのは誰か。 全員が管理者という状態は、承認ルートを誰でも書き換えられる状態と同じです
設定変更の履歴が残るか。 申請の承認履歴が残ることと、設定変更の履歴が残ることは別の機能です
退職・異動でアカウントがどう扱われるか。 残ったままのIDは、アクセス管理の穴になります

承認者マスタそのものの設計は承認者マスタの設計｜組織改編で壊れない承認ルートで、自作した仕組みが変更に弱くなる理由は属人化とは｜解消すべきものと放置してよいもので扱っています。

ＩＴ基盤ごとに必要になる

全般統制の単位についても、基準は具体的に書いています。

ＩＴに係る全般統制は、通常、業務を管理するシステムを支援するＩＴ基盤（ハードウェア、ソフトウェア、ネットワーク等）を単位として構築することになる。

基準の例では、購買・販売・流通の3つの業務管理システムが1つのホスト・コンピュータで集中管理されている場合、そのIT基盤に対する有効な全般統制を構築すれば3つの業務の情報の信頼性を高められるとされています。一方、3つが異なるIT基盤で稼働していれば、それぞれのIT基盤ごとに全般統制を構築する必要があるとされています。

これは現在のSaaS利用にそのまま当てはまります。ワークフローはA社、経費精算はB社、購買はC社という構成なら、基盤は3つです。管理者権限の棚卸もアカウント削除も、3つ別々に回ることになります。

ツールを増やすときに見落とされるのがこのコストです。機能単価だけでなく、統制を1基盤ぶん増やす負担も比較対象に入ります。

外部委託の管理は、委託すれば終わりではない

全般統制の具体例の4つ目が「外部委託に関する契約の管理」です。

クラウドサービスを使う場合、サーバーの運用管理やバックアップは提供事業者が担います。しかし利用する側の責任が消えるわけではありません。基準が全般統制の一項目として契約の管理を挙げているのは、委託先が適切に統制しているかを確認する責任が委託者側に残るためです。

実務で確認する項目は、おおむね次のものです。

サービス提供事業者の第三者認証や保証報告書の有無
障害時・データ消失時の責任範囲
データの保存場所と保存期間
契約終了時のデータ返還と削除

とくに保存期間は、自社の文書保存ルールと噛み合っているかを見る必要があります。保存年数の考え方は証憑とは｜証憑書類の種類と保存期間で整理しています。

よくある質問（FAQ）

IT全般統制と業務処理統制の違いは何ですか？

業務処理統制は、1つの業務が正しく処理・記録されるように業務プロセスに組み込まれた統制です。全般統制は、その業務処理統制が有効に機能する環境を保証するための統制で、複数の業務処理統制に関係する方針と手続を指します。

ITGCとは何の略ですか？

IT General Controls の略で、日本語では「ＩＴに係る全般統制」と呼ばれます。基準の表記は「ＩＴに係る全般統制」です。

IT全般統制には何が含まれますか？

基準は、システムの開発・保守に係る管理、システムの運用・管理、内外からのアクセス管理などシステムの安全性の確保、外部委託に関する契約の管理の4つを具体例として挙げています。

承認ルートを正しく設定すれば、IT統制は足りますか？

足りません。承認ルートの設定は業務処理統制に当たりますが、その設定を誰が変更できるか、変更の記録が残るかは全般統制の領域です。基準は、全般統制が有効に機能しない場合には業務処理統制の有効性が保証されなくなる可能性があるとしています。

クラウドサービスを使えば全般統制は提供事業者の責任になりますか？

なりません。基準は「外部委託に関する契約の管理」を全般統制の具体例に挙げており、委託先が適切に統制しているかを確認する責任は委託者側に残ります。アカウントの管理や権限の付与も利用者側の責任です。

SaaSを複数使っている場合はどうなりますか？

基準は、全般統制をIT基盤を単位として構築するとしており、基盤が異なればそれぞれに全般統制が必要だとしています。サービスが3つあれば、管理者権限の棚卸もアカウント削除も3つ別に回ることになります。

中小企業でもIT全般統制は必要ですか？

J-SOXの評価対象になるのは上場会社ですが、全般統制が無ければ業務処理統制の有効性が保証されないという構造は規模を問いません。管理者を絞る、退職者のIDを消す、設定変更の履歴を残すといった最低限の対応は、規模に関わらず効果があります。

設定変更の履歴は、承認履歴とは別ですか？

別です。承認履歴は「誰がどの申請を承認したか」の記録で、業務処理統制の結果にあたります。設定変更の履歴は「誰が承認ルートや権限をいつ変更したか」の記録で、全般統制にあたります。製品によってはどちらか一方しか残らないため、導入前に確認が必要です。

1Approvalでの実現方法

1Approvalは、2層の両方に関わります。

業務処理統制の側では、金額や部門による承認ルートの分岐、入力必須項目の指定、承認者マスタの管理が設定画面で行えます。申請1件ごとに、誰がいつ承認したかが記録として残ります。

全般統制の側では、管理者権限を持つユーザーを限定でき、承認ルートや権限の設定を変更した履歴が残ります。承認履歴と設定変更履歴が別に残るため、「ルートが正しかったか」と「ルートが途中で書き換えられていないか」を分けて確認できます。

ただし、全般統制のうち運用側に残る部分があります。管理者を誰にするか、退職者のIDをいつ削除するか、棚卸をどの頻度で行うかは、製品の設定ではなく社内のルールです。また外部委託に関する契約の管理は、利用する側が確認する領域として残ります。

この境界を曖昧にしたまま「内部統制に対応済み」と整理すると、評価の段で全般統制側が空くことになります。

まとめ

IT統制は2層です。業務処理統制は、承認された業務が全て正確に処理・記録されることを確保するために業務プロセスに組み込まれたもの。全般統制（ITGC）は、その業務処理統制が有効に機能する環境を保証するものです。

重要なのは両者の関係です。基準は、全般統制が有効に機能しない場合には、適切な業務処理統制を組み込んだとしてもその有効性が保証されなくなる可能性があると明記しています。承認ルートが正しくても、誰でも設定を書き換えられるなら統制は成立しません。

全般統制の中核は、基準が対応として挙げた2つ、すなわち変更の記録とアクセス管理です。そして全般統制はIT基盤を単位として構築するため、SaaSを3つ使えば3基盤ぶんの負担になります。

最後に、製品選定で抜けやすい点を挙げておきます。機能一覧に載るのは業務処理統制の側だけです。 承認ルートを比較する前に、管理者権限を持つのは誰か、設定変更の履歴は残るか、退職者のIDはどう消えるかを確認してください。

主な参照先

※本記事は2026年11月時点で確認した公開情報をもとに整理したものです。基準・実施基準の引用は上記の意見書本文によります。本記事は一般的な情報提供であり、個別の案件に対する助言ではありません。自社のIT統制の整備・評価については、監査人および専門家にご確認ください。

※記載されている会社名・製品名は各社の商標または登録商標です。