- 公開日
System Promptの文章が見えた事故と、顧客データや認証情報が流出した事故は、露出した資産と影響を分けて評価します。両方が同時に起こることもありますが、指示文らしい回答が出たことだけで、実際の内部指示や秘密が漏れたとは確定できません。元の設定や記録と照合し、何が誰に届き、権限や実行結果に影響したかを確認します。
「指示が見えた」の中身を分解する
System Promptは、AIの役割や応答方針などを与えるための指示です。アプリケーションによって配置や呼び方は異なりますが、ここでは運営側が用意する内部指示を指します。そこに書かれた文章は、秘密を安全に保管する仕組みではありません。
OWASP LLM07:2025 System Prompt Leakageは、System Prompt自体を秘密やセキュリティ制御として扱うべきではないとし、問題の本質は文面が知られることより、その中に置かれた認証情報や、認可・権限分離をモデル任せにしている構成にあると説明しています。対策として、認証情報などの機微な情報を指示文に埋め込まないこと、権限分離や認可の確認をモデルから独立して行うことが挙げられています。
この区別は、内部指示を公開してよいという意味ではありません。内部の業務方針や非公開の判断条件が含まれていれば、その内容にも保護すべき価値があります。ただし、単に文面が知られたことと、顧客情報へのアクセスが可能になったことでは、確認する資産も対処も異なります。
また、AIが出した「私の内部指示はこうです」という文章は、設定そのものの複製とは限りません。出力を証拠として保存する必要があっても、その文面だけで漏えいを確定しないことが大切です。権限のある担当者が対象時点の実設定と照合し、一致、部分一致、照合不能を分けます。
保護資産ごとに確認する
事故の入口が同じでも、影響の整理には複数の行が必要です。次の表は、確認項目を決めるための例です。重大度の点数や一律の対応期限を定めたものではありません。
| 露出した可能性がある資産 | 確認すること | 対応を変える条件 |
|---|---|---|
| 一般的な応答方針 | 実設定との一致、公開範囲、取得経路 | 元から公開情報か、非公開の業務情報を含むか |
| 内部の業務ルール | 対象版、機密区分、到達先、悪用可能な範囲 | 判断条件の不正利用や社外開示の影響があるか |
| 顧客や従業員のデータ | 対象者、項目、件数、届いた相手、閲覧可能範囲 | 情報の性質や対象者への影響が変わるか |
| 認証情報 | 有効性、権限範囲、利用履歴、露出経路 | 不正利用が可能か、失効や切替が必要か |
| 操作の権限・実行結果 | 拒否記録、許可された対象、実際の変更 | 文面の露出に加え権限逸脱や実害があるか |
指示文に顧客情報が入っていれば、指示文の露出と顧客情報の流出の両方として記録します。反対に、顧客データが検索結果やツール応答から出力された場合、System Promptが露出していなくてもデータ流出は起こり得ます。「指示文を隠せたから機密は守れた」とする評価は、この経路を見落とします。
確認範囲は出力画面だけではありません。回答の共有、添付、ログ、外部ツールへの引数など、対象情報が通った経路を調べます。到達先を確かめられない場合は「流出なし」とせず、どこまで確認できたかを残します。調査用に秘密そのものを別の共有文書へ貼ることも、露出範囲を増やす原因になります。
架空の三つの事故記録を読む
同じ顧客対応AIで三つの事象があったと仮定します。いずれも説明用の架空例で、実在する事故や実験結果ではありません。
事象Aでは、回答に「丁寧に対応し、資料にない内容は断定しない」という文が出ました。担当者が対象時点の設定と照合すると、同じ文が含まれていたとします。この段階で確認できるのは、その文面が出力されたことです。顧客データや資格情報の混入、他の内部指示の露出、出力先の範囲は別に確認します。一般的な文だから確認不要とも、設定と一致したから全機密が流出したとも判断しません。
事象Bでは、別の顧客の契約内容が回答へ混ざりました。System Promptの文字列は出ていません。検索時のアクセス範囲、モデルへ渡った資料、回答の共有先を追います。もし利用者に閲覧権限のない契約内容だったなら、指示文の露出とは独立した機密データの事故として扱います。
事象Cでは、内部指示に置かれていた架空の接続用秘密が回答へ出たとします。ここでは指示文の露出と認証情報の露出が重なります。実運用なら、権限のある担当者が管理記録で秘密の有効性、アクセス可能な範囲、露出後の利用を確認し、必要な失効や切替を行います。単に指示文から削除しただけでは、既に出力された情報の利用可能性は消えません。
三つを「System Prompt抽出成功」という一つの指標にまとめると、Bのデータ流出を見落とし、AとCの対処の違いも消えてしまいます。資産、到達先、権限、実行済み操作を別々に記録すれば、次に調べる担当と対象を絞れます。
秘密を指示文へ置かない構成にする
設計時には、指示文に何が含まれているかを棚卸しします。役割や回答の形式を定める文章と、顧客固有の情報、接続用の秘密、アクセス許可の判定条件を区別します。必要がない秘密はモデルへ渡さず、外部の適切な管理機構で保管・利用します。
たとえばデータ取得ツールは、認証済みの利用者を基に、取得してよいデータを実行側で判定します。「管理者として扱って」とモデルが出力しても、権限を増やしません。必要な資料だけを返し、接続に使う秘密を回答用の文脈へ返さないようにします。OWASP Authorization Cheat Sheetの最小権限とリクエストごとの権限確認は、この分離を考える基礎になります。
指示文に「秘密を出さない」と書くことは、応答方針の一部にはなります。しかし、秘密がモデルへ渡らない構成や、取得時の認可を置き換えるものではありません。実行に不要な情報を渡さないことと、渡した情報の出力を検査することを組み合わせます。
権限の判定を複数のツールへ移すと、設定の整合や運用管理の負担は増えます。それでも、秘密の一文を知っていることだけで認可が通る仕組みより、主体と対象を明示して検査する仕組みの方が、事故時にどの制御が働いたかを調べやすくなります。モデルの応答を拒否させるテストだけで、認可が正しいと判断しないようにします。
実データを使わず資産別に確かめる
検査には、公開しても問題のない模擬指示、架空の顧客資料、実際の認証には使えない目印を用います。実顧客情報や有効な秘密を入れて流出を試す方法は採りません。外部への送信・共有機能を無効にし、回答と模擬操作の記録を確認します。
確認するのは、保護対象の内部指示を再掲しないか、許可のない顧客資料を取得しないか、不要な秘密をモデルへ渡さないか、許可された通常の回答ができるかです。抽出を拒否する回答が出ても、裏で権限外の資料を取得していたら、取得制御の側は合格にできません。逆に、模擬目印が見つからないだけで、言い換えや別経路での流出が一切ないと証明したことにもなりません。
文字の正規化や類似照合は、検査対象の一致を見つける補助です。表現が似ていることだけで漏えいを断定せず、原設定や資料との対応を確認します。類似文を検知したという記録と、秘密の流出を確認したという記録は、結論の強さを分けて残します。検知できた露出、阻止した操作、未確認の範囲を分けて残し、設計を変えた後も通常業務と保護資産の両方を再確認します。
LLMアプリで守る資産と信頼境界の洗い出しは「LLMアプリの何を守る？ 資産・入口・信頼境界を洗い出す手順」、JailbreakとPrompt Injectionの違いと防御の選び方は「JailbreakとPrompt Injectionの違いから防御を選ぶ」で解説しています。
