サイトが変わるたびに壊れるスクレイパー、AIに修復を任せたらどこまで直せる？

スクレイパーを作ること自体は、かなり楽になりました。

URLと欲しいデータを伝えれば、AIがコードまで作ってくれる。 前回はBright DataのScraper Studioを使い、自然言語からスクレイパーを作るところまで試しました。そのときの検証は前回の記事にまとめています。

でも、運用で本当に面倒なのはその後です。

昨日まで動いていたスクレイパーが、サイトのリニューアルを境に突然データを返さなくなる。

CSSのclass名だけが変わることもあれば、DOM構造や描画方法が変わることもあります。 もっと大きなリニューアルなら、そもそも「そのページから何を取得したいのか」まで変わります。

そこで今回は、Bright Data Scraper StudioのSelf-Healingを使い、世代の異なる3つのダッシュボードへ追従できるか試しました。

先に結果

検証	結果
v1	正常に取得
v1向けスクレイパー → v2	実行自体は完了するが、期待したデータが消える
v2へSelf-Healing	URL・セレクタ・待機処理などを修正し、取得可能な範囲は復旧
v2向けスクレイパー → v3	再び期待したデータを取得できず
v3へSelf-Healing	RefactorとValidationを繰り返したが、最終的に修復失敗

今回使うのは、実際に世代交代した3つの画面

検証対象はDisnanaのダッシュボードです。

v1からv2は、同じダッシュボードとしてUIやDOM構造を大きく変更しています。

v3ではさらに踏み込み、ページを「全体概要」として再設計しました。 サーバーの保護状態やサーバー一覧が中心になり、v1・v2とは表示する情報の意味まで変わっています。

今回の変更をざっくり分けると、

世代	変更の大きさ
v1	基準
v2	UI・DOM構造の変更
v3	UI・DOM・表示情報・ページの目的まで変更

という状態です。

この3世代なら、「普通のサイト変更」と「旧スクレイパーを維持する意味まで怪しくなる変更」を同じサイトで試せます。

v1では9項目を正常に取得できた

最初にv1を対象としてスクレイパーを作りました。

取得するのは次の9項目です。

dashboard_title
dashboard_description
total_servers
total_users
command_executions
bot_status
response_time
memory_usage
cpu_usage

Parser codeはv1のDOMに合わせて、各カードやテキストをCSSセレクタで取得する形になっていました。

ここを基準にして、まずv2へ壊してみます。

v2に変えたら「成功率100%」なのに中身が消えた

スクレイパーのコードは変更せず、入力URLだけv2へ変更して実行しました。

https://dashboard.disnana.com/dashboard/v2

返ってきたのはこれだけです。

[
  {
    "input": {
      "url": "https://dashboard.disnana.com/dashboard/v2"
    }
  }
]

9つあったはずのフィールドがありません。

それでもRuns画面では、ジョブ自体は失敗扱いにならず成功率100.00%と表示されました。

ここはかなり印象に残りました。

「処理が正常終了した」ことと「欲しいデータを正しく取得できた」ことは別です。

例外を出して止まってくれれば、監視でも気づきやすい。 一方、処理だけ成功して出力が欠ける壊れ方は見逃しやすくなります。

Bright DataのSelf-Healingでも、修正後はPreviewで期待したデータが返っているか確認してからProductionへ反映する流れになっています。

Self-Healingに「v2へ移行した」と伝える

Self-Healingは、Scraper Studio内で自然言語から既存コードの修正案を作れる機能です。 対象サイトが変わって期待したデータを返さなくなったケースの修正にも使えます。

詳しくはSelf-Healingの公式ドキュメントにまとまっています。

今回は次のように依頼しました。

サイトがv2に移行したら、以前取得できていたデータが取得できなくなりました。
現在のv2ページに合わせてスクレイパーを修正してください。
既存の出力項目とフィールド名は変更せず、
セレクタや取得ロジックのみ必要に応じて修正してください。

ポイントは、既存のフィールド名を維持してほしいと明示したことです。

Self-Healingには出力項目を変更する用途もありますが、今回は新しいスクレイパーを考えてもらうのではなく、既存の出力契約をどこまで維持できるかを見ます。

「修正して終わり」ではなく、Validationを挟んでいた

実行すると、画面には次のようなステップが並びました。

Starting automation...
Planning...
Refactoring code...
Validating results after refactor...
Refactoring code...
Validating results after refactor...

少なくともUI上では、

Refactor → Validation → 必要なら再Refactor

という流れです。

内部でどのような基準を使って再試行しているかまでは分からないので、そこは断定できません。 ただ、「AIが一度コードを書いて終わり」ではないことは画面から確認できました。

セレクタだけでなく、URLと待機処理まで変わった

修正後の差分を見ると、v1向けのセレクタがv2へ合わせて変更されていました。

それだけではありません。

入力URLも、

/dashboard/

から、

/dashboard/v2

へ更新されました。

さらにInteraction codeにはwait()も追加されました。

今回は「v2へ移行した」という文脈とCustom inputを渡していましたが、セレクタだけでなく対象URLまで修正されたのは素直に便利でした。

wait()追加でBrowser workerへの切り替えが必要になった

そのままPreviewしようとすると、今度はIncompatible workerと表示されました。

元のスクレイパーはCode workerでしたが、追加されたwait()はBrowser workerで実行する必要があります。

Bright Dataの公式ドキュメントでは、Code workerは直接HTTPリクエストを行い、Browser workerはヘッドレスブラウザを使ってJavaScript実行やDOM待機などに対応すると説明されています。

Workerの違いはScraper Studio worker types、各関数の仕様はScraper Studio functions referenceで確認できます。

GitHubみたいなdiffで確認してから反映できる

修正が終わると、変更前と変更後のコードが左右に並んで表示されます。

削除は赤、追加は緑。 GitHubなどでdiffを見慣れていれば、かなり分かりやすいUIです。

個人的にここはかなり良かったです。

Self-Healingが作ったコードをそのままProductionへ入れるのではなく、

差分確認 → Accept / Decline → Draft → Preview → Production

と段階を踏めます。

Productionへ反映した後もVersionsから過去版へ戻せます。

「AIが勝手に直す機能」というより、AIに修正案を作らせて、人間がコードレビューする機能と考える方が実態に近く感じました。

コードだけでなく、取得結果もBefore / Afterで見られた

テスト時にはコードだけでなく、

Sample previous result

と

Current result

も比較できました。

v2では、未ログイン状態でも表示されるダッシュボードタイトルと説明文を再び取得できました。

一方、Botの実データやサーバー数などはログイン後に表示する設計なので、未ログインのテストでは取得できません。

これはSelf-Healingの失敗ではなく、ページ上にその値が存在しないためです。

現在アクセスできる情報に対して、旧スクレイパーを追従させられたか。

この基準では、v2へのSelf-Healingは成功と判断しました。

過去の入力ですぐテストできるのも実用的

Accept後は、過去に使った入力を利用してテストクロールできました。

サイト変更対応では、コードがきれいになったかより、

以前と同じ入力で、必要なデータが戻ってくるか

の方が重要です。

その場で実データに近い条件を再利用できるので、修正→確認の往復はかなり短く感じました。

Previewの仕様はScraper Studio IDE interface referenceで確認できます。

数分でも、待たなくていいのは大きかった

Self-Healing中には、

You can safely leave this page. We’ll email you when your code is ready.

と表示されます。

実際、完了するとメールが届きました。

今回の処理は数分程度でした。

数分なら、その場で待てなくもありません。

でも私はSelf-Healingを開始したあと、そのまま別の作業を続けました。 メールが届いたら戻って差分を見る。

進捗バーを眺めるためだけに、作業を止めなくていい。

たった数分でも、その数分は普通に別の仕事へ使えます。 実際に触ってみると、こういう地味な部分の方がありがたかったです。

一覧へ戻っても、復帰は簡単

処理中のBack to scrapers listを押すと、文字通りMy Scrapersの一覧へ戻ります。

戻るときは、対象スクレイパーを選んで上部のコードを押すだけです。

処理を待ちながら別の画面へ移っても、元のIDEへ戻る手順で迷うことはありませんでした。

では、画面の目的まで変えたv3は直せるのか

ここからが今回の限界テストです。

v2までは、DOMが変わっていても「同じダッシュボードの新バージョン」と言えます。

v3では、ページを全体概要として再設計しました。

旧スクレイパーが前提にしていた、

• 総サーバー数
• 総ユーザー数
• コマンド実行数
• Botステータス

といった情報構成そのものが変わっています。

まず、v2対応済みのスクレイパーをそのままv3へ実行しました。

[
  {
    "input": {
      "url": "https://dashboard.disnana.com/dashboard/v3"
    }
  }
]

再び、期待したフィールドは返ってきません。

今度は「存在しない値を無理に埋めないで」と頼んだ

v3へのSelf-Healingでは、条件を一つ追加しました。

サイトがv3に更新され、再びデータを取得できなくなりました。
現在のv3ページに合わせてスクレイパーを修正してください。
既存の出力項目とフィールド名は可能な限り維持してください。

ただし、v3では画面構成や表示される情報自体が変更されているため、
既存フィールドに対応する情報がページ上に存在しない場合は、
無理に誤った値を割り当てないでください。

例えばtotal_serversに、意味が違う「管理中」の数を入れてしまえば、形式上は値が入っていてもデータとしては間違っています。

v3では何度もRefactorとValidationを繰り返した

v3でもSelf-Healingは動き始めました。

ただ、v2よりも明らかに長く、

Refactoring code...
Validating results after refactor...
Refactoring code...
Validating results after refactor...
Refactoring code...

と修正と検証を繰り返しました。

そして最終的には、直りませんでした。

メールでは、要求した変更に対して動作するコードを生成できなかったと通知されました。

失敗理由を内部まで特定することはできないため、「v3の破壊的変更が直接の原因だった」とまでは断定しません。

ただし今回、

v2では復旧できた一方、表示情報やページの目的まで変えたv3では、複数回のRefactor / Validationを経ても修復できなかった

という差は確認できました。

直せなかったなら、作り直す方が自然なこともある

v3の失敗は、個人的には悪い結果だと思っていません。

ここまでページが変わったら、考えるべきなのは、

どうやって旧スクレイパーを延命するか

ではなく、

そもそも旧スクレイパーと同じデータを取り続ける必要があるのか

だからです。

v1向けスクレイパーは「サーバー数やユーザー数、Botの状態を取得したい」という画面設計を前提にしています。

v3ではページの役割自体が変わっています。

そんな状態で昔の9フィールドを何とか埋め続けると、むしろ意味の違うデータを古いスキーマへ押し込むことになります。

大きなリニューアルは、

• 今も同じデータが必要なのか
• フィールド名は現在の意味に合っているか
• 新しいページから本当に取得したい情報は何か
• そもそもスクレイパーを残す必要があるのか

を見直す良い機会でもあります。

今回の検証から見えた使い分け

サイト側の変更	今回どうなったか	運用上の判断
selector / DOMの変更	v2で追従できた	まずSelf-Healingを試す
描画タイミングの変化	wait()が追加された	Worker変更まで確認する
URLの移行	v2 URLへ更新された	入力差分もレビューする
表示情報の大幅変更	v3では修復できず	新規作成も候補にする
ページの目的まで変更	旧スキーマと合わなくなった	要件そのものを見直す

一番良かったのは「全部自動」ではなかったこと

試す前はSelf-Healingという名前から、「壊れたらAIが全部直してくれる機能」を想像していました。

実際に使ってみると、良かったのはむしろ逆でした。

最後の判断を人間に残してくれる。

今回の流れをまとめると、次のようになります。

Workerが変わる場合は確認が入り、直せなければ失敗として通知される。 処理中は別作業へ移り、メールが来たら戻れる。

これは「完全自動修復」というより、

スクレイパー保守の面倒な部分をAIに渡しつつ、最後のレビューは人間が行う

という使い方がしっくりきました。

結論：価値は「壊れなくする」ことではなく、「壊れた後を短くする」ことだった

Self-Healingを使っても、スクレイパーは壊れます。

今回もv1向けのコードはv2で壊れ、v2向けに直したコードもv3では使えませんでした。 Self-Healingもv3を修復できませんでした。

それでもv2では、壊れた状態から自然言語で状況を伝え、AIによる修正・検証、差分レビュー、実データでの確認を経てProductionへ反映するところまで進められました。

従来なら、DevToolsを開いて、死んだselectorを探し、HTMLを追い、コードを書き換えて、もう一度テストするところです。

Self-Healingは、その作業をゼロにはしません。

最初の調査と修正案作成を前へ進めてくれる。

そして、ページの目的まで変わったら無理に延命せず、新しい要件で作り直す。

今回触ってみて、このくらいの距離感が一番現実的だと感じました。

Bright Data Scraper Studioについて

今回検証したScraper StudioのSelf-Healingは、サイト変更で壊れたスクレイパーに対して修正案を生成し、差分確認やPreviewを挟みながら復旧を進められる機能です。

Bright Data Scraper Studioを試してみたい場合は、こちらからBright Dataを確認できます。

Self-Healingの詳しい仕様については、公式ドキュメントで確認できます。

今回の検証ではv2相当の変更には追従できましたが、v3のようにページの目的や表示情報そのものが変わったケースでは修復できませんでした。

「どこまでSelf-Healingで直し、どこから新しく作り直すか」を判断するための道具として使うのが、個人的には一番しっくりきました。

なお、Bright Dataでは、月5,000リクエストまで無料で利用できるFree tier（5,000 requests/month）も用意されています。