Holo4 徹底解説｜フロンティアモデルの1/7のコストで業務自動化を実現するコンピュータ使用エージェント

はじめに：「AIがPCを操作する」はどこまで現実になったか

「AIがパソコンを人間のように操作する」――数年前まであくまで研究レベルの話だったこのビジョンが、2026年に入って急速に現実味を帯びてきました。スクリーンショットを見ながらクリックし、フォームを入力し、コードを書き、APIを呼び出す。そうした一連の操作を自律的にこなすAIエージェントが、いよいよ実用フェーズに突入しつつあります。

その中で、H Companyが2026年9月28日に公開したHolo4は、ひとつの転換点を示すリリースとして注目を集めています。最大の理由はシンプルです。フロンティアモデルの1/7のコストで、約75%に相当する性能を実現したという点です。

OSWorld 2.0ベンチマークにおいて、Holo4-27BはClaude Opus 5.5の$8.48に対してわずか$1.22というコストで61.7%のスコアを記録しました。「最高性能」よりも「コスト対性能のバランス」が意思決定の軸になりつつある現在、この数字が持つ意味は決して小さくありません。

この記事では、Holo4の2バリアントの違いと使い分け、OSWorld 2.0という評価指標の読み方、そして自社への導入を検討するうえでの判断材料と注意点を段階的に整理していきます。

Holo4 を3行で要約

H Company が 2026年9月28日 に公開したオープンウェイトの汎用コンピュータ使用エージェント
デスクトップ・Web・Android・API をまたいで操作し、GUI・コード・MCP・API を単一モデルで処理
Apache 2.0 ライセンスでセルフホスト可能、商用利用もフリー

Holo4 とは何か：汎用コンピュータ使用エージェントの定義

「コンピュータ使用エージェント（CUA）」とは

コンピュータ使用エージェント（Computer Use Agent、以下CUA）とは、人間がPCを操作するのと同じレイヤーで動くAIのことです。具体的には、スクリーンショットや画面のDOM情報を入力として受け取り、マウスのクリック・キーボード入力・スクロールといった操作を出力として返します。

従来のRPA（ロボティック・プロセス・オートメーション）ツールとの最大の違いは、事前に定義したスクリプト通りにしか動けないRPAに対し、CUAは画面を見てその場で判断できるという点にあります。ログイン画面のレイアウトが変わっても、エラーダイアログが出ても、文脈を理解したうえで次の一手を選択できるのがCUAの強みです。

従来のGUIエージェントが抱えていた分断

初期のGUIエージェントが直面した最大の課題は「インターフェースの分断」でした。GUI操作に特化したモデル、コード生成に特化したモデル、外部ツール呼び出しに特化したモデルを、それぞれ別々に用意してオーケストレーションする必要があったのです。

この構成では、インターフェースをまたぐタスクのたびに引き継ぎコストが発生します。「Webブラウザで情報を取得してスプレッドシートに書き込む」といった複合タスクは、複数のモデルが連携しなければならず、エラーが起きたときのデバッグも複雑になります。

Holo4 が狙った「汎用性」の中身

Holo4はこの分断を解消するために設計されました。単一のモデルが次の4種類の環境と操作手段に対応します。

対応環境：デスクトップ（Windows/Mac/Linux）/ Webブラウザ / Android / API
対応アクション：GUI操作 / コード実行 / MCP（Model Context Protocol）/ API呼び出し

「汎用」という言葉は抽象的に聞こえますが、実際の開発現場では「一つのモデルで業務フローの全体をカバーできる」という意味で非常に重要です。アーキテクチャの詳細は次節で見ていきましょう。

Holo4 のアーキテクチャ：27B 密集型 vs 35B-A3B MoE

2バリアントのスペック比較

Holo4には用途に応じた2つのバリアントが用意されています。

項目	Holo4-27B	Holo4-35B-A3B
タイプ	密集型（Dense）	MoE（Mixture of Experts）
アクティブパラメータ	27B	3B（総数35Bのうち）
ベースモデル	Qwen3.8-27B	Qwen3.6-35B-A3B
コンテキスト長	256K	256K
ライセンス	Apache 2.0	Apache 2.0
OSWorld 2.0 スコア	61.7%	30.9%

256Kという長大なコンテキスト長は両バリアントで共通しており、数百ステップにわたる長期タスクを処理する際の重要なアドバンテージになっています。

MoE（Mixture of Experts）が効く理由

35B-A3BのMoEアーキテクチャを理解するには、MoEの基本的な仕組みを押さえておく必要があります。

Mixture of Expertsとは、モデルの全パラメータを常に使うのではなく、入力に応じて「専門家（Expert）」の一部だけを選択的に活性化させる手法です。Holo4-35B-A3Bの場合、総パラメータ数は35Bありますが、推論時に実際に使われるのは3Bのみです。

これが実用上で意味を持つのは次の理由からです。

計算コストの圧縮：GPUが処理するパラメータが1/10以下になるため、推論コストが大幅に下がる
セルフホスティングの現実性：限られたGPUリソースでも実用的なレイテンシを実現できる
API利用時の課金削減：消費するトークン数が少なくなるため、従量課金でも有利

ただし、トレードオフも明確です。OSWorld 2.0のスコアが61.7%から30.9%へと約半減します。「計算コストを下げる代わりに性能が落ちる」という構造的なトレードオフは、用途によっては許容できる場合もあれば、致命的になる場合もあります。

訓練パイプライン：SFT → RLエキスパート分離 → Expert Merging

Holo4の訓練パイプラインは3段階構成で設計されており、この設計が性能を支える重要な要素になっています。

ステップ1：SFT（教師あり微調整）

まず127Bトークンの大規模データセットを使った教師あり微調整を行います。この段階でGUI操作、コード実行、MCP呼び出しといった基礎的な操作能力を獲得させます。

ステップ2：RLエキスパートの独立学習

SFTの後、2つの専門化されたRLエキスパートを独立して学習させます。

「デスクトップ/Web」専門エキスパート：マウス操作・フォーム入力・ブラウジングに特化した報酬設計
「ターミナル/MCP/API」専門エキスパート：コード実行・外部ツール呼び出しに特化した報酬設計

エキスパートを分離して学習させる理由は、報酬設計が本質的に異なる2つのドメインを混在させると、干渉が起きて両方の性能が下がるからです。「画面を見てクリックする」タスクと「コードを書いて実行する」タスクでは、「正しい」行動の定義が根本的に異なります。

ステップ3：Expert Merging

2つの専門エキスパートを単一モデルへと統合します。この最終ステップにより、単一のモデルが状況に応じてGUI操作とコード実行を切り替えられる「汎用性」が実現します。

どちらを選ぶべきか：用途別の判断軸

実際の導入を検討する際の選択基準を整理すると以下のようになります。

Holo4-27B（Dense）が向いているケース

業務クリティカルな処理で失敗のコストが高い
精度優先で多少のAPI費用は許容できる
タスク数が少なくバッチ処理の必要がない

Holo4-35B-A3B（MoE）が向いているケース

大量のタスクを並列処理したい
簡易・低リスクなタスクでコスト削減が最優先
セルフホストでGPUリソースに制約がある

256Kコンテキストは両者共通なので、「長い会話履歴を保持しながら作業したい」という要件だけでは差はつきません。

OSWorld 2.0 ベンチマークとは：何を測っているのか

2026年7月に登場した「長期ワークフロー」評価

Holo4の性能を語る際に必ず登場するOSWorld 2.0は、2026年7月に発表されたデスクトップ制御エージェント向けのベンチマークです。前バージョンのOSWorld 1.0が比較的短期のタスクを対象にしていたのに対し、OSWorld 2.0は人間が実際にこなすような長期的なワークフローを評価対象としています。

主要なスペックを確認しておきましょう。

タスク数：108件の長期タスク
人間の完了時間の中央値：1タスクあたり1.6時間
平均ツール呼び出し数：318回（OSWorld 1.0の約10倍）

「318回のツール呼び出し」という数字は、このベンチマークの要求レベルを直感的に示しています。単純なクリックや検索ではなく、複数のアプリケーションをまたぎ、何百もの判断を積み重ねてようやく完了するような、現実の業務に近いタスクを評価対象にしているのです。

OSWorld 1.0 からの進化点

OSWorld 2.0が1.0から大きく変わった点は主に2つあります。

部分進捗スコア（Partial Credit）の導入

1.0では「成功か失敗か」の二値評価でしたが、2.0では「どこまで完了できたか」を段階的に評価します。118ステップのタスクで100ステップまで完了できたエージェントと、10ステップで止まったエージェントを同じ「失敗」として扱わない、より細かい評価が可能になりました。

自己ホスト型環境による再現性の担保

評価環境を自己ホストできるため、どの研究チームが同じ条件で評価しても同じ結果が得られます。クローズドなAPIで評価結果が変わってしまう問題を回避しています。

モデル	スコア	コスト/タスク
Claude Opus 5.5	81.8%	$8.48
GPT-6 Astra	73.5%	$9.07
Holo4-27B	61.7%	$1.22
Holo4-35B-A3B	30.9%	低コスト

スコアの読み方：61.7%は「使える」のか

61.7%というスコアは、どう解釈すればよいでしょうか。

技術的に正確な表現をすれば、「OSWorld 2.0の108タスクのうち、部分進捗スコアの加重平均で61.7%を達成した」ということです。しかし実務的に言い換えると、「複雑な長期タスクにおいて、3回に1回以上は完全には完了できない」水準とも言えます。

人間のオペレーターを基準にすると、現時点でも最強のClaude Opus 5.5が81.8%にとどまっていることが示すように、人間レベルのコンピュータ操作能力はまだ誰も達成していない状況です。Holo4の61.7%は、「そのギャップの中でコスト効率の高い選択肢」として位置づけるのが適切でしょう。

実際の業務設計においては、失敗をどう検出してリカバリーするか、どの部分を人間が確認するかを設計に組み込むことが前提になります。

GUI・コード・MCP・API を統合する仕組み

単一モデルで4インターフェースを処理する流れ

Holo4の中核的な設計思想は、4種類のインターフェースを単一のモデルが統一的に処理することです。その処理フローを可視化すると、以下のようになります。

[タスク受信]
     ↓
[アクション種別判定]
┌────┬──────┬────┬────┐
│GUI │コード│MCP │API │
└────┴──────┴────┴────┘
     ↓
[環境フィードバック（スクリーンショット/実行結果）]
     ↓
[メモリ更新 → 次アクション決定]
     ↓
[タスク完了 or 次ステップへ]

タスクを受け取ったモデルはまず「次のアクションに最適なインターフェースはどれか」を判断します。そのアクションを実行し、環境からのフィードバック（スクリーンショット・コード実行結果・APIレスポンスなど）を受け取り、内部メモリを更新して次の判断へと進む――このループを数十から数百回繰り返すことで、複雑なタスクを完遂します。

4つのアクション種別の使い分け

Holo4が持つ4種類のアクションは、それぞれ異なる強みを持っています。

GUI操作

マウスクリック・キーボード入力・スクロールなど、画面を見ながら行う操作です。APIが提供されていないレガシーシステムや、Webブラウザ上の動的なUIに対して有効です。ただし、スクリーンショットの取得と処理にトークンコストがかかるため、APIが使える場合は後述のAPI呼び出しを優先するほうがコスト効率は高くなります。

コード実行

Pythonスクリプトやシェルコマンドをその場で書いて実行します。大量のファイル処理・データ変換・数値計算など、GUI操作では非効率な処理を高速かつ確実にこなせます。Pac-Man開発タスクの事例で示すように、コード1行で済む処理をGUIでやろうとすれば無駄なステップが増えます。

MCP（Model Context Protocol）

Anthropicが策定した、AIエージェントと外部ツールを接続するための標準プロトコルです。MCP対応のツール・サービスなら、プロトコルを通じて統一的に呼び出せます。エコシステムが整いつつある現在、MCP対応ツールの数は急速に増加しています。

API呼び出し

RESTやGraphQL等のAPIを直接呼び出します。確実性・スピード・コスト効率の三点でGUI操作より優れており、APIが利用可能な場合はこちらが優先されます。

Harness（制御ループ）の重要性

コンピュータ使用エージェントの実用性を決めるのは、モデル単体の性能だけではありません。数百ステップにわたる操作を管理する「Harness（制御ループ）」の設計が成否を大きく左右します。

Holo4のHarnessが実現していること：

信頼性のあるメモリ管理：256Kコンテキストを活用し、タスクの初期目標・中間状態・制約条件を長期にわたって保持
自動タグ付けと継続改善：失敗したタスクを自動的にタグ付けし、エンジニアがその失敗パターンからHarnessを改善するサイクルを構築
コスト効率との連動：「どのインターフェースを使うか」の判断をモデルに委ねることで、無駄なGUI操作を避けてトークン消費を抑える

実際の開発現場では、「モデルを変えるより、Harnessを改善するほうが成果が出やすい」という知見が蓄積されつつあります。Holo4のアーキテクチャはこの考え方を設計レベルで組み込んでいます。

コスト効率を数字で検証する

API 価格（1Mトークンあたり）

Holo4の公式API価格は以下のとおりです。

モデル	入力	出力
Holo4-27B	$0.40	$3.00
Holo4-35B-A3B	$0.30	$2.00

出力トークン単価がGPT-4やClaude系のフロンティアモデルに比べて大幅に抑えられており、エージェントタスクのように出力が多くなるユースケースで特にコスト優位が際立ちます。

OSWorld 実測：1タスク $1.22 の内訳感覚

OSWorld 2.0での1タスクあたりのコスト実測値を改めて確認します。

Holo4-27B：$1.22（スコア 61.7%）
Claude Opus 5.5：$8.48（スコア 81.8%）
GPT-6 Astra：$9.07（スコア 73.5%）

「1/7のコストで約75%の性能」という表現はこの比較から来ています。パフォーマンスで20ポイント差があるとしても、コストが7分の1なら、スループットが7倍になる計算です。同じ予算で7件処理できるのか、1件しか処理できないのか――業務設計においてこの差は無視できません。

実例：Pac-Man ゲーム開発タスクの驚くべき効率差

Holo4の公式ブログが公開したPac-Manゲーム開発タスクの比較は、「賢いエージェント」と「非効率なエージェント」の差を如実に示しています。

	API呼び出し数	消費トークン数
Holo4-27B	68回	2.4M
ベースのQwen3.8（Fine-tune前）	197回	11.4M

呼び出し数で約3分の1、トークン消費で約5分の1という差です。

この差はどこから来るのでしょうか。Holo4-27Bは「GUI操作より1行のコードで解決できる」と判断した場合、迷わずコード実行を選びます。一方、ファインチューン前のベースモデルはGUI操作に頼りがちで、10行のコードで済むことを画面をクリックしながらやってしまうのです。

「賢さ」はスコアだけでなく、ステップ数の削減、ひいてはトークン効率として現れるというのが実際の開発現場での観察です。

セルフホストした場合のコスト試算の考え方

Apache 2.0ライセンスのHolo4はセルフホストも可能で、その場合API課金をゼロにできます。ただし、技術的に正確な評価には以下の要素を加味する必要があります。

GPU調達・維持コスト：Holo4-27Bをフルで動かすには相応のGPUメモリが必要です。A100 80GB×1〜2枚程度の環境が実用的な目安になります。

スループットとレイテンシのトレードオフ：セルフホスト環境では、同時リクエスト数に応じてレイテンシが増加します。

MoE版の注意点：35B-A3BのMoEモデルは、大バッチで推論する際に複数のエキスパートが同時に呼ばれることで「疑似Dense化」が起き、理論上のコスト削減が得られないケースがあります。大量バッチ処理でコスト削減を期待する場合は、実測値で確認することを強く推奨します。

汎用コンピュータ使用エージェントの現在地と課題

Holo4の登場は業界の前進を示すものですが、汎用CUAとして実用化するには依然として課題が残っています。技術的に正確な表現を心がけながら、主要な課題を整理します。

技術的課題① 長期文脈の管理

256Kコンテキストは長大ですが、「覚えていること」と「適切に使えること」は別問題です。タスクが数百ステップに及ぶと、初期に与えられた制約条件を見落とす、現在の状態を誤認識するといった問題が発生しやすくなります。

人間が1.6時間かけてこなすタスクを自律的にこなすためには、長期記憶の管理戦略——何を常に参照すべきか、何を圧縮して保存するか——をHarness側で工夫する必要があります。

技術的課題② MoE特有の落とし穴

前述の「疑似Dense化」問題は、MoE版を選ぶ際に見落としがちな落とし穴です。大量の並列リクエストを処理しようとすると、Expertのルーティングが集中してしまい、理論上の「3B相当の計算コスト」が実現しないケースがあります。ベンチマーク上の「低コスト」が本番環境で再現するとは限らないという点は、セルフホスト・大規模展開の設計時に必ず確認すべきポイントです。

技術的課題③ GUI観測の非効率

GUI操作の最大のコスト要因は、スクリーンショットの処理です。1280×800のスクリーンショットをエンコードしてモデルに渡すと、それだけで数百〜数千トークンを消費します。アプリが複雑なDOMを持つWebアプリや、高解像度ディスプレイを前提とするソフトウェアでは、この観測コストがボトルネックになります。

「APIが使えるならAPIを使う」というHolo4の設計思想は、こうした構造的コスト要因を意識したものでもあります。

技術的課題④ 安全性と不可逆操作

これは技術的課題であると同時に、運用設計の問題でもあります。ファイルの削除、メールの送信、外部APIへのPOSTリクエスト、コードの実行——これらはすべて「やり直しのきかない」操作です。

ベストプラクティスとして、以下の設計を推奨します。

サンドボックス隔離：本番環境とは切り離された実行環境でPoC・テストを行う
不可逆操作への人間承認フロー：削除・送信・実行の前に必ず人間が確認するステップを挟む
監査ログの完全記録：全アクション・全ステップのログを保存し、問題発生時に追跡可能にする

業界動向：競合と周辺エコシステム

Holo4の公開は、汎用GUIエージェント市場の競争が本格化したことを示しています。

MoEバックボーンを採用した同系統の汎用GUIエージェント「OmegaUse」など、類似アーキテクチャの競合が登場しており、オープンウェイト×汎用CUAという市場セグメントが急速に拡大しています。また、NVIDIA Nemotronコアリションに、Holo4互換の「Holotron4 Nano」が参加するという動きも報告されており、ハードウェアサイドとのエコシステム形成も進みつつあります。

日本市場固有の課題として注意すべきなのは、日本語UIへの対応、社内規程・コンプライアンスへの適合、既存の業務システム（特にレガシーな社内システム）との統合です。現時点でこれらに関する事例はまだ少なく、実際の開発現場でのノウハウ蓄積が必要な領域です。

自社で Holo4 を試すには

向いているユースケース

Holo4が現時点で最も力を発揮しやすいのは、以下のような特性を持つタスクです。

繰り返し頻度が高い業務：毎日同じフローを繰り返すデータ入力・集計・転記
失敗しても安全にリトライできる：読み取り専用操作や、失敗が軽微なファイル生成タスク
複数ツールをまたぐ操作：「Aシステムからデータを取得してBシステムに入力する」系の業務
API・自動化が整備されていないシステムへの操作：レガシーWebシステムの情報収集

まだ向いていないユースケース

一方で、現状のHolo4が適していないシナリオも明確にしておく必要があります。

100%の成功率が前提の処理：3〜4割の失敗を許容できない業務
不可逆・高リスクの操作が多い業務：大量メール送信・金融取引・本番DBへの書き込み
高速なリアルタイム処理が必要な業務：レイテンシが問題になるユーザー向けのフロー

導入ステップの提案

段階的に理解を深めていく観点から、以下のようなステップでの導入を推奨します。

Step 1：低リスクなPoC（読み取り専用から）

最初は「見るだけ」「情報収集だけ」のタスクから始めます。ファイルの削除や外部への送信が発生しない範囲に限定することで、失敗のコストをゼロに近づけられます。

Step 2：失敗パターンの収集とHarnessのチューニング

PoCで得られた失敗パターンを分析し、Harnessを改善します。どのステップで詰まるか、どんな画面構成でエラーが起きるかを把握することで、次のフェーズの成功率を高められます。

Step 3：承認フローを挟んで書き込み系へ拡張

失敗パターンが把握できたら、書き込み系の操作へと範囲を拡張します。ただし、この段階でも不可逆操作の前には人間の確認ステップを挟む設計を維持することが大切です。

試す際のリソース

Holo4を試す際に参照すべきリソースをまとめます。

Hugging Faceのモデルウェイト（Apache 2.0、商用利用可）
H Company提供のHarnessのOSS：Harnessの実装例として参考にできます
OSWorld 2.0の自己ホスト環境：自社のタスクを再現した評価環境を構築し、本番投入前のベンチマークとして活用できます

まとめ：コストが性能を民主化するフェーズへ

この記事の要点3つ

改めて本記事の核心を整理します。

1. 1/7のコストで約75%の性能という新しい選択肢

フロンティアモデル一択だった時代から、コスト対性能で選ぶ時代へ。Holo4-27Bの$1.22という数字は、CUAの実用化ハードルを大きく下げる可能性があります。

2. MoE版は低コストだが精度が大きく落ちる → 用途で選ぶ

61.7%（27B）と30.9%（35B-A3B）の差は大きく、MoE版を精度優先の業務に使うべきではありません。大量・低リスク・簡易なタスクに限定して使い、重要度の高い業務には27Bを当てるという使い分けが基本戦略です。

3. 実用化の鍵はモデル性能よりHarnessと安全設計

「いいモデルを使えば自動化できる」という発想は危険です。Harnessの設計、失敗検出・リカバリーの仕組み、不可逆操作への承認フロー――これらが整ってはじめて、業務での実用化が現実になります。

次に注目すべきポイント

汎用CUA市場は2026年後半に入って急加速しています。今後注目すべき動向を挙げておきます。

OSWorld 2.0スコアの上昇ペース：現在のトップが81.8%という状況から、人間レベル（≒100%）まであとどれくらいかかるか
日本語環境・企業内システムへの適応事例：英語圏中心の現在のエコシステムが日本語UIやレガシー業務システムにどう対応していくか
Apache 2.0コミュニティの発展：オープンウェイトという性質を活かして、どのようなFine-tuneやHarness改善事例が生まれるか

CUAの実用化は「最高性能のモデルを追い求める」フェーズから、「コスト・性能・安全性のバランスを設計する」フェーズへと移行しています。Holo4はその転換点を示す、重要なリリースと言えるでしょう。