IBMのエージェント一貫性テストが示す、1回の成功だけでは不十分な理由

IBMのエージェント一貫性テストは、ベンチマークでの成功と信頼できる振る舞いの間に大きな隔たりがあることを明らかにした。GPT-4.1を搭載したエージェントはAppWorldの実行の77.4%を完了したものの、5回の試行すべてを成功させられたタスクは53.0%にとどまった。

この24.4ポイントの差は、エージェントのデモでいう「成功」の意味を変える。1回の正しい実行は、エージェントに必要な能力があることを示せる。しかし、翌日、あるいは5分後にユーザーが同じ結果を受け取れることまでは示せない。

IBM Researchは、ALTK-Evolveの新たな一貫性ガイドラインによって、この違いに取り組んでいる。このシステムは記録済みのエージェント軌跡から不安定な判断を見つけ、その弱点を再利用可能な指示へと変換する。初期結果は、信頼性の向上に必ずしもより大きなモデルを必要としないことを示唆している。

この研究は、ベンダーがエージェント性能を示す標準的な方法にも再考を迫る。リーダーボードの平均値は、頻繁に動作するエージェントを評価できる一方で、いったん成功した後にどれほど失敗するかを隠してしまう可能性がある。

IBMのエージェント一貫性結果が明らかにする、欠けていた指標

IBMの中心的な発見は、平均精度と再現可能な成功は、実質的に異なる2つの製品特性を表しているということだ。

研究者らは、GPT-4.1を基盤とするReActエージェントを、AppWorldのtest_normal分割に含まれる168タスクでテストした。ReActは、推論ステップと、アプリケーションの呼び出しや保存情報の検索といった行動を交互に行うエージェント設計である。

各タスクは新規の実行を5回受けた。IBMの一貫性研究によると、ベースラインのエージェントは77.4%のMean@5スコアを達成した。Mean@5は、5回の試行における成功率の平均である。

この数値は、強力な製品デモには十分に見える。しかし、このエージェントのPass^5スコアはわずか53.0%だった。Pass^5では、5回の試行すべてが成功した場合にのみ、そのタスクを成功と数える。

この結果の差が一貫性ギャップである。このケースでは24.4パーセントポイントに達した。最も難しいタスク群では、その差は30ポイントに達したとIBMは述べている。

この区別が重要なのは、Pass^5が一部のコーディング評価で用いられる一般的なPass@5指標とは異なるためだ。Pass@5は、5回の試行のうち少なくとも1回が成功したかを問う。Pass^5は、すべての試行が成功したかを問う。

これらの指標は異なる製品に適している。Pass@5は、システムが複数の候補を生成し、テストして、最良のものを残せる場合に有効だ。Pass^5は、各実行に信頼性が求められるワークフローに適している。

開発者がエージェントに5種類のコードパッチ候補を求める場合、1つの有効な回答から利益を得られる。取引照合をエージェントに依頼する経理チームは、4回の正しい実行と1回の損害を招くミスを安全に受け入れることはできない。

同じ問題は契約分析にも当てはまる。あるレビューでは義務を特定するが、別のレビューでは見落とすエージェントは、単にばらつきがあるだけではない。同一の証拠から一貫しないビジネス判断を生み出している。

IBMの結果は、GPT-4.1にこれらのタスクを実行する能力がないことを示すものではない。77.4%という平均は、しばしば実行できることを示している。結果が示すのは、この特定のエージェント構成では、その能力が反復実行において確実に維持されなかったということだ。

これが本記事の中心的な逆転である。最初の成功は可能性の証拠であって、運用上の信頼性の証拠ではない。

より広範な評価コミュニティも同様の結論に達している。Anthropicのエージェント評価ガイダンスはPass@kとPass^kを区別し、製品要件に合わせて指標を選ぶよう推奨している。

Anthropicは簡単な例を示している。1試行あたりの成功率が75%のタスクは、独立した3回の試行すべてで成功する確率が約42%になる。要件が時折の成功から途切れない成功へと変わるため、見かけ上の品質は低下する。

平均値にも依然として価値がある。全体的な能力を比較し、変更がタスクセット全体で結果を改善したかを明らかにするのに役立つ。だが、購入者がそれを信頼性の保証として解釈すると、誤解を招く。

エンタープライズ導入では、両方の数値が評価に含まれるべきだ。Mean@kはエージェントがどの程度の頻度で動作するかを示す。Pass^kは、反復利用においてどれだけのタスクが信頼できる状態に保たれるかを示す。

温度ゼロでもエージェントが判断を変える理由

プロンプト、モデル、ツール、デコーディング温度が変わっていないように見えても、エージェントは一貫性を失うことがある。

LLMは、確率分布から次のトークンを選ぶ。明確に優勢な選択肢を持つ判断もあれば、ほぼ同率の選択肢が複数ある判断もある。

IBMはこれを、鋭い判断と平坦な判断として説明している。鋭い分布では、確率の大半が1つの選択肢に集中する。小さな計算上の変化で勝者が変わる可能性は低い。

平坦な分布では、確率が複数のもっともらしい選択肢に分散する。ごく小さな数値上の変化によって最初に来るトークンが変わり、エージェントが別の経路へ進む可能性がある。

この違いは、ツールを使用するシステムで重要になる。1つの変更されたトークンが、APIの選択、検索クエリ、ツール引数、再試行判断、中間結果の解釈を変える可能性がある。

通常のチャットボットは、最終的な意味を変えずにある程度の表現揺れを吸収できる。エージェントは中間的な選択に基づいて行動する。変更された選択はそれぞれ、次のステップで利用できる情報を変える。

リスクは長い軌跡の中で複利的に増大する。エージェントが数十の判断を下す場合、そのいくつかは不安定な境界の近くにある可能性がある。後続のツール呼び出しや最終回答が失敗するには、1つが反転するだけでよい。

IBMはReActエージェントを温度0.0で実行した。そのため研究者らは、通常のサンプリングが観測されたばらつきの原因ではないと論じている。

温度ゼロでも、ホスト型モデルのすべての実行が数学的に同一になるわけではない。リクエストのバッチ処理、ハードウェアの挙動、浮動小数点演算、プロバイダー側の実装詳細が、確率をわずかに変化させる可能性がある。

こうした変化は通常のテキスト生成では見えないままにとどまることが多い。しかし、2つの選択肢がほぼ同率の場合には重要になる。ユーザーリクエストが変わらなくても、わずかな変化が順序を入れ替えうる。

固定シードにも限界がある。生成プロセスの一部は制御できるが、リモート推論システムのすべての層を固定することはできない。また、不確実な判断をより決定的にするものでもない。

この仕組みは、成功したリハーサルがライブデモで失敗しうる理由を説明する。エージェントが必ずしもタスクを忘れたわけではない。同じ意思決定ツリーの別の分岐に入ったのである。

たとえば、ノート内の完了済みアクティビティ数を数えるよう求められたエージェントを考えてみよう。ある実行では、すべてのチェックボックス記号を数えるかもしれない。別の実行では、チェックボックス形式を説明する凡例まで数えるかもしれない。

どちらの経路も、最初は合理的に見える可能性がある。意図した合計を出すのは一方だけだ。エラーはノートへのアクセス不足ではなく、文書をどう解釈するかという未解決の判断から生じる。

より長いワークフローはこの挙動を増幅する。リサーチエージェントは異なる情報源を選んだり、曖昧な日付を誤解したり、最初に一致した文書で停止したりする可能性がある。それぞれの選択が下流のすべてを形作る。

これは、AIエージェントの信頼性が部分的にはオーケストレーションの問題であることを示している。より優れたベースモデルは良い判断を下す確率を高められるが、境界的な選択が消えることを保証するものではない。

外部条件はさらに別の層を加える。ReliabilityBenchは、言い換えられたリクエストやツール障害とともに反復実行を評価する。その本番ストレスフレームワークは、一貫性、堅牢性、耐障害性を別個の次元として扱う。

IBMの現行実験は、より狭い範囲で反復実行を切り出している。この焦点により一貫性ギャップを検証しやすくなる一方、エージェントが本番環境で遭遇するすべての障害を表すものではない。

実際の導入では、変更されたデータ、期限切れの認証情報、APIレート制限、部分的なレスポンス、変化するスキーマに直面する。したがって、同一入力に対する安定した振る舞いは出発点となる要件であり、信頼性の基準全体ではない。

ALTK-Evolveは不確実性を的を絞ったガイダンスへ変換する

ALTK-Evolveは、すべてのタスクをライブ環境に対して再実行することなく、不安定な判断を修復しようとしている。

新しいプロセスは、1つの記録済み軌跡から始まる。軌跡とは、エージェント実行時に生成されたプロンプト、判断、ツール呼び出し、観測、応答の時系列記録である。

IBMのConsistency Analyzerは、そのトレースにすでに保存されたコンテキストを使って、各判断点を再検討する。複数の代替補完を要求し、モデルの選択がどの程度変動するかを測定する。

デフォルト構成では、判断ステップごとに追加のモデル呼び出しを1回行い、5つの補完を取得する。外部ツールの呼び出しを繰り返したり、タスク全体を再実行したりはしない。

この設計は本番環境で重要だ。完全な再実行は、別のメールを送信したり、レコードを二重に変更したり、購入を重複させたり、すでに変化したデータに遭遇したりする可能性がある。

オフラインでの再サンプリングは、そうした副作用を避ける。また、診断段階で正解ラベルを必要としない。

このアナライザーはブラックボックス方式であり、モデルのロジットや内部アクセスを必要としない。チームは、元のトレースを保持し、その判断コンテキストを再送信できれば、ホスト型モデルにも適用できる。

各判断には一貫性スコアが与えられる。補完結果が分岐するステップは、追加ガイダンスの候補となる。

ALTK-Evolveは次に、これらの候補を簡潔な行動指示へと変換する。そのより広い目的は、過去の軌跡から有用な教訓を抽出し、後続タスクでそれを取得することにある。

ノートの件数カウントの例では、生成されたガイダンスは基本的な部分文字列カウントではなく、行に固定した正規表現を推奨した。また、ノートを選ぶ前に複数の検索一致を確認するようエージェントに指示した。

これらの指示は、一般的な失敗パターンに対応する。元のタスクの正しい数値回答を単に保存するものではない。

この違いは本質的だ。1つの回答を記憶するだけでは、エージェントを強化せずにベンチマーク項目を改善することになる。再利用可能なルールであれば、新しいノート、異なるチェックボックス形式、関連する検索判断にも役立つ。

ALTK-Evolveリポジトリには、Consistency Analyzerとガイドライン生成コンポーネントが追加されている。このプロジェクトはApache 2.0ライセンスを採用し、Model Context Protocolを通じた統合をサポートしている。

その検索レイヤーは、推論時に関連するガイドラインをエージェントのコンテキストへ取り込む。これにより、過去のすべての軌跡をアクティブなプロンプトに残すことなく、モデルに的を絞った注意喚起を与えられる。

このアプローチは、焦点を絞った運用メモリの形態に似ている。エージェントに過去に行ったすべてを読み返させるのではなく、システムは繰り返し現れる教訓を抽出し、現在のタスクに関連するものを取得する。

この区別はナレッジワークにも重要である。より大きなアーカイブが自動的により良い判断を生むわけではない。有用な記憶には、選択、競合の処理、アクティブなリクエストに適したコンテキストが必要だ。

同じ原則は、適切に構造化されたAI knowledge baseの基盤にもなっている。保存された情報は、システムが作業コンテキストを過剰に埋めることなく、適切な証拠を取得できるときに価値を持つ。

ALTK-Evolveの手法は、汎用的なナレッジプラットフォームよりも対象が狭い。エージェントの振る舞いを対象とし、軌跡から導出したガイドラインを用いる。それでも両者は同じ制約を浮き彫りにする。情報を保持することは、それを適切な瞬間に適切に適用することより容易である。

この仕組みは、フィードバックループも生み出す。チームはトレースを収集し、不安定なステップを検出し、候補となるガイダンスを生成し、そのガイダンスが後続の実行を改善するかを評価できる。

ただし、このシステムによってテストが不要になるわけではない。生成されたルールは誤っていたり、過度に一般化されていたり、生成元となった状況以外では有害だったりする可能性がある。

チームには依然としてバージョニングとロールバックが必要だ。特にエージェントが規制対象の業務や財務上重要な作業を行う場合、どのガイドラインが判断に影響したかを追跡する必要もある。

信頼性の向上は大きいが、証拠の範囲は限定的

IBMは大幅な改善を報告しているが、この研究は主要なベンチマーク構成1件における初期評価にとどまる。

一貫性ガイドラインを追加した後、168件のAppWorldタスクにおけるPass^5は53.0%から69.0%へ上昇した。これは、5回すべての実行で合格したタスクの割合が16ポイント改善したことを示す。

Mean@5も77.4%から81.0%へ上昇した。その結果、一貫性ギャップは24.4ポイントから12.0ポイントへ縮小した。

この結果が重要なのは、平均値が低下していないためだ。エージェントを一貫して平凡な戦略に縛り付けることで再現性だけを高める手法では、根本的な問題は解決しない。

IBMによれば、ガイドラインはすべての難易度でMean@5を維持または改善した。中難度グループではPass^5が22.9ポイント向上し、高難度グループでは14.3ポイント向上した。

相対的な改善率は、中難度タスクで44%、高難度タスクで45%だった。簡単なタスクは改善余地が小さく、12.2ポイントの向上となった。

IBMは、同じAppWorldシナリオ内にある別の関連タスクでもガイドラインを検証した。Pass^5は13ポイント上昇し、同一タスクでの16ポイントの改善と比べられる。

この結果は、一部のガイドラインが記録された単一の軌跡を超えて転用できるという主張を裏付ける。ただし、無関係なアプリケーション、業界、エージェントアーキテクチャにまたがる広範な一般化を示すものではない。

2つ目の実験ではgpt-oss-120bを用いた。同一タスクにおけるPass^5は10.1%から16.1%へ上昇し、類似タスクの性能も8.7ポイント改善した。

低いベースラインは、ガイダンスが能力そのものを完全に代替できないことを示している。6ポイントの改善には意味があるものの、全実行での成功率が16.1%では、重要な自動化に適しているとは言えない。

完全な技術報告書には、これらの主張を支える手法が記載されている。それでも読者は、この結果を本番システム全体で独立して確認されたものではなく、著者らによる評価から得られた証拠として扱うべきだ。

主なテストでは、1つのReAct構成、1つの主要ベンチマーク分割、タスクあたり5回の反復を用いている。AppWorldは現実的な複数アプリケーションのシナリオを提供するが、ベンチマークはあくまで統制された環境である。

5回の実行は、1回の実行では見えない不安定性を明らかにする。しかし、数千件の顧客とのやり取りを通じて現れる可能性のあるまれな障害を正確に推定するものではない。

この評価は統計的な疑問も提起する。Pass^kは、試行が1回増えるごとに失敗の機会も増えるため、kの増加に伴って自然に低下する。

したがって、プロダクトチームは実際のリスク露出に基づいてkを選ぶ必要がある。5回連続の成功は妥当な開発時のスクリーニングになり得るが、エンタープライズ規模での信頼性を証明するものではない。

ガイドラインは古くなる可能性もある。APIは変わり、ポリシーは進化し、以前の回避策が新しいシステムの挙動と衝突することもある。

不安定な1つの分岐から導かれたルールが、別の場所で有効な選択肢を抑制するかもしれない。システムに蓄積されるガイドラインが増えるほど、競合解決と取得品質の重要性は高まる。

一貫した振る舞いと正しい振る舞いは別物でもある。同じ誤った行動を繰り返すエージェントは、行動上の安定性は完璧でも、タスクとしての価値はゼロだ。

IBMの実験は、Pass^5と並べてMean@5を報告することで、この問題に対処している。本番チームも同じ組み合わせを維持し、成果に固有の安全対策を追加すべきだ。

センシティブなワークフローでは、一貫した正確性を目標にしなければならない。安定性だけを、事実の正確さ、ポリシー順守、認可チェック、人によるレビューの代替にしてはならない。

より大きなモデルは、システムレベルの競争相手に直面している

新たな証拠は、信頼性の問題はまず基盤モデルの置き換えで解決すべきだという前提に異議を唱える。

モデルのアップグレードは、多くのタスクを同時に改善できるため、依然として魅力的だ。また、エージェントのメモリーや評価システムを再構築するよりも、個別の診断を必要としない。

しかし、より大きなモデルであっても、既存のエージェントがどこで不安定になるかを明らかにするわけではない。平均性能を引き上げても、時折の成功と繰り返しの成功の間に意味のある差が残る可能性がある。

IBMのアプローチは、これに対抗する経路を示している。モデルを変更するのではなく、高リスクの意思決定ポイントで与える情報を変える。

この比較は、厳密にはモデル対メモリーではない。強力なシステムは、能力の高いモデル、適切に設計されたツール、的を絞ったコンテキスト、決定論的なチェック、反復評価を組み合わせて用いる。

影響を受けるのは、依然として単一の成功率を報告しているエージェントベンダーとエンタープライズの購入者だ。Pass^kが調達の議論に入れば、高い平均値は証拠の一部にすぎなくなる。

購入者は、同じタスクを繰り返したか、環境をリセットしたか、すべての実行が許容可能な成果に到達したかを尋ねられる。単一の集計値ではなく、難易度別の結果を求めることもできる。

開発者も同様の変化に直面する。エージェントが一度失敗したというバグ報告は、求めても再現できないかもしれない。チームには、最初に分岐した判断を特定するための完全なトレースが必要になる。

オブザーバビリティはプロダクト品質の一部となる。保存されたプロンプト、ツール引数、結果、中間的な選択がなければ、不安定な実行は理由を説明しないまま消えてしまう可能性がある。

そのため、展開前から評価アーキテクチャが重要になる。チームには、代表的なタスク、統制された開始状態、明示的な成功基準、ばらつきを明らかにするのに十分な反復回数が必要だ。

また、再試行可能な作業と一度きりのアクションを分ける必要がある。下書きの生成は複数回の試行を許容できる。支払いの送信、ファイルの削除、契約の承認には、より厳格な制御が必要だ。

出力を自動的に検証できる場合、Pass@kは前者に適している。特にユーザーが最初の結果にも安全性を期待する後者では、Pass^kの方が多くを示す。

一部のワークフローは、どちらの指標だけにも依存すべきではない。取引エージェントには、不可逆なアクションを実行する前に、権限境界、冪等性制御、監査ログ、決定論的な検証も必要だ。

ガイドラインは不確かな推論を減らせるが、こうした安全策を置き換えるものではない。信頼できるエージェントは、モデルのスコアではなくシステムの特性である。

この結果は、キュレーションされた作業コンテキストの有用性も強めている。チームはすでにknowledge blendingを使い、保存された証拠と進行中の作業を結び付けている。エージェントのガイドラインは、この考え方を行動上の学びに適用するものだ。

重要なのは節度である。取得するコンテキストが増えるほど、注意散漫、矛盾、レイテンシーの増加を招く可能性がある。的を絞った指示に価値があるのは、正しいタスクに届き、不可欠な証拠を押しのけない場合に限られる。

ここに、ALTK-Evolveの長期的な課題がある。その診断機能は変動する判断を特定できるが、周辺システムは増え続ける学びの集合を管理しなければならない。

展開を成功させるには、有効期限ポリシー、競合検出、来歴、ガイドライン変更に対する評価が必要になる。そうでなければ、昨日の修正が明日の隠れた障害源になりかねない。

IBMのアプローチが持続するかを示すもの

一貫性ガイドラインが標準的なエージェント層になるのか、それとも有望なベンチマーク技術にとどまるのかは、3つのシグナルによって決まる。

第1のシグナルは、他のベンチマークやエージェントアーキテクチャにおける独立した再現だ。研究者は、ブラウザーエージェント、コーディングエージェント、カスタマーサービスシステム、実際のAPI障害を伴うワークフローでこの手法を検証すべきだ。

Pass^5の16ポイント改善が再現されれば、IBMの中心的な主張はより強固になる。改善が小さい、または一貫しない場合は、AppWorldにガイドラインによる修復に特に適した失敗パターンが含まれていることを示唆する。

比較には複数のベースモデルを含めるべきだ。また、トークン使用量、レイテンシー、アナライザーのコスト、取得のオーバーヘッド、タスクあたりに注入されたガイドライン数も報告すべきである。

第2のシグナルは、より長い期間にわたる性能だ。有用な学習システムは、競合するルールや古いルールを蓄積することなく、新たなガイダンスを扱えなければならない。

チームは、数百または数千の軌跡の後でも利点が維持されるかを測定すべきだ。また、ストアが拡大してもガイドラインの取得が正確であり続けるかを検証すべきである。

1つのガイドラインセットを固定し、その後のアプリケーションバージョンに対してテストする評価に注目したい。強い性能は、ルールが持続的な振る舞いを捉えていることを示す。急速な低下は、保守負担を露呈させる。

第3のシグナルは、反復実行レポートの採用だ。ベンダーのスコアカードは、kを明確に示したうえで、Mean@kとPass^kを併記すべきである。

この変化により、購入者は頻繁に成功するモデルと、確実に成功するシステムを区別できるようになる。また、1回の好条件な実行を中心に構築されたデモンストレーションを抑制することにもなる。

この分野はさらに進むべきだ。反復に加え、言い換えや統制されたツール障害も組み合わせる必要がある。同一のプロンプトは、本番環境で生じる圧力の一種にすぎない。

IBMの研究は、1回の成功だけでは基準として弱すぎることを説得力をもって示している。また、現実世界のすべてのアクションを繰り返さずに、不確実性を特定する実用的な手法も提示している。

残る疑問は、こうした改善が研究環境の外でも持続するかどうかだ。開発者は、自身の重要なワークフローを再実行し、完全なトレースを保存し、全実行での成功を測定することで答えられる。

エージェントが重要な業務を扱うなら、タスクを完了したかだけを問うべきではない。同じタスクを正しく完了する頻度、どの判断が変動するか、そして昨日のガイダンスが明日の条件に直面したときに何が起こるかを問うべきだ。