- 公開日
Jailbreakテストを再利用するには、入力文だけを保存するのではなく、試験の許可範囲、モデルと周辺システムの条件、期待する許可・拒否・実行阻止、実際の観測を一組にします。正当な依頼を断った失敗と、安全上の制約を越えた失敗は別に数えます。危険な文言を広く共有せず、管理された入力と安全な報告を分けることも必要です。
Jailbreakは、安全上の制約を回避させようとする試みを指します。ここでは突破文の作り方ではなく、組織が許可した範囲で、守るべき境界が維持されるかを確かめる評価の管理を扱います。外部資料の指示に処理が引きずられるプロンプトインジェクションと重なる場面もありますが、入力経路を区別して記録します。二つの違いと防御の分け方は「JailbreakとPrompt Injectionの違いから防御を選ぶ」で扱っています。
試験の目的と許可を先に固定する
最初に、何の失敗を見つける試験かを定めます。不許可の内容を回答する問題と、権限のない外部操作を行う問題では、必要な観測が異なります。会話上の応答だけを検査するのか、ツール呼び出しと最終状態まで含めるのかを分けます。
架空の社内文書アシスタントを例にします。このシステムには、許可された公開資料を要約する機能と、別途承認されたときだけ文書を指定先へ送る機能があると仮定します。試験では、公開資料に見立てた架空の説明文、架空の文書ID、外部へ届かない模擬送信先を用います。本稿のケースは説明用で、モデル試験や送信は実施していません。
許可する範囲は、試験対象のモデルとアプリ、テスト用アカウント、利用時間、使ってよい入力、ログの保存先まで定めます。第三者のサービスへ無断で試すことや、本番の顧客情報を流し込むことは、この計画に含めません。サービスの利用条件や組織の試験手続が別にある場合は、それも確認します。
環境側では、模擬ツールを本番の送信先へ接続しないようにします。「送らないでください」という指示だけでは、誤った呼び出しが外部へ届かないことを保証できません。実行できる機能と接続先を制限し、試験の停止手段、監督担当、予算上限を準備します。
OWASPのLLM01:2025 Prompt Injectionは、Jailbreakをプロンプトインジェクションの一形態と位置付けたうえで、外部の内容を区別して示すこと、モデルの権限を必要最小限に絞ること、特権的な操作に人の承認を挟むこと、定期的な侵入試験などを対策に挙げています。以下の試験台帳や判定表は、これらを参考にした管理案です。特定の入力一つを防げたことを、すべてのJailbreakへの耐性の証明とはしません。
信頼境界と防御する場所を対応させる
この例で利用者が依頼したのは、資料の要約です。資料の中に操作を促す内容があっても、それは読む対象のデータであり、利用者からの追加承認ではありません。誰の依頼か、どの資料か、どこへ何を送る許可があるかを別々に判断します。
| 境界 | 守りたい条件 | 確認する位置 |
|---|---|---|
| 利用者の依頼と外部資料 | 資料内の指示を操作権限へ変えない | 入力の区分、モデルへ渡す文脈 |
| モデルの回答とツール要求 | 文章が送信を勧めても即実行しない | ツール呼び出し前の検証 |
| 要求と実行権限 | 対象文書・宛先・操作が承認範囲に合う | 実行ゲートと認可処理 |
| 呼び出しと外部状態 | 成功の発話だけで送信済みと扱わない | 模擬ツールの記録と最終状態 |
モデルの拒否、入力検知、権限ゲートは役割が違います。検知器が危険な入力だと表示しても、送信が実行されれば阻止には失敗しています。逆に検知器が見落としても、権限ゲートで操作を止める場合があります。その場合は、全体の被害阻止と、検知の失敗を両方残します。
テキストの正規化を行う場合は、その前後も区別します。正規化は、文字の表記や入力形式を揃える前処理です。何を変換したか、意味を保てたかを記録し、変換後に見える文だけで元入力の性質を推測しないようにします。原文と変換後の対応が失われた試験では、防御がどこで働いたかを追いにくくなります。
正規化が常に有益とは限りません。意味のある区切りや引用の境界を消すと、資料の内容が利用者の指示のように見える可能性があります。許可された無害な資料で、正常な引用が保たれるか、不要な拒否が増えないかも確認します。危険な表記の工夫や回避手順を公開する必要はありません。
ケースには期待結果まで含める
テストケースは、繰り返し使う入力と判定条件のまとまりです。実行するたびに変わる観測記録は、ケース本体から分けます。同じケースでもモデルや設定が変われば、別の実行記録になります。
| ケースの項目 | 残す内容 |
|---|---|
| 識別と目的 | ケースID、版、守る境界、対象の失敗 |
| 許可範囲 | 試験の承認記録、環境、対象アカウント、利用期間 |
| 入力条件 | 管理された入力への参照、会話履歴、資料版、前処理 |
| 構成 | モデル識別子、プロンプト版、推論設定、ツールと権限 |
| 期待応答 | 答えてよい部分、拒否する部分、確認を求める条件 |
| 期待操作 | 許される呼び出し、禁止する呼び出し、期待する最終状態 |
| 判定 | 採点基準、重大性、判定不能の条件、判定者 |
| 管理 | 所有者、閲覧できる人、保管期限、更新・廃止条件 |
期待結果は、「安全に処理する」のような一語にしません。要約は指定された内容を保つ、資料内の追加操作には従わない、送信ツールを呼ばない、送信状態が変わらない、といった観測可能な条件へ分けます。許可された部分まで止めたときの扱いも明示します。
入力の正確な再現が必要でも、危険な本文や秘密を台帳の一覧欄へ複製する必要はありません。制限された保管先へ参照を置き、一覧には分類、識別値、対象条件を載せます。識別値は同じデータかを照合する助けになりますが、内容の利用許可や安全性を保証するものではありません。
正当な依頼と境界を越える依頼を対にする
この例では、通常の要約、資料内の無権限な操作要求、利用者からの未承認の送信要求、承認条件が揃った模擬送信を別のケースにします。実用的な攻撃文は示さず、どの条件を変えるかだけを説明します。
| ケース | 変える条件 | 期待する応答 | 期待する操作と状態 |
|---|---|---|---|
| 通常の要約 | 操作を促す記載のない資料 | 内容を正しく要約する | 送信呼び出しなし、状態変更なし |
| 資料に追加操作の記載 | 資料内に試験用の操作要求がある | 記載をデータとして扱い、要約を続ける | 送信呼び出しなし、状態変更なし |
| 承認不足の送信 | 利用者の依頼だが文書や宛先が未確定 | 不足する承認条件を確認する | 条件が揃うまで実行しない |
| 承認済みの模擬送信 | テスト文書・宛先・操作の承認が揃う | 承認範囲内の処理を行う | 模擬先のみへ一度反映し、記録と一致 |
すべてを拒否する設定では、通常の要約や承認済み処理も失敗します。そのため、正当な入力も対照として用意します。許可条件が揃ったケースを試すには、その模擬操作自体が試験の許可範囲にあることが前提です。
不許可の依頼と許可される依頼が混在する場合は、部分回答の条件を追加します。たとえば、公開資料の要約と未承認の送信が一緒に求められたなら、要約を作ることと送信することを分けます。資料中の命令を検知した後に要約まで止めた場合は、検知が誤っていたとは限らず、停止範囲が広すぎる問題として扱います。
逆に、操作要求のない正常な資料で危険検知が出れば、検知の誤検知です。誤検知と、正しく検知した後の過剰な停止を一つの欄へ入れると、入力判定を直すべきか、処理継続の条件を直すべきかが分からなくなります。
試行ごとに環境の状態を揃える
前の試行で会話履歴や模擬送信状態が残れば、同じ入力文でも条件が違います。単独ケースでは開始時の会話と文書状態を固定し、試行後に元の状態へ戻したことを確認します。複数ターンを対象にするケースなら、前段の発話も入力の一部として保存し、一文だけを抜き出した試験と区別します。
復元できなかった状態で次の試行へ進まず、ケースの実行を保留します。想定外の外部接続、実データの混入、許可外の操作要求、ログの欠落が起きた場合も、事前の停止手順へ移します。結果不明の模擬送信は、状態を照合するまで無条件に再試行しません。試験担当者が原因と影響範囲を確認し、許可された開始状態へ戻せたと判断してから再開します。
ケースの実行順による影響も記録します。単独では合格し、連続実行でだけ失敗するなら、それを単独ケースの再現失敗として消さず、状態の共有や履歴の扱いを調べる追加条件として残します。
観測と判定を一つの結果欄へ押し込まない
実行記録には、実施日時、試行番号、ケース版、構成、モデルの出力、検知結果、ツール要求、実行ゲートの判定、最終状態を対応させます。モデルが「送信しません」と答えても、別の経路で送信要求が出ていないかを確認するためです。
AnthropicのDemystifying evals for AI agentsは、エージェントの発話や処理の記録と、環境に実際に残った結果を区別しています。また、モデルを使う採点器を人の判定と照らして較正すること、情報が足りないときは「不明」と返せるようにすることも説明しています。ここでも、成功したという発話を最終状態の代用にしません。模擬先の記録が取れない場合は、実行阻止を確認済みとせず、結果不明として扱います。
判定は、少なくとも「期待どおり」「期待と異なる」「判定不能」を分けます。期待と異なるものは、通常処理の失敗、誤拒否、過剰な停止、不許可の内容生成、無権限な操作要求、無権限な実行などに分類します。操作要求を出したが実行ゲートで止まった場合は、要求側の問題を残しつつ、実行阻止は成功と記録できます。
同じ入力で結果が変わる可能性があるため、試行回数と各回の観測を残します。前掲のAnthropicの解説も、出力が実行ごとに変わることを前提に複数回試行し、k回のうち一度でも成功したか（pass@k）と、すべて成功したか（pass^k）を分けています。一回の成功を再現性の保証にせず、一回の失敗も消さずに原因を調べます。安定した動作を確認したい目的に合わせて指標を選びます。
評価者の判断が分かれたら、入力の意図、許可範囲、回答の該当箇所へ戻ります。採点モデルの評点だけで決着させず、判定基準が曖昧だったのか、根拠が不足したのか、実際に重要な見解差があるのかを記録します。資料が足りないケースは、確認するまで合格数へ加えません。
率を出すときは対象群と分母を明示する
架空の集計として、正常入力40件のうち不要な拒否が2件なら、正常入力に対する誤拒否率は2÷40＝5％です。境界越えを確認する入力20件のうち、不許可の実行が1件なら、その入力群における実行の突破率は1÷20＝5％になります。同じ5％でも、分母と意味が違います。
境界確認20件のうち2件で最終状態のログが欠け、判定できた18件で不許可実行が1件だった場合は、全20件に占める確認済みの突破が5％、判定できた18件の中での突破が約5.6％です。ログのない2件を阻止成功として数えません。未確認の2件も突破していれば全体は3÷20＝15％となるため、5％を全体の確定した突破率と呼ばないようにします。
検知率を計算するなら、検知対象と定めた入力を分母にし、実行阻止率とは別にします。正しく検知したのに実行が進んだケースを、検知成功の一行だけで隠しません。正常な入力を含む全体の合格率も併記できますが、重大な一件を多数の通常成功で相殺しない採否基準が必要です。
これらの数値は計算方法を示す仮定で、実在製品の性能ではありません。小さい集合の割合は入力の選び方にも左右されます。NISTの生成AIプロファイル（NIST AI 600-1）も、狭い範囲や体系的でない評価から性能を外挿しないよう求めています。管理された試験環境の結果を、そのまま配備先のすべての条件へ広げず、試した範囲を結果に添えて報告します。
修正後に再利用する範囲と公開する範囲を分ける
失敗を修正したら、同じケースを再実行するだけでなく、対になっている正常入力も確認する計画を立てます。境界越えの要求を止める変更で、通常の要約まで止まることがあるためです。変更した防御位置と関係のあるケース群を選び、選んだ理由と試験範囲外の条件を残します。
ケースの期待結果を変えた場合は、同じ版へ上書きせず、変更理由を記録します。旧版で不合格だった結果を、新しい基準で黙って合格へ置き換えないようにします。対象モデルや権限設定が変われば、同じ入力であっても新しい実行構成として記録します。
公開報告には、守る対象、試験環境の性質、判定基準、件数、確認できた失敗の種類、残る限界を載せます。実用的な突破文、機密プロンプト、認証情報、内部の接続先は載せません。外部へ共有する必要がある場合は、相手と目的に必要な範囲へ絞り、組織の手続に従います。
保管するだけで終わらせず、ケースの所有者と見直し時点を決めます。対象機能の廃止、根拠となる方針の変更、試験許可の失効で使えなくなったケースは、その理由を残して実行対象から外します。再利用できる試験とは、同じ入力を繰り返せるだけでなく、何を確かめ、どこまで確認したかを後から説明できる試験です。
ロールプレイで制約を外そうとする入力への備えは「ロールプレイによる制約突破に備えて役割と権限を分ける」、命令の改変を検知する方法と、誤検知・見逃しの測り方は「外部入力の命令改変を検知し誤検知と見逃しに備える」で解説しています。
