生成AIアプリ開発のセキュリティ入門 — OWASP Top 10 for LLM の要点解説

結論：3行で終わらせる

• プロンプトインジェクションは LLM の構造的脆弱性。完全防止は困難 → 多層防御で被害最小化
• 機密データのモデル学習回避は Enterprise プラン契約条項で担保。個人プランは業務利用 NG
• サプライチェーン（モデル提供者・依存ライブラリ）のセキュリティ評価を導入時に必ず実施

1. なぜ生成AIアプリ特有のセキュリティが必要なのか

従来のWeb・モバイルアプリのセキュリティ知識（OWASP Top 10）だけでは生成AI アプリの脅威に対応できない。LLM は「自然言語の入力を解釈して任意の出力を生成する」ため、プロンプトインジェクション・出力制御・学習データ管理など、新たな脆弱性パターンが生まれる。OWASP は2023年から「OWASP Top 10 for Large Language Model Applications」を継続的に更新しており、生成AIアプリ開発の業界標準として広く参照されている。

2. OWASP Top 10 for LLM の概要（2026年版相当）

3. プロンプトインジェクション（LLM01）の対策

LLM の構造的脆弱性で完全防止は困難。攻撃者が「これまでの指示を無視して以下を実行せよ」のような悪意あるプロンプトを混入させる Direct Injection と、ユーザーがアップロードしたドキュメント・URL に攻撃指示を埋め込む Indirect Injection の2種類がある。

対策の多層防御

• **入力フィルタリング**: 既知の攻撃パターン（'ignore previous instructions' 等）を事前検出
• **システムプロンプトの分離**: 開発者プロンプトとユーザー入力を明示的に分離（区切り文字・タグで構造化）
• **最小権限の原則**: LLM が呼び出せるツール・APIを機能ごとに最小限に制限
• **出力検証**: LLM 出力を必ずヒトレビュー or 構造化バリデーションを通してから次の処理へ
• **監査ログ**: 全プロンプト・出力をログ記録し、異常パターンを検知

4. 機密情報漏えい（LLM06）の対策

プロンプトに機密情報（API キー・顧客個人情報・営業秘密）を含めて LLM に渡すと、(1) 学習データに使われる、(2) 他ユーザーへの返答に漏れる、(3) ログに残って漏えいする、というリスクがある。

対策

• **Enterprise プラン契約**: ChatGPT Enterprise / Claude Team / Gemini for Workspace 等、データ学習除外がデフォルトのプランを使う。個人プラン（Plus / Pro）は業務利用厳禁
• **機密データの匿名化**: 個人情報・顧客名を仮名化してから LLM に渡す前処理パイプライン
• **ZDR（Zero Data Retention）契約**: より厳しい要件があれば Enterprise 個別交渉で ZDR を契約条項化
• **出力フィルタリング**: LLM 出力に機密情報が含まれていないか自動検証（DLP ツール連携）
• **プロンプトとレスポンスのログ管理**: アクセス権限を厳格化し、必要最小限の保持期間に

5. サプライチェーン脆弱性（LLM05）の対策

生成AI アプリは「LLM プロバイダー」「ベクトル DB」「埋め込みモデル」「依存ライブラリ（LangChain / LlamaIndex 等）」のサプライチェーン上に成立する。各層の脆弱性が自社アプリに伝播するリスクがある。

対策

• **LLM プロバイダーの SOC2・ISMS 確認**: 利用する LLM API 提供元のセキュリティ認証を契約前に確認
• **依存ライブラリの脆弱性スキャン**: pip-audit / npm audit / Snyk / Dependabot で継続監視
• **モデル選択の慎重化**: Hugging Face 等の OSS モデル利用時、ライセンス・学習データ・配布元の信頼性を評価
• **プラグイン・ツール統合の最小化**: LLM が呼び出す外部 API は本当に必要なものだけに絞る
• **インフラ層のセキュリティ**: API ゲートウェイ・WAF・レート制限を必ず設置

6. 過剰な権限付与（LLM08）の対策

AI エージェント（LangChain Agents / Function Calling 等）に「メール送信」「データベース更新」「外部 API 呼出」等の権限を与えすぎると、プロンプトインジェクションと組み合わさって甚大な被害が発生する。

対策

• **Read-only 優先**: 可能な限り「データ取得」のみを LLM に許可、書き込み・削除はヒト承認を経る設計
• **ヒトインザループ（HITL）**: 重要な操作（金銭取引・データ削除・外部送信）は必ずヒト承認のステップを挟む
• **Sandbox 実行**: コード生成 → 実行を許可する場合、必ず隔離環境（Docker / VM）で実行
• **操作ログ + 監査**: AI が実行した全操作をログ化し、異常検知を組む

7. 過度な依存（LLM09）の対策

「AI が言ったから正しい」と人間がチェックを怠ると、ハルシネーション・偏見・誤情報がそのまま業務に反映されるリスクがある。特に医療・法務・金融の意思決定では致命的。

対策

• **HITL ワークフロー**: AI 出力を「下書き」と位置づけ、必ずヒトレビューを経て公開・実行する設計
• **信頼度スコア併記**: LLM 出力に「信頼度」「出典」を併記する仕組みで、ヒトが判断材料を持てるように
• **業務 KPI モニタリング**: AI 導入後の精度・誤りを継続監視し、問題発生時にロールバックできる体制
• **社員教育**: AI 出力の限界（ハルシネーション・偏見）について全社研修を実施

8. セキュアな生成AI アプリ開発の標準フロー

• **1. 脅威モデリング**: OWASP Top 10 for LLM をチェックリストとして、自社アプリの想定脅威を整理
• **2. データ分類**: 扱うデータの機密度（公開・社内・機密・極秘）を分類し、LLM に渡せる範囲を明文化
• **3. アーキテクチャ設計**: 多層防御（入力フィルタ・システムプロンプト分離・出力検証・監査ログ）を組み込む
• **4. ベンダー選定**: LLM プロバイダー・依存ライブラリの SOC2・脆弱性履歴を評価
• **5. テスト**: Red Team によるプロンプトインジェクション攻撃テストを実施
• **6. 運用監視**: 異常パターン検知・ログ分析・継続的なセキュリティパッチ適用

編集部の助言: 「生成AI アプリのセキュリティ」は従来Webアプリより新しい領域で、ベストプラクティスが日々進化している。OWASP・各 LLM プロバイダーの公式セキュリティドキュメント・業界カンファレンス（Black Hat / DEF CON 等）を継続フォローすること。

Q. OWASP Top 10 for LLM はどこで確認できますか？

A. OWASP 公式（owasp.org/www-project-top-10-for-large-language-model-applications/）。日本語訳もコミュニティで公開されている。年1〜2回更新されるため、最新版を継続フォロー。

Q. プロンプトインジェクションを完全防止できますか？

A. 現状の技術では完全防止は困難。「多層防御で被害を最小化する」が現実解。入力フィルタ・出力検証・最小権限の3点を必ず組み込むこと。

Q. 個人プラン（ChatGPT Plus 等）を業務に使うのはダメですか？

A. 原則 NG。Plus / Pro は学習除外がデフォルトでない・契約上の保護条項がない・監査ログがない、という3点で業務利用に向かない。社員が個人プランを業務で使うのを禁止する社内規定が必要。

Q. ヒトインザループ（HITL）はどこまで必要？

A. 業務影響度で判断。「公開コンテンツ・金銭取引・データ削除・外部送信」は必ず HITL。「内部下書き・要約・分類」は HITL 不要のケースもあるが、ログ監査は最低限必要。

Q. セキュリティ監査はどう実施する？

A. (1) 脅威モデリングを設計時に実施、(2) 開発中は静的解析・依存ライブラリスキャン、(3) リリース前に Red Team でプロンプトインジェクション攻撃テスト、(4) 運用後は継続的なログ分析と異常検知。CI/CD パイプラインに組み込むのが現実的。

まとめ

生成AI アプリのセキュリティは「LLM 特有の脆弱性 + 従来Webアプリのセキュリティ」の二層対応が必要。OWASP Top 10 for LLM をチェックリストにして、プロンプトインジェクション・機密漏えい・サプライチェーン脆弱性・過剰権限・過度な依存の各項目に多層防御を組むこと。

完全防止は困難な領域なので、被害最小化と検知・対応の体制構築が現実解。Enterprise プラン契約・HITL ワークフロー・継続的なセキュリティ監査の3点を必ず組み込み、業界の最新ベストプラクティスをフォローし続けることが重要。