複数クラスタ運用と検索の高度化：ビズリーチにおけるElastic活用事例 / ElasticON Tokyo2026

複数クラスタ運用と検索の高度化〜ビズリーチにおけるElastic活用事例〜 @ElasticOnTokyo 2026 株式会社ビズリーチ（Visionalグループ）加藤遼 1

複数クラスタ運用と検索の高度化　〜ビズリーチにおけるElastic活用事例〜 2 自己紹介株式会社ビズリーチプロダクト本部データプロダクト部検索基盤1グループ加藤遼 Ryo
Kato 2023 - 現在株式会社ビズリーチ検索エンジニアとして、企業向けレジュメ検索機能の API化、ランキング改善に取り組む。 Interleavingを用いたABテストの仕組みやベクトル検索導入などを推進。

複数クラスタ運用と検索の高度化　〜ビズリーチにおけるElastic活用事例〜 • 「ビズリーチ」の紹介 • 「ビズリーチ」におけるレジュメ検索 • 機能要件に応じたクラスタ設計 • Sparse Vectorによるベクトル検索の導入
• まとめ 3 目次

4 「ビズリーチ」の紹介

「ビズリーチ」の紹介 5 C (求職者様) と B (企業様/ヘッドハンター様) へ転職・採用プラットフォームを提供引用：ビジョナル株式会社「2025年7月期
第2四半期決算説明資料」即戦力人材と企業をつなぐ転職サイト「ビズリーチ」

「ビズリーチ」におけるレジュメ検索 6 HR領域の検索が直面する課題 - 双方向マッチングの難しさと技術的挑戦採用プラットフォーム「ビズリーチ」におけるマッチング企業(B側)と求職者(C側)のマッチングは、双方向の行動により発生する返信・書類通過
スカウト送信母集団形成求人作成企業スカウト受信・応募ログインレジュメ登録求職者面接採用決定

「ビズリーチ」におけるレジュメ検索 7 採用プラットフォーム「ビズリーチ」におけるマッチング求人レジュメメッセージ通知複数の検索機能をElastic Cloudで実現

8 「ビズリーチ」におけるレジュメ検索

「ビズリーチ」におけるレジュメ検索 9 採用プラットフォーム「ビズリーチ」におけるレジュメ検索母集団形成の改善がマッチング機会の質を左右する。そのために重要な機能がレジュメ検索 HR領域の検索が直面する課題 - 双方向マッチングの難しさと技術的挑戦返信・
書類通過スカウト送信母集団形成求人作成企業スカウト受信・応募ログインレジュメ登録求職者面接採用決定

「ビズリーチ」におけるレジュメ検索 10 採用プラットフォーム「ビズリーチ」におけるレジュメ検索スカウト送信〜返信で絞り込まれるため母集団形成では漏らさないこと(High Recall)が重要 HR領域の検索が直面する課題 - 双方向マッチングの難しさと技術的挑戦返信・
書類通過スカウト送信母集団形成求人作成企業スカウト受信・応募ログインレジュメ登録求職者面接採用決定

「ビズリーチ」におけるレジュメ検索 11 High Recallの実現のためには二つの課題語彙の不一致による検索漏れ応答速度と精度の両立

「ビズリーチ」におけるレジュメ検索 12 ２つの課題解決にむけて High Recallを実現する手段としてsparse vectorを用いたベクトル検索を検討しかし、 • Elasticsearchのバージョンアップ •
パフォーマンスのチューニングを実施するために運用上の課題をクリアする必要があった

13 機能要件に応じたクラスタ設計

機能要件に応じたクラスタ設計 14 改善前のクラスタ状況当時のクラスタは特性のことなる複数の機能向けのIndexをもつ巨大なモノリス機能クエリ特性スループットデータ量レジュメ複雑
大中メッセージシンプル小大通知複雑 & Percolate 大小

機能要件に応じたクラスタ設計 15 モノリスクラスタの課題の顕在化ノイジーネイバー問題キャパシティプランニング/監視の困難さバージョンアップの重荷ある機能が利用するindexへの負荷が、他機能が利用するindex のパフォーマンスへ影響
最大公約数的なスペック・監視にせざるを得ず、最適化が困難利用箇所が多くバージョンアップに膨大なコストと時間がかかり、バージョンアップの優先度が上がらない状況サービス規模の増大により課題が顕在化 • 検索機能改善のためのベクトル検索のような新機能の導入が困難に

機能要件に応じたクラスタ設計 16 機能特性に応じたクラスタ分割機能ごとにクラスタを分割し、機能特性に合ったOptimizationを利用したクラスタ設計 • 最適なリソース割り当てにより全体コストを25%削減に成功 • ベクトル検索導入に向けたバージョンアップやチューニングが可能に

機能要件に応じたクラスタ設計 17 参考：Elasticsearch - 適切なOptimization Typeの選定と安全なクラスター分割具体的な設計やサービス影響を最小限に抑えた切替方法など詳細はテックブログで Elasticsearch - 適切なOptimization
Typeの選定と安全なクラスター分割

18 Sparse Vectorによるベクトル検索の導入

Sparse Vectorによるベクトル検索の導入 19 Sparse Vector ほとんど0の高次元ベクトル（非ゼロが少ない特徴表現） • ベクトル内のほとんどの値が0で、0以外の値のみが記録されたキーと文章の意味や前後関係を踏まえた値のペアとして表現されることが多い「Pythonで機械学習モデルを開発し、検索機能の改善を行うエンジニアを募集」
dense vector sparse vector [0.183, -0.072, 0.441, 0.028, -0.315, 0.509, -0.124, 0.267, -0.038, 0.196, -0.287, 0.354, 0.081, -0.163, 0.472, -0.091] { "python": 2.1, "機械学習": 1.8, "モデル": 1.2, "開発": 1.4, "検索": 2.3, "機能": 0.9, "改善": 1.7, "エンジニア": 1.1}

Sparse Vectorによるベクトル検索の導入 20 Why SparseVector？サービス特性を踏まえ、低Latencyと解釈性を優先 • 低latency ◦ SparseVectorであれば転置インデックスが使える
◦ ドキュメント側のみ拡張して、クエリはキーワード検索方法(SPLADE-Doc)もとれる • 解釈性 ◦ サービス特性上なぜこの人が関連しているかの説明性も重要 ◦ SparseVectorならmodelの出力トークンをタグのように扱い、検索結果に表示するなどの活用もできる

Sparse Vectorによるベクトル検索の導入 • ESでのモデル推論を使用する ◦ 現状、ELSERのみ利用可能（英語のみ） ◦ プラチナプランのみ 21 Elasticsearchでのsparse
vector Elasticsearchでは2種類の方法が提供されている • 事前計算されたベクトルを利用する ◦ どんなモデルも利用できる ◦ 全プラン利用可能こちらを採用

Sparse Vectorによるベクトル検索の導入 Elasticsearchの機能は使わず Embedding用のアプリケーション経由でベクトル作成 22 実現方法: Infrastructure

Sparse Vectorによるベクトル検索の導入独自のHRドメイン特化の日本語 SPLADEモデルを利用 • 自社データで事前学習から実施、HRにおいて意味のある粒度でトークナイズ可能 • 公開されている日本語SPLADEモデルより小型かつ高性能 • ベースのSPLADE実装はOSSとして公開
◦ 商用利用可 23 実現方法: Model 日本語SPLADEモデルと学習コードのOSS公開 bizreach-inc/light-splade

24 課題と工夫

Sparse Vectorによるベクトル検索の導入 25 失敗事例：長文をそのままクエリにした原因 • 長文をSparse vectorに変換すると、非ゼロトークンが大幅に増加 •
スコアリング対象のトークンが増えることで検索負荷が著しく増大した対策案 • Pruningオプションを使う • LLMで短いテキスト/キーワードに変換 • 入力文字数を制限 → こちらを採用 • etc … 長文クエリにより精度と検索速度の両方が悪化

Sparse Vectorによるベクトル検索の導入クエリパフォーマンス向上のため、クエリから重要でないトークンを省略するオプション 26 Pruning option 判断基準 • トークンの出現頻度 ◦
検索対象フィールドで平均よりも一定以上多い一般的なトークンは重要ではないと判断 ◦ パラメータ:tokens_freq_ratio_threshold • 重みが非常に小さい ◦ 入力とあまり関係がない可能性があるため重要ではないと判断 ◦ パラメータ:tokens_weight_threshold

Sparse Vectorによるベクトル検索の導入条件によってはパラメータ調整が必要なため検証必須 • パラメータの設定は利用するモデルやドキュメントに応じて調整が必要な可能性がある ◦ デフォルト値はELSERで検証した結果での最適パラメータであり、日本語や別モデル適用時は調整が必要そう • Pruningするかどうかも含めて検証が必要
◦ 精度に影響する ◦ Pruningはシャードレベルで実施されるため、マルチシャードで実行する場合はrescore queryの追加が推奨されている 27 Pruning パラメータの調整

Sparse Vectorによるベクトル検索の導入検証の結果、ビズリーチでは現状Pruningしない方針を採用 • 頻出語が重要スキル名であるケースがあり、重要な単語が消えてしまうケースが確認された • 基準がドキュメント依存になりコントロールできず、重要な単語が反映されないリスクがある • 検索クエリは長文を使わないようにする方向で調整 28
ビズリーチでのPruning パラメータの調整

Sparse Vectorによるベクトル検索の導入構造に合わせたチャンキング戦略が重要 • レジュメは構造のある長い文章 ◦ 冒頭の文字数だけを使うと、特定の項目の抜け落ちが発生 ◦ すべて含まれるようにtoken
sizeを増やすと、 token数が増加し、検索性能が劣化 • 項目ごとにチャンキングを実施 ◦ レジュメ全体をカバー ◦ 1フィールドのトークン数も抑える 29 工夫①　レジュメは構造単位でチャンク職務要約職歴スキル・株式会社ビズリーチ / 検索エンジニア検索エンジニアとして、企業向けレジュメ検索機能の API化、ランキング改善に取り組む Elasticsearch / Opensearch 職務要約職歴スキル

Sparse Vectorによるベクトル検索の導入精度コントロールのためハイブリッド検索導入 • キーワード検索とベクトル検索のハイブリッド検索を採用 ◦ RRF(Reciprocal rank fusion)アルゴリズムを採用
• retrieverクエリでハイブリッド検索可能 ◦ ただしEnterpriseプランのみ ◦ 利用できるならこちらがおすすめ • ビズリーチでは、アプリケーション側でRRFを実装 30 工夫②　ハイブリッド検索

31 まとめ/今後の展望

今後の展望 • 精度とパフォーマンスのチューニング ◦ トークンの分布を加味した独自のPruning戦略の検討 ◦ Chunking戦略の改善 ◦ モデルの改善 •
LLMを使ったクエリ調整 ◦ 長い文章や求人からでも適切な検索条件を作成できるようにする 32 パフォーマンスの改善とLLMの活用

33 検索基盤エンジニアポジション絶賛募集中！検索基盤エンジニア求人 Engineering blog 検索基盤開発検索ランキング改善 R&D まずは気軽にカジュアル面談でお話ししましょう。 …
検索マイクロサービス開発

複数クラスタ運用と検索の高度化：ビズリーチにおけるElastic活用事例 / ElasticO...

複数クラスタ運用と検索の高度化：ビズリーチにおけるElastic活用事例 / ElasticON Tokyo2026

Visional Engineering ＆ Design

More Decks by Visional Engineering ＆ Design

Other Decks in Technology

Featured

Transcript