リランクモデル（リランカー）とは？種類・2026年の代表モデルと選び方

リランクモデル（リランカー、リランキングモデル）は、ベクトル検索や全文検索が集めた候補文書を、クエリとの関連度で並べ替え直すモデルです。一段目の検索が速さを優先して広く候補を拾い、リランクモデルがその上位数十件だけを精密に採点し直す、という二段構成で使います。RAGでLLMへ渡す文書を選ぶ工程に入れるのが代表的な使い方です。この記事では、仕組みと方式・提供形態、2026年10月時点の代表モデル（Cohere Rerank 5、Voyage rerank-3、Qwen3-Reranker、日本語向けのRuri-v3など）、料金の考え方、Pythonでの実装までを一次情報で整理します。

まとめ：リランクモデルの要点と選び方の結論

• 役割：一段目の検索が返した上位50〜100件を、クエリと文書のペアで読み直して順位を付け直す二段目の処理です。全文書には使いません。
• 方式と提供形態：採点の方式はクロスエンコーダが主流で、ほかに遅延相互作用（ColBERT）とLLMを土台にした型（Qwen3-Reranker、Jina Reranker v3.5）があります。これとは別の軸で、自前で動かすかAPIで呼ぶかを選びます。
• 2026年10月の現行モデル：APIはCohere Rerank 5（10月21日公開）とVoyage rerank-3が最新です。Zerank-2を出していたZeroEntropyは、2026年9月4日でAPIの提供を終えました。
• 日本語：自前で動かすなら、日本語の評価セットJQaRAの公開比較表で最も高い値のRuri-v3-reranker-310m（Apache 2.0）か、CPUでも速いjapanese-reranker-v2系（MIT）から試すのが近道です。
• 入れない判断：一段目のRecall@kが低いなら、リランカーを足しても正解は上がってきません。先に一段目を直してください。

リランクモデルの仕組み：一次検索の候補を並べ替え直す二段目

一段目のベクトル検索は、クエリと文書を別々にベクトルへ変換し（バイエンコーダ）、事前に索引化した文書ベクトルとの距離で候補を取ります。文書側を前もって計算して索引に載せておけるので、件数が増えても検索時の計算を小さく抑えられます。代わりに、クエリと文書の語どうしの対応までは見ていません。ベクトル検索そのものの仕組みはベクトル検索とセマンティック検索の違い、索引の構造はベクトルDBの仕組みと製品比較で扱っています。

主流のクロスエンコーダ型のリランクモデルは、クエリと候補文書を組にしてモデルへ入れ、文書ごとに関連度スコアを出します。語どうしの関係まで見るので並び順の精度が上がりやすい反面、候補100件ならクエリと文書の組を100組採点します。バッチでまとめて流すことはできますが、計算量は組の数に比例して増えます。このため、一段目で候補を絞ってから上位だけに使う順番が前提になります。一段目を含めた検索工程全体の設計と、候補件数の決め方はリトリーバルの工程と精度改善の判断基準にまとめています。

ハイブリッド検索のRRFとリランクの違い

BM25とベクトル検索を併用するときに使うRRF（Reciprocal Rank Fusion）は、2つの順位リストを順位の逆数の和でまとめる計算式です。文書の中身は読まず、リランクモデルは中身を読んで採点し直します。RRFで統合した上位をさらにリランクする、と重ねる構成もよく使われます。RRFの式と定数k=60の意味はRRF（Reciprocal Rank Fusion）の解説、統合方式の比較はハイブリッド検索の仕組みと実装コードを参照してください。

リランクモデルの方式と提供形態の比較：クロスエンコーダからLLM型、APIまで

採点の方式（クロスエンコーダ・遅延相互作用・LLM型）と、提供形態（自前で動かすかAPIか）は別の軸です。方式どうしも重なり、Qwen3-RerankerはLLMを土台にしながらクエリと文書を組で読むクロスエンコーダとしても使えます。たとえばCohere Rerank 5は非公開の独自モデルをAPIで提供しており、2つの軸が重なります。表では読みやすさのため1行ずつに並べています。

クロスエンコーダ型：精度と扱いやすさの標準

クエリと文書を1本の入力につないでTransformerに通し、関連度を1つ出します。文書側を事前に計算できないぶん重くなりますが、sentence-transformersのCrossEncoderで数行で動き、日本語モデルも揃っています。最初の1本はこの型から選んで問題ありません。連結入力の中身、候補件数・トークン長の初期値、自前学習に踏み切る条件はクロスエンコーダの仕組みと判断基準で詳しく扱っています。

遅延相互作用型（ColBERT）：速度と精度の中間

文書をトークン単位のベクトル列として事前に保存し、検索時にクエリの各トークンと最も近い文書トークンの類似度を足し合わせます（MaxSim）。クロスエンコーダより速く、バイエンコーダより細かく比べられます。ただし、トークンごとにベクトルを持つので索引が大きくなります。採点手順と採否の線引きはColBERTの仕組みとRAGへの導入判断で整理しています。

LLM型：Qwen3-RerankerとJina Reranker v3.5

2025年以降に増えた型で、小型LLMを土台にリランク用に学習したモデルです。Qwen3-Reranker（0.6B・4B・8B、Apache 2.0、2025年6月5日公開）は、クエリと文書を見せて関連するかをyes/noで答えさせ、その確率をスコアにします。入力長は32kトークンで、Instructとしてタスクの説明を添えられます。公式の評価表（Qwen3-Embedding-0.6Bで集めた上位100件を並べ替えた条件）では、多言語の検索評価MMTEB-Rが0.6Bで66.36、bge-reranker-v2-m3は58.36でした。

jina-reranker-v3.5（0.6B、2026年7月公開）は、候補をまとめて1回の推論で並べるlistwise型で、131Kトークンまで入ります。ただし公開されている重みのライセンスは非商用に限るCC BY-NC 4.0で、モデルカードは商用利用を問い合わせ窓口へ案内しています。商用で使うなら、Jinaに利用条件を問い合わせるか、JinaのAPIを使うか、Apache 2.0のQwen3-Rerankerを選びます。

2026年10月時点の代表モデルとクラウド各社のリランク機能

マネージドAPIはGPUの運用が要らない代わりに、文書を社外へ送ります。送れない文書があるなら、後半のオープンモデルを自前で動かします。この分野は2026年の9月と10月だけでも提供終了と新版公開が続いたので、モデルIDは公式ドキュメントでも確かめてください。

マネージドAPI：Cohere Rerank 5とVoyage rerank-3

Cohere Rerank 5はProが約20億、Fastが約5億パラメータで、日本語を含む100以上の言語に対応します。新しい機能が2つあります。1つは、文書の中で関連の強い箇所を文字位置付きで返すContext Focus（relevant_spans）です。LLMへ渡すトークンを減らせます。もう1つは、0〜1に較正されたスコアです。クエリをまたいで同じしきい値で足切りできます。一方で、関連度の判断基準を指示文で変える機能は対象外と明記されています。Cohereの公開記事によると、Rerank 5のAPI単価はProが100万トークンあたり0.05ドル、Fastが0.02ドルです。1回のリクエストで最大10,000文書を渡せ、長い文書はmax_tokens_per_doc（既定4,096トークン）で切り詰められます。同じ記事では、日本語の評価でProがVoyage rerank-3を2.7ポイント上回ったとしています（Cohere自身の評価です）。旧版のrerank-v4.0-pro／fastもAPIに残っていますが、公式は新規利用にv5.0を勧めています。

Voyage AIの現行はrerank-3とrerank-3-liteで、2025年8月公開のrerank-2.5系は旧モデルの扱いになりました。料金はトークン単位で、計算式は「クエリのトークン数×文書数＋全文書のトークン数」です。公式の試算では、100文書でクエリと各文書の合計が500トークンなら、rerank-3で1リクエスト約0.0025ドルです。100万リクエストなら約2,500ドルになります。rerank-3系は最初の2億トークンが無料です。

ZeroEntropyはNotionに買収され、2026年9月4日で全製品の提供を終えました。新規登録もできません。zerank-2の重みはApache 2.0でHugging Faceに公開されているので、使い続けるなら自前で動かすことになります。

クラウド各社のリランク機能：Bedrock・Vertex AI・Azure AI Search

すでに使っているクラウドの中で完結させたい場合の選択肢です。

Amazon BedrockのRerank APIで選べるのは、2026年10月時点でAmazon Rerank 1.0とCohere Rerank 3.5の2つです。CohereのRerank 4・5はBedrockの対象表に載っていないため、最新版を使いたいならCohereのAPIかSageMaker経由になります。Vertex AIのranking APIは、2026年9月1日に公開されたsemantic-ranker-default-005とfast-005が最新のエイリアス（@latest）の参照先で、25言語・1件1,024トークンまで扱います。Azure AI Searchのセマンティックランカーは、検索結果の上位50件だけを並べ替える仕様です。どの価格レベルでも月ごとの無料枠付きのFreeプランで使え、無料枠を超えて従量課金のStandardプランへ切り替えるにはBasic以上の価格レベルが必要です。

自前で動かすオープンモデルとライセンスの確認点

商用サービスに組み込むなら、まずライセンスで候補を絞ります。CC BY-NCのモデルは非商用に限られるため、商用では候補から外すか提供元と別に契約します。BAAIの後継に当たるbge-reranker-v2.5-gemma2-lightweightは、Gemma 2 9Bを土台に層の削減とトークン圧縮で軽くしたモデル（BAAIの一覧では2.72B）で、Gemmaのライセンスに従う必要があります。

日本語で使うリランクモデルの選び方：JQaRAのスコアと速度

日本語の検索評価セットJQaRA（nDCG@10）での公開値を並べると、この比較表の範囲では、日本語で学習した上位モデルが多言語向けのbge-reranker-v2-m3を上回っています。数値はjapanese-reranker-tiny-v2のモデルカードの比較表から引きました。速度は同じカードの、約15万ペアをRTX 5090（flash-attention2使用）で処理したときの推論時間で、トークナイズの時間は含みません。

精度を最優先するなら、名古屋大学のRuri-v3-reranker-310mが第一候補です。ModernBERT-Jaを土台にした315Mパラメータのモデルで、8,192トークンまで入ります。多言語向けのbge-reranker-v2-m3（568M）より小さいのに、JQaRAでは約0.2高い値です。

CPUしか使えない、あるいは応答時間が厳しいなら、japanese-reranker-v2系です。tiny-v2は3層・29.4Mパラメータと小さく、カードではM4 MaxのCPUで約15万ペアを702秒で処理しています。手元のIntel Mac上のDocker（CPU、torch 2.15.0）で、max_length=512とし、8ペアで一度ウォームアップしてから、短い日本語文4件を繰り返した100ペアをbatch_size=32で1回採点したところ、tiny-v2は0.43秒、Ruri-v3-310mは11.87秒でした。この環境と条件では、応答に数百ミリ秒しか使えない構成にRuri-v3をCPUのまま載せるのは難しく、GPUを使うかtiny-v2・xsmall-v2を選ぶことになります。旧世代のcross-encoder-v1系のスコアと、候補件数・トークン長の調整手順はクロスエンコーダの解説に載せています。

Pythonでリランクを実装する：sentence-transformersのCrossEncoder.rank

自前で動かす最短の方法は、sentence-transformersのCrossEncoderです。rank()にクエリと候補を渡すと、スコアの降順に並んだcorpus_id（元の並びの番号）とscoreが返ります。次のコードは、sentence-transformers 6.2.0・transformers 5.21.0・torch 2.15.0（CPU版）で実行し、結果をコメントに書いています。

from sentence_transformers import CrossEncoder

query = "RAGで検索した文書を関連度順に並べ替え直すモデルは？"
docs = [
    "BM25は単語の出現頻度と文書長から関連度を計算する全文検索のスコアです。",
    "リランカーはクエリと文書をペアで読み、関連度スコアを付け直して順位を入れ替えます。",
    "東京の明日の天気は晴れのち曇りの予報です。",
    "埋め込みモデルは文章を固定長のベクトルに変換し、近さで類似文書を探します。",
]

# 日本語で学習した小型リランカー（3層・29.4Mパラメータ）
model = CrossEncoder("hotchpotch/japanese-reranker-tiny-v2", max_length=512)

for r in model.rank(query, docs):
    print(round(float(r["score"]), 4), r["corpus_id"])
# 0.0464 1  ← リランカーの説明文が1位
# 0.0142 3
# 0.0012 0
# 0.0003 2  ← 天気の文が最下位

モデル名をcl-nagoya/ruri-v3-reranker-310mに替えても同じコードで動き、並び順は同じく1・3・0・2でした。注意したいのはスコアの値です。同じ1位でもtiny-v2は0.0464、Ruri-v3は0.0188で、モデルごとにスコアの幅が違います。並べ替えに使う分には問題ありませんが、しきい値で足切りするなら、使うモデルで正解と不正解のスコア分布を測ってから値を決めてください。rank()は出力が1つ（num_labels=1）のモデルでだけ使えます。分類用の多クラスモデルを渡すとエラーになります。

RAGへ組み込むときは、並べ替えた上位の数件だけをLLMへ渡します。評価の出発点は3〜5件とし、複数の文書をまたいで答える質問が多い場合やチャンクが短い場合は増やして、回答の評価で決めます。関係の薄い文書を大量に渡すと、回答の精度が下がることがあるためです。長いコンテキストで中ほどの文書が無視されやすい現象と対策はLost in the Middle現象の解説にまとめています。

リランクの効果を測る評価指標：nDCG@10・MRR・Recall@k

検索エンジンやRAGの並び順は、次の3つの指標で導入前と導入後を比べます。

• nDCG@10：上位ほど重みを付けて関連度を足し、理想の並びで割って0〜1にした値です。3段階・4段階の関連度を扱えるので、リランクの評価ではこれが主指標になります。
• MRR：最初の正解が何位に来たかの逆数を平均した値です。正解が1件のFAQ検索に向きます。
• Recall@k：正解の文書のうち、上位k件に入った割合です。リランク後の上位にも使えますが、主に一段目が候補を取りこぼしていないかを見るのに使います。

判断の目安は、Recall@50とnDCG@10を並べることです。Recall@50が高いのにnDCG@10が低ければ、候補は取れているのに並びが悪い状態で、リランクが最も効きます。Recall@50自体が低いなら、リランクでは直りません。評価用のクエリと正解の作り方、生成側の指標まで含めた評価の組み方はRAG評価の指標とRagasでの実装で解説しています。

レイテンシと料金を抑える設計：候補件数とモデルの大きさ

リランクの費用と遅延は、ほぼ「候補件数×1件あたりの推論コスト」で決まります。下げる順番は次のとおりです。

1. 候補件数を減らす：100件から50件、20件へ下げて、nDCG@10が落ち始める手前で止めます。正解を取りこぼさない最小の件数は、一段目のRecall@kを見て決めます。
2. 小さいモデルに替える：APIならrerank-v5.0-fastやrerank-3-lite、自前ならjapanese-reranker-xsmall-v2やQwen3-Reranker-0.6Bです。CohereはRerank 5 Fastが旧世代のRerank 4 Proを上回ると発表しています。
3. 文書を短く切る：Cohere Rerank 5もVoyageもトークン単位の課金です。Voyageは「クエリのトークン数×文書数＋全文書のトークン数」で数えるため、チャンクとクエリを短く保つことがそのまま節約になります。
4. 月間の件数で自前とAPIを比べる：Voyage rerank-3で1リクエスト0.0025ドルなら、月100万リクエストで約2,500ドルです。この額が、同じ処理量をさばくGPUサーバーの費用（冗長化の台数と運用の人手を含む）を上回るなら、自前で動かす案を試算します。

リランクモデルを選ぶ判断基準と入れないほうがよい場面

選び方は、データを外に出せるかで最初に分かれます。

データを外に出せて、運用の人手が少ない場合は、Cohere Rerank 5かVoyage rerank-3を選びます。日本語の精度を自社データで比べ、高いほうを使ってください。AWSの中で完結させたいならBedrockのCohere Rerank 3.5、Azure AI Searchを使っているならセマンティックランカーが最短です。BedrockのCohereはRerank 5より前の世代なので、Azureも含めて自社の評価セットでAPI直利用と精度を比べてから決めてください。

データを外に出せない、または件数が多くAPI料金が重い場合は、自前で動かします。日本語中心ならRuri-v3-reranker-310m、CPUで動かすならjapanese-reranker-v2系、多言語が混ざるならQwen3-Reranker-0.6Bかbge-reranker-v2-m3です。社内のRAG基盤にどの方式を組み込むか決めきれない場合は、RAG構築支援で評価セットの作成から相談を受けています。

一方で、次の場面ではリランクの導入を保留し、先に別の手を打つ順番を勧めます。

• 一段目のRecall@kが低い：候補に正解が入っていなければ、並べ替えても出てきません。チャンク分割や埋め込みモデルの見直しが先です。
• 候補が数件しかない：並べ替えで順位が変わる余地が小さく、遅延の増加のほうが目立ちやすくなります。関連の薄い候補を足切りしたいだけなら、一段目のスコアのしきい値で足りるかを先に確かめます。
• 応答を数十ミリ秒で返す必要がある：APIの通信時間や、CPUで動かす300M級のモデルの推論時間が予算を超えやすい条件です。実際の候補件数・文書長・ハードウェアで測り、収まらなければ導入を見送るか小型モデルに替えます。

導入すると決めた場合も、特定のモデルに固定した設計は避けます。Zerank-2のように、提供元の事情でAPIが1年足らずで終わることがあるためです。モデル名を設定で差し替えられるようにし、自社の評価セットでnDCG@10を測り直せる状態にしておくのが安全です。

よくある質問（リランクモデル）

リランクとはどういう意味ですか？

検索で得た文書の並びを、クエリとの関連度でもう一度並べ替えることです。リランキング、再ランキングとも呼びます。並べ替えに使う専用のモデルを、リランクモデルまたはリランカーと呼びます。

リランカーモデルとリランクモデルは違うものですか？

同じものです。英語のreranker（リランカー）、reranking model（リランキングモデル）、rerank model（リランクモデル）は、いずれも二段目で候補を並べ替え直すモデルを指します。

RRFとリランクは同じものですか？

別のものです。RRFは複数の検索結果の順位を、順位の逆数の和でまとめる計算式で、文書の中身を読みません。リランクはモデルが中身を読んで採点し直します。RRFで統合した上位をリランクする、と重ねて使うこともあります。

Cohere Rerank 3.5や4は今も使えますか？

2026年10月時点では、CohereのAPIでrerank-v3.5とrerank-v4.0-pro／fastを指定できます。ただし公式は新規利用にrerank-v5.0を勧めています。Amazon Bedrockで選べるCohereのリランカーはRerank 3.5です。

日本語の文書には、どのリランクモデルがよいですか？

JQaRAの公開比較表ではRuri-v3-reranker-310m（0.8688）が掲載モデルの中で最も高く、Apache 2.0で商用にも使えます。CPUで速く動かしたいならjapanese-reranker-xsmall-v2やtiny-v2（MIT）です。APIならCohere Rerank 5が日本語を重点言語に挙げています。

関連記事

• クロスエンコーダとは？バイエンコーダとの違いと精度・速度の判断基準【2026年版】
• ColBERTとは？遅延相互作用の仕組みとRAG検索精度への効果・導入判断【2026年版】
• ハイブリッド検索とは？RAGでBM25とベクトル検索を統合する仕組み・RRF・実装コード
• RAG評価とは？検索と生成を分けて測る指標・Ragasでの実装・運用への組み込み【2026年版】
• 埋め込みモデルとは？仕組みと日本語モデルの選び方・RAG実装での判断基準【2026年版】