ASADASHI
バイブコーディング
バイブコーディング2026.09.21·読了 2分·難易度: ふつう

壊れないブラウザ自動化、AIが自己修復する

朝の出汁版（通勤2分）

  • ポイント1: 「Browser Harness」は、AIがブラウザ操作中にエラーや画面変更が起きても自動で修復しながらタスクを完遂できる自己修復型の自動化フレームワークとして公開された。
  • ポイント2: 従来のブラウザ自動化はサイトのHTML構造が少し変わるだけで動作が止まっていたが、このツールはLLMがその場で状況を判断して操作を組み直す仕組みになっているため、スクレイピングやフォーム入力の自動化がより安定して動く。
  • ポイント3: PythonとGitHubのリポジトリが公開されているので、まずは公式のREADMEにあるサンプルコードをコピーしてローカルで動かすところから始めるとイメージがつかみやすい。

出汁の素（深読みモード）

なぜブラウザ自動化はいつも途中で止まるのか

スクレイピングやフォーム自動入力を試したことがある人なら、心当たりがあるはずだ。昨日まで動いていたスクリプトが、サイト側のリニューアルでボタンのクラス名が変わっただけで動かなくなる。Seleniumでも、Playwrightでも、この問題からは逃げられない。従来のブラウザ自動化は「あらかじめ決めたセレクタや手順」を愚直に実行するだけで、画面の変化に対して適応する仕組みを持っていなかった。サイトのHTML構造は、運営側の都合でいつでも変わる。自動化スクリプトの保守に追われ続けるのが、これまでの現実だった。

「壊れたら自分で直す」自動化の仕組み

Browser Harnessは、そのボトルネックにLLMを挟み込むことで解決を試みるフレームワークだ。GitHubに公開されたリポジトリ（browser-use/browser-harness）には「Self-healing harness」という言葉がある。自己修復型、という意味だ。

仕組みとしては、ブラウザ操作の途中でエラーが発生したり、想定していた要素が見つからなかったりしたとき、LLMがその時点の画面状況をリアルタイムに読み取り、次に取るべき操作を組み直す。固定のルールではなく、「今の画面を見て判断する」という流れに切り替わる。

ログイン済みブラウザをAIに操作させる新手法でも触れたように、ブラウザとAIを組み合わせるアプローチは各所で試みられている。Browser Harnessはその中でも「途中で止まらないこと」に特化した設計になっているのが特徴だ。PythonベースでGitHubに公開されており、すでに17,800スターを超えている。リリース直後の反応としては相当な注目度といえる。

コードなしでできること・書けると有利なこと

コードなしでできることは今のところ限られる。Browser Harnessはあくまでもエンジニア向けのPythonフレームワークで、GUIやノーコードUIは現時点では提供されていない。ただし、ドキュメントに掲載されているサンプルコードは短く、Pythonの基礎があれば数行のコピペで動作確認まで持っていける設計になっている。

コードが書けると有利な場面はいくつかある。定期的にサイトをチェックして情報を取得したい（価格監視・競合調査・求人ウォッチ）、フォームへの自動入力を繰り返したい、複数ステップのWebフローを安定して動かしたい、といったユースケースだ。これまでSeleniumやPlaywrightを使って「サイト更新のたびに修正」を繰り返してきた人には、選択肢として評価する価値がある。

また、仕様書を先に書くとAIコードが変わるで紹介したように、AIにコードを書かせるときに「何をどの順番で操作するか」を自然言語で仕様として渡す手法と組み合わせると、Browser Harnessのタスク記述も書きやすくなる可能性がある。

まず触るならここから：公式READMEとサンプルの読み方

触り始めるなら、GitHubの公式リポジトリ（https://github.com/browser-use/browser-harness）から入るのがいちばん早い。READMEにはインストール手順とサンプルコードが載っており、Pythonとpipが使える環境があればすぐに動かせる。

最初の確認ポイントは3つ。

  1. どのLLMに対応しているか：OpenAIのAPIキーが必要なのか、ローカルモデルでも動くのかをREADMEで確認する。LLMのAPI利用コストが発生する場合があるため、先に把握しておく。

  2. サンプルタスクの内容：公式に提示されているサンプルがどんな操作を想定しているかを読むことで、自分のユースケースとの距離感がつかめる。

  3. エラー時の挙動：自己修復の動きを確認したい場合は、意図的に存在しないセレクタを指定するか、動作途中でページ構造が変わるシナリオを組んでみると、修復プロセスがどう動くかが見える。

まずは「自分がよく使うサイトへの操作を1ステップだけ自動化する」ところから始めると、仕組みの理解が早い。

LLMの推論コストとの兼ね合いをどう考えるか

注目したいのは、自己修復のたびにLLMが画面を読んで判断するということは、その分の推論コストが発生するという点だ。単純なスクレイピングであれば従来のスクリプトの方が速く・安く動く。Browser Harnessが本領を発揮するのは、「エラー対応の手動メンテナンスコスト」と「LLMの推論コスト」を比較したときに、前者が上回るケースだ。

たとえば毎日動かすワークフローで、月に2〜3回のサイト変更のたびに手動修正が必要になるような状況なら、LLMに判断を任せるコストを吸収できる可能性がある。一方、1回限りの処理や、構造が安定しているサイトへのアクセスであれば、従来の手法で十分だ。

NVIDIAのTensorRT-LLMのような推論最適化レイヤーが普及してくれば、こうしたLLM内包の自動化フレームワークの実行コストも下がってくる。この種のツールが「使えるレベル」になるまでの距離は、半年前と比べてかなり縮まっている。

参照ソース