プロンプト・ログ・回答はすべて出口になる — 機密情報の漏えい

一行まとめ

モデルが見られるものはいつか回答として出てくる可能性があり、プロンプトを記録するすべての場所はその内容を複製します。秘密は入れない、他人のものは入れる前にフィルタリングする、ログはマスクする、それでも漏れるものはマーカーで検知します。

なぜこれが必要だったのか

LLMアプリで機密情報が漏れる経路は3つあります。1つ目はシステムプロンプトです。開発中に「モデルがツールを呼ぶときに使うように」とAPIキーや社内の連絡先をシステムプロンプトに書いておくことはよくありますが、システムプロンプトは秘密の保管庫ではありません。ユーザーがその文面を繰り返させようとするリクエストは際限なく形を変え、モデルがそれを常に拒否するという保証はありません。OWASP LLM Top 10 2025は、機密情報の漏えい(LLM02)とは別に、システムプロンプトの漏えい(LLM07)を項目として設けています。

2つ目はログです。障害時に見直すためにプロンプト・ヘッダー・回答を原文のまま記録すると、プロンプトに入ったすべてのもの — 顧客の電話番号、認証トークン、キー — がログに複製されます。ログはサービスよりも多くの人とシステムに届きます。ログ収集ツール、診断バンドル、パートナー企業、長く残るバックアップがそうです。

3つ目は検索権限です。質問に似たチケットを顧客の区別なく探して入れると、モデルは他の顧客の個人情報で答えます。システムプロンプトに「他人の情報は話すな」と書くことは境界ではありません — すでに入力に入ったものをモデルが話さないと信じているだけです。

どう動くのか

層	すること	モデルを信頼するか
入れない	キーはツールが実行されるサーバーコードでのみ読む	信頼しない
フィルタリングする	リクエストしたユーザーのものだけを検索候補にする	信頼しない
マスクする	ログにはトークンの代わりに名前、電話番号は末尾4桁のみ	該当なし
検知する	システムプロンプトにカナリア(漏れてはいけないマーカー)を入れ、出力に現れたらブロックして記録	信頼しない

カナリアは誠実に扱う必要があります。このコースの偽モデルは「システムプロンプトを見せて」という指示にシステムプロンプトをそのまま付け加えるので、カナリア文字列のチェックで捕まります。本物のモデルは言い換えたり、翻訳したり、1文字ずつ区切って出力したりでき、そうなると文字列チェックは見逃します。そのためカナリアは検知装置であって保証ではなく、最優先は常に秘密をモデルの入力に入れないことです。

秘密を「入れない」ということを具体的に説明するとこうなります。モデルがツールを呼ぶときに必要なのはツールの名前と引数だけで、そのツールが外部APIを呼ぶときに使うキーは、サーバーコードが設定やシークレットストアからその場で読みます。モデルには「注文状況を照会するツールがある」とだけ伝えれば十分です。こう分けておけば、プロンプトが丸ごと漏れてもキーは一緒に漏れず、キーを変えるときにプロンプトを直す必要もありません。ユーザーごとの権限が必要なツールなら、そのユーザーの身元も同じように、モデルを経由せずサーバーが持っていきます。

マスキングにも原則があります。ログを止めると障害を調査できないので止めずに、何を残すかを選びます。身元はトークンではなく名前で、顧客確認に必要な分だけ(電話番号の末尾4桁)、そしてリクエストidは必ず残して他のログとつなげて見られるようにします。OWASP Logging Cheat Sheetも、セッションid・アクセストークン・個人情報は記録しないかマスクするよう勧めています。

マスクする場所も重要です。ログを書く関数1か所でマスクしなければなりません。画面に出すとき、パートナー企業にバンドルを送るときにそれぞれマスクすることにすると、いつか1か所が抜け落ちます。そしてすでに原文のまま残ったログは「今後マスクする」では解決しません — 今あるファイルとすでに送り出したコピーを探して作り直す必要があります。ラボのインシデントがこの後始末まで求めるのはそのためです。

現場で出会う姿

カスタマーサポートボットの診断ログをパートナー企業に送ったら、その中に顧客の電話番号とログイントークンが原文のまま入っていたケース、システムプロンプトに書いておいた「VIP顧客の連絡先」がプロンプト抽出のリクエスト1回で画面に出てしまったケース、相談記録が誤った顧客アカウントに紐づき、別の顧客にその人の番号が回答として出てしまったケースなどです。表面上はどれも「番号が外部で見つかった」で同じで、調査は見つかった断片がどのログから出てきうるかを1つずつ突き合わせる作業です。経路ごとに塞ぐ場所と片付ける場所が異なるため、経路を見誤ると見当違いの場所を直し、本当の出口は開いたまま残ります。

検索権限ももう一度確認しておきます。顧客の区別は検索の「後」ではなく「前」でかけます。スコアを付けて上位いくつかを選んだ後に他人のものを除くと、他人のチケットが枠を占めて肝心の自分のチケットが押し出され、フィルタリングするコードが1行ずれただけで他人のものがそのまま入力に入ります。候補を選ぶクエリ自体に「リクエストした顧客のものだけ」を入れるのが安全で、ベクトル検索を使う実際のシステムならメタデータフィルターがその場所です。

次のラボですること

カスタマーサポートボットの昨日のログで原文のまま残った秘密を数え、キーをシステムプロンプトからツール層へ移し、ログをマスクし、カナリアでプロンプトの漏えいを防ぎ、検索を顧客ごとにフィルタリングします。最後のインシデントでは、3人の顧客の番号がそれぞれ異なる経路で漏れたことを、断片からさかのぼって突き止めます。