AIエージェントの成績は、モデルと検索・試行の組合せで比べる

構成を選ぶ問い

成績が上がった。その理由まで分かったか

社内手順書に基づいて回答するエージェントのモデルを替え、根拠が足りなければ再検索する手順も加える。 正しい回答が増えたので、新しいモデルが良かったと結論する。 だが、一度しか検索しない旧構成と比べているなら、追加検索の効果も混ざっている。 これは、比較方法を考えるための想定例である。

この場面には二つの問いがある。 仕事に使う構成としてどちらが良いか、そして何の変更が改善を生んだかだ。 前者には完成した構成全体の比較が役立つ。 後者にはモデル、情報の見せ方、検索や再試行を分けて調べる必要がある。 二つを混ぜると、次に直すべき箇所も、増えた費用の理由も分かりにくくなる。

本稿は、BrowserGym、RE-Benchと開発ツールから、その比較条件を具体化する。 設計とモデルを一般的な重要度で順位付けするのではなく、同じ仕事で何を変えると、どの負担で成果が良くなるかを問う。 構成の厚みやモデルの新しさだけで選ぶより、この問いが次の改善を決める材料になる。

観測できる情報

同じページでも、モデルに見えるものは違う

BrowserGymの論文初版は、ページの構造を表すDOM、アクセシビリティ用の木構造、画面画像などを観測として提供する。 それをどう加工してモデルへ渡すかは、エージェントの実装が決める。 観測と操作を共通の形式で扱う研究環境であり、異なる業務の難しさを同じにする製品ではない。

論文の例では、検索ボタンが自動補完のメニューに隠れ、クリックがエラーになる。 そのエラーは次の観測へ返される。 ページの文字だけでなく、重なりを見られる画像や、直前の失敗を受け取れるかが、次の行動を選ぶ材料になる。 操作に失敗したという結果から、モデルの計画能力だけが不足したとは決められない。

社内手順書の想定例でも、回答に必要な注意事項を検索結果から除いていれば、モデルはそれを使えない。 新構成で全文を渡し、旧構成で短い抜粋しか渡していない比較は、同じ情報でモデルを比べたものではない。 どの版の資料を、どこまで、どの形式で渡したかをそろえたい。

ただし、実際の構成を選ぶ比較では、各モデルに適した見せ方を使う選択もある。 その場合は、モデルと観測の組合せを比べたと説明する。 情報をそろえる比較と、使える構成の比較を区別すれば、片方を不当に弱い条件へ置くことも、改善をモデルだけへ帰属することも避けやすい。

道具と応答

同じ検索という名前でも、返される条件を確かめる

観測の差は、ブラウザーの画面だけに限られない。 検索ツールが本文と出典を返すのか、短い要約だけを返すのかでも、後段の回答は変わる。 古い資料を含む範囲や、閲覧権限、検索結果の件数も、比較の条件になる。

MCPの2025年6月18日版のツール仕様は、構造化出力と、ツールの失敗を表す結果を説明する。 出力の形式を明示できることは接続を調べる助けになる。 それでも同じ形式の応答が、同じ内容や網羅性を持つとは限らない。 接続方法が共通でも、検索の条件まで同等とは判断できない。

想定例では、旧検索が取得失敗を空の結果にし、新検索が失敗を明示するだけで、回答の停止判断が変わり得る。 この差を新しいモデルの慎重さと呼ぶと、再現に必要な条件を見落とす。 モデルへ渡った実際の本文、不足、失敗の情報を記録し、道具の交換も構成の変更として扱う必要がある。

時間と試行の配分

総予算が同じでも、一回を長くするか、回数を増やすかで違う

RE-Benchの初版は、七つの機械学習研究開発の環境で、時間と複数試行の配分を調べる。 合計八時間を配分する比較では、試した配分のうち、Modularという実行構成では三十分の試行、AIDEでは二時間の試行が最良だったと報告する。 同じ総時間でも、有利な分け方は実行構成によって異なった。

この比較は、複数試行から良い結果を選ぶ評価を含む。 点数が見えないScaling Law Experimentでは、選択はランダムとされる。 得られた最高点を、任意の一回で出せる成績とは扱えない。 また、限られた研究開発課題の結果から、社内問い合わせでも三十分や二時間が最適だとは言えない。

ここから取り入れたいのは、モデルだけでなく予算の使い方を比較することだ。 同じ検索を繰り返すのか、別の資料を探すのか、いくつかの回答を作って選ぶのかで、増えた時間の用途が違う。 再試行の上限だけを記録しても、何の改善を買ったかは分からない。

利用者の待ち時間と計算に使った総時間も分けたい。 複数の試行を並列にすれば、待ち時間は短くできても、計算量や選別の仕事は残る。 依頼から使える回答までの時間、呼び出しや検索の数、利用費用を一緒に見る。 予算の違う最高点だけを並べれば、仕事で使える構成を選ぶ判断から離れてしまう。

原因を分けて試す

モデルと再検索の四つの組合せを比べる

社内手順書の想定例へ戻る。 同じ質問集、資料の版、採点条件と総予算で、旧モデルと新モデル、一回の検索と不足時の再検索を組み合わせる。 まずモデルだけ、次に手順だけ、最後に両方を変えた構成を見る。 初期状態を戻して各構成を複数回試し、単発の成功だけで判断しない。 四つの構成を調べることで、改善を片方へ決めつけずに比較できる。

再検索が効くには、モデルが根拠不足を見つけ、別の検索を選ぶ必要がある。 新しいモデルはこの判断が得意で、旧モデルは同じ検索を繰り返すかもしれない。 これは仕組みを説明する仮説であって、特定のモデルで測った結果ではない。 相互作用があるため、片方ずつの改善を足して、組合せの成績を推定しない。

一方、実用構成の選定では、各構成を業務で認められる予算へ調整して比べてもよい。 その比較は、モデル固有の能力ではなく、調整した構成全体の成果を見る。 調整に使った質問と、最終判断に使う質問を分ければ、見慣れた入力へ答えを合わせただけの改善を見つけやすい。

採点と選別

良い候補を作るだけでなく、正しく選べるか

Anthropicのツール設計の解説は、成果を確かめられる課題と、実際の仕事を代表する評価、未使用の課題による確認を勧める。 本稿の手順書への回答なら、正しい設定値だけでなく、適用する製品の版と根拠が一致しているかを確かめたい。 資料を取得できないときの停止も、別に見る。

複数の回答を作る方法では、評価時に正解を知っている採点器が選ぶ結果と、本番で選べる結果を区別する。 正解を知らない利用者が、五つの候補から一つを選ぶ必要があれば、その確認作業も費用になる。 候補の中に正解があることから、正しい案内を渡せることへは、選別の確認が一つ残る。

平均点のほかに、どの質問で改善し、どこで悪化したかを読む。 再検索で根拠を集められた回答と、古い版の説明を混ぜて誤った回答を分ける。 途中で正しく停止した件数を、回答できなかった件数へまとめてしまえば、必要な停止を消す方向へ調整しかねない。 用途に合う成果条件が、構成の評価を決める。

構成を記録する

名前だけでなく、失敗した実行へ戻れる版を残す

AgentKitの発表は、手順の版管理と、実行記録を使う評価を示す。 Agent Builderはベータであり、機能があること自体は性能向上の証明ではない。 BrowserGymと併用するAgentLabも、実験の版情報や、観測・行動を読むための道具を説明する。 どちらも、構成と結果の対応を調べる材料になる。

想定例で残すのは、モデルと指示、資料と検索条件、時間・再試行の上限、実際の呼び出し、採点と選別の方法である。 担当者が誤った回答を見たとき、どの版の設定を案内し、何を取得できず、何を追加で探したかへ戻れるようにする。 記録を増やす目的は、構成の複雑さを示すことではなく、次に変える箇所を説明できることだ。

記録しても、完全な再現は保証されない。 BrowserGymの論文は、動くサイトの内容や地域設定などが結果へ影響する限界を挙げる。 自前の資料を固定した比較と、変化する実サイトでの確認を区別したい。 一度の固定条件で改善した結果を、そのまま将来のすべての画面や資料へ広げない。

採用の判断

次に増やすのは、モデルの能力か、必要な情報か

冒頭の新構成が良かった理由が追加検索なら、旧モデルにも同じ手順を試す価値がある。 同じ情報で新モデルが改善するなら、読み取りや判断の能力を替える価値を調べられる。 両方を組み合わせた場合だけ改善するなら、その相互作用と増えた費用を採用判断へ渡す。 特定の構成が必ず勝つという結論は、実際の比較前には出せない。

その判断には、正しい回答の数に加えて、利用者の待ち時間、誤りを見つける時間、根拠を探し直す負担を含める。 自動回答が増えても、担当者が製品の版をすべて確認し直すなら、業務の改善は小さいかもしれない。 モデル、道具、手順を比較する終点は、点数の説明だけでなく、受け取る人が次の作業へ進めることにある。