Computer Useとは?AIの画面操作の仕組みとAPI・ブラウザ操作との違い

AI脆弱性診断
そのAIシステム、従来の診断だけで十分ですか?
外部・内部の弱点に加え、プロンプトインジェクションや過剰な権限などAI固有の攻撃面も診断します。
Computer Use(コンピューターユース)とは、AIがコンピューター画面の状態を観測し、クリック・文字入力・スクロールなどの次の操作を決め、実行結果を再び観測しながらタスクを進める方式です。
重要なのは、モデルが「次に何をするか」を決めることと、アプリケーションまたは実行環境が実際に操作を実行することを分けて理解することです。AIモデルがOSを直接支配するわけではありません。実装側は、許可した操作だけを受け付け、操作後の画面や状態をモデルへ返し、完了条件を別途確認します。
Anthropicの現行ドキュメントでは、computer_toolset_20260801 はスクリーンショット、マウス、キーボード操作を含むデスクトップ操作用のクライアントツールセットとして案内されています。各ツール呼び出しは、利用者側が管理する環境で実行します。Anthropic公式ドキュメント
本記事では、Computer Useを製品名ではなく、画面を介してソフトウェアを操作するインターフェースの総称として説明します。特定のパーソナルAIエージェント製品の内部実装を、API資料だけから推定するものではありません。
Computer Useの仕組み:観測→判断→実行→再観測
Computer Useは、1回の命令で必ず完了する仕組みではなく、画面状態を材料にした反復ループです。AIエージェント全体における反復と終了条件の考え方は、ループエンジニアリングでも解説しています。
- 観測:スクリーンショット、画面座標、またはブラウザの要素情報を取得する。
- 判断:依頼内容と現在の状態を照合し、「どこをクリックするか」「入力すべきか」「完了しているか」をモデルが判断する。
- 実行:実行環境が、許可されたクリック、入力、スクロール、キー操作などを実行する。
- 再観測・検証:更新後の画面や状態を取得し、次の操作または完了判定へ進む。
OpenAIのResponses API向けComputer Useドキュメントも、タスクを送信し、返された操作を実行し、スクリーンショットを返す3段階の交換として説明しています。また、会話の状態とブラウザ・デスクトップ実行環境の状態は別であり、ブラウザのセッションやログイン状態は実装側で維持する必要があります。OpenAI公式ドキュメント
架空の例:フォーム入力の1ループ
次は、テスト用の申請画面に「表示名」を入力して保存する架空の例です。実在するサービス、個人情報、ログイン情報は使いません。
- 実行環境が画面を撮影する。画面には「表示名」の入力欄と「保存」ボタンがある。
- モデルが画面を見て、入力欄のおおよその位置と、未入力である状態を判断する。
- モデルは「入力欄をクリックし、架空の例として『山田テスト』と入力する」という操作を要求する。
- アプリケーションが座標クリックとキー入力を実行する。
- アプリケーションが更新後の画面を返す。入力欄に値が表示されたことをモデルまたはプログラムが確認する。
- モデルは保存ボタンを押す操作を要求する。ただし、ここで外部送信や確定更新になるなら、実装側が人の承認を求める設計にできる。
- 保存後に「保存しました」という表示、または保存済みデータの再取得結果を確認し、完了と判定する。
この例で座標は「操作を届けるための手段」にすぎません。画面レイアウト、拡大率、ポップアップ、読み込み遅延、同名ボタン、エラー表示によって、同じ座標が同じ意味を持たなくなることがあります。そのため、画面操作では操作した事実ではなく、期待する状態変化が起きた事実を確認する設計が重要です。
API・ブラウザ操作・デスクトップ画面操作の違い
3方式の違いは、「AIが賢いか」ではなく、どの層をインターフェースとして使うかです。同じ業務でも、対象システムが提供する接続口と、求める正確性・保守性・操作範囲により選択が変わります。
方式 | 主な操作対象 | AIへ返す観測結果 | 向きやすい条件 | 主な注意点 |
|---|---|---|---|---|
API連携 | データ・業務機能 | JSONなどの構造化した応答 | 必要な機能が認証・権限つきAPIとして提供されている | API仕様、権限、入力検証、冪等性、エラー処理を実装する |
ブラウザ操作 | Webページの要素・タブ・フォーム | DOM、アクセシビリティツリー、要素情報、画面 | 対象がWebに閉じ、画面構造を参照できる | 画面変更、ログイン、動的表示、Webページ内の不信な指示を扱う |
Computer Use | デスクトップ画面全体 | 主にスクリーンショットと座標 | ネイティブアプリを含む複数ソフトをまたぐ、画面以外に安定した接続口がない | 視覚的な曖昧さ、解像度・拡大率、ダイアログ、誤操作の影響を扱う |
この表は一般的な設計上の目安です。実際の結論は、モデル、画面や入力データの品質、画面変更の頻度、求める処理件数、成功率・処理時間・誤操作率などの評価指標、許容誤差によって変わります。
API連携:機能とデータを直接呼ぶ
API連携では、たとえば「注文状態を取得する」「下書きを作成する」「在庫を照会する」といった、システムが公開した機能を構造化した要求で呼び出します。画面上のボタンを探す必要がないため、画面の配置変更には比較的影響されにくく、返却値をプログラムで検証しやすい点が特徴です。
ただし、APIが存在しても、必要な業務操作が公開されているとは限りません。また、APIの有無だけで自動化の可否は決まりません。認可範囲、レート制限、更新の重複防止、業務ルール、エラー時の再実行条件まで確認する必要があります。
ブラウザ操作:Webページの構造を使う
ブラウザ操作は、Webページ内のフォーム、タブ、要素、アクセシビリティツリーなどを利用して操作する方式です。画面画像だけを見る操作より、要素の役割やテキストを参照できる場合があります。
Anthropicのbrowser_toolset_20260801は、ページの構造(アクセシビリティツリー、要素、フォーム、タブ)と、スクリーンショット・表示領域の座標を組み合わせてWebページを扱うものです。同社は、作業がWebページ内に収まる場合にはbrowser useを、デスクトップ全体が必要な場合にはcomputer useを使い分けるよう案内しています。Anthropic公式ドキュメント
Computer Use:画面に見える操作を使う
Computer Useは、ブラウザだけでなく、デスクトップアプリ、ファイル選択ダイアログ、複数アプリ間の移動などを含められる点に特徴があります。一方、画面上の見え方に依存しやすく、UI変更や表示倍率の変更、読み込み途中の状態、通知・モーダル表示の影響を受けます。
したがって、「APIがない画面なら必ず自動化できる」とは言えません。画面を通じて操作可能でも、認証方式、CAPTCHA、利用規約、承認が必要な行為、誤操作時の影響、画面変化への追随コストにより、実装・運用の可否は変わります。また、画面操作が常に遅いとも限りません。処理時間は、画面遷移、待機、再観測回数、ネットワーク、モデル、実行環境、検証の厳しさに依存します。
OpenAIとAnthropicの現行資料で確認する実行経路
製品名が似ていても、実行環境の持ち方は同じではありません。現行ドキュメントでは、少なくとも次の経路を区別して確認できます。
- Anthropic Computer Use:
computer_toolset_20260801を用い、利用者側が制御するデスクトップ環境で呼び出しを実行する方式です。公式仕様 - Anthropic Browser Use:
browser_toolset_20260801を用い、利用者のアプリケーションが実行するブラウザ自動化に対して、ページ構造と画面を使って操作する方式です。公式仕様 - OpenAI Responses APIの持込実行環境:アプリケーションがブラウザまたはデスクトップのランタイムを用意し、モデルが返したアクションを実行して、画面などの観測結果を返す経路です。公式仕様
- OpenAI Agents APIのホストブラウザ:OpenAIホスト環境でブラウザセッションを開始し、イベント、サイトアクセス要求、ログイン、結果確認、セッション削除を管理する経路です。公式仕様
これらは別資料・別経路です。旧来のプレビュー名や、ある経路の仕様を、現在のComputer Use全体の唯一の仕様として扱わないようにしてください。
実装方式を選ぶための判断手順
以下はMojiによる実務上の提案です。まず「どの方式が流行しているか」ではなく、対象の操作をどこで確実に確認できるかから選びます。
- 正本となるデータ・処理を確認する
在庫、残高、承認状態、更新結果など、業務上の正本がAPIやDBにあるなら、画面上の表示だけで完了を判定しない設計を検討します。 - 必要な操作範囲を分ける
Webページだけで完結するか、デスクトップアプリ・ファイルダイアログ・複数アプリの往復まで必要かを整理します。 - 観測可能な状態を決める
「クリックできた」ではなく、「保存済みIDが返った」「一覧に新しい行が出た」「ステータスが更新された」など、成功を示す状態を定義します。 - 失敗時の影響で権限を分ける
閲覧、下書き、更新、送信、金銭・契約に関わる確定操作を同じ権限で扱わないようにします。 - 同じテストケースで比較する
対象業務に近いケースで、成功率だけでなく、再試行回数、手動介入回数、所要時間、誤操作の有無、画面変更後の復旧容易性を記録します。
エージェントのツール、権限、状態、ログ、復旧経路を一体で設計する観点は、ハーネスエンジニアリングも参考になります。対象業務そのものがエージェントに向くかを先に整理したい場合は、AIエージェントとは?を確認してください。
安全に試すための最小チェックリスト
Computer Useでは、画面に表示される文言や画像も外部入力になり得ます。Webページ上の指示を、利用者の指示や社内ルールより優先させないことが必要です。
- 専用の仮想マシン、コンテナ、またはテストアカウントで開始する
- 必要最小限の権限だけを付与し、ログイン情報や機密情報へ不要にアクセスさせない
- 接続先を必要なドメインに限定できるか確認する
- 送信、購入、規約同意、権限変更、削除など、現実的な影響が大きい操作は人の確認を挟む
- 操作ログ、画面遷移、最終状態、停止・再開の手順を残す
- 画面の文言を根拠に権限を拡大したり、保護情報を入力したりしない
Anthropicは、最小権限の専用環境、機密情報へのアクセス回避、ドメインの許可リスト、人による確認を注意事項として示しています。Anthropic公式の安全上の注意 OpenAIのAgents APIでも、サイト単位のアクセス承認は個別の購入・破壊的変更などへの確認を保証しないため、確実な確認が必要なら操作できないリソースに制限するか、自ら制御するブラウザ実行環境を使うよう案内しています。OpenAI公式の承認に関する注意
まとめ:Computer Useは「画面をAPIにする」技術ではない
Computer Useは、画面を見て操作するAIのための実行方式です。しかし、画面を介しているからといって、画面が安定したAPIと同じ性質になるわけではありません。
- APIは、機能・データを構造化して直接扱いやすい
- ブラウザ操作は、Webページの構造と画面を利用できる
- Computer Useは、画面に見える範囲を介してデスクトップ全体を扱える一方、視覚的な状態変化と実行環境の制御が中心課題になる
方式選定では、「APIがないから画面操作」と直結させず、正本データ、必要な操作範囲、確認可能な完了状態、許容できない操作、画面変更時の保守性を順に確認してください。モデルの判断だけに完了を委ねず、アプリケーション側で操作の許可と状態変化の検証を担うことが、Computer Useを業務へ組み込む出発点になります。