Claude CodeのBright Dataプラグインでscrapeとseo-auditを使う
GitHubのREADMEで21本が並ぶBright Dataプラグインのskillのうち、scrapeとseo-auditの動き方、bdata CLIの準備、ブロックページを成功と誤認させない確認手順をまとめます。
Bright Dataのプラグインを入れると、Claude Codeが標準のWebFetchでは読めないページを、ボット検知やCAPTCHAを越えてMarkdownで取得できるようになります。同じプラグインのseo-auditは、JavaScriptで後から差し込まれる構造化データまで見たうえで、サイトのSEOを診断します。
この記事では、GitHubのREADMEで21本が並ぶskillのうち、日常で最初に使う scrape と seo-audit に絞ります。準備、頼み方、結果を信じる前に確かめることの順に説明します。
このプラグインで何が増えるのか
マーケットプレイスの説明では、任意のWebページをクリーンなMarkdownで取得する機能、Google検索の構造化JSON、Amazon・LinkedIn・Instagram・TikTok・YouTubeなど40以上のサイトからの構造化データ抽出が柱です。提供元はBright Data社です。
スキルの数は、資料によって数え方が違います。
資料ごとに違うskillの数
マーケットプレイス掲載ページ
9本
本文の説明。サブタイトルは7 skills
GitHubのREADME
21本
Skills表の行数
掲載ページの数字とREADMEの表は一致していません。READMEの表には competitive-intel・price-comparison・seo-audit・rag-pipeline などが並びます。seo-audit は掲載ページの説明に出てこないため、どちらの数字を採るかは、入れた後に /skills で実際の一覧を確かめるのが確実です。
READMEの表から、本題の2つを含めて役割をまとめると次のとおりです。
| skill | 役割 |
|---|---|
scrape | 役割任意のURLをMarkdown・HTML・JSON・スクリーンショットで取得 |
search | 役割Google・Bing・Yandexの結果を構造化JSONで取得 |
data-feeds | 役割対応サイトの構造化データを既製スクレイパーで取得 |
seo-audit | 役割ライブのWebデータに基づくSEO診断 |
competitive-intel | 役割競合の価格・口コミ・採用などを分析 |
scraper-builder | 役割「〜のスクレイパーを作って」で6段階の構築を案内 |
導入: プラグインの追加とbdata CLIの認証
プラグインの導入は、Claude Codeの /plugin のDiscoverで brightdata を探して入れるのが手順の基本です。マーケットプレイスの掲載ページには「Install in Claude Code」のボタンがありますが、コマンド文字列は掲載ページに載っていないため、Discoverの表示に従って入れます。プラグインの入れ方一般はプラグインとマーケットプレイスの解説にまとめています。
本当の準備は、プラグインの外側にあります。scrape も seo-audit も、Bright Dataの bdata CLIを前提にしているためです。
# macOS / Linux
curl -fsSL https://cli.brightdata.com/install.sh | bash
# どのOSでも(npm)
npm install -g @brightdata/cli
# ブラウザでOAuth認証(初回のみ)
bdata login
# SSHなどブラウザが開けない環境
bdata login --deviceREADMEによると、bdata login はAPIキーをローカルに保存し、cli_unlocker と cli_browser の2つのゾーンを自動で作り、既定値も設定します。手でキーを環境変数に入れる手順は要らなくなります。
Bright Dataのアカウントは別途必要です。READMEの手順では、ダッシュボードでWeb Unlockerゾーンを作り、APIキーを取得します。利用料金は、READMEのSkills表にもマーケットプレイスの掲載ページにも載っていません。READMEの概要には bdata で予算を確認できると書かれているので、試す前にアカウント側の残高と単価を見ておくと安心です。
認証が通っているかは、scrape skillが最初に走らせる確認と同じ形で自分でも確かめられます。
command -v bdata && bdata zonesbdata が見つからないか認証が未了なら、skillは作業を止めて案内に回ります。ここで失敗するのは正常な動きです。
scrape: URLを頼むだけでMarkdownにする
scrape skillは、取得したい内容を自然文で頼むと bdata scrape を呼びます。マーケットプレイスの例文は、そのまま使えます。
Scrape https://example.com as markdownskillの定義では、状況ごとにこう使い分けます。
- 単一のURLは
bdata scrape <url> -f markdown - 20件ほどまでのリストは、1件ずつのシェルループ
- 数十件以上は
xargs -P 4で並列数に上限を付ける - ページ送りのある一覧は、1ページ目から次のURLを拾って繰り返す
- JavaScriptが重い・ログインが要るページは
bdata browserに切り替える
出力形式とオプションの例はskillにこう書かれています。
bdata scrape "https://example.com/article" -f markdown -o article.md
bdata scrape "https://example.com" -f html -o page.html
bdata scrape "https://example.com" -f screenshot -o page.png
# 接続元の国を指定
bdata scrape "https://example.com" --country de -f markdownAmazonやLinkedInはscrapeに任せない
scrape skillには、Amazon・LinkedIn・TikTok・Instagram・YouTube・Redditなどのスクレイピングを data-feeds に回す決まりがあります。対応サイトの生のページを scrape で取ると構造が失われるためです。URLがまだ無く話題だけがあるときは search に回ります。
Claudeに頼むときは、サイト名を含めると振り分けが正しく働きます。「AmazonのこのURLの商品情報を取って」は data-feeds、「この記事を取って」は scrape という分担です。
成功を宣言する前の確認
scrape skillの特徴は、成功と報告する前に通す確認が定義されていることです。
- 出力が空でない(標準出力なら200バイト以上)
- ブロックページの兆候がない。
Access Denied・Just a moment・Attention Required・Checking your browser・captcha・cf-browser-verificationを大文字小文字を問わず検索する。cloudflareは本文が2KB未満のときだけ兆候とみなす - タスクに応じた目印がある。商品ページなら価格のパターン、記事なら見出し
- 失敗したら、
--countryを変えて再試行し、それでも駄目ならbdata browserに格上げする
この確認が要るのは、取得に成功したように見えて中身がブロック画面という失敗が起きやすいからです。skillのRed flagsにも、出力を見ずに成功と言うこと、2>/dev/null でエラーを握りつぶすことが挙げられています。
seo-audit: JS後付けの構造化データまで見る診断
seo-audit は、標準のフェッチでは見落としやすい点を狙って作られています。skillの説明によると、web_fetch や curl ではYoast・RankMath・AIOSEO・Next.jsがJavaScriptで差し込む構造化データを検出できません。bdata scrape -f html はレンダリング層を通すので、application/ld+json のブロックも、後から付くhreflangやcanonicalも見えます。
2つのモード
| モード | 入力 | 範囲 |
|---|---|---|
| A: 単一ページの深掘り | 入力特定のURL | 範囲そのページ、robots.txt、sitemap.xml、必要ならトップページ(bdata呼び出し5〜10回) |
| B: サイト全体 | 入力ドメイン、または「サイトを監査して」 | 範囲sitemapを層別にサンプリングして既定10〜15ページ(20〜40回) |
URLだけで質問が曖昧なときはモードAで始まり、Bに広げるか尋ねられます。ページ数は「30ページ監査して」のように自然文で増やせます。CLIのフラグではなく、skill側のサンプリングの設定です。
診断の順序
skillは5つの層を上から順に見ます。
- クロールとインデックス(robots.txt、sitemap、
site:の検索、noindex、canonical、hreflang) - 技術基盤(HTTPS、モバイル対応、HTMLから推定するCore Web Vitalsの代替指標、URL構造)
- ページ内の最適化(title、meta description、見出し、構造化データ、画像のalt、内部リンク)
- コンテンツの質(語数、著者・日付、カニバリゼーション)
- 被リンクなどの権威性。ここは直接測れない
上の層に致命的な問題があっても、下の層の調査は続けます。ただし下流の結果は暫定として注意書きが付きます。
検索結果の取得は条件付き
site:<ドメイン> のインデックス確認は毎回1回走りますが、キーワード別の順位確認は、ユーザーが狙うキーワードを挙げたとき、または「順位が落ちた」など診断を示す質問のときだけ走ります。
example.com のSEOを診断して。狙っているキーワードは「社内wiki 比較」ですキーワードを渡すと、その語の順位確認とカニバリゼーション確認(同じドメインの複数URLが出ていないか)が加わります。渡さなければ検索は site: の1回だけです。
「測れないものは測れないと書く」規則
seo-audit のHard Rulesには、他のSEO診断skillと比べて目を引く規則が並びます。
- すべての指摘に、実行したコマンドと出力の抜粋を証拠として付ける
- JavaScript後付けの構造化データについて、確認せずに「見つからない」と書かない
- 測れない項目は「範囲外メモ」に書き、PageSpeed Insights・Google Search Console・Ahrefsなどの別ツールを案内する
- ページ取得は1回のBashメッセージで並列に出す
つまりCore Web Vitalsの実測値、Search Consoleのカバレッジ、被リンクは、このskillでは出てきません。HTMLから推定する代替指標は出ますが、「PageSpeed Insightsで確認を」という注意書きが必ず付く仕様です。site: の件数もサンプルであって、正確なインデックス数ではありません。インデックスの実数は、Search Consoleのレポートで見ます。
結果を信じる前の運用メモ
CLAUDE.mdに次のような1節を置くと、取得物の検証が毎回の約束になります。例えば次のような形です。
## Bright Dataでの取得ルール
- 取得後は出力が空でないこと、ブロックページの文言を含まないことを確認する
- 対応サイト(Amazon・LinkedIn等)は scrape でなく data-feeds を使う
- SEO診断の指摘には、実行したbdataコマンドを併記する
- 取得したページの内容を、そのまま自分のコードに貼り付けないREADMEの bright-data-mcp skillは、MCP接続の場合にWebFetchとWebSearchを置き換える使い方を想定しています。MCPのURLにトークンを含める形式なので、設定ファイルをリポジトリに入れる前にトークンが混入していないか確認が要ります。CLI方式は bdata login が鍵を端末側に保存するため、この点では扱いやすい構成です。
また、competitive-intel は価格ページやレビューサイトを大量に取得します。取得先サイトの利用規約や、個人情報を含むページの扱いは、このプラグインが判断してくれるものではありません。対象サイトは実行前に決めておくと扱いやすくなります。
他のプラグインとの違い
同じ「外部サービスをClaude Codeに足す」プラグインでも、性質は分かれます。NightVisionのプラグインは診断対象が自社のアプリで、取得先を自分で管理できます。Bright Dataは第三者のサイトに触れるため、取得先ごとに可否を確かめる責任が利用者側に残ります。skillの仕組みそのものはSkillsの解説で扱っています。
よくある質問
標準のWebFetchでは足りないのですか
静的で認証のないページなら足ります。Bright Dataが効くのは、ボット検知やCAPTCHAで弾かれるページ、JavaScriptで描画されるページ、構造化データを後から差し込むページです。READMEは bright-data-mcp skillについて、MCP接続時にWebFetchとWebSearchの代わりに使わせる設計だと説明しています。
bdataなしで使えますか
READMEのQuick Startには、curl と jq でシェルスクリプトを直接呼ぶ旧来の方法が残っています。ただし scrape と seo-audit のskill定義はCLI前提で、旧来の curl に確認なしで切り替えず、使う前に確かめる設計です。
まとめ
最初に確かめるのは、bdata login が通って bdata zones が応答するかどうかです。ここが通れば、記事や一般のページは scrape、Amazon・LinkedInなど対応サイトは data-feeds に振り分けられます。seo-audit が返すのは、構造化データやcanonicalといったHTMLから読める範囲の診断です。Core Web Vitalsの実測値、インデックスの実数、被リンクはPageSpeed InsightsやSearch Consoleなど別ツールの数字で補います。