AIアプリケーションセキュリティとは？
AIアプリケーションセキュリティとは、AI model、エージェント、データpipelinesを組み込んだアプリケーションを、コード、クラウドインフラ、runtimeの挙動にまたがる脅威から保護する取り組みです。これが重要なのは、AIアプリケーションがprompt injection、datasetへのデータポイズニング（Data poisoning）、自律型エージェントの悪用といった攻撃対象領域をもたらすためです。従来のAppSecツールは、こうした脅威の検知を想定して設計されていません。
なお、「AIアプリケーションセキュリティ」とは、AIを活用したアプリケーションそのものを保護することを指し、本記事ではこれを扱います。これは、AIを活用したコードスキャンやアラートトリアージのautomationなど、既存のセキュリティワークフローの改善にAIを使うこととは異なります。どちらも有効ですが、解決する課題が異なります。
では、AIアプリケーションは従来のアプリケーションと何が違うのでしょうか。一般的なアプリケーションコードに加えて、AIアプリケーションにはtrainingされたmodel、inferenceエンドポイント（modelの予測を提供するAPI）、vectorデータベース（embeddingベースの検索に使うストア）、検索拡張生成（RAG）のpipelines（modelが外部のナレッジベースからcontextを取得する仕組み）、エージェントのオーケストレーション層、外部ツールとの接続が含まれます。これらのコンポーネントにより、攻撃対象領域はコード、データ、インフラ、挙動のすべてにまたがって根本的に拡大します。
今、AIアプリケーションセキュリティが重要な理由
AIの導入は、セキュリティプログラムが適応できる速度を上回るペースで加速しています。『クラウドにおけるAIの現状2025年版（Wiz State of AI in the Cloud 2025）』レポートでは、大多数の組織がすでにクラウド環境でAIサービスやツールを利用していることが明らかになりました。AIを活用したコーディング、開発者がセキュリティ承認なしに立ち上げるマネージドクラウドAIサービス、サードパーティmodelの迅速な統合により、AIアプリケーションは従来のソフトウェアよりも速いペースでリリースされています。
このスピードが、shadow AIと呼ばれる問題を拡大させています。開発者は、Amazon SageMaker、Google Vertex AI、Azure OpenAI Serviceなどのマネージドサービスを一元的な監視なしに導入しています。マイクロソフトの『ワークトレンドインデックス（Work Trend Index）』では、AIユーザーの78%が独自のツールを職場に持ち込んでいることが判明しており、公式なsecurity controlsの外側でデータリスクのexposureが拡大しています。セキュリティチームは見えないものを保護できないため、agentlessな自動検出が基盤となる要件になります。
よくあるシナリオを考えてみましょう。データサイエンティストが、fine-tuningしたmodelを試すために、パブリックIPと広範なIDおよびアクセス管理（IAM）権限を持つVertex AIノートブックを立ち上げたとします。一元的なvisibilityがなければ、セキュリティチームはこのエンドポイントの存在すら把握できず、機密データを含むdatasetがインターネットに公開されていることにも気付けません。
規制の整備も進んでいます。『OWASP Top 10 for LLM Applications』、米国国立標準技術研究所（NIST）の『AIリスクマネジメントフレームワーク（AI Risk Management Framework）』、EU AI Actなどの基準により、組織がAIシステムをどのように保護すべきかが明文化されつつあります。AIセキュリティを後回しにすると、技術面とcompliance面の両方でリスクが生じます。禁止されたAI利用行為への違反に対しては、EU AI Actの制裁金が最大3,500万ユーロに達します。
AIアプリケーションセキュリティと従来のAppSecの違い
従来のアプリケーションセキュリティは、コードの脆弱性、dependencyの欠陥、misconfiguration、決定論的な入力とoutputsを伴うインジェクション攻撃といった既知のパターンに焦点を当てています。AIアプリケーションは、こうした前提を根本から覆します。
| 観点 | 従来のAppSec | AIアプリケーションセキュリティ |
|---|---|---|
| 攻撃対象領域 | アプリケーションコードとdependency | model＋dataset＋エージェントのツール＋MCP（Model Context Protocol）サーバー＋クラウドAIサービス |
| 入力の挙動 | 決定論的（構造化クエリ、フォーム入力） | 非決定論的（自然言語のprompt、マルチモーダル入力） |
| データへのdependency | 静的な設定ファイル | trainingに使うdataset、ナレッジベース、vectorストア |
| アイデンティティの考え方 | ユーザー向けの認証 | ツールへの自律的なアクセス権とサービスアカウント権限を持つエージェント |
| runtimeの挙動 | 予測可能なコード実行 | modelのinferenceとエージェントの意思決定から生じる創発的な挙動 |
| supply chain | ライブラリとパッケージ | modelの重み、事前training済みのチェックポイント、promptテンプレート、AI SDK（ソフトウェア開発キット） |
重要な変化はここにあります。従来のAppSecでは、コードがアプリケーションそのものでした。AIアプリケーションセキュリティでは、コード、model、trainingに使われたdataset、呼び出せるツール、実行時のアイデンティティ、依存するクラウドサービスのすべてがアプリケーションに含まれます。セキュリティは、これらのレイヤーをまとめて考慮する必要があります。
AIアプリケーションセキュリティの主なリスク
AIアプリケーションは、model自体、データpipelines、エージェントを含むアプリケーションロジック、クラウドインフラという4つのレイヤーにわたってリスクをもたらします。最も危険なリスクは、複数のレイヤーの弱点が組み合わさったときに生じます。
prompt injectionと入力操作
prompt injectionとは、細工した入力によってmodelに指示を回避させたり、システムpromptを漏洩させたり、意図しない操作を実行させたりする攻撃です。直接prompt injectionは、ユーザー向けの入力を通じてmodelを標的にします。間接prompt injectionはより巧妙で、攻撃者はRAGベースのアシスタントが取得して従うドキュメントやデータソースに、隠れた指示を埋め込みます。
たとえば、攻撃者が社内ナレッジベースに保存されたPDFに悪意のある指示を仕込んだとします。社内アシスタントが質問に答えるためにそのドキュメントを取得すると、隠れた指示に従い、接続されたvectorストアからデータを持ち出してしまいます。こうした攻撃は完全にruntimeの入力に依存するため、静的コード解析では検出できません。だからこそ、prompt injectionのガードレールとruntime監視が不可欠です。
datasetへのデータポイズニングとデータのexposure
datasetが侵害されたり、exposureが生じたりすると、modelの完全性は2つの方向から損なわれます。データポイズニングとは、datasetに悪意のあるサンプルを注入し、modelに誤った挙動や有害な挙動を学習させることです。データ漏洩とは、modelがtraining中に個人を特定できる情報（PII）や認証情報などの機密データを記憶し、outputsとして再現してしまうことです。
AIパイプラインにデータを供給するdatastoreに攻撃者がアクセスしたり、操作したりできれば、model outputsはすべて信頼できなくなります。チャット履歴や運用データが漏洩していたDeepSeekのデータベースの公開状態をWiz Researchが発見した事例は、misconfigurationのあるdatastoreがいかに短時間でAIの運用全体を露出させ得るかを示しています。
AIのサプライチェーンの脆弱性（Supply chain vulnerabilities）
AI supply chainは、従来のライブラリやパッケージの範囲を超えています。シリアライズされた悪意のあるコードを含む可能性のあるmodelファイル、LangChainやHugging Face TransformersなどのAI SDK、サードパーティから入手した事前training済みの重み、そしてAI supply chainを構成するpromptテンプレートもその一部です。従来のdependencyとは異なり、modelの重みやデータのartifactは、標準的なSAST（static application security testing）やSCAツールでは監査が困難です。Pythonのpickleによるデシリアライズで読み込まれた悪意のあるmodelファイルは、読み込まれた瞬間にホスト上で任意のコードを実行できます。
エージェントとツールの悪用
エージェント型AIは、根本的に新しいリスクカテゴリーをもたらします。エージェント型AIとは、どのツールを呼び出し、どのデータにアクセスし、どのコードを実行するかをmodelが自律的に判断するシステムです。MCPサーバーは、エージェントがアクセスできるツールとデータソースを定義します。ツール定義の権限が過剰だと、侵害されたエージェントのblast radiusは大幅に広がり、データベースへの書き込み、シェルコマンドの実行、外部APIの呼び出しにまで及ぶ可能性があります。
多くのセキュリティプログラムはmodelの挙動に注目する一方で、modelを包むエージェントの権限と機能を見落としています。これは現在のAIセキュリティにおいて、最も急速に拡大しているギャップです。
AIサービスにおけるクラウドインフラのmisconfiguration
SageMakerエンドポイント、Vertex AIノートブック、Azure MLワークスペースなどのマネージドAIサービスはクラウドresourceであり、他のインフラと同じmisconfigurationのリスクを抱えています。具体的には、パブリックなexposure、暗号化されていないエンドポイント、過剰な権限を持つIAMロール、ネットワーク制御の欠如です。暗号化なしでデプロイされ、機密データを含むdatasetを格納したS3バケットへのアクセスを許可する広範なIAMロールを持つSageMakerエンドポイントは、model自体がどれほど適切に保護されていても深刻なexposureです。AIセキュリティは、クラウドセキュリティ態勢管理（CSPM）と切り離せません。
コードからクラウド、runtimeに至るAIアプリケーションセキュリティの仕組み
AIアプリケーションの保護は、3つのライフサイクルフェーズにまたがって行われます。フェーズごとに対処するリスクカテゴリーは異なりますが、実効性のある保護には3つすべてのsignalを結び付けることが欠かせません。
開発段階におけるAIの保護
開発フェーズは、安全でないAIのパターンを本番環境に到達する前に検出できる段階です。具体的には、コードリポジトリと継続的インテグレーション／継続的デリバリー（CI/CD）のpipelinesをスキャンし、AI workload特有の次のような問題を見つけます。
埋め込まれた認証情報：ソースファイルにハードコードされた、OpenAI、Anthropic、クラウドAIサービスのAPIキー
脆弱なAIライブラリ：既知の共通脆弱性識別子（CVE）を持つ、古いバージョンのLangChain、Hugging Face Transformers、その他のAI SDK
安全でないmodelの読み込み：信頼できないmodelファイルから悪意のあるコードを実行し得るデシリアライズのパターン
権限が過剰なエージェント定義：制約なしにデータベースへの書き込み権限やシェル実行をエージェントに許可するツール設定
クラウドインフラ全体におけるAIの保護
AI workloadがデプロイされた後は、態勢管理が中心になります。具体的には、shadow AIを含め環境内で稼働しているすべてのAIサービスを検出し、その設定をセキュリティベースラインに照らして評価し、各workloadに付与されたアイデンティティの権限をマッピングします。AI部品表（AI Bill of Materials、AI-BOM）は、環境全体のmodel、SDK、エージェント設定、データのdependencyをinventoryとして把握し、クラウドにおけるAI supply chainの全体像をチームに示します。AIサービスが短時間で起動と停止を繰り返す環境では、agentlessなクラウドネイティブのAPIベースのスキャンにより、coverageの抜けを生じさせずにすべてを捕捉できます。
runtimeにおけるAIの保護
runtime監視は、実際の利用時にしか現れない脅威を検知します。たとえば、静的解析をすり抜けるprompt injectionの試行、想定された範囲を逸脱するエージェントの挙動、model outputsを通じたデータの持ち出し、予期しないツール呼び出しなどです。AIの挙動は非決定論的であるため、runtime監視は省略できるものではありません。本番環境で実際の入力がmodelやエージェントと相互作用することで生じる脅威を捕捉するには、これが唯一の方法です。
次のようなシナリオを考えてみましょう。社内ドキュメントの要約を目的としたエージェントが、明示的に設定されていない外部APIを呼び出し始めます。きっかけは、取得したドキュメントに埋め込まれた、巧妙に細工された間接prompt injectionです。
contextの連携が重要な理由
真の価値は、開発、インフラ、runtimeのsignalが結び付いたときに生まれます。コードスキャンで指摘された脆弱なAIライブラリは、1つの検出結果にすぎません。しかし、同じライブラリがパブリックに公開されたコンテナにデプロイされ、PIIを大量に含むdatasetを格納したバケットへのS3読み書き権限を持つサービスアカウントで動作し、ネットワークセグメンテーションもない場合、それは悪用可能な重大なattack pathになります。こうしたレイヤー横断のつながりによって、検出結果の一覧が、実際のリスクを優先度順に把握できる情報へと変わります。
AIアプリケーションセキュリティのメリットとは？
AIアプリケーションセキュリティの価値は、機能の一覧ではなく、測定可能な成果として表れます。
AI workload全体の死角の解消
継続的な検出とinventoryにより、セキュリティチームはどのAIが稼働し、どこにデプロイされ、何にアクセスできるかを把握できます。この基盤がなければ、他のすべてのsecurity controlsは不完全な情報に基づいて機能することになります。
悪用可能なAIの脅威への集中によるリスク低減
コード、クラウド、runtimeのsignalを結び付けることで、継続的な脆弱性管理を通じて何千件もの理論上の検出結果をトリアージするのではなく、実際に到達可能で影響の大きいAIの問題を特定できます。優先度を決めるのはcontextです。
AI開発のスピードに合わせたセキュリティ
AIアプリケーションは従来のソフトウェアよりも速くリリースされます。既存の開発者ワークフローやCI/CD pipelinesに組み込まれたセキュリティプラクティスであれば、ボトルネックになることなくそのペースに対応できます。Genpact社のチームはAIセキュリティ態勢管理（AI-SPM）を活用し、セキュリティのベストプラクティスを適用しながらAIアプリケーションのデプロイを加速させ、secure by designなAIアプリケーションを展開しました。
AIシステムのコンプライアンス態勢の強化
継続的な態勢評価と監査に対応できるレポートにより、組織はEU AI Act、NIST AI RMF、OWASP LLM Top 10で新たに求められる要件を満たしやすくなります。継続的なvisibilityを備えた組織であれば、監査の際にも慌てることなくcomplianceを証明できます。
AIアプリケーションセキュリティプログラムでよくある落とし穴
AIセキュリティプログラムの多くは、ツールの不足ではなく、重大なギャップを残すアーキテクチャや運用上の誤りによって失敗します。成熟したセキュリティ組織でさえ陥りがちなパターンを紹介します。
AIセキュリティをmodelだけの問題として扱うこと：多くの組織はmodelの挙動に注目する一方で、modelレベルの悪用によるblast radiusを左右するクラウドインフラ、アイデンティティ層、データpipelinesを見落としています。prompt injectionは単体であれば厄介な程度で済みます。しかし、データベースへの書き込み権限を持ち、ネットワークセグメンテーションもないエージェントに対するprompt injectionは、データ侵害そのものです。
短期間で入れ替わるAI workloadにエージェントベースのアプローチで対応すること：AIサービスやコンテナは短時間で起動と停止を繰り返します。各workloadにセキュリティエージェントのインストールを必要とするツールでは、環境内で最も変化の激しい部分にcoverageの抜けが生じます。
コードとクラウドをcorrelationなしで個別にスキャンすること：AI SDKの脆弱性の優先度は、そのworkloadがインターネットに公開されているか、付与されたサービスアカウントが広範なデータアクセス権を持つかによって変わります。ドメイン横断のcorrelationがなければ、重大な問題とnoiseを区別できません。
エージェント層を無視すること：modelとインフラは保護していても、エージェントのツール権限、MCPサーバーの設定、自律的な意思決定の境界を評価していない組織では、最も高い能力を持つAIコンポーネントが管理されないまま残ります。
AIアプリケーションセキュリティソリューションの選定ポイント
AIセキュリティツールがカバーする範囲はそれぞれ異なります。適切なソリューションは、AIリスクの各レイヤーを個別に扱うのではなく、相互に結び付けます。
コードからruntimeまでのライフサイクル全体のcoverage：1つのフェーズだけでなく、開発、クラウドインフラ、runtimeのすべてに対応している必要があります。
agentlessな検出とinventory：すべてのworkloadにエージェントを導入しなくても、AIサービス、model、データのdependencyに対する広範なvisibilityをすばやく得られることが重要です。
クラウドのcontextとアタックパス分析：検出結果は深刻度スコアだけでなく、ネットワークのexposure、アイデンティティの権限、データアクセスなど、実際のデプロイ状況に照らして評価される必要があります。
AI特有のリスク検知：AI向けに再パッケージされた従来の脆弱性だけでなく、prompt injection、datasetのexposure、エージェントの悪用など、AIネイティブな脅威を検知できるplatformである必要があります。
AI部品表（AI-BOM）：AIコンポーネントをsupply chainのartifactとしてinventoryで管理し、コードとクラウドを統合したビューで把握できる機能が求められます。
既存ワークフローとの統合：検出結果は、JIRA、Slack、ServiceNow、CI/CD pipelinesなど、チームがすでに使っているツールに連携される必要があります。
AIアプリケーションセキュリティに対するWizのアプローチ
Wiz AI-Application Protection Platform（AI-APP）は、開発からクラウドインフラ、runtimeに至るまでAIスタック全体を1つのセキュリティの枠組みに結び付けます。WizはAIセキュリティを独立した分野として扱うのではなく、既存のクラウドのセキュリティ態勢、脆弱性管理、アイデンティティ、データセキュリティのワークフローにシームレスに統合します。
platformがAI lifecycleの各フェーズをどのように保護するかを紹介します。
ビルド（Wiz Code）：リポジトリとCI/CD pipelinesをスキャンし、安全でないAIのパターン、脆弱なAI SDK、埋め込まれた認証情報を検出します。
デプロイ（Wiz Cloud & AI-SPM）：shadow AIを含むすべてのAIサービスを検出し、AI-BOMの全体像をマッピングして、厳格なセキュリティベースラインに照らして設定を評価します。
実行（Wiz Defend）：本番環境のAIトラフィックをリアルタイムで監視し、prompt injection、不正なエージェントの挙動、データの持ち出しを能動的に検知します。
contextに基づく優先順位付け（Wiz Security Graph）：各要素をつなぐ役割を担い、AI特有のリスクをアイデンティティの権限、ネットワークのexposure、データ分類といった広範なクラウドのcontextと結び付けます。孤立したアラートを大量に出す代わりに、機密データを含むdatasetに過剰な権限を持つクラウド認証情報でアクセスする、パブリックにアクセス可能なエージェントといった危険な組み合わせを特定します。
AIアプリケーションのコード、クラウドインフラ、runtimeにまたがるリスクを包括的に把握する方法について、Wizのデモでご確認ください。 Wizのデモを見る