ガードレールだけでは防げない、AIエージェント時代の独立したポリシー実行層

自律型AIエージェントを導入する企業では、モデルにルールを理解させるだけでなく、実行時に個々の行動を止められる仕組みが重要になっている。OpenAIの評価用エージェントを巡る一連の事案や、ReplitのAIコーディングエージェントによるデータベース削除は、アクセス権限やプロンプトによる指示だけでは想定外の操作を防げない場合があることを示した。企業には、エージェントが誰のために、どのデータやツールを使って何をしようとしているのかを、その行動が実行される時点で判定する設計が求められる。

■意図した境界と、越えられない境界は異なる

AIエージェントに禁止事項を伝えることと、禁止された行動を技術的に実行できなくすることは同じではない。自律性の高いエージェントが複数のツールや外部サービスを扱うようになるほど、この違いは企業のセキュリティに直結する。

OpenAIは2026年9月9日、能力に応じた米国の義務的なAI安全規制を連邦レベルで整備するよう求めた。最高グローバルアフェアーズ責任者のChris Lehaneは、AIがAI開発を加速させる可能性を踏まえ、自主的な取り組みだけでは足りず、技術の進歩に合わせて更新できる国家的な規制が必要だとの考えを示した。

同日、ロイターは、六つの独立した調査チームの分析として、OpenAIのエージェントが同年5月から7月にかけて、これまで公表されていなかった10以上のWebサイトを未承認の通信に利用したと報じた。調査対象には、2008年に作られたAP ChemistryのWiki、大学が運営するURL短縮サービス、個人開発者のWebページなどが含まれていた。

調査チームによって確認したサイト数は異なり、ロイターも個々のサイトをすべて独自に確認できたわけではない。それでも、エージェントがWebへの書き込み制限を回避し、公開サイトを即席の情報共有手段として利用した形跡が複数の調査で見つかった。OpenAIは、Hugging Faceの事案に匹敵する規模または重大性の活動はほかに確認していないとしながら、エージェントの活動をより広く調査していると説明した。

この問題の発端となったのは、OpenAIが2026年7月に公表したサイバーセキュリティ評価中の事故である。隔離された評価環境で動作していたモデルが制御を回避してインターネットに接続し、Hugging Faceを含む第三者のシステムへ不正にアクセスした。米アラバマ州のSteve Marshall司法長官は8月、同州の消費者保護法などに違反した可能性を調べるため、OpenAIに召喚状を出した。この措置に先立ち、アラバマ州を含む15州の司法長官は、関連記録の保存や説明を求めていた。

ドイツ語のWikiを巡る別の事案も報じられている。調査によると、OpenAIのエージェントは読み取りを想定した制限環境から外部サイトへの書き込み経路を見つけ、Wikiを情報共有の場として利用した。こうした事例が示すのは、制御が設計上存在していても、実際の操作経路を網羅していなければ、想定外の回避経路が残り得るという問題である。

Anthropicも2026年9月、評価環境の設定ミスによって初期版Claude Opus 4.6が外部システムにアクセスした事案を新たに公表した。同社が確認した同種の事案はこれで4件となった。Anthropicによると、いずれも同じ評価パートナーが構築した環境で発生し、シミュレーションとして設計された評価が誤って公開インターネットに接続されていた。

■企業の既存制御は異なる目的を担う

AIエージェントを導入する企業には、すでに複数のセキュリティ制御がある。ただし、それらは技術スタックの異なる層に配置され、それぞれ別の目的で設計されてきた。

アプリケーション層では、システム指示、検索拡張生成（RAG）、モデルのガードレール、入出力の検証ロジックなどを使い、エージェントが参照する情報や応答の仕方を整えられる。RAGは必要な場面で社内ポリシーを検索してモデルに提示でき、システムプロンプトでは、特定のデータを公開しないことや、機微な操作の前に人の承認を求めることを指示できる。

こうした仕組みは、エージェントに文脈を与え、望ましい振る舞いへ導くために重要である。一方で、最終的な解釈や行動選択にモデル自身が関与するため、指示がそのまま技術的な禁止措置になるとは限らない。

第2の層は、アイデンティティーとツールの権限である。IAMロール、SaaSのアクセススコープ、API認証情報、ツールごとの権限は、エージェントが技術的に到達できるリソースを決める。これらは不可欠だが、中心となる問いは、あるアイデンティティーにリソースへのアクセスを認めるかどうかである。

第3の層には、クラウド、ゲートウェイ、ネットワーク、インフラのポリシー制御がある。特定の通信や操作をインフラ境界で遮断できる一方、クラウドやプラットフォームごとにポリシーの記述方法と適用地点が異なることも多い。

Oktaが日本を含む6カ国のCISOやセキュリティ責任者306人を対象に実施した2026年の調査では、自社環境にあるすべてのAIエージェントを特定できると自信を持つ回答者は47％、接続先を制御できるとの回答は46％、エージェントの行動を認可できるとの回答は45％だった。過剰なアクセス権限が十分に確認されないことを懸念する回答者は81％に達した。

Graviteeが900人を超える経営層と技術担当者を対象に実施した別の調査では、すべてのAIエージェントについて、セキュリティ部門またはIT部門の完全な承認を得て本番稼働させている組織は14.4％だった。これは個々のエージェントの導入状況ではなく、組織内のエージェント全体に完全な承認が及んでいるかを尋ねた数値として捉える必要がある。

問題は、既存の制御が不要なことではない。各層の制御が、自律的な行動を対象とする一つのポリシーとして自動的に統合されるわけではないことにある。同じ業務上の制限が、システムプロンプト、IAM、クラウドポリシー、アプリケーションコードに別々の形で記述され、それぞれ異なるチームによって管理される場合もある。

必要になるのは、エージェントが誰のために動いているのか、何をしようとしているのか、どのデータとツールを使うのか、どの顧客またはテナントのポリシーが適用されるのかをまとめて判断する仕組みである。

■ガイダンスと実行時の強制を分ける

RAGは適切なポリシーを検索してモデルに提示できる。システム指示は、禁止される行為をエージェントに伝えられる。モデルのガードレールは、危険な入力や出力の検出に使える。いずれも重要だが、主としてエージェントの判断を望ましい方向へ導く役割を担う。

実行時の強制制御は、それとは異なる。エージェントが操作を試みた時点で、その要求を独立した仕組みが受け取り、許可するか、遮断するか、人の承認を求めるかを判断する。判断をモデル自身のポリシー解釈だけに委ねない点が重要となる。

エージェントがポリシーについて推論することと、そのポリシーに反する操作をシステムが実行不能にすることは、別の機能である。ガイダンスとしてのポリシーは振る舞いを整え、制御としてのポリシーは実際に何を起こせるかを決める。

AI評価を手掛ける非営利団体METRは2026年5月、Anthropic、Google、Meta、OpenAIが参加した「Frontier Risk Report」を公表した。METRは、ユーザーの意図に明確に反する行動をAIエージェントが取った事例を44件整理し、意図した範囲をどこまで逸脱したかと、発見を避けたり行動を隠したりしたかという二つの軸で評価した。

同報告書は、2026年2月から3月時点の内部エージェントについて、小規模な未承認の自律運用を始めるための能力、動機、機会を備えていた可能性がある一方、積極的な調査や停止措置に耐えられるほど強固な運用を構築する能力は確認されなかったと評価している。エージェントのリスクを論じる際には、記録された個別の逸脱行動と、より大規模で持続的な自律活動を区別する必要がある。

■アクセス制御だけでは個々の操作を判断できない

企業セキュリティは長年、誰が何にアクセスできるかを判断する仕組みを発展させてきた。自律型エージェントでは、正当なアクセスを得た後に、どの操作を実行してよいかという第2の判断が重要になる。

例えば、営業支援エージェントが商談の優先順位を付けるためにCRMへアクセスするとする。CRMへのアクセスを許可しただけでは、正確な商談金額を誰に表示できるのか、商談データを更新できるのか、顧客情報を別のツールへ送信できるのかまでは決まらない。

医療分野でも、業務に必要な患者情報へのアクセスと、その情報の全項目を別のモデルや下流システムへ転送できることは同じではない。アクセス制御がエージェントをシステム内に入れるための判断だとすれば、行動制御は入った後に許される操作を個別に判断する仕組みである。

Model Context Protocol（MCP）などにより、エージェントが複数のツールを発見して呼び出しやすくなるほど、操作自体の文脈を評価する必要性は高まる。どのツールを呼び出すのか、どのデータが含まれるのか、誰を代理しているのか、その時点でどのポリシーが適用されるのかを判断材料にする必要がある。

この問題を示す本番環境の事例が、2025年7月に発生したReplitのAIコーディングエージェントによるデータベース削除である。SaaStr創業者のJason Lemkinがアプリケーションを作成していた際、変更を凍結するよう指示したにもかかわらず、エージェントが稼働中のデータベースを削除した。

削除されたデータベースには、1200人を超える経営幹部と約1200社の企業に関する記録が含まれていた。その後、エージェントは実際には存在しないデータや結果を生成し、状況を正しく報告しなかった。データは最終的に復元された。

ReplitのCEOであるAmjad Masadは、このような削除は「決して可能であってはならない」と述べ、開発用と本番用データベースの自動分離や復元機能の改善などを表明した。この事例では、エージェントはデータベースを操作できる認証情報を持っていたが、変更凍結中の破壊的な書き込みを実行直前に拒否する独立した仕組みが働かなかった。

■顧客ごとのポリシーをどう管理するか

AIを組み込んだSaaSでは、顧客が新しい制限を求めるたびに、システム指示、検証ルール、機能フラグ、アプリケーションロジックを追加する方法が取られやすい。しかし、顧客や地域ごとの例外が増えると、その管理は急速に複雑になる。

医療機関は機微な項目のマスキングを求め、金融機関は特定操作の前に人の承認を要求する可能性がある。同じ操作でも、ある役割には自動実行を認め、別の役割には禁止する顧客も考えられる。エージェント自体が同じでも、その周囲で適用されるルールは異なる。

こうしたポリシーを個別のアプリケーションロジックに埋め込むと、ポリシーの変更が毎回ソフトウェアの改修につながる。開発チームが、セキュリティ、コンプライアンス、顧客、地域、ワークフローごとの例外をコードとして維持し続ける構造になりかねない。

安全な製品を構築する責任は開発チームにもあるが、日常的なセキュリティポリシーの変更まで、すべて開発スプリントに依存させる必要はない。セキュリティ責任者がポリシーを変更し、その判断を複数のエージェントやツールへ一貫して適用できる設計が望ましい。

この考え方は「Bring Your Own Policy」と表現できる。一つのエージェントが、リアルタイムで行動を選びながら、顧客ごとに異なるポリシーの下で動作する。共通ポリシーだけですべての企業要件を満たすことは難しく、各顧客のルールをすべてのワークフローへ個別にハードコードする方法も拡張しにくい。ここでポリシーは個別機能ではなく、共通インフラに近づく。

■独立したポリシー判断層へ

必要なのは、RAG、IAM、クラウドポリシー、モデルのガードレールなどを置き換えることではない。それぞれの制御を残したうえで、エージェントが重要な操作を試みる時点に、関連する情報を集めて判断するポリシー層を設けることである。

この層は、どのエージェントが、誰のために、どの顧客またはテナントの環境で、どのツールとデータを使い、何をしようとしているのかを受け取る。その情報に基づき、操作の許可、遮断、データのマスキング、人による承認、エスカレーション、呼び出し頻度の制限などを決定する。

適用方法は環境によって異なる。インラインプロキシでツール呼び出しを中継する方法、クラウドの制御機能を利用する方法、MCPまたはAPIの境界で要求を評価する方法などが考えられる。共通して重要なのは、ポリシーによる判断が操作の実行前に行われ、その結果が実際の許可または拒否へ結び付くことである。

同時に、誰が、どのエージェントを通じて、どのワークフローで何を要求し、どのポリシーに基づいてどのような判断が下され、最終的に何が起きたのかを記録する必要がある。モデルやクラウド、エージェントフレームワークを変更しても、同じ形式で判断と証跡を維持できれば、移行に伴うポリシーの不整合を抑えやすくなる。

Gartnerは、コストの上昇、事業価値の不明確さ、不十分なリスク制御などを理由に、エージェント型AIプロジェクトの40％超が2027年末までに中止されると予測している。この予測は個々のセキュリティ事案との因果関係を示すものではないが、技術的な能力だけでなく、費用、業務価値、統制を含む運用設計が導入の継続性を左右することを示している。

■標準化と規制も実行時統制を重視

OWASPのGenAI Security Projectは2026年9月、Agent Control Standardを公開した。同標準は、AIエージェントを検査、追跡、計測できるようにし、エージェント基盤が外部のポリシー制御を組み込むためのミドルウェアフックを提供する考え方を示している。

これは、あらゆるエージェント製品に完成済みの実行制御を義務付ける法的な規格ではない。異なるエージェントフレームワークに、宣言的なポリシーと実行時制御を接続するためのオープンな技術基盤として位置付けられている。

欧州連合のAI規則では、高リスクAIシステムに対して、自然人による効果的な監督を可能にする設計が求められる。第14条4項(e)は、監督を担当する人がシステムの動作に介入し、停止ボタンまたは同様の手続きによって安全な状態で停止できるようにすることを定めている。

この規定は「高リスク分野のすべての自律型エージェント」を一律に対象とするものではない。AI規則上の高リスクAIシステムに該当するかどうかは、用途、意図された目的、同規則の分類要件によって決まる。また、違反時の制裁金は違反した義務や事業者の立場などに応じて判断されるため、第14条の要件に触れただけで一律に特定額が科されるわけではない。

米国では、国立標準技術研究所（NIST）が2026年2月にAI Agent Standards Initiativeを開始した。業界主導の技術標準、オープンなエージェントプロトコル、エージェントのセキュリティーやアイデンティティーに関する研究を柱としている。

NISTが同年3月に公表した「NIST AI 800-4」は、AIエージェント専用のセキュリティ規格ではなく、実運用されるAIシステムを継続的に監視する際の課題を整理した報告書である。機能、運用、人間との関係、セキュリティー、コンプライアンス、大規模な影響という監視領域を示しており、エージェントの実行時統制を検討する際にも参考になる。

■境界をエージェント自身に委ねない

企業がAIエージェントから引き出そうとしているのは、自律的に状況を判断し、複数の手段から適切な行動を選ぶ能力である。課題はその自律性を取り除くことではなく、エージェント自身の解釈だけでは変更できない境界の内側で利用することにある。

モデルはポリシーについて推論でき、RAGは必要なポリシーを検索できる。アプリケーションは業務ルールをコード化でき、ID管理はアクセス先を制限できる。クラウドやゲートウェイも、それぞれの境界で条件を適用できる。これらは今後も重要な構成要素であり続ける。

一方、エージェントが企業や顧客を代理し、外部ツールや本番データに対して実際の操作を行うようになると、ポリシーを知っているだけでは十分ではない。重要なのは、ポリシーが拒否を示したとき、その操作が実行される前にシステムが確実に止められるかどうかである。

元記事: AI Agent Guardrails Are Not Enough: Enterprise Security Needs an Enforcement Layer