Claude Computer Use（日本語では「コンピュータ使用」とも表記されます）は、Claudeにスクリーンショットを見せて、マウスとキーボードで画面を操作させるためのAPIツールです。2024年10月のベータ公開から仕様は三度更新されており、当時の記事どおりにcomputer_20241022を指定しても、対応していたClaude 3.5 Sonnetがすでに提供終了しているため動きません。さらに2026年8月19日のリリースノートで、ベータヘッダーの要らないクライアントツールセット版computer_toolset_20260801がベータを抜けたと告知され、ツール定義の書き方そのものが入れ替わりました。ここでは2026年9月時点の公式ドキュメントを基に、現行のツール版と対応モデル、最小構成のリクエスト、旧版からの移行手順、実装で最も詰まる座標のずれ、トークン単位の料金内訳、そして安全に運用するための線引きまでを整理します。
まとめ：Claude Computer Useの要点
- Computer Useは画面の「スクリーンショット取得・マウス操作・キーボード入力」をClaudeに委ねるツールで、実行するのはアプリ側。Claudeが直接PCを触るわけではない。
- 現行は
computer_toolset_20260801というクライアントツールセットで、ベータヘッダーが不要。screenshotやleft_clickなど17個のメンバーツールが1エントリで有効になる。 - ツール定義のパラメータが総入れ替えになった。
name・display_width_px・display_height_px・display_number・enable_zoomはいずれも拒否される。指定できるのはtype・configs・cache_control・allowed_callersの4つ。 - Claudeは1ターンに複数のアクションをまとめて返す（バッチアクション）。順番に実行し、最初の失敗で止め、残りには決められた停止テキストを返す。
- 画像の自動縮小がなくなった。上限を超えたスクリーンショットはバリデーションエラーで拒否されるため、縮小と座標の戻しをアプリ側で必ず書く。
- ツールセット定義だけで入力約4,500トークンが固定で乗り、さらに1手ごとに画像トークンが加算される。1920×1080のスクリーンショット1枚が高解像度ティアで2,691トークン。
- Webページ内で完結する操作なら、デスクトップを前提にしないBrowser Use toolのほうが噛み合う。
- Webページや画像に仕込まれた指示にClaudeが従うことがあるため、人の確認を挟まない完全自動運用には向かない。
対応モデルの対応表から、実装で詰まりやすい座標のずれ、そして採用可否の判断まで順に見ていきます。旧computer_20251124で組んだ実装をお持ちなら、移行の章から読んでも困りません。
Computer Useが担う操作範囲とブラウザ拡張・Browser Useとの違い
画面認識・マウス・キーボードに限定された操作の提供範囲と実行側の役割
Computer Useが提供する機能は、現在の画面を撮るスクリーンショット取得、座標を指定するマウス操作、文字列とショートカットを送るキーボード入力の3系統に限られます。ファイルを読む、コマンドを打つといった操作は別のツール（text editorツール、bashツール）が担当し、実務ではこれらを併用して一連の作業を組み立てます。
Claudeはこれらを自分で実行しません。「座標(500, 300)を左クリックせよ」というtool_useブロックを返すだけで、実際にクリックを発生させ、結果のスクリーンショットを撮って返すのはアプリケーション側の責務です。裏を返せばOSは問いません。公式のリファレンス実装はDockerとXvfbを使ったLinux環境ですが、Windowsでもmacでも、スクリーンショットと入力さえ実装できれば動きます。画面認識から操作までの内部処理はスクリーンショット解析でPCを操作するComputer Useの動作原理で詳しく扱っています。
ツールセット版になって、この「Claudeは指示を返すだけ」という性質はいっそう明確になりました。公式ドキュメントはComputer Useをクライアントツールセットと呼び、17個のメンバーツールをアプリ側が自分の環境で実行する構図だと説明しています。Anthropic側では何も動きません。スクリーンショットも入力も、すべて自社の管理下に残ります。
Claude for Chrome・Claude Desktopとの使い分けの判断軸
「Claudeに画面を操作させる」手段はAPIだけではありません。ブラウザ内の操作に限ってよいなら、拡張機能のClaude for Chromeのほうが実装コストはゼロです。公式サイトの表記は「Available in beta on all paid plans.」で、全有料プランがベータとして対象になります。導入手順や対応ブラウザはClaude in Chromeとは？使い方・料金・対応プランとできることをわかりやすく解説【2026年】にまとめました。
判断の軸ははっきりしています。操作対象がWebサイトだけならClaude for Chrome、デスクトップアプリを含むならAPIのComputer Use、手元のファイルとMCP連携が主眼ならClaude Desktopとは？できること・料金・インストール・MCP連携を解説【2026年】のデスクトップ版、外出先から自宅のPCを動かしたいならClaude Dispatchとは｜Remote Controlとの違いと使い方・Windows対応です。仮想環境を用意してエージェントループを書くコストは小さくないので、既製の仕組みで足りないかを先に確認してください。
Webで完結する自動化はBrowser Use toolという選択肢
ツールセット版が出たのと同じ2026年8月19日には、Computer Useと同じクライアントツールセットの形でBrowser Use tool（browser_toolset_20260801）が加わりました。既定で27個のメンバーツールを持ち、navigateやread_pageのようにページの構造そのもの（アクセシビリティツリー、要素、フォーム、タブ）を読んで操作します。座標とスクリーンショットだけで戦うComputer Useとは前提が違い、デスクトップ環境を用意する必要もありません。
使い分けは、公式ドキュメントの言い方を借りれば「タスクがWebページの内側で完結するかどうか」です。ログインして申請フォームを埋める、管理画面から一覧をエクスポートする、といった仕事ならBrowser Use tool。Excelやレガシーな業務クライアントを含むならComputer Use。両方を同じリクエストに宣言することもでき、その場合はtoolset_nameで呼び分けられます。なお、Browser Use toolはClaude APIとGoogle Cloudのみの提供で、AWSやMicrosoft Foundryでは使えません。API版との性格の違いはcomputer‑use機能の動作原理とAPI版にはないGUI操作自動化の強みでも整理しています。
2026年9月時点のツール版と対応モデル・対応プラットフォーム
ここが旧記事から最も大きく変わった箇所です。従来はどのツール版を使うにもanthropic-betaヘッダーが必須でしたが、現行のcomputer_toolset_20260801はヘッダーなしで通ります。旧版も引き続き動くため、既存の実装が急に壊れることはありません。
| ツール版 | ベータヘッダー | 使える主なモデル | 主なプラットフォーム |
|---|---|---|---|
| computer_toolset_20260801 | 不要 | Opus 5・Sonnet 5・Opus 4.8 | Claude API・Google Cloud |
| computer_20251124 | computer-use-2025-11-24 | Opus 4.7・4.6・Sonnet 4.6 | AWS・Bedrock・Foundry |
| computer_20250124 | computer-use-2025-01-24 | Sonnet 4.5・Haiku 4.5 | ベータのみの旧世代 |
ツールセット版に対応するモデルは、公式の互換性欄にclaude-fable-5-1・claude-mythos-5-1・claude-fable-5・claude-mythos-5・claude-opus-5・claude-sonnet-5・claude-opus-4-8が列挙されています。逆に、Claude Opus 4.7・Opus 4.6・Sonnet 4.6・Opus 4.5の4モデルは旧computer_20251124経由でしかComputer Useを使えません。世代の新しいモデルを使いながら旧ツール版のコードを回している、という状態が起こりうるので、モデルとツール版の組み合わせは必ず突き合わせてください。
プラットフォームの差も無視できません。ツールセット版が使えるのはClaude APIとGoogle Cloudで、Claude Platform on AWS・Amazon Bedrock・Microsoft Foundryはベータ扱いの旧ツール版のみです。マルチクラウドで同じコードを回す設計なら、この非対称が制約になります。2024年10月の公開当初に使われていたcomputer-use-2024-10-22とcomputer_20241022は一覧から完全に消えており、日本語の解説記事はこの初版のまま更新されていないものが多いので、コードをコピーする前にヘッダーの日付を確認してください。
アクションの数もツール版で変わります。ツールセット版のメンバーは17個で、screenshot・zoom・left_click・right_click・middle_click・double_click・triple_click・left_click_drag・mouse_move・left_mouse_down・left_mouse_up・cursor_position・scroll・type・key・hold_key・waitが揃います。カーソル位置を問い合わせるcursor_positionはツールセット版で加わったメンバーです。keyには1〜100のrepeatが付き、Tabを4回押すといった操作を1ブロックで表現できます。hold_keyとwaitのdurationは最大300秒です。
ツールセット版の最小構成リクエストとエージェントループの実装手順
ツールセット版のツール定義に指定できる4つのパラメータと設定の制約
ツールセット版のエントリが受け付けるのはtype・configs・cache_control・allowed_callersの4つです。旧版で必須だったdisplay_width_pxとdisplay_height_pxは書けません。座標は常に「アプリが返したスクリーンショットのピクセル空間」で表現される、という前提に一本化されたためです。
curl https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "claude-opus-5",
"max_tokens": 1024,
"tools": [
{ "type": "computer_toolset_20260801" },
{ "type": "text_editor_20250728", "name": "str_replace_based_edit_tool" },
{ "type": "bash_20250124", "name": "bash" }
],
"messages": [
{"role": "user", "content": "画面を確認して、請求書の一覧ページを開いて"}
]
}'ベータヘッダーは1行も要りません。SDKでもベータ名前空間ではなく通常のMessages APIクライアントを使います。メンバーを絞りたいときはconfigsを使います。17メンバーはzoomを含めてすべて既定で有効なので、ズーム画像を返せない環境では明示的に切っておくほうが安全です。
{
"type": "computer_toolset_20260801",
"configs": {
"zoom": { "enabled": false }
},
"cache_control": { "type": "ephemeral" }
}このツールを要求すると、Computer Use専用のシステムプロンプトがAPI側で自動生成され、「sandboxed computing environment（サンドボックス化された計算環境）へのアクセスがある」旨がClaudeに伝えられます。利用者が指定したsystemパラメータは無効化されず、この自動生成分と結合されます。
tool_use→実行→tool_result を回すエージェントループの骨格
Computer Useは1往復では完結しません。Claudeがtool_useを返す→アプリ側が操作を実行してスクリーンショットを撮る→tool_resultとして返す、という往復を、Claudeがツールを要求しなくなるまで繰り返します。これがエージェントループです。ツールセット版では、ブロックのnameがメンバー名そのもの（left_clickなど）になり、inputからactionフィールドが消え、代わりにtoolset_nameが付きます。
import anthropic
client = anthropic.Anthropic()
MAX_STEPS = 30 # 暴走時のコスト上限
for _ in range(MAX_STEPS):
res = client.messages.create(
model="claude-opus-5",
max_tokens=4096,
tools=[{"type": "computer_toolset_20260801"}],
messages=messages,
)
messages.append({"role": "assistant", "content": res.content})
if res.stop_reason != "tool_use":
break
results, halted = [], False
for block in res.content: # 1ターンに複数ブロックが来る
if block.type != "tool_use":
continue
if getattr(block, "toolset_name", None) != "computer":
continue
if halted: # 先行アクションが落ちたら以降は実行しない
results.append({
"type": "tool_result",
"tool_use_id": block.id,
"toolset_name": "computer",
"is_error": True,
"content": "Not executed: an earlier computer action in this turn failed.",
})
continue
ok, payload = run_action(block.name, block.input) # 実行は自前
halted = not ok
results.append({
"type": "tool_result",
"tool_use_id": block.id,
"toolset_name": "computer",
"is_error": not ok,
"content": payload,
})
messages.append({"role": "user", "content": results})上のコードでMAX_STEPSを置いているのは、想定外の画面に迷い込んだClaudeが延々とスクリーンショットを撮り続けると、そのぶんAPIコストが積み上がるからです。無限ループのまま本番に出さないでください。ディスパッチはtoolset_nameとnameの組で行うのが公式の指示です。同じリクエストの中でカスタムツールがメンバーと同名を持つことがあり、将来のツールセット版がメンバーを増やす余地もあるためです。
バッチアクションの実行順序と失敗時に返すtool_result
ツールセット版で挙動が最も変わったのがここです。Claudeは「クリックして、文字を打って、スクリーンショットを撮る」といった短い手順をまとめて1レスポンスで返してきます。これがバッチアクションで、並列ツール使用と同じレスポンス形をとりながら、並行ではなく順番に実行する点だけが違います。
ルールは3つです。第一に、contentに並んだ順序どおりに実行する。後続のアクションは先行の結果に依存しており、例のtypeは直前のクリックでフォーカスが当たった場所に文字を入れるからです。第二に、ひとつ失敗したら残りは実行しない。失敗したブロックにはis_error: trueと原因の説明を返し、それ以降のブロックには次の停止テキストをそのまま返します。
{
"type": "tool_result",
"tool_use_id": "toolu_01Xf5W1sD8Q9aBcJ7kLmN2pQ",
"toolset_name": "computer",
"is_error": true,
"content": "Not executed: an earlier computer action in this turn failed."
}第三に、すべてのtool_useブロックにtool_resultを返す。ひとつでも未応答のブロックが残ったリクエストはinvalid_request_errorで弾かれます。旧版のコードは「レスポンスの最初のブロックだけ読む」書き方が多く、その実装をそのまま持ち込むことが、次の呼び出しでエラーになる原因です。画像を返す必要があるのはscreenshotとzoomだけで、ほかのメンバーにはOK程度の短いテキストで足ります。cursor_positionだけは座標をテキストで返します。
運用上の注意もひとつ。人の承認を挟む設計にしているなら、その確認はブロック単位で、実行の直前に行ってください。バッチは1ターンで複数手を進めてしまうため、ターン単位の承認では「気づいたら送信ボタンまで押されていた」という事故が起こります。どうしても1手ずつにしたい場合は、tool_choiceにdisable_parallel_tool_useを立てると、Claudeが1ターンに返すメンバーのブロックは最大1つになります。
旧computer_20251124からツールセット版へ移行する9つの変更点
公式は移行を任意としており、旧ツール版はベータヘッダー付きで動き続けます。とはいえ、対応モデルが広いのも、今後メンバーが増えるのもツールセット版の側です。移行するなら次の9点をまとめて直します。
- ベータヘッダーを外す：
anthropic-beta: computer-use-2025-11-24を削除し、SDKではbetasを消して通常のクライアントに戻します。 - tools のエントリを差し替える：
typeをcomputer_toolset_20260801にし、name・display_width_px・display_height_px・display_number・enable_zoomを消します。残すとリクエストごと弾かれます。 - zoomの既定が反転している：旧版の
enable_zoomは既定false、ツールセット版のzoomは既定で有効です。実装していない環境ではconfigsで明示的に切ります。 - 全ブロックを処理する：最初の1件だけ読む実装をやめ、
input.actionではなくnameとtoolset_nameでディスパッチします。 - 順番に実行し、停止テキストを返す：前章のルールです。
- 結果に toolset_name を付ける：メンバー呼び出しに答える
tool_resultには必ず"toolset_name": "computer"を入れます。中身に置けるのはテキストと画像だけです。 - keyのrepeatに対応する：未知のフィールドを無視する実装だと1回しか押されません。
- 画像は自分で縮小する：上限超過は縮小ではなく拒否になります（次章）。
- 使えないオプションを片付ける：
defer_loadingはエントリ直下ではなくconfigsの中へ移します。
tool_useブロックの形も変わります。旧版はnameがcomputer固定でinputに{"action": "left_click", "coordinate": [500, 300]}が入っていましたが、ツールセット版ではnameがleft_clickになり、toolset_nameがcomputer、inputは{"coordinate": [500, 300]}だけになります。ハンドラの分岐条件をそのまま移植すると、どのアクションにも一致せず無反応になるので注意してください。なお、同じリクエストにcomputer_20251124のエントリとcomputerという名前のツールを同居させることはできません。
クリック座標がずれる原因と、画像サイズ上限に合わせる縮小の実装
クリック座標のずれを抑えるモデル別の画像サイズ上限と推奨解像度の選定基準
Claudeは「自分が見た画像」の座標系で位置を返します。したがって、送る画像とアプリ側の実画面がずれていれば、返ってくる座標もずれます。まずモデルごとの上限を把握してください。
| 解像度ティア | 対象モデル | 長辺上限 | 視覚トークン上限 |
|---|---|---|---|
| 高解像度 | Opus 4.7以降の全モデル | 2576px | 4784（約3.75メガ） |
| 標準 | Opus 4.6・Sonnet 4.6以前 | 1568px | 約115万ピクセル |
ここが旧版から変わった最大の落とし穴です。従来は上限を超えた画像もエラーにならず、API側で自動的に縮小されてからClaudeに渡されていました。ツールセット版は縮小しません。上限を超えたtool_resultの画像はバリデーションエラーで拒否されます。旧実装を移植して「4Kのまま送っていたが動いていた」ケースは、移行した瞬間にエラーで止まります。逆に言えば、黙って縮小されて座標だけがずれるという厄介な失敗はなくなりました。
視覚トークンは⌈幅÷28⌉×⌈高さ÷28⌉で決まります。高解像度ティアでは長辺2576px・4784トークン（約3.75メガピクセル）、それ以前のモデルでは長辺1568px・約115万ピクセルが上限です。縮小と座標の戻しは次のように書きます。
import math
MAX_LONG_EDGE = 2576 # Opus 4.7以降の高解像度ティア
MAX_VISUAL_TOKENS = 4784 # 28px角のパッチ数の上限
def scale_factor(width, height):
edge_scale = MAX_LONG_EDGE / max(width, height)
patches = math.ceil(width / 28) * math.ceil(height / 28)
token_scale = math.sqrt(MAX_VISUAL_TOKENS / patches)
return min(1.0, edge_scale, token_scale)
scale = scale_factor(2560, 1440)
shot = capture_and_resize(int(2560 * scale), int(1440 * scale))
def to_screen(x, y): # Claudeが返した座標を実画面へ戻す
return x / scale, y / scale解像度そのものは、一般的なデスクトップ操作なら1024×768または1280×720、Webアプリの操作なら1280×800または1366×768が公式の推奨で、1920×1080超は性能面の問題が出るため避けるよう明記されています。画面を広くすれば見える情報は増えますが、縮小で細部が失われてクリック精度は落ちます。
クリック座標のずれに出る典型パターンと画像の縮小・表示倍率の切り分け方
- 一定方向にずれ続ける：スクリーンショットのピクセル空間と実画面のサイズが違うのに、スケールを掛けずにクリックしています。撮影後にリサイズしたなら、その縮小率で座標を戻します。
- macOSで座標が2倍になる：Retinaディスプレイはdevice pixel ratio 2でスクリーンショットを撮るため、画像が論理座標の2倍の解像度になります。送信前に1/2へ縮小するか、返ってきた座標を半分にしてからクリックします。
- だいたい合うが小さな要素を外す：対象が小さいか、4K以上の画面を縮小した際に細部が潰れています。
zoomメンバーを有効なまま実装しておく、低いDPIで撮る、対象領域だけを切り出す、といった対処になります。リサイズでアスペクト比が崩れると、縦と横で誤差の出方が変わるため原因の切り分けも難しくなります。 - まったく別の要素を押す：指示があいまいか、見た目の似た要素が近くにあります。「右下の青いSubmitボタン」のように位置で指すか、手順を細かく割ります。
- 全体に精度が低い：解像度が低すぎます。1280×720を基準にして測り直してください。
公式にはモデルによるクリック精度の差も記載されています。旧computer_20251124を使うモデル群のうち、Sonnet 4.6はOpus 4.6より機械的なクリック精度が高く、強い縮小が必要な場面でも安定したクリックが可能です。Opus 4.7はその差をほぼ埋め、解像度上限が高いぶん縮小自体が少なくて済みます。精度が出ないときは、プロンプトを練り直す前にモデルと解像度を疑ってください。
zoomメンバーで小さな文字やUI要素を原寸のまま読み取る方法
zoomは、画面の一部を原寸で見直すメンバーツールです。regionパラメータに[x0, y0, x1, y1]の形で左上と右下の座標を渡すと、その領域だけをフル解像度で撮り、アスペクト比を保ったまま通常のスクリーンショット寸法に収めて返します。旧版のenable_zoomと違って既定で有効なので、環境がズーム画像を作れないならconfigsで外しておきます。外さずにエラーを返し続けるより、最初から渡さないほうが素直です。
注意したいのは座標系です。ズームしたあともClaudeは全画面スクリーンショットの座標空間で位置を答えます。ズーム画像の中の相対座標ではありません。ここを取り違えて「ズームすると急にクリックが外れる」と悩む実装は少なくないはずです。
効くのは、標準のスクリーンショット解像度では判読できない要素です。サイドバーのファイル名、タブのタイトル、ステータスバーの文字、行番号、ボタンのラベルなどがこれにあたります。逆に、期待した場面でClaudeがズームしないときは、指示の粒度が粗いことが多い。「画面に何が表示されているか」ではなく「左側のファイル一覧にあるファイル名を読んで」のように、領域か要素を名指しすると使うようになります。
ツールセット定義の追加トークンと操作ごとの画像トークンの料金内訳
まず前提として、Computer UseはAPIの従量課金です。ProやMaxといったサブスクリプションに含まれる機能ではありません。プラン契約の範囲でClaudeに画面を触らせたいなら、対象はブラウザ拡張のClaude for Chrome側になります。API側には機能単体の追加料金がなく、標準のツール利用料金に従いますが、通常のテキスト往復にはないトークンが次のように乗ります。
- ツールセット定義：
computer_toolset_20260801を既定のメンバー構成で宣言すると、入力に約4,500トークンが加算されます。内訳は17メンバーのツール定義とツール使用のシステムプロンプトです。公式表記はOpus 5・Opus 4.8・Fable 5・Mythos 5で約4,520、Sonnet 5で約4,590。旧版の「ツール定義735トークン＋システムプロンプト466〜499トークン」から6倍近くに増えています。 - zoomを切ると約410トークン減る：
configsでzoomを無効化した場合の差分です。使わないなら切る理由がここにもあります。 - スクリーンショットの画像トークン：1手ごとに画像を送るため、往復回数がそのまま入力トークンに跳ね返ります。公式の目安は1枚あたり1,000〜1,800トークン。
- ツール実行結果：Claudeへ返す
tool_resultの中身も入力トークンとして計上されます。 - 併用ツールのコスト：bashツールやtext editorツールを一緒に定義した場合、それぞれのトークンコストが別途かかります。
定義が4,500トークンに膨らんだぶん、cache_controlの効き目は旧版より大きくなりました。ツールセット定義にキャッシュのブレークポイントを置けば、2回目以降の読み出しは基本入力価格の10%（Fable 5.1とMythos 5.1は2.5%）で済みます。長いループを回すなら、ここは最初に打っておく手です。
実務でもっと効くのは画像トークンです。Claudeは画像を28×28ピクセルのパッチ単位で見るため、消費量は「⌈幅÷28⌉×⌈高さ÷28⌉」で決まります。公式の実測表では、1000×1000が1,296トークン、1920×1080は標準ティアで1,560トークン（1456×819へ縮小）、高解像度ティアでは縮小されないため2,691トークン、3840×2160は高解像度ティアで4,784トークンです。高解像度モデルは同じ画像で最大3倍近い視覚トークンを消費します。
| モデル | 入力（100万トークン） | 出力（100万トークン） |
|---|---|---|
| Claude Fable 5.1 | 10ドル | 50ドル |
| Claude Opus 5 | 5ドル | 25ドル |
| Claude Sonnet 5 | 2ドル | 10ドル |
| Claude Haiku 4.5 | 1ドル | 5ドル |
Sonnet 5の2ドル・10ドルは、当初「2026年8月31日までの導入価格」とされていた水準です。公式の料金ページには2026年9月1日に予定されていた3ドル・15ドルへの引き上げを行わない旨が明記され、この価格が標準になりました。「9月から値上がりする」という前提で試算していた見積もりは、そのまま据え置きで組み直せます。
金額に直すと輪郭がはっきりします。公式の試算では、Opus 5に1000×1000の画像を投げると1,000枚あたり約6.48ドル、4K画像なら約23.92ドルになります。1タスクに20手かかる処理を1日1,000件回すなら、画像だけで日次100ドル規模の入力トークンが発生する計算です。価格は改定されるため、見積もりの際は公式の料金ページで最新値を確認してください。
もうひとつのレバーがeffortです。ただし公式が具体的な推奨値を示しているのは旧computer_20251124を使うモデルに限られます。Opus 4.7はhighを既定とし、スループット重視やコスト重視ならlow。Sonnet 4.6とOpus 4.6はmediumが精度対コスト比で最良で、maxはUIタスクの精度を上げないままトークンだけ増えるため避けるべきとされています。この2モデルではlowが思考を無効化した場合より出力トークンが少なくなるという指摘もあります。ミスが減れば再試行も減るからです。安くしたいからと思考を切るのは、この用途では逆効果になり得ます。ツールセット版に対応するOpus 5・Sonnet 5・Opus 4.8については記載がないので、自分のタスクでmediumから順に振って測るところから始めてください。
スクリーンショット履歴とプロンプトキャッシュを両立させる設計
長いループでは画像が溜まります。1リクエストの画像が20枚を超えると、そのリクエスト内のすべての画像に厳しい辺長制限が掛かる、というAPIのリクエスト制限があるためです。履歴を全部持ったまま回すループは数十ターンでこの数に届きます。対処は二択で、各スクリーンショットをどちらの辺も2000px以下に縮めるか、古い画像を間引いて20枚以下に保つかです。
間引くときに効くのが、プロンプトキャッシュとの両立です。公式は次の3点を挙げています。第一に、システムプロンプトとツール定義の直後にcache_controlのブレークポイントを1つ置き、直近ターンの最後のtool_resultに最大3つを順送りする。バッチの中で複数ブロックにマーカーを付けても1つのブレークポイントとして働きますが、上限4つの勘定には別々に数えられます。第二に、間引きは毎ターンではなくまとめて行う。1ターンごとに1枚落とすとプレフィックスが毎回変わり、キャッシュが効かなくなります。直近3枚を残して25ターンごとに間引く、といった運用が現実的です。
第三に、Fable 5.1ではクライアント側の間引きを避けます。古いスクリーンショットを取り除くと、そのターン以降の思考ブロックが無効になるためです。辺を2000px以下に抑えたうえで、サーバー側のtool result clearingで古い結果を落とす形が推奨されています。どうしても間引くなら、以降ずっとprefix_mismatch_behaviorをdrop_blockにしておきます。
画面操作エージェントのプロンプトインジェクション対策と権限設計の線引き
Computer Useは通常のAPI機能とは質の違うリスクを持ちます。Claudeは、Webページや画像の中に書かれた指示を、利用者の指示と衝突していても実行してしまうことがあるためです。インターネットに接続した環境ではこのリスクが高まります。
Anthropic側の対策として、モデルはインジェクション耐性の訓練を受けており、加えてComputer Useツールを使うと分類器が自動で走ります。スクリーンショットの中に疑わしい指示を検知すると、次の操作へ進む前に利用者へ確認を求めるようモデルを誘導する仕組みです。この防御層は無人運用には噛み合わないため、サポート経由でのオプトアウトも用意されています。
そのうえで、実装側が守るべき線引きは公式に明示されています。権限を絞った専用の仮想マシンかコンテナで動かすこと。ログイン情報のような機微データをモデルに渡さないこと。アクセス先を許可ドメインのリストに限定すること。そして、Cookieへの同意、決済、利用規約への同意など、現実に影響が及ぶ操作と明示的な合意が要る操作は人が確認すること。分類器が入ったあとも、これらの前提は変わりません。エンドユーザー向けの製品に組み込むなら、リスクを説明したうえで同意を得ることも求められます。
バッチアクションが入ったことで、この「人が確認する」の実装難度は一段上がりました。1レスポンスに3手が入っていれば、承認の単位も各ブロックに合わせて分ける設計が必要です。ログイン認証情報をどうしても渡すなら、公式が示すとおり<robot_credentials>のようなXMLタグで囲って範囲を明示し、そのうえで許可ドメインを絞ります。社内の業務システムに画面操作エージェントを入れる構想があるなら、この権限設計と監査ログの置き場所を先に決めておくと、後戻りが減ります。要件整理から実装まで外に出すなら、AIエージェント開発のように、ツール実行と権限設計まで含めて引き受ける受託先を選んでください。
Computer Useを採用すべきでない場面と、置き換えられる代替
画面を操作できるという性質上、Computer Useは何にでも使えそうに見えます。しかし次の条件に当てはまるなら、別の手段のほうが確実です。
APIやMCPで同じことができる場合は使わない。これが最大の判断基準です。スクリーンショットを介する操作は、1手ごとに画像トークンと往復のレイテンシを払います。対象システムにAPIがあるなら、そちらを直接叩くほうが速く、安く、壊れにくい。Computer Useの価値は、APIが存在しない業務アプリや、レガシーなGUIしか窓口がない相手に対して発揮されます。
Webページの中で完結するならBrowser Use toolに寄せる。2026年8月19日に加わったこのツールセットは、ページの構造を直接読むぶんスクリーンショット往復より軽く、デスクトップ環境の用意も要りません。Computer Useを選ぶ理由は「デスクトップ全体が要るかどうか」に絞られました。
人の確認を挟まない完全自動運用も避けてください。夜間バッチのように誰も見ていない時間帯に決済や外部送信を伴う操作を任せる構成は、前節の防御層を無効化したうえで走らせるのと変わりません。
ピクセル単位の正確さが求められる操作、たとえば画像編集ソフトでの細かい選択や、数ピクセルしかない要素のクリックも不得手です。座標は縮小と復元を経ており、誤差はゼロにできません。加えて、1日に何万件も回すような高頻度バッチは画像トークンで採算が合いにくい。前節の試算をそのまま自分のワークフローに当てはめ、処理単価を出してから設計に入ってください。公式の制限事項にも、レイテンシ・座標のハルシネーション・スクロールの効きにくさ・表計算ソフトのセル選択の難しさが並んでいます。試す前に、この一覧を自分の業務手順と突き合わせておくと無駄が減ります。
よくある質問
Claude Computer Useとは何ですか？
Claudeにスクリーンショットを見せ、マウスとキーボードでデスクトップやブラウザを操作させるためのAPIツールです。2024年10月にベータ公開され、2026年8月19日からはcomputer_toolset_20260801というクライアントツールセットとして、ベータヘッダーなしで使えるようになりました。screenshotやleft_clickを含む17個のメンバーツールが1エントリで有効になります。操作そのものを実行するのはアプリケーション側で、Claudeは操作の指示を返す役割を担います。
Computer Useの使い方は？何から始めればいいですか？
公式のリファレンス実装であるclaude-quickstartsのcomputer-use-demoから始めるのが最短です。Dockerコンテナ、Xvfbによる仮想ディスプレイ、ウィンドウマネージャ（Mutter）とパネル（Tint2）、Firefox ESRやLibreOfficeなどのアプリ、ツール実装、エージェントループ、確認用のWeb画面が一式そろっています。リポジトリはanthropic-quickstartsから改称されており、旧URLからはリダイレクトされます。自前の環境に移すのは、この動作を確認したあとで構いません。
Claude Computer Useの料金はいくらですか？
APIの従量課金で、サブスクリプションには含まれません。機能単体の追加料金もなく、標準のツール利用料金に従います。コストはトークン量で決まり、computer_toolset_20260801の定義だけで入力約4,500トークン（Opus 5で約4,520、Sonnet 5で約4,590）が固定で乗り、そこへ1手ごとのスクリーンショット画像のトークンが加わります。1920×1080の画像は高解像度ティアで2,691トークンです。モデル単価は100万トークンあたりClaude Opus 5が入力5ドル・出力25ドル、Claude Sonnet 5が入力2ドル・出力10ドル。最新の価格は公式の料金ページで確認してください。
APIから使うには何が必要ですか？
APIキーと、typeにcomputer_toolset_20260801を入れたtoolsエントリ、対応モデル（Opus 5・Sonnet 5・Opus 4.8など）、そしてスクリーンショット取得と入力操作を実行する仮想環境です。ベータヘッダーは要りません。旧computer_20251124やcomputer_20250124を使う場合だけ、対になるベータヘッダーとモデルの組み合わせを守ります。display_width_pxのような旧パラメータをツールセット版に渡すとリクエストごと拒否されます。
Claude CodeでComputer Useは使えますか？
Claude CodeやClaude Agent SDKに組み込まれているのはファイルの読み書き、Bash実行、検索、Web取得といったツールで、画面座標をクリックするcomputerのメンバーは含まれていません。GUI操作を伴う作業は、Messages APIでComputer Useツールセットを自分で宣言するか、Webページ内で完結するならBrowser Use toolかClaude for Chromeを使う切り分けになります。
