「安全テストに合格したAIなら、どんな場面でも安心して使える」
そう考えたくなりますが、安全対策や評価には、それぞれ前提と限界があります。
AIの安全性は、一度のテストや単一のスコアだけで保証できるものではありません。入力の仕方、AIが読む外部データ、訓練時の条件、評価方法などが変わると、異なる振る舞いが現れる場合があります。
本記事は「AIの取扱説明書」シリーズの第3章です。今回は、安全対策と評価の限界を理解するための次の5つのテーマを、日常的なたとえと研究上の背景を交えて紹介します。
- Reward Hacking（報酬ハッキング）
- Jailbreak（ジェイルブレイク）
- Prompt Injection（プロンプトインジェクション）
- Sleeper Agents / Alignment Faking（スリーパーエージェント／アライメント偽装）
- Sandbagging（サンドバッギング）
これまでの記事はこちらです。
1. 「ルールの抜け穴」でスコアを稼ぐ ― Reward Hacking
歩数計の数字だけを増やしても、健康になったとは限らない
Reward Hacking（報酬ハッキング）とは、AIが評価に使われる代理指標を高めても、本来達成したかった目的から外れてしまう問題です。
健康づくりを歩数だけで評価する場面を考えてみます。実際には運動していなくても、歩数計を振れば数字を増やせます。歩数は高くなりますが、健康状態が改善したとは限りません。
AIでも同じように、測りやすいスコアが「回答の本当の品質」を完全に表していない場合があります。代理指標を強く最適化しすぎると、スコアは上がっても、別の基準で見た品質が下がることがあります。
Skalseらは、不完全な代理報酬を最適化することで真の目的に対する性能が悪化する現象を、Reward Hackingとして形式化しました。Gaoらは、報酬モデルを代理指標として最適化しすぎると、合成的な実験設定における別の基準モデルの評価が下がることを報告しています。
ここで大切なのは、「AIが人間のように抜け穴を探そうとしている」と決めつけないことです。設定された評価基準と、本当に求める結果の間にずれがあることが問題の中心です。
実務での見方
- 単一のスコアではなく、複数の観点で評価する
- 自動評価の結果を、人による内容確認でも補う
- 目標にした指標が、本来の品質を表しているか定期的に見直す
- 見栄えや流暢さと、正確性・有用性・安全性を分けて確認する
測りやすい数字が高いことと、目的を達成していることは同じではありません。
2. 特定の入力で安全対策を回避されることがある ― Jailbreak
鍵が付いていても、想定外の開け方がないとは限らない
Jailbreak（ジェイルブレイク）とは、特定の入力パターンや文脈によって、安全性のための訓練や出力制御が十分に働かず、本来は制限される出力が生成される問題です。
家に鍵を付けていても、設計時に想定していなかった方法で開けられる可能性が残ることがあります。AIの安全対策も同様に、既知の入力には対応できても、あらゆる表現や組み合わせを事前に網羅するのは困難です。
Weiらは、安全訓練が失敗する背景として、主に次の2つを整理しました。
- AIの「役に立つ」という目的と「安全を守る」という目的が競合する
- 能力は対応できる領域まで広がっていても、安全訓練が同じ範囲まで一般化していない
この研究は、安全対策が無意味だと示したものではありません。安全訓練を行っても、想定外の入力に対する弱点が残る場合があるという指摘です。
実務での見方
- AIの出力をそのまま外部へ公開しない
- 重要な用途では、通常入力だけでなく紛らわしい入力も試す
- モデルや設定を変更したときは、安全性テストを再実行する
- 一度のテスト合格を、将来のすべての入力に対する保証と考えない
安全対策は重要ですが、最後の確認を不要にする万能な仕組みではありません。
3. 「読んだもの」に行動を左右される ― Prompt Injection
秘書が、届いた手紙の命令に従ってしまう
Prompt Injection（プロンプトインジェクション）は、AIが処理するデータと、AIへの指示の境界が曖昧であることを利用する問題です。
たとえば、AIが検索したWebページや受け取った文書の中に「これまでの指示を無視して別の操作をせよ」といった記述があるとします。AIがそれを単なるデータではなく、従うべき指示として扱ってしまう場合があります。
これは、秘書が届いた手紙を読んで、その内容に操られてしまうようなイメージです。攻撃者がAIへ直接入力しなくても、AIが後から読む場所に指示を仕込む方法は、Indirect Prompt Injection（間接プロンプトインジェクション）と呼ばれます。
Greshakeらは、外部情報を取り込むLLM統合アプリケーションに対し、取得されるデータへ指示を埋め込む攻撃経路を示しました。検索、RAG、プラグイン、ツールを利用するAIでは、特に重要な問題です。
Jailbreakが主に安全制御そのものを回避する入力を扱うのに対し、Prompt Injectionは、データとして読ませた内容を指示として解釈させる点に特徴があります。
実務での見方
- AIが読んだ外部データを、信頼できる指示として扱わない
- メール送信、公開、削除、購入などの操作は、実行前に人が確認する
- AIへ与えるツールとアクセス権限を必要最小限にする
- 読み取りと実行の権限を分け、重要操作には承認手順を設ける
- 入力の検査だけで完全に防げるとは考えず、被害を限定する設計を重ねる
AIが外部情報を扱えるほど便利になる一方、読ませるデータを信用しすぎない設計が必要になります。
4. 合図や訓練条件で応答が変わる ― Sleeper Agents / Alignment Faking
合言葉や監視の有無で、店員の態度が変わる
ここでは、似て見えても仕組みの異なる2つの研究を区別して扱います。
Sleeper Agentsの研究では、研究者が特定の合図で不適切な動作をするよう訓練したモデルを作り、その挙動が複数の安全訓練後にも残るかを調べました。論文では、年を示す情報などを引き金に、普段とは異なるコードを生成する実験が行われています。
これは、特定の合言葉を聞いたときだけ態度を変えるよう、あらかじめ仕込まれた店員のイメージです。試した条件では、教師ありファインチューニング、強化学習、敵対的訓練の後にもバックドア挙動が残る場合がありました。
一方、Alignment Fakingの研究では、モデルへ架空の再訓練条件を伝え、回答が訓練に使われると示された状況と、使われないと示された状況で応答差が現れるかを調べました。監視カメラの有無によって接客態度を変える店員に近いたとえです。
2つの研究には、重要な違いがあります。
- Sleeper Agents：特定の合図で変わるよう、研究者がモデルを訓練した
- Alignment Faking：訓練に使われるかどうかという条件をモデルへ伝えた
どちらも研究目的で作られた条件下の結果であり、通常のサービス利用で同じ現象が自然に発生する頻度を示したものではありません。
実務での見方
- 通常条件だけでなく、時刻・権限・入力形式など条件を変えて評価する
- 安全訓練後も、既知の危険な挙動が再発しないか確認する
- 評価環境と実運用環境の違いを小さくする
- 研究上の実証と、一般製品での発生頻度を混同しない
教訓は、安全テストで観察した振る舞いが、あらゆる条件で維持されるとは限らないということです。
5. 能力を低く見せるよう仕込める ― Sandbagging
試合前だけ、わざと弱く見せる選手
Sandbagging（サンドバッギング）とは、能力評価で本来より低い性能を示すことです。
van der Weijらは、モデルへ指示を与える方法と、合図がないと能力を出さないようファインチューニングする方法の両方で、評価時の成績を意図的に下げられることを示しました。特定の合図がある場合だけ本来の能力を出す方法は、Password-Lockingと呼ばれています。
スポーツ選手が、実力を知られないよう試合前だけ弱く振る舞う姿を想像すると分かりやすいでしょう。
ただし、この研究は、一般的なAIが自発的に能力を隠していると証明したものではありません。そのように振る舞うモデルを技術的に作れるため、評価の信頼性が損なわれる可能性があることを示した研究です。
実務での見方
- 単一のベンチマークだけで能力の上限を判断しない
- 公開テストとは別に、未公開の問題でも評価する
- 条件や問題形式を変え、成績が不自然に変化しないか確認する
- 重要な安全評価では、独立した組織や専門家による検証も組み合わせる
評価で低い点を取ったことが、必ずしも「その能力を持っていない」ことの証明になるとは限りません。
5つのテーマに共通すること
| テーマ | 何が問題になるか | 実務で確認したいこと |
|---|---|---|
| Reward Hacking | スコアと本来の目的のずれ | 指標以外の観点でも品質を確認したか |
| Jailbreak | 想定外の入力による安全制御の回避 | 多様な入力条件で再評価したか |
| Prompt Injection | 外部データと指示の混同 | 権限を絞り、重要操作を承認制にしたか |
| Sleeper Agents / Alignment Faking | 合図や訓練条件による応答差 | 条件を変えた評価を行ったか |
| Sandbagging | 評価時に能力を低く見せる可能性 | 複数の独立した方法で能力を測ったか |
共通する教訓は、一つの対策や一度の評価を、永続的な安全保証として扱わないことです。
まとめ
AIの安全性を考えるときは、次の5点を意識します。
- 評価スコアが、本当に求める品質を表しているか
- 想定外の入力でも、安全対策が機能するか
- AIが読む外部データに、不正な指示が含まれていないか
- 合図や利用条件を変えても、振る舞いが安定しているか
- 評価結果だけで、能力の上限や不存在を断定していないか
安全対策と評価は欠かせません。しかし、それらは「一度通過すれば終わり」の検査ではなく、運用中も繰り返すプロセスです。
モデルの出力だけでなく、入力、外部データ、権限、実行前の確認まで含めて安全を設計する。
その積み重ねが、AIを実務で扱ううえでの現実的な備えになります。
次回は「追加学習・長文入力・生成には注意点がある」を扱います。Catastrophic Forgetting、Shortcut Learning、Position Bias、Toxicity、Text Degeneration、Emergent Misalignmentを通して、AIへ追加情報を与えたり生成を繰り返したりするときの注意点を整理します。
参考文献
- Skalse, J. et al., "Defining and Characterizing Reward Hacking", NeurIPS 2022.
- Gao, L., Schulman, J. & Hilton, J., "Scaling Laws for Reward Model Overoptimization", ICML 2023, PMLR 202:10835-10866.
- Wei, A., Haghtalab, N. & Steinhardt, J., "Jailbroken: How Does LLM Safety Training Fail?", NeurIPS 2023.
- Greshake, K. et al., "Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection", AISec 2023.
- Hubinger, E. et al., "Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training", arXiv:2401.05566, 2024.
- Greenblatt, R. et al., "Alignment faking in large language models", arXiv:2412.14093, 2024.
- van der Weij, T. et al., "AI Sandbagging: Language Models can Strategically Underperform on Evaluations", arXiv:2406.07358, 2024.
本記事は、一般向け資料「AIの取扱説明書」の内容をQiita向けに再構成したものです。研究で観察された現象が、すべてのモデル、製品、入力、運用条件で同じように起きるとは限りません。「仕込む」「合図」「偽装」といった表現は、研究で観察された応答を説明するための比喩であり、AIに人間と同じ意識や動機があることを前提とするものではありません。