こんにちは、株式会社TIMEWELLの濱本です。エンタープライズAIガバナンスの連載も3本目、いよいよ「実際にAIを監査するときに、何を、どの順番で、どんなツールで見るのか」という現場仕事の話に入ります。
社内でAIを使うところまでは、わりと多くの会社がたどり着きました。問題はその次です。経営会議で「うちのAIは大丈夫なのか」と問われたとき、ほとんどの担当者が言葉に詰まる。SOC2やISO27001のような従来の監査チェックリストを開いても、AIの中身を評価する項目はほぼ書かれていません。実際、Grant Thorntonが2026年に発表したAI Impact Surveyでは、AI導入が期待通りに進まない要因として46%の経営層がガバナンスとコンプライアンスを挙げています。中身を見る仕組みがないまま動かしているから、止めるか、無視するか、見て見ぬふりをするかの三択になる。
この記事では、その状況を抜け出すための「3層レビュー」を提案します。データ層・モデル層・運用層の3つに分けて、それぞれ何を確認するか、どのツールを使うか、誰が責任を持つかを具体的に書きます。前2作のエンタープライズAIガバナンス｜SOC2・ISO27001・ISO42001の監査統制と日本の経産省・総務省AIガイドライン準拠を前提にしているので、まだの方はあわせて読むと話がつながりやすいはずです。
AI監査が「3層」に分かれる理由
AI監査というと、つい「ChatGPTを使ってよいですか」「Copilotの設定は安全ですか」というような利用ガイドラインの話に寄りがちです。けれど本当に問われているのはもう一段深いところで、学習に何を食べさせ、どんな振る舞いを学習し、どう使われ続けているか、という3つの時間軸を別々に見る必要があります。これがそのまま「データ層・モデル層・運用層」という3層構造になります。
ISO/IEC 23894:2023（Artificial intelligence — Guidance on risk management）が、この層別の考え方を国際標準のレベルで言語化した最初の文書です。ベースはISO 31000:2018のリスクマネジメントで、そこにAI固有のハザード（ドリフト、ハルシネーション、ブラックボックス、敵対的入力）を乗せています。23894自体は認証スキームを持たないため「とるもの」ではなく「使うもの」ですが、認証可能なISO/IEC 42001（AIマネジメントシステム）と組み合わせて運用するのが2026年時点での定石です。両者の関係を雑に言えば、42001が屋台骨、23894が中で動かす検査機構という役回りになります。
3層に分けるもう一つの理由は、責任の所在が変わるからです。データ層はデータエンジニアとデータプロバイダーの責任、モデル層はMLエンジニアとモデルプロバイダーの責任、運用層はサービス開発者とSREの責任。1つのチェックリストで全部を済ませようとすると、誰も自分の管轄ではないと言い出して止まります。AICPAとCPA Canadaが2026年に共同で出した「Closing the AI Trust Gap: The Role of the CPA in AI Assurance」も、まさにこの「誰が、どこに、どこまで責任を持つのか」を整理し直す文書として読むのが正解です。
3層レビューは、この責任分担とリスク種別の両方を素直に投影しただけのフレームワークです。新しい考え方ではありません。ただ、現場で実装しようとすると、3つの層を別の暦・別のツール・別の参加者で回す必要があり、ここが多くの会社で詰まっています。次のセクションから、層ごとに何を見るかを具体的に書きます。
データ層監査：学習データの出所・偏り・著作権・PII
最初の砦はデータ層です。古い格言の通り、ゴミを学べばゴミを返す。生成AIの時代になっても、原則は変わっていません。むしろ、学習データのスケールが事業判断を超えて巨大化しているぶん、ゴミが混ざったときの被害が以前より大きくなっています。
データ層監査でまず作ってほしいのが、Datasheets for Datasetsのテンプレートに沿った「データシート」です。これはGebruら（2018年）が提唱したデータセット用のドキュメント様式で、データの動機、収集方法、前処理、利用上の注意、配布条件などをセットで記録します。Googleが「Data Cards」として実装しているフォーマットも実質同じ系譜です。社外から購入したデータでも、社内で集めたデータでも、必ずこの様式で1ファイル作る。これだけで、後続の監査コストが半分以下になります。
技術的にやるべき作業は3つあります。1つ目は出所トラッキング。AWSの「Amazon SageMaker ML Lineage Tracking」、オープンソースなら「DVC（Data Version Control）」を使い、どのデータがどのバージョンの前処理を通ってどのモデルに入ったかを系譜として残します。2つ目はPIIスキャン。Microsoftの「Presidio」は2025年時点で50以上の認識器を備え、氏名や住所、クレジットカード番号、医療エンティティを抽出できます。Wealthsimpleが公開した「PII Redact Gateway」のような、LLM呼び出しの前段でスクラブする運用も増えてきました。3つ目は著作権スクリーニング。Common Crawlのような公開データを直接学習に使う場合は、ライセンス条項とオプトアウト署名（noai、noimageaiなど）の解釈ポリシーを文書化し、運用ログとして残す必要があります。
偏りの検査は、データ層と次のモデル層をまたぐ作業です。University of Chicago DSSGの「Aequitas」は、保護属性（性別、年齢、人種など）ごとの代表性ギャップを定量的に測れる定番ツールで、Aequitas Flow v1.0からは検査だけでなく緩和策（リサンプリングや再重み付け）まで一気通貫で扱えるようになりました。Microsoft発の「Fairlearn」もほぼ同じ役割で、PythonエコシステムのML開発者には馴染みやすい設計です。私はAequitasから始めるのを勧めます。理由は、UI付きの監査レポートをそのまま経営説明に持って行ける完成度があるからです。
データ層の監査記録は、「データシート＋系譜ログ＋PIIスキャン結果＋偏りレポート」の4点セットで残す。これを四半期単位で更新するのが、2026年時点で現実的に回るペースです。EU AI Actが2026年8月から要求してくる高リスクAIの技術文書（Technical Documentation）も、結局はこの4点セットを各国語で出せるかという話に帰着します。最初に作っておけば、規制対応の半分は終わったようなものだと思っています。
モデル層監査：精度・バイアス・公平性・ロバストネス
データの次はモデルそのものです。ここで主役になるのは「Model Card」というドキュメントと、それを支える評価ツール群です。
Model CardはMitchellら（2019年）が提案した、モデル用の「栄養成分表示ラベル」のような様式です。Hugging Face Hubでは事実上の標準フォーマットになっており、モデルの用途、訓練データ、評価メトリック、想定される失敗モード、利用上の注意などを一枚で記述します。社内モデルでも、ファインチューニング済みのオープンモデルでも、このModel Cardを必ず1つ作る。Datasheetがデータ側のIDなら、Model Cardはモデル側のIDです。両方が揃って初めて、データとモデルの紐づけ監査ができます。
精度評価は、メトリック選びで結果が変わります。「Hugging Face Evaluate」ライブラリが2026年に追加した「Community Evals」は、リーダーボードをコミュニティが運営できるようにし、ベンチマークの透明性を一段引き上げました。社内モデルでも、Evaluateの標準メトリック（accuracy、precision、recall、F1、BLEU、ROUGEなど）を使ってバージョンごとの数値を残しておくと、後で「精度が悪化したのはいつか」を遡って言える。これが意外に効きます。私が見てきた現場では、メトリックのバラつきよりも、メトリックの選択そのものが揺らぐパターンのほうが事故になりやすい。最初にメトリックを固定し、レビューで変えるルールを作るほうが、評価の精緻化より優先順位が高いと感じています。
バイアス・公平性の評価は、データ層で使ったAequitasやFairlearnを再利用します。ただしモデル層では「学習後の出力がどう偏っているか」を見るため、入力分布だけでなく予測値の差分を見る指標（Demographic Parity、Equal Opportunity、Predictive Parityなど）を追加で計算します。経済合理性とのトレードオフが避けられない領域なので、定義の選択を経営会議に上げてから動かすほうが安全です。「公平にした結果、ビジネス上のKPIがどう変わるか」を同時に出さないと、現場で握れません。
ロバストネス評価は、もはやAI監査の中心テーマと言ってもよくなりました。IBMの「Adversarial Robustness Toolbox（ART）」、Microsoftが社内のCopilot評価で使っている「PyRIT」、商用なら「Giskard」あたりが2026年の定番です。プロンプトインジェクション、データポイズニング、モデル抽出、回避攻撃といった攻撃カテゴリ別にテストを自動化し、合否ラインをCIに組み込む運用が現実味を帯びてきました。ここを「やった/やってない」の二値で済ませると、いざインシデントが起きたときに監査人が見る記録が一切残っていない、という最悪の状況になります。試験項目と結果はバージョンごとに必ず保管してください。
運用層監査：プロンプト・出力ログ・ドリフト検知・誤動作対応
3層目は運用層、つまり本番で動いているAIの監査です。データ層とモデル層が「事前」の検査だとすれば、運用層は「事後」と「進行中」の両方を見る場所になります。
中心になるのは出力ログの収集と評価です。LLMアプリケーションでは、入力プロンプト・モデル応答・トークン使用量・コスト・レイテンシ・関連するRAGコンテキストを、トレースとしてまるごと残します。オープンソースなら「Langfuse」、ELL2のもとで自己ホスト可能な「Arize Phoenix」、エンタープライズで一気通貫を狙うなら「Datadog LLM Observability」「Weights & Biases Weave」「Braintrust」あたりが2026年時点の選択肢です。LangfuseはClickHouseが2026年1月に買収しましたが、OpenTelemetryネイティブの設計と寛容なライセンスは維持されています。Arize Phoenixはドリフト検出と評価テンプレートの完成度が高く、RAG品質のビジュアル化に強い。私はLangfuseで開発・実験フェーズを回し、本番監視はDatadog LLM Observabilityに寄せる組み合わせをよく勧めています。
ドリフト検知は、特徴量分布の変化を定量的に追う仕組みです。Fiddlerで標準的に使われているJensen-Shannon Divergence（JSD）とPopulation Stability Index（PSI）が業界の事実上の標準で、Evidently AI、WhyLabs、Amazon SageMaker Model Monitorも同じ系統の指標を備えています。週次でPSIをモニタし、しきい値を超えたら自動でアラートを上げ、人間がトリアージする運用が現実的なスタート地点です。本番初期は閾値が荒くてかまいません。1〜2四半期回しながら、誤検知と見逃しの比率を見てチューニングしていく。
誤動作対応のフローは、検知から隔離、分析、是正、再評価の5ステップで設計します。検知はモニタリング（Datadog、Phoenix、Langfuseなど）、隔離はフィーチャーフラグや段階リリース、分析はトレースログとデータ系譜、是正はモデル再学習またはプロンプト調整、再評価はモデル層の評価セットへの組み込み、という流れです。COSOが2026年2月に発表した生成AI向け統制ガイダンスは、このフローを「Control Activities」と「Monitoring Activities」の2要素にマップしています。社内の監査担当が読むなら、まずCOSOの新ガイダンスを横に置きながら自社のランブックを書き直すのが手っ取り早いと思います。
EU AI Actは2026年8月2日から、高リスクAIシステムに対して入出力ログとメタデータの自動記録を義務化します。違反時のペナルティは€15Mまたは全世界売上3%のいずれか大きい方。日本企業も域外適用の対象になり得るので、ログ保存の設計は今すぐ着手して損はありません。
AI監査ツール選定：オープンソース vs SaaS
ツール選びでつまずく会社が多いので、選定の考え方を整理しておきます。前提として、3層をそれぞれ専用ツールで埋める必要はありません。1つのプラットフォームで2層をカバーするケースもあれば、用途別に細かく分けるケースもあります。
オープンソース系は、Aequitas（バイアス監査）、Fairlearn（公平性）、Hugging Face Evaluate（メトリック）、IBM ART（敵対的ロバストネス）、Microsoft Presidio（PII）、Langfuse（LLMトレース）、Arize Phoenix（LLMドリフト・評価）、Evidently AI（データドリフト）、DVC＋MLflow（系譜管理）といった具合に、層ごとにデファクトが揃っています。長所は3つ。コストが低く、ベンダーロックインが弱く、検査ロジックが自社のリポジトリで読めるため監査人に説明しやすいことです。短所は、運用の手間と内部統制のドキュメント化を自社で背負う必要がある点。エンジニアリング能力が前提になります。
SaaS系は、Datadog LLM Observability、Arize AX、Fiddler、WhyLabs、Weights & Biases Weave、Braintrust、Confident AIなどが2026年時点の主流です。長所は、SOC2 Type IIやISO27001などの第三者認証が取得済みで、コンプライアンス報告にそのまま流用できる点。短所は、データを社外に出す前提になりがちで、機密度の高いプロンプトや業務文脈が外に漏れない設計を別途作り込む必要がある点です。
私が現場で勧めることが多い構成は、「OSSで開発・実験、SaaSで本番監視」のハイブリッドです。具体的には、開発フェーズはLangfuse＋Aequitas＋Hugging Face Evaluateで自社内に閉じて回し、本番運用ではDatadog LLM ObservabilityまたはArize AXに集約してSOCレポートに使う。これなら、感度の高いプロンプトはOSS側に閉じ、コンプライアンス報告に必要な統制はSaaS側で揃う。Big4のAI監査サービス（PwCのGL.aiやH2O.ai連携、EYのHelix、KPMGのIgnite、DeloitteのAI-driven analytics）も、基本的にはこのハイブリッドを前提に設計が進んでいる印象です。KPMGは2026年夏にAI主導の監査を本格運用させ、2027年の完全実装に向けて2億ドル規模の投資を表明しました。社内で同じ水準を完全自前で揃えるのは現実的ではないので、OSSとSaaSと外部監査の3点セットでカバー範囲を埋めるのが、当面のベストプラクティスだと考えています。
ツール選定の最後に大事なのが、AIエージェントの監査をどこで見るかです。エージェントは複数モデル・複数ツール・複数データソースを跨ぐので、トレースが一本にまとまっていないと監査になりません。連載番外編のAIエージェントのKPIモニタリングと運用設計でも触れていますが、エージェント時代の運用層監査は「ステップ単位のトレース＋ドリフト指標＋人間レビューキュー」の3点セットを最初から想定しておくのが安全です。
監査プログラムを社内に根付かせるための実装手順
最後に、3層レビューを「始めて、続ける」ための実装手順を6ステップで整理します。実際に走らせてみると、最初の3ヶ月でいちばん多い失敗は「検査はしたが結果が誰のものでもない」というやつです。手順自体より、責任の置き場と頻度の設計が肝になります。
第1ステップは責任分担の固定です。データ層はデータエンジニアリング部門、モデル層はML・AI推進部門、運用層はSRE・サービス開発部門、横串で内部監査と法務、という4枠を最初に書きます。AICPAの「Closing the AI Trust Gap」が指摘するように、CPAや内部監査人は「全層を最終チェックする横串役」に置くと機能します。第2ステップは資産棚卸し。どのモデルが、どこで、何のデータを使い、誰のために動いているかを一覧化する。これがないと、監査対象が曖昧になります。第3ステップは3層それぞれのドキュメント整備。データシート、Model Card、運用ランブックの3点セットを、必ず1モデル1セットで揃えます。
第4ステップは検査実行とログ蓄積です。データ層は四半期、モデル層は新バージョンリリース時、運用層は週次〜日次という頻度で回す。ここで使うツールは前述のOSSとSaaSのハイブリッドが現実的です。第5ステップは経営報告とリスク受容判断。検査結果は数字で出し、しきい値を超えたものは経営会議の議題に上げる。COSO 2026ガイダンスのフレームを使うなら、5要素（control environment、risk assessment、control activities、information & communication、monitoring activities）にマップした報告書を四半期ごとに作るのがちょうどよい粒度だと思います。第6ステップは外部監査・第三者評価への接続。EU AI Actは高リスクAIに第三者監査を義務化します。日本でも金融・医療・採用といった分野では、外部監査の波は確実に強くなる。ここで困らないように、第1〜5ステップで作った成果物を「外に出せる形式」で残しておくのが肝心です。
AI監査は、一度仕組みを作ってしまえば運用は驚くほど軽くなります。逆に、仕組みがないまま「とりあえず動かしている」状態を放置すると、半年後にIT部門と法務部門の間で板挟みになり、AI活用そのものが止まるという未来が待っています。私の経験では、本気で詰まっている会社の8割が「3層のうち1層しか動いていない」状態でした。データ層だけ整備して安心しているとか、運用層のログだけ取って中身を見ていないとか、そういう片肺運用が一番危ない。3層を同時に立ち上げる必要はありません。順番でも構いません。ただし、3層全部に責任者と頻度を置いてください。
TIMEWELLでは、エンタープライズAI基盤「ZEROCK」を提供する立場として、データ層・モデル層・運用層の3層レビューを最初からプラットフォーム機能として組み込んでいます。GraphRAGの参照ログ、プロンプトライブラリのバージョン管理、AWS国内サーバーでのトレース保存などは、ここで述べた監査要件をそのまま満たすための仕様です。AI監査の仕組みづくりに困っている企業のご担当者は、お気軽にご相談ください。次回の連載では、AI監査と並走する「インシデント対応プレイブック」を扱う予定です。
参考文献
[^1]: ISO/IEC 23894:2023 Artificial intelligence — Guidance on risk management, https://www.iso.org/standard/77304.html [^2]: Journal of Accountancy, COSO creates audit-ready guidance for governing generative AI（2026年2月）, https://www.journalofaccountancy.com/news/2026/feb/coso-creates-audit-ready-guidance-for-governing-generative-ai/ [^3]: The CPA Journal, How to Audit AI（2026年1月13日）, https://www.cpajournal.com/2026/01/13/how-to-audit-ai/ [^4]: EU Artificial Intelligence Act, Article 6: Classification Rules for High-Risk AI Systems, https://artificialintelligenceact.eu/article/6/ [^5]: Langfuse FAQ, Langfuse vs Arize AI / Phoenix, https://langfuse.com/faq/all/best-phoenix-arize-alternatives [^6]: Aequitas: The Bias and Fairness Audit Toolkit, University of Chicago DSSG, https://dssg.github.io/aequitas/ [^7]: Hugging Face Evaluate Documentation, https://huggingface.co/docs/evaluate/index [^8]: Amazon SageMaker ML Lineage Tracking, https://docs.aws.amazon.com/sagemaker/latest/dg/lineage-tracking.html [^9]: Datadog Blog, Observability in the AI age: Datadog's approach, https://www.datadoghq.com/blog/datadog-ai-innovation/