SaaSのリブランドが自動化パイプラインを壊す — freee→Pasture事例から学ぶ「見えないリスク」と対策
freee業務委託がPastureにリブランドされた際、月末の自動化パイプラインが全壊した実例を深掘り。海外で議論される「selector rot」問題と、RPA・AIエージェント時代に必要な監視設計を解説。
エンジニアのゆとです。
先日、Zennで読んだある技術者の投稿が引っかかって離れません。月末17時に動くはずだったmulti-agentパイプラインが、6タスク中2つで失敗。原因を調べたら、freee業務委託がPastureにリブランドされていた。たったそれだけのことで、自動化が全壊していました。
「修正は10分で終わる。でも気づくのは月末の本番実行まで待たなければならない」。この一文に、現代の自動化が抱えるリスクの本質が詰まっています。
この記事では、この事例を起点に、海外で活発に議論されている「selector rot」問題、RPAベンダーの対応、そしてAIエージェント時代に必要な監視設計まで深掘りします。
何が起きたか: 月末17時の自動化崩壊
発端はシンプルです。月末の勤怠・請求処理を担うmulti-agentパイプラインが17:00に実行。6タスク中4つは成功、2つがタイムアウトで失敗。ログを追うと、エージェントがログインページで停止していました。
原因は以下の3つの変更でした。
- ログインURL:
/loginから/users/sign_inに変更 - フォームのname属性:
session[email]からuser[email]に変更 - 保存ボタンのvalue: 「保存」から「更新」に変更
スクリプトがハードコードしていたURLとセレクタが、リブランドに伴うフロントエンド刷新で全て無効になった。UIの変更は機能追加ではなくブランド変更の副産物ですが、自動化エージェントにとっては「全壊」に等しい破壊的変更です。
修正自体は軽い。記事の著者も「各スクリプトの3箇所を書き換えるだけ。10分で終わる」と書いています。問題は「気づくタイミング」でした。月末の本番実行時に初めて壊れるため、事前テストをしていない限り当日まで検知できない。
しかもリブランドのお知らせメールは届いていました。「URLが変わります」とは書いてあったが、フォームのname属性が変わるとは一言も書かれていなかった。
海外で白熱する「Selector Rot」問題
これは日本だけの問題ではありません。海外のautomation・RPA界隈では「Selector Rot（セレクタの腐敗）」という概念が定着しています。UIが変わるたびに自動化スクリプトが壊れていく現象を指す言葉です。
PlaywrightとPuppeteerコミュニティの議論
PlaywrightやPuppeteerのコミュニティでは、セレクタの耐久性が最重要課題として議論されています。Latenode Communityでは複数のスレッドが立っており、あるユーザーは「Hardcoded selectors are inherently fragile, and no amount of clever selector writing completely solves the problem（ハードコードされたセレクタは本質的に脆く、どんなに賢いセレクタ記述も根本的には解決しない）」と述べています。
現在の推奨アプローチは以下の3段階です。
data-testid属性の活用: QA用に付与されたテスト属性は、UIリニューアルでも維持されやすい。ただしSaaS側がこの属性を提供している必要がある- テキストベースのロケーターへの移行:
page.getByRole('button', { name: '保存' })のようなセマンティックなロケーターは、CSSクラス変更に強い - 複合ロケーター戦略: 1つのセレクタに頼らず、フォールバック付きの複数条件でマッチングする
しかし、今回のPasture事例のようにボタンのラベルテキスト自体が「保存」から「更新」に変わった場合、テキストベースのロケーターすら壊れます。結局、完全に壊れないセレクタは存在しない。
RPAベンダーの対応状況
大手RPAベンダーもこの問題を重く見ています。
UiPathは2025年にHealing Agentをパブリックプレビュー開始。セレクタ再生成、セマンティックターゲティング（「First Name」→「Given Name」のようなラベル変更をNLPで理解）、コンピュータビジョンフォールバックの3層構造で自動修復します。
Automation AnywhereはProcess Reasoning Engineを投入。4億件以上のエンタープライズフローデータで訓練された自己修復型システムで、ダウンタイムを最大50%削減すると発表。2025年のImagineカンファレンスではEnterprise UI Agents（computer use型AIエージェント）も発表しています。
Microsoft Power Automateも2025 Wave 1でSelf-heal UI機能を追加。AIがスクリーン上の要素を実行時に検出し、セレクタが壊れた場合に修復候補を提示する仕組みです。
ただし、Forrester Researchの調査では45%の企業が週次以上の頻度でbotの故障を経験しており、Ernst & Youngは「30〜50%のRPAプロジェクトが初期段階で完全に失敗する」と報告しています。RPAの総コストの70〜75%はメンテナンス・サポートに消えるという試算もある。Self-Healing機能は進化していますが、リブランドのようなURL構造ごと変わるレベルの変更には対応しきれないのが現実です。
視覚ベース操作ツールの台頭
「HTMLセレクタに依存しない」という発想から、視覚ベースの操作ツールが注目されています。
Anthropic Computer Useは、スクリーンショットをAIモデルが解析してマウス操作を指示するアプローチ。セレクタを一切使わないため、DOM構造の変更には強い。WebVoyagerベンチマークでは56%とまだ発展途上ですが、Claude Cowork（2026年1月発表）ではデスクトップアプリ内でマルチステップタスクを自律実行する段階に進化しています。
BrowserUse（Y Combinator出身のオープンソース）は、DOMの構造情報と視覚情報を組み合わせたハイブリッドアプローチ。WebVoyagerベンチマークで89%（最高スコア）を記録。GitHub上でスター数78,000超と爆発的な成長を見せており、Fortune 500企業も採用しています。
Browserbase + Stagehandは2025年6月に$40M Series Bを調達（評価額$300M）。自然言語+コードでブラウザ自動化を実現するStagehandと、スクリプト自動生成のDirectorを提供。2025年に5,000万セッションを処理しています。
ただし視覚ベースでも完璧ではないことは認識しておく必要があります。リブランドでボタンのラベルが変われば、テキストマッチも崩れる。根本的な解決策は「壊れにくい設計」ではなく、「壊れたことを即座に検知できる監視設計」です。
Redditでの実体験: 「自動化を信頼しすぎた」
海外のRedditコミュニティ（r/automation, r/RPA, r/selenium）では、SaaSのUI変更で自動化が壊れた体験談が定期的に投稿されています。
ある投稿では、Salesforceの四半期リリースでCSSクラスが変更され、社内のデータ抽出スクリプトが全滅した事例が共有されていました。修正自体は簡単だったものの、「壊れていることに2週間気づかなかった」ことが問題だったと著者は振り返っています。
別のスレッドでは、HubSpotのUI刷新でPlaywrightベースの自動化テストが50%以上失敗した事例も。コメントには「SaaSにとってUIは自社の資産であり、自動化のために安定させる義務はない」という冷静な指摘がありました。
この指摘は本質を突いています。SaaSベンダーは「機能変更」のリリースノートは出しますが、HTMLのname属性やDOM構造の変更は、APIドキュメントには載らない。ブラウザ操作型の自動化（RPA・AIエージェント問わず）は、このレイヤーに全面依存しているのです。
ChangeDetection.ioで変更を監視する
この問題への現実的な対策の一つが、Webサイト変更監視ツールの導入です。
ChangeDetection.ioはオープンソースの変更監視ツールで、指定したURLのHTML/テキストの変更を検知してSlack・メール・Webhook等で通知できます。
自動化パイプラインの文脈での活用方法は以下の通りです。
- 自動化対象のSaaSのログインページURLを監視対象に追加
- フォーム要素（input name, button value）の変更をCSSセレクタで絞り込み監視
- 変更検知時にSlack通知 → 即座にスクリプトの確認・修正
Docker一発で立てられるので、個人開発者でも導入ハードルは低い。本番パイプラインが壊れる前に変更を検知できるだけで、月末のパニックは大幅に減ります。
実務者が今取るべき4つのアクション
今回の事例から、自動化パイプラインを運用するBtoB企業が取るべきアクションを整理します。
SaaS変更の監視をパイプラインの外に置く
リブランドのメール通知に頼るのは危険です。変更通知の粒度がベンダーに依存するため、フォームのname属性変更などは通知されません。ChangeDetection.ioのようなツールや、定期的にログインフローをテスト環境で走らせるCIジョブを用意するのが現実的です。
自動化の「失敗通知」を月末前に設計する
今回の問題の本質は「月末本番実行まで気づかなかった」こと。自動化スクリプトのテスト実行を月中（例: 25日）に走らせ、失敗をSlackやメールで即通知する仕組みを入れるだけで、検知タイミングを大幅に早められます。
SaaSのAPI提供状況を常に確認する
ブラウザ操作で自動化しているSaaSがAPIを提供しているなら、APIへの移行を最優先で検討すべきです。APIはベンダーが後方互換性を保つ責任を持ちますが、HTMLのDOM構造にはその責任がありません。
バージョニングされたAPIエンドポイント（/v2/users等）であれば、破壊的変更は事前通知されるのが一般的。ブラウザ操作よりも桁違いに安定します。
依存関係をドキュメント化する
どのエージェントがどのSaaSのどのURLとセレクタに依存しているかを一覧化する。リブランドのメールが届いたとき、影響するエージェントを即座に特定できるかどうかが、対応速度を左右します。
まとめ: 「壊れた瞬間を捕まえる」設計ができているか
SaaS自動化は今後も拡大します。AIエージェントがブラウザを操作し、複数SaaSをまたいで業務を処理する構成は、すでに実運用フェーズに入っている。だからこそ「壊れにくい」ではなく「壊れたらすぐ分かる」の設計思想が重要です。
freee業務委託からPastureへの移行は、技術的な複雑さは低い。しかし「月末に初めて壊れる」という構造的なリスクは、自動化の規模が大きくなるほど影響が深刻になります。
アクションポイントをまとめます。
- 自動化スクリプトの月中テスト実行 + Slack通知を設計する
- 依存しているSaaSのURL・セレクタをドキュメント化する
- ブラウザ操作からAPI連携への移行可否を定期レビューする
- ChangeDetection.ioなどの変更監視ツールを導入する
自動化が壊れるのは仕方ない。壊れたことに気づかないまま月末を迎えるのが、本当のリスクです。
