ベクトル検索のPoCはデータ準備から始まる

前回の記事では、PyCon JP 2026の画像検索トークに向けて、Embedding、マルチモーダル検索、ANNの流れを紹介しました。

こうした技術を自社の検索へ取り入れるには、EmbeddingモデルやVector DB、検索方法の選択が重要です。一方で、実際のPoC（概念実証）では、もう一つ忘れてはいけないことがあります。それが、「何を、どのように探したいのか」と「評価できるデータがあるか」の整理です。

検索技術の検証に目が向くと、その土台となるデータの確認は後回しになりがちです。しかし、データの状態や評価方法によって、選ぶ技術やPoCの進め方も変わります。

今回は、ベクトル検索のPoCを始める前に整理したい5つのことを、実践的な例とともに紹介します。

技術の検証と並行して、データを見られる状態にする

検索対象になるデータは、一か所に整理されているとは限りません。CMS、ファイルストレージ、データベース、表計算ファイルなどに分かれていたり、同じ内容が複数の形式で保存されていたりします。

実際に調べ始めると、次のような問題が見つかります。

• 同じ文書や画像が重複している
• 古い版と現在の版を区別できない
• 画像と説明文、管理番号の対応が揃っていない
• タイトルや分類など、検索に使いたい情報が欠けている
• 閲覧権限の異なるデータが混在している
• 更新や削除を検索インデックスへ反映する方法が決まっていない

検索機能の実装よりも、データの収集、整理、利用範囲の確認に時間やコストがかかる場合があります。これは遠回りではありません。PoCで扱えるデータの範囲と品質が分かれば、実現できる検索と、追加で準備すべきことを具体的に判断できます。

1. 何を検索対象にできるか

最初に、検索対象となるデータを棚卸しします。文書であれば本文だけでなく、タイトル、作成者、分類、公開日なども候補です。画像であれば画像そのものに加えて、キャプション、撮影日時、人物やイベントとの対応も役立ちます。

例えば社内文書を探す場合、下書きや過去の版まで検索するのか、公開済みの最新版だけにするのかで、必要なデータ処理が変わります。アクセス権限のある人だけが見られる文書なら、検索結果にも同じ制御が必要です。

「正しい元データはどこにあるか」「誰がどこまで検索できるか」を整理しておくと、ベクトル化や検索方法の検証も進めやすくなります。

2. 何から何を探すのか

ベクトル検索といっても、入力と検索対象の組み合わせは一つではありません。

• 質問文から、意味の近い文書を探す
• 商品画像から、見た目の近い商品を探す
• 「ステージで発表している人」のような文章から、該当する写真を探す
• 問い合わせ内容から、過去の対応事例を探す

目的が違えば、使うEmbeddingモデルも評価方法も変わります。「検索を改善したい」だけで始めるのではなく、実際に利用者が入力しそうな検索語と、期待する結果を具体例として書き出します。

この段階で、ベクトル検索だけでは解決しにくい条件も見えてきます。日付、部署、商品カテゴリのように明確な値で絞り込めるものは、通常のフィルターと組み合わせた方が分かりやすく、正確です。

3. データ量だけでなく、増え方を見る

現在の件数だけでなく、データがどのように増減するかも確認します。

• 毎日追加されるのか、年に数回まとめて追加されるのか
• 内容の更新や削除がどれくらい発生するのか
• 登録後すぐに検索できる必要があるのか
• Embeddingモデルを変更したとき、再計算できる量なのか

データが小規模であれば、すべてのベクトルを比較する方法でも十分に機能します。最初から大規模なVector DBやANNを導入する必要があるとは限りません。一方、件数が増え続ける場合は、検索速度だけでなく、Embeddingの生成時間、保存容量、更新処理、運用費用まで含めて考える必要があります。

4. 正解例を先に作る

PoCでは、検索画面が動くだけでは効果を判断できません。よく使われる検索語を集め、それぞれについて「どの文書や画像が上位に出てほしいか」という正解例を用意します。

例えば画像検索なら、「受付」「集合写真」「ステージでの発表」といった検索文に対して、期待する写真を複数選びます。文書検索なら、実際の問い合わせや社内で使われる言い回しを使い、見つけたい資料を対応付けます。該当する結果がない検索例も含めると、無関係な結果を自信ありげに表示していないかを確認できます。

調整に使うデータと最終確認に使うデータを分けておくことも大切です。同じ例だけを見ながら調整すると、その例にだけ強い検索になってしまいます。

正解例があれば、Embeddingモデル、検索方法、パラメーターを変えたときに、印象ではなく同じ条件で比較できます。利用部門の人と一緒に正解例を作ること自体が、「何をもって便利な検索とするか」を共有する機会にもなります。

5. 優先順位と制約を決める

検索品質、応答時間、費用、メモリ使用量、既存システムとの連携、セキュリティなど、すべてを同時に最大化することはできません。PoCでは、何を優先し、どこまでを許容するかを決めます。

例えば、社内で一日に数回使う検索と、不特定多数が利用する公開サービスでは、必要な応答時間や費用の考え方が異なります。検索対象を外部サービスへ送れない場合は、利用できるモデルや実行環境にも制約が生まれます。

私たちがPyCon JP 2026で紹介する画像検索では、約2.3万件の画像ベクトルと約7万件の顔ベクトルを扱いながら、クラウドの無料枠で動かすことを制約にしました。この条件があったからこそ、全件を読み取らずに候補を絞る方法や、ブラウザー側での処理を検討しました。

最適な構成は技術の名前だけで決まるのではなく、データと制約から決まります。

PoCの成果は検索画面だけではない

PoCを通して整理できるものは、動く検索画面だけではありません。

• 検索対象にできるデータと、その課題
• 実際に使われる検索例と評価用データ
• 現在の方法と比較するための基準
• 品質、速度、費用に関する測定結果
• 本番導入へ進むために必要な追加作業

検証の結果、現時点では全件検索で十分だと分かることもあります。データ整理を先に進めるべき場合や、別のEmbeddingモデルを試すべき場合もあります。それも、次の投資を判断するための大切な成果です。

CMSコミュニケーションズでは、テキストや画像を対象としたベクトル検索の実験と実装を続けています。自社のデータで何ができるのか、評価用データをどう用意するのか、どの規模のPoCから始めるのかといった段階から、一緒に整理できます。

8月21日（金）のPyCon JP 2026では、実際のデータと制約から画像検索システムを組み立てた過程を、動くものをお見せしながら紹介します。技術の選び方だけでなく、その前提となるデータにも注目していただければと思います。