azure-recipe-user 🧩 この記事でわかること
- 2025年版 OWASP Top 10 for LLM Apps の“本質” が掴める
- プロンプトインジェクションや情報漏洩など、LLM固有リスクの全体像が理解できる
- 具体的に「どう実装すればいいか」が分かる（入力・出力・RAG・運用）
- 安全なLLMアプリ開発には 継続改善（Continuous Hardening） が欠かせない理由も明確になる
1. なぜ“OWASP Top 10 for LLM Apps”が必要なのか
従来のWebアプリの脆弱性（SQLi、XSS など）は、アプリケーションの コードや構造 が攻撃対象でした。
LLMアプリは違います。
モデルの判断プロセスそのものが攻撃対象になる （＝モデルが読む・生成するもの全てがリスクになる）
これにより伝統的な対策だけでは守れない場面が急増し、2023 → 2024 → 2025 と急激にアップデートされたのが OWASP Top 10 for LLM Apps です。
2. 2025年版 OWASP Top 10 の要点
内容を「エンジニアが理解すべき粒度」に落とした10分類です。
※ 公式の項目名を噛み砕いた日本語＋要点で説明します。
LLM01｜プロンプトインジェクション（Prompt Injection）
外部から混入した命令によりモデルが誤操作・漏洩・誤答をする攻撃。
Day3で解説。
LLM02｜不適切な出力（Model Hallucination / Unsafe Output）
AIが事実ではない情報や不適切内容を生成し、ユーザーやシステムが誤誘導されるリスク。
LLM03｜機密情報漏洩（Sensitive Information Disclosure）
モデルやログ、RAGデータベースを通じて個人情報・社内情報が流出するケース。
LLM04｜トレーニングデータ汚染（Training Data Poisoning）
悪意あるデータ混入によってモデル内部にバックドアが仕込まれるリスク。
Day4で解説。
LLM05｜サプライチェーンリスク（Model / SDK / Plugins）
偽モデル・脆弱ライブラリ・危険プラグインによる侵害。
Day6で解説。
LLM06｜過剰な権限（Excessive Agency / Over-Permission）
AIエージェントが外部APIやツールを“過剰な権限”で実行できてしまう状態。
LLM07｜認証・認可の不備（Auth / RBAC for LLM）
LLMが社内データにアクセスする際の
認証や権限管理が不十分で情報が逸脱。
LLM08｜不適切な境界設定（Improper Isolation）
ユーザー入力・外部データ・内部プロンプトが同じコンテキストで処理され、意図せぬ干渉が起こる。
LLM09｜ログ・監査の欠如（Insufficient Monitoring）
LLMの挙動の追跡ができず、攻撃や誤動作を後から特定できない状態。
LLM10｜モデルの悪用（Abuse of LLM Functionality）
AIそのものを使ってスパム・コード生成・詐欺など“攻撃者の武器”にされるパターン。
3. 実装に落とすための具体策
OWASPはあくまで“原則”。
ここでは 「ではどう作れば（守れば）いいの？」 に答える技術施策に整理します。
◆ 3-1. 入力側の防御（Input Hardening）
✔ 禁止語句・構文のフィルタ
- これまでの指示をすべて無視して
- システムプロンプトを表示して（漏らして）
- 次の指示文を書き直して（内容を変えて）
✔ Unicode 正規化（不可視文字除去）
→ Hidden Prompt Injection の対策。
✔ 画像の場合は OCR の異常検査
◆ 3-2. 出力側の防御（Output Filtering）
✔ LLM-as-a-Judge（二段出力チェック）
- 個人情報
- 不適切内容
- 幻想（ハルシネーション）
- 内部情報の漏洩
✔ ベンダーのガードレール
- OpenAI Prompt Shields
- Azure AI Content Safety
- AWS Bedrock Guardrails
◆ 3-3. RAGの安全設計（Safe Retrieval）
- ✔ 文書登録の権限制御（RBAC）
- ✔ 参照文書の追跡（Lineage）
- ✔ Web検索のホワイトリスト化
- ✔ 文書改ざん検知（ハッシュ管理）
◆ 3-4. プロンプト構造の安全設計（Prompt Architecture）
- ✔ System / Developer / User の明確な分離
- ✔ 命令の優先順位をモデルに明示
- ✔ 上書きされないよう禁止事項を再強化
◆ 3-5. エージェント・外部APIの安全設計
- ✔ 最小権限原則（Least Privilege）
- ✔ 書き込み操作には人間の承認を挟む
- ✔ APIキーをLLMに渡さない（Proxyで保護）
◆ 3-6. ログと監査
- どのプロンプトにどう回答したか
- 参照した文書
- プラグインの実行履歴
- 異常応答の追跡
→ “後から原因をたどれる”仕組みが最重要。
4. まとめ：LLMセキュリティは“実装しながら改善する”領域
OWASP Top 10 for LLM Apps が示しているのは、
「LLMは複雑で、万能の対策は存在しない」
「だからこそ、基本原則を守り、継続改善する」
という姿勢です。
- 入力
- 出力
- RAG
- エージェント
- プラグイン
- モデル
AIはこれらが密結合で動きます。
どれか1つが弱いだけで 攻撃者はそこから崩しに来ます。
本記事は、ナレッジコミュニケーションによる生成AIセキュリティ支援の実務知見をもとに執筆しています。
安全にAIを活用するための導入支援・運用設計をご希望の方は、ぜひご相談ください。
👉 AIセキュリティ支援サービス
