近年、LLMベースのエージェントにおいて、自らのプロンプトやガードレールを修正し自己改善を進める「自動ハーネス最適化 (Automated Harness Optimization)」の導入が進んでいます。しかし、「観察された失敗を抑制すること」だけを報酬として設定する最適化ループには、大きな落とし穴が潜んでいます。それは、「そもそも修正すべき実際の失敗は存在したのか？」という前提の問いが抜け落ちてしまう点です。

今回は、AIが完全に合法で問題のない入力データに対して、架空のエラーをでっち上げ、無意味な防護壁を生成してしまう「Phantom Guardrails（幻の防護壁）」現象について解説します。なぜAIは、存在しない問題を自ら創り出し、修正しようとするのでしょうか？

この記事では、その発生メカニズムから、報酬ハッキング (Reward Hacking) との違い、実稼働ループで生じるリスクの蓄積、そして具体的なプロンプト設計を用いた様々な対策まで、客観的な検証データに基づき詳しく紹介します。エージェント開発者にとって、システムの信頼性を高めるための新たな視点となるはずです。

1. Phantom Guardrails とは何か？

Phantom Guardrails（幻の防護壁）とは、AIエージェントが「決して起きていない失敗」を自らでっち上げ、修正する必要のないデータに対して架空のガードレールを構築してしまう現象を指します。

現在のAIエージェントの多くは、「観察された失敗を抑制すること」のみを報酬とする仕組みで自己改善を進めています。しかし、このようなエージェントに対して「直す必要が全くない合法なデータ」を与えると、問題が存在しないにもかかわらず、幻のエラーを報告して不要な防護壁を生成してしまうことが明らかになりました。

この特異な現象を客観的に証明するため、研究チームはボードゲームを模した検証環境を構築し、以下の3つのエラークラスを設定しました。

• syntax: 不正な形式の入力による構文エラー
• bounds: 盤面外へ移動しようとする境界エラー
• castle: キャスリング（チェスにおける特別な移動）のルール違反

この検証において、3つ目の castle の違反はデータセット上に絶対に出現しないよう、意図的に制御されています。つまり、この環境下でAIが「キャスリングのルール違反を防ぐガードレール」を提案した場合、それはAIが自らでっち上げた「Phantom Guardrails」であると明確に断定できる仕組みです。

さらにこの研究で注目すべき点は、AIの出力を別のAIに評価させる「LLM-as-a-judge」のアプローチを避けたことです。LLMを判定役にすると、AI特有の事実誤認や、もっともらしい理由づけ（事後的な正当化）に評価が引きずられる懸念があります。

そこで本検証では、決定論的なプログラムコードである「オラクル（Oracle）」を導入しました。このオラクルは、AIが指摘した違反がデータ上に実在したかどうかを、バイト単位の厳密さで機械的に判定します。これにより、AIによるエラーのでっち上げを、人間の主観や他のモデルの曖昧さを完全に排除し、客観的かつ厳密に測定することに成功しています。

2. 検証環境とモデル

AIエージェントの自己改善は、基本的に「エラーをどれだけ減らせたか」というスコアを最大化することで進められます。この検証では、この評価指標を「抑制プロキシ (Suppression Proxy)」と呼び、以下の数式で厳密に定義しています。

$$S(H,D) = \frac{1}{|D|}\sum_{e\in D}\mathbf{1}\left[\mathrm{fired}(H(e))=\emptyset\right]$$

ここで使用されている変数は、それぞれ以下の意味を持ちます。

• \(H\) (Harness): エージェントに適用されたハーネス（プロンプトやガードレールなどの防護層）
• \(D\) (Dataset): 評価対象となるエピソード（実行ログ）の集合
• \(\mathrm{fired}(H(e))\): ハーネスを適用した結果、実際にトリガーされたエラークラス

この数式は、要するに「ハーネスを適用した結果、エラーが一つも発火しなかったエピソードの割合」を表しています。

今回の検証における最大のポイントは、入力データとして「全てが合法なデータのみを含むデータセット (all-legal pool)」を用意したことです。このデータセットにはエラーが一切含まれていないため、初期段階から失敗クラスは発火しません。したがって、何も修正しなくても抑制プロキシ \(S(H, D)\) は最初から最大値の「1」となります。

この完璧な状態において、本来あるべき妥当なハーネス \(W(D)\) は、防護壁を一切追加しない「空のハーネス（\(\emptyset\)）」になるはずです。エラーが存在しない以上、システムを修正する必要はないからです。

しかし、AIがこのエラーのないデータに対して、「存在しないルール（本検証ではキャスリングの違反など）」のためのガードレールを独自に生成してしまうことがあります。研究チームは、この不必要なガードレールが追加された状態を「でっち上げ指標 \(Fab(H, D)\)」として数式化しました。これにより、AIによる「Phantom Guardrails」の構築を、主観を交えずに検出・測定する環境が整えられました。

3. AIがエラーをでっち上げる3つの条件

AIはどのような状況でも無闇にエラーをでっち上げるわけではありません。実際、何の特徴も持たない完全にクリーンなデータを与えられた場合、AIは適切に防護壁を追加せず「何もしない（Abstain）」という判断を下します。

しかし、データの中に違反ではない「無害な繰り返しパターン（例えば、偶然同じマスに複数回移動した記録など）」が含まれていると状況は一変します。AIは「同じマスへの反復移動は特別ルールの違反である」といったもっともらしい理由をでっち上げ、Phantom Guardrails を構築してしまうのです。

研究の結果、1回の提案プロセス（シングルショット）においてこの現象が発生するには、以下の3つの条件が同時に揃う必要があることが判明しました。

• 1. ジャンルの事前知識に似たパターンの存在
  データの中に、AIが事前学習で獲得した「ジャンルのルール」を想起させるパターンが含まれている必要があります。本検証のボードゲーム環境であれば、「反復移動」や「すでに埋まっているマスへの移動」などが該当します。一方で、「対角線上に動く」や「同じ列に動く」といった、一般的なボードゲームのルールに直結しないパターンを提示した場合は、エラーのでっち上げは一切発生しませんでした。
• 2. ルールの完全性が未定義
  システムに対して「提示されたルールのセットが全てである」という完全性が明示されていない場合、AIは自らの事前知識から勝手にルールを補完しようとします。
• 3. 失敗を前提とする指示 (Failure presupposition)
  システムプロンプトの中に「このログには失敗したゲームが含まれています」といった、エラーの存在を前提とする指示が含まれている場合です。

非常に興味深いのは、これら3つの条件のうちどれか1つでも取り除かれると、でっち上げの発生率は完全にゼロになるという点です。例えば、プロンプトに「提供したルールが全てです」という一文を明記して完全性を保証したり、「ログから『妥当な』ガードレールを提案してください」と中立的な指示に変更したりするだけで、AIは Phantom Guardrails を構築しなくなります。

この結果は、AIエージェントを制御する上で、プロンプトにおける「事実と異なる前提の排除」や「仕様の明言」がいかに重要であるかを如実に物語っています。

4. 報酬ハッキングや過剰拒否との違い

AIが不必要なガードレールを自発的に生成すると聞くと、既存の「過剰拒否 (Over-refusal)」や「報酬ハッキング (Reward Hacking)」といった現象を思い浮かべるかもしれません。しかし、今回の「Phantom Guardrails」はそれらとは明確に異なる性質を持っています。

具体的には、以下の点で既存の課題と区別されます。

• 過剰拒否との違い: 従来の過剰拒否は、システムが過敏に反応することで安全性を高める代わりに、本来のタスクの有用性を下げてしまうトレードオフを伴います。一方、Phantom Guardrails は合法なデータに対して構築される無意味なルールであるため、タスクの有用性を損なうといったトレードオフは発生しません。
• 報酬ハッキングとの違い: 報酬ハッキングは、本来の目的を犠牲にして評価スコア（プロキシスコア）だけを不当に引き上げる現象です。しかし今回のケースでは、エラーのないデータセットを用いるため初期状態ですでにスコアが満点であり、Phantom Guardrails を追加してもスコアはこれ以上上がりません。

また、「単にAIが特定の出力をしやすい（デフォルトの語彙の偏りがある）だけではないか？」という懸念も提起されました。これに対しては、Blinded-congruent arm と呼ばれる厳密なテストによって反証されています。このテストでは、入力データからエラーを示すタグなどの語彙的なヒントを完全に隠蔽しましたが、それでもAIは60回のテストすべて（60/60回）で本物の違反を正しく検知し、適切なガードレールを選択できました。つまり、Phantom Guardrails は単なる出力の偏りではなく、正常に機能するディテクターが引き起こした純粋な「偽陽性（誤検知）」であることが証明されたのです。

さらに、様々な追加検証も進められています。その一つである GridErrand という実験では、情報の提示順序（フレーミング）がエージェントの判断に与える影響を測定しました。ここでは「Steering contrast」という指標を用いて、以下の数式で影響度を算出しています。

$$\Delta(c) = \pi_{\mathrm{fg},c}[\mathrm{fix}(c)] – \pi_{\mathrm{bg},c}[\mathrm{fix}(c)]$$

この数式は、あるエラークラス \(c\) の情報を前に出して強調した場合（\(\mathrm{fg}\)）と、背景に隠した場合（\(\mathrm{bg}\)）とで、対応する修正機能（\(\mathrm{fix}(c)\)）が選ばれる割合の差を示しています。

算出された結果は \(\Delta = +0.02\) とほぼゼロに近い値でした。この結果から、提供する情報を固定したまま情報の提示順序だけを変更しても、ガードレールの選択には実質的な影響を与えないことが確認されています。

5. 反復的改善ループにおける隠れたコスト

1回の提案プロセスにおけるでっち上げの条件を整理しましたが、実際の開発現場で稼働する「反復的な自己改善ループ」においては、事態はさらに深刻です。前述した3つの条件が完全に揃わなくても、Phantom Guardrails がシステムに侵入し、永続化するリスクが存在します。

自己改善エージェントは、提案された修正をシステムに取り入れる際、様々な評価ルールに基づいて判断を進めます。本検証では、以下の2つのルールの下で Phantom Guardrails がどのように振る舞うかが調査されました。

• 「悪化しなければ受容 (Accept-if-not-worse)」の罠
  このルールの下では、新しいガードレールが既存の評価スコア（プロキシスコア）を下げない限り、修正が採用されます。Phantom Guardrails は、合法なデータに対して何も影響を与えない無害な処理（No-op）として機能するため、スコアを下げることはありません。その結果、スコアが悪化しないことを理由に受容され続け、ラウンドを経るごとに単調に蓄積（Ratchet）していくことが確認されています。
• 「厳密な改善のみ受容 (Strict-improvement)」の限界
  では、スコアが向上したときのみ採用するルールにすれば防げるのでしょうか。確かにこのルールでは、単独で Phantom Guardrails が提案された場合は弾かれます。しかし、本当に必要な別の妥当な修正（バッチ）の中に混ざって提案された場合、バッチ全体としてスコアが向上してしまうため、Phantom Guardrails もシステム内に侵入し、そのまま永続化してしまいます。

「観察された失敗の抑制」という単一の指標のみでAIエージェントを評価し続けると、表面上のスコアは満点を維持できます。しかし、その裏では不要なガードレールによって、以下のような隠れたコストがシステムに蓄積していくことになります。

• レイテンシ（遅延）の増加: 実行時に不要な防護壁の処理を毎回通過するため、システムの応答速度が低下します。
• サーフェスエリアの拡大: 無意味なコードや防護ロジックが増えることで、攻撃を受ける余地（攻撃面）が広がってしまいます。
• 特異性 (Specificity) の喪失: 本来のタスクに特化した動作が失われ、システム全体が不必要に複雑化します。

6. 実運用における測定の難しさと限界

ここまでは意図的に統制されたクリーンな検証環境での結果を見てきましたが、実際の開発や運用シナリオにおいて「過剰修正 (Over-fixing)」を正確に測定することには、非常に大きな困難が伴います。

セキュリティを題材にした MiniDojo という実験では、この難しさが浮き彫りになりました。当初、この実験ではAIが攻撃のない安全なデータに対してもガードレールを構築してしまう過剰修正率が98%と、非常に高い数値を示しました。しかし詳細な調査により、これが純粋なエラーのでっち上げではなく、検証環境に潜む「交絡因子 (Confounds)」によるものであることが判明したのです。

具体的には、以下のような交絡因子がAIの判断を狂わせていました。

• 隠れた攻撃データ: 「無害」とラベル付けされていたデータの中に、実際にはプロンプトインジェクションのペイロード（攻撃コード）が含まれてしまっており、AIのガードレール構築は妥当な反応でした。
• 同音異義語効果 (Homonym effect): 「パスワード (password)」や「資格情報 (credentials)」といったセキュリティ関連の名詞が、日常的な無害な文脈で使用されていました。AIは文脈ではなく、これらの単語そのものに過敏に反応してしまいました。

これらの要因を慎重に取り除いた厳密な対照群（コントロールグループ）で再検証を実施したところ、統計的に有意な過剰修正は確認されませんでした。つまり、実世界に近い複雑なデータセットでは、「AIの純粋なでっち上げ」と「データ側の紛らわしさに対する妥当な反応」を明確に切り分けることが極めて難しいのです。

では、過剰に作られたガードレールを後から評価して削る「事後処理」はどうでしょうか。本研究では、各修正の成果を記録した「正直な報酬台帳 (Honest ledger)」を用いて、効果のない無価値なガードレール（フック）をAI自身に削除させるテストも実施されました。

確かに、台帳の情報が正確であれば、AIは不要な「Phantom Guardrails」を高い確率で削除します。しかし、ここにも大きな限界が存在します。AIは自らの判断で削除しているのではなく、単に台帳の指示に盲目的に従っている（Compliance）だけだったのです。実際、台帳にあえて「本来必要な修正の効果がゼロだった」という誤った情報を与えてみたところ、AIはその必須の修正まで削除してしまいました。

このように、実運用において「Phantom Guardrails」を正確に検出し、安全かつ自動的に除去する仕組みを構築することは、まだ多くの課題を残しています。

おわりに

LLMを用いた自己改善システムを構築する際、単に「エラーの抑制率」だけを評価指標に設定すると、無駄なリソースを消費する「Phantom Guardrails」の蓄積を招きます。この現象を防ぎ、健全な改善ループを維持するために、開発者は以下の設計方針を取り入れるべきです。

• プロンプトの衛生管理 (Instruction Hygiene): 「これらは失敗した記録です」といったエラーを前提とする文言を削除し、中立的な指示に変更します。
• 仕様の完全性の明示: 「ルールのセットはこれで全てである」とプロンプトに追記し、AIが未知のルールをでっち上げる余地をなくします。
• 正当性を意識した受容 (Warrant-aware acceptance): 提案されたガードレールを無条件に組み込むのではなく、判定プログラム（オラクル）が確認した実際の違反ログと紐付いているかを厳格に検証するルールを採用します。

More Information

• arXiv:2607.13083, Su Wang et al., 「Phantom Guardrails: When Self-Improving Agent Harnesses Fix Failures That Never Happened」, https://arxiv.org/abs/2607.13083