AIREITERGoogleは2026年10月30日、Gemini Computer Useを一般提供（GA）へ移行しました。ただし発表は変更履歴に2行追加された程度で、対象はInteractions APIとGenerateContent API、モデルの追加はなし、料金変更もなしという内容です。実運用で気になるのはもっとシンプルでしょう。スクリーンショットを返し続ける仕組みも、トークン単位の有料課金も変わりません。ただ、これで本番利用を前提に組みやすくなりました。
プレビュー版であることを理由に見送る必要はなくなりましたが、スクリーンショットの課金と安全対策は引き続き実装側の責任です。
10月30日のGAで変わったこと、変わらないこと
2026年10月30日のGA告知が示しているのは、Computer UseツールがInteractions APIとGenerateContent APIの両方で一般提供になった、という一点です。変更履歴には、新しいモデルIDやアクションスキーマ、レート制限、料金の記載はありません。
変わったのはステータスであって、仕組みではありません。computer_useとスクリーンショットのループを使っていたプレビュー版の連携は、そのまま動かせます。GA化でプレビュー版という制約はなくなりましたが、信頼性と安全性は実装に委ねられます。課金は引き続き有料ティアのみで通常のトークン課金。クリックも毎回アプリ側で実行し、結果に影響する操作ではユーザー確認を処理しなければなりません。
Gemini 2.5 Computer Useのプレビュー版（2025年10月7日発表）から移行する場合、必要なのは全面的な書き換えではなく設定の見直しです。Interactions（RESTの例ではhttps://generativelanguage.googleapis.com/v1/interactions）またはGenerateContentでGA版のツールを指定し、PlaywrightやBrowserbaseの実行部分は維持したまま、安全確認の挙動を再テストします。リファレンス実装のREADME例は今もデフォルトでgemini-3.6-flashを使うため、その設定に依存せず、GA対応のモデルIDを明示的に固定してください。
スクリーンショットを返し続ける実行ループ
Gemini Computer Use APIがコンピューターを直接操作するわけではありません。アプリがスクリーンショットと指示を送り、モデルがfunction_callとしてUI操作を提案します。アプリ側でその操作を実行し、新しいスクリーンショットを撮って再び送信する。この流れを、タスクが完了するか、エラーになるか、安全上の停止に達するか、ユーザーが終了するまで繰り返します。
Pythonで最小構成を動かすには、google-genai 2.7.0以上（Computer Useのドキュメントによる）に加え、ブラウザー実行用のPlaywrightが必要です。
pip install google-genai playwright
playwright install chromiumドキュメントの例では、Chromiumをheadless=Falseで起動し、ビューポートを1440 x 900に設定して、https://www.google.comから開始します。リクエストでは"environment": "browser"、モデルにgemini-3.8-flash、ツールタイプにcomputer_useを指定します。Python、JavaScript、Java、Goの完全なエージェントループ例ではターン数5が使われていますが、これはサンプルコード上の設定であり、API全体の上限ではありません。
実装で最も間違えやすいのが座標です。モデルが返すxとyは1000 x 1000の座標空間に正規化されており、通常は0から999までの整数です。実際の画面上のピクセル座標への変換は、アプリ側で行います。
actual_x = int(x / 1000 * screen_width)
actual_y = int(y / 1000 * screen_height)リクエストにディスプレイのサイズを送る必要はありません。Gemini 4とGemini 3.xのレスポンスでは、各アクションにモデルがその操作を選んだ理由を説明するintent文字列と、任意のsafety_decisionも含まれます。
対応モデルと実行環境
現在のComputer Useドキュメントでは、4モデルがComputer Useに対応しています。GoogleはUI操作と安定したツール呼び出しにはGemini 3.8 Flashを推奨し、複雑なエージェントワークフローにはGemini 4 Argonを最も高性能なモデルとして位置づけています。
| モデルID | 位置づけ |
|---|---|
gemini-4-argon | 最も高性能。複雑な推論やエージェント型UIワークフロー向け |
gemini-3.8-flash | Computer Use推奨。高精度なUI操作 |
gemini-3.5-flash-lite | 低レイテンシでコスト効率を重視する場合の選択肢 |
gemini-3-flash-preview | プレビュー版。挙動が変わる可能性あり |
| 環境 | 適した用途 | 主なアクション |
|---|---|---|
Browser（ENVIRONMENT_BROWSER） | Webフォーム、テスト、調査 | クリック、ダブルクリック、トリプルクリック、右クリック、ミドルクリック、移動、press_enter付き入力、ドラッグ＆ドロップ、スクロール（0〜999、デフォルト300）、press_key、hotkey、戻る、進む、navigate、wait（デフォルト1秒）、スクリーンショット |
Mobile（ENVIRONMENT_MOBILE） | Androidアプリの操作フロー | open_app、list_apps、タップ、入力、ドラッグ＆ドロップ、long_press（デフォルト2秒）、戻る、wait、スクリーンショット |
Desktop（ENVIRONMENT_DESKTOP） | OSレベルのカーソル操作 | 各種クリック、移動、入力、ドラッグ＆ドロップ、スクロール、press_key、hotkey、wait、スクリーンショット |
GitHubのリファレンス実装（google-gemini/computer-use-preview、Apache-2.0）は、同じタスクをローカルのPlaywright ChromeとBrowserbaseのクラウドブラウザーという2通りで実行できます。CLIはpython main.py --query "Go to Google and type 'Hello World' into the search bar" --env="playwright"です。--initial_urlのデフォルトはhttps://www.google.comで、視覚的なデバッグには--highlight_mouseを使えます。デバッグに長時間費やす前に知っておきたい既知の問題もあります。OSがページの外側に描画するため、PlaywrightではネイティブHTMLの<select>ドロップダウンをキャプチャできないことがあります。READMEでは、CSS/JSのインジェクションよりBrowserbaseを有力な解決策として挙げています。
思考レベルを調整すれば、操作品質と速度のバランスを取れます。一般的なフォーム入力やテストループなら低いレベル、UIの状態があいまいなケースでは高い推論負荷が向いています。ドキュメントにはレベル名やレイテンシの数値は公開されていないため、自分のワークフローでA/Bテストするための調整項目と考えるのがよいでしょう。
料金の仕組み
Computer Useに無料ティアはありません。料金ページのツール向け料金欄には、Computer UseはFreeでは利用できず、Paidでは通常のトークンとして課金されると明記されています。例としてGemini 3.8 Flashの料金が示されています。Computer Use専用の追加料金はなく、通常の入力トークンと出力トークンとして、ベースモデルの料金が適用されます。
この一文だけでは見落としやすいのが、タスク全体のコストです。1ターンごとにスクリーンショットの入力、持ち越される履歴、アクションの出力が課金されるため、20ステップのフォーム入力なら、リトライを除いても20回の視覚処理が発生します。見積もりにはturns x (screenshot + history input tokens + action output tokens) x base-model rateを使えます。料金ページでは、Flash Standardを2026年12月31日まで入力100万トークンあたり$0.75、出力100万トークンあたり$3.75としています。BatchとFlexはより低いトークン料金ですが、Computer Use自体がPaid専用である点は変わりません。
ラウンドごとにスクリーンショットを送り返すので、そこもトークンとして課金されます。ランダムなクリックはページだけでなく請求額も荒らします。 — @vastplan、AI導入アカウント、投稿
コード側でターン数、スクリーンショットの解像度、リトライ回数に上限を設け、ループ単位で予算を管理しましょう。
安全対策は自分で組み込む
Computer Useの安全性はモデルの内部機能だけで完結するものではなく、周辺のサービスとして設計する必要があります。Gemini 4とGemini 3.xは、提案された各アクションを7つの組み込みポリシーカテゴリで評価します。その結果、実行可能なアクションの代わりにrequire_confirmationやブロックが返ることがあります。クライアントはこのレスポンスを毎回処理しなければなりません。
| ポリシー | 保護する対象 |
|---|---|
FINANCIAL_TRANSACTIONS | 支払い、オンライン購入、規制対象商品 |
SENSITIVE_DATA_MODIFICATION | 医療、金融、政府の記録 |
COMMUNICATION_TOOL | メール、チャット、下書きの送信 |
ACCOUNT_CREATION | Webサイトの新規アカウント登録 |
DATA_MODIFICATION | ファイル変更、共有、ストレージからの削除 |
USER_CONSENT_MANAGEMENT | Cookieバナー、プライバシー確認 |
LEGAL_TERMS_AND_AGREEMENTS | 利用規約や法的拘束力のある契約 |
モデルがdecision: require_confirmationと、たとえばmust check check-boxのようなexplanationを含むsafety_decisionを返した場合、ドキュメントのフローは明確です。人間に確認を求め、続行または終了を選んでもらい、承認された場合は次のfunction_resultにsafety_acknowledgementを含め、CONTINUEまたはTERMINATEの結果を返します。disabled_safety_policiesでポリシーを無効化する設定（例ではdata_modificationを無効化）を指定しても、それはあくまで希望を伝えるだけで、確認を求められる場合はあります。
プロンプトインジェクション検出はオプトインで、デフォルトでは無効です。enable_prompt_injection_detection: trueで有効にでき、Gemini 3.5 Flash-Lite以降で利用できます。スクリーンショットから「以前の指示を無視して」といった隠し指示を探し、見つかると実行をブロックします。Googleはそのほか、VM、Dockerコンテナ、権限を絞った専用ブラウザプロファイルでのサンドボックス化、ナビゲーションの許可・拒否リスト、入力のサニタイズ、コンテンツガードレール、初期状態をクリーンに保った安定したGUI、そして監査用のログを推奨しています。ログにはプロンプト、スクリーンショット、提案されたfunction_callアクション、安全性レスポンス、実際に実行したアクションを残します。
サンプルの安全指示では、自律実行してはいけない操作も列挙されています。利用規約やCookieバナーへの同意、CAPTCHAの解決、購入や送金、メールや投稿の送信、医療・金融記録やSSN・カード番号の操作、ファイルのダウンロード、データ共有、履歴やパスワードの読み取り、ログイン、本人になりすます行為、行き詰まった状態での無限ループなどです。本番での基本パターンは、エージェントには準備作業まで任せ、最後のSend、Submit、Confirm purchase、Shareの直前で止めることです。
今導入すべきか？チェックリストと比較
GA化によって、ブラウザー自動化、フォーム入力、UIの自動テスト、商品ページの調査にComputer Useを使うことは、現実的な本番候補になりました。一方で、スクリーンショットを頼りに動くエージェントであることは変わりません。UIを読み違えたり、長い処理で文脈を失ったり、リトライでトークンを消費したりする可能性は残ります。
実ユーザーに開放する前に、次を確認してください。
- GA対応のモデルIDを明示的に固定する
- ターン数に上限を設け、アイドル状態のループを検出する
- 許可リスト付きのサンドボックス化ブラウザプロファイルまたはコンテナで実行する
- 取り消せない操作の前に必ず人間の確認を求める
- プロンプトインジェクション検出を有効にする
- スクリーンショットと安全判定をログに残す
- 毎回、既知のクリーンな状態からタスクを開始する
- 確認を有効にした状態で購入とログインのフローをテストする
ベンチマークについては、Googleのモデルカードが報告しているのは2.5 Computer Use系統の結果であり、現在のGAモデルではありません。ブラウザー操作に関する系譜上の参考値として見てください。
| ベンチマーク | Gemini 2.5系統 | 比較対象の最高値 |
|---|---|---|
| Online-Mind2Web（公式） | 69.0% | OpenAI Operator 61.3% |
| WebVoyager（公式） | 88.9% | OpenAI 87.0% |
| Online-Mind2Web（Browserbase） | 65.7% | Sonnet 4.5 55.0%、Sonnet 4 61.0%、OpenAI 44.3% |
| WebVoyager（Browserbase） | 79.9% | Sonnet 4.5 71.4%、Sonnet 4 69.4%、OpenAI 61.0% |
| AndroidWorld | 69.7% | Sonnet 4.5 56.0%、Sonnet 4 62.1% |
そのモデルカードの時点では、Claudeの自己申告値61.4%と比較して、OSWorldのデスクトップ操作にはまだ対応していませんでした。現在のドキュメントではデスクトップも対応環境に含まれますが、OSレベルの操作はブラウザーフローより新しく、実績も少ないものとして扱うべきです。
| タスク | 選択肢 |
|---|---|
| 大量の単純入力、コスト優先 | gemini-3.5-flash-lite + 厳格なターン数上限 |
| 一般的なブラウザー自動化、精度優先 | gemini-3.8-flash |
| 複数アプリにまたがる複雑な推論 | gemini-4-argon、サンドボックス環境、人間による承認を有効化 |
| 金銭、アカウント、法的規約に関わる操作 | Human-in-the-loop、金融関連ポリシーは無効化しない |
ローカルのPlaywrightで描画に問題が出る場合は、Stagehandを使ったBrowserbaseのテンプレート（npx create-browser-app --template gemini-cua）から試すのもよいでしょう。どの構成を選んでも、料金と信頼境界を管理するのは実装側です。
よくある質問
GAでGemini Computer Use APIのエンドポイントは変わりましたか？
GAの告知では新しいエンドポイントは発表されていません。Googleは同じツールをInteractions APIとGenerateContent APIの両方で提供しています。GA版のツールに明示的なモデルIDを指定すれば、同じ実行部分を利用できます。
Gemini Computer Useは無料ですか、有料ですか？
有料ティアのみです。公式料金ページには、Computer UseはFreeでは利用できず、基盤モデルの料金に基づく通常のトークンとして課金されると記載されています。スクリーンショットとアクションの各ループも課金対象です。
Computer UseにはどのGeminiモデルを使うべきですか？
Googleは、UIの精度と安定したツール呼び出しにはgemini-3.8-flashを推奨しています。低レイテンシで大量の処理を行うならgemini-3.5-flash-lite、複雑なエージェントワークフローならgemini-4-argonが候補です。本番環境ではプレビュー版のIDを避けてください。
フルデスクトップを操作できますか？それともブラウザーだけですか？
GA版のドキュメントでは、ブラウザー、Androidモバイル、デスクトップOSレベルのカーソル操作に対応しています。最も成熟し、ベンチマークも多いのはブラウザーフローです。デスクトップ操作はより新しい機能として、厳格にサンドボックス化して使ってください。
クリック操作は自分で実行する必要がありますか？
はい。モデルが返すのは、0〜999に正規化された座標と意図を含むfunction_callの提案だけです。マウス操作、入力、スクリーンショット取得、結果の返却は、Playwright、Browserbase、またはネイティブの実行基盤が担当します。
コード上では安全確認をどのように処理しますか？
すべてのレスポンスでsafety_decisionを確認します。require_confirmationが返ったらユーザーに確認し、次のfunction_resultでsafety_acknowledgementとCONTINUEまたはTERMINATEを送ります。ポリシーを無効にしていても、この処理は残してください。
関連記事：Gemini 3.8 Flashの料金とエージェントタスクのコスト、Gemini 4 Argon APIの料金と提供状況、コンピューター操作エージェント向けCUA-Liteレビュー。