どこかのニュースルームでは数秒おきに記事が公開され、競合他社は真夜中にプレスリリースを出し、今すぐ確認したい規制関連の資料は州政府のサイトの4ページ目に埋もれている。そんな大量のブラウザタブを人手で見張る仕事なんて、誰にでもできるものではありません。だからこそ「news scraper」が本当の製品カテゴリとして成立したわけですが、同時に、関連する購入ガイドの多くがあまり役に立たない理由でもあります。
今回調べる中で何度もぶつかった問題はここです。ほとんどの「best news scraper」系まとめ記事は、最初から担当領域を1つに絞ってしまいます。ある記事はノーコードSaaSだけを並べ、別の記事はPythonライブラリだけを扱い、まるで世界中の読者がScrapyのspiderを書ける前提で話しているような内容です。これでは、ブラウザ拡張が必要なのか、APIキーで足りるのか、それとも pip install から始める週末作業が必要なのかを判断したい人の助けにはなりません。そこでこの記事では、10個のツールを「ノーコード/agentic」「マネージドAPI」「コーディングライブラリ」の3つに分け、上位表示の理由ではなく、実際のスキルレベルと監視したいソース数に応じて選べるようにしました。
2026年版、最適なニューススクレイパーの条件とは？
ここで本当に見るべきポイントは6つです。以下の基準を軸に、各ツールを見ていきます。
- カテゴリ適合性 — クリック操作型のツールか、インフラまで任せられるマネージドAPIか、自分で組み立てるコーディングライブラリか
- 非エンジニアでも使いやすいか — フォーラムで「非エンジニアでも実際に使えるWeb data scraperが欲しい」という声は本当に多く、決してニッチではありません
- 拡張性 — 20件、100件、1,000件のニュースソースを、都度ルールを書き直さずに扱えるか
- ボット対策とJSレンダリングへの正直な対応 — 「必ず回避できる」といった宣伝文句ではなく、JavaScript、CAPTCHA、ペイウォールにぶつかったとき実際に何が起きるのか
- 料金体系 — サブスク型か、クレジット制か、従量課金か、そしてニュース規模の運用に見合う単価か
- エクスポート先 — CSV、JSON、Sheets、Airtable、webhookなど、必要な場所へデータを届けられるか
ニュース監視用途でこの条件の大半を満たせないツールなら、GitHubのスター数がどれだけ多くても意味はありません。
ノーコード vs API vs コード：あなたに合うニューススクレイパーの選び方
多くの「トップ10」記事は、この3カテゴリをまるで同じ土俵で競っているかのように混ぜて紹介します。でも、実際はまったく別物です。
ノーコード/agenticツールは、営業、オペレーション、リサーチ、マーケティングなどのビジネスユーザー向けです。コードを書かずに、見出しとリンクの一覧が欲しい人に向いています。マネージドAPIは、プロキシ基盤やヘッドレスブラウザを自前で運用したくない開発者向けです。URLを送ればHTMLやJSONが返ってくるので、その上にパイプラインを組み立てます。コーディングライブラリ/フレームワークは、クロール、パース、リトライなどをすべて自分で制御したいエンジニア向けです。その代わり、保守もすべて自分持ちになります。
Thunderbitは、ノーコードの世界が実際の現場でどう見えるかを示す分かりやすい例です。 Thunderbit Chrome extension は One Click Extract というワークフローで動きます。クリックするとツールがページを読み取り、何があるかを判断し、そのうえで Run Now を表示します。押せばすぐ抽出が始まり、何もしなくても数秒後には自動で開始されます。セレクタを書く必要も、最初にスキーマを定義する必要もありません。これは、フォーラムで何度も見かける「非エンジニア向けスクレイパーが欲しい」という悩みに対する、かなり直接的な答えです。ただし、このリストにある他のツールと同様、アクセス権のあるページでのみ動作し、ペイウォールを突破する道具ではありません。
このカテゴリの進化をもう少し広く見たいなら、AI web scrapingの解説 と、スクレイパーが名乗る「ノーコード」が実際には何を意味するのかをまとめた記事も参考になります。
まず確認：RSSフィードやNews APIはすでにないか？
何かを作ったり課金したりする前に、配信元がすでにデータを無料提供していないか確認してください。聞けば当たり前に思える話ですが、実際には見落とされがちです。
多くのニュースサイトは今でもRSSまたはAtomフィードを提供しており、WHATWG HTML spec で定義された標準の <link rel="alternate"> タグから見つけられることがあります。さらに、RSS 2.0 specification 自体も、ほとんどの国ではお酒が飲める年齢くらい古い仕様です。配信元の sitemap.xml も、Sitemaps protocol に従えば、ナビゲーションを1つも触らずに記事URLの一覧をきれいに取得できます。
個別メディア以外にも、いくつかの集約系オプションがあります。
- NewsAPI — 商用のニュース集約API。無料の開発者向けプランと有料の本番向けプランがあります。無料枠を使って本番運用する前に、必ず terms を確認してください。
- GDELT — 無料で使える、一次情報ベースの大規模なグローバルニュース/イベントデータセットです。DOC 2.0 API もあります。発見用途やトレンド分析には本当に便利ですが、プロジェクト側も rate limiting guidance を公開しているので、無限に流れてくる水道のように扱ってはいけません。
ソースにフィードがない、フィードに必要な項目（たとえば本文全文）が含まれない、あるいは監視対象が多すぎて10種類の形式を1本化したい。そんなときはスクレイピングが正解です。ただし、まず確認すること。ここで使う10分は、このプロジェクト全体で最も安く済む10分です。
ニューススクレイパー比較一覧
ここでの価格単位は、クレジット、"successful requests"、コンピュート単位、定額サブスクなどが混在しており、単純比較はできません。予算を決める前に、必ず最新情報を確認してください。
| ツール | カテゴリ | 最適な用途 | JS/ボット対策 | コーディング必要 | 料金体系 |
|---|---|---|---|---|---|
| Thunderbit | ノーコード / agentic | 公開ニュースページから素早く抽出したい非エンジニア向け | 対応済み・許可済みページで利用可能。難しいペイウォールの突破は保証されない | なし | 無料枠 + クレジット制の有料プラン、最新料金はこちら |
| Octoparse | ノーコードのビジュアルスクレイパー | テンプレートを使ったクリック操作型ワークフロー | 内蔵ブラウザ、手動のAJAX設定 | なし〜少ない | 無料枠 + サブスクプラン |
| Apify | Actorプラットフォーム | 既製品と自作スクレイパーを大規模に使いたい開発者向け | Actorごとに異なる | 少ない〜中程度 | 無料利用クレジット + サブスクプラン |
| Bright Data | マネージドAPI/プロキシ | エンタープライズ規模で地域をまたいだスクレイピング | Web Unlocker + 別提供の Browser API | 中程度 | 従量課金 + ボリューム別プラン |
| ScraperAPI | マネージドAPI | HTML/JSレンダリングをシンプルなAPI呼び出しで使いたい | 任意のレンダリング、プロキシローテーション | 少ない（API呼び出し） | クレジット制のサブスクプラン |
| Oxylabs | マネージドAPI/プロキシ | 大量アクセスが必要なエンタープライズ用途 | レンダリング + ブラウザ操作指示 | 中程度 | 結果単位の料金プラン |
| Crawlbase | マネージドAPI | JSの重いサイトや記事向け抽出 | JSトークンレンダリング + プロキシ | 少ない（API呼び出し） | 無料枠 + ドメイン別の動的料金 |
| Scrapy | コーディングフレームワーク | 高い制御性が必要なPythonクローラー | 手動対応（middleware/ブラウザ連携が必要） | 高い | 無料、オープンソース |
| Beautiful Soup | コーディングライブラリ | 静的ページの軽量HTMLパース | なし（Requestsと組み合わせる） | 高い | 無料、オープンソース |
| Selenium | ブラウザ自動化ライブラリ | JSレンダリング済みまたはログイン必須ページ | 実ブラウザを実行。CAPTCHA回避は不可 | 高い | 無料、オープンソース |
1. Thunderbit: 非エンジニア向けの最強ノーコードニューススクレイパー
Thunderbit は、開発者が独自パイプラインを組むためのツールではなく、営業、リサーチ、オペレーションなどのビジネスユーザー向けに作られた、ブラウザベースのagentic抽出ツールです。ワークフローは意図的にシンプルで、One Click Extract を押し、ページ内容を読み取らせ、そのあと Run Now を押します（あるいは何もしなくても、数秒後に自動で始まります）。
主な機能:
- 抽出前にセレクタ、スキーマ、フィールドマッピングを作る必要がない
- 対応ページではページネーションやサブページの情報補完にも対応し、カテゴリページから記事一覧へ展開するような用途に便利
- Excel、Google Sheets、Airtable、Notionへエクスポート可能
- 後からブラウザ運用を超えるチーム向けの別サービスとして Open API も用意
料金は無料枠に加えてクレジット制の有料プランです。クレジット上限やページ制限は変わることがあるので、最新の料金ページ を確認してください。APIは別の料金体系なので、拡張機能のクレジットとAPIの単位を同じだと思わないようにしましょう。
最適な人: 6週間後の本格的な取り込み基盤ではなく、今日すぐにニュースデータのきれいな表が欲しい研究者やアナリスト。
長所と短所
長所: コーディング不要、セットアップが速い、手動でセレクタを作り直さなくてもページ構造の変化に追従しやすい、チームがすでに使っているツールへそのまま出力できる。
短所: 細かなリクエスト制御や独自クロールロジックを求める開発者向けではない。このリストにある全ツールに共通しますが、強いペイウォールやCAPTCHA保護ページには壁があります。そこに魔法の回避策はありませんし、あってはいけません。完全手動構成と比較したいチーム向けには、web scraping without coding の記事でトレードオフを詳しく解説しています。
2. Octoparse: クリック操作で使える最高のビジュアルニューススクレイパー
Octoparse は、ノーコードユーザー向けに、内蔵ブラウザの中でスクレイピングの流れを組めるビジュアルキャンバスを提供します。クリック、ループ、ページネーションルール、待機条件などを組み合わせて作る形式で、agenticツールよりは手動制御が強く、コーディングフレームワークよりは低い難易度です。
主な機能:
- 内蔵ブラウザがJavaScriptを実行し、AJAX読み込みコンテンツを処理できるが、タイミング調整は手動設定が必要なことが多い
- News & MediaカテゴリやCNN専用テンプレートを含む template library
- ローカル実行でのテストに加え、定期ジョブ用のクラウドスケジューリングを利用可能
- 無料枠では、対象のカスタムタスクに対して月50,000行までのローカル出力をサポート
注意点は保守です。ワークフローに具体的なクリックやセレクタを埋め込むため、配信元のUI変更でループや項目が壊れることがあります。これは手書きのScrapyルールが壊れるのと同じです。Pricing は、ローカル無料枠、Standard（月83ドル、年払いなら月69ドル、同時クラウド処理3本）、Pro（月299ドル、年払いなら月249ドル、同時クラウド処理20本）です。
最適な人: 完全自動ツールよりもページ操作の明示的な制御を求めるノーコーダーで、たまのテンプレート保守を気にしない人。
3. Apify: 開発者向けのActorベース・スクレイピングプラットフォーム
Apify は、ApifyがActorと呼ぶ仕組みで動いています。これは、入力と出力が決まった、パッケージ済みのホスティング型スクレイピングプログラムです。Apify自身が管理するものもあれば、コミュニティ製のものもあり、自作も可能です。つまり、1つの製品というよりマーケットプレイスに近く、そのぶん良し悪しがあります。
主な機能:
- 公式管理の Website Content Crawler は、検索やLLMパイプライン向けに適したきれいなテキスト/Markdownを出力
- Google News向けのコミュニティ製Actorもあるが、信頼性と価格は作者次第なので、利用前に必ず個別確認が必要
- 定期実行用の Scheduling、webhook、APIトリガー
- Dataset exports は JSON、CSV、XML、Excel、HTML、RSS、JSONL に対応
Pricing は無料開始で月5ドル相当の利用分が含まれ、Starterが月29ドル、Scaleが199ドル、Businessが999ドルです。さらに従量課金のコンピュート費用と、Actorごとの追加コストがかかります。最終的な支出は、どのActorを使うか、そして裏でフルブラウザを動かすかに大きく左右されます。
最適な人: 1つの固定エンドポイントを買うのではなく、コンポーネントを評価して入れ替えることに慣れた技術チーム。
4. Bright Data: ニューススクレイピング向けの最高のエンタープライズプロキシ基盤
Bright Data は、単体製品というよりスタックとして理解するのが正解です。検索用にはDiscovery datasets、公開ページ取得にはルーティングとアクセス管理を担う Web Unlocker、JavaScriptが重いページにはリモートブラウザを提供する Browser API を使います。万能な「News Scraper API」が1本あるわけではなく、部品を組み合わせて使う形です。
主な機能:
- 地域限定版へのアクセスを助ける広範なジオターゲティング
- 取得専用とフルブラウザ用の製品が分かれており、必要な部分にだけコストを乗せられる
- パイプライン統合向けのAPIおよびwebhook配信
Web Unlocker pricing には月5,000回の無料リクエストが含まれ、その後は1,000件の成功リクエストあたり1.50ドルの従量課金です（499ドル/月プランでは383,000件込みで1,000件あたり1.30ドルに下がります）。Browser API は帯域課金で、従量課金は$8/GBからです。なお、Bright Dataの規約では「successful」は記事の有効性ではなくレスポンスステータスで定義されているので、予算設計時は注意が必要です。
最適な人: すでに抽出ロジックと検証ロジックを持っていて、その下を支える強力なルーティング基盤が必要なエンタープライズチーム。
5. ScraperAPI: ニュースリクエストのスケールに最適なシンプルAPI
ScraperAPI は、このグループの中でも最もシンプルなマネージド取得APIです。URLを送れば、HTML、text、Markdownが返ってきます。必要に応じてJavaScriptレンダリングや地域ルーティングも使えます。
主な機能:
render=trueでヘッドレスChromeを起動し、クライアントレンダリングページに対応- 一部対象向けの組み込みパーサーあり（例: Google News検索結果）だが、配信元記事の万能パーサーはない
- DataPipeline で、1回あたり最大10,000 URLを受け付ける定期・低コードジョブを実行可能
- Batch requests では、非同期で最大50,000 URLを処理可能
Pricing は、1,000クレジット付きの無料枠から始まり、Hobbyが月49ドル（100,000クレジット、同時実行20、US/EUのみ）、Businessは月299ドル（300万クレジット、グローバルルーティング）まで拡張します。注意点として、credit costs vary by request type のとおり、リクエスト種別で消費クレジットが変わります。通常ページは1クレジットですが、JavaScriptレンダリングは10、premium-plus-renderは25です。404の失敗を大量に投げると、月間枠を静かに消耗します。
最適な人: プロキシやブラウザ基盤を自分で管理せず、HTTPリクエストの直置き換えとして使いたい開発者。
6. Oxylabs: 大量処理向けエンタープライズプロキシサービスの最適解
Oxylabs は、ここに挙げたマネージドAPI群の中でも、ワークフローの幅が非常に広いサービスです。任意URLの取得、オプションのレンダリング、クリックや待機を行う browser instructions、独自パース、cron記法対応の組み込み scheduler などが揃っています。
主な機能:
- 任意の公開URLを対象にできる汎用ソース対応と、発見用途向けのGoogle News検索専用パーサー
- 完全成功と部分欠損/欠落を分けてくれる詳細な response codes。ただのHTTPステータスより実用的です
- S3、GCSなどのオブジェクトストレージへクラウド配送可能
- 独自スケジューラには、未検証のスケジュール設定が費用を急増させると明記されており、料金ページとしてはかなり誠実です
Pricing は、最大2,000件の結果まで使える無料トライアル、Micro（月49ドル）、Starter（月99ドル）、Business（月999ドル）があり、ボリューム増加に応じて1件あたりの単価が下がります。注意点として、Oxylabsは4xxレスポンスも請求対象の「成功結果」として扱うため、役に立たないページでも費用が発生することがあります。
最適な人: 地域に柔軟で高スループットな取得が必要で、複雑なAPI面を自分で管理できるエンタープライズ。
7. Crawlbase: JSが重いニュースサイトの解析に最適なAPI
Crawlbase は、このリストの他のマネージドAPIよりも記事向けの出力にかなり寄っています。 Crawling API では、静的コンテンツ用の通常トークンと、フルブラウザレンダリング用のJavaScriptトークン、さらにreadabilityモードが使えます。
主な機能:
md_readability=trueにすると、メイン記事を残しつつ、よくあるナビゲーション、サイドバー、広告のノイズを取り除いたMarkdownを返す- サイト非依存の本文、タイトル、メタデータ抽出用 Generic Extractor
- クリックセレクタ、スクロール、待機制御など、インタラクティブなJSページ向け操作
- Enterprise Crawler では最大48時間の再試行つき非同期キューを提供。バックフィルには向きますが、速報アラートにはあまり向きません
Pricing には最大20,000件の無料リクエストがあり、その後の費用は単一料金ではなく対象ドメインの複雑さで変わります。予算化する前に、実際のニュースソースで計算機を確認してください。なお、現時点では非同期対応はLinkedIn専用として文書化されており、サポートが有効化していない限り他ドメインには当てはめないほうが安全です。
最適な人: 自前でreadability parserを作らずに、レンダリング済みで記事志向の出力が欲しいチーム。
8. Scrapy: カスタムニュースクローラー向けの最強コーディングフレームワーク
Scrapy は、自分でクローラーを所有・運用したいエンジニアにとって、この一覧で最も強力な選択肢です。Pythonフレームワークで、現在のバージョンは 2.17.0。リクエストスケジューリング、重複排除、リトライ、cookie、pipelineまで標準で備えています。
主な機能:
- ParselによるCSS/XPathセレクタで精密抽出
- AutoThrottle とドメイン別同時実行制御で、礼儀正しいクロールが可能
- proxy、headers、独自リトライロジック向けのmiddlewareフック
- dynamic content guide では、フルブラウザ連携の前に埋め込みJSONや構造化データを確認するよう推奨
料金は無料、オープンソース、リクエストごとの課金なしです。実際のコストはコンピュート、デプロイ、そして誰かのオンコール体制にあります。通常のScrapyリクエストはJavaScriptを実行しないため、JSが重いサイトには scrapy-playwright のような追加機能が必要です。また、Scrapyの公式ドキュメントでは、middlewareや重複排除を迂回しやすくなるため、spider内でヘッドレスブラウザを直接動かすのは避けるべきだと明記されています。
最適な人: 長期運用を前提に、自分たちで保守していくマルチドメインのクローラーを作るエンジニアリングチーム。
9. Beautiful Soup: 静的ニュースページ向けの軽量ライブラリ
Beautiful Soup はクローラーではなくパーサーです。この違いは「best scraper」系のリストではしばしば曖昧にされますが、実際には重要です。別のツールが取得済みのHTMLやXMLを受け取り、それをたどれるツリー構造にしてくれます。PyPI上の現行バージョンは 4.15.0 です。
主な機能:
- official docs にあるとおり、複数のパーサー（
html.parser、lxml、html5lib）を速度/寛容性の違いで使い分けできる - Soup SieveによるCSSセレクタ対応で、なじみのある記法が使える
- 実際のHTTP取得は通常 Requests library と組み合わせる
- ページの初期HTML内にあるJSON-LDやOpen Graphメタデータの解析に非常に向いている
料金は無料、オープンソースです。ただし、通信、リトライ、プロキシローテーション、JavaScript実行は一切ありません。そこはBeautiful Soupの仕事ではないからです。すでに取得済みのマークアップが手元にあり、そこから構造化フィールドを抜き出したいときに適しています。
最適な人: 別コンポーネントが取得処理を担当している、小〜中規模のパイプラインを作るエンジニア。
10. Selenium: JSレンダリング済みページやログイン必須ニュース向けの最適なブラウザ自動化
Selenium は実ブラウザを操作するため、JavaScript実行後にしか内容が出ないページや、認証済みのログインセッションが必要な作業に適しています。現在のバージョンは 4.47.0 です。
主な機能:
- Selenium Manager が互換性のあるブラウザドライバを自動検出してキャッシュし、セットアップの手間を減らす
- 固定sleepではなくページ条件に紐づく explicit wait strategies を使える。読み込み後もコンテンツを追加し続ける現代のニュースサイトでは特に重要
- サーバー側実行向けに
--headless=newでヘッドレスChromeをサポート - 配信元の規約で自動化が許可されている範囲で、認可済みのログインセッション内で動作可能
料金は無料、オープンソースです。ただし、ブラウザのコンピュート、コンテナ、ドライバ保守は現実の運用コストになります。記事ごとに1ブラウザインスタンスを立ち上げる設計は、小規模な例外処理を超えると適切ではありません。Seleniumの testing guidance explicitly discourages CAPTCHA automation も明確で、多くの人が「何でも力技で突破できる」と誤解しがちなツールとしては、むしろ誠実です。
最適な人: JS依存ページや認可済みセッションページ向けの限定的なエスカレーション層。何百もの普通の記事に使う標準輸送手段ではありません。
100〜1,000以上のニュースソースに拡張すると何が壊れるのか
CSSやXPathのルールは、「見出しはこのclassの中にある」という前提をコードに埋め込みます。その前提は、配信元がデザインを変更したり、A/Bテストをしたり、CMSを移行したりするまでは有効です。そこから先は、ルールが静かに壊れるか、もっと悪い場合には、静かに間違った結果を返します。たとえば、スクレイパーは成功を返しているように見えて、実際には本文ではなく関連記事のティーザーを取っていたり、公開日時ではなく更新日時を拾っていたりします。空の結果よりもずっと危険です。なぜなら、誰も気づかないまま下流の意思決定が誤データに基づいて進んでしまうからです。
Scrapy、Beautiful Soup、テンプレート型のノーコードプラットフォームのような静的セレクタ方式は、すべてこの問題を抱えます。ThunderbitのようなAI駆動/agentic型のフィールド検出は、固定ルールではなく毎回ページ構造を再分析するため、正確なclass名への依存を減らせます。これは大規模運用では確かに大きな利点です。ただし、保守不要の保証ではありません。決定論的な判断を確率的な判断に置き換えるので、別の種類のエラーと引き換えになります。
本当の意味で大規模（100〜1,000件超）になると、解決策は1つの魔法ツールを選ぶことではありません。ソース登録台帳を作ることです。どのサイトにフィードがあるか、どれがHTMLスクレイピングを必要とするか、想定フィールドは何か、ドメインごとのレート制限はどうするか、そして記事ではなくチャレンジページが返ってきた場合の隔離ルートをどうするか。最初はフィード、次に構造化メタデータ、その次に汎用またはAI抽出、個別ルールは価値の高い例外だけ、ブラウザレンダリングは本当に必要なページだけに限定する。Scrapyの dynamic content documentation も、基本的には同じことを述べています。ブラウザに頼る前に構造化データを確認しましょう。
ボット対策とJSレンダリング：各アプローチでできること、できないこと
この分野の宣伝文句は、まったく異なる5つの問題を1つにまとめがちです。クライアントサイドレンダリング、操作状態（クリック、スクロール、同意バナー）、アクセス頻度制限、認証要件、コンテンツのライセンス権です。実際にレンダリングの問題なのは最初の2つだけで、残りはJavaScriptとは関係ありません。
ツールごとの正直な整理はこうです。proxy rotation（Bright Data、Oxylabs）はルーティングを変えてレート制限の摩擦を減らせますが、許可がないところに許可を生み出すわけではありません。managed rendering（Crawlbase、ScraperAPI）はJavaScriptを実行してクライアントレンダリングされたコンテンツを表示させますが、レンダリングされたページがログイン壁や購読促進画面を返すことは普通にあります。レンダリングは問題を消すのではなく、見えるようにするだけです。headless browser automation（Selenium）は実際の操作を実行できますが、Selenium自身のドキュメントでもCAPTCHAを突破する用途には向かないと明言されています。Thunderbitのレンダリングとアクセス処理も同じで、対応済み・許可済みページのみが対象です。大手有料メディアのような強固なペイウォールをこじ開ける魔法ではありません。
この記事で紹介した10個のツールのどれも、CAPTCHA、ログイン壁、ペイウォールを通過することは保証しません。そう言う人がいたら、存在しないものを売っています。壁にぶつかり続けるなら、取るべき行動は公式フィード、API、またはライセンス契約を探すことです。スクレイピング手法をエスカレートさせることではありません。
ニュースコンテンツをスクレイピングするのは合法？著作権と利用規約
これは法的助言ではありませんし、結果は管轄地域や利用目的によって本当に変わります。ただ、何かを作る前に知っておくべき境界線はいくつかあります。
事実は著作権の対象になりませんが、表現は通常対象になります。U.S. Copyright Office Circular 33 と 17 U.S.C. §102 はその線引きを明確に示しています。記事に書かれた事実そのものは、最初に公開した配信元が誰かというだけでは保護されません。一方で、配信元独自の文体、構成、写真は通常保護されます。ニューススクレイピングでは特に重要な違いです。なぜなら、ニュースコンテンツは（オープンデータや企業ディレクトリと違って）表現された形ではほぼ常に著作権で保護されるからです。
フェアユースは文字数基準ではなく、複数要素で判断されるテストです。17 U.S.C. §107 を見れば分かります。Copyright Office's own summary of Associated Press v. Meltwater は良い注意喚起になります。商用のニュース監視サービスが記事の抜粋をコピーした事例では、その具体的事実関係においてフェアユースとは認められませんでした。これは監視用途全般を禁じるルールではなく、「ただ索引しているだけです」が自動的に勝つわけではない、という警告です。
アクセス法の面では、第9巡回区の hiQ Labs v. LinkedIn と、最高裁の Van Buren 判決によって、Computer Fraud and Abuse Act の適用範囲は狭まりました。ただし、どちらも配信元の利用規約を無視したり、技術的アクセス制御を突破したりする一般的な許可を与えるものではありません。robots.txt は RFC 9309 で標準化されていますが、そこでもこれはセキュリティ機構ではなくプロトコルだと明記されています。従うのは良い習慣ですが、それだけで法的にOKという意味ではありません。
実務上のベストプラクティスは、一般公開データに絞ること、記事全文の再掲載を避けること、出典表記とcanonical linkを保つこと、そして購読壁の向こう側をスクレイピングする前や、全文を再配布する製品を大規模に作る前には弁護士に相談することです。
どのニューススクレイパーを選ぶべきか？
もしあなたが非エンジニアで、明日までに見出し一覧が必要なら、まずは
Learn More
