生成AIの話になると、つい「回答の精度」や「ハルシネーション」に目が向きがちです。ですが、いま本当に前提が変わり始めているのは、AIが答えるだけでなく、計画し、判断し、ツールを使い、外部システムに対して実際に操作を行うようになってきたことです。OWASPが公開した「OWASP Top 10 for Agentic Applications 2026」は、まさにその変化に合わせて整理されたリスク集です。資料では、こうした自律的なAIシステムが、金融、医療、防衛、重要インフラ、公共分野へと広がっていることも示されています。
ここで厄介なのは、攻撃者が狙う場所が増えることです。従来のWebアプリであれば、コード、認証、API、データベースを中心に守ればよかった場面でも、エージェント型のシステムでは、その途中に「判断」「委任」「ツール実行」「他エージェントとの連携」が入ってきます。OWASP自身も、不要な自律性を避ける「Least-Agency」と、エージェントが何をし、なぜそうしているのかを追える強い可観測性を重要な考え方として打ち出しています。
OWASP Top 10 for Agentic Applications for 2026：https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026
TABLE OF CONTENTS
「AIが答える」から「AIが動く」へ
OWASPの整理を実務目線で言い換えると、守るべき対象は次のように変わります。図でも、リスクは入力、統合・処理、出力の全体にまたがって配置されており、プロンプトだけの問題ではないことがわかります。
| 従来のアプリケーション | エージェント型アプリケーション |
|---|---|
| 主な防御対象はコード、API、DB | 主な防御対象は判断、ツール実行、権限連鎖、連携経路 |
| ユーザー操作が中心 | エージェントが自律的に複数ステップを実行 |
| 不正入力や脆弱性悪用を想定 | 目標誘導、権限悪用、連鎖誤動作まで想定が必要 |
| ログ監視が中心 | 行動の流れ、意思決定、ツール呼び出しの追跡が必要 |
この違いは、開発の話だけでは済みません。業務部門が「便利そうだから使う」、情シスが「SaaS連携ならすぐ入れられる」と判断した時点で、すでに社内の認証情報、業務データ、メール、ワークフロー、外部APIが一つの自動化チェーンに結びつく可能性があります。守る側としては、導入時点から「どこまで自動で動かしてよいか」を決めておかないと、あとから帳尻を合わせるのがかなり難しくなります。
OWASPが挙げた10の主要リスク
OWASPが示した10項目を、日本の企業現場でイメージしやすい言葉に寄せると、次のようになります。正式なリスク名はOWASPの原文に準拠しています。
| ID | リスク名 | 現場で起きること |
|---|---|---|
| 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 | 記憶やRAGの文脈が汚染され、後から効いてくる |
| ASI07 | Insecure Inter-Agent Communication | エージェント間通信がなりすましや改ざんを受ける |
| ASI08 | Cascading Failures | 小さな異常が自動連鎖で全体障害に広がる |
| ASI09 | Human-Agent Trust Exploitation | 人間の信頼や権威バイアスが悪用される |
| ASI10 | Rogue Agents | 見た目は正常でも、振る舞いが逸脱・暴走する |
10項目を眺めると、従来のセキュリティの延長で説明できるものもあります。ただ、決定的に違うのは、単発の脆弱性というより「行動の連鎖」が問題になることです。ひとつの入力、ひとつの判断ミス、ひとつの緩い権限設定が、そのまま複数システムをまたいで被害に育っていく。そこがエージェント型システムの怖さだと感じます。
現場で特に見落としやすい論点
目標そのものがずらされる
ASI01でOWASPが強調しているのは、エージェントや基盤モデルが、命令と関連データを安定して見分けられないという点です。つまり、攻撃者は出力を少し乱すだけでなく、エージェントの目的、タスク選択、判断経路そのものを曲げられます。しかもその入口は、プロンプト欄に限りません。RAGで読み込む文書、メール、外部データ、他エージェントからのメッセージにも潜ませることができます。
現場感として厄介なのは、「一見ただのデータ」に見えることです。人が見れば添付資料、議事録、取引先から来たメールでも、エージェントにとっては次の行動を決める材料です。ここを信用しすぎると、知らないうちに送信先が変わる、内部データを別の場所に渡す、意思決定の前提がすり替わる、といったことが起こります。
正規ツールと正規権限が、そのまま攻撃面になる
ASI02は、とても現実的なリスクです。エージェントは悪性コードを持ち込まなくても、正規のメール機能、DB参照機能、社内API、ファイル操作機能を使って被害を出せます。OWASPも、信頼されたバイナリや有効な認証情報のもとでコマンドが動くため、EDR/XDRのようなホスト中心の監視では異常が見えにくいケースを挙げています。
ここで必要なのは、ツール単位の最小権限だけでは足りないということです。OWASPは、ツールごとの権限プロファイル、実行ごとの認証、高影響操作に対する人の承認、実行前のポリシー検証、サンドボックス実行まで求めています。要するに、「使えるツールを持っている」ことと「その場で使ってよい」ことは分けて考えるべきだ、という話です。
記憶は便利だが、汚染されると後から効いてくる
ASI06のメモリ／コンテキスト汚染は、短期的なインシデントよりも長引く問題になりやすい領域です。OWASPでは、会話履歴、サマリー、埋め込み、RAGストア、共有コンテキストなど、エージェントが保持・再利用する情報全体を対象にしています。ここに偽データや誘導データが入り込むと、次のセッションでも、その次の判断でも、同じ誤りが再利用されます。
このタイプの怖さは、侵害の瞬間が見えにくいことです。たとえば一度の会話で管理者権限を奪うような派手な挙動は出なくても、徐々に判断の重みづけが変わる、誤った運用ルールを「正しい前提」として覚える、別のエージェントへ汚染が広がる、といった形で効いてきます。あとからログを見返しても、「どこで壊れたのか」が見つけにくいので、かなりやっかいです。
人が最後に承認していても、安心とは言い切れない
ASI09は、個人的にかなり重要だと思っています。OWASPは、人間がエージェントを過信し、権威性のある説明やもっともらしい根拠に引っ張られることで、危険な操作を自分で承認してしまうリスクを整理しています。資料では、不正な振込先を含む請求書に影響された財務エージェントが、緊急送金をそれらしく勧め、管理者が独立した確認なしに承認する例も挙げられています。
これは、よくあるソーシャルエンジニアリングがAI経由で強化される、と考えるとわかりやすいです。最終クリックが人間なら安全、ではありません。エージェントが「監査に残らない悪い影響役」になると、フォレンジックの視点でも原因の追跡が難しくなります。だからこそ、重要操作では説明の上手さではなく、出所、根拠、承認フローを見なければいけません。
連携が増えるほど、小さな異常が全体障害に育つ
ASI07とASI08は、単体のAIよりも、複数エージェントや外部連携を組み合わせた時に効いてくる論点です。OWASPは、API、メッセージバス、共有メモリを介したエージェント間通信で、なりすまし、改ざん、再送、ルーティング偽装が起こりうると整理しています。さらに、一つの誤判断や汚染データが、別のエージェントやワークフローへ伝播し、短時間で全体障害に育つ「Cascading Failures」も独立したリスクとして挙げています。
ここまで来ると、もはや単発の脆弱性診断だけでは足りません。どのエージェントが何を受け取り、どの条件で別のツールや別のエージェントに渡すのか。その経路を追える設計と、途中で止める仕組みが必要です。OWASPが可観測性を「必須」と言っているのも、この文脈だと納得しやすいはずです。
あらかじめ方針・ルールを定める
OWASPの資料を読み込むと、対策の方向性はかなりはっきりしています。ポイントは、AIだから特別な魔法が必要なのではなく、自律性を前提にした統制を最初から埋め込むことです。
- 不要な自律性を与えないこと。OWASPは最小権限だけでなく、不要な自律性を避ける「Least-Agency」を明確に打ち出しています。判断をAIに任せなくてもよい箇所まで自動化すると、攻撃面だけが広がります。
- ツールごとに権限を細かく絞ること。読み取り専用、送信不可、削除不可、接続先制限など、ツール単位で上限を固定し、都度の実行にも認証と承認をかける設計が重要です。
- 高影響操作には人の承認を残すこと。削除、送金、権限変更、公開処理のような不可逆な操作は、人の確認を必須にするべきです。OWASPも、権限昇格や高リスク操作でのHuman-in-the-Loopを繰り返し推奨しています。
- 計画と実行を分離すること。エージェントが提案した内容を、そのまま本番で動かさず、外部のポリシーエンジンや実行前検証で止める構成が有効です。
- コード実行は必ず隔離すること。生成コード、シェル実行、パッケージ導入は、サンドボックス、ネットワーク制限、実行前検査、ログ監査が前提です。
- エージェントにも独立したID管理を適用すること。短命トークン、タスク単位権限、セッション分離、委任の再検証が必要です。人の権限をそのまま長く引き継がせる設計は危険です。
- 文書、メール、API応答、他エージェントのメッセージまで、入力全般を信用しないこと。エージェントはそこから次の行動を決めるため、見た目が普通でも攻撃面になり得ます。
- ログを見るだけで終わらず、行動の流れを追うこと。どの入力を受け、どの判断で、どのツールを使い、どこへ影響が広がったのか。この連鎖が見えないと、異常の早期検知も、事故後の説明責任も難しくなります。
導入前に、最低限これだけは確認したい
AIエージェントの導入検討で、先に社内で確認しておきたいのは次の点です。
- そのエージェントは、何を「読む」だけで、何を「実行」できるのか
- 実行できるツールのうち、削除、送信、変更、公開の権限はどこまであるのか
- エージェント固有のIDと権限管理があるのか
- 高リスク操作を止める承認フローがあるのか
- メモリ、RAG、共有コンテキストの更新ルールと検証手順があるのか
- 外部プラグイン、MCP、連携先の真正性確認をどう行うのか
- 事故時に、どの入力からどの行動が生まれたか追跡できるのか
ここが曖昧なままPoCを進めると、最初は便利でも、運用に乗った段階で統制が追いつかなくなりやすいです。エージェントは「賢いUI」ではなく、「権限を持って動く実行主体」だと捉えた方が、設計判断を誤りにくいと思います。
便利さより先に、止め方を決めておく
OWASP Top 10 for Agentic Applications 2026を見ていると、AIエージェントのリスクは、目新しい単語が増えただけではないとわかります。従来からある権限管理、入力検証、監査、承認、分離、サンドボックスといった基本原則が、自律性によって一段厳しく問われるようになった、というのが実態に近いはずです。
便利に動くことを考える前に、どこで止めるのか、誰が承認するのか、何を記録するのかを決めておく。エージェントを安全に使ううえで、いちばん地味ですが、いちばん効くのはそこだと思います。導入が進むほど、この見直しは一度やっておいて損がありません。
