OWASP Agentic AIセキュリティ成熟度Level 0〜3はそれぞれ何を意味するのか？

Level 0（Unaware and Ad Hoc）：正式なガバナンスなし、シャドーITによる実験。Level 1（Experimentation Without Guardrails）：定義されたガードレールのないパイロットプロジェクト、曖昧な説明責任。Level 2（Policy-Defined, Human-in-the-Loop）：正式なポリシー、指名されたオーナー、高影響の意思決定に人間の確認が必要。Level 3（Integrated, Continuous Oversight）：リアルタイムダッシュボード、キルスイッチ、Governance-as-code。OWASPの公式定義はLevel 3まで。

自分のAIエージェントシステムがどの成熟度レベルにあるかをどう評価するか？

5次元自己評価法を使用する：AIアセットインベントリの完全性、ポリシーとコンプライアンスのカバレッジ、監視と検知能力、テストと検証の頻度、インシデント対応の成熟度。各項目0〜10点。合計0〜10点=Level 0、11〜25点=Level 1、26〜40点=Level 2、41〜50点=Level 3。

AT採用層とガバナンス成熟度Levelの違いは何か？

AT層（AT0-AT5）は「どのタイプのエージェントを展開しているか」を表す。ガバナンス成熟度（Level 0-3）は「セキュリティガバナンスがどの程度成熟しているか」を表す。この2つは独立している。AT4（コード実行型エージェント）でありながらLevel 0（ガバナンス皆無）という組織は少なくない。

Level 1からLevel 2に上がるための最重要な3つのアクションは？

1. AIアセットインベントリの構築（シャドーAIを含む全エージェント展開のカタログ化）。2. ツール呼び出しログの確立（全エージェント操作に追跡可能な記録）。3. 高影響エージェントごとの指名オーナー設定（明確な説明責任）。Level 2への入場券はより強いフィルターではなく、オブザーバビリティだ。

個人開発者が責任ある展開のために必要な成熟度レベルは？

AT層によって異なる。AT1-AT2（ベンダープラットフォーム使用、コード実行なし）：ベンダーが主要な責任を負うため、厳密な自己評価は不要。AT4-AT5（エージェントがコードを実行し外部システムにアクセス）：最低でもLevel 2が必要。具体的にはツール呼び出しログ、ツールごとの明示的な最小権限、エージェントごとの独自ID（共有アカウント禁止）が求められる。

OWASP エージェント型AIセキュリティ成熟度フレームワーク2026：あなたのエージェントは何レベル？

Q: ASI06メモリポイズニングと通常のプロンプトインジェクションの違いは？

プロンプトインジェクションはセッション内の攻撃で、セッション終了とともに終わる。ASI06メモリポイズニングは「低頻度植え込み・持続的影響」が特徴だ。攻撃者は1回のセッションでエージェントの長期記憶ストアに悪意ある情報を注入し、その後数週間の推論に影響を与え続ける。89%のエージェントがユーザー/セッション間でメモリを共有し整合性検証がないため（Repello AI, 2026）、プロンプトインジェクションより追跡が難しい。

組織の83%がagentic AIの展開を計画しているが、それを適切に保護できると考えているのはわずか29%だ（Cisco State of AI Security 2026、via Practical DevSecOps）。この54ポイントの差が示すのは、「セキュリティをやっているかどうか」ではなく「どのレベルまでやっているか」が問題だということだ。PromptfooやWAFを導入しただけでセキュリティ対策が完了したと思っているチームは多い。しかしOWASPが2026年6月に正式発表したEnterprise Adoption Maturity Modelによれば、そのアプローチは精々Level 1（事後対応）であり、責任ある本番展開に必要なLevel 2との間には明確なギャップがある。

本記事ではOWASP公式フレームワークの完全な2次元マトリクス（採用層AT0-AT5×ガバナンス成熟度Level 0-3）を解説し、OWASP Agentic Top 10で最も見落とされている3つのマルチエージェント脅威（ASI06/ASI07/ASI08）を補強し、実践的な自己評価方法とアップグレードロードマップを提供する。

TL;DR

OWASPが6つの採用層（AT0-AT5）×4つのガバナンス成熟度（Level 0-3）の2次元マトリクスを公式定義
79%の組織がLevel 1に停滞：ツールはあるがガバナンスなし（Practical DevSecOps, 2026）
最も見落とされている3つのマルチエージェント脅威：ASI06（メモリポイズニング）、ASI07（エージェント間通信）、ASI08（カスケード障害）
Level 1からLevel 2への移行に必要なのは、より強力なフィルターではなくオブザーバビリティ：ツール呼び出しログ＋指名オーナー
OWASPの公式フレームワークはLevel 3まで定義。Level 4〜5はPractical DevSecOps/SANS/CSAなどの独自拡張であり、OWASPの公式定義ではない

「セキュリティツールがある」は「セキュリティが成熟している」と同じではない

これは最もよくある認知の罠だ。PromptfooやLLM Guardを導入したから、セキュリティ対策は済んだと思い込んでしまう。

Practical DevSecOpsの調査データは直接的だ。79%の組織がLevel 1（Reactive）に留まっている。Level 1の実態は：基本的なプロンプトフィルタリング、LLMフロントにWAF、問題が起きてから対応が始まる。しかし欠けているものの方が重要だ。

AIアセットインベントリなし（組織内でどのエージェントが動いているか把握できていない）
ツール呼び出しログなし（エージェントが何をしたかの追跡可能な記録がない）
指名オーナーなし（何かあったとき誰が責任を取るかが不明確）

成熟度フレームワークが提供する核心的な認識の転換は、「ポイント防御」から「体系的なガバナンス」への移行だ。ファイアウォールがあるからといって、ネットワークセキュリティが成熟しているわけではない。LLMフィルターがあるからといって、agentic AIガバナンス能力があるわけではない。

Level 2への入場券はオブザーバビリティであり、より強力なフィルターではない。「自分のエージェントが今何をしているか」「さっき何をしたか」「その操作を誰が承認したか」という3つの質問に答えられて初めて、Level 2に入ったといえる。

OWASP Agentic AI Top 10 完全リスト（ASI01-ASI10）

OWASP Top 10 for Agentic Applications 2026は10の脅威（公式番号ASI01-ASI10）を定義している。以下に完全リストを整理する。

コード	脅威名	核心リスク	カバレッジ状況
ASI01	Agent Goal Hijack	攻撃者が直接/間接注入でエージェントの目標を操作	カバー済み
ASI02	Tool Misuse & Exploitation	安全でないツールの組み合わせや過剰な呼び出しが有害な結果を生む	一部カバー
ASI03	Agent Identity & Privilege Abuse	クロスエージェント信頼チェーンを悪用した不正操作	カバー済み
ASI04	Agentic Supply Chain Compromise	外部エージェント・ツール・スキーマ・プロンプトへの侵害	カバー済み
ASI05	Unexpected Code Execution	エージェントが生成・実行するコードが隔離されていない環境で動作	カバー済み
ASI06	Memory & Context Poisoning	メモリやコンテキスト状態への注入/漏洩が将来の推論に影響	未カバー
ASI07	Insecure Inter-Agent Communication	エージェント間メッセージの傍受・注入・なりすまし	未カバー
ASI08	Cascading Agent Failures	小規模なエージェント障害がパイプラインを通じて大規模な影響を与える	未カバー
ASI09	Human-Agent Trust Exploitation	エージェントへの人間の過信を悪用した行動操作	間接的に言及
ASI10	Rogue Agents	目標ドリフトや予期しない動作によりエージェントが意図した目標を超える	間接的に言及

ASI01-ASI05の技術的防御手法については、OWASP Agentic AIセキュリティ防御ガイドを参照。実装方法を網羅的に扱っている。

以下では、3つのギャップ脅威に絞って解説する。

ASI06 メモリポイズニング：最も過小評価されている持続的脅威

なぜ危険か：89%のエージェントがユーザー/セッション間でメモリを共有しており、整合性検証が行われていない（Repello AI, 2026）。

一般的なプロンプトインジェクションはセッション内の攻撃であり、セッション終了とともに終わる。ASI06メモリポイズニングの特徴は「低頻度植え込み・持続的影響」だ。攻撃者は1回のセッションでエージェントの長期記憶ストアに悪意ある情報を注入し、その後数週間の推論に影響を与え続ける（Repello AI, 2026）。攻撃発生点を追跡することも困難だ。

典型的な攻撃経路：

攻撃者が1回のセッションで「ユーザー設定」風の悪意あるデータをエージェントの記憶ストアに注入
次回、別のユーザーがエージェントを使用する際、汚染されたメモリがエージェントの動作に影響
RAGデータソースポイズニング：ベクターデータベースを汚染し、そのナレッジベースに依存する全エージェントに影響

防御方法：ユーザー/テナント別にメモリを分離する。各メモリエントリにソースとセッションをタグ付けする。セカンダリモデルでメモリ書き込みを検証する。メモリエントリに有効期限を設定する。

ASI07 エージェント間通信攻撃：マルチエージェントアーキテクチャの盲点

なぜ危険か：マルチエージェントアーキテクチャ（オーケストレーター＋サブエージェント）は2026年に主流となった。エージェント間通信は通常、信頼を前提としており、暗号化や認証が行われていない。

典型的な攻撃手法：

MitM（中間者攻撃）：A2AやMCPプロトコルのメッセージを傍受
注入：サブエージェントに悪意ある指示を注入し、オーケストレーターからの正規指示に偽装
リプレイ攻撃：傍受した古い指示を再利用して意図しない動作を引き起こす
なりすまし：正規エージェントになりすまして指示を送信

防御方法：各エージェントに固有の暗号化IDを割り当てる（SPIFFE/SPIRE、エージェント間mTLS）。エージェント間メッセージに署名する。下流への各リクエストを再認可する。全エージェント間通信を完全に記録する。

ASI08 カスケード障害：アーキテクチャ設計レベルの問題

なぜ危険か：76%のマルチエージェントシステムにサーキットブレーカーがない（Repello AI, 2026）。オーケストレートされたマルチエージェントシステムでは、1つのサブシステムが侵害されることは、エージェントネットワーク全体への脅威を意味する。

類比：2003年の北米大停電は発電所自体の問題ではなく、障害伝播メカニズムに遮断点がなかったことが原因だ。ASI08も同様に、単一の脆弱性ではなくアーキテクチャ設計の問題だ。

典型的な障害モード：侵害されたエージェントがマルチエージェントパイプライン内で悪意ある指示を伝播させる。リソース枯渇（1つのエージェントが過剰なツール呼び出しをトリガーし、下流システムのリソースを消費）。状態汚染（汚染された出力が別のエージェントの入力となる）。

防御方法：サーキットブレーカーを実装する。安全な障害モードを設計する（エージェントは障害時に継続ではなく一時停止して人間にエスカレーション）。エージェント境界を分離する。可逆操作にはトランザクションロールバック機構を構築する。

OWASP Enterprise Adoption Maturity Model 解説

OWASP State of Agentic AI Security and Governance v2.01（2026年6月1日）は2次元マトリクスを定義している。何を展開しているか（採用層）と、ガバナンスがどの程度成熟しているか（ガバナンス成熟度）だ。

重要な点：この2つの次元は独立している。AT4（コード実行型エージェント）でありながらLevel 0（ガバナンス皆無）という組織は珍しくない。これは最も一般的な高リスクの組み合わせであり、最も見落とされやすい診断の盲点だ。

次元1：採用層AT0-AT5（何を展開しているか）

層	名称	典型的な特徴
AT0	Shadow AI	組織の知識・承認なしに使用されているAIツール
AT1	Vendor Embedded Assistant	ベンダーが完全に管理するAIアシスタント（消費するだけ、構築しない）
AT2	Platform Integrated	データを使用するAIネイティブプラットフォームだが任意コードは実行不可
AT3	Citizen Developer Agent	ローコード/ノーコードプラットフォーム。コードを書かずにワークフローを設定し、実際の組織データを操作
AT4	Code Executing Agent	コードを生成・実行し、ローカルまたはクラウドレベルの権限を持つ
AT5	Custom In-House Agent	組織自製システム。ID・ツール・境界を自組織で管理

セキュリティ責任の転換点はAT3だ。AT1-AT2の「ベンダーが主に責任を負う」から「組織が積極的にガバナンスを行わなければならない」へと移行する。AT4-AT5のセキュリティ責任はほぼ完全に組織自身に帰属する。

次元2：ガバナンス成熟度Level 0-3（ガバナンスがどこまで達しているか）

レベル	名称	核心的特徴
Level 0	Unaware and Ad Hoc	正式なガバナンスの認識なし。シャドーIT実験。ログ最小限。汎用ITインシデント対応を使用
Level 1	Experimentation Without Guardrails	自律的制限と意思決定範囲が定義されていないパイロットプロジェクト。散発的なレッドチームテスト。継続的監視なし。説明責任が曖昧
Level 2	Policy-Defined, Human-in-the-Loop	正式なポリシーと法規制対応（EU AI Act、GDPR）。高影響の意思決定に人間の確認が必要。指名オーナー。ログとバージョン管理の確立
Level 3	Integrated, Continuous Oversight	Agentic AIを重要インフラとして扱う。リアルタイムダッシュボード、キルスイッチ、Governance-as-code

OWASPの公式フレームワークは現在Level 3まで定義している。 業界の一部フレームワーク（Practical DevSecOpsはLevel 4まで、SANSはStage 5まで、CSAはLevel 4まで）にはより高いレベルの定義があるが、これらは各機関独自の拡張フレームワークであり、OWASPの公式標準ではない。引用時は出典の区別に注意が必要だ。

2次元マトリクス：高リスクな組み合わせ

	Level 0	Level 1	Level 2	Level 3
AT1-AT2	低リスク	許容範囲	標準以上	標準以上
AT3	中リスク	改善が必要	最低要件	良好
AT4	高リスク	即時改善が必要	最低要件	目標
AT5	極高リスク	展開すべきでない	最低要件	良好

AT4-AT5 + Level 0-1は即座に対処が必要な組み合わせだ。上記の54ポイント差のデータを考えると、多くの組織がまさにこの位置にいる。

セキュリティ成熟度の自己評価方法

5次元スコアリング法（Practical DevSecOps, 2026）

各次元0〜10点、合計点が成熟度レベルに対応する。

次元	0点（Level 0）	5点（Level 1-2境界）	10点（Level 3）
AIアセットインベントリ	どのエージェントが存在するか全く不明	主要エージェントは把握、シャドーAIは未棚卸	シャドーAIを含む完全なインベントリ
ポリシーとコンプライアンス	AIポリシーが一切ない	汎用AIポリシーあり、規制へのマッピングなし	規制フレームワークに対応した正式なポリシー
監視と検知	監視なし	基本的なアラートあり、ランタイム監視なし	リアルタイムのツール呼び出し監視
テストと検証	セキュリティテストを実施したことがない	散発的なレッドチームテスト、定期的な計画なし	四半期ごとのレッドチーム＋継続的な自動化テスト
インシデント対応	汎用ITプロセスを使用	AI専用プレイブックはあるが未演習	演習済みのAIインシデント対応プロセス

採点基準：0〜10点=Level 0、11〜25点=Level 1、26〜40点=Level 2、41〜50点=Level 3

79%の組織がこのスコアリングでLevel 1（11〜25点）に留まる。スコアを引き下げている主な次元は「監視と検知」と「AIアセットインベントリ」だ。

企業版と個人開発者版：現実的な差異

企業版Level 2の要件：

指名されたエージェントオーナー（全エージェントに責任者が明確）
高影響操作のための人間による確認ワークフロー
ツール呼び出しの完全なログ（各操作でエージェントID・承認者・アクセスデータ・操作内容・ポリシー結果・タイムスタンプをキャプチャ）
NIST AI RMFの4つの機能との対応（Govern/Map/Measure/Manage）
四半期ごとのレッドチームテスト

個人開発者/小規模ツールのLevel 2要件（現実的なバージョン）：

基本的なツール呼び出しログ（エージェントが何をしていつ行ったかを記録）
ツールごとの明示的な最小権限（エージェントに必要なツールのみを提供、全権限を開放しない）
エージェントごとの独自ID（共有アカウントや共有APIキーを使わない）
最低でも各リリース前に手動のセキュリティレビューを1回実施

CISAが定めるSHA-256ハッシュチェーンログや6ヶ月保持は個人開発者には非現実的だ。重要なのは完璧な企業コンプライアンス標準に合わせることではなく、オブザーバビリティの習慣を作り始めることだ。

Level 1からLevel 3への90日ロードマップ

出典：Repello AI 2026年OWASP Agentic AI Top 10エンタープライズ実装ロードマップ。

Phase 1（第1〜4週）：可視性の確立

シャドーAIを含む全エージェント展開を棚卸し
各エージェントに対して爆発半径評価を実施（このエージェントが侵害された場合の最悪シナリオは何か）
ASIリスクベースラインを構築（ASI01〜ASI10に対して対応するコントロールが存在するか確認）

Phase 2（第5〜8週）：クイックウィン

サービスアカウントの権限を縮小し、短命な認証情報を実装
コード実行環境をサンドボックス化
ユーザー/テナント別にエージェントメモリを分離（ASI06の最低要件に対応）
ツール呼び出しログを確立（Level 2の最低要件）

Phase 3（第9〜12週）：積極的防御

目標変更とツール誤用のプレ実行検証を展開
行動異常検知を実装
署名付き証明書でサプライチェーンを強化（ASI04に対応）
マルチエージェントシステムにサーキットブレーカーを追加（ASI08に対応）

Phase 4（継続）：継続的な検証

エージェント型攻撃ベクターに特化した専門的レッドチームテストを実施
行動ベースラインを維持し定期的に再検証
ポリシーの自動実行のためのGovernance-as-codeを構築

個人開発者の簡略化パス：

Phase 1 + Phase 2の基礎作業（インベントリ、最小権限ツール、ツール呼び出しログ）を完了すれば、個人ツールに適したLevel 2水準に達することができる。Phase 3〜4は企業が優先すべき項目だ。

各成熟度レベルの実際の様子

以下のシナリオは、OWASPのLevel定義に基づいた典型的な組織の状況を描写するものであり、特定の組織の実体験を主張するものではない。

Level 0の典型的なシナリオ：Claude Codeでサイドプロジェクトを作る独立した開発者。ツールの権限を一度も確認したことがなく、エージェントはシェルアクセスを持っているがAPIキーが漏洩しているかどうか不明。異常が発生した場合、AI専用のインシデントプロセスなしに汎用的な方法で対処する。

Level 1の典型的なシナリオ：LLM Guard をAPIの前に展開し、基本的なプロンプトフィルタリングも行っている小規模SaaS企業。しかしAIアセットインベントリはない（他にどのエージェントが動いているか不明）。APIキー漏洩事件がきっかけで、初めて臨時のセキュリティスキャンを実施した。説明責任が曖昧だ。

Level 2の典型的なシナリオ：AIアセットインベントリを構築し、四半期ごとにレッドチームテストを実施し、ツール呼び出しの基本的なログ記録を行っている中規模企業。高影響の意思決定には人間の確認が必要。ただし監視は定期的なバッチ処理であり、リアルタイムアラートではない。

Level 3の典型的なシナリオ：大手金融機関や規制対象業種。リアルタイムダッシュボードがエージェントの行動ドリフトを追跡し、自律性を即時停止できるキルスイッチがある。ガバナンスポリシーは機械可読であり、AIライフサイクル全体で自動的に適用される。全ての意思決定が完全に追跡可能だ。

結論

まず5分間の自己評価から始めよう。上の5次元スコアリング表に照らして、自分のシステムにスコアをつけてみる。合計が11〜25点であれば、Level 1にいる。組織の79%と同じだ（Practical DevSecOps, 2026）。

そこからの意思決定の道筋は明確だ。

個人開発者または小規模ツールを構築している場合、AT1-AT2の優先アクションはベンダーのセキュリティポリシーを確認することだ。AT4-AT5であれば、Phase 1 + Phase 2の基礎作業（最小権限ツール＋ツール呼び出しログ＋エージェントごとの独自ID）を今月の開発計画に優先的に組み込む。

企業のセキュリティまたはエンジニアリングリーダーであれば、Level 2が責任ある本番展開のための最低閾値だ。OWASPフレームワークによると、指名オーナーなし、ツール呼び出しログなし、人間による確認機構なしでAT4-AT5のエージェントを展開することは、Level 0-1の高リスクな組み合わせに該当し、本番環境への展開は推奨されない。

技術的防御の具体的な実装（ASI01-ASI05のツールチェーン・設定方法・コードレベルの防護）については、OWASP Agentic AIセキュリティ防御技術ガイドで詳しく解説している。