trafilatura: HTMLから本文とメタデータを取り出すPython製ツールの実力と境界

trafilaturaが埋める穴は「本文だけ」を取り出す作業

HTMLからテキストを取り出すだけなら、正規表現でもBeautifulSoupでも足りる。難しいのは、ナビゲーション、フッター、関連記事、クッキー同意文、コメント欄を落としつつ、本文の段落、見出し、リスト、引用、コードブロックを構造のまま残す作業である。trafilaturaはこの部分を専用のルールベース抽出器として実装し、失敗時にjusTextとreadability-lxmlをフォールバックとして使うとREADMEに記されている。

対象読者は、Web上の記事をまとめてテキスト化したい人である。研究目的のコーパス構築、ニュースの収集、LLMやRAG向けの前処理が想定されている。READMEは、データベースを必要とせず、出力を一般的な形式に変換できる点を「handy and modular」と表現している。抽出対象は本文だけでなく、タイトル、著者、日付、サイト名、カテゴリ、タグといったメタデータ、そして任意でコメント、リンク、画像、表も含む。

発見から抽出までを1つのパッケージに入れた構成

trafilaturaの処理は大きく3段に分かれる。発見、取得、抽出である。発見の段ではサイトマップ(TXT/XML)とフィード(ATOM、JSON、RSS)を読み、URLのフィルタリングと重複排除を行う。取得の段ではURLを並列にダウンロードし、ダウンロード済みのHTMLファイルやパース済みのHTMLツリーも入力として受け付ける。抽出の段で本文とメタデータを取り出し、TXT、Markdown、CSV、JSON、HTML、XML、XML-TEIへ出力する。

この構成の意味は、オンラインとオフラインで同じ抽出経路を使えることにある。一度落としたHTMLをディレクトリに置いておけば、抽出ロジックの調整をネットワークアクセスなしで繰り返せる。抽出器の挙動を変えたいときに、毎回クロールし直さずに済むのは大きい。

出力形式にXML-TEIが含まれる点は、このツールの出自を反映している。READMEによれば、著者の博士課程での言語学とNLPの仕事が出発点で、ベルリン・ブランデンブルク科学アカデミーのDWDSとZDLの研究用テキストデータベースを作るために始まった。TEIは人文系テキストの符号化標準であり、研究用途を想定した設計だと読める。

インストールと最小の呼び出し方

配布はPyPI上のPythonパッケージで、パッケージ名はtrafilatura。READMEが示すPython側の最小例は次のとおり。

from trafilatura import fetch_url, extract downloaded = fetch_url("https://github.blog/2019-03-29-leader-spotlight-erin-spiceland/") extract(downloaded)

メタデータ付きでJSONを得る場合は、extract(downloaded, output_format="json", with_metadata=True)のように引数を渡す。READMEの例では、title、author、textを含むJSON文字列が返る。

CLIも用意されており、READMEとドキュメントではusage-cliのページが案内されている。入力はURLでもローカルのHTMLファイルでもよく、出力形式は引数で切り替える。Rから使うためのusage-rページも用意されている。Python以外の言語から呼びたい場合、CLIを経由するのが現実的な経路になる。

READMEにはインストール手順の詳細は書かれておらず、installationのページを参照する形になっている。pip install trafilaturaが通るかどうか、追加の依存やオプションの扱いは、この資料からは確認できない。導入前に公式ドキュメントのinstallationページを開く必要がある。

精度と再現率のトレードオフは設定で動かす

READMEは抽出器の性格を「limiting noise (precision) and including all valid parts (recall)」のバランスとして説明している。ノイズを減らせば本文の一部を取りこぼし、取りこぼしを減らせばナビゲーションや定型文が混ざる。この調整は設定で動かせる。favor_precisionとfavor_recallというパラメータが用意されている。

どちらを既定にするかは用途で決まる。記事の言及を数える計量分析なら、混入したフッター文が件数を狂わせるのでprecision側に倒す。全文を後段のモデルに読ませるRAGなら、段落が1つ欠けるほうが痛いのでrecall側に倒す。同じtrafilaturaでも、この1つの判断で出力の性格が変わる。

もう1つの調整点はフォールバックの存在である。独自のルールベース抽出器が主で、jusTextとreadability-lxmlが控えている。つまり同じ入力でもサイトの構造によってどの抽出器が効くかが変わる。抽出結果を評価するときは、ツール全体の平均ではなく、自分の対象サイト群での当たり外れを見る必要がある。READMEが参照するベンチマークは複数の研究で最良と報告されているが、それは対象データセット上での話であり、自分のサイトで同じ結果になる保証ではない。

ブラウザで描画されるページには届かない

trafilaturaが扱うのはHTMLである。JavaScriptを実行してDOMを組み立てるブラウザは含まれていない。READMEの機能一覧にもヘッドレスブラウザやレンダリングに関する記述はない。したがって、初期HTMLに本文が含まれないSPAや、スクロールやクリックで内容が読み込まれるページでは、抽出対象がそもそも存在しない。

ログインが必要なページも同様である。fetch_urlはURLを取得する関数であり、認証フローやセッション管理を担うとはREADMEに書かれていない。フォーム送信やページ操作を伴う作業は、このツールの守備範囲外と考えたほうがよい。

クロール機能についても、READMEは「polite processing of download queues」と述べるにとどまり、レート制御やrobots.txtの扱いの詳細はこの資料からは確認できない。自前のクローラを置き換えるつもりなら、その部分はドキュメントで直接確かめるべきである。

もう1つの限界は、抽出がルールベースであることだ。サイトのテンプレートが変わればルールの前提が崩れる。逆に言えば、失敗したときにどのルールが効いたかを追える余地がある。

代替としてのScrapyとBeautifulSoupの分担

比較対象として分かりやすいのはScrapyである。Scrapyはクローリングの枠組みで、スケジューラ、リクエストの再試行、ミドルウェア、アイテムパイプラインを持ち、大規模な巡回とサイトごとの取得制御に向く。本文抽出は利用者が自分で書くか、外部の抽出器を組み込むことになる。trafilaturaは逆で、発見と取得は簡素に済ませ、本文とメタデータの抽出に力を置いている。

BeautifulSoupはパーサであり、抽出器ではない。HTMLを木構造として扱う道具を提供するが、「どこが本文か」は決めてくれない。trafilaturaはその判断をルールとして同梱している。

使い分けの目安はこうなる。サイトごとに細かい取得制御が必要で、本文抽出は自分で設計したいならScrapy。取得は素直でよく、本文とメタデータの取り出しに工数をかけたくないならtrafilatura。両者は排他ではなく、Scrapyで取得したHTMLをtrafilaturaに渡す構成も取れる。trafilaturaがパース済みのHTMLツリーを入力に取れるとREADMEが述べている点は、この組み合わせを想定した作りとも読める。

ライセンスとメンテナンスの見取り図

現行版はApache-2.0。READMEはv1.8.0より前のバージョンがGPLv3+であったと明記している。この境界は、古いバージョンを前提にしたコードや、GPLv3+のまま固定されたフォークを扱う場合に効いてくる。自社製品に組み込むなら、依存しているバージョンがどちら側かを確認する必要がある。ここでは法的助言はできないので、条件の解釈は各自の法務判断に委ねる。

メンテナンスについては、リポジトリはアーカイブされておらず、直近のリリースはv2.2.0、その前がv2.1.0、その前がv2.0.0である。v2.0.0からv2.1.0までが約半年、v2.1.0からv2.2.0までが2か月弱という間隔で、活発に更新されている。アップグレードのコストは、メジャー番号が上がったときに抽出結果が変わる可能性をどこまで許容できるかで決まる。抽出結果を下流のデータセットとして固定している場合、バージョンを上げると過去のデータと新規データで本文の切り出しが揃わなくなることがある。

READMEはスポンサーシップを求めている。著者はこの作業が博士課程のプロジェクトとして始まり、今後の維持はコミュニティの支援に依存すると書いている。業務で依存するなら、この点は導入判断の材料になる。

導入前に自分のデータで確かめるべきこと

最初にやるべきは、対象サイトの代表的なURLを20から30件ほど選び、extract()の出力を人手で読むことである。ナビゲーションの文言が混ざっていないか、逆に本文の段落が落ちていないか。favor_precisionとfavor_recallを切り替えて、どちらが自分の用途に合うかを同じサンプルで比べる。

次に、抽出の再現性を確かめる。同じHTMLを2回渡して同じ結果が返るか、バージョンを上げたときに結果が変わるか。コーパスを長期で積むなら、どのバージョンで抽出したかをメタデータとして残しておくほうがよい。

最後に、取得の層を自前で持つかどうかを決める。JavaScript描画や認証が必要なサイトが対象に含まれるなら、trafilaturaは抽出器としてだけ使い、取得は別の道具に任せる構成になる。READMEが示すとおり、パース済みのHTMLツリーを入力に取れるなら、その分離は無理なく成立する。

編集部の結論

ニュース記事やブログの本文をコーパス化したい研究・NLP・RAG構築の担当者には向く。ブラウザで描画されるSPA、ログインが必要なページ、フォーム送信や操作を伴うスクレイピングには向かない。導入前に確認すべきは、対象サイトでの抽出結果そのもの、v1.8.0より前のGPLv3+と現行Apache-2.0の境界、そしてextract()のfavor_precisionとfavor_recallのどちらを既定にするかである。判断は、trafilaturaが返した本文を人手で数十件読んで、抜けと混入のどちらが自分の用途で痛いかを決めてから下すのがよい。

公式情報源

1. adbar/trafilatura on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases