ガバナンスとはAIシステムが「何をすべきか」を決定するものであり、クオリティエンジニアリングとはAIシステムがそれを実行していることを「どのように確認するか」を決定するものだ。筆者が協働する企業において、前者は資金が投入されているものの、後者は当然できているものと想定されているにすぎない。両者の間に生じるギャップは、ポリシーをコードへと落とし込まなければならない一つの局面で露呈する。
筆者は20年にわたりテクノロジー製品の構築、販売、サポートに携わり、ここ数年は各チームがエージェントを本番環境に投入する様子を見てきた。筆者が目にするポリシーは固定的なルールである。挙動は一貫していなければならず、出力は正確でなければならず、人間が介入できなければならない。その一方で、ソフトウェアを生成する側は四半期ごとに高速化しているが、それを検証する側は追いついていない。
グラントソントンの「2026年AI影響度調査（2026 AI Impact Survey）」では、米国の経営幹部950人に対し、自社のAIガバナンスが90日以内の外部監査に耐えられるかを尋ねたところ、78%が強い確信を持って「耐えられる」とは答えられなかった。同社はこの不足を「AI証明のギャップ（AI proof gap）」と呼んでいる。
AIガバナンスが証明を求めるもの
調達時のアンケートに登場するフレームワークは、相違点よりも共通点の方が多く、それぞれ検証可能な核（コア）を持っている。
米国国立標準技術研究所（NIST）の「AIリスクマネジメントフレームワーク（RMF）」には4つの機能があり、そのうちの1つが「測定（measure）」である。これこそテストチームが日々行っていることそのものだ。EU AI法の高リスク規則から法律用語を取り除けば、残るのは受入基準（アクセプタンス基準）だ。すなわち、介入できる人物の存在、維持される精度、負荷下での堅牢性、後から誰かが確認できる記録である。
公平性や透明性を含む責任あるAIの原則は、出力に対して実行できるチェック項目である。環境・社会・ガバナンス（ESG）でさえテストラボの領域に含まれる。なぜなら、変更ごとにあらゆるテストを再実行するスイート（テスト群）は、そのままコンピューティングの請求額に反映されるからだ。
したがって、機能するガバナンスのフレームワークには3つの層が存在する。ルールを定める「ポリシー」、ルールが維持されたことを示す「証拠」、そしてルールが守られなかった場合にリリースを停止する権限を持つ「責任者」だ。リスク階層によって、投じる労力は適切に配分される。
社内の下書き作成アシスタントであれば軽微なチェックで十分だ。しかし、返金処理を実行したり申請を却下したりできる顧客向けのAIエージェントには、継続的に実行される完全なテストスイートが必要であり、すべてのリリースにその結果が添付されなければならない。
堅牢なAIガバナンスフレームワーク
セキュリティ、法務、オブザーバビリティ（可観測性）の各チームは、検証における回答の一部をそれぞれ担っている。「挙動（振る舞い）」はテストが担う領域であり、筆者の経験上、次の4つの実践によってその大部分をカバーできる。
1. 固定されたベースラインに対する回帰テストから始める
ベースラインは、正常な応答が既知である代表的なケースのセットとし、定期的に実行して前回の実行結果と比較すべきだ。実行スケジュールは見た目以上に重要である。モデルプロバイダーが新しいバージョンをリリースした際、自社側でコードのコミットが行われなければ、何も実行されず警告も出ない。スケジュールされた実行があれば日付が得られる。それがなければ、最初のシグナルは通常、顧客からのクレームとなって現れる。
2. 受入基準には署名（責任者の明記）が必要
筆者が読んできたAIポリシーの多くには「出力は正確でなければならない」といった文言が含まれており、取締役会へのプレゼンテーションでは聞こえが良いものの、エンジニアがテストする上では手がかりに乏しい。実用的な基準とは、何を測定するのか、クリアすべき基準値、そしてそれを満たさなかった場合に誰がリスクを負うのかを明記したものだ。多くのチームがこの3つ目の要素を省略しがちだ。名前が特定されていない閾値（しきい値）は、リリースが遅れた際に曖昧になりやすい。
3. カバレッジはエージェントが実行できるアクションに対応させる
エージェントが実行できるすべてのアクションを洗い出し、そのうちどれにテストが用意されているかをチームに尋ねてほしい。2つ目のリストはほぼ例外なく短くなり、その差分こそがガバナンスが破綻する場所となる。人間へのエスカレーションは、筆者が最もテストされていないと感じるパスである。
4. ゲート（関門）にはリリースを停止する権限を持たせる
統制（コントロール）が失敗した場合は、デフォルトでリリースをブロックすべきだ。例外の適用は、それぞれに責任者の名前と有効期限が紐付いているのであれば問題ない。有効期限のない例外は溜まり続け、最終的にはゲートがすべてのリリースを通過させてしまうことになる。
ポリシーから証明へ：監査人に提出できる統制手段
筆者らは長年、AIネイティブなテストツールの構築に取り組んできた。これは、多くの顧客が自社のAIについて尋ねてくる以前から、自社のAIを統治していたことを意味する。上記に挙げた参照基準、すなわちNISTの機能、EU AI法の高リスク義務、出力チェックとしての責任あるAIの原則、そしてESGレビュー担当者が利用できるレポート機能に準拠して構築を行ってきた。
筆者らのエージェントテスト製品も同じ原則を適用している。AIエージェントが、実際のユーザーのように顧客のチャット、音声、動画エージェントをテストし、エージェント自身の要約ではなく「実際に何が起きたか」に基づいて挙動を評価する。検証できなかった事項は合格率に含めず、個別に報告する。検証できない内容を隠した合格率とは、緑信号（安全のシグナル）に偽装した証明のギャップにほかならない。
これを構築したことで、筆者があらゆる検証体制に求めるもの（そして読者にも求めることを勧めるもの）が定まった。
・すべての統制手段に責任者の名前が紐付いていること。これには直近の判定結果も含まれ、エージェントの挙動に対する説明責任の所在が明確になる。
・各実行が、筆者らが同席しなくとも外部の第三者が再構築できる記録として残ること。これには、入力された内容、エージェントが行ったこと、満たされた基準、誰にも確認できなかった項目が含まれる。これこそが、テストの副産物として生成されるEU AI法が求める記録保持である。
・敵対的な入力やツールの不正利用が標準スイートに含まれていること。これにより、堅牢性はリスク登録簿上の記載事項から、日付の入った実績へと変わる。
・スイートがリリースパイプライン内で実行されること。これにより、単体テスト（ユニットテスト）が失敗した場合と同様に、統制手段の失敗がリリースをブロックできるようになる。
これこそが「証明できるガバナンス」であり、筆者がベンダーと契約を交わす前に実証を求めるポイントである。
証明可能なガバナンス
エージェントは収益や顧客に直結する業務領域へと移行しつつあり、その段階において品質は単なる開発上の懸念事項にとどまらなくなる。前述の調査においてグラントソントンは、AIを完全に統合した企業の58%がAIに関連する収益増加を報告したのに対し、パイロット運用（実証実験）にとどまっている企業ではわずか15%であったことを明らかにした。
証明とパフォーマンスは表裏一体だが、どちらが一方を牽引しているのかはまだ定かではない。
