現実の勤務日を想像してみてください。プロジェクトマネージャーはプロジェクトの状況を更新し、経理担当者は顧客の請求書を整理し、医療事務管理者は予約と保険情報を照合しなければなりません。
これらは高度な専門家のタスクではありません。多くの場合、きちんとしたインターンであれば、手順に従って完了できるものです。
しかし、今日のAIエージェントにとって、このような「日常業務」は見かけほど単純ではありません。ビジネス目標の理解、複数のアプリケーションを横断した情報検索、状態の一貫性の維持、そして数十、数百もの操作ステップを経て、すべての詳細をシステムに正確に反映させる必要があります。
これこそが、SaaS-Benchが明らかにしようとしている現実です。エージェントは単にボタンをクリックしたり、フォームに入力したりできるだけでなく、実際のオフィスでの長いプロセスの仕事を完了できなければなりません。インターンが日常的にこなせるタスクさえ安定して完了できないのであれば、私たちは再考する必要があります。本当に使えるエージェントまで、あとどれくらいの距離があるのかを。
Computer-Useエージェントの「シンギュラリティ」は到来せず、まず現実という冷や水を浴びせられたのです。
昨年、各社のGUIエージェントは競って人間の代わりに働けると主張しました。ベンチマークのスコアは急上昇し、投資家は興奮し、メディアは大騒ぎし、「全自動オフィス」が目前に迫っているかのようでした。
しかし、UniPat AIが一連のデータで証明したのは、これらすべてが砂上の楼閣に過ぎないということです！
23の実システム、106のタスク、過酷な実戦テスト
既存のエージェント評価は、端的に言えば、シミュレーション環境での単純なタスクをせいぜい数十ステップで完了するというものです。実際の仕事とは全く異なります。
実際のオフィスワークとはどのようなものでしょうか？医療事務管理者がSOAPカルテを作成し、症例報告を入力し、正式な文書を生成します。経理担当者が経費申請を処理し、承認し、支払いを行い、記帳します。複数のシステムを横断し、ステップ数は数百に及ぶこともあります。
SaaS-Benchのアプローチは非常に直接的です。実システムを直接Dockerに導入し、エージェントに現実のフロントエンドとバックエンドのロジック、データベースの状態、ビジネス制約の中で作業させるのです。
SaaS-Benchは、23のオープンソースSaaS（Software-as-a-Service）システムを厳選し、すべてDocker経由でローカルにデプロイし、完全なフロントエンドとバックエンドのロジック、データベースの状態、ビジネス制約を保持しています。対象分野は以下の6つの専門分野に及びます。
- ソフトウェア開発: OpenProject、Baserow、Code-Server、Metabase
- 経理・財務: Twenty CRM、BigCapital、HRMS、Pretix
- 医療管理: OpenEMR、OpnForm、OnlyOffice
- チームコラボレーション: SiYuan、Roundcube、Mattermost、ownCloud
- 農業サプライチェーン: FarmOS、Grocy、Recipya、E-Label
- インディーズメディア: PhotoPrism、MediaCMS、BookLore、Watcharr
さらに重要なのは、これらのシステムが「空のウェブページ」ではないということです。各ソフトウェアには、ユーザー、プロジェクト、注文、ファイルなどの実体レコードを含む、実際のビジネスデータが投入されています。エージェントが入っていくのは、白紙のテストページではなく、履歴データ、ノイズとなる要素、システム間の関連性を持つ、実際の作業環境なのです。
106のタスクのうち、93.4%が少なくとも2つのアプリケーションを横断し、3つのアプリケーションにまたがるタスクは全体の半分（53個）を占めました。純粋なテキストタスクは74個、マルチモーダルな理解を含むタスクは32個でした。Claude Opus 4.6の実行軌跡で推定すると、テキストタスクの97.3%で操作ステップ数が100ステップを超え、最長の軌跡は300ステップ以上に達しました。
これらのタスクはどのように作成されたのでしょうか？エージェントの操作能力はどのように評価されるのでしょうか？SaaS-Benchは、「LLMによる生成と専門家によるチェック」という方式でタスクを構築しています。
- まず、LLMが6つの専門分野と特定の職務役割に基づいてタスクを生成し、タスクの目標、アプリケーション間の依存関係、検証要件を明確にし、複数回の修正を経て曖昧さや抜け穴を減らします。
- 次に、専門家がタスクを手動で選別し、実際に実行してチェックします。この際、タスクが専門的で、自然で、完了可能で、検証可能かどうかを判断します。ステップの羅列、論理的な混乱、検証が不正確なタスクは修正または除外され、最終的にすべてのタスクが実際に実行可能で、検証器によって正確に評価できることを保証します。
SaaS-Benchでは、エージェントがBrowser-Useを使用してSaaS環境でコンピュータを操作することを許可し、以下の2つの指標を導入しています。
- Resolved Score (完全合格スコア、厳格): すべてのチェックポイントを通過した場合のみ1、それ以外は0
- Checkpoint Score (チェックポイントスコア、寛容): 重みに基づいて部分的なチェックポイントの達成率を計算
後述する結果が示すように、これら2つの数値間の大きな落差こそが、エージェントの中核的な問題を露呈させています。
ランキング発表：全滅
この数字を見てください。
最強のClaude Opus 4.7でさえ、チェックポイントスコアは43.9%、エンドツーエンドの完全合格スコアはわずか3.8%でした。106のタスクのうち、完全に完了できたのは4つだけです。Kimi K2.5とGemini 3.1 Proは？完全合格スコアはゼロでした。1つもタスクを完了できなかったのです。
この数字が示す意味は極めて残酷です。エージェントは作業の一部の中間プロセスを進めることはできますが、完全な長距離ワークフローを最後までやり遂げる能力はほぼ皆無なのです。
複数回の試行で救えるか？
各モデルを同じタスクで独立して3回実行し、1回でも通過すれば合格としました。pass@3はpass@1と比較して、全体で約8パーセントポイント向上しました。
Sonnet 4.6は、マルチモーダルタスクにおいて33.9%から52.1%（+18.2pp）へとジャンプしました。これは、完全に不可能なのではなく、実行が極めて不安定であることを示しています。
これは環境のランダム性によるものではありません。各実行の初期状態は完全に同一です。これは経路依存性であり、モデルがある分岐点でのわずかな違いによって、後続の軌跡が完全に分岐してしまうのです。
複数回実行することは役立ちますが、決して解決策ではありません。
複雑になるほど、スコアは低下する
3つの構造的次元すべてが単調減少を示しています。
- 横断アプリ数 1→4: 平均スコアは53%から20%に低下。
- 操作ステップ数の増加: タスクの軌跡が長くなるほど、スコアは著しく低下。
- チェックポイント数 ≤6 vs ≥18: 平均スコアは65%から27%に低下。
「アプリ横断＋長い軌跡＋きめ細かい検証」のタスクのスコアが最も低く、これこそがまさに実際のワークフローで最も一般的な形態なのです。
4つの構造的失敗：エージェントは一体どこで失敗するのか
SaaS-Benchの真の価値はスコアそのものではなく、実環境におけるエージェントの4つの致命的な欠陥を暴露したことにあります。
失敗1：タスクが長くなるほど、正しく実行できなくなる
たとえ各チェックポイントの通過率が95%と高くても、12個のチェックポイントをすべて通過する確率はわずか54%です。そしてSaaS-Benchの平均チェックポイント数は12をはるかに超えています。
すべてのモデルが同じパターンを示しました。通過率はタスクの進行とともに下降傾向にあり、後半になっても前期のパフォーマンスを維持できるモデルは1つもありませんでした。
これは不可逆的な下降曲線です。後半に行けば行くほど、完了できる可能性は低くなります。
失敗2：一歩間違えれば、すべてが狂う
典型的な事例です。タスクの要求は、「Arcturus Digital」という法人顧客を作成することでした。エージェントは担当者名と会社名を同時に入力し、個人顧客のロジックをトリガーしてしまい、実際に作成されたのは個人顧客の「Elena Vasquez」でした。
その後の10枚の請求書、支払い記録、口座照合は、すべて誤ったエンティティの下に作成されました。中核的なチェックポイントの重みはわずか3%でしたが、下流で30%の重みの損失を引き起こしました。
3%のエラーノードが、30%のスコア損失を引き起こしたのです。
失敗3：やりっぱなしでチェックせず、自己判断で「できた」と思う
Claude Opus 4.6は、Step 124で日付の誤り（2026-03-19 vs 2026-03-20）を特定し、修正を実行しましたが、ページに戻って再確認することなく、そのまま後続のサブタスクを進めました。Step 210での提出時には、「請求日2026-03-20、修正済み」と報告しましたが、画面上の実際の日付は03-19のままでした。
エージェントは意図のレベルでは成功したと考え、検証器は状態のレベルで失敗を発見します。この2つの間の断絶は構造的なものです。現在のCUAフレームワークには「厳密な内省の閉ループ」が欠けています。エージェントは、自分の宿題をチェックしない生徒のようなものです。
失敗4：同じ試験で、成績が大きく変動する
Claude Sonnet 4.6は、同一タスクの3回の独立した実行において、スコアが0.00から0.68までの範囲でばらつきました。これは環境のランダム性によるものではなく、毎回の実行の初期状態は完全に同一でした。経路依存性が原因です。モデルがある分岐点でのわずかな違いが、後続の実行軌跡を完全に分岐させ、長距離タスクにおけるエージェントの実行をギャンブルに変えてしまうのです。
これは何を意味するのか
SaaS-Benchは一つの幻想を打ち砕きました。エージェントのベンチマークスコアと実際の作業能力との間には、巨大なギャップが存在するということです。
4つの構造的な失敗パターン—後半になるほど正しくできなくなる、一歩間違えればすべてが狂う、やりっぱなしでチェックしない、毎回スコアが異なる—は、同じ根本的な事実を指し示しています。現在のエージェントには、永続的な状態に対する効果的な推論能力、操作後のフィードバック検証メカニズム、エラーから回復する能力が欠けているのです。
これらは、モデルを大きくしたり、いくつかのエンジニアリングモジュールを追加したりするだけで解決できる問題ではありません。それらは、現在のエージェントパラダイムのより深い限界を示しています。長距離タスクにおいて、モデルは全体的な状態に対する継続的な認識を欠き、人間のように「状況を把握している」ことができないのです。これは単なる技術的負債ではなく、現在のパラダイムの天井なのです。
Computer-Useエージェントが本当に人間の代わりに働けるようになるには？道のりはまだ遠いです。SaaS-Benchが地図を広げました。あとは各社がどのように進むかを見守るだけです。
しかし、これは同時に、徐々に形成されつつあるコンセンサスにもつながります。今日のSaaSは人間向けに設計されています。メニュー、ボタン、フォーム、すべてが人間の目と指のために作られています。しかし、エージェントが主要なユーザーになれば、これらのインターフェースは足かせになります。未来は、エージェントに人間のソフトウェアの操作方法を学習させることではなく、ソフトウェア自体がエージェントのために再設計されることにあります。SaaS-Benchが明らかにしたのは、エージェントの弱点だけでなく、現在のソフトウェアのあり方の賞味期限でもあるのです。人間向けのSaaSは、すべてエージェントのために作り直される必要があるかもしれません。
UniPat AIについて
UniPat AIは、現実のシナリオに根ざしたAIのトレーニング、評価、応用の新しいパラダイムの構築に取り組み、エージェント能力の様々な業界での大規模な実用化を推進し、確かな経済的・社会的価値を創出します。詳細は公式サイトをご覧ください：https://unipat.ai
© THE END
転載は本公式アカウントからの許可を得てください
投稿または取材のお問い合わせ: liyazhou@jiqizhixin.com