Keyword Search

ひとことで言うと：Keyword Searchは、検索語と文書中の語・トークンの一致を主な手掛かりに候補を探す検索方式で、現代の全文検索では単純な文字列一致だけでなく、テキスト解析や転置インデックス、BM25などの関連度計算を組み合わせることが一般的です。^[1][2][3]

Keyword Searchとは

Keyword Search（キーワード検索）は、検索語に含まれる単語やトークンと、文書側に登録された語の一致を主要な手掛かりとして、関連する文書を探す検索方式です。Web検索、ECサイト内検索、社内文書検索、ログ検索、RAG（Retrieval-Augmented Generation）の検索段階など、非常に幅広い場面で使われます。

ここで最初に注意したいのは、Keyword Searchを「入力した文字列と完全に同じ文字列だけを探す仕組み」と考えないことです。完全一致検索はキーワード検索の一形態ですが、一般的な全文検索では、検索対象の文章をあらかじめ単語やトークンに分割し、必要に応じて小文字化、語形の正規化、ストップワード処理などを行い、その結果を索引に登録します。検索時にもクエリを同様に解析し、どの文書が検索語を含み、どの程度重要な一致なのかを評価します。

どうやって高速に探すのか

典型的な全文検索では「転置インデックス」が使われます。これは、文書を先頭から順番に毎回読み直すのではなく、「この語はどの文書に現れるか」を逆引きできる形で保存するデータ構造です。たとえば「vector」という語が文書Aと文書Cに現れるなら、索引側ではvectorからAとCへすぐたどれるようにします。

この仕組みにより、大量の文書に対しても高速に候補を絞り込めます。さらに、単に語が存在するかだけではなく、文書中での出現回数、コーパス全体での珍しさ、文書の長さなどを使って関連度を計算することがあります。代表例がBM25です。ElasticsearchやLucene系の全文検索ではBM25が標準的な関連度計算として使われています。

したがって、Keyword Searchの「keyword」は検索UIに入力した単語そのものを指す日常語として理解する方が安全です。Elasticsearchにはkeywordというフィールド型もありますが、これはIDやタグのような構造化値を扱うための製品固有の用語です。一般概念としてのKeyword Searchと、特定製品のkeyword型は同じものではありません。

完全一致検索との違い

たとえば検索欄に「生成AI 安全性」と入力した場合、単純な完全一致だけなら「生成AI 安全性」という連続文字列を含む文書しか見つからないかもしれません。しかし全文検索では、「生成AI」と「安全性」を別の語として解析し、両方を含む文書、一方を強く含む文書、タイトルに含む文書などを関連度順に返せます。

一方で、製品番号、ユーザーID、法令番号、固有のエラーコードのように「意味が似ている」では困る検索もあります。この場合は、完全一致やフレーズ一致を強く使う方が適切です。Keyword Searchには、曖昧さを許す全文検索と、厳密な一致を求める検索の両方があり得るため、実装を確認せずに「キーワード検索だから完全一致」と決めつけるのは危険です。

Semantic Searchとの境界

Keyword Searchと対比されることが多いのがSemantic Searchです。Keyword Searchは語の一致を中心に候補を探し、Semantic Searchは埋め込みなどを使って意味の近さを扱います。

たとえば「自動車」を検索したとき、文書に「車」しか書かれていなければ、素朴な語一致だけでは取りこぼす可能性があります。意味表現を使うSemantic Searchなら、「自動車」と「車」が近い概念であることを捉えられる場合があります。

ただし、この違いは「Keyword Searchは意味を一切扱えない」「Semantic Searchは常に意味を正しく理解する」という意味ではありません。キーワード検索でも同義語辞書、形態素解析、ステミング、クエリ拡張などで語の違いを吸収できます。逆にSemantic Searchでも、モデルが固有名詞、数値、型番、専門用語をうまく表現できず、明示的な語一致に負けることがあります。

RAGでなぜ今も重要なのか

RAGでは、質問に関係する文書を検索し、その結果をLLMへ渡します。このときKeyword Searchは古い方式として捨てられたわけではありません。型番、API名、エラーコード、人名、製品名、法令名など、文字列そのものが重要な検索では強みがあります。

また、キーワード検索は結果の理由を追いやすいという利点があります。「この語が文書に含まれていたから候補になった」と説明しやすく、検索のデバッグにも向いています。埋め込み検索だけでは、なぜ近いと判断されたかが直感的に分かりにくいことがあります。

このため、実務ではKeyword SearchとVector Searchを併用するHybrid Searchがよく採用されます。キーワード一致の強さと意味的な類似性を両方利用し、どちらか一方の弱点を補う狙いです。

検索結果を見るときのチェックポイント

「キーワード検索を採用している」と書かれていても、検索品質は方式名だけでは判断できません。元の製品説明や設定画面に戻ったら、少なくとも次を確認すると理解しやすくなります。

• どのフィールドが検索対象か。本文だけか、タイトルやタグも含むか。
• 日本語なら、どのような分かち書き・形態素解析を使うか。
• 同義語、表記揺れ、誤字、前方一致、フレーズ一致を扱うか。
• BM25などの関連度計算を使うか、単純なBoolean一致か。
• タイトルや新しさなど、語一致以外の要素でスコアを補正するか。
• 結果ゼロのとき、クエリを緩めるか、別の検索方式へフォールバックするか。

典型的な誤解

次に起こりやすい誤解は、「Vector Searchの方が新しいので、Keyword Searchは不要」というものです。実際には、検索対象やクエリの種類によって得意分野が違います。意味の近さが重要ならベクトル検索が有利な場面があり、固有語や正確な文字列一致が重要ならキーワード検索が有利な場面があります。

もう一つは、「Keyword Searchなら結果が客観的で、ランキングの恣意性がない」という誤解です。実際の検索順位は、分析器、同義語辞書、フィールド重み、BM25パラメータ、ブースト規則など多くの設計に影響されます。同じ文書集合でも、設定が違えば順位は変わります。

元文脈へ戻るために

ニュースや製品説明でKeyword Searchという語を見たら、「何を完全一致で探しているのか」ではなく、「どのテキスト表現を、どんな解析と索引で、どんな関連度規則により探しているのか」を確認するのが実用的です。

Keyword Searchというラベルだけから、検索が単純、古い、意味を扱えない、精度が低い、と推論してはいけません。逆に、高度な全文検索であることも自動的には保証されません。検索対象、解析方法、ランキング、同義語処理、他方式との併用を確認して、はじめてその検索の性格を判断できます。

日本語検索では「単語」の作り方が重要

英語では空白で単語境界を見つけやすい場面がありますが、日本語は単語間に空白を置かないため、検索エンジンがどの単位で文字列を分けるかが結果へ大きく影響します。形態素解析で「人工知能／の／安全性」のように分ける方式もあれば、一定文字数のn-gramで索引を作る方式もあります。

たとえば「機械学習」を「機械」と「学習」に分けるか、一語として扱うかで検索結果は変わります。「生成AI」「生成ＡＩ」「Generative AI」のような表記揺れを正規化するか、英数字の大文字小文字や全角半角をどう扱うかも重要です。

そのため、日本語サービスの「Keyword Search精度」を評価するときは、検索アルゴリズム名だけでなくAnalyzerやTokenizerを見る必要があります。英語ベンチマークで良い結果が出ていても、日本語で同じ挙動になるとは限りません。

RecallとPrecisionの調整

キーワード検索では、条件を厳しくすればPrecisionが上がりやすい一方、言い換えや表記揺れを取りこぼしてRecallが下がることがあります。逆に、同義語や曖昧一致を広く許すとRecallは上がってもノイズが増えます。

検索UIでAND／OR、フレーズ検索、必須語、除外語、フィールド指定などが提供されるのは、このトレードオフをユーザーやシステムが調整できるようにするためです。RAGでは、候補取得段階ではやや広く拾い、その後Re-Rankingで絞る設計もあります。

ここから、「上位10件のうち8件が良かった」というPrecision寄りの評価と、「正解文書がtop 100に入った」というRecall寄りの評価では意味が違うことが分かります。製品の「検索精度○%」という表示を見たときは、何を測った数字か確認が必要です。

検索クエリが短い場合と長い場合

Keyword Searchは、ユーザーが数語だけ入力するWeb検索型の使い方と、自然文の質問をそのまま入れるRAG型の使い方で挙動が変わります。

自然文をそのまま全文検索へ渡すと、重要でない語までクエリに含まれ、関連度が分散することがあります。そのため、検索前に重要語を抽出する、不要語を除く、製品名や日付を別フィールドのfilterに分ける、といったQuery Processingが行われることがあります。

「キーワード検索」と表示されていても、ユーザー入力がそのまま検索エンジンへ渡されているとは限りません。LLMが検索語へ書き換えるQuery Rewritingを前段に置くRAGもあり、検索方式とクエリ生成方式を分けて確認する必要があります。

評価例

FAQ検索で「パスワードを忘れた」と入力したとき、正解が「ログイン情報を再設定する」であるとします。検索エンジンへ同義語辞書を入れていなければ、Keyword Searchは「パスワード」という語を含む別FAQを上位に出すかもしれません。

このとき改善策はVector Searchだけではありません。「パスワード ↔ ログイン情報」「忘れた ↔ 再設定」といった同義語・クエリ拡張、タイトルへの重み付け、FAQ質問フィールドの優先など、Keyword Search側でも改善できます。

つまり、Keyword SearchとSemantic Searchの比較は、素朴な語一致と高度なベクトル検索を比べるだけでは公平ではありません。実運用では、双方に多くの最適化手段があります。

最終的な読み方

検索画面に「キーワード検索」とだけ表示されている場合、その名称から内部方式を断定せず、全文検索なのか完全一致なのか、どのフィールドを解析しているのかを確認します。検索結果の順位に納得できないときは、入力語だけを変える前に、同義語処理、フィールド重み、Analyzer、Filter、Query Rewritingの有無を見ると原因を切り分けやすくなります。

検索方式の名称と検索体験は一対一ではありません。同じKeyword Searchでも、Analyzer、同義語辞書、boost、fuzzy matching、Query Processingの設計によって挙動は大きく変わります。したがって、名称ではなく設定と評価結果を読むことが最終的な判断材料になります。

関連するAI用語

• Retrieval
• Semantic Search
• Hybrid Search
• Sparse Retrieval

注・出典

1. Elastic Docs, Full-text search — 検索対象テキストの解析、転置インデックス、lexical/full-text searchの基本 ↩
2. Elasticsearch Guide, Full-text search — BM25、転置インデックス、クエリ解析、関連度スコア ↩
3. Elastic Docs, Term query — 完全一致型term queryと全文検索の違い ↩

AI協働制作について