はじめに
今や、社内ドキュメントやWiki（WordPressやNotionなど）から情報を探す際、高性能な検索窓があるのは当たり前かもしれません。しかし私が学生時代、検索は「用意されているもの」ではなく、「創り出すもの」でした。もちろん、インターネット上に公開されている情報は今と同じようにGoogleやYahoo!で検索していましたが、その裏側を理解したいという欲求がありつつ、会社のイントラネットや自分のパソコン上のドキュメントを効率的に検索ができないか考えていました。
私は学生時代、情報工学の授業で検索システムを理解するため、OSSの全文検索エンジン Namazu をベースに、どうすれば「単語が一致しなくても意図が伝わる検索」ができるのか、Perlと格闘しながら自作の検索システムを構築していました。また、内部構造を理解するためかなり高額な参考書も買い、理論も合わせて勉強していました。
それからだいぶ年月が経ち、クラウドアーキテクトとして Vertex AI Search に触れたとき、かつての自分が数式と正規表現の先に見ようとしていた「理想イメージ」が、そこには完成された形で存在していました。本記事では、当時の苦労を振り返りつつ、最新のAI検索がいかに「不連続な進化」を遂げたのかをまとめます。
本記事は、検索エンジンの内部構造を理解しようと足掻いた経験を持つエンジニアが、Google Cloudの最新技術によって検索がどう「民主化」されたのかを記録するものです。
1. 「手作りパイプライン」の記憶：Perlと形態素解析の格闘
当時は、検索窓にクエリを投げる前の「前処理」だけで、エンジニアリングの全精力を使い果たしていました。
① Perlによる泥臭いデータクレンジング
検索対象となるテキストを整形（データクレンジング）するため、正規表現の嵐の中でコードを書いていました。HTMLタグを除去し、文字コードを統一し、全角半角を正規化する。1行ずつ、テキストを「検索可能な素材」へと削り出す地道な作業でした。
② 形態素解析器の三段活用（KAKASI / CHASEN / MeCab）
日本語を「わかち書き」するために、ツールを試行錯誤しました。
- KAKASI / 茶筌 (CHASEN): 日本語を品詞レベルで分解する。
- MeCab: 当時登場したばかりの高速な解析器に感動したのを覚えています。
③ 「意味」を捉えるための自作特徴ベクトル
最大の挑戦は、単語の一致に頼らない 「単語レベルの特徴ベクトル」 の作成でした。
単語の共起頻度などの統計量から多次元ベクトルを算出し、コサイン類似度で「リンゴ」と「アップル」を近づけようとする試みです。当時は計算リソースの限界もあり、理想の精度を出すのは至難の業でした。
④ 言語統計アルゴリズムによるスコアリング
自作システムでは、単語の出現頻度を元にした統計モデル（TF-IDFや、その進化系の $BM25$）を組み込んでいました。
$$score(D, Q) = \sum_{i=1}^{n} IDF(q_i) \cdot \frac{f(q_i, D) \cdot (k_1 + 1)}{f(q_i, D) + k_1 \cdot (1 - b + b \cdot \frac{|D|}{avgdl})}$$
- 当時の工夫: タイトルタグ内の単語に高い重み（ブースト）をかけたり、数式のパラメータ（$k_1, b$）の数値を少しずつ変えてはテストを繰り返す「秘伝のタレ」のような調整を行っていました。また、重要語の抽出に関する論文を読み漁り、与えられた語の中で重要と思われる語に対し重み付けをしたということもしていました。
- 限界: どれだけ統計を極めても、文章の中に「その単語」が含まれていなければ、検索結果に出すことは不可能でした。
2. Vertex AI Searchによる「不連続な進化」
クラウドアーキテクトとしてVertex AI Searchを触った時に感じたのは、単なる「便利さ」ではなく「技術の断絶」です。
「アルゴリズムの実装」から「データの配置」へ
かつて数週間かけていたパイプライン構築が、今は「Cloud Storageにファイルを置く」だけで終わります。
| プロセス | 学生時代の自作システム (Perl + MeCab) | Vertex AI Search (Google Cloud) |
|---|---|---|
| クレンジング | 正規表現による自作スクリプト | PDFやHTMLをそのまま投入可能 |
| 意味の抽出 | 解析器 + 統計ベースの自作ベクトル | 数千次元の高精度エンベディング |
| 検索精度 | 単語一致 + 統計的類似度 | セマンティック検索（意味一致） |
| アウトプット | 関連ドキュメントのリンク集 | LLMによる統合された「回答」 |
検索の終着点：RAG（Retrieval-Augmented Generation）
かつての検索のゴールは「関連文書を上位に出すこと」でした。しかし、Vertex AI Searchはその先へ行きました。検索結果をGeminiが読み込み、「答えそのもの」を生成する。これはもはや、自分が勉強していた「検索エンジン」の枠を超えた存在です。
当初触ったとき、素直にすごい！こんなことできるんだ。と感動してしまいました。
3. Vertex AI Search 構築手順：かつての数ヶ月を「数分」で再現する
現代のアーキテクチャでは、検索システムの構築は以下のようなシンプルなステップになります。
Step 1: データストアの作成
Google Cloud Consoleで、検索対象となるドキュメントが格納されたCloud Storage等のバケットを指定します。ここで驚くのは、前処理が不要な点です。
Step 2: アプリの作成と紐付け
「検索アプリ」を作成し、データストアを選択します。インデックス作成（ベクトル化）はGoogleのインフラ側で自動的に行われます。
Step 3: プレビューと回答の確認
コンソールのプレビュー画面で質問を投げます。例えば「サーバーの再起動手順は？」と聞けば、複数の文書から情報を拾い集め、Geminiが手順を要約して回答してくれます。
かつてインデックスバッチの残り時間を深夜まで見守っていた日々が、数クリックの操作に置き換わりました。
おわりに
学生時代、Perlでテキストを1行ずつ処理し、単語の海からベクトルを抽出しようとしたあの時の思考プロセスは、今の私のエンジニアとしてのバックボーンになっています。
「仕組みを知っているからこそ、ツールの凄さがわかる」
Vertex AI Searchは、かつて学生だった自分が手作りで辿り着こうとしていた「言葉の意味を解する検索」の、一つの完成形です。アーキテクトの仕事は、アルゴリズムを書くことから、「AIが理解しやすい良質なデータをどう整備し、ビジネスに活かすか」へとシフトしたと思います。
これだから技術の進化は楽しいものです。これからも技術の進化をウォッチしていきたいと思います。
もし、社内など外部非公開の情報を検索すると、まだ「キーワードが一致しないと出てこない」古い検索システムに苦労しているのなら。一度、この圧倒的な進化を体験してみてください。きっと、検索キーワードを考える必要のないストレスフリーな検索の形が、そこにあると思います。