AI監査が止まる原因とHolistic AI｜基盤に任せる範囲

「AIの監査は年に1回、評価表を埋めて提出すれば終わりだと思っていた」「監査を始めたのに、半年後には一覧も検査の結果も古くなっていた」——AIの利用を広げた会社のガバナンス担当から、こうした声が聞かれるようになりました。監査を一度やったのに続かないのは、担当者の怠慢ではありません。本当は、使っているAIのモデルや中身が入れ替わるたびに、検査をやり直す仕組みがないことが原因です。こうした仕組みを外部の基盤に持たせる製品の一つが、Holistic AI です。この記事では、AIの監査が止まる原因から始め、Holistic AI のような基盤に任せてよい検査と、任せても人が持つ判定・例外の承認・記録の責任の線を整理します。

Holistic AIは何をする基盤か

Holistic AI は、企業が使うAIのモデル、AIエージェント、AIを組み込んだアプリを対象にした、AIガバナンスの基盤です。公式サイトでは、機能を「見つける」「守る」「徹底させる」の3つの層に分けて説明しています（2026年10月時点）。1つずつの道具ではなく、監査に要る作業を1か所に集める作りです。

見つける層は、クラウド、コード、業務向けのクラウドサービスにまたがって、許可外のものを含むAIを見つけ、持ち主・リスクの水準・依存関係つきの一覧を最新に保つ機能です。AWS、Azure、GitHub、Databricks など20を超える連携先が挙がっています。守る層は、プロンプトインジェクションや制限破りを試す攻撃の演習、偏り・作り話・個人情報・頑健性についての40を超える検査、本番での性能の変化の監視です。

徹底させる層は、欧州のAI規則、米国の国立標準技術研究所（NIST）のAIリスク管理の枠組み、ISO/IEC 42001 といった規制や規格に自社の管理策を対応づけ、承認、本番に出す前の関門、人による監督、監査の記録を回す機能です。さらに、AIエージェントの動きを方針と照らして見張る役と、方針に外れた動きを止める・別の経路に回す・人に上げる役のエージェントを、Guardian Agents として打ち出しています。一覧・検査・記録を1つの基盤で回すのが、この製品の考え方です。

作っている会社と、国内でまだ知られていない理由

公式のプライバシーポリシーによれば、Holistic AI Inc を親会社とする会社群で、その子会社が個人データの管理者になっています。2023年9月には、英国政府の科学・イノベーション・技術省がまとめたAIの保証の手法の事例集に、同社の監査の進め方が載りました。そこでは、偏り、個人情報、有効性、頑健性、説明のしやすさの5つの領域から対象を選び、分類、評価、軽減、保証の4段で進めると説明されています。監査の手作業を基盤に移してきた会社だと分かります。

2026年7月の公式ブログでは、Gartner が初めて出したAIガバナンスの基盤の評価で、評価対象の13社のうち唯一の「チャレンジャー」に位置づけられ、付随する機能の評価ではAIのリスクと規制対応の用途で1位、AIエージェントの統制の用途で上位3社に入ったと、提供元は発表しています。2026年10月にも新しい機能の告知を出しており、製品の終了、名称の変更、他社への統合の告知は見当たりません。

日本語の解説がほとんど無い理由は、確かめた範囲で3つあります。公式サイトと資料は英語で、日本語の案内は見当たりません。打ち出している規制は欧州のAI規則や米国の枠組みが中心で、国内の指針との対応づけは公式では確かめられませんでした。そして対象は、クラウドとコードに多数のAIを抱える大企業です。AIの数が少ない会社では、一覧を基盤で持つ必要がまだ生まれていないことも、比べる場面が少ない理由です。

「監査は年に1回、評価表を埋めれば済む」は誤り

監査を年1回の書類の仕事と考えると、評価表を埋めて承認を取った時点で終わったことになります。しかしAIは、導入した後も中身が変わります。提供元がモデルを更新する、社内でAIに渡す指示や参照する資料を変える、AIエージェントにつなぐ道具を増やす。どれも、評価したときとは別のものが動いている状態を生みます。

Holistic AI が本番での性能の変化の監視や、規制や方針が変わったときに一覧を更新する作りを打ち出しているのも、この前提に立っているからです。監査の対象は、評価した日のAIではなく、いま動いているAIです。年1回の評価表は、その日に撮った写真にすぎません。写真が古くなったことに気づく仕組みがなければ、監査は書類の上だけで続きます。

だからといって、毎日すべてを検査し直す必要はありません。必要なのは、何が変わったら検査をやり直すかという引き金と、引き金が引かれたときに誰が判定するかの決まりです。次の3節で、監査が止まる原因を3つに分けて見ていきます。評価の物差しや工程そのものの作り方は、リスク評価の手順を扱った別の記事に譲ります。

止まる原因1：一覧が現物とずれる

監査は一覧から始まります。ところが一覧は、作った日から古くなります。部門が独自に契約したAIサービス、開発の部門が試しに組み込んだモデル、業務のクラウドサービスに後から加わったAI機能は、申請の仕組みを通らずに増えていきます。

一覧が現物とずれると、監査は一覧に載っているものだけを検査し、載っていないものは見ないまま「問題なし」と報告することになります。監査の結果は、一覧の外については何も語らないのに、報告を受ける側はそのことに気づきにくいのが厄介な点です。

Holistic AI の公式ブログでは、クラウドの環境とコードの保管庫を見張るエージェントが、モデル、エージェント、外部とのつなぎ口、使い道を見つけ、記録されていない許可外のAIも拾うと説明しています。一覧の各項目には、持ち主、置き場所、触れるデータ、関わる規制が記録されるとしています。人の申告に頼らず見つける手段を持つことが、この原因への手当てです。ただし、見つけた候補を正式に一覧に載せ、持ち主を決めるのは人の仕事として残ります。一覧の項目の作り方と、許可外の利用の見つけ方そのものは、別の記事で扱っています。

止まる原因2：中身が変わっても検査をやり直す引き金がない

2つ目の原因は、検査をやり直すきっかけが決まっていないことです。導入前に一度検査して合格にしたAIが、その後モデルの更新で答え方が変わっても、誰も検査をやり直さない。これが、監査が形だけになる典型です。

やり直しの引き金になる変化は、おおむね次のとおりです。モデルの提供元による版の更新、社内で書き換えた指示や参照資料、AIエージェントにつないだ道具や権限の追加、使う部門や用途の広がり、そして適用される規制や社内の方針の変更です。どれも日常の運用で起き、変えた人は、検査のやり直しが要るとは思っていないことが多いのが特徴です。

基盤に任せられるのは、変化の検知と、決めておいた検査の再実行です。Holistic AI は本番での性能の変化の監視を打ち出しています。一方で、どの変化を引き金にするかを決めるのは人です。引き金を決めないまま監視だけを入れると、警告が大量に出て、やがて誰も見なくなります。引き金の一覧は、変える側の部門にも配り、変える前に知らせてもらう約束にしておきます。

監査を1回で終わる作業ではなく輪として回す考え方は、新しいものではありません。2023年の英国政府の事例集に載った同社の監査の進め方でも、軽減の段で技術面と運用面の手当てを勧め、手当てが済んだら評価し直す、と説明されています。直したら確かめ直す、変わったら確かめ直す。この2つの輪を、人の記憶ではなく決まりと基盤の設定で回すことが、止まらない監査の条件です。

止まる原因3：結果を誰が判定するかが決まっていない

3つ目の原因は、検査の結果が出ても、それを合格とするか不合格とするかを決める人がいないことです。たとえば偏りの検査で、ある属性に対する答えに差が出たとします。その差が業務上許せる範囲なのか、直すまで止めるべきなのかは、数字だけでは決まりません。

判定の席が空いていると、結果は報告書の中に積まれるだけになります。開発の担当は「指摘は出したが、判断は求められていない」と考え、事業の担当は「技術の結果は読めない」と考える。こうして、検査は回っているのに、何も決まらない状態が続きます。検査の件数だけが増えていくので、外からは監査が進んでいるように見えるのも厄介です。

判定する人は、AIの用途ごとに決めます。顧客に答えるAIなら顧客対応の責任者、採用の選考に関わるAIなら人事の責任者、といった具合に、結果の影響を受ける業務の責任者を判定者に置き、技術の担当は結果の意味を説明する役に回ります。AIの責任者の置き方そのものは、体制を扱った別の記事を参照してください。

検査の対象と頻度は、変わる速さで決める

3つの原因への手当てを、対象ごとの検査の頻度に落とします。全部を同じ頻度で検査すると手が回らず、結局どれも続きません。変わる速さと、外れたときの影響の大きさで頻度を分けます。下の表は、頻度と判定者の置き方の一例です。

対象の例	主に変わるもの	やり直しの引き金	定期の頻度の目安	判定する人
顧客に直接答えるAI	モデルの版、指示、参照資料	版の更新、指示の書き換え	毎月	顧客対応の責任者
道具や権限を持つAIエージェント	つなぐ道具、渡す権限	道具・権限の追加	変更のたび	業務の責任者と情シス
社内向けの文章作成の補助	モデルの版	版の更新、用途の拡大	半年ごと	AI推進の責任者
採用や与信など人に影響する判断に関わるAI	学習データ、判断の基準	データや基準の更新、規制の変更	変更のたびと四半期ごと	業務の責任者と法務
部門が独自に契約したAIサービス	提供元の仕様	契約の更新、仕様変更の告知	契約の更新のたび	契約した部門の長

頻度は目安で、決めた後も見直します。大事なのは、表の右端の列を空けないことです。判定する人の欄が埋まらない対象は、基盤で検査を回しても止まります。逆に、判定する人が決まっていれば、頻度が多少粗くても監査は続きます。基盤の設定に入る前に、この表を社内で1枚作っておくと、どの検査を自動で回すかの議論が早く進みます。

基盤に任せる検査：偏り・頑健性・誤り・攻撃への耐性

Holistic AI の公式サイトでは、偏り、作り話、個人情報、頑健性についての40を超える検査と、プロンプトインジェクションや制限破りを試す演習を挙げています（2026年10月時点）。決めた手順で何度でも同じように回せる検査は、人が手で行うより基盤に向いています。

基盤に任せる利点は、同じ検査を同じ条件で繰り返せることです。人が手で試すと、試す人によって問いの選び方が変わり、前回との比較ができません。前回と同じ物差しで差を見られることが、続けて回す監査では一番効きます。モデルの版が上がったとき、前の版と同じ検査を当てて差だけを読めば、判定者が見る量も絞れます。

ただし、基盤の検査は一般的な問いの組で作られています。自社の業務に特有の失敗、たとえば自社の商品名の取り違えや、社内の規程と食い違う答えは、自社で問いを足さなければ見つかりません。偏りの現れ方と確かめ方そのものは別の記事で詳しく扱っているので、ここでは検査を基盤に任せるときの線だけを押さえます。攻撃の演習の進め方や、出す前の検査の標準化も、それぞれ別の記事で整理しています。

検査を基盤に回すには、基盤の側から自社のAIに問いを投げられる接続が要ります。ここで決めておきたいのが、本番のAIに直接投げるのか、検査用に分けた環境に投げるのかです。本番に投げると、検査の問いが利用の記録や費用の集計に混ざり、利用の数字が実態より多く見えます。検査用の環境に投げると、本番と設定がずれていないかを別に確かめる必要があります。どちらを選んでも、検査の問いと答えが基盤の側にどこまで残るかは、契約前に確かめる項目です。

人が判定すること：合否・例外の承認・経営への報告

基盤が出すのは検査の結果であって、判定ではありません。人が持つべき判定は3つあります。1つ目は合否で、検査で出た差や誤りの率が、その用途で許せる範囲かを決めます。2つ目は例外の承認で、基準を満たさないが事業上の理由で使い続ける場合に、誰がどの条件で認めるかを決めます。3つ目は経営への報告で、何を検査し、何が分かり、何が分からないかを伝えます。

例外の承認には、特に記録が要ります。「直すまでの3か月は、人が全件を確かめる条件で使い続ける」といった判断は、条件と期限と承認者をそろえて残します。期限が来たときに、条件が守られたかを確かめる人も決めておきます。例外は期限つきで認め、期限が来たら必ず判定し直すのが原則です。期限のない例外は、いつの間にか通常の扱いに変わります。

Holistic AI は、承認と人による監督の流れを基盤の中に持つと説明しています。ただし、承認の欄に誰の名前を入れるかは会社が決めます。基盤の承認の流れは、決めた人に回すための道具です。判定者を決めずに承認の流れだけを作ると、担当者が形だけ承認を押す運用になりがちです。

3つ目の経営への報告は、合否の件数を並べるだけでは判断の材料になりません。区分を、止めたもの、条件つきで使い続けているもの、直して使い続けているものの3つに分け、それぞれの件数と、条件つきのものの期限を示します。経営が知りたいのは「いま危ないものが動いているか」と「それを誰が見ているか」です。検査の件数の多さは、その答えになりません。報告の形を先に決めておくと、判定者が記録に何を書けばよいかもそろってきます。

「何も出なかった」を安全の証明にしない

検査で何も見つからなかったとき、それを「安全が確かめられた」と報告したくなります。しかし検査で分かるのは、用意した問いと手口では問題が出なかった、ということまでです。用意していない問いや、まだ知られていない手口については、何も言えません。

英国政府の事例集でも、同社の監査は最後に規格や規制への適合を表明する段を持ちますが、リスクの高い問題が残る場合は条件つきの保証にとどめる、と書かれています。保証には常に範囲と条件が付くということです。社内の報告でも同じ書き方をします。次のような報告は、検査の結果を実際より重く見せてしまいます。

• 検査で指摘が0件だったことを、「このAIは安全」と経営に報告する
• 基盤の標準の検査だけを回し、自社の業務に特有の問いを足さない
• 警告の閾値を緩めて指摘を減らし、件数の減少を改善と報告する
• 一覧に載っていないAIについて、検査の結果から何かを言う

報告には、検査した対象、使った検査の種類、検査しなかった範囲、次に検査する予定の日を必ず添えます。この4点がそろっていれば、読む側は結果の重みを正しく受け取れます。指摘の件数の増減は、検査の範囲を広げたか狭めたかでも動くので、件数だけを並べた報告は避けます。

記録の残し方：誰が何を見て何を決めたか

監査の記録で残すべきなのは、検査の結果だけではありません。誰が結果を見て、何を決め、その理由は何だったかです。検査の結果は基盤が自動で残せますが、判断の記録は人が書かなければ残りません。

Holistic AI は監査の記録を基盤の機能に挙げています。基盤に残る記録と、社内の会議体や稟議に残る記録が別々になると、後からたどるときに突き合わせが要ります。判断の記録をどこに置くかを、基盤を入れる前に決めます。基盤の中に判断を書き込むのか、社内の文書に残して基盤には参照だけを置くのか、です。どちらでもよいので、片方に寄せます。

判断の記録は、長い議事録である必要はありません。対象のAI、見た検査の結果、決めたこと、その理由、決めた人、次に見直す日がそろっていれば、後から経緯をたどれます。逆に、検査の結果の画面だけが残り、決めた人と理由が残っていない記録は、監査の記録としてはほとんど役に立ちません。基盤の画面に残る結果と、人が書く判断を、同じ対象の名前で結びつけておくことが要点です。

もう一つ決めておくのは、基盤をやめたときの記録の行き先です。監査の記録は、規制への対応や取引先の確認で、数年後に求められることがあります。契約を終えたときに、記録を取り出せる形式と期間を契約前に確かめておきます。監査で見られる記録の項目そのものは、別の記事で一覧にしています。

規制の更新への追従を基盤に任せる範囲

Holistic AI は、欧州のAI規則、米国の国立標準技術研究所の枠組み、ISO/IEC 42001 に管理策を対応づけ、規制や方針が変わると一覧が更新される作りを打ち出しています。条文の変化を追い、自社のどのAIに関わるかの候補を出す作業は、人が手で行うと漏れやすく、基盤の得意な領域です。

たとえば欧州のAI規則は、2026年に期限の一部が見直されました。Holistic AI の公式サイトでは、リスクの高いAIへの義務が2027年12月2日から適用されると説明しています。適用の範囲と時期の解説は別の記事に譲りますが、こうした変化を一覧の各項目に結びつけて知らせる働きは、基盤に任せる価値があります。

一方で、条文と自社のAIの突き合わせの結果は、あくまで下読みです。どの規制が自社に及ぶか、国内の法令や指針との関係をどう扱うかは、法務が判断します。対応づけの表は、法務が確かめてから正式な記録にすると決めておきます。また、国内の指針との対応づけが基盤に用意されているかは、2026年10月時点の公式では確かめられなかったので、導入前に確かめる項目に入れます。

見張りのエージェントに止める権限を渡すか

公式サイトによれば、Guardian Agents は、AIエージェントの動きを方針と照らして見張る役と、方針に外れた動きを止める・別の経路に回す・人に上げる役に分かれます。定期の監査の外側で、動いている最中のAIに手を出す仕組みです。監査が「後から確かめる」仕事だとすれば、こちらは「その場で止める」仕事です。

ここで決めるべきなのは、どこまで自動で止めさせ、どこから人に上げるかです。顧客に誤った約束をしそうな応答や、権限の外のデータへの接続は、自動で止めてよい場面が多いでしょう。一方で、止めると業務への影響が大きい処理は、止める前に人に上げる設定にしておくほうが安全です。自動で止める範囲は、止めたときの業務への影響から逆算して決めます。

止めた記録は、監査の記録と同じ場所に残します。何を、いつ、なぜ止めたかが残っていれば、止めすぎや止め漏れを定期の見直しで直せます。止める仕組みそのものの設計、たとえば隔離した環境での実行については、別の記事で扱っています。

もう一つ、止める条件を書き換えられる人を絞っておきます。条件を緩める変更は、AIエージェントを使う部門から見れば仕事が速くなる変更なので、求められやすいからです。条件の変更は、判定者の承認を経て行い、変更そのものを記録に残します。また、見張る側のエージェントもAIなので、方針に外れていない動きを誤って止めることがあります。誤って止めた件数も見直しの会で数え、止める条件が厳しすぎないかを確かめます。

定期の見直しを回す順番

基盤を入れても、見直しの会を回さなければ監査は止まります。月に1回、次の順で回すと、一覧・検査・判定・記録がつながったまま保てます。

この会の段取りは、AIガバナンスの事務局が担います。ただし事務局は判定者ではありません。事務局が回すのは段取りで、合否を決めるのは各業務の責任者です。年に1回は、引き金の一覧と検査の頻度そのものを見直します。基盤の新しい機能が増えたときも、その機能に何を任せ、何を人に残すかをこの場で決め直します。

導入前に確かめる項目

外部の基盤に監査の一部を任せる前に、次の項目を提供元と社内の両方で確かめます。

• 一覧の見つける機能が、自社が使うクラウド、コードの保管庫、業務のクラウドサービスにつながるか
• 見つける機能が、どの権限で自社の環境を読むか。読み取りだけか、変更の権限まで求めるか
• 検査のために、自社のAIへの問いと答え、学習データのどこまでが基盤に送られるか。保存の場所と期間
• 標準の検査に、自社の業務に特有の問いを足せるか
• 国内の法令や指針への対応づけが用意されているか。無ければ自社で持つ範囲
• 承認の流れに、自社の判定者と例外の期限を設定できるか
• 見張りのエージェントが自動で止める範囲を、自社で絞れるか
• 契約を終えたときに、監査の記録を取り出せる形式と期間
• 日本語の画面と問い合わせへの対応の有無

これらのうち、2026年10月時点の公式サイトで確かめられたのは、連携先の例と、検査・監視・承認・記録の機能があることまでです。読む権限の範囲、送られるデータ、保存の期間、日本語への対応は、公式の公開情報からは確かめられませんでした。確かめられなかった項目は、提供元に書面で答えてもらってから判断します。費用は個別の見積もりで、監査の対象にするAIの数と使う機能の範囲で増えると見ておきます。

まとめ

AIの監査が止まるのは、一覧が現物とずれる、中身が変わっても検査をやり直す引き金がない、結果を判定する人が決まっていない、の3つが重なるときです。Holistic AI は、AIの発見と一覧、偏りや頑健性などの検査、規制への対応づけ、承認と記録を1つの基盤で回す製品で、このうち繰り返しの作業を引き受けます。検査の実行と集計、条文との突き合わせの下読みは基盤に任せ、合否の判定、例外の承認、経営への報告、判断の記録は人が持つ。何も出なかったことを安全の証明にしない。この線を決めてから、基盤に任せる範囲を広げてください。

• 製品の機能・提供状況・Gartner の評価は、Holistic AI の公式サイト、公式ブログ（2026年7月7日）、プライバシーポリシーを2026年10月19日に確かめた範囲に基づきます。Gartner の評価は提供元の発表によるものです。機能や条件は更新されることがあるため、利用前に最新の原文を確かめてください
• 監査の進め方の記述は、英国政府の科学・イノベーション・技術省の事例集（2023年9月）に基づきます。規制への対応の判断は、実際の運用にあたって法務の担当者と確かめてください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。