Gemini Computer Useで画面が動く時代、AI副業の単価を分けるのは『止め方』の設計だった

AIツールで自動化の仕組みを組めるようになったのに、収益がゼロのまま止まっている人が多い。自分は10年以上現役でエンジニアをやりつつ、副業でAIエージェントを24時間動かしているけれど、この壁は道具の進化では超えられないと感じている。

Googleが公開したGemini APIのComputer Useが話題になっている。ブラウザやデスクトップの画面をAIが見て、次にクリックすべき場所や入力すべきテキストを返してくれる機能で、いよいよ「AIが人間の代わりにPCを操作する時代」だと騒がれている。

でも、この機能を触って「案件が取れる人」と「触っただけで終わる人」の差は、機能そのものにはない。差が出るのは、動いた後の設計の部分だ。

AIが画面を操作できるようになっても、稼げる人と稼げない人は同じままだ
Gemini API Computer Useが返すのは『操作の実行』ではなく『次の一手の提案』
1. スクリーンショットを見て、クリックや入力の候補を返すだけの仕組み
動くデモより先に聞かれるのは『止め方』と『権限の境界』
自動化案件で単価が乗るのは、検証項目を設計できる人
まとめ
参考
【PR】フリーランスエンジニアにおすすめのツール
【PR】おすすめの書籍
1. あわせて読みたい

AIが画面を操作できるようになっても、稼げる人と稼げない人は同じままだ

「AIが画面を見て操作できる」と聞くと、いよいよ手作業が全部無くなると感じる人が多い。実際、SNSでは「業務が全部AIに置き換わる」「エンジニアの仕事が終わる」といった反応が並んでいる。

ただ、自分の実感としては逆で、こういう新機能が出るたびに「触れる人」と「案件にできる人」の距離はむしろ広がる。理由はシンプルで、新機能は誰でも触れるから、触れる時点では差別化にならないからだ。

副業でAIを回している中で何度か経験したのが、「動いたスクリーンショットをXに貼って終わる人」と「動いた後の運用設計まで詰めて発注に繋げる人」の差だった。今回のComputer Useも構造は同じで、動かすだけなら公式ドキュメントを読めば数時間で辿り着ける。むしろ稼げるかどうかを分けるのは、動いた後に「これを本番で回すには何を決めなきゃいけないか」を言語化できるかどうかだ。

Claude Codeで仕組みは作れたけど収益がゼロのまま、という人ほど、この差が響く。仕組みを作る力ではなく、仕組みを「安心して人に渡せる状態にする力」が単価に直結する。

Gemini API Computer Useが返すのは『操作の実行』ではなく『次の一手の提案』

まず、機能そのものの誤解を解いておく。Computer Useは「AIがブラウザやPCを勝手に動かしてくれる魔法」ではない。ここを間違えると、案件の見積もりも工数も狂う。

Google公式の資料では、Computer Useの推奨モデルとしてgemini-3.5-flashが挙がっていて、ブラウザ・モバイル・デスクトップ環境をサポートしている。2025年10月に出たgemini-2.5-computer-use-preview-10-2025はLegacy Preview扱いに移った。これから触るなら3.5 Flash軸で見ておくのが自然だ。

重要なのは、モデルは「次にこう操作するとよさそう」という候補を返すだけで、実際にクリックしたり文字を打ったりするのは自分たちのクライアント側コードだという点だ。ここが従来の「テキストを返すAI」と決定的に違うようで、実は責任範囲としては大差がない。API呼び出しの結果を受け取って、次の処理を走らせるのは開発者側の仕事のままだ。

スクリーンショットを見て、クリックや入力の候補を返すだけの仕組み

もう少し中身に入る。Computer Useにモデルに渡すのは、ユーザー指示・現在の画面スクリーンショット・直近の操作履歴の3つだ。これに対してモデルが返してくるのは、たとえば以下のようなものだ。

・指定座標をクリックする・テキストを入力する・ページをスクロールする・戻る・進む・URLへ移動する・キー操作を行う

gemini-3.5-flashだと、操作にintentという「なぜその操作を選んだか」を示す情報が付くようになっていて、判断の透明性が上がっている。加えて、安全上必要な場合にはsafety_decisionという形で「人間の確認が必要な操作」として返される仕組みも入っている。

つまり実装イメージは、「画面を見る、操作する、また画面を見る」のループだ。1回APIを叩いて終わりではなく、スクリーンショット駆動のループとして設計する必要がある。ここに、Playwrightのようなブラウザ自動操作ツールを組み合わせるのが定番の構成になる。

座標ベースの操作なので、画面サイズやズーム率、スクロール位置の影響をモロに受ける。ここが検証の肝で、「デモは動いた、本番で崩れた」の8割はこの周辺で起きる。自分が別件でスクリーンショットベースの自動化を組んでいた時も、モニターの解像度が変わっただけで座標がズレて全部壊れた経験がある。3時間かけた仕組みが5分で壊れた。泣いてない。

動くデモより先に聞かれるのは『止め方』と『権限の境界』

ここからが本題で、案件に繋がるかどうかの分岐点でもある。

Computer Useのデモを見せると、初対面のクライアントは大抵「すごい」で終わってくれる。ただ、実際に社内で走らせる話になると、質問が一気に切り替わる。「何かあった時に止められますか」「どのアカウントで動きますか」「監査ログはどう残しますか」──動いた瞬間の話ではなく、動き続ける仕組みの話に飛ぶ。

公式ドキュメントでも、重要なタスクでは監督を強めること、重大な判断や機微情報、取り返しのつかない操作には注意すること、といった注意が明示されている。Preview機能である以上、「動く」ことと「安心して任せられる」ことの間には距離があるという前提が置かれている。

発注側の目線に立つと、次のような観点が最初に飛んでくる。

・サンドボックスやVM、コンテナで実行環境を分離しているか・本番アカウントではなく検証用アカウントで動かせるか・高リスク操作(送金・削除・外部送信)で人間確認が必ず入るか・秘密情報が画面に映る前提でログマスキングを設計しているか・プロンプトインジェクションへの想定と対策があるか・監査ログとして画面・操作・モデル応答・人間確認を残しているか

この一覧を「発注前チェックリスト」として持っている担当者は、SIerや情シスなら山のようにいる。逆に言えば、開発者側がこの観点を先に潰した提案を持ち込めれば、それだけで話が前に進む。自分の副業でも、機能デモではなく「止め方の設計書」を先に出した案件の方が、圧倒的に決着が早かった。

仕組みを作れる人は山ほどいる。「仕組みを止められる形で作れる人」は、そこから一段落ちる。ここが、Claude Codeで動くものは作れるのに1円も入ってこない状態を抜けるヒントだと思っている。

自動化案件で単価が乗るのは、検証項目を設計できる人

もう一歩踏み込むと、Computer Useのような新機能で発注が発生する時、単価が乗るのは「実装する人」ではなく「検証項目を設計できる人」だ。

この機能で作れるものとして公式が挙げている代表例は3つある。Webサイト上の繰り返し入力やフォーム入力の自動化・Webアプリケーションのユーザーフロー自動テスト・複数サイトを横断した調査や情報収集だ。E2Eテスト補助や、SaaS管理画面の読み取り・棚卸しあたりは、事故が起きにくくて始めやすい。

ただ、どのユースケースでも、動くところまでは公式サンプルとPlaywrightの組み合わせで割と早く辿り着ける。差が出るのはその後で、「本番投入する前に何を潰しておくか」の設計だ。ここが単価を分ける。

PoCの見積もり段階で、たとえばこういう項目を先に持っていける人は強い。

・対象タスクは小さく、成功条件が明確か・検証用アカウントと検証用データで実行しているか・操作前後のスクリーンショットを保存しているか・モデル応答と実行結果をログに残しているか・高リスク操作で必ず人間確認が入るか・操作失敗時に停止できるか・連続実行時の上限回数やタイムアウトがあるか・画面レイアウト変更時の失敗を検知できるか・コストとレイテンシを代表タスク単位で測っているか

これは公式が示しているチェック観点をベースにしているが、ここまで整理して見積もりに落とせる人と、「とりあえず動きます」で提案する人では、単価が2倍以上変わることは珍しくない。発注側からすると、動いた後の運用不安が消えている提案の方が、稟議が通りやすいからだ。

AIツールで仕組みは作れているのに収益が乗らない原因は、大体ここだ。動くものを作る力はもう持っている。足りないのは、動くものを「止められる状態」「監査できる状態」「引き継げる状態」に整えて渡す設計力の方だ。

新機能を触った時、「動いた」で満足せず、「これを他人に渡す時に何を書くか」まで一気に言語化するクセをつけると、次の案件で単価が変わってくると思うよ。すごく。