Holo4：汎用コンピュータ利用エージェントを駆動、ただしベンチマークの隔たりは依然重要
Holo4は9月28日、2つのモデル、4つの対話モード、そして特化型コンピュータ利用システムへの直接的な挑戦とともに登場した。H Companyは、Holo4: powering generalist computer-use agentsを、画面の操作、コードの実行、ソフトウェアツールの呼び出しを1つのモデルファミリーで担えるものだと説明している。
このリリースが重要なのは、コンピュータ自動化が1つのインターフェース内にとどまることはほとんどないためだ。業務プロセスはブラウザで始まり、APIを経由し、最新の統合機能を持たないデスクトップソフトウェアの中で終わることもある。ほとんどのエージェントシステムは、異なるモデル、ツール、制御ループを組み合わせて、この移行に対応している。
Holo4は、より単純な道筋を提示する。同じモデルが、グラフィカルインターフェース、コード、Model Context Protocolツール、APIの間で選択できる。MCPは、AIシステムが構造化された接続を通じて外部ツールやデータにアクセスできるようにする標準だ。
この約束により、Holo4は単なる別のモデルベンダーではなく、特化型アーキテクチャと対峙することになる。特化型のアプローチでは、視覚的ナビゲーション、コーディング、ツール呼び出しにそれぞれ別のモデルやポリシーを割り当てる。H Companyは、訓練済みの単一汎用モデルなら、これらの領域をより効率的に調整できると主張している。
同社はまた、数千件のベンチマーク用トラジェクトリを検証可能な形で公開した。この透明性により、開発者はリーダーボードのスコアだけでは得られない証拠を手にできる。ただし、実際の組織内における信頼性、安全性、性能をめぐる疑問が解消されるわけではない。
4つのインターフェースをまたぐHolo4：汎用コンピュータ利用エージェントを駆動
中心となる変化はアーキテクチャにある。Holo4はインターフェースをエージェントを囲む固定的な境界ではなく、タスク内で選択する対象として扱う。
Holo4 releaseによれば、このファミリーには、密な270億パラメータモデルと、350億パラメータのMixture-of-Expertsモデルが含まれる。後者は、各推論ステップでおよそ30億のパラメータを有効化する。
Mixture-of-Expertsモデルは、すべてのパラメータを有効化するのではなく、入力を選択された内部コンポーネントに振り分ける。この設計は計算量を抑えられる可能性があるが、実際の速度はハードウェア、ソフトウェア、デプロイメントの選択に左右される。
両方のHolo4モデルは、グラフィカルユーザーインターフェースとの対話、コードの記述・実行、MCPまたはAPIツールの呼び出しが可能だ。H Companyは、同じモデルがデスクトップ、Webサイト、Androidデバイス、コーディングサンドボックス、業務システムを操作できるとしている。
これは、スクリーンショットからマウスクリックだけを予測するエージェントとは異なる。また、アプリケーションにAPIがないと機能しなくなるツール呼び出しモデルとも異なる。Holo4は、ワークフローの変化に応じて手法を切り替えるよう設計されている。
日常的な財務業務を考えてみよう。エージェントは文書から項目を抽出し、コードで正規化し、API経由で送信し、画面上で結果を確認するかもしれない。旧来の業務ソフトウェアでは、さらにマウスとキーボードによる操作へ移行せざるを得ない可能性がある。
汎用モデルなら、これらの段階を通じて1つの意思決定プロセスを維持できる。特化型スタックでは通常、各段階を別のモデル、ポリシー、サービスへ振り分ける。このルーティングは制御性を高めうる一方、引き継ぎや障害点も増やす。
H Companyによれば、Holo4は生成された対話環境全体で、教師あり学習と強化学習を通じて訓練されたという。同社の内部タスクファクトリーは、Webアプリケーション、デスクトップ、MCPサーバー、ハイブリッド環境を対象に、約10,000件のタスクを生成したとされる。
こうした生成タスクが重要なのは、静的な例ではエージェントの行動がもたらす結果を再現できないためだ。対話環境では、クリックによって状態が変化したか、コードが実行されたか、API呼び出しが意図したレコードを生成したかを検証できる。
このアプローチにより、H Companyはドキュメントやスクリーンショットからもタスクを生成できる。すべてのワークフローを手作業で設計せずに、訓練対象を広げられる可能性がある。ただし、生成環境は、権限、遅延、想定外の状態を伴う複雑な本番システムとは依然として異なりうる。
このリリースには、2つの主要なHolo4バリアントに加え、更新版のHolotron4 Nanoモデルも含まれる。また、BF16、FP8、NVFP4、4ビットGGUFを含む複数の形式でモデルウェイトを提供している。
これらの形式で利用できることで、開発者には複数のデプロイメント選択肢が与えられる。それでも、より重要な主張は、外部のモデル選択レイヤーなしに、1つのモデルが複数のインターフェースを調整できるという点にある。
これは、Holo4: powering generalist computer-use agentsを、特化型エージェントが提供する精度を犠牲にせず、インターフェースの汎用性によってシステムの複雑さを低減できるかを試すものにしている。
長いワークフローが特化型エージェントスタックに圧力をかける理由
Holo4が特化型スタックに圧力をかけるのは、長いワークフローではルーティング判断、コンテキストの引き継ぎ、復旧手順ごとのコストが増幅されるためだ。
短いブラウザタスクでは、アーキテクチャ上の弱点が隠れうる。エージェントは1つのページを開き、値を入力し、フォームを送信するだけかもしれない。脆弱なシステムでも、その一連の操作を完了できる場合がある。
プロフェッショナルな業務はそれとは異なる。複数のアプリケーション、持続する状態、曖昧な指示、実行中に現れる情報を含む。エージェントは、後続の事象に適応しながら、先行する制約を記憶しなければならない。
OSWorld 2.0は、このより困難な状況を念頭に設計された。研究者らは、日常業務と専門業務にまたがる108件の長期ワークフローを構築した。熟練した人間でも、各タスクの完了には中央値で約1.6時間を要する。
このベンチマークでは、主要エージェントが1つのワークフロー当たり平均300ステップを超える可能性が報告されている。OSWorld 1.0のタスクはおよそ30ステップであり、新しいベンチマークはコンテキスト管理に対してはるかに厳格な試験となる。
失敗は不正確なクリックだけにとどまらない。研究者らは、エージェントが制約を見失う、届いた情報を見落とす、確認が必要な場面で推測する、検証を省略するといった問題を観察した。こうした弱点は、長いプロセスの中で複合的に悪化しうる。
H Companyは、これらの問題を受けてHolo4のエージェントハーネスを再構築したとしている。ハーネスとは、観測を提供し、コンテキストを管理し、アクションを実行し、結果をモデルに返す実行ループのことだ。
最も注目すべき追加要素は、数百ステップにわたる永続メモリと、デスクトップマシン上で動作するシェルだった。このシェルにより、直接的なGUI操作が非効率になった場合に、エージェントはコードベースの経路を利用できる。
ここで、汎用設計は単なる機能一覧を超える。モデルは、ローカルファイルをコードで解析する方が視覚的に読むより望ましいと判断できる。その後、視覚的な確認が必要なアクションのためにインターフェースへ戻ることもできる。
特化型スタックでも同じ順序を実行できる。ただし、いつ制御を移すか、各移行にどれだけのコンテキストを伴わせるかを判断しなければならない。誤ったルーティング判断は、ステップを無駄にしたり、情報を失わせたりする可能性がある。
Holo4は、その判断を訓練済みモデルの内部に置こうとしている。このアプローチが一貫して機能するなら、開発者はブラウザ操作、デスクトップ操作、コード実行、構造化ツールを調整するために必要なロジックを減らせる可能性がある。
ただし、これでオーケストレーションが不要になるわけではない。本番システムには、依然として認証情報管理、サンドボックス化、リトライ、ログ、承認ゲートが必要だ。また、不確実な操作が損害を引き起こす前にエージェントを停止する信頼できる手段も必要となる。
変化の範囲は限定的だが、それでも意味はある。開発者は、各インターフェースをどのモデルが担当するかの判断に費やす労力を減らせるかもしれない。その分、権限の定義、出力の検証、完全なワークフローの測定に集中できる。
この違いは、searchable knowledge baseを構築するチームにとって重要だ。そのワークフローは、ローカル文書、社内検索、ブラウザツール、構造化された社内システムをまたぐことが多い。
Holo4は、汎用モデルがすべての特化型モデルを置き換えることを証明するものではない。むしろ、特化型ルーティングを避けられない基盤ではなく、開発者が正当化すべき設計上の選択肢にする。
1つのエージェントモデルはより単純だが、信頼性の基準は依然として特化型が築く
主な競争は、1つの汎用モデルと、調整された特化型モデルのスタックの間にあり、どのアーキテクチャが勝つかは信頼性が決める。
特化型モデルには直感的な利点がある。視覚的グラウンディングに特化して訓練されたモデルは、コントロールの位置特定に集中できる。コーディングモデルは、すべてのスクリーンショットを解釈することなく、構文、実行、デバッグに集中できる。
ツール呼び出しモデルも、構造化されたスキーマの恩恵を受ける。APIは許可されたアクションと予測可能なフィールドを公開する。グラフィカルインターフェースはより柔軟だが、ボタン、レイアウト、一時的な状態が曖昧さを生む。
特化型アプローチでは、エンジニアが各領域に最適なモデルを選べる。また、リスクの高い機能を分離することもできる。視覚エージェントには、任意のシェル実行を与えずに画面アクセスだけを付与できるかもしれない。
しかし、特化によって複雑さは周辺システムへ移る。ルーターは各段階を分類し、コンポーネントを選択し、引き継ぎをまたいでユーザーの意図を保持しなければならない。スタックは異なるコンテキスト形式と障害シグナルを整合させる必要がある。
Holo4の汎用ルートでは、この調整の一部をモデル内部へ移す。エージェントは画面を見て、直接操作が非効率だと認識し、代わりにコードや構造化ツールを使用できる。
H Companyは、このアプローチをプロフェッショナルソフトウェアのタスクで例示している。ある例では、Holo4 27Bが、同じプロンプトとハーネスの下で、自律型ゲームをGodotで構築するために68回の呼び出しと240万トークンを使用したとされる。そのQwenベースは197回の呼び出しと1,140万トークンを使用した。
これらの数値は独立した研究機関によるものではなく、H Company自身の評価に基づく。平均的な本番性能ではなく、1つのタスクを説明している。それでも、同社がHolo4で実現したい効率性の種類を示している。
ほかの例には、FreeCAD内で詳細なオブジェクトを構築する作業がある。これらのワークフローは、空間的な解釈、ソフトウェア制御、コード生成を組み合わせる。単一のWebフォームを入力するよりも要求が高い。
これらの例は、限界も示している。Holo4のエッフェル塔タスクでは、84回の呼び出しと130万トークンを要したと報告されている。最終結果が成功した場合でも、長時間のコンピュータ利用セッションは計算コストが高いままでありうる。
ワークフローが予測可能な場合、特化型には別の利点が残る。決定論的なスクリプトや限定的なAPI統合は、複数の可能なアクションから選択するエージェントより高速で、監査もしやすい場合がある。
ワークフローが変動し、インターフェースが変化し、旧来のシステムに統合機能がないとき、汎用モデルの主張はより強くなる。組織が再現性を必要とし、プロセスを正確に定義できるとき、特化型の主張は依然として強い。
つまり、Holo4が従来型の自動化を消し去る可能性は低い。むしろ、固定スクリプトが破綻する一方、制約のない最先端エージェントは高コストすぎるか、ガバナンスが難しすぎる不確実な中間領域で競合する。
したがって開発者は、個別のクリックではなく完全なタスクを評価すべきだ。重要な問いは、Holo4が実際のワークフロー全体で失敗とエンジニアリングの負担を減らせるかどうかである。
より少ない引き継ぎで正しい最終状態に到達するモデルであれば、1つの限定的なスキルにおける生の精度が低くても正当化できる。手法を予測不能に変える汎用モデルは、より大きなデバッグ負担を生み出しかねない。
結果は、トラジェクトリの品質、再現性、復旧動作に左右される。これらの要因は、どちらのアーキテクチャが図の上でより洗練されて見えるかよりも重要だ。
Holo4のベンチマーク結果にはハーネスと注記が必要
Holo4の結果は注目に値するが、リリース内容そのものが、いくつかの主要な比較が直接同等ではない理由を示している。
H Companyによると、Holo4 27BはOSWorld 2.0で61.7％を記録した。35B-A3Bモデルは30.9％に達した。同社はこれらの結果を、Opus 5.5の81.8％と比較している。
Holo4 27BとOpus 5.5の差は20.1ポイントであり、大きい。報告されたこの指標において、Holo4は最強のクローズドモデルを上回ってはいない。同社の主張は、モデルサイズ、導入の柔軟性、推定タスクコストに焦点を置いている。
H Companyはさらに、Opus 5の70.2％、GPT-5.6 Solの66.2％というスコアも引用している。これらの参照値は、2026年8月8日付のオフラインOSWorld 2.0セットにおいて、最大エフォートの部分報酬を用いたものだ。
リリースでは、モデルのバージョン、ハーネス、タスクのサブセットが異なる点に注意を促している。この警告は、あらゆる比較に付記されるべきだ。エージェントの性能は、モデルのチェックポイントだけで決まるものではない。
ハーネスは、メモリ、ツールへのアクセス、観測結果の形式、再試行の挙動、最大ステップ数を制御する。基盤となるモデルが変わらなくても、これらの変数のいずれかを変更すれば結果は変わり得る。
コストチャートにも同様の注意が必要だ。H Companyは、各実行で使用された入力・出力トークンから費用を推定した。Holo4には自社API料金を適用し、他モデルには外部の定価を用いた。
このような推定は社内計画の材料にはなり得るが、統制された経済測定ではない。キャッシュの前提、推論インフラ、再試行、ボリュームディスカウントによって、実際の導入コストは変化し得る。
AutomationBenchでは、比較可能性に関する別の問題もある。H Companyは、社内ハーネス上でバージョン1.0.6を用い、Holo4とQwenベースラインを評価した。他モデルのスコアは、このベンチマークの公開セットに由来する。
他モデルについて引用されたコスト値は、非公開セットで運用されるリーダーボードから得られたものだ。H Companyは、テスト実施後にその非公開評価でHolo4の結果を報告する予定だとしている。
それまでは、すべてのAutomationBenchのポイントを単一の統制実験による結果として扱うべきではない。これらは異なる条件で生み出された、関連はあるが別個の測定値である。
ベンチマークの定義でさえ、物語を形作り得る。OSWorld 2.0は二値の完了判定と部分点評価をサポートしている。モデルは、完了済みのワークフローを実現できなくても、有意な部分点を得る可能性がある。
これは部分点評価が無用だという意味ではない。二値の成功判定では改善が見えにくい長時間タスクにおいて、進捗を特定できる。一方で、購入者が重視するのは、最終的なレコード、ファイル、取引が正しいかどうかだ。
効率性も、トークン数だけでは測れない。agent efficiencyに関する研究では、主要なコンピュータ操作エージェントが評価において必要なステップ数の1.4〜2.7倍を要したことが示された。
同じ研究は、後半のステップほど前半より大幅に時間がかかる場合があることも明らかにした。プランニングとリフレクションの呼び出しが、レイテンシーの大部分を占めていた。そのため、長いエージェントトレースは、見かけ上のアクション数を超えて遅延を増幅し得る。
これらの知見は、H Companyがメモリとシェルアクセスを重視する理由を補強する。同時に、ベンチマークでの成功スコアが、自動的に許容可能なユーザー体験につながるわけではないことも示している。
公正な読み方は、否定でも無批判な受容でもない。Holo4は比較的コンパクトなモデルとして競争力のある自己報告結果を示した一方、最先端のクローズドシステムには後れを取っている。
実務上の検証は、その結果が独立したハーネス、非公開評価、組織固有の権限やデータを含むワークフローでも持続するかどうかだ。
オープントラジェクトリは検証を改善するが、安全性を保証しない
H Companyが信頼性を高めるうえで最も有力な取り組みは、スコアの裏付けとなるトレースを公開したことだ。ただし、挙動を検査できることが自動的に安全な挙動を意味するわけではない。
trajectory datasetには、Holo4 27BおよびHolo4 35B-A3Bによる7,366件の実行結果が含まれている。各トレースには、タスク、推論、アクション、ツール結果、スクリーンショット、所要時間、ステップ数、最終スコアが含まれる場合がある。
このコレクションには、両モデルを合わせて2,100件超のOSWorld実行が含まれる。また、OSWorld 2.0の212件の実行と、3,200件近いAutomationBenchの実行も収録されている。
追加のトレースはAndroidWorld、PinchBench、Agents’ Last Examを対象とする。H Companyは、ユーザーがデータセットをダウンロードするか、専用ビューアでトレースを再生できるようにしている。
この開示により、研究者は同社の結論を多面的に検証できる。成功した実行が妥当な経路を取ったのか、不必要なアクションを繰り返したのか、タスク固有の近道の恩恵を受けたのかを調べられる。
失敗パターンも検証できる。集計スコアだけでは、エージェントが指示を誤解したのか、誤った対象をクリックしたのか、文脈を失ったのか、検証前に停止したのかは分からない。
オープントラジェクトリは、性能改善がより優れた推論によるものなのか、より寛容なハーネスによるものなのかを明らかにできる。また、チームが人間の介入頻度を見積もる助けにもなる。
ただし、実行後の透明性と、実行前の統制は異なる。トレースは調査者が何が起きたかを理解する助けになるが、エージェントによるデータ送信、ファイル削除、悪意ある指示への追従を防ぐものではない。
コンピュータ操作エージェントは、従来のチャットシステムにはないリスクに直面する。信頼できないコンテンツと価値の高い認証情報が存在する環境で動作するためだ。Webページは、敵対的なテキストをモデルの観測結果に直接埋め込める。
OS-Harm benchmarkは、150件のタスクを通じて、意図的な悪用、プロンプトインジェクション、意図しないモデル挙動を検証する。その研究者たちは、複数の最先端システムで有意な危険挙動を確認した。
この研究はHolo4を評価していないため、その結果からHolo4の安全性を判断することはできない。ただし、有能なコンピュータ操作と安全なコンピュータ操作は、別個の評価課題であることを示している。
1つのモデルが幅広いインターフェースアクセスを持つ場合、リスクはより鮮明になる。汎用モデルは、Webページの閲覧からコード実行やAPI呼び出しへ移行できる。この柔軟性は有用性を高める一方、ミスがもたらし得る影響も拡大する。
企業は、ベンチマークスコアにかかわらず、多層的な統制を必要とする。その統制には、スコープを限定した認証情報、隔離された実行環境、制限されたネットワークアクセス、可逆的なアクション、重要なステップに対する人間の承認が含まれる。
また、各アクションをユーザーの指示と、その時点で観測された状態に結び付けるログも必要になる。Holo4のトレース形式は、こうした監査記録にとって有用なモデルを提供している。
ライセンスにも注意が必要だ。オープンウェイトであっても、すべてのチェックポイントやコンポーネントで同一の商用利用権が保証されるわけではない。チームは導入前に、各モデルカードと依存関係を確認すべきだ。
データガバナンスも同様である。スクリーンショットやエージェントトレースには、個人情報、顧客記録、機密文書が含まれる可能性がある。すべてをログに記録すればデバッグは改善するが、新たな機微データセットも生まれる。
H Companyは、公開トレースで認証情報、内部ホスト、個人データをマスキングしたとしている。本番運用者は、自身のトレースにも同等のマスキングと保持管理を構築しなければならない。
オープンデータセットは、今後のリリースに求められる水準を引き上げる。優れたコンピュータ操作性能をうたうベンダーには、再現可能な証拠がどのようなものか、より明確な前例が示された。
それでも、最も価値の高い外部検証は、敵対的な再生、独立した採点、H Companyのハーネス外でのテストを含むものになるだろう。透明性はそのプロセスを開くが、それ自体で完結させるものではない。
Holo4の汎用モデル戦略が有効かを示す3つのシグナル
次の段階は、独立した再現、非公開ベンチマークの結果、本番ワークフローからの証拠によって判断されるべきだ。
最初のシグナルは、Holo4のOSWorld 2.0性能の独立再現である。研究者は、公開されたウェイトを、文書化されたインフラ、プロンプト、ステップ上限、採点ルールとともに実行する必要がある。
報告された61.7％を再現できれば、能力を担っているのはモデル自体だというH Companyの主張を補強する。大きな差異が出れば、同社のハーネスが見出しから受ける印象以上に寄与している可能性が示される。
再現では、二値の完了、部分点、ステップ数、レイテンシー、介入率も比較すべきだ。単一のスコアだけでは、エージェントが実用的な制約の中で利用可能な結果に到達できるかを捉えられない。
公開されたトレースによって、この作業はより実現可能になる。研究者は既知の実行から始め、失敗の境界を調べ、同じタスクで代替ハーネスを比較できる。
2つ目のシグナルは、Holo4の非公開AutomationBench結果だ。リリースでは、現在のスコアが公開セット上での内部実行に由来する一方、比較コストは非公開セットのリーダーボードを参照していることを認めている。
非公開評価は、よりクリーンな比較を可能にし、可視化されたタスクに対するチューニングへの懸念を抑える。また、Holo4が未知のAPIワークフローをまたいで一般化できるかも検証できる。
結果には成功率以上の情報を含めるべきだ。開発者には、文書化された単一の評価設定でのコスト、トークン使用量、再試行、レイテンシー、失敗カテゴリーが必要になる。
3つ目のシグナルは、混在インターフェースのワークフローにおける信頼できる本番証拠である。最適な事例は、1つのセッション内でGUI、コード、構造化ツールを本当に必要とするタスクだろう。
有用な報告は、人間の修正なしでの完了、インターフェース変更からの回復、制限された権限下での性能を示すべきだ。成功した実行だけでなく、不可逆的なエラーも数える必要がある。
経費処理ワークフローは代表的なテストとなる。エージェントは文書を読み、フィールドを検証し、業務ソフトウェアを操作し、レコードが意図した状態に到達したことを確認しなければならない。
もう1つの有力なテストは、ローカルファイル、課題トラッカー、ブラウザコンソール、コマンドラインツールにまたがるエンジニアリング運用だ。このようなワークフローは、共有コンテキストが利点なのか、統制不能な挙動の源なのかを明らかにする。
モデル更新も関連するシグナルとなる。H Companyは、推論を高速化するために最適化されたドラフターのチェックポイントを計画しているとしている。測定可能なレイテンシー削減は、汎用アーキテクチャの経済的根拠を強化するだろう。
競合他社の対応も重要だが、補助的な証拠にとどまる。クローズドモデルの提供者はコンピュータ操作能力を改善できる一方、オープンモデル開発者は自社リリースにより幅広いツールトレーニングを追加できる。
中心的な問いは、Holo4があらゆる代替手段を上回り続けるかどうかではない。単一の汎用モデルが、専門モデルのスタックより優れた信頼性と複雑性の比率を提供できるかどうかだ。
開発者にとって、直近の機会は統制された評価にある。代表的なタスク、制限された認証情報、可逆的な環境を使うべきだ。個別のモデルアクションではなく、完了した成果を測定する必要がある。
企業の購入担当者にとって、調達時の問いにはハーネスも含めるべきだ。メモリ、承認、再試行、シークレット、監査ログ、部分実行後の復旧を、どのコンポーネントが管理するのかを確認すべきである。
ナレッジワーカーにとって、このリリースはエージェントがより多くのアプリケーション境界をまたぐことを示唆している。その利便性は同時に、権限設計と可視的な確認をより重要にする。
Holo4: 汎用コンピュータ操作エージェントを支えるは、勝利宣言というより、具体的なアーキテクチャ上の挑戦である。H Companyはモデル、主張、そして異例なほど詳細なトレースを提供した。
次の一手は、独立評価者と導入チームに委ねられている。Holo4は報告された結果を再現し、未知のタスクに耐え、運用リスクを拡大させずに実務を完了できるのか。
この3つの検証が、汎用コンピュータ操作エージェントが自動化を簡素化するのか、それとも最も困難な問題を移し替えるだけなのかを決定する。
