Instruction fragility under hidden operational requirements

技術要約：隠れた運用要件下における指示の脆弱性

問題定義
本論文は、隠れた運用要件に起因する**指示の脆弱性（instruction fragility）**という問題に取り組んでいる。大規模言語モデル（LLM）との自然言語による対話において、ユーザーは、自身や評価者は知っているもののプロンプトには含まれていない制約（例：特定の出力形式、語数制限、リスクラベル、ソースの制限など）を省略することが多い。著者らは、これを単一の意図された結果としてではなく、**集合値意味論（set-valued semantics）*として定式化している。すなわち、一つの指示は実行可能な履歴の集合を意味する。このような未指定状態における安全性は、その集合内のすべての*実行可能な履歴が、ユーザーの許容範囲内にあることを要求する。もし指示が、一つでも不適切な実行（例：「私を裕福にする」ための詐欺的な手法）を許容してしまうならば、その指示は堅牢ではない。核心的な問題は、有限の指示では、すべての潜在的な制約を伝達することなしに、単一の意図された実行を一意に特定できないことにある。

手法
本研究は、形式的な理論的枠組みと、制御された経験的ベンチマークを組み合わせている。

1. 形式的枠組み:

   • 著者らは、背景理論 $B$ の下で、指示 $s$ が持つ指示対象を $J_sK_B \subseteq H$（実行可能な履歴の集合）として定義する。
   • 安全性は、**敵対的安全性基準（adversarial safety criterion）**によって定義される：$J_sK_B \subseteq A_{\tau, \eta}$。ここで、$A_{\tau, \eta}$ は、効用閾値および副作用予算を満たす許容可能な履歴の集合である。
   • 理論的分析により、情報理論的な下限（$N$ 個の意図を区別するには $\Omega(\log N)$ 個の記号が必要であること）、基数制約（有限の指示は任意の無限の実行空間の部分集合を記述できないこと）、および計算量的な困難さ（安全な合成はNP完全な集合被覆問題に帰着すること）が導出されている。

2. ベンチマーク構築:

   • 20のトピック領域（例：政策メモ、インシデント対応、財務ノート）をカバーする100タスクのベンチマークが作成された。
   • 各タスクは、可視化されたユーザープロンプトと、評価者には既知であるがプロンプトからは省略されている隠れた要件（タスクあたり2〜5個）で構成される。
   • 要件は以下の3つのタイプに分類される：
     • 慣習的な暗黙的要件： 仮定、不確実性、トレードオフ、リスクレベル。
     • 運用上の要件： 語数制限、ソース制限。
     • プライベートなフォーマット要件： 有効なJSON、正確な箇条書きの数。
   • 「厳格な合格（strict pass）」は、タスク内のすべての隠れた要件を満たすことと定義される。

3. 実験プロトコル:
   研究では、9つの条件下で3つのモデル（GPT-5.4, Claude Opus 4.7, Gemini 3.1 Pro）を評価した：

   • 低情報（Low-Information）： ワンショット・プロンプティング、汎用テンプレート、およびネガティブ制御による明確化（「隠れた制約なし」という回答を伴う強制的な質問）。
   • 引き出し（Elicitation）： 強制的な明確化（メニュー形式の質問に対する真実の回答）および検証（可視的または内部的なチェックリスト）。
   • オラクル条件（Oracle Conditions）： 予算付きオラクル（最大4つの隠れた要件を開示）およびフルオラクル（すべての隠れた要件を開示）。

主要な結果
2,700のタスク–モデル–条件の観測に基づく経験的な結果は、一般的なインタラクションと、真の制約の開示との間の極端なコントラストを明らかにしている：

• 一般的なインタラクションの失敗： ワンショット・プロンプティングの厳格な合格率はわずか2.7%（300試行中8回）であった。汎用テンプレート（7.3%）やネガティブ制御による明確化（1.7%）も、ほとんど改善は見られなかった。これは、タスクに関連する情報がない状態でのインタラクションでは、省略された制約を回復できないことを示している。
• 正しい引き出しの価値： 正しい隠れた要件を開示した場合、質的な性能向上が見られた。フルオラクル条件では、**64.7%**の厳格な合格率を達成した。予算付きオラクル（部分的開示）は54.0%に達した。
• 引き出しの失敗： モデルに質問を強制した場合（Forced Clarify）でも、合格率は8.0%にとどまった。Forced ClarifyとBudgeted Oracleの間の差（46.0ポイント）は、モデルがどの潜在的な制約が関連しているかを特定することに頻繁に失敗し、間違った質問をしたり、重要なものを見落としたりしていること（例：ソース制限が想起されたのはわずか1.0%であった）を示している。
• 実行の失敗： すべての要件が既知であるフルオラクル条件下であっても、合格率は100%に達しなかった（64.7%）。これは第二の失敗モードである、既知制約への遵守失敗（known-constraint compliance failure）、すなわち、明示的に提供されているにもかかわらず、モデルが完全な仕様を実行できないことを示している。
• 累積的な失敗： 厳格な合格率は、隠れた要件の数が増えるにつれて乗法的に崩壊した。低情報プロトコルの場合、3〜5個の要件を持つタスクでは合格率はほぼゼロまで低下した。
• 要件の特定性： プライベートなフォーマット要件（JSON、箇条書きの数）は、開示なしでは回収がほぼ不可能であった（ワンショットでは0%）。一方で、慣習的な要件（不確実性、絶対的な表現の回避）は部分的に推論されたが、依然として信頼性は低かった。

意義と主張
本論文は、AIシステムにおける厳格な運用の遵守に関する制御された失敗モードを特定したと主張している。その主な貢献は以下の通りである：

1. 指示の脆弱性の定式化： 堅牢性には、単に一つの「良い実行」を含めることではなく、すべての「不適切な実行」を除外することが必要であることを示す、集合値の指示対象フレームワークを提供した。
2. コミュニケーション失敗の診断： 指示遂行におけるボトルネックは、単なる対話ターンの不足ではなく、情報の引き出しの質であることを示した。汎用的な明確化は不十分であり、ターゲットを絞った要件の引き出しが必要である。
3. テンプレートと検証の再考： プロンプトテンプレートや汎用的な検証チェックリストは、わずかな改善しか提供しないことを示唆している。これらは、タスク固有のプライベートな制約の明示的な伝達の代わりにはなり得ない。
4. 安全性への影響： 本研究の結果は、堅牢なAIアシスタントには、より長いプロンプトや汎用的なインタラクションに頼るのではなく、明示的な要件状態の引き出し、それらの制約の忠実な統合、およびその状態に対する検証が必要であるという設計原則を支持している。

著者らは、本ベンチマークは合成的なものであり、テキストのみに焦点を当て、表面的な確認が可能な制約を対象としていることを述べ、その範囲を控えめに設定している。彼らは、長期的なエージェントの振る舞いや主観的な品質を測定することを目的としているのではなく、省略された運用要件という特定の失敗モードを分離して調査している。結果は、現在の最先端モデルは有能ではあるものの、決して全知ではなく、明示的なコミュニケーションなしには省略された制約を確実に回復できないことを示唆している。