プロンプトインジェクションは防げるのか — 入力検査だけでは止まらない理由

AIセキュリティ実務ガイド 編集部

なぜ「防ぎきれない」と言われるのか

プロンプトインジェクションは、LLMに与える入力に指示を紛れ込ませ、開発者が意図しない動作をさせる攻撃です。

SQLインジェクションと名前は似ていますが、対策の難易度が根本的に違います。SQLでは、プレースホルダを使えば「ここはデータであって命令ではない」とデータベースに伝えられます。**LLMにはこの区別がありません。**システムプロンプトも、ユーザーの入力も、読み込んだ文書も、最終的には同じ1本のテキストとしてモデルに渡ります。

そのため「命令として解釈してはいけない部分」を構造的に指定する手段が存在しません。これが、入力検査で止めきれない理由です。

入力検査の限界

多くの実装では、危険そうな語句をフィルタする方式が最初に試されます。しかし次の理由で回避されます。

• 言い換えが無限にある — 「前の指示を無視して」を検知しても、婉曲な表現、別言語、比喩、コード片など経路は無数にあります
• 文字表現で回避できる — 全角・半角、ゼロ幅文字、符号化した文字列など、モデルは読めるがフィルタは通す形にできます
• フィルタを強めると誤検知が増える — セキュリティの記事を要約させるだけで、正当な入力が弾かれるようになります

入力検査は攻撃の手間を上げる効果はあるので無駄ではありませんが、これに依存した設計は成り立ちません。

本当に危ないのは間接的な経路

自社サービスの入力欄から攻撃されるより、AIが自動で読み込む外部データに仕込まれるほうが深刻です。これを間接プロンプトインジェクションと呼びます。

想定される経路は業務システムのいたるところにあります。

• 社外から届いたメールを、AIが要約する
• 取引先から受領した文書ファイルを、AIが読み取る
• Webページを取得して要約する機能
• 社内文書をRAGで検索して回答する仕組み(書き手に悪意がなくても、外部から取り込んだ資料が混ざる)

この場合、**攻撃者は自社のシステムに直接触れる必要がありません。**対象の従業員に読ませる文書を1通送るだけで済みます。

発想を「防ぐ」から「成功しても困らない」へ

止めきれない前提に立つと、設計で決めるべきことが変わります。攻撃が成功したときに何が起きるかを制御するのが主眼になります。

1. 権限を最小にする(最も効果が大きい)

AIエージェントに与える権限が、そのまま攻撃者が得る権限になります。

• 読み取り専用で足りる用途に、書き込み権限を渡さない
• メールを読む権限と、メールを送る権限を分ける
• 全社のファイルではなく、必要な範囲のフォルダに絞る
• 外部への通信先を許可リストで限定する(情報を持ち出す経路を塞ぐ)

「要約するだけのAI」が送信権限を持っていなければ、乗っ取られても情報は外に出ません。

2. 実行の前に人を挟む

取り返しのつかない操作は、AIの判断だけで完了させないようにします。

• 送信、削除、決済、権限変更などは人の承認を経る
• 承認画面にはAIが実行しようとしている内容そのものを表示する(AIによる説明文ではなく)

2つめは見落とされがちです。AIに「何をしようとしているか説明させる」と、その説明自体が攻撃者の制御下にあります。

3. 出力を信用しない

LLMの出力を、後続の処理がそのまま実行しない設計にします。

• 出力をコマンドや問い合わせ文としてそのまま実行しない
• 出力に含まれるURLを自動で取得しない(情報を外部へ送る典型的な経路)
• 画面に出すときは、そのままHTMLとして解釈させない

4. 記録を残す

どの入力に対してAIが何を実行したかを追えるようにします。攻撃が成功した後、影響範囲を特定できるかどうかがインシデント対応の成否を分けます。

ガードレールの位置づけ

入出力を検査するガードレール製品は、上記の設計を前提としたうえで上乗せする層として有効です。単体で信頼できる防御にはなりませんが、既知のパターンを弾き、明らかな異常を検知する役には立ちます。

導入する場合は「これで防げる」ではなく「攻撃の成功率を下げ、検知を早める」ものとして位置づけ、権限設計を省略しないことが重要です。

社内で説明するときの要点

経営や事業部門に説明する際、「完全には防げない」とだけ伝えると導入自体が止まりかねません。次の整理が実務的です。

1. この攻撃はLLMの構造に由来し、製品を変えても消えない
2. したがって、防ぐのではなく影響範囲を限定する設計にする
3. 具体的には、AIに渡す権限を絞り、重要な操作には人の承認を挟む
4. これは新しい考え方ではなく、従来の最小権限の原則をAIに適用しただけ

導入前の確認項目は生成AI導入セキュリティチェックリストに、社内ルールへの落とし込みは生成AIの利用規程に何を書くかにまとめています。

まとめ

• 命令とデータを区別できない構造上の性質が原因で、入力検査では止まりきらない
• 危険なのは直接入力より、AIが自動で読み込む外部データ
• 主眼を「防ぐ」から「成功しても被害が出ない設計」へ移す
• 最も効くのは権限の最小化。渡していない権限は悪用されない
• ガードレールは上乗せの層。権限設計の代わりにはならない