クロスエンコーダとは？バイエンコーダとの違いと精度・速度の判断基準【2026年版】

クロスエンコーダは、クエリと文書を1本の入力系列に連結してTransformerに通し、両者の関連度をスコアとして直接出力するモデルです。文書を単独でベクトル化するバイエンコーダと違い、クエリ側の単語と文書側の単語の対応を全層のアテンションで計算します。そのぶん並べ替えの精度は上がるものの、文書側の事前計算ができないため、候補1件ごとに推論が走ります。この記事は、仕組みの違いから日本語モデルの実測スコア、二段構成の検索パイプラインへの組み込み手順、候補件数とコストの決め方、そして導入を見送るべき条件までを実装目線で整理した内容です。

まとめ：クロスエンコーダの精度向上効果と採用を見送るべき条件

クロスエンコーダは「検索の一段目」ではなく「二段目の並べ替え」に置く部品です。ベクトル検索や全文検索で候補を50〜100件に絞り、その候補だけをクエリとペアにして再スコアリングする。この分業が前提で、全文書を直接スコアリングする使い方は現実的な処理時間に収まりません。sentence-transformersの公式一覧では、6層のms-marco-MiniLM-L6-v2がNDCG@10で74.30、12層のL12-v2が74.31とほぼ同値でありながら、スループットは1,800件毎秒と960件毎秒で倍近い差がつきます。層を増やせば精度が伸びるという単純な関係ではありません。

採用の条件ははっきりしています。ベクトル検索の上位10件に正解が入っているのに順番が悪い、という症状が出ている場合は効きます。逆に、上位100件を見ても正解文書がそもそも入っていない場合、並べ替えでは何も改善しません。この場合に手を入れるべきはチャンク分割や検索クエリの作り方であって、リランカーではありません。また、1リクエスト200ミリ秒以内といった応答時間の制約が厳しく、GPUを常時確保できない構成では、候補件数を絞りきれない限り見送る判断が妥当です。

クロスエンコーダの定義とクエリ・文書をペアで同時入力する仕組み

まず、モデルが何を入力として受け取り、何を返すのかを押さえます。ここが分かれば、後段の速度・コストの話はすべて同じ理屈で説明がつきます。

クエリと文書を1本の系列に連結して関連度スコアを出す処理の流れ

入力は文の「ペア」です。BERT系のエンコーダに対して、クエリと候補文書を区切りトークンで連結した1本の系列として与え、先頭トークンの出力ベクトルを分類ヘッドに通し、スカラー値を1つ得ます。sentence-transformersではCrossEncoderクラスが該当し、model.predictにタプルのリストを渡すと候補件数ぶんのスコアが配列で返ります。

返る値の意味はモデルごとに違います。Sigmoidを通す設定なら0から1の範囲に収まりますが、MS MARCO系の多くは生のロジットを返すため、マイナス10からプラス10程度の範囲に散らばる。この差を意識せずに「0.5以上を採用」といった閾値を書くと、モデルを差し替えた瞬間に検索結果が空になります。スコアの解釈は後段の設計に直結する部分なので、採用するモデルのモデルカードで活性化関数の指定を確認してください。

文書側の事前計算ができない構造がもたらす精度向上と計算量の増加

バイエンコーダは、文書を投入時に一度ベクトル化して索引に入れておけます。検索時に計算するのはクエリのベクトル1本だけで、あとは近傍探索が候補を返す。対してクロスエンコーダは、スコアがクエリと文書の組に対して定義されるため、クエリが決まるまで何も計算できません。候補が100件あれば100回の順伝播が発生します。

この構造が精度の源でもあります。バイエンコーダでは、文書ベクトルを作る時点でクエリが何かを知らないため、文書の情報を固定長ベクトルへ圧縮する過程で、そのクエリに効く手がかりが落ちることがある。クロスエンコーダは圧縮を挟まず、クエリ側のトークンと文書側のトークンを直接照合します。「Aという条件でのBの扱い」のように、語の組み合わせで意味が決まる問い合わせほど差が出ます。

バイエンコーダ・遅延相互作用型との構造比較と推論コストの違い

検索で使われるエンコーダは、大きく3系統に分かれます。どこまで事前計算できるかが、そのまま精度と速度の位置を決めます。

バイエンコーダとの分業で成り立つ候補取得と並べ替えの二段構成

実務で組む形は決まっています。一段目でバイエンコーダによるベクトル検索、あるいはBM25などの全文検索で候補を広めに取り、二段目でクロスエンコーダが並べ替える。一段目の役目は再現率、二段目の役目は順位の正しさで、評価する指標も違います。一段目の設計は埋め込みモデルの選び方と、BM25とベクトル検索を統合するハイブリッド検索の側で決まります。

表の「1クエリの推論回数」が、そのままコストの読み方になります。候補を100件から30件に減らせば推論も3分の1になる。ここが後述するチューニングの主戦場です。

ColBERT型の遅延相互作用との中間的な位置づけと使い分け基準

遅延相互作用型は、文書をトークンごとのベクトル集合として事前計算し、検索時にクエリ側トークンとの最大類似度を足し合わせます。事前計算が効くぶん高速で、単一ベクトルへの圧縮を避けるぶん精度も稼げる中間解です。ただし索引サイズは文書1件あたりトークン数×次元に膨らみ、単一ベクトル索引の数十倍になることもある。仕組みと索引設計はColBERTの遅延相互作用の解説で扱っています。

選び分けの基準は保有リソースで決めます。文書が数万件規模でストレージに余裕があり、応答時間の要求が厳しいなら遅延相互作用型。文書量が多く索引を膨らませたくない、かつ二段目に数十ミリ秒を割けるならクロスエンコーダ。両方を並べる構成も理屈のうえでは可能ですが、運用するモデルが2つ増えるだけの効果が出るかは検証してから決めてください。

日本語で使える主要クロスエンコーダモデルと精度・速度の実測比較

モデル選定は「英語ベンチマークの数字」と「日本語での実測」を分けて見る必要があります。前者は速度と精度の関係を、後者は実務での通用度を教えてくれます。

MS MARCO系英語モデルのNDCG@10とスループットの対応関係

sentence-transformersの公式ドキュメントが公開している、MS MARCO学習済みクロスエンコーダの一覧です。NDCG@10はTREC Deep Learning 2019、Docs/Secは同一GPU環境での相対値として示されています。

読み取るべきは飽和点です。L4からL6でNDCG@10は1.26ポイント伸びますが、L6からL12では0.01ポイントしか動かず、スループットは半分近くまで落ちる。層数を倍にした投資が返ってこない領域が明確に存在します。英語圏の一般的な出発点がcross-encoder/ms-marco-MiniLM-L6-v2に落ち着いているのは、この表がそのまま根拠です。

日本語リランカーの選択肢とJQaRA・JaCWIRでの実測スコア

日本語文書を扱うなら、日本語または多言語で学習されたモデルを選びます。実務で候補に挙がるのは、hotchpotch氏が公開する日本語リランカーシリーズ、多言語対応のBAAI/bge-reranker-v2-m3、そして機械翻訳版MS MARCOで学習されたcross-encoder/mmarco-mMiniLMv2-L12-H384-v1の3系統です。最後のものは14言語へ翻訳したデータで学習され、パラメータは約0.1B、ライセンスはApache 2.0です。

シリーズ最上位のjapanese-reranker-cross-encoder-large-v1は0.3Bパラメータで、公開されているベンチマークではJQaRA 0.7099、JaCWIR 0.9364、MIRACL 0.8406、JSQuAD 0.9773という値が示されています。多言語で揃えたい場合のBAAI/bge-reranker-v2-m3はbge-m3を土台にした0.6Bのモデルで、FlagEmbeddingのFlagRerankerからも呼び出せます。GPUメモリが限られる環境では、まずxsmall-v1かsmall-v1で二段構成そのものが効くかを確かめ、効果を確認してから大きいモデルへ上げる順番が無駄になりません。

二段構成の検索パイプラインへ組み込む実装手順とスコア運用の判断基準

コードとしての実装は短く済みます。むしろ設計上の判断は、候補件数とスコアの使い方に集中します。

sentence-transformersのCrossEncoderで再ランクする実装

2026年8月時点のsentence-transformersは5.6系です。CrossEncoderの推論は、モデルを読み込み、クエリと候補文書のタプルを並べてpredictを呼び、返ったスコアで候補を降順に並べ替えるだけで完結します。

1. ベクトル検索や全文検索で候補文書を取得する（初期値は上位50件）
2. CrossEncoderにモデル名を渡し、max_lengthを文書の実長に合わせて指定する
3. クエリと各候補文書のタプルのリストを組み立てる
4. predictにリストとbatch_sizeを渡してスコア配列を受け取る
5. スコアの降順に並べ替え、上位k件だけを生成モデルへ渡す

この5工程のうち、性能に効くのは1と5の件数指定です。2から4はライブラリ側の作法にすぎません。並べ替え後にk件へ絞る処理を忘れると、コンテキストに100件が流れ込んで生成側のコストが跳ね上がります。

候補件数・トークン長・バッチサイズの初期値と調整する順序の目安

調整には順番があります。まず候補件数を50件に固定し、二段目を入れる前後で検索評価指標がどれだけ動くかを測る。ここで差が出ないなら、以降のチューニングをしても報われません。差が出た場合に限り、候補件数を100件へ広げて伸びしろを確認します。

次にトークン長です。MS MARCO系の多くは512トークンで学習されており、それを超える文書は切り詰められる。長い文書をそのまま入れると後半が評価対象から消えるため、チャンクの粒度を512トークン以内に収めるか、チャンク単位でスコアリングして文書ごとに最大値を取る設計へ変えます。バッチサイズは最後です。GPUメモリが許す範囲で16から32あたりに上げるとスループットは改善しますが、精度には影響しません。

スコアの絶対値で足切りする設計と順位だけを使う設計の使い分け

並べ替えた結果をどう使うかで、設計は2通りに分かれます。順位だけを使う設計は「上位5件を必ず渡す」という運用で、候補が弱くても常に5件が生成側へ流れる仕組みです。絶対値で足切りする設計は「スコアが閾値未満なら渡さない」という運用で、該当文書がないときに空を返せます。

社内文書の検索アシスタントのように、根拠がないなら答えさせないほうが安全な用途では、後者を選びます。閾値はモデルの出力レンジに依存するため、正解ラベル付きの評価セットを数十件用意し、正解と不正解のスコア分布が分かれる位置を実測して決める。この手間を惜しんで勘で閾値を置くと、モデル更新のたびに再現率が静かに落ちていきます。

レイテンシとGPUコストを抑える候補件数・量子化・API併用の設計

二段目の追加コストは、候補件数とモデル層数の掛け算でほぼ決まります。予算と応答時間の制約から逆算する手順を示します。

モデル層数とスループットのトレードオフから決める候補件数の上限

先の一覧をコスト計算に使います。1,800件毎秒のモデルで候補50件なら理論値で約28ミリ秒、候補100件なら約56ミリ秒。960件毎秒のモデルに替えると同じ100件で約104ミリ秒に伸びます。実際にはバッチ化の効率やトークン長で上振れするため、この2倍程度を見込んでおくと見積もりが崩れません。

応答時間の予算が二段目に100ミリ秒しかないなら、6層クラスで候補50件が現実的な上限になります。それ以上の件数が必要だと分かった時点で、選ぶべきはより大きいモデルではなく、一段目の候補精度の改善です。ONNXやint8量子化での高速化も選択肢に入りますが、量子化は精度が数ポイント落ちることがあるため、評価セットで劣化幅を測ってから採否を決めてください。

自己ホストとマネージドAPIのコスト構造と切り替えの判断分岐点

自己ホストはGPUインスタンスの時間課金、マネージドAPIは検索リクエストと文書件数に応じた従量課金です。コスト構造が固定費と変動費で逆になるため、分岐点は検索リクエストの量で決まります。1日数百件の社内利用ならAPIのほうが安く、常時稼働のGPUを遊ばせずに済む。1日数万件を超え、GPUの稼働率が高く保てるなら自己ホストが逆転します。

もう1つの分岐が、文書を外部へ送れるかどうかです。機密性の高い社内文書を扱う案件では、この一点で自己ホストに決まることが多くあります。マネージドのリランカー製品を含めた種類ごとの比較は、リランクモデルの種類と選び方をまとめた記事で整理しています。

ファインチューニングが要る場面と導入を見送るべき典型的な失敗例

最後に判断の話をします。既製モデルで止めるか、自前で学習するか、そもそも入れないか。この3択を条件つきで切り分けます。

既製モデルで足りる条件と自前学習に踏み切る判定ラインの引き方

既製モデルで足りるのは、検索対象が一般的な日本語文書で、クエリも自然文の質問である場合です。マニュアル検索やFAQ検索の大半はここに入ります。自前学習を検討すべきなのは、社内固有の型番・略語・部署名が関連度の判断を左右する場合や、「新しい版を優先する」といったドメイン固有の順序規則がある場合です。

判定ラインは実測で引きます。評価セット100件程度で既製モデルのNDCG@10を測り、一段目からの伸びが2ポイントに届かないなら、学習を検討する。伸びが5ポイント以上あるなら、まずはその状態で運用に載せ、学習は後回しにする。この順番を守らないと、効果が出るか分からない学習に人日を溶かすことになります。

学習データの作り方と損失関数の選び方をめぐる実務上の判断指針

学習データは、クエリと正解文書のペアに加えて、一段目の検索が返した不正解の上位文書をハードネガティブとして集めます。無作為に選んだ不正解では簡単すぎて学習が進みません。sentence-transformersの学習はCrossEncoderTrainerとCrossEncoderTrainingArgumentsで構成し、データセット・損失関数・評価器を渡す形です。

損失関数は、データの持ち方で決まります。正解か不正解かの2値ラベルしかないならBinaryCrossEntropyLoss、1クエリに複数の候補を並べて相対順序を学ばせるならMultipleNegativesRankingLossやメモリ効率を上げたCachedMultipleNegativesRankingLoss。順位そのものを目的に据えるならLambdaLossやListNetLossといったランキング損失が用意されています。最初の1本は2値ラベルとBinaryCrossEntropyLossで組むのが手戻りの少ない選択です。

導入すべきでない検索要件と精度が上がらないときの典型的な原因

導入しないほうがよい場面を明確にします。第一に、候補100件の中に正解が入っていないケース。並べ替えは候補集合の外にあるものを持ってこられないため、リランカーの効果はゼロです。第二に、文書が数百件しかなく、一段目だけで上位に正解が来ているケース。ここで二段目を足しても順位はほとんど動かず、レイテンシとGPU費用だけが増えます。第三に、完全一致の型番検索やコード検索のように、語彙の一致が答えそのものである要件。意味的な近さを測るモデルは、この種の検索では素直な全文検索に劣ります。

精度が上がらないときの原因は、モデルよりも入力側にあることがほとんどです。チャンクが長すぎてトークン切り詰めが起きている、チャンク境界が文の途中で切れていて文脈が壊れている、クエリが検索用に整形されず会話の断片のまま渡っている。この3つを先に潰してからモデルを疑ってください。RAGの検索段を含めた設計・実装の相談はRAG構築支援で承っています。

よくある質問

クロスエンコーダの導入検討でよく寄せられる質問をまとめます。

クロスエンコーダはRAGの回答精度をどれくらい改善しますか？

改善幅は一段目の品質に依存するため、一律の数値は示せません。目安として、ベクトル検索の上位10件に正解が含まれているのに順位が5位以下に埋もれている状態なら、二段目の追加でNDCG@10が数ポイント動くことがあります。逆に一段目の再現率が低い場合、並べ替えでは改善しません。導入前に「候補100件のうち正解が何件目に入っているか」を測り、順位の問題なのか候補取得の問題なのかを切り分けてください。

日本語の文書で最初に試すべきクロスエンコーダはどれですか？

GPUが確保できる環境なら、日本語リランカーシリーズのbase-v1クラスから始めると、精度と速度のバランスを掴みやすくなります。多言語文書が混在する構成ではBAAI/bge-reranker-v2-m3が候補です。いずれの場合も、最初から最上位モデルを選ばず、小さいモデルで二段構成の効果そのものを検証してから規模を上げる順番をおすすめします。英語専用のMS MARCO系を日本語文書へそのまま当てる選択は避けてください。

CPUだけでクロスエンコーダを動かせますか？

動きますが、候補件数を絞る前提が要ります。CPU推論では6層クラスでも1件あたり数十ミリ秒かかるため、候補50件では秒単位の待ち時間になります。バッチ処理や非同期の事前計算で応答時間の要求が緩い用途、あるいは候補10件程度まで絞れる用途に限れば実用範囲です。オンラインの対話用途でCPUのみという条件なら、ONNX Runtimeでの量子化推論か、マネージドAPIへの委譲を検討してください。

クロスエンコーダのスコアはそのまま関連度として使えますか？

モデルによります。Sigmoidを通す設定なら0から1に収まりますが、MS MARCO系の多くは生のロジットを返すため、値の大小関係は使えても絶対値の意味は共通しません。閾値で足切りする設計にする場合は、採用するモデルごとに評価セットでスコア分布を確認し、正解と不正解が分かれる位置を実測して閾値を決めます。モデルを差し替えたら閾値も引き直す前提で運用してください。

クロスエンコーダとColBERTはどちらを選ぶべきですか？

索引サイズに余裕があり応答時間の要求が厳しいならColBERT型、索引を膨らませたくなく二段目に数十ミリ秒を割けるならクロスエンコーダという分け方になります。ColBERT型は文書をトークン単位のベクトル集合として事前計算するため索引が大きくなる一方、検索時の計算は軽い。クロスエンコーダは索引を増やさない代わりに、候補件数ぶんの推論が毎回発生します。文書量とインフラ予算から先に制約を確定させると迷いません。

関連記事

• リランクモデルとは？ベクトル検索と組み合わせる種類・仕組み・選び方：クロスエンコーダを含むリランカー全体の種類とマネージド製品の比較はこちらで扱っています
• ColBERTとは？遅延相互作用の仕組みとRAG検索精度への効果：本記事で中間解として触れた遅延相互作用型の索引設計を掘り下げています
• 埋め込みモデルとは？仕組みと日本語モデルの選び方：二段構成の一段目を担うバイエンコーダ側の選定基準をまとめています
• ハイブリッド検索とは？RAGでBM25とベクトル検索を統合する仕組み：候補取得の再現率を上げる一段目の設計として組み合わせられます
• ModernBERTとは？BERT後継エンコーダの特徴・base/largeと使い方：クロスエンコーダの土台になるエンコーダ側の世代交代を解説しています