MCPサーバーのエコシステムが急拡大した2026年、AIエージェントのサプライチェーンは組織の主要な攻撃経路に変わった。Cloud Security Allianceの調査では200,000件超の脆弱なMCPインスタンスが確認されており、そのうち82%がパストラバーサルリスクを抱え、OAuth認証を実装しているのはわずか8.5%だ。npm typosquatting経由の偽MCPサーバー配布、マーケットプレイス汚染、設計起因のRCE脆弱性——これらはコードの問題ではなく、依存管理ガバナンスの欠如が引き起こす構造的失敗だ。
本記事はAIエージェントガバナンスのピラーコンテンツに連動しています。
AIエージェントのサプライチェーンとは何か
AIエージェントの依存関係はモデル・MCP・SDK・プロンプトの4層で構成され、各層が独立した攻撃面になる。
従来のソフトウェアサプライチェーンはコードとパッケージが対象だったが、AIエージェントは異なる性質を持つ依存関係を複数の層に持つ。
- モデル依存: 基盤LLMのウェイト、ファインチューニングデータ、安全評価結果
- プロトコル依存: MCPサーバー、Function Calling定義、A2Aエンドポイント
- SDK・フレームワーク依存: LangChain、LlamaIndex、Anthropic SDK等のnpmやPyPIパッケージ
- ランタイムコンテキスト依存: システムプロンプトのバージョン、メモリ初期化値、外部ツール定義
このうちMCPサーバーは「信頼を付与された通信エンドポイント」として、エージェントのコンテキストに直接命令を注入できる。これが他の依存関係と本質的に異なる点だ。エージェントガバナンスの観点からは、MCP依存を未管理のまま本番運用するのはアクセス制御のないデータベースを外部公開するに等しい。
MCPサーバー依存が抱える構造的リスクとはどれか
MCPの設計上の欠陥と認証の任意化が組み合わさり、パストラバーサル・ツールポイズニング・無認証公開の3種の攻撃面を生む。
Cloud Security Alliance（2026年5月）の調査では、MCPの脆弱性は特定製品のコーディングエラーではなく設計上の欠陥であることが明らかになっている。主な攻撃ベクターは3種類だ。
1. パストラバーサルとRCE
STDIOトランスポートはOS命令をサニタイズなしに実行する設計になっており、これが推定200,000件のインスタンスに影響する。2026年に確認された重大CVEの例を示す。
| CVE番号 | 影響製品 | 深刻度 |
|---|---|---|
| CVE-2026-30623 | LiteLLM | Critical |
| CVE-2025-54136 | Cursor IDE | High |
| CVE-2026-30615 | Windsurf | High（未パッチ） |
| CVE-2026-22252 | LibreChat | High |
これらはすべてMCPの公式SDKが持つデフォルト挙動から生じており、個別パッチで解決できる性質ではない。アーキテクチャレベルの対応が必要だ。
2. ツールポイズニング
悪意あるMCPサーバーはツール定義にプロンプトインジェクションを埋め込み、エージェントを操作して意図しない操作を実行させる。2026年2月には1,184件の悪意あるマーケットプレイススキルが確認された。攻撃者はtyposquatting（名前が酷似したnpmパッケージ）でも偽MCPサーバーを配布しており、事前承認なしに接続されたMCPサーバーが企業APIキーを外部に漏洩する事例が複数報告されている。プロンプトインジェクションの多層防御と連動した対策が不可欠だ。
3. 無認証公開
MCP仕様ではOAuth 2.1は「任意」とされており、2025年7月のスキャンでは1,862台のMCPサーバーが認証なしでインターネットに公開されていた。組織内でシャドーAIとして設置されたMCPサーバーがセキュリティレビューなしに使われている状況は、シャドーAI対策の観点からも放置できない問題だ。
ABOMでサプライチェーンを可視化するにはどうするか
ABOMはSBOMをAI向けに拡張し、モデルウェイト・コンテキスト・MCPサーバーの3層を一元管理する部品表だ。
従来のSBOM（Software Bill of Materials）はコードとパッケージの依存関係を記録するが、AIエージェントの構成要素すべてを捕捉できない。この問題に対応するため、ABOM（Agent Bill of Materials）という概念が提唱されている。ABOMはSBOMを3方向に拡張する。
① 非決定論的コンポーネント（ML-BOM）
モデルウェイト、ファインチューニングデータセット、安全ベンチマーク結果を記録するML-BOMをABOMに統合する。モデルプロバイダーが変更・更新した際に影響を追跡でき、「どのモデルが使われているか」だけでなく「どのデータで学習されたか」まで把握できる。
② ランタイムコンテキストコンポーネント
システムプロンプトのハッシュ値とバージョン（例: v1.2.3@sha256:abc...）、メモリ初期化値、コンテキストウィンドウへの外部データ投入ルートを記録する。システムプロンプトのバージョン管理と連動させることで、プロンプト変更による挙動差異を追跡できる。
③ 信頼エンドポイント（MCPサーバー）
MCPサーバーはエージェントが信頼する通信エンドポイントであり、ABOMの中核をなす。登録すべき属性は以下のとおりだ。
``yaml``
mcp_servers:
- id: "github-mcp-v1.2"
uri: "https://mcp.example.com/github"
version: "1.2.0"
sha256: "a3f9c8..."
auth: "oauth2.1"
scopes: ["repo:read", "issues:write"]
approved_at: "2026-06-01"
approved_by: "security-team"
risk_tier: "tier-2"
vulnerabilities_checked_at: "2026-07-01"
ABOMは静的なコンプライアンス文書ではなく、継続的に更新・クエリ可能なシステムとして運用することが前提だ。脆弱性フィードとの相関付けにより、新たなCVEが公開された瞬間に影響を受けるMCPサーバーを特定し、即応できる。
実装すべき多層ガバナンス統制はどれか
MCP承認ワークフロー・バージョンピニング・ETDI・セッション分離の4層が、供給攻撃の基本的な防御ラインを形成する。
ABOMによる可視化の次は統制の実装だ。以下の4層を組み合わせる。
層1: MCP承認ワークフロー（Allowlist）
新規MCPサーバーの接続をデフォルトで禁止し、セキュリティチームの審査を経たものだけをallowlistに追加する。審査基準として次の4点を設ける。
- リポジトリのメンテナー数と更新頻度（公開30日未満・単一メンテナーはブロック）
- OSSライセンスと公開元の身元確認
- 既知CVEの有無（NVD/OSVデータベース自動照合）
- 要求スコープが最小権限の原則を満たすか
9つのレジストリを横断して調査した結果、単一のレジストリオーナーがベッティングに投資するインセンティブを持たないため、悪意あるパッケージが複数のレジストリを通過した事例が確認されている。組織側でのallowlist管理が唯一の確実な防御だ。
層2: バージョンピニングと署名検証
MCPサーバーのバージョンを固定（"github-mcp": "1.2.0" のように完全バージョン指定）し、更新は明示的な再承認を経てからallowlistを更新する。SLSAレベル3の証明書（ビルドプロセスの暗号署名）を要求することで「どのように作られたか」の検証が可能になる。AIエージェントの権限管理設計と連動したスコープ管理も必須だ。
層3: ETDI（Enhanced Tool Definition Interface）
ETDIはツール定義の整合性を検証する仕組みで、エージェントが受け取ったツール定義が承認済みのものと一致するかを確認する。ツールポイズニング攻撃では攻撃者がツール定義を改ざんしてエージェントの行動を操作するため、ETDIはこれを検知する重要な統制だ。現時点ではMCP仕様に含まれないが、CSAはETDIの採用を推奨している。
層4: セッション分離と最小権限ID
MCPサーバーごとに異なる認証情報を付与し、侵害が一つのサーバーに限定されるよう設計する。エージェントのNon-Human Identity（NHI）管理と統合し、認証情報ローテーションを自動化する。詳細はエージェントのIAMスコープ付き認証情報設計を参照してほしい。
Kuu株式会社のエージェントガバナンス運用管理サービスでは、ABOM設計からMCP承認ワークフローの構築まで一貫した統制基盤の導入を支援している。
規模別の留意点（SMB / エンタープライズ）
SMBの場合
まずMCP承認ワークフローの整備から着手する。現在使用しているMCPサーバーをリストアップし、公式・検証済みのもの以外は接続を停止する。Dependabotなどの依存管理ツールを導入してCVEアラートを自動化すれば、専任セキュリティ担当なしでも最低限の統制を維持できる。ABOMは最初はスプレッドシートでも構わない——可視化すること自体が最初のゴールだ。
エンタープライズの場合
ABOM管理を既存のSBOM管理インフラ（SCAツール、Dependencyトラッキング）と統合する。複数チームが独自にMCPサーバーを接続する「シャドーMCP」問題には、ネットワーク境界でのMCPトラフィック可視化とCASBライクな承認ゲートが有効だ。LLMゲートウェイ設計との組み合わせで全社のAIツール通信を一元的に統制できる。MAESTROなどの脅威モデリングフレームワークをMCP依存に適用した統制基盤の設計については、Kuuのエンタープライズ実装サービス（RDE）に相談してほしい。
参考
- MCP Security Crisis: Systemic Design Flaws in AI Agent Infrastructure — Cloud Security Alliance, 2026年5月
- The 2026 Guide to Software Supply Chain Security: From Static SBOMs to Agentic Governance — Cloudsmith, 2026年
- SBOMs into Agentic AIBOMs: Schema Extensions, Agentic Orchestration, and Reproducibility Evaluation — arXiv, 2026年3月
まとめ
AIエージェントのサプライチェーンリスクはMCPサーバーの急速な普及とともに、組織のセキュリティ設計の前提を塗り替えた。200,000件超の脆弱インスタンス、8.5%のOAuth採用率、7件の重大CVE——これらは「後から対処する」問題ではなく、エージェントシステムの設計段階から組み込むべきガバナンス要件だ。
ABOM（エージェント部品表）による依存の可視化、MCP承認ワークフロー、バージョンピニング、ETDIによるツール整合性検証、セッション分離——この4層の統制を組み合わせることで、現実的なサプライチェーン防御が成立する。一度整備すれば継続的に更新・運用できる基盤として機能する。
エージェントガバナンスの統制基盤設計について、Kuu株式会社のAI Opsサービスにご相談ください。