エージェント型開発ライフサイクルにおける新たなセキュリティリスク
2026年6月3日
0 分で読めます重要なポイント
エージェント型開発ライフサイクルとは、AIエージェントがツール、コードベース、環境と連携しながら、ソフトウェアの計画、構築、変更、テスト、リリースを行うプロセスです。
コードがリポジトリに到達する前からリスクが入り込むため、セキュリティの中心的な問いは「このコードは安全か?」から「これを作ったシステムを信頼できるか?」へと変わります。
エージェントがリスクをもたらすのは、利用するもの、実行すること、生成するものの3つです。
従来のAppSecが成果物を保護するのに対し、エージェント型開発では成果物を生み出すプロセスの保護が必要です。
エージェントのワークフローに継続的な制御を組み込むことで、開発者とエージェントは信頼できる境界の中で迅速に作業できます。
長年、アプリケーションセキュリティはシンプルな前提に基づいていました。ソフトウェアはライフサイクルに沿って進み、開発から本番環境へ移る過程で成果物を検査する、というものです。開発者が計画し、コードを書き、コミットし、テスト、スキャンを経てリリースする。プルリクエストのレビュー、CI/CDのゲート、コミット後のスキャンなど、あらゆる制御は各段階の間に人がいて判断を下し、その判断を後からツールで確認できることを前提に設計されていました。
AIエージェントはこの前提を覆しています。ソフトウェアはもはや、人が書いて後から確認するだけのものではありません。従来の制御が結果を検知する前に、自律システムがソフトウェアを組み立て、変更し、実行するケースが増えています。「開発者」が必ずしも人とは限らず、システム自体が構築を担うこともあります。
この変化を理解するうえで知っておきたい言葉があります。それが「エージェント型開発ライフサイクル」です。ソフトウェアにリスクが入り込む場所が変わり、保護すべき対象も変化します。
エージェント型開発ライフサイクルとは?
エージェント型開発ライフサイクルとは、AIエージェントがツール、コードベース、データソース、開発環境と連携しながら、ソフトウェアの計画、構築、変更、テスト、リリースを行うプロセスです。
従来のSDLCは人が主導し、成果物を中心に、各段階のチェックポイントを通過しながら進みます。セキュリティは各段階の成果物を検査します。一方、エージェント型開発ライフサイクルは、エージェントが主導する動的かつ継続的なプロセスで、行動を中心に進みます。エージェントは目標を解釈し、ツールを選び、ファイルを変更し、スクリプトを実行し、APIを呼び出し、依存関係を追加し、本番環境に対応したコードを生成できます。多くの場合、これらを一連の中断のない処理として実行します。
これはSDLCに取って代わるものではなく、その上に重なり、開発を加速させるものです。エージェントは引き続きコード、依存関係、設定、API、インフラの変更を生み出します。ただし、IDEで開発者がコードを入力する場合に比べ、可視化やガバナンスがはるかに難しいワークフローを通じて実行します。
エージェント型開発でリスクモデルが変わる理由
従来のAppSecでは、リスクはソースコード、オープンソースの依存関係、コンテナ、Infrastructure as Code、APIなどの成果物に存在すると考えます。それは今も変わりませんが、エージェント型開発では攻撃対象領域に、成果物を生み出すシステムも加わります。セキュリティの問いは「このコードは安全か?」から「これを作ったシステムを信頼できるか?」へと変わります。これは別の問いであり、答えられる体制が整っているセキュリティプログラムは、まだ多くありません。
エージェント型開発ライフサイクルにおける3つの制御ポイント
新しいライフサイクルを理解するには、エージェントがリスクをもたらす3つの場面、つまり利用する入力、実行するアクション、生成する出力に注目するとよいでしょう。リスクが継続的に入り込むなら、3つの場面で対策を講じる必要があります。エージェントが利用するもの、実行すること、生成するものです。
1. エージェントが利用するもの
エージェントは何もないところから開発を始めるわけではありません。作業を進めるため、MCPサーバー、スキル、API、外部ツール、データソース、開発インテグレーションを取り込みます。従来の依存関係として宣言されていなくても、こうした入力がソフトウェアサプライチェーンの一部になることがあります。また、多くの場合、レビューなしに実行時に選択、呼び出しが行われます。
リスクとしては、未承認のMCPサーバー、脆弱または悪意のあるスキル、出所が不明確な外部ツール、誰も追跡していないAIツールなどがあります。これは仮説ではありません。Snykの調査では、分析した3,984件のうち76件で悪意のあるスキルが確認されました。また、公開されているMCPサーバーの約3分の1に、悪用可能な欠陥が見つかっています。
エージェントが何を利用しているか把握できなければ、開発ワークフローにどのようなリスクが入り込んでいるのかも把握できません。
2. エージェントが実行すること
エージェントは変更案を提示して返答を待つだけではありません。スクリプトを実行し、内部システムに問い合わせ、ファイルを変更し、マシンの速度でAPIを呼び出します。
これにより、安全でないコマンドの実行、システムやデータへの不正アクセス、ツール呼び出しによるデータ漏えい、開発ワークフロー内でのプロンプトインジェクション、予測不能な一連のアクションといったリスクが生じます。実際に起きた事例では、コーディングエージェントが繰り返し指示された「停止」を無視し、本番データベースを削除したうえ、エラーを隠すためにレコードを捏造しました。エージェントは、たまたま与えられていた権限を使い、小さな障害を解決しようと推論を重ねたのです。
アクションは人が確認して介入するより速く実行される可能性があるため、エージェントの振る舞いはリアルタイムで管理する必要があります。
3. エージェントが生成するもの
エージェントは、ソフトウェアの一部となるコードや依存関係を生成します。出力が正常に動作するように見えても、AI生成コードには脆弱性、安全でないパターン、設定ミスが含まれていることがあります。
従来のAppSecでは、コードは書かれた後にレビューできると考えます。しかしエージェント型開発では、出力はマシンの速度で生成され、セキュリティチームが変更内容や理由を把握する前に、提案からコミットまで進むことがあります。リスクは、AI生成コードが安全でない可能性だけではありません。安全でない出力がより早い段階で入り込み、急速に複製され、従来のチェックポイントが追いつく前にリリースされることです。
コミット後のスキャンだけでは、もはや不十分です。エージェントが生成するものを作成時に検証する必要があります。
従来のAppSecのチェックポイントだけでは不十分な理由
だからといって、従来のAppSecが重要でなくなるわけではありません。コード、依存関係、コンテナ、インフラのスキャンは引き続き必要です。AIはソフトウェアサプライチェーンに取って代わるのではなく、その進行を加速させるため、この基盤はこれまで以上に重要です。
しかし従来のチェックポイントは、開発に関する意思決定の大半を人が行い、検査対象となる主な成果物がコードであり、コミット、ビルド、デプロイの段階でリスクを検出できることが多い世界を前提に設計されていました。セキュリティは、下流での検査だけに頼ることはできません。エージェント型ワークフロー自体に組み込む必要があります。従来のAppSecは成果物を保護します。Agentic Development Securityは、成果物を生み出すプロセスを保護します。
エージェント型開発ライフサイクルの保護に必要なこと
このライフサイクルを保護するために、開発者に新たなレビュー工程を課して速度を落としたり、AIツールを禁止したりする必要はありません。チームが安全に導入できるよう、エージェントに信頼できる境界を設けることが重要です。そのためには、エージェントが動作するワークフロー内で機能する制御が必要です。
セキュリティチームは、利用中のエージェント、ツール、スキル、MCPサーバーを特定し、入力が信頼できるかを評価し、エージェントがアクセスおよび実行できる内容を管理し、エージェントのワークフロー中にポリシーを適用し、生成されたコードや依存関係をリアルタイムで検証し、エージェント主導の開発活動全体の監査証跡を維持する必要があります。
共通するのは、継続的な監視です。セキュリティチームがエージェントの近くでリスクを評価し、成果物のコミット、アクションの実行、脆弱性のデプロイに至る前に対処できる体制が必要です。
ライフサイクルが変わったなら、セキュリティも変わらなければなりません。
エージェント型開発ライフサイクルは、単に高速化されたSDLCではありません。自律システムがツールを取り込み、アクションを実行し、継続的に出力を生成する、新しいソフトウェア開発のあり方です。この変化によって、チェックポイント型の制御だけでは答えられないセキュリティ上の問いが生まれています。
AI主導の開発を安全に拡大するには、エージェントが利用するもの、実行すること、生成するものまで、ライフサイクル全体を可視化し、制御する必要があります。AIの導入を遅らせることが目的ではありません。セキュリティがバックグラウンドで継続的に機能するなか、開発者とエージェントが信頼できる境界の中で迅速に作業できるようにすることが目的です。
AIエージェントが従来の制御を超えてどのように動作するのか、さらに詳しく知りたいですか?今すぐチートシートをダウンロード。
エージェント型開発ライフサイクルに関するよくある質問
エージェント型開発ライフサイクルとは何ですか?
エージェント型開発ライフサイクルとは、AIエージェントがツール、コードベース、データソース、API、開発環境と連携しながら、ソフトウェアを計画、構築、変更、テスト、リリースするプロセスです。従来のソフトウェア開発ライフサイクルと異なり、エージェントは人間の介入をほとんど受けずにツールを選択し、ファイルを変更し、スクリプトを実行し、APIを呼び出し、コードを生成できるため、より動的で実行重視のプロセスです。
エージェント型開発によって、アプリケーションセキュリティはどのように変わりますか?
エージェント型開発では、コードそのものだけでなくリスクの対象が広がり、アプリケーションセキュリティも変化します。従来のAppSecは、ソースコード、依存関係、コンテナ、Infrastructure as Codeなどの成果物の保護に重点を置いています。エージェント型開発ではさらに、エージェントが使用する入力、実行するアクション、生成する出力など、こうした成果物を作成するプロセスも保護する必要があります。
AIコーディングエージェントにおける主なセキュリティリスクとは?
AIコーディングエージェントにおける主なセキュリティリスクには、信頼できないツール、脆弱なMCPサーバー、安全でないコマンド実行、システムやデータへの不正アクセス、プロンプトインジェクション、安全でないコードの生成、未承認の依存関係などがあります。こうしたリスクは、コードがリポジトリや従来のセキュリティチェックポイントに到達する前に、開発ワークフローへ入り込む可能性があります。
従来のAppSecのチェックポイントでは、エージェント型開発に不十分なのはなぜですか?
従来のAppSecのチェックポイントでは不十分です。人間主導の開発ワークフローを前提に設計されており、コードの作成後やコミット後にセキュリティを確認する仕組みだからです。AIエージェントは機械の速度で動作し、下流のスキャンやレビューが行われる前に、変更を加えたり、ツールを呼び出したり、コードを生成したりします。セキュリティ制御は成果物の作成後だけでなく、エージェントのワークフロー内で機能する必要があります。
エージェント型開発のライフサイクルをチームでどのように保護できますか?
チームは、使用中のエージェント、ツール、スキル、MCPサーバーを把握し、それらの入力が信頼できるかを検証し、エージェントがアクセス・実行できる範囲を管理し、エージェントのワークフロー中にポリシーを適用し、生成されたコードと依存関係をリアルタイムでスキャンし、エージェントによるアクティビティの監査証跡を維持することで、エージェント型開発のライフサイクルを保護できます。
Agentic Development Securityとは何ですか?
Agentic Development Securityとは、AI支援型およびAIエージェント主導のソフトウェア開発に関わるシステム、ワークフロー、成果物を保護する取り組みです。従来のAppSecがソフトウェア成果物を保護するのに対し、Agentic Development Securityは成果物を生み出すプロセスを保護します。これにより、開発者とエージェントは、管理されていないリスクを招くことなく、信頼できる境界のもとで迅速に開発を進められます。
AIエージェントのセキュリティを確保すると、AIの導入が遅れてしまいますか?
いいえ。AIエージェントのセキュリティを確保することは、AIツールを禁止したり、不必要な制約を加えたりすることではありません。開発者とエージェントに信頼できる境界、継続的な可視性、リアルタイムの制御を提供することで、ソフトウェアの提供スピードを維持しながら、チームがエージェント型開発を安全に進められるようにすることが目的です。
チートシート
AIエージェントが従来のセキュリティ制御を超えて動作する6つの方法
AIエージェントは従来のソフトウェアと同じルールには従いません。ADLC全体にわたり、エージェントが従来のセキュリティ制御を超えて動作する6つの具体的な方法を解説します。
