要点：研究者たちは「Arbiter」という枠組みを作り、複数の大規模言語モデル（LLM）と形式ルールを組み合わせて、コーディングエージェントのシステムプロンプト内で起きる「干渉（矛盾や重複）」を検出しました。システムプロンプトはエージェントの振る舞いを決めるソフトウェア的な文書ですが、従来のソフトで使うようなテストはほとんどありません。Arbiterはそれを補うための方法です。

研究のやり方：Arbiterは二つの補完的な段階で動きます。まず有向評価（Directed evaluation）で、プロンプトを意味のあるブロックに分解し、事前に定義したルール（例：命令と禁止の矛盾、範囲の重複、優先順位のあいまいさ、暗黙の依存など）を使ってペアごとにチェックします。次に無指向スカウリング（Undirected scouring）で、あえて曖昧な探査指示を与えた複数の異なるLLMにプロンプトを読ませ、各モデルが「興味深い」と判断した箇所を集めます。後続のパスは以前の発見を受け取り、まだ調べられていない領域を狙います。停止は「連続して3つのモデルがもう探さない」と判断した時点で決めます。

何を調べたかと結果：公開されている三つの主要なコーディングエージェントのシステムプロンプトを対象にしました。対象はAnthropicのClaude Code（1,490行、約78K文字）、OpenAIのCodex CLI（298行、約22K文字）、GoogleのGemini CLI（245行、約27K文字）です。無指向スカウリングで152件の所見が出され、有向評価では1ベンダー（Claude Codeの例）について21件の干渉パターンが手作業でラベル付けされました。Claude Codeの有向分析では、4件の重大な直接矛盾（例：「常にTodoWriteを使え」と「決して使うな」が同じプロンプト内にある）、13件の範囲重複、2件の優先順位あいまいさ、2件の暗黙依存が見つかり、そのうち20件（95%）は構文的・静的検査で検出可能でした。全体として、プロンプトの「アーキテクチャ」（単一大域型＝モノリシック、フラット、モジュール化）が観測された障害クラスと強く相関しましたが、障害の重さ（深刻度）とは相関しませんでした。

なぜ重要か：システムプロンプトの内部矛盾は、実行するLLM自身が「判断」で矛盾を押し流してしまうため、外側からの検査がなければ見えにくい問題です。Arbiterは形式ルールで網羅的に見つけられる問題と、多様なモデルを使うことで単一モデルでは見えない別種の脆弱性を発見できることを示しました。実例として、スカウラーが指摘したGemini CLIの「構造的なデータ損失」に関する所見は、Googleが同様の症状を報告・修正した事実と一致しました。ただしベンダーの修正は症状への対応にとどまり、スカウラーが指摘したスキーマレベルの根本原因までは解決されていないと報告されています。加えて、著者は同種のクロスベンダー分析がAPIコール費用でわずか0.27ドルで行えることも示しています。

限界と注意点：有向手法は定義したルールの枠内では網羅的ですが、その枠外の問題は見つけられません。無指向スカウリングは枠外を探れますが、体系的な列挙は保証しません。スカウリングで示された「パス数とプロンプトサイズの対数関係」はデータ点が三つしかなく、確実な法則とは言えません。また、本研究は三つの公開プロンプトに基づく横断分析であり、より広い種類のプロンプトや運用環境での評価が必要です。最後に、いくつかの問題は静的検査で検出可能だった一方で、暗黙の依存など意味理解を要する問題はモデルの意味解析を必要とします。