AnthropicはComputer Use、Skills API、Files APIの3機能を同時に正式版へ移行し、Computer Useには新しいブラウザ操作機能を追加した。3機能はこれまでベータ版として提供されており、開発者はAPI呼び出しにbetaヘッダーを付ける必要があり、可用性やレート制限もベータ扱いだった。
Computer Useの仕組み自体は変わらない。モデルにスクリーンショットを渡すと、キーボードの前に座った人間のようにクリック・入力・スクロールを行う。今回の変更で最も実用的なのは、1ターンで複数アクションを実行できるようになった点だ。これまではAPI呼び出し1回につき返せるアクションは1つだけで、マウスを動かすだけでも往復が必要だった。今後は1ターンで複数ステップをまとめて送信でき、タスク全体の所要時間が縮む。同時にComputer UseはBAA（事業提携契約）の対象に加わり、HIPAA要件を満たすようになった。医療や保険分野でのコンプライアンス上のハードルが一段下がったことになる。
ブラウザ操作機能は別の道を選んだ
新しく追加されたBrowser Useは、コンピュータ操作の対象をWebアプリケーションに広げるものだが、そのやり方はスクリーンショットを見てクリックする方式とは異なる。モデルはページの構造を読み取り、具体的な要素を直接指定する。ピクセル座標には依存しない。
この違いは本番環境で大きく効いてくる。座標でクリックするスクリプトは、ウィンドウサイズが変わったり、フォントの描画が違ったり、クッキー同意バナーが出たりするだけで誤った位置をクリックしてしまう。しかもその失敗は静かに起きる——モデルは「送信」ボタンを押したつもりでも実際には空白部分をクリックしており、エラーを抱えたまま処理全体が先に進んでしまう。要素を指定するモデルなら「これはnameがsubmitのボタンだ」といった情報を得られるため、エラーが起きても上流で検知しやすい。
自動化の世界ではSelenium全盛期にも同じ道をたどったことがある。画像マッチングからDOMセレクタへの回帰だ。今回のエージェントの波はスクリーンショットから出発し、結局同じ結論にたどり着いた。
この2つの方式は完全に排他的というわけでもない。スクリーンショット方式の強みは対応範囲の広さにある。デスクトップソフト、リモート端末、古いWindowsクライアントにはDOMが存在せず、見て判断するしかない。ブラウザ操作機能が解決するのはWebの領域であり、Webは企業の業務システムの大部分を占めている。Anthropicはこの2つを同じComputer Useの下にまとめており、開発者は2種類のAPIを使い分ける必要がなく、モデルが対象となるウィンドウの種類に応じて手段を切り替える。
スキルはアップロード方式に
Skills APIが扱うのは別の話だ。Anthropicはスキルを、指示・スクリプト・テンプレートを収めたフォルダと定義しており、モデルはタスクに必要な時だけそれを読み込む。正式版になったAPIはアップロードとバージョン管理を簡素化し、スキルはClaude付属のコードサンドボックス内で実行される。開発者が自分で実行環境を用意する必要はない。
ホスティングの手間が省ける意味は小さくない。社内のレポート生成フローをスキル化しようとすると、これまではスクリプトをどのマシンで動かすか、どう隔離するか、失敗時にどう回復するかを先に詰める必要があった。今はその部分がプラットフォーム側に吸収される。引き換えに実行環境の主導権は相手側に渡ることになり、どんな依存パッケージを入れられるか、外部ネットワークに出られるかはプラットフォームのルール次第になる。
ファイル容量は1TBに
Files APIの変更はインフラ面のチューニングに近い。ファイルは自動失効に対応し、レート上限は従来の5倍に引き上げられ、組織ごとに1TBのストレージが割り当てられる。一度アップロードしたファイルは以降のリクエストでIDを指定して参照できるため、同じ契約書や決算資料を毎回コンテキストに詰め込む必要がなくなる。
1TBという数字はテキスト中心のアプリケーションには十分すぎるほどだが、スキャン画像や録音データ、動画フレームを扱うアプリケーションにとっては話が別だ。自動失効の機能は見落とされがちだが、これは「削除」という作業を開発者のタスクリストから消し去るものであり、長時間動き続けるエージェントが中間生成物の削除を忘れて容量を使い切る心配がなくなる。
Asteroidの3つの数字
Anthropicが挙げた顧客事例は保険金請求の自動化を手がけるAsteroidだ。最も長い請求処理フローは32分から13分に短縮され、1件あたりのコストは約3割下がり、完了率は100%に達したという。
3つの数字のうち、完了率が最も達成しづらい。保険金請求のフローは複数の基幹システムをまたいでおり、途中のどこか一箇所でも誤ってクリックすれば処理は途中で止まってしまい、そこから人手で引き継ぐコストは自動化しない場合より高くつく。所要時間とコストの改善は1ターン複数アクションやリトライ回数の減少で得られるが、完了率の向上はブラウザ操作機能によるところが大きいとみられる。
公開された数字を単純計算すると、32分かかっていたフローが13分になったことで、同じ人員が1日に処理できる件数はほぼ倍になる。さらにコストが3割下がることで、1件あたりの採算がようやく合う。保険金請求という業務はミスへの許容度が極めて低く、払いすぎても払わなさすぎても責任を問われる。それでも完了率100%を公表できるということは、この会社が人手によるチェックポイントを残さずに最後まで処理を走らせる自信を持っているということだ。
3機能は現在Claude PlatformとMicrosoft Foundryで利用でき、Google CloudのVertex AIも追って対応する予定だ。同じ時期に各プラットフォームがこの方向で機能を揃えつつある。OpenAIも以前、Codexの推論機能とコンピュータ操作を同一モデルに統合しており、路線としては今回の正式版化と重なる。どちらの操作がより安定しているかは、最終的にはこうした複数システムをまたぐ業務の完了率で決まるものであり、ベンチマークの点数が持つ意味は限られる。
参考資料：Anthropic公式発表、CocoLoop、Claude Platformドキュメント。レート倍率、ストレージ容量、Asteroid事例の3つの指標はそれぞれ個別に確認済み。