会話はファイアウォールでは守れない：AIレッドチーミングがミッションクリティカルになった理由

業界動向 | 2026年4月16日

Jessica BrennanAIセキュリティ担当シニアプロダクトマーケティングマネージャー | F5

Allan Healyシニアソリューションエンジニア | F5

2020年以降、AIの利用はかつてない勢いで急増しています。導入のペースはクラウドやモバイルを上回り、インターネットの普及時よりも明らかに速くなっています。Gartnerは、今年、80%を超える企業がAIを導入すると予測しています。

企業におけるAI導入の道のりを分類すると、その成熟度は4つのカテゴリーに分けられます。これらは順番に進むのではなく、並行して進むことがよくあります。

カテゴリー1は、汎用AIと生産性に関するものです。たとえば、従業員によるChatGPT、Gemini、Copilotなどの利用が該当します。
カテゴリー2は、組織内にユースケースがあり、人事やITなどの業務向けにカスタムチャットボットを構築するケースです。
カテゴリー3には、一般公開される生成AIアプリケーションの構築など、カスタマーサービス用チャットボットを含む外部向けのユースケースが該当します。
カテゴリー4は、エージェント型ワークフローです。これは、ユーザーに代わって自律的にアクションを実行する複雑なシステムで構成されます。

セキュリティが極めて重要になるのは、これら最後の3つのカテゴリーです。これは、組織が非決定論的なAIモデルを基盤として複雑なソフトウェアを構築しており、従来のファイアウォールでは検知できない脆弱性が生じるためです。

“AIを導入する企業がベースラインを確立するだけでも、既知の脆弱性に対する迅速な自動テストが必要であることは明らかです。”

セキュリティは企業にとって常に優先事項ですが、AIには従来とは異なる懸念があります。それは、セキュリティ上の盲点です。セキュリティ責任者は20年にわたり、Webアプリケーション、Webサイト、さらにはAPIを保護するために、Webアプリケーションファイアウォール（WAF）の導入と設定に取り組んできました。しかし、WAFは非常に有用である一方、AIへの対応には限界があります。AIで使用される自然言語処理は、従来のWAFでは検知が難しい場合があります。簡単に言えば、会話をファイアウォールで保護することはできません。企業には、場所を問わずアプリとAPIを保護し、あらゆる環境でAIのセキュリティを確保するための新たなアプローチが必要です。

そのため、CISOの75%がAIセキュリティインシデントを報告しています。既存の防御策は、こうした脅威を検知するようには設計されていないためです。また、91%がAIインフラストラクチャに対する攻撃の試みをすでに検知しており、実に94%がAIシステムのテストを優先するようになっているのも、同じ理由によるものです。

新たなカテゴリーの認知攻撃

AI時代において、組織が対処すべき課題はコードの脆弱性だけではありません。次のような、まったく新しい種類の認知攻撃にも直面しています。

プロンプトインジェクション（直接および間接）
データポイズニング（トレーニングフェーズ中）
高度なジェイルブレイク手法（記号言語攻撃など）
トークン圧縮：攻撃者が、AIモデルには読み取れても人間には読み取れない形式で悪意のある命令を隠す手法

従来のセキュリティガードレールは決定論的な入力には対応できますが、プロンプトインジェクションなどの自然言語攻撃は、パターンマッチングではなく意味解釈に関わる問題です。これらは個別のバグではなく、AI駆動型アーキテクチャによってもたらされる構造的なビジネスリスクです。

AIが脅威モデルをどのように変えているかを示す実例は数多くあります。昨夏、ある国際的なソフトウェアプロバイダーで発生した侵害は、組織をまたぐデータ漏えいを許したMCPサーバーのテナント分離ロジックの不備に起因していました。これは典型的なマルチテナントのバグですが、LLMシステムでは、漏えいしたデータが流暢な言語として現れ、検出がはるかに困難になるため、より危険です。

一方、あるグローバルテクノロジー企業で発生したインシデントでは、信頼境界の破綻という別の問題が明らかになりました。プロンプトインジェクションによってチャットボットの役割が再定義され、バックエンドシステムはサーバー側で認可を適用せずに、そのツールリクエストを信頼していました。問題はモデルがルールを無視したことではなく、モデルに認可を不適切に委ねていたことです。

これらは、はるかに広範な新興リスクの全体像を示す、わずか2つの例にすぎません。業界では、こうしたAIの脆弱性を分類する取り組みが急速に進んでいます。現在、OWASP Top 10 for Large Language Model (LLM) Applications、OWASP Top 10 for Agentic Applications 、Mitre Atlas、NIST AI Risk Management Frameworkなどのフレームワークが登場していますが、セキュアな状態を明確に定義する決定版のデータベースや統一規格は、まだ存在しません。

従来のアプローチでは追いつけない

今、業界は存続を左右するほどのAI導入圧力にさらされています。開発者はAIを活用し、従来の10倍の速さでコードを記述しています。企業は文字どおり、一夜にして新機能、さらには新製品までリリースしています。

同時に、規制によって対応が加速しています。コンプライアンスの面では、たとえばEU AI Actが、高リスクAIシステムおよび汎用AIシステムに対する敵対的テストを明示的に求めています。実際には、専用のレッドチーミング、つまり敵対的攻撃をシミュレーションしてAIシステムをテストすることを、AIセキュリティスタックの中核要素として位置付け、これらのシステムが直面する現実の課題に対応できる形で実施する必要があるということです。

CISOやセキュリティチームが、マシンスピードで進む変化に対応してセキュリティを確保しようとするのは、バケツで津波を食い止めるようなものです。規模の面でも、速度の面でも対応できません。AIの攻撃対象領域は根本的に異なり、従来のアプローチでは追いつけません。

従来のレッドチーミングでは効果が不十分であり、スピードと制御のせめぎ合いを解消するには、AIレッドチーミングが必要であることは明らかです。お客さまとの対話やAIシステムのセキュリティ確保を支援してきた経験から、検討すべき重要な領域は4つあります。

第1に、脅威の進化です。AI攻撃は、静的なテストスイートよりも速く進化します。チェックを自動化しても、すぐにAIモデルや攻撃が変化するため、セキュリティチームはリスクの低減ではなく、テストの保守に追われることになります。

次に、エージェントの複雑性です。AIエージェントは決定論的なシステムではないため、検索、ツール、メモリを追加すると、組み合わせはほぼ無限になります。もはやコードをテストするのではなく、コンテキストに応じて変化する会話をテストすることになります。

3つ目は、自動化とスケーラビリティです。こうしたシステムでは、手動のレッドチーミングは規模の拡大に対応できません。チャットボットが1つなら管理できるかもしれませんが、数百、数千となれば困難です。モデルやシステムプロンプトが更新されるたびに、何千もの敵対的な会話を人手で再現する方法には頼れません。

最後に、実行可能なレポートです。調査結果は再現可能で、具体的な対応につながるものでなければなりません。「ボットが不適切に動作した」だけでは、対応に結び付きません。エンジニアには会話のパラメーターとトリガー条件が必要です。これらがなければ、修正と是正は進みません。

攻撃を受けてもAIが意図どおりに動作するようにする

いくつかの事例を通じて、これを実際の状況に照らして検証してみましょう。F5のお客さまの1社に、規制の厳しい環境で事業を展開するグローバル銀行があります。F5が初めてこの銀行を支援した時点で、人事、調達、サイバーセキュリティの分野に50件を超えるAIユースケースがありました。しかし、社内監査担当者に安全性を証明できなかったため、いずれも本番環境に導入できませんでした。

AI red-teaming with F5 AI Red Teamを使用したAIレッドチーミングにより、同行は、AIシステムが実際にどのように動作するか、つまりデータ漏えいの可能性、プロンプトが悪用される方法、環境内で制御が機能しなくなる箇所を把握するために必要な根拠を得ることができました。

このお客さまは、AI Red Teamの調査結果を活用し、カスタムセキュリティ制御をF5 AI Guardrailsで実装することで、防御態勢の強化に取り組んでいます。この組み合わせにより、銀行はセキュリティ態勢とガバナンスプログラムへの確信を持って、AIの活用を事業全体に拡大できます。

公共部門では、テストは任意ではなく必須となりつつあります。NISTやCISAなどの機関の指針に基づき、公共機関は、生物学的データの兵器化といったミッションクリティカルなリスクを特定するため、敵対的ストレステストなどの対策を講じています。ここでAIレッドチーミングに求められるのは、単なるリスク低減ではなく、ミッションの継続性と運用権限の維持です。

顧客データと公共サービスのどちらを保護する場合でも、求められることは同じです。誰かがAIシステムを破壊しようとしている状況でも、意図したとおりに動作することを、継続的かつ証拠に基づいて保証する必要があります。