OWASP Top 10 for LLM Applications 2025 を実務目線で読み解く

生成AIを組み込んだアプリケーションでは、従来のWebアプリケーションとは違う種類のリスクが生まれます。OWASPの「Gen AI Security Project」が公開している OWASP Top 10 for LLM Applications は、そうしたリスクを10項目にまとめた、いまや業界の共通語ともいえる資料です。

本記事では2025年版の10項目を、「現場で何をすべきか」 という観点で整理します。

なぜLLMアプリには独自のリスク整理が必要なのか

LLMアプリの難しさは、命令（コード）とデータ（入力文章）の境界があいまいなところにあります。SQLインジェクションはプレースホルダを使えば構造的に防げますが、LLMは自然言語で書かれた入力すべてを「指示になりうるもの」として扱います。

さらにRAG（検索拡張生成）やツール呼び出しを持つAIエージェントでは、外部のWebページ・メール・ドキュメントがそのままモデルに渡ります。攻撃面がアプリの外側にまで広がるのです。

10項目の全体像

ID	リスク	ひとことで言うと
LLM01	Prompt Injection	入力でモデルの振る舞いを乗っ取られる
LLM02	Sensitive Information Disclosure	機密情報・個人情報が出力から漏れる
LLM03	Supply Chain	モデル・データセット・ライブラリ経由で汚染される
LLM04	Data and Model Poisoning	学習データや追加学習でモデルを歪められる
LLM05	Improper Output Handling	出力を検証せずに下流の処理へ渡してしまう
LLM06	Excessive Agency	エージェントに必要以上の権限・自律性を与えてしまう
LLM07	System Prompt Leakage	システムプロンプトとそこに含まれる情報が漏れる
LLM08	Vector and Embedding Weaknesses	RAGのベクトルDB・埋め込みまわりの弱点
LLM09	Misinformation	もっともらしい誤情報（ハルシネーション）を信じてしまう
LLM10	Unbounded Consumption	リソースを使い尽くされる、コストを膨らまされる

2023年版と比べると、LLM07（システムプロンプトの漏えい） と LLM08（ベクトル・埋め込みの弱点） が新たに加わりました。また「過剰な代理権（Excessive Agency）」の比重が大きくなっています。RAGとAIエージェントが広く使われるようになった現状を映した改訂といえます。

開発・運用チームが押さえるべきポイント

1. プロンプトインジェクションは「防ぎきれない」前提で設計する（LLM01）

プロンプトインジェクションには、ユーザーが直接仕掛ける直接型と、Webページや文書に埋め込まれた指示をモデルが読み込んでしまう間接型があります。入力フィルタやプロンプトの工夫で完全に防ぐ方法は、現時点ではありません。

だからこそ、乗っ取られても被害が限られる設計が要になります。

• モデルの出力を「信頼できない入力」として扱う
• 重要な操作（送金、外部へのメール送信、データ削除など）の前に人の承認を入れる
• 信頼できない外部コンテンツを読んだ後は、使えるツールを絞る

2. 出力は必ず検証してから使う（LLM05）

LLMの出力をそのままHTMLとして描画する、シェルコマンドやSQLとして実行する――。こうした実装は、XSSやコマンドインジェクションの入口になります。出力にも、通常の外部入力と同じエスケープ・検証・サンドボックス化をかけるのが原則です。

3. エージェントの権限は最小にする（LLM06）

AIエージェントに付与するツール・API・権限は、次の3つの軸で見直します。

1. 機能：そのツールは本当に必要か（「何でもできる汎用シェル」を渡していないか）
2. 権限：読み取りだけで済むのに書き込み権限を渡していないか
3. 自律性：影響の大きい操作を人の確認なしで実行できる状態になっていないか

4. システムプロンプトに秘密を書かない（LLM07）

システムプロンプトはいつか漏れるものと考えます。APIキー、内部URL、権限判定のロジックなどをシステムプロンプトに書いて「隠したつもり」になるのは危険です。認可の判断はモデルの外側、つまりアプリケーション側で行いましょう。

5. RAGのデータにもアクセス制御を（LLM02 / LLM08）

社内文書をベクトルDBに入れると、元の文書についていた閲覧権限が失われがちです。検索の段階で利用者の権限に応じたフィルタをかけないと、本来見られない文書の内容が回答に混じります。また、検索対象に悪意ある文書が紛れ込むと、間接プロンプトインジェクションの温床にもなります。

6. コストとリソースの上限を決める（LLM10）

トークン数、リクエスト数、エージェントのループ回数、1ユーザーあたりの利用額に上限を設けます。大量のリクエストでコストを膨らませる攻撃（いわゆる「Denial of Wallet」）や、モデルの出力を大量に集めて模倣モデルを作る行為への備えにもなります。

まずやるべきチェックリスト

• 自社のLLMアプリが「どの外部データを読み込み」「どのツールを呼べるか」を棚卸ししたか
• LLMの出力をHTML・SQL・コマンドへ渡す箇所で、エスケープや検証をしているか
• 影響の大きい操作に、人の承認ステップを入れているか
• システムプロンプトに秘密情報が含まれていないか
• RAGの検索結果に、利用者の権限によるフィルタをかけているか
• 利用量・コスト・ループ回数に上限を設けているか
• プロンプトと応答のログを、プライバシーに配慮しつつ監査できる形で残しているか

まとめ

OWASP Top 10 for LLM Applicationsは、チェックリストとして使えるだけでなく、チーム内でリスクを話すときの共通語としても役に立ちます。特に、プロンプトインジェクションは完全には防げない前提に立ち、権限の最小化と出力の検証で被害を限定するという考え方は、AIエージェント時代の設計の土台になります。

まずは自社のLLMアプリの構成図を描き、10項目それぞれについて「どこで起こりうるか」を書き込むところから始めてみてください。