AIブラウザ自動化を壊れにくくする設計

AIエージェントにブラウザ操作を任せると、最初の1週間は快調に動く。ところが2週間後、対象サイトがボタンのクラス名を変えただけでスクリプトが沈黙する。これはAI自動化あるあるではなく、設計上の欠陥だ。LLMに「よしなにやって」と丸投げするだけでは、再現性のある自動化は作れない。

見落とされがちなリスクもある。自動化が依存する外部サイト自体が、検索エンジンのポリシー変更に対応して構造を書き換えるケースだ。2026年4月13日、Googleはバックボタン・ハイジャックをスパムポリシーの明示的違反に指定した。対象サイトが対応を急げば、自動化スクリプトが踏んでいたナビゲーション構造が丸ごと消える。

Librettoが解く問題：なぜAI自動化は壊れやすいのか

AIブラウザ自動化の不安定さは、主に二つの層から来る。一つはLLMの推論そのものが確率的であること。同じページ、同じ指示でも、呼び出しごとに微妙に違うセレクターを選ぶ。もう一つは、自動化の土台にしているサイトのDOM構造が外部要因で変わることだ。

Librettoは、医療ソフトウェア向けブラウザ統合を維持するためにSaffron Healthが構築し、オープンソースとして公開したツールキットだ。アプローチの核心は「AIを補助に使い、決定論的な記録を主軸に置く」こと。ライブページの検査、サイトAPIの逆解析のためのネットワークトラフィック取得、ユーザー操作の記録とスクリプトとしての再生、壊れたワークフローのインタラクティブなデバッグ——この4機能を組み合わせる。

LLMはスナップショット分析（PNG＋HTMLを渡して意図を解釈させる）に限定して使い、実際の操作は記録済みのアクションを再生する。推論の揺らぎが実行パスに影響しない設計だ。

セットアップから記録・再生まで：実装の流れ

導入は3ステップで完結する。

1. インストール: npm install libretto
2. 初期設定: npx libretto setupを実行すると、環境変数（OPENAI_API_KEY、ANTHROPIC_API_KEY、GEMINI_API_KEYなど）から資格情報を読み取り、利用可能な最初のプロバイダーのモデルを自動でピン留めする
3. ブラウザ起動: npx libretto open <url>でヘッド付きブラウザが立ち上がる

設定は.libretto/config.jsonに集約される。AIモデルの明示的なピン留めがポイントで、例えばai.model: "openai/gpt-5.4"のように記述する。モデルをピン留めしないと、プロバイダー側のデフォルト変更がスナップショット分析の挙動を変えてしまう。ビューポートもwidth: 1280, height: 800のように固定するのが基本だ。

セッションデータは.libretto/sessions/<name>/以下に保存される。state.json、logs.jsonl、network.jsonl、actions.jsonl、そしてスナップショット群がセットで記録される。このディレクトリはgit-ignoredなので、認証情報が誤ってコミットされる事故を防げる。ブラウザセッション（cookieやlocalStorage）はnpx libretto save <domain>でプロフィールとして保存し、再ログインなしで再利用できる。

デバッグ時はnpx libretto snapshot --objective "..." --context "..."でスナップショットを取得し、LLMに「このページで何が起きているか」を分析させる。AIはここでだけ動き、実行は記録済みアクションが担う。

Googleのバックボタン規制が自動化に与える影響

Googleの発表によると、バックボタン・ハイジャックは2026年4月13日にスパムポリシー「malicious practices」の明示的違反に指定され、2026年6月15日から強制適用される。違反ページは手動スパムアクションまたは自動ディモーション（検索順位の降格）の対象になる。

バックボタン・ハイジャックとは、サイトがブラウザのナビゲーション履歴に欺瞞的なページを挿入・置換し、ユーザーが「戻る」ボタンで直前のページに戻れないようにする手法だ。広告収益目的のリダイレクトや、サードパーティの広告プラットフォームが埋め込むスクリプトがその典型とされている。

開発者目線で問題なのは、この規制への対応がサイト構造の変更を強制する点だ。ブラウザ履歴スタックを操作していたスクリプトや、history.pushState（JavaScriptでブラウザの履歴に新しいエントリを追加するAPI）を使ったナビゲーションパターンが削除・無効化されると、自動化スクリプトが依存していたページ遷移の順序や特定URLの出現タイミングが変わる。6月15日前後に対象サイトが一斉に対応を進めれば、その期間に複数の自動化が同時に壊れる可能性がある。

Googleはサイト運営者に対し、ライブラリや広告プラットフォームを含む技術実装全体の見直しを求めている。変更するのは自動化の作者側ではなく、依存先のサイト側だ。自分でコントロールできない変更である以上、備えは早いほど良い。

外部仕様変更に壊れない設計の原則

UI変更やポリシー対応に強い自動化を作るには、依存レイヤーを意識することが先決だ。壊れやすい順に並べると、DOMセレクター（最も壊れやすい）→ページ遷移パターン→内部API（比較的安定）という序列になる。

APIレイヤーを直接叩く

Librettoのネットワークトラフィック取得機能が真価を発揮するのはここだ。対象サイトが内部で呼んでいるREST APIやGraphQLエンドポイントをnetwork.jsonlから特定し、UIを経由せず直接叩く設計にすると、ボタンのクラス名変更程度では壊れない。バックボタン規制対応でナビゲーション構造が変わっても、APIエンドポイントが変わらなければ自動化は動き続ける。

変更検知を組み込む

スナップショット機能を定期実行し、「前回と構造が変わったか」をLLMに判定させるパターンが有効だ。本番実行が壊れてから気づくのではなく、変更を検知した時点でアラートを出す。Librettoのスナップショット分析は--objectiveと--contextパラメータで意図を渡せるので、「ログインボタンが同じ場所にあるか確認する」といった具体的なチェックを自動化できる。

セッション管理を分離する

認証セッションをnpx libretto save <domain>でプロフィールとして保存しておくと、ワークフロー本体から認証ロジックを切り離せる。ログインフローが変わっても、プロフィールを更新するだけでワークフロー本体には手を入れなくて済む。

まとめ

AIブラウザ自動化を「動いたらおしまい」ではなく維持できるインフラとして扱うなら、決定論的な記録・再生を軸に置き、LLMは変更検知と分析に絞って使う設計が現実的だ。2026年6月15日のGoogleポリシー施行を一つの契機として、依存しているサイトのナビゲーション構造を今のうちに棚卸しし、APIレイヤーへの移行可否を確認しておきたい。Librettoのnetwork.jsonlはその調査にそのまま使える。