AIのComputer Useとは？画面を操作するAIの仕組みと、主要3社の実装の違い
Computer Use（コンピュータユース）とは、AIモデルが画面のスクリーンショットを「見て」、マウスのクリックやキーボード入力といった操作を出力し、人間と同じようにGUIを操作する仕組みです。APIが用意されていないソフトウェアでも、画面さえあれば自動化の対象にできる点が最大の特徴です。ただし重要な前提があります。モデルが返すのは「次にすべき操作」であって、実際に操作を実行する環境は利用者側が用意します。この構造を理解しているかどうかで、導入の成否が分かれます。
仕組みは「画面を見る→操作を決める→結果を確認する」のループ
Anthropic、Google、OpenAIのいずれも、公式ドキュメントで説明している動作原理はほぼ同じです。
- アプリケーションが、ユーザーの指示と現在の画面のスクリーンショットをモデルに送る
- モデルが「座標(405,157)を左クリックする」「penguinと入力する」といった操作を返す
- アプリケーション側がその操作を実際の環境で実行する
- 実行後の新しいスクリーンショットをモデルに返し、2に戻る
この繰り返しは「エージェントループ」と呼ばれます。モデル自体はクリックできないので、Playwright（ブラウザ自動操作ライブラリ）やPyAutoGUI、仮想ディスプレイなどを使って操作を実行する部分は、開発者が実装する必要があります。Anthropicは参照実装としてDocker上にXvfb（仮想ディスプレイ）とFirefoxなどを含むコンテナを公開しており、Googleもサンドボックス付きのリファレンス実装をGitHubで提供しています。
従来のRPAやAPI連携とどう使い分けるか
従来型のRPAは、記録した座標や要素IDを再生する方式が中心で、画面が変わると壊れやすいという弱点があります。Computer Useは毎回その時点の画面を解釈し直すため、多少のレイアウト変更には強い設計です。
一方で、常にComputer Useが最適というわけではありません。Anthropicの公式ドキュメントは、処理がWebページの中で完結するなら、デスクトップ環境を必要としない「browser use tool」のほうが適していると明記しています。APIやMCP（外部ツール接続の標準規格）で直接つなげるなら、そちらのほうが速く確実です。判断の順序は「API・コネクタ → ブラウザ特化のツール → フルデスクトップのComputer Use」と考えるのが妥当です。
コスト構造も無視できません。Anthropicのドキュメントによれば、スクリーンショット1枚あたりおよそ1,000〜1,800入力トークンを消費し、ツール定義だけで約4,500トークンが追加されます。数十ステップのループを回せば画像入力が積み上がるため、単価より「1タスクあたり何枚の画面を送るか」がコストを決めます。レイテンシもAPI連携より明確に遅く、リアルタイム応答が必要な用途には向きません。
主要3社の実装の違い（2026年9月時点）
同じ発想の機能でも、インターフェースの設計思想は分かれています。
- Anthropic（Claude API）：
computer_toolset_20260801という1つのツールセットを宣言すると、screenshot、left_click、type、zoomなど17のメンバーツールが使えます。座標は返したスクリーンショットのピクセル空間そのままで、複数操作をまとめて返す「バッチアクション」に対応します。小さな文字を読むためのzoom（指定領域を原寸で再取得）が標準で有効なのが特徴です。 - Google（Gemini API）：
computer_useツールで、browser／mobile／desktopの3環境を選べます。座標は画面サイズに依存しない0〜1000の正規化値で返るため、クライアント側で実寸に変換します。各アクションには判断理由を示すintentが付き、監査ログの材料になります。 - OpenAI（Responses API）：構造化された操作を返す
computerツールに加え、モデルがPyAutoGUIやPlaywrightを使うコードを書いて実行させる「コード実行」方式があり、最新モデルではコード実行が推奨と案内されています。1回の呼び出しにループや条件分岐をまとめられるぶん、往復回数を減らせます。
3社に共通するのは、実行環境とその安全性が利用者の責任範囲だという点です。逆に違うのは抽象度と座標系なので、将来的に乗り換える可能性があるなら、操作の実行部分（ハーネス）を自前で抽象化し、モデル固有の座標変換をそこに閉じ込めておくと移植が楽になります。
個人が試す手段も出てきました。Anthropicは2026年3月、Claude Pro／Max向けにmacOS限定の研究プレビューとして画面操作機能を公開しています。同社はこの機能について、コーディングやテキスト処理と比べるとまだ初期段階であり、誤りが起こりうると自ら注意を促しています。
最大のリスクはプロンプトインジェクション
画面上のテキストをモデルが読む以上、Webページや画像に仕込まれた指示を、ユーザーの指示より優先してしまう危険があります。OpenAIのドキュメントは「画面の内容は信頼できない入力として扱う」こと、ページ内のテキストが権限を与えたり指示を上書きしたりすることはない、と明確に書いています。
各社の対策と推奨は共通しています。Anthropicは、最小権限の専用VMやコンテナで動かす、ログイン情報など機微なデータを渡さない、アクセス先をドメインの許可リストで絞る、決済や規約同意など影響の大きい操作は人間が確認する、という4点を挙げています。加えて、スクリーンショットを分類器でスキャンし、インジェクションの疑いがあればユーザーに確認させる防御層も入っています。Geminiでは金融取引、通信手段の利用、アカウント作成、法的合意などがカテゴリ化され、該当する操作にrequire_confirmationが返る仕組みと、オプトインのプロンプトインジェクション検出が用意されています。
つまり「モデルが賢くなれば安全になる」種類の問題ではありません。承認ポイントの設計と実行環境の隔離は、アプリケーション側で必ず作り込む必要があります。
導入を検討するときの判断基準
向いているのは、APIやコネクタが存在しない社内システムの定型入力、Webアプリのフローテスト、複数サイトを横断する調査など、速度より網羅性が重要で、失敗しても取り返しがつく作業です。逆に、完全な精度が要る処理、不可逆な金銭のやり取り、機微情報を人の監督なしに扱う処理には現時点で適しません。これはAnthropicのドキュメントにも制約として明記されています。
検討を進めるなら、次の順で確認するのが現実的です。
- 対象業務にAPIやMCPサーバーが存在しないかを先に調べる（あればそちらが安く速い）
- 各社の参照実装をサンドボックスで動かし、自社の画面で何ステップ必要かを観察する
- 低リスクな業務を1つ選び、ステップ上限・タイムアウト・人間の承認ポイントを先に決める
- 10〜20件の実データで成功率と1件あたりのトークン消費を実測し、人手コストと比較する
なお、OSWorld（実際のデスクトップ上の369タスクで評価するベンチマーク）などのスコアは比較の出発点にはなりますが、実行ハーネスや試行回数の設定で結果が変わります。公開スコアをそのまま自社業務の成功率と読み替えないでください。判断材料にすべきは、自社画面での実測値です。
Computer Useは、APIのない業務を自動化できる有力な選択肢になってきました。まずは「APIで済まないか」を確認し、済まない業務を1つだけ隔離環境で試し、成功率とコストを測る。ここから始めるのが、過剰投資も過小評価も避ける進め方です。
出典
- Anthropic: Computer use tool（コンピュータ操作ツールの公式ドキュメント）
- Google: Gemini API Computer use（コンピュータ操作機能の公式ドキュメント）
- OpenAI: Computer use（Responses APIでの画面操作ガイド）
- Anthropic: Claude Sonnet 4.6の発表（コンピュータ操作能力とOSWorldについて）
- Google: Gemini 2.5 Computer Useモデルの発表
- CNBC: Anthropicが Claude によるパソコン操作機能を公開（2026年3月）
- OSWorld: 実環境でのマルチモーダルエージェント評価ベンチマーク
