AIエージェントの実力は、ベンチマークだけでわかるのでしょうか？
AIが画面を読み取り、アプリを操作して仕事を進めるようになりました。性能を判断する問いも変わります。何を知っているかだけでなく、実際にどこまで仕事を終えられるかを確かめる必要があります。
昨日、OSWorldの共同著者Tianbao Xieとオンラインミーティングをしました。モデルのスコアと製品としての業務遂行能力の違い、そしてエージェントが進化するほど性能の測定が難しくなる理由について話しました。
OSWorld、実際のPC業務を試す
OSWorldは、AIに実際のOSやアプリを使って課題を実行させる評価環境です。2024年の原論文では、Ubuntu環境で行う369の課題が主な評価対象でした。Chrome、GIMP、LibreOfficeなどで設定を変更し、ファイルを編集し、複数の資料を行き来します。
評価は、初期ファイルと設定を用意するところから始まります。エージェントが作業を終えると、評価コードが実際のファイルや設定を確認します。AIの「完了しました」という返答ではなく、実行結果を採点します。
観察条件には、スクリーンショットや、画面要素の構造とテキストを含むアクセシビリティツリーなどがあります。与えられる情報や許される行動回数が違えば、結果も変わります。OSWorld原論文
長時間の業務で見える、完遂の難しさ
OSWorld 2.0は、108の長期ワークフローへと評価範囲を広げました。人間が課題を終えるまでの時間の中央値は約1.6時間です。
出張経費の精算では、規程のPDF、メールの領収書、銀行の記録、過去の報告書を照合します。新しいメールで条件が変われば計画を修正し、証憑に矛盾があればユーザーに質問しなければなりません。情報の整合性と作業の進行状況まで管理する課題です。
評価には、課題あたり平均27.25のチェックポイントがあります。すべての要件を満たした完遂率と、一部を処理した部分スコアを区別します。2.0論文の2026年6月24日リリース、スクリーンショットによる観察、500ステップ、行動の一括実行という条件で、Claude Opus 4.8 maxは完遂率20.6%、部分スコア54.8%を記録しました。OSWorld 2.0論文
AIの進化に追いつくベンチマーク
実際のアプリを使う評価は、環境の変化に左右されます。ウェブサイトが変わり、アプリの起動が遅れ、初期ファイルの状態がずれることがあります。機能的には同じ表計算の数式を、採点器が不正解と判定する場合もあります。
2025年のOSWorld-Verifiedでは、300件を超えるフィードバックを検討し、こうした問題を修正しました。スコアの変化には、モデルだけでなく、評価環境や採点方法の変更も影響します。OSWorld-Verified
Tianbaoは、先端研究所の進歩が加速するなか、V2はV1よりも早く性能差を見分けにくくなっていると評価していました。難しい課題を追加するだけで、評価の価値を維持できるのかも考えていました。
ここでいう飽和は、特定の先頭集団を区別する力が弱まることであり、すべてのモデルが現実のあらゆる業務を解決したという意味ではありません。研究上の次の限界を探る評価と、実際のユーザー業務での能力を予測する評価では、必要な課題が異なります。
同じモデルの性能を変えるハーネス
私は、モデル自体の性能と、実際のエージェント製品の能力を分けて考えるべきではないかと尋ねました。Tianbaoは「ハーネス（Harness）」も含めて見る必要があると説明しました。
ハーネスとは、モデルを動かす実行コード、ツールとの接続、観察と行動の仕組みです。何を見せ、どのツールを与え、選んだ行動をどう実行するかが含まれます。Codexの実行コードも、繰り返し改善されてきたシステムの一部だという説明がありました。
モデル同士を比べるなら、周辺条件をできるだけそろえる必要があります。一方、製品を比べるなら、各製品が実際に提供するツールや実行方法も含めるべきです。条件を統一するために接続機能を取り除けば、ユーザーが購入する製品の強みまで消してしまうことがあります。
評価では、モデルとハーネスの組み合わせ、実行条件を併せて示す必要があります。
何を見て、どう行動するのか
スクリーンショットを受け取るエージェントは、画像の中からボタンを探します。アクセシビリティツリーを受け取るエージェントは、構造化された要素やテキストを利用できます。
Tianbaoは、十分なアクセシビリティ情報があれば、視覚能力の限られたモデルでも作業できると説明しました。ただし、情報の欠落や遅延があるため、視覚情報だけを使うアプローチも長期的に重要だと考えていました。
行動の仕方も性能を変えます。Tianbaoが挙げたのは、入力欄が100個あるフォームでした。項目ごとにモデルを呼び出す方法と、コードで複数の入力をまとめて実行する方法では、やり取りの回数と遅延が異なります。途中で画面が変われば再び観察する必要があり、一括実行する範囲も設計しなければなりません。
同じ「500ステップ」でも、1ステップに許される作業量は異なる場合があります。APIやコマンドラインを使う製品と、画面をクリックする製品でも実行条件は違います。画面操作能力を測るのか、許された手段で業務を終える能力を測るのかによって、比較基準が変わります。
現地サービスとの接続が完遂を左右する
ミーティングでは、韓国や日本の個別の認証アプリ、承認手続き、外部接続の制限によって、購入や登録を終えにくい問題も話しました。Tianbaoは、現地サービスに対応するには、モデルに加え、接続機能、提携、運用面の準備が必要だと考えていました。
業務が止まったときは、原因を分ける必要があります。依頼を理解できなかったのか、画面を操作できなかったのか、必要な接続がないのか、それともユーザーの承認待ちなのかは、それぞれ別の問題です。
認証や接続の制約を評価から取り除けば、現実の業務を過度に簡単にしてしまいます。必要な確認を求め、確認後に作業を再開する能力も評価すべきです。地域別の評価には、指示文の翻訳だけでなく、実際に使われるサービスや業務手順まで反映する必要があります。
ユーザーを知るAIをどう評価するか
対話の後半では、継続学習が話題になりました。Tianbaoは、エージェントがユーザーの状況や好みを深く理解するほど、その文脈を別のサービスに伝え直すコストも大きくなると見ていました。
評価に当てはめると、新たな問題が生じます。毎回初期化すれば、蓄積された文脈の価値を見落とします。それぞれの履歴を残したままでは、同じ条件で比べることが難しくなります。初めて使う状態と、長く使った状態を分けて評価すべきかという問いが生まれます。
記憶を保存・検索する機能と、モデルの重みを更新する継続学習も異なる技術です。使ううちに性能が向上したなら、何が変わったのかを説明する必要があります。
スコアの先にある、実務能力の測り方
エージェントの性能表には、モデルとハーネス、課題のバージョン、観察情報と許可されたツール、実行に使える予算を併記する必要があります。結果では部分的な進捗と最終的な完遂を区別し、時間、コスト、ユーザーの介入、安全な遂行も見るべきです。
AIBが専門的な評価を一般のユーザーに伝える際も、この違いを消してはいけないと考えています。何を見て、どのツールを使い、どの環境で、誰の助けを借りて、どこまで終えたのか。それがAIエージェントの実力を説明する基準になるべきです。