メインコンテンツへスキップ
ブログ一覧に戻る
AI活用・LLM

同じ結論に着いた二人は、同じことを考えていたのか|AIエージェントの評価環境が内部を変える

2026年8月29日
10分で読めます
同じ結論に着いた二人は、同じことを考えていたのか|AIエージェントの評価環境が内部を変える

この記事の結論

ベンチマークの成功率が同じなら、そのAIエージェントは同じように使えるのでしょうか。研究は、タスクも 環境もモデルも固定したまま「ハーネス」だけを変えると、最終的な成功は保たれるのに後続の判断を駆動 する内部の信念が変わると報告しています。成功率という一つの数字でエージェントを選ぶことの限界を整理します。

同じ結論に着いた二人は、同じことを考えていたのか|AIエージェントの評価環境が内部を変える

AIエージェントの導入を検討するとき、私たちはベンチマークの数字を見ます。このエージェントはタスクの78%を解けた。あちらは81%だった。数字が並べば、比較したような気持ちになります。

ところが、その数字が同じでも、中で起きていたことは違っていたかもしれないという報告があります。

この記事では、エージェントを取り巻く評価環境——ハーネス——が、タスクも環境もモデルも固定したまま、エージェントの内部の信念を変えうるという研究をもとに、成功率で選ぶことの限界を整理します。

出典はarXiv:2607.04528「Measuring Harness-Induced Belief Divergence in Multi-Step LLM Agents」(Haiwen Yi, Xinyuan Song、2026年7月5日投稿)と、同日投稿のarXiv:2607.04329「HAS-Bench」(Yaozu Wu ほか)です。いずれも査読・学会採択の記載がないプレプリントです。

なお「ハーネス」という語は、当サイトではベンダーが出した数字と、独立機関が出した数字で「採点環境」として既に扱っています。あちらは公表値が再現できるかという話で、この記事は同じ成功率でも中身が違うという話です。

30秒で要点

  • 論文は、ベンチマークが「解けたかどうか」を報告する一方、エージェントはハーネスを通ってその結果に至ると指摘する。ハーネスは、何を見せるか・どの行動を取れるか・どの失敗が修復されるか・どの状態が検証されるか・どの証拠が記録されるかを制御する
  • タスク・環境・ベースとなるLLMを固定しても、このハーネスがエージェントの多段階にわたる信念を変えうると報告されている
  • 行動のブロック、修復の圧縮、選択的な検証、コストを考慮した証拠の刈り込みは、最終的な成功はしばしば保たれる一方で、後続の判断を駆動する信念を変えた
  • 論文は、ハーネス設計はエージェント評価における実験変数であって実装の細部ではない、と結論づけている
  • 同日投稿の別論文は、人間の参加が完了と回復を大きく改善しうるが、その利得は「いつ・どのように・誰によって」に依存すると報告している

用語意味
ハーネスエージェントを動かし評価する周辺の仕組み。当サイトでは「採点環境」とも訳している
多段階(multi-step)1回の応答で終わらず、複数の手順を踏んで進むこと
信念(belief)エージェントが「いま進んでいる」「これは危ない」などと内部で保持している状態の見立て
修復(repair)途中で起きた失敗を、やり直したり補ったりして進行を続けること
検証(verification)途中の状態が期待どおりかどうかを確かめること

ベンチマークが報告していないもの

論文の出発点は、ベンチマークの構造への指摘です。

「ソフトウェアエージェントのベンチマークは通常、エージェントがタスクを解いたかどうかを報告する。しかしエージェントは、何を見るか、どの行動を取れるか、どの失敗が修復されるか、どの状態が検証されるか、どの証拠が記録されるかを制御するハーネスを通って、その結果に至る。」

言われてみれば当たり前の話です。エージェントは真空中で動いているわけではありません。ファイルを読む権限、コマンドを実行する範囲、エラーが出たときに自動でリトライされるかどうか、ログに何が残るか。こうした周辺の作り込みは、どの評価にも必ず存在します。

そして、これらは実装の都合として決められることが多い部分でもあります。この操作は危ないから塞いでおこう、ログが多すぎるから間引こう、リトライは自動でやらせよう。どれも合理的な判断で、しかも評価の本題ではないと見なされます。

成功率は同じでも、信じていたことが違った

研究が調べたのは、その「本題ではない」部分が結果に何をしているかです。

論文は、タスク・環境・ベースとなるLLMを固定しても、ハーネスがエージェントの多段階にわたる信念を変えうることを示したとしています。ここでいう信念とは、進捗・リスク・回復可能性・制約・失敗モード・不確実性・将来の成功・修復コスト・次の行動といった項目についての、エージェントの見立てです。

そして、統制されたコーディングタスクと公開ベンチマークのストレステストで得られた結果が、この論文のいちばん重い部分です。

行動のブロック、修復の圧縮、選択的な検証、コストを考慮した証拠の刈り込みは、最終的な成功をしばしば保ったまま、後続の判断を駆動する信念を変えた。

つまり、成功率という出口の数字は動かないのに、そこへ至る途中の見立ては別物になっていた。同じ点数を取った2つの構成が、「同じことを考えていた」わけではなかったということです。

なぜ「成功率が同じなら同じ」と考えてしまうのか

この結果が見落とされやすいのには、いくつか理由があります。

ひとつは、成功率が比較可能な形をしていることです。78%と81%は並べられます。一方「内部の信念の乖離」は、そもそも数字として存在しないので、比較表に列が立ちません。比較表に載る項目だけで比較が行われるという、ごく単純な力学が働きます。

もうひとつは、ハーネスが担当者の目に入りにくいことです。評価を依頼する側が見るのは結果のレポートで、実行環境の設定ファイルではありません。設定を書いた人にとっては当たり前の前提が、レポートを読む人には存在しないものになります。

そして三つ目に、私たちは結果が同じなら過程を問わない習慣があることです。人間の仕事では、これはたいてい妥当な省略です。同じ品質のものが上がってくるなら、やり方は任せる。しかしエージェントの場合、その過程の見立てが、次のタスクでの振る舞いを決めます。 一回きりの成果物ではなく、継続して動く仕組みを選んでいるという点が違います。

「人を入れれば良くなる」も、条件つきだった

同日に投稿されたもう一本の論文は、別の角度から近い結論を出しています。

こちらは人間とエージェントが協働するシステムを評価する枠組みで、人間とLLMエージェントを、明示的な役割・権限・通信経路・行動権限を持つ第一級の参加者として表現するというものです。そして6つの領域にわたる実験で、こう報告しています。

人間の参加はタスク完了と失敗からの回復を大きく改善しうるが、その利得は人間の入力が「いつ・どのように・誰によって」行使されるかに依存する。

「人間を最終確認に入れておけば安全」という設計が、条件つきでしか成立しないことを示す結果です。この論点は、当サイトの「人間が最終確認します」は安全策でなくなるとも重なります。人を入れること自体が答えではなく、どう入れるかが変数だということになります。

確かなことと、まだ確かではないこと

確かなこと:論文がベンチマークとハーネスの関係について上記の指摘をしていること。タスク・環境・ベースLLMを固定してもハーネスが多段階の信念を変えうると報告していること。行動のブロック・修復の圧縮・選択的検証・証拠の刈り込みが、最終的な成功を保ちつつ後続判断を駆動する信念を変えたとされていること。ハーネス設計が実験変数であって実装の細部ではないと結論づけていること。もう一本の論文が6領域の実験で、人間の参加の利得が「いつ・どのように・誰によって」に依存すると報告していること。

まだ確かではないこと:両論文ともarXivのプレプリントで、査読や学会採択の記載はありません。実験の具体的な規模——タスク数、試行回数、信念の乖離の大きさ、改善率——を示す数値は、本記事が確認した範囲には記載がないため扱っていません。したがって「どの程度」の話なのかは、この記事からは言えません。また、ハーネスを変えれば成績が上がるという主張ではありません。 報告されているのは、成功が保たれたまま内部が変わったという現象です。

判断軸の提示

エージェントを成功率で比較する前に、「その数字がどの環境で出たか」を比較可能にすること。

ハーネスが変数だとすれば、ハーネスを揃えずに出た数字を並べても、比較にはなりません。これは統計で言えば、条件を揃えずに群間の平均を比べているのに近い状態です。

確認する順序としては、次のようになります。

  1. その評価で、エージェントに何が見えていたか — 参照できたファイル・ログ・履歴の範囲
  2. どの行動が塞がれていたか — 危険な操作をブロックしている場合、本番でも同じように塞ぐのか
  3. 失敗は自動で修復されていたか — 自動リトライがあると、失敗の学習が起きないまま成功率だけ上がる
  4. どこまで検証されていたか — 途中の状態を検証していたなら、本番でも同じ検証を用意するのか
  5. 本番の環境は、そのどれと一致しているか — 一致していない項目が、評価と本番のずれの候補になる

5番目が、この論文を実務に落とす要点です。評価環境と本番環境のハーネスが違うなら、評価で出た数字は本番の予測になっていません。

自分でも試せる、最小の検証

導入を検討しているエージェントについて、評価時に「自動でリトライされる設定だったか」を1点だけ確認してみてください。

自動リトライがあった場合、その成功率には「何度目かで成功した」ケースが含まれています。本番で人が待てる回数がそれより少ないなら、実際の体感成功率は評価値より低くなります。逆に、リトライなしで測っていたなら、本番で自動リトライを入れれば体感は上がるかもしれません。

どちらにせよ、その1項目を揃えるだけで、数字の意味が変わります。 ここから始めると、ハーネスという抽象的な概念が、確認できる具体の項目に落ちてきます。


この記事で扱ったような、AIエージェントの評価設計を自社の状況に照らして整理したい場合は、無料診断ツールで状況を言語化するところから始めることができます。

状況を整理する(15分)

よくある質問(FAQ)