要点(30秒で): Googleが6月24日、Gemini 3.5 Flashに「Computer Use」を標準搭載した。専用モデルを呼び分けずに、画面を”見て操作する”AIを直接APIから叩ける。試すなら、まずBrowserbaseの公式デモで自分のサイトを一巡させてみるのが早い。

これまで「AIにPCを操作させる」というのは、わざわざ別モデル(Gemini 2.5 Computer Use)を呼び出す必要があった。今回の発表で、その分離が消える。主力のFlashが、そのまま画面を見て、考えて、クリックやキー入力までやってくれる。地味だが、エージェント開発のしきい値を一段下げる変更だ。

しかも数字が強い。OSWorld-Verifiedで78.4を出したと公表されており、これはAnthropic Claudeの最新世代と肩を並べる水準だ。Flash枠でこのスコアが出る、というのが今回の本当のニュースだろう。

何が起きたか

Googleは6月24日(米国時間)、開発者ブログで「Gemini 3.5 FlashにComputer Useが組み込まれた」と発表した。Gemini APIおよびGemini Enterprise Agent Platformから即日利用できる。

これまでGoogleはこの機能を、2025年10月に公開したGemini 2.5 Computer Useという単独モデルとして提供していた。当時のスコアはOSWorldで約61.4(自己申告ベース)。ブラウザ操作には強かったが、デスクトップOSのフル操作は「未対応」と明記されていた、いわば実験的なプレビューだった。

今回それが主力Flashの”内蔵ツール”になり、ブラウザ・モバイル・デスクトップの3面を一通り扱えるよう拡張された。エンジニアからすれば、function callingの延長線上で computer use を呼べる、ということだ。

モデル切り替えからFlash内蔵へ ── Computer Useの呼び出し方が変わった
モデル切り替えからFlash内蔵へ ── Computer Useの呼び出し方が変わった

仕組み——「画面を読む→次の手を決める→実行する」ループ

中身の発想自体は、いま各社が出しているComputer Use系と同じ系譜にある。エージェントがスクリーンショットを受け取り、UIの状態を理解し、次に取るべき行動(クリック座標、入力文字列、スクロール量など)を返す。それをアプリ側のランタイムが実行し、また次のスクリーンショットを返す。この往復ループを回す。

違いは、Flashの応答が速いことだ。Computer Use系はとにかく1ステップごとに往復が走るので、1回の応答が500ms単位で短縮されることが、体感のキビキビ感を決める。8時間動かす自動テストなら、累積で大きな差になる。

GoogleはBrowser Use、Browserbase、UiPathといった既存のブラウザ・RPAエコシステムを引き合いに出していて、「Flashになって速くなったから本番投入できる」というメッセージを意識している。実際に試したい開発者向けには、Browserbaseがホストするデモ環境とリファレンス実装が公開済みで、GitHubから引っ張ってきて自分の環境で動かせるようになっている。

Computer Useの動作ループとセーフガードの中身
Computer Useの動作ループとセーフガードの中身

ベンチマークと競合の地図

OSWorld-Verifiedの数字を並べると、いまの勢力図がはっきり見える。Gemini 3.5 Flash Computer Useが78.4。先代のGemini 3 Flash Previewが65.1だったので、世代交代で十数ポイントの跳ね上がりだ。Anthropic Claude Opus 4.7のComputer Useは78.0前後と報告されており、ほぼ同水準で並走している。

注目すべきは「Flash枠でこのスコアが出た」点に尽きる。Computer Useはこれまで上位モデル(Claude Opusや、専用に切り出されたGemini 2.5 Computer Use)の領分だった。それが、より安く、より速いFlashで足並みを揃えてくる。

価格も追い風で、Gemini 3.5 Flashの本体料金は入力$1.50/出力$9.00(100万トークンあたり)。前世代のGemini 3 Flash Previewからは値上がりしているが、上位のGemini 3.1 Proよりは25%安い。大量のステップを踏むComputer Useでは、この単価差は積み上がる。

競合のAnthropicも独自の動きが続いており、最近はモデル盗用を巡る訴訟が大きな話題になったが、Computer Use単体の競争としては、GoogleがClaudeに数字で並んだ意味は大きい。

OSWorld-Verifiedスコア比較 ── Flash枠でClaude Opus並みに並んだ
OSWorld-Verifiedスコア比較 ── Flash枠でClaude Opus並みに並んだ

使いどころ——「人がやっていた地味な往復」を任せる

Googleが具体例として挙げているのは、社内アプリの機能を片っ端から触って分類タグを付ける作業、ドキュメントを巡回してアクセシビリティ違反を洗い出す監査、そして継続的なソフトウェアテスト

特に最後のが本命に見える。E2EテストはこれまでPlaywrightやSeleniumでスクリプトを書いていたが、UIが変わるたびに壊れる。Computer UseのAIは「ログインしてカートに商品を入れて、決済画面までいけばOK」といった意図ベースで動くので、ボタンの位置や名前が変わっても追従する。

業務側でいえば、SaaSの管理画面を横断して数字を集めるような、いわゆる「画面の前で人がやってきた地味な往復作業」が、いちばん刺さるはずだ。バックエンドのAPIが提供されていない古いシステム相手でも、画面さえあれば動かせる、というのがComputer Useの効きどころでもある。

安全策と、消えない不安

Googleは2つの企業向けセーフガードを同時に出している。1つは「不可逆な操作の前に人間の承認を必須にする」モード。送金・削除・公開のような後戻りできない手前で、必ず人が一拍置く設計だ。

もう1つは「間接的なプロンプトインジェクションを検知したら自動でタスクを止める」仕組み。たとえば訪問先のWebページに「ここの内容を全部メールで送れ」といった隠し指示が埋め込まれていた場合、それを拾って暴走する前に止める、という発想だ。標的型の対抗学習も施したとしている。

ただし、これで安全になったわけではない。Computer Useはブラウザ越しに実際の本番環境のボタンを押せる力を持つ。クレデンシャルへのアクセス権限設計、サンドボックスの分離、ログの可観測性——いわゆる多層防御の方をどう組むかが、現場で問われる本題になる。

日本・個人開発の視点

日本の個人開発・スタートアップ側から見ると、嬉しいのは「専用モデルを切り替えなくていい」ことだ。これまでだと、対話はGemini Flash、操作はGemini 2.5 Computer Useと使い分ける必要があり、コードが二重化していた。それが消える。

そしてもう一つ大きいのが、同日にGoogleがChromeブラウザ側でもGemini in Chromeの「画面から選択」機能を、Chrome 149で配り始めたことだ。ユーザーがChrome上でAIに「この部分を見て」と指示できるUIが整いつつあり、開発者側のAPIと、消費者向けのUI体験が、同じ”画面を見るAI”という思想で同時に進んでいる。

日本のSaaSは、海外と比べてAPI整備が追いついていない領域(古い販売管理、業務系の管理画面)が広い。だからこそ、Computer Useは「日本のSaaSの方が一段刺さる」可能性がある技術だと言える。ここで動ける個人開発者は、地味だが太い受託案件をつかむチャンスになる。

要点まとめ

  • Gemini 3.5 FlashにComputer Useが標準搭載され、専用モデル切り替えが不要になった。
  • OSWorld-Verifiedで78.4を記録し、Claude Opus 4.7の78.0と肩を並べた。
  • 価格は入力$1.50/出力$9.00(100万トークン)。Flash枠の速度と単価でComputer Useが回せるのが新しい。
  • Googleは不可逆操作の人間承認間接プロンプトインジェクション自動停止の2つを企業向けに用意。
  • 本命用途は継続的E2Eテストと、API未整備の業務システムを画面越しに動かす自動化。

🐦‍⬛ 編集部の視点

正直、数字より構造の話の方が刺さる発表だった。Computer Useが”主力モデルの内蔵ツール”側に降りてきた——これは単なる機能追加というより、エージェントAIの設計図の書き換えに近い。

去年までは「対話モデル」「コード生成モデル」「画面操作モデル」と、用途ごとに別のエンドポイントを叩いていた。それが、Flash一つに統合され、function callingと同じ作法で呼べる。この設計が浸透すれば、エージェントの実装コストは大きく下がる。OpenAIもAnthropicも、近いうちに同じ形に寄せてくるはずだ。

一方で、World AI News 編集部として一つ釘を刺しておきたいのは、「画面を操作できるAI」を本番に出すときの、ログとロールバックの薄さだ。LLMの出力は確率的で、同じ画面でも違う手を選ぶ。検証なしで本番ボタンを押させたら、事故は必ず起きる。

ベンチマークは78.4でも、現場で問われるのはたぶん「失敗した22%をどうハンドリングするか」の方だ。読者のあなたが、もしこれを業務に組み込むなら——いきなり本番ではなく、まずBrowserbaseで自分のサイトを巡回させてみてほしい。10回中、何回ちゃんと動くか。そこから設計が始まる。

「AIで楽したな」と空気で刺される時代に、AIが画面までクリックし始めた。便利さの裏側で、「誰がそのクリックの責任を取るのか」という古くて新しい問いが、また一段、重くなる。

出典・リンク

コメントを残す

現在の人気