IT全般統制にAIのリスクをどう組み込むか｜COSOの考え方と4カテゴリ評価

📚 IT全般統制シリーズ
まず全体像から知りたい方は、こちら →
IT全般統制（ITGC）とは？4つの領域と実務対応

はじめに

「IT全般統制の対象に、AIの利用をどう含めるべきか」――この問いに明確な答えを持っている会社は、まだ多くありません。

生成AIを業務に使う会社は増えています。文章の下書きや情報検索だけでなく、請求書の読み取り、仕訳の提案、契約書のレビュー、売上予測、異常取引の検知など、利用範囲は少しずつ基幹業務へ広がっています。一方で、「AI利用規程は作ったが、IT全般統制の評価対象にAIを含めるかどうかは決めていない」という会社に、実務の相談の中でよく出会います。

2026年、COSO（Committee of Sponsoring Organizations of the Treadway Commission）は「Achieving Effective Internal Control Over Generative AI（GenAI）」を公表しました。生成AIのために新しい内部統制の枠組みを作るのではなく、既存のCOSO内部統制フレームワークの5要素・17原則を、生成AIの特徴に合わせて適用する考え方を示した文書です。

この記事では、COSO文書の内容をそのまま紹介するのではなく、日本企業がJ-SOX上のIT全般統制を運用する立場から、生成AIのリスクをどこに位置づけ、何を整備すべきかという観点で整理します。

この記事を読んでわかること

「AIを使っている」ことがなぜIT全般統制の論点になるのか
COSOが示す生成AI統制の考え方（5要素・8つの能力分類）
生成AIのリスクをIT全般統制の4カテゴリ（変更管理・運用管理・アクセス管理・外部委託管理）にどう当てはめるか
AIがIT全般統制の評価対象になるかどうかの判断基準と、最初に行うべきAI利用ケースの棚卸

なぜ「AIを使っているか」がIT全般統制の論点になるのか

IT全般統制は、本来「システムの継続的かつ適切な運用を支える会社のプロセス」を評価するものです。開発・変更管理、運用管理、アクセス管理、外部委託管理という4つのカテゴリで整理されるのが一般的な実務です（詳しくはIT全般統制とはで解説しています）。

このカテゴリ分けは、システムが「同じ入力に対して同じ結果を返す」ことを前提に組み立てられています。ところが生成AIは、この前提が崩れます。同じ質問をしても表現や結論が変わり得ますし、ベンダー側がモデルを更新しただけで、それまで有効だった統制が機能しなくなることもあります。

実務でぶつかるのは、「AIの管理は情報システム部の仕事」という単純な切り分けそのものより手前の問題です。従来のシステムであれば、同じ入力に対して同じ結果が返ってくることを前提に、開発・運用・アクセスといった役割分担を決められました。ところが生成AIは確率的に動き、同じ質問でも答えが揺れることがあります。この「入力を固定しても出力が固定されない」という特性そのものが、誰がどこまで責任を持つかを決めにくくしています。情報システム部に管理を任せておけば統制できる、という発想自体が、AIには通用しにくくなっているということです。

実際に難しいのは、AI利用規程を作ることそのものではありません。「入力してはいけない情報」や「禁止する用途」を定めるだけなら、規程は形にできます。難しいのは、その規程を個々の利用ケースでどう運用し、何をもって「統制できている」と判断するかです。出力が確率的に変わるAIに対して、どこまで人がチェックすれば十分なのか。その基準自体が定まっていない会社がほとんどだ、というのが実情に近いでしょう。

COSOが示す生成AI統制の考え方

新しいフレームワークではなく、既存の5要素を拡張する

最初に位置づけを整理しておきます。COSOの今回の文書は、内部統制フレームワークそのものを改訂した新基準ではありません。日本のJ-SOX基準が変更されたわけでもありません。既存のCOSOの考え方を、生成AIが組み込まれた業務にどう適用するかを示した実務ガイダンスです。

COSOの内部統制は、次の5つの構成要素から成り立っています。

統制環境
リスク評価
統制活動
情報と伝達
モニタリング活動

この基本構造は、生成AIを使っても変わりません。ただし、COSO文書は生成AIの基礎的な特徴として、確率的に動くこと、モデルや設定が継続的に変化すること、誤りも高速・大量に処理されること、現場が情報システム部を通さずに使い始められること、AIをAIの監視に使えることの5点を挙げています。従来のシステムを前提にした統制を、そのまま形式的に当てはめるだけでは不十分になる理由が、ここに集約されています。

なお、日本の内部統制基準（金融庁「財務報告に係る内部統制の評価及び監査の基準」）では、この5要素に加えて「ITへの対応」を独自に加えた6つの基本的要素で整理されています。COSOのフレームワークには「ITへの対応」という要素はなく、日本が実務上の必要性から追加したものです。生成AIをめぐる論点の多くも、実質的にはこの「ITへの対応」の中に位置づけて考えることになります。

製品名ではなく「AIが何をしているか」で分類する

COSO文書のもう一つの特徴が、AIを製品名ではなく8つの能力に分類していることです。

能力の分類	業務での利用例	主なリスク
データ抽出・取込み	請求書や契約書から項目を抽出する	読み取り漏れ、入力データの欠落
データ変換・統合	データを分類・正規化して統合する	マッピング誤り、下流データの汚染
取引処理・照合	請求書照合、自動仕訳、消込処理	誤分類、閾値の不備、大量の誤処理
ワークフロー・自律実行	AIエージェントが複数処理を自動実行する	過剰な権限、承認の迂回
判断・予測・分析	売上予測、意思決定資料の作成	ハルシネーション、過度な依存
AIによるモニタリング	不正取引・異常値の検知	誤検知、見逃し
情報検索・要約	法令・契約書・社内規程の検索	根拠のない要約、古い文書の参照
人間とAIの協働	チャット、文章作成、コード生成	情報漏えい、未検証出力の外部利用

この分類が実務的に重要なのは、同じAIツールを使っていても、使い方によって必要な統制が変わるためです。反対に、製品が違っても「請求書を読み取って自動仕訳する」という機能が同じなら、検討すべきリスクは似てきます。

IT統制の実務は、制度の理解だけでは終わりません

月次決算・IPO準備・IT統制の実務知見を、月1回メールでお届けします

無料でメルマガを受け取る

AIのリスクをIT全般統制の4カテゴリで整理する

生成AIの利用を起点に、変更管理・運用管理・アクセス管理・外部委託管理の4カテゴリへ分岐する図 — 図1　生成AIの利用は、IT全般統制の既存の4カテゴリ（変更管理・運用管理・アクセス管理・外部委託管理）へマッピングして考える

COSOの5要素・8分類は網羅的ですが、既存の4カテゴリにAIのリスクをそのまま当てはめて考えた方が運用しやすくなります。

カテゴリ1：変更管理

生成AIにおける「変更」は、自社が書いたコードの変更だけではありません。ベンダー側のモデル更新、システムプロンプトの変更、RAGで参照する文書の更新、信頼度や自動処理の閾値の変更も、すべて出力結果を変えうる「変更」です。

重要なモデル変更の前後で新旧の結果を比較する、新しい取引パターンや帳票形式は稼働前にテストする、といった手続きを変更管理の枠組みに組み込む必要があります。ベンダーが勝手にモデルを更新する場合は、その事後検証の手続きも決めておかなければなりません。自社で開発・運用しているシステムに生成AIを組み込む場合は、GitHubを使った変更管理の完全ガイドで解説しているプルリクエストベースの証跡管理が、そのままAI関連の変更にも応用できます。

つまり、AIの行った変更をそのまま鵜呑みにするのではなく、内容をきちんと検証する必要があるということです。

カテゴリ2：運用管理（IT業務管理）

ここでいう運用管理は、AIの出力を「検証すべき主張」として扱う仕組みを指します。例えば、重要な判断は有資格者や業務責任者が原資料まで確認する、一定の信頼度を下回る処理は自動実行せず例外キューへ送る、といったレビュー設計が該当します。

入力データ、プロンプト、AIの出力、引用・参照元、モデルのバージョン、人間によるレビュー結果は、後から「何を根拠にAIが出力し、誰が確認したか」を追跡できる状態で保存しておく必要があります。AIの出力をそのまま受け入れるのではなく、どのような経緯でその結果に至ったのかを追跡できる状態を確保することが重要になります。

また、生成AIは導入時に正しく動いていても、その後も同じ性能が続くとは限りません。モデルの更新や入力データの変化によって、少しずつ精度が落ちる可能性があります。正答率や修正率、例外件数の推移といった指標を継続的に確認し、一定の基準を下回った場合に利用範囲を縮小する、あるいは旧バージョンへ切り戻すといった判断ルールまで決めておくと、導入時のテストだけで終わらせずに済みます。異常時にどう対応するかという枠組み自体は、運用管理とは？インシデント管理・障害管理を解説で扱ったジョブ管理・インシデント対応の考え方と重なります。

カテゴリ3：アクセス管理

生成AIのアクセス管理では、AIツールそのものへのアクセス権に加えて、AIが参照できるデータ範囲、AIが実行できる処理範囲までを管理対象に含める必要があります。AIエージェントが複数の処理を自律的に実行する場合、過剰な権限を持たせていないか、承認プロセスを迂回していないかという職務分掌の観点が、通常のシステムより重要になります。

具体的なアクセス権の棚卸方法自体は、アカウント棚卸のやり方で解説している考え方がそのまま応用できます。

カテゴリ4：外部委託管理

生成AIの多くは外部ベンダーが提供するサービスです。ベンダーがいつモデルを更新するか、更新後の性能をどう検証できるか、SOCレポート等でベンダー側の統制状況を確認できるかは、従来の外部委託管理の論点と地続きです。

とはいえ、SOC1レポートを取得しているようなAIサービスはまだそこまで多くないと考えられるため、AI自体の信頼性についての検証方法は論点になると思います。

生成AIはIT全般統制の対象になるのか｜依拠度で判断する

実務上、特に気になるのはこの点だと思います。J-SOX対応がどこで止まりやすいかはJSOXのIT統制対応でつまずく会社に共通する、現場の落とし穴でも触れていますが、生成AIが絡むと評価範囲の線引きはさらに悩ましくなります。

結論から言うと、すべての生成AI利用をJ-SOX上のIT全般統制の対象にする必要はありません。従業員が社内文書の下書きにAIを使っているだけであれば、直ちに財務報告に係るIT全般統制の対象になるわけではないでしょう。

一方で、生成AIが財務報告に関係する重要な処理や統制に組み込まれ、会社がその出力に依拠する場合は話が変わります。例えば、AIが証憑と仕訳を自動照合し、担当者がAIの判定結果だけを見て承認しているなら、会社はAIの出力を統制証拠として利用していることになります（自動仕訳そのものの前提条件は税理士がAI自動仕訳を実現する前に見落としがちな前提条件で扱っています）。この場合、モデル・プロンプト・アクセス権・外部連携を信頼できる状態に保つIT全般統制と、個々の取引が正しく処理されたかを確かめる情報処理統制の、両方が検討対象になります。

AIへの依拠度が低い下書き作成・情報検索の補助として使用。最終判断・入力は必ず人間が行う。誤りがあっても財務報告への影響は限定的

AIへの依拠度が高いAIの判定結果をそのまま承認・自動処理に反映。原資料まで再確認しない。誤りが会計処理や開示に直接影響する

ここで大切なのは、「AIだからIT部門の問題」と切り分けないことです。IT全般統制でモデルやアクセス権を信頼できる状態に保てていても、AIが出した仕訳案や判定結果の中身そのものが正しいかどうかは、また別の問題です。その出力が「もっともらしいだけの誤り」なのか「妥当な判断」なのかを見分けるには、会計・法務・業務の専門知識が要ります。統制の仕組みを整えることと、AIが出した内容そのものを検証することは、分けて考える必要があります。

📥 AIのリスクも、まず既存のITGCの現状把握から

AIを4カテゴリに当てはめる前に、既存のITGCが回っているかを自己点検しておくと整理しやすくなります。
→ ITGCチェックリスト（自己点検用）を見る

最初に行うべきAI利用ケースの棚卸

生成AIのガバナンスを始めようとすると、最初にAI利用規程を作りたくなります。しかし、会社の中で何にAIを使っているかが分からなければ、規程を具体的な統制へ落とし込めません。

COSO文書が示す6段階の実装ロードマップ（Implementation roadmap）でも、AIガバナンス体制を確立した直後のStep2に「GenAI利用ケースの棚卸（Inventory GenAI use cases）」が置かれています。稼働中・計画中を問わずすべての利用ケースを洗い出し、能力分類・責任者・データソース・使用モデル・重要度などを記録することが求められています。この記事では、これを実務で扱いやすい形に「AI利用ケースの棚卸」として整理します。

管理項目	記載する内容
利用ケース名	請求書読取り、契約書要約など
業務プロセス	購買、経理、法務、営業など
能力分類	COSOが示す8分類のどれに該当するか
責任者・利用者	業務責任者、管理者、レビュー担当者
使用するAI	製品名、モデル、提供ベンダー
入力データ	個人情報、機密情報、財務データの有無
出力の利用先	下書き、意思決定、会計処理、自動実行など
AIへの依拠度	原資料まで再確認するか、AI出力に依存するか
該当するITGCカテゴリ	変更管理・運用管理・アクセス管理・外部委託管理のどれに関わるか
主要統制	人間の確認、閾値、ログ、変更管理など

最初から全社のAIを完全に把握しようとすると、作業が止まってしまいます。まずは、財務報告、法令遵守、顧客対応、自動実行など、誤りが大きな影響を与える利用ケースから棚卸するのが現実的です。

なお、ダウンロード資料やチェックリストの類は、最初から作り込みすぎない方がよいというのが個人的な考えです。要点だけ見える形にしておき、詳細は個別の相談で詰める方が、実際に使われる資料になりやすいと感じています。

AI利用も含めたIT全般統制の構築・評価をご検討の方へ

生成AIを業務に導入したものの、IT全般統制のどこに位置づければよいか、監査対応をどこから整理すべきか分からない場合は、お気軽にご相談ください。

無料相談・お問い合わせ

まとめ｜AIを止めるのではなく依拠度で評価する

生成AIの内部統制というと、利用禁止や承認手続きを増やす話に見えやすいものです。しかし、COSO文書が目指しているのは、AIの利用を止めることではありません。生成AIの性質を理解した上で、どこまで自動化し、どこに人間の判断を残し、どのような証跡と監視を設ければ、会社が安心してAIを使えるかを考えるものです。

実務上のポイントを整理すると、次のとおりです。

生成AI用に別の内部統制体系を作る必要はなく、既存のIT全般統制の4カテゴリ（変更管理・運用管理・アクセス管理・外部委託管理）にリスクを当てはめて考える
AIの出力は事実ではなく、検証が必要な主張として扱う
製品名ではなく、AIが業務の中で果たす機能で分類する
すべてのAI利用がIT全般統制の対象になるわけではない。判断基準は「AIの結果にどこまで依拠しているか」
AI利用規程の作成前後に、AI利用ケースの棚卸を実施する（COSOのロードマップでもStep 2に位置づけられている）

生成AIの利用が文章作成の補助にとどまっている間は、比較的簡単なルールでも対応できます。一方、会計処理・契約判断・予測・自動実行へ進むほど、AIは業務プロセスとIT全般統制の一部になっていきます。「AIを使っているか」ではなく「どの業務で、どの程度AIの結果に依拠しているか」。まずはこの観点から社内の利用状況を棚卸することが、IT全般統制にAIを組み込む第一歩になるはずです。

AIの前に、既存のITGCを自己点検する

アクセス管理・変更管理・IT運用の3領域を、自己点検の形でまとめた資料です。

ITGCチェックリストを無料でダウンロード

参考資料

Committee of Sponsoring Organizations of the Treadway Commission（COSO）, Achieving Effective Internal Control Over Generative AI (GenAI), Copyright 2026.
- https://www.coso.org/generative-ai （COSO公式ページ。PDF直リンク：https://www.coso.org/_files/ugd/719ba0_ef4dbc255331406e95faf46e7a9e3a1c.pdf ）
- 著者：Scott Emett（Arizona State University）、Marc Eulerich（University of Duisburg-Essen）、Jason Guthrie（Ernst & Young Global Limited）、Jason Pikoos（Meta Platforms Inc.）、David A. Wood（Brigham Young University）
- 本文で引用した該当ページ：8つの能力分類（p.7）、生成AIの基礎的特徴5点（p.8）、6段階の実装ロードマップ・Step2「Inventory GenAI use cases」（p.18-19）