trafilatura は、同じ検証データ上で Readability よりもラベル付きボイラープレートの除去性能が高かった

trafilatura は、ブラウザ不要の Python 用コンテンツ抽出ツールです。この記事で使ったラベル付きフィクスチャでは、同じ HTML を対象にした抽出品質で並べられる相手は Mozilla Readability だけでした。trafilatura は 17 個の注釈付きボイラープレート単位のうち 1 つを取りこぼした一方、Readability は 5 つ取りこぼしました。ブラウザを前提とするツールは、ここでは導入時のフットプリント比較としてのみ登場し、このページ群では品質評価の対象にはしていません。

主な役割は本文抽出です。HTML を入力し、記事向けのテキストとメタデータを出力し、ページの周辺要素はヒューリスティックで除去します。JSON などの形式で出力できますが、ユーザー定義の行スキーマや、型付きの繰り返しレコードを生成するわけではありません。検証したのはバージョン 2.1.0 です。JavaScript は実行せず、Readability との比較結果を見る限り、これは「精度」と「保持率」のトレードオフであって、カテゴリ全体での完全勝利ではありません。

trafilatura が得意なこと、そしてしないこと

trafilatura は、Web 上のテキストとメタデータを収集するための Python / CLI ツールだと説明されています。クロール、スクレイピング、抽出までカバーし、CSV、JSON、HTML、Markdown、TXT、XML で出力できるという、かなり広い打ち出しです。ですが実際にこのツールが担う中心はもっと狭くて明確です。HTML ドキュメントを受け取り、周囲のページ装飾を削ったうえで、本文 を返します。

ここはイメージしておくと理解しやすいです。なぜなら、このツールの強みと境界の両方を説明してくれるからです。多くのスクレイパーはセレクタ駆動です。たとえば「product-price クラスの要素を取ってきて」と指定すると、その場所にあるものを返します。trafilatura は逆です。ページ全体を読み込み、書いたセレクタではなくコンテンツのヒューリスティックで、どのブロックが本当の本文で、どれがボイラープレートかを判断 します。だからサイトごとの個別ルールなしでページをきれいにできます。反面、構造化されたカタログをそのまま渡すことはできません。スキーマも型付き行もなく、あるのは「意味のあるテキストだけ」です。狙って抜くパーサーではなく、抽出器です。

また、別途ダウンロードするブラウザ実行環境も必要ありません。依存関係には lxml のようなプラットフォーム向けホイールが含まれるため、「ブラウザをダウンロードしない」と「ソースだけで動き native コードも不要」は同義ではありません。

セットアップ: 依存関係は軽め、ブラウザ導入も不要

Python 3.14 の新しい virtualenv で pip install trafilatura を実行すると、17 パッケージが入ります。記録上もっとも大きかったホイールは lxml の 8.6 MB でした。詳細は pip-install-trafilatura.log を参照してください。別途ブラウザを入れたり、インストール後にブラウザ用コマンドを実行したりする必要はありませんでした。

規模感を比べると、同じ研究基盤の Scrapling パックでは、フェッチャーを動かすまでに pip を 4 回別々に実行する必要があり、最終的に 26 パッケージ、うち 2 つは 42.2 MB の Playwright ドライバーホイールでした（tools/scrapling/artifacts/logs/pip-install-scrapling.log）。しかもこれはブラウザバイナリをダウンロードする前の話です。Crawlee パックでは、その別途 Chromium ダウンロードだけで約 81.7 MiB でした（tools/crawlee/research-materials.md）。これらのツールはもっと大きな仕事をしているので、機能面で公平な勝負ではありませんが、ディスクと CI キャッシュに何が見えるかという意味では参考になります。さらに、pip が配布した 2.1.0 は現行リリースと一致しているため、以下の数値に「古い版を試しただけ」という但し書きは付きません。

実地検証: 実際に何が返ってきたか

強みが出る場面と壁にぶつかる場面の両方を狙ったフィクスチャで試し、元の出力は benchmark repo に保存しました。記事テストは、これで一気に納得できました。

ローカルの本文入り記事フィクスチャを用意し、そこにノイズを重ねました。ログイン促進、"Subscribe" の案内、ナビゲーションリンク、著作権フッターといった、素朴なスクレイパーが本文と一緒に拾いがちな定番ボイラープレートです。すると trafilatura は タイトルと本文 3 段落すべて を返し、Login、Subscribe、Copyright の各ボイラープレートはきれいに消えていました。テキストだけでなく、ページメタデータから 著者名と日付 も正しく取得しています。.txt、.md、.json を含む完全な結果は results/local_article.json にあります。

同じ保存済み HTML を、プレーンテキスト、Markdown、JSON として出力しました。ただし、この記事はその 3 形式が 1 回の同時呼び出しから出たとまでは示していません。あくまで抽出パスの別々のシリアライズです。ここでの JSON は、抽出したテキストとメタデータをまとめたもので、ユーザー定義の繰り返しレコードではありません。

以下は最初の実行結果を 1 か所にまとめたものです。主張を確認する際の手がかりにしてください。

各行は trafilatura パック内の artifacts/raw/trafilatura-test-summary.json から読み出したものです。trafilatura 2.1.0、Python 3.14、macOS arm64、1 台のマシンで 1 回だけ実行した結果です。時間はあくまで観測値であり、ベンチマーク値として扱うべきではありません。

500 のフィクスチャでは、近くのローカルエンドポイントが速かった一方、fetch_url は約 30 秒後に None を返しました。ここで分かるのは遅延があったことまでで、再試行やバックオフ、固定タイムアウト、あるいは別の内部経路のどれが原因かまでは分かりません。この記事では fetch_url に対するサポート済みの呼び出し単位タイムアウト引数は確認していません。証拠として示せる制御方法は、呼び出し側で制御できるクライアントで取得し、その HTML を trafilatura に渡すやり方です。

同じテストで、3 つの境界も明らかになりました。

まず最も重要なのは、trafilatura は構造化スクレイパーではなくコンテンツ抽出器 だという点です。商品カタログのフィクスチャにかけると、12 個すべての商品名をテキストとして返し、構造化行はちょうど 0 でした（results/local_catalog_extraction.txt によると 478 文字のフラットテキスト）。価格も $18.00 から $51.00 まで、それぞれ名前の下に独立した行として出ています。欲しい情報は 出力には含まれている のに、どれもフィールドではありません。[{name, price, rating}, …] が必要なら、このツールは向いていません。設定をいくら変えてもそれは変わりません。これは不具合ではなく設計です。

2 つ目は、JavaScript をレンダリングしない ことです。静的 HTML を読むだけです。クライアントレンダリングのページを渡すと、JavaScript 実行前にサーバーが返した内容しか見ません。多くの場合、それは使える情報ではありません。対象が JS だらけなら、別のレンダラーを組み合わせる必要があります。trafilatura がそこまで面倒を見てくれるわけではありません。

3 つ目は、私自身の証拠に関する注意です。最初の公開ページでの抽出テストは、本物のニュース記事ではなく商品説明ブロック を使っていました。というのも、公開サンドボックスにはニュースページがなかったからです。上の「記事のクリーンアップ」結果は、管理されたローカルフィクスチャから得たものです。ボイラープレート除去が明確だったので信頼していますが、商品ページをニュースルーム級の抽出の証拠として盛る気にはなれなかったため、このパックでは未解決ギャップとして扱いました。2026-07-14 の追試でそこは埋まり、結果は次のセクションにあります。

実ページでのボイラープレート確認

実際のページを 2 つ取得し、SHA-256 ハッシュ付きのオフラインフィクスチャとして保存したうえで、ネットワークなしで再実行しました。タイミングもラベル付きの正解データも記録していません。これは実ページのボイラープレート確認であって、忠実度スコアではありません。

2 行とも artifacts/results/trafilatura-fidelity-summary.json 由来です。確認したマーカーは、Wikipedia 側の "Jump to content"、"Privacy policy"、"Powered by MediaWiki"、"This page was last edited"、そして Wikinews 側の "free news source" です。どちらのページでも漏れはなく、きれいに除去されていました。

本文/生の比率は削減量を示すもので、正確さではありません。削られた記事内容は採点していません。これら 2 つの MediaWiki テンプレートでは author と sitename は null でしたが、管理されたローカルフィクスチャでは著者が供給されていました。これはテストで観測された MediaWiki 固有の取りこぼしであり、一般的な著者名抽出の信頼性を示すものではありません。抽出された日付は返り値のまま報告しており、正解データとは照合していません。

同じ HTML バイトを、2 つの抽出器と 1 つのスコアリングスクリプトで比較する

この研究基盤には、trafilatura を同条件で比較したセットが 1 つだけありますが、その比較自体は trafilatura のパックでは作っていません。mozilla-readability のパックが対照群として作成しました。内容忠実度セットは 22 個の手作業ラベル付きフィクスチャで構成され、各テキストブロックは ARTICLE か BOILERPLATE のどちらかにタグ付けされ、さらに各単語には一意のセンチネル・トークンが埋め込まれています。そのため、抽出された単語は必ず 1 つのラベル付きブロックに対応づけられます。両ツールには同じ HTML バイトを与えました。Readability は jsdom 29.1.1 上の Node v22.22.3 で動かし、trafilatura は独自パーサーで動かしました。

出典は、この研究基盤の tools/mozilla-readability/artifacts/raw/comparison.json です。内容忠実度セットは 11 個のフィクスチャ、40 の記事単位、17 のボイラープレート単位で構成されています。これらは意図的に厳しめのケースを多めにした合成フィクスチャなので、実コーパスのランキングではなく、メカニズムの理解用として読むべきです。

どちらのツールも完璧ではありませんし、その差こそが面白いところです。trafilatura は周辺装飾をよりきれいに排除します。Readability の 5 ブロック漏れに対して 1 ブロック漏れ、41 個の汚染トークンに対して 3 個です。これは「きれいな記事テキスト」の精度側に当たりますし、LLM のコンテキスト窓をサイドバーリンクで埋めないかどうかを左右する部分でもあります。一方で Readability は、trafilatura が切り落とす内容を拾い戻します。非本文フィクスチャでは、trafilatura は Readability が保持した <figcaption> を落とし、非常に短い記事では 0.571 対 0.800 でした。強めのクリーンアップは、ただの得ではありません。コーパスが短い断片、キャプション、表やコード中心のページばかりなら、そのトレードオフは不利に働きます。

この比較を、ツール選定テストに変えるには

まず、自分のパイプラインでどちらのエラーが高コストかを決めてください。ページ装飾が下流のトークンを食い潰したり、検索結果を汚したりするなら、ボイラープレート単位の漏れや汚染トークン数を重く見るべきです。逆に、キャプション、短文記事、非本文ブロックを落とすのが許容できないなら、ページ形状ごとの内容再現率を重く見るべきです。共通フィクスチャセットはそのトレードオフを見える化してくれますが、ニュースアーカイブ、ドキュメントコーパス、検索用パイプラインに対する重み付けまでは決めてくれません。

より広いストレステストの文脈は、10 ライブラリのメモリと不正 HTML 比較 にあります。

ベイクオフはライブ URL ではなく保存済み HTML で行い、両方の抽出器に同一のバイト列を渡してください。通常の長文記事、短いお知らせ、キャプションが多い記事、表やコードが多い文書、そして実際に取り込む各発行元のテンプレートを含めます。実行前に、必要なコンテンツ単位と既知の装飾ブロックを少数ラベル付けしておきましょう。そのうえで、空出力、必要単位の回収、不要単位の漏れ、メタデータ項目をそれぞれ別々に採点します。1 つの総合「品質」スコアでは、運用上もっとも重要な失敗モードが隠れてしまうことがあります。

下流側で出力契約も必ず確認してください。trafilatura の JSON には抽出内容とメタデータを載せられますが、JSON 化されたものは型付き行スキーマそのものではありません。記事テキストなら、非空かどうかだけでなく、最低本文長や必須マーカーを確認してください。メタデータは、欠損と誤値を区別し、元 URL と抽出バージョンを残しておくと、見逃しを再現できます。

取得処理は別レイヤーとしてテストすべきです。ローカルでの 30 秒失敗観測は fetch_url に関するもので、すでに手元にある HTML からの抽出ではありません。また、その内部メカニズムも特定していません。締切、再試行、認証、プロキシポリシーが重要なら、挙動を自分で制御できるクライアントを使い、最終レスポンスのバイト列を記録して、それを抽出器に渡してください。こうすると、取得失敗と内容選択失敗を切り分けられ、比較も再現しやすくなります。

最後に、デプロイ特性は実際に使うプラットフォームで測ってください。17 パッケージの Python 3.14 インストールでは別ブラウザは不要でしたが、それだけでスループット、メモリ増加、全アーキテクチャでのホイール可用性、並列ワーカー下の挙動は分かりません。この記事が示しているのは、Readability に対する精度/保持率の有益なメカニズムです。本番適性は、やはりコーパスとランタイムの両方で判断する必要があります。

この基盤の外にある検証としては、trafilatura の公式評価ページ と、公開されている ScrapingHub article-extraction-benchmark の両方で、約 181 の実ページにおける word-F1 が readability-lxml を上回っています。方向性は上の表と同じです。なお、多くの解説で見落とされがちな点として、そこでよく引用される trafilatura の F1（約 0.945）は、ここで試した 2.1.0 ではなく、古い 0.5.1 系に紐づいています。

長所と短所

長所:

• 共通フィクスチャセットで、Readability よりラベル付きボイラープレート漏れが少ない。17 ブロック中 1、Readability は 5。
• ローカルフィクスチャでは著者と日付を正しく取得し、実ページ 2 つでも title / date / hostname を取得できた。
• 同じ HTML をテキスト、Markdown、JSON にシリアライズできる。
• 17 パッケージのインストールで、別ブラウザの実行環境が不要。
• 失敗時は静かで、HTTP 500 では例外を投げずに fetch_url が None を返す。
• 検証した版が最新（2.1.0）なので、バージョン差によるズレがない。
• Apache-2.0 ライセンスで、利用条件が緩く商用でも扱いやすい。

短所:

• 構造化スクレイパーではない。カタログテストでは 12 個の商品名と 12 個の価格をテキストとして返したが、型付き行は 0 だった。スキーマもフィールドもない。
• JavaScript レンダリングはしない。静的 HTML 専用で、クライアントサイドのページには別レンダラーが必要。
• 実ページ 2 つでは author と sitename がどちらも null で、著者情報抽出は保証されない。
• 強いクリーンアップには代償がある。Readability が保持した <figcaption> を落とし、非常に短い記事では Readability の 0.800 に対して 0.571 だった。
• HTTP 500 の静かな失敗でも None 返却まで 30.012 秒かかった。締切制御が重要なら、呼び出し側で制御できるフェッチャーを使うべき。
• 内蔵のクロール / サイトマップ用スパイダーと CSV / XML 出力形式は今回の検証では使っていないため、それらについては断定しない。

どんな人向けか、そして誰が避けるべきか

trafilatura は、記事中心の本文抽出向けです。ヒューリスティックなクリーンアップで十分な、静的 HTML からのテキストコーパス作成、読みやすいアーカイブ、NLP 入力づくりに向いています。共通フィクスチャ比較では Readability よりボイラープレート漏れが少なく、一方で短文や非本文ケースでは Readability の方が多くを残しました。

本当に必要なのが構造化抽出、つまり価格付きの商品行、型付きレコード、key: value 形式のフィールドなら、これは避けてください。返ってくるのはテーブルではなくテキストです（カタログテストでは 12 個すべての商品名と 12 個すべての価格を回収したものの、行は 0 でした）。対象がブラウザで内容を描画するタイプで、別レンダラーを追加したくない場合も避けたほうがいいです。trafilatura は静的 HTML を読んで終わりだからです。また、コーパスの大半が短い断片、画像キャプション、表だらけのページなら、そこがまさにクリーンアップで本物の内容を削ってしまう領域です（非常に短い記事で F1 0.571、<figcaption> の取りこぼし）。ツールは仕事に合わせて選んでください。全文記事テキストなら可、構造化 JSON や JS ページ、100 ワード級の短文なら別の選択肢を。

代替案、Thunderbit の位置づけを含めて

trafilatura は Apache-2.0 のセルフホスト型ライブラリで、ベンダーへの従量課金はありません。コストは計算資源、帯域、取得、監視、保守を運用者が負担します。供給された HTML からの記事向け抽出には対応しますが、ブラウザ実行や、ユーザー定義の繰り返し行スキーマには対応しません。

6 つの抽出器すべてで同じフィクスチャを比べた結果は、6 ライブラリの抽出比較 を参照してください。

マネージドサービスなら、取得、レンダリング、スキーマ整形をベンダー境界の向こう側に置けます。私たちは Thunderbit を開発していますが、今回のフィクスチャでは未実行です。そのため、この記事は品質、レンダリング、レイテンシ、ボット対策、コストの比較を支持しません。選択は、セルフホストで HTML からコンテンツまで制御するか、ホスト型の取得・構造化抽出境界を使うか、という違いです。

関連レビューとして、オープンソース・スクレイパーの総まとめ比較、Crawl4AI のブラウザ対応 Markdown レビュー、Firecrawl のセルフホスト Markdown レビュー もあります。

Thunderbit で Web データ抽出を試す

総評

静的 HTML からの記事中心抽出が仕事で、ラベル付きボイラープレートをなるべく落としたいなら、trafilatura を検討する価値があります。共通フィクスチャでは、注釈付きボイラープレートの漏れが Readability の 5 に対して 1 でした。ただし、その代わりに非常に短い記事と非本文フィクスチャでの保持率は下がったので、コーパスの形状で選ぶべきです。

JavaScript は実行せず、ユーザー定義の繰り返し行も出力しません。2 つの MediaWiki ページでは author と sitename は null で、これはテンプレートに限った観測です。Readability は trafilatura が落としたキャプションを保持し、f3_short_120 とラベルされたフィクスチャでは高いスコアを出しました。ここで見えている証拠が支持するのは「非常に短いフィクスチャで F1 が低い」という点までで、文字数や出力が壊れていたという主張ではありません。

Thunderbit で Web データ抽出を試す Get Started Free

FAQ

trafilatura はどんな構造を返しますか？
抽出した内容とメタデータを JSON、Markdown、テキスト、HTML、XML、CSV としてシリアライズできます。ただし、それは構造化されたシリアライズであって、商品名・価格・評価のようなユーザー定義の繰り返し行スキーマではありません。カタログのフィクスチャでは、値は型付き行ではなくフラットなコンテンツとして返されました。

trafilatura で商品カタログを構造化行にできますか？
いいえ。これはコンテンツ抽出器であって、構造化スクレイパーではありません。カタログのフィクスチャでは、12 個すべての商品名をフラットテキストとして返し、構造化行は 0 でした。名前・価格・評価のような型付きレコードが必要なら、セレクタ駆動のパーサーか、スキーマ駆動の抽出 API を使ってください。

trafilatura は JavaScript をレンダリングしますか？
いいえ。静的 HTML のみを読みます。クライアントレンダリングのページを渡すと、JavaScript 実行前にサーバーが返したものしか見えません。多くの場合、それは欲しい内容ではありません。対象が JS だらけなら、別レンダラーを組み合わせてください。

trafilatura のインストールは難しいですか？
検証した Python 3.14 の virtualenv では、17 パッケージが入り、別ブラウザ実行環境は不要でした。最大ホイールは lxml の 8.6 MB です。別件ですが、ローカルの 500 応答 1 回では None が返るまで 30.012 秒かかりました。期限を厳密に管理したいなら、呼び出し側で制御できる HTTP クライアントを使ってください。

trafilatura は商用利用できますか？
Apache-2.0 ライセンスなので、利用条件は緩く商用利用にも向いています。とはいえ、実装前に必ず repo で最新ライセンスを確認してください。