約10,000件の開発者環境から見えてきた、エージェント型開発のリスク

主な調査結果

• AIコーディングツールの乱立は一般的：開発者の43%が、2つ以上のAIコーディング環境を利用しています。

• MCPはすでに広く普及：開発者の50.8%が、少なくとも1つのMCPサーバーをインストールしています。

• MCPのリスクはすでに顕在化：MCPサーバーを利用する開発者の7人に1人で、少なくとも1件のセキュリティ上の問題が見つかりました。

• エージェントスキルが新たなリスクレイヤーに：開発者の22.8%が、少なくとも1つのスキルをインストールしていました。

• アクティブなツールにプロンプトインジェクションが存在：Snykは、ツールの説明文に埋め込まれたプロンプトインジェクションを392件確認しました。

アプリケーションセキュリティチームは長年、次のような馴染みのある問いに取り組んできました。コードは安全か？依存関係に脆弱性はないか？ビルドパイプラインは保護されているか？問題を本番環境に到達する前に検出できているか？

エージェント型開発では、新たな問いが生まれます。このコードの生成に、どのシステム、ツール、指示、権限が関わったのか？

AIコーディングエージェントは、単にコードの断片を提案したり、行を補完したりする存在ではなくなっています。MCPサーバー、スキル、インテグレーションなど、ソフトウェア開発環境のさまざまな要素とつながるようになっています。コンテキストを取得し、外部サービスを呼び出し、操作を実行し、既存のセキュリティプロセスでは把握も管理もできない方法でコードを生成することがあります。

つまり、開発者環境は、チームが把握し管理すべきソフトウェアサプライチェーンの一部になりつつあります。そして、新たなSnykの調査によると、こうした変化はすでに実際の開発者環境に表れています。

Snykは、約10,000件の開発者環境とADSの早期導入環境を分析し、AIコーディングツール、MCPサーバー、エージェントスキルにわたる定量的なリスクを明らかにしました。このデータは、AppSecチームがもはや理論上の問題として扱えない変化を示しています。エージェント型開発が新たなソフトウェアサプライチェーンのレイヤーを生み出している一方で、ほとんどのセキュリティプログラムは、その存在を把握し管理するようには設計されていません。

AIコーディングツールが、相互接続された開発環境へと進化

AIコーディングツールは、今や日々の開発ワークフローの一部です。しかし多くの組織では、導入されるツールは、承認済みの1つのツールや標準化された環境に限られません。開発者は、Claude、Cursor、Windsurf、Gemini、Copilot、Kiro、VS Codeの拡張機能など、複数のAIコーディング環境を同時に利用することがあります。それぞれのツールに独自の設定、インテグレーション、コンテキストソース、権限が存在するため、AppSecチームにとって可視性の確保が課題となります。

AIツールの乱立がセキュリティ上の懸念となるのは、それぞれの環境が外部システムに接続し、指示を取り込み、コードの生成方法に影響を与える可能性があるからです。利用するツールが増えるほど、基本的なガバナンスの問いに答えるのが難しくなります。

• どのAIコーディング環境がインストールされているか？

• 何に接続されているか？

• どのような権限が付与されているか？

• どのような指示が動作に影響しているか？

• 承認済みのセキュリティ対策の範囲内で動作しているか、それとも範囲外か？

従来のAppSecでは、リポジトリ、ビルドパイプライン、デプロイ済みの成果物から調査を始められることが多くありました。エージェント型開発では、コードがコミットされる前の開発者環境で、より早い段階からリスクが発生する可能性があります。

MCPサーバーが新たなサプライチェーンのレイヤーに

MCP（Model Context Protocol）は、AIエージェントが外部のツールやデータソースに接続する手段を提供します。実際には、ソフトウェア開発ライフサイクル全体にわたるコードリポジトリ、ブラウザー自動化、ドキュメント、ローカルファイル、課題管理ツール、デザインツール、その他のサービスなどが含まれます。MCPサーバーは単なる利便性を高めるレイヤーではなく、エージェントがアクセスできるものや実行できることを定める役割を担います。

これらは、開発者のマシンからエージェントが外部のツールやサービスと直接やり取りできるようにする、実際に稼働中の設定です。

従来のソフトウェア開発では、サプライチェーンはパッケージ、依存関係、コンテナ、成果物という観点から捉えられることが一般的です。これらのコンポーネントは、確立されたプロセスを通じてスキャン、インベントリ管理、ガバナンス、監視を行えます。

しかしMCPサーバーは異なる仕組みで動作し、エージェントが何を見て何を実行できるかを決めるアクセスレイヤーの一部となります。ローカルにインストールされたり、一元的なレビューを経ずに設定されたりすることがよくあります。また、コードがリポジトリ、CIパイプライン、標準的なセキュリティゲートに到達する前に、機密システムへのアクセスをエージェントに与える場合もあります。エージェント型開発環境では、すでにリスクの兆候が表れています。

実際には、このリスクはアプリケーションに取り込まれる脆弱なパッケージのような形で現れるとは限りません。エージェントの動作、アクセス可能なシステム、従う指示に影響を与えるMCPサーバーやエージェント設定として現れることがあります。

たとえば、従来のスキャンでは検査されない可能性がある場所に、プロンプトインジェクションのリスクが潜んでいることがあります。Snykは、ツールの説明文に埋め込まれたプロンプトインジェクションを392件、エージェントスキルファイルに含まれる悪意のあるコードパターンを98件確認しました。いずれも、スキャン時点ですでに稼働していた環境で見つかったものです。

ツールの設定によって予期しないアクセス経路が生まれたり、コードリポジトリの外にある指示によってエージェントの動作が左右されたりすることがあります。また、自律性の高いワークフローでは、人が結果を確認する前にエージェントが動作する可能性もあります。つまり、組織はこうしたツールが動作する環境そのものを保護する必要があります。

エージェントスキルが新たなリスクレイヤーを生み出す

企業のデザインパートナー環境を対象とした別の分析では、2つ目のサプライチェーンレイヤーであるエージェントスキルを調査しました。スキルとは、エージェントの動作、デフォルト設定、ペルソナ、ワークフロー、再利用可能な機能を定める指示ファイルです。チームがエージェントの動作を標準化するのに役立つ一方で、共有、変更、サードパーティのエコシステムからの取得、通常のコードレビューを経ない実行が行われる可能性のある「指示」という新たなサプライチェーンレイヤーも生み出します。

スキルは、さまざまな形でリスクをもたらします。

• 外部ソースから指示を取得する

• 管理されていないサードパーティのコンテンツにエージェントをさらす

• シークレットの取り扱いを誤る

• エージェントの動作を操作する隠し指示を含む

スキルは共有されたり、サードパーティのエコシステムから取得されたりすることが多いため、従来の依存関係のようには見えなくても、サプライチェーンの構成要素として機能する可能性があります。

公開されているエージェントスキルのエコシステムに関するSnykの別の調査では、こうしたリスクが実際にどのように現れるかを示しています。ToxicSkillsの調査で、Snykの研究者はClawHubとskills.shにある3,984件のスキルを分析し、13.4%に重大度「Critical」のセキュリティ問題が少なくとも1件、36.82%に何らかのセキュリティ上の欠陥が少なくとも1件含まれていることを明らかにしました。また、人間による検証を通じて、認証情報の窃取、バックドアのインストール、データの外部流出を狙った悪意のあるペイロードも確認されました。

外部の指示がエージェントの動作を左右する可能性があるなら、生成されたコードを保護するだけでは不十分です。エージェントの動作に影響する指示のレイヤーについても、組織が把握する必要があります。

従来のAppSec対策を拡張する必要がある理由

従来のAppSecは、コード、リポジトリ、パイプライン、成果物を中心に設計されてきました。エージェント型開発では、コードが生成される前にその内容を左右するツール、指示、設定の中で、より早い段階からリスクが生じます。

AIコーディングエージェントは、コードがコミットされる前にリスクをもたらす可能性があります。たとえば、MCPサーバーが一元管理されたインベントリに含まれず開発者のマシンにインストールされていたり、スキルがソースコードのようなレビューを受けないまま動作に影響したりすることがあります。また、エージェントが従来のSAST、SCA、CI/CD、リポジトリベースの対策の範囲外で、ツールに接続して操作を実行する可能性もあります。

だからといって、既存のAppSecが時代遅れになるわけではありません。SAST、SCA、IaCスキャン、コンテナセキュリティ、パイプライン対策は引き続き不可欠ですが、それだけでは不十分になる可能性があります。進化するソフトウェア開発に対応するため、セキュリティチームはコード成果物の保護にとどまらず、それらを生み出すシステムまでプログラムを拡張する必要があります。

その対象には、AI支援開発に関わるエージェント、ツール、インテグレーション、指示、設定が含まれます。核心となる課題は可視性です。どのエージェントが使われ、何に接続し、どのような指示を取り込んでいるのかをセキュリティチームが把握できなければ、リスクを効果的に管理できません。

セキュリティチームが今すぐ取り組むべき5つのステップ

エージェント型開発は急速に進んでいますが、AIの導入を禁止したり、開発者の作業を遅らせたりする必要はありません。セキュリティチームは、開発者がすでに利用しているワークフローに可視性とガバナンスを組み込む必要があります。まずは、次の5つのステップから始めましょう。

1. 開発者とエージェントが使っているものを把握する：開発者環境全体で、AIコーディング環境、MCPサーバー、スキル、インテグレーションをインベントリ化します。把握できていないものは管理できません。

2. エージェントの設定をソフトウェアサプライチェーンの一部として扱う：セキュリティレビューの対象をコードや依存関係だけでなく、エージェントが依存するツール、指示、外部コンポーネントにまで広げます。

3. MCPサーバーとスキルにもポリシーを適用する：組織には、リスクに応じて許可、制限、承認必須、ブロックの対象を定める方法が必要です。

4. エージェントの操作に対するガードレールを評価する：エージェントの自律性が高まるにつれ、コードの生成後だけでなく、操作の実行時に近い段階で機能するセキュリティ対策が必要です。

5. エージェント型開発のセキュリティを既存のAppSecプログラムに組み込む：独立したガバナンスの枠組みにするのではなく、ソフトウェアの現在の構築方法に合わせてAppSecを拡張します。

これらは、SnykのAgentic Development Securityのアプローチが重視する機能です。エージェントのワークフローに入る前にMCPサーバーやスキルを検出・管理することから、エージェントの実行ループ内でガードレールを適用すること、AI生成コードを生成時に検証することまでを網羅します。

ソフトウェアの構築を支えるシステムを保護する

AI生成コードのセキュリティ対策は不可欠ですが、それだけではもはや十分ではありません。エージェントがソフトウェア開発に深く組み込まれるにつれ、セキュリティチームはエージェントが生成するコードだけでなく、その出力を左右するツール、指示、インテグレーション、権限も把握する必要があります。ソフトウェアサプライチェーンには、そもそもソフトウェアの構築を支えるエージェント型システムも含まれます。

完全版レポートでは、最も広くインストールされているMCPサーバーとそのリスクプロファイル、企業環境におけるスキルの問題の種類別内訳、プロンプトインジェクションと悪意のあるコードパターンの全データ、セキュリティチーム向けの推奨アクションを詳しく解説しています。今すぐダウンロードして詳細をご覧ください。