日常文に潜む悪意のプロンプト検出

自然文に紛れた「命令文」を検出する基本的な考え方と、ローカル環境で安全に再現するための概観を学びます。専門用語（ペイロード＝埋め込まれた実行対象、ゲートキーパー＝前段の簡易検査、ターゲットモデル＝命令を最終的に解釈する高度モデル）は初出でやさしく説明します。実操作はInteractive Labで行い、ここでは目的・構成・評価基準を整理します。

前提と準備（機材・安全ルール）

使う機器

• 操作用PC（検証端末）：Terminalとテキスト編集、Python実行ができる端末。screening.pyやtarget_simulator.pyを実行するために使う。
• ネットワーク隔離装置（スイッチ/ファイアウォール）：検証中に外部通信を遮断するための物理または仮想的な装置。ローカル実行を保証する用途。
• USBメモリ（テスト入力保存用）：検証用テキスト（wrapperファイル）を移動・バックアップするために使う。

Labでは機器は充電・給電済みです。必要なSDカードも挿入済みとし、カードの挿抜や書込みそのものを練習する場合だけ操作に含めます。

安全ルール

• すべて自分の所有端末・検証用データのみで実施すること。
• 外部APIやクラウドへ送信しない（ネットワークを物理的に切るかファイアウォールで遮断）。
• ペイロードは必ず無害（画面出力のみ等）に限定すること。
• 実機の重要ファイルや機密データを使わないこと。

機材がなくても、この記事のInteractive Labで設定手順と結果の見方を練習できます。実機の通信ではなく、この記事に対応した教材用シミュレーションです。

この記事で何がわかるかと主要用語の説明

何を学ぶかを端的に示します。PuzzleMask的なラッパー（自然文に命令を隠す手法）を概念的に理解し、前段の軽量検査（ゲートキーパー）と後段の高度な解釈（ターゲットモデル）における盲点を再現・評価する方法を学びます。

用語（初出で定義）

• ペイロード：文章の中に隠された「実際に実行させたい命令」。
• ゲートキーパー（gatekeeper）：入力を素早く判定する前段の検査処理。簡易ルールや正規表現で動作する想定です。
• ターゲットモデル：最終的に応答や行動を生成する、より能力の高い後段モデルの模擬。ここではローカルの模擬スクリプトで再現します。
• パラフレーズ：元の文章を別表現に書き換え、埋め込まれた命令構造を壊す処理。

用語は以後この意味で使います。

今回やることと教材シミュレーションの範囲（概要）

本記事のBriefingでは、検証の目的・構成図・検証範囲を示します。Interactive Labで実際の操作手順（コマンド実行、ファイル観察）を行います。ここでは手順の全体像だけを示し、細かいクリック順や逐次コマンドはLabへ移します。

構成（簡易）: 操作用PC（Terminal）→ screening.py（ゲートキーパー）→ target_simulator.py（模擬ターゲット）

教材シミュレーションの対応範囲:

• テキスト入力の検査・変換・ログ保存までをローカルで模擬します。
• 実際の外部サービス呼び出し、ファイルシステムの重要領域変更、ネットワーク送信は行いません。
• 実機なしで練習する場合、文字列の検出率やログの読み方は確認できますが、実運用のレイテンシやスケールの動作は再現範囲外です。

重要: Labを開始する前に必ずネットワークが遮断（オフライン）であることを確認してください。Labはここで示した範囲内の操作のみ実行します。

Interactive Lab

ここまでで理解した仕組みを、機材不要の仮想Labで実際に操作して確かめます。最初に資料を読み、操作・調査・問題へ進みます。実機ではなく教材用のシミュレーションです。

記事の内容をもとにした仮想教材です。操作し、表示された結果を確認してください。

Lab Debrief

Labで操作した重要ポイントを、あなた自身の記録から振り返ります。Labを作り直した場合、この解説も新しいLabの記録へ自動で追従します。

スクリーニング設計の基本（ルール設計とログ）

検出ルールの目的は高リスクの命令を前段でブロックし、許可される入力のみを後段に渡すことです。設計の基本方針を示します。

• 単語ベースのブラックリストだけでなく、自己参照句（例: "the following sentence instructs you"）やコマンド構造を検出するルールを組み合わせる。
• パラフレーズ処理を前段に入れると、ラッパーの依存する語順を壊せる場合があるが、誤検知増加のトレードオフがある。
• 必須のログ: 原文、スクリーニング判定、判定理由、後段へ渡した（または破棄した）内容の記録。高影響アクションはヒューマン承認を要求する設計にする。

設計のポイントを守ることで、盲点を減らせます。具体的なルール追加やログ形式の例はLabで実践します。

簡易スクリーニングと模擬ターゲットの操作イメージ（コマンド例）

以下は操作イメージ（例）。これらのコマンドは操作用PCのTerminalで実行します。各コマンドについて「入力先」「目的」「読むところ」を示します。実際の細かい手順はInteractive Labで行ってください。

コマンド例:

# 入力: wrapper1.txt（ラッパー文章）
# 目的: screening.py が前段判定を行い、結果を screened.json と screening.log に出力する
python3 screening.py wrapper1.txt --output screened.json --log screening.log

# 入力: screened.json（screeningが通した/変換した内容）
# 目的: target_simulator.py が模擬ターゲットとして応答を生成し target_out.txt に保存する
python3 target_simulator.py screened.json --out target_out.txt

読むところ（観察ポイント）:

• screening.log: 判定結果（safe/blocked）と判定理由（どのルールにマッチしたか）。
• screened.json: 前段で変換・修正されたテキスト。後段へ渡した実際の入力をここで確認。
• target_out.txt: 模擬ターゲットの応答。ペイロードが復元されて実行的な出力になっていないかを確認する。

コマンドは操作用PC／Terminalで実行し、出力はTerminal標準出力と上記ログファイルを確認してください。ファイルの所在（パス）とログのタイムスタンプを読むことが重要です。

出力の見方と評価指標

観察する主要項目と評価の考え方を示します。数値の目標値は環境依存なので、ここでは指標の定義だけを示します。

• 検出率: 実験セット内でゲートキーパーがペイロードを検出（blockedと判断）した割合。実測値はLabで得られます。
• 誤検知率（false positive）: 無害入力を誤ってブロックした割合。業務影響とバランスを取る必要があります。
• 復元事例: ゲートキーパーがsafeと判定した入力に対して、ターゲットが命令的な応答を生成したケースのログ（screened.json と target_out.txt を突き合わせる）。

ログの読み方（短く）: まずscreening.logで判定と理由を確認し、次にscreened.jsonの実際の渡し先テキストを読み、最後にtarget_out.txtの生成物でペイロードの痕跡があるかを確認します。

注: 実測値や検出率はモデル・ルールセット・テストデータに依存します。具体的な数値は実機で計測してください。

実運用への移行で注意すべき点

ローカル検証から実運用へ移すときの代表的な注意点を列挙します。

• モデル差: 異なるターゲットモデルやバージョンでは挙動が変わるため、再評価が必要です。
• パフォーマンスと誤検知: 厳しいルールは誤検知を増やす。業務影響を評価し、しきい値をチューニングする。
• 権限管理: 出力による高影響操作（ファイル書換、外部送信）は必ず別プロセス／ヒューマン承認を経由させる。
• 監査と復旧: ログ保存方針、アラート条件、ログ保全手順を整備する。異常時に即座にサービスを切れる手段を用意する。

これらは技術的対策だけでなく運用設計（ワークフロー）を含めて検討する必要があります。

まとめと次のステップ（実験案）

まとめ: 前段の軽量スクリーニングと後段の模擬ターゲットの能力差が盲点を生む点を確認しました。防御は(1) 入力のパラフレーズ化や自己参照検出、(2) 権限最小化、(3) ロギングとヒューマン承認の組合せが有効です。

次の実験案（Labで実施）:

• 自己参照句を追加したルールの有効性を3種類のラッパーで比較する。
• パラフレーズ処理を挟んだ場合の検出率と誤検知率のトレードオフを測る。
• ログから復元事例を抽出し、どのルールが効いていないかを特定する。

参考: 実測データや外部サービスへの適用性は環境依存です。Labで得た結果を基に、運用前に再検証してください。