現在、本番環境で稼働しているソフトウェアの大部分はAIによって作成されています。によると Aikidoの『2026年 セキュリティおよび開発におけるAIの現状』レポートによると、本番環境のコードの24％が現在AIによって生成されている。しかし、69％の組織がAI生成コードに脆弱性を発見しており、20％はその結果として重大なインシデントを報告している。
LLMをめぐるセキュリティに関する議論の多くは、モデルに「ガードレール」を設けることに焦点が当てられています。しかし、アプリケーション層にははるかに注目が集まっていません。にもかかわらず、こうしたインシデントの多くはアプリケーション層に起因しており、ガードレールでは防ぎきれないのが実情です。 2025年1月、AIが生成したコードにおける重大な設定ミスのため、Lovableが開発した170以上のアプリで、メールアドレス、API 、支払い情報、個人データが流出する事態が発生しました。モデルの前にどのようなガードレールを設置していたとしても、これを検知することはできなかったでしょう。
この記事では、LLMアプリケーションのセキュリティが実際にどのような範囲をカバーしているのか、なぜそれが必要なのか、その課題に対応できるツールの選び方、そしてどのプラットフォームが最も広範な対応を提供しているのかについて解説します。
{{cta}}
要約
Aikido セキュリティ は、AI開発ライフサイクル全体にわたってエンタープライズグレードのLLMアプリケーションセキュリティを求めるチームにとって、最も強力な選択肢です。IDE内でAIが生成したコードをスキャンし、インストール時に悪意のあるパッケージや誤った情報を生成するパッケージをブロックし、悪意のあるMCPサーバーなどの脅威から開発環境を保護し、本番環境でアプリケーションがどのAIモデルを呼び出しているかを追跡します。
LLMアプリケーションのセキュリティとは何ですか？
本稿では、アプリケーション側の観点からLLMのセキュリティに焦点を当てます。つまり、LLMを取り巻くコード、依存関係、およびインフラストラクチャのセキュリティ確保について取り上げます。これは、実行時のLLMの挙動を対象とする「モデルセキュリティ」とは区別されるものであり、モデルセキュリティはLakera Guard、Prisma AIRS、NeMo Guardrails、Garakといったガードレールやレッドチームングツールによって対処されます。いずれか一方だけでは不十分です。
AikidoPromptPwndの調査により、アプリケーション側に注目すべき理由が明らかになった。GitHub Actionsのワークフロー内で実行されていたGemini CLIやその他のエージェントのプロンプトに、信頼できない入力が注入され、それらのエージェントが特権トークンを使用してシークレット漏洩させてしまった。少なくとも5社のフォーチュン500企業が影響を受けた。
このモデルは攻撃者の侵入経路でしたが、脆弱性 ワークフローファイル内に脆弱性 、これはアプリケーションセキュリティツールでチェック可能なものです。SAST 、プロンプトに流入する信頼できない入力や、エージェントに公開されている特権トークンを検知することができます。まさにこれが AikidoのOpengrepルールが検出し、Googleが開示から4日以内に修正した内容そのものです。
「OWASP Top 10 for LLM Applications 2025」は、この分野における基準となるフレームワークであり、そのカテゴリーのいくつかはアプリケーション層に該当します。これには、サプライチェーン（LLM03）、不適切な出力処理（LLM05）、過剰な自律性（LLM06）、誤情報（LLM09）などが含まれます。 しかし、この分類体系は実行時のLLMアプリケーションを念頭に置いて作成されたものであり、AIを活用した開発に伴うリスクを部分的にしか捉えていません。
こうした脆弱性は、すでに現実の世界で発生しています。 LLM09の研究において、USENIX 2025の研究者らは223万件のコードサンプルを対象に16のモデルをテストし、19.7％のモデルに少なくとも1つの「幻覚」パッケージ名が含まれていることを発見しました。同一のプロンプトを再実行したところ、10件のクエリすべてにおいて、43％の「幻覚」パッケージが再出現しました。現在、攻撃者は事前に偽の名前を登録し、モデルの特性を悪用してサプライチェーン攻撃を仕掛けています。
これらのカテゴリを網羅するには、いくつかの異なる機能が必要です。アプリケーションコードに対するSAST ークレットスキャンは、ハードコードされた認証情報や、プロンプトに流入するサニタイズされていない入力を検出します。SCA 、既知の脆弱性を持つAIフレームワークのバージョンをSCA 、サプライチェーンマルウェア検出は、悪意のあるパッケージや「幻覚」を生成するパッケージを検知します。開発環境の保護機能は、パッケージとして配布される悪意のあるMCPサーバーや、侵害された拡張機能を、インストールされる前に検知します。 また、LLMの利用状況追跡により、アプリケーションが実際にどのモデルを呼び出しているかを監視し、許可されていないAI統合を明らかにします。
LLMセキュリティツールが必要な理由
AIの開発により、セキュリティチームが対処すべき新たな脆弱性が生じています。
- AI生成コードがレビューなしでリリースされている： 現在、本番環境のコードの4分の1が AIによって生成されているが 、レビューのペースがコード生成のペースに追いついていない。
- LLMは、実行されるコードの脆弱性を引き継いでしまいます。重要なのは、AIが記述したコードだけではありません。LLMが読み込み、実行対象とし、あるいは文脈として参照するあらゆるコードが、その攻撃対象領域の一部となります。まさにこの点が、PromptPwndを悪用可能にした要因なのです。
- Slopsquatted パッケージ：攻撃者は 、AIアシスタントが誤認識するパッケージ名を登録し、モデルの特性を悪用してサプライチェーン攻撃を仕掛ける。
- Shadow AI：各チームは 、誰も管理リストに載せていないモデルを呼び出し、誰も承認していないプロバイダーにデータを送信している。
- コンプライアンス上の圧力により、LLMのセキュリティ対策が求められ始めています。 EUのAI法 がその 最も明確な例であり、OWASPの「LLM Top 10」は、セキュリティレビューにおける事実上の基準枠組みとなりつつあります。
LLMセキュリティツールの選び方
AIのSDLC全体を網羅
AI生成コード、それを支えるサプライチェーン、そしてそれを生み出す開発環境を網羅するプラットフォームです。単機能ツールでは一部しかカバーできず、複数のベンダーを組み合わせると、ダッシュボードが複数になり、分析結果の重複が生じてしまいます。
IDE内でAIが生成したコードをチェックしますか？
アシスタントが作成したコードは、プルリクエストに追加された後にCIで発見されるのではなく、作成時点でスキャンされるべきです。IDEは、AIが生成したコードの脆弱性に対する最初の防衛線となります。なぜなら、IDEこそが、人間がすべての行を積極的に確認する場所だからです。
信号ノイズ
AIによって、コードの量も発見事項の量も膨れ上がってしまった。自身の出力を適切に選別できないツールは、新たな未処理業務の積み残しとなってしまう。
LLMの利用状況の追跡
アプリケーションがどのモデルを呼び出しているかを可視化することで、監査担当者や攻撃者が先に発見する前に、隠れたAIを洗い出すことができます。
AIアプリケーション向けのトップLLMセキュリティツール
Aikido Security
Aikido 、AIアプリケーションのライフサイクルをエンドツーエンドでカバーします。その範囲は、AIによって生成されたコードの起点となるIDEから、そのコードが実行される本番環境に至るまでを網羅しています。
コードレベルでは、 AikidoのMCPプラグインは、 AikidoのセキュリティエンジンをAIコーディングツールに直接接続し、自動的に SASTシークレット 生成されたコードに対してIDE内で自動的に実行します。脆弱性は、プルリクエストや、さらに悪い場合には本番環境で表面化するのではなく、作成の段階で検出されます。これと並行してSafe Chainが機能し、インストール時に悪意のあるnpmパッケージや偽装されたnpmパッケージをブロックし、パッケージが依存関係ツリーに組み込まれる前にスロープスクワッティング攻撃の経路を遮断します（これはOWASP LLM09に直接対応しています）。
環境レイヤーにおいて、Device ProtectionはAIを活用した開発が行われているマシンを監視します。AIコーディングツールはMCPサーバーに接続し、拡張機能をインストールし、パッケージを取得しますが、そのそれぞれが攻撃者にエクスプロイト経路となります。Device Protectionは、悪意のあるMCPサーバーや侵害された拡張機能を、インストールされる前に検知します。
DSPMは、AIアプリケーションのデータが最終的にどこに保存されるかを把握します。機密性の高い顧客データは、ベクトルデータベースやプロンプトログなど、従来のツールでは検知できない場所に流れ込み、多くの場合、事前に匿名化されることなく保存されます。DSPMは、こうした無防備な状態で放置されているデータを特定するため、AI機能が書き込むインフラストラクチャ内に個人識別情報（PII）が知らぬ間に蓄積されるのを防ぎます。
また、制作においては、 Zen は、アプリ内でのLLM利用状況の追跡機能を提供します。これにより、アプリケーションがどのAIモデルを呼び出しているかをリアルタイムで正確に把握し、データがどこへ送信されているかをリージョンレベルまで追跡し、AI利用のコンプライアンスを徹底することで、不正な統合が即座に検出されます。
これらすべての背後で、AutoTriageが重複排除、到達可能性フィルタリング、およびスキャナー間の相関分析を行い、AIによって膨れ上がった検出件数をエンタープライズ規模でも管理可能なレベルに抑えています。
また、RBAC、SSO、監査ログがすべてのレイヤーの基盤となっているため、企業のガバナンス要件を満たしています。
最適な対象：開発ライフサイクル全体にわたるAIアプリケーションのセキュリティを確保し、ガバナンスに必要なRBAC、SSO、監査証跡を整備したいエンタープライズチーム。
{{walkthrough}}
Snyk
Snykのプラットフォームは、SAST、SCA、コンテナ、およびIaCのスキャンを網羅しており、そのDeepCode AIエンジンが、IDE内での検出機能やAIによるコード分析を支えています。この1年間で、Snykは「AIセキュリティプラットフォーム」として位置づけを刷新し、エージェント型AIのポスチャー管理を行う「Evo AI-SPM」、ライフサイクル全体にわたるAIエージェントのガバナンスを実現する「Agent Security」、そしてIDE内での自律的な修正を行う「Agent Fix」を相次いでリリースしました。
依然としてSnykの最大の強みは、従来のAppSecエンジンにあります。これらのAI製品の多くは発売から1年未満であるため、SnykのSAST SCA ほどの規模で実戦的な検証がまだ行われていないからです。Snykに通常伴うトレードオフも変わりません。Snykの検出件数の多さはよく指摘される不満点であり、その価格モデルは小規模なチームよりも大規模な組織に適しています。
最適な対象：幅広い言語に対応した定評のあるプラットフォームを求めており、Snykが拡充を進めているAIベースのセキュリティ評価ツールへの投資を厭わないチーム。ただし、検出件数を管理可能な範囲に抑えるためのチューニング時間を予算に組み込む必要があり、小規模な組織には適さないエンタープライズ価格帯となることを想定しておく必要があります。
Semgrep
Semgrepの強みは、カスタマイズ可能なルールにあります。チームは、LLM特有のコードパターンに対して独自の検知ロジックを作成できます。2026年3月にリリースされた「Semgrep Multimodal」は、Semgrepの決定論的ルールエンジンとLLMによる推論を組み合わせることで、トリアージの負担を軽減し、プルリクエスト内で段階的な修正ガイダンスを生成します。 2026年5月にリリースされた「Semgrep Guardian」は、Claude Code、Cursor、Windsurf、Kiroなどのエージェント型コーディングツール内で動作する、AI生成コード向けのリアルタイムセキュリティスキャン機能です。AIリスクに特化した3つの厳選ルールパックが同梱されています。
その代償となるのが適用範囲です。Semgrepはコードセキュリティプラットフォームであるため、パッケージ脆弱性 、開発環境の防御、DSPM、本番環境でのLLM利用状況の追跡といったサプライチェーン保護機能は、すべて別の手段で実現する必要があります。 ルールベースという基盤も依然として重要な要素です。カバー範囲は、どのルールパックを有効にし、どのように調整するかによって異なりますが、Semgrepが現在提供しているAI専用のパックは、以前と比べて、導入直後からより多くの作業を自動的に処理できるようになっています。
最適な対象：独自の検知ルールを記述・調整したいと考えており、フルスタック型のセキュリティスイートよりもコード中心のプラットフォームに慣れているセキュリティエンジニアリングチーム。ただし、サプライチェーン保護、開発環境の脅威、本番環境におけるLLMの利用状況の可視化については、別途対策を講じる必要があります。
Endor Labs
Endor Labsは、SCA、SAST、シークレット 、コンテナスキャン、そして「Package Firewall」による悪意のあるパッケージの検出を網羅する統合プラットフォームです。 AIの分野では、Endorはコードベースに取り込まれたAIモデルを検出し、AI-BOMを生成するとともに、Hugging Faceなどのパブリックリポジトリから取得したモデルに対するリスクスコアリング機能を提供します。同社のAURI MCPサーバーは、Cursor、Claude Code、CopilotなどのAIコーディングアシスタントに直接連携し、コードが記述される際にリアルタイムでスキャンを行います。
しかし、EndorはIDEプラグイン以外の開発環境をカバーしておらず（インストールされた脅威としての悪意のあるMCPサーバーに対する保護機能がない）、本番環境では動作せず（LLMの使用状況の追跡や、実行時のアプリケーション保護機能がない）、DSPMにも対応していない。
最適な対象：AIに関する主なリスクがオープンソースのサプライチェーンにあるチーム。ただし、IDE内のAI生成コード、開発者マシン上の悪意のあるMCPサーバー、本番環境での不正なモデル呼び出しなどがリスクに含まれる場合は、これとは別に別の対策も必要になります。
Wiz
Wizは、クラウドの観点からAIセキュリティに取り組んでいます。同社のAI-SPMは、クラウド環境全体にわたるAIサービス、モデル、トレーニングインフラストラクチャを検出するとともに、設定ミスや情報漏洩のリスクを特定します。 Wiz DSPMは、その検出機能を、機密性の高いAI関連データが蓄積されがちなベクトルストアやプロンプトログにまで拡張します。開発者のワークフローへの展開を目的としてリリースされたWiz Codeは、VS Code、JetBrains、Lovable向けのIDEプラグインを通じて、SAST、SCA、シークレット 、およびIaCスキャンをカバーしています。2026年3月にGoogleによる買収が完了して以来、WizはGoogle Cloud内で独自のブランドとして事業を継続しています。
Wizのカバー範囲が不十分なのは、AI開発パイプラインの最も初期の段階です。悪意のあるパッケージに対するインストール時のブロック機能はありません（Wizはインストール前に遮断するのではなく、事後にそれらを特定します）。また、開発環境を悪意のあるMCPサーバーから保護する機能や、アプリケーション内でのリクエスト単位のLLM利用状況の追跡機能もありません。
最適な対象： AIセキュリティにおける課題が「クラウド全体にわたる可視性」であるセキュリティチーム 。ただし、AI関連の脆弱性が本番環境に到達する前に阻止すること（インストール前の悪意のあるパッケージのブロック、開発者マシン上のMCPサーバーへの脅威の検知、本番環境におけるモデル呼び出しの追跡など）を目標としている場合、Wizの強みは、期待する段階よりもさらに下流に位置しています。
