「テストに合格した」が安全を意味しない世界
従来のWebアプリは決定的(deterministic)です。同じリクエストには同じレスポンスが返り、脆弱性診断に合格すれば、その挙動は本番でも再現されると期待できます。LLMアプリはそうではありません。非決定性は、実務上3つの帰結をもたらします。
- 静的検証は「必要条件」止まり。リリース前のテストで危険な挙動が出なかったことは、本番で出ないことを保証しない。
- 入力とデータの完全な分離ができない。LLMにとっては指示も参照文書も同じ「テキスト」であり、文書に埋め込まれた悪意ある指示を仕様として完全に遮断する方法は、現時点で存在しない。
- 攻撃面が「会話」に広がる。SQLインジェクションのような構文ベースの防御では、自然言語による攻撃(プロンプトインジェクション)を網羅できない。
結論はシンプルです。「デプロイ前に閉じる守り」に加えて、「ランタイム防御+継続監視」を一級のセキュリティ制御に据えること。リリース前の検証だけで安全を宣言できるという従来の感覚を、まず手放す必要があります。
OWASP Top 10 for LLM ― ただし「番号順」ではなく「効く場所」で整理する
LLMアプリのリスク整理の出発点として、OWASP(Open Worldwide Application Security Project)が公開している OWASP Top 10 for LLM Applications 2025 が事実上の共通言語になっています。プロンプトインジェクション、機微情報の漏えい、サプライチェーン、過剰な権限付与(Excessive Agency)など10項目が定義されています。
ただ、10項目を番号順に潰していく進め方はおすすめしません。私たちは各項目を「主たる対策がどの工程で効くか」でライフサイクル4層に再整理するアプローチを取っています。
| 層 | 主な対策の例 | 性格 |
|---|---|---|
| ➀ 設計 | 指示/データ分離の設計、秘密情報をプロンプトに置かない、権限・ツールの最小化 | デプロイ前に「閉じられる」対策 |
| ➁ デプロイ前 | 依存関係・モデルのスキャン、AIBOM(AI部品表)による来歴検証、出力処理レビュー | デプロイ前に「閉じられる」対策 |
| ➂ ランタイム | 入出力フィルタリング、出力スキーマ検証、サンドボックス実行、重要操作の人間承認、レート制限 | 動的に「下げ続ける」対策 |
| ➃ 継続運用 | ログ・監視・異常検知、定期レッドチーミング、RAG取り込みデータの継続検証、コスト監視 | 動的に「下げ続ける」対策 |
この整理の効用は、「一度やれば終わる対策」と「運用として回し続ける対策」が明確に分かれることです。セキュリティ予算と体制の議論が、導入時の一時費用だけでなく運用の話として正しく立てられるようになります。
2025〜2026年、攻撃は「理論上」から「実戦」へ移った
長く「理論上のリスク」と言われてきた攻撃が、この1年で実際のインシデントとして相次いで報告されるようになりました。公開報告からいくつかの類型を挙げます。
- 間接プロンプトインジェクションの実戦化。Webページ・文書・メールに隠し指示を仕込み、それを読んだエージェントにデータ持ち出しや認証情報の窃取を実行させる攻撃が、本番環境で観測される段階に入った。クリックすべきリンクも、起動すべきマルウェアも存在しないのが特徴。
- エージェント用スキル/プラグインのサプライチェーン攻撃。誰でも公開できるマーケットプレイスに悪性のスキルが多数投稿され、マルウェア配布の経路になった事例が報告されている。
- AIそのものの攻撃転用。ジェイルブレイク(安全機能の回避)により、攻撃作業の大部分をAIに実行させた大規模侵害が報告されている。国内でも、生成AIのガードレールを回避して攻撃プログラムの作成を補助させた事案が報道されている。
これらの事例が共通して示すのは、「モデル自身の安全機能(ガードレール)はセキュリティ境界にならない」ということです。防御は、プロンプトの工夫ではなく、モデルの外側に置いた決定論的で監査可能な統制 ― 権限の最小化、認可のLLM外強制、サンドボックス、人間承認 ― で構成する必要があります。
国内では制度面の整備も進んでいます。IPA「情報セキュリティ10大脅威 2026」では組織向け脅威として「AIの利用をめぐるサイバーリスク」が初めて上位に入り、総務省「AIセキュリティ確保 技術的対策ガイドライン」(2025年12月)、経済産業省・総務省「AI事業者ガイドライン」などの指針も出揃ってきました。取引先からAI利用のセキュリティ体制を問われるケースも増えており、対応は「あると良いもの」から取引条件になりつつあります。
見落とされがちな盲点 ― 「シャドウビルダーズ」
もうひとつ、多くの組織で対策が抜けている領域があります。AI支援やノーコードツールの普及で、情報システム部門の管理外で、現場の社員が自作のLLMアプリやエージェントを作れるようになりました。私たちはこれを「シャドウビルダーズ」と呼んでいます。承認外の生成物は、それ自体がOWASPリスクの塊です。
ここで重要なのは、禁止一辺倒にしないことです。禁止は利用の地下化を招き、可視性をさらに失わせます。有効なのは「発見と安全レール」のアプローチです。まず棚卸しで自作ツールを発見し、承認済みの安全な構築環境(ガバナンスの効いたプラットフォーム)へ誘導し、段階的に統制に乗せていく。作る意欲は組織の資産として活かしつつ、リスクだけを統制する設計です。
まとめ ― 最初に確認すべき5つ
- 秘密情報(APIキー・認証情報)をプロンプトに書いていないか
- LLMに与えた権限・ツールは業務に必要な最小限か
- 重要な操作(送信・決済・削除など)に人間の承認を挟んでいるか
- 入出力のログを取り、異常を検知できる状態か
- 社内の「承認外の自作AIツール」を把握できているか
この5つに1つでも「いいえ」があれば、ライフサイクル4層のどこに穴があるかを体系的に点検する価値があります。