ベクトル検索

AI検索が埋め込みベクトルを比較して関連コンテンツを見つける仕組み — ANNアルゴリズム(HNSW、ScaNN)、距離メトリクス、ハイブリッド検索、そしてSEOへの影響。

初回公開:2026年6月24日 · 最終更新:2026年8月3日 · Advanced
言語

ベクトル検索は、クエリの意味を保存されたコンテンツと埋め込みベクトルとして比較し、高次元空間で最も近いものを取得することでコンテンツを見つけます。大規模には、近似最近傍(ANN)アルゴリズム(HNSW、IVF、FAISS、ScaNN)を使用し、わずかな再現率を犠牲にして大幅な速度向上を実現します。なぜなら、数十億のベクトルをリアルタイムで正確に比較することは不可能だからです。これはセマンティック検索を実現する方法であり、同義語ではありません。また、AI Overviewsに供給されるものを含むすべてのRAGシステム内の取得ステップです。本番検索では単独で実行されることはほとんどなく、実際のパターンはハイブリッド(キーワードBM25 + ベクトル + 再ランキング)です。SEOに関しては調整できるノブはありません — ベクトルの近接性が候補プールへの新しいゲートであり、キーワード密度よりもトピック的に一貫したパッセージレベルの深さを評価します。

TL;DR — ベクター検索は、高次元の埋め込み空間でクエリベクターに最も近いベクターを取得し、近似最近傍(ANN)アルゴリズム(HNSW、IVF、FAISS、ScaNN)を使用します。なぜなら、数十億のベクターに対する正確な比較はリアルタイムでは不可能だからです。ANNは設計上近似です。わずかな再現率を桁違いの速度と引き換えにします。ベクター検索はセマンティック検索のメカニズムであり、同義語ではありません。また、すべてのRAGシステム(AI Overviewsを含む)内の取得ステップです。本番環境では単独で実行されることはほとんどなく、実際のパターンはハイブリッドです:BM25 + ベクター + 再ランキング。SEOに関しては調整するノブはありません。ベクターの近接性が候補プールへのゲートであり、トピック的に一貫した、パッセージレベルの深さを報います。

ベクター検索の位置づけ

ベクトル検索は、ランキングや生成に供給できる一つのコンポーネントであり、それ自体が完全な検索システムではありません。 Evidence for this claim HNSW is an approximate nearest-neighbor method that organizes vectors in a multilayer navigable graph for efficient search. Scope: The HNSW algorithm and reported evaluations; production indexes may use different ANN methods and parameters. Confidence: high · Verified: Malkov and Yashunin: HNSW 固定された距離閾値やインデックスアルゴリズムが普遍的に最適というわけではありません。 Evidence for this claim Embedding vectors can be compared by distance to retrieve related items. Scope: OpenAI embedding guidance; retrieval quality depends on model choice, corpus, index, filters, and evaluation. Confidence: high · Verified: OpenAI: Embeddings guide

埋め込みはベクトルを与えます。ベクトル検索は、それを使って行うことです。埋め込みが「ベクトルとは何か」という物語の半分なら、これは「最も近いものを見つける」という半分です。そして、業界が常に曖昧にしている区別について正確に述べる価値があります。セマンティック検索は目標であり、ベクトル検索はそれを達成するための一つの方法です。 セマンティック検索は、ナレッジグラフ、エンティティ認識、意図マッチングにも依存できます。ベクトル検索は、具体的には埋め込み空間上のANN検索を意味します。つまり、この二つは同義語ではありません。たとえ同じように使われていてもです。

ベクトル検索の仕組み:ステップバイステップ

パイプラインは、Googleであれ週末のRAGプロジェクトであれ同じです。

The query is embedded into the same representation as indexed content before nearby candidates are retrieved. 出典: Vector Search

Documents are embedded and indexed before the search. At query time, the system embeds the query, searches an approximate-nearest-neighbor index, finds nearby vectors, and returns their corresponding documents as candidates.

© Patrick Stox LLC · CC BY 4.0 ·

  1. コンテンツを埋め込む。 エンコーダーモデルがコンテンツの各チャンクをベクトルに変換します。チャンクに注意してください。ベクトル検索はページ全体を比較するのではなく、パッセージを比較します。チャンキングは検索の単位であり、ページレベルのキーワード存在よりもパッセージレベルの密度が重要である理由です。
  2. インデックスを構築する。 ベクトルは、高速な最近傍検索用に構築されたベクトルインデックス(ANNインデックス、詳細は後述)に入ります。
  3. クエリを埋め込む。 クエリ時に、同じモデルがユーザーのクエリを同じ空間のベクトルに変換します。
  4. ANN検索を実行する。 インデックスは、クエリベクトルに最も近い上位k個のベクトル、つまり候補セットを返します。
  5. ランク付けして返す。 これらの候補はスコアリングされ、多くの場合再ランク付けされ、最良のものが提供されます(または、RAGではLLMに渡されて生成に使用されます)。

近似最近傍探索 — 「近似」の理由

正確な最近傍を見つけるには、クエリを保存されているすべてのベクトルと比較する必要があります。クエリあたりO(N)です。数十億のベクトルをミリ秒で処理するには、これは非現実的です。そこで本番検索ではANNを使用します。これは、比較の大部分をスキップしながら、最近傍をほぼ完璧に見つけるインデックス構造です。

Elasticが述べるように、ANNは*「完全な精度を犠牲にして、高次元の埋め込み空間で大規模に効率的に実行する」ものです。Weaviateは同じトレードオフを「わずかな精度を犠牲にして、速度を大幅に向上させる」と表現しています。これはバグではありません。ベクトル検索を可能にするエンジニアリング上の選択です。「近似の良さ」の指標は再現率です。Googleはこれを「インデックスによって返された最近傍のうち、実際に真の最近傍であるものの割合」*と定義しています。Google自身のVector Searchサービス(「Vertex AI Vector Search」からブランド変更され、現在はGemini Enterprise Agent Platformの下で文書化されています)は、95〜98%の再現率を報告しています。真の最近傍の数パーセントを犠牲にして、その代わりにウェブスケールでの検索を手に入れるのです。

主要なANNアルゴリズム

これらを実装する必要はありませんが、名前を知っておくと、AI検索に関する議論の多くが理解しやすくなります。

  • HNSW(階層的ナビゲーション可能なスモールワールド) — 業界標準。上位層は長距離接続を持つ疎な「高速レーン」で高速な走査を実現し、下位層は精密なナビゲーションのための密な「ローカル道路」である多層グラフ。ほぼ対数検索複雑性を実現し、これが本番環境で支配的である理由です。Weaviate、Pinecone、pgvector、Qdrantなどで使用されています。欠点はメモリです:HNSWインデックスはRAMを大量に消費します。Pineconeの見解 — “HNSW gives us great search-quality at very fast search-speeds — but there’s always a catch — HNSW indexes take up a significant amount of memory.” (翻訳) 「HNSWは非常に高速な検索速度で優れた検索品質を提供しますが、常に欠点があります—HNSWインデックスはかなりの量のメモリを消費します。」
  • IVF(転置ファイルインデックス) — 空間をクラスタ(k-means)に分割し、クエリ時にクエリに最も近い少数のクラスタのみを検索します(nprobe)。Pineconeはこれを “a very popular index as it’s easy to use, with high search-quality and reasonable search-speed… a good scalable option.” (翻訳) 「使いやすく、高い検索品質と妥当な検索速度を備えた非常に人気のあるインデックスであり、優れたスケーラブルなオプションです。」と呼んでいます。
  • FAISS — Facebook AIのライブラリ(Johnson、Douze、Jégou)で、数十億規模の類似性検索向け。単一のアルゴリズムではなくツールボックスです:フラットな完全一致ベースライン(IndexFlatL2)、クラスタ化されたIVF、4〜64倍のメモリ圧縮を実現する製品量子化IVFPQ、そしてHNSW実装。そのGPU適応版はk-NN検索で8,5倍の高速化を報告しています。
  • ScaNN(スケーラブルな最近傍探索) — Googleのライブラリで、オープンソース化されており、Google画像検索、YouTube、Google Playの背後にある技術と同じファミリーです。その革新は異方性ベクトル量子化です:平均距離を最小化する代わりに、“more heavily penalizes quantization error that is parallel to the original vector,” (翻訳) 「元のベクトルに平行な量子化誤差をより重く罰する」のです。なぜなら、方向性のある誤差は高内積(最も関連性の高い)結果に不釣り合いに害を及ぼすからです。その成果:ann-benchmarks.comで*“outperforms other vector similarity search libraries by a factor of two”* (翻訳) 「他のベクトル類似性検索ライブラリを2倍上回る」— 特定の精度で毎秒のクエリ数がおよそ2倍になります。
  • フラット(完全一致)インデックス — 近似を一切行わず、総当たりで最も正確ですが最も遅い。Pineconeはフラットインデックスが*“produce the most accurate results”* (翻訳) 「最も正確な結果を生み出す」と述べており、検索品質が最優先される場合やインデックスが小さい場合(約10Kベクトル未満)に適切な選択です。その規模を超えると、ANNに移行します。

The through-line: every ANN index is a dial between recall, latency, throughput, and memory. As Weaviate puts it, most vector databases let you “configure how your ANN algorithm should behave… to find the right balance.”

距離メトリクス

「Closest」には定義が必要です。一般的なものは3つあります。

  • コサイン類似度 — テキストのデフォルト。2つのベクトル間の角度を測定し、大きさを無視するため、同じトピックの短い文書と長い文書は同じようにスコアリングされます。Weaviate: “Cosine similarity is commonly used in Natural Language Processing… It measures the similarity between documents regardless of the magnitude.” (翻訳) 「コサイン類似度は自然言語処理で一般的に使用されます…大きさに関係なく文書間の類似度を測定します。」
  • ドット積(内積) — 関連性が内積によって定義される場合に使用されます(ScaNNが最適化するMIPS問題)。
  • ユークリッド距離(L2) — 直線距離。大きさが意味を持つ場合に使用されます。

実用的な近道はこれです:正規化されたベクトルでは、コサイン類似度とドット積は同じ順位付けを与えます。そして、最近のほとんどの埋め込みモデルは出力を単位長に正規化します。OpenAIは明確に述べています — “We recommend cosine similarity. The choice of distance function typically doesn’t matter much” (翻訳) 「コサイン類似度を推奨します。距離関数の選択は通常あまり重要ではありません」— それはまさに彼らの埋め込みが長さ1だからです。Weaviateによると、実際のルールはこれです:“Use the distance metric that matches the model that you’re using… There is no ‘one size fits all’.” (翻訳) 「使用しているモデルに合った距離メトリクスを使ってください…『万能なもの』はありません。」

ベクトルデータベース

ベクターデータベースはベクトルを保存し、その上でANNを実行するため、インデックスインフラを自分で構築する必要はありません。一般的な名前としては、Pinecone(マネージド)、Weaviate(ハイブリッド検索を内蔵)、ChromaFAISS(プロトタイピング/インプロセスに最適)、QdrantMilvus(セルフホストでのスケール)、そしてpgvector(Postgres拡張機能で、すでにSQLを使っているチーム向け)があります。これは列挙であってランキングではありません。適切な選択は、スケール、マネージドとセルフホストのどちらを望むか、そしてハイブリッド検索がすぐに必要なかどうかによって決まります。Google/Bingのスケールでは、「データベース」はこれらではなく、内部のScaNN/ANNインフラです。

ハイブリッド検索 — 本番環境での実際の仕組み

「キーワード検索 vs. ベクトル検索」という枠組みは誤った二分法です。純粋なベクトル検索は完全一致クエリ(エラーコード、SKU、固有名詞)を見逃し、純粋なキーワード検索は意味的バリアントを見逃します。そのため、本格的なシステムはハイブリッド検索を実行します。キーワード(BM25)とベクトル検索を並行して実行し、結果を融合(一般的にはReciprocal Rank Fusion)し、その後、上位候補をクロスエンコーダーで再ランク付けします。Microsoftはハイブリッド検索を*「同じリクエスト内でのベクトル検索とキーワード検索の実行…クエリは並行して実行され、結果は単一のレスポンスにマージされ、それに応じてランク付けされる」*と定義しています。GoogleのVector Searchも同じ3つのモード(dense(意味的)、sparse(キーワード)、hybrid)をサポートしています。このセクションから1つだけ学ぶなら、本番環境での検索はほぼベクトルのみではありません。組み合わせが勝つのです。

Google(およびBing)が実際にベクトル検索をどう使っているか

これは2023年のChatGPT時代の目新しいものではありません。このインフラはLLMの波より何年も前から存在しています。

  • ScaNN(ICML 2020、オープンソース化)は、Google Image Search、YouTube、Google Playを支え、GoogleのVector Search製品(旧Vertex AI Vector Search)の基盤となっています。これは、それらの消費者向け製品と*「同じバックエンドを共有」しています。GoogleのKaz Satoはこの技術を「Googleのコアサービスの最も重要なコンポーネントの1つ」と呼んでいます。性能仕様:「1秒あたり数万リクエスト…90パーセンタイルで10ms未満、再現率95〜98%」*。
  • Bingは2019年までに1000億以上のベクトルインデックスを実行していました。 Microsoft自身の言葉によれば、Bingは*「1000億以上のベクトルからなるこの巨大なインデックスを検索して、5ミリ秒で最も関連性の高い結果を見つける」*ことができました。これは6年以上前のことです。
  • Dense Passage Retrieval(DPR、EMNLP 2020)は、単純なデュアルエンコーダーで、密なベクトル検索がトップ20のパッセージ検索精度においてLucene-BM25を9〜19%絶対値で上回ることを証明しました。DPRは現代のRAG検索が従う青写真です。AI Overviewsの背後にある検索ステップは、このパターンの子孫です。
  • MUVERA(2025)は、マルチベクトル検索をシングルベクトル検索と同じくらい高速にします。従来の方法と比較して、およそ*「約90%低いレイテンシで10%高い再現率」*です。
  • TurboQuant(ICLR 2026)は、最近傍探索用にベクトルを圧縮し、報告によると6倍のメモリ削減と実質的にゼロの精度損失を実現します。

重要なのはロードマップを暗記することではなく、埋め込みベースの検索が大手エンジンが関連コンテンツを見つける方法であり、それが何年も続いているということです。

SEOへの影響

ここは注意して進めます。なぜなら、SEOのアドバイスは通常ここで過剰に及ぶからです。

ベクトルの近接性が候補プールへの新しいゲートです。 RAGベースの回答では、検索は生成の前に行われます。あなたのパッセージがクエリ埋め込みに意味的に近くなければ、モデルが書き出すショートリストに入ることはなく、引用されることもありません。それがメカニズムです。

しかし、「ベクトル検索最適化」のつまみはありません。 基盤となるシグナルは 意味的な一貫性とトピックの深さであり、それは質の高いコンテンツが常に 必要としてきたものです。ベクトル検索は新しいトリックに報酬を与えるのではなく、薄いコンテンツや キーワードの詰め込み(埋め込み空間で一貫した近傍を形成しない)をペナルティし、 真に包括的で構造化されたカバレッジに報酬を与えます。私が embeddingsの記事で述べたように、Danny SullivanのBERTに関する発言を反映して言えば、ここには「最適化すべき」ものはほぼありません — あなたのコンテンツが、答えるべきクエリの近くにきれいにクラスタリングされるようにするだけです。

実際に従う2つの具体的な含意:

  • チャンキングが重要です。 検索はページ全体ではなくパッセージに対して動作します。個々のパッセージがクリーンな意味的マッチでなければ、ページは何にもランクされない可能性があります。自立したパッセージを書きましょう。
  • トピックの深さとエンティティカバレッジが、埋め込み空間で正しい近傍を占める方法です。浅く散らかったコンテンツは、特定の何かの近くにもない曖昧な領域に埋め込まれます。

ベクトル検索はRAG とAI回答の背後にある検索エンジンです。パッセージランキング検索後に候補に対して行われる処理です。そして、これらのシステムに供給する AIクローラーは、取得したものを埋め込み、ベクトルインデックス化します。より広いパイプラインについては、 検索の仕組みを参照してください。

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.