法制度・統制公開 2026-10-31・更新 2026-10-31

ITGCとITACとは：開発者が守るJ-SOXの統制を、仕訳とテーブルで見る

確認日 2026-10-31（調べ方）・制度は変わることがあります。個別の判断は公式の資料と専門家に確かめてください。

ITGC（IT全般統制）は、システム全体の土台を守る統制です。ITAC（IT業務処理統制）は、個々の業務処理の中で数字を正しく保つ統制です。この2つは、財務報告の信頼性を確保するための J-SOX の枠組みの中にあります。

開発者にとっての要点は、変更・権限・記録の3つを、あとから説明できる形で残すことです。ITGC で問われるのはコードの出来ばえとは別のことで、誰が承認して、誰が本番に入れ、何が変わったかの記録です。

J-SOXで求められているのは「財務報告の信頼性」

J-SOX は通称です。正しくは金融商品取引法による内部統制報告制度で、上場会社を対象に導入されました。経営者が財務報告に係る内部統制を評価して報告し、監査人がその評価を監査します。

基準は、ITの統制目標として準拠性・信頼性・可用性・機密性を例に挙げています。このうち財務報告で特に大事なのが信頼性で、次の3つに分かれます。

• 正当性：取引が組織の意思に沿って承認され、行われていること
• 完全性：記録した取引に漏れや重複がないこと
• 正確性：発生した取引が、科目分類などの主要な項目に正しく記録されていること

SE の言葉に直すと、不正な伝票が入らないこと、連携で欠けたり二重になったりしないこと、値が正しいことです。この3語を覚えておくと、統制の説明がそのまま設計の言葉になります。

ITGCとITACの違い

基準によると、全般統制は業務処理統制が有効に働く環境を保証するものです。通常は複数の業務処理統制に関わります。業務処理統制は、承認された業務がすべて正確に処理・記録されるよう、業務プロセスに組み込まれた統制です。

単位も異なります。全般統制は、ハードウェアやネットワークなどの IT 基盤を単位に整えます。実施基準の例では、販売・購買・物流を管理するシステム部と、会計パッケージを管理する経理部で、評価単位を2つに分けています。業務処理統制は、基本的にシステムごとに評価します。

もう1つ重要な点があります。全般統制が有効でも、それだけで業務処理統制も有効だとは言えません。基準はこの点に留意を求めています。逆に全般統制に問題があると、組み込んだ統制の有効性が保証されなくなるおそれがあるとも説明しています。

変更管理：本番を直すときに残すもの

実施基準は全般統制の対応の例として、変更が既存システムと整合するよう検討し、開発・変更の過程の記録を適切に残すことを挙げています。不正な改ざんを防ぐアクセス管理も同じ箇所で挙げています。

設計の例として、次の4つのテーブルがあると、証跡の抽出がしやすくなります。名前は説明用です。

deployments のうち change_id が空のものを探せば、手順の外で入った変更を見つけられます。外部の CI ログと突き合わせるなら、commit_sha が照合の鍵になります。

職務分掌：開発者と本番権限を分ける理由

実施基準は職務分掌の例として、取引の承認と記録、資産の管理を別の者に担当させることを挙げています。担当者の間で互いに牽制を働かせるためです。

システムに置き換えると、次のように考えられます。

• 変更を作る人と承認する人を分ける
• 開発者に本番の常時権限を持たせず、必要なときだけ申請で渡す
• 本番 DB への直接操作は、理由と実行者とクエリを記録する

ただし、基準が「開発者は本番に触れてはならない」と具体的に書いているわけではありません。これは職務分掌とアクセス管理を実現する方法のひとつです。少人数のチームでは、権限を分けきれないこともあります。その場合は操作ログを第三者が定期的に確認するなど、別の統制で補う考え方が取られます。

取消の作り方は赤伝と赤黒処理の記事で詳しく扱っています。二重連携そのものを防ぐのは ITAC の役割です。source_key に一意制約を置けば完全性の統制になります。連携の設計は仕訳連携の記事も参照してください。

3点セットとRCMを開発者はどう読むか

業務記述書、フローチャート、RCM をまとめて3点セットと呼ぶことがあります。これも実務の呼び名です。実施基準の参考2・参考3に、業務の流れ図、業務記述書、リスクと統制の対応の例があります。ただし基準はこれらを参考例と位置づけ、必ずこの様式で作るよう求めてはいません。

RCM は「この業務にどんなリスクがあり、どの統制で抑えるか」を並べた表です。開発者が読むときは、統制の列にシステムの機能名があるかを見ます。自動チェックが統制として書かれていれば、その機能の変更は監査の対象に直結します。

業務の流れ図は、受注から入金までの全体像を知るのにも役立ちます。読み方の土台は受注から入金までの流れの記事にまとめています。

2023年改訂でITの何が変わったか

企業会計審議会は令和5年4月7日に基準と実施基準を改訂しました。適用は令和6（2024）年4月1日以後に開始する事業年度からです。IT に関係する主な点は次のとおりです。

• ITの委託業務の統制が以前より重要になっていることを明記した
• クラウドやリモートアクセスの活用にあたり、サイバーリスクを踏まえたセキュリティの確保が重要だと記した
• 大量の情報を扱う状況で、情報の信頼性の確保にシステムが有効に働くことの重要性を記した
• IT を利用した統制を一定の頻度で評価する場合、特定の年数を機械的に当てはめないことを明確にした

評価範囲についても、売上高等のおおむね3分の2といった例示を機械的に使わないよう明確にしています。また、評価範囲外の業務で開示すべき重要な不備が見つかれば、その業務を評価範囲に含めるのが適切としています。SE にとっては、これまで範囲外だった業務のシステムが対象に入る可能性があるということです。

委託の点も実務に響きます。基準は、委託業務に関しては委託者が責任を負い、その統制も評価範囲に含まれるとしています。業務の重要な一部を外部の SaaS に任せている場合、「ベンダーの仕事だから」では済みません。受託会社の統制をどう確かめるかを、導入の時点で考えておく必要があります。

評価を毎年やり直さないための条件

IT の統制の評価は原則として毎期です。ただし自動化された統制は、変更やエラーがない限り同じように動き続けます。そこで実施基準は、過年度に有効と評価され、統制が変更されておらず、障害がなく、関連する全般統制も有効な場合に、結果を継続利用できるとしています。

つまり、ITGC が弱いと ITAC の評価も軽くできません。変更管理の記録を整えることは、監査対応の工数を抑えることにもつながります。

基準はまた、自動化された統制を過信しないよう注意を促しています。電子記録は変更の痕跡が残りにくい場合があり、統制の無効化の発見が遅れることがあるためです。監査ログを業務データと別の権限で管理する設計は、この点への備えになります。

電子帳簿の訂正削除履歴とも考え方が重なります。税務の要件は目的が異なりますが、設計の共通点が多いので、コンプライアンスのハブもあわせて読むと整理しやすいはずです。

開発の現場で先に決めておくこと

最後に、編集部が開発チームの準備として勧める項目を挙げます。基準の要求そのものではなく、ここまでの内容を実務に落とした例です。

• 財務に関わるシステムの一覧と、RCM に載っている機能の一覧を持つ
• 緊急変更の手順を平時に決める（事後承認の期限、記録の項目）
• 本番権限の棚卸しの頻度と確認者を決める
• 証跡を SQL やログから取り出す手順を書いておく
• SaaS や委託先の統制を確かめる資料を契約時に確認する

統制の担当者が使う言葉と設計の言葉をつなげられると、監査対応は作業の押し付けではなく、設計の条件のひとつとして扱えるようになります。