AIと内部統制：財務チームが押さえるべきSOXの論点

著者: Jane Ha · 更新日: 2026年10月11日

AIと内部統制とは、財務報告に関わるAIツールが、上場企業がSOXの下で維持しなければならない統制にどう収まるのかという問いです。誰が責任を持つのか、何をしてよいのか、出力をどうレビューするのか、そのレビューが行われたことをどんな証拠で示すのかを扱います。 AIが新しいルールを生み出すわけではありません。人と決定論的なシステムを前提に設計された統制の枠組みの中に、速く、一貫性に欠け、説明しにくいことがある新しい種類の主体が加わるということです。

このガイドは、買掛金管理、銀行勘定調整、月次決算といったプロセスにAIを導入するコントローラー、CFO、SOXプログラムのリーダー、財務マネージャー向けです。AI for Financeコレクションの一部ですので、まず全体像を知りたい場合は財務・会計におけるAIからお読みください。

重要なポイント

• SECの規則は、発行体の経営者に対し、各会計年度末に財務報告に係る内部統制（ICFR）を評価するよう求めています。その際は、適正な手続を経て確立された、適切で認知された統制の枠組みを用います（17 CFR 240.13a-15）。
• PCAOB AS 2201は、重要な欠陥（material weakness）を、ICFRにおける不備またはその組み合わせであって、重要な虚偽表示が適時に防止または発見されない合理的な可能性が生じるものと定義しています（PCAOB AS 2201）。
• 2026年2月にCOSOが公表したAchieving Effective Internal Control Over Generative AIは、内部統制の統合的フレームワークの5つの構成要素を適用し、生成AIのユースケースを8つの能力タイプに分類しています（Journal of Accountancy）。
• 2024年7月のスポットライトで、PCAOBのスタッフは、監査法人は生成AIが人を置き換えるのではなく補完すると見ており、PCAOBの監査基準を利用の妨げとは考えていないと報告しました（PCAOB）。
• AS 2201の下で、監査人が完全に自動化されたアプリケーション統制に「ベンチマーキング」を用いることができるのは、プログラム変更、プログラムへのアクセス、コンピューター運用に関する全般統制が有効で、基準時点の設定以降に当該統制が変更されていない場合に限られます（PCAOB AS 2201）。

AIはIT部門だけの問題ではなく、SOXの問題である理由

SOX 404条は、責任を経営者に負わせています。SECの規則は、経営者が毎年、認知された枠組みに照らしてICFRを評価することを求めています。多くの財務チームが知っているのは、COSOの内部統制の統合的フレームワークです。AIツールが仕訳を準備したり、銀行明細の1行を照合したり、開示の下書きをしたり、請求書を分類したりするなら、その出力は財務諸表に流れ込み、その周囲の統制環境は対象範囲に入ります。

PCAOBスタッフのスポットライトが役に立つのは、作成者側がすでに語っていたことを説明しているからです。一部の作成者は、社内文書のたたき台や、勘定照合の準備のような複雑でない反復的な業務に生成AIを使っていました。作成者はまた、一部のツールの「ブラックボックス」的な性質と出力の不一致を指摘しており、ツールが生成するものの監査可能性に疑問が生じます。さらに一部の監査人は、作成者による生成AIの利用が、職務分掌のような既存のITリスクを増幅させたり、これまでになかったリスクを生んだりする可能性があると述べました。

この3点が、本ガイドの残りの枠組みになります。実際の会計業務に使われるツール、ばらつきのある出力、そして新しい場所に現れる従来の統制リスクです。

AS 2201の技術の扱いと、AIにとっての意味

AS 2201は、外部監査人がICFRを監査する際に従う基準です。その3つの考え方が、監査人のAIの見方を左右します。

トップダウンのアプローチ。 監査人は財務諸表レベルから始め、全社レベルの統制に重点を置いたうえで、重要な勘定とその関連するアサーションへと進みます（PCAOB AS 2201）。事業のうち財務と無関係でリスクの低い一角にあるAIツールは、テストされないかもしれません。重要な勘定の内部にあるものは、テストされます。

ITは別個に評価されない。 この基準は、監査人がITが会社の取引の流れにどう影響するかを理解すべきだとし、IT内のリスクと統制の識別は別個の評価ではなく「トップダウンのアプローチに不可欠な一部」だとしています。つまりAIシステムは、独立した技術レビューではなく、それが支えるプロセスの一部として評価すべきだということです。

自動化された統制は全般統制に依存する。 AS 2201は、関連するIT全般統制が有効であれば、自動化された統制は一般にリスクが低くなるとしています。また、プログラム変更、アクセス、運用の統制が機能している場合には、完全に自動化されたアプリケーション統制のベンチマーキングを認めています。ここでAIは厄介になります。従来の自動化された統制は毎回同じように動作するため、誰かがコードを変更するまで基準時点の結果は有効です。ベンダーのアップデート、新しい学習データ、プロンプトの変更で挙動が変わるモデルは、監査人にその安心感を与えません。モデルとプロンプトの変更は、コードの変更と同じように扱う計画にしてください。

AIが統制環境に関わる箇所

COSOの生成AIに関する指針は、フレームワークの5つの構成要素（統制環境、リスク評価、統制活動、情報と伝達、モニタリング）にわたって統制をマッピングし、ユースケースを8つの能力タイプに分類しています。取り込み、変換、計上、オーケストレーション、判断、モニタリング、規制インテリジェンス、人とAIの相互作用です（Journal of Accountancy）。この文書には、各能力についての事例、最低限の統制の期待水準、参考となる指標が含まれています。COSOは以前にもロボティック・プロセス・オートメーションに関する補足指針を公表しており、従来型の自動化を使っている財務チームは併せて読むことができます。

次の表は、その能力の考え方を一般的な財務業務に当てはめたものです。自社の分析を整理する方法の一例であり、COSOのマッピングの写しではありません。

あらゆるAIツールについて問うべき統制設計の質問

ツールが財務プロセスに入ってきたら、どんな統制にも問うのと同じ質問に、AI特有のいくつかの質問を加えて確認します。

1. その役割は、作成者、レビュー担当者、どちらでもないのか？ 下書きをするAIは作成者です。別のAIの作業をレビューするAIは、人が結論に責任を持たない限り、SOXの意味での独立したレビューではありません。
2. 人のレビュー担当者は実際に何を確認するのか？ 「コントローラーがAIの出力をレビューする」という統制は、レビュー担当者が要約しか見ないなら弱いものです。何を見るのか、どのしきい値で詳細を確認するのか、何かおかしいときにどうするのかを定義してください。
3. 統制はどの情報に依拠しているのか？ レビュー担当者のチェックがAIの作成したレポートに依存しているなら、そのレポートの網羅性と正確性も統制の一部です。
4. 出力は再現できるのか？ 同じ入力から異なる出力が得られるなら、統制の記述にそれを明記し、ばらつきを捕捉できるようにレビューを設計します。
5. 誰が変更できるのか？ モデル、プロンプト、検索のソース、業務ルールは構成情報です。責任者と変更記録が必要です。プロンプト、検索コネクタ、変換ルールは、管理された構成として扱ってください。
6. 誤ったとき、または停止したときはどうなるのか？ 手作業による代替手段と、ツールを停止できる担当者を明確にします。

AIのためのIT全般統制

IT全般統制（ITGC）は、アプリケーションを取り巻く環境、すなわちアクセス、変更管理、運用をカバーします。AIはそれらに取って代わるのではなく、それらを拡張します。

• アクセス管理。 ツールを使える人、読み取れるデータ、書き込める内容を制限します。計上の作成と承認の両方ができるサービスアカウントは、職務分掌を1つの認証情報に潰してしまいます。PCAOBスポットライトには、AIがまさにこの種のリスクを増幅させ得るという監査人の懸念が記録されています。
• 変更管理。 モデルのバージョン、プロンプトの変更、検索のソースの変更、ベンダーのアップデートを追跡します。リリース前に非本番環境でテストします。PCAOBスポットライトは、一部の作成者が導入前に並行環境で新しい技術を稼働させていると述べており、ここでも有効な習慣です。
• 運用とモニタリング。 入力、出力、オーバーライドを記録します。ドリフトに注意してください。取引量、金額、オーバーライド率の急な変化は、挙動が変わった初期の兆候です。
• 第三者とデータのリスク。 ベンダーがモデルをホストする場合は、どんな財務データが自社の環境から出ていくのか、ベンダーがそれをどう扱うのかを把握します。スポットライトでは、機密データが公になるのを防ぐために、AIツールにアップロードできる内容に制限を設ける法人が紹介されており、財務チームも元帳データと銀行情報に同じルールが必要です。

証拠：監査人が見たがるもの

AIプロジェクトが不十分になりがちなのは証拠の面です。ツールは時間を節約するために作られ、誰も監査証跡を作らないからです。最初から計画に入れてください。スポットライトには、法人が利用した元のソースデータを記録するよう自社のAIツールを設計している例が紹介されており、御社にも同じ原則が当てはまります。

こうした統制のすべてが前提とするデータ品質の基盤については、財務データの準備で扱っています。

AIツールをSOXプログラムに組み込む手順

1. 財務におけるAIの利用をすべて棚卸しします。 個々のチームが購入したツールや、既存システム内で有効化された機能も含めます。新しい利用が絶えず現れるため、常に最新に保ってください。
2. 財務報告への影響度で区分します。 出力は重要な勘定、開示、見積りに到達しますか？ そうでないツールは、より軽いポリシーで運用できます。
3. ツールごとに責任者を割り当てます。 範囲、変更、モニタリングに責任を持つ担当者を1人指名します。
4. プロセスと統制を文書化します。 記述書とリスク・統制マトリクスを更新し、AIがどこにあり、何をし、誰がレビューするのかを示します。レビューについては具体的に書いてください。
5. 職務を分離します。 AIが同じ項目の作成と承認の両方を行ってはならず、1つのアカウントが両方の権限を持ってもいけません。
6. ITGCのカバレッジを整えます。 ツールとその構成について、アクセス、変更管理、ログ記録、ベンダーのレビューを整えます。
7. 稼働前にテストします。 数サイクルは既存のプロセスと並行稼働し、1行ずつ比較します。結果を証拠として記録します。
8. 外部監査人に早めに相談します。 統制が稼働する前に設計を共有し、年度末のウォークスルーまで待たないでください。内部監査の視点については内部監査におけるAIをご覧ください。
9. モニタリングと再テストを行います。 オーバーライド率、例外、精度を追跡します。モデル、プロンプト、データソースが変わったらテストをやり直します。

よくある落とし穴

• 「人がレビューする」ことを統制とみなす。 定義されたレビュー、しきい値、記録がなければ、テストすべき統制は存在しません。
• AIに承認を持たせる。 計上を準備したのと同じシステムによる自動承認は、いずれ発見される職務分掌の不備です。
• 構成の変更を見落とす。 プロンプトの修正やベンダーのモデル更新は、コードのリリースもチケットもなしに挙動を変え得ます。
• 台帳がない。 財務チームのシャドーAIは、存在を知らなければ評価できないリスクです。
• 後からの証拠づくり。 ログやレビュー担当者のメモは、数か月後に再現するのが困難です。統制が動いている最中に記録してください。
• ベンダーの保証が自社もカバーすると考える。 ベンダーの報告書は役立つかもしれませんが、ツールの使い方に関する統制はあくまで自社のものです。
• 不正を忘れる。 モデルは悪用や操作を受け得ます。AIが両刃の剣である点は財務における不正検知AIをご覧ください。
• 判断領域を見過ごす。 収益や見積りが中心の領域は特別な注意が必要です。判断がどこにあるかは収益認識におけるAIで示しています。

測定すべき指標

• カバレッジ： 棚卸し、責任者の割り当て、区分けが済んでいるAIユースケースの割合
• 統制のパフォーマンス： レビュー担当者が捕捉した例外、オーバーライド率、それぞれの解決までの時間
• 精度： 原資料または実績に対する誤り率（ツール別）
• 変更の規律： 承認ありで行われたモデル、プロンプト、ルールの変更と、承認なしの変更の比較
• 証拠の準備状況： 四半期末時点で、ログと最終承認が揃っている統制の割合

次に読む記事

この四半期に1つだけ行うなら、台帳を作り、各ツールが重要な勘定に到達するかどうかで区分してください。次に、最上位の区分のツールについてレビューのステップを強化し、今から証拠の記録を始めます。そのうえで、作業が移っていく中でどの統制を誰が担うのかを決め、書き残してください。