Vertex AI Searchによる検索エンジンの構築
はじめに
はじめまして、株式会社グロービスでAIチームに所属する李と申します。機械学習エンジニアとして、GLOBIS学び放題にてAIプロダクトの開発を担当しています。
GLOBIS学び放題には3,900コース、計17,800本以上(2025年10月時点)の動画があります。たくさんの動画からいかに学びたいコンテンツまで辿り着くかが、学び始める前に最も重要なポイントです。そこを手助けするのに重要な役割を果たすのが、検索エンジンです。
検索エンジンの精度が少しでも落ちると、ユーザーは必要な動画にたどり着けず、学び始める前に離脱してしまいます。だからこそ、検索の質が学習体験に直結します。
私たちはこの課題を解決するために、Vertex AI Search を使って検索エンジンを再構築し、検索精度の向上を図りました。本記事では、その取り組みと成果についてご紹介します。
現状の課題
検索精度に関する課題
これまではキーワードベースのシンプルな検索エンジンを運用していましたが、主に以下の課題がありました。
-
ゼロマッチの問題:
- 意味が近いが漢字が異なるとゼロマッチ。
- 例えば、「プレゼン」に対して「伝え方」を検索。
- 表記揺れによるゼロマッチ。
- 例えば、「itパスポート」に対して「ITパスポート」を検索。
- 入力ミスによるゼロマッチ。
- 例えば、「減価償却」に対して「原価消却」を検索。
- 意味が近いが漢字が異なるとゼロマッチ。
-
表示順番の不適切:
- コースID順のため、必ずしも関心度が高いものが上位に出るわけではない。
-
複数キーワードの検索不可:
- 複数キーワードがあっても、最初のものしか見ない。
ユーザー体験への影響
これらの技術的な課題は、直接的にユーザー体験に影響を与えていました:
- 適切なコンテンツが見つからないことによる学習機会の損失
- ユーザーがいつも同じようなキーワードやパターンでしか検索しない、多様性に欠ける状態
ソリューションの比較検討
Vertex AI Searchの選定理由
上記の課題を解決する方法として、今の時代であればベクトル検索が自然に想起されます。私たちはベクトル検索を中心にいくつかのソリューションを検討しました。複数のソリューションを検討しましたが、その中から代表的な3つを共有します。
-
Vertex AI Search
- 概要
- GCP(Google Cloud) が提供する、RAG、ドキュメント理解、ベクトル/ハイブリッド検索などを備えた企業向けAI検索プラットフォーム
- 利点
- ベクトル検索、ハイブリッド検索のサポート
- 開発負担が低い
- 課題
- 細かなアルゴリズム制御や独自エンジンを使ったカスタマイズには制限あり
- 例えば、ハイブリッド検索でのキーワード検索とセマンティック検索の間の重みは自動最適化されるため、カスタマイズできない
- マネージドサービスゆえに、コストは自動スケールやストレージ・トークン量に比例し、用途によっては高くなる可能性がある
- サービスに依存することで、他ベンダーへの移行が難しくなる可能性がある
- 細かなアルゴリズム制御や独自エンジンを使ったカスタマイズには制限あり
- 概要
-
Elasticsearch
- 概要
- GCP上で Elasticsearch を用い、自前でベクトル検索・ハイブリッド検索機能を構築するソリューション
- 利点
- 拡張性が高い
- Embeddingモデルの選択自由
- ランキングモデルのカスタマイズが可能
- ハイブリッド検索において、キーワード検索とセマンティック検索の重み調整
- 重視したいフィールドの重み付け
- ハイブリッド検索が可能
- 拡張性が高い
- 課題
- インフラ構築・スケーリング・運用管理のためのコストが発生
- 概要
-
BigQuery + Embedding
- 概要
- Embeddingモデルで生成したベクトルを BigQuery に保存し、SQL や Python/Dataflow で類似度検索や分析を行う方式
- 方法
- ベクトルをBigQueryに格納
- ユークリッド距離やコサイン類似度をSQLで計算
- PythonやDataflowで前処理や検索結果の強化
- 利点
- GCP上でサーバーレスにスケーラブルな構築が可能
- BigQuery を中心にした既存データ活用が容易
- SQLベースの開発で親和性が高い
- 課題
- ハイブリッド検索や高度な機能(ランキング改善・全文検索連携など)は自前で構築する必要があり、設計・開発負担が大きい
- モニタリングや運用機構も自前で整備する必要があり、拡張性という点では運用負担に依存する形になる
- 概要
各ソリューションの特徴をまとめると、以下の表になります。
ソリューション タイプ |
カスタマイズ性 | 開発 難易度 |
拡張性 | メンテナンス 難易度 |
|
---|---|---|---|---|---|
Vertex AI Search | フルマネージド | △ | ○ | △ | ○ |
Elasticsearch | セミオーダー | ○ | △ | ○ | ○ |
BigQuery + Embedding | フルオーダー | ○ | × | × | × |
上記を踏まえ、GCP Vertex AI Searchを以下の理由で最終的に採用しました。
- ベクトル検索、ハイブリッド検索の実現:従来のキーワード検索では発見できなかった関連コンテンツの表示が可能
- フルマネージドサービス:開発・運用コストが低い
- スケーラビリティ:グロービス学び放題の規模に対応可能
- GCPエコシステムとの親和性:既存のGCP基盤との連携が容易
開発に関して
システム構成
本システムは以下のように構成されています。
青枠のGCP AI Applications(旧称:Agent Builder)は、AIエージェントや検索エンジンなどの迅速な開発・デプロイをサポートするプラットフォームです。その中でVertex AI Searchが検索機能を提供するツールとして組み込まれています。
GCP AI Applicationsを活用することで、検索エンジンの開発・デプロイは簡便になりますが、そこに投入するデータの処理プロセスは自前で用意する必要があります。これは図の赤枠に示す部分です。
今回の検索エンジンに使用されるデータはBigQueryやCloud Storageに保存され、取得・前処理・結合などの一連のプロセスを経て、最後にVertex AI Searchのデータを保持するDataStoreに連携されます。上記のプロセスはVertex AI Pipelinesでスケジュールを組み、定期実行するようにしています。
コンポーネント
本システムは2つのコンポーネント、BuilderとUpdaterから構成されています。それぞれの役割は以下のとおりです。
Builder(検索エンジンのセットアップ)
- 検索エンジン用データベースのスキーマ定義および作成
- 検索エンジン本体の構築
- 通常はプロジェクト立ち上げ時に一度のみ実行
Updater(データ更新)
- 構築済みデータベースへの新規データ取り込み
- Vertex AI Pipelineによる定期的なデータ更新処理の実施
インプット情報
検索エンジンには以下のデータをインプット情報として投入しています。
- コースタイトル
- 講師プロフィール
- タグ情報
- カテゴリ
- タイプ
- 要約データ(AIによる自動生成コンテンツのサマリー)
開発の進め方
開発リソースが限られていること、そして早急な検索エンジン改善のニーズがあることから、フェーズを分けて短い開発サイクルを複数回繰り返し、検索機能の継続的な改善を図りました。
以下のように開発を進めています。
Phase 1(ベクトル検索実装)
- Vertex AI Searchによるベクトル検索の実装
- 従来の検索とベクトル検索の一時的併用
Phase 1.5(実装拡張)
- 従来の検索の廃止
- ベクトル検索に合わせたフロント側の調整
Phase 2(機能拡張)
- フィルタリング機能の追加(カテゴリ、タイプ別)
Phase 3(機能拡張2)
- これから実施予定。詳細は未定だが、ソート機能の実装や辞書登録機能による略語対応などを検討。
開発エピソード① データ前処理の工夫
検索エンジンのインプットとしてコース概要を検討しました。私たちのコース概要には、関連コースの紹介や、学びの意欲を引き出す表現、参考情報のURLなどが含まれています。人間が読むと確かに親しみやすいのですが、検索エンジンにとってはどうでしょうか。
実はノイズ情報として認識され、検索精度に影響が出ます。
例えば、URLの中に偶然「ai」という文字列が含まれている場合があります。その結果、「ai」で検索すると本来AIとは関係のないコースまで結果に表示されてしまいます。ユーザーから見ると、理解しづらい結果になってしまいますね。
もう一つの例をご紹介します。コース概要の中には、講師プロフィールが含まれていることがあります。そこには、講師の経歴や専門分野といった情報が記載されています。これらは講師の専門性を伝える上で有益な情報ですが、検索精度に悪影響を及ぼすこともあります。
たとえば、以下の図に示すように、「クリティカル・シンキング」に関するコースの講師プロフィールに、「業務改革」や「人事組織変革」といったキーワードが含まれています。この状態で「業務改革」と検索すると、本来の意図とは異なるこのコースが、検索結果に表示される可能性があります。
そのため、コース概要をインプット情報から除外しました。代替として、コースの要約をAIで生成し、インプット情報として検索エンジンに投入しています。AIで生成したコース要約は親しみやすさがやや欠けますが、情報の網羅性という観点から、最終的に検索エンジンのインプットとして採用しました。
(AIでいかにコース要約を生成しているかは、また別途紹介させてください 🙇♂️)
開発エピソード② 検索DBのキープロパティの設定
検索DBのキープロパティ設定は忘れがちですが、設定することで検索エンジンの挙動が変わり、精度向上につながります。必ず対応してください。
GCP AI Applicationsのドキュメントにも記載があります。
キープロパティは、検索エンジンに投入されたインプット情報の各列がどのような役割を持つかを明示するものです。今回の検索エンジン構築では、以下のようにキープロパティを設定することで、検索の質が向上しました。
- コースタイトルに
name
を設定 - コース要約に
description
を設定
一般的に、コースタイトルとコース要約では文字数が大きく異なります。コースタイトルが数十文字であるのに対し、コース要約はその数倍から数十倍の文字数になることがあります。name
と description
を設定することで、文字数の違いを検索エンジンに伝えます。これにより、検索エンジンはキーワード検索とセマンティック検索の重みや埋め込みモデルなどを調整し、精度向上を図っていると考えられます。
(設定によって挙動がどう変わるかは公式ドキュメントに明記されておらず、個人の推測です。誤りがあればご容赦ください)
開発エピソード③ 検索DBの列名変更や列削除ができない
今回の開発で得られた教訓ですが、検索DBの列のリネームと削除はできません。開発時には、下記の点を念頭に置いて進めてください。
- スキーマ変更の制限:一度作成したデータストアの列名変更や削除は不可能
- 事前設計の重要性:スキーマ設計は慎重に行い、将来の拡張性も考慮する必要がある
運用コスト
Vertex AI Searchの運用コストは以下の要素で構成されます(2025年10月時点)。
- クエリ課金:1,000クエリあたりの従量課金(1.5 $ / 1,000クエリ)
- インデックスストレージ課金:インデックスを保存するための課金(1GiBあたり $5.00 / 月)
- インフラコスト:フルマネージドサービスのため、サーバー運用コスト不要
今後の展望
今後は、ソート機能の搭載や辞書登録による略語対応などの高度な機能を追加し、検索エンジンの継続的な改善を進めていきたいと考えています。
まとめ
今回はVertex AI Searchを使用して検索エンジンを開発した事例をご紹介しました。Vertex AI Searchはフルマネージドサービスならではの利便性がある一方で、キープロパティの設定やデータ前処理を工夫することで、独自のニーズに合わせて検索精度を向上させることも可能です。
この記事が、皆さんの現場で検索エンジンを構築する際にVertex AI Searchを試すきっかけになれば幸いです。
Discussion