Computer Useのクリックが外れる4パターンと診断表
Computer Useのクリックが外れる原因を症状別に4パターンへ分解した診断表。zoomの使いどころ、プロンプト設計、モデル選びが精度に効く範囲まで実装目線でまとめます。
クリックが外れる原因は4パターンに絞り込める
Computer Useのクリックが的を外すとき、原因は無数にあるように見えて、実際は4パターンに収束します。診断表は次の通りです。
| 症状 | 原因 | 対策 |
|---|---|---|
| クリックが一定方向にずれ続ける | 原因座標のスケーリング不一致 | 対策スクリーンショットと実画面のサイズ比でスケーリング、Retinaは2倍補正 |
| 近くまで来ているのに対象を外す | 原因対象が極小、4K以上の縮小で情報欠落、アスペクト比の歪み | 対策zoomを有効化、低DPIで撮影、アスペクト比を保持 |
| 全く違う要素をクリックする | 原因指示があいまい、視覚的に似た要素が近くにある | 対策位置を明示する指示、操作を小さいステップへ分割 |
| 精度が全体的に低い | 原因解像度が低すぎる | 対策1280x720を基準値に試す |
最初にこの表と実際の症状を突き合わせ、どのパターンに当てはまるかを切り分けてから対策に進むと、無関係な設定をいじって時間を溶かさずに済みます。4つの症状は互いに独立しているとは限りません。解像度を上げたつもりが上限を超えて縮小され、結果としてスケーリングと対象の小ささが同時に発生する、という複合的な症状もよくあります。1つ直しても改善しない場合は、表の上から順に1行ずつ潰していく進め方が確実です。
座標のスケーリングが合っていないケース
「一定方向にずれ続ける」症状は、Claudeが返す座標をそのまま実画面へ適用していることがほとんどの原因です。Claudeの座標は、あなたが返したスクリーンショット画像のピクセル空間で表現されます。実画面のサイズとスクリーンショットのサイズが違えば、比率で変換する処理が必須です。macOS Retinaディスプレイはデバイスピクセル比が2倍のため、この変換を忘れると常に2倍ずれた場所をクリックすることになります。計算式の具体的な実装はComputer Useの座標ズレを直すスケーリング計算式にまとめているので、この症状に当てはまる場合はそちらを参照してください。
zoomメンバーツールで小さいターゲットの精度を上げる
「近くまで来ているのに外す」症状は、対象そのものが小さすぎて縮小時に情報が失われているケースです。4K以上の高解像度ディスプレイをそのまま縮小してから返すと、小さいアイコンやチェックボックスの座標が数ピクセルの誤差で判別しづらくなります。
対策の中心はzoomメンバーツールです。regionパラメータで矩形を指定すると、その範囲だけをフル解像度で切り出し、アスペクト比を保ったまま返します。ファイル名やタブのタイトル、行番号のように、縮小した全体スクリーンショットでは判読できない要素を確認するために使います。zoomを含む17個のメンバーツールはすべて既定で有効です。実装できない環境では、有効なまま放置してエラーを返し続けるのではなくconfigsで明示的に無効化しておきます。低DPIでのキャプチャや、対象領域だけを切り出して渡す工夫も、同じ症状への対処になります。
指示のあいまいさを潰すプロンプト設計
「全く違う要素をクリックする」症状は、座標計算やモデルの視覚認識ではなく、指示そのものの精度不足が原因であることが少なくありません。位置を明示するプロンプト(「右下にある青いSubmitボタン」のように)を使うこと、複雑な操作は小さいステップに分割することが効きます。
ほかにも実装レベルで効くプロンプト設計がいくつかあります。ユーザーターンのcontent配列を組み立てるとき、指示テキストをスクリーンショット画像より前に置くと、対象の説明を先に処理してからクリック精度を判断できます。ドロップダウンやスクロールバーのようにマウス操作が苦手なUI要素には、キーボードショートカットを使うよう促すと安定します。反復するタスクなら、成功した操作のスクリーンショットとtool_useの例をプロンプトに含めておくのも有効です。ログインが必要なタスクでは、ユーザー名とパスワードを<robot_credentials>のようなXMLタグでプロンプトに含める方法が案内されています。ただしこの種のアプリケーションでComputer Useを使うことはプロンプトインジェクションのリスクを高めるため、認証情報を渡す前にガードレールの強化策を確認しておく必要があります。
各ステップの後にスクリーンショットを撮って結果を確認させるプロンプト(「各ステップの後にスクリーンショットを撮り、正しい結果になっているか慎重に評価してください」)を添えると、Claudeが操作結果を確認せずに次へ進んでしまう誤りを減らせます。バッチアクションを毎回スクリーンショットで締めくくらせたい場合は、システムプロンプトにその旨を明記します。
「全く違う要素をクリックする」症状には、指示の精度不足だけでなく、モデル側のツール選択そのものが揺らぐケースも含まれます。Claudeはアクションを生成する際にツール選択そのものを間違えたり、想定外の操作を取ったりすることがあります。特にニッチなアプリケーションを操作する場面や、複数のアプリケーションを同時に扱う場面では信頼性が下がりやすい傾向です。複雑なタスクを依頼するときほど、指示を丁寧に書く必要があるのはこのためです。1回の指示に複数の意図を詰め込まず、1操作ずつ確認しながら進める設計にすると、ツール選択自体の迷いも減らせます。
バッチアクションのどこで外れたかを特定する
クリック精度の問題は、1回のクリック単体ではなく、バッチアクションの途中で発生することも多くあります。Claudeは「クリック→入力→スクリーンショット」のような複数アクションを1つの応答にまとめて返すことがあり、この一連の流れの中でどのブロックが外れたのかを特定できないと、再現性のある修正ができません。
バッチアクションはブロックを順番に実行し、最初の失敗で残りを打ち切る仕様です。つまり、失敗したブロックのインデックスとtool_useの内容をログに残しておけば、「3番目のクリックだけが外れる」といった再現条件を後から追えます。
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.7ではこの差が縮まり、クリック精度はSonnet 4.6とおおむね同等になったうえ、解像度の上限が高いぶん縮小の必要性自体が減っています。一方、新しいツールセット(computer_toolset_20260801)に対応する以下7モデルについては、同種の比較がドキュメント上に見当たりません。
- 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が座標を出力する際、まれに誤った座標を出したりハルシネーションを起こしたりすることは、Computer Useの制限事項に明記されている既知の挙動です。原因がスケーリングでもプロンプトでもなさそうなときは、Claudeの推論過程を確認する手段があります。thinking設定のdisplayを"summarized"にすると、Claudeがその座標をどう判断したかの要約が返るようになります。Computer Useツールセットに対応するモデルはdisplayが既定で"omitted"(非表示)になっているため、デバッグ目的でこの値を明示的に"summarized"へ変更しておくと、クリック位置の判断根拠を後から追いやすくなります。
スクロールが効かないときも同じ発想で切り分ける
クリックそのものではありませんが、スクロール操作が効かない症状も似た切り分けが有効です。scrollアクションは方向(上下左右)と量を指定できますが、アプリケーションによってはスクロールイベントを正しく受け取らないことがあります。この場合はマウスホイールの模倣にこだわらず、Page Downのようなキーボード操作へ切り替える代替手段が案内されています。クリックの診断表と同じで、症状を1つ特定してから対応する打ち手を1つ選ぶ進め方が、あちこちの設定を同時にいじるより早く収束します。
まとめ
クリックが外れたときは、まず症状を4パターンの診断表に当てはめます。一定方向へのずれは座標のスケーリング、近くて外すならzoomの活用、見当違いの要素をクリックするなら指示の明確化、全体的な精度不足なら解像度の見直しが対応する打ち手です。モデル選びが効く範囲は、精度比較が明言されている旧ツールバージョンの対象モデルに限られる点には注意します。原因の切り分けに詰まったら、thinkingのdisplayを"summarized"にしてClaudeの判断根拠を確認するのも手です。エージェントループ全体の組み方や自前実装とCoworkの使い分けはComputer Useツールを自前実装する最小構成にまとめています。