自律型AIエージェントには新たなガバナンスモデルが必要だ

Google Newsには、直接的な警告を発するSiliconANGLEの見出しが掲載された。自律的に動くAIアクターには、重大な行動を実行できるソフトウェア向けに設計されたガバナンスが必要だという。

この違いは重要だ。AIエージェントは回答を生成するだけではない。ファイルを取得し、ツールを呼び出し、コードを実行し、記録を更新し、他のシステムと通信できる。こうした能力により、信頼性の低い出力が、許可されていない行動につながる可能性がある。

この見出しは、いま企業のテクノロジー責任者が直面している対立を捉えている。企業はより少ない監督で稼働するエージェントを求めている一方、多くのセキュリティ制御は依然として、あらゆる重要な行動を人間が開始することを前提としている。

規制当局、標準化団体、セキュリティベンダーは、この隔たりを埋め始めている。新たに浮上している答えは、固有のエージェントID、制限された権限、継続的な監視、人による承認ポイント、復旧メカニズムを組み合わせるものだ。

中心的な問題は、もはやモデルが不正確な文章を生成するかどうかではない。ミスが広がる前に、組織がエージェントの行動を特定し、封じ込め、説明し、取り消せるかどうかである。

Google Newsの見出しが指し示す、より大きなガバナンスの転換

AIガバナンスは、モデル出力の監督から、ID、権限、ツール、運用責任を持つソフトウェアアクターの統制へと移行している。

従来の生成AIガバナンスは、学習データ、有害コンテンツ、モデル評価、生成される回答の正確性に大きく重点を置いてきた。これらの懸念は依然として重要だが、自律型エージェントは異なる運用上の課題をもたらす。

AIエージェントは、一連の判断を通じて目標を追求できる。ツールを選択し、変化する情報を読み取り、計画を修正し、各段階で承認を求めることなく行動を開始できる。

この振る舞いにより、ユーザーの当初の指示と最終的な結果の間の連鎖は長くなる。ステップが増えるたびに、意図、文脈、権限がずれる可能性のある地点が新たに生まれる。

たとえば、従業員がエージェントに顧客契約更新用の書類作成を依頼する場合を考えてみよう。チャットボットなら文面を下書きして待機するかもしれない。自律型エージェントは、アカウント記録を取得し、テンプレートを選び、契約書を修正し、その一式を送信する可能性がある。

こうした行動には複数のシステムと、複数の権限境界が関わる。曖昧な指示や汚染された文書が、処理の全体に影響を及ぼしかねない。

したがって、このGoogle Newsの記事は、不正確なAIに関する単なる警告以上のものだ。組織内でソフトウェアが動作する方法の構造的な変化を反映している。

ソフトウェアサービスは以前からマシンIDを使用してきた。しかし、そうしたサービスは通常、狭い技術的境界の中で予測可能な機能を実行する。

AIエージェントは、曖昧な目標を解釈し、複数の行動候補から選択できる。その振る舞いは、プロンプト、取得データ、メモリ、モデル出力、利用可能なツール、変化する環境条件に左右される。

このため、エージェントは通常の従業員でも従来型のソフトウェアサービスでもない。企業には依然として、所有者を割り当て、権限を定義し、活動の証拠を保持する必要がある。

その責任の所在を暗黙のままにしてはならない。複数のチームが異なるプラットフォームでエージェントを展開するなら、セキュリティ責任者には、どこでエージェントが動作し、何にアクセスできるかを示す完全なインベントリが必要になる。

AppViewXは、agent identity platformを導入した際、この新たな製品カテゴリを例示した。同社によると、そのシステムはエージェントを検出し、権限をマッピングし、その振る舞いを監視する。

この製品は、適格な企業向けにプライベートプレビューとして公開された。その主張は実際の導入環境での検証をなお必要とするが、その設計は市場の進む方向を反映している。

重要な転換は概念的なものだ。企業は、各エージェントをアプリケーション内の目に見えない機能ではなく、統制対象のアクターとして扱い始めている。

この変化が、この記事の中心的な緊張関係を生む。エージェントが有用になるほど、通常はより多くのアクセス権を必要とする。追加される権限はすべて、操作、エラー、認証情報の侵害後に生じうる被害も拡大する。

自律的な能力は、認可された権限と同じではない

エージェントの技術的能力によって、組織がその実行を許可する範囲を決めてはならない。

開発者は、完了率、推論テスト、ツール利用ベンチマークを通じてエージェントを評価することが多い。こうした評価は能力を説明するが、エージェントに運用上の権限を与えるべきかどうかには答えない。

コーディングエージェントは、リポジトリ全体を変更できるかもしれない。しかし、それはレビューなしに本番環境へ変更をマージすべきことを意味しない。

金融エージェントは、有効な支払い指示を生成できるかもしれない。しかし、それは定められた閾値を超えて資金を送金すべきことを意味しない。

ガバナンスでは、エージェントが達成できることと、実行を許可されていることを分離しなければならない。この分離は、1つのモデルが異なる責任を持つ多数のエージェントを支える場合に不可欠となる。

同じ基盤モデルが、リサーチアシスタント、カスタマーサポートエージェント、インフラ運用者を動かす可能性がある。それぞれの行動がもたらす結果は異なるため、権限も異なるべきだ。

組織はすでに、従業員とソフトウェアサービスに同様の考え方を適用している。カスタマーサポート担当者がデータベースクエリを理解しているからといって、無制限のデータベースアクセスを与えられるわけではない。

エージェントにも、技術的な制御を通じて実装される同じ原則が必要だ。権限は、定義されたタスク、事業責任者、環境、許容可能な影響を反映すべきである。

NISTは、2026年2月17日に発表したagent standards initiativeにおいて、IDと認可を中心に据えた。この取り組みは、標準、オープンプロトコル、セキュリティ研究、信頼できる相互運用性に焦点を当てている。

NISTは、コードを書き、コミュニケーションを管理し、商品を購入できるエージェントについても説明した。これらの例は、モデルレベルの安全ポリシーだけでは、そこから生じるすべての行動を統制できない理由を示している。

複数のアプリケーションをまたいで動作するエージェントには、検証可能なIDが必要だ。アクセスを受ける各システムは、どのエージェントがアクセスを要求しているのか、誰の代理で行動しているのかを把握しなければならない。

そのIDは、責任を負う個人または組織単位に結び付いているべきだ。そうでなければ、監査ログは行動が発生したことを示せても、誰がそのアクターを認可したのかを確定できない。

認可では、委任も考慮しなければならない。エージェントは専門的なサブエージェントを作成したり、外部プロバイダーが運用する別のエージェントを呼び出したりする可能性がある。

単純なユーザー認証情報では、その連鎖を捉えられない。組織には、元の要求、委任された権限、中間アクター、最終行動を説明する証拠が必要だ。

ここで、よく知られたIDツールは依然として有用である一方、不十分でもある。認証は、誰が認証情報を提示しているかを確認できる。しかし、文脈に依存する行動がエージェントに割り当てられた目的に合致するかどうかを、自動的に確立するものではない。

認証済みの調達エージェントであっても、有効な購買ツールを誤用する可能性がある。すべての認証情報が技術的には有効なままでも、侵害された指示によって未認可のサプライヤーへ向かわせられるかもしれない。

したがって、エージェントガバナンスにはタスクを意識した認可が必要だ。システムは、要求された行動をエージェントの役割、現在の目標、データの機密性、想定される影響と照らして評価しなければならない。

短命な認証情報は、露出を減らすことができる。制限されたツールスコープは、エージェントが割り当てと無関係な機能を利用することを防げる。

組織は、読み取りアクセスと行動権限も分離すべきだ。分析のために請求書データを必要とするエージェントが、請求書を承認または支払う権限まで必要とするとは限らない。

これらの制御は摩擦を生むが、無差別な自律性が有用な代替策ではない。より望ましい目標は、証拠がその判断を裏付けた場合にのみ監督を減らす、比例した自律性である。

静的なアクセス制御では変化する意図を統制できない

有効な認証情報が有効な行動を保証するわけではないため、AIエージェントには実行時の制御が必要だ。

従来のアクセスシステムは通常、ユーザーやサービスがリソースに到達できるかを問う。エージェントガバナンスでは、アクターが何をしようとしているのか、その行動が割り当てられた目標の範囲内にとどまっているのかも問わなければならない。

この違いは、エージェントが信頼できないコンテンツを処理する際に明らかになる。文書、メール、ウェブサイト、ツールの応答には、ユーザーの要求と衝突する指示が含まれている可能性がある。

プロンプトインジェクションとは、AIシステムが処理するコンテンツ内に悪意ある指示を埋め込む攻撃である。エージェントは、それらの指示を正当なガイダンスと誤認する可能性がある。

リサーチエージェントは、保存済み情報を開示するよう指示するウェブページを読むかもしれない。サポートエージェントは、顧客確認ルールを無視するよう指示するメッセージに遭遇するかもしれない。

モデルは誤った指示に従っていても、技術的には機能し続けることがある。エージェントが依然として有効なIDを提示しているため、認証だけではその振る舞いを止められない。

OWASPのagentic risk listは、目標乗っ取り、ツールの誤用、権限乱用、メモリ汚染、サプライチェーンの弱点を主要な懸念事項として挙げている。

このリストには、100人を超えるセキュリティ研究者、実務家、利用組織、テクノロジープロバイダーからの意見が反映された。これは、セキュリティ思考における重要な変化を示している。

防御側はモデルだけを評価することはできない。プロンプト、メモリ、ツール、コネクター、認証情報、オーケストレーションロジック、外部通信を含む、エージェントシステム全体を検討しなければならない。

実行時ポリシーの適用は、その対応策の一つとなる。これは、導入時に設定されたルールだけに全面的に依存するのではなく、エージェントが動作している最中に行動を評価する。

ポリシーレイヤーは、購買エージェントによる注文準備を許可しつつ、送信前には承認を求めることができる。同じエージェントによるサプライヤーの銀行口座情報の変更をブロックすることも可能だ。

判断は、可逆性にも依存しうる。カレンダー招待の下書きは容易に取り消せる。本番データの削除には、それとはまったく異なる復旧負担が伴う。

影響の大きい行動には、より強力なチェックポイントが必要だ。これには、人による確認、2つ目の自動検証者、取引上限、隔離環境内での実行などが含まれる。

ただし、人による承認が自動的に意味のあるものになるわけではない。承認ボタンしかない説明のない確認依頼を受け取っても、レビュー担当者は十分な情報に基づく判断を下せない。

システムは、提案された行動、影響を受けるリソース、裏付けとなる証拠、予想される結果を提示すべきだ。また、不確実性や矛盾する情報も開示すべきである。

メモリは、さらに別の複雑さをもたらす。エージェントメモリは、後で利用するために事実や過去のやり取りを保存し、セッションをまたいで振る舞いを維持できるようにする。

この持続性は継続性を改善できるが、誤った情報や悪意ある情報を保持する可能性もある。汚染されたメモリエントリは、元の攻撃が消えた後も長期間にわたり判断に影響を与えるかもしれない。

組織には、誰がメモリを書き込めるのか、エントリにどのように来歴を付与するのか、古い文脈をいつ失効させるのかについての制御が必要だ。機密性の高いメモリストアにも、他の業務データと同じアクセス規律が求められる。

これは社内ナレッジシステムにとって重要である。検索可能なナレッジベースは、検索ツールを通じて接続されると、エージェントの意思決定環境の一部となる。

Google Newsの見出しはこれらのシステムを自律的な主体として描いているが、自律性には条件が伴うべきだ。重要なすべての行動には、権限から実行までを限定した経路が必要である。

真の争点は自律性と説明責任の対立だ

企業が選んでいるのは有用なエージェントか安全なエージェントかではない。運用スピードの中でも自律性に説明責任を持たせられるかを判断している。

自律型エージェントを支持する最も強い論拠は効率性だ。反復的なタスクを連携させ、継続的に稼働し、分析から実行までの遅延を減らせる。

最も強い反論は、影響範囲の大きさに関するものだ。高速なエージェントは、人が気付く前に、多数のレコード、システム、顧客にわたって誤った行動を繰り返しかねない。

エージェントが広範な認証情報を持つ場合、このリスクは高まる。さらに、エージェントが作業を委任したり、後続のエージェントが利用するコンテキストを変更したりできる場合、リスクは一段と増す。

セキュリティベンダーは異なる方向から対応している。アイデンティティ分野の専門企業は暗号学的アイデンティティと限定的な権限を重視する。データセキュリティ企業は、監視、復旧、機密情報の保護を重視する。

クラウドセキュリティ事業者は、エージェント、アプリケーション、データの間の接続に焦点を当てる。エージェントプラットフォームのベンダーは、評価、ポリシー定義、開発者向けの制御を強調することが多い。

これらのアプローチは重なり合うが、いずれも単独では問題を解決できない。検証済みのアイデンティティは目標操作を防げず、行動監視も誰が権限を付与したかを明らかにはしない。

同様に、人による承認ステップは欠けた監査記録を補えない。ロールバックツールでも、物理的、財務的、あるいは評判上の結果をすべて覆すことはできない。

シンガポールの情報通信メディア開発庁は2026年1月22日、エージェント・ガバナンス・フレームワークを公表した。同フレームワークは、ガバナンスを4つの実務的な観点で整理している。

組織はまず、自律性とアクセスを制限してリスクを抑えるべきだ。その後、実質的な人間の説明責任と承認のポイントを設ける必要がある。

このフレームワークは、ライフサイクル管理、ベースラインテスト、ホワイトリスト化されたサービスへのアクセスも求めている。最後の観点では、透明性、研修、エンドユーザーの責任を扱う。

このアプローチは、エージェントのガバナンスを完全にセキュリティ部門の内部に置くことはできないと認識している。プロダクトオーナーがユースケースを決め、開発者がシステムを構築し、事業責任者が運用展開を承認する。

調達チームも、サードパーティーツールの選定を通じてリスクに影響を与える。ベンダーのエージェントは、外部モデル、コネクター、メモリーサービスを通じて企業データを処理する可能性がある。

契約では、ログ記録、インシデント通知、データ保持、再委託先、システム変更を扱う必要がある。購入者は、インシデント後にベンダーがエージェントの意思決定経路を再現できるかを把握すべきだ。

中心的なトレードオフは、自律性の水準を一度設定すれば解決するものではない。エージェントの権限は、タスク、環境、証拠の変化に応じて変えるべきである。

新しいエージェントは、読み取り専用アクセスと必須の承認から始めることができる。制御されたテストでの成功は、狭いワークフロー内での限定的な実行を正当化するかもしれない。

繰り返される失敗は、権限の縮小につながるべきだ。予期しない挙動、設定ドリフト、モデル更新があれば、再度のレビューを発動すべきである。

これにより、獲得型自律性のモデルが生まれる。エージェントは、関連する条件下で許容可能な挙動を示した場合にのみ、より大きな運用上の自由を得る。

それでも組織は、厳格な境界を維持すべきだ。その結果を元に戻すことが難しいため、監督なしの実行に適さない行為もある。

例としては、アクセス制御の変更、規制対象の開示の公開、雇用の終了、多額の資金移転、主要レコードの削除が挙げられる。

正確な境界は企業ごとに異なる。ただし、自律性をリスク、可逆性、説明責任を負う所有者と結び付ける明確な意思決定は、一貫して維持されるべきだ。

現在のガバナンス製品がなお証明できないこと

市場では、購入者がモデル、プラットフォーム、委任されたワークフローをまたいでその制御が機能するか検証できる速度を上回って、エージェント制御ツールが生み出されている。

製品発表では、発見、監視、ポリシー適用、迅速な是正が約束されることが多い。これらの機能には価値があるが、それを裏付ける証拠にはばらつきがある。

ベンダーは、自社プラットフォームが既知のツール呼び出しを遮断することを実演できる。しかし、そのテストは新しい攻撃、曖昧な目標、複雑な委任の連鎖に対する性能を証明するものではない。

発見にも難しい問題がある。中央管理されたエージェントは棚卸ししやすい一方、従業員はブラウザツール、スクリプト、外部サービスを通じて非公式な自動化を作成できる。

こうしたエージェントは、個人の認証情報やコピーされたAPIキーを使用する可能性がある。中央のガバナンスコンソールが監視するシステムの外で動作することもある。

そのため組織は、エージェント版のシャドーITに直面する。違いは、シャドーエージェントが行動を開始し、さらなる自動化を生み出せる点にある。

監視ツールは、悪意ある行動と正当な変動を区別しなければならない。エージェントは同じタスクを完了するために異なる手順を使うことが多く、硬直的な行動ルールは誤警報を起こしやすい。

アラートが多すぎると監督機能が損なわれる可能性がある。セキュリティチームはノイズの多い警告を無視するかもしれず、事業チームは正当な業務を頻繁に妨げる制御を回避する方法を探す。

説明可能性も別の弱点だ。エージェントは、その行動を生んだプロセスについて信頼できる証拠を示さずに、もっともらしい推論の説明を生成できる。

監査システムは、観測可能なイベントを優先すべきだ。有用な記録には、入力の来歴、ツール呼び出し、認可判断、データアクセス、モデルバージョン、ポリシー結果、最終出力が含まれる。

これらの記録は改ざんから保護されなければならない。エージェントが自身の行動を調査するために必要な証拠を消去できてはならない。

復旧に関する主張も精査に値する。独立したコピーがあれば、削除されたコードブランチを復元することは可能だ。外部メールを取り消したり、公開済みの情報を元に戻したりすることははるかに難しい。

一部の行動は部分的にしか元に戻せない。支払いは取り消せる場合があるが、試みられた送金自体がコンプライアンスや不正に関する懸念を生む可能性は残る。

ガバナンスプラットフォームは、復元できるリソースと、その制御の外に残る結果を明示すべきだ。購入者に必要なのはロールバックに関する一般的な約束ではなく、シナリオに基づく証拠である。

相互運用性はさらに不確実性を加える。企業が単一のモデル、単一のエージェントフレームワーク、単一のアイデンティティプロバイダーだけで運用することはめったにない。

あるベンダーのプラットフォーム内で機能するポリシーも、エージェントが外部ツールを呼び出すとコンテキストを失う可能性がある。委任されたエージェントは、組織的・技術的な境界を越えうる。

標準はこうした分断を減らせるが、なお発展途上にある。NISTの取り組みは勢いを示しているが、実用的な実装には実際のエンタープライズシステムを横断したテストが必要になる。

世界経済フォーラムは、経営幹部の82%が1年から3年以内にエージェントを導入する予定だと報告した。この数字が示すのは意向であり、実証済みの本番導入ではない。

この区別は重要だ。調査で示された熱意は、組織が信頼できる棚卸し、成熟した制御、測定可能な収益を備えていることを示すものではない。

したがって、独立した評価で確認されるまでは、ベンダーの主張はあくまで主張として扱うべきだ。購入者は、自社のリスクプロファイルに似た導入事例からの証拠を求める必要がある。

ガバナンス市場には、インセンティブ上の問題もある。より大きな自律性を販売するプラットフォームが、その自律性を受け入れ可能にするための制御も販売することが多い。

この構図がツールの有効性を否定するわけではない。しかし、顧客には独立したセキュリティテスト、明確な契約上の説明責任、導入を制限する社内権限が必要であることを意味する。

エージェント・ガバナンスが成熟しているかを示す3つのシグナル

次の段階は、追加のポリシー声明ではなく、相互運用可能なアイデンティティ、証拠に基づく自律性、復旧可能な本番導入によって評価される。

第1のシグナルは、NISTのAI Agent Standards Initiativeによる具体的な実装ガイダンスだ。その価値は、組織が標準を相互運用可能な制御へと変換できるかにかかっている。

有用な成果があれば、アプリケーションはベンダーの境界を越えて、エージェントのアイデンティティ、委任された権限、許可された範囲、責任を負う所有者を検証できるようになる。

共通のアイデンティティ項目は、インシデント対応も改善する。調査担当者は、どのエージェントが行動したか、誰が認可したか、実行中にその権限が変わったかを再構築できる。

標準が抽象的なままであれば、ベンダーは互換性のないアイデンティティモデルを実装し続けるだろう。その分断は、異種環境を横断する中央集権的なガバナンスの根拠を弱める。

第2のシグナルは、動的な自律性ポリシーの採用だ。企業は、テスト、リスク、観測されたパフォーマンスに応じてエージェントの権限がどのように変化するかを報告し始めるべきである。

そのためには測定可能な基準が必要だ。エージェントはポリシーに違反したり保護情報を露出させたりしながらもタスクを完了できるため、完了率だけでは不十分である。

評価では、未承認のツール使用、プロンプトインジェクション、メモリー汚染、認証情報の悪用、委任、復旧を対象にすべきだ。テストはエージェントの実際の本番環境も反映する必要がある。

成熟した導入では、評価結果が権限と結び付けられる。不合格のテストは、その弱点が修正・レビューされるまで、より広い権限を自動的に阻止すべきである。

この実践の証拠は、企業が責任ある形で自律性を拡大できるという主張を強める。静的な権限モデルは、ガバナンスが導入の後手に回っていることを示唆するだろう。

第3のシグナルは、インシデントの封じ込めと復旧に関する公開証拠だ。組織は、有害なエージェント活動を検知し、その影響を限定できることを示す必要がある。

これは、機微なインシデントの詳細を公開することを意味しない。企業は匿名化したシナリオ、独立した評価、測定された復旧パフォーマンスを公開できる。

有用な開示では、何が起きたか、どの制御が検知したか、行動がどこまで広がったか、何を元に戻せたかを説明する。

失敗も情報をもたらす。適切に認証されたエージェントが関与するインシデントは、アイデンティティだけでは信頼できる意図を確立できない理由を示すだろう。

複数のエージェントにまたがる失敗は、現在のログ記録が完全な委任チェーンを保持しているかを試すことになる。不可逆な結果は、ロールバックをうたうマーケティングの限界を露呈させる。

これらのシグナルは、また一つ増えるガバナンスダッシュボードより重要だ。この技術は、エージェントが実際のシステム全体で機械の速度で動作する場合にも、制御が有効であり続けることを証明しなければならない。

開発者にとって、当面の意味は明確だ。エージェントアーキテクチャには、最初からポリシーチェックポイント、追跡可能なツール呼び出し、制限された認証情報を組み込むべきである。

エンタープライズの購入者にとっては、ガバナンス要件を導入前の調達プロセスに組み込むべきだ。エージェントが部門全体に広がった後で所有権、監査可能性、復旧を後付けする方が、コストは高くなる。

ナレッジワーカーにも利害がある。エージェントはますます彼らのアカウント、データ、コミュニケーションツールを通じて行動し、人間のアイデンティティのもとで結果が現れる可能性がある。

Google Newsの見出しは、新しいガバナンスモデルの必要性を正しく示している。より難しい問いは、自律的な活動が日常的なインフラになる前に、組織がそのモデルを導入するかどうかだ。

導入されているすべてのエージェントを誰が所有しているのか、どの行動を取れるのか、指示が変わったときに何が起こるのかを問うべきだ。そして、その答えが実際の失敗に耐えられることを示す証拠を求めるべきである。