いまの Claude Computer Use は、二つの異なる実行契約を指しています。 API 側では、Anthropic はビルダーに対して、スクリーンショット、マウス操作、キーボード入力、デスクトップ自動化を自分で管理するサンドボックス内で使う beta ツールを提供しています。製品側では、Cowork と Claude Code は Claude があなた自身のマシン上で仕事を進める経路を指し、Anthropic のデスクトップ製品がセッションを回しつつ、どのアクセスや承認を許すかはあなたが決めます。
最短で正しい答えはこうです。製品に自動化を組み込みたいなら API ルートを使う。自分のマシン上で Claude に仕事をさせたいなら Cowork か Claude Code を使う。 重要なのは「Claude はクリックできるのか」ではありません。重要なのは「実行環境を誰が所有し、ツールループを誰が持ち、どの権限境界と保持条件を受け入れるのか」です。
“証拠メモ:本記事は Anthropic の現行 computer use API docs、Cowork ヘルプページ、Cowork 製品ページ、computer use のプライバシー説明 を 2026 年 3 月 28 日時点で確認した内容に基づいています。
TL;DR
- Anthropic API computer use はビルダー向けです。beta ツールを有効にし、自分で用意した VM やコンテナの中で Claude を動かし、実際の操作を実行して
tool_resultを返します。 - Cowork と Claude Code は、自分のマシン上で Claude に仕事を委ねたい人向けです。Anthropic のデスクトップ製品がセッションをオーケストレーションし、あなたはフォルダ、コネクタ、承認、そしてファイルやブラウザから画面操作へエスカレートさせるかどうかを管理します。
- 最速で試すなら、API 側は Anthropic の reference implementation から始めるのが安全です。デスクトップ側は Claude Desktop -> Cowork から入るのが最短です。
- この二つのルートは、設定、権限、データ保持で一つの共通契約を共有していません。別々に理解する必要があります。
- 安全な基本順序は コネクタまたはローカルファイル -> ブラウザ -> 画面操作 です。
- 機密アカウント、支払い、同意フロー、完璧な精度が必要な操作では、どのルートでも人間の確認を外さないでください。
Claude Computer Use はいま何を指しているのか

この言葉が最初に目立ち始めた頃は、主に一つの開発者向け能力を指していました。Anthropic が Claude にスクリーンショット理解とマウス・キーボード操作の手段を与え、制御されたデスクトップ環境の中でタスクを進められるようにした、という話です。エージェント製品を作る人にとって、いまでもこのルートは中心です。
ややこしくなったのは、Anthropic が同じ種類の能力を Cowork や Code の製品ストーリーにも広げたからです。現行の Cowork 製品ページでは、Claude がスマホとデスクトップをまたいで同じ会話を続け、コネクタを使い、Chrome でウェブ作業をし、直接統合がないときにはコンピュータ自体を使うと説明されています。ヘルプページでは、Cowork は Claude Desktop の中で動き、ユーザーのコンピュータ上でタスクを実行し、作業中でも途中介入できると書かれています。つまり、同じ言葉がいまは二つの異なる実行モデルを指しています。
ここで起きやすい誤解はかなり実務的です。ビルダーは API 側で Anthropic がどこまで面倒を見てくれるかを過大評価しやすく、デスクトップ側のユーザーは自分のマシンでの権限設定、スコープ、承認がどれだけ重要かを過小評価しやすいのです。このテーマを理解するいちばん確かな方法は、実行環境の所有者で分けることです。 あなたのアプリが tool_use を受け取り、操作を実行し、結果を返すなら API ルート。Anthropic のデスクトップ製品があなたのマシン上でセッションを回すなら Cowork または Claude Code ルートです。
もう一つ最初に分けておくべきなのは、ブラウザ使用と完全なコンピュータ使用は同じではないということです。Anthropic の Cowork ページには、実はかなり良い優先順位がすでに書かれています。コネクタで解けるならコネクタ、Chrome で済むならブラウザ、直接統合がないときだけ画面操作。この順序のほうが、「Claude はコンピュータを使える」という派手な表現よりずっと実務的です。
ルート1: Anthropic API のコンピュータ使用ツール

製品の中に自動化を組み込む、社内向けエージェントを作る、あるいは人間のように GUI を操作する必要があるワークフローを組みたいなら、見るべきなのはこの API ルートです。Anthropic の現行ドキュメントでは、computer use はスクリーンショット取得、マウス制御、キーボード入力、一般的なデスクトップ自動化を行う beta ツールとして説明されています。ここでいちばん重要なのは「Claude がクリックできる」ことではなく、契約の形です。Claude が tool call を返し、あなたのアプリが VM またはコンテナ内で実際の操作を実行し、tool_result を返し、そのループを完了まで繰り返します。
この「ループを所有するのはあなた」という点がすべてを決めます。Anthropic があなたの代わりにマシンを遠隔操作するわけではありません。システムインテグレータはあなたです。 ディスプレイをどう用意するか、スクリーンショットをどう取得するか、高解像度で座標をどう変換するか、クリックやキー入力をどう実行するか、どんな制約でモデルを閉じ込めるか。computer use を API で使うとは、単に強い機能をオンにすることではなく、ツール契約を実際の実行環境につなぐことです。
現行の beta ヘッダーも、これがあくまでツール契約であることを示しています。Anthropic は現在、
computer-use-2025-11-24を Claude Opus 4.6、Claude Sonnet 4.6、Claude Opus 4.5 向けcomputer-use-2025-01-24を Sonnet 4.5、Haiku 4.5、Opus 4.1、Sonnet 4、Opus 4、そして廃止予定の Sonnet 3.7 向け
として案内しています。
最小限のリクエスト骨格は次のようになります。
bashcurl https://api.anthropic.com/v1/messages \ -H "content-type: application/json" \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "anthropic-beta: computer-use-2025-11-24" \ -d '{ "model": "claude-opus-4-6", "max_tokens": 1024, "tools": [ { "type": "computer_20251124", "name": "computer", "display_width_px": 1024, "display_height_px": 768, "display_number": 1 } ], "messages": [ { "role": "user", "content": "Open the browser and summarize the dashboard." } ] }'
このスニペットが教えてくれるのは、「万能なコンピュータ自律性」が手に入るということではありません。どの beta 契約を使うか、どのツール型を使うか、どの表示面を前提にするかを、あなたが明示的に渡すということです。その外側の環境づくりこそが本体です。
このルートが最も強いのは、実際に GUI しかないケースです。古い業務アプリ、きれいな API を持たない社内ツール、RPA に近いブラウザ操作、end-to-end テストなどは合理的な用途です。逆に、すでに API、CLI、Webhook、DB クエリなどがあるなら、画面操作はたいていより悪い設計です。computer use が悪いのではなく、直接触れる機械向けインターフェースがあるのに、いちばん壊れやすい層を使っているからです。
コスト構造もその判断を後押しします。Anthropic の現行 docs では、computer use beta は 466-499 の system prompt tokens を追加し、Claude 4.x 系では 735 のツール定義入力トークン も必要だと書かれています。さらにスクリーンショットの vision コストと tool result のコストが乗ります。つまり、画面レベルの自動化には必然的に視覚的文脈のオーバーヘッドがついてきます。UI そのものが唯一の入口なら払う価値がありますが、そうでないなら高い回り道です。
ここでいちばん価値があるのは安全ガイドです。Anthropic は 専用の VM またはコンテナ、最小権限、ドメイン制限、重大な操作に対する人間の確認を推奨しています。さらに Web ページや画像からの prompt injection も明示的に警告しています。これは定型的な注意文ではありません。computer use の本質です。モデルが画面上の指示を読み、そこから次の行動を決める以上、環境は常に潜在的な対抗入力だと考えるべきです。
もう一つ見落としやすい実装上の論点が座標スケーリングです。Anthropic の現在の docs では、モデルが見る画像サイズと、実際に操作するスクリーン座標が一致しない場合があると説明されています。自分で縮尺変換をしないと、推論自体は正しくてもクリック先がずれます。これも API ルートが「機能好きの人向け」ではなく「実装責任を負える人向け」である理由です。
ルート2: Cowork と Claude Code を自分のコンピュータで使う
多くの人が「Claude にコンピュータを使わせたい」と言うとき、実際に求めているのはこのデスクトップ製品ルートです。ここで重要なのは、あなたが自分の製品にツールループを組み込むのではなく、Anthropic のデスクトップ環境を使って、自分のマシン上の仕事を Claude に委ねることです。現行の Cowork ヘルプページでは、Cowork には Claude Desktop が必要で、macOS と Windows をサポートし、Web やモバイル単体の実行面ではないと説明されています。タスク中はデスクトップアプリを開いたままにしておく必要があります。
この時点で、API と同じものではないことがかなりはっきりします。API は統合契約です。Cowork は製品ワークフローです。Anthropic はこれを「タスクを渡して、出来上がった成果物を受け取る」方向で説明しています。デスクトップアプリはあなたが共有したフォルダ、コネクタ、ローカルファイルを扱い、長めのタスクを実行できます。さらにヘルプページでは、タスクがデスクトップ上で動いている間に、スマホから Claude にメッセージを送り続けられるとも書かれています。これは API の便利さとは別の種類の便利さです。こちらは runtime を作るのではなく、製品の中で舵を取る感覚に近いです。
Cowork 製品ページには、二次情報が省きがちな重要なヒントもあります。Claude はまずコネクタ、次に Chrome、最後に画面を使う。つまり Anthropic 自身の文脈でも、画面操作は第一選択ではなく最後の手段です。この順番を先に理解しておくと、「Claude はあなたのコンピュータを使える」という派手な表現に引っ張られにくくなります。
Anthropic の書き方は可用性についても慎重です。ヘルプページでは、Cowork 全体は有料プランの Claude Desktop 上で macOS と Windows にまたがって使えるとされています。一方、製品ページのより強い表現、つまり "Anything you can do on your computer, Claude can do" には Available on macOS とあります。ここで無理に「全部同じ」と言い切るのは危険です。文書が実際に言っていることだけを言うべきです。Cowork というデスクトップ作業面は広いが、明示的な computer-use 訴求は現時点では macOS に結びついている、という理解がいちばん安全です。
加えて、Anthropic はその製品ページで persistent conversation と computer use update が Cowork と Code の両方にまたがると述べています。ただし、現時点で最も具体的に公開されている運用手順は Cowork 側であり、Code 側の完全対称なセットアップ手順が同じ粒度で公開されているわけではありません。だから実務上は、Code を同じファミリーの関連面として理解しつつ、具体的なスタートは Cowork ドキュメントに寄せるのがいちばん堅実です。
権限の境界もこちらはずっと製品寄りです。Cowork ヘルプページでは、ファイルを恒久削除する前に明示的な許可が必要だと書かれています。製品ページでは、Claude はまず計画を見せて承認を待ち、アクセスできるフォルダやコネクタをあなたが決めると書かれています。これは、サンドボックスや確認ロジックを自分で作る API ルートとはまったく違う姿勢です。デスクトップルートは低レベルの自動化ツールというより、権限境界つきの委任 UI です。
多くの非開発系タスクでは、そのほうが正しい選択です。Downloads フォルダの整理、ノートからの報告書ドラフト作成、領収書のスクリーンショットを表に変換する作業、定期サマリーの作成などは、API computer use より Cowork に近い仕事です。コーディング周辺の仕事でも、問うべきなのは「エージェント runtime が必要なのか、それとも自分のマシンで Claude に仕事をさせたいだけなのか」です。後者なら Cowork または Claude Code が自然な入口です。
もし今の関心がプランやアクセス条件なら、Claude Code 料金ガイド を併読すると整理しやすいはずです。また、広い意味での computer use ではなく、コード作業での安全な長時間自律性が知りたいなら、Claude Code Auto mode の解説 のほうが直接役に立つことも多いです。
各ルートの最短スタート
エコシステム全体を理解しきってから試すのではなく、まず最短で始めたいなら次の流れです。
API ルートでは、Anthropic の reference implementation から入るのが安全です。素の「クリック実行機」を自作するところから始めるべきではありません。現行の beta ヘッダーを設定し、専用 VM またはコンテナ上で環境を立ち上げ、computer tool とユーザープロンプトを Claude に渡し、返ってきたアクションを実行して tool_result を返す。この繰り返しが本体です。重要なのは最初の API 呼び出しそのものではなく、その外側にある隔離境界です。
デスクトップルートでは、Claude Desktop を開き、Cowork に切り替え、Claude に触らせる作業フォルダやファイルを選び、欲しい成果物を伝え、Claude が出した計画を確認してから実行に進みます。実行中はデスクトップアプリを開いたままにしておく必要があります。途中でスマホから補足したい場合は、Anthropic が案内しているモバイル継続の流れを使えますが、実行そのものはデスクトップ側にひもづいたままです。
どのルートを選ぶべきか
エージェント機能を自分の製品に組み込みたいなら API。
自分のマシン上の仕事を Claude に委ねたいなら Cowork または Claude Code。もう少し具体的にはこうです。
| 必要なもの | 選ぶべきもの | 理由 |
|---|---|---|
| 自分のアプリや workflow にエージェントを入れたい | Anthropic API computer use | VM、tool loop、ネットワーク境界、承認ルールを自分で制御できる |
| ローカルファイルやデスクトップ作業を Claude に進めてほしい | Cowork または Claude Code | Anthropic のデスクトップ製品がセッションを回し、あなたは権限境界を管理する |
| ウェブ調査、ダッシュボード閲覧、フォーム操作 | ブラウザ経路を画面操作より優先 | より狭い権限で済み、監査もしやすい |
| Slack、GitHub、Drive など既存サービスとの作業 | まずコネクタ、その次にブラウザや画面 | UI をなぞるより統合のほうが自然で安全 |
| 機密アカウント、支払い、同意、破壊的操作 | 人間主導のフロー | Anthropic も重大な操作では人間の確認を要求している |
いちばん役に立つ整理はこれです。API ルートはツールを作る人のためのもの、デスクトップルートは仕事を委ねる人のためのもの。 重要なのは機能を大きく見せることではなく、実行環境の所有者を先に分けることです。そこを分けないと、リスクも設定コストも承認フローもユースケースも正しく判断できません。
プライバシーと保持の話は surface ごとに見るべき
ここは特に雑に書かれやすい箇所です。Anthropic の現行公開資料は、computer use の全表面を一文で完全に説明するような単一の保持説明を出していません。
API 側の computer use docs では、この機能は client-side tool であり、ZDR 契約がある組織ではレスポンス後に保持しない形で扱えると説明されています。ところが commercial products 向けの privacy article では、スクリーンショットは別条件がない限り backend から 30 日以内に自動削除されると書かれています。一方で Cowork の製品ページでは、タスク履歴は基本的にローカル保存だと強調されています。
ここから導くべき結論は「Anthropic の説明が矛盾している」ではありません。そうではなく、computer use がすでに複数の surface にまたがっているということです。開発者なら retention を実装契約の一部として扱い、自分の契約やモードに合った文書を読むべきです。デスクトップユーザーなら、ローカル履歴、権限、製品境界の話として捉えるべきです。やってはいけないのは、ある surface の一文を別の surface にそのまま当てはめて「これが universal rule だ」と言うことです。
いつ computer control を使うべきではないか

Anthropic の現在の製品表現から導ける実務ルールはシンプルです。問題を解決できる最小のコントロール面を使うこと。 コネクタで取れるならコネクタ。ローカルファイルだけで済むならファイル。ウェブ調査やフォーム操作なら Chrome。直接統合もより狭いブラウザ経路もないときにだけ、画面全体の操作へ進む。この順番を守るだけで、不要なリスクと不安定さをかなり減らせます。
これは安全性だけでなく、信頼性の話でもあります。コネクタやファイルアクセスは範囲を限定しやすく、監査しやすく、UI 変更で壊れにくい。ブラウザ操作は API より脆いですが、全面的なデスクトップ制御よりはまだ狭い。画面操作は最も強力で、最も推論しにくい層です。だからこそ最後の段であるべきで、出発点ではありません。
また、「Claude ができる」ことと「Claude にやらせるべき」ことは別です。Anthropic は現行 docs で、意味のある結果をもたらす操作には人間の確認を要求しています。これは正しい基準です。Cookie 同意、支払い、契約承諾、破壊的な削除、機密アカウントへのアクセス、完璧な精度が求められる操作は、人間の主導を残すべきです。デモが成功したからといって、本番の責任まで委ねられるとは限りません。
同じことは、もっと良い機械向けインターフェースがあるタスクにも当てはまります。すでに API、CSV エクスポート、SQL、Webhook があるのに、あえて画面を読ませてクリックさせるなら、それは computer use の価値を引き出しているのではなく、最も壊れやすい層を選んでいるだけです。computer use が本当に有効なのは、ソフトウェアが依然として「人間向けの形」でしか存在しない場所です。
FAQ
Claude Computer Use は Anthropic API ツールだけを指しますか?
いいえ。開発者にとっては API ツールが最重要の意味ですが、Anthropic の現在の Cowork と Code のページも同じ系統の能力をデスクトップ作業フローの一部として扱っています。つまり、いまのこの語は一つの surface だけを指していません。
ツールループは自分で実装する必要がありますか?
API ルートでは必要です。Anthropic の現在の docs は、tool call の抽出、VM またはコンテナ内での実行、tool_result の返却をあなたのアプリが行う前提で書かれています。デスクトップルートでは、Anthropic の製品がこのオーケストレーションを担います。
Cowork は Web で動きますか? スマホだけで実行できますか?
いいえ。現行のヘルプページでは、Cowork は Claude Desktop を必要とし、macOS または Windows 上で動き、Web やモバイル単体の実行面ではないとされています。スマホからメッセージを送ることはできますが、実行自体はデスクトップアプリに結びついたままです。
Cowork が使えるなら、完全な computer use も同じ条件で使えると考えていいですか?
そうは考えないほうが安全です。ヘルプページは Cowork を広く説明していますが、製品ページのより明示的な computer-use 表現は現時点で Available on macOS です。より具体的なほうの表現を信頼するのが無難です。
API ルートのコストは高いですか?
通常のテキスト利用より高くつきます。理由は単にモデルが強いからではなく、ツールとスクリーンショットのオーバーヘッドがあるからです。Anthropic は現時点で、466-499 の beta system prompt tokens、Claude 4.x における 735 のツール定義トークン、さらにスクリーンショットと tool result の追加コストを明記しています。だからこそ、このルートは本当に UI 自動化が必要な場面に絞るべきです。
Anthropic はスクリーンショットを保存しますか?
この質問は surface ごとに答える必要があります。API docs は ZDR 契約下の扱いを説明しています。commercial products 向けの privacy article は 30 日以内の削除を説明しています。Cowork はローカル履歴を強調しています。自分のケースで重要なら、実際に使う surface と契約の文脈で確認するべきです。
役に立つ問いは「Claude はクリックできるか」ではない
Claude はクリックできます。そこ自体は、もう驚くポイントではありません。
役に立つ問いは、あなたがどんなシステムを作ろうとしているのか、どこまでの制御権を Claude に渡したいのかです。製品を作るなら、API ツールを本物の自動化 runtime として扱い、実際のサンドボックスと承認境界の中に置くべきです。自分のマシン上で Claude に仕事をしてほしいなら、Cowork や Claude Code を使い、Anthropic のデスクトップ製品にセッション管理を任せつつ、フォルダ、コネクタ、重要な承認は自分で管理するべきです。
そう捉え直せば、Claude Computer Use は曖昧な魔法の約束ではなく、具体的なルーティング判断になります。そして、その判断をどれだけ正確にできるかが、実用的な自動化と壊れやすいデモの分岐点になります。
