jina-ai/reader を採用する前に確認すべきこと
Convert any URL to an LLM-friendly input with a simple prefix https://r.jina.ai/
ひと目でわかる
- これは何？
- URL の先頭に https://r.jina.ai/ を付けるだけでページを LLM 向けテキストに変換する Reader について、README とリポジトリ構成から読み取れる仕組み、動かし方、そしてオープンソース版に何が含まれていないかを整理する。
- 誰に向いている？
- Reader が向くのは、エージェントや RAG の入力前処理を自前で書きたくないチームだ。r.jina.ai と s.jina.ai をそのまま叩けば、ヘッドレス Chrome の起動も PDF.js の組み込みも不要になる。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 117 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
r.jina.ai が埋めるのは「HTML をそのまま渡すと崩れる」という隙間
LLM に Web ページを読ませようとすると、生の HTML を渡した時点でナビゲーション、広告、スクリプトが本文に混ざる。かといって自前でパーサを書くと、JavaScript で描画されるページ、PDF、Office 文書をそれぞれ別の経路で処理することになる。Reader はこの前処理を URL の書き換えに畳み込む。README の表現では、任意の URL を LLM フレンドリーな入力に変換する、というのがその役割である。対象は本文を読ませたいエージェント開発者と RAG の構築者で、検索側の s.jina.ai は「最新の世界知識」をモデルに渡したい場合を想定している。
入力の種類ごとに処理系が分かれている
README の What Reader can read の節を読むと、内部が単一のパーサではないことが分かる。Web ページはヘッドレス Chrome でレンダリングするか、curl-impersonate で軽量に取得するかを Reader 自身が選ぶ。PDF は PDF.js、Word・Excel・PowerPoint は LibreOffice で変換したうえで HTML か PDF として扱う。画像は vision-language model でキャプションを付ける。つまり「URL を渡せばテキストが返る」という単一の入口の裏に、少なくとも 4 系統の変換経路がある。自前で同じことをするなら、この分岐と各系の依存を保守し続けることになる。ここが Reader をラッパーとして使う最大の理由であり、同時にセルフホスト時の重量物でもある。
s.jina.ai は検索結果の本文まで取りに行く
検索側の設計は、一般的なエージェントフレームワークの function calling とは異なると README は説明している。多くの実装は検索エンジン API が返すタイトル、URL、説明文だけを返し、本文が必要なら呼び出し側がその URL を取得する。s.jina.ai は検索を実行した後、上位 5 件の URL を訪れてそれぞれに r.jina.ai の処理を適用する。つまり検索と本文取得が 1 リクエストに統合されている。サイトを絞る場合はクエリパラメータで指定する。README の例は curl 'https://s.jina.ai/When%20was%20Jina%20AI%20founded%3F?site=jina.ai&site=github.com' である。site を複数並べられる点は、特定ドメインだけを根拠にしたい RAG で効く。
出力形式は x-respond-with ヘッダーで切り替える
既定のレスポンスは Title: と URL Source: という独自のヘッダー形式のプレーンテキストだが、x-respond-with で変更できる。markdown は readability を通さない markdown、html は documentElement.outerHTML、text は document.body.innerText、screenshot はビューポートの画像 URL、pageshot はページ全体を撮ろうとする。frontmatter を指定すると YAML フロントマター付きの markdown になり、README には title、description、url を持つ例が載っている。markdown+frontmatter はそのページ全体版である。README は「最も有用ないくつか」を挙げるに留め、既定値と検証規則の完全な一覧は https://r.jina.ai/docs、実装上の正は src/dto/crawler-options.ts だと明記している。パラメータの挙動を追うときは後者を読むほうが確実だ。
OSS 版には MongoDB レイヤーが入っていない
このリポジトリは SaaS のコードベースのオープンソース枝であり、r.jina.ai と s.jina.ai の背後で動いているものの一部である。README の引用では、stateless かバケットキャッシュのモードで動き、MongoDB を使う SaaS のストレージ層はここに含まれない。2026-04 の更新でも、SaaS コードとの再同期に際して MongoDB 層が取り除かれ、OSS 枝は stateless で動き、任意で MinIO/S3 互換のバケットキャッシュを docker compose 経由で使うと書かれている。2025-03 には Firebase アプリケーションではなくなり、Firestore と Cloud Functions から Cloud Run イメージと MongoDB Atlas へ移行したという経緯も記されている。つまり SaaS と OSS 版は同じ変換ロジックを共有していても、状態の扱いが違う。セルフホストを選ぶ動機が「データを外に出したくない」であれば、この差分はむしろ都合がよい。動機が「SaaS と同じ挙動を再現したい」であれば、そのままでは一致しない部分があると考えるべきだ。
ローカルで動かす場合の入り口
README が示す最短経路は、ローカル開発の節と docker compose である。バケットキャッシュを使う構成も docker compose 経由で立ち上げる。文書のアップロードは 2025-12 の更新で追加され、PDF と MS Office 文書を file ボディフィールドで直接 POST できる。ホスト先を用意する必要はない。詳細な手順と例は cookbooks.md の PDF, MS Office and raw HTML uploads の節にまとまっている。API のパラメータを試す用途では、ホームページの Interactive Code Snippet Builder を使うほうが早い。ヘッダーの組み合わせを手で書くより、生成されたリクエストをそのまま curl に落とせる。
無料であることと、依存を引き受けることは別の話
README は本番利用について、無料で安定してスケーラブルであり、Jina AI の主要製品のひとつとして活発に維持していると述べ、料金ページへのリンクを添えている。ここで注意したいのは、無料である根拠が「自社運用の SaaS である」ことに依存している点だ。レート制限の実際の値は README には書かれておらず、https://jina.ai/reader#pricing を読む必要がある。セルフホストに切り替えればレート制限からは離れられるが、代わりにヘッドレス Chrome と LibreOffice を抱えたイメージの運用、そして PDF や Office 文書の変換品質の追跡が自分の側に来る。可用性の責任も同様に移動する。どちらを取るかは、変換品質の変化を自分で検知できるかどうかで決めるのが現実的だ。
Firecrawl との違いは、状態を持つかどうか
比較対象として自然なのは Firecrawl である。どちらも URL を LLM 向け markdown に変換し、クロールと検索を提供する。差が出るのは状態の扱いだ。Reader の OSS 版は README の記述どおり stateless かバケットキャッシュで動き、ジョブの永続化やクロールの進捗管理をリポジトリ内に持たない。Firecrawl はクロールジョブを管理する側に重心があり、サイト全体を辿って結果を蓄積する使い方を想定している。単発の URL 変換や検索上位数件の本文取得が目的なら Reader のほうが軽い。数千ページのサイトを継続的に追跡し、途中状態を保持したいなら、状態を持たない Reader の OSS 版はその用途に向かない。SaaS 側を使うか、別の道具を選ぶ判断になる。
ライセンスと保守コスト
ライセンスは Apache-2.0 で、リポジトリのメタデータに記載がある。商用利用や改変を含む条件の解釈はここでは扱わない。保守の観点で見ておきたいのは、この枝が SaaS 本体から切り出されたものであり、2026-04 に再同期されたという履歴だ。上流との差分を追う作業が発生しうる。依存も軽くはない。ヘッドレス Chrome、curl-impersonate、PDF.js、LibreOffice、画像キャプション用のモデルが変換経路ごとにぶら下がる。リリースは取得できておらず、バージョン番号で更新を追う手段は確認できていない。追跡するなら main のコミットと README の Updates 節を読むことになる。
編集部の結論
Reader が向くのは、エージェントや RAG の入力前処理を自前で書きたくないチームだ。r.jina.ai と s.jina.ai をそのまま叩けば、ヘッドレス Chrome の起動も PDF.js の組み込みも不要になる。逆に向かないのは、取得先や保存先を完全に統制したい場合である。このリポジトリの OSS 版は MongoDB ベースのストレージ層が外され、stateless か MinIO/S3 互換のバケットキャッシュで動く構成だと README に明記されている。採用前に確認すべきは 2 点で、第一に https://r.jina.ai/docs と src/dto/crawler-options.ts のどちらが自分の用途で正なのか、第二に docker compose で立ち上げた OSS 版が SaaS と同じ変換結果を返すのかである。無料枠の範囲は https://jina.ai/reader#pricing に書かれているので、そこを読んでから本番の流量を決めればよい。
コミュニティノート