今年注目を集めているスクレイピングツールの多くは、ブラウザを動かすことを前提にしています。ですが、trafilatura は違います。これは純粋な Python ライブラリで、静的 HTML を読み込み、どの部分が本文かを判定し、それ以外を切り捨てます。この「本文抽出」という役割こそが本質であり、しかもこのライブラリは、まだ「LLM 対応の Markdown」という言葉が一般的になる前から、その仕事をこなしてきました。
私はバージョン 2.1.0 を Python 3.14 上の固定フィクスチャ群で検証しましたが、特に印象に残ったのは記事抽出のテストでした。実際の文章を、ログイン誘導、"Subscribe" の案内、ナビゲーションリンク、著作権フッターといった典型的なページ要素で囲んだところ、trafilatura はタイトル、本文の 3 段落すべて、著者名、日付を返し、そうした定型文の痕跡はきれいに消えていました。ブラウザ不要、サイトごとのルール設定も不要、呼び出しは 1 回だけ。もちろん注意点はあります。構造化データを求めた瞬間、その限界が見えてきます。これは欠点というより設計上の線引きです。詳細は後ほど触れます。
trafilatura とは何か、そして捨ててもいい前提
公式の説明では「Web 上のテキストとメタデータを収集する Python & コマンドラインツール。クロール、スクレイピング、抽出に対応」とされています。CSV、JSON、HTML、Markdown、TXT、XML といった出力形式も用意されています。この説明でも十分広いのですが、実際にこのツールを際立たせている部分は少し伝わりにくいです。価値があるのはクロール補助機能や 6 種類の出力形式そのものではありません。核となるのは コンテンツ抽出 です。HTML を入力すると、本文だけを抜き出し、ページの周辺要素を取り除いてくれます。
このツールの強みと限界を一度に理解するには、こう考えるとわかりやすいです。多くのスクレイパーはセレクタ駆動です。たとえば「product-price クラスの要素を取ってきて」と指示すると、その場所にある値を返します。対して trafilatura は逆の動きをします。文書全体を読み込み、手書きのセレクタではなく、内容のヒューリスティクスを使って、どのブロックが本文でどれが定型文かを 判断 します。だからこそ、一度も見たことのないページでも、サイトごとの設定なしで整えられるのです。逆に言えば、構造化されたカタログは返せません。スキーマもフィールド対応表もなく、内容と見なすかどうかの判断しかないからです。これは「抽出器」であって、狙って使うパーサーではありません。
さらに、かなり軽量です。純 Python で、ヘッドレスブラウザもなければ、キャッシュに chromium のバイナリを抱えることもなく、初回実行で Playwright のインストールに驚かされることもありません。こうした特徴は、数千 URL に対して抽出を回し始めるまでは地味に聞こえるかもしれませんが、依存関係のサイズやサブプロセスの数がそのまま運用負荷になる場面では大きな意味を持ちます。2026-07-09 時点で約 6.26k スターのプロジェクトです (adbar/trafilatura)。ブラウザ系やクローラ系のフレームワークと比べるとずっと小規模ですが、それは品質を下げる話ではなく、スコープを示しているだけです。
セットアップは短い、それ自体が評価ポイント
インストールは 1 行で済み、特に警告すべきこともありません。むしろそれ自体が報告に値します。新しい仮想環境で pip install trafilatura を実行すると、Python 3.14 上で余計なもののないクリーンなパッケージツリーが入ってきました。ブラウザのダウンロードも、インストール後の追加手順も、厄介な依存の連鎖もありません。こういうライブラリを何本も見ていると、次に何か落とし穴が来るのではと身構えてしまいます。初回実行で 150MB のブラウザ一式が降ってくるとか、ネイティブ拡張がビルドできないとか、誰も説明していない [fetchers] グループがあるとか。trafilatura では、そうした“あとから来る厄介さ”はありませんでした。
pip が入れたバージョンは 2.1.0 で、2026-06-07 に公開された最新版と一致しています。つまり、下で述べる数値に「古い版を試しただけでは」という但し書きはつきません。こういうカテゴリでは珍しいことです。重めのツールでは、試した時点ですでに大きなバージョン差があることも少なくありません。その点、ここでは検証版と配布版が同じでした。
実地検証: 抽出器は実際に何を返したか
trafilatura を、得意な領域と限界の両方が見えるフィクスチャで試しました。私の印象を決めたのは、やはり記事抽出のテストでした。
ローカルのアーティクル用フィクスチャに対し、実際の本文をノイズの中へ埋め込みました。ログイン誘導、「Subscribe」の CTA、ナビゲーションリンク、著作権フッターです。素朴なスクレイパーなら本文と一緒に拾ってしまう、まさにその手の定型要素です。trafilatura はタイトルに加え、本文 3 段落を 3/3 すべて返し、Login / Subscribe / Copyright といった定型文の目印は出力から完全に消えていました。さらにページのメタデータから著者名と日付も正しく取得しています。結果は 1 回の呼び出しで .txt、.md、.json の各形式に出力されました。
この複数形式対応は、少し立ち止まって見る価値があります。1 回の抽出で、プレーンテキスト、Markdown、JSON が同時に得られます。特に Markdown 出力は、今まさに皆が追い求めている「LLM 向けテキスト」の工程です。汚れたページを入力し、構造を保ったきれいな文章を取り出してモデルに渡せる。trafilatura はブラウザを一切使わずにそれを実現しています。レンダリング用の巨大スタックを立ち上げるブラウザ系ツールと比べると、ずっと静かな方法で同じ成果にたどり着けます。
次は公開ページでの確認です。Books to Scrape の商品ページを指定すると、1,324 文字のきれいなテキストと Markdown が返ってきました。説明文だけが抜き出され、ページの周辺要素はありませんでした。そして HTTP 500 を返すページを与えたときは、fetch_url は例外を投げず None を返しました。クラッシュもスタックトレースもなし。この地味だけれど正しい失敗の振る舞いは、定期実行のバッチで動かす用途にはまさに欲しいものです。
注意点
注意点は 3 つあります。どれも、このツールの適用範囲を狭めるものです。
まず最大の点は、trafilatura は構造化スクレイパーではなく、コンテンツ抽出器だということです。12 商品のカタログ用フィクスチャで試したところ、12 個の商品名はすべてテキストとして返りましたが、構造化された行は 0 件でした（フラットなテキストは 478 文字）。名前や価格は出力には含まれていますが、フィールドではありません。[{name, price, rating}, …] のような形が必要なら、このツールは選ぶべきではありませんし、設定フラグをいじってもそこは変わりません。これは不具合ではなく、ツールの役割に関する設計判断です。
次に、JavaScript をレンダリングしません。扱うのは静的 HTML だけです。クライアント側で描画されるシングルページアプリに当てると、JS 実行前にサーバーが返したものしか取れません。つまり、たいていの場合は欲しい中身がそこにないのです。対象が JavaScript 多用のサイトなら、レンダラーと組み合わせる必要があります。trafilatura はその部分までは担いませんし、そうすると明言しているわけでもありません。
3 つ目は、私自身の検証方法に関する注意です。上の公開ページでの抽出テストは、実際のニュース記事ではなく商品説明ブロックを使いました。というのも、私が利用した公開サンドボックス（toscrape 系）はカタログばかりで、ニュース記事がなかったからです。きれいな記事抽出の結果自体は、ローカルの制御されたフィクスチャから得たものです。その結果は信頼しています。定型文が消えているのは明白で、再現性もありますが、商品ページがニュースルーム品質の抽出の証明になるわけではないので、そこまで言い切るつもりはありません。
そのギャップを少し埋めるため、別途、あえて採点対象にしないデモとして、実際の記事ページを 2 つ検証しました。保存済みフィクスチャを読み込ませているので、実行は決定的です。Wikipedia の「Web scraping」記事では、trafilatura によって生 HTML の 230,049 バイトが抽出後 26,673 バイトまで圧縮されました（本文/生データ比 0.116）。確認した 4 つのページ装飾マーカー——"Jump to content"、"Privacy policy"、"Powered by MediaWiki"、"This page was last edited"——はいずれも消えていました。アーカイブされた Wikinews の記事では、79,716 バイトから 2,200 バイトに減少し（比率 0.028）、確認した 5 つのマーカーはすべて除去されていました。両方ともタイトル、日付、ホスト名は埋まっていましたが、著者名とサイト名は両方とも null でした。私はこの欠落も隠さずそのまま報告しています。ここで混同しないでほしいのは、このバイト比はどれだけマークアップや周辺装飾が削れたかを示すもので、抽出精度そのものではないこと、そしてどちらのページも同じ MediaWiki 系であるため、これは実在記事のデモではあっても代表的なコーパスではないという点です。
精度については、私の測定ではなく外部の根拠を示します。trafilatura には evaluation page があり、ScrapingHub article-extraction benchmark では readability-lxml（約 0.887）などと比較して、オープンソース中トップの F1（約 0.945）を記録しています。ただし、この数値には 2 つの正直な注釈があります。1 つは、私のテスト結果ではなくそのベンチマーク由来だということ。もう 1 つは、報告されている約 0.945 という値が 2.1.0 ではなく、ソース上では古い 0.5.1 系に紐づいていることです。したがって、これはこのツールが評価されている理由を示す外部ベンチマークとして読むべきであり、このレビューで私が直接測った値として受け取るべきではありません。
長所と短所
長所:
- 私の検証セットでは最もきれいに記事を抽出できた——タイトル、本文 3 段落すべて、定型文（Login / Subscribe / Copyright）を完全に除去。
- 本文と一緒に著者名と日付のメタデータも正しく取得。
- 1 回の呼び出しで txt / Markdown / JSON を出力。Markdown は実用的な LLM 向けテキスト工程。
- 軽量な純 Python インストール——ブラウザ不要、バイナリのダウンロード不要、依存関係の重さも小さい。
fetch_urlは HTTP 500 で例外を投げずNoneを返す、落ち着いた失敗挙動。- テストした版が現行リリース（2.1.0）と一致しており、バージョンずれがない。
- Apache-2.0 ライセンス——緩やかで商用利用にも向く。
短所:
- 構造化スクレイパーではない。カタログテストでは 12 件の名前がテキストで返っただけで、型付きの行は 0 件。スキーマもフィールドもない。
- JavaScript レンダリング非対応——静的 HTML のみ。クライアントサイド描画ページには別レンダラーが必要。
- 一部サイトではメタデータが部分的。実在記事のフィクスチャ 2 つとも、著者名とサイト名が null だった。
- 公開ページでの文章検証は、実ニュース記事ではなく商品説明ブロックを使った。
- 内蔵のクロール / sitemap スパイダーと CSV / XML 出力は今回試していないため、それらについては判断保留。
どんな人向けか、どんな人は避けるべきか
trafilatura がぴったりなのは、「URL はある。ナビバーも cookie バナーもニュースレターの催促もいらないから、きれいな記事本文だけ欲しい」という人です。テキストコーパスを作る、モデルにページを渡す、読みやすいコンテンツをアーカイブする、Web 記事に NLP をかける——そういう用途がまさにこのツールの領域で、非常に強いです。ブラウザ不要で、汚れた HTML をきれいな Markdown や JSON に変える軽量な一手が欲しいなら、入れてそのまま使えばいいでしょう。
逆に、必要なのが構造化抽出なら避けたほうがいいです。たとえば価格付きの商品行、型付きレコード、key: value のフィールドなどです。返してくれるのはテキストであって表ではありません。カタログテストでは名前は拾えましたが行にはならず、その挙動は変わりません。また、対象ページがブラウザ上で描画されるタイプで、別レンダラーを足すつもりがないなら、これも向きません。trafilatura は静的 HTML を読んでそこで止まるからです。失敗の見え方は派手ではありません。空っぽか薄い結果が返ってきて、なぜかと首をかしげることになります。ツールは用途に合わせて選んでください。記事本文なら yes、構造化 JSON や JavaScript 描画ページなら別の選択肢です。
代替案と、Thunderbit が入る位置
まず前提を公平に整理しましょう。trafilatura は無料で、Apache-2.0 ライセンスの、セルフホスト可能なライブラリです。コードは自分で持てますし、ページごとのコストもかかりません。どんなパイプラインにも運用負荷をほとんど増やさず組み込めます。記事をきれいなテキストに削る、という特定の仕事に限れば、この組み合わせは非常に強力で、有料サービスがそれを覆すことはありません。
比較が本当に面白くなるのは、trafilatura が意図的に線を引いている境界です。構造化データと JavaScript、まさにこの 2 つは trafilatura がやらない領域であり、同時にマネージドな抽出 API が吸収するために作られている領域でもあります。そこに位置するのが Thunderbit の開発者向けスタックです。静的 HTML の記事テキストという同じ土俵で trafilatura と競うのではなく、その外側で補完する存在です。/distill エンドポイントは、ページをきれいな LLM 向け Markdown に整えるという点で trafilatura と同じ“形”の仕事をしますが、JavaScript レンダリングはサーバー側で処理されます。これは trafilatura がまさに省いている半分です。一方 /extract は、あなたが定義したスキーマに対して構造化 JSON を返します。これは trafilatura が設計上やらない領域です。カタログが 478 文字のフラットテキストとして返ってきたケースは、まさに /extract を使いたい場面です。AI エージェントやコードアシスタント向けには MCP サーバーもあり、フィールド提案ツールは無料で試せます。さらに、ターミナルや CI、cron 用には npx @thunderbit/thunderbit-cli で CLI も使えます。これは 100,000 人以上が使っている Thunderbit Chrome Extension と同じエンジン上で動いているので、非技術者向けの道もあります。ただしこの読者層にとって重要なのは、API / MCP / CLI のほうでしょう。
つまり、実際のトレードオフはテキスト抽出の品質ではありません。trafilatura は、対象ページに合っている限り、その仕事では勝っています。そこははっきり言えます。違いはスコープと、ブラウザを誰が動かすかです。静的 HTML から、セルフホストで、1 ページごとの費用ゼロで、きれいな記事本文が欲しいなら trafilatura が軽くて鋭い選択です。スキーマ付きの構造化 JSON が必要、あるいはページが JavaScript 実行後にしか表示されないなら、そちらはマネージド側の担当です。trafilatura が戦おうとしている領域ではありません。マネージド側の料金は、1 ページごとのコストと自前レンダラー運用の負担を比べるなら、Thunderbit pricing page を確認してください。
カテゴリ全体で比較したいなら、私は実際に使っている web scraping tools を随時まとめています。このライブラリのようなものを、ブラウザ駆動型やマネージド型の代替と並べて整理しています。
結論
trafilatura は使うべきか？ はい。ただし、やらないことを理解しているなら、です。面倒な HTML をきれいな記事本文へ変換するのが仕事なら、これは十分に有効です。ページからあらゆる定型文を消し、タイトル、本文 3 段落、著者名と日付を、ブラウザなしの軽量インストール 1 回で返してくれました。txt、Markdown、JSON をまとめて出力できるので、実際に使える LLM 向けテキスト工程と言えます。何をするにもヘッドレスブラウザや AI クローラが必要だと思われがちな今、この「ブラウザを開かない」ツールが、私にとって重要な整形をやってのけました。
ただし、役割は正しく見積もるべきです。これは抽出器であって、構造化スクレイパーではありません。カタログは 12 件の名前と 0 件の行として返ってきました。静的 HTML は読めますが、JavaScript は実行しません。メタデータ抽出はページによって強く効くこともあれば部分的なこともあります（私が確認した実在記事のフィクスチャ 2 つでは、著者名とサイト名が null でした）。そして公開ページでの文章テストは、実ニュース記事ではなく商品説明ブロックに依存していたので、ニュースルーム品質の抽出については「有望だが未確定」と捉えるのが妥当です。この線の内側では、trafilatura は私が比較した重いツールよりも、その 1 つの仕事をずっときれいにこなし、しかもほとんど何もインストールせずに済みます。
Web データ抽出に Thunderbit を試す Get Started Free
よくある質問
trafilatura はページから何を実際に抽出しますか？ 本文が中心です。記事本文に加えてタイトル、著者名や日付などのメタデータを、定型文を除いた形で抽出します。私のテストでは、ナビゲーション、ログイン、購読誘導、著作権表示に囲まれたページから、タイトルと本文 3 段落すべてを返し、それらのノイズは一切出力に残りませんでした。どの部分がコンテンツかはヒューリスティクスで判断するため、初見のページでもサイトごとのセレクタ設定は不要です。
trafilatura で商品カタログを構造化行にできますか？ できません。これは構造化スクレイパーではなく、コンテンツ抽出器だからです。12 商品のカタログ用フィクスチャでは、12 個の商品名がフラットなテキスト（478 文字）として返っただけで、構造化行は 0 件でした。名前 / 価格 / 評価のような型付きレコードが必要なら、セレクタベースのパーサーか、スキーマ駆動の抽出 API を使ってください。
trafilatura は JavaScript をレンダリングしますか？ しません。静的 HTML のみを扱います。クライアント側描画のページに当てると、JS 実行前にサーバーが返した内容しか取得できません。欲しい情報がそこで初めて出るサイトなら、別のレンダラーと組み合わせる必要があります。trafilatura は静的文書を読んで終わりです。
trafilatura のインストールは難しいですか？
いいえ。むしろそれが大きな強みの 1 つです。Python 3.14 の新しい仮想環境で pip install trafilatura を実行したところ、クリーンなパッケージ一式が 1 つ入るだけで、ブラウザのダウンロードも、インストール後の追加手順も、隠れた extras グループもありませんでした。pip が入れたバージョンは 2.1.0 で、2026-06-07 公開の現行リリースと一致しています。
他の抽出器と比べて trafilatura の精度はどうですか？ このレビューでは精度そのものはベンチマークしていないので、外部の根拠を示します。trafilatura には evaluation page があり、ScrapingHub article-extraction benchmark では readability-lxml（約 0.887）などと比べて、オープンソース中トップの F1（約 0.945）を報告しています。ただし、この数値は私のテストではなく、そのベンチマーク由来であり、しかも 2.1.0 ではなく古い 0.5.1 系に結びついたものです。したがって、このレビューで測った値ではなく、このツールが高く評価される理由を示す外部証拠として読むのが正しいです。
