🧩 この記事でわかること

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セキュリティ支援サービス