検索 API を「純ベクトル類似度の top-N」から「キーワード + ベクトルの融合ランキング（RRF 等）」に統一するとき、その API を内部で呼んで『類似度が閾値以上なら重複とみなす』型の判定をしている消費者は静かに壊れる。

何が壊れるか

旧 API の「上位 N 件を類似度順で返す」契約では、先頭要素が必ず全候補中の最大類似度になる。融合ランキングでは並び順が融合スコア順になるため、両リストに中位で載る無関係な候補が上位を占め、ベクトル単独リストで rank 1（類似度最大）の真の近傍が取得 window（limit）の外に押し出されうる。「言い回しが違う重複」こそセマンティック重複検知の主目的なのに、まさにそのケース（キーワード非一致・ベクトル高類似）が検知漏れする。単体テストは API 応答をモックするためこの変化を検出できず、置換後も緑のままになる。

対処の選択肢（今回の判断）

• 採用: 消費者側の取得 limit を契約上限まで広げ、score 付き候補だけを抽出→降順ソート→先頭を閾値判定。window 拡大で漏れ確率を実用上十分に下げられ、統一 API をそのまま使える。融合順と score 順は別物なので、取得後の score 再ソートは必須。
• 完全に保証したい場合: 閾値判定専用に純ベクトル経路（内部 API やパラメータ）を残す。公開サーフェスを 1 本化しても、機械判定の消費者まで同じ統一検索に乗せる必要はない。

検証観点

置換時は「キーワード非一致・ベクトル高類似の候補が検知される」ことを回帰テストに固定する。具体的には score なし（キーワードのみ）・低 score・高 score を非降順で混在させた応答検体で、ソートと閾値判定が壊れたら落ちるテストにする。また、広げた limit が実際に送られていることも固定する（既定値のままだと window が狭くなる退行を検知できない）。

適用条件

検索基盤の種類を問わず（pgvector・専用ベクトル DB・全文検索エンジンのハイブリッド機能）、「ランキング用の検索」と「閾値判定用の類似度取得」を同じ API に相乗りさせるとき全般に当てはまる。