Computer Useのクリックが外れる4パターンと診断表

クリックが外れる原因は4パターンに絞り込める

Computer Useのクリックが的を外すとき、見るべき原因は4つの症状に分けられます。診断表は次の通りです。

最初にこの表と実際の症状を突き合わせ、どのパターンに当てはまるかを切り分けてから対策に進みます。関係のない設定を触る手間を省けます。

4つの症状は重なって現れることもあります。1つ直しても改善しない場合は、表の上から順に1行ずつ潰していく進め方があります。

座標のスケーリングが合っていないケース

「一定方向にずれ続ける」症状は、Claudeが返す座標を実画面へそのまま適用していることが典型的な原因です。Claudeの座標は、あなたが返したスクリーンショット画像のピクセル空間で表現されます。実画面とスクリーンショットのサイズが違えば、比率で変換する処理が必須です。

macOS Retinaディスプレイはデバイスピクセル比が2です。画像が論理座標の2倍の解像度になるため、変換を忘れると2倍ずれた場所をクリックします。

もう1つ押さえたい点があります。zoomで切り出した画像を返した後も、Claudeは座標を全画面スクリーンショットの空間で答えます。zoom画像の中の相対位置では答えません。zoom用の補正を別に作ると、かえってずれる原因になります。

計算式の具体的な実装はComputer Useの座標ズレを直すスケーリング計算式にまとめているので、この症状に当てはまる場合はそちらを参照してください。

画像サイズの上限は縮小を自動では助けてくれない

「近くまで来ているのに外す」症状の背景には、画像サイズの扱いがあります。computer_toolset_20260801はディスプレイ寸法を受け取りません。返した画像が上限を超えていても、APIは縮小しません。上限を超えたtool_resultの画像は、検証エラーで拒否されます。

つまり、解像度を上げただけで精度が上がるわけではありません。上限の内側に収まるよう、アプリ側で縮小し、そのスケール係数を保持して座標を戻す必要があります。上限はモデル世代で次のように違います。

ビジュアルトークンは⌈幅÷28⌉×⌈高さ÷28⌉で数えます。履歴にも注意が要ります。1回のリクエストに画像が20枚を超えると、すべての画像にさらに厳しい辺ごとの上限がかかります。ループが履歴を持ち続けると、数十ターンで到達する計算です。各画像の辺を2000px以下に縮めるか、古い画像を落として20枚以下に保ちます。

Fable 5.1・Opus 5.5・Sonnet 5.5では、クライアント側での間引きを避けるよう案内されています。以前のスクリーンショットを消すと、それ以降のthinkingブロックがすべて無効になるためです。この3モデルでは辺を2000px以下へ縮める方法を取り、古い画像はサーバー側のツール結果クリアで落とします。

画面そのものの大きさも関わります。一般的なデスクトップ作業なら1024x768か1280x720、Webアプリなら1280x800か1366x768が目安です。1920x1080を超える解像度は、性能上の問題を避けるため勧められていません。

zoomメンバーツールで小さいターゲットの精度を上げる

小さい対象が判別できないときの中心は、zoomメンバーツールです。4K以上の高解像度ディスプレイをそのまま縮小して返すと、縮小で細部が失われ、小さいアイコンやチェックボックスを見分けにくくなります。

zoomはregionパラメータの矩形だけをフル解像度で切り出し、アスペクト比を保ったまま画像として返します。ファイル名、タブのタイトル、ステータスバーの文字、行番号、ボタンのラベルなど、縮小した全体像では読めない要素の確認に使います。

Claudeがzoomを呼ばないときは、画面全体について聞くのでなく、特定の領域や要素を名指しして尋ねます。

zoomを含む17個のメンバーツールは、すべて既定で有効です。zoom画像を作れない環境では、有効なままエラーを返し続けず、configsで明示的に無効化します。

{
  "type": "computer_toolset_20260801",
  "configs": {
    "zoom": { "enabled": false }
  }
}

低DPIでのキャプチャや、対象領域だけを切り出して渡す工夫も、同じ症状への対処になります。

指示のあいまいさを潰すプロンプト設計

「全く違う要素をクリックする」症状は、座標計算ではなく、指示そのものの精度不足から起きる場合があります。位置を明示する指示(「右下にある青いSubmitボタン」)と、複雑な操作の分割が効きます。

プロンプトの組み立てにも、クリック精度に効く細部があります。

• ユーザーターンのcontent配列では、指示テキストをスクリーンショット画像より前に置きます。対象の説明を先に処理してから画像に進むと、クリック精度が上がります。
• ドロップダウンやスクロールバーのようにマウス操作が苦手なUI要素には、キーボードショートカットを使うよう促します。
• 反復するタスクなら、成功した操作のスクリーンショットとtool_useの例をプロンプトに含めます。
• 結果の確認を促す文を添えます。たとえば「各ステップの後にスクリーンショットを撮り、正しい結果になっているか評価してください。画面が示す内容と成否を1文で述べ、失敗したならやり直してください」です。Claudeが操作結果を確かめずに次へ進む誤りを減らせます。

バッチアクションを毎回スクリーンショットで締めくくらせたいときは、システムプロンプトに書きます。たとえば「アクションのまとまりごとに、結果を確認できるようスクリーンショットで終えてください」です。

ログインが必要なタスクでは、ユーザー名とパスワードを<robot_credentials>のようなXMLタグでプロンプトに含める方法が案内されています。ただし、ログインを要するアプリケーションでのComputer Useは、プロンプトインジェクションによる悪い結果のリスクを高めます。認証情報を渡す前に、ガードレールの強化策を読んでおく必要があります。

モデル側のツール選択が揺らぐ場合もあります。Claudeはアクションの生成時にツール選択を誤ったり、想定外の操作を取ったりすることがあります。ニッチなアプリケーションや、複数のアプリケーションを同時に扱う場面では、信頼性が下がる場合があります。複雑なタスクほど指示を丁寧に書くのはこのためです。1回の指示に複数の意図を詰め込まず、1操作ずつ確認する設計が助けになります。

バッチアクションのどこで外れたかを特定する

クリック精度の問題は、バッチアクションの途中で表面化することがあります。Claudeは「クリック→入力→スクリーンショット」のような複数のアクションを、1つの応答にまとめて返します。ブロックはAPIの並列ツール使用と同じ形で届きますが、並列には実行せず順番に実行します。

toolset_nameが欠けた結果や、tool_useと別のツールセット名を書いた結果は、拒否されます。外れたクリックの調査に入る前に、結果の形が正しいかを見ておくと無駄が減ります。

def log_action(action_type, params, result):
    logging.info(f"Action: {action_type}, Params: {params}, Result: {result}")

すべてのアクションと結果をこの形式で記録しておくと、症状が座標のスケーリングなのか、対象の小ささなのか、指示のあいまいさなのかを、ログの傾向から逆算しやすくなります。特定のUI要素でだけ毎回外れるならターゲットの小ささを、画面全体で一様にずれているならスケーリングを疑います。

実行前のバリデーションも仕込んでおくと、再現条件の特定が早まります。座標がディスプレイの範囲を超えていないかを実行直前に調べ、範囲外なら実行せずエラーとして扱います。スケーリングのバグが、「クリックが的を外す」という曖昧な症状でなく、範囲外エラーという具体的なログとして現れやすくなります。

解像度の下限とモデル選びが精度に効く場面

「精度が全体的に低い」症状は、解像度が低すぎることが原因です。1280x720を基準値として試すのが起点になります。ただし先の画像サイズの上限と、スケーリング計算式の範囲に収める点は変わりません。

モデル選びもクリック精度に影響しますが、精度の比較が明言されている範囲は限られます。旧バージョンのcomputer_20251124ツールを使うモデルのうち、Claude Sonnet 4.6はClaude Opus 4.6より機械的なクリック精度が高めです。スクリーンショットを大きく縮小する場面でも安定します。Claude Opus 4.7ではこの差が縮まり、クリック精度はSonnet 4.6とおおむね同等になりました。解像度の上限が高いぶん、縮小の必要性自体も減っています。

新しいツールセットcomputer_toolset_20260801に対応する9モデルについては、同種の比較がComputer useツールのページに載っていません。ツールの対応関係は次のとおりです。

そのため、Sonnet 4.6からSonnet 5.5へ差し替えるだけでも、APIとGoogle Cloudではツール定義の移行が必要です。クリック精度を優先したい場合は、モデル名だけで判断せず、自分のタスクで実測してから選びます。

座標のハルシネーションを疑うときの確認手段

Claudeが座標を出力するとき、誤った座標を出したりハルシネーション(事実に基づかない出力)を起こしたりすることは、Computer Useの制限事項に明記された既知の挙動です。原因がスケーリングでもプロンプトでもなさそうなときは、推論過程を確認する手段があります。

thinking設定のdisplayを"summarized"にすると、その座標をどう判断したかの要約が返ります。ツールセットに対応するモデルはdisplayが既定で"omitted"(非表示)です。デバッグするときは明示的に"summarized"へ変えます。

"thinking": { "type": "adaptive", "display": "summarized" }

既定はモデルで違います。Opus 4.8・Opus 4.7・Opus 5・Sonnet 5などは"omitted"で、Sonnet 4.6とOpus 4.6は"summarized"です。モデルを差し替えて比べるとき、thinkingの見え方が変わるのはこのためです。

スクロールが効かないときも同じ発想で切り分ける

クリックそのものではありませんが、スクロール操作が効かない症状も似た切り分けが有効です。scrollアクションは方向(上下左右)と量(ホイールのクリック数)を指定できます。アプリケーションによっては、スクロールが効かない場合があります。

そのときはマウスホイールの模倣にこだわらず、Page Downのようなキーボード操作に切り替える方法が案内されています。クリックの診断表と同じで、症状を1つ特定してから対応する打ち手を1つ選ぶと、あちこちの設定を同時にいじるより早く収束します。

まとめ

新しいツールセットへ移るときは、画像の縮小とスケール係数の保持がアプリ側の責任になります。この処理を最初に実装へ入れておくと、クリックが外れたときの切り分けが座標の問題から始められます。

エージェントループ全体の組み方はComputer Useツールを自前実装する最小構成で扱っています。