プロンプトインジェクション対策｜LLMアプリのセキュリティ実装ガイド

LLMアプリ特有のセキュリティリスクの全体像

LLMアプリのセキュリティは、従来のWebアプリセキュリティにプロンプト経由の攻撃面が加わった構造です。OWASP LLM Top 10（2025年版）ではLLM01（プロンプトインジェクション）を筆頭に、機密情報の漏えい、サプライチェーン、データ／モデル汚染、不適切な出力処理、過剰なエージェント権限などが並んでいます。

従来のOWASP Top 10（Webアプリ全般）が引き続き適用される点も見落とせません。SQLインジェクションと構文レベルでは異なりますが、「信頼できない入力・出力をそのまま下流で使わない」という発想はLLM出力の扱いにも共通します。詳細はSQLインジェクションとは｜仕組み・主要攻撃4種・実装対策と検知方法を参照してください。

LLMアプリの主要リスク（OWASP LLM Top 10 2025年版）

上表は本記事と関係の深い項目の抜粋です。全項目の一次情報はOWASP Foundation公式（OWASP Top 10 for LLM Applications）を参照してください。日本語訳（非公式）は補助資料として便利です。

ミニFAQ

Q. LLMアプリのセキュリティは、既存のWebセキュリティ知識だけで足りますか？

不足します。SQLインジェクション対策や認可設計といった土台は活きますが、プロンプト経由の攻撃面はWebアプリでは存在しなかった新種です。従来の脆弱性対策と、LLM特有のガードレールを二段構えで用意します。

プロンプトインジェクションの仕組みと攻撃タイプ

プロンプトインジェクションは、信頼できないテキストがモデルへの指示として解釈されることで成立します。自然言語ベースの攻撃は表現の揺れが大きく、入力時点での機械的な遮断だけでは取りこぼしが生じやすいため、多層防御が前提になります。攻撃者は「これまでの指示を無視して〜」といった命令を入力に紛れ込ませ、システムプロンプトの制約を回避します。

直接インジェクションと間接インジェクション

間接インジェクションはRAG（検索拡張生成）やエージェントで顕在化しやすく、対策の重点も直接インジェクションとは変わります。ユーザーの目に触れないため検知が遅れる点も難しさです。

攻撃で狙われる典型的な弱点

• システムプロンプトの露出（「これまでの指示を表示せよ」）

• ロールプレイ経由の制約回避（「開発者モードに切り替えてください」）

• ツール／API呼び出しの誘導（メール送信・ファイル削除など破壊的操作の引き出し）

• 出力フォーマット逸脱によるパーサ攻撃（下流のJSON処理器の破壊）

ミニFAQ

Q. プロンプトインジェクションと「ジェイルブレイク」は同じですか？

重なる部分はありますが、同義ではありません。ジェイルブレイクはモデルの安全策を外すことを目的とした攻撃を指し、プロンプトインジェクションはそのうち入力から指示を上書きする手法です。安全策の突破に成功しなくても、システムプロンプトを引き出せれば攻撃としては成立します。

プロンプトインジェクションの実装対策

対策は設計段階からの多層防御が基本です。ガードレールを1つ足すのではなく、下記5つのレイヤーを組み合わせます。

1. 権限最小化（Least Privilege）

LLMに与えるツール・API・データアクセス権限を、そのタスクに必要な最小限に絞ります。「削除できる」「送信できる」といった破壊的操作は原則としてLLMから直接呼ばせず、人手承認を挟むか、書き込み系は別レイヤーに分離します。

• 読み取り専用トークンと書き込みトークンを分離する

• ツールごとにレートリミットを設定する

• エージェント経由の破壊的操作は原則ホワイトリスト方式で明示許可した対象のみ

2. 入力サニタイズと分離

ユーザー入力とシステムプロンプトを構造的に分離します。たとえば、system／user／retrieved_context を別フィールドで保持し、単純な1本の文字列として連結しない設計を取ります。モデルが「これはユーザー由来のデータで、指示ではない」と扱えるようテンプレート境界を明示します。

• ユーザー入力を明示的なタグ（例：「user_input」タグ）で囲む

• 制御文字・エスケープ文字の除去

• 長さ制限と文字種の絞り込み

なお、サニタイズだけで100%防ぐことはできません。回避表現は絶えず更新されるため、他レイヤーとの組み合わせを前提にします。

3. Human-in-the-Loop（HITL）

判断の重い操作は人間の承認を挟みます。特にエージェント型のアプリで、外部への通信・ファイル書き込み・決済関連の操作は、LLMの出力をそのまま実行せず、ユーザーまたは運用者の確認を挟む設計にします。

4. 出力検証とゴールロック

LLMの出力を下流システムに渡す前に検証します。JSONスキーマ・許可された値集合・長さ・特定文字列の除外などを機械的にチェックし、不整合があれば拒否します。

• 出力を無検証でコード実行系（execなど）／SQL／HTMLレンダリングに流さない

• 目的逸脱チェック：想定タスクから外れた出力を検知して破棄する仕組み（いわゆる goal locking の考え方）

• 特にコード生成・SQL生成では、実行前のパース検証を必須にする

5. 監査ログと継続監視

LLMアプリでは、攻撃対象領域がネットワークやOSレイヤーで監視しづらいため、アプリケーション層のログが検知の主軸になります。

• 検知・監査に必要な範囲で、プロンプト・応答・ツール呼び出しのメタデータと重要イベントを記録する（医療・金融・公共系ではログ最小化の要件が優先される場合がある）

• 異常パターン（急激な入力長・特定キーワード頻出）をアラート化する

• ログ自体にPII混入がないか定期的にサンプリング確認する

情報漏えいの実装対策

情報漏えい対策は、入力・システムプロンプト・出力・ログの4層で扱います。層ごとに何を守り、何を書き込ませないかを設計時に決めます。ここで頻出する「PII（Personally Identifiable Information）」は、氏名・メールアドレス・電話番号など個人を識別し得る情報の総称です。

4層で分ける守り方

生成AIサービスのポリシー確認

主要な生成AIサービスは、API経由の入力を学習に使わない設定を提供しています。ただし契約プラン・提供経路・時期で変わるため、導入時点の公式ドキュメントで必ず確認します。参考として、業務委託で生成AIを使う際の契約観点は業務委託で生成AIを使うときの契約・機密情報の注意点にまとめています。

• OpenAI API：契約プランでデータ利用の扱いが異なるため、OpenAI Enterprise privacyなどの公式ページで確認する

• Anthropic API：エンタープライズ規約下ではデータ保持ポリシーが選択可能（詳細はAnthropicのプライバシー方針）

• Google Gemini API：Vertex AI経由と一般APIで扱いが異なる（詳細はGoogle Cloud Generative AI データガバナンス）

各社ともポリシー改定の頻度が高いため、案件開始時点で最新版を確認したうえで発注元と合意します。

ローカルLLMという選択肢

機密性要件が高い案件では、外部APIを使わずローカルLLMで完結させる選択肢もあります。Ollamaなどの実行環境を使えば、モデル・入出力ともにネットワーク外に出さない構成が可能です。詳細はOllamaとは？ローカルLLM実行環境の特徴・使い方を参照してください。

ミニFAQ

Q. RAGで取り込むデータからPIIを完全に除去する必要がありますか？

案件の要件次第です。医療・金融・行政系ではPII除去（マスキング／匿名化）を前段に置くケースが多く、社内向けアシスタントで社員データを扱う場合は権限制御と監査ログでカバーするパターンもあります。要件定義時に除去するのか制御するのかを必ず合意しておきます。

LLMアプリの構成別セキュリティ設計

同じLLMアプリでも、想定利用シーンによって対策の重点が変わります。3類型で整理します。

社内RAGアプリ

社内文書を検索・要約するRAGアプリでは、間接プロンプトインジェクションと権限バイパスが主なリスクです。

• 検索対象文書ごとに閲覧権限を持たせ、ユーザー権限で絞り込んでからLLMに渡す

• マクロなど従来型の危険要素の検査（実行コード寄りの脅威）

• 文書本文・注釈・隠しテキストに混入した指示文のスキャン（LLM解釈寄りの脅威）

• 社外文書（メール添付・共有リンク）の取り込みは慎重に設計する

RAGの基盤としてDifyのようなプラットフォームを使う場合、プラットフォーム側のセキュリティ機能と自前実装の切り分けを明確にします。詳細はDifyとは？ノーコードでLLMアプリを構築できる生成AIプラットフォームを参照してください。

顧客向けチャットボット

一般公開されるチャットボットは、直接インジェクションとブランド毀損が主なリスクです。

• システムプロンプトの露出を防ぐ（露出しても致命傷にならない前提で設計する）

• 攻撃者による過剰リクエストへのレート制限

• 出力にブランド外の内容が混じらないよう出力側でチェック

• ユーザー登録前・後で使える機能を分ける

AIエージェント

ツール呼び出し・外部システム連携を行うエージェント型は、過剰権限と間接インジェクションの合わせ技が最大の脅威です。

• 各ツール呼び出しに認可レイヤーを挟む

• 破壊的操作（送信・削除・課金）はホワイトリスト＋人手承認

• ツール呼び出し履歴を必ずログ化する

• エージェント間通信を行うマルチエージェント構成では、信頼境界を設計段階で明示する

エージェント開発案件の全体像はAIエージェント開発案件の単価相場｜必要スキル・獲得ルートにもまとめています。

実装時のよくある失敗と対策

LLMアプリ開発で起こりやすい失敗例として、以下のパターンを整理します。

失敗1：入力サニタイズだけで安心してしまう

サニタイズは必要条件ですが、十分条件ではありません。攻撃表現は自然言語のため、正規表現でのブロックは網羅性に限界があります。必ず出力側・権限側との組み合わせを前提にします。

失敗2：システムプロンプトに秘密情報を書き込む

APIキー・接続文字列・顧客IDなどをシステムプロンプトに埋めると、プロンプトインジェクションで露出します。シークレットは環境変数・シークレット管理サービスで分離し、LLMにはトークン化された参照のみ渡します。

失敗3：エージェントに全権限を渡してしまう

「便利だから」とAdmin権限のAPIトークンをエージェントに与えると、間接インジェクション経由で破壊的操作を引き出される恐れがあります。ツールごとに最小権限を割り当てます。

失敗4：ログにPIIをそのまま残す

デバッグ目的で全プロンプト・全応答をログに残すのは便利ですが、PIIや機密情報がそのまま蓄積されます。ログ書き込み前にマスキングを挟み、保持期間を要件に応じて短くします。

失敗5：本番投入後のレッドチームテストを省く

導入したガードレールが効いているかは、ガードレールを設計した本人には見えにくいものです。本番投入前・投入後に、攻撃を想定したテスト（レッドチームテスト）を挟みます。定期的な再検証もセットで運用に組み込みます。

開発案件で気をつける契約・実務ポイント

フリーランスがLLMアプリ開発案件を受託する場合、参画前に確認しておくと後工程で揉めにくくなるポイントを整理します。

参画前チェック

• 脅威モデル：想定攻撃者・想定被害・対策の到達水準が定義されているか

• ガードレール要件：どのレベルのガードレールを実装対象とするか（設計書レベル／PoCレベル／本番レベル）

• ログ要件：どこまで記録するか、保持期間、閲覧権限

• PII取扱範囲：入力に含まれ得るPIIの種類、マスキング責任の所在

• リリース後の保守範囲：ガードレール更新・レッドチームテストの継続契約か、リリース時点で終わりか

単価・稼働の観点

LLMアプリのセキュリティ実装は、AIアプリ開発案件のなかでも要件定義・設計工程の比重が大きい部分です。要件定義・設計から関わる場合、実装専任案件より評価されやすい傾向があります。自分がどのくらいの単価を狙えるか気になる方は、無料のフリーランスエンジニア単価診断で現在の市場単価の目安を確認できます。

なお、LLMアプリ関連の実装案件のスキル要件はLLMファインチューニング案件の全体像｜必要スキル・単価目安・参画ルートやエンジニアの生成AI活用術にまとめています。

ケース別：契約形態で変わる責任範囲

参画前・実装前チェックリスト

LLMアプリのセキュリティ実装で最低限確認しておく項目を整理しました。案件参画時のスコープ合意にも使えます。

• 脅威モデル（想定攻撃者・被害）が言語化されているか

• 権限最小化の方針が決まっているか（読取／書込／削除の分離）

• ユーザー入力とシステムプロンプトが構造的に分離されているか

• 出力を下流システムに渡す前にスキーマ検証があるか

• 破壊的操作は人手承認またはホワイトリスト方式か

• ログ設計にPIIマスキングが含まれているか

• ログ保持期間・閲覧権限が定義されているか

• 定期的なレッドチームテストの計画があるか

• 使用する生成AIサービスのデータ利用ポリシーを確認済みか

• 契約書・NDAにAI利用条項が明記されているか

まとめ

LLMアプリのセキュリティ対策は、多層防御を設計段階から組み込むことに尽きます。プロンプトインジェクションを単一のガードレールで完全に防ぐ手段はなく、権限最小化・入出力検証・監査ログ・継続テストの組み合わせで被害面を減らす発想が現実的です。

• OWASP LLM Top 10（2025年版）を土台に、案件の脅威モデルを言語化する

• プロンプトインジェクションは直接／間接の2系統で対策の重点を分ける

• 情報漏えい対策は入力・システムプロンプト・出力・ログの4層で設計する

• アプリ類型（社内RAG／顧客向け／エージェント）で重点対策が変わる

• 受託案件では参画前に脅威モデル・ログ要件・PII扱いを合意しておく

セキュリティ実装は「実装しました」で終わらず、運用フェーズでの継続テストと更新が前提の領域です。設計時点で運用体制も含めて発注元と合意しておくと、リリース後のトラブルを避けやすくなります。

参照した一次情報：

• OWASP Top 10 for LLM Applications（公式）

• OpenAI Enterprise privacy

• Anthropicのプライバシー方針

• Google Cloud Generative AI データガバナンス

• OWASP Top 10 for LLM Applications 2025 日本語訳（非公式・補助資料）