【2026年版】AIエージェントの「脅威モデリング」実践ガイド——“個別攻撃対策”を貼り続ける前に、攻撃面を体系的に洗い出す｜MAESTRO（エージェント7層）×STRIDEで、プロンプトインジェクション・権限昇格・ツール汚染・メモリ汚染・多エージェント伝播を設計段階でマッピングし、“点の対策”を“面の防御アーキテクチャ”に束ねる

AIエージェントのセキュリティ記事は、いま「個別攻撃の解説」で溢れています。プロンプトインジェクション、権限昇格、ツールポイズニング、メモリ汚染——ひとつひとつは重要な論点です。しかし個別対策を貼り続けるだけでは、防御はいつまでも「モグラ叩き」から抜け出せません。本記事は、対策を打つ前に攻撃面（アタックサーフェス）そのものを設計段階で体系的に洗い出すための実践ガイドです。CSA（Cloud Security Alliance）が提唱するMAESTRO（エージェントを7層に分ける脅威モデリング枠組み）と、古典的なSTRIDEを掛け合わせ、「点の対策」を「面の防御アーキテクチャ」へ束ね直す方法を解説します。

この記事でわかること

  • なぜ「個別攻撃対策の積み上げ」だけでは防御が破綻するのか
  • MAESTROの7層モデルで、AIエージェントの攻撃面をどう分解するか
  • STRIDEとの掛け合わせで、各層の脅威をどう洗い出すか
  • プロンプトインジェクション・権限昇格・ツール汚染・メモリ汚染・多エージェント伝播が「どの層のどの脅威か」
  • 設計段階の脅威モデリングをCI/CDに組み込み、運用まで回す実践手順

目次

  1. はじめに——「個別対策の積み上げ」がモグラ叩きになる理由
  2. 前提——脅威モデリングとは「攻撃面を先に地図化する」こと
  3. MAESTRO——エージェントを7層に分けて脅威を洗い出す
  4. STRIDE——古典的6分類をエージェントに当てはめ直す
  5. MAESTRO×STRIDE——主要攻撃を層でマッピングする
  6. クロスレイヤー脅威——「組み合わせ」で増える攻撃面
  7. 標準フレームワークでの位置づけ（OWASP LLM Top 10／MITRE ATLAS）
  8. 設計段階からCI/CDへ——脅威モデリングを「生きた成果物」にする
  9. 攻撃面マッピング・チェックリスト
  10. よくある質問（Q&A）
  11. まとめ——「点の対策」を「面の防御」に束ねる
  12. 参考リンク

はじめに——「個別対策の積み上げ」がモグラ叩きになる理由

2026年、AIエージェントは「単発でプロンプトに応答するチャットボット」から、「複数のエージェントが連携し、外部ツールを呼び出し、長期記憶を持ち、数日から数週間にわたって稼働する自律システム」へと変わりました。守る対象が変わると、攻撃面も変わります。

ところが、いま世に出ているセキュリティ記事の多くは「個別攻撃の解説」に集中しています。プロンプトインジェクションの記事、権限昇格の記事、ツールポイズニングの記事——それぞれは正確で有用です。しかし読者（設計者）の側から見ると、次の問いに答えられないまま対策だけが積み上がっていきます。

  • この対策は、システムのどこに効いているのか？
  • まだ洗い出せていない攻撃面はどこか？
  • 限られた予算を、どの層の防御に優先配分すべきか？

個別対策を貼り続けるアプローチは、攻撃者が新しい入口を見つけるたびに後追いで穴を塞ぐ「モグラ叩き」になります。エージェントが複数連携・長期運用されるほど、攻撃面は単純な足し算ではなく「組み合わせ」で増えます。全体像を俯瞰できないまま個別対策を続けると、投資配分を誤り、重大な入口を見落とします。

解決策は、対策を打つ前に攻撃面を設計段階で体系的に地図化すること——すなわち脅威モデリングです。本記事では、AIエージェント向けに設計されたMAESTROと、古典的なSTRIDEを組み合わせ、実務で使える「攻撃面マッピングの入口」を提示します。

前提——脅威モデリングとは「攻撃面を先に地図化する」こと

脅威モデリングとは、システムを構成要素・信頼境界・データフローに分解し、「どこに、誰が、何をし得るか」を設計段階で洗い出す作業です。攻撃が起きてから対応する事後対応（監査・報告・インシデント対応）に対して、脅威モデリングは事前・アーキテクチャ層の営みです。

2つの層は補完関係にある

監査チェックリストやNIST AI RMFに基づくガバナンスは「事後・ガバナンス層」で、「何が起きたか・報告できるか」を担保します。本記事が扱う脅威モデリングは「事前・アーキテクチャ層」で、「そもそも何が起こり得るか」を設計段階で地図化します。どちらか一方ではなく、両方が必要です。

従来のWebアプリでは、STRIDEやデータフロー図（DFD）で十分でした。しかしAIエージェントには、従来のフレームワークが想定していない固有の攻撃面があります。たとえば——

  • 非決定的な振る舞い：同じ入力でも出力が変わり得るため、「入力検証だけ」では防げない
  • 自然言語が制御平面になる：データ（プロンプト）と命令の境界が曖昧で、注入が制御を奪う
  • ツール／外部システムへの権限：エージェントが実世界に副作用を及ぼす（ファイル操作、API呼び出し、決済）
  • 長期記憶：一度汚染された記憶が、後続のセッションに影響を持ち越す
  • エージェント間連携：あるエージェントの侵害が、連携する他エージェントに伝播する

これらを体系的に扱うために設計されたのがMAESTROです。

MAESTRO——エージェントを7層に分けて脅威を洗い出す

MAESTRO（Multi-Agent Environment, Security, Threat, Risk, & Outcome）は、CSAが2025年に公開したエージェント向け脅威モデリング枠組みです。エージェントシステムを7つの層（レイヤー）に分解し、各層の脆弱性と、層をまたぐ相互作用の両方を洗い出すのが特徴です。

層名称代表的な脅威
Layer 1Foundation Models（基盤モデル）敵対的サンプル、モデルへのデータポイズニング、プロンプトインジェクション、脱獄（ジェイルブレイク）
Layer 2Data Operations（データ運用）学習・RAGデータの汚染、ベクトルDBへの汚染注入、機密データの漏えい
Layer 3Agent Frameworks（エージェント基盤）ツールポイズニング、コンポーネント／プラグインのバックドア、権限昇格、Confused Deputy
Layer 4Deployment & Infrastructure（配備・基盤）コンテナ侵害、オーケストレーション攻撃、シークレット／認証情報の露出
Layer 5Evaluation & Observability（評価・可観測性）評価指標の改ざん、監視の無効化、ログ改ざんによる否認
Layer 6Security & Compliance（横断層）セキュリティエージェントの回避、統制のバイアス、ポリシー迂回
Layer 7Agent Ecosystem（エージェント・エコシステム）エージェントなりすまし、マーケットプレイス汚染、A2A（エージェント間）での攻撃伝播

表1：MAESTROの7層と代表的な脅威。Layer 6はすべての層を貫く「横断（vertical）層」として扱われます。

ポイントは、Layer 6（Security & Compliance）が他の6層すべてを貫く横断層として設計されていることです。セキュリティ統制はどの層にも関わるため、独立した1枚のレイヤーではなく、全体を縦断する軸として位置づけられています。

MAESTROが従来枠組みと決定的に違うのは、各層内の脆弱性だけでなく、層をまたぐ相互作用（クロスレイヤー脅威）を明示的に扱う点です。これは後述する「組み合わせで増える攻撃面」を捉えるうえで欠かせません。

STRIDE——古典的6分類をエージェントに当てはめ直す

STRIDEは、Microsoftが提唱した古典的な脅威分類で、6つの脅威カテゴリの頭文字から成ります。汎用的な脆弱性の洗い出しには今も有効です。

STRIDE脅威侵害される性質AIエージェントでの例
SSpoofing（なりすまし）認証正規エージェント／ユーザーになりすまして権限を得る
TTampering（改ざん）完全性プロンプト・ツール定義・メモリ・RAGデータの改ざん
RRepudiation（否認）否認防止ログ改ざんで、誰が何をしたかを追跡不能にする
IInformation Disclosure（情報漏えい）機密性システムプロンプト・PII・認証情報の抽出
DDenial of Service（サービス妨害）可用性トークン枯渇、無限ループ誘発、コスト増大攻撃
EElevation of Privilege（権限昇格）認可ツール権限の逸脱、Confused Deputyによる権限の借用

表2：STRIDEの6分類とAIエージェントでの現れ方。

STRIDE単体ではAI固有の脅威（敵対的機械学習、データポイズニング、非決定的な振る舞い）を十分に捉えきれません。CSA自身も「STRIDEはAI固有の脅威をカバーする範囲が足りない」と指摘しています。だからこそ、層を分けるMAESTRO（縦軸）と、脅威の種類を分けるSTRIDE（横軸）を掛け合わせることに意味があります。

MAESTRO×STRIDE——主要攻撃を層でマッピングする

ここが本記事の核心です。世に出ている個別攻撃の解説を、「どの層（MAESTRO）の、どの脅威種別（STRIDE）か」という2軸で束ね直します。こうすると、バラバラだった対策記事が1枚の地図の上に配置され、「どこが手薄か」が一目で分かるようになります。

攻撃主なMAESTRO層STRIDE分類設計段階の主な対策
プロンプトインジェクション（直接／間接）Layer 1（基盤モデル）／ Layer 2（データ）Tampering / Elevation入力の信頼境界の明示、データと命令の分離、間接注入源（RAG・Web）の隔離
権限昇格 / Confused DeputyLayer 3（基盤）Elevation of Privilegeツール単位の最小権限、能力スコープ限定、ツール呼び出し時の認可チェック
ツールポイズニングLayer 3（基盤）／ Layer 7（エコシステム）Tampering / Spoofingツール定義の署名・検証、MCPサーバーの出所確認、レジストリの信頼管理
メモリ汚染（長期記憶）Layer 2（データ）Tampering記憶書き込みの検証、汚染ソースの隔離、記憶のTTL／出所タグ付け
システムプロンプト／PII抽出Layer 1（基盤モデル）Information Disclosure出力フィルタ、機密の外部化、最小開示原則
多エージェント伝播（A2A）Layer 7（エコシステム）Spoofing / Elevationエージェント間の相互認証、メッセージ検証、目標整合性の監視
認証情報／シークレット露出Layer 4（基盤）Information Disclosureシークレット管理、環境変数の分離、外部API資格情報の最小化
監視回避・ログ改ざんLayer 5（評価・可観測性）Repudiation改ざん耐性ログ、独立した監査経路、可観測性の担保
コスト増大・DoSLayer 4（基盤）Denial of Serviceレート制限、トークン上限、ループ検知、予算アラート

表3：主要攻撃のMAESTRO×STRIDEマッピング。既存の個別攻撃記事は、この表のどこかのセルに必ず収まります。

この地図の効用は、「網羅性の確認」にあります。もし特定の層や特定のSTRIDE分類にひとつも対策が置かれていなければ、そこが手薄な攻撃面です。個別記事を100本読むより、この1枚で「投資配分の抜け」を発見できます。

各攻撃の詳細は個別記事へ（内部リンク）

クロスレイヤー脅威——「組み合わせ」で増える攻撃面

単層の脅威だけを潰しても不十分です。MAESTROが強調するのは、層をまたいで連鎖する脅威です。攻撃面がエージェント連携で「組み合わせ」的に増えるのは、まさにここが原因です。代表的なクロスレイヤー脅威は次の3つです。

  1. サプライチェーン伝播：あるコンポーネント（Layer 3）の汚染が、配備基盤（Layer 4）やエコシステム（Layer 7）へ広がる。
  2. 横方向移動（Lateral Movement）：ある層で得たアクセスを足がかりに、別の層を侵害する。たとえばLayer 1へのプロンプトインジェクションが、権限チェックのないツール実行（Layer 3）へ連鎖する。
  3. 目標のずれ（Goal Misalignment）の連鎖：あるエージェントの逸脱した目標が、連携する他エージェント（Layer 7）へ波及する。

連鎖の具体例

Webページに埋め込まれた間接プロンプトインジェクション（Layer 1へ注入）が、権限チェックなしのツールディスパッチ（Layer 3）を経由してシェル実行に到達し、環境変数から外部APIへ認証情報が流出する（Layer 4）——という信頼境界の連続的な越境は、実際のエージェント診断で繰り返し観測されています。各層を単独で見ていると、この一本の攻撃経路は決して見えてきません。

標準フレームワークでの位置づけ（OWASP LLM Top 10／MITRE ATLAS）

MAESTRO×STRIDEの地図は、業界標準の脅威カタログとも接続できます。設計段階のマッピングを、既存の共通言語に紐づけておくと、監査・報告フェーズへの橋渡しがスムーズになります。

  • OWASP Top 10 for LLM Applications：プロンプトインジェクション（LLM01）、機密情報漏えい、過剰なエージェンシー（Excessive Agency）などの項目は、上記マッピングの各セルに対応づけられます。「どの層のどの脅威が、OWASPのどの項目か」を並べると、抜けの確認が容易になります。
  • MITRE ATLAS：AIシステムに対する敵対的な戦術・技術のナレッジベース。各脅威を具体的な攻撃技術（TTP）へ落とし込む際の参照先になります。実務ツールでは、検出した脅威をMITRE ATT&CK／ATLASの技術IDへ自動マッピングする動きも進んでいます。

役割分担で整理すると、MAESTROが「どこ（層）」、STRIDEが「どんな種類」、OWASP LLM Top 10が「代表的な項目」、MITRE ATLASが「具体的な攻撃技術」を担います。4つを重ねることで、抽象から具体までを一本の線でつなげます。

設計段階からCI/CDへ——脅威モデリングを「生きた成果物」にする

脅威モデリングを一度きりの設計文書で終わらせると、コードの変化にすぐ置き去りにされます。2026年の実践では、脅威モデリングをCI/CDパイプラインに組み込み、継続的に更新・強制するアプローチが標準的な入口になりつつあります。

具体的な運用像は次の通りです。

  1. 資産・データフローの棚卸し：エージェントが持つツール（シェル実行、ファイル操作、DB照会、Web閲覧など）、資産、データフロー、信頼境界を洗い出す。
  2. 7層×STRIDEで脅威を列挙：表3の地図に沿って、各層・各分類の脅威を機械的に確認する。
  3. プルリクエストごとの差分スキャン：コード全体を毎回再スキャンするのではなく、ブランチ間で脅威プロファイルを比較（threat diff）し、「そのPRで新たに導入・変化した脅威だけ」を提示する。
  4. クリティカル脅威でPRを自動失敗：重大なエージェント脅威を検出したらPRを失敗させ、修正が最も安いその場でフィードバックする。
  5. 修正の常態化：差分が毎コミットで可視化されるため、開発者が層間のバリデーション・ツールディスパッチの権限チェック・能力スコープ限定を自発的に足すようになる。

この運用に乗せると、脅威モデルは「静的なコンプライアンス文書」から「コードベースの一部として継続的に更新・強制される生きた成果物」へと変わります。設計段階の攻撃面マッピングを、運用まで途切れさせない——これが本記事のゴールです。

攻撃面マッピング・チェックリスト

設計レビュー時に、次のチェックリストを上から順に確認してください。すべてに「対策の置き場所」が答えられれば、少なくとも主要な攻撃面は地図化できています。

  • □ エージェントの信頼境界（入力・ツール・記憶・エージェント間）を図に描き出したか
  • □ MAESTROの7層それぞれに、想定脅威を1つ以上列挙したか
  • □ 各脅威をSTRIDEの6分類に割り当て、抜けている分類がないか確認したか
  • □ データ（プロンプト）と命令の分離を設計に組み込んだか（Layer 1）
  • □ RAG・Web・記憶など間接注入源を隔離・検証しているか（Layer 2）
  • □ ツールを最小権限・能力スコープ限定で定義したか（Layer 3）
  • □ ツール呼び出し時に認可チェックを挟んでいるか（Confused Deputy対策）
  • □ シークレット・認証情報を分離・最小化したか（Layer 4）
  • □ 改ざん耐性のあるログと独立した監査経路を用意したか（Layer 5）
  • □ エージェント間の相互認証・メッセージ検証を設計したか（Layer 7）
  • □ クロスレイヤーの攻撃経路（横方向移動・伝播）を1本以上たどってみたか
  • □ 脅威モデルをCI/CDに組み込み、PR差分で継続確認できる仕組みにしたか

よくある質問（Q&A）

Q1. MAESTROとSTRIDEはどちらか一方でよいのでは？

両方使うことをおすすめします。STRIDEは「脅威の種類」を分ける横軸として優秀ですが、AI固有の脅威をカバーする範囲が足りません。MAESTROは「エージェントのどの層か」を分ける縦軸として優秀です。2軸を掛け合わせることで、初めて「どの層のどの種類の脅威が手薄か」を面で把握できます。

Q2. 小規模なチームでも脅威モデリングは必要ですか？

必要です。むしろ小規模なほど、限られた予算をどの防御に配分するかの判断が重要になります。攻撃面を地図化しておけば、「まず塞ぐべき入口」の優先順位が明確になり、個別対策のモグラ叩きにコストを溶かさずに済みます。

Q3. すでに監査チェックリストやNIST AI RMFを運用しています。重複しませんか？

重複しません。監査・NIST AI RMFは「事後・ガバナンス層（何が起きたか・報告できるか）」を担い、本記事の脅威モデリングは「事前・アーキテクチャ層（そもそも何が起こり得るか）」を担います。両者は補完関係で、片方だけでは防御が片肺になります。

Q4. プロンプトインジェクションはMAESTROのどの層の問題ですか？

主にLayer 1（基盤モデル）への注入ですが、間接注入の場合はLayer 2（データ運用）が入口になり、権限チェックのないツール実行（Layer 3）へ連鎖します。単層ではなくクロスレイヤーで捉えるのが重要です。

Q5. 脅威モデリングは設計時に一度やれば十分ですか？

不十分です。コードやツール構成が変われば攻撃面も変わります。2026年の実践では、脅威モデルをCI/CDに組み込み、プルリクエストごとに差分（threat diff）を確認して継続的に更新・強制する運用が推奨されています。

まとめ——「点の対策」を「面の防御」に束ねる

AIエージェントの防御は、個別攻撃対策を貼り続ける「点」の発想では破綻します。エージェントが連携・長期運用されるほど、攻撃面は組み合わせで増えるからです。本記事の要点を振り返ります。

  • 対策を打つ前に、攻撃面を設計段階で地図化する（＝脅威モデリング）ことが出発点。
  • MAESTRO（7層）を縦軸、STRIDE（6分類）を横軸に取り、主要攻撃を1枚の地図へ配置する。
  • 単層だけでなくクロスレイヤーの攻撃経路をたどることで、見えなかった一本の連鎖を可視化する。
  • OWASP LLM Top 10・MITRE ATLASと接続し、抽象から具体・事後ガバナンスまでを一本の線でつなぐ。
  • 脅威モデルをCI/CDに組み込み、生きた成果物として継続的に更新・強制する。

「公開した瞬間に攻撃され得る」を前提に、点の対策を面の防御アーキテクチャへ束ね直す。その入口として、MAESTRO×STRIDEはいま最も実務的な選択肢のひとつです。まずは自社エージェントの信頼境界を1枚の図に描き、表3の地図に当てはめるところから始めてみてください。

免責事項：本記事は一般的な情報提供を目的としたものであり、特定の環境における網羅的なセキュリティ対策を保証するものではありません。実際の導入にあたっては、各組織の要件・リスク許容度に応じて、専門家の助言を得たうえで判断してください。フレームワークの仕様は更新される可能性があるため、実装時は一次情報を確認してください。

参考リンク

コメント

タイトルとURLをコピーしました