live-research

Bright Data — ライブリサーチ

1つのリサーチ課題を、意図に応じて順位付けした Discover クエリを複数実行し、最適な情報源を読み込み、本文中に引用を付けて調査結果をまとめることで、引用付きの統合レポートに仕上げます。これは discover-api スキルを土台とした ワークフロー です。API の仕組み、モード、パラメーターについては、そちらをお読みください。

成果物がリンク集（それは search／discover-api の用途です）ではなく、理解を深めること（レポート／ブリーフィング）であり、継続的に稼働するシステム（それは rag-pipeline の用途です）ではない場合に使用してください。

セットアップの確認

Discover にアクセスできる必要があります。簡単な確認方法（CLI の場合）：

command -v bdata >/dev/null 2>&1 || echo "CLI missing — see bright-data-best-practices/references/cli-setup.md"
bdata zones >/dev/null 2>&1 || echo "not authenticated — run: bdata login"

（SDK／REST の場合は BRIGHTDATA_API_TOKEN があれば十分です。）

手順

Step 1 — 課題の範囲を決める（最初に行い、省略しない）

課題が広範または曖昧な場合は、API 呼び出しを行う前に、期間、地域／市場、深さ、リサーチが支援する意思決定について、2～3個の確認質問をしてください。範囲を明確にすることが、適切な intent パラメーターの設定につながります。

Step 2 — サブクエスチョンに分解する

トピックを4～8個の観点（定義、主要な関係者、仕組み、根拠、反証、最近の動向、リスク）に分解します。それぞれの観点について、個別に調整した intent を使って Discover を1回呼び出します。こちらの方が、幅広いクエリを1回実行するより効果的です。num_results の上限は20件なので、網羅性を高めるには、1回の大規模な呼び出しではなく、複数のクエリで幅広く調べることが重要です。

Step 3 — 各観点について、コンテンツを含めて Discover を並列実行する

# one call per angle; --include-content so you read sources in the same pass
bdata discover "stablecoin regulation 2026" \
  --intent "recent regulatory actions and proposed legislation, primary sources" \
  --include-content --num-results 15 -o angle_regulation.json &

bdata discover "stablecoin reserve transparency" \
  --intent "audits, attestations, reserve composition disclosures" \
  --include-content --num-results 15 -o angle_reserves.json &
wait

難しいトピックを最大限網羅するには、未加工の REST フローで "mode":"deep" を使用してください（discover-api を参照）。deep は網羅的ですが、時間がかかり、REST のみで利用できます。

Step 4 — 統合、重複排除、順位付け、品質チェック

• 各 bdata discover -o ファイルは {status, results: [...]} 形式のオブジェクトです。統合する前に、すべてのファイルから .results[] をフラット化してください。
• URL で重複排除します（正規化：クエリ／フラグメントを除去し、ホストを小文字にする）。
• relevance_score の降順で並べ替えます。
• コンテンツの品質を確認します（relevance_score が高くても、404 の仮ページやナビゲーションだけのページの場合があります）。content が null、ブロックページの特徴に一致、約200文字未満、または「見つかりません」のように見える行は除外してください。

# VERIFIED: this is the correct merge. `jq -s 'add | unique_by(.link)'` does NOT work —
# each file is {results:[...]}, so you must flatten .results[] first.
jq -s '
  [ .[].results[] ]                                   # flatten results from all files
  | unique_by(.link)                                  # dedup by URL
  | map(select(
      .content != null
      and (.content | length) > 200                   # drop empty / 404 stubs
      and ((.content | test("just a moment|captcha|access denied|cf-browser|page not found|post not found"; "i")) | not)
    ))
  | sort_by(-.relevance_score)
' angle_*.json > corpus.json
echo "kept $(jq length corpus.json) sources"

または、ヘルパーを実行してください（同じロジックで、テスト済みです）：scripts/merge_corpus.sh -o corpus.json angle_*.json （-m <n> でコンテンツの最小文字数を設定します）。jq を手作業でコピーすると間違いやすいため、スクリプトの使用をおすすめします。

注：--include-content を指定すると、通常、content の冒頭部分にはページの ナビゲーションや定型文（メニュー、ロゴ）が含まれます。主張を抽出する際（Step 5）は、 これらの要素を読み飛ばし、記事本文に進んでください。

Step 5 — 読み込み、主張を抽出する

残した各情報源の content から、サブクエスチョンに答える具体的な主張、数値、日付、引用を取り出します。各主張の出典 URL を記録してください。後で引用します。

Step 6 — ブリーフをまとめる

構成されたブリーフを作成します（テンプレートは references/brief-template.md）。自明でない主張にはすべて、番号付きの情報源リストに対応する本文中の引用 [n] を付けます。情報源間に意見の相違がある場合は、平均化して曖昧にせず、明記してください。

Step 7 — 提出前に確認する

• すべての主張をリスト内の情報源までたどれるか？（出典不明の主張がないか）
• 情報源間の矛盾を隠さず示しているか？
• 情報が得られなかった点を明記しているか（「X について一次情報源は見つかりませんでした」など）？
• 情報の新しさを記載しているか。いつ収集した情報で、情報源はどの程度新しいか？

品質基準

• クエリで幅広く、コンテンツで深く調べる。 曖昧なクエリを1つ使うより、明確な intent を多数使います。
• すべてに引用を付ける。 引用のない主張を含むリサーチブリーフは単なる意見です。各 [n] をコーパス内の実在する URL に対応付けてください。
• 一次情報源を優先する。 relevance_score が同程度なら、集約サイトよりも提出書類／文書／発表を優先します。
• 異論を示す。 情報源が食い違う場合は、そのことを明記し、双方の見解の出典を示します。
• 不足している情報を明記する。 「見つかりませんでした」は隠すべき失敗ではなく、調査結果の一つです。

注意すべき兆候

• Discover を大まかに一度呼び出しただけで「ライブ調査」と呼ぶこと。複数の切り口に分解してください。
• 取得した content ではなく、記憶や学習データに基づいて主張を書くこと。すべての主張はコーパスに基づく必要があります。
• 引用や relevance_score を捏造すること。呼び出しに失敗した場合は、その不足を報告してください。
• --include-content を無視してリンクを列挙するだけにすること。それは調査ではなく discover-api です。
• 情報源間の矛盾を平均化して消してしまうこと。
• 重複排除を忘れること。同じ記事が3つのアグリゲーター経由で掲載されると、見かけ上の合意が水増しされます。

参考資料

• references/brief-template.md — 出力の構成（エグゼクティブサマリー、小質問ごとの調査結果、矛盾、情報の不足、番号付き情報源）と、引用例。
• scripts/merge_corpus.sh — ステップ4を、検証済みのワンライナーとして実行します。各切り口のファイルにある .results[] を統合し、URL で重複排除し、品質チェック（null／短い内容／404／ブロックページ）を行って、relevance_score 順に並べ替えます。

関連スキル

• discover-api — 基盤となる API（モード、パラメーター、トリガー／ポーリング）。最初に読んでください。
• rag-pipeline — 1回限りのレポートではなく、再利用可能な検索 システム をユーザーが求めている場合に使用します。
• competitive-intel — 競合に焦点を当てた調査（価格設定、採用、ポジショニング）。
• brand-listening — Reddit／X／TikTok などを対象とした、ソーシャルメディア／センチメント調査。