AI監査の準備では、何を基準に、どの期間の運用を、どの記録で確かめるかを先に決めます。「AIを安全に使っているか」という問いを、第三者が追跡できる確認項目へ分けることが出発点です。
この記事では、企業が利用するAIについて、運用ルールと実際の利用が整合しているかを証拠に基づいて確認し、改善につなげる活動をAI監査として扱います。モデルの性能試験だけでなく、人の承認、変更管理、問題への対応も対象に含める整理です。
以下の確認表と手順は、自社の監査担当と範囲を合意するための実務案です。特定の認証取得や法令適合を判定する基準ではありません。参考にするNIST AI RMFも任意利用のリスク管理枠組みであり、本稿はその1.0を参照しています。
AI監査で確かめることと、担当の分け方
日常の運用担当は、出力の確認や障害対応を行います。監査側には、その対応が決めた基準に沿って行われたか、記録から確かめる役割を持たせます。自己点検の結果を渡す場合も、点検した本人の説明だけで結論を出さず、承認履歴や評価結果と照合しましょう。
NIST AI RMF 1.0のMEASURE 1.3では、開発の第一線を担わなかった内部専門家や独立評価者が評価に関与する考え方が示されています。AI RMF Core：MEASURE
社内で確認する場合は、対象業務の運用担当と確認担当を分け、担当者の関与範囲を記録します。外部へ依頼する場合も、依頼先が導入支援や開発に関わった範囲と、今回確認する範囲を明らかにします。契約前には、報告先、必要な専門性、閲覧できる資料、追加確認への対応まで合意しておくとよいでしょう。
最初に監査範囲を一枚にまとめる
「全社のAI」を一括で対象にする前に、業務単位で境界を置きます。たとえば問い合わせ返信の下書き作成なら、入力から担当者の確認、送信までを並べ、どこにAIが入るかを示します。
| 合意する項目 | 記入する内容 |
|---|---|
| 対象業務とシステム | 用途、利用部門、サービス名、連携先、人が最終判断する工程 |
| 対象期間と版 | 確認する運用期間、モデル・設定・参照資料の版、変更日 |
| 確認基準 | 承認済みの利用ルール、評価基準、委託先との合意事項とその版 |
| 優先するリスク | 誤回答、情報の不適切な参照、承認を経ない送信など、業務への影響 |
| 対象外・確認の限界 | 提供元の内部処理など閲覧できない部分、証跡がない期間 |
| 担当と報告先 | 資料提出者、確認者、改善責任者、残るリスクの判断者 |
対象外は空欄にせず、「確認できない理由」と「結論への影響」を残します。たとえば提供元のモデル内部を確認できない場合、自社で行った利用時の評価と、提供元から受領した説明資料の範囲を区別します。
外部支援の依頼範囲も整理したい場合は、生成AIの導入支援で依頼する成果物と社内の分担を併せて確認できます。
AI監査に必要な証跡を、問いと対応させる
証跡とは、判断や作業が実際に行われたことを確かめる記録です。ファイルを大量に集めるよりも、監査上の問いに答える資料をひも付けます。
NISTのMEASURE 2.1と2.3では、テスト集合・評価指標・使用ツールの詳細や、利用環境に近い条件での評価の記録が扱われています。下表はそれを含め、業務側で用意する資料を整理したものです。AI RMF Core：評価の記録
| 監査で確かめる問い | 用意する証跡の例 | 確認のしかた |
|---|---|---|
| 承認された用途で使われたか | 利用申請、承認履歴、用途別の利用記録 | 申請内容と抽出した実利用を照合する |
| 適切な情報を参照したか | データ一覧、参照権限、設定の変更履歴 | 利用者の権限と実際の参照範囲を照合する |
| 品質基準を満たしたか | 評価データ、判定基準、実行条件、失敗例を含む結果 | 結果がどの条件・版で得られたかを追う |
| 人の確認を経たか | 出力、修正・承認履歴、送信記録 | 承認者と時刻、未承認時の扱いを確認する |
| 変更後も使えると判断したか | 変更申請、再評価結果、反映の承認 | 変更と評価、反映の順序を追う |
| 問題に対応できたか | 問題の受付記録、停止・復旧判断、改善後の確認結果 | 発見から対応完了までの経緯を照合する |
各証跡には、対象業務、日時、版、作成・承認者、保管先を付け、監査項目からたどれる一覧にします。取得できない項目は、代わりの資料と確認できる限界を書きます。
入力や出力の全文を無条件に保存する設計にはせず、監査に必要な情報を選びます。閲覧者、保存期間、マスキングの方法を情報管理担当と決め、監査用に加工した資料は加工範囲も記録してください。
規程の存在と、実際の運用を分けて確認する
確認は「ルールがあるか」「実際に守られたか」「狙った効果を確認できるか」の順で進める案が使えます。
- 確認基準の版と適用開始日を確定する。
- 対象期間の利用・変更・問題対応の一覧を受け取る。
- 抽出した記録について、申請から結果までを追跡する。
- 記録が足りない箇所は担当者へ照会し、説明を裏付ける資料を確認する。
- 確認した範囲、発見事項、確認できなかった点を報告する。
抽出対象には通常の処理に加え、例外、変更直後、問題が発生した処理を含める方針を立てます。件数は一律に決めず、対象数や影響に応じて監査担当と合意し、選び方を記録します。抽出範囲での結果を、全件の確認結果として記述しないことも報告上の約束にします。
たとえば返信下書き業務で「送信前に人が確認する」と定めた場合、利用マニュアルだけで確認を終えません。抽出した処理の承認履歴と送信記録を照合します。承認履歴が残っていなければ、規程違反と即断する前に、別の証跡で確認可能かを調べます。それでも分からなければ「実施を確認できない」と報告します。
指摘は、改善後の再確認まで追う
指摘事項には、基準、観察した事実、証跡、想定される影響、対応担当、期限、完了の確認方法をセットで記載します。「管理を強化する」といった方針だけで終了させず、どの記録で改善を確かめるかを決めておきましょう。
前述の承認履歴の例なら、改善担当は記録方法を整備し、監査側は適用後の処理を抽出して、承認者と承認時刻を追跡できるか再確認します。手順書の改訂と、実際に記録が残ることを分けて扱う形です。
NISTのMANAGE 4.2と4.3も、継続的な改善と、インシデントやエラーへの対応を記録する活動を扱っています。AI RMF Core：改善と問題対応
再確認の結果は「解消」「対応中」「確認不能」などに分け、残るリスクを受け入れる場合は判断者と理由、再検討する条件を記録します。証跡がないまま「問題なし」とする扱いは避けます。
最初の準備物は、対象業務の範囲表、問いに対応する証跡一覧、指摘の管理表です。対象を一つの業務に絞ってこの三つを作り、監査担当と不足を確認してください。これから運用を広げる段階なら、生成AI導入のステップと段階ごとの判断条件を参考に、監査で見つかった課題を次の展開判断へつなげられます。