内部監査・内部統制のAI活用｜18用途・J-SOXと全件分析の確認点

内部監査・内部統制でAIを使う場合は、資料の収集や下書き、異常の候補の抽出と、監査人が根拠を評価して結論を出すことを分けます。全件データを処理できても、すべての不正を発見したことや、内部統制が有効であることの証明にはなりません。本記事は18の活用候補、J-SOXとの関係、構成とツール選定、導入・運用の確認点を整理します。

内部監査・内部統制とJ-SOX：AIを使う場合も責任と根拠を明確にする

内部統制の整備・運用、経営者による評価、内部監査、外部監査は、関係しながらも役割が異なります。AIを使う目的も、監査人の作業を支援することと、業務部門がAIを使う際の統制を評価することでは違います。「AI監査」という言葉だけで対象を決めず、誰が何について判断し、どの証拠を使うかを定めます。

J-SOXとして扱う内部統制報告制度では、財務報告に係る内部統制の評価・報告と監査を確認します。企業会計審議会は2023年4月に基準等の改訂を公表しました。公式説明では、リスクに基づく評価範囲の決定や、内部監査人の報告経路等が示され、改訂は2024年4月1日以後開始する事業年度の評価・監査から適用されています。金融庁：改訂意見書の公表／企業会計審議会：改訂内容と適用時期の説明

基本的な内部統制の目的の一つが「報告の信頼性」へ広がったことと、J-SOXの評価・監査の対象が自動的にすべての非財務情報へ広がることは区別します。AIを導入しただけで、制度対応が終わったり、評価範囲を一律に決められたりするわけではありません。自社の対象と重要性、適用する制度・基準を対応付けて確認してください。

IIAの現行案内は、内部監査の役割を独立した、リスクに基づく客観的な保証・助言等として説明しています。Global Internal Audit Standardsは2025年1月9日に適用開始となっています。AIを使えば独立性が担保されるとはせず、監査機能の位置付け、報告経路、不当な影響を受けない判断、利益相反への対応を整えます。IIA：現行の専門職基準と内部監査の目的

例えば、AIの抽出ルールを設計・運用する担当と、その仕組みの妥当性を評価する担当の関係を確認します。出力に人が目を通すだけで客観性や証拠の十分性が保証されるわけではありません。使用したデータ、手続、例外、追加調査、判断した理由と承認者を残し、別の担当者が内容を追えるようにします。

COSOは「Achieving Effective Internal Control Over Generative AI」で、生成AIに伴うリスクと統制を扱うガイダンスを公表しています。紹介ページは、プロンプトによる操作、モデルの変化、頻繁な設定変更等にも触れています。これはAI利用そのものへの統制を考える資料であり、監査作業をAIで自動化すれば内部統制が有効になるという認定ではありません。COSO：生成AIと内部統制のガイダンス紹介

全社の目標とリスク、部門間の依存関係から対象を整理する段階は、ERMとCOSO・ISO 31000の使い方にもつながります。経営のリスク管理、業務の統制、内部監査を一つの自動処理へまとめず、それぞれが何を実行し、何を評価するかを明らかにしましょう。

六分野・18の活用候補：生成・検知した内容を確認して使う

以下は、本稿が整理する活用候補です。すべての製品が対応している機能や、実証済みの削減効果の一覧ではありません。情報の整理・下書き・例外抽出へ用途を分け、確認者と根拠を対応付けます。判断の重要性が高いものほど、出力をそのまま採用せず、確認手続と権限を先に設計します。

A. 監査計画・リスク評価の三用途

用途	AI等による支援の候補	人が確認すること
1. リスク評価の補助	過去の指摘、業務や組織の変更から評価材料を整理する	情報の偏り、重要性、評価根拠。点数だけで監査対象を決めない
2. 監査計画の下書き	対象、手続、必要な資料・工数の案を作る	監査目的、実施可能性、必要な技能と承認
3. 規制・業界情報の確認支援	公表資料や変更候補を集め、差分を示す	原文、施行・適用時期、自社への関係。見逃しゼロとはしない

B. 統制テスト・継続監査の四用途

用途	支援の候補	人が確認すること
4. 対象データの全件分析	取得した取引等へ定義したルールを適用する	母集団の完全性、ルールの対象と限界、処理漏れ
5. 取引・経費の異常候補	重複や通常と異なる値を抽出する	正当な例外か、誤り・不正の疑いか。異常だけで不正と断定しない
6. 権限・職務分掌の点検	権限台帳と操作ログを照合する	承認済みの役割と例外、権限を持つことと実際の操作の違い
7. 継続的な状況の可視化	統制の実施状況や未確認事項を集計する	更新時点、欠測、確認担当。画面の更新だけで監査完了としない

C. 統制文書化・規程管理の三用途

用途	支援の候補	人が確認すること
8. RCMの更新案	変更資料からリスク・統制の見直し候補を作る	業務の実態、変更の承認と実施、既存の統制との対応
9. 規程の整合性確認	承認者や手順の記載が異なる箇所を示す	対象範囲、例外条項、版と優先関係。違いをすべて矛盾としない
10. 業務記述書の下書き	既存資料や確認済みの記録を文書化する	記録に表れない手作業、担当者確認、根拠と記述の一致

D. 調書・報告書の三用途

用途	支援の候補	人が確認すること
11. 監査調書の下書き	実施記録を指定様式へ整理する	未実施の手続や存在しない証拠を補っていないか
12. 指摘事項の分類	対象や影響の候補を付け、関連する発見事項をまとめる	重要性、根拠、重複、対応する部門と期限
13. 監査報告書の下書き	調書と是正状況から報告案を作る	結論と証拠の関係、留保、未確認事項と承認

E. 不正・インシデント対応の三用途

用途	支援の候補	人が確認すること
14. 検知ルールの見直し	過去の評価結果から変更案を作る	誤検出と見逃し、過去への過適合、変更前後の試験
15. 通報・報告の整理	報告内容を分類し、確認先の候補を示す	秘密保持、通報者への配慮、緊急性と送信の許可
16. 調査資料の検索支援	許可された資料の検索・時系列整理を補助する	取得権限、原本と取得経緯の保全、要約の欠落。要約を原証拠と混同しない

F. ナレッジ・組織運用の二用途

用途	支援の候補	人が確認すること
17. 監査ナレッジの検索	過去の指摘や規程を根拠付きで探す	資料の版、アクセス権、他案件との混同、該当資料がない場合の扱い
18. 委員会向けの要約	主要リスク、統制、指摘、是正状況をまとめる	報告対象と期間、重要事項の省略、未確認と対応済みの区別

どの用途も、処理速度だけでなく、確認・修正の時間、根拠へ戻れる割合、重要な誤りや見逃し、利用を続ける負担を評価します。少人数なら必ず効果が大きい、検索が一定秒数で終わる、監査人は結論の編集だけでよい、といった前提は置きません。対象の業務を小さく選び、従来の進め方と比較して採用を判断します。

全件分析と三層構成・ツール選定で確認すること

全件分析の「全件」は、何を母集団として取得したかで意味が変わります。会計上の対象取引と抽出した行数・金額を照合し、取消、修正、欠損、重複、期間境界を確認します。取得できた行へルールを適用しても、未取得のデータやルールが扱わないリスクまで検証したことにはなりません。ルールでの照合は、生成AIを使わずに行える場合もあります。

業務部門による継続的なモニタリングと、内部監査が独立した立場で行う評価を区別します。日次でアラートを出すことだけで、継続監査として十分な手続を行ったとは言えません。通知の正誤と見逃し、対応の根拠、実施した手続と未実施の範囲を記録します。内部監査で得た分析を外部監査人が利用できるかや、監査報酬への影響も、自動的には決まりません。

データ・分析・監査業務の三層で責任を対応付ける

構成の整理例	扱う内容	設計時に確認すること
L1：データ	会計、権限、業務記録、規程などの取得と対応付け	元資料、完全性、版、保存・削除、権限
L2：分析・生成	ルール照合、異常候補、検索、要約、分類	対象と限界、根拠、形式・内容の検証、変更履歴
L3：監査業務	計画、調書、発見事項、是正確認、報告	実施・レビュー・承認の担当、判断と証跡、保留時の扱い

この三層は本稿の整理方法で、法定のシステム構成ではありません。監査人がどこで確認し、どの成果物を使うかから逆算し、必要なデータと処理を決めます。既存の表計算や監査管理ツールを生かす案と、画面を見直す案の両方を試し、「専用画面は必ず使われない」「既存ツールへ追加する方法が最速・最安」と決めつけないようにします。

ツールは、分析と証拠・承認管理の役割で比較する

候補の種類	役割の例	選定時の確認
監査・GRC管理	計画、調書、テスト、発見事項と報告の管理。Workivaの公開資料等が例	自社の様式・承認、証拠の履歴、権限、既存システムとの連携
監査データ分析	取引の全件分析、例外抽出、反復可能なテスト。Caseware IDEA等が例	取込形式、対象データとの照合、分析の再現、記録と出力
ワークフロー・RPA	資料収集、確認依頼、処理の受け渡しを設計する	例外処理、権限、失敗と再実行、対象外の手作業
汎用LLMと個別実装	資料の検索、分類や文章の下書きを業務へ組み込む	モデル・契約・データ条件、評価、保守、証拠管理との接続

Workivaの公開企業資料は、監査計画や調書・テスト・発見事項・報告の管理を説明しています。資料は製品の役割を知る参照点で、現行の料金や全機能の契約上の提供保証とはしません。CasewareのIDEA製品ページも、母集団の分析や例外の抽出、繰り返すテストと実行履歴を紹介しています。地域・版・追加機能を含む条件は、利用する契約で確認してください。

比較では、ライセンスだけでなく、データ整備、連携、検証、監査人の確認、保守と移行を含む総費用を見ます。製品がAI機能を持つことと、自社の監査目的やJ-SOXの要件を満たすことは別です。デモ用のデータで動くかに加え、実際の例外、権限の異なる利用者、失敗時の処理を確認しましょう。

導入と運用：七つの確認原則と90日を目安にした検証計画

本稿が提案する確認原則は七つです。①監査の目的と成果物から設計する、②小さい範囲で効果と負担を測る、③既存ツールとの接続・変更を比較する、④根拠と処理・判断の履歴を残す、⑤データと権限を管理する、⑥重要な判断を人が行い例外を引き継ぐ、⑦変更後に再評価する、という考え方です。これらを置くだけで、独立性や制度適合が保証されるものではありません。

例えば調書の下書きから試す場合、資料の入力から確認・修正・承認までの時間を測ります。出力の文章が自然でも、未実施の手続を実施済みと書く、重要な例外を落とす、別案件の証拠を引用するといった誤りを検証します。AIの自信度が高い出力を、正しいとみなす条件にはしません。影響と業務上の判断に合わせて確認を設けます。

90日という期間は、本番化やROIを保証する期限にしない

次は90日を仮に置いた計画例です。各段階で継続・修正・中止を判断し、権限やデータの整備が終わっていなければ次へ進めません。本番展開の時期は、監査日程、情報の取得条件、確認者と連携範囲に応じて見積もります。

期間の例	行うこと	次へ進む前に確認すること
1〜14日	目的・対象・役割と現状の負担を整理	対象外、判断者、比較する指標が合意されている
15〜30日	資料と取得・保存条件を整える	利用権限、版、元資料との照合、機密情報の扱い
31〜45日	小さい範囲の試作と評価	既知の誤り・例外・根拠の検証結果
46〜60日	調書や既存管理への受け渡しを試す	承認、履歴、失敗・再実行、アクセス範囲
61〜75日	利用者を絞って試用し、従来と比較	確認・修正を含む時間、品質と運用負担
76〜90日	採用範囲と残課題、運用・引き継ぎを判断	展開条件、責任者、再評価と停止・復旧の方法

機密データと技術的な弱点の確認を、監査判断と対応付ける

外部のAIを使う場合は、送信する情報、利用目的、保存・削除、学習利用、ログ、委託先、管理者と閲覧者の権限を、実際の契約と設定で確認します。BYOKという用語だけでログ保持がなくなったり、閉域やオンプレミスという構成だけで安全になったりするわけではありません。要約や出力にも機密情報が含まれ得るため、保存先と共有先まで対象にします。

システムの認証・権限や外部との接点に関する技術検証は、脆弱性診断と侵入テストの目的・範囲を整理して進めます。renueのAI脆弱性診断支援サービスでは、合意した範囲でのコード分析や侵入経路の検証、影響と改善方法の報告、別途合意した改修・刷新を相談できます。これはJ-SOXの監査意見や、内部統制全体の有効性を認定するサービスとは役割を分けて検討します。

用途の優先順位、経営と現場の合意、実行計画と評価指標を整理する場合は、コンサルティングへ相談できます。監査人、IT、業務の担当者が、実施した処理と得られた証拠、残る課題と判断を共有できる状態を目指します。品質やカバレッジの倍増、一定期間での回収、監査報酬の削減を根拠なく約束せず、試行で確認した範囲から進めます。