こんにちは。エーピーコミュニケーションズ ACS事業部の福井です。
近年、生成AIやLLM（大規模言語モデル）を活用したアプリケーションの開発・導入が急速に進んでいます。一方で、セキュリティ要件定義の現場はそのスピードに追いついていないという課題が浮き彫りになっています。
そんなことを考えていた矢先、2026年3月27日にIPAが「中小企業の情報セキュリティ対策ガイドライン」を第4.0版に改訂・公開しました。 中小企業向けのガイドラインがこのタイミングで改訂されたのは、AIを使った攻撃手法の台頭やサプライチェーンリスクの広がりを受け、IPAとしても中小企業のセキュリティ対策の遅れを懸念している表れではないかと感じています。 大企業と違い専任体制を持てない中小企業ほど、体系的なフレームワークに頼る必要があると改めて思いました。
プロンプトインジェクション、機密情報漏洩、RAGを介したデータ改ざん——これらはもはや「理論上のリスク」ではなく、現実に発生しているインシデントだと私は考えています。
この記事では、今回の中小企業ガイドライン第4.0版の改訂ポイントを起点に、IPA「情報セキュリティ10大脅威 2026」と「OWASP Top 10 for LLM Applications 2025」も合わせて、LLMアプリに求められるセキュリティ要件の考え方と、具体的な強化のポイントを整理してみたいと思います。
- なぜ「従来のセキュリティ要件定義」では足りないのか
- OWASP Top 10 for LLM Applications とは
- IPA 中小企業の情報セキュリティ対策ガイドライン 第4.0版（2026年3月）が示すこと
- セキュリティレベルを「リスクに応じて」段階化する
- クラウド環境での「セキュリティレベル強化」具体例
- 今すぐ「要件定義書」に追加すべき観点
- まとめ：IPA 2026 × OWASP LLM × 中小企業ガイドラインv4 = 「現代の最低ライン」
- 参考リソース
- ACS 事業部のご紹介
なぜ「従来のセキュリティ要件定義」では足りないのか
私がこれまで関わってきたWebアプリ・APIの開発では、セキュリティ要件定義のベースとしてOWASP Top 10（SQLインジェクション、XSS、認証不備など）を参照することが多くありました。 あるいは、AIが登場する前の時代に社内で整備された独自のセキュリティ要件定義書をそのまま使っているケースも少なくないと思います。 どちらにせよ、LLMを組み込んだアプリケーションには、それとは構造的に異なるリスクが存在していて、従来の枠組みでは拾いきれないと感じています。
| 従来のWebアプリのリスク | LLMアプリ固有のリスク |
|---|---|
| SQLインジェクション・XSS | プロンプトインジェクション |
| セッション・認証の不備 | System Promptの漏洩・改ざん |
| 機密データのDB不正アクセス | LLM出力からの機密情報の抽出 |
| ライブラリの脆弱性 | RAG・プラグイン・埋め込みデータのポイズニング |
| APIのDoS攻撃 | モデルDoS（高コストリクエストによる課金暴走） |
IPA「情報セキュリティ10大脅威 2026」においても、AI活用を利用した攻撃手法（フィッシングの高度化、AIによるマルウェア生成など）が明記されるようになりました。しかし、LLMアプリの「設計要件」レベルまではカバーしきれていないと感じています。
その「設計要件」の部分を最も体系的にカバーしているのが、OWASP Top 10 for LLM Applicationsだと思います。
OWASP Top 10 for LLM Applications とは
OWASPが公開している「Top 10 for LLM Applications」は、LLM・生成AIアプリケーションにおける代表的な10種類のセキュリティリスクをまとめたフレームワークです。2025年版では以下のリスクが整理されています。
| # | リスク名 | 概要 |
|---|---|---|
| LLM01 | プロンプトインジェクション | 悪意ある入力をプロンプトに混入し、意図しない動作・情報開示・コマンド実行を誘発。Direct（ユーザー直接）とIndirect（外部データ経由）の2種類がある |
| LLM02 | 不安全な出力処理 | LLMの出力をバリデーションなしにDBやスクリプトに渡すことで、XSS・コードインジェクション・コマンド実行が起きうる |
| LLM03 | トレーニングデータのポイズニング | 学習データに悪意ある情報を混入し、モデルの判断・回答をバイアスさせる |
| LLM04 | モデルDoS | 高コストなリクエスト（超長文・再帰処理など）を大量に送り、クラウドの推論コストを暴走させる |
| LLM05 | サプライチェーンの脆弱性 | LLMプラグイン・SDK・RAGデータソース・外部APIに含まれる脆弱性が連鎖する |
| LLM06 | 機密情報の漏洩 | プロンプトや出力を通じて、学習データ・業務情報・個人情報が流出する |
| LLM07 | System Promptの漏洩 | System Promptを抽出・改ざんされ、アプリの制御ロジックが奪われる |
| LLM08 | ベクトル・埋め込みの脆弱性 | RAG用ベクトルDBやEmbeddingデータが改ざん・汚染されることで、意図しない情報が取得・返却される |
| LLM09 | 不適切な権限設定（エージェント） | LLMエージェントが過剰な権限（ファイル削除・API実行等）を持つことで、悪用時の被害が拡大する |
| LLM10 | モデルの盗用 | APIへの大量クエリによりモデルのロジックやパラメータを推定・複製される |
IPA 中小企業の情報セキュリティ対策ガイドライン 第4.0版（2026年3月）が示すこと
2026年3月27日、IPAが「中小企業の情報セキュリティ対策ガイドライン」を第4.0版に改訂しました。今回の改訂には、LLMアプリのセキュリティを考える上でも見逃せない視点が含まれていると感じました。
改訂の主なポイント
情報セキュリティ「6か条」への拡張
「バックアップを取ろう！」が新たに追加され、5か条から6か条になりました。クラウド上にRAGデータや推論ログを蓄積するLLMアプリでも、バックアップ設計は欠かせないと思います。サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）の取り込み
経済産業省・内閣官房が検討する「SCS評価制度」の考え方に沿った内容となっています。これはOWASP LLM05（サプライチェーンの脆弱性）と直接対応する観点だと思います。 LLMプラグイン・外部APIベンダーのセキュリティ評価が、今後サプライチェーン管理の文脈で求められるようになるのではないでしょうか。セキュリティ人材確保・育成の実践ガイドブックを付録追加
AI時代に対応したセキュリティ人材の確保・育成が明示的な課題として位置づけられました。 LLM固有リスクを理解できるエンジニア・レビュアーの育成が、今後の組織にとって重要な課題になると感じています。
中小企業・スタートアップへの示唆
大企業に比べてセキュリティ専任体制が手薄な中小企業こそ、LLMアプリ導入時のリスク設計を外部フレームワーク（OWASP LLM・IPA）に基づいて体系化しておくことが重要だと思います。 ガイドライン第4.0版の「自社診断」ツールを起点に、LLM固有のリスク観点を追加する形で自社のセキュリティ要件チェックリストを整備してみるのが、現実的な第一歩ではないでしょうか。
セキュリティレベルを「リスクに応じて」段階化する
セキュリティ要件を考えるとき、個人的にいつも感じるトレードオフがあります。 がっちり固めれば固めるほど、開発者から見ると扱いづらくなる——入力の検証が厳しすぎてデバッグしにくい、プロンプトのカスタマイズ幅が狭くてユースケースに対応できない、といった「開発のしづらさ」が生まれてくるのが正直なところです。
セキュリティと開発体験はトレードオフの関係にあると思っています。 どちらか一方を取るのではなく、そのアプリが何を守るべきか・どこまで許容できるかを起点に、必要な部分にだけ必要なレベルのセキュリティを当てていくことが、長く運用できる設計につながるのではないでしょうか。
すべてのLLMアプリに同じ水準のセキュリティ要件を求めることは現実的ではないと思います。 利用シナリオと扱う情報の機密度をもとに要件レベルを段階化する、というのが私なりの現実解です。
🔴 高リスク（厳格な要件が必要）
利用例：人事・給与・財務・調達などの機密性の高い業務データと連携するLLMチャット、RAGで社内機密ドキュメントを参照するアプリ、外部APIやプラグインと連携するLLMエージェント
要件例：
- System Promptの暗号化管理・外部公開禁止
- 入力・出力に対するDLP（情報漏洩防止）チェックの実装
- RAG用ベクトルDBへのアクセス制限・プライベートネットワーク分離
- エージェントの権限を最小化し、実行ログを全件取得
🟡 中リスク（標準的な要件）
利用例：社内ドキュメント・FAQ支援（機密情報を含まない前提）、限定ユーザー向け社内チャットツール
要件例：
- プロンプトテンプレートの固定化（ユーザー入力をそのままSystem Promptに挿入しない）
- 出力のフォーマット制限・サニタイズ
- APIレート制限・最大トークン数の設定
🟢 低リスク（最低限の要件）
利用例：公開デモ・ToC向けチャット（学習データのみ公開）
要件例：
- LLM01（プロンプトインジェクション）の最低限対策
- LLM04（モデルDoS）のレート制限
- 出力のバリデーション（LLM02）
クラウド環境での「セキュリティレベル強化」具体例
クラウドで生成AI・LLMアプリを運用する場合、以下のような技術的対策でOWASPの各リスクに対応できます。
| OWASPリスク | クラウドでの対策例 |
|---|---|
| LLM01: プロンプトインジェクション | APIゲートウェイで入力フィルタリング、プロンプトテンプレートをシークレット管理に格納 |
| LLM02: 不安全な出力処理 | 出力をJSONスキーマで型固定、DB保存前にサニタイズ処理を挟む |
| LLM04: モデルDoS | APIゲートウェイでレート制限・最大トークン設定、クラウドのコスト予算アラートを設定 |
| LLM05: サプライチェーン | OSS・プラグインの依存関係を定期スキャン（pip-audit / npm audit をCIに組み込み） |
| LLM06: 機密情報漏洩 | LLM呼び出し前にPII検出・仮名化処理、出力ログのマスキング |
| LLM07: System Prompt漏洩 | System Promptをシークレット管理ツールで管理、APIレスポンスにSystem Promptを含めない |
| LLM08: ベクトルDB脆弱性 | ベクトルDBをプライベートネットワーク内に配置、IAMロールで最小権限アクセス制御 |
| LLM09: エージェント権限 | エージェントのロールを最小権限に限定、ツール実行ごとに監査ログを取得 |
今すぐ「要件定義書」に追加すべき観点
現在使っている「セキュリティ要件定義書」に、以下のLLM固有セクションを追加することをお勧めしたいと思います。
【生成AI・LLMアプリケーション 追加セキュリティ要件】 1. プロンプト制御 - ユーザー入力をSystem Promptに直接結合してはならない - プロンプトテンプレートはコードリポジトリに平文保存しない 2. 出力処理 - LLMの出力はスキーマバリデーション後に後続処理に渡す - DB・ファイルへの書き込みにLLM出力を直接使用しない 3. データ保護 - LLMに渡す入力データにPII・機密情報を含む場合は仮名化/マスキングを必須とする - RAGデータソースへのアクセスはロールベース制御（RBAC）を適用する 4. リソース制御 - APIレート制限・最大トークン数・コスト上限アラートを設定する - LLMエージェントのツール実行権限を最小化する 5. 依存関係管理 - LLM SDK・プラグイン・RAGソースの脆弱性スキャンをCIパイプラインに組み込む - 外部AIサービスの利用規約・データ処理ポリシーを事前確認する 6. バックアップ・事業継続 - RAGデータソース・ベクトルDB・推論ログのバックアップ設計を行う（IPA 6か条準拠） - AIサービス障害時のフォールバック手順を定義する
まとめ：IPA 2026 × OWASP LLM × 中小企業ガイドラインv4 = 「現代の最低ライン」
- IPA「情報セキュリティ10大脅威 2026」 は、AIが攻撃側でも利用される時代を明確に示していると思います。ただ、LLMアプリ設計の具体要件まではカバーしきれていません。
- IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」（2026年3月） は、サプライチェーン対策強化とバックアップを新たに明示しました。OWASP LLM05・LLM08と接続できる観点が含まれていると感じています。
- OWASP Top 10 for LLM Applications 2025 は、LLMアプリのリスクを体系化した、事実上の設計チェックリストとして活用できると思います。
- セキュリティ要件定義書に「LLM固有セクション」を追加し、利用シナリオのリスクレベルに応じた段階的な要件を明示することが、今の現場に求められていると私は考えています。
生成AIは「便利なツール」と同時に「新しい攻撃面」でもあります。従来の要件定義に「AI時代のアップデート」を加えることが、今すぐ取り組める現実的な第一歩です。
参考リソース
- OWASP Top 10 for LLM Applications 2025
- IPA 情報セキュリティ10大脅威 2026
- IPA 中小企業の情報セキュリティ対策ガイドライン 第4.0版
- 東京都 中小企業サイバーセキュリティ関連ニュースクリップ
ACS 事業部のご紹介
私の所属する ACS 事業部では、開発者ポータル Backstage、Azure AI Service などを活用し、Platform Engineering ＋ AI の推進・内製化を支援しています。
www.ap-com.co.jp www.ap-com.co.jp www.ap-com.co.jp
また、GitHub パートナーとしてお客様に GitHub ソリューションの導入支援を行っています。 GitHub Copilot などのトレーニングなども行っておりますので、ご興味を持っていただけましたらぜひお声がけいただけますと幸いです。
一緒に働いていただける仲間も募集中です！ ご興味持っていただけましたらぜひお声がけください。 ※求人名の冒頭に【ACSD】と入っている求人が当事業部の求人です。
