BroadcomのVMware Tanzu『Auditable Agent Governance』はなぜPrivate AI Cloud企業に重いのか――オンプレ推論基盤でも外部モデル並みの操作ログが必要になる理由
BroadcomのVMware Tanzuが示した「監査されるAIエージェント」という前提
社内に閉じたAI基盤なら、外部APIより安全だ。そう考えてPrivate AI Cloudやオンプレ推論基盤を選ぶ企業は少なくありません。
ただ、AIがチャット回答だけでなく、検索、要約、承認補助、システム操作まで担う“エージェント”に近づくほど、問われるのはモデルの配置場所ではなく、何を見て、何をして、何を出したかです。
Broadcomは2026年9月公表のTanzu関連発表で、VMware Tanzu PlatformのAI向け機能として「Auditable Agent Governance」に言及しています。ここがPrivate AI Cloud企業にとって重く見えるのは、単なる運用機能の追加ではなく、AIの判断経路と実行履歴を企業側が説明できる状態を重視しているように読めるからです。
VMware Tanzu全体の製品文脈を見ても、対象は単なる推論実行基盤ではなく、Private AI Cloud上で動くアプリケーションやエージェントの運用基盤です。そのため、監査対象もモデル単体では完結しません。
「閉じたAIなら安全」が通用しにくくなる理由
結論から言えば、オンプレAIが安全に見えるのは「データが外に出にくい」という一面に限った話です。実際の業務で問題になるのは、AIがどの文書を参照し、どの権限で、どんな判断を経て、どの操作候補を出したかという一連の行為です。
たとえば社内LLMが、人事文書を検索し、ナレッジベースを読み、申請システムに下書きを返す場合を考えてみます。このとき重要なのは、モデルが社内サーバー上にあることより、どの情報源にアクセスし、誰の権限を前提にし、結果として何を実行させたかを追えることです。
NISTのAI Risk Management Frameworkも、AIリスク管理を設計、開発、展開、利用、評価まで含むライフサイクル全体で捉える考え方を示しています。オンプレか外部APIかより先に、説明可能な運用状態をどう作るかが問われるわけです。
Auditable Agent Governanceが見るのはモデル精度ではなく実行された行為
このテーマで最も重要なのは、監査対象が「モデル品質」だけでは足りないという点です。Auditable Agent Governanceという言葉が示すのは、正答率の管理ではなく、AIエージェントが行った一連のアクションを後から検証できる状態です。
少なくとも、監査のためには次のような情報が必要になります。
- どのユーザー要求が起点だったか
- どのプロンプトやシステム指示が使われたか
- どの文書やDB結果を参照したか
- どのツールやAPIを呼び出そうとしたか
- 最終的に何を出力し、何が実行されたか
これは従来のアプリ監査ログに似ていますが、AIでは中間過程が増えます。RAGで引いた文書、ツール選択、再試行、要約後の変形などが入るため、単なるアクセスログでは説明しきれません。
加えて、上級読者が検討すべきなのは、操作ログの保存先、エージェントごとのレート制御、異常時に停止を判断する責任者を、モデル運用とは別に定義することです。VMware基盤責任者、インフラアーキテクト、MLOps責任者、内部監査担当者で見たい粒度が違うため、ここを曖昧にするとAuditable Agent Governanceは機能よりも負担に見えやすくなります。
OpenTelemetryはクラウドネイティブ向けのオブザーバビリティ基盤として、トレース、メトリクス、ログの収集と出力を標準化する枠組みです。AIワークフロー監査との接続は、その延長線上で考えやすい論点です。
Private AI Cloud企業にとって重いのは機能追加ではなく責任範囲の拡張
Private AI Cloudの担当者にとって重いのは、「ログを増やすのが大変」という技術的負荷だけではありません。より本質的には、外部ベンダーに一部委ねていた説明責任を、自社の基盤運用へ引き取る必要が出ることです。
外部の生成AIサービスを使う場合、モデル更新、一定の安全対策、操作記録の一部はベンダーの管理範囲にあります。一方でオンプレ環境では、モデル提供元、推論基盤、ベクトルDB、検索コネクタ、業務ツール連携、認可設計まで、分散した責任を自社が束ねなければなりません。
つまり「データ主権が高い」ことと「運用責任が軽い」ことは別です。むしろ自前化するほど、証跡保存、再現性、インシデント調査、監査部門への説明は重くなります。
Kubernetes中心で運用している企業であっても、基盤レイヤーの標準化だけでは十分ではありません。Kubernetes自体も監査ログの設計と運用を前提にしていますが、AIではその上のアプリ層やツール呼び出し層まで追わなければ、説明責任を果たしにくくなります。
Auditing allows cluster administrators to answer the following questions:
what happened? when did it happen? who initiated it? on what did it happen? where was it observed? from where was it initiated? to where was it going? Audit records begin their lifecycle inside the kube-apiserver component. Each request on each stage of its execution generates an audit event, which is then pre-processed according to a certain policy and written to a backend. The policy determines what's recorded and the backends persist the records. The current backend implementations include logs files and webhooks.
Kubernetes
オンプレ推論基盤でも外部モデル並みの操作ログが必要になる理由
理由はシンプルです。リスクの発生源が「外部接続」ではなく「AIによる代理行為」へ移っているからです。たとえ外部送信がゼロでも、AIが社内システムに対して提案、検索、要約、更新を行うなら、監査の深さは外部モデル利用時と同等か、それ以上に求められます。
たとえば購買部門向けエージェントが、過去の契約書を検索し、取引条件を要約し、稟議文を自動作成したとします。ここで誤った契約条項を混ぜた場合、あとから必要になるのは「モデルが間違えた」という説明ではありません。どの文書を根拠にし、誰の依頼で、どのバージョンの設定で出力したのかという操作履歴です。
このため、オンプレ推論基盤でも、少なくとも参照系、更新系、外部連携系でログ粒度とレート制御の考え方を分ける必要があります。読み取り中心の社内エージェントと、レコード更新や外部送信を伴うエージェントでは、停止判断の厳しさも同じにはできません。
EU AI Actは2024年8月1日に発効しました。条文全体の適用は一律ではなく個別確認が必要ですが、記録保持や透明性、情報提供への関心が制度側でも強まっている方向性は押さえておくべきです。
RAGと社内ツール連携で監査不能になりやすい箇所
実務で最も危ういのは、RAGと社内ツール連携が組み合わさったケースです。RAGは便利ですが、「参照した情報」と「最終出力」の間に変換が入るため、証跡を残していないと因果関係が見えにくくなります。
典型的な監査不能ポイントは、次のようなものです。
- 検索結果に本来見せるべきでない文書が混ざった
- 権限継承の設計が曖昧で、代理参照が起きた
- 古い文書を根拠に回答したが、更新履歴を追えない
- ツール実行前の確認プロセスが残っていない
- 出力だけ保存され、中間の判断経路が消えている
たとえば社内ヘルプデスクAIが、退職者向け手順書を現役社員に適用してしまうケースは起こり得ます。このとき必要なのは、回答本文の保存だけではなく、検索クエリ、ヒットした文書、ランキング順、最終採用された根拠、実行可否判定までの記録です。
RAGは外部知識を参照してLLM出力を補強する考え方ですが、裏返せば、どの知識を引いたかの追跡ができなければ本番運用での監査性は弱くなります。
Amazon Web Services, Inc.監査を後付けの足かせではなく運用設計の前提にする
ここで差が出るのは、監査を後付けの足かせと見るか、運用可能なAI基盤の前提と見るかです。PoCの段階では回答精度ばかり見がちですが、本番運用では「何を残すか」の設計が先に必要です。
最低限、残すべきなのは、ユーザー要求、システムプロンプトの版、参照データID、ツール呼び出し履歴、権限コンテキスト、最終出力、承認有無です。すべてを生ログで永久保存する必要はありませんが、再現性と説明責任を満たす粒度は決めておくべきです。
機械学習やAIの運用管理でも、継続的デリバリーや自動化だけでなく、プロセスの標準化と追跡可能性が重要な論点として整理されています。AI基盤を社内に持つ企業ほど、この発想を推論運用とエージェント運用にまで広げる必要があります。
Google Cloud Documentation
運用面では、AI基盤チーム、セキュリティ、法務・監査、業務部門を早めに巻き込むほうが失敗しにくいはずです。あとから監査ログを足すと、コネクタ設計や権限制御を作り直すことが多いからです。
Private AI Cloudの成熟度は、GPU枚数やモデルサイズだけでは測れません。後から説明できる運用フローをどれだけ先に埋め込めるかで、基盤の実力差が出る段階に入っています。
検討段階では、社内エージェントを参照、更新、外部連携の3段階に分け、操作ログ保存先、レート制御、停止判断者を整理した監査運用表を作成してみると、Auditable Agent Governanceがなぜ重いのかを機能論ではなく責任分界として把握しやすくなります。