OWASP Top 10 for LLM Applications を読み解く

LLM アプリケーションの開発・運用が急速に広がる一方で、包括的なセキュリティのベストプラクティスはまだ浸透しきっていません。

OWASP Top 10 for Large Language Model Applications は、その溝を埋めるために公開されたレポートです。一般的なアプリケーションセキュリティの原則と、LLM 特有の課題との間にあるギャップを整理してくれます。

ここでは10項目それぞれについて、実際のアプリケーションでどう現れるかと 何から手を付けるかという観点で見ていきます。

LLM01: プロンプトインジェクション

1位は順当にこれです。不正なプロンプトを入力し、LLM に意図しない動作をさせる攻撃です。

レポートでは2つに分類されています。

直接（ダイレクト） — 攻撃者がシステムプロンプトを上書き・暴露する。ジェイルブレイクとも呼ばれます
間接（インダイレクト） — 攻撃者が制御できる外部ソース（Webページ、ファイル等）に指示を仕込み、LLM にそれを読ませる

危険度が跳ね上がるのは、プロンプトがデータストアやバックエンドに接続されている構成です。この場合、不正アクセスや権限昇格が成立し得ます。

対策の優先順位

バックエンドへの権限制御。LLM 用のトークンを分離し、最小権限を付与する
削除など取り消せない操作には、ユーザーの明示的な承認を必須にする
信頼できないコンテンツをそのままプロンプトに混ぜない

入力フィルタリング（ブラックリスト、トピック判定など）も併用できますが、これらは補助的な層です。権限制御を省略する理由にはなりません。

LLM02: 安全でない出力処理

LLM の出力を検証せずに、そのまま関数・シェル・SQL・HTML に渡してしまう問題です。

自然言語で問い合わせてデータを引ける体験は魅力的ですが、プロンプトでモデルを制御できる以上、出力は信頼できない入力として扱う必要があります。 LLM の出力を eval に渡せば、それは実質的に任意コード実行です。

対策は従来どおりで、出力先に応じたバリデーションとエスケープ、そして実行権限の分離です。

LLM03: 学習データの汚染（Training Data Poisoning）

学習データやファインチューニング用データに悪意あるデータを混入させ、モデルの挙動そのものを歪める攻撃です。

厄介なのは、実行時には痕跡が見えないことです。データの出所の検証、取り込みパイプラインの管理、学習後の挙動テストが対策になります。

LLM04: モデルへの DoS

計算コストの高いリクエストを大量に送りつけ、サービスを利用不能にしたり、コストを意図的に膨張させる攻撃です。 LLM は1リクエストあたりの単価が高いため、金銭的な攻撃としても成立します。

レート制限、入力長の上限、ユーザーごとのコスト上限が基本です。

LLM05: サプライチェーンの脆弱性

事前学習済みモデル、データセット、プラグイン、ライブラリ。 LLM アプリは外部依存の塊です。どこから来たモデルなのか、改ざんされていないかを検証できる体制が必要になります。

従来のソフトウェアサプライチェーン対策と考え方は同じですが、 モデルとデータセットも対象に含める点が新しいところです。

LLM06: 機密情報の開示

モデルが学習データに含まれる機密情報を出力してしまう問題です。社内データで学習させたモデルが、意図しない利用者に内部情報を答えてしまう、という形で現れます。

学習データからの機密情報の除去・マスキング、出力フィルタ、そして「そもそもそのデータを学習させる必要があるか」の見直しが必要です。

LLM07: 安全でないプラグイン設計

プラグインが入力を十分に検証せず、過大な権限で動作している場合に発生します。プラグインは LLM とバックエンドの境界線であり、ここが緩いと LLM01 や LLM02 がそのまま実害につながります。

パラメータの型と範囲を厳密に定義し、プラグインごとに権限を絞ってください。

LLM08: 過剰なエージェンシー（Excessive Agency）

LLM に与える権限・機能・自律性が過剰な状態です。「メールを読む」ために与えた権限で「メールを送れる」ようになっていないか。エージェント構成では特に重要な観点になります。

機能は必要最小限に。影響の大きい操作には人間の承認を挟む。

LLM09: 過度の信頼（Overreliance）

出力を検証せずに受け入れる運用そのものがリスクである、という項目です。技術的な脆弱性ではなくプロセスの問題であり、だからこそ見落とされます。

モデルの出力には不確実性があることを前提に、重要な判断には人間のレビューを組み込んでください。

LLM10: モデルの盗難

独自モデルの重みや、API を通じた大量クエリによる挙動の複製（モデル抽出）です。知的財産の保護という観点に加え、盗まれたモデルは攻撃者がオフラインで攻撃手法を試せる環境にもなります。

アクセス制御、レート制限、異常なクエリパターンの監視が対策です。

まとめ

10項目を通して見ると、半分は従来のアプリケーションセキュリティの応用です。権限の最小化、入力と出力の検証、依存関係の管理 — ここは変わりません。

一方で、プロンプトインジェクション、学習データの汚染、過剰なエージェンシーは、 LLM 固有の考え方を必要とします。特に「出力を信頼できない入力として扱う」という原則は、既存の設計思想からの発想の転換が要ります。

まずは自分たちのアプリが10項目のどこに該当するかを棚卸しするところからです。