AIに渡すWebデータ、ちゃんと取れてる？ スクレイパーの修復もAIに任せてみた

スクレイパーの取得結果を開いたら、こんなJSONが返ってきました。

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

……URLしかない。

JSONとしては読めますが、欲しかったダッシュボードの情報がありません。このままAIに渡したら、不足を指摘してくれるのでしょうか。それとも、何かそれらしい報告を始めてしまうのでしょうか。

今回は、このJSONをAIに渡すところから、Bright Data Scraper Studioでの修正、さらにAIエージェントにBright Data CLIを操作させるところまで試しました。

途中から、直すコードだけでなく、直す相手まで確認することになりました。

URLしかないJSONをAIに渡してみた

使ったのは、以前v2向けに作成したスクレイパーです。これをv3へ向けたところ、冒頭の出力になりました。サイト変更への追従を試した前回の記事の続きです。

検証日は2026年9月19日。使用したモデルの画面表示は「GPT-5.6 Luna 最大」でした。以下、Luna Maxと呼びます。前半はJSONをチャットへ手動で添付し、後半ではCodex側にCLI操作を依頼しています。

最初は、推測を禁止し、入力データ自体も確認するように指示しました。

あなたは運用監視を行うAIエージェントです。

添付したJSONは、Disnanaの管理ダッシュボードをスクレイピングして取得した最新データです。

このデータだけを根拠に、以下を報告してください。

- 現在のサービス稼働状態
- サーバー数
- ユーザー数
- Botの状態
- 異常や注意すべき点

重要:
- JSON内に存在しない情報を推測しないでください。
- URLへアクセスしたり、外部情報を参照したりしないでください。
- データが不足している場合は、具体的に何が不足しているか示してください。
- スクレイピング結果そのものが正常かどうかも確認してください。

最後に、このデータをそのまま自動運用の判断材料として利用してよいか、理由付きで回答してください。

返ってきたのは、稼働状態は判定不可、サーバー数・ユーザー数・Botの状態も不明、という回答でした。

特に納得したのは、サービス障害とスクレイピングの失敗を区別できないと指摘したところです。データがないからといって、サービスが落ちているとは限りません。

念押しをやめたらどうなる？

とはいえ、最初の指示ではかなり親切に確認を促しています。そこで、同じJSONを使って普通に聞いてみました。

添付JSONはDisnanaの管理ダッシュボードから取得した最新データです。
このデータをもとに、現在のサービス状況を簡潔にまとめてください。
サーバー数、ユーザー数、Botの状態、注意点があれば併せて報告してください。

こちらも、URLしかないことを指摘し、数値を勝手に補いませんでした。

AIは「分からない」と返せました。ただ、それで欲しかった情報が手に入るわけではありません。今度は取得側を直します。

修正案は出た。でも、数値は戻らない

Bright Data Scraper StudioのSelf-Healingから、Refactor collector を開きます。手動のSelf-Healing機能を使い、日本語で修正を依頼しました。

このコレクターは以前のダッシュボード向けに作成したものですが、新しいv3ページでは正しくデータを抽出できなくなりました。

以下のURLで再び正常に動作するよう修正してください。
https://dashboard.disnana.com/dashboard/v3

可能な限り、現在の出力項目とJSONスキーマを維持してください。
各項目が表す意味も変更しないでください。
新しいページに存在しない項目については、値を推測・生成しないでください。

修正案には、タイトルや説明文のセレクタ変更、見出しの表示待ち、ログインを要求する文言の検出処理が入りました。一方、旧画面で取っていた指標はこうなっています。

const total_servers = null;
const total_users = null;
const command_executions = null;
const bot_status = null;
const response_time = null;
const memory_usage = null;
const cpu_usage = null;

値を作ってはいません。ただし、これは数値を再取得するコードではなく、null を返すコードです。案を採用して試しましたが、期待した指標の再取得は確認できませんでした。

wait('h1');

画面にないなら、取るものを変えよう

ここでv3の画面を見直しました。確認していた未ログインの画面には、旧ダッシュボードで求めていた数値が表示されていません。ログインへの誘導や、状態を読み込めないという表示も出ています。

画面にないものを、セレクタの修正だけで取り戻そうとしていたわけです。そりゃ厳しい。

そこで、取得対象を見直しました。今度は、ページにあるタブ一覧を取ります。

ページのタブ一覧をとるようにしてください

すると、出力に tabs が追加されました。出力項目の定義であるスキーマの更新確認も表示されたので、承認しています。

[
  {
    "dashboard_title": "全体概要",
    "dashboard_description": "問題のあるサーバーを先に確認できます。",
    "input": {
      "url": "https://dashboard.disnana.com/dashboard/v3"
    },
    "tabs": [
      "fleet",
      "system",
      "servers",
      "plans",
      "commands"
    ]
  }
]

今度は取れました。URLだけだった出力に、タイトル、説明文、5つのタブ情報が入りました。

ただし、旧スキーマを維持したまま元どおりに復旧したわけではありません。同じCollectorを編集しつつ、取得対象を数値指標から画面構成へ変えています。

その後、各タブを開いて内容を取ることも依頼しましたが、この段階で確認できた出力は一覧まででした。

分かることだけ、ちゃんと増えた

取得したJSONを、再びLuna Maxに渡します。今度は稼働状況ではなく、ダッシュボードの構成を整理してもらいました。

添付したJSONは、Disnanaの管理ダッシュボードから取得した最新データです。
このデータをもとに、現在のダッシュボード構成と主要な状態を簡潔に整理してください。

特に以下を確認してください。
- 利用可能なタブ一覧
- 各タブが何を示しているか
- 現在の画面構成から分かる重要な情報
- データに不足や不明点がある場合は、その点を明示

JSON内にない情報は推測しないでください。

Luna Maxは、取得した構成を整理する一方、各タブの中身は不明としました。説明文に「問題のあるサーバーを先に確認できます」とあっても、現在サーバーに問題があるとは断定していません。

取れた情報は使い、取れていないところは埋めない。今回の入力では、そこを区別してくれました。

flowchart TD
    A["v3の取得結果"] --> B["URLだけのJSON"]
    B --> C["Luna Max：情報不足と回答"]
    B --> D["UIで取得項目を見直す"]
    D --> E["タイトル・説明文・タブ一覧"]
    E --> F["Luna Max：構成を整理し、詳細は不明と回答"]

なお、前後で取得項目も質問も変えています。同一条件で修復効果を比較したわけではなく、取得した範囲をAIがどう扱うかの確認です。

修正コマンドまでAIに任せてみる

ここまでは、自分でScraper Studioを操作して、取得結果をAIへ渡していました。

それなら、修正するためのCLI操作もAIに任せられるのではないでしょうか。

追加検証では、Codex側のLuna MaxにBright Data CLIを操作させました。対象はv3からv4へ変更したダッシュボードです。

エージェントの実行記録ではCLIは 0.3.7。WindowsのPowerShellから npm.cmd exec 経由で起動しており、MCP経由ではありません。

狙った流れは、次のようなものです。

flowchart TD
    A["Codex：runして出力を確認"] --> B["必要ならhealを実行"]
    B --> C["修正候補を提示して承認待ち"]
    C --> D{"人間が対象と修正内容を確認"}
    D -->|承認| E["Codex：approveして再run"]
    D -->|却下| F["Codex：rejectして方針を見直す"]

新しいCollectorは作らず、承認前に止まるよう指示しました。今回使ったCLIコマンドの役割は次のとおりです。

公式CLIの説明では、heal は既存のCollector IDを維持して修正し、--auto-approve を付けなければ承認待ちになります。ただし、取得結果が壊れているかをCLIが自動判定するわけではありません。確認するのは、呼び出す側の人間やエージェントです。

10件取れた。でも、それ何のデータ？

途中の修正プレビューでは、articles が10件取得されたと報告されました。

……ダッシュボードを見ていたはずでは？

実行したコマンドを確認すると、最初は対象URLがルートの / になっていました。その後も /dashboard/ への取り違えがあり、指定した /dashboard/v4 に合わせてやり直すことになりました。

さらに、記事のような出力が実画面と合わない点をこちらから指摘すると、エージェントは画面を確認し、提案を却下しました。続いて、dashboard_title と tabs[] を指定した案が承認待ちになりました。

ここまでは、候補を見て修正方針を調整する操作ができています。

しかし、問題はもう1つ残っていました。

URLだけでなく、Collectorも違っていた

後からUIの管理URLと照合すると、CLIで選ばれていたCollectorは、前半で編集していたものとは別でした。

しかも、その別Collectorでは、修正案の承認と再実行まで進んでいました。承認待ちで止まるようにしていても、確認する対象を取り違えていたら防げません。

「同じIDのまま直せるか」を見ていたのに、その前の「このIDで合ってる？」が抜けていました。

最後にv4から確認できたもの

対象を確認し直した後、最後に確認できたJSONでは、input.url が /dashboard/v4 になっていました。タイトルと説明文に加え、6つのタブが返っています。

[
  {
    "dashboard_title": "全体概要",
    "dashboard_description": "問題のあるサーバーを先に確認できます。",
    "input": {
      "url": "https://dashboard.disnana.com/dashboard/v4"
    },
    "tabs": [
      {
        "tab_name": "fleet",
        "tab_title": "コミュニティの状態を一画面で確認",
        "tab_content": "OPERATIONS COMMAND CENTER 確認中 コミュニティの状態を一画面で確認 サーバー、会話量、通話時間、Botの稼働状況を同じ基準で見渡せます。 応答 — 最終更新 — サーバーを管理 Bot導入サーバー — メッセージ総数 — 通話時間 — アクティブユーザー — コマンド実行 — サーバーの状態を確認しています…"
      },
      {
        "tab_name": "system",
        "tab_title": "unavailable",
        "tab_content": "unavailable"
      },
      {
        "tab_name": "servers",
        "tab_title": "unavailable",
        "tab_content": "unavailable"
      },
      {
        "tab_name": "plans",
        "tab_title": "unavailable",
        "tab_content": "unavailable"
      },
      {
        "tab_name": "commands",
        "tab_title": "unavailable",
        "tab_content": "unavailable"
      },
      {
        "tab_name": "updates",
        "tab_title": "unavailable",
        "tab_content": "unavailable"
      }
    ]
  }
]

一方、本文には次のような表示も残っています。読みやすいように抜き出して改行しました。

応答 —
最終更新 —
Bot導入サーバー —
メッセージ総数 —
通話時間 —
アクティブユーザー —
コマンド実行 —
サーバーの状態を確認しています…

画面の構成は取れていますが、稼働状況を判断する数値はまだありません。— や unavailable は、ゼロでも正常稼働でもありません。

なお、このJSON単体では、どのCollectorを使い、どの承認操作の後に実行したかまでは分かりません。正しい対象で一連の修復を完了できたと断定せず、v4の出力確認として扱います。

便利だった部分と、任せきれなかった部分

UIでは、日本語で修正内容を伝えてコードの差分を確認し、取得項目を追加できました。CLI側でも、エージェントに実行・修正候補の取得・承認待ち・却下・承認といった操作を任せられました。

スクレイパーを自分で一から書き直す以外に、修正案を作ってもらって確認する選択肢があるのは便利です。一方、今回の対象取り違えは、Bright Dataの修復結果そのものとは別の問題でした。

ここまでで確認できた範囲を整理します。

自動化へ進めるなら、確認したいのは次の3つです。

操作先：Collector IDと対象URLは、指定したものか
出力　：必要な項目と値があり、読み込み中の表示ではないか
用途　：修正後も、そのデータで元の判断ができるか

特にスキーマ変更では、キーの名前や型だけでなく意味も確認したいところです。articles が返る処理を tabs に変えても、記事一覧を期待する後続処理がそのまま使えるわけではありません。既存スケジュールや外部連携が無変更で使えるか、という検証も今回はしていません。

試してみるなら

Bright Data Scraper Studioは、今回のような既存スクレイパーの修正や、取得項目の変更を試す入口になります。

専用リンクからBright Dataを試す

まとめ

JSONが返ることと、必要な情報が取れることは別でした。修復でも同じで、コマンドが成功しても、対象と中身の確認は残ります。

Self-Healingで修正案を作り、CLI操作までAIに任せることは試せました。ただし、全部おまかせ、とまではいきませんでした。