システムプロンプト漏えいは防げるか｜生成AIサービスの秘密情報と認可設計

AWSは2026年7月8日、AWS Security Blogで「Designing for the inevitable: System prompt leakage and mitigations in generative AI applications」と題する記事を公開しました。同記事は、生成AIアプリケーションのシステムプロンプトは完全には漏えいを防げないという前提に立ち、秘密情報をプロンプトに置かない設計や、認可制御をモデルの外側で行う仕組みを解説しています。これは一企業による技術解説であり、法令、行政のガイドライン又は業界標準ではありません。本稿では、AWSが示した技術的な整理を紹介した上で、システムプロンプトに秘密情報や個人情報を書き込むことの法的なリスク、営業秘密としての保護の限界、AIサービス提供者及び委託先ベンダーとの契約での手当てを、企業法務の視点から整理します。

AWSが示した設計原則、漏えいを前提とする防御

AWSは、システムプロンプトの漏えいそのものを根絶することはできないという前提に立ち、漏えいしても被害が生じない設計と、漏えいの試みを検知して対応する仕組みを組み合わせるよう説明しています。設計面では、APIキー、データベースの接続情報、認証情報その他の秘密情報をシステムプロンプトに含めないこと、内部のAPIエンドポイントやSQL文といった不要な詳細を書き込まないことを挙げています。認可の実装についても、アクセス制御をシステムプロンプトの指示によって強制するのではなく、Amazon CognitoやIAM、Verified Permissionsのような、モデルの外側にある決定的な仕組みで行うべきだとしています。

検知の仕組みとしては、Amazon Bedrock Guardrailsのプロンプト攻撃フィルターによる漏えい試行の検出、システムプロンプトに埋め込んだ固有の文字列がモデルの応答に含まれていないかを確認する「カナリートークン」、応答のスキーマや数値範囲を検証するレスポンス検証、システムプロンプトと応答の類似度を比較する検知手法、不可視文字や全角文字による回避を防ぐUnicode正規化を紹介しています。複数の層を重ねる考え方であり、単一の対策で足りるという説明ではありません。

システムプロンプトの漏えいを完全に防げない理由

AWSは、「絶対に明かさない」という趣旨の指示をシステムプロンプトに書き込むだけでは防御として機能せず、単発の要求だけでなく、複数のやり取りを重ねて少しずつ情報を引き出す手法によって回避され得ると説明しています。同記事は、現在の生成AI技術における根本的な限界であるため、完全な修復手段は現時点で存在しないと明言しています。

同様の整理は、生成AIアプリケーションのセキュリティリスクを整理したOWASP Gen AI Security ProjectのLLM Top 10 for LLM Applications 2025にも見られます。同資料はLLM07「System Prompt Leakage」の項目で、システムプロンプトを秘密として扱うべきではなく、セキュリティ制御として利用すべきでもないと整理しています。いずれも技術的なベストプラクティスを示す資料であり、日本法上の義務を定めたものではありません。

システムプロンプトと秘密情報の法的整理

システムプロンプトに営業秘密に当たる情報を書き込む場合、不正競争防止法第2条第6項の営業秘密の要件との関係を確認する必要があります。同項は、秘密として管理されていること、事業活動に有用な情報であること、公然と知られていないことの3要件を満たす情報を営業秘密と定義しています。システムプロンプトがプロンプト注入によって第三者に引き出され得る状態にあるまま秘密情報を格納していた場合、秘密管理性の要件を満たすための具体的なアクセス制限や管理体制が備わっていたと評価されるかが問題になり得ると考えられます。実際に漏えいが生じた事案では、非公知性そのものが失われる可能性もあります。

個人情報についても同様の視点が必要です。顧客の氏名や取引内容など実在する個人データをシステムプロンプトの例示や参照情報として書き込み、その内容が外部のAIモデル提供事業者へ送信される場合、個人情報保護法上の委託又は第三者提供の整理に沿った対応が必要になります。プロンプト経由で個人データを外部送信していることに気づかないまま運用しているケースは、棚卸しの対象として確認する価値があります。エージェント型AIにどこまでの情報アクセスと実行権限を与えるかを事前に決めておく視点は、AIエージェントを法務業務に入れる前に決めるべきことでも扱っています。

契約による手当て、AI提供者の利用規約とベンダー契約

技術的な対策だけでは、秘密情報や個人情報がシステムプロンプトに残っている状態そのものは解消されません。自社が利用するAIモデル提供事業者との契約では、入力したプロンプトを学習に利用するかどうか、保存期間及び保存場所、漏えいを検知した場合の通知義務、Guardrailsに相当するセキュリティ機能の提供有無を確認しておくことが望ましいと考えます。ベンダーへの確認項目の立て方はAIベンダーデューデリジェンスと契約審査で整理しています。

自社が生成AIサービスを提供する側である場合には、利用規約においてシステムプロンプトの内容を自社の非公開情報として扱う旨や、プロンプト抽出を試みる行為を禁止事項として明記しているかを確認する必要があります。あわせて、利用者からNDAで受領した秘密情報をシステムプロンプトへ組み込む運用を認めるかどうかは、社内の生成AI利用ポリシーで整理しておく事項です。ポリシー整備の考え方は生成AI利用ポリシーの作り方を参照してください。

企業が翌日から確認する事項

AWSが示した技術対策は開発部門が実装する事項ですが、法務担当者が確認すべき事項は次のとおりです。

• 自社が提供・利用する生成AIサービスのシステムプロンプトに、APIキーや接続情報、実在する顧客の個人データ、営業秘密に当たる社内情報が書き込まれていないかを棚卸しする
• 利用しているAIモデル提供事業者の利用規約及びデータ処理条項で、入力プロンプトの学習利用の有無と保存期間を確認する
• 自社の生成AIサービスの利用規約に、システムプロンプトの秘密性及びプロンプト抽出行為の禁止を定めているかを確認する
• システムプロンプトの漏えいを検知した場合の社内報告フローと、個人情報が含まれていた場合の対応要否の判断基準を整理する

漏えいが発生したときの検知記録や対応履歴をどこまで残し、誰が確認するかという運用設計は、AIエージェントのログ監査と責任分界のチェックポイントで扱っている論点と重なります。システムプロンプトを秘密保持の境界として扱わないという技術的な前提を踏まえ、秘密情報と個人情報の保護は、契約と社内運用の側で担う設計に切り替えることが実務上の出発点になると考えられます。