Cohere、Embed 5とRerank 5をOpenRouterの統合APIで提供

Cohereは2026年11月4日、発表した。同社の検索モデルであるEmbed 5とRerank 5がOpenRouterで利用可能になった。既存ユーザーは、別途SDKやアカウント、請求を用意することなく、他のモデルと同じAPIキーとクレジットでこれらのモデルを呼び出せる。

これらのモデルは、検索拡張生成（RAG）パイプラインの検索段階を担う。Embed 5は文書やクエリをベクトルに変換し、Rerank 5はクエリに照らして候補を再スコアリングする。その後、OpenRouter上の任意のチャットモデルが最終回答を生成できる。Cohereは、インデックス作成、検索、関連性による絞り込み、出典を示した回答生成までを網羅するPythonのリファレンスワークフローも公開した。

OpenRouterのEmbed 5 Proの掲載価格は、テキストトークン100万個あたり0.12ドル、画像トークン100万個あたり0.40ドル。Embed 5 Fastはトークン100万個あたり0.08ドルで掲載されている。Rerank 5 Proの掲載価格は、入力トークン100万個あたり0.05ドルで、Rerank 5 Fastはトークン100万個あたり0.02ドル。

OpenRouterでの提供開始は、新たなモデル世代を投入するものではなく、提供範囲を広げるものだ。Cohereは2026年9月30日にEmbed 5を、2026年10月21日にRerank 5を発表しており、どちらのモデル群にもProとFastの各ティアがある。

埋め込み空間の共有でインデックス作成とクエリのコストを分離

アーキテクチャ上の重要な点は、Embed 5 ProとFastが同じ埋め込み空間を共有していることだ。そのため、両方で同じ出力次元数を使えば、インデックスを再構築せずに、Proでコーパスのインデックスを作成し、Fastでクエリを処理できる。これにより、コーパスごとに一度だけ行うインデックス作成と、質問のたびに発生する、レイテンシとコストが重視される埋め込み処理を切り分けられる。

Cohereが40の開発用データセットで行ったテストでは、正規化した平均検索品質は、Proで作成したインデックスをFastで検索した場合が98.4、両側でFastを使った場合が96.6だった。両側でProを使った場合の数値は100だった。OpenRouterのワークフローでは、オフラインのインデックス作成段階にProを用い、Proでインデックスを作成してFastで検索する組み合わせを採用している。

Embed 5では、256次元から2,048次元までの6種類のベクトルサイズを選択でき、デフォルトは2,048次元だ。OpenRouterの例では、同社の埋め込みAPIが浮動小数点数を返すため、1,024次元の浮動小数点ベクトルを使用している。一方、Cohereは同じ次元数で、品質とコストのバランスが最もよい選択肢としてint8ベクトルを推奨している。チャンクをまとめて処理すると、インデックス作成時のネットワーク往復回数は減るが、トークン数に基づく埋め込み料金は減らない。オンライン処理では、質問ごとにEmbed 5 Fastを1回、Rerank 5を1回呼び出し、フィルターを通過したコンテキストがある場合はチャットモデルも1回呼び出す。

関連性スコアで回答生成に使うコンテキストを制御

リファレンスパイプラインは、コサイン類似度で20個のチャンクを取得し、質問とともにRerank 5に渡す。そこから最大5件を残し、デモ用のしきい値である0.3を下回るスコアは除外する。再ランキングでは、ベクトルの近さだけに頼るのではなく、クエリと各候補を組み合わせて評価する。また、Embed 5を使わずに、セマンティック検索、キーワード検索、またはハイブリッド検索の後段で実行することもできる。

Cohereによると、Rerank 5のキャリブレーション済みスコアは、クエリやドメインが異なっても一貫性が保たれるため、単一のしきい値で、生成モデルに渡すコンテキストを決められる。発表時のドキュメントでは、スコア0.7は文書が有用である確率が70%であることを示すと説明している。Proは推論負荷の高いクエリや、長文または特定分野の文書向けである一方、Fastは大量の検索や、繰り返し検索を行うエージェントを対象としている。両モデルは32Kトークンのコンテキストに対応し、JSONレコードや、YAML文字列形式のテーブルを処理できる。

回答生成時には、フィルターを通過したチャンクを番号付きの情報源として示し、それらの情報源だけを使って回答し、本文中に引用を付けるよう指示する。しきい値を超えるチャンクが一つもなければ、ワークフローは回答を見つけられなかったと報告し、チャットモデルの呼び出しを省略する。Rerankはクエリ処理時に生テキストを読むため、再ランキングモデルのバージョンを切り替えても、インデックスの再作成や再埋め込みは必要ない。

デモの結果と本番環境での制約

Cohereのデモでは、架空のAPIドキュメントを使い、停止時間を発生させずにキーをローテーションする方法を尋ねている。埋め込みのみの検索では、正解の文書APIキーのローテーションが0.522で最上位となり、続いてWebhook署名シークレットが0.337、APIキーの作成が0.316だった。再ランキング後は正解の文書が0.808となり、内容の近い2件はいずれもしきい値を下回った。

このサンプルの実行には、Python 3.10以降、OpenRouterのAPIキーとPython SDK、さらにメモリ内のベクトルストア用のNumPyが必要だ。本番環境で実装する場合は、このストアをベクトルデータベースに置き換えるよう案内されている。OpenRouterのRAGに関するガイダンスでは、再ランキングは精度とレイテンシのトレードオフとして説明されている。候補を広く取得して絞り込む必要がある場合は結果を改善できる一方、API呼び出しが追加されるため、最小限のレイテンシを優先する場合には適さない。

マルチモーダル検索には回避策が必要だ。Embed 5は画像や、PDFページのようなテキストと画像の混在入力を受け付け、OpenRouterの埋め込みAPIも画像URLに対応しているが、Rerank 5が扱えるのはテキストのみだ。選択肢として、解析したページのテキストやキャプションを再ランキングする方法と、視覚情報の検索結果には再ランキングを使わない方法が示されている。

OpenRouterでは、両方のProモデルのプロバイダーとしてCohereのみが掲載されており、リクエストは同社に直接転送される。どちらの掲載情報にも、EU域内ルーティングは利用できないと記載されている。

OpenRouterで利用可能になったことで、検索スタックの統合と課金が一元化される一方、本番環境でのコスト構造はアーキテクチャに左右される。具体的には、Proによるインデックス作成は一度きりだが、Fastでの検索、再ランキング、チャットの呼び出しは継続的に発生し、生成コンテキストを制御する関連性のしきい値も関わる。この単一APIによって、そのスタックについて記録されている追加レイテンシ、テキストのみを対象とする再ランキング、地域ルーティングの制約がなくなるわけではない。