LLMエージェントのEcosystem・Governance層を設計する

LLMエージェントのセキュリティ対策として、プロンプトインジェクション対策やツール権限の最小化はすでに多くのチームが取り組んでいる。しかし、エージェントスタック全体をアーキテクチャレベルで評価するフレームワークを使って、外部エコシステムとガバナンスの設計を体系的に検証したことがあるチームは少ない。

本記事は、2026年5月に発表されたarXivプレプリント「A Systematic Survey of Security Threats and Defenses in LLM-Based AI Agents: A Layered Attack Surface Framework」（arXiv:2604.23338）が提唱するLASM（Layered Attack Surface Model）の**Ecosystem層（L6）とGovernance層（L7）**に絞った実践ガイドだ。

既存記事との差別化を明確にしておく。 本サイトのNSAのMCPセキュリティ設計指針解説はNSA公式ガイダンスの概要紹介、MCPのtool poisoning防御設計はMCP固有の3リスクへの防御設計に特化している。本記事は**LASM全体の上位2層という「アーキテクチャ境界レベルの攻撃面」**を、実装チェックリストに落とし込む点が異なる。サードパーティ統合のリスク管理と人間監視ゲートの具体的な実装パターンだけに集中して読んでほしい。

---

LASMの7層モデル：エージェントスタックを構造化する

LASMは、LLMエージェントの攻撃面を7つの層として定義する。各層が固有の攻撃ベクターと防御要件を持ち、層をまたぐ攻撃経路を体系化できるのが特徴だ（arXiv:2604.23338、2026年5月公開、査読前プレプリント）。

層	名称	主な攻撃面
L1	Foundation	ベースモデル・ファインチューニング・量子化
L2	Cognitive	CoT・ReAct推論ループ・プロンプト処理
L3	Memory	ベクターDB・セッション状態・長期記憶
L4	Tool Execution	ツール定義・サンドボックス・コード実行
L5	Multi-Agent Coordination	エージェント間委譲・信頼伝播
L6	Ecosystem	外部API・プラグイン・MCPサーバー・依存関係
L7	Governance	人間監視・ポリシー適用・監査証跡・自律性制御

LASMが重要なのは、攻撃の「時間軸」も分類している点だ。瞬時攻撃（T1）・セッション持続（T2）・クロスセッション累積（T3）・サブセッションスタック（T4）という4クラスの時間的攻撃パターンを定義し、L5〜L7 × T3〜T4の組み合わせが最も危険な新興脅威だと指摘している。

L1〜L5が「ランタイム層」であるのに対し、L6はデプロイ時アーティファクト（MCPサーバー・パッケージ・モデルチェックポイント）を定義するエコシステム境界として機能する。L7はスタック全体を横断するガバナンスプレーン（観測チャンネルと政策適用の書き戻し）として描かれる。

---

Ecosystem層（L6）：サードパーティ統合の攻撃面とリスク管理設計

L6が定義する攻撃面

Ecosystem層は、エージェントが「外部の世界」と接続するあらゆるインターフェースを含む。

• 外部APIプロバイダー：検索、データ取得、外部サービス連携
• プラグインマーケットプレイス：コミュニティ提供のツール・スキル
• MCPサーバー：ファイルシステム・DB・ブラウザ操作などのコンテキストプロバイダー
• エージェントフレームワーク依存関係：LangChain、LlamaIndex、AutoGenなどのライブラリ
• モデルチェックポイント：Hugging Faceなどからダウンロードしたモデルの重み

LASMが強調するのは、L6はいわゆる「サプライチェーン問題」として矮小化できない点だ。SBOM（Software Bill of Materials）スタイルのパッケージ検証は依存関係の列挙にとどまり、ツール定義のコンテンツレベルのリスク（ツール説明文に埋め込まれた悪意ある指示など）を捕捉できない。LASMはL6を「ABOM（Agent Bill of Materials）拡張が必要な制御ポイント」として位置づけ、コンテンツレベルの検証を求める。

L6の代表的リスクシナリオ

シナリオ1：MCPサーバーのサプライチェーン侵害

Endor Labsの調査（2026年）では、2,614件のMCP実装の分析結果として82%がパストラバーサルに脆弱なファイル操作を使用、67%がコードインジェクション関連APIを使用、34%がコマンドインジェクションに脆弱なAPIを使用していた。また、公認なしで公開されているMCPサーバーが8,000以上存在することも確認されている。

コミュニティが提供するMCPサーバーを審査なしで本番エージェントに接続するのは、ソースを確認していないnpmパッケージをsudo権限で実行するのに等しい。

シナリオ2：プラグインマーケットプレイスのリポジトリハイジャック

公開スキルマーケットプレイスでは、アカウント乗っ取りや放棄リポジトリの再取得を通じて、攻撃者が正規の人気スキルの信頼と配布チャンネルを悪用して悪意あるアップデートを配信できる。LASMはこれをT3（クロスセッション累積）脅威の典型例として挙げる。

シナリオ3：フレームワーク依存関係のバックドア

エージェントフレームワークやLLMクライアントライブラリへの悪意あるコミット。CI/CDパイプラインで依存関係の固定バージョンを使っていないチームが最もリスクを受けやすい。

Ecosystem層の実装チェックリスト（12項目）

統合前の検証（デプロイ時）

• ソース確認：MCPサーバー・スキル・プラグインのソースコードを必ずレビューする（バイナリ配布のみは受け入れない）
• コード署名の検証：可能な限りコード署名またはハッシュ検証を実装する（npm --dry-run、pip hash検証など）
• サンドボックス隔離：新規サードパーティツールは本番前に隔離環境でテストする
• 最小権限スコープ：各外部APIのOAuthスコープ・IAMロールを「そのツールが行う最小限の操作」に絞る
• 依存関係のピン留め：package-lock.jsonまたはpoetry.lockで依存関係を特定バージョンに固定し、Dependabotなどで更新通知を受ける
• ABOM（Agent Bill of Materials）の作成：エージェントが統合するすべての外部コンポーネント（API・MCP・プラグイン）のインベントリを管理する

運用中の継続監査

• 定期的な依存関係監査：月次でのセキュリティスキャン（npm audit、pip-audit）を自動化する
• APIレスポンスの検証：外部APIのレスポンスをスキーマ検証し、予期しない形式のデータがエージェントのCognitive層（L2）に到達しないよう遮断する
• ツール説明文の静的解析：MCPサーバーのツール定義に埋め込まれた不審な指示（「前の指示を無視して」などのインジェクションパターン）を検出するスキャナーを導入する
• ネットワーク出口の制限：エージェントが呼び出せる外部エンドポイントをホワイトリストで管理し、未知のエンドポイントへのアウトバウンドをブロックする
• バージョン変更の監視：統合している外部ツールのバージョン変更・オーナー変更を検知するアラートを設定する
• 廃止・放棄リポジトリの検出：使用中のオープンソースパッケージのメンテナー活動を追跡し、放棄の兆候があれば代替を検討する

---

Governance層（L7）：人間監視ゲートの実装パターンと自律性制御

L7が定義するガバナンスプレーン

Governance層はLASMの「クロスカッティング」な層として、L1〜L6のすべてのランタイム層を観察・制御する。具体的には次の4つの機能で構成される。

1. Human Oversight（人間監視）：高リスク操作への承認ゲートとHuman-in-the-Loop（HITL）制御
2. Policy Enforcement（ポリシー適用）：許可・禁止アクションのルールエンジン
3. Audit Trails（監査証跡）：エージェントの行動履歴の記録と追跡可能性
4. Accountability Structure（説明責任構造）：誰がどのエージェントに何を承認したかの記録

LASMがL7について特に警告するのは、**「ガバナンスの空洞化（Governance Vacuum）」**だ。エージェントが自律的に行動する範囲が広がるにつれ、「誰が何を承認したか」が曖昧になり、インシデントが発生しても遡及できなくなる。これはCISA Five Eyes指針が「説明責任の欠如（Accountability Gaps）」として指摘する最大リスクの1つでもある。

CISA Five Eyes指針との対応

2026年5月1日、CISA・NSA・ASD ACSC・カナダCCCS・ニュージーランドNCSC-NZ・英国NCSC-UKの6機関が「Careful Adoption of Agentic AI Services」を共同公開した（Five Eyes初のエージェントAI向け専用指針）。この指針が定義する5リスクカテゴリは、LASMのL7設計と直接対応する。

CISA指針のリスクカテゴリ	LASM L7での対応設計
権限昇格（Privilege Escalation）	動的ポリシーエンジンによる権限の段階的解除
設計・設定の失敗（Design & Configuration Flaws）	HITLゲートの設計を「エージェント自身が決定しない」原則の実装
行動の不整合（Behavioral Misalignment）	不変監査ログと異常検知による行動の追跡
構造的脆弱性（Structural Brittleness）	依存関係をL6で管理し、Governance層でカスケード障害を制限
説明責任の欠如（Accountability Gaps）	承認フロー記録と監査証跡の保全

CISA指針のコアメッセージは「エージェントを信頼できないコンポーネントとして扱う」ことだ。これはユーザーと同様に、エージェントのすべてのアクションは認証・最小スコープ権限での認可・ログ記録が必要だということを意味する。Zero Trustをエージェントアーキテクチャに適用した表現だ。

また「HITLゲートの範囲をエージェント自身に決定させない」原則も重要だ。エージェントが「この操作は自分で承認して構わない」と判断できる設計は、CISA指針が明確に否定している。どのアクションが人間の確認を必要とするかは、システム設計者が事前に定義してコードに埋め込む必要がある。

HITLゲートの実装パターン

パターン1：リスクレベル分類ゲート

アクションをリスクレベルで分類し、レベルに応じて承認要件を変える。

from enum import Enum

class RiskLevel(Enum):
    LOW = "low"       # 自動実行OK（読み取り専用・可逆操作）
    MEDIUM = "medium" # ソフト確認（ログ + 5秒タイムアウト付き自動承認）
    HIGH = "high"     # 人間の明示的承認が必要
    CRITICAL = "critical"  # 人間の承認 + 理由の記録が必要

# アクション定義でリスクレベルを事前に設定
ACTION_RISK_MAP = {
    "read_file": RiskLevel.LOW,
    "send_email": RiskLevel.HIGH,
    "delete_record": RiskLevel.CRITICAL,
    "execute_sql_query": RiskLevel.HIGH,
    "call_external_api": RiskLevel.MEDIUM,
}

def gate_action(action_name: str, action_params: dict) -> bool:
    """HITLゲート：アクション実行前に必ず呼ぶ"""
    risk = ACTION_RISK_MAP.get(action_name, RiskLevel.HIGH)  # デフォルトHIGH
    
    if risk == RiskLevel.LOW:
        log_action(action_name, action_params, "auto_approved")
        return True
    elif risk in (RiskLevel.HIGH, RiskLevel.CRITICAL):
        # 外部承認チャンネル（Slack/メール/Webhook）へ通知
        approval = request_human_approval(action_name, action_params, risk)
        log_action(action_name, action_params, "human_approved" if approval else "rejected")
        return approval

パターン2：不可逆操作の明示的マーキング

操作の「可逆性」を設計時に明示し、不可逆操作は常に人間承認を要求する。

@dataclass
class AgentAction:
    name: str
    is_reversible: bool
    rollback_procedure: str | None  # None = 不可逆
    requires_human_approval: bool   # 設計者が事前定義
    
# 不可逆操作の例
DELETE_USER_ACCOUNT = AgentAction(
    name="delete_user_account",
    is_reversible=False,
    rollback_procedure=None,
    requires_human_approval=True,
)

パターン3：段階的権限拡大（Progressive Autonomy）

CISAが推奨する「低リスクタスクから始め、セキュリティコントロールが成熟するにつれて自律性を拡大する」アプローチをコードで実装する。

class AutonomyLevel(Enum):
    SUPERVISED = 1   # すべてのアクションに人間承認が必要
    ASSISTED = 2     # MEDIUM以上のアクションに承認が必要
    AUTONOMOUS = 3   # HIGH以上のアクションのみ承認が必要

def get_current_autonomy_level(agent_id: str) -> AutonomyLevel:
    """
    エージェントの実績（誤動作率・インシデント件数・稼働期間）に基づいて
    自律性レベルを動的に決定する。初期はSUPERVISEDから開始する。
    """
    track_record = load_agent_track_record(agent_id)
    if track_record.days_operational < 30 or track_record.incident_count > 0:
        return AutonomyLevel.SUPERVISED
    elif track_record.error_rate < 0.01:
        return AutonomyLevel.AUTONOMOUS
    return AutonomyLevel.ASSISTED

不変監査ログの設計

Governance層の監査証跡は「書き換えができない」ことが要件だ。通常のアプリケーションログとは異なり、エージェントが自分の行動履歴を消去・改ざんできないことを保証する。

import hashlib
import json
from datetime import datetime, timezone

class ImmutableAuditLog:
    """
    各エントリが前エントリのハッシュを含む連鎖構造（ブロックチェーン的手法）で
    改ざん検出を可能にする監査ログ
    """
    def __init__(self):
        self._entries = []
        self._last_hash = "genesis"
    
    def append(self, event: dict) -> str:
        entry = {
            "timestamp": datetime.now(timezone.utc).isoformat(),
            "event": event,
            "prev_hash": self._last_hash,
        }
        entry_json = json.dumps(entry, sort_keys=True, ensure_ascii=False)
        current_hash = hashlib.sha256(entry_json.encode()).hexdigest()
        entry["hash"] = current_hash
        self._entries.append(entry)
        self._last_hash = current_hash
        # 外部のイミュータブルストレージ（S3 Object Lock、Azure Immutable Blobなど）へ書き込む
        persist_to_immutable_store(entry)
        return current_hash
    
    def verify_integrity(self) -> bool:
        """監査ログの改ざん検出"""
        prev_hash = "genesis"
        for entry in self._entries:
            check_entry = {k: v for k, v in entry.items() if k != "hash"}
            expected_hash = hashlib.sha256(
                json.dumps(check_entry, sort_keys=True, ensure_ascii=False).encode()
            ).hexdigest()
            if expected_hash != entry["hash"] or entry.get("prev_hash") != prev_hash:
                return False
            prev_hash = entry["hash"]
        return True

Governance層の実装チェックリスト（10項目）

HITLゲート設計

• アクションリスク分類の事前定義：エージェントがどのアクションを自律実行していいかを設計者がコードで定義する（エージェント自身が判断しない）
• 不可逆操作の明示的マーキング：削除・送信・外部書き込みなど不可逆操作はすべてフラグを立て、常に人間承認を要求する
• 承認タイムアウト設計：承認待ち中にエージェントが「デフォルト実行」しないよう、タイムアウト後はキャンセルを選択する
• 承認チャンネルの帯域外化：承認通知をエージェントが操作できないチャンネル（Slack、メール、SMS）で送る

監査証跡

• 不変ログストレージ：監査ログをエージェントが書き換えられない外部ストレージ（S3 Object Lock・Immutable Blob等）に保存する
• ログの連鎖整合性：エントリのハッシュ連鎖など改ざん検出メカニズムを実装する
• 「誰が・何を・なぜ承認したか」の記録：承認者ID・理由・承認時刻を監査ログに含める

ポリシーエンジンと自律性制御

• 段階的権限拡大の実装：新規エージェントは最も制限されたSupervisedモードから開始し、実績に基づいて自律性を拡大する
• 緊急停止（Kill Switch）の実装：エージェントの全アクションを即座に停止できる外部制御インターフェースを設計する
• ポリシー設定変更のゲート：ガバナンス設定自体の変更も人間承認と変更管理の対象にする

---

Ecosystem × Governance の統合設計：実装の優先順位

L6とL7は独立した設計要件ではなく、補完関係にある。以下の順序で実装することを推奨する。

フェーズ1（即日着手）：観測基盤の構築

まず現状を「見える化」する。エージェントが呼び出している外部ツールのインベントリ（ABOM）を作り、監査ログを外部ストレージに保存するよう変更する。これは実装コストが低く、他のすべての改善の基礎になる。

フェーズ2（1〜2週間）：ゲート設計

アクションのリスク分類マップを作成し、まずCRITICALに分類した操作だけHITLゲートを実装する。LLMエージェントの過剰権限設計で解説したOWASP LLM06の最小権限チェックリストと組み合わせると効果的だ。

フェーズ3（1ヶ月）：Ecosystem検証パイプライン

依存関係のピン留め・定期監査・MCPサーバーのコンテンツ検証を自動化する。新規サードパーティツールの本番導入には必ずサンドボックステストを挟むプロセスを確立する。

フェーズ4（継続）：段階的自律性拡大

エージェントの稼働実績データ（誤動作率・インシデント件数）に基づいて、承認要件を段階的に緩和する。CISAが推奨する「成熟するまで低リスクタスクに限定する」アプローチの実装版だ。

---

関連記事

• NSAがMCPセキュリティ設計指針を公開：AIエージェント自動化のトラストゾーン分離・DLP・入力検証ガイダンス解説 — MCPを使ったエージェント自動化の公的設計指針。Ecosystem層の設計と合わせて読むと、トラストゾーン分離の方針が具体化する
• LLMエージェントの「過剰権限」を排除する：OWASP LLM06:2025 準拠の最小権限設計チェックリスト — ツール権限スコープの絞り込みとGovernance層のHITL設計の補完資料。L4〜L6のチェックリストとして機能する
• LLMエージェントのトレース異常検知でリソース悪用を早期発見する — Governance層の監査ログを活用した事後検知の実装。L7観測基盤の構体的な実装例
• AIエージェントのアイデンティティ管理：JITエフェメラル認証情報とマルチエージェント認可伝播の実装ガイド — Ecosystem層のサードパーティAPI統合でAPIキー管理をJITエフェメラル認証情報に移行する際の設計パターン

---

FAQ

FAQ

よくある質問

Ecosystem・Governance層の設計について

Q LASMのL6とL7は、既存のOWASP LLM Top 10とどう違うの？

A

OWASP LLM Top 10は「何が問題か」（リスクカテゴリ）を定義するのに対し、LASMは「どのアーキテクチャ層で問題が発生するか」を定義するフレームワークだ。例えばOWASP LLM08「Excessive Agency」はLASMではL6とL7の両方に関連する。LASMを使うと「このリスクをどの層で防御するか」という設計上の問いに答えやすくなる。

Q MCPサーバーはEcosystem層とTool Execution層のどちらに属するの？

A

LASMではMCPサーバーはL6（Ecosystem層）のコンポーネントとして扱われる。MCPサーバーが提供するツールの実行処理はL4（Tool Execution層）で行われるが、MCPサーバー自体のデプロイ・検証・依存関係管理はL6の設計問題だ。本記事ではL6の観点で「MCPサーバーをエコシステムへの統合コンポーネントとして検証する」方法を扱っている。

Q HITLゲートを全アクションに適用するのは現実的じゃない。どこから始めればいい？

A

CISA指針が推奨するのも「すべての操作を人間が承認する」ではない。「高インパクト・不可逆的なアクション」への集中だ。まずアクションリストを「削除・外部送信・アカウント変更・外部API書き込み」などのカテゴリで棚卸しし、その中でis_reversible=Falseに分類したものだけにHITLゲートを実装するのが現実的な出発点だ。その後、実績データに基づいて範囲を調整していく。

Q 監査ログを「不変」にするのはコストがかかりすぎない？

A

S3 Object Lock（WORM設定）やAzure Immutable Blob Storageは、既存クラウドサービスの機能として追加コストなしまたは低コストで使える。エージェントが書き込んだ後に自身でログを書き換えられないことが最低要件だ。ハッシュ連鎖の実装は数十行のPythonで完結する（本記事のコード例参照）。まず「エージェントが書けないストレージ」に向けてログを書き出すだけから始めてよい。

Q CISA指針はどんな組織が対象で、うちには関係ある？

A

CISA指針は当初、高インパクトシステムを運用する政府・重要インフラ事業者を主な対象としている。しかし指針自体は「セキュリティプラクティスが成熟するまで、組織はエージェントAIが予期しない行動をとる可能性を前提に、回復力・可逆性・リスク封じ込めを効率性の優先より上に置くべき」と述べており、この原則は規模・業種を問わずLLMエージェントを本番運用するすべての組織に適用可能だ。

---

参考リンク

• arXiv:2604.23338 — A Systematic Survey of Security Threats and Defenses in LLM-Based AI Agents: A Layered Attack Surface Framework（Kexin Chu他、2026年5月、査読前プレプリント）
• CISA — Careful Adoption of Agentic AI Services（CISA・NSA・ASD ACSC他、Five Eyes共同、2026年5月）

---

次に読むおすすめ

LASMのEcosystem・Governance層の設計をひと通り把握したら、以下のコンテンツで理解をさらに深めてほしい。

• 【2026年最新】主要AIツール5つに自腹課金して徹底比較！生産性が劇的に変わる「用途別・最強の1つ」の選び方（noteで続きを読む）— エージェント設計の前提として、各AIプラットフォームの特性を実務目線で比較した深掘り記事