一律のガバナンスがエンタープライズAIエージェントを失敗させている
Google Newsは企業に向けた厳しい警告を取り上げた。一律のガバナンスは、AIエージェントの安全性や有用性、あるいはその両方を損なう可能性がある。Techzine Globalが紹介したJFrogの分析は、深刻な運用上の影響を伴うGartnerの予測を踏まえたものだ。
Gartnerは、2027年までに企業の40%が自律型AIエージェントを格下げ、または廃止すると予測している。同社は、ガバナンスの欠陥が本番環境でインシデントが起きた後になって初めて表面化すると見込む。この予測は、ガバナンスを単なるコンプライアンス業務から、導入上のリスクへと変える。
対立軸はガバナンス対イノベーションではない。一律の統制対、影響に見合った統制だ。調査支援エージェントと自律的な決済エージェントは、同じリスクを生まない。それにもかかわらず、多くの組織は依然として両者に同一の審査プロセス、権限、監視ルールを適用している。
このアプローチは、相反する二つの失敗をもたらす。過剰な統制は低リスクのツールの導入を遅らせる。弱い一般的統制は、高い影響力を持つエージェントに、組織が安全に監督できる範囲を超えた権限を与えてしまう。
新たに浮上している代替案は、自律性、アクセス権、想定される影響に応じて統制を割り当てるものだ。また、すべてのモデル、ツール、プラグイン、スキル、接続を、ガバナンス対象のソフトウェアコンポーネントとして扱う。
Google Newsの記事が実際に変えたこと
重要な変化は、一律のガバナンスとAIエージェント導入の失敗をGartnerが明確に結び付けた点にある。
Gartnerは2026年5月26日にこの警告を発表した。すべてのエージェントに同じガバナンスモデルを適用すれば、エージェントごとに権限と適用範囲が異なるため、失敗につながると論じた。
この区別は一見すると当然に思えるが、企業ポリシーではしばしば見落とされる。多くのプログラムは、単一の利用許容ポリシー、単一の審査委員会、単一のセキュリティチェックリストから始まる。こうした統制は通常、生成AIを広いカテゴリーとして扱う。
エージェントはこの構造を複雑にする。AIエージェントとは、目標に向けて手順を計画し、ツールを選択し、行動を実行できるシステムである。したがって、その振る舞いは基盤モデルだけで決まるものではない。
基本的な要約エージェントは、文書を読み、テキストを生成するかもしれない。ソースファイルの変更、メッセージの送信、コードの実行はできない。その最も起こり得る失敗は、不正確または誤解を招く回答だ。
カスタマーサービス・エージェントは、アカウントデータの閲覧、記録の更新、クレジットの付与、ユーザーへの連絡を行う可能性がある。その誤りは、金銭、プライバシー、契約上の義務、顧客の信頼に影響し得る。
インフラストラクチャ・エージェントは、さらに大きなリスクをもたらす。クラウドリソースの変更、アクセスポリシーの修正、コードのデプロイ、セキュリティアラートへの対応を行うかもしれない。一つの誤った操作が、接続されたシステム全体に広がる可能性がある。
「AIエージェント」という単一のラベルは、こうした違いを覆い隠す。単一の統制パッケージは、それをさらに覆い隠す。
Gartnerのガバナンスに関する警告は、エージェントの自律性とアクセス範囲を分けている。どちらの次元も重要だ。
自律性は、エージェントがどの程度独立して手順を選び実行できるかを示す。範囲は、到達できるシステム、データ、業務プロセスを示す。エージェントは一方の次元で高く、もう一方で低いことがある。
例えば、使い捨てのテスト環境内で高度に自律的に動くエージェントは、事業リスクが限定的かもしれない。一方で、自律性が低いエージェントでも、本番の決済アクセスを持つ場合は厳格な統制が必要になり得る。
Google Newsの検索結果が重要なのは、実際のリスクに基づくガバナンスモデルを示しているからだ。もはや問うべきなのは、組織が「エージェントを許可するか」ではない。
リーダーは、各エージェントが何を観測し、判断し、変更できるのかを問わなければならない。また、それらの操作を元に戻せるかどうかも判断する必要がある。
こうした問いは、ガバナンスをエンジニアリングに近づける。ポリシーチームは引き続き許容可能なリスクを定義するが、技術システムは開発時と本番環境でその制限を強制しなければならない。
したがって、この変化は構造的なものだ。企業のAIガバナンスは、承認時に適用される文書のままではいられない。アイデンティティ、権限、依存関係、行動、結果に結び付いた継続的な統制システムへと進化しなければならない。
一つのポリシーが二つの異なる失敗を生む理由
一律のガバナンスが失敗するのは、同じ制約があるエージェントには過剰で、別のエージェントには危険なほど不十分になり得るためだ。
第一の失敗は、業務上の停滞だ。低リスクの社内アシスタントが、財務記録の変更を許可されたエージェントと同じ承認プロセスを受ける可能性がある。
その審査には、法務、プライバシー、サイバーセキュリティ、モデルリスク、調達、アーキテクチャの各チームが関与する場合がある。各グループは、組織内で最も機微なシステム向けに設計された証拠を求めるかもしれない。
このプロセスは、重大な影響を伴う導入には理にかなっている。しかし、エージェントが公開文書を要約するだけ、あるいは人間のレビュー用テキストを下書きするだけなら、不釣り合いになる。
長い承認サイクルが常に導入を止めるとは限らない。導入を承認済みのチャネルの外へ移してしまうことがある。従業員には依然として締め切り、反復作業、利用可能なツールを使う圧力がある。
結果として生じるのが、中央からの可視性なしに使われる未承認システム、いわゆるシャドーAIだ。厳格で一律のポリシーは、正式な導入を減らす一方で、把握できない導入を増やす可能性がある。
第二の失敗は、システム全体へのリスクだ。一般的なチェックリストでは、高い影響力を持つエージェントの具体的なツール、認証情報、障害経路、エスカレーション動作をテストせずに承認してしまう可能性がある。
請求書を読めるエージェントと、支払いを承認できるエージェントは異なる。クラウド変更を下書きするエージェントと、それを自動デプロイするエージェントも異なる。
広範なポリシー文言では、こうした境界を捉えられることはほとんどない。「人間による監督」のような表現も、どこで承認が行われ、審査者がどの証拠を受け取るのかを示さなければ意味をなさない。
すべての操作を承認する人間は、形式的な承認者になり得る。例外的な操作だけをレビューする人間には、例外を識別するための信頼できる基準が必要だ。
タイミングも重要だ。不可逆な操作の後に行われる承認は、意味のある監督ではない。インシデント後の監査は被害を説明できても、その被害を防ぐことはできない。
JFrogのエージェント・ガバナンス分析は、この問題を包括的な制限と影響に見合った統制の選択として位置付けている。その主張は、ソフトウェアサプライチェーンの観点を反映している。
この観点が有用なのは、エージェントが変化し続ける複数のコンポーネントで構成されるからだ。チームは今日エージェントを承認しても、明日にはモデル、プロンプト、プラグイン、ツールを更新する可能性がある。
あらゆる変更が振る舞いを変え得る。新しいツールはアクセス範囲を広げる可能性がある。改訂されたプロンプトは判断の優先順位を変える可能性がある。依存関係の更新は脆弱なコードを持ち込む可能性がある。
一律のガバナンスは、承認済みエージェントを安定した対象として扱う。実際には、導入されたシステムは変化するソフトウェアスタックに近い振る舞いをする。
したがって、承認モデルは変更を考慮しなければならない。無害な更新に、新しい決済機能と同じプロセスを適用すべきではない。ただし、意味のある変更を見過ごしてはならない。
これには明確な閾値が必要だ。チームは、どの変更に自動テスト、セキュリティレビュー、事業部門の承認、または新たなリスク評価が必要かを把握する必要がある。
中心的な問題は、書類作業の不足ではない。統制の解像度が低いことだ。
すべてのエージェントを同等と見なすとき、ガバナンスの解像度は低い。権限、データの機微性、可逆性、運用上の到達範囲を区別するとき、有用な解像度を得る。
真の分岐点は読み取りアクセスと行動権限の違いにある
エージェントが会話ウィンドウの外にある世界を変えられるようになると、ガバナンスは実質的に難しくなる。
従来のチャットボットは主にコンテンツを生成する。ユーザーはそのコンテンツを信頼するか、行動に移すかを決める。この分離は、自然な承認境界を生む。
エージェントはその境界を取り払うことができる。ツールを選択し、APIを呼び出し、アプリケーションを更新し、人が各手順を承認しなくても作業を続けられる。
この能力は、手作業による引き継ぎを減らすため価値を生む。同時に、失敗の地点を画面上の回答から業務プロセス内の操作へ移す。
企業における三つのシナリオを考えてみよう。
調査エージェントは承認済み文書を読み、市場サマリーを下書きする。外部コミュニケーション用ツールは持たない。配布前に人が結果を確認する。
営業エージェントは顧客記録を読み、フォローアップタスクを作成し、メッセージを下書きする。顧客関係プラットフォームに書き込めるが、外部コミュニケーションを送信することはできない。
収益管理エージェントは、サブスクリプションの状態を変更し、クレジットを適用し、顧客通知を送る。直接的な財務上・評判上の影響を生み得る。
これらのシステムは同じ基盤モデルを使うかもしれない。それでも、ガバナンス要件は大きく異なるべきだ。
第一のエージェントには、ソースアクセス、データ漏えい、事実の正確性に関する統制が必要だ。第二のエージェントには、加えて書き込み制限、レコード単位の権限、変更ログが必要になる。
第三のエージェントには、取引上限、承認ゲート、ロールバック手順、職務分離、迅速な停止機能が必要だ。特定の管轄区域に結び付いたコンプライアンスレビューも必要になる可能性がある。
これが影響に見合ったガバナンスだ。エージェントがより重大な信頼境界を越えるにつれて、統制も強化される。
この原則はすでに確立されたフレームワークにも見られる。NIST AI RMFは、ガバナンス、マッピング、測定、管理の機能を通じてリスク対応を整理している。
NISTは、これらの機能を万能のチェックリストとして提示していない。そのガイダンスは、組織に対し、リスク管理を文脈、目標、法的要件、リスク許容度に整合させるよう求めている。
同フレームワークのマッピング機能は、特に関連性が高い。チームは、エージェントの想定タスク、影響を受ける関係者、運用条件、起こり得る障害モードを理解するまで、適切な統制を選べない。
欧州連合も関連する考え方を採っている。AI Actは、リスクカテゴリーとユースケースに応じて異なる義務を定めている。
AI Act guidanceは、許容不可能なリスク、高リスク、透明性リスク、最小リスクのシステムを区別している。すべてのAIアプリケーションを同一に規制するものではない。
企業のガバナンスには、より詳細なレベルで同様の差別化が必要だ。規制上の分類は一つの境界を与えるが、社内の運用リスクには追加の層が必要になる。
二つのエージェントは高リスクの法的カテゴリーに該当しない場合でも、非常に異なるサイバーセキュリティ上のリスクを生む可能性がある。一方は公開情報にアクセスするだけかもしれないが、もう一方は内部システムの認証情報を保持しているかもしれない。
アイデンティティは中心的な統制となる。各エージェントには、開発者のアカウントを借用したり、広範なサービス認証情報を共有したりするのではなく、固有の非人間アイデンティティを持たせるべきだ。
権限は最小権限の原則に従うべきである。これは、定義されたタスクに必要なアクセスだけを付与し、不要になった時点で削除することを意味する。
組織には操作レベルのポリシーも必要だ。アプリケーションへのアクセスが、その中のあらゆる操作を自動的に許可するべきではない。
エージェントには、チケットを読み、内部メモを追加し、ステータス変更を提案する権限が必要かもしれない。しかし、チケットを閉じたり履歴を削除したりする権限は必要ないかもしれない。
この区別により、制御可能な操作面が生まれる。また、ログに各操作を要求したアイデンティティが示されるため、監査の有用性も高まる。
すべてのエージェントはソフトウェアサプライチェーンでもある
モデルはエージェントの実行経路における一つのコンポーネントにすぎないため、ガバナンスはモデル承認で終わることはできない。
現代のエージェントは、モデル、プロンプト、メモリ、検索システム、ツール、プラグイン、API、オーケストレーションコードを組み合わせて構成される。各コンポーネントは、エージェントが何を知り、何を行うかを変え得る。
モデルが妥当な計画を生成することはある。それでも、侵害されたツールが有害な処理を実行する可能性はある。安全なツールであっても、過剰な権限で構成されれば危険になり得る。
一般にMCPと呼ばれるModel Context Protocolは、この課題をよく示している。MCPは、AIアプリケーションがデータソースや実行可能なツールに接続するための標準的な方法を提供する。
この標準化により、独自統合にかかる作業を減らせる可能性がある。一方で、外部ソースから取得したパッケージやサーバーを通じて、新たな機能を容易に追加できるようにもなる。
接続が容易になると、ガバナンスの問題も変わる。セキュリティチームはエージェントのモデルを承認していても、ソースコードや認証情報へアクセスできる新たに追加されたMCPサーバーを見落とす可能性がある。
プラグインやスキルも同様の懸念を生む。これらにはスキーマ、指示、スクリプト、認証スコープ、依存関係の連鎖が含まれる場合がある。各要素がシステムの振る舞いを拡張する。
従来のソフトウェアプログラムは明示的なコードパスに従うが、複雑なシステムではなお予期せぬ動作が起こり得る。エージェントでは、実行時にそれらのパスから選択するモデル主導の意思決定が加わる。
これはエージェントの保護が不可能であることを意味しない。コンポーネントの棚卸しと実行時の観測が不可欠になるということだ。
組織には、導入済みのすべてのエージェントについて部品表が必要だ。その記録には、モデル、プロンプト、ツール、プラグイン、パッケージ、コンテナ、データソース、外部サービスを特定できる情報を含めるべきである。
各コンポーネントには所有者とバージョンを設定すべきだ。チームは、誰が承認したのか、どのテストに合格したのか、どのシステムに到達できるのかを把握していなければならない。
依存関係の管理は重要である。更新によって、エージェントの公開名を変えずに振る舞いが変わる可能性があるためだ。プラグインの新バージョンが新たな権限を要求したり、脆弱なライブラリを導入したりすることもある。
成果物は信頼できるリポジトリを経由させるべきだ。これにより、導入前にセキュリティチェックでパッケージ、コンテナ、設定ファイルをスキャンできる。
同じ規律はプロンプトとポリシーにも適用すべきである。これらは従来の意味で実行可能なコードではないが、変更によってエージェントの振る舞いが大きく変わる可能性がある。
プロンプトの更新により、エージェントへレビューより速度を優先するよう指示されるかもしれない。ポリシーの更新により、取引額が一定の閾値未満であれば自動実行が許可されるかもしれない。
どちらの変更にも、バージョン履歴とテストが必要である。必要なレビューはファイル形式ではなく、その影響に見合うものであるべきだ。
OWASPのエージェント向けガイダンスは、目標、ツール、メモリ、アイデンティティ、マルチエージェントの相互作用から生じるリスクを説明している。これらのリスクは、不正確なモデル出力にとどまらない。
目標の操作は、エージェントを攻撃者の目的へと誘導し得る。ツールの悪用は、正当な機能を攻撃経路へ変えてしまう可能性がある。
メモリポイズニングは、保存されたコンテキストを通じて後続の意思決定に影響を与え得る。過剰な自律性は、エージェントがユーザーの意図を超えた行動を取ることを許しかねない。
これらの脅威には異なる統制が必要だ。入力フィルタリングだけでは、侵害された依存関係を防げない。モデル評価だけでは、過剰な権限を持つサービスアカウントを検出できない。
だからこそ、比例的なガバナンスも成果物中心でなければならない。リスク分類が必要な統制を決め、成果物管理がそれらの統制を実効可能なものにする。
モデルは、エージェントが何について推論できるかを決める。ツールと認証情報は、その推論が何に影響を及ぼせるかを決める。
比例的なガバナンスには、ラベルではなく証拠が必要
リスク階層は、チームが実際の実行時に統制が機能することを証明できなければ、ほとんど価値がない。
組織はしばしば、低・中・高リスクといった分類を作成する。これらのラベルに測定可能な基準がなければ、その作業はまた別の画一的なチェックリストになり得る。
有用な階層は、自律性から始まる。チームは、そのエージェントが行動を推奨するだけなのか、承認を要するのか、独立して実行するのかを文書化すべきだ。
次の次元はアクセスである。これには、データの機密性、許可されたシステム、操作の種類、地理的境界、影響を受けるユーザーが含まれる。
第三の次元は結果である。チームは、不正確な、悪意ある、または利用不能な振る舞いによる損害を見積もるべきだ。
可逆性も重要な次元となる。下書きは破棄できる。内部記録は多くの場合復元できる。公開情報の開示や資金移動は、元に戻すことが難しい可能性がある。
速度もリスクを変える。毎日、レビュー済みの行動を1回実行するエージェントと、毎時数千件の変更を行うエージェントでは、封じ込めの課題が異なる。
これらの次元は、具体的な統制につながるべきである。
低リスクの読み取り専用エージェントには、承認済みソース、データ損失防止策、出力レビュー、基本的なログ記録が必要かもしれない。リリースプロセスは軽量に保てる。
書き込み可能な中リスクのエージェントには、スコープを限定した認証情報、アクションログ、自動テスト、利用制限、機微な操作に対する承認が求められる可能性がある。
高リスクの自律型エージェントには、より強力な分離が必要だ。統制には、取引制限、独立した認可、継続的な監視、緊急停止、テスト済みのロールバック手順を含められる。
組織は次に、これらの統制を検証しなければならない。エージェントが最小権限を使用しているという文書上の記述は、その認証情報で実際に何ができるかを示さない。
テストでは、禁止された操作を試みるべきだ。エージェントが未承認の記録、ツール、環境に到達できないことを確認すべきである。
チームは間接経路もテストすべきだ。エージェントに支払いを直接変更する権限がなくても、その変更を実行するワークフローを起動できるかもしれない。
実行時テレメトリーは、次の証拠層を提供する。ログには、エージェントのアイデンティティ、選択したツール、パラメータ、結果、承認状態を記録すべきだ。
機微なデータには、ログ内でも慎重な取り扱いが必要である。監視が、機密情報や認証情報の新たな流出源になってはならない。
行動ベースラインは異常な活動の検出に役立つ可能性があるが、明示的なポリシーの代わりにはならない。新しいエージェントの振る舞いが常に悪意あるとは限らず、見慣れた振る舞いが常に安全とも限らない。
決定論的な統制は、明確に禁止された行動を遮断すべきだ。行動分析システムは、調査に値する予期せぬパターンを特定すべきである。
懐疑的な問いは、企業がこの詳細さを数千のエージェントにわたって維持できるかどうかだ。比例モデルには、一律禁止よりも充実した棚卸し、所有責任、監視が求められる。
不適切な実装は、階層の水増しを生む可能性がある。チームは遅延を避けるためにすべてを低リスクに分類したり、個人的な責任を避けるためにすべてを高リスクに分類したりするかもしれない。
したがって、事業責任者も参加しなければならない。セキュリティチームは脅威を理解しているが、プロセス責任者は財務、顧客、運用への影響を理解している。
エージェントの所有者は、導入後も説明責任を負うべきだ。所有責任には、インシデントのレビュー、重大な変更の承認、エージェントが依然として有効な目的を果たしていることの確認が含まれる。
ガバナンスにも期限を設けるべきだ。権限と承認には、無期限に有効な状態を維持するのではなく、レビュー日を設定すべきである。
最も強力なモデルは、摩擦を伴わない統制ではない。結果が正当化する場所に摩擦を置くことである。
Google Newsの読者が次に注目すべきこと
次の試金石は、企業がリスクベースの原則を実効可能な運用統制へ転換できるかどうかだ。
最初のシグナルは、エージェントの棚卸しの質である。組織は、特定できないシステムを統治できない。
信頼できる棚卸しには、承認済みのエージェント、ベンダー製品に組み込まれたエージェント、社内プロトタイプ、従業員アカウントを通じて接続された外部サービスを含めるべきだ。
発見は調達記録を超えなければならない。エージェントは、ブラウザー拡張機能、SaaS機能、開発者向けパッケージ、ワークフローツール、クラウドマーケットプレイスを通じて入り込む可能性がある。
第二のシグナルは、アイデンティティの分離である。成熟した導入では、本番環境の各エージェントに、狭く監査可能な権限を持つ固有のアイデンティティが付与される。
共有アカウントは引き続き警告サインとなる。責任の所在を曖昧にし、他のサービスを中断せずに1つのエージェントだけを停止することを難しくするからだ。
第三のシグナルは、アクションレベルの可視性である。企業は、エージェントがどの操作を試み、どの操作をポリシーが遮断し、どの操作を人間が承認したかを把握すべきだ。
モデル利用状況を示すダッシュボードだけでは不十分である。トークン数からは、エージェントがデータベースのフィールドを変更したのか、業務取引を開始したのかは分からない。
MITREのATLAS knowledge baseは、AI対応システムに対する敵対的な戦術の有用な参照先となる。進化する技法は、脅威モデルが実際のシステムの振る舞いに追随しなければならない理由を示している。
組織は、エージェント階層ごとに本番インシデントも追跡すべきだ。その証拠により、統制が比例的なのか、単に都合がよいだけなのかが明らかになる可能性がある。
低リスクのエージェントが意味のある安全上の利益なしに長い遅延に直面しているなら、ガバナンスは依然として制限が厳しすぎる。高リスクのインシデントが導入後に表面化するなら、統制は依然として弱すぎる。
指標には、承認遅延、遮断されたアクション、ロールバック頻度、ポリシー例外、未承認ツール、未解決の所有責任を含めるべきだ。
これらの指標は、ガバナンスを運用に結び付ける。また、ある統制がリスクを低減するのか、それとも管理業務を増やすだけなのかをリーダーが判断する助けにもなる。
規制の動向も別のシグナルになる。欧州連合は、高リスク分類、監視、文書化、人間による監督、サイバーセキュリティ、インシデント対応に関するガイダンスを引き続き公表している。
しかし、法的コンプライアンスは完全なエージェントセキュリティプログラムではなく、最低限の基準にすぎない。有害な行動の多くは、特別に規制されたユースケースの範囲外で起こる。
ベンダーの動向にも注意が必要だ。エンタープライズプラットフォームは、既存製品にエージェントを組み込む動きを強めており、通常の機能更新を通じて新たな機能が有効化される場合もある。
顧客は、それらのエージェントに個別のアイデンティティが付与されているかを問うべきだ。また、どのアクションを制限できるのか、どの記録が監査のために利用可能であり続けるのかも確認すべきである。
企業が自律実行型エージェントを推奨モードへ格下げし始めれば、Gartnerの予測は信頼性を増す。その変化は、組織が本番環境での教訓を受けて権限を是正していることを示すだろう。
企業がインシデントや大規模なロールバックを増やさずに自律システムを拡大するなら、その予測は弱まる。その結果には、開発環境と実行時環境の両方で機能する統制が必要となる。
Google Newsは有用な警告を広めたが、その見出しが企業向けエージェントを禁止する理由になってはならない。この議論が支持するのは、野心を抑えた自動化ではなく、より精密なガバナンスである。
経営幹部は、導入済みのすべてのエージェントについて、ひとつの直接的な問いを投げかけるべきだ。このシステムは、人が止めることなく何を変更できるのか。
その答えが、アイデンティティ、権限、テスト、監視、承認ゲート、停止プロセスを決めるべきである。これらの統制がすべてのエージェントで同一のままであれば、ガバナンスモデルは依然としてリスクを見落としている。
