結論：headerを外すだけでなく、requestと実行制御を移行する
Claude Computer UseのGA移行では、computer_toolset_20260801へ名前を変えるだけでなく、request shape、tool result処理、batch actions、zoom、member別configs、監査logを旧betaと比較します。公式release notesは2026年8月19日にClaude API上でbeta終了を案内し、GA版はbeta header不要、複数actionを一turnで扱うbatch actions、既定有効のzoom、configsによるmember別設定を提供すると説明しています。旧版を止めずにstaging、canary、全体の順で切り替えます。
読者の具体的な困りごとは、既存のComputer Use連携が動いているため、GA版へ変えた時にどこが壊れるか判断できないことです。読了後には、即時移行、改修後移行、旧版の期限付き維持のどれを選ぶか判断できます。次の行動は、現行tool version、beta header、action dispatch、screenshot、座標変換、承認、retryを一つの差分表へ記録することです。
公式仕様、提供条件、料金、制限を確認する
Claude Platform release notesとComputer Use公式文書によると、GA版の正式なtoolsetはcomputer_toolset_20260801です。beta headerは不要で、以前のbeta versionも利用可能と案内されています。ただし「利用可能」は恒久supportを意味しません。model deprecationと同様に更新があり得るため、旧versionを残す場合もowner、期限、移行issueを設定します。
対応modelはClaude Fable 5、Claude Mythos 5、Claude Opus 5、Claude Sonnet 5、Claude Opus 4.8とされています。利用前にmodel overviewでmodel ID、提供platform、context、出力上限を確認します。料金は選択modelのinput/output tokenと、desktopやcontainerを動かす自社基盤費用で決まります。batch actionsは往復を減らせる一方、一turnに含む観測・actionが増えればtokenと失敗時の影響範囲も変わるため、旧版との実測が必要です。
Computer Useは画面を介してdesktopを操作するため、prompt injection、誤click、機密表示、download、clipboard、認証sessionがriskになります。production端末や日常利用accountを直接渡しません。専用sandbox、最小権限account、許可network、temporary storage、監査記録を用意し、外部送信、購入、削除、公開、権限変更は人間確認で止めます。
旧betaとGA版を6軸で比較する
- 識別子：GAは
computer_toolset_20260801を使い、旧betaのtool versionを混在させません。 - header：GAではbeta headerが不要です。共通clientに残る不要headerを棚卸しします。
- request形：公式migration sectionのbefore/afterをfixtureへ落とし、serialize結果を比較します。
- action：GAはbatch actionsを扱えます。途中actionが失敗した時の停止位置を決めます。
- 表示：zoomが既定で有効です。座標、screenshot、DPI、viewportのtestを更新します。
- 設定：
configsでmember別設定が可能です。roleとpermissionの対応を明文化します。
最大の落とし穴は、requestが受理されたことを移行完了とみなすことです。座標変換、tool resultの順序、複数actionの部分成功、zoom後のelement位置、timeout後の画面状態まで確認します。既存testが静的screenshot一枚だけなら、window size、DPI、dialog、scroll、popupを変えたscenario testを追加します。
batch actionsは速度改善だけを目的に広く許可しません。「scrollして読む」のような取消可能な連続actionから始めます。「入力して送信」「選択して削除」のように最後のactionが外部状態を変えるbatchは分割し、変更直前に最新画面と対象を人間へ提示します。途中失敗後にbatch全体を再送しないよう、actionごとの結果を保存します。
安全に移行する8手順
- productionで使うmodel、tool version、beta header、SDK versionを固定します。
- 公式migration sectionを読み、requestとtool resultの差分fixtureを作ります。
- 旧版の代表task、失敗task、停止taskをrecordし、合格基準を決めます。
- GA版をstagingの隔離desktopで動かし、zoom、scroll、keyboard、dialog、downloadを確認します。
- batch actionsはread-only taskから有効化し、部分成功と再試行をtestします。
- member別configsをrole台帳と照合し、管理者権限を既定にしません。
- 少数sessionへcanaryし、成功率、誤操作、latency、token、費用、承認回数を比較します。
- 全体移行後も旧artifactとrollback手順を期限付きで保持し、旧beta廃止情報を追跡します。
canaryでは同じtaskを旧版とGA版へ無制御に二重実行しません。外部状態を変えないtest datasetを使うか、read-only mirrorで比較します。production taskは利用者単位に割り当て、同一taskが両環境へ入らないrouting keyを設定します。
rollback条件は誤操作率上昇、承認画面の欠落、部分成功の判定不能、cost急増、screenshot保存漏れです。version rollbackだけでなく、GA用requestを送るfeature flag、configs、SDK、container imageを同じrelease単位で戻します。
企業運用チェックリストとHOLD条件
- 公式情報を2件以上確認した
- GA toolset名を確認した
- 対応modelを確認した
- request差分fixtureがある
- beta headerの扱いを確認した
- zoomをtestした
- batch部分成功をtestした
- member別権限を確認した
- 専用sandboxを使う
- 外部送信前に承認する
- action単位のlogがある
- tokenと費用を比較する
- canary routingがある
- rollback artifactがある
HOLD条件は、正式toolset名や対応modelが不明、request差分を未検証、production accountを共用、batchの部分成功を判定できない、zoom後の座標を未test、送信や削除が無承認、旧版へ戻せない場合です。GAは製品成熟度の合図であり、自社workflowの安全性を保証するものではありません。
よくある質問と次の行動
GAになったらすぐ全面移行すべきですか？
いいえ。requestとaction処理が変わるため、stagingとcanaryを通し、指標が許容内なら進めます。
batch actionsは必須ですか？
必須ではありません。read-onlyの連続操作から限定的に導入し、外部状態を変える操作は分割します。
旧betaを残す時の注意点は？
owner、終了期限、deprecation監視、rollback目的を明記し、新規実装を旧版へ増やしません。
一次情報はClaude Platform release notes、Computer Use公式文書、同文書のmigration sectionです。関連するBrowser Use導入、権限設定、API費用削減も確認してください。Miraigentの無料診断では、差分test、canary、監査、rollbackを60秒で整理します。