Anthropicが2026年5月13日に公開した、Claude 4.6ファミリー（Opus 4.6 / Sonnet 4.6 / Haiku 4.5）およびOpus 4.7向けのComputer Use / Browser Use統合に関する包括的な技術ガイドの要点をまとめます。解像度とスケーリング、思考レベルの調整、セキュリティ、コンテキスト管理、デモンストレーションベースの教示パターンまで、実運用に必要な知識を整理しました。
解像度とスケーリング
クリック精度はComputer Use統合の基盤です。クリックが正しい位置に着地しなければ、フォーム入力もボタン操作もワークフローも機能しません。Anthropicが最もインパクトが大きいとする最適化は、スクリーンショットをAPI送信前にダウンスケーリングすること。APIには画像サイズの内部処理制限があり、超過した画像は自動的にダウンスケーリングされます。この場合、モデルが見ている画像と座標空間にずれが生じ、クリックが正確に着地しなくなります。
モデルごとの解像度制限
| 制限 | Claude 4.6ファミリー | Opus 4.7 |
|---|---|---|
| 最大長辺 | 1,568 px | 2,576 px |
| 最大総ピクセル数 | 1.15 MP | 3.75 MP |
| 推奨解像度 | 1280 x 720 | 1920 x 1080 |
1280x720はピクセル予算の約80%を使用し、長辺と総ピクセル数の両制限を十分に下回る安全な実用的デフォルトです。Opus 4.7では1080pが推奨で、720pに対して画質面で有意な向上があります。
アスペクト比を維持した最大解像度の計算
固定解像度の代わりに、ソース画像のアスペクト比に基づいて最大解像度を自動計算する compute_max_api_fit 関数が提供されています。
避けるべき解像度設定
- ネイティブ解像度（無加工） — クリック精度低下の最も一般的な原因
- 960x540未満の低解像度 — 小さなUI要素の認識に必要なディテールが失われる
- 4.6ファミリーでの1920x1080以上 — ピクセル制限を超過し自動ダウンスケーリングされる
- MacOSでのデバイスピクセル比2倍 — スクリーンショットが画面座標の2倍解像度になりうる
content配列でのテキスト・画像の順序
messages配列を構成する際、テキスト指示を画像の前に配置します。モデルがスクリーンショットを処理する前に何を探すべきかを把握できるため、クリック精度が向上します。
Thinking Effortの最適化
Claude 4.6以降のモデルはAdaptive Thinkingをサポートしており、effortレベル（low / medium / high / xhigh / max）でモデルの思考深度を制御できます。Computer Useにおいて重要なのは、UIタスクは深い論理的推論よりも知覚的・機械的な性質を持つため、思考を増やしても必ずしも精度が上がらないという点です。
Opus 4.7の推奨設定
Opus 4.7はOSWorld Verifiedベンチマークで4.6ファミリー全モデルを上回り、low effortでもSonnet 4.6の max と同等のスコアを出しつつ、トークン使用量は約1/10です。
| シナリオ | 推奨effort | 理由 |
|---|---|---|
| 大半のユースケース | high | maxの約半分のトークンで最高精度に近い成功率を達成 |
| 高スループット/コスト重視 | low | Opus 4.6のhigh〜max相当の品質でトークン削減 |
| 複雑な一発勝負タスク | max | 最も困難なタスクで初回成功率を最大化したい場合 |
| シンプル/最速 | Sonnet 4.6推奨 | 低レイテンシが最優先の予測可能なワークフロー |
4.6ファミリーの推奨設定
medium がスイートスポットです。high と比較して出力トークン量が約半分でありながら、ほぼ同等のタスク成功率を達成します。リトライを含めた場合、medium と high は同じ成功率に収束するため、コスト効率を考慮すると medium が最適です。
4.6ファミリーでは max effortは非推奨。 テストでは high に対して精度向上がなく、出力トークンコストだけが増加しました。UIタスクは深い論理推論を必要としないため、追加の思考予算が活用されないか、過度な思考につながるとされています。
モデル選択の指針
モデルごとにクリック精度と推論力のバランスが異なります。ユースケースに応じた選択が重要です。
Sonnet 4.6
機械的なクリック精度が最も高く、高解像度ソースのダウンスケーリングにも堅牢。コストと精度のバランスが最良で、大半のタスクに推奨。
Opus 4.7
Sonnet 4.6同等のクリック精度にOpusレベルの推論力を組み合わせ。高解像度対応（3.75MP）により圧縮損失も軽減。困難なタスクに最適。
Opus 4.6
推論力は強いがクリック精度ではSonnetに劣る。Opus 4.7がこの差を大きく縮めたため、推論が必要な場面では4.7を推奨。
Haiku 4.5
レイテンシが最優先の場合に選択。短く予測可能なワークフローで、UIが安定しており操作手順が既知の場合に適する。
高度なワークフローでは、推論モデルが計画・意思決定を担当し、SonnetやHaikuが機械的なクリック操作を実行するオーケストレーター + サブエージェントパターンが有効です。
プロンプトインジェクション防御
Computer Useエージェントはスクリーンショットやウェブページなど信頼できないコンテンツを処理するため、プロンプトインジェクションが深刻なリスクとなります。Anthropicは3層の防御戦略を採用しています。
トレーニング時の堅牢性
強化学習により、シミュレートされたウェブページやアプリUIに埋め込まれた注入コンテンツへの耐性をモデルに直接組み込みます。
リアルタイム分類器
Claudeのコンテキストウィンドウに入るコンテンツをスキャンするプローブが、テキスト・画像・UIなど複数モダリティで攻撃を検出します。公式 computer_20251124 ツール使用時にデフォルトで有効です。
継続的レッドチーミング
セキュリティ研究者による防御の継続的な検証と、外部の敵対的評価への参加でロバスト性をベンチマークします。
カスタムツール定義使用時の注意
- 公式
computer_20251124ツールタイプを使わず独自のスクリーンショット・クリックツールを定義している場合、分類器は動作しない - Anthropicはカスタム実装への保護拡張を検討中（関心フォームあり）
分類器に加えて、以下のプラクティスが推奨されています。高リスクアクションにはhuman-in-the-loopを実装すること（フォーム送信、購入、メッセージ送信など不可逆な操作の前にユーザー確認を求める）。エージェントの権限スコープを最小化し、ワークフローに不要な機能へのアクセスを制限すること。そして全アクションのログ記録とスクリーンショット保存で異常検出と事後分析を可能にすること。
コンテキスト管理の3層構造
Computer Useエージェントではスクリーンショットが急速に蓄積され、各画像が約1,000〜1,800トークンを消費します。200kコンテキストウィンドウでも100枚未満のスクリーンショットで埋まる可能性があります。効果的なコンテキスト管理は、長時間エージェントのコストとレイテンシに対してほぼ他のどの最適化よりも大きな影響を持つとされています。
Layer 1: キャッシュブレークポイントの配置
APIは最大4つのキャッシュブレークポイントをサポートします。推奨は、システムプロンプトまたはツール定義に1つ、直近のtool_resultに最大3つを配置し、ターンごとに前回のブレークポイントをクリアして再設定する方式です。複数のブレークポイントを分散させることで、最新のブレークポイントが無効化されても、より前のブレークポイントがキャッシュヒットし、入力コストの90%を節約し続けます。
Layer 2: キャッシュ対応ローリングバッファ
直近のN枚のスクリーンショットのみを保持し、古いものをプレースホルダーに置換します。ポイントはバッチでの置換です。1枚ずつ置換するとプレフィックスが毎ターン変わりキャッシュが無効化され続けますが、まとまった間隔でバッチ置換すれば、プルーニングイベント間でメッセージ配列がバイト単位で同一になり、キャッシュが効き続けます。
推奨デフォルト値: keep_n = 3（直近3枚を保持）、interval = 25（25枚溜まったらバッチ置換）。キャッシュヒット率と総入力トークン数を計測しながら調整してください。
Layer 3: LLMベースのコンパクション
古いスクリーンショットを黙って破棄するのではなく、会話全体を要約してから破棄します。要約には、ユーザー指示（逐語的に保持）、タスクテンプレート、制約とルール、実行済みアクション、エラーと修正方法、進捗追跡、現在の状態、次のステップの8セクションが含まれます。
サーバーサイドコンパクション（beta）では、context_management パラメータでカスタム要約プロンプトとトークン閾値を設定するとAPIが自動的に要約を実行します。この場合、クライアント側でも message_index_after_compaction を使って会話履歴を同期的にトランケートし、サーバーとクライアントの状態を一致させる必要があります。
実験的な機能と高度なパターン
Batch Tools New
computer_batch と browser_batch は、複数のサブアクションを1回のツールコールで実行します。N個の機械的操作が1往復で完了するため、長時間タスクでの実行時間と出力トークンを大幅に削減できます。ただし、サブアクション間に視覚的依存がある場合（アクション1の結果を見てアクション2を判断する必要がある場合）は、エラーが連鎖するリスクがあります。フォーム入力やキーボードショートカットチェーンなど、自己完結したアクションの組み合わせに適しています。
Advisor Tool Public Beta
実行モデル（例: Sonnet 4.6）にOpus 4.7レベルのアドバイザーを組み合わせるパターンです。大半のターンはエグゼキューターの機械的操作で処理し、計画が必要な局面やエラー回復時にアドバイザーに相談します。サーバーサイドで1リクエスト内に完結するため追加のラウンドトリップは不要です。注意点として、アドバイザーはツールを持たないためテキストアドバイスのみ返却し、長時間セッションではエグゼキューターがアドバイザーの存在を忘れることがあるため、20ターンごとのリマインダー挿入が推奨されています。
Teach Mode（デモンストレーション録画・再生）
テキストプロンプトでワークフローを記述する代わりに、ユーザーがタスクを実際に操作する様子を録画し、そのデモンストレーションをコンテキストとしてClaudeに渡すパターンです。Claude in Chrome内部で使われている手法を公開したものです。録画は各ステップでスクリーンショット・アクション・音声ナレーションをキャプチャし、再生時にClaudeはデモを参考にしつつ現在のUI状態に適応します。厳密な座標リプレイではなく、ボタンが移動していても同等の要素を見つけて操作できます。
クリック精度のトラブルシューティング
| 症状 | 考えられる原因 | 対処法 |
|---|---|---|
| 一方向に一貫してずれる | display寸法と実際の画像サイズの不一致、API制限超過による自動ダウンスケーリング | display寸法をリサイズ後のサイズに正確に一致させる。1280x720へのプリダウンスケール |
| 大体合うが微妙に外れる | ターゲットが小さい、高解像度ソースのダウンスケーリングで詳細消失 | enable_zoom: True を有効化。DPIの低下やブラウザズームの活用 |
| 完全に違う要素をクリック | 曖昧な指示、類似要素の近接、UIの複雑性 | 位置情報を含む具体的なプロンプト。操作の分割 |
| 全般的に精度が低い | API制限を超えたスクリーンショット、4K+ディスプレイからの極端な圧縮 | 全スクリーンショットのプリダウンスケーリング。Opus 4.7の高解像度対応の活用 |
効果がなかったアプローチ: Anthropicの内部評価で一貫した改善が見られなかったのは、画像をタイルに分割して個別送信する方法、座標グリッドをオーバーレイする方法、リサイズアルゴリズムの選択（PIL LANCZOS、sips等は同一結果）の3つです。
まとめ
Computer Use統合の成功は、適切な解像度管理（事前ダウンスケーリングと座標スケーリング）、タスク特性に合ったThinking effortの選択、プロンプトインジェクション防御の確保、そして長時間セッションでのコンテキスト管理の3層構造（キャッシュ、ローリングバッファ、コンパクション）にかかっています。
特に注目すべきは、Opus 4.7が推論力とクリック精度の両立を達成したこと、Advisor Toolによるexecutor/advisorパターン、そしてTeach Modeによるデモンストレーションベースのワークフロー定義です。これらの技法はComputer Useに限らず、長時間稼働するAIエージェント設計全般に応用可能なアーキテクチャパターンとして参考になります。