AIエージェントのセキュリティリスクと対策｜権限管理やツール実行、統制設計を解説

AIエージェントのセキュリティは、従来の生成AIリスク対策とは別物として設計し直す必要があります。
生成AIが「出力」を返すだけだったのに対し、AIエージェントはツール実行・ファイル操作・外部API呼び出しといった「アクション」を自律的に取るため、プロンプトインジェクションが成功しただけで実害が発生する構造になっているからです。

本記事では、2025年12月に公表されたOWASP Top 10 for Agentic Applications 2026のASI01〜ASI10を主軸に、権限・ツール実行・記憶の汚染という3つの実務論点、国内外のガイドライン、統制設計の進め方までを2026年10月時点の最新情報で体系的に解説します。

AIエージェント特有のセキュリティリスクとは

AIエージェントのセキュリティリスクとは、AIエージェントが自律的に外部ツールを実行し、ファイル操作・メール送信・API呼び出しといった「アクション」を取れることで生じる、従来の生成AIにはなかった新しい攻撃面を指します。

従来の生成AIは「問いに対して出力を返す」だけで閉じていたため、情報漏えいとプロンプトインジェクションに注意すれば防御の輪郭が描けました。AIエージェントではこの前提が崩れ、プロンプトインジェクション1件が成功しただけでメール送信・権限昇格・社内データ流出といった実アクションに直結します。

2026年10月時点で、IPA「情報セキュリティ10大脅威2026」の組織編第3位に「AIの利用をめぐるサイバーリスク」が初選出され、OWASPは2025年12月にAgentic Applications専用のTop 10（ASI01〜ASI10）を公表しました。

IPA「情報セキュリティ10大脅威2026」解説書（組織編）表紙。AIリスクが組織編で初選出・第3位にランクイン（出典：IPA 情報セキュリティ10大脅威2026）

生成AI向けのOWASP LLM Top 10とは別物として整備された事実が、エージェントのセキュリティが別レイヤーで扱われるべきであることを端的に示しています。

生成AIセキュリティとの決定的な違い

AIエージェントが生成AIと同じ土俵で語れないのは、「出力の検閲」で止まる設計では防御が成立しないからです。

生成AIのリスクは最終出力に対するフィルタリング（有害出力の抑制、PII検出、ハルシネーション判定など）で一定の対応が取れました。エージェントの場合は出力がそのままツールAPIコールに変換されるため、フィルタをすり抜けた瞬間に外部システムが動く構造になっています。

Microsoft Entra Agent IDのように「エージェントは人間ユーザーとは別のアイデンティティとして扱う」独立ID基盤が整備されてきているのは、この構造変化を踏まえた設計です。

Claude Code・OpenAI Agents SDK側はツール実行時の許可・承認ルール（permission mode）として同じ論点にアプローチしており、独立IDとは別レイヤーで統制を積み重ねる形です。

シャドーAIや野良AIの問題も、エージェントが自律的に動く以上「使われている存在に気づけない」こと自体が重大リスクになるため、生成AIよりも検出・棚卸しの重要度が1段上がります。

---

OWASP Top 10 for Agentic Applications 2026が示す10のリスク

AIエージェントのセキュリティリスクを体系的に押さえるうえで、現時点で最も参照されている標準がOWASP Top 10 for Agentic Applications 2026です。2025年12月9日にOWASP Foundationから公表され、生成AI向けのLLM Top 10とは別フレームとして整備されました。

OWASP Gen AI Security Project「Top 10 for Agentic Applications 2026」公式ドキュメント表紙（Version 2026・December 2025公表）（出典：OWASP GenAI Security Project）

本セクションでは、ASI01〜ASI10の10カテゴリ全体を俯瞰し、本記事の後段で深掘りする「権限・ツール実行・記憶の汚染」の3軸にどう対応するかを示します。

ASI01〜ASI10の全体像

以下の表で、OWASP Top 10 for Agentic Applications 2026のASI01〜ASI10を一覧化しました。公式の定義と、本記事の後段でホームH2として深掘りするテーマとの対応を併記しています。

ID	名称	概要	本記事のホームH2
ASI01	Agent Goal Hijack	攻撃者が外部データ経由でエージェントの目的を書き換える	記憶・コンテキスト汚染
ASI02	Tool Misuse & Exploitation	エージェントが正規ツールを意図外の方法で連鎖させる	ツール実行
ASI03	Identity & Privilege Abuse	共有・過剰権限が侵害時の被害を増幅する	権限・アイデンティティ
ASI04	Agentic Supply Chain Vulnerabilities	MCPサーバー・ツールレジストリ経由の侵害	統制パターン（サプライチェーン）
ASI05	Unexpected Code Execution (RCE)	意図しないコード実行が発生する（ホスト侵害・サンドボックス脱出含む）	ツール実行
ASI06	Memory & Context Poisoning	後に自前知識として扱う領域に悪意情報を埋め込む	記憶・コンテキスト汚染
ASI07	Insecure Inter-Agent Communication	エージェント間通信で認証なき呼び出し・なりすまし	統制パターン（エージェント間）
ASI08	Cascading Failures	1つの誤判断が接続ワークフロー全体に伝播する	統制パターン（連鎖）
ASI09	Human-Agent Trust Exploitation	人間がエージェント出力を過信して不安全な行動を取る	権限・アイデンティティ（人間承認）
ASI10	Rogue Agents	侵害・ドリフトでポリシー外動作をするエージェント	統制パターン（野良AI）

この一覧から分かるのは、ASIの10カテゴリは独立したリスクではなく、「権限（ASI03・09）／ツール実行（ASI02・05）／記憶（ASI01・06）／連携と信頼境界（ASI04・07・08・10）」の4軸にほぼ再編できるという点です。

OWASP自身も「securing what AI says」（生成AIが言うこと）から「securing what AI does」（AIが実行すること）への転換と説明しており、本記事ではこの4軸のうち前3軸をH2#3〜5のホームとして深掘りし、第4軸はH2#6「統制パターン」にまとめます。

従来のLLM Top 10との違い

既にOWASP Top 10 for LLM Applicationsが存在する中で、Agentic専用版が別建てで整備された理由は、エージェント特有の攻撃面がLLM Top 10では捕捉しきれないためです。

LLM Top 10の2025年版も、LLM06「Excessive Agency」でツール実行・過剰権限・自律性・人間承認を扱っており、エージェントの論点を全く扱っていないわけではありません。ただしLLM Top 10はLLMアプリケーション全般（単発生成〜エージェント型を含む）が対象なのに対し、Agentic Top 10は「複数ツール・複数エージェント・持続メモリを前提とした自律実行」に絞って、エージェント化で顕在化する攻撃面（ゴール書き換え・ツール連鎖・エージェント間通信など）を深掘りする構成になっています。

なおLLM Top 10 の2026年版が2026年8月3日に発表され、Excessive Agencyが第6位から第3位に繰り上がるなど、エージェント化の進行がLLM Top 10側のランキングにも反映されました。LLM Top 10 2026とAgentic Top 10 2026は補完関係にあり、エージェント型アプリケーションではこれら2本を並行して参照するのが現在地です。

日本語でASI01〜ASI10を体系的に扱う記事はまだ少なく、個別カテゴリの詳細は今後の個別解説記事で深掘りしていきます。本記事ではハブとして、各ASIがどの実務論点に対応するかの地図を提示する位置づけとします。

---

権限とアイデンティティのリスクと統制

AIエージェントのセキュリティで最初に設計し直すべきは、権限とアイデンティティです。ASI03 Identity & Privilege AbuseとASI09 Human-Agent Trust Exploitationが示すとおり、エージェントに人間ユーザーの延長で権限を持たせると、侵害時の被害が「エージェントのアクセス範囲すべて」に拡大します。

本セクションでは、権限過剰付与がなぜ事故につながるかの構造、最小権限・JIT（Just-In-Time）アクセス・Non-Human Identity（NHI）の設計、人間承認を組み込むHuman-in-the-Loopまでを整理します。

権限とサプライチェーンに関連する実インシデント

2026年3月から4月にかけて、エージェントまたはAIツール連携が関与するインシデントが相次ぎました。公開報道で確認できる代表例は以下の3件で、根本原因は事例ごとに異なります。

• 米Meta社の情報漏えい事件（2026年3月）
  AIエージェントが関与し、本来アクセス権を持たない社員が約2時間にわたって機密性の高い社内データを閲覧可能な状態になった事案。
  
  

• Google広告MCCアカウント乗っ取り（2026年3月・原因未特定）
  AIエージェントツール導入後にGoogle広告のMCC（My Client Center）が乗っ取られ、8桁後半の金銭被害が発生した事案。侵入経路・原因は公式には特定されていないと記載されています。
  
  

• Vercel社への侵害（2026年4月・サプライチェーン型）
  従業員が権限を付与していたサードパーティAIツール「Context.ai」側の侵害を起点に、Vercelのアカウントが乗っ取られた事案（Vercel公式確認）。
  エージェント自身のツール実行ではなく、連携したSaaS経由のアカウント侵害が攻撃経路です。

これらは「エージェントが悪意を持った」のではなく、権限設計・連携先SaaS・運用統制のいずれかに起因する異なるタイプのインシデントです。

従来のID管理ではエージェントや連携AIツールを「人間ユーザーの一時的な分身」として扱っていましたが、その前提では止められない事故が実在することが共通して明らかになっています。

最小権限とJIT（Just-In-Time）アクセス

対策の起点は、エージェントに付与する権限を業務遂行に必要な最小限に絞り、必要なときだけ・必要な期間だけ権限を発行する設計です。Microsoft Entra IDやAWS IAMで既に実装されているJust-In-Time（JIT）アクセスの考え方を、エージェント専用アカウントに対して適用します。

実務では次の3層でスコープを縛るのが有効です。

• アクション層: エージェントが呼び出せるAPIエンドポイント・SQLステートメント種別・ファイル書き込みパスを明示列挙する
• リソース層: アクセスできるテナント・プロジェクト・データベーススキーマを限定する
• 時間層: タスク実行期間だけ有効なトークンを発行し、タスク終了で自動失効させる

既存の人間向けIDに「エージェント用」のロールを増やす形で対応すると、権限委譲チェーンのどこかで最小権限が崩れるケースが多発します。Microsoft 365 Copilotエージェントのように、エージェント固有のIDを人間IDと別軸で設計する運用のほうが、長期的には統制コストが下がります。

Non-Human Identity（NHI）とエージェント専用アカウント

2026年の実務トレンドとして、エージェント・サービスアカウント・ワークロードIDをまとめて「Non-Human Identity（NHI）」として扱い、人間IDとは別のライフサイクル管理に乗せる動きが広がっています。

MicrosoftはEntra Agent IDを提供開始、GoogleもAgent IdentityとしてService Accountと区別された専用アイデンティティを用意しています。

Microsoft Entra Agent IDはDiscover・Govern・Protectの3領域を中心に、認証/認可・A2Aプロトコル・MCP・SDK・Conditional access・ID governanceを統合する構造になっている（出典：Microsoft Learn: What is Microsoft Entra Agent ID?）

この構造図が示しているのは、Entra Agent IDが単体の認証機能ではなく、エージェントの発見（Discover）・ガバナンス（Govern）・リソース保護（Protect）の3層を同じ基盤で扱う設計になっているという点です。

A2Aプロトコル・MCP・SDKがエージェントの入出力経路として基盤に組み込まれ、Conditional access・ネットワーク制御・ID governanceが外周でエージェントのライフサイクル全体を囲む配置になっています。

NHIの運用で押さえるべきポイントは次の3点です。

• 人間IDと同じMFA前提に戻さない。代わりにワークロード属性ベースの認可を組み合わせる
• 認証情報（APIキー・トークン・証明書）を定期的にローテーションする仕組みを初日から用意する
• どのエージェントがいつ・どのAPIを呼んだかを人間IDと同じ粒度で監査ログに残す

権限統制のゴールは「エージェントの悪事を人間の悪事と同じ精度で可視化できる」ことです。

これができていない状態でエージェントを本番導入すると、インシデントが起きた時に「誰が何をしたのか」を事後に再現できず、監督官庁・顧客への説明責任を果たせません。

Human-in-the-Loopで高リスクアクションに人間承認を挟む

最後の防波堤として、エージェントが高リスクアクションを実行する前に人間承認を挟む「Human-in-the-Loop」（HITL）を組み込みます。

ASI09 Human-Agent Trust Exploitationは「人間が過信してエージェント出力をそのまま承認してしまう」リスクも含むため、HITLは単に承認ボタンを置けば済むものではありません。

実装の要点は次の2つです。

• アクション分類: メール送信・ファイル削除・外部API呼び出し・金銭移動・権限変更など、取り返しのつかないアクションをリストアップし、HITL必須に設定する
• 承認情報の提示: 承認者が「何を承認するか」を一目で判断できるよう、エージェントの意図・使用ツール・影響範囲を人間可読の形で提示する

承認者にJSON形式のツールコールだけを見せると、人間はほぼ素通りで承認します。承認を機能させるには、エージェント側に「このアクションの影響を人間向けに要約する」ステップを義務化する設計が必要です。

---

ツール実行のリスクと統制

AIエージェントの価値はツール実行にあり、同時に最大の攻撃面もツール実行にあります。ASI02 Tool Misuse & ExploitationとASI05 Unexpected Code Executionが示すとおり、エージェントが正規ツールを連鎖させることで、個別ツールの権限範囲内でも想定外のアクションに到達する構造になっています。

本セクションでは、Tool Allow-listによる実行可能ツールの限定、MCP（Model Context Protocol）経由のツールポイズニング、サンドボックスでの実行環境分離までを扱います。

Tool Misuseとツールチェーン攻撃

Tool Misuseが従来の脆弱性と異なるのは、権限昇格を伴わずに成立する点です。エージェントが与えられたツールを個別に使う分には問題がなくても、「ファイル読み取りツール → データ送信ツール → メール送信ツール」のように連鎖させた瞬間に、個別ツールでは想定していなかった情報持ち出しが成立します。

Tool Allow-listでは「使えるツールのリスト」を縛るだけでは不十分で、以下の2点を併せて設計する必要があります。

• ツール組み合わせの制約: 外部送信系ツール（メール・HTTP・外部API）と機密データ読み取り系ツールを同一セッションで同時使用禁止にする
  
  
• 連鎖時の承認ゲート: ツールAの出力をツールBに渡す経路に、人間承認か自動フィルタを挟む

Anthropic Claude CodeのAgent SkillsやOpenAIのAgents SDKでも、ツール単位の権限制御は実装が進んでいますが、ツール連鎖の統制はアプリケーション層の設計責任として残されています。

OWASPが2026年9月にv0.1公開プレビューを公表したAgent Control Standard（ACS）は、セッション開始・ツール呼び出し・メモリ読み書き・サブエージェント生成・応答配信など19のライフサイクルフックを定義し、ツール連鎖に対する実行時の統制を標準化しようとしている取り組みで、本記事の設計方針を実装レベルで補完する参照先として押さえておく価値があります。

MCPのツールポイズニングと悪意あるサーバー

MCP（Model Context Protocol）はエージェントが外部ツール・データソースと接続するためのプロトコル標準として広く採用されています。普及に伴い実装起因のCVEも報告が増え、Equixly社の技術ブログが複数の実装脆弱性を確認したと紹介しています。プロトコル仕様自体の欠陥と、個別実装・サーバー側の脆弱性は分けて議論する必要があり、現時点で定量的な集計の二次検証は限定的です。

代表的な攻撃手法が「ツールポイズニング」（Invariant Labsが2025年4月に命名）です。MCPサーバーが提供するツール説明文（description）に悪意ある指示を仕込むことで、エージェントがツールを呼び出す際に意図しない動作を誘発します。

対策の要点は次の3つです。

• MCPサーバーの信頼境界設計: 社内で管理するMCPサーバーと、第三者が運営するMCPサーバーを明確に分離し、第三者サーバーには最小権限と検閲を適用する
  
  
• ツール説明文の署名・検証: サーバー更新時にdescriptionの差分を検知し、改変があった場合はエージェントの自動取り込みを止める
  text
• MCP通信の監査ログ化: どのMCPサーバーに・どのツールを・どの引数で呼び出したかを不変ログに残す

MCP固有のセキュリティ論点は、本記事では概要にとどめます。詳細はMCPセキュリティの個別記事で扱う予定です。

ASI05: 自然言語がコード実行に変わる経路

ASI05 Unexpected Code Executionは、エージェントが意図しないコードを実行するリスク全般（意図外のコード実行、ホスト・コンテナ侵害、サンドボックス脱出を含む）を指します。

コード実行ツール（Python interpreter・shell execution・SQL実行）を持つエージェントで特に発生しやすく、Anthropic公式のClaude Codeサンドボックス設定ドキュメントでも実行環境のサンドボックス化と権限制御がdefense-in-depthとして示されています。

実務的なサンドボックス設計は次の3層です。

• プロセス分離: エージェントのコード実行をコンテナ・VMで実行環境として分離し、ホスト環境・他のテナントに影響しないよう構成する
  text
• ネットワーク分離: 外部通信をプロキシ経由にし、許可した外部エンドポイントのみに制限する
  text
• ファイルシステム分離: 書き込み可能領域を一時ディレクトリに限定し、永続化は明示的な承認アクションを通す

サンドボックスの実装度合いは製品によって異なります。たとえばMicrosoft 365 CopilotのCode Interpreterは隔離VM上で実行され外部通信も制限される設計が公開されています。

自社でエージェントを組み込む場合は、各製品の実行環境ドキュメントを個別に確認してから、必要な追加統制（アプリケーション側での二重の制限）を設計しましょう。

---

記憶・コンテキスト汚染のリスクと統制

エージェントが「次のアクションを決める材料」として参照するあらゆるデータ源が、記憶・コンテキスト汚染の攻撃面になります。ASI01 Agent Goal HijackとASI06 Memory & Context Poisoningは、同じ構造を異なる経路で突く攻撃で、両者を合わせて対策する必要があります。

本セクションでは、プロンプトインジェクションの直接・間接の違い、RAG汚染、長期メモリ汚染までを整理します。

直接プロンプトインジェクションと間接プロンプトインジェクション

プロンプトインジェクションには2つの経路があり、エージェントで特に危険なのは間接型です。

• 直接プロンプトインジェクション
  ユーザー自身が「システム指示を無視して〜」のような指示を直接投入する。生成AIチャット段階からある古典的な攻撃で、入力フィルタである程度対処できる
  
  
• 間接プロンプトインジェクション
  エージェントが読み込む外部データ（メール本文・PDF・Webページ・Slackメッセージ・MCP経由のツール応答）に悪意ある指示が仕込まれている。ユーザーは何も入力していないのに攻撃が成立する

間接型が特に深刻なのは、エージェントが「情報を集める」行為自体が攻撃経路になるため、入力フィルタでは防げないからです。

Simon Willisonが提唱したLethal Trifectaは、機密データへのアクセス・信頼できないコンテンツへの接触・外部通信チャネルの3条件が揃うとデータ流出につながる攻撃が成立し得る、という脅威モデルで、エージェントは3条件を同時に満たしてしまうケースが多いのが実情です。

RAG汚染と検索結果の信頼境界

RAG（Retrieval Augmented Generation）でエージェントが社内ドキュメントや検索結果を参照する構成では、検索インデックス自体への攻撃がASI06 Memory & Context Poisoningに直結します。

よくある汚染経路は次の3つです。

• 社内ドキュメント経由: Shadow AIで作成された不正ドキュメントが社内検索インデックスに取り込まれる
• Web検索結果経由: SEO操作で攻撃ページを検索上位に押し上げ、エージェントの検索ツールが拾う
• コードリポジトリ経由: 外部OSSライブラリのREADMEやコメントに悪意指示を埋め込む

対策の起点は、エージェントが参照するデータ源に「信頼境界」を設定することです。社内公式ドキュメントと、ユーザーアップロードコンテンツと、Web検索結果を同じコンテキストに混ぜず、信頼度の低いソースから来た情報は「参考資料」として扱い、アクション判断の根拠にはしない設計が必要です。

長期メモリ汚染と検出困難性

エージェントに長期メモリ機能（ユーザーの好み・過去の対話履歴・学習した業務ルール）を持たせる構成では、Memory Poisoningは1回の攻撃で終わらず、エージェントが使われるたびに影響が再発します。

長期メモリの統制で押さえるべき点は次の2つです。

• 書き込み権限の分離: 長期メモリへの書き込みは、エージェント自身の判断ではなく、ユーザーの明示的な承認アクションでのみ発生する設計にする
  
  
• メモリ内容の定期監査: 保存されたメモリの内容を人間が定期的にレビューし、意図しない指示や事実と異なる記録を削除する

長期メモリ汚染は検出が極めて難しく、現時点では「汚染を前提に、影響範囲を局所化する」運用設計が現実解です。

長期メモリを扱うアプリケーションでは、保存ストレージ・読み出し経路・書き込み権限を独立設計し、プロンプトインジェクション経由で記憶が書き換わっても即座にツール実行権限へ波及しないよう分離する責任がアプリケーション層に残ります。

---

AIエージェント特有の統制パターン

ここまでの3軸（権限・ツール実行・記憶）に加え、エージェントを運用する組織全体で押さえるべき統制パターンがあります。ASI04 Agentic Supply Chain Vulnerabilities・ASI07 Insecure Inter-Agent Communication・ASI08 Cascading Failures・ASI10 Rogue Agentsが対象で、サプライチェーン・エージェント間通信・連鎖障害・野良AIの4つの論点を含みます。

本セクションでは、監査ログ・サンドボックス・ガードレール・野良AI検出といった組織レベルの統制パターンを整理します。

監査ログの不変保管とトレーサビリティ

エージェントの統制で最初に整備すべきは、監査ログの不変保管です。インシデント発生時に「どのエージェントが・いつ・誰のID下で・どのツールを・どの引数で呼び出し・何を返したか」を再現できなければ、原因究明も再発防止もできません。

実務で押さえるべき3点は次のとおりです。

• 保管対象
  ユーザー入力・エージェントのプランニング中間出力・ツール呼び出し引数・ツール応答・最終応答のすべてを1セッション単位で紐付けて保管する
  
  

• 改ざん防止
  ログ書き込みをアプリケーション側ではなく独立したログ基盤（Azure Monitor・AWS CloudTrail等）に委ね、エージェント本体から書き換えできない構成にする
  
  

• 保管期間
  業種・適用法令・社内規程に応じて設定する（NIST SP 800-92でも組織方針と法規制に基づく策定が求められている）

監査ログは「あとで見るためのもの」ではなく、インシデント対応の初動30分で参照されるものです。

可読性と検索性を初日から設計しておくことが、運用の実効性を決めます。

サプライチェーンの統制とMCPサーバー管理

ASI04 Agentic Supply Chain Vulnerabilitiesは、エージェントが動的に取り込むコンポーネント（MCPサーバー・ツールプラグイン・プロンプトテンプレート・外部ライブラリ）が侵害されるリスクです。

対策の要点は次の3つです。

• コンポーネントの許可リスト化: エージェントが読み込めるMCPサーバー・プラグイン・ライブラリをホワイトリスト管理する
• 署名検証: コンポーネント更新時に提供元の署名を検証し、改ざんがないことを確認する
• SBOM（Software Bill of Materials）管理: どのエージェントがどのコンポーネントに依存しているかの一覧を常に最新化する

Vercel社の侵害事例が示すように、サードパーティAIツールを従業員が自由にインストールできる状態では、組織全体のアタックサーフェスが従業員の数だけ増えます。

SaaS間のエージェント連携は、個人の判断ではなく組織的な承認プロセスの対象にすべき領域です。

ガードレールと出力フィルタリング

AIガードレールは、エージェントの入出力に対して方針違反・PII流出・有害出力を検出する仕組みです。各クラウドベンダーが実装を提供しており、2026年10月時点では以下のような選択肢があります。

• AWS Bedrock Guardrails: Amazon Bedrockでのプロンプト・応答フィルタリング
• Google Vertex AI Safety Filters: Vertex AI上のモデル応答の安全性制御
• Google Cloud Model Armor: プロンプト・応答に対するプロンプトインジェクション・ジェイルブレイク検出・機密情報・有害コンテンツの検査をテンプレート単位で設定できるサービス
• Azure AI Content Safety: Microsoft Foundry／Azure OpenAI向けの統合ガードレール

Anthropic Claudeも方針遵守の仕組みをモデル自体に組み込んでいますが、Constitutional AI自体は追加学習手法で、上記3つのような導入時に設定するフィルタサービスとはレイヤーが異なります（ベンダー側で学習済みの状態がデフォルトで効く）。

ただし、ガードレールは「万能のフィルタ」ではなく、プロンプトインジェクション耐性には限界があることが各社から明示されています。

CloudflareはMythos Previewの検証で、同一リクエストでも表現・文脈の違いで拒否挙動が揺らぐことを報告しています。ガードレールを「最後の砦」ではなく「複数防御層のうちの1層」として位置づけ、権限統制・監査ログと組み合わせる前提で設計します。

野良AI（Rogue Agents）の検出と棚卸し

ASI10 Rogue Agentsは、OWASP公式の定義では「意図した機能や認可範囲から逸脱して、侵害・ミスアライメント・ドリフトにより有害な動作をするエージェント」を指します。

シャドーITの発展形としての未承認AI利用（シャドーAI・野良AI）はASI10そのものとは別概念ですが、棚卸しが欠けていると「意図外に逸脱したエージェント」を発見する起点がなくなるため、ASI10対策の前提として両者を同じワークフローで扱います。

野良エージェントの検出には次の3つのアプローチを組み合わせます。

• ネットワーク監視: 社内から主要AIプラットフォーム（Anthropic・OpenAI・Google・Microsoft等）への通信ログを収集し、未許可の利用を検出する
• SaaS利用の棚卸し: 従業員が利用しているSaaSに組み込まれたエージェント機能（Notion AI・Slack AI・Zoom AI等）を一覧化する
• APIキー発行の統制: 従業員が自己判断でAIプラットフォームのAPIキーを発行できないよう、申請フローを義務化する

野良AIの棚卸しは野良AIとは？シャドーAIとの違いや棚卸し手順、統制フレームワークを解説の記事で詳述しています。

---

国内外のガイドライン・規制と導入コストの考え方

AIエージェントのセキュリティは企業内の技術的対策だけでは完結せず、国内外のガイドライン・規制が運用設計に影響します。2026年10月時点で押さえるべきガイドラインと、エージェント統制の導入コストの考え方を整理します。

日本国内の主要ガイドライン

国内では2026年3月から4月にかけて複数のガイドラインが相次いで整備されました。

• AI事業者ガイドライン第1.2版（総務省・経済産業省、2026年3月31日公表）
  AIエージェントおよびフィジカルAIの定義が追加され、Human-in-the-Loopや最小権限、ガードレールへの言及が強化されています。

AI事業者ガイドライン第1.2版 概要（令和8年3月31日・総務省/経済産業省公表）（出典：METI AI事業者ガイドライン）

• AIのセキュリティ確保のための技術的対策に係るガイドライン（総務省、2026年3月27日公表）
  LLMおよびLLMを構成要素に含むAIシステムが対象です。AIエージェントについては技術が急激な発展途上にあることを理由に、現時点では対象外とされており、本記事のテーマである「AIエージェント」固有の技術対策はこのガイドラインではカバーされません。
  
  

• IPA「情報セキュリティ10大脅威2026」（2026年1月29日公表）
  「AIの利用をめぐるサイバーリスク」が組織編第3位に初選出。経営層の投資判断を後押しする外部根拠として機能します。
  
  

• AISI「AI-IRS AIインシデントレスポンス・アプローチブック」（2026年1月9日公表）
  エージェントを含むAIシステムでインシデントが発生した際の対応手順を整理した資料で、社内のインシデント対応計画のテンプレートとして活用できます。
  
  

• AISI「AIセーフティに関する評価観点ガイド 第1.20版」（2026年7月7日公表）
  AIエージェントの普及を踏まえて評価観点が更新・拡充され、エージェント固有の「観測と制御」が追加されました。導入前のリスク評価や社内レビュー基準として使えます。

総務省の技術対策ガイドラインがAIエージェント対象外である点は特に重要です。「ガイドラインに準拠すればOK」ではなく、AI事業者ガイドライン1.2版と組み合わせて自社の統制を設計し直す必要があります。

海外のフレームワーク

海外では以下の3つが実務の参照先として押さえておくべきです。

• OWASP Top 10 for Agentic Applications 2026
  本記事で解説したASI01〜ASI10のフレーム。業界横断の標準として最も参照される
  
  
• NIST AI Risk Management Framework (AI RMF)
  米国NISTが提供するAIリスク管理の包括的フレームワーク。Govern・Map・Measure・Manageの4機能で整理
  
  
• EU AI Act
  2024年8月1日発効、2025年2月2日に禁止行為条項が適用開始、2025年8月2日に汎用AI（GPAI）要件が適用開始。独立型の高リスクAIシステム要件は2027年12月2日、規制対象製品に組み込まれる高リスクAIは2028年8月2日まで移行期間が設けられています。EU市場に製品・サービスを提供する企業は域外適用の対象になります

NIST AI Risk Management FrameworkのCore 4機能構造。中心にGovern（リスク管理文化の醸成）を置き、Map（文脈とリスクの識別）・Measure（識別リスクの評価）・Manage（優先順位付けと対応）が周囲で連続的に回る設計（出典：NIST AI Risk Management Framework）

4機能のうちGovernは組織全体の土台として常時働き、Map/Measure/Manageが具体のエージェント・AIシステムごとに繰り返し回るループを形成します。本記事で扱ってきた権限・ツール実行・記憶の統制は、このMap（リスク識別）とMeasure（評価）に相当し、Manage（対応）で実装・運用に落ちる構造です。

EU AI Actは域外適用の性格を持つため、日本企業でもEU市場向けサービスを提供している場合は適用対象になります。社内で導入するエージェントもEUの従業員・顧客を扱う場合は要件を確認する必要があります。

エージェント統制の導入コストの考え方

AIエージェントのセキュリティ統制にかかるコストは、以下の3層で見積もるのが実務的です。

層	内容	コストの性格
初期設計層	権限モデル設計・HITL設計・ガードレール設定・サプライチェーン棚卸し	一時費用。社内リソース＋外部SIer支援で3〜6か月規模
プラットフォーム層	Entra ID P2・Azure AI Content Safety・AWS Bedrock Guardrails等のライセンス	継続費用。製品によって課金単位が異なる（Entra ID P2＝ユーザー数ベース／Content Safety＝テキストレコード・画像枚数／Bedrock Guardrails＝検査リクエスト量）。Entraの保護機能をエージェントに拡張する場合、追加ライセンス（Agent 365等）の提供条件も関係するため、公式pricing・ライセンスガイドを別途確認する
運用層	監査ログ運用・インシデント対応・定期的な野良AI棚卸し	継続費用。内製SOCまたは外部MSSPへの委託

この表が示すように、エージェントの統制コストは「ツール導入のライセンス費」よりも、初期設計層と運用層の人件費が主要な部分を占めます。モデル利用料（Claude・GPT・Geminiの従量課金）とは別軸で見積もる必要があります。

---

AIエージェント統制設計の進め方

ここまでに整理した権限・ツール実行・記憶・統制パターン・規制を、実務でどう組み立てるかを示します。本セクションは中立のまとめではなく、AI総合研究所の支援現場で見てきたパターンをもとに、ケース別の推奨を提示します。

統制設計の4ステップ

AIエージェント導入時の統制設計は、以下の4ステップで進めるのが現実的です。

• ステップ1: 棚卸しと分類
  社内で既に動いているエージェント（意図した導入・野良AIの両方）を棚卸しし、扱うデータ・実行アクションの重要度でリスク分類する。
  
  この時点で「社内で誰がAPIキーを発行できるか」を把握できていない組織が多く、まずは発行経路の統制から始まるケースが多い。
  
  

• ステップ2: ホームH2（権限・ツール・記憶）の設計
  エージェントごとに、本記事H2#3〜#5で扱った3軸の統制方針を文書化する。全エージェント一律ではなく、業務影響度に応じて統制レベルを3段階程度に分けると現実的に運用できる。
  
  

• ステップ3: パイロット運用と監査ログ検証
  限定業務でパイロットを開始し、監査ログが設計通りに取れているか・インシデント発生時の対応フローが機能するかを検証する。パイロット段階で監査ログの検索性が足りないケースが多い。
  
  

• ステップ4: 本番展開とNHI管理の継続運用
  本番展開後は、Non-Human Identityのローテーション・野良AIの定期棚卸し・ガードレールのチューニングを継続運用に組み込む。ステップ1〜3を終えた直後に「終わった」と判断すると、半年で統制が形骸化する。

この4ステップのうち、特にステップ1の棚卸しが最も時間を消費します。既存のSaaS・開発環境・業務アプリに組み込まれたエージェントが想像以上に多く、網羅的な把握には3〜4週間かかるのが一般的です。

導入判断で詰まる3つの論点

AI総合研究所の支援現場で、エージェント統制の導入判断が止まりやすいのは次の3論点です。

• 「ガードレールだけで十分では？」**
  AWS Bedrock Guardrails・Azure AI Content Safetyなどを入れれば大丈夫と考えがちだが、本記事H2#6で見たようにガードレールだけでは不十分。権限統制・監査ログと組み合わせて初めて機能する。
  
  

• 「HITLは業務速度を落とすのでは？」
  全アクションにHITLを入れると確かに業務が止まる。本記事H2#3で見たようにアクション分類を先に設計し、取り返しのつかない高リスクアクションのみHITL必須にすることで、速度と安全性を両立できる。
  
  

• 「サプライチェーン棚卸しは誰が主管？」
  IT部門・情シス・AI推進部門・事業部門のどこが主管するかで止まりがち。実務的には、情シスがMCPサーバー・プラグイン・SaaS組み込みエージェントの棚卸しを主管し、AI推進部門が業務影響度のレビューに加わる構成が機能しやすい。

これらは技術論ではなく運用設計の論点で、組織の意思決定スピードが律速になります。導入前に3論点の意思決定フローを決めておくと、ステップ2〜3の作業がスムーズに進みます。

ケース別の推奨

企業の規模と状況に応じて、起点になるアクションは変わります。

• 全社AI推進を進めている大企業: ステップ1〜4の全工程をIT部門・情シス・AI推進部門の合同プロジェクトとして進める。初期設計層に3〜6か月、本番展開まで含めて6〜12か月を目安にする
  
  
• 特定部門でパイロット中の中堅企業: ステップ1の棚卸しをパイロット部門に絞り、ステップ2〜3を同部門で先行実装する。全社展開は半年ほどの実績を見てから判断する
  
  
• 既にSaaS組み込みエージェントが稼働中: 新規導入より先に、既存SaaSのエージェント機能の棚卸し（ステップ1）から着手する。野良AIの棚卸し手順が実務の起点になる

どのケースでも、「エージェントを導入してからセキュリティを後付けする」順序は推奨しません。パイロット段階で監査ログと権限統制を設計せずに本番展開すると、インシデント発生時の対応コストが導入メリットを上回ります。

---

AIエージェントの統制を1画面で回す基盤を導入するなら

AIエージェントのセキュリティは、権限統制・ツール実行統制・記憶の汚染対策・監査ログ運用を揃えて初めて成立します。個別の対策を部分最適で積み上げると、インシデント発生時に「どこで何が起きたか」を再現できず、監督官庁・顧客への説明責任を果たせません。

このレイヤーを統合管理するのが、自社Azureテナント内で動くエンタープライズAIエージェント基盤です。AI総合研究所のAI Agent Hubは、Teamsから呼び出せる業務特化エージェントを1つのダッシュボードで統合管理し、権限・ツール実行・監査ログの統制を1画面で設計・運用できる基盤として機能します。

• エージェント単位のアクセス範囲設計
  Agentごとに扱えるデータ・呼び出せるツール・アクセスできるテナントを明示的に定義。本記事H2#3で解説した最小権限・JIT設計を基盤レベルで実装できます。
  
  

• 不変監査ログの一元保管
  誰がどのAgentで何を照会したか、どのツールをどの引数で呼び出したかを不変ログで保管。インシデント発生時の原因究明と監督官庁への説明責任に対応できる形で残します。
  
  

• モデル世代交代を吸収する管理層
  Claude・GPT・Geminiの短サイクル世代交代を吸収しながら、業務Agent側の設計は不変。本記事H2#2で見たOWASP ASIの各カテゴリに対する統制を、モデル依存せず継続運用できます。
  
  

• データは100%自社Azureテナント内に保持
  業務データ・プロンプト・エージェントの思考プロセスはAIの学習対象から完全除外。Azure Managed Applicationsとして自社テナント内で動作が完了する設計です。

AI総合研究所の専任チームが、エージェントの統制設計から業務Agent基盤の実装・運用まで一貫して支援します。AI Agent Hubのサービスページで、本記事で扱った権限・ツール実行・記憶の統制を1画面で回す実装例をご確認ください。

---

まとめ

本記事では、AIエージェントのセキュリティを権限・ツール実行・記憶の汚染の3軸で整理し、OWASP Top 10 for Agentic Applications 2026、国内外のガイドライン、統制設計の進め方までを2026年10月時点の最新情報で解説しました。

2026年時点で押さえておくべきポイントは次の3つです。

• AIエージェントのセキュリティは「出力の検閲」から「アクションの統制」へ軸が移っており、権限・ツール実行・記憶の3層を同時に設計し直さなければ従来の生成AI対策では止まらない
• OWASP Top 10 for Agentic Applications 2026のASI01〜ASI10は2025年12月公表の最新標準で、Meta・Google広告MCC・Vercelの連続事案（原因は事例ごとに異なる）が示したとおり、権限設計とサプライチェーン統制の両面を同時に見直す必要がある
• 総務省の技術対策ガイドラインはAIエージェント対象外で、AI事業者ガイドライン1.2版と組み合わせて自社の統制設計を進める必要があり、最小権限・HITL・監査ログの3点を導入前に設計できていないエージェントは本番運用に乗らない
  
  

企業のセキュリティ責任者にとってAIエージェントは、「生成AIと同じ対策で守れる」という前提を捨てて、権限・ツール実行・記憶を独立した設計対象として扱い直す段階に来ています。パイロット段階で統制設計を後回しにせず、ステップ1の棚卸しから着手することが、エージェントを本番運用に乗せるための最短ルートになります。