Claude Platform で computer use / Skills API / Files API が一般提供へ — 新しい browser use ツール、1ターン複数アクション、HIPAA 対応

要約

Anthropic は 2026-08-20、Claude Platform の **computer use、Skills API、Files API を一般提供（GA）**に切り替えました。あわせて computer use の一部として browser use ツールを新設しています。

公式が示す組み合わせ方は明快です。computer use と browser use が「ソフトウェアを操作する」部分、Skills API が「自社の専門知識を適用する」部分、Files API が「成果物のファイルを受け渡す」部分を担います。公式が挙げている例は保険金請求のエージェントで、Files API から受付書類を読み、チームの申請手順を書いたスキルに従い、browser use ツールで保険会社の Web ポータルに入力し、確認書をファイルとして保存する、という流れです。すでに GA 済みのコード実行と Web 検索も同じループに入ります。

ここで押さえておきたいのは、これが新機能の発表ではなく「beta から GA への切り替え」だという点です。computer use も Skills も Files API も、これまで beta フラグ付きで使えていました。実験としては動かせるが、SLA や規制対応の観点で本番に載せる判断は取りにくい、という状態が続いていたわけです。GA はその制約を外します。企業側の意思決定で言えば、PoC の予算から本番の予算へ移す根拠がここで揃った、ということになります。

技術面で効くのは **computer use の「1ターン複数アクション」**です。これまでは1回のモデル呼び出しにつき1アクションしか実行できませんでした。フォームに5項目入力するだけで5往復かかる構造です。1ターンで複数アクションを実行できるようになると、呼び出し回数が減り、所要時間が縮み、結果としてコストも下がります。エージェントの実用性を決めるのは多くの場合この「往復回数」なので、体感の差は大きいはずです。

新しい browser use ツールは、スクリーンショットに加えてページ構造を読み取ります。画面上の座標ではなく特定のフィールドやボタンを対象に操作するため、レイアウトが少し変わっただけで壊れる、という従来のピクセルベース操作の弱点が緩和されます。Web アプリを対象にした自動化では、これが安定性を大きく左右します。

規制対応では、computer use が BAA 下の HIPAA 規制ワークロードの対象になりました。医療系のデータを扱う業務で画面操作の自動化を検討できる、ということです。日本国内であれば HIPAA そのものは直接関係しませんが、「規制対象ワークロードに載せられる水準まで来た」という信号としては読む価値があります。

提供面では、Skills API と Files API が Microsoft Foundry 経由でも利用可能です。更新版 computer use と browser use ツールは Google Cloud の Vertex AI に近日提供予定とされています。既存の beta 連携は移行期間中も動作します。

何が変わったか

• computer use が GA。1回のモデル呼び出しにつき1アクションだった制約が外れ、1ターンで複数アクションを実行できる
• computer use が BAA 下の HIPAA 規制ワークロードの対象に
• browser use ツールを新設。スクリーンショットに加えてページ構造を読み取り、座標ではなく要素を指定して操作する
• Skills API が GA。独自スキル（指示・スクリプト・テンプレートをまとめたフォルダ）のアップロードとバージョン管理に対応。Claude のコード実行サンドボックス内で動くためホスティング不要
• Files API が GA。自動有効期限、レート上限5倍、組織あたり 1TB のストレージ
• Skills API と Files API は Microsoft Foundry 経由でも利用可能
• 更新版 computer use と browser use ツールは Vertex AI に近日提供
• 既存の beta 連携は移行期間中も動作

業務インパクト（一般企業向け）

「自動化できない業務」の範囲が変わります。 API を持たない業務システム、ベンダーが提供する Web ポータル、社内で長年使われている古い画面。これらは RPA の領域でしたが、RPA は画面の座標や DOM の固定を前提にするため、UI が変わるたびに保守が発生します。browser use ツールがページ構造を読んで要素を指定する方式は、その保守コストの構造を変えます。RPA を導入済みの組織は、既存シナリオのうちどれが壊れやすいかを棚卸しして、置き換え候補を選ぶところから始めるのが現実的です。

Skills API は、社内標準の配布手段として読むのが正しいと考えています。「チームの申請手順」「見積書の書式」「レビューのチェック観点」といった暗黙知を、指示・スクリプト・テンプレートのフォルダとしてパッケージし、バージョンを付けて配れます。これまで社内 Wiki に書いて「読んでおいて」で終わっていたものが、エージェントが実際に従う実行可能な形になります。バージョン管理が API で提供される意味は大きく、手順を更新したときに、どのエージェントが古い手順で動いているかを追えるようになります。

情シス・法務のレビュー観点では、GA 移行に伴う3点を確認してください。第一に、スキルはコード実行サンドボックス内で動くため、自社でホスティング環境を用意する必要がありません。裏を返せば、実行環境の統制は Anthropic 側に依存します。第二に、Files API に組織あたり 1TB という単位が入りました。何を置いてよいか、保持期間をどうするかを決めておかないと、自動有効期限の設定が実質的なデータ保持ポリシーになってしまいます。第三に、Microsoft Foundry 経由という選択肢は、既に Azure でガバナンスを固めている組織にとって導入経路の候補になります。

既に beta で組んでいるチームは、移行計画を立てる時期です。公式は既存の beta 連携が動き続けると明言していますが、beta のまま放置すると、いつ移行するかの判断を先送りし続けることになります。GA の API に切り替えるコストは、今のほうが小さいはずです。

副業・個人活用視点

個人開発者にとって効くのは、ホスティング不要でスキルを動かせる点です。「エージェントに自分の作業手順を教える」ことは以前からできましたが、そのためにサンドボックス環境を用意して守るのは個人の手に余る作業でした。Skills API はその部分を引き受けます。自分の納品フォーマット、チェックリスト、定型スクリプトをスキルとして固め、案件ごとに付け替える、という使い方が現実的になります。

受託の観点では、browser use ツールが提案の幅を広げます。「API が無いので自動化できません」と答えていた領域に、画面操作という選択肢が入ります。特に中小企業の業務システムは API を持たないものが多く、そこが手作業で残っているケースは珍しくありません。安定性が上がったとはいえ画面操作は壊れうるので、壊れたときに気づける監視をセットで提案するのが誠実な売り方です。

Files API の「一度アップロードして ID で参照する」設計は、地味ですがコストに効きます。同じ PDF を何度も送り直す構成は、そのぶんトークンを払っています。長い資料を繰り返し参照する用途では、ファイルの扱い方を変えるだけで請求額が変わることは知っておいて損がありません。

1ターン複数アクションへの変更は、料金の見積もり方にも影響します。エージェントの単価を「1タスクあたりのモデル呼び出し回数 × 単価」で見積もっていた場合、その回数が減ります。見積もりの前提が変わったので、過去の実績値をそのまま引き写さないほうがよいでしょう。