企業が繰り返しのウェブ操作を AI に任せたいと考えるとき、最初の発想はたいてい「AI にそのサイトをクリックさせよう」というものです。しかし成否を本当に分けるのは AI の賢さではなく、まず一つの点を切り分けられているかどうかです。対象システムに外部インターフェースがあるかどうか、という点です。API があるならシステム対システムの連携を使うべきで、ブラウザ自動化の出番は、ウェブ画面しかなく、いかなる接続口も持たない場面に限られます。この境界を混同することが、自動化プロジェクトが初日から方向を誤る主因です。
本稿では製品仕様には触れません。2025 年から 2026 年の公開ベンチマークをもとに、より実務的な三つの問いに答えます。AI ブラウザ自動化は今なにができ、なにができず、そしていつ API ではなくそれを使う価値があるのか、です。能力の境界をはっきり見極めることが、ページが変わった途端に壊れる脆いスクリプトへ資源を賭けずに済む方法です。
まず境界を引く:API が届かないときの代替手段です
API 連携はシステム対システムの対話であり、契約に裏づけられ、安定し、ミリ秒単位で動きます。ブラウザ自動化は AI に人間の真似をさせるもので、ページを開き、画面を認識し、クリックし入力します。前者は常に第一選択であり、正式なインターフェースがある場面では、ブラウザへ迂回するのはほぼ損な取引です。
| 観点 | API 連携 | ブラウザ自動化 |
| 前提条件 | 対象システムが API を提供 | ウェブ画面のみ、接続口なし |
| 安定性 | 高い。契約に守られたインターフェース | 低い。ページ改修で失効しうる |
| 速度 | ミリ秒単位 | ページ読込と描画に左右される |
| 保守コスト | 低い | 高い。ページ変更に追従し続ける必要 |
| 使いどころ | 連携できるなら必ず優先 | API がない、または費用過大な場合の補完 |
一言でいえば、API が使えるならブラウザは使わないことです。ブラウザ自動化の価値は、まさに「そもそも API がない」隙間を埋める点にあります。
なにができるか:読み取りは強く、書き込みは弱い
ある作業をブラウザ自動化に任せるべきか判断するには、まずそれが「読み」か「書き」かを見ます。2026 年に公開された Web Bench ベンチマーク(5,750 タスク、452 の実サイト)は、明確な落差を明らかにしました。読み取り型タスクでは、評価対象 7 エージェントのうち 5 つが成功率 70% を超えました。しかし書き込み型タスク、つまりログイン、フォーム入力、アップロード、二要素認証の処理になると、最強の Skyvern 2.0 でも 46.6% しか完了できず、全タスクを通じて最良の完全自動エージェントでも 66% にとどまりました。
言い換えれば、AI に「ページを見てデータを取らせる」のはかなり信頼できますが、「手を入れてデータを変えさせる」と一気にリスクが上がります。書き込みはログイン状態、ボット検知、そして取り返しのつかない結果に関わり、一手の誤りが実損につながりうるからです。安心して任せられるのは、規則が明確で、読み取りと報告を主とする作業です。
- ウェブデータの抽出と監視:定期的に価格、在庫、状態変化を読み取って報告する。読み取り型で成功率が最も高いです。
- システム間のデータ移送:バックオフィス A で整えたデータを、エクスポート機能のない B システムに貼り付ける。読みが多く書きが少なく、比較的安定します。
- 順序が固定された多段操作:ログイン、検索、絞り込み、帳票のダウンロードといった画面フローです。
- 定型のフォーム提出:行政や取引先ポータルの繰り返し入力。ただしこれは高リスクな書き込み領域に入るため、人による確認を残す必要があります。
実際どれだけ信頼できるか:一つの数字に騙されない
公開リーダーボードの数字は見栄えします。WebVoyager ベンチマーク(643 タスク、15 の人気サイト)では、オープンソースの Browser Use が 89.1% を記録し、一部のエージェントは 90% を超え、OpenAI の CUA も約 87% でした。デスクトップ層の OSWorld ベンチマークも進歩が速く、Claude は 2025 年初めの 28% から 2026 年初めの 72.5% まで伸び、約 72% の人間基準に迫っています。
しかしこれらは「クリーンなテスト環境」の成績です。実サイトに戻れば、Web Bench の 66% という全体の天井のほうが正直な目安です。差はどこから来るのでしょうか。ベンチマークチームは、プロキシの遮断、突破できない CAPTCHA、ボットと判定されるログインといったインフラ問題が失敗の相当部分を占めると指摘します。これらは AI の賢さとは無関係です。ですから評価の際はリーダーボードだけを見ず、「改修され防御もある自分の実サイトで、成功率はどれだけ残るか」を問うべきです。現実的には、自分の対象サイトで小規模に試走し、実際の成功率と人手による補正が要る割合を測ってから、規模化の是非を決めるのが賢明です。
なにができないか:反自動化の仕組みと安全の一線
ブラウザ自動化を万能の鍵とみなすのは、最も高くつく誤判断です。いくつかの天井をまず認識する必要があります。
- 意図的な阻止を突破できない:CAPTCHA、二要素認証、人間確認は、そもそも自動化を阻むために設けられています。reCAPTCHA v3 で 0.7 以上のスコアを得るにはほぼ本物の人間のように振る舞う必要があり、通常のスクリプトは設計上、安定して失敗します。無理に突破すべきではありません。
- 画面が変わると壊れうる:項目の移動やボタンの改名でスクリプトは失効し、保守は継続コストになります。
- 安全リスクが過小評価されている:2025 年 8 月、Perplexity の AI ブラウザ Comet に「間接プロンプトインジェクション」の脆弱性が見つかりました。ページに潜ませた指示により、150 秒以内に AI がユーザーの受信箱にログインし、認証を回避し、認証情報を外部に送信できたのです。AI に自律的にブラウザを操作させることは、攻撃面をそのまま広げることに等しいのです。
- 高頻度・大量は不可、重要な判断は丸投げ不可:ページ読込速度に縛られ、API の毎秒数千回のスループットには及びません。金額、契約、法令順守に関わる操作は、人を介在させて確認する必要があります。
いつ使うか:一つの判断順序
導入の是非に悩むより、次の問いに順に答えるほうがよく、答えはたいてい明確な選択を指し示します。
- API はあるか:あれば API 連携を使う。これで終了です。
- 読みか書きか:読み取り/監視が主なら成功率は高く任せられます。大量の書き込みは、期待値を下げ人による確認を加えます。
- 作業は繰り返すか:一度きりなら手作業が安上がりで、毎日・毎週続くものこそ自動化の価値があります。
- 画面は安定し、誤りの代償は抑えられるか:頻繁に変わり結果も重いものは避け、安定し追跡可能なものが最も適します。
この判断が重要なのは、代償が現実だからです。Gartner は 2026 年末までに約 4 割の企業アプリがタスク特化型 AI エージェントを組み込むと見積もる一方、2027 年末までに 4 割超のエージェント型 AI プロジェクトが、費用の暴走、価値の不明確さ、あるいは不十分なリスク管理により中止されると予測しています。適切な場面で使い、監視と人による関門を残すことが、生き残るプロジェクトと打ち切られるプロジェクトを分ける境目になることが多いのです。
ナードテクニックがどうお手伝いできるか
ブラウザ自動化で最も難しいのは技術そのものではなく、どの業務が自動化に値し、どれを API に任せ、どれには触れるべきでないかを見極めることです。ナードテクニックの AI 導入コンサルティングは、まずお客様の実際の業務を棚卸しし、「API で連携できる」「ブラウザしかない」「人手を維持すべき」の三つに分類します。そのうえで、本当に適した読み取りと監視の場面に自動化を設計し、改修の検知、失敗時の再試行、人による確認の関門を組み合わせます。目指すのは、投じたすべてを成功率が持ちこたえる場所に置くことであり、改修で壊れ、安全リスクを潜ませた脆いスクリプトに費やすことではありません。
参考資料