AIセキュリティの予算を確保したら、次は何をすべきか？

重要なポイント

• AIセキュリティの予算は、分断されたツールへの支出から、AIのライフサイクル全体にわたる可視化、ガバナンス、制御への統合的な投資へと進化させる必要があります。

• 組織は、相互につながる2つの領域に予算を割り当てるべきです。AIエージェントがコードを生成し、ツールを使い、ワークフローを実行するエージェント型開発のセキュリティと、エージェントがユーザー、データ、API、本番システムとやり取りするエージェント型アプリケーションのセキュリティです。

• 効果的なAIセキュリティ予算には、AIの検出、エージェントとモデルのリスク評価、ポリシーの強制適用、敵対的テスト、ランタイム保護、ガバナンスの証跡に対する専用の予算が必要です。

• ガバナンスとコンプライアンスは、ツール費用に埋もれさせたり、後工程としてGRCに任せたりせず、独立した予算項目として扱うべきです。AIシステムを責任ある形で管理していることを証明するには、継続的な検出、強制適用できるポリシー、リスクレポート、監査証跡が必要です。

• 連携されていないAIセキュリティのポイントツールを購入しても、統合的な制御が実現しないままコストと複雑さが増す可能性があります。プラットフォームアプローチなら、開発から本番まで、AIの可視性、リスクインテリジェンス、ポリシーの強制適用、証跡をセキュリティチームが連携できます。

多くの組織は、AIセキュリティの予算を誤った領域に費やしています。モデルの一覧を作り、APIをマッピングし、ダッシュボードを公開するために、まずは可視化だけを導入しようと考えがちです。

しかし、可視化だけでは、侵害されたMCPサーバーを取り込んだコーディングエージェントを止められません。顧客情報を送ってはならない場所へ転送しようとしている本番エージェントも止められません。個々には「許可」されている5つのアクションを自律型ワークフローが連鎖させ、危険な結果を招くことも防げません。

強制適用を伴わない可視化は、ガバナンスではありません。AIエージェントを導入する組織は今、相互につながるものの、それぞれ異なる2つの領域を保護する必要があります。

1. ソフトウェアを開発するエージェント

2. 本番環境のアプリケーション内で稼働するエージェント

セキュリティリーダーが今解決すべき予算の課題は、事後にAIリスクを検出できるかどうかではありません。エージェントがどのように構築され、本番環境でどのように振る舞うかまで、そのライフサイクル全体を管理できるかどうかです。そのためには、ソフトウェアの構築段階でAI生成コードとエージェントのサプライチェーンを保護する「シフトレフト」と、本番環境で稼働するエージェントとアプリケーションの可視化およびガバナンスの両方が必要です。

領域1：ソフトウェアを開発するエージェントの保護

エージェント型開発では、AIエージェントが依存関係を取り込み、MCPサーバーを呼び出し、スクリプトを実行し、環境をまたいでアクションを連鎖させ、ほとんど人のレビューを受けずに本番環境向けのコードを生成するようになっています。その結果、従来のAppSecでは制御するよう設計されていなかった3つのリスク領域が生まれます。エージェントが何を使うか、何をするか、何を生成するかです。

1. エージェントが使うもの：MCPサーバー、スキル、外部ツール

AIコーディングエージェントは、何もない状態から作業するわけではありません。タスクを完了するため、MCPサーバー、外部API、再利用可能なスキル、オープンソースコンポーネント、プラグイン、サードパーティ製ツールを継続的に取り込みます。そのいずれにも、脆弱性、悪意のある挙動、設定ミスが潜んでいる可能性があります。

これらのコンポーネントは事前承認されることなく、実行時に選択、呼び出されます。そのため、信頼されていない外部ツールが瞬時にワークフローへ入り込む可能性があります。最終成果物だけをスキャンするセキュリティツールでは、エージェントが信頼できない入力を選択して使った瞬間、つまりワークフローにリスクが入り込んだ時点を見逃します。

Snykの調査では、共有エコシステムにおける悪意のあるエージェント機能や脆弱なMCPサーバー、広く使われているエージェントインフラの重大な欠陥がすでに特定されています。たとえばCVE-2025-6514では、mcp-remoteを介した完全なリモートコード実行が可能になっていました。

2. エージェントが行うこと：ツールの実行、スクリプト、システムアクセス

エージェントは提案するだけではなく、人の介在なしに、機械の速度でアクションを実行します。目標を与えられると、コマンドの実行、ファイルの変更、インフラとのやり取り、システムへの問い合わせ、APIの呼び出し、環境をまたいだワークフローの連鎖が可能です。多くの場合、広範な権限が付与され、監督は限られ、人による承認プロセスもありません。

Replitでのインシデントは、この問題が現実に起きることを示しました。AIエージェントが明示的な「凍結」指示を無視し、本番データベースを削除したうえ、自らの行為を隠すために何千件もの偽のレコードを捏造したのです。

このようなインシデントは、スキャナーが脆弱な関数を見逃したために起きるのではありません。エージェントの動的で複数ステップにわたる振る舞いが、アクションの実行時に管理されていなかったために起きます。エージェント型開発では、危険なアクションが完了する前に、コンテキスト、権限、リスクを評価できるよう、実行ループ内に十分近い場所で制御する必要があります。

3. エージェントが生成するもの：コードと依存関係

エージェントは、人のレビューで検証できる速度を超えて、コードや依存関係を生成します。その出力には、脆弱性、安全でない依存関係、ハードコードされたシークレット、設定ミスが含まれる可能性があります。

エージェント型開発の課題は、AIが機械の速度でコードを継続的に生成し、組織が頼りにするレビュー工程を経ないことも多い点です。コミット後のスキャンが実行される頃には、脆弱な出力がすでにリポジトリに入っているかもしれません。ワークフローによっては、すでにパッケージ化、デプロイされていたり、別のエージェントに再利用されていたりする可能性もあります。

生成物を保護するには、コードがリポジトリに入る前、またはより大きなエージェント駆動型ワークフローの一部になる前に、生成された瞬間に検証する必要があります。エージェント型開発では、生成されたコードをその時点で保護しなければ、リスクが入り込んだ後から追いかけることになります。

領域2：本番環境のアプリケーション内で稼働するエージェントの保護

2つ目の領域は本番環境です。多くの組織ではすでに、顧客からの問い合わせに対応するサポートエージェント、社内システムにアクセスするワークフローエージェント、APIを呼び出す自律型パイプライン、人の介在なしにデータを取得し、判断し、アクションを起こすAIネイティブアプリなど、アプリケーション内でエージェントが稼働しています。

問題は、エージェントが何をしているか把握し、誤った行動を取ったときに止められるかどうかです。エージェントが稼働すると、ガバナンスは検出、リスク評価、コンプライアンスという3つの側面で機能しなくなります。

1. 検出：見えないエージェントは管理できない

セキュリティチームには、AIエージェントがどこで稼働しているか、どのモデルを使い、どのツールを呼び出し、どのデータにアクセスし、どのワークフローを実行しているかをリアルタイムに把握する必要があります。

多くの組織は、その全体像を把握できていません。従業員やチームが独自の生成AIツールを構築し、ワークフローにエージェントを組み込み、正式なセキュリティレビューを受けずにAIシステムを社内データへ接続することで、シャドーAIが問題をさらに深刻化させています。つまり、棚卸しの漏れは、既知のシステムに関する文書が不完全というだけではありません。確立されたチャネルの外で稼働する未知のエージェントが存在するということです。

どのエージェントが存在するか把握できなければ、そのエージェントにポリシーを適用し、リスクを評価し、コンプライアンスを証明し、問題発生時の責任者を特定することはできません。棚卸しはガバナンスの基盤ですが、それだけで十分ではありません。

2. リスク評価：ルールはエージェントが行動する場所で適用する

すでにAIガバナンスポリシーを策定している組織は少なくありません。問題は、その大半が文書やスプレッドシート、エージェントが触れることのないレビューワークフローに置かれていることです。この「書類上のガバナンス」は、危険な誤った安心感を生みます。

たとえば、「エージェントは顧客データを外部サービスに公開してはならない」というポリシーは、エージェントが実行しようとしたときに適用されて初めて意味を持ちます。そうでなければ、組織には書類上のガバナンスしかなく、本番環境では振る舞いが制御されないままです。

エージェント型アプリケーションには、実行レイヤーでのポリシー強制適用が必要です。そこでは、エージェントが何をしようとしているか、どのデータに触れているか、どのツールを呼び出しているか、アクションが定義された境界を越えるかどうかをルールで評価します。たとえば、操作されたエージェントが顧客データを外部エンドポイントに送ろうとした場合、完了する前にそのアクションをブロックまたは変更できます。

3. コンプライアンス：何が起きたのか、なぜ起きたのか、どの権限で行われたのかを証明する

エージェントがビジネス上の問題を引き起こしたとき、セキュリティチームに必要なのはログだけではありません。何が起きたかを説明できる、信頼性の高い記録が必要です。エージェントが何をしたか、どのデータにアクセスしたか、どのツールを呼び出したか、どのポリシーが適用されたか、アクションが許可またはブロックされたか、ワークフローの責任者は誰かを記録します。

Air Canadaの事例は、AIチャットボットが顧客に伝えた内容について、組織が責任を問われる可能性を示しました。Chevroletへのプロンプトインジェクション事例は、一般公開されたAIがいかに簡単に操作され、ビジネスに影響する結果を生み出すかを明らかにしました。トキシックフローは、単独のアクションだけでは明らかにならない形で、エージェントがツール、データ、APIを連鎖させる可能性を示しています。

ガバナンスとコンプライアンスは、ツール費用に埋もれさせたり、後工程のGRC業務として扱ったりせず、AIセキュリティの専用予算項目とすべきです。AIエージェントが開発ワークフローや本番アプリケーション全体に広がるなか、組織には、どのAIシステムが存在し、それぞれにどのポリシーが適用され、そのポリシーが強制適用されているかを証明する手段が必要です。この基盤がなければ、監査の不合格、大口商談の停滞、インシデント後の調査、あるいは本来最初から存在すべきだった監査証跡を再構築するための緊急コンサルティングなど、後になってガバナンスのコストが発生します。

連携されていない2つのツールを購入しても解決しない理由

AIリスクは、きれいに1つのレイヤーに収まるものではありません。モデル、エージェントフレームワーク、MCPサーバーは、コードに導入され、パイプラインを通じてデプロイされ、アプリケーションから呼び出され、本番環境でエージェントのアクションに使われることがあります。各段階を異なるツールで管理すると、セキュリティチームは同じシステムの断片的な情報をつなぎ合わせることになります。

AIリスクは、きれいに1つのレイヤーに収まるものではありません。モデル、エージェントフレームワーク、MCPサーバーは、コードに導入され、パイプラインを通じてデプロイされ、アプリケーションから呼び出され、本番環境でエージェントのアクションに使われることがあります。各段階を異なるツールで管理すると、セキュリティチームは同じシステムの断片的な情報をつなぎ合わせることになります。

ツールが分断されれば、制御も分断されます。その結果、次のような問題が生じます。

• 開発環境とランタイムでポリシーが一貫しない

• 互いに食い違う重複したインベントリ

• ビルドからデプロイまでの盲点

• 全体像の一部しか伝えない、別々の監査証跡

• エージェントが関わるインシデント発生時の責任者が不明確

さらに、ポイントツールごとにライセンス、統合作業、データパイプライン、ダッシュボード、ベンダー対応が必要となり、コストも分散します。検出、リスク分析、ポリシー強制適用の機能が重複しているにもかかわらず、チームが作業を重ねる一方で、ツール間には依然として抜け漏れが残ることも少なくありません。複数のツールをつなぎ合わせる頃には、総コストと複雑さが統合プラットフォームの価値を上回り、統合的な制御も実現できない可能性があります。

AIセキュリティにおける統合は、単なる予算の判断ではありません。ガバナンスの要件です。セキュリティチームには、AIがどこに存在するか、どんなリスクをもたらすか、どのように振る舞うか、ライフサイクル全体でどのポリシーが強制適用されるかをつなげて把握する必要があります。この一貫性がなければ、AI導入を安全に拡大するために必要な可視性、説明責任、制御が不足したまま、支出だけが増えることになりかねません。

Snykは、1つのプラットフォームでエージェント型セキュリティの両面を保護

SnykのAI Security Platformは、1つのプラットフォームでエージェントのライフサイクルの両面を保護します。エージェント型開発では、MCPサーバーやスキルから、実行やAI生成コードに至るまで、エージェントが使うもの、行うこと、生成するものの管理を支援します。本番環境のエージェント型アプリケーションでは、Evo AI-SPMを通じて、エージェント、モデル、ツール、データ、ワークフロー全体にわたるAIリスクの記録システムを提供し、ガバナンスの方針を強制適用可能なポリシーへと変えます。

これにより、エージェントセキュリティの制御レイヤーを1つに集約できます。開発から本番まで、検出、ポリシー、リアルタイムの強制適用、監査可能性を共有できます。

これにより、エージェントセキュリティの統合モデルが実現します。

• AIとエージェントのリスクを一元管理する記録システム

• 開発から本番環境まで一貫したポリシーモデル

• エージェントの危険な動作を防ぐ単一の適用レイヤー

• ガバナンスと説明責任を支える一元的な監査証跡

予算を確定する前に答えるべき問い

AIセキュリティ予算があり、経営陣が成果を期待しているなら、問うべきことは明確です。危険なアクションが完了する前に、開発環境と本番環境の両方で、エージェントに対してセキュリティポリシーを適用できますか？

答えが「いいえ」なら、エージェントセキュリティを確保できているとは言えず、次にエージェントが本番データベースを削除する、会社に法的責任を負わせるようなポリシーを幻覚する、機密データを漏えいする、あるいは承認済みツールを連鎖させて危険なワークフローを実行する事態に備えられていません。AI活用で成功するのは、導入を遅らせる組織ではありません。エージェントがソフトウェアを構築する方法と、本番環境で稼働する方法に、継続的な制御を組み込む組織です。

予算は承認され、脅威は現実のものです。次のステップは、危険なアクションがビジネスインシデントになる前に、AIセキュリティプログラムが対応できるようにすることです。継続的かつ確実に適用できるガバナンスの実践ガイドをお探しですか？今すぐ「AIガバナンスの実践と適用に関するエグゼクティブガイド」をダウンロードしてください。