Task 外部検索に渡すクエリに個人情報が混ざらないようにする

[vesperworks]

背景

ユーザーの発話は回答を組み立てる過程でいくつかの外部サービスへ渡っているメインの LLM はプライバシーポリシーで開示済みの委託先だがWeb 検索まわりは経路が別でクエリの中身を確認する仕組みが今のところ入っていない

普段のやりとりで問題になることはまずないが利用者が個人情報を含む相談を送ってきたときにその内容が検索クエリの一部として外部へ出る余地が残っている実害が出ているわけではないものの気付いたうちに塞いでおきたい

現状の経路

経路 渡るもの 現状のガード

メイン LLM 会話全文 プラポリで開示済みの委託先
Google Custom Searchserver/src/mastra/tools/google-search-tool.ts:89 LLM が生成した検索クエリ なし
Gemini グラウンディング検索server/src/mastra/agents/web-researcher-agent.ts:45 Gemini が生成したクエリで検索実行 なし
Gemini EmbeddingRAG 検索時のクエリ埋め込み 質問文そのもの なし委託先は同じ Google
Sentry エラーオブジェクトと threadId のみ 発話本文は乗せない設計のため問題なし

エージェントの instructions を見ても検索クエリに個人情報を含めない趣旨の指示は入っていないLINE でも Web 検索系のサブエージェントが有効になっているserver/src/mastra/agents/nepp-chan-agent.ts:274-281

なお MCPserver/src/mastra/mcp/playwright-mcp.tsはどこからも import されていないためMCP 経由の経路は現状ない

対応案

1. ツール実行層でクエリを検査本命

検索ツールの execute 内でクエリを軽量 LLM に通して個人情報の有無を判定し検知したらマスクするか検索を止める外部送信の直前という確実な位置で止められるただしグラウンディング検索はクエリ生成が Gemini 内部で完結するため同じ手が使えず委譲プロンプト側の検査が別途必要になる

2. instructions 強化 委譲入口の検査

メインと web-researcher の instructions に個人情報を検索クエリや委譲文に含めない旨を明記するあわせて Web 検索系への委譲テキストを検査する実装コストが小さくすぐ入れられる一方instructions だけでは保証にならない

3. 入力全体の前段ゲート

パイプライン投入前に全入力を判定する網羅性は高いが全リクエストにレイテンシとコストが乗る個人情報を含む相談自体は受けたいという要件とも衝突しやすい

進め方

2 を先に入れて当面をしのぎつつ1 を本命として実装する

完了条件

• 検索クエリに個人情報が含まれる場合外部へ送信される前で止まる

[owk-owk130]

ナレッジ HIL の作業（#1120）で PII 検出を実際に使ったので、この Issue の判断材料になる部分を書いておきます。

Mastra に PII 検出が入っている

PIIDetector が @mastra/core/processors から export されています。core 1.52.1 に同梱なので新規依存はゼロです。

検出種別は name address phone email date-of-birth credit-card ssn api-key ip-address url uuid 等。戦略は block / warn / filter / redact、伏せ方は mask / hash / remove / placeholder から選べます。

エージェント側の組み込み口は inputProcessors / outputProcessors で、エージェント定義に detector インスタンスを渡すだけです。対応案 3（入力全体の前段ゲート）の実装コストは想定よりかなり小さいと思います。

コストの実測見込み

processInput の実装を読むと、検出は全種別が LLM 判定になります。正規表現（PII_PATTERNS）が使われるのは processOutputStream だけです。

processInput        → detectPII（LLM のみ）
processOutputStream → detectPIILocal（正規表現） + LLM バッファリング

つまり対応案 3 は 1 ターンあたり LLM 呼び出しが 1 回増えるという見積りになります。gpt-5.6-luna + effort low で回せるので単価は低いですが、チャットの応答前に直列で入るためレイテンシがそのまま乗ります。

裏を返すと、正規表現の形式に縛られないので日本の電話番号（090-1234-5678 や 01656-5-3311）も LLM が見て判断できます。北米形式の正規表現しか無い、という制約は processInput には当てはまりません。

実装するときの注意

strategy: "redact" に素通りのパスがあります。

// handleDetectedPII
case "redact":
  if (result.redacted_content) {
    return this.createRedactedMessage(message, result.redacted_content);
  } else {
    console.warn(`[PIIDetector] No redaction available, filtering: ...`);
    return null;
  }

// processInput
} else if (this.strategy === "redact") {
  if (processedMessage) {
    processedMessages.push(processedMessage);
  } else {
    processedMessages.push(message);   // ← 原文がそのまま通る
  }

LLM が「PII がある」と判定したのに redacted_content を返せなかった場合、warn ログだけ出て原文が通ります。返り値は成功扱いなので呼び出し側から区別できません。

外部送信の直前で止めるゲートとして使うなら、redact を信用せず block にするか、伏せた結果を自前で検証する必要があります。

もう 1 点、redact は LLM が返すテキスト全体の書き直しを採用します。オフセット指定ではなく全文置換なので、モデルが無関係な部分を言い換える余地があります。検索クエリのような短い文字列なら影響は小さいはずですが、意図した検索が壊れていないかは確認したいところです。

検出設定の置き場所

#1120 で server/src/lib/pii.ts を追加しました。

piiDetectorConfig()   // 検出種別・model・strategy
redactPii(texts)      // 文字列配列を伏せて同じ順序で返す

この Issue の対応案 1（ツール実行層でクエリを検査）は redactPii をそのまま呼べます。対応案 3 は piiDetectorConfig() をエージェント定義に渡す形になります。どちらも検出種別を再宣言せずに済むので、経路ごとに保護範囲がずれるのを防げます。

グラウンディング検索の扱いは変わらない

Gemini グラウンディング検索はクエリ生成が Gemini 内部で完結するため、ツール実行層では掴めません。この Issue に書かれているとおり委譲プロンプト側の検査が別途必要で、そこは PIIDetector を入れても解決しません。