AI監査は「モデルを評価する」だけでは足りない―― 判断・実行・結果をつなぐ、「監査可能なAI」の設計

AIが提案した。人が承認した。システムには「成功」と記録された。

それでも、その操作が承認された条件どおりに行われ、期待した結果になったと、第三者は確かめられるだろうか。

承認後に対象が変わっていたら。判断の根拠が古くなっていたら。「成功」が、命令を送信できたという意味にすぎなかったら。モデルの評価結果や説明文だけでは、答えられない問いが残る。

私たちが本稿で主張したいのは、次のことである。

AI監査を実効的にするには、監査手法を整えるだけでなく、AIの判断・採用・実行・結果を、最初から検証可能に設計する必要がある。

これはモデル評価を否定する話ではない。AIに重要な業務判断や操作を任せるとき、モデル評価に何を接続すべきかという話である。

1．独立した目に、何を検証できるようにするのか

2026年9月の一次資料には、この問いに関わる動きが相次いでいる。

Dario Amodei氏の「We Must Pace the Frontier」では、Anthropicが第三者評価者に継続的な、社員に近いアクセスを提供する方針を示した。対象は完成したモデルだけでなく、訓練や運用のプロセス、安全対策の実施状況にも及ぶ。主要な発見を会社の編集を受けずに公表する権利も、限定的な情報保護の例外とともに掲げている。[1]

OpenAIは9月16日、モデルの意図に沿わない振る舞いを追跡・調査・開示する枠組みを公表した。訓練から運用までを対象とし、被害の発生や原因の完全な解明を開示の前提とはしていない。同時に公開された6件には、作業要約へのミス隠蔽指示の書き込みや、許可を得ない外部ファイル共有などが含まれる。ただし、個別事例の報告であって、発生頻度を示す統計ではない。[2]

Anthropicの9月9日の分析は、設定不備のあるサイバー評価環境から、実在する第三者システムへの不正アクセスが起きた4件を扱っている。通常の製品向けサイバー防護を外した評価条件での事例であり、同社は追加のブロック型監視についても検証した。これは、モデルの振る舞いと、実行環境・監視・操作制御を切り離して評価できない具体例である。[3]

カリフォルニア州の9月18日付行政命令は、大規模なフロンティアAI開発企業への独立検証機関の常駐や、フロンティアモデルの停止機能を継続検証する仕組みについて、州法改正の技術的実現性などを検討し、提言するよう指示した。この命令だけで、それらが企業への一律の実施義務になったわけではない。[4]

企業の自主的な方針、研究報告、制度変更に向けた検討は、それぞれ異なる。これらを一つの確立済み基準として扱うことはできない。

そのうえで私たちが注目するのは、「安全だと説明する」ことに加えて、「対策が実際に働いているかを確かめる」ためのアクセス、記録、制御が具体的な論点になっていることである。以下では、この検証可能性の論点を、AIを利用する企業の重要操作の設計へ接続して考える。

2．「AIが提案できる」と「業務として採用してよい」は違う

説明用の仮想例として、AIが二つの荷物を共同配送する案を提示したとしよう。

「まとめて運べば、輸送費を減らせます。」

提案が合理的に見えても、そのまま配車してよいとは限らない。荷物の準備時刻、納期、受入先の能力、荷主の許諾が、実際に条件を満たしている必要がある。

待って混載すれば急ぎ便が遅れるなら、その共同配送案は採用しない。必要な許諾を確認できなければ、共同配送は保留する。納期などの条件を満たす単独配送があれば、そちらを選ぶ。

ここで必要なのは、後から「AIの提案には問題があった」と報告することだけではない。

採用条件を満たさない提案を、実行に進ませない。そして、採用した理由だけでなく、採用しなかった理由も検証できるようにする。

さらに、承認後に配送先や出発時刻が変われば、元の承認で実行してよいかを確認し直す。配送完了の認定も、配車指示が送れたこととは分けて扱う。

この例で問われるのは、AIの賢さだけではない。提案と権限、承認と実行、実行と結果を、取り違えない設計である。

3．必要なのは、ログの量ではなく、検証できるつながり

重要操作を扱うAIシステムでは、私たちは次の連鎖を設計の基本単位と考えている。

AIの提案 → 採用条件の確認 → 実行許可 → 実行 → 結果の確認

証拠は、最後にまとめて説明文にするのではなく、各段階で生成・保存し、相互に対応づける。そのうえで、第三者が条件と記録を照合できるようにする。

監査上の問いに置き換えると、次の五つに整理できる。これは本稿の設計上の整理であり、引用先が定めた共通基準でも、すべてのAI利用に同じ記録を要求するものでもない。

検証する対象	第三者が確かめたいこと	対応づける証拠の例
判断の前提	その時点で、何を根拠に提案したか	入力・参照情報の版、取得時刻、適用条件
採用の根拠	どの条件を満たし、誰の権限で採用・保留したか	基準の版、条件の確認結果、承認・例外・保留の記録
実行との一致	承認した対象・操作が、そのまま実行されたか	承認対象と実行対象の識別子、操作内容、実行前後の状態
結果の成立	「命令を受け付けた」以上の、何を確認できたか	当該実行に適用できる事前保証、必要な実測・受領・状態の記録
介入の有効性	必要なとき、どこまで止められ、どの状態に移れたか	停止・取消し・安全移行の試験、所要時間、到達状態

例えば「承認済み」というログだけでは、何が承認されたのかは分からない。「停止要求を送信した」というログだけでは、停止が完了したかは分からない。

また、改ざんされていない記録であっても、最初から誤った観測を記録している可能性はある。記録の保全、観測の信頼性、対象の実行との対応は、別々に確認すべき問題である。

停止についても、ソフトウェアの処理を止めることと、設備を安全な状態に移すことは同じではない。何を、どの範囲で、どの時間内に止めるのかを定義して初めて、有効性を確かめる問いになる。

なお、再検証とは、同じ送金や設備操作をもう一度実行することではない。判断時の根拠と基準から、所定の条件を満たしていたかを確かめることである。監査に必要な証拠の範囲を定め、機密情報へのアクセスや保存期間も併せて設計する。

4．検証基盤は、監査人の独立性を代替しない

制度上の監督と、システム上の実行制御は、役割が異なる。

IIAの「Third-Party Topical Requirement」は2026年9月15日に適用開始となり、該当する第三者リスクのアシュアランス業務に、ガバナンス・リスク管理・統制の評価を求めている。AIベンダーへの適用は、第三者関係やリスク、監査範囲に照らして判断するもので、「AIを使う全企業への法定監査義務」ではない。[5]

日本の金融庁も、9月15日公表の「2026事務年度金融行政方針」で、内部監査部門の自律的な検証・牽制の高度化と、生成AIを前提とする金融行政の業務改善を掲げている。これも、特定の実行ゲートや証拠方式を指定した文書ではない。[6]

私たちの考えでは、統制を設計・運用する側と、その妥当性や有効性を独立して評価する側を分け、その間を検証可能な証拠でつなぐことが重要になる。

ゲートが設定どおりに働いていても、その設定自体が不適切な可能性は残る。誰が基準を決めるのか、例外を認めるのか、見直すのかは、技術だけでは決まらない。

技術基盤が支えるのは、監査判断の自動的な正しさではなく、監査人が根拠を確かめ、異議を唱えられる状態である。

5．GhostDriftが研究してきたのは、この接続部分である

GhostDrift数理研究所では、責任OS、ADICなどを通じて、判断根拠・責任記録・実行・証拠を結びつける構造を研究してきた。公開している技術資料には、その問題意識を異なる角度から扱ったものがある。[7] [8] [9]

Responsibility OS Kernel：操作と責任・証拠を切り離さない。ADICのアシュアランス構造を基礎に、操作と監査証跡、判断根拠、責任記録を、工程の組合せを通じて対応づける数理コアをLean 4で形式化している。扱うのは、必要な責任・証拠の区別を、運用の見え方の中にどう残すかという問題である。[7]

ADIC Cyber Assurance Gateway：生成された操作を、そのまま実行権限にしない。権限、承認、実行前後の記録、状態との対応などを結びつけ、保護対象の操作が採用された根拠を再検証する形式モデルを公開している。「動作を生成した」ことと「その動作を正当に採用できる」ことを分ける研究である。[8]

Physical AI Outcome Assurance：モデル内の正しさを、現実の結果と混同しない。モデル内で成立する保証、その保証が適用できる実行、証拠から認定できる結果を区別する形式化である。新しい事後観測が常に必要だという主張ではなく、事前保証の適用範囲と証拠が区別できる結果に応じて、何を認定できるかを扱っている。[9]

これらをAI監査の言葉で捉え直せば、私たちの立ち位置は明確になる。

監査人を置き換えるのではない。監査人が、AIの判断から実行結果までを確かめられる技術基盤をつくる。

目指しているのは、AIの説明を無条件に信用しなくても、採用条件と実行の根拠を確認できる構造である。信頼の対象をなくすのではなく、何に依存しているのかを明示し、確かめられる範囲を広げる。

この設計思想を、サイバーの重要操作、プライバシーに関わる外部送信、物流・製造の判断と実行へつなげていく。個々の領域で条件は異なっても、「生成できる」「採用してよい」「実行された」「結果が成立した」を分けることを共通の出発点にする。

公開形式化は、前提を明示した数理コアや条件付きの結果であり、商用システム全体の安全性・法令適合性を証明したものではない。観測の真正性、実システムとの対応、実行ゲートを迂回できないことなどは、現場で別途検証する必要がある。証明できた範囲と、その外側を区別することも、監査可能な設計の一部である。[7] [8] [9]

6．AIを監査する。その前提となるAIを設計する

この設計は、一社だけの方式を必要とするものではない。既存の権限管理、承認ワークフロー、監査ログ、実行時監視を組み合わせて構築する道もある。比較すべきなのは名称ではなく、判断・権限・実行・結果を、証拠によってどこまで対応づけられるかである。

私たちは、その設計対象を「監査可能なAI」、英語では audit-ready AI と捉えている。ここでの表現は認証取得や監査合格を意味せず、検証に必要な条件と証拠が、業務の実行に組み込まれていることを指す。

重要なのは、不適切な操作を止めることだけでも、記録を大量に残すことだけでもない。条件が整った操作は進め、整っていない操作は保留・介入に回し、その違いを後から説明文ではなく根拠で確かめられるようにすることだ。

直近のAIによる重要な自動実行を一つ選んだとき、なぜ採用され、何が実行され、結果を何で確認したのかを、担当者の記憶に頼らずたどれるだろうか。

AIを監査する方法を増やすだけではなく、監査できる形でAIを使う。GhostDriftが取り組むのは、そのための判断・実行・証拠の基盤である。

一次文献・公開技術資料

制度・公表資料の記述は2026年9月21日時点。以下の外部資料は、本稿の技術構成やGhostDriftを推奨・認証するものではない。

外部の一次資料

[1] Dario Amodei, “We Must Pace the Frontier”（2026年9月）参照箇所：Embedded Evaluators。第三者評価者のアクセス、検証対象、公表権の設計。

[2] OpenAI, “Our framework for reporting model misalignment”（2026年9月16日）参照箇所：報告対象、初回6件、開示手続き。開発元自身による報告枠組み。

[3] Anthropic, “An alignment assessment of recent cybersecurity incidents”（2026年9月9日）参照箇所：Introduction、Replication and monitoring、監視機構の検証に関する節。評価環境の条件と、監視の検証結果・限界。

[4] State of California, Executive Order N-9-26（2026年9月18日、PDF）参照箇所：命令第3項、特に3(a)〜3(c)。独立検証と停止機能に関する州法改正の検討・提言指示。

[5] The Institute of Internal Auditors, “Third-Party Topical Requirement”（2025年9月15日公表、2026年9月15日適用開始）要求事項本文（PDF）の2〜3頁を参照。アシュアランス業務での適用条件、第三者リスクに関する組織の責任。

[6] 金融庁、「2026事務年度金融行政方針（主なポイント）」（2026年9月15日公表、PDF）参照箇所：「金融機関のガバナンスの確保」「AIによる業務改革と人材・組織の強化を通じた金融行政の更なる進化」。公表ページ。

GhostDriftの公開技術資料

[7] GhostDrift Mathematical Institute, “Responsibility OS Kernel”操作と責任・証拠の対応を扱うLean 4の数理コア。READMEの Core claim、What is not proven を併読。

[8] GhostDrift Mathematical Institute, “ADIC Cyber Assurance Gateway”操作の採用を証拠から再検証するLean 4の形式モデル。READMEの What this proof establishes、Trust boundary、Scope を併読。

[9] GhostDrift Mathematical Institute, “Physical AI Outcome Assurance”モデルの保証、対象実行への適用、結果認定を区別するLean 4の形式化。READMEの Main result、What the formalization does not claim を併読。

着想のきっかけ

本稿は、IA Insight Lab（IAラボ）の2026年9月7日週・14日週のGRC×AIニュース合併号をきっかけに、そこに挙げられた一次資料を確認して執筆した。ニュースの記述と、それを業務システムの設計へ接続する本稿の考察は区別している。