長いOffice作業はGUIだけでは崩れる。OmegaUse-OfficeValが示したコード操作と成果物検証の重要性
WordやExcelの操作をAIに任せるとき、多くの人が思い浮かべるのは、人間のように画面を見てクリックする姿でしょう。
ところが、数時間かかるOffice作業を集めた新しい評価では、GUIだけを使う方式のスコアが0.78まで落ちました。同じモデルにコード操作を許すと14.41です。単純計算で18倍以上の差があります。
ただし、ここで「画面操作はもう不要」と結論づけるのは早すぎます。別のOffice評価では、GUIとコードを組み合わせた方式が最も高いスコアでした。
大切なのは、AIにどの道具を持たせるかだけではありません。仕事の種類に応じて道具を切り替え、最後にできあがったファイルを独立して検査することです。
この問題を、Baiduの研究チームが公開したOmegaUse-OfficeValから読み解きます。2026年8月18日に公開されたv2では、コード操作とGUI操作を直接比べる実験が追加されました。
クリック回数では、仕事の完成度を測れない
従来のcomputer-use評価には、短い操作をうまく実行できるかを見るものが多くあります。
メニューを開く。セルを選ぶ。ボタンを押す。ファイルを保存する。こうした局所的な動作は、画面を操作するAIの基礎能力を測るうえで欠かせません。
しかし、実際の仕事はそれだけでは終わりません。
たとえば、複数の資料から情報を集め、指定された書式のWord文書へ移し、表の崩れを直し、目次を更新し、編集可能な状態で納品する。途中のクリックが正しくても、最後の文書が壊れていれば仕事は未完成です。
長い作業ほど、小さな失敗が積み重なります。途中で選択範囲を間違える。ページをまたぐ表の設定が消える。別の箇所の書式まで変える。保存形式を誤る。見た目は近くても、数式や構造が壊れていることもあります。
そこでOmegaUse-OfficeValは、操作の軌跡ではなく、最終成果物を評価対象にしました。
100件の仕事を、できあがったファイルで採点する
OmegaUse-OfficeValには、Officeを使う長時間タスクが100件あります。元になったのは実務者から集めた1,715件の提案です。実務性、明確な納品物、人間が完了できるかといった条件で絞り込み、最終的に100件が残りました。
入力ファイルは合計220個です。Word、Excel、PowerPoint、PDFに加え、画像、動画、音声も含まれます。期待される出力は115ファイルあります。
1件あたりの人間の作業時間は平均2.32時間、中央値2.03時間、最長8.35時間です。数分の小技ではなく、状態を保ちながら作業を続ける必要があります。
各タスクには、次の材料がそろっています。
- 自然な依頼文
- 作業に必要な入力ファイル
- 人間が完了するまでの時間
- 依頼の価格を表すproxy値
- 細かな採点rubric
- 最終ファイルを検査する実行可能なverifier
採点rubricは全体で2,009項目です。納品物が開けるか、必要な形式か、指定された変更が入っているか、関係ない部分を壊していないかを確認します。利用可能性の必須条件を一つでも落とすと、そのタスクは0点になります。
これは厳しい仕組みです。ですが、仕事では「半分できた壊れたファイル」がそのまま価値になるとは限りません。途中の動きより、手元に残った成果物を確認する設計には実務的な意味があります。
AIは安くて速い。それでも人間の品質には届かなかった
研究チームは複数の2026年モデルを同じ評価へかけ、人間の作業結果と比べました。
平均スコアは人間が27.79です。最も高かったLLMはGLM-5.2の17.91でした。次いでQwen3.7-Plusが17.51、Kimi K2.6が17.00です。
一方で、時間と費用はAIが大きく下げています。
人間は1件あたり平均2.324時間、価格proxyは6.8560ドルでした。Qwen3.7-Plusは平均0.193時間、推論費用は0.2152ドルです。DeepSeek-V4-Proは0.184時間で、比較したモデルの中では最速でした。
ここで注意したいのは、安さと速さが、そのまま完成度になっていないことです。
人間は21%のタスクで50点を超えました。LLMの中で完全な0点が最も少なかったQwen3.7-Plusでも、0点は38%あります。DeepSeek-V4-Proは50%、MiniMax M3は51%でした。
つまり、現在のAIは作業単価と待ち時間を減らせても、長いOffice作業を安定して納品する段階にはまだ達していません。速い未完成品を量産しても、確認と修正で人間の時間が戻ってくれば、節約分は簡単に消えます。ここ、経理より先に胃が痛くなるやつです。
高得点のモデルと、高い価値を拾うモデルは同じではない
この評価のもう一つの特徴が、作業時間と価格をタスクごとに持っていることです。
通常の平均スコアではGLM-5.2が17.91で首位でした。しかし、人間の作業時間で重みを付けたスコアと、価格proxyで重みを付けたスコアではQwen3.7-Plusが最も高くなりました。
これは小さく見えて重要な違いです。
簡単で安い仕事をたくさん解けるモデルと、時間のかかる重要な仕事で部分的に前進できるモデルは、同じ平均点でも価値が異なります。導入判断では、タスク数だけでなく、削減できる人手時間や、失敗したときの手戻りも見る必要があります。
ただし、価格proxyを実際の市場価格と同一視してはいけません。実務者が明確な価格を示したタスクは約20%です。残りは3人の専門家による推定です。経済性を考える入口としては有用ですが、導入先の給与、外注単価、確認コストに置き換えて計算し直す必要があります。
v2で見えた、GUIだけでは長時間作業が崩れやすい理由
2026年8月18日のv2では、Kimi K2.6を共通のbackboneにして、3つの行動方式を比べる実験が追加されました。
- Hybrid：GUIとコードを使い分ける
- Coding-Only：コードによるファイル操作だけを使う
- CUA-Only：画面を見てGUIだけを操作する
OmegaUse-OfficeValでの結果は、Coding-Onlyが14.41、Hybridが13.77、CUA-Onlyが0.78でした。
長いファイル変換では、コード操作に利点があります。大量のセルや段落をまとめて処理でき、条件分岐を明示でき、同じ操作を繰り返しても結果がぶれにくいからです。処理前後のファイル構造を機械的に比較することもできます。
GUIだけの方式では、一つずつ画面をたどる必要があります。対象が増えるほど操作列が長くなり、視覚的な位置合わせや選択ミスが累積します。途中の一手がずれると、その後の操作が正しくても別の場所を編集し続ける可能性があります。
では、すべてコードで処理すればよいのでしょうか。
同じ3方式をOSWorldのOffice関連タスクで比べると、Hybridが77.58で首位でした。CUA-Onlyは68.90、Coding-Onlyは55.62です。
2つのbenchmarkはタスクも採点方法も異なるため、14.41と77.58を横に並べて性能差を語ることはできません。比較できるのは、それぞれのbenchmark内での順位です。
ここから分かるのは、最適な道具が仕事によって変わるということです。ファイル内部の構造を正確に変えるならコードが強い。見た目を確認し、アプリ固有の操作を行うならGUIが必要です。混合タスクでは、両方を切り替えるrouterが重要になります。
実務では、操作方法より先に検証方法を決める
この研究を実務へ持ち込むなら、AIにいきなりOfficeを触らせる前に、完了条件を決めるべきです。
おすすめは、作業を三つの層に分ける方法です。
1. 依頼を、構造操作と視覚判断に分ける
まず、何を変える仕事かを分解します。
構造操作には、表の行追加、数式の設定、見出しstyleの統一、複数ファイルからの転記、metadataの更新などがあります。これはdocument APIやscriptに向いています。
視覚判断には、図の重なり、余白のバランス、画像の見切れ、スライド全体の読みやすさなどがあります。これはrenderした画面やページ画像の確認が必要です。
両方が必要な仕事は、コードで大半を処理し、GUIや画像確認で仕上げる混合型にします。
2. 変更を小さく区切り、途中成果物を残す
長い作業を一度に実行させると、どこで壊れたか分からなくなります。
元ファイルを保持し、変換ごとに新しい成果物を出し、各段階で最低限の検査を行います。ファイルが開くか、必要なsheetやheadingが残っているか、数式の件数が変わっていないかなど、安い検査を先に通します。
問題が起きたら、全工程ではなく失敗した段階だけをやり直します。
3. 最後は別系統の検査で合否を決める
作業を行ったagent自身に「できた？」と聞くだけでは不十分です。
WordやExcelの構造はparserで確認し、PDFやスライドはrenderして画像でも確認します。重要な数値は元資料と照合します。公開や送信が伴う場合は、人間の承認を最後に残します。
作業経路と合否判定を分けると、agentが自分の失敗を自分で見逃す問題を減らせます。
小さく試すための4マス実験
自社の作業でAIが使えるかを確かめるなら、いきなり100件を用意する必要はありません。
実際によく起きるOffice作業を12件ほど選び、次の4条件に分けます。
| 条件 | 実行方法 | 最後の検査 | | — | — | — | | A | GUIだけ | 人間の目視だけ | | B | コードだけ | 構造検査だけ | | C | GUIとコード | 構造検査と画像確認 | | D | 人間 | 同じ合格条件 |
各タスクについて、完成度、作業時間、推論費用、確認時間、修正回数を記録します。さらに、完全失敗を0として数えます。
この実験で見るべきなのは、AI単体の速度ではありません。
「AIの実行時間＋人間の確認時間＋修正時間」が、人間だけで作業した時間より短いか。失敗した成果物が外部へ出る危険を抑えられるか。ここまで含めて初めて、導入価値が見えます。
このbenchmarkにも見落とせない限界がある
OmegaUse-OfficeValは公開範囲が広く、検証codeまで確認できる点が魅力です。それでも、結果をそのまま一般化はできません。
まず、100件は世界のOffice作業から無作為抽出されたものではありません。教育と試験のタスクが25%を占め、business operationsが20%です。業種や国が変われば、文書構造も品質基準も変わります。
人間の27.79点も、人間一般の能力を示す数字ではありません。厳しいrubricのもとで、募集した20人のannotatorが作った成果物を測った値です。人間でも29%のタスクが0点でした。
また、code verifierがあるからといって、品質を完全に測れるわけではありません。rubricに書かれていない見た目の違和感や、文章の自然さ、依頼者の暗黙の意図は見逃す可能性があります。
公開されたverifierのうち91件は通常のcross-platform modeで動きますが、9件はWindows上のMicrosoft Office COMが必要です。macOSやLinuxのautomatic modeでは、この9件がskipされます。
そして、今回のモデル比較をAICompany側で100件すべて再実行したわけではありません。論文、公式project page、公開code、datasetを照合した結果として読む必要があります。
結論：強いOffice agentは、画面を真似るだけでは作れない
OmegaUse-OfficeValが示したのは、AIが人間より安く速くOffice作業を進められる場面が増えても、納品品質にはまだ大きな差があるという現実です。
v2の追加実験は、その差を縮める方向も示しています。長い構造編集ではコードを使い、視覚的な判断が必要な場面ではGUIを使う。そして、どちらで作業したとしても、最後は成果物そのものを別系統の検査に通すことです。
人間らしくクリックできるかより、壊さずに仕上げ、検証可能な形で渡せるか。
Office agentを実務へ入れるときの評価軸は、そこへ移りつつあります。