Nullstead

AI

ブラウザ操作AIは便利ですが、APIを捨てるにはまだ早いです 2026年夏のcomputer use実務プレイブック

OpenAI、Anthropic、Cloudflareの2026年最新情報をもとに、ブラウザ操作型AIエージェントを個人開発や自動化へどう組み込むべきかを整理します。computer useとAPI自動化の使い分け、安全策、実装の勘所をまとめました。

約11分

2026年夏のAI界隈を見ていると、ひとつ目立つ変化があります。エージェントが「コードを書く」だけでなく、ブラウザやデスクトップを実際に操作する 方向へかなり本気で進み始めたことです。リンクを開く、フォームを埋める、スクリーンショットを見る、画面の変化に応じて次の操作を決める。昔のRPA ※画面操作を自動化する仕組み を知っている人ほど、「それ、見たことあるやつでは？」と思うはずです。はい、だいたい合っています。ただし今回は、固定シナリオのロボットではなく、状況に応じて手順を組み替える推論層 が乗っています。そこが2026年版の違いです。

一方で、ここでテンションだけ上げて「もう全部UI自動化でいけます」と言い切るのは危険です。ブラウザ操作型AIは便利ですが、APIの代わりになる万能選手ではありません。むしろ実務では、APIで済むところはAPI、APIが無い穴を埋めるところだけcomputer use という考え方のほうが安定します。派手なデモはたいていクリックで始まりますが、運用事故もだいたいクリックで始まります。

この記事では、2026年8月時点のOpenAI、Anthropic、Cloudflareの公開情報をベースに、個人開発や小規模な自動化でブラウザ操作型エージェントをどう使うべきかを整理します。私はここで「全サービスを何か月も本番運用しました」とは書きません。そこは盛らずに、公式ドキュメントから読み取れる共通パターン と、実装する側が先に知っておきたい判断軸に絞って話します。

2026年夏、何が変わったのか

まず、各社とも「AIが画面を触る」ことを実験枠から実務枠へ寄せています。

OpenAIは2026年7月9日の発表で、ChatGPT Workの Scheduled Tasks がブラウザや接続済みアプリを使って、定期チェックや更新作業を進められる方向を明示しました。さらにOpenAI APIの computer use ガイドでは、モデルがスクリーンショットを見てUI操作を返すだけでなく、組み込みの computer ツール、既存の自動化ハーネス、コード実行環境 まで含めた複数の実装形態を前提にしています。要するに「画面操作は研究デモです」ではなく、「実装形は複数あるので、自分の環境に合わせて組み込みなさい」という段階に入っています。

Anthropicも同じ流れです。Claudeの computer use tool はベータ扱いではあるものの、スクリーンショット取得、マウス操作、キーボード入力を公式の道具として提供しています。さらに2026年3月のリリースノートでは、Claude Desktop側でも computer use や scheduled tasks の展開が進んでいます。つまり、チャット欄で気の利いた返事をするだけではなく、実際の作業面を引き受けるUI操作エージェント が各社の製品戦略に組み込まれ始めています。

Cloudflareはもう少しインフラ寄りで面白く、2026年8月の Agents Week で Kitesurf と WebMCP を打ち出しました。Kitesurf は「人間に快適なブラウザ」ではなく「エージェントに都合がいいブラウザ」を狙っていますし、WebMCP はサイト側がエージェント向けに道具を公開する考え方です。これは重要で、2026年の論点は単なる「AIがUIを読めるか」ではありません。サイトやアプリの側も、エージェントにどう触らせるかを設計し始めた ということです。

ここまで来ると、ブラウザ操作AIは一時的な流行というより、エージェント実装の一レイヤーとして定着し始めたと見てよさそうです。

なぜ今また「画面操作」が戻ってきたのか

理由はかなり単純で、現実のソフトウェアがAPIだけでできていないからです。

個人開発でも業務自動化でも、理想は全部API連携です。認証は安定し、レスポンスは構造化され、リトライ条件も組みやすい。監査ログも残しやすい。夢があります。ですが現実には、APIが無い管理画面、機能の一部だけAPI未対応のSaaS、担当者向けUIにしか存在しない設定項目、微妙にCSVエクスポートだけ人間向けな画面などが山ほどあります。

そこで従来はPlaywrightやSeleniumで頑張るわけですが、分岐が増えるほどスクリプトは壊れやすくなります。ボタン文言が少し変わった、モーダルの順番が変わった、画面幅でDOMが変わった。この手のトラブルは、エンジニアの睡眠と仲が悪いです。

computer use型エージェントが効くのは、ここです。固定手順をひたすら再生するのではなく、今見えている画面から次の一手を決められる。これにより、「厳密には毎回少し違うが、人間なら対応できる」作業を自動化しやすくなります。たとえば以下のような仕事です。

  • 管理画面で複数ページを横断して変更点を確認する
  • ダッシュボードを見て異常値だけ拾って要約する
  • ブラウザでCSVをダウンロードし、内容を別のツールへ転記する
  • UI上のエクスポート失敗を再現して、どの操作で壊れるか記録する

この種の仕事は、APIだけでも、従来RPAだけでも、少し中途半端でした。だから今、推論付きのUI操作が刺さっています。

それでもAPIを捨てないほうがいい理由

ここはかなり大事です。browser agent が面白いのは事実ですが、実務では APIを第一候補から外さない ほうがいいです。

理由の一つ目は、再現性 です。APIは入出力が比較的安定していて、失敗時の条件分岐も書きやすいです。UI操作は、どうしても画面状態に左右されます。Cookieバナー、A/Bテスト、メンテナンス告知、権限による表示差分、モバイルレイアウトへの切り替わり。人間には「ちょっと邪魔」でも、エージェントには「完全にルートが塞がった」になりがちです。

二つ目は、副作用の制御 です。APIは dry-run、read-only token、権限スコープの分離など、安全側に倒しやすい。一方でUI操作は、見た目が同じでも結果が重いことがあります。保存、公開、送信、承認。このへんは一文字違うだけで胃に来ます。OpenAIもAnthropicも、公式ドキュメントで高インパクトな操作には人間の承認を入れること、隔離された環境で動かすこと、ページ内容を信頼しないことを強く勧めています。これは慎重すぎるのではなく、実務でちょうどいい慎重さです。

三つ目は、コストの見え方 です。API呼び出しは比較的読みやすいコスト構造ですが、computer use はスクリーンショット、ツール定義、やり直し、画面遷移のぶんだけトークンも時間も膨らみやすいです。Anthropicのドキュメントでも、computer use は通常のツール利用コストに加えて画像や結果のぶんが増えます。面白いからといって全部クリックに寄せると、いつの間にか「この自動化、手でやったほうが早かったのでは」という古典的な反省会が始まります。

結論として、APIがあるならまずAPI、無いところをbrowser agentで埋める のが堅実です。スパナで済むネジをわざわざハンマーで回す必要はありません。道具箱のテンションが高いと、たまにそういう事故が起きます。

個人開発で実用的な使い分け

では、どう切り分けるのが現実的なのか。個人開発なら、私は次の三層で考えるのが扱いやすいと思います。

1. まずは公式APIや既存ツール

Slack、GitHub、Notion、Cloudflareなど、もともとAPIやCLIが整っているものはここで処理します。データ取得、更新、一覧化、バッチ処理はこの層の担当です。ここは堅く、静かに、壊れにくく。

2. APIが弱い部分だけ browser agent

たとえば、請求画面の確認、設定UIの切り替え、ドキュメントサイトの差分確認、アナリティクス画面のスクリーンショット取得などです。構造化APIが足りない場所にだけ使います。主役にするというより、穴埋めの職人 として使う感覚です。

3. できればサイト側も agent-ready にする

ここでCloudflareの WebMCP 的な発想が効きます。もし自分のサービスを持っているなら、将来的には「人間向けUIを読ませてクリックさせる」より、「エージェント向けの最短経路を渡す」ほうがいいです。agentが人間向け画面を推測しながら進むのは、言ってしまえば毎回ちょっとした謎解きです。謎を減らせるなら、減らしたほうがいい。

この三層にしておくと、「全部AIに任せる」でも「結局全部手書きスクリプト」でもない中間に着地できます。2026年の実務では、この中間がいちばん生き残りやすい気がします。

実装するときの安全策

ここはケチらないほうがいいです。OpenAIの computer use ガイドも、Anthropicの computer use docs も、かなり一貫した注意点を出しています。

隔離された実行環境を使う

OpenAIは、ローカルブラウザ自動化でも環境変数を引き継がないことや、拡張機能やローカルファイルアクセスを絞ることを勧めています。Anthropicも専用VMやコンテナ、最小権限、ドメイン制限を挙げています。これは「気をつけましょう」ではなく、設計の前提です。

高インパクト操作は人間承認

送信、支払い、削除、公開、規約同意。このあたりは human in the loop ※重要操作の前で人間確認を挟む形 を入れるべきです。AIが賢いほど、最後のクリックを任せたくなりますが、そこが事故の交差点です。

画面の文言を信用しすぎない

Anthropicは、スクリーンショット内の指示が元の命令と衝突する形でモデルに影響する可能性、つまり prompt injection のリスクを明記しています。UI内の「ここをクリックしろ」は、必ずしもあなたの味方ではありません。Webページは親切な顔をした他人です。

観測ログを残す

少なくとも、最終判断に使ったスクリーンショット、実行した操作列、保存前の確認文言、失敗時の要約は残したいです。あとで「なぜこうなった」が追えるだけで、夜の自分が少し優しくなれます。

最小構成の実装イメージ

OpenAIのガイドでは、Playwrightのような既存ハーネスを土台にする形が紹介されています。個人開発なら、最初はこの路線が始めやすいです。以下は考え方をつかむための最小イメージです。未検証のサンプル ですが、構成の方向性はこんな感じです。

import { chromium } from "playwright";

const browser = await chromium.launch({
  headless: false,
  chromiumSandbox: true,
  env: {},
  args: ["--disable-extensions", "--disable-file-system"],
});

const page = await browser.newPage({
  viewport: { width: 1280, height: 720 },
});

await page.goto("https://example.com");
// ここでスクリーンショットを取得し、モデルへ渡して次の操作を決める

重要なのはコード数行より、その外側の運用です。

  • どのドメインまで触ってよいか
  • 読み取り専用で済むか
  • 保存や送信前に誰が承認するか
  • 失敗時にどこまで自動リトライするか
  • API経由へ置き換えられる箇所がないか

この設計なしに「とりあえずcomputer useをON」は、包丁だけ買ってキッチンを作った気になるのに少し似ています。切れることは切れますが、あとが大変です。

これから何が起きそうか

2026年8月時点の流れを見ると、今後は二方向へ進みそうです。

ひとつは、browser agent自体の性能向上 です。OpenAIはcomputer useをResponses APIやデスクトップ体験に広げ、Anthropicはローカル実行系の体験を強め、CloudflareはKitesurfのように「エージェント向けブラウザ」そのものを最適化し始めています。人間向けブラウザを無理やり使うのではなく、最初からagent都合で設計された実行面が増えるはずです。

もうひとつは、サイト側がagentに最短経路を渡す流れ です。WebMCPが象徴的ですが、長期的には「人間UIを読ませて頑張らせる」より、「ここに使える道具があります」と公開するほうが自然です。個人開発でも、自分のアプリに管理用の安全なAPIやagent向けの薄い操作面を用意しておく価値は上がると思います。

つまり未来は、「全部ブラウザをクリック」でも「全部API」でもありません。構造化できるところは構造化し、それでも残る現実の摩擦をbrowser agentが吸収する 方向です。地味ですが、この組み合わせがいちばん強いはずです。

まとめ

2026年のbrowser agentブームは、単なるデモ映えでは終わらなさそうです。OpenAIもAnthropicもCloudflareも、UI操作をエージェント実装の現実的な選択肢として前に出してきました。ただし、だからといってAPIや従来の自動化設計が不要になるわけではありません。

個人開発での実務的な答えは、たぶん次の一文に尽きます。APIで行けるところはAPI、画面にしか道がないところだけbrowser agent、重要操作には必ずガードレール。夢は見つつ、保存ボタンの前だけは現実主義で行きましょう。自動化にはロマンが必要ですが、公開事故にはいりません。

参考リンク

Tags #AI #Automation #Browser Agents #Computer Use #Personal Development
← 記事一覧に戻る ページの先頭へ ↑