プロンプトインジェクションだけでは足りない｜OWASP LLM Top 10で押さえる生成AIの実装セキュリティ

生成AIのセキュリティは「プロンプトインジェクション」だけではない

生成AIのセキュリティ対策はプロンプトインジェクションだけでは完結しません。機密漏えい・過剰なエージェント権限・出力処理・RAGのベクトルDBなど、固有のリスクは多岐にわたります。本記事ではOWASP LLM Top 10（2025年版）を起点に、10のリスクを5つの設計系統に再構造化し、設計・実装・レビューに落とし込む方法を解説します。

生成AIをプロダクトや社内業務に組み込む動きが広がるなかで、そのセキュリティ対策として真っ先に語られるのが「プロンプトインジェクション」です。確かにプロンプトインジェクションはLLMアプリ最大級のリスクですが、それだけを塞いでも、生成AIシステムが安全になるわけではありません。

LLMを組み込んだシステムには、従来のWebアプリケーションには存在しなかった固有のリスクが数多くあります。たとえば、モデルが学習データやコンテキストから機密情報を漏らす。LLMの出力をそのまま下流の処理に流して新たな脆弱性を生む。AIエージェントに与えた権限が過剰で、想定外の操作を実行してしまう。RAGで使うベクトルデータベースから、本来見えてはいけないデータが漏れる——これらは、入力対策だけでは決して防げません。

こうした生成AI固有のリスクを体系的に整理したのが、OWASPが公開する「OWASP Top 10 for LLM Applications」です。Webアプリの定番フレームである従来のOWASP Top 10とは別に、LLMアプリ専用のリスクフレームとして整備され、2025年版で内容が刷新されました。

本記事では、OWASP LLM Top 10（2025年版）を起点に、生成AIアプリのリスク10領域を「5つの設計系統」に再構造化し、それぞれの実装対策と設計・レビューへの落とし込み方を解説します。個別の対策を羅列するのではなく、開発の現場で「どこで何を点検すべきか」を判断できる俯瞰フレームの提供を目指します。

OWASP LLM Top 10（2025年版）の全体像

OWASP Top 10 for LLM Applications は、LLMを組み込んだアプリケーションで特に重大な10のリスクをまとめたフレームです。2025年版では、生成AIの実運用が進むなかで顕在化した新しいリスクが追加・再整理されました。まず10項目を俯瞰します。

2025年版で特に注目すべきは、システムプロンプトの漏えい（LLM07）、ベクトル・埋め込みの脆弱性（LLM08）、誤情報（LLM09）が独立した項目として加わった点です。これは、RAGやエージェントといった実運用パターンが普及し、「モデル単体」ではなく「LLMを組み込んだシステム全体」のリスクが重視されるようになったことを反映しています。

10リスクを5つの設計系統に再構造化する

10項目を1つずつ暗記しても、実装には活きません。重要なのは、これらを「システムのどの境界で対処するか」という設計の軸で捉え直すことです。本記事では10リスクを次の5系統に再構造化します。

この5系統は、生成AIシステムの「入力→処理→出力」というデータフローと、それを支える「データ・権限・供給網」という基盤に対応しています。以下、系統ごとに具体的な実装対策を見ていきます。

設計系統①入力系・②出力系 ― 境界での防御

入力系：プロンプトインジェクション（LLM01）とシステムプロンプト漏えい（LLM07）

入力系の核心は、「ユーザーが与える入力」と「開発者が与えるシステムプロンプト」を明確に分離し、前者を信頼しないことです。プロンプトインジェクションは、ユーザー入力（あるいはRAGで取り込む外部文書）にシステムへの指示を紛れ込ませ、本来の挙動を乗っ取る攻撃です。

• ユーザー入力とシステム指示を構造的に分離し、入力を信頼境界の外として扱う
• LLMに渡す前後でガードレール（入力フィルタ・出力チェック）を設ける
• 重要な操作には人間の承認（human-in-the-loop）を挟む
• システムプロンプトに認証情報や権限ロジックを書かない（LLM07）。システムプロンプトは漏れ得る前提で設計し、本当の制御は外部の認可・ガードレールで担保する

なお、プロンプトインジェクション（LLM01）への具体的な実装対策は範囲が広く深いため、本記事では全体像のなかでの位置づけにとどめます。多層防御の詳細は、プロンプトインジェクション対策に特化した記事（記事末尾の関連記事を参照）と併せてご覧ください。本記事はその上位フレームとして、10リスク全体のなかでLLM01をどう位置づけるかを示します。

出力系：不適切な出力処理（LLM05）と誤情報（LLM09）

LLMの出力は「信頼できる処理結果」ではなく「未検証の外部入力」として扱う必要があります。出力をそのままHTMLに描画すればXSS、シェルやSQLに渡せばコマンドインジェクションやSQLインジェクションにつながります（LLM05）。

• LLM出力を下流に渡す際は、用途に応じてエスケープ・サニタイズ・パラメータ化を必ず行う
• 出力にコード実行やシステム操作を伴う場合はサンドボックス化し、権限を限定する
• 誤情報（LLM09）対策として、RAGで出力を根拠ある情報にグラウンディングし、出典を提示する
• コード生成では存在しないパッケージを提案する『パッケージ幻覚』に注意し、依存追加時の検証を運用に組み込む

設計系統③データ・RAG系 ― 学習・参照データの管理

RAGやファインチューニングが一般化したことで、データ層のリスクが大きく浮上しています。この系統は3つのリスクを含みます。

機密情報の漏えい（LLM02）

モデルが学習データ・コンテキスト・RAGの取得結果から機密情報を出力に漏らすリスクです。入力段階での機密のマスキング、データ最小化（必要な情報だけを渡す）、出力フィルタ、そして利用者ごとのアクセス制御を組み合わせて防ぎます。

ベクトル・埋め込みの脆弱性（LLM08）

RAGの基盤となるベクトルデータベースは、権限分離が不十分だと、本来アクセスできないユーザーに他テナント・他部門のデータを返してしまいます。ベクトルDBにもアプリ同様のアクセス制御・テナント分離を適用し、取り込むソースの信頼性を検証することが必要です。埋め込みから元データを推定する攻撃の可能性も考慮します。

データ・モデルのポイズニング（LLM04）

学習・微調整・RAGに使うデータが汚染されると、バックドアやバイアスがモデルに埋め込まれます。データの来歴（provenance）を管理し、取り込み元の信頼性を検証し、想定外のデータ分布を検知する仕組みを設けます。これは次のサプライチェーン系とも密接に関係します。

設計系統④エージェント権限系・⑤サプライチェーン・リソース系

エージェント権限系：過剰なエージェンシー（LLM06）

AIエージェントにツール実行や外部API操作の権限を与えるほど、利便性と同時にリスクが増します。過剰なエージェンシーとは、LLMに与えた機能・権限・自律性が必要以上に大きく、誤動作やインジェクションが実害に直結する状態を指します。

• 機能の最小化：エージェントが呼べるツール・APIを必要最小限に絞る
• 権限の最小化：各ツールに付与する権限を、用途に必要な範囲だけに限定する
• 自律性の最小化：影響の大きい操作（送金・削除・外部送信等）には人間の承認を必須にする
• 全操作をログ化し、事後追跡と異常検知を可能にする

サプライチェーン・リソース系：サプライチェーン（LLM03）と無制限消費（LLM10）

LLM03は、利用するモデル・プラグイン・ライブラリ・データセットの供給網に潜むリスクです。改ざんされたモデルや脆弱な依存関係を取り込めば、システム全体が危険にさらされます。来歴の検証、署名の確認、SBOM（ソフトウェア部品表）による依存管理、信頼できるソースの利用が基本対策です。

LLM10の無制限消費は、入力サイズや呼び出し回数に上限がないことで、サービス拒否（DoS）・コスト暴騰・モデル抽出（繰り返しクエリでモデルの挙動を盗む）を招くリスクです。レート制限・クォータ・入力サイズ制限・コスト監視とアラートを設け、消費に明確な上限を設けます。

開発ライフサイクルへの落とし込み ― そしてまとめ

OWASP LLM Top 10は、リストとして眺めるだけでは機能しません。設計・実装・レビュー・運用の各フェーズで「どこで何を点検するか」に変換して初めて、実装の防御力になります。レビュー観点のチェックリストとして整理します。

フェーズ別チェックリスト

• 【設計】ユーザー入力とシステムプロンプトを分離し、入力を信頼境界の外として扱う設計になっているか（①）
• 【設計】システムプロンプトに機密・権限ロジックを含めず、制御を外部の認可で担保しているか（①）
• 【実装】LLM出力を下流に渡す前にエスケープ・サニタイズ・サンドボックス化しているか（②）
• 【実装】RAGのベクトルDBにアクセス制御・テナント分離が適用されているか（③）
• 【実装】エージェントの機能・権限・自律性が最小化され、重要操作に承認が入るか（④）
• 【調達】モデル・依存・データの来歴と信頼性を検証し、SBOMで管理しているか（⑤）
• 【運用】レート制限・クォータ・コスト監視で消費に上限を設けているか（⑤）
• 【運用】機密のマスキング・出力フィルタ・操作ログ・異常検知が稼働しているか（②③④）

まとめ：OWASP LLM Top 10を実装の言語に変える

• 生成AIのセキュリティはプロンプトインジェクション（LLM01）だけでは完結せず、出力・データ・権限・供給網まで含む10リスクの体系で捉える必要がある
• OWASP LLM Top 10（2025）はシステムプロンプト漏えい・ベクトルの脆弱性・誤情報を新たに重視し、『システム全体』のリスクに焦点を移した
• 10項目は『入力／出力／データ・RAG／エージェント権限／サプライチェーン・リソース』の5設計系統に再構造化すると実装に落としやすい
• 各リスクは独立ではなく連鎖する（インジェクション→過剰権限→実害など）。系統横断で多層防御を設計する
• フレームは設計・実装・レビュー・運用のチェック観点に変換して初めて防御力になる

生成AIのセキュリティは、モデルを選ぶだけでも、ツールを導入するだけでも完結しません。入力から出力、データ、権限、供給網までを一つの設計として捉え、開発プロセスに組み込む取り組みが必要です。OWASP LLM Top 10を「リスクの一覧」から「設計・実装・レビューの言語」へと変換できるかどうかが、生成AIを安全に業務へ実装できる組織とそうでない組織を分けていきます。