本稿は「AIアプリケーションに内在するセキュリティリスク」というタイトルで、「AI環境を保護するためのセキュリティ対策には何が必要なのか」「AI利用におけるセキュリティ対策として何が必要なのか」について解説していきます。
前編では「AIアプリケーションに内在するセキュリティリスク」というタイトルで、OWASP Top10を例にしてAIアプリケーションのセキュリティリスクをお伝えしました。
後編となる今回は「Security for AIの現状」というタイトルで、AIアプリケーションのセキュリティ対策としてSecurity for AIに必要な具体的コンポーネントについて説明します。
前回と併せてご覧いただくことで、リスクと対策が対になって理解できると思いますので、そちらもぜひご覧ください。
Security for AIに必要なコンポーネント
弊社では、メーカーが提供する上で必要なコンポーネント8個(注)を「Security for AI」と定義して、各セキュリティメーカーのカバレッジを調査しています。
(注)2025年10月現在の数値です。今後Security for AI市場が成熟したり新しい技術が出てきたりした場合には増減する可能性があります。
以下が、Security for AIを構成するコンポーネントです。
1.LLM Firewall
LLMを悪用から守るFirewall機能として、外部からのInput/Outputを監視・制御を行う。LLMに対しプロンプトインジェクションなど不正な指示がないかどうか、LLMへの指示やLLMからの応答に対して機密情報や危険な情報(コード)が含まれていないかどうかを検査します。
2.Model Scan
モデル内で利用する公開リポジトリや外部のソースコード、ライブラリには敵対的または悪意のあるコードが潜んでいる可能性があります。こうしたデジタルサプライチェーンのリスクを排除するために、モデルをスキャンして敵対的または悪意のあるコードを検出することで、安全なデプロイが保証されます。
3.AI Red Teaming
攻撃者視点でAIシステムのリスク対策を評価するサービスや機能です。上述のOWASPやNIST、IPAなどが手法のガイドラインを公開しています。以下にそれぞれのガイドラインのイメージキャプチャとリンク先を示します。
-
、[NIST](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.jpn.pdf)、[IPA](https://www.ipa.go.jp/digital/ai/begoj90000004szb-att/ai_safety_rt_v1.00_ja.pdf)](images/001.jpg)
左から[OWASP](https://genai.owasp.org/2025/01/22/announcing-the-owasp-gen-ai-red-teaming-guide/)、[NIST](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.jpn.pdf)、[IPA](https://www.ipa.go.jp/digital/ai/begoj90000004szb-att/ai_safety_rt_v1.00_ja.pdf)
AI Red Teamingは、セキュリティメーカーが提供しているケースもあれば、コンサルティング企業やSIerがサービスとして提供しているケースもあります。
4.AI SPM(AI Security Posture Management)
AIモデル、データ、インフラストラクチャのセキュリティ状態を継続的に監視、評価、改善することで設定ミスがない状態にしたり、関連するプライバシーおよびセキュリティ規制へのコンプライアンスを確保したりすることができます。
少し歴史的な背景を補足しますが、まずPosture(状態)というキーワードはゼロトラストがうたわれ始めてから注目されるようになりました。
従来の境界防御が立ち行かなくなり、端末からリソースへアクセスする際には、端末のPostureを都度確認して動的な制御(二要素認証の追加など)をすることが求められ始めたからです。
そしてSPM(Security Posture Management:セキュリティ状態管理)という言葉は、最初はクラウドネイティブ(パブリッククラウドやコンテナ、マイクロサービスなどクラウドの利点を徹底的に活用するシステムの総称)の設定ミスを検出して改善を促すCSPM(Cloud Security Posture Management)から言われ始めました。
現在では、クラウドネイティブを保護する機能が細分化されプラットフォームとして集約されたCNAPP(Cloud Native Application Protection Platform)の一機能として存在しています。
また、SPMはクラウドだけでなく他の要素にも派生しており、CNAPPの中の別機能のものもあれば、他の領域の機能としても存在します。代表的なものだけでも下記のようにたくさんあります。
- SSPM(SaaS Security Posture Management)
- DSPM(Data Security Posture Management)
- ASPM(Application Security Posture Management)
- KSPM(Kubernetes Security Posture Management)
- ISPM(Identity Security Posture Management)
したがって、AI環境のセキュリティ状態を担保する機能としてAI SPMが登場したのは必然であり違和感はありません。また、CNAPPを提供するメーカーがAI SPMも提供し始めているケースが多いのも納得です。
5.DSPM(Data Security Posture Management)
クラウドに存在するデータのセキュリティ状態を継続的に監視、評価、改善することで設定ミスがない状態にしたり、個人情報や医療個人情報、クレジットカード情報などの機密情報を絶えずモニタリングし、攻撃経路の検知を自動で行うことにより漏洩や窃取のリスクを低減したりします。
No.3の「AI SPM」で他のSPMにも触れましたが、DSPMが出始めた当初はCSPMと何が違うのかについてよく質問を受けました。
一例になりますが、AWSのS3バゲットにデータを格納している場合、CSPMではS3バゲットの環境設定の監視・評価はできますが、格納されているデータまでは監視・評価できません。DSPMではそれが逆になります。このようにデータに特化したSPMと理解してもらうとわかりやすいかもしれません。
6.Data Classification
あらゆるところに点在するデータを自動検出しカテゴライズ(分類)する機能です。クラウド上のデータであればDSPMの機能によって自動検出と分類できることが多いですが、データはオンプレミスの環境内にもある可能性があります。
一部のDPSMではオンプレミスのデータにも拡張されて自動検出と分類が可能ですが、大半はクラウドのみ対応、もしくは同一メーカーの別の製品ラインナップでオンプレミスに対応といった状況です。
RAGの登場により、社内(オンプレミス環境)の特定のドキュメントに基づいた回答を生成する社内特化向けサービスが今後活性化していくことが予想されるため、オンプレミス環境も含む一元的な対応に期待しています。
7.Data Encryption
AIモデル内で利用するデータを暗号化されたまま利用できる機能です。FHE(Fully Homomorphic Encryption:完全準同型暗号)という技術を利用します。
この機能を提供しているメーカーはスタートアップ企業が単機能として提供しているケースが多く、Security for AIを提供している大手セキュリティメーカーではまだ未実装が多いです。今後も実装されない可能性がありますが、この機能があるとモデル内での平文処理が不要になり格段にセキュリティが向上するため、個人的には実装して欲しい機能です。
8.Data Masking
学習元データの中の個人情報をマスキングして特定できないようにする機能です。この機能も、Security for AIを提供している大手セキュリティメーカーではまだ未実装が多いですが、個人情報の秘匿は今の世の中では最重要事項であるため近い将来には実装されるのではないかと思います。
これらのコンポーネントを先のAI周辺環境に当てはめると下図のようになります。
AI BOM
弊社では、まだ未成熟としてコンポーネントに追加していませんが、AI BOM(AI Bill of Materials:AI部品表)という考え方が出てきています。
上述の通り、AI自体はソフトウェアのためフレームワークやライブラリ、外部のソースコードやバイナリなどを利用している場合もあるため、OWASP Top10のNo.3の「サプライチェーンの脆弱性」やNo.6の「過剰な自律性」のように部品が多いことで管理しきれないリスクが顕在化してしまいます。
そのため、開発で使用されるすべてのAIコンポーネントをカタログ化することで、セキュリティ、透明性、バイアスといった課題に対処するためのコンポーネントがAI BOMです。
こちらも少し歴史的な背景を補足しますが、BOM自体は元々SBOM(Software Bill of Materials:ソフトウェア部品表)という考え方があり、AI BOMはその拡張です。
SBOMが近年注目されている背景には、ソフトウェアの運用・管理が複雑化し、OSSやサードパーティ製品を利用することが増加しているため、ソフトウェアサプライチェーン攻撃の増加があります。
2021年5月に発出された米国大統領令(EO14028)において、政府調達におけるSBOM活用の検討指示が明記されたことをきっかけに、米国規制当局を中心とした取引組織へのSBOM整備の義務化など、SBOMが急速に普及しつつあります。日本でも経済産業省により産業分野ごとのSBOM導入に向けた議論や実証実験が始まるなど普及に向けた取り組みが進んでいます。
スタートアップ企業買収の考察
前のセクションでスタートアップ企業について少し触れたので、大手セキュリティメーカーがSecurity for AI関連のスタートアップ企業を買収した最近の事例を紹介しJます。
2024年8月26日、Cisco SystemsがRobust Intelligenceを買収する意向を発表しました。
Robust IntelligenceはAIモデルの開発から運用まで全ライフサイクルでリスク管理を自動化する包括的なAIリスク管理ソリューションを提供しており、ハーバード大卒の日本人研究者とその指導教授が共同で設立した企業です。Robust IntelligenceはLLM Firewall/AI SPM/AI Red Teamingの3コンポーネントを提供しています。
Cisco SystemsのSecurity for AIソリューションの「AI Defense」は3コンポーネントのうちLLM Firewall/AI SPMを提供していますが、AI Red Teamingは提供していないので、この買収により「AI Defense」のさらなる機能強化と新機能の追加が今後期待されます。
もう1つは2025年4月28日に発表された、Palo Alto NetworksのProtect AIの買収です。
Protect AIはAI環境のサプライチェーン全体を可視化し、セキュリティ対策を包括的に自動化できるソリューションを提供している企業です。Protect AIはLLM Firewall/Model Scan /AI Red Teamingの3コンポーネントを提供しています。
Palo Alto NetworksのSecurity for AIソリューションは「AI Runtime Security」と「Cortex Cloud」から成ります。3コンポーネントのうちLLM Firewallを提供していますが、Model Scan/AI Red Teamingは提供していないので、この買収によりCisco Systems同様さらなる機能強化と新機能の追加が今後期待されます。
2社の買収事例で共通しているのは、両者とも既に自社のSecurity for AIソリューションを持っていますが、カバーできていないコンポーネントの中でもAI Red Teamingに軸足を置いて、それを提供しているスタートアップ企業の買収しているため、AI Red Teamingの重要度が高いことが伺えます。
OWASP Top10のリスクの対策に有効なコンポーネント
最後に、OWASP Top10のリスクの対策にはどのコンポーネントが有効なのかをまとめたのが下表です。
見ていただくとLLM Firewallが占める割合が多いです。
やはり入出力のインタフェースが一番狙われやすいため、LLM Firewallを導入するだけでもかなり有効です。
したがって、新たに続々とSecurity for AI領域に大手セキュリティメーカーが参入してきていますが、上述の8つのコンポーネントのうちLLM Firewall単機能の提供で参入している、Akamai Technologies、F5、Cloudflareなどのメーカーもいます。
今後も目が離せない「Security for AI」
今回は、AIアプリケーションのセキュリティ対策としてSecurity for AIに必要な具体的コンポーネントの説明をゼロトラスト領域との関連性や歴史的背景、スタートアップ企業の買収動向などにも少し触れながらお伝えしました。
Security for AIの領域はまだまだ未成熟なため、エンタープライズ企業でもまだ検討の優先度がそこまで高まっていないように感じますが、今後も新しい技術やコンポーネントの台頭、メーカーの機能拡充や買収動向など目が離せない市場です。
ぜひ皆さまにも今後も注目してもらいたいと思います。


