AI監査とは？導入判断・評価との違い・実務手順とチェックリスト

AI監査とは、AIの出力だけを採点することではありません。どの業務に、どのAIを、どのデータ・権限・人の確認と組み合わせて使っているかを対象に、あらかじめ決めた基準と証跡で確認し、問題があれば是正し、再確認する仕組みです。

生成AIやAIエージェントでは、同じモデルでもプロンプト、参照文書、接続するツール、権限、利用者、業務上の意思決定によってリスクが変わります。そのため、「モデルのベンチマークが高い」「PoCで一度うまく動いた」だけでは、運用可能とは判断できません。

本記事では、AI監査を導入可否と運用継続を判断するための実務として扱います。手順、監査観点、チェックリスト、記録テンプレートは、特記のない限りMojiによる実務上の提案です。法令適用、契約上の義務、認証取得の必要性は、対象国・業界・取引条件で異なるため、法務・情報セキュリティ・個人情報保護の担当者と確認してください。

結論：AI監査は「モデルの点数」ではなく「業務で許容できる失敗か」を確かめる

経営・事業の責任者が最初に決めるべきなのは、AIに高得点を求めることではなく、何が起きたら使わせないかです。たとえば、顧客へ誤案内する、閲覧権限のない文書を参照する、未承認のメールを送る、金額や契約条件を確定する、といった失敗は、単なる文章品質の低下とは別の扱いが必要です。

NISTのAI RMF 1.0は、AIリスク管理をGOVERN（統治）・MAP（文脈とリスクの把握）・MEASURE（測定）・MANAGE（対応）の4機能として整理しています。特定の製品を選ぶための一律チェックリストではなく、用途や組織のリスク許容度に応じて運用する枠組みです。 NIST AI RMF 1.0

本記事でいうAI監査は、この4機能を、個別のAIシステムや業務単位で「証跡を確認できる状態」に落とし込む活動です。

AI監査とは：評価・リスク管理・セキュリティレビューとの違い

AI評価だけで終わらせないことが重要です。評価で正答率が高くても、評価対象が実際の利用者・入力・例外を含んでいなければ、実運用のリスクは残ります。反対に、厳しい権限や承認を設けても、業務品質を測っていなければ、実用性を判断できません。AI監査では両方を確認します。

評価指標の作り方や、最終回答だけでなく検索・生成を切り分ける考え方は、AIの評価とは？評価指標や評価方法、その費用について、RAGを対象とする場合はRAG評価データセットの作り方｜設計・作成・品質確認・更新を実務手順で解説も参照してください。

監査が必要になりやすいAIの条件

すべてのAI利用に同じ重さの監査は必要ありません。Mojiでは、次の4軸で対象を仕分けることを提案します。

生成AIには、もっともらしい誤情報を自信ありげに提示する「confabulation（一般にハルシネーションとも呼ばれる）」が起き得ます。NISTは、利用者が誤った出力を信じて行動・拡散することがリスクになるとしており、重要な意思決定に組み込む場合は特に監視が必要だと説明しています。 NIST AI 600-1: Generative AI Profile

したがって、社内文書の下書き補助と、顧客へ自動送信する問い合わせ対応エージェントを同じ監査深度で扱うべきではありません。外部への影響、扱うデータ、取り消しやすさに応じて、確認項目・承認者・実施頻度を増やします。

監査の深さを選ぶ3段階の目安

以下は法令上の分類ではなく、監査投資を決めるためのMojiによる設計目安です。実際の結論は、利用するモデル、入力データの品質、評価指標、許容誤差、業界規制、契約条件によって変わります。

NIST AI RMFは、AIシステムを導入前にテストし、運用中も定期的にテストすること、また独立したレビューが内部バイアスや利益相反の緩和に役立ち得ることを示しています。ここでいう「独立」は必ずしも外部委託を意味しません。開発・導入の直接責任者だけで完結させず、別の権限・視点を持つ担当者が確認できるようにする、という設計です。 NIST AI RMF Core

AI監査の実務手順：6ステップ

1. 監査対象を「AIツール名」ではなく「業務の一場面」で定義する

「社内でChatGPTを使っている」を監査対象にしても、範囲が広すぎて結論を出せません。対象は、誰が、何の入力を使い、何を出力し、次に誰が何をするかで切ります。

• 対象業務：例）サポート担当が、社内の製品手順書を検索して回答案を作る
• 利用者：例）サポート担当者のみ
• 入力：質問文、顧客情報の有無、参照文書
• 出力：回答案、引用、エスカレーション判定
• 禁止する操作：顧客への自動送信、返金確定、契約条件の確定
• 業務上の最終責任者：例）サポート部門長

AIが外部ツールを操作する場合は、AIの回答だけでなく、委任する権限、承認、停止、監視を対象に含めます。設計の詳細はAIエージェントのガードレール設計｜暴走を防ぎながら自動化を進める権限・承認・停止・監視の実務ガイドを参照してください。

2. 監査基準を「守るべき結果」と「確認方法」の組にする

「安全に使う」「精度を高める」だけでは、監査で判定できません。基準は、観察可能な状態に置き換えます。

日本では、経済産業省が公開するAI事業者ガイドライン第1.2版に、ガイドライン本編のほか、チェックリストとワークシートを掲載しています。自社の監査基準をゼロから作る前に、開発者・提供者・利用者のどの立場に当たるかを確認し、必要な観点を抜き出す出発点として使えます。 経済産業省：AI事業者ガイドライン（第1.2版）

3. AIシステム台帳とデータフローを作る

監査で最も起きやすい抜けは、チャット画面の外側です。モデル名だけでなく、検索、OCR、埋め込み、ログ、分析ツール、外部SaaS、管理者権限、バックアップまで追います。

最低限、台帳へ入れる項目

• システム名・業務名・オーナー・技術オーナー
• モデル、モデル提供者、モデルバージョン、利用リージョン
• 入力データの分類、保管先、外部送信の有無
• 参照データの正本、更新責任者、権限の継承方法
• ツール実行の種類、書き込み権限、承認者
• ログの種類、保存期間、閲覧可能者
• 評価実施日、合格条件、既知の制約、次回見直し日

社内RAGでは、回答を最後に隠すのではなく、検索時点で認可フィルタを適用する設計が重要です。具体的な設計観点は社内RAGの権限管理｜検索前フィルタ・ACL連携・権限変更反映の設計で解説しています。

4. 実データに近い評価と統制テストを分けて行う

品質評価と統制テストは混ぜずに記録します。

• 品質評価：正確性、根拠の利用、形式、処理時間、費用、未回答にすべき質問への反応
• 統制テスト：権限外文書を検索しないか、危険な操作に承認が必要か、ログが残るか、停止条件が機能するか
• 変更テスト：モデル、プロンプト、参照文書、権限、ツール定義を変えた後に基準を再び満たすか

正答率だけで合否を決めると、重大な失敗を見逃します。たとえば、100件中95件正答でも、残り5件が「本来は回答せず人へ引き継ぐべき契約・返金案件」なら、単純な平均点は意思決定に不十分です。失敗の種類ごとに、件数、影響、検出可能性、許容可否を記録してください。

生成AIの正確性を扱う場合は、原典、確認者、承認条件、失敗を次回評価へ戻す流れまで設計する必要があります。生成AIの正確性課題とは？企業文書の誤情報を防ぐ評価・承認・改善フローもあわせて確認してください。

5. 指摘を「欠陥」ではなく、意思決定できるリスクとして整理する

監査結果は「問題あり」の一覧ではなく、責任者が対応順を決められる形にします。Mojiでは、次の4項目を最低限そろえることを提案します。

優先順位は、影響度だけでなく、発生可能性、検出のしやすさ、可逆性、代替策の有無で変わります。重大な操作でも、人の事前承認で取り消せるなら残余リスクは下がる場合があります。一方、低頻度でも漏えい・法令違反・安全上の影響が大きい失敗は、より重く扱います。

6. 是正後に再確認し、運用中の再監査条件を決める

監査報告を提出して終わりにすると、モデル更新や業務変更で前提が崩れます。再監査の日時だけでなく、何が変わったら再確認するかを決めます。

• モデル、埋め込みモデル、主要プロンプトを変更した
• 参照するデータの正本、更新方法、チャンク設計を変更した
• 外部ツールへの書き込み権限や承認フローを変更した
• 対象利用者、対象国、顧客向けの表示内容を拡大した
• 重大な誤回答、権限逸脱、セキュリティ事象、苦情が発生した

ISO/IEC 42001:2023は、AIを提供・利用する組織向けに、AIマネジメントシステム（AIMS）を確立、実装、維持、継続的に改善するための要求事項を定める国際規格です。AI監査を単発の点検ではなく、方針・責任・評価・改善の循環へ組み込む際の参照枠として使えます。 ISO/IEC 42001:2023

そのまま使える：AI監査の開始判定チェックリスト

次の項目で「いいえ」または「未確認」が残る場合、対象範囲を縮める、承認を追加する、限定試行に戻す、といった判断を検討してください。すべてに一律で「はい」が必要とは限りませんが、未対応の項目と残余リスクを意思決定者が理解している状態は必要です。

• □ 対象業務、利用者、入力、出力、禁止操作を1枚で説明できる
• □ 業務責任者、技術責任者、情報管理責任者、最終承認者が決まっている
• □ 入力してよい情報・いけない情報が、利用者向けに明文化されている
• □ モデル、プロンプト、検索対象、ツール、権限の変更履歴を追える
• □ 想定する重大な失敗と、停止・エスカレーション条件が定義されている
• □ 実際の業務に近い評価ケースと、期待結果・採点方法がある
• □ 「回答すべきでない質問」「人へ引き継ぐ質問」も評価対象に入っている
• □ 権限外のデータへアクセスできないことを、テストで確認している
• □ 外部送信・書き込み・金銭・権限変更には、必要な承認がある
• □ ログから、入力、参照根拠、ツール実行、承認、出力を必要な範囲で追える
• □ 事故時の停止、連絡、利用者への案内、復旧、再発防止の担当が決まっている
• □ 次回の定期監査日と、再監査トリガーが決まっている

監査記録テンプレート

以下は、最初の監査で使える最小構成です。文書名・日付・システム名は架空の例です。

文書名：AI利用監査記録（架空の例）
対象：社内サポート回答案作成AI（架空の例）
監査日：2026年10月20日（架空の例）

1. 対象範囲
- 利用者：サポート担当者
- 入力：問い合わせ文、製品カテゴリ
- 出力：回答案、参照文書、エスカレーション候補
- 禁止操作：顧客への自動送信、返金・契約条件の確定

2. 監査基準
- 権限外文書を検索しない
- 重要案件は回答を確定せず、人へ引き継ぐ
- 評価ケースに対する合格条件を満たす
- モデル・プロンプト・参照文書の変更履歴を残す

3. 確認した証跡
- AIシステム台帳
- 評価ケースと採点結果
- 権限テスト結果
- 承認ログ
- 変更履歴
- インシデント対応手順

4. 指摘・残余リスク
- 事実：＿＿＿＿
- 影響：＿＿＿＿
- 対応責任者：＿＿＿＿
- 期限：＿＿＿＿
- 再確認方法：＿＿＿＿
- 本番可否：承認／条件付き承認／限定利用／差し戻し

経営者・事業責任者が最終承認前に確認する5つの質問

1. このAIは、どの業務のどの判断・作業を変えるのか。
   「便利そう」ではなく、対象工程と責任者が明確かを確認します。
2. 失敗したとき、誰にどの程度の影響が出るのか。
   品質の低下、漏えい、差別・不公平、誤送信、誤った自動実行を分けます。
3. AIの出力を誰が、どの条件で確定するのか。
   人の確認を置く場合も、確認者に時間・権限・根拠があるかを確認します。
4. その判断を支える証跡は残るのか。
   後から「なぜその回答・操作が行われたか」を調べられない設計は、改善も説明も困難です。
5. 変更・事故の後に、止めて戻して学べるか。
   停止条件、ロールバック、連絡、再評価が決まっているかを確認します。

AI監査で避けたい4つの失敗

1. 監査を年1回の書類確認だけにする

AIは、モデル更新、プロンプト変更、参照文書の更新、ツール追加で挙動が変わります。定期監査に加え、変更・事故を起点にした再監査を設計してください。

2. ベンダー資料だけで適合と判断する

提供者のセキュリティ資料やモデルカードは重要な入力ですが、自社のデータ、利用者、権限、業務フローで起きるリスクを代わりに評価するものではありません。提供者の統制と、自社実装・自社運用の統制を分けて確認します。

3. 平均スコアだけで本番化する

平均的に良い回答でも、特定の重要ケースで誤案内する、拒否すべき依頼を実行する、権限外の情報を出すなら、本番化条件を満たさない場合があります。評価ケースを重要度別に分け、致命的な失敗を別枠で扱います。

4. 「禁止」で終わらせ、現場の代替手段を用意しない

利用者が必要な業務を進められないまま禁止だけを増やすと、管理外のAI利用へ流れるおそれがあります。入力禁止情報、許可済みの利用環境、確認が必要な操作、相談先を業務の流れで示してください。社内ルールの具体的な作り方は生成AIの社内ルール設計｜禁止事項だけにしない許可範囲・権限・承認・人間確認の決め方で解説しています。

まとめ：AI監査は「導入を止めるため」ではなく、任せる範囲を決めるための仕組み

AI監査の目的は、AI利用を一律に禁止することではありません。どの業務なら任せられるか、どこで人が確認するか、何が起きたら止めるかを、説明可能な証跡とともに決めることです。

最初から全社共通の巨大な制度を作る必要はありません。まずは、外部影響が限定的で、成果と失敗を確認しやすい1業務を対象に、台帳、評価、権限、承認、ログ、再監査トリガーをそろえてください。その記録を基に、用途の拡大に合わせて監査の深さを上げる方が、過剰な統制と無統制の両方を避けやすくなります。