IT全般統制（ITGC）とは
個々のシステムが信頼できる状態で運用されているかを確認する内部統制です。変更管理・運用管理・アクセス管理・外部委託管理の4つの領域に分かれ、情報処理統制（ITAC）が正しく機能するための「土台」にあたります。
「IT全般統制がよくわからないので、相談に乗ってほしい」。こうした相談を、経理担当者や経営者から数多く受けてきました。話を聞いていくと、原因は技術的な難しさではないことがほとんどです。
エンジニアに聞けば「正直、IT監査人が何を言っているのか分からない」と言われ、管理部に聞けば「ITのことがよく分からないから、統制の話もよく分からない」と返ってくる。双方が「相手の言葉が分からない」まま、話が噛み合っていないのです。
厄介なのは、間に立って翻訳できるはずの会計士自身も、IT統制を得意としている人が多くないことです。監査の現場でも、「そこはスコープ外です」の一言でIT統制の論点が棚上げにされるケースをよく見ます。会計士はITを避け、エンジニアは会計を避け、管理部はどちらも分からない。三者三様に「自分の専門ではない」と思っている間に、誰も全体を見ないまま時間だけが過ぎていきます。
逆側にも同じ構造があります。システム監査の専門家に相談すると、セキュリティやシステムの堅牢さには詳しくても、財務諸表監査で何が論点になるのか、監査人がどこを気にしているのかという勘所を押さえていないことがあります。IT統制までカバーできる会計士は限られていて、逆にシステム監査の専門家は財務諸表監査の要点を押さえられない。この隙間が埋まらないまま、双方が「自分の範囲ではない」を繰り返しているのが実情です。
このすれ違いを放置すると、何が起きるでしょうか。会社側に判断の軸がないまま、監査法人から言われたことをそのまま受け入れるしかなくなります。その場しのぎの対応が積み重なり、統制の全体像がないままぐちゃぐちゃになっていく。そういうケースを何度も見てきました。
IT統制には3つの種類があり、「IT全般統制」はそのうちの1つです。しかし、その「1つ」が何を指すのか、どこまでの範囲を見ればいいのかが分からないまま、評価を任されてしまう人が少なくありません。だからこそ、会計とITの両方が分かる人間が間に立って翻訳する必要がある、と考えています。この記事も、その翻訳の一つとして書いています。
この記事は、IT全般統制の全体像から、4つの領域（変更管理・運用管理・アクセス管理・外部委託管理）ごとの実務、監査で実際に指摘される不備、J-SOXとの関係、上場準備やM&Aで見落とされがちな論点、そして生成AI時代への対応まで、1本にまとめたものです。個別の論点をさらに深く知りたくなったら、各セクションの末尾から詳細記事に進んでいただければと思います。まずはこの記事で、全体地図を持ち帰ってください。
この記事を読んでわかること
- IT全社的統制・IT全般統制・情報処理統制、3つの違いと関係
- IT全般統制を構成する4つの領域（変更管理・運用管理・アクセス管理・外部委託管理）の実務と、監査で確認されるポイント
- 監査で実際に指摘される不備トップ10と、J-SOX・上場準備・M&A・生成AI対応という発展的な論点
- 今日から何に着手すればよいか
なぜIT全般統制はわかりにくいのか｜会計担当者とエンジニアの「すれ違い」
具体的にどこですれ違うのか、もう少し掘り下げます。
会計担当者の多くは、AWSやGitHub、JIRAといったツールに触れたことがありません。バッチ処理が何を指すのか、アジャイル開発がどういう進め方なのかが分からないまま、評価を進めることになります。「何の基準に従って評価しているのか」自体が整理できていないケースも珍しくありません。監査基準委員会報告書なのか、J-SOXの実施基準なのか。複数の基準があることは知っていても、自分が今どちらを使って何を確認しているのかが分からないまま作業が進むこともあります。
一方のエンジニアは、そもそもIT統制が何を目的にしたものかを知りません。そのため、「なぜソースコードを見ないのか」「セキュリティ的には問題ないのに、何が足りないと言われているのか」という疑問を持ちます。「アジャイルで開発しているのに仕様書を求められる」「AWSの自動バックアップがあるのに、それでは不十分だと言われる」という摩擦は、現場でよく起きます。
これは、エンジニアの認識が間違っているわけではありません。IT統制が「財務報告の信頼性を担保するための仕組み」だという前提が共有されていないだけです。前提がずれたまま話をしても、監査人の質問の意図はいつまでも伝わりません。
▶ 詳しくはこちら：IT全般統制がわかりにくい本当の理由｜会計担当者とエンジニアの「すれ違い」を解説
IT統制3種類の中の位置づけ｜IT全社的統制・IT全般統制・情報処理統制
IT統制の全体像
財務報告に関わるIT統制は、大きく3種類に分かれます。対象範囲は「会社全体」から「システム単位」、そして「処理単位」へと、段階的に狭くなっていきます。
IT全社的統制は、会社全体のIT方針・体制を対象にします。ITガバナンスの体制はあるか、情報セキュリティポリシーは文書化されているか、IT投資の意思決定プロセスはあるか、といった論点です。実務では、全社的な内部統制の評価と同時に検証されることが多く、IT統制特有の調査はそこまで深く行われない傾向があります。
IT全般統制（ITGC）は、個々のシステムを対象にします。「システム自体が信頼できる状態で運用されているか」を確認するもので、このあと説明する4つの領域（変更管理・運用管理・アクセス管理・外部委託管理)に分かれます。この記事のメインテーマです。
情報処理統制（ITAC）は、業務アプリの処理内容を対象にします。「売上データが会計システムに漏れなく、正確に、正当な権限で連携されているか」といった、データそのものの正確性を確認するものです（この領域だけを取り出した解説はIT業務処理統制（ITAC）とはにまとめています）。監基報315のガイダンスでは、情報のインテグリティ（網羅性・正確性・正当性）ごとに、次のような統制の例が示されています。
| 確認するリスク | 統制の例 |
|---|---|
| 網羅性（データが漏れなく処理されているか） | システム間インターフェースで、出力側と入力側のデータ件数を突合し、不一致ならデータ処理を中止する |
| 正確性（データが正しく処理されているか） | 取引データ入力時に、登録済みのマスタファイルと突合し、不一致なら受け付けない |
| 正当性（権限のある処理か） | 処理担当者に業務内容に応じた操作権限をユーザーIDに付与し、認証によって本人確認する |
IT全般統制はIT統制の土台である
IT全般統制は、この中で「土台」にあたります。情報処理統制は「会計システムの中の計算が正しいか」を確認しますが、その会計システム自体が「誰でも改ざんできる」「テストなしにコードが変わる」「退職者もログインできる」状態では、中の計算が正しくても意味がありません。IT全般統制が有効だと確認できて初めて、情報処理統制の評価を効率的に行えます。
逆に、IT全般統制に不備があると、監査人はシステムを信頼できないため、手動でのテスト件数を大幅に増やさざるを得なくなります。システムが信頼できないということは、「システムが正しく動いている」という前提に依拠した自動化テストが使えないということです。結果として、1件ずつ手で拾って確認するしかなくなり、会社にとっても監査対応のコストが跳ね上がります。
この「土台」という位置づけは、日本公認会計士協会の監査基準委員会報告書315（重要な虚偽表示リスクの識別と評価）でも同じ形で説明されています。同報告書は、IT全般統制を「IT環境の継続的かつ適切な運用を支援する企業のITプロセスに係る内部統制」と定義し（第11項(2)）、情報処理統制を「情報のインテグリティ（取引及びその他の情報の網羅性、正確性、正当性）のリスクに直接対応する、企業の情報システムにおけるITアプリケーションの情報処理又は手作業による情報処理に関連した内部統制」と定義しています（第11項(9)）。同報告書の適用指針（Q&A）は、この関係を「経営者が財務報告において依拠する内部統制が自動化されている程度が高いほど、自動化された情報処理統制の継続的な運用を支援するIT全般統制の適用は重要となる」と説明しています。経営者向けの「財務報告に係る内部統制の評価及び監査の基準」と、監査人向けの監基報315という、目的の異なる2つの基準が同じ結論に至っている、という点は、この土台構造が単なる一つの立場からの解釈ではないことを示しています。
内部統制の6要素とIT統制の関係
金融庁・企業会計審議会が定める「財務報告に係る内部統制の評価及び監査の基準」（2023年4月7日改訂）でも、IT全般統制とIT業務処理統制は次のように定義されています。
ＩＴに係る全般統制とは、業務処理統制が有効に機能する環境を保証するための統制活動を意味しており、通常、複数の業務処理統制に関係する方針と手続をいう。
具体例として基準が挙げているのが、まさにこの記事で扱う4つの領域です。「システムの開発、保守に係る管理」「システムの運用・管理」「内外からのアクセス管理などシステムの安全性の確保」「外部委託に関する契約の管理」。この記事で「変更管理・運用管理・アクセス管理・外部委託管理」と呼んでいるのは、この4項目の実務上の呼び方だと考えてください。
一方、この記事で「情報処理統制」と呼んでいるものは、財務報告に係る内部統制の評価及び監査の基準では「ＩＴに係る業務処理統制」と呼ばれています。「業務を管理するシステムにおいて、承認された業務が全て正確に処理、記録されることを確保するために業務プロセスに組み込まれたＩＴに係る内部統制」という定義で、具体例は、入力情報の完全性・正確性・正当性を確保する統制、例外処理（エラー）の修正と再処理、マスタ・データの維持管理、アクセスの管理などです。
呼び方が2つあるのは、単なる表記ゆれではありません。「財務報告に係る内部統制の評価及び監査の基準」は「業務処理統制」という言葉を使い続けていますが、監査人が使う監基報315では、この用語はすでに「情報処理統制（Information processing controls）」に置き換わっています。実は、金融庁の内部統制基準の見直しに関する意見募集でも、「監基報315が『業務（application）』より『情報（information）』のインテグリティを重視する方向に用語を改めたのだから、実施基準側も『業務処理統制』から『情報処理統制』に合わせるべきではないか」という意見が出ていました。ただ、この意見は基準の改訂には反映されず、同基準側は「業務処理統制」のままになっています。実務では両方の呼び方が並存している、と理解しておくとよいと思います。
なお、基準はIT全般統制の不備についても、重要な視点を示しています。IT全般統制の不備は、財務報告の重要な事項に虚偽記載が発生するリスクに直接つながるものではないため、直ちに開示すべき重要な不備と評価されるわけではありません。ただし、IT全般統制に不備があると、IT業務処理統制が整備されていても、その有効な運用を継続的に維持できなくなる可能性があり、結果として虚偽記載のリスクは高まります。「今すぐアウト」ではなく「じわじわ効いてくる」というのが、この基準が示している位置づけです。
もう一段階、上位の枠組みも押さえておきます。内部統制は、次の6つの基本要素で構成されています。IT統制は、この最後の「ITへの対応」を具体化したものです。
| 基本要素 | 定義（同基準より） |
|---|---|
| 統制環境 | 組織の気風を決定し、組織内の全ての者の統制に対する意識に影響を与えるとともに、他の基本的要素の基礎をなす基盤 |
| リスクの評価と対応 | 組織目標の達成を阻害する要因をリスクとして識別・分析・評価し、適切な対応を行う一連のプロセス |
| 統制活動 | 経営者の命令及び指示が適切に実行されることを確保するために定める方針及び手続 |
| 情報と伝達 | 必要な情報が識別・把握・処理され、組織内外及び関係者相互に正しく伝えられることを確保すること |
| モニタリング | 内部統制が有効に機能していることを継続的に評価するプロセス |
| ITへの対応 | 組織目標を達成するために予め適切な方針及び手続を定め、業務の実施において組織内外のITに適時かつ適切に対応すること |
この6つのうち、「ITへの対応」は日本の基準で独自に追加された要素です。COSOの国際的な内部統制フレームワークは本来、統制環境・リスク評価・統制活動・情報と伝達・モニタリングの5要素で構成されています。
同基準は、ITが組織に深く浸透している現状を踏まえ、ここに「ITへの対応」を6つ目の基本的要素として加えました。これは新しいITシステムの導入や更新を組織に強いるものではなく、「組織内外のITに適切に対応することが、内部統制の目的達成に不可欠になっている」という現状認識を明文化したものだと基準は説明しています。
現代の企業では、システムなしに業務を回すことがほぼ不可能になっています。だからこそ、IT統制の整備なしに内部統制全体の実効性を確保することはできません。IT統制は「おまけの1項目」ではなく、他の5要素を支える基盤の一つだと考えた方が実態に近いはずです。
▶ 詳しくはこちら：内部統制とIT統制の違いとは？3種類の分類と実務の進め方
IT全般統制の全体像｜4つの領域
IT全般統制は、実務では4つの領域に整理して扱うのが一般的です。金融庁・企業会計審議会「財務報告に係る内部統制の評価及び監査の基準」（2023年4月7日改訂）でも、IT全般統制の具体例として、この4項目とほぼ同じ内容が挙げられています。
基準の条文とJ-SOXの現場で使われる呼び方は、表現がやや異なります。混乱しやすいポイントなので、対応関係を表にしておきます。
| 領域 | 基準の表現（財務報告に係る内部統制の評価及び監査の基準） | J-SOX現場での呼び方 |
|---|---|---|
| 変更管理 | システムの開発、保守に係る管理 | システムの開発・保守 |
| 運用管理 | システムの運用・管理 | システムの運用・管理 |
| アクセス管理 | 内外からのアクセス管理などシステムの安全性の確保 | 内外からのアクセス管理 |
| 外部委託管理 | 外部委託に関する契約の管理 | 外部委託に関する契約の管理 |
基準は、経営者がIT全般統制を評価する際も、この4項目に沿って整備・運用状況を確認するとしています。さらに、評価の頻度についても実務上重要な指定があります。財務報告の信頼性に特に重要な影響を及ぼす項目を除き、前年度の評価結果が有効で、かつ整備状況に重要な変更がない項目については、前年度の評価結果を継続利用してよいとされているのです。結果として、複数の会計期間に一度の頻度で評価する運用も認められています。ただし、これは「何年かに一度でよい」という機械的なルールではなく、IT環境の変化を踏まえて経営者が慎重に判断し、必要に応じて監査人と協議して決めるべきものだとされています。毎年すべての項目をフルスクラッチで評価している会社があれば、ここは見直しの余地があるかもしれません。
IT全般統制の評価は、この4領域を順番に片付けていく作業ではありません。まず「システム構成と業務プロセスの理解」から始めます。どのシステムがどの業務に関わっているか、データはどこから来てどこへ流れるか、開発体制や運用体制はどうなっているか。この全体像がないまま個別の領域だけを見ても、何が重要で、どこに不備があるかを正しく判断できません。全体像を踏まえた上で、4領域を並行して評価していくのが実務での進め方です。この作業には、業務とITの双方への理解が欠かせません。どちらか一方しか分からない評価者では、現場の実態を正しく把握するのは難しいはずです。
全部を同じ厳密さでやる必要はない｜リスクベースという考え方
ここまで4つの領域を説明してきましたが、実務では「4領域すべてを同じ厳密さで評価する」わけではありません。経済産業省の「システム管理基準追補版（財務報告に係るIT統制ガイダンス）」（令和6年12月25日）が示すIT統制評価のロードマップには、評価結果を分析したうえで「リスクの高いものから優先順位を付けて対応策を実施する」ことが明記されています。財務報告への影響が大きいと想定される領域では、より広範囲なテストや統制項目の追加を行い、影響が小さい領域では、そこまでの厳密さを求めない。この濃淡のつけ方は、公式にも認められている考え方です。
ここで注意したいのは、「統制のためのチェックリストを埋めること」自体が目的化してしまうケースです。この後の「不備トップ10」でも見るとおり、監査で指摘される項目の多くは、技術的に高度なことをやっていないのに指摘されています。統制を整備する目的は、あくまで財務報告の信頼性を確保することであり、チェックリストの項目を埋めること自体ではありません。「なぜこの統制が必要なのか」を見失うと、形だけ整えて中身が伴わない、という状態に陥りがちです。
もう一つ、実務でよく見落とされるのが、外部監査人との早期の協議です。同じガイダンスは、評価対象とするITの範囲について、事業年度のできるだけ早い段階で外部監査人と認識を合わせておくことを推奨しています。評価範囲に入れなかった子会社やシステムについて、期末になってから監査人に不備を指摘されると、是正のための時間的余裕がなくなってしまいます。範囲の決定は社内だけで完結させず、早めに監査人を巻き込んでおいた方がいい、というのが実務上の教訓です。
現場でよく見る不備のパターン
実際に評価の現場に入ると、最も頻繁に出てくる不備はアクセス管理です。退職者のアカウントが残ったままログインできる、全員が管理者権限を持っていて誰でも設定を変更できる、という状態は珍しくありません。アカウント棚卸を定期的に行っていないどころか、そもそもどのシステムを契約しているのかすら、社内で正確に把握できていないケースもあります。
変更管理では、「うちはアジャイルなんで」という説明で、仕様書も議事録もなく、デプロイのタイミングも管理されていないケースをよく見かけます。ノリで開発が進んでいた、という表現がそのまま当てはまることもあります。もちろんアジャイル開発そのものを否定しているわけではありません。ただ、それが「ドキュメントや証跡を残さない」「手順を決めない」ことの免罪符になってはいけない、というのがここでの論点です。
不備が見つかった後の対応にも時間がかかります。修正だけで済めばよいのですが、場合によっては組織体制ごと見直すことになり、数か月単位の対応になることもあります。だからこそ、開発部門とガバナンス担当が普段から連携しておくことが、結果的に近道になります。
J-SOXとIT全般統制の関係
4領域の実務に入る前に、そもそも何のためにこれをやるのか、という土台を確認しておきます。
J-SOXは、財務報告に係る内部統制の評価・監査制度です。内部統制には、業務の有効性および効率性、報告の信頼性、法令遵守、資産保全という4つの目的があり、IT統制はこれを支える一部として機能します。
多くの企業が「財務に直結しないシステムは対象外」と考えていますが、これは誤解です。人事システムや在庫管理システムであっても、最終的に財務諸表の数字につながるのであれば、評価範囲に含まれます。J-SOXが求めているのは「システムの技術的な健全性の点検」ではなく、「財務報告の正確性を支える統制設計・運用・証跡の整備」です。
対応が停滞する根本原因は、多くの場合、技術的な不備ではありません。会計側とエンジニア側の「認識ギャップ」です。会計側は「何の基準で、何を評価するか」という土台が整理できておらず、エンジニア側は、技術的な正確性よりも承認記録を求められる理由が分からないまま作業を進めることになります。両者は評価の枠組みそのものを共有しないまま、互いに「相手が分かっていない」と感じ、平行線をたどります。
システムレベルの統制不備は、入口の経理チェックだけでは補完できません。かつての手作業の伝票処理であれば、人間のチェックで誤りを防ぐこともできました。しかし現在は、販売管理システムが自動生成した仕訳が、そのまま決算数値に直結します。単価マスタの誤更新のような不備は、経理担当者が伝票を1枚ずつ見返しても気づけません。
実際に起きた例を挙げます。キーコーヒー株式会社は、2025年6月に提出した有価証券報告書を、その後訂正しています。原因は、2025年1月に導入した新しい基幹システムで、自社倉庫間を移動した商品が「入庫済」と「積送中在庫」の両方に計上されてしまう二重計上でした。同社はこれを3つの不備として整理しています。重要なシステム導入時の情報伝達ルールが不明確だった全社的IT統制の不備、カスタマイズしたプログラムの受入検証で出荷側の在庫減少確認が漏れていたIT全般統制の不備、そして期末の積送中在庫の検証プロセスがこの種のシステムエラーを検出できない仕様だった業務プロセス統制の不備です。財務諸表監査そのものは適正と評価されており、内部統制の不備が直ちに決算数値の誤りにつながったわけではありませんが、システム導入・移行の場面でIT全般統制と業務プロセス統制がどちらも機能していないと、こうした形で表面化することがよく分かる事例です。
株式会社ツインバードも、2025年5月に同様の開示をしています。2024年12月に導入した新しい基幹システムで、原価計算と関連データの連携機能について、導入前のシステムテストの検証手続が不十分でした。本番稼働後に原価計算結果の不整合が発生し、システム内での原価計算を諦めてシステム外で暫定的に計算する対応を取った結果、決算作業が遅延し、在庫購買管理の決算統制を十分に実施できなくなりました。同社はこれをIT全般統制の不備（新基幹システム導入時のシステムテスト工程の不備）と認定しています。もう一つの要因として、新基幹システムの開発要件を理解していた担当者が退職し、適切な引き継ぎがされなかったことも挙げられています。決算統制が回らなくなった直接の引き金はシステムテスト不足ですが、その裏には「担当者が辞めたら誰も分からなくなる」という、属人化のリスクも重なっていたことになります。
2社に共通するのは、どちらも新しい基幹システムを導入した直後に問題が表面化している点です。IT側の統制評価が不可欠になっているのは、こうした背景があるためです。
罰則よりも先に効いてくるのが、監査対応工数の増加です。IT全般統制に不備があると、監査人はシステムデータの信頼性を独自に検証する必要が生じ、手作業でのサンプルテストなど追加の手続きが発生します。この負担は、統制が改善されるまで毎年続く可能性があります。
対応の進め方としては、いきなり4領域に着手すると迷子になります。まずシステム棚卸でどのシステムがどの業務に関連するかを整理し、次にデータフローを追跡して財務数値への接続経路を確認し、リスク仮説を立てたうえで4領域に割り振っていく、という順番が現実的です。IPO準備企業であれば、N-2期（上場申請の2期前）から着手するのが一つの目安になります。
▶ 詳しくはこちら：J-SOXのIT統制とは？対象範囲・担当部門・対応手順を解説
領域①変更管理｜承認と証跡が監査対応の核になる
変更管理で監査人が確認する目的は、突き詰めると一つです。「承認なしに本番コードが変更される状態」を防げているか、という点です。会計システムや財務データに関わるプログラムが無承認で変更されてしまう状態は、数字の改ざんリスクに直結します。具体的には、次の4点が確認されます。
- 変更要件が記録されているか
- 申請者以外が承認しているか
- 本番反映前にテストが行われているか
- 承認後に本番反映されているか
近年は、GitHubのプルリクエスト（PR）が、この証跡としてそのまま機能する仕組みが整ってきました。PRには、diff（何を変更したか）、作成者（誰が申請したか）、レビュアーの承認記録（タイムスタンプ付き）、コメント履歴、マージした人と日時、紐づくIssue・チケットが自動的に記録されます。この記録をそのまま監査証跡として使えるのが、GitHub運用の強みです。
証跡として機能させるには、次の3つの設定が最低限必要です。
- ブランチ保護：mainブランチへの直接pushを禁止し、承認なしの本番反映を防ぐ
- 自己承認禁止：PR作成者が自分自身のPRを承認できないようにする
- レビュアー固定：
.github/CODEOWNERSで、重要な領域のレビュアーを強制指定する（例：/src/accounting/ @lead-engineer @cfo-reviewer）
運用フローとしては、次のような流れが一般的です。
- 変更要求の起票（Jira／Backlogなど）
- 変更承認者による優先度・影響度の評価
- featureブランチでの開発
- PR作成・レビュアー指定
- コードレビュー（技術承認）
- CI/CDによるテスト実行
- ステージング環境での動作確認
- 業務部門によるUAT（受け入れテスト）・承認
- 本番移行の承認（開発者とは独立した承認者が行う）
- mainへのマージ＝本番デプロイ
- デプロイ後の動作確認と証跡保存
ここで一手間かけておくと効果が大きいのが、チケット番号をPRタイトルに記載しておくことです（例：「fix: 売上計上バグ #1234」）。要件を書いたチケットから、実際のコード変更まで、証跡を一本の線でつなげて追跡できるようになります。監査人にとっても、口頭説明に頼らず、この線をたどるだけで変更の妥当性を確認できるという意味があります。
一方で、こうした仕組みを入れても、レビューが「LGTM」の一言だけで終わる形骸化、少人数の組織で申請者本人が自分のコードを承認してしまう自己承認、本番デプロイ前のテストが形式的になるテスト不足は、監査でよく指摘されるパターンです。緊急対応（ホットフィックス）で通常フローを外れる場合も、エスカレーションフローと事後の修正手続きの記録さえ残しておけば対応できます。「設定していること」と「実際に機能していること」は別物だ、というのが、この領域で最も重要な視点です。
変更管理には、日々の小さな修正だけでなく、システムの入れ替えという大きな変更も含まれます。監基報315は、変更管理の一部として「データコンバージョン」（システムの開発・導入・アップグレードに伴うデータ移行）を統制項目として挙げています。先ほどJ-SOXの節で触れた、システム移行時のデータ不整合というトラブルは、まさにこのデータコンバージョンの統制が不十分だったケースに当てはまります。新システムを入れる作業そのものより、「移行の前後でデータが正しく引き継がれているか」を検証するプロセスの方が、実は見落とされやすいポイントです。
▶ 詳しくはこちら：IT全般統制の変更管理｜GitHubのプルリクエストが監査証跡になる仕組み
領域②運用管理｜インシデント対応で「やってはいけないこと」
運用管理では、日々のIT業務が正しく機能しているかを見ます。バッチ処理の監視やバックアップと並んで、監査での指摘が多いのが、インシデント対応です。
インシデント管理と問題管理は、似ているようで役割が違います。インシデント管理は、発見→初動→事象・影響の特定→回復→収束宣言という5段階で、「今起きている障害を止める」ことが目的です。これに対して問題管理は、原因究明→対策検討→振り返りという3段階で、「同じことを繰り返さない」ことが目的です。復旧を急ぐあまり、この問題管理のフェーズがまるごと抜け落ちる現場は少なくありません。「直して終わり」では、統制としては機能していないと見なされます。
監査で指摘されるパターンは、大きく3つです。
- 記録を残さない対応：Slackや口頭だけでのやり取りは属人化し、後から監査対応ができなくなる
- 原因分析をしない：復旧はしたが「なぜ起きたか」の反省がなく、同じ障害が繰り返される
- 責任者が不明確：本番環境への緊急変更を承認した人が記録に残っていない
いずれも、対応そのものは適切でも、証跡が残っていないために「統制されている」と説明できなくなるケースです。正しい体制としては、対応者・作業者・レビュアー・インシデント責任者の役割を分け、本人が自分自身の対応を承認する構造は避ける必要があります。監査で求められる証跡は、主に次の6点です。インシデント起票（発生時刻・内容・発見者）、対応記録（時系列での作業内容）、承認記録、原因分析と再発防止策、重大度分類とエスカレーション、社内報告体制の記録です。
監視ツールやバックアップツールを導入していても、それを「証跡として使う」という発想がない現場は多く、IPO準備の段階になって初めて不備に気づくというパターンもよく見られます。ツールがあることと、統制として機能していることは、ここでも別問題です。
インシデント対応と並んで見落とされがちなのが、構成管理とバックアップです。経済産業省のIT統制ガイダンスは、構成管理を「情報資産の購買・設置・固定資産管理・廃棄等の統制結果を資産情報として一元管理し、情報システムを正しい構成に保つこと」と位置づけています。許可されていないソフトウェアやハードウェア、クラウドサービスの使用を禁止し、調達記録を管理台帳に反映させ、情報資産の有効期限が来たら管理者に警告する仕組みを持たせる。地味に見えますが、無断で持ち込まれた機器やソフトウェアが誤処理やシステム停止の原因になるケースは実際にあります。
バックアップについても、同ガイダンスは「バックアップを取得すること」だけでなく「バックアップ媒体からの復旧をテストすること」まで求めています。バックアップは取っているが、実際に復旧できるかを試したことがない、という状態は、監査ではほぼ確実に指摘されます。
▶ 詳しくはこちら：インシデント対応で「やってはいけないこと」｜IT全般統制の監査で指摘される運用管理の穴
領域③アクセス管理｜アカウント棚卸「監査に通るExcel必須7項目」
アクセス管理は、誰がどのシステムにどんな権限でアクセスできるかを対象にします。この領域の実務の中心が、アカウント棚卸です。
アカウント棚卸とは、システムの利用者と権限を、定期的に確認・整理する作業です。監査に通す証跡としては、次の7項目をExcelにまとめる形が基本になります。
| # | 項目 | 内容 | 必須理由 |
|---|---|---|---|
| 1 | ユーザーID | システムログインID | 識別のため |
| 2 | 氏名 | フルネーム | 在籍確認のため |
| 3 | 所属・役職 | 部署・雇用形態 | 権限妥当性の確認 |
| 4 | 権限レベル | 管理者／一般／閲覧のみ | 最小権限原則の確認 |
| 5 | 在籍ステータス | 在籍中／退職済／休職中 | 削除対象の特定 |
| 6 | 確認者・確認日 | 誰がいつ確認したか | 監査証跡として最重要 |
| 7 | 対応状況 | 不要／削除済／権限変更済 | 結果の記録 |
6の確認者・確認日が抜けていると、「棚卸をやった」という証跡にならず、監査では未実施と同じ扱いになってしまいます。実施の流れは、次の5ステップです。
- システムからCSVでユーザーリストをエクスポートする（証跡としてスクリーンショットも残す）
- 人事データと照合する（退職日を超えたアカウント、外部委託・派遣の契約終了日、長期休職者・育休中の権限停止要否を確認）
- 各システムのオーナー（業務責任者）に、権限の妥当性を確認してもらう
- 削除・権限変更を実施し、記録を残す
- Excelに確認者・確認日を記入し、サイン・メール・ワークフロー承認のいずれかで証跡化する
棚卸対象の優先順位は、財務諸表への影響度で決めます。会計システム（freee・弥生など）、ERPや売上・受発注システム、AWS・GCPなどのクラウドインフラ、給与・人事システムの順に優先度が高くなります。体制としては、情シスが「リストの出力」を担当し、業務責任者が「権限の妥当性判断」を担当するという役割分担が基本です。頻度は年1回の定期棚卸を基本に、退職・異動・外部委託終了のタイミングでリアルタイムに対応します。
現場でよく起きる失敗は、業務委託や派遣のアカウントが放置されるケースです。人事側と情シス側の連携が不足していると、退職・契約終了の情報が伝わらないまま、アカウントだけが残り続けます。GitHubやAWSのような外部サービスは、契約終了後の即刻削除を習慣にしておく必要があります。情シスだけでアクセス管理を完結させようとする体制自体に、そもそも無理があります。
アカウント棚卸は「定期的な事後チェック」ですが、これとは別に「日常的な設計」も必要です。経済産業省のIT統制ガイダンスは、アクセス管理を次の4つの観点に整理しています。
- アクセス制御：職務権限に応じてアクセス範囲・権限レベルを決め、担当者の登録・削除は承認手続きを経る。特に管理者権限（特権ID）は、担当者と利用期間を限定し、その業務にしか使わせない
- パスワードの管理：パスワードの方針を決め、社内の全システムに統一して適用する
- ネットワークアクセスの制御：ネットワークへの接続を、事前に定めたルールで制限する
- OSのアクセス制御：本人認証の機能を持たせ、認証の成功・失敗をログとして記録・保管する
アカウント棚卸が「今の状態が正しいか」を定期的に確認する仕組みだとすれば、この4観点は「そもそも権限がどう発行され、どう制限されるか」という設計側の話です。両方が揃って初めて、アクセス管理が機能していると言えます。
監基報315の付録は、アクセス管理のプロセスをさらに細かく、認証・権限の付与・プロビジョニング（新規利用者への権限付与や既存アクセス権の変更を承認する内部統制）・デプロビジョニング（退職・異動時にアクセス権を削除する内部統制）・特権アクセス・利用者アクセスレビュー・セキュリティの環境設定・物理的アクセス（データセンターやハードウェアへの物理的なアクセス制限）に整理しています。「プロビジョニング」「デプロビジョニング」という言葉は聞き慣れないかもしれませんが、要は「権限を与えるとき」と「権限を外すとき」のプロセスをそれぞれ独立した統制として管理する、という考え方です。物理的アクセスは見落とされがちですが、どれだけ論理的なアクセス制御を固めても、サーバーやハードウェアに誰でも物理的に触れる状態では、その制御自体を無効化されてしまいます。
▶ アカウント棚卸Excelテンプレート（7項目＋承認欄つき）をダウンロードする
▶ 詳しくはこちら：アカウント棚卸のやり方｜監査を通す業務プロセスと証跡の残し方
領域④外部委託管理｜SOC1レポートで委託先を評価する
外部委託管理は、外部委託先や外部サービスの利用が適切に管理されているかを対象にします。実務上の中心にあるのがSOC1レポートですが、その前段階として、委託先を選ぶ・契約するという入口のプロセスも見ておく必要があります。
経済産業省のIT統制ガイダンスは、特定の業務を数多くの企業から請け負うクラウドサービスほど、委託先の内部統制がブラックボックスになりやすいと指摘しています。だからこそ、契約前の段階で、委託先の業務提供能力や財務上の適格性を確認し、契約書には委託業務の主なリスクへの統制方法と、それを確認するための監査権（再委託先の分も含めて）を明記しておくことが重要になります。委託先の拠点が海外にある場合は、その国・地域の法令や規制に起因するリスクも判断材料に加えます。契約後は、サービスレベル契約（SLA）を結び、委託業務が要求どおりに実施されているかをモニタリングします。
こうした入口の設計をした上で、実際に稼働している委託先の統制状況を確認する手段として使われるのが、SOC1レポートです。SOC1レポートは、システムベンダーの内部統制に係る保証報告書で、外部監査人が受託者の統制を評価・証明したものです。財務報告に影響するプロセスを外部委託している以上、委託先の統制が機能しているかを、独立した第三者の目で確認する必要があります。
| 区分 | 評価内容 | 信頼度 |
|---|---|---|
| Type1 | 特定時点における統制の整備状況のみ | 限定的 |
| Type2 | 一定期間（通常1年）の整備・運用状況 | 高い |
信頼度が高いのはType2です。SOC1レポートがない場合、監査法人からは追加ヒアリングや証跡の個別確認、委託先への往査（実査）が求められます。これは監査スケジュールを大きく圧迫する要因になります。
会計ソフトを選ぶ際、SOC1レポートの有無はほぼ必須の選定基準と考えてよいでしょう（※以下は2026年8月時点で確認した情報のため、選定時には必ず最新状況を確認してください）。freee・マネーフォワード・OBC奉行シリーズ・PCAクラウド・TKC関連システムはType2相当の取得済み、弥生会計は確認範囲では未取得でした。一方、kintoneのような周辺の販売・購買システムはSOC1を取得していないケースもあり、システムごとに対応がまちまちです。SOC1取得システムは価格が高い傾向にあるため、乗り換えを検討するならIPO準備のN-2期からN-3期あたりが現実的なタイミングになります。
なお、SOC1とSOC2は別物です。
| 項目 | SOC1 | SOC2 |
|---|---|---|
| 評価対象 | 財務報告関連の内部統制 | セキュリティ・可用性 |
| 主な利用場面 | 監査法人からの要求への対応 | セキュリティ水準の確認 |
| 財務報告の代替性 | ○ | △（限定的） |
SOC2はセキュリティ評価としては有効でも、財務報告の保証としてはそのまま代替できません。取り寄せて満足してしまい、実際にはレポート内の「利用者側が実施すべき統制（UEC）」の部分を読んでいない、というのが現場で最も多い不備です。
委託先の選定基準や契約内容の整理、SOCレポートの読み方まで、社内だけで進めるのが難しいと感じたら、外部の支援を借りるという選択肢もあります。会計とITの両方が分かる立場から見ると、この領域は特に自己流で進めて後から手戻りが出やすいところです。
▶ 詳しくはこちら：IT全般統制：SOC1レポートのあるシステムを選ぶべき理由
監査で指摘されるIT統制不備トップ10
ここまでの4領域を踏まえて、実際に監査で指摘される不備を、発生頻度と影響度から順位づけしたものが次の一覧です。
| 順位 | 不備内容 | 発生頻度 | 影響度 | 該当領域 |
|---|---|---|---|---|
| 1 | アカウント棚卸未実施、または証跡なし | ★★★★★ | ★★★★☆ | アクセス管理 |
| 2 | 退職者アカウントの削除漏れ | ★★★★☆ | ★★★★☆ | アクセス管理 |
| 3 | 本番環境へのアクセス権が複数人に付与 | ★★★☆☆ | ★★★★★ | アクセス管理 |
| 4 | 変更管理が形骸化している | ★★★☆☆ | ★★★★★ | 変更管理 |
| 5 | 開発環境と本番環境の分離がない | ★★★☆☆ | ★★★★★ | 変更管理 |
| 6 | 操作マニュアルが存在しない・未更新 | ★★★★★ | ★★★☆☆ | 運用管理 |
| 7 | バッチ処理エラーの通知がない | ★★★☆☆ | ★★★★☆ | 運用管理 |
| 8 | 委託先選定基準が未設定 | ★★★★☆ | ★★★☆☆ | 外部委託管理 |
| 9 | IT統制運用の属人化 | ★★★★☆ | ★★★☆☆ | 運用管理 |
| 10 | 二段階認証・VPNが未設定 | ★★★★☆ | ★★☆☆☆ | アクセス管理 |
カテゴリ別に見ると、アクセス管理に関する不備が4件（1・2・3・10位）と最も多く、運用管理が3件（6・7・9位）、変更管理が2件（4・5位）、外部委託管理が1件（8位）という内訳になります。ここまで読んでいただいた方には、この分布がそのまま4領域の実務内容と対応していることが分かるはずです。
不備の根本原因は、多くの場合「担当者が曖昧」「管理が追いつかない」「証跡がない」という3つに集約されます。技術的に難しいことをやっていないのに指摘される、というケースがほとんどです。だからこそ、最初の一歩としてアクセス管理、特にアカウント棚卸から着手するのが、費用対効果の高い進め方だと考えています。
▶ 詳しくはこちら：監査で指摘されるIT統制不備トップ10｜公認会計士が現場で見た実例と対策
上場準備・上場子会社化で見落とされがちなIT全般統制
ここからは、少し発展的な論点に触れます。まずはM&Aの場面です。
買収した企業が「重要な構成単位」と判定されると、その企業にも親会社と同水準のIT全般統制評価が求められます。ところが、M&Aの意思決定時は事業シナジーや顧客基盤、システム資産といった前向きな評価軸に集中しがちで、「買収後に発生する統制構築の義務」という観点は後回しにされやすいのが実情です。
非上場企業では、共有アカウントでのログイン、退職者アカウントの削除未実施、無承認での改修・設定変更、外部委託内容の把握不十分といった状態が、統制を意識しないまま放置されているケースが珍しくありません。買収後に会計側から「統制上当然の手続き」を求められても、現場は「意味不明な余計な作業」と感じ、この認識ギャップが離職につながることもあります。
買収後統合（PMI）の一部として発生するIT全般統制の構築コストは、外部コンサル費用や社内人員配置、システム連携作業など多岐にわたります。これが予算計画に織り込まれていないと、特定の担当者に負担が集中してしまいます。買収前のデューデリジェンスの段階で、システム構成の棚卸や権限管理体制、変更履歴・アクセス記録の保存状況を確認しておくコストは、買収後に慌てて対応するコストより、はるかに小さくて済みます。
▶ 詳しくはこちら：IT全般統制、上場子会社になった時の落とし穴
生成AI時代のIT全般統制｜COSOガイダンスを4領域で読み解く
もう一つの発展的な論点が、生成AIです。COSO（内部統制委員会）は2026年に、生成AIの内部統制に関するガイダンスを公表しました。これは新しいフレームワークではなく、既存のCOSO5要素（統制環境・リスク評価・統制活動・情報と伝達・モニタリング）を、生成AIに適用するための実務ガイダンスという位置づけです。
生成AIが従来のシステム統制と異なるのは、確率的に動作する点です。同じ入力に対して同じ結果が返るとは限らず、モデルや設定も継続的に変化します。誤りが高速かつ大量に処理される可能性がある一方、現場がIT部門を通さずに使い始められてしまう、という特徴もあります。
COSOのガイダンスでは、生成AIの利用を8つの能力に分類しています。
| 能力 | 利用例 | 主なリスク |
|---|---|---|
| データ抽出・取込み | 請求書・契約書から項目抽出 | 読取漏れ、データ欠落 |
| データ変換・統合 | データ分類・正規化・統合 | マッピング誤り |
| 取引処理・照合 | 請求書照合、自動仕訳 | 誤分類、閾値不備 |
| ワークフロー・自律実行 | AIエージェントの自動実行 | 過剰権限、承認迂回 |
| 判断・予測・分析 | 売上予測、意思決定資料の作成 | ハルシネーション |
| AIモニタリング | 不正検知、異常値検知 | 誤検知、見逃し |
| 情報検索・要約 | 法令・契約書の検索 | 根拠のない要約 |
| 人間協働 | チャット、文章作成の補助 | 情報漏えい |
自社のAI利用がどの能力に当てはまるかを整理すると、リスクの所在が見えやすくなります。このガイダンスは、生成AIのリスクを、これまで説明してきた4領域にそのまま当てはめて考えます。変更管理では、モデルの更新やプロンプトの変更、参照文書の更新も「出力を変える変更」として管理対象になります。運用管理では、AIの出力を「検証が必要な主張」として扱い、入力・プロンプト・出力・参照元・モデルバージョン・レビュー結果を追跡できる形で保存します。アクセス管理では、ツールへのアクセス権だけでなく、「参照可能なデータ範囲」「実行可能な処理範囲」も管理対象に加わります。外部委託管理では、ベンダーのモデル更新時期や性能検証の方法、SOCレポートの確認が論点になります。
すべてのAI利用がIT全般統制の対象になるわけではありません。判断基準は「AIの結果にどこまで依拠しているか」です。社内文書の下書き補助のように最終判断を人間が行っている場合は対象外ですが、AIが証憑と仕訳を自動照合し、担当者がAIの判定だけを見て承認しているような場合は、モデル・プロンプト・アクセス権・外部連携についてのIT全般統制が必要になります。
最初にやるべきことは、社内で稼働中・計画中のAI利用ケースをすべて洗い出す「棚卸」です。利用ケース名、業務プロセス、責任者、AIへの依拠度、該当する領域、主要な統制を一覧化するところから始めます。財務報告や法令遵守に関わる利用ケースから優先的に着手するのが現実的です。
▶ 詳しくはこちら：IT全般統制にAIのリスクをどう組み込むか｜COSOの考え方と4カテゴリ評価
会計側とIT側、どちらの言葉も分かる相談先をお探しの方へ
公認会計士とシステム監査技術者、両方のライセンスを持つからこそ押さえられる要点があります。エンジニアに寄り添ったコミュニケーションで、監査対応・IPO準備・M&A後のPMIなど、状況に応じたIT統制構築をご支援しています。
まとめ
IT統制には、IT全社的統制・IT全般統制・情報処理統制という3種類があり、IT全般統制はその中でも「システムが信頼できる状態で運用されているか」を担保する土台です。変更管理・運用管理・アクセス管理・外部委託管理という4つの領域は、それぞれ独立した実務ですが、根っこにある問題は共通しています。会計側とIT側の間で、前提知識と共通言語が共有されていないことです。
監査で指摘される不備トップ10のうち、最も多いのはアクセス管理に関するものでした。J-SOX対応、上場準備、M&A、生成AI対応と、状況によって次に見るべき論点は変わりますが、迷ったときはまずアクセス管理、特にアカウント棚卸から着手するのが、現実的な一歩になります。
ITの重要性は、今後さらに増していきます。それにもかかわらず、ここまで書いてきたような基本的な統制すら整っていない会社は、実務の現場ではまだ多く見かけます。会計とITの両方が分かる立場から見ると、そこにはまだ伸びしろがあると感じています。まずはこの記事のチェックリストで、自社の現在地を確認するところから始めてみてください。
▶ IT全般統制チェックリスト（自己点検用）をダウンロードする
関連記事（内部リンク一覧）
- IT全般統制がわかりにくい本当の理由
- アカウント棚卸のやり方
- IT全般統制の変更管理｜GitHubのプルリクエストが監査証跡になる仕組み
- インシデント対応で「やってはいけないこと」
- 監査で指摘されるIT統制不備トップ10
- IT全般統制：SOC1レポートのあるシステムを選ぶべき理由
- J-SOXのIT統制とは？対象範囲・担当部門・対応手順を解説
- 内部統制とIT統制の違いとは？3種類の分類と実務の進め方
- IT全般統制、上場子会社になった時の落とし穴
- IT全般統制にAIのリスクをどう組み込むか｜COSOの考え方と4カテゴリ評価
- IT業務処理統制（ITAC）とは？IT全般統制との違いと評価のポイント
- 【支援事例】「内部統制×情報セキュリティ」で企業価値を高める（ブランディングテクノロジー株式会社）
