ローカルPC操作向けHolo4：モデル・runner・権限の境界

一般的なchat modelはtextを受け取り回答を返します。PC操作modelは画面画像とtask指示を受け取り、次にclickする場所、入力する文字列、呼び出すtoolを選びます。Holo4の応答は行動計画または構造化tool requestであり、それ自体がmouse clickではありません。画面をcaptureしてmodelへ送り、応答を実際の入力に変換するrunnerが別途必要です。

model、harness、接続tool、OS権限はそれぞれ別の構成要素です。modelがbrowser操作を要求しても、harnessがそのtoolに対応していなければ実行されません。反対にharnessがbrowserやfileに広い権限を持つと、誤った計画が実際の変更につながる可能性があります。「ローカルmodel」だから安全、またはofflineだと決めつけないでください。

最初のtestは非機密のtest pageで特定の文言を探す読み取り専用作業にします。screenshotとtool requestがlogに残ることを確認してください。実際のemail、購入、account設定、重要fileは初回の実習から除外します。

Holo4-27Bのmodel cardは、Qwen3.8ベースの27B dense architectureと262,144 token²のcontext設定を記載しています。この設定は、その長さで十分なmemoryや速度が得られる保証ではありません。screenshotや長い行動履歴もvision処理とKV cache³用のmemoryを消費します。

Holo4-35B-A3BはQwen3.6ベースの別のMoE⁴ checkpointです。全weight規模とtokenごとの活性量を区別してください。3B相当のfileだけで動くわけではありません。27BのlicenseはCC BY-NC 4.0、35B-A3BはApache-2.0です。Holotron4など似た名前のmodelと混同せず、正確なrepository IDを確認します。

model weightsの利用許可は、websiteへのaccessやclick自動化の権限を付与するものではありません。runner code、接続tool、model weightsを個別に確認してください。業務利用では組織の法務・security policyに従います。

実行経路は、modelが提供するformatとrunnerが対応するbackendの組み合わせである必要があります。model cardでTransformers、vLLMなどの実装を確認し、そのbackendがscreenshot入力とtool call⁵にも対応するか調べてください。text生成だけでは画面理解も動作する証明になりません。

GGUF⁶、FP8⁷、NVFP4⁸ではweight表現と必要hardwareが異なります。formatが公開されていても、すべてのrunnerがすべてのGPU⁹やMacで対応するとは限りません。NVFP4は対応hardwareとkernelを、GGUFは現在のllama.cpp系versionでmodelとvisionが対応するか確認します。file sizeだけから実行時memoryを推測せず、load logとdevice使用量を確認してください。

hai-agents quickstartで最新のinstall手順と対応modelを確認し、別のtest profileで始めてください。現在のdocsとinstall済みcodeが一致しない場合やcheckpoint対応が不明な場合は、commandを作らず公式releaseを確認します。このガイドではデバイス別の新たな性能測定は行っていません。

browser profileまたはtest accountを別に作成し、機密性のあるlogin sessionを外します。access先をtest domain一つに制限し、「返品可能期間を見つけて報告して」といった読み取り専用taskを実行します。正常ならrunnerがpageをcaptureし、modelが該当文を探して報告し、tool callと画面がlogに記録されます。

次に、一時folder内のfileを読んで一覧化するなど、取り消せるローカル作業だけを許可します。runnerが許可directory外を開けないことを確認し、taskの前後でfileを比較してください。

その後、制限付きの書き込み操作を試します。下書き作成は許可して送信をblockする、または一時fileの保存は許可して上書きには承認を必要とする、といった設定が考えられます。削除、購入、message送信、account変更の前には、対象と内容を人が確認してください。tool call実行中にもpause/stopが機能するか試します。

同じtestを5回繰り返し、成功の有無、誤click、最初の操作までの時間、完了時間、人の介入回数を記録します。layout変更やpopup表示後も無理に操作を続けるか確認してください。速くても危険なbuttonを何度も押そうとするagentは、運用に適しません。

model planとrunner logを保存する場合も、password、個人data、session tokenが記録されないようにします。screenshotの保存期間とaccessを制限し、backendやtelemetryが外部へdataを送るか確認してください。

画面が予想と異なる場合、agentは自動で続行せず停止して人に確認するべきです。test前に一時folderの復旧やbrowserのresetなど、失敗時の手順を準備してください。導入基準には成功率だけでなく、影響範囲、検知時間、停止可能性、least-privilege制御も含めます。

modelが端末に読み込まれるか、backendがvision入力とtool callを処理できるか、runnerの権限が意図どおりに機能するかを個別に確認します。load失敗ではcheckpoint、format、memoryを、画面の読み違いではcapture経路を、tool call失敗ではharness互換性を調べます。

人による確認と修正も含め、5回の反復で作業時間全体が短縮したかを判断します。作業の大半が要約やcode質問なら、一般的なlanguage modelのほうが簡単かもしれません。Holo4を選ぶ根拠は、定めた境界内で画面・tool作業を実際に安全に減らせたという記録です。

architecture、license、対応formatは各checkpointの最新公式cardに基づきます。このガイドは端末性能の測定値を示しません。選択したrunnerとtaskで速度と成功率を直接確認してください。