この記事で伝えたいこと
- 内部統制の評価は「整備状況」と「運用状況」の二段階に分かれる。ルールが設計されていることと、そのとおりに動いていることは、制度上、別の事実として扱われる。
- AIガバナンスは新しい概念ではない。内部統制の対象範囲に、AIが加わっただけだ。
- AIは「確認しました」と書ける。確認していなくても。嘘ではない。確認の定義が、人間とずれているだけだ。
- ルールは、無いから死ぬのではない。「ここは重要でない」という例外判断によって死ぬ。
- チェックリストの正しい形は「規程はあるか」ではない。「実際に叩いて、出力を見たか」だ。
「確認済み」と書いてあった。しかし、動いていなかった
自社の話から始めます。
当社のInsights記事には、構造化データを埋め込んでいます。検索エンジンや生成AIに対して、これは記事で、著者は誰で、いつ公開され、どんな質問と答えが載っているかを、機械が読める形で伝えるものです。生成AIに引用されることを狙った設計の、中核にあたります。
設計書には「確認済み」と書かれていました。AIに検証させ、その報告を記録したものです。
先日、生成AIに引用されるための施策が実際にどう機能しているかを調べていて、構造化データがどう登録されているかを確認しようとしました。
反映されていませんでした。記事11本すべて、1ヶ月以上にわたって、1件も出力されていませんでした。
原因は拍子抜けするほど単純でした。データを入れる「器」の要素と、データを持つ属性が、テンプレート上で別々の要素に分かれていた。器にはIDが付いているが中身が空。中身を持つ要素にはIDが付いていない。仕組みはIDで器を探すので、いつも空の器を読んで、そこで止まっていました。
片方だけでは、何も動かない。しかし、どちらも「存在している」ようには見える。
誰も嘘をついていない。それが厄介なところだ
ここで大事なのは、誰も嘘をついていないということです。
AIは「確認済み」と書きました。おそらく、コードを読み、処理の流れを追い、正しく動くはずだと判断した。設計上は、確かに正しかったのです。仕組そのものには何の問題もありませんでした。問題は、その仕組が前提としている要素が、テンプレート側に存在しなかったことです。
AIは、コードを読んで「確認」しました。私が期待していた「確認」は、公開されたページを実際に開いて、出力を見ることでした。この2つは違います。
そして、AIが書いた「確認済み」という 3文字は、どちらの意味でも成立します。文章としては完璧です。読んだ人間は、後者の意味で受け取ります。
私はそれを読んで、確認されたと理解しました。そこで思考を止めました。
AIが間違ったのではありません。AIの報告を、私が証跡として扱った。これが今回の落ち度です。
AIは「確認しました」と書ける。確認していなくても。それは嘘ではない。確認の定義が、人間とずれているだけだ。
内部統制は、整備と運用を分けて評価する
私は上場企業のCFOをで11年務めました。内部統制監査を、受ける側にいた立場です。
日本の上場企業には、内部統制報告制度があります。制度上の対象は「財務報告に係る内部統制」です。その中にはIT全般統制という領域があり、ここでアクセス権限の管理、システムの変更管理、データの処理、バックアップ、外部委託の管理が見られます。
監査の手順はこうです。まず、規程、業務フロー、業務記述書といった文書一式を提出します。監査人はそれを読み、統制がどう設計されているかを把握します。
内部統制の評価は、制度上、二段階に分かれています。
整備状況の評価。 ルールが、リスクに対して適切に設計されているか。文書を読み、担当者に話を聞き、業務の流れを一件、最初から最後までたどります。実際に一件追いかけて、設計が機能しうるかを見ます。
運用状況の評価。 そのルールが、実際にそのとおり運用されているか。ここでは文書を読みません。一定期間の処理からいくつか抜き出して、実際の伝票や記録と突き合わせます。承認が誰の手で行われているか。権限のない人が処理していないか。ログが残っているか。
そして、整備状況が良好でも、運用状況に不備があれば、内部統制の不備と評価されます。
ルールがあることと、ルールが動いていることは、別の事実である。だから制度は、その2つを分けて評価するようになっています。
内部統制の制度は、20年前から「ルールが設計されていること」と「そのとおり動いていること」を分けて評価してきました。アクセス権限、データ処理、バックアップ、外部委託。この記事で扱う項目は、すべて以前から監査対象です。AIガバナンスは新しい概念ではありません。内部統制の対象範囲に、AIが加わっただけです。
ルールは、無いから死ぬのではない
規程が形だけになっていく過程には、決まった型があります。私が見てきたのは、2つです。
ひとつは、成長している会社で必ず起きます。
ベンチャー、スタートアップ、事業拡大期の会社。当初、規程もルールもマニュアルも業務フローも作りました。しかし半年、10ヶ月と業務を回し、拡大していく。部署異動があり、配置転換があり、拠点が増える。現場は業務を最適化するため、変更に次ぐ変更を加えていきます。
そして、その変更はどこにも記録されません。ルーチンでない業務では、その意識が働かない。だから業務は、静かに規程を逸脱していきます。
もうひとつは、属人化した部署で起きます。
ひとりが複数の業務を兼務している。すると、その人に権限が集中します。処理する人と、それをチェックする人が同一になる。ルールがあっても、無いのと同じ状態になります。
内部統制で職務の分離が重視されるのは、この構造を防ぐためです。そして中堅企業では、人が足りないという理由で、これが日常的に起きています。
- 事業拡大に伴い、現場が業務を最適化していく
- 部署異動・配置転換・拠点増加で運用が変わる
- ルーチンでない業務では、規程を意識する機会がない
- 変更を管理部門に報告する経路がない
- 規程は残るが、業務は別のものになっている
- 人手不足により、ひとりが複数業務を兼務する
- 処理する人とチェックする人が同一になる
- 職務の分離が成立しない
- ルールはあるが、それを守らせる第三者がいない
- その人が異動・退職すると、何も残らない
私の落ち度は、AIを信じたことではない
冠頭の話に戻ります。
当社では普段、AIの出力を検証しています。調査で誤引用や解釈のずれが起きることを警戟しているからです。知らないことが出てきたときは、必ず出所とデータの中身を社内で確認する。そのルールは、あったのです。
では、なぜ今回は動かなかったのか。
社外への影響が全くない作業だったからです。社内的な内容で、重要度も高くない。処理も作業も難しくない。システム上で一括処理できる。そしてAIが品質管理の最終確認をして、報告書に「不備なし、完了」と書いていた。
だから誰も疑わず、再検証もしませんでした。
落ち度は、AIを信じたことではありません。「これは重要でない」と判断して、検証のルールを適用しなかったことです。
そして、その判断自体が間違っていました。構造化データは、生成AIに引用されるための施策の中核でした。重要度が低いと思ったから検証しなかった。低くなかった。
かなり手前の話で、section-04で挙げた2つの型と同じ構造だと気づきます。ルーチンでない業務だったから、ルールを意識する機会がなかった。そしてその作業は、判断も検証も担当者一人に集中していました。職務の分離が、そもそも成立していなかった。
その状態を放置していたのは、私です。
叩いて、出力を見る。7つの確認手順
記事12で、AIのルールを書く前にアクセス権と持ち出し経路の棚卸しをすべきだと書きました。この記事は、その次の段階です。棚卸しをして、ルールを作った。では、それが生きているかをどう確かめるか。
内部統制でいう「運用状況の評価」を、AIガバナンスに当てはめたものが、以下です。
書類を見るためのチェックリストではありません。実際に手を動かして、出力を見るための手順です。システムが多くなければ1時間かかりません。
- SaaSのユーザー一覧を開く。同じメールアドレスや部署名アカウント（info@、sales@ など）でログインしているものが無いことを、目で見て確認する
- 顧客の個人情報が入っている全システムで、エクスポート権限を持つアカウントを一覧表示する。想定より多ければ、そこが穴
- 生成AIの法人契約の管理画面を開き、ライセンス保有者と、実際にログインしている人数が一致しているか確認する
- 過去1週間の利用ログを、今この場で出せるか試す。出せなければ、記録は取れていない
- 削除要求のテストを1件、自分で流す。プラットフォームが自動で消す範囲と、手で追いかけた範囲を書き出す
- 連携している外部サービスを１つ選び、そこに顧客データが残っていないかを実際に見に行く（バックアップを含む）
- 上記の実行結果を、画面のスクリーンショットまたはログとして残す。「確認した」という文章ではなく、出力そのものを残す
AIに「確認した」と書かせない
今回の一件から、当社の運用を１つ変えました。
AIに検証作業を依頼してよい。ただし、その結果を「確認済み」という文章で受け取らない。出力そのものを出させます。実行結果、ログ、画面のスクリーンショット。文章での報告は、証跡として扱いません。
これは、AIを信用しないという意味ではありません。人間の報告も、同じように扱うべきだからです。「確認しました」という言葉は、人が言っても同じ曖昧さを持ちます。監査人が規程集ではなく記録を求めるのは、人間を疑っているからではない。報告と記録は、そもそも違う種類の情報だからです。
AIの登場で新しくなったのは、報告を生成するコストがゼロになったことです。それだけでなく、瞬時に大量に手に入る。だからこそ、記録を求める規律が、以前より重要になっています。
ルールを作った日が、ゴールではない
AIガバナンスの相談を受けると、多くの場合「ルールを作りたい」という話から始まります。正しい出発点です。ただ、ルールを作った日はゴールではありません。その日から、動いているかを確かめる仕事が始まります。
そして確かめる方法は、報告を読むことではない。叩いて、出力を見ることです。
当社は、AIガバナンスを支援する会社です。その会社が、AIの生成物を検証せずに信じていました。この記事を書くのは、決まりが悪い。ただ、この失敗を隠したまま他社にガバナンスを説く方が、はるかに悪いと思っています。
同じことは、どの会社でも起きます。起きたときに気づける仕組みがあるかどうか。差はそこにしかありません。
Japan Consultingは、AIガバナンス診断において「規程があるか」ではなく「実際に叩いて出力を見たか」を確認します。内部統制でいう運用状況の評価にあたる部分です。当社自身が、AIの報告を証跡として扱って失敗しました。その経験を含めて、記録が残る運用への移行を伴走します。
この記事に関するFAQ
本記事は、筆者が上場企業のCFOとして11年間、内部統制監査を受ける側にいた経験、および自社Webサイトで実際に発生した不具合（2026年7月）をもとに構成しています。内部統制の評価が「整備状況の評価」と「運用状況の評価」に分かれること、およびIT全般統制がアクセス権限・変更管理・データ処理・バックアップ・外部委託を対象とすることは、金融商品取引法に基づく内部統制報告制度の枠組みによります。制度の対象は財務報告に係る内部統制であり、本記事はその考え方をAIガバナンスに応用したものです。日本企業の生成AI活用方針の策定率は、総務省「令和7年版 情報通信白書」（2025年）を参照。活用方針を定めている企業は49.7%、企業規模別では中小企業において「方針を明確に定めていない」が約半数を占める。解釈・考察は筆者による。
