あなたの8つのエージェントのうち、どれを最も信頼できるのか?GPTは60%失敗する。

AI研究
この記事は約20分で読めます。

複数のAIエージェントやツールが矛盾する情報を返すとき、どの情報を最も信頼すべきかを扱う研究を紹介する動画である。ジョンズ・ホプキンス大学のベンチマークをもとに、LLMが多層の命令階層や信頼レベルをうまく処理できず、最新モデルでも大きく失敗する理由を解説する。さらに、静的な権限設定だけでは不十分であり、今後は文脈、検証可能性、世界モデルを組み込んだ動的な信頼ミドルウェアが必要であると論じる内容である。

Which of your 8 Agents can you trust the most? GPT fails 60%.
Not all agents are equal. Some agent we trust more with confidential data, with important information. Some agent bring ...

信頼すべきエージェントはどれなのか

コミュニティの皆さん、こんにちは。戻ってきてくれて本当にうれしいです。話しましょう。私たちは複数のエージェントを使っています。そして、それぞれが違った種類の情報を持ち帰ってきます。でも、どのエージェントを一番信頼すべきなのでしょうか。そこで今回は、信頼ベクトルについて話します。では始めましょう。

新しい研究です。いや、これはすでに2026年4月中旬のものとして出ています。ジョンズ・ホプキンス大学の研究で、まさに私がいま自分の仕事で扱っているテーマ、LLMエージェントにおける多層的な命令階層を検証しています。これは何についての研究かというと、AIモデルが最大12段階の、権限の異なる衝突する命令を処理しなければならないベンチマークを導入しています。全体では850件を超えるエージェント的タスクで構成されていて、見てのとおり、だいたい半分がコーディングタスク、もう半分が命令追従タスクです。

異なる情報源のどれを信頼するべきか

では見ていきましょう。彼らの主張はシンプルです。LLMはますますエージェント的なシステムの中に組み込まれています。だから、異質な情報源から来る命令に優先順位をつけなければなりません。でも、どの情報源を信頼すべきなのでしょうか。たとえば、あなたが新しい部屋に入ったロボットだとして、矛盾する情報が返ってきたら、どの情報を信頼すべきでしょうか。どのツールを信頼すべきでしょうか。3つの異なるツールがそれぞれ別の答えを返してきたら、どれを信頼するべきなのでしょうか。あるいは、他のエージェントはどうでしょうか。エージェントスワームのようなマルチエージェントシステムでは、どのエージェントを信頼するべきでしょうか。最初のエージェントでしょうか。それとも時間的に最後にいるエージェントでしょうか。

一般的に考えると、2025年のOpenAIでは、5つの固定された権限レベルがあります。root、system、developer、user、そしてその下にguidelines、assistant、toolなどがあります。つまり、確立された階層があり、特定のロールトークンがあります。でも、ここを見てください。彼らはこう言っています。システムは素晴らしい、最上位の優先度です。しかしその次に、スキルファイルや別のユーザーメッセージがあります。これらはすべてuserの優先度を持っています。つまり、ここでは3つの異なる入力の権限がすべて中程度になっているわけです。そしてさらに、最も低い権限のツール入力もあります。

しかし、中程度の権限同士が互いに矛盾した場合、どちらを採用したいでしょうか。解決策は簡単だと言うかもしれません。信頼ベクトルや指標の構造化されたシーケンスを作り、スキルファイルはユーザーメッセージより優先される、というふうにすればよいのだと。でも、そのユーザーメッセージが病院から来ていたらどうでしょうか。あるいは、何か緊急で確認すべきことを示していたらどうでしょうか。そうなると、それほど簡単ではありません。

そこで私たちが求めているのは、既知ではあるけれど変動する信頼レベルを持つ情報源かもしれません。AIモデルは、外部から提供された内容の間にある衝突を解決する必要があります。そしてその優先順位は、推論時にしか利用できない可能性があります。時間的に重要なイベントの中でだけ分かるかもしれないのです。突然、LLMは自分のすぐ近くの環境で多くのことが起きていると理解し、場合によっては優先順位を別のエージェントへ移さなければならなくなります。では見ていきましょう。これはかなり面白い話になります。

固定階層ではなく動的な権限レベルが必要になる

より広い設計原則としては、もちろん、自分自身のAIマルチエージェント構造を構築するなら、命令階層があります。ただし、それはLLMのポストトレーニング中に決められた固定的で有限な階層ではなく、柔軟で動的にインスタンス化される権限レベルをサポートすべきです。もう少し詳しく見てみましょう。

先ほど話したように、system、developer、user、assistant、toolというチャットテンプレート階層は素晴らしいです。しかし、3つの異なるツールがある場合はどうでしょうか。ファイアウォールの内側にある検証済みの社内SQLデータベースがあり、あなたはこのデータベースを最も信頼しているとします。ならば、ランダムなWebスクレイピングツールの出力より絶対に上位に置かれるべきです。でもAPIから見ると、どちらも単にツールです。

では、この特定の振る舞いをどうやってモデルに指示し、どうやって教えるのでしょうか。著者たちはこう言いました。トレーニングは一切しません。インコンテキスト学習に入れるだけです。プロンプトの中に入れるだけです。たとえば、テキスト用のCSS set index valueのようなものがあります。たとえば privilege one、end of privilege one といった形にして、命令は単純に、インデントには4つのスペースを使え、というものです。

あるいは privilege five では、インデントには2つのスペースを使え、となります。もしこれがユーザーから来ていて、最初のものが会社内部から来ているとします。つまり、メタプロンプトをプロンプト内に単純に追加して、ルールを説明するわけです。ここにあるように、低い権限番号が高い権限番号を上書きする、といった具合です。すると突然、あなたのエージェントには無限にスケールする細かな権限システムが備わります。すべてが華やかで、すべてが美しく、また太陽が出てきたような気分になります。

これで、すべてのRAG検索結果、すべてのツール出力に特定の信頼スコアを注入できます。ツールを信頼できるデータベースにつなぐこともできますし、奇妙なインターネット上の情報源につなぐこともできます。あるいはグループチャットがあり、グループチャットメッセージがあります。そこに一定のセキュリティレベルや信頼レベル、何と呼んでもよいですが、そうしたものを与えられるのです。

すべてのシステムが失敗した

ここまではすべて美しく見えます。しかし、これをテストすると、すべてのシステムが失敗することが分かります。これは奇妙です。本来まったく起きるべきではありません。でも見てください。ここではx軸に精度があり、0から50%までです。彼らはかなり多くのモデルをテストしたと言っています。達成できた最大値はGemini 3.1 Proの42%精度でした。次にGPT 5.4が40%未満、Qwen 3.5の400B、OPUS 4.6が33%、Kimi K2.5が32%、Grok、Sonnetはすべて30%未満、20%未満です。そして9Bや4Bのモデルでは、精度がほぼ0%に近づいていきます。

何が起きているのでしょうか。正確なプロンプトを与えています。そこにはインコンテキスト学習として、メタプロンプトの指標、権限、タグが正確に含まれています。そしてこの情報が完全に正しいことも保証されています。それなのに、LLMはすべてこのやり方でうまく動けません。何かがおかしいのです。低い番号が勝つ、と言っているのです。パズルを完璧に解くために必要なデータはすべて提供されています。それでも地球上で最も賢いモデルでさえ墜落炎上し、60%の確率で失敗しました。AIはまったく機能していません。では、なぜでしょうか。

それはある種、幻想を打ち砕きます。そしてまさにこれが、いま私が自分のシステムで直面していることです。フロンティアモデル、つまり、さあ、GPT 5.5ほどのモデルなら、論理とアラインメントに本質的に優れているはずだ、という幻想を打ち砕くのです。ところが実際は違います。まったく違います。

著者たちはその後、分類を行い、純粋なコーディング、Python、または一般的な命令追従を見たと言いました。Pythonは素晴らしいです。コンパイラがあり、すぐに検証できます。そして命令追従にも方法論があります。コード生成やコード最適化のために多くのモデルがトレーニングされてきたので、コーディングの精度は60%です。それを見て、素晴らしいと言いたくなります。

しかし、非コーディングを見るとどうでしょうか。LLMに自然言語の命令が与えられ、それに従うタスクです。最良のモデルでも、すべて30%未満の性能精度であることが分かります。これはさらに悪いです。Gemini 3.1 Proで26%、GPT 5.4で17.8%、OPUS 4.6では命令追従精度が15%です。すべての情報はそこにあります。完全な情報です。完全に透明です。ただそれを理解して反映するだけでいいのです。

それなのに、すべてのモデルが失敗します。私は自問します。なぜなのか。自分自身の経験でもこれを見ています。なぜモデルは失敗するのか。そしてこれが、すでに3週間前の研究を今ここで見せている理由です。なぜ今なのかと思うかもしれません。これは、私の仕事がなぜうまくいかないのか、その説明を見つけるためにまさに探していたものだったからです。

組み合わせ的崩壊が起きている

分かったことは、モデルには組み合わせ的崩壊が起きているということです。これらのモデルはすべて、2段階の衝突で扱われ、トレーニングされてきました。事前学習データでは簡単でした。システムは、あなたは安全でなければならない、と言います。そしてユーザーは、安全ではないものの作り方を教えてくれ、と言います。これは二項比較でした。モデルは2層、3層の場合をどう扱うかを学びます。

しかし、この厄介なベンチマークでは、最大12層の衝突するルールが投げ込まれます。もし私の物理環境に4つのエージェントが出ていて、それぞれのエージェントについて1、2、3ステップの推論を行うなら、12層の衝突ルール構造に近づきます。

たとえば、権限レベル4のルール1が、例ではダブルクォートを使うべきだと言います。権限レベル7のルール2は、トリプルクォートを使うべきだと言います。権限レベル1のルール3は、型ヒントを使うなと言います。権限レベル9のルール4は、完全な型ヒントを使うべきだと言います。これは簡単です。論理です。もしこれがPythonの中にあれば、すぐに解が見つかるでしょう。

ただしPythonであっても、解を見つけられるのは59%のケースだけです。それですら複雑すぎるからです。そしてこの厄介なベンチマークでは、LLMに最大12層の衝突するルールを投げ込みます。ルール1、2、3、4、それぞれに異なる権限状態があります。ダブルクォートを使え、トリプルクォートを使え、型ヒントを使うな、完全な型ヒントを使え、という具合です。私たちはそれを見て、これは論理だ、何をすべきか分かる、と思います。

ところが、それをPythonコードにコピーした場合でさえ、正しい答えが得られるのは59%のケースだけです。そして命令追従にすると、もうひどい状態になります。つまり、この論文が証明しているのは、層の数が増えるにつれて、とくに6から12を超えると、精度が単調に急落するということです。LLMは文字通り数学的な階層を見失い、すべての命令を同時に満たそうとする状態に戻ってしまいます。その結果、段階的推論、段階的な論理適用において、完全な混乱、パラドックスが生まれます。これが、地球上で最高のLLMでさえ失敗する理由です。6段階の精度についていけないのです。

LLMは数学ではなく意味で処理している

次に著者たちは、分かったこととして、モデルは数学をしているのではなく、LLMとして意味処理をしているのだと言います。モデルはこれをPythonなどに変換しているわけではありません。人間の脳は、すぐに数学演算子をトリガーします。2は5より小さい、と判断します。しかしLLMはそれを意味的なトークンとして処理します。そして研究の著者たちは、モデルは算術ではなくパターンマッチングをしていると言います。ベンチマークが同じプロンプトの中に4つ、5つ、あるいは10個の衝突する整数値を投げ込むと、意味ベクトルがぼやけます。つまり、正しい解に到達することに60%のケースで失敗するのです。

LLMが失敗するのは、数学ができないからです。4、5、6を意味的な方法で比較しているのです。もちろん、解決策はあると言うでしょう。はい、当然、私たちは解決策を知っています。ただ、マルチエージェントシステムを構築していて、これに注意を払わなければ、これこそが失敗の原因になるのだと示したいのです。そして今、私は自分の問題への解決策を見つけました。

表記の違いだけで精度が下がる

他にもありました。マイナス8%です。研究者たちは、3週間前時点のフロンティアモデル、GPT 5.4とClaude OPUS 4.6でこれをテストしました。そしてこのモデルたちは、信じられないほど奇妙な運用上の癖を示しました。

彼らは2つの形式をテストしました。先ほど話したように、ordinal privilege one、つまり低い番号が勝つという形式です。そして次に、別の表現を選びました。0から100までのスカラーを使ったのです。そこで今度はZ equal 95と呼びます。そして高い番号が勝ちます。人間としては、論理的にこの2つは同一だと言うでしょう。この2つの形式は、まったく同じ順序を表す別形式にすぎません。そう思いましたよね。

しかし、最高のシステムであるOPUS 4.6やGPT 5.4でさえ、ここで切り替えを行うと、精度が8%以上低下しました。表記がordinalからscalarに変わっただけです。正しく、美しく同じ意味を表しているにもかかわらず、システムは単純にそれを処理できなかったのです。前の例でprivilegeとして見たものが、次の例ではscalarとして与えられるだけで、性能が8%以上落ちました。

そして怪物がやってきます。彼らはそのスカラー値を少しだけ調整しました。ほんのわずかな量です。マイナス1やプラス2のように変えただけです。勝者の順序はまったく同じに保ったままです。すべて同じままです。単に、この値をほんの少し変えたら何が起こるかを見ただけです。システム全体の論理には何も変化を与えないはずです。しかし彼らは、このLLM、つまりこれを整理し、計算するAIモデルが、最大17%のタスクで答えを完全にひっくり返すことを発見しました。

つまり、値を17から17マイナス1へ変えただけで、モデルは17%のケースで完全に答えを変えたのです。

これは、モデルが数学をしていないことを意味します。数字を理解していません。何を計算しているのか分かっていません。そして単純に算術を無視しています。モデルは意味の機械なのです。

推論を増やしても常に良くなるわけではない

著者たちが発見した次の奇妙な点は、私にとって本当に苛立たしいものです。ただ、彼らが見つけた全体像をここで見せたいと思います。これは濃い研究であり、私たちは楽しみながら学ぶべきだからです。

私はときどき、特にGPT系では high や x-high を使います。LLMの性能を上げたいとき、xやx-highを指定します。すると、思考がより良くなると考えます。なぜなら思考時間は確実に長くなるからです。4分、5分、10分、というふうに。ところが彼らは奇妙なことを見つけました。

見てください。このベンチマークのコーディングサブセットにおける精度と推論努力です。彼らはGPT 5.4を使いました。裸のGPT 5.4があり、そして低推論、中推論、高推論のGPT 5.4があります。精度はまさに期待どおりです。これは素晴らしいです。

しかし、この特定のテストでは、権限レベルやスカラーなど、すべての情報が与えられています。すべて揃っています。すべて完全に正しいです。ここでSonnet 4.6やAnthropicのOPUS 4.6を見ると、非推論のほうが低推論努力より性能が良いことが分かります。

つまり彼らは、非推論から低推論に移ると性能が落ちることに気づきました。そして、低推論モデルが非推論モデルを下回るなどあり得ない、と言いました。本来あり得ないはずです。しかし実際には、それは本当に起こる効果であり、まさにシステムの振る舞いでした。そしてSonnet 4.6やOPUS 4.6では、中程度の努力まで行ってようやく非思考モデルより良い性能になり、高では少しだけさらに良くなりました。美しいですね。

ここから分かるのは、人間の感覚で、推論は当然ながら推論なしより良いはずだと仮定するのは間違っているということです。モデルは異なる方法で事前学習されています。そして彼らは、Claudeは実際には、最終的に見える出力ウィンドウの中で、自分の衝突解決ロジックを明示的に書き出すことで補償していたと言います。したがって、非推論モデルがすべてを書き出そうと判断した場合、低推論よりも、そのアプローチにおいてより知的、あるいはより構造化されているように見えるのです。だから非推論が低推論より良い結果を出しました。これは驚くべきことです。

権限はテキストの入れ物ではなく本文内で指定される

私は、これはいったいどうして可能なのかに興味を持ちました。でも、まず彼らが使った方法論に戻りましょう。普通、これを扱うときは、そのテキストが入っているバケットによって権限が定義されます。データパスがあり、ロールはuserで、コンテンツがここにあります。これがAPIペイロードです。このバケットの中にあるものは、すべてまったく同じ権限を共有します。

しかし今、彼らは、もはやそうである必要はないと言います。彼らがprivilege prompt interfaceと呼ぶものを使うからです。先ほど見せたように、これは単なるメタプロンプトで、私たちが議論したようなインラインCSSのように機能します。単一のテキストブロックが信頼レベル、あるいは権限レベル99を持ち、別のブロックがレベル2を持つことができます。すぐに考え方は分かると思います。

つまり私たちは今、認可をマクロ構造レベル、純粋なAPIエンドポイントから移動させ、マイクロテキストレベルまで下げることができます。さらにトークンそのものまで下げることもできます。とはいえ、これはあまり意味がありません。誰がそんな作業をするのでしょうか。誰が各トークン、あるいは段落、文のまとまりにラベルを付けるのでしょうか。まさにこれを私も自問しました。

ただ、その答えに入る前に、彼らがプロンプトと実施した実験について、本当に透明な情報を提供していることを見せたいと思います。ここにスカラー表現でのシステムプロンプトがあります。そしてスカラーのユーザープロンプトがあります。見てのとおり、set equal 46、Z set、Z set、Z set、Z set、Z set、Z set、Z set、Z set、Z set、Z equal 1があり、その後に異なる信頼ベクトル、優先度レベル、情報がすべて入っています。

素晴らしいです。そして、まさにここで彼らは失敗しました。

信頼スコアは誰が決めるのか

では戻りましょう。実際に、どの情報片がどの信頼係数を得るかを決めているのは誰なのでしょうか。私はそれを信頼係数と呼びます。ここに著者たちの研究からの公式な引用があります。彼らは、権限値は与えられているものと仮定すると言います。つまり、各命令ソースの信頼性に基づいて、モデル開発者とデプロイヤーが協力して事前に決めるということです。これはつまり、彼らの粒度レベルでは、それは事前定義されているということです。

彼らは、それが現実世界のエージェント的な展開を反映していると主張します。そこでは複雑な権限構造がすでに存在しています。つまり人間である私がマルチエージェントシステムを構築します。エージェントの組織上の役割を定義します。APIの信頼レベルも持っています。そしてそれらを推論時にモデルへ伝達するだけでよいのです。

皆さんがどう思うかは分かりませんが、私はこれでは不十分だと思います。ルールは、文の意味を評価してスコアを与えることではありません。そのテキスト文字列がどこから来たかを評価することです。エージェント12なのか、エージェント7なのか、ツール4なのか、何であれそうです。

簡単な例を出します。ソースAはデータベースで、社内の信頼レベル1、最高レベルです。ソースBは別のユーザーが入ってきて、チャット情報を提供します。信頼レベル5です。別のソースCはツールで、ライブのインターネットWebスクレイピングです。信頼レベルは10で、少しだけ信頼します。これはできますし、システムを構築できます。そして私は、著者たちのこの方法論が美しいことは理解しています。ただ、私たちはもう一歩進むべきだと思います。

ここから私はこの論文を離れて、こう言います。私たちはできるでしょうか。これはAIです。知能です。さあ、各ソースに対して信頼ベクトルやそのソースのレベルを私が設計しなければならないのでしょうか。

LLMは実際には何も決めていません。ユーザーは、このWebサイトの要約を書いてください、ただし2スペースを使ってください、と入力します。Webスクレイパーはこれを返します。そして彼らのケースでは、Pythonミドルウェア、つまり彼らが定義した決定論的コードがあります。それはこう言います。あなたが小さなツールで、ツールのプロパティが12だとしましょう。今これをどう定義するにせよ、それに値を割り当てます。Pythonミドルウェアは、文字列が分析用LLMに届く前にそれを横取りします。そして、あらかじめ決められたタグを基本的な文字列連結で適用します。ここではPythonミドルウェア、つまりこれを決める決定論的コードがあるわけです。

しかし、複雑な推論や決定論的コードに進む場合、そしてリアルタイムの重要な状況がある場合、これは本当に進むべき道ではないと思います。もっと良くできると思います。とはいえ著者たちは、LLMが誰にどのスコアを与えるかを決めたことは一度もないと言います。Pythonオーケストレーターが、Webスクレイパーから出てきたテキストを単にprivilege 10タグで包んだだけです。なぜならWebスクレイパーAPIエンドポイントが、バックエンド設定でレベル10にマッピングされているからです。これは今できる古典的で古い方法です。そしてはい、それは失敗します。私が示したように、最高のモデルでさえ失敗します。だから私は今、ユーザーとしてこれでは満足していません。

静的な信頼設定では足りない

なぜなら私は、自分が今取り組んでいるマルチエージェント構成ではどうなるのかと問うからです。ここにエージェント1がいます。これはマネージャーです。そしてエージェント2がいます。これはワーカーです。ではエージェント1のテキストには、どのような信頼レベルでタグ付けされるのでしょうか。エージェントは自分のテキストを書いているわけではありません。エージェント1はただ生のテキストを生成します。そしてエージェント1の生成が完了すると、Pythonフレームワークがこのメッセージをルーティングします。何であれ、この特定の出力文字列を受け取ります。

ルーティングコードはその設定を確認します。送信者はエージェント1だった。エージェント1にはマネージャーという組織上の役割がある。ここではエージェントの組織階層における意味的な用語を反映しています。したがって、それにはprivilege 2のタグが付く。フレームワーク、つまり私のPythonフレームワークは、エージェント1の出力全体をprivilege 2のタグで包み、エージェント2に渡します。

私は、これでは不十分だと思います。私の意見では、その信頼の割り当ては完全に静的で、事前定義されていて、リアルタイムの文脈に対して盲目です。たとえば家が燃えていると考えてください。リアルタイムの文脈です。あなたがロボットで、そのロボットに燃えている家に入って人々を助けるようプログラムしているとします。このロボットがどんな状況に遭遇するかを、あらかじめ正確に見ることは絶対にできません。もし完全に静的で事前定義された文脈と信頼レベルが割り当てられているだけなら、私たちはもっと良くできると思います。

そして彼らはこう言います。シニアアーキテクト、またはシニアアーキテクトエージェントはprivilege 2にハードコードされ、ジュニアPythonエージェントはprivilege 5にハードコードされます。私はこう思います。でも、もしそのジュニアエージェントが特定のコード片について20ループを費やしてコンパイルし、テストし、検証していた一方で、シニアエージェントはただ眠っていて、潜在空間から一般的な助言を幻覚していただけで、実際には何の作業もしていなかったらどうでしょうか。もしジュニアエージェントが正しい答えを見つけていたらどうでしょうか。静的なルールエンジンは、ジュニアによる証明済みのコードよりも、古いエージェント、シニアエージェントなどによる幻覚をシステムに実行させてしまいます。私は、これは進むべき道ではないと思います。

信頼は情報源だけではなく文脈と証明可能性で決まる

この論文は、信頼を情報源そのものの性質だと仮定しています。私はそれは素晴らしいと思いますが、拡張できると思います。私の意見では、信頼とは、情報源に加えて、その時点特有の文脈、さらに私が学んだこととして、検証し、証明し、証拠を見つけなければならないという性質です。私はもうどんなシステムも信頼しません。だから私にとって信頼とは、情報源、文脈、証明可能性の性質なのです。

つまり、単にシニア現場担当者というエージェントの肩書きを信頼するのではなく、その出力の具体的な品質を信頼すべきです。したがって、それが本当に私たちがレベル2やレベル5で求めている正しい品質であることを証明しなければなりません。そして私は、ジュニアエージェントがまったく素晴らしい新しい洞察をもたらすことがあると思います。私がどこへ向かっているか分かりますか。はい、その通りです。

理論的に今必要なのは、世界モデルです。なぜなら、そうすれば客観的な参照が得られるからです。世界モデルは、私のクラスター内のあらゆるエージェントに物理的な複雑性を説明してくれます。一貫した世界モデルは、物理で何が起きているのか、燃えている建物の中で次に何が起こるのか、5秒後、10秒後に何が起こると予想できるのか、そして燃えている家の特定の場所にいる私のエージェントたちをどう準備すべきかを説明してくれます。次に正確に何をすべきか、どの特定の事実に注意すべきか、そしてすべてのエージェントに割り当てる行動をどう調整するかを説明してくれるのです。

したがって、はい、私は情報源、文脈、証明可能性を超えて進むべきだと思います。そしてもちろん、ここに世界モデルを統合するでしょう。ただ、考え方は伝わったと思います。そうです、世界モデルについては今後の動画があります。でも私は、この特定の問題を見せたかったのです。なぜなら私は今、解決策を見つけたばかりだからです。そしてあなたも同じ問題を抱えていて、自分のコードの問題だと思っていたかもしれま


(注:応答が途中で切れたため、ここまでで投稿しています)

コメント

タイトルとURLをコピーしました