AIに画面を操作させる コンピューターユースの任せ方と止めどころ

昨日のGoogle Antigravityの記事で、「ブラウザを操作できる」と1行だけ書きました。ただ、それが業務にとって何を意味するのかは書いていません。今日はそこを扱います。

AIが画面を見て、クリックして、入力する。コンピューターユースと呼ばれる機能です。デモを見ると派手なのですが、自社の業務に入れるとなると話が変わります。何を任せて、どこで止めるか。 そこを決めないまま渡すと、たいてい途中で怖くなって戻すことになります。

つないでいない業務にも手が届く

AIに業務システムを触らせるとき、これまで第一候補はAPIでした。窓口が用意されていれば、権限を絞って安全につなげます。用意されていない場合は、RPAを組むか、CSVで出し入れするか、個別に自動化を作るか。どれも、事前に手順を作り込む必要がありました。

コンピューターユースは前提が違います。AIが見るのは画面で、押すのはボタンです。人が使う画面をそのまま使うので、手順を作り込まなくても、その場で判断しながら進みます。社内の古い業務システム、管理画面しかないSaaS、ログインしないと何も出てこないサイト。ここへの距離が縮まりました。

代わりに割り切っているものもあります。画面の状態を読み取って一歩ずつ進むので、APIを叩くよりは手数がかかります。そして扱うのがログイン済みの画面である以上、そこに映るものは扱う側から見えているという前提になります。速さと確実さより、届く範囲を優先した仕組みだと考えるのが近いと思います。

入口はこの半年で入れ替わっている

この領域は動きが速く、半年前の記事には、もう存在しない製品名が出てきます。

OpenAIは「ChatGPT agent」という名前でこの機能を出していましたが、公式のヘルプは現在こう書いています(訳です)。

ChatGPT agentは提供を終了しました。より長い複数手順のタスクと完成物には、ChatGPT Workをお使いください。

専用ブラウザだった「Atlas」も、2026年8月9日を停止予定日として廃止が案内されました。機能はChatGPTとCodexに移されています。

2026年9月7日時点の入口はこうです。

	名前	提供状況
OpenAI	Cloud browser(ChatGPT Work内)	対応地域の有料プラン。無料版とGoは対象外
Anthropic	Claude in Chrome	有料プラン全部。ただしChrome上ではベータ
Google	Antigravityのブラウザ機能	追加課金なしの枠から使える

作りも用途も揃っていません。OpenAIの Cloud browser はクラウド上の別のコンピュータでブラウザを動かすので、こちらがPCを閉じても作業が続きます。Anthropicの Claude in Chrome は手元のChromeの拡張機能です。Antigravityは開発者向けの環境なので、非エンジニアがいきなり触る入口ではありません。

導入を検討するときは、記事ではなく公式のヘルプを開いてください。この記事も同じです。

3社に共通するのは「見る」と「操作する」を分けたこと

設定画面を見比べると、はっきりした共通点が1つあります。ページを見る許可と、そのページを操作する許可を、一段で扱っていない。

OpenAIのヘルプは、この分離を言葉で書いています。

ウェブサイトへのアクセス許可は、重大な操作の承認とは別のものです。サイトを許可しても、重要な操作を実行前に確認する必要がなくなるわけではありません。

Googleはもっと機械的で、権限のドキュメントにある read_url と execute_url が別々の権限として並んでいます。前者がページの読み込み、後者がクリックや入力です。同じドメインでも、読むのは許可して操作は止める、という書き方ができます。

Anthropicは承認モードを3段階で持ち、そのうえでサイトのallowlistを管理者が設定します。

「このサイトを触ってよい」と「この操作をしてよい」は別、という整理です。当然に見えますが、権限を1本で考えていると混ざります。うちが広告運用で権限を割ったときも、最初は「このアカウントを触らせるか」だけで考えていて、操作の側はあとから足しました。

分かれるのは、止めるのか禁じるのか

一方で、高リスクの操作をどう扱うかは3社で違います。ここを揃っていると思い込むと危ないので、並べます。

	高リスクの操作
OpenAI	確認を求める。「取り消しが難しい操作、または金銭上・法律上・アカウント上その他の現実の約束を生む操作」
Anthropic	一部は禁止。購入、アカウント作成、取引の実行、ファイルの完全削除などはモードによらず実行しない。ダウンロードや機微な情報の入力は確認
Google	Deny / Ask / Allow の3リストで操作の種類ごとに指定。既定はAsk

OpenAIは人に判断を返す設計、Anthropicはそもそもさせない線を製品側で引く設計、Googleは利用者が書く設計です。同じ「安全な設計」でも、誰が線を引くかが違います。

この違いは、そのまま自社での扱い方に響きます。禁止型なら「できないこと」を把握しておけばよく、確認型なら承認する人の判断力が安全装置の一部になります。設定型は自由度が高い代わりに、書き漏らしがそのまま穴になる。

パスワードと視界の守り方は、製品ごとに違う

AIに見せないための経路も用意されていますが、これも各社で形が違います。

OpenAIの Cloud browser は、ログイン画面で止まって専用の入力フォームを出します。

安全なフォームから入力された認証情報は、リモートブラウザへ直接送られます。そこで入力されたユーザー名とパスワードはモデルからは見えず、ChatGPTがその認証情報を保存することもありません。

フォームを出す前に、別の審査モデルがフィッシングかどうかを確認するとも書かれています。クラウド側の別のブラウザなので、手元のブラウザの履歴や保存済みパスワードとは分かれています。

Anthropicは手元のChromeを使うぶん、事情が違います。

Claudeはページを見て次の行動を決めるため、作業中のタブのスクリーンショットを撮ります。そのタブに表示されているものは何であれスクリーンショットに入り、会話の一部になります。

表示されている内容を選り分けることはできないので、機微な情報を扱うサイトでは使わないこと、そして機微なアカウントにログインしていない別のブラウザプロファイルを使うことが勧められています。Antigravityは分離したプロファイルが標準ですが、そのプロファイルの中で入れたログインは残ります。

そして3社が揃って書いていることがあります。リスクはゼロにならない。 Anthropicは、Claude Opus 4.8と現行構成で既知の攻撃手法を組み合わせた内部評価において攻撃成功率を0.08%未満にしたと述べたうえで、「リスクはゼロではありません」と添えています。実運用で事故が起きる確率ではなく、特定の構成での社内評価の値です。

最大の危険はプロンプトインジェクションです。ウェブページやメールに仕込まれた「AIへの命令」を、AIが利用者の指示と取り違える。画面を操作できるAIがこれを踏むと、読むだけでは済みません。

設定作業こそ、コンピューターユースの出番だった

うちがこの機能を一番使ったのは、広告運用そのものではありませんでした。その手前の、APIを使えるようにする作業です。

8月の記事で、Google広告とMeta広告をAPIにつないだときの苦労を書きました。Google Ads APIの開発者トークンはアクセスレベルが4段階に分かれていて、上位のレベルには審査があります。Metaはアプリを作って権限を付ける必要があります。そこにOAuthの同意画面が挟まります。

この一連の作業を、Claude in Chromeにブラウザを操作させて進めました。

向いている理由がはっきりしています。APIを使えるようにする作業に、APIはありません。 管理コンソールを開いて、フォームを埋めて、申請を出す。人が画面でやるしかない領域です。しかも画面は複雑で、公式ドキュメントの説明と実際の表示がずれていることも珍しくない。そのうえ一度きりの作業なので、自動化を組む価値がありません。 RPAを作るほどではないが、人がやると調べながらで半日溶ける。ここがちょうど空いていました。

やり方も、結果的にこの記事で書いた形になっていました。ログインは人が済ませて、その状態から操作だけ引き渡す。 認証情報をAIに渡してはいません。Claude in Chromeは手元のChromeを使うので、開いているタブは見えている前提になります。だから作業に必要なものだけを開いた状態にしておく。前の章で書いた「見せない経路」を、意識せず自然にやっていた形です。

ひとつ、後味の悪い話も書いておきます。この設定作業では、申請フォームが提出されていなかったことに4日後まで気づきませんでした。原因は特定できていません。私たちの操作手順の問題かもしれず、AIの側かもしれず、フォームの挙動かもしれない。分からないままです。

ただ、そこから引ける教訓ははっきりしています。画面操作が保証するのは「押したところ」までです。 相手のシステムで処理が確定したかどうかは、別に確かめないと分かりません。8月の記事ではこう書きました。

開通の判定は、本番で一番やりたい操作を1回通すまで確定しない。

画面を操作させる場合、これはさらに重くなります。AIは自分が見た画面を報告するので、「完了しました」は「完了画面が出た」の意味にしかなりません。外部に対して何かを確定させる作業なら、相手側の管理画面か通知で、人が別途確認してください。

任せる範囲は、戻せるかどうかで割る

運用のほうに話を戻します。8月の記事で、権限を3段に割った表を出しました。

区分	具体例
AIが単独で実行してよい	分析、レポート作成、設定書のドラフト、クリエイティブ案の作成
提案してから承認を取る	予算配分の変更、キャンペーン構成の変更、テストの勝者判定
人しか触らない	支払い設定、配信の開始と停止、権限の操作、規約への同意

分けた軸は2つでした。戻せるかどうかと、外部に対して確定するかどうか。予算配分の変更は金額が動きますが、上限を決めておけば戻せるので2段目に置いています。配信の開始と支払い設定は、外に出た瞬間に確定するので3段目です。

この区分はAPI経由の運用で作ったものなので、そのままコンピューターユースに持ち込むことはできません。画面操作には、APIにはないリスクが乗ります。ログイン済みのセッションを使うこと、画面が丸ごと見えること、そしてプロンプトインジェクション。軸は流用できますが、3段目に置くものは増えます。

始めるなら、順番はこうです。

まず読み取りと下書きから。 調べる、集める、整形する、比較する、案を作る。失敗しても戻せます。

次に、承認を挟む枠を作る。 提案はAIにさせて、実行の前に人が見る。ここに置くのは、変更はするが取り返せるものです。

最後まで渡さないものを決める。 技術的には渡せます。それでも手元に残しているのは、間違えたときに払う額と、説明する相手を考えた結果です。

最初の題材は、ログインの要らない公開情報の収集から選んでください。安全だからではなく、踏んだときの被害を小さくしやすいからです。新しいプロファイルで、どのサービスにもログインせず、書き込みの権限を持たせず、接続するアプリを切っておく。この状態なら、妙な指示を踏んでも持ち出されるものがありません。

慣れてきたら、次は一度きりの設定作業です。人がログインを済ませてから引き渡し、終わったら相手側の画面で確認する。

コンピューターユースで変わるのは、AIが手を出せる業務の範囲です。最終的な責任と、止める権限は人に残ります。 うちの広告運用で手元に残ったのも、承認と、止める判断でした。ツールが賢くなっても、そこは動かないのだと思います。