AI に PC の作業を任せる方法は、API で直接つなぐやり方だけではありません。
画面のスクリーンショットを AI に見せて、マウスとキーボードの操作で PC を動かしてもらう方法もあります。
これがコンピューターユース（Computer Use）と呼ばれる仕組みです。
API が用意されていない業務画面でも、人と同じ画面を通して作業できるところに強みがあります。
その代わり、遅さや押し間違い、画面に書かれた文字による乗っ取りといった、ほかの連携方式には無い弱点も抱えています。
コンピューターユースは画面を通してPCを動かす仕組み
AI が人と同じように画面を見て、カーソルを動かし、ボタンを押し、文字を打つ使い方を指します。
Anthropic は 2024年10月22日、新しい Claude 3.5 Sonnet とあわせて、この機能をパブリックベータとして API で公開しました。
当時の発表は、まだ実験的な段階で、手間取ったり間違えたりすることがあると断っていました。
経緯は Anthropic の発表記事で読めます。
OpenAI も 2025年1月23日に、同じ考え方のモデル Computer-Using Agent（CUA）を発表しました。
CUA は GPT-4o の画像を読む力に強化学習を組み合わせたもので、ブラウザ操作を代行する Operator の中で使われました。
仕組みの説明は OpenAI の CUA の発表にあります。
Operator はその後、2025年7月17日に ChatGPT の中の ChatGPT agent へ統合されています。
1回の操作はスクリーンショットから始まる
コンピューターユースの動きは、同じ手順の繰り返しでできています。
Anthropic のドキュメントに沿うと、流れは次のとおりです。
- アプリが、依頼文とコンピューターユースのツールをモデルに渡す
- モデルが「画面を撮る」「座標 (512, 742) を左クリックする」のような操作を返す
- アプリが手元の環境でその操作を実行し、スクリーンショットなどの結果を返す
- モデルは新しい画面を見て、次の操作を決める
- モデルが操作を返さなくなったら、作業は終わり
モデル自身は、PC に一度も触れていません。
モデルが返すのは操作の指示だけで、実際にクリックするのはアプリ側のプログラムです。
以下は、このループをアプリ側から見た擬似コードです。
# 擬似コード（アプリ側のループ）
messages = [依頼文]
while True:
reply = モデルに送る(messages, tools=[コンピューターユース])
if reply に操作の指示が無い:
break # 作業が終わった
for 操作 in reply の操作の指示:
結果 = 手元の画面で実行(操作) # クリック・入力・撮影
messages に 結果 を足す # 撮影なら画像が入る
# 略: 回数の上限・エラー時の中断2026年9月時点の Claude API では、computer_toolset_20260801 というツールを 1 つ指定して使います。
これ 1 つで、screenshot・left_click・type・zoom など 17 個の操作が使えるようになります。
2026年10月20日時点のドキュメントでは、このツールは Claude API と Google Cloud で一般提供（GA）、Amazon Bedrock・Microsoft Foundry・Claude Platform on AWS ではベータの扱いです。
Claude API と Google Cloud では、Claude 5.5 以降のモデルはこの computer_toolset_20260801 だけを受け付け、以前の computer_20251124・computer_20250124 を指定するとエラーを返します。
仕様の一次情報は Anthropic の computer use tool のドキュメントです。
クリックして文字を打ち、最後に画面を撮る、といった短い操作の列を 1 回の応答でまとめて返すこともできます。
その場合、アプリは順番に実行し、途中で失敗したら残りを実行しません。
座標は、アプリが返したスクリーンショットの画素が基準です。
画像を縮小して送ったなら、返ってきた座標を元の大きさに戻してからクリックする必要があります。
操作の指示が決まった形で返ってくるところは、ファンクションコーリングと同じ仕組みです。
APIやブラウザ自動化との違い
AI に外の作業をさせる方法はほかにもあり、違いは AI が何を見て、何を返すかにあります。
- ファンクションコーリング: AI は決められた関数名と引数を返す。相手は API で、画面は使わない
- ブラウザ操作用のツール: ページの構造（アクセシビリティツリーや要素）とスクリーンショットの両方を読んで、Web ページを操作する
- コンピューターユース: スクリーンショットと座標だけを手がかりに、デスクトップ全体を操作する
Anthropic のドキュメントも、作業が Web ページの中で済むなら、ブラウザ操作用の browser use tool のほうが合うとしています。
API があるなら、画面を撮って読む往復が要らない分、そちらのほうが速く済みます。
コンピューターユースは、API もページの構造も使えない場面で選ぶものと考えると分かりやすいでしょう。
どんな場面で使われるか
Anthropic は 2024年の発表で、表計算の中身を確かめ、ブラウザで関連ページを開き、そのデータでフォームを埋める、という流れを例に挙げていました。
現在のドキュメントは、速さが重要でない用途として、裏で進める情報収集やソフトウェアの自動テストを挙げています。
どちらも、信頼できる環境で動かすことが前提です。
考えやすいのは、次のような場面です。
- API が公開されていない社内システムや、古い業務アプリへの入力
- 表計算の値を別のアプリの画面へ写すような、複数のアプリをまたぐ作業
- 見た目の操作ごと確かめたい画面のテスト
どこまでできるようになったか
実力を測る代表的なベンチマークに、実際の OS 上で作業させる OSWorld があります。
2024年4月の論文では、369 個の作業のうち人は 72.36% をこなせた一方、最も良いモデルでも 12.24% でした。
2024年10月の Claude 3.5 Sonnet は画面だけを見る条件で 14.9% を記録し、2025年1月の CUA は 38.1% まで伸ばしています。
2026年6月に公開された OSWorld 2.0 は、人がこなすのに中央値で約 1.6 時間かかる長い作業 108 個に切り替えました。
2026年9月時点の公式サイトでは、最も良い Claude Opus 4.8 でも、500 ステップまでに完了できた作業は 20.6% にとどまります。
詳しい条件は OSWorld 2.0 の公式サイトに載っています。
同じサイトは、いまのエージェントがつまずくのは基本的な画面操作よりも、長い作業の進め方だと分析しています。
条件を忘れる、途中で届いた情報を見落とす、利用者に聞かずに推測する、確認を飛ばす、といった失敗が挙がっていました。
短い操作はこなせても、長い作業を最後までやり切るのはまだ難しい段階です。
使う前に知っておきたい落とし穴
弱点は大きく 3 つあり、どれも画面越しに 1 回ずつ操作する作りから来ています。
1回ずつ往復するので遅い
画面を撮って送り、次の操作を待つ往復が、操作のたびに発生します。
Anthropic のドキュメントも、いまの速さは人が自分で操作するより遅い場合があると書いています。
スクリーンショットは 1 枚あたりおよそ 1,000〜1,800 トークンを使うため、長い作業ほど費用もかさみます。
小さなボタンは押し間違えやすい
モデルは、クリックする座標を間違えたり、ありもしない位置を答えたりすることがあります。
Anthropic の 2026年5月のベストプラクティス記事は、チェックボックスやドロップダウンの矢印のような小さな的ほど精度が落ちるとしています。
同じ記事は、スクリーンショットを API の上限に収まるよう先に縮小しておくことを、最も効果の大きい改善に挙げていました。
内容は Anthropic のベストプラクティス記事にまとまっています。
スクロールが効かないアプリでは、Page Down などのキー操作に置き換えると通ることもあります。
ブラウザの自動操作で、座標を決め打ちしたクリックがページの高さの揺れで空振りした例は、別の記事に書きました。
画面に書かれた文字で指示を乗っ取られる
Web ページや画像の中に書かれた指示に、モデルが従ってしまうことがあります。
画面をそのまま読むコンピューターユースは、このプロンプトインジェクションを避けて通れません。
Anthropic は、スクリーンショットなどツールの戻り値を分類器で自動的に調べています。
怪しい指示が見つかると、それが本当に利用者からの指示かを確かめるようモデルを誘導する仕組みです。
ただし、ドキュメントは 分類器があっても、ほかの対策は引き続き必要だとしています。
権限を絞り、大事な操作は人が確かめる
Anthropic のドキュメントが挙げる対策は、次のとおりです。
- 権限を最小限にした専用の仮想マシンかコンテナで動かす
- ログイン情報のような機密データに触れさせない
- インターネットの接続先を許可リストで絞る
- 購入や利用規約への同意のように、影響の大きい操作の前に人が確認する
AI エージェントを隔離した環境で動かす考え方は、サンドボックスの記事で整理しています。
ベストプラクティス記事は、フォーム送信・購入・メッセージ送信・データの変更の前に止めて確認を取ることを、乗っ取りへの最も効果的な対策としています。
OpenAI の Operator も、ログイン情報や支払い情報の入力は利用者に操作を代わってもらい、注文やメール送信の前には承認を求める設計でした。
取り返しのつかない操作の手前で人が止められるかが、導入を決めるときの目安になります。
最後に
コンピューターユースは、スクリーンショットを見たモデルが操作を返し、アプリがそれを実行する往復で PC を動かします。
API もページの構造も使えない画面に手が届く一方で、遅さ、押し間違い、画面経由の乗っ取りという弱点があります。
API で済む作業は API に任せ、画面越しの操作は権限を絞った環境と人の確認を用意してから使うのが基本です。
以上です。
コメントを残す