本記事はBright DataのPR記事です。検証には、自分で運営しているDisnanaのダッシュボードを使用しています。
スクレイパーの取得結果を開いたら、こんな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しかないことを指摘し、数値を勝手に補いませんでした。
各条件を1回ずつ試した結果です。2回目は外部参照の禁止も外しています。今回の回答から、モデル全般の安全性や、あらゆる欠損への耐性までは判断できません。
AIは「分からない」と返せました。ただ、それで欲しかった情報が手に入るわけではありません。今度は取得側を直します。
修正案は出た。でも、数値は戻らない
Bright Data Scraper StudioのSelf-Healingから、Refactor collector を開きます。手動のSelf-Healing機能を使い、日本語で修正を依頼しました。
v3対応を依頼した文面
このコレクターは以前のダッシュボード向けに作成したものですが、新しい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 を返すコードです。案を採用して試しましたが、期待した指標の再取得は確認できませんでした。
修正案が生成されたことと、必要なデータが復旧したことは別です。キーが残っていても、値が null なら元の監視用途には足りません。
プレビュー時にはWorkerの切り替えも必要だった
さらにプレビューすると、生成コードに追加された wait('h1') と、その時点のCode Workerが非互換でした。
wait('h1');
wait() は公式の関数リファレンスでもBrowser Worker向けの機能です。修正案だけでなく、実行環境との組み合わせも確認する必要がありました。
また、案の採用後には「Changes saved to draft」と表示されました。修正案の採用と本番への反映も、同じ操作ではありません。
切り分けでは、生成された認証チェックを一時的にコメントアウトする手修正もしています。ログインを突破したわけではなく、未ログインで見える情報を確認するためです。
画面にないなら、取るものを変えよう
ここで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と一緒に渡した指示
添付したJSONは、Disnanaの管理ダッシュボードから取得した最新データです。
このデータをもとに、現在のダッシュボード構成と主要な状態を簡潔に整理してください。
特に以下を確認してください。
- 利用可能なタブ一覧
- 各タブが何を示しているか
- 現在の画面構成から分かる重要な情報
- データに不足や不明点がある場合は、その点を明示
JSON内にない情報は推測しないでください。
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経由ではありません。
狙った流れは、次のようなものです。
新しいCollectorは作らず、承認前に止まるよう指示しました。今回使ったCLIコマンドの役割は次のとおりです。
| コマンド | 役割 |
|---|---|
bdata scraper run |
Collectorを実行して取得結果を見る |
bdata scraper heal |
既存Collectorの修正候補を作る |
bdata scraper approve --reject |
提案を却下する |
bdata scraper approve |
修正案を承認する。反映後の確認は別途 run で行う |
公式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で合ってる？」が抜けていました。
承認待ちと承認後の記録（いずれも別Collectorでの操作）
エージェントの記録では、awaiting_approval、--reject による却下、その後の approve、再実行まで確認できました。
ただ、後から別Collectorを触っていたことが分かったため、この結果は今回のダッシュボード修復の成功例には含めません。
今回のCLI検証では、修正案そのものだけでなく、どのCollectorを、どのURLに対して直しているのかを確認する必要がありました。
--auto-approve は使っていません。承認の手前で止める仕組みは役立ちましたが、何を確認してから承認するかまではこちらで決める必要があります。
最後にv4から確認できたもの
対象を確認し直した後、最後に確認できたJSONでは、input.url が /dashboard/v4 になっていました。タイトルと説明文に加え、6つのタブが返っています。
| 項目 | 最終JSONで確認できた内容 |
|---|---|
| タイトル | 全体概要 |
| タブ |
fleet / system / servers / plans / commands / updates
|
fleet のタイトル |
コミュニティの状態を一画面で確認 |
fleet の本文 |
画面の説明、指標のラベル、読み込み中の表示 |
| その他5タブのタイトル・本文 | unavailable |
最後に取得できたv4のJSON全文
[
{
"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の修復結果そのものとは別の問題でした。
ここまでで確認できた範囲を整理します。
| 検証 | 確認できたこと | ここからは言えないこと |
|---|---|---|
| 欠損JSONをLuna Maxへ渡す | 今回の2条件では、不足を指摘して数値を補わなかった | どんな欠損でも安全に処理できる |
| UIのSelf-Healing / Refactor | 日本語で修正を依頼し、v3のタイトルやタブを取得できた | 旧指標や旧スキーマがそのまま復旧した |
| CodexからのCLI操作 |
run / heal / 却下 / 承認 / 再実行を試せた |
当初意図したCollectorで修復を完了できた |
| 最終的なv4のJSON | タイトル、6タブ、fleet の本文を取得できた |
サーバーの稼働状態や利用数値を取得できた |
自動化へ進めるなら、確認したいのは次の3つです。
操作先：Collector IDと対象URLは、指定したものか
出力 ：必要な項目と値があり、読み込み中の表示ではないか
用途 ：修正後も、そのデータで元の判断ができるか
特にスキーマ変更では、キーの名前や型だけでなく意味も確認したいところです。articles が返る処理を tabs に変えても、記事一覧を期待する後続処理がそのまま使えるわけではありません。既存スケジュールや外部連携が無変更で使えるか、という検証も今回はしていません。
試してみるなら
Bright Data Scraper Studioは、今回のような既存スクレイパーの修正や、取得項目の変更を試す入口になります。
2026年9月19日時点の公式料金ページには、月5,000ページ読み込みの無料枠と、クレジットカード不要の案内があります。取得レコード数とページ読み込み数は同じではないため、反復実行する場合は使用量も確認しておきたいところです。
業務利用向けには、ISO/IEC 27001認証やSOC 2 Type II報告書についての案内もあります。
まとめ
JSONが返ることと、必要な情報が取れることは別でした。修復でも同じで、コマンドが成功しても、対象と中身の確認は残ります。
Self-Healingで修正案を作り、CLI操作までAIに任せることは試せました。ただし、全部おまかせ、とまではいきませんでした。