Jina は 開発者・プラットフォームチーム が RAG の検索＋リランキング＋LLM向けWeb読み取り を、明確な上限とトークン課金で運用したいときに堅実な選択肢です。n8n/Zapier に差し込める“検索レイヤー”として強みがあります。一方で、価格の細部は課金UI側での確認が必要になりやすく、品質は評価設計に左右されます。
好きなポイント
- 運用設計に必要な上限（RPM/TPM/同時数）が明確
- Reader/Embeddings/Rerank を 1 つのキーで統合利用
- RAG と Web グラウンディングの相性が良い
注意点
- 金額の見通しは課金UIでの確認が必要になりがち
- 評価基盤は必須。リランキングだけで品質は保証できない
- OSS 自前運用はインフラ負荷が増える
について
Executive Summary: Jina は、埋め込み（Embeddings）・リランキング（Rerank）・LLM向けWeb Reader を API として提供する検索基盤です。RAG、社内検索、URL→クリーンテキスト変換のパイプラインを作る開発チーム向けで、トークン課金と明確なレート制限で運用設計がしやすいのが強みです。
Jina は 1 つの API Key で Search Foundation 機能を横断利用でき、Embeddings でベクトル化、Reranker で精度改善、Reader で URL をモデル入力に適したテキストへ整形できます。
計画に使える数値：新しい API Key には 1,000,000 の無料トークン（非商用）が付与され、より大きなトークン束（例：1B / 11B トークン）でトップアップ可能です。さらに、Free（100 RPM / 100K TPM / 同時 2）、Paid（500 RPM / 2M TPM / 同時 50）、Premium（5,000 RPM / 50M TPM / 同時 500）という段階的な上限に加え、IP ベースで 60 秒あたり 10,000 リクエストの制限があります。
料金：Jina は Free プランがあり、有料は 1B トークン（トップアップ）から開始します。このカテゴリでは平均的なコスト感です。
活用パターン：Reader を前処理として使い RAG に接続、または n8n / Zapier で自動化、LangChain でアプリ実装を高速化。
主な機能
- ✓Reader API：URL→LLM向けクリーンテキスト
- ✓Embeddings＋Rerank を 1 つのキーで利用
- ✓段階的なレート制限（RPM/TPM/同時数）
- ✓トークントップアップで従量拡張
よくある質問
結論は運用の安定性です。Jina の Reader は URL を一貫した形で LLM 向けテキストに正規化する設計で、DIY は HTML 例外や反ボットで破綻しがちです。小規模なら DIY が安い場合もありますが、本番では Jina の明確な上限のほうが扱いやすいです。
Jina は新規キーで 1,000,000 の無料トークン（非商用）を提供し、Free では 100 RPM / 100K TPM / 同時 2 などの上限があります。有料では 500 RPM / 2M TPM / 同時 50、Premium では 5,000 RPM / 50M TPM / 同時 500 と拡張され、API 横断で IP ベース 10,000 リクエスト/60 秒の制限もあります。
埋め込みで広めに候補を取って（ベクトルDBで大きめの top-K）、その後リランキングで再スコアして LLM に渡す候補を絞るのが基本です。埋め込みは再現率、リランキングは精度に寄るため、「広く取って、狭く整える」が定石です。
よくあるのは「範囲が広く複雑」という点です。フレームワーク/クラウド/API が混在するため、入門者はドキュメントや導線が重く感じやすく、オンボーディングや例の充実を求める声が出がちです。対策は Reader か埋め込みのどちらか 1 つに絞って小さく成功させ、段階的に広げることです。
はい。API ファーストでトークン計測のため、イベント駆動の自動化（新URL→Reader→保存→埋め込み→検索→リランキング）に素直に組み込めます。重要なのは、トークン上限やリトライ回数などの予算ガードレールを必ず入れることです。
一般的な外部 AI API と同様に扱うのが安全です。秘密情報は送らない、キーをローテーションする、入力データを最小化する。機微データはマスキングを徹底し、可能なら OSS を自前運用して VPC 内に閉じる設計も検討してください。
予算設計とキャッシュが重要になります。Reader の結果は積極的にキャッシュし、URL の重複排除、更新されていないコンテンツの再埋め込みを避ける。大きな束で心理的摩擦は下がりますが、幂等なパイプライン設計でリトライによる消費増を防ぐのが本質です。