「人間より優秀」という点数は、私たちの業務にも当てはまるのでしょうか？
コンピューター操作型AIエージェントを検討していると、スライド1枚が判断を急がせることがあります。OSWorld-Verified 85%、人間のベースラインは約72%。ポータルへの入力やチケット処理を任せてもよさそうに思える数字です。
しかし、点数の横にベンチマークのバージョン、タスクの長さ、エージェント構成、許容ステップ数がなければ、まだ自社業務の成功率として読むことはできません。実際、公開されている85%とOSWorld 2.0の20.6%は、モデルからタスク、採点方法まで異なる結果です。両者の差はAIの能力が突然低下した証拠ではなく、何をどの条件で完了と見なしたのかを、まず確認すべきというサインです。
85%は「検証済みの公認スコア」ではありません
a16zは2026年8月10日の記事で、2026年6月時点の第三者OSWorld-VerifiedリーダーボードにおけるClaude Fable 5の85%というスコアを紹介し、約72%の人間ベースラインを上回ったと説明しました。 ただし確認したリーダーボードでは、Fable 5が85.0%、Claude Opus 4.8が83.4%と表示される一方で、登録された24件の結果はすべてself-reportedであり、独立してverifiedされた結果は0件と記載されています。
ここでの「Verified」はベンチマーク名の一部であり、表に掲載された個々の実行が独立検証されたことを保証するものではありません。Fable 5の元の実行レポート、タスク別結果、ハーネス、ステップ予算、再試行条件も公開ページでは確認できませんでした。したがって、85%はa16zが当時引用した第三者リーダーボードのスナップショットとして扱うのが正確です。
人間の72%という数字も、出所を区別する必要があります。2024年の元のOSWorld論文は、369件のタスクで人間の成功率72.36%、当時の最高モデルの成功率12.24%を報告しました。 この人間評価が、その後のOSWorld-Verifiedと厳密に同じタスク集合とプロトコルで再算出された値かどうかは、公開資料では確認できません。
20.6%は、より長い業務を「完全に終えたか」を問います
OSWorld 2.0は、名前だけを変えた同じ試験ではありません。研究、コンテンツ制作、ソフトウェア開発、ビジネス、金融などの実務を反映した長期タスク108件で構成されています。熟練者のタスク完了時間の中央値は約1.6時間で、69.6%は1時間を超えます。タスクあたりの採点チェックポイントは平均27.25件です。
この試験でClaude Opus 4.8は、500ステップ、maximum thinking、batched tool callsの条件で、二値の完了率20.6%と部分スコア54.8%を記録しました。 半分以上進んでいても、最終成果物を条件どおりに仕上げられなければ完全完了には含まれない、という違いが表れています。
長い業務では実行負荷も変わります。公式資料は、Claude Opus 4.7のmaximum thinking実行では平均ツール呼び出し回数が約318回だったと説明しており、OSWorld 1.0の約30回と対比しています。 これはすべてのモデルの平均ではなく特定構成の結果ですが、短いアプリ操作と複数ステップをつなぐ業務を同じ数字で比較しにくい理由をよく示しています。
| 公開数値 | 確認済みの条件 | そのままでは言えないこと |
|---|---|---|
| 85% | 第三者OSWorld-Verifiedリーダーボード上のClaude Fable 5の自己申告スコア | 独立検証済みで再現可能な結果、自社の長期業務における完了率 |
| 20.6% | OSWorld 2.0におけるClaude Opus 4.8の500ステップ条件での二値完了率 | Fable 5が同じ条件で64.4ポイント低下したという結論 |
| 54.8% | 同じOSWorld 2.0実行の部分スコア | 業務の54.8%が実務ですぐ使えるという意味 |
点数はモデル名ではなく、「評価条件の束」です
ベンチマーク結果を比較するには、少なくともベンチマーク系列・リリース・タスク集合・モデル・エージェントハーネス・ステップ予算・再試行・人の介入・採点指標がそろっている必要があります。1つでも違えば、数値は別の問いに答えている可能性があります。
リリースも見落としてはいけません。OSWorld 2.0の公式リポジトリは現在、osworld-v2-2026.08.08を推奨し、コード、タスク、アセット、ウェブサイトのバージョンを合わせるよう案内しています。このリリースでは14件のタスクが修正され、31件のタスクで評価の堅牢性と公平性が改善されました。 論文の20.6%がこの修正版リリースでもそのまま再現されるかは公開資料で確認できないため、リリースの異なる点数を1つの表に置いて順位付けしてはいけません。
1行で書けない点数は、まだ購入の根拠ではありません。
「OSWorld 85%」ではなく、「OSWorld-Verified、リリース未確認、Claude Fable 5、第三者リーダーボードの自己申告、ハーネス・ステップ・再試行は非公開」のように書いてみてください。空欄がそのままベンダーに尋ねる質問になります。
今日は、ベンダーの点数と実際の業務を1行ずつ照らし合わせましょう
新しい評価システムを最初から作る必要はありません。ベンダーが提示した原典リンクと、自動化候補業務1件の実際の記録を開き、次の順で比較してみてください。
- 点数の身分証を作ります。
ベンチマーク名とリリース、タスク集合、モデル、ハーネス、二値・部分スコアの区別、ステップ予算、再試行、人の介入の有無を1行に記載します。公開されていない項目は推測せず、「未確認」と残してください。 - 検証状態を別に表示します。
公式評価、独立再現、ベンダーの自己申告を区別します。ベンチマーク名に「Verified」が入っているだけで、個別結果まで検証済みと表示しないでください。 - 実際の業務の長さと分岐を書き出します。
たとえば保険ポータルでの請求なら、使うアプリ数、外部資料との照合、中間保存、例外発生時の質問、提出後の確認まで記録します。受付画面が表示された時点ではなく、追加補正なしに処理された時点を完了と見るのかも決めましょう。 - 完全完了と部分的な進捗を分けます。
パイロット表には「最終完了」「部分完了」「再試行回数」「人の介入」「実行後に見つかった失敗」を別々の列として置きます。部分スコアが高くても、後続業務を人がやり直す必要があれば、自動化完了には数えません。 - 条件差が大きい点数は参考値に下げます。
リリースやハーネスがなく、実行軌跡も公開されていなければ、性能保証ではなく候補選定の情報としてのみ使ってください。実際の購入判断は、同じ業務記録と成功基準で進めたパイロットで下します。
ベンダーの主張：OSWorld-Verified 85%
出所と検証状態：第三者リーダーボード / self-reported
ベンチマークリリース・ハーネス・ステップ・再試行：未確認
私たちの業務：保険ポータルの請求提出
完了基準：受付画面の表示ではなく、後続の補正なしに処理完了
エスカレーション：証券番号の不一致または追加確認の依頼時は担当者へ引き渡し
この記録を終えた時点での成功基準は、特定の点数を信じることでも反証することでもありません。ベンダーの点数を再現可能な条件で説明し、その条件と自社業務の違いを表示し、パイロットの完全完了率と人の介入を別々に数えられれば十分です。
a16zがベンダーへのインタビューを通じて紹介した導入事例も、システム記録の更新、ポータル間のデータ移動、チケット処理のように、範囲と完了条件が比較的明確な業務に集中していました。原文も、検証、権限、エラー処理、エスカレーションを重要な運用レイヤーとして挙げています。 ただし、紹介されたベンダー事例は試行総数、失敗率、独立検証資料を公開していないため、一般的なROIの根拠へと広げてはいけません。
さらに深く調べたいなら
OSWorld 2.0: Benchmarking computer-use agents on long-horizon real-world tasks 長期タスクの構成と、二値完了率・部分スコアの違いを確認できる公式プロジェクトです。 osworld-v2.xlang.ai
OSWorld-V2 README 現在推奨されるリリースと、コード・タスク・アセットのバージョンを一緒に固定すべき理由を確認するのに役立ちます。 github.com
OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments 2024年の元のOSWorldにおけるタスク数と人間・モデルのベースラインが、どこから来た数値かを追跡できます。 arxiv.org
