新たなAIリスク領域：目に見えず、自律的で、すでに内部に存在

James WhiteAIセキュリティ担当CTO | F5

2025年も折り返しを迎えた今、企業におけるAI導入の進展とAIセキュリティの現状を概観するには、ちょうどよいタイミングです。

企業における生成AIの利用が標準に

企業では総じて、少なくともGenAIの基礎が理解されています。GenAIとは何か、どのような用途に活用できるかも把握されています。現在、GenAIを利用できない職種では、時代の流れに後れを取ることになります。

GenAIを基盤としたアプリケーション開発は、企業で急速に標準化しつつあります。実際に、お客さまが社内向けと社外向けの両方でAIアプリを本番環境にデプロイしている状況を、F5は目の当たりにしています。

エージェントの導入には、サードパーティを通じた導入と、独自エージェントの構築という2つの流れがあります。サードパーティを通じたエージェントの導入はかなり進んでいますが、企業が導入済みであることを必ずしも認識しているとは限りません。ブラウザ上のGenAIモデルインターフェースから利用を始めた組織は、エージェント型AIも使用していることに気付いていない可能性があります。

たとえば、Google Geminiの提供開始当初は、エージェント型AIの要素は組み込まれていませんでしたが、現在ではDeep ResearchがGemini内のエージェントとして機能しています。Deep Researchはプロンプトを受け取ると、実行すべきタスクや必要なWeb検索を判断し、情報を収集してレポートを作成します。同様に、Microsoft 365 Copilotにもエージェントが組み込まれています。

独自エージェントの構築は、主にプロトタイプ作成と実験の段階にありますが、エージェントの進展はGenAIよりもはるかに速いペースです。2024年には、「これは本当に実現するのか」「リスクに本当に違いがあるのか」が問われていました。今では、こうした疑問は解消され、企業は確信を持っています。

だからこそ、エージェントと「エージェント型AIへの抵抗」を理解することが非常に重要です。

MCPはセキュリティを意味するものではない

多くの企業が、Model Context Protocol（MCP）を、エージェント型AIを導入する唯一の方法であるかのように捉え始めています。組織では「エージェント」という言葉がMCPに置き換わりつつあり、「MCPを構築する」と語られるほどです。

厳密には正確ではありません。MCPは実質的に、エージェントが処理を実行する際に利用できる選択肢のメニューを表します。MCPサーバーが「利用できるのはこれです」と提示し、MCPクライアントが「この方法でこれを使う」と決めるイメージです。その後、AIモデルを使用して、何をどのように実行するかを判断します。

この構造でも、リスクは依然としてモデルに起因します。また、サーバーソフトウェア内にも別のリスクが存在します。こうしたリスクは、MCPによって自動的に解消されるわけではありません。このプロトコルは非常に優れていますが、最近のセキュリティインシデントで明らかになったように、デフォルトでセキュアとは決して言えません。たとえば、Asanaは最近、Asana MCPユーザーのデータが別のアカウントのユーザーに公開される可能性があったバグを特定し、公表しました。

MCPによってリスクが最小限に抑えられると考えることで、企業はかえってリスクへのエクスポージャーを高める可能性があります。現在、多くのお客さまや見込み客から「MCPをどのように保護しているのか教えてほしい」という声が寄せられています。ユースケース、モデル、導入パターンに加え、MCPやその他の標準を介したツールとの連携を考慮し、ストレステストを行うという包括的な視点が必要です。

エージェント型AIでは「どのように」が重要

これは、何を達成するかにはさまざまな方法があるものの、その多くが不適切または誤っているためです。たとえば、データベースを最新の状態に保つタスクを割り当てられたエージェントが、データを削除または挿入するためのアクセス権限を持っているとします。このエージェントは、会社名と完全に一致するデータを正確に特定して削除することで、F5に関連するエントリを削除できます。

しかし、エージェントが「F*のレコードを削除する」という命令を出し、Fで始まるすべての企業のレコードを削除してしまう可能性もあります。このような粗雑な処理でも同じ目的は達成できますが、容易には修復できない可能性のある意図しない結果が連鎖的に生じます。非決定論的モデルによってアクションが実行されるエージェント時代では、意図しない動作そのものが侵害です。特に、セーフガードが不十分な場合はなおさらです。エージェントを適切に導入するには、エージェントの動作を理解することが極めて重要です。

エンタープライズセキュリティスタックが抱える課題

AIのセキュリティ確保には、既存のセキュリティソリューションを多少変更するだけではなく、まったく新しい運用方法が必要です。企業が利用している従来型ソフトウェアは、時間の経過とともに別の形態へと変化していきます。それらをどのように保護すべきかは、現時点ではまだ完全には明らかになっていません。

従来型のセキュリティスタックを使用している組織では、すでに限界が見え始めています。これは、そうしたセキュリティスタックがAI以前の時代を前提に設計、構築されているためです。AI時代には、無価値なものから高品質でミッションクリティカルなデータまで、新たに生成される情報量が爆発的に増加しています。

過去数十年にわたり、人間が生成するトラフィックを監視してきたシステムは、今やAIを利用する人間が生成するトラフィックへの対応を迫られています。それだけでもトラフィック量は桁違いに増加します。さらに、AIエージェントが情報を生成するトラフィックになればどうなるでしょうか。増加は指数関数的になります。

従来のセキュリティスタックは、こうした現実を想定して構築されていません。対応していくには、早急かつ抜本的な変革が必要です。

未来を垣間見る：アトミックエージェント

現在、エージェントが動作するには、頭脳の役割を果たすAIモデルが必要です。通常、その頭脳はどこかに集約されており、エージェントフレームワークがモデルに問い合わせ、モデルから回答を受け取ります。エージェントとモデルの間でこのやり取りが繰り返されます。

そのシナリオでエージェントが制御不能になった場合、組織は簡単なネットワークルールを適用し、エージェントによるモデルへのアクセスを遮断できます。最悪の場合は、モデルを停止することも可能です。

将来的には、モデルが小型化し、GPUが不要になり、サーバールームやクラウドに配置する必要もなくなります。「頭脳」がエージェントと同じ場所で動作するため、エージェントは場所を問わず効率的に稼働し、柔軟にスケールアップ／ダウンできるようになります。そうなれば、セキュリティリスクは急増します。

ここで重要な概念となるのがアトミックエージェントであり、その登場を示す兆候もあります。Microsoftの「BitNet b1.58 2B4T」は、CPUで動作する1ビットモデルであり、今後の可能性を示しています。現時点では、まだ十分に小さくも、速くもなく、おそらく性能も十分ではありません。しかし、AI時代には「まだ」が瞬く間に現実へと変わります。

著者について

James WhiteAIセキュリティ担当CTO | F5

James Whiteは、エンタープライズソフトウェア業界で約20年の経験を持つ、優れたエンジニアでありビジネスリーダーです。

James Whiteのその他のブログ記事