Gemini 3 Computer Use 実測 2026：AI にホテル予約を任せる前に知るべき 8 つのこと
Gemini 3 Computer Use 実測 2026：AI にホテル予約を任せる前に知るべき 8 つのこと
結論から言うと： Gemini 3 Computer Use は Google が 2026 年に投入した「AI が直接 PC を操作する」能力で、モデルが文章ではなく click_at(x, y) / type_text / key_combination のような操作コマンドを出力します。Claude Computer Use と比較すると、座標正規化と安全境界の設計がより先鋭的で、そのためにネイティブのデスクトップクライアントが必須になります。現状 macOS でもっとも完成度の高い実装が GeminiDesktop で、内部では scap による画面キャプチャ、enigo によるマウス・キーボード制御、AtomicBool + unblock channel による emergency stop を組み合わせています。この記事では AI を本気で走らせる前に 必ず 把握しておくべき 8 点を整理します。
一行警告： Computer Use は実験室のおもちゃではなく、本物の刃物です。動かす前に deny-list、per-step approval、emergency stop の 3 つのセーフティの位置を必ず確認してください。
1. Gemini 3 Computer Use vs Claude Computer Use：3 つの違い
名前は同じでも、内部設計にはいくつかの明確な分岐があります。
| 項目 | Gemini 3 Computer Use | Claude Computer Use (Sonnet 4.5+) |
|---|---|---|
| 座標正規化 | モデルは 0–1000 に正規化した座標を返し、クライアントが現在の画面サイズに合わせてリスケール | モデルが生のピクセル座標を返し、解像度変化に弱い |
| 画面入力 | スクリーンショット + オプションのアクセシビリティツリー | 主にスクリーンショット、UI はモデルがピクセルから読み取る |
| Action 粒度 | 6 種のアトミック action (click_at / type_text / key_combination / scroll_at / wait / finish) | 類似の粒度、命名規則が異なる |
| 安全境界 | モデル側 + クライアント側 deny-list の二層 | 主にクライアントの approval + ユーザー確認 |
| Per-step approval | デフォルト ON、MVP では trusted bypass を提供しない | 構成可能、エンタープライズのサンドボックスでは無効化可 |
| 料金 | action 回数 + 画像トークン | 近似、画像トークンはやや低い |
座標正規化 が今世代の最も実用的な設計判断です。モデルは訓練時に画面全体を 1000×1000 の仮想グリッドにマッピングするため、出力する (x, y) は常に 0–1000 の整数です。MacBook Pro (2560×1600) から 4K 外部ディスプレイ (3840×2160) にクライアントを移しても、モデルは座標系を学び直す必要がなく、クライアントが線形リスケールするだけで済みます。Claude の「ピクセル直出」は高 DPI への切り替え時にドリフトが目立ち、実測で一番分かりやすい安定性の差になっています。
2. デスクトップアプリが必須な理由（Web 版では絶対に動かない）
初見で「Chrome 拡張で良くない？」と考える人が多いですが、答えは明確に No です。
- 画面キャプチャ API がブラウザにない：Chrome の
getDisplayMediaで録画は可能ですが、毎秒フル画面の JPEG をモデルに安定供給することはできません (タブがフォーカスを失えば停止)。複数ディスプレイやシステムメニューは言うまでもありません - マウス・キーボード操作もブラウザには渡されない：ブラウザ内の click や type はすべて DOM サンドボックス内で閉じており、ブラウザ外の UI には届きません。Spotlight のクリック、ウィンドウ切り替え、Cmd+Tab は enigo や robotjs のような OS レベルのライブラリが必要です
- 権限モデルが別物：ブラウザの権限粒度は「現在のタブ」ですが、Computer Use はシステム全体への許可 — macOS のアクセシビリティ、Windows の UI Automation — を要求し、これらはネイティブアプリにしか開放されません
したがって GeminiDesktop のようなデスクトップクライアントは「あった方が良い」ではなく、macOS における Computer Use の 唯一の経路 です。Google が将来 Web 版を開放してもブラウザ自体しか操作できず、クロスアプリのワークフローは永遠に対象外になります。
3. 6 種 action の意味
Gemini 3 Computer Use は全操作を 6 つのアトミック action に圧縮しており、その意味を理解することが重要です。
click_at(x, y)：0–1000 正規化座標での左クリック。クライアントがリスケールして enigo のMouseClickを呼ぶtype_text(text)：フォーカス中の入力フィールドに文字列を入力。ショートカットは解釈しないのでCmd+Sはkey_combinationを使うkey_combination(keys[])：複数キー同時押し。例：["cmd", "shift", "z"]で redo。システムが押下して順に離すscroll_at(x, y, direction, distance)：指定座標でスクロール。方向は up/down/left/right、距離は notch 単位wait(ms)：明示的な待機。非同期ロードより早くスクショを取ってしまうのを防ぐfinish(reason)：「作業終わり」を明示的に宣言する唯一の正規ルート
これらで桌デスクトップ操作の 99% をカバーできますが、同時に 連続ドラッグ、ホバーで出るツールチップ、複雑なジェスチャは扱えません。「ファイルをゴミ箱にドラッグ」は 1 action では表現できず、「click_at で選択 → key_combination Cmd+Delete」に分解する必要があります。
4. Deny-list：rm / sudo / git push –force をどう自動遮断するか
GeminiDesktop はクライアント側にハードコードされた deny-list を持ち、一致したら モデルの action が実際に実行される前 にスキップ不可の確認ダイアログを出します。
rm/sudo/chmod 777/chown(破壊的シェルコマンド)Cmd+Q/Alt+F4(未保存データを失う強制終了)git push --force/git reset --hard(リポジトリ状態の破壊)Cmd+Shift+Delete(ゴミ箱を経由しない直接削除)
実装の骨子：クライアントは type_text を実行する前に、入力しようとする文字列を deny-list と正規表現で照合します。ヒットしたら action を suspend しメインスレッドにモーダルを出す。モデル側はこの遮断を「見られず」、次のターンで「rejected by user」を受け取って再プランニングするか停止してユーザーに問い合わせるかを決めます。
思想：「モデルは自分で避けてくれる」を信じてはいけない。Gemini 3 が RLHF で rm -rf / を避けるように教わっていても、プロダクションではクライアント側で最終防衛線を張るのが責任ある選択です。
5. Per-step approval：MVP で trusted bypass を用意しない理由
デフォルトでは、すべての action に対して実行前に短い approval プロンプトが出ます。「モデルが click_at(450, 230) を実行しようとしています — 許可しますか？」。Enter で許可、Escape で拒否。
「面倒なので trust this session トグルを付けて」という要望は多いですが、MVP は明確に却下しています。理由：
- モデルバイアスは現実：Gemini 3 は 2.5 より精度が大幅に向上しても、「間違ったボタンをクリック」の低確率イベントは残ります。20 ステップのワークフローで 1 ステップあたり 0.5% のエラー率なら、エンドツーエンドで約 10% の失敗率 — approval をバイパスすればユーザーの損失は大きい
- UI は予測不能：A/B テスト、ポップアップ広告、Cookie banner が座標を常に動かします。Approval は「確かに自分が押したい場所だ」と確認する唯一の機会
- 監査要件：エンタープライズでは AI の一操作ごとに追跡可能性が必要。Per-step approval はそのまま操作ログになる
将来方向：action 種別 + ユーザー履歴に基づく適応的 approval。「同じホテルの予約」を 20 回繰り返していれば信頼済みテンプレートとしてスキップ可能にし、UI レイアウトが顕著に変われば直ちに厳格モードに戻る — といった形です。
6. 実践デモ：AI にフォーム記入とツイート投稿をさせる
私が実際に流した完全デモ — ランディングページの waitlist にメール登録させ、その後 Twitter で宣伝ツイートを投稿させる、という流れ。
プロンプト： 「2 つお願いします：1) example.com/waitlist に行って alice@example.com で登録、2) Twitter に移って『X のウェイトリストに登録したばかり、面白そう』という内容のツイートを投稿」
Action シーケンス（wait は省略気味）：
click_at(500, 300)— アドレスバーをクリックtype_text("example.com/waitlist")key_combination(["return"])— 送信wait(800)— ロード待ちclick_at(420, 510)— メール入力フィールドをクリックtype_text("alice@example.com")click_at(500, 580)— Join Waitlist をクリックwait(1200)— 登録成功を待機key_combination(["cmd", "t"])— 新しいタブtype_text("twitter.com/compose/post")- …（続く）
finish("登録とツイート投稿が完了しました")
M2 MacBook で全体 90 秒ほど、うち 40 秒がページロードと approval の確認でした。手動で同じことをやれば 3 分かかる作業なので、効率向上は確かに明確です。ただ、もっと重要な観察：5 ステップ目でモデルが初めて位置を間違え（装飾アイコンを入力フィールドと誤認）、私が reject した直後に自分で再プランニングして正しい座標にたどり着きました。これが per-step approval の本当の価値です。
7. Emergency stop：AtomicBool + unblock pending approval の仕組み
AI が暴走したら？GeminiDesktop にはグローバルな emergency stop (デフォルトショートカット Cmd+Shift+.) があります。押下後の挙動：
- グローバル
AtomicBoolを true に - 実行中の enigo action は次回 tick でフラグをチェックし即座に abort
- approval 待ちでブロックされている channel を unblock、対向に「cancelled」シグナル送出
- WebSocket 接続を能動的にクローズしモデルへのフレーム送信を停止
なぜ AtomicBool と channel の両路が必要か？AI action は 2 つの状態のいずれかに居る可能性があるからです。
- OS コール実行中（enigo 内のマウス移動）→ AtomicBool で worker thread が次ループで抜ける
- ユーザー approval 待ち（channel にブロック）→ channel を能動的に unblock しないと AtomicBool は意味をなさない (worker は recv で止まったまま)
この二重遮断が多くの「中途半端な」AI 自動化ツールの落とし穴です。AtomicBool だけ設定しても、ユーザーが emergency stop を押してから数秒間 app が止まったままになります。GeminiDesktop は両シグナルを並行発火し、最悪でも 200ms 以内に完全停止します。
8. 既知の制約：macOS アクセシビリティ権限 + Windows 画面キャプチャ
実戦で必ず踏む 3 つの制約：
- macOS アクセシビリティ権限：Computer Use は enigo でマウス・キーボードを模擬するため、「システム設定 → プライバシーとセキュリティ → アクセシビリティ」で GeminiDesktop を許可する必要があります。macOS はこの権限に敏感で、初回許可時に app 再起動が必要、バージョンアップで勝手に剥奪されることもあります
- Windows 画面キャプチャ：scap ライブラリの Windows サポートがまだ完成していないため、GeminiDesktop の公式 Windows ビルドでは Computer Use が暫定的に無効化されています (テキストチャットと Live は動作)。ロードマップ目標は 2026 Q3
- マルチモニタの一貫性：解像度の異なる複数ディスプレイを使っていると、モデルの 1000×1000 座標系は「アクティブウィンドウがあるディスプレイ」に適用されます。モニタをまたぐドラッグはまだ不安定で、当面はシングルモニタ環境を推奨します
より低リスクで Gemini 3 のリアルタイム能力を試したい場合は、姉妹記事の Gemini Live Mac デスクトップ完全ガイド がおすすめです — あちらは「AI が画面を見て助言する」だけで、実際にクリックすることはありません。Google の公式 API を深掘りしたい場合は Google AI デベロッパーサイト に Computer Use の完全な API リファレンスがあります。
よくある質問
Q1：自分の Gemini API Key で Computer Use を動かせる？
A： 動かせます。GeminiDesktop の BYOK は鍵を Google に直送し、クライアントがローカルで computerUse: ツールエンドポイントを呼ぶ形です。Computer Use はプレーンテキストの 3〜5 倍のトークンを消費するので (スクショが重い)、BYOK 利用では請求を監視してください。
Q2：AI に見られたくないウィンドウがあるときは？
A： Computer Use を有効化する前に機密ウィンドウ (パスワード管理、プライベートチャット) を閉じるか別の Space に退避してください。「ウィンドウ単位のキャプチャホワイトリスト」機能はロードマップにありますが、MVP ではユーザー側の自制に依存します。
Q3：50 ステップの長いワークフローを全自動で回せる？
A： 技術的には可能、実践的には推奨しません。1 ステップあたりの失敗率が累乗的に拡大し、per-step approval は途中で介入できるようにするためのものです。推奨：長いワークフローを 3〜8 ステップ単位の小タスクに分解し個別に回すこと。
Q4：Zapier / n8n と競合する？
A： 完全には違います。Zapier は「API を持つ SaaS 同士を繋ぐ」、Computer Use は「API がないデスクトップ UI も自動化する」世界です。殺し文句になるのは古い企業ソフトウェア — API がないけれど普通の Web / ネイティブクライアントのように見える — AI が目で見てクリックしていけるケースです。むしろ補完関係です。
まとめ
Gemini 3 Computer Use は「AI が自律的に PC を操作する」をデモからプロダクション入口まで押し上げましたが、「何でも安心して任せられる」段階にはまだ届いていません。deny-list、per-step approval、emergency stop — この 3 つのセーフティの仕組みを理解することが、実タスクへの投入前提です。ホテル予約のような低リスクの単一タスクから始め、モデルの安定性への信頼を段階的に積み上げる — MVP に trusted bypass がないことの裏メッセージはまさにこれです。