Firecrawl / Jina Reader / API Pick：URL 抽出 API の選び方
「エージェントに URL リストを読ませて要約させる」を作ったことがあれば、URL クリーンアップ税は必ず踏んでいる。Firecrawl / Jina Reader / API Pick Extract の解法はそれぞれ違う。実用比較。
要点
- •3 社とも URL を LLM 用クリーンテキスト / markdown に変える。違いはバッチ処理、課金モデル、難ページの扱い。
- •全サイトクロール + 構造化抽出を一気通貫で → Firecrawl。
- •プロトタイプ用に <InlineCode>r.jina.ai/<url></InlineCode> 形式 → Jina Reader。
- •LLM エージェントループ内で複数 URL（最大 25）をバッチ処理、従量、成功時のみ課金 → API Pick Extract。
問題：HTML は LLM の食事ではない
典型的なリサーチエージェントのループは：検索 → 関連 URL を選ぶ → 取得 → 要約。3 番目で必ず破綻する。生 HTML はナビ、Cookie バナー、関連記事、広告スクリプトだらけ。これをそのままモデルに入れるとトークンを浪費し、推論品質が落ちる。URL 抽出 API はボイラープレートを剥がし、クリーンなテキスト / markdown を返す。
Firecrawl、Jina Reader、API Pick Extract はどれもこれを行うが、スコープ、操作感、価格設定が異なる。
3 社
Firecrawl
完全な crawl + extract プラットフォーム。単一 URL の scrape、サイト全体の crawl、sitemap ベースの map、schema を渡すと型付き JSON を返す構造化抽出エンドポイント。サイト全体をたどる場合や、成果物が markdown ではなく構造化データ（テーブル、商品、記事）の場合に最適。
Jina Reader
このカテゴリーで「Hello World」が最速。任意の URL の前に https://r.jina.ai/ を付ければ markdown が返る。無料枠は寛大、上限拡張は有料。プロトタイプ、デモ、単発呼び出しに最適。
API Pick Extract
バッチ重視の URL クリーナー。POST /api/extract は 1〜25 URL を受け取り、{ url, title, content, status } 配列を返す。content は markdown 風テキスト。URL 1 件 2 credits、HTTP 200 全体時のみ課金、extract_effort で JS 重ページの処理深度を制御。
横並び比較表
| Firecrawl | Jina Reader | API Pick Extract | |
|---|---|---|---|
| 単一 URL 抽出 | あり（scrape） | あり（r.jina.ai プレフィックス） | あり（1 URL = 1 呼び出し） |
| 1 回のバッチ | scrape は 1 件、crawl はドメイン全体 | 1 件（外部で並列化） | 最大 25 件 |
| 出力形式 | markdown / HTML / JSON / 構造化 | markdown | markdown 風テキスト |
| サイト全体クロール | あり（crawl / map） | — | — |
| JS レンダリング | 対応 | 対応 | 対応（extract_effort） |
| 課金 | サブスク / credit | 無料 + 有料 | 従量課金 credit |
| 失敗時の課金 | プラン依存 | プラン依存 | 全体 HTTP 200 のみ課金 |
| 最適用途 | クロール + 構造化抽出 | プロトタイプ / 単発 | エージェント内バッチ抽出 |
バッチ：見落とされがちな最重要軸
エージェントが 1 度に 1 URL しか読まないなら、バッチ能力は無視してよい。5〜25 URL を読むなら、バッチが他の何より重要 — 1 件ずつ fan out すると、毎回の auth、HTTP コネクション、モデルレイテンシが単一 URL の抽出時間を支配する。
API Pick Extract のバッチ呼び出し：
curl -X POST https://www.apipick.com/api/extract \
-H "x-api-key: pk_yourkey" \
-H "Content-Type: application/json" \
-d '{
"urls": [
"https://en.wikipedia.org/wiki/Retrieval-augmented_generation",
"https://docs.anthropic.com/claude/docs/intro-to-claude",
"https://platform.openai.com/docs/guides/function-calling"
],
"extract_effort": "auto"
}'レスポンス：
{
"results": [
{ "url": "...", "title": "...", "content": "Retrieval-augmented...", "status": "ok" },
{ "url": "...", "title": "...", "content": "Claude is a family...", "status": "ok" },
{ "url": "...", "title": "...", "content": "Function calling lets...", "status": "ok" }
],
"result_count": 3,
"credits_used": 6,
"remaining_credits": 994
}各 URL が独自の status を持つので、部分失敗で全体が止まらない。
「検索 → 抽出」コンボ
本番でよくあるパターン：Web 検索で 5 URL → 抽出でクリーン化 → モデルがクリーン化済みコンテンツで推論。API Pick なら 2 呼び出し、JSON 形式は揃っている：
import requests
KEY = "pk_yourkey"
def research(query: str) -> str:
# 1. 情報源を見つける
s = requests.post(
"https://www.apipick.com/api/search/web",
headers={"x-api-key": KEY},
json={"query": query},
).json()
urls = [r["url"] for r in s["results"]]
# 2. クリーン化
e = requests.post(
"https://www.apipick.com/api/extract",
headers={"x-api-key": KEY},
json={"urls": urls, "extract_effort": "auto"},
).json()
# 3. モデルに渡す
return "\n\n".join(
f"### {r['title']}\n{r['content']}"
for r in e["results"] if r["status"] == "ok"
)純抽出が間違いになるケース
ページから型付きオブジェクト（商品価、ISBN、著者）を取り出したいなら、schema による構造化抽出の方が「markdown を抽出してから regex」より信頼できる — Firecrawl の構造化抽出はそのために存在する。
ドメイン下の全ページをたどりたいなら、必要なのは抽出器ではなくクローラ。Firecrawl の crawl がそれ。API Pick Extract では外部 sitemap ループを自前で組み、バッチで送り込むことになる。
クイック選択
r.jina.ai/<url> はおそらく業界最低摩擦。よくある質問
URL リストを LLM に渡す最良の方法は？
生 HTML を貼らないこと。まず抽出器でナビ / 広告を除いた markdown 風テキストにし、それをコンテキストに入れる。API Pick Extract は 1 回最大 25 URL、{url, title, content, status} 配列を返す。
API Pick Extract は JavaScript をレンダリングする？
する。デフォルト extract_effort=auto は必要時にレンダリング、extract_effort=high は遅いが JS 重 / ペイウォール風ページに強い。失敗 URL は結果オブジェクトの status エラーコードで返り、呼び出し全体は成功扱いになる。
Firecrawl と純抽出器の違いは？
Firecrawl はプラットフォーム：scrape、crawl、map、schema による構造化抽出。サイト全体をたどる、または schema による型付き JSON が必要なら適する。「URL → クリーンテキスト」だけなら純抽出器の方がシンプルで安い場合が多い。
Jina Reader は無料？
r.jina.ai/<url> プレフィックスで寛大な無料枠あり、上限拡張は有料プラン。プロトタイプから動作までが業界最速級。
なぜ呼び出し単位ではなく URL 単位の課金？
URL 単価が労力に対して正直だから。25 URL をクリーンするのは 1 件の約 25 倍の作業量。API Pick Extract は URL 1 件 2 credits、5 URL バッチで 10 credits。HTTP 200 全体時のみ課金されるが、呼び出し内の個別 URL 失敗は作業が発生済みなので課金される。
この記事で使われている API
API Pick の CEO。AI エージェントと LLM ワークフロー向けの本番運用可能な API について執筆。