全文検索エンジンとは？仕組みと主要OSS比較、DB内蔵検索との使い分け【2026年10月】

全文検索エンジンは、文書を語の単位に分解した索引（転置インデックス）を先に作っておき、検索語を含む文書を関連度の高い順に返すソフトウェアです。索引の無いLIKE '%語%'のように検索のたびに全行を読むのではなく、索引で対象の文書を先に絞り込みます。この記事では、仕組みと日本語特有の分割の問題、Elasticsearch・OpenSearch・Apache Solr・Meilisearchなど主要エンジンの2026年10月時点の版とライセンス、そして「エンジンを立てずにデータベース内蔵の機能で済ませる」「社内文書なら全文検索システム製品を買う」という別の選択肢との境界を、実測を交えて整理します。

まとめ

全文検索エンジンを選ぶ前に、「エンジンが要るのか」を決めます。最初にSQLiteのFTS5やPostgreSQLの拡張で検索要件を満たせるか検証します。本記事の短い合成文字列20万件を使ったメモリ上の件数取得では、試した3文字以上の検索語でFTS5がLIKEより約5〜26倍速く返しました。社内のファイルサーバーやPDFを探したいだけなら、エンジン単体ではなくクローラーと検索画面を備えた全文検索システム（OSSのFessや商用製品）を選ぶ方が早く終わります。

エンジンを自前で持つと決めたら、軸は規模・運用体制・ライセンスの3つです。ログ分析も兼ねる大規模用途はElasticsearch 9.5かOpenSearch 3.9、Apache License 2.0に揃えたいならOpenSearchかSolr 10、数百万件以下のサイト内検索を手早く載せるならMeilisearch 1.56かTypesense 30.2、サーバーを持ちたくなければAlgoliaやAmazon OpenSearch Serviceです。日本語では検索語と正解文書の組を用意し、まず形態素解析またはN-gramで品質を評価します。未知語や部分一致の検索漏れが残る場合は、両方式の併用を検討します。

全文検索エンジンの仕組み｜LIKE検索との違い

全文検索は、文書を登録するときに索引を作る段階と、検索語で索引を引く段階の2つに分かれます。grepや、利用できる索引のないLIKEによる部分一致検索は、検索対象を走査します。ただし、LIKEでもDBと索引の構成によって索引を利用できます。全文検索エンジンは登録時に手間と容量を払う代わりに、検索時の読み取り量を検索語に関係する部分だけに絞ります。

転置インデックスによる語から文書への対応付け

転置インデックスは「語→その語を含む文書IDと出現位置の一覧」という対応表です。「議事録」で検索すると、エンジンは表の「議事録」の行だけを読み、該当する文書IDの集合を得ます。複数語のAND検索は、それぞれの行の文書ID集合の積を取るだけで済みます。出現位置を保存する構成なら、語の連続を判定するフレーズ検索もできます。たとえばElasticsearchのtextフィールドは、既定で語の出現位置を索引に保存します。

BM25による関連度の順位付け

ヒットした文書の並び順は、関連度スコアで決めます。Elasticsearch・OpenSearch・Solrの既定はBM25で、検索語がその文書に何回出るか（多いほど高い）、検索語がコーパス全体でどれだけ珍しいか（珍しいほど高い）、文書の長さ（長い文書ほど割り引く）の3つから点数を計算します。計算式と調整パラメータのk1・bの意味はBM25の読み方・計算式とk1・bの意味で、Pythonの実装例付きで解説しています。LIKE単体では関連度スコアを計算しないため、関連度順に表示するには別途スコアリングが必要です。更新日などによる並べ替えや表示件数の制限はSQLで指定できます。

日本語の分割：形態素解析とN-gram

英語は空白で語が区切られていますが、日本語は区切りを機械が決める必要があり、分割結果が検索漏れや誤ヒットに影響します。方式は2つあります。

• 形態素解析：辞書を使って「全文/検索/エンジン」のように意味の単位で切ります。語の単位で一致させやすい一方、辞書に無い社名・製品名・新語は意図しない分割になることがあります。検索漏れの有無は、索引側と検索側の分割結果や検索条件によって変わります。Elasticsearchではanalysis-kuromoji、OpenSearchでも同名のプラグインを使います。
• N-gram：文字列を機械的にN文字ずつずらして切ります（2文字ならbigram）。辞書が要らず検索漏れは起きにくい一方、「京都」で検索すると「東京都」の文書も拾います。索引も大きくなります。

未知語や部分一致を補いたい場合は、同じ本文を形態素解析用とN-gram用の2つのフィールドに索引化する方法があります。形態素解析側の一致を優先し、検索漏れと誤ヒットの変化を評価します。形態素解析器そのものの違いはMeCabとSudachiなど形態素解析ツールの比較、Elasticsearchでのアナライザー設定と辞書追加の手順はElasticsearchの日本語全文検索（kuromojiのanalyzer構成）、ひらがな入力で漢字の文書を拾う読み仮名変換はkuromoji_readingformの設定例で扱っています。

全文検索エンジン・DB内蔵検索・全文検索システムの違い

「全文検索」で調べると、開発者向けのエンジンと、社内文書を探すための製品が混ざって出てきます。両者は層が違い、買う・作る範囲がまったく異なります。

自社のWebサービスやECに検索機能を組み込むなら上の2層、ファイルサーバーやSharePoint、PDFの中身を社員が探せるようにしたいなら3層目です。全文検索システムの多くは内部で全文検索エンジンを使っており、たとえばFessはOpenSearchを、デスクトップ向けのInazuma SearchはGroongaを検索部分に使っています。

主要な全文検索エンジンの比較（2026年10月時点）

版番号とリリース日は各プロジェクトの公式ダウンロードページとGitHubのリリースで2026年10月27日に確認しました。全文検索エンジンは更新が速く、Meilisearchは1.55.0（10月12日）から2週間で1.56.0（10月26日）が出ています。採用時は公式で最新版を確かめてください。

ElasticsearchとOpenSearchの分岐と現在の違い

OpenSearchは、Elasticsearchが2021年にApache License 2.0をやめたことを受けて、AWSが7.10.2をもとに分岐させたプロジェクトです。2024年9月16日にはLinux FoundationがOpenSearch Software Foundationの発足を発表し、運営はAWS単独から財団へ移りました。OpenSearchの公式ダウンロードページは最新版を3.9.0（2026年9月29日）、ライセンスをApache License 2.0と明記しています。

Elasticsearch側は2024年8月29日にソースコードへのAGPLv3追加を発表し、8.16.0から、無償機能に対応する対象ソースにAGPLv3・SSPL・Elastic License 2.0の選択肢が加わりました。一方でリポジトリのLICENSEによると、x-packフォルダにはElastic License 2.0だけが適用されるコードが残っており、配布されるバイナリの既定もElastic License 2.0のままです。「ElasticsearchはOSSに戻ったから何をしてもよい」とは読まず、ソースからビルドする場合は各ファイルのライセンスを確認し、公式配布物を使う場合はELv2の条件を確認してください。最新版はElasticの公式ダウンロードページで9.5.5（2026年10月6日）です。両者のAPI互換・機能差・移行先の決め方はElasticsearchとOpenSearchの違い、OpenSearch 3系の新機能はOpenSearch 3の新機能と2.xとの違いにまとめています。

Apache Solr 10の変更点

Solrは2026年3月3日に10.0.0を公開し、検索の土台をApache Lucene 10.3へ上げました。Solr 10の主な変更点によると、サーバーの動作にはJava 21以上が必要です。密ベクトルのスカラー量子化・二値量子化にも対応しました。Solrは、Apache License 2.0が要件で、既存の設定やスキーマを引き継ぎたい場合に有力です。新規導入では、ファセット検索やストリーミング処理など、必要な機能と運用経験も比較します。

MeilisearchとTypesense：小〜中規模の即時検索

どちらも入力のたびに結果を返す検索窓（search-as-you-type）に利用できます。導入にはデータ投入と画面連携が必要で、日本語の検索品質や認証の設定も確認します。違いはライセンスです。Meilisearch 1.56.0のLICENSEファイルはCommunity EditionがMIT、Enterprise Editionの対象コードがBusiness Source License 1.1で、Enterprise Editionの本番利用には商用契約が必要です。Typesense 30.2はGPL v3です。日本語の設定や料金を含むMeilisearchの詳細はMeilisearchの使い方・日本語設定・料金で扱っています。

マネージドとSaaS：サーバー運用の負担軽減

サーバー管理の負担を減らしたいなら、Elastic Cloud、AWSのAmazon OpenSearch Service、SaaSのAlgoliaが候補です。Algoliaの料金表はFree・Grow・Grow Plus・Elevateの4プランで、Freeには月10,000検索リクエストと50,000レコードが含まれます。AWS上の選択肢の違いはCloudSearchとElasticsearch(OpenSearch)の違い、OpenSearch Serviceの料金と構築手順はAmazon OpenSearch Serviceとはを参照してください。

全文検索エンジンの選び方

規模・運用体制・ライセンスを軸に候補を絞ります。下表の件数は用途を整理するための目安で、製品の性能上限や採用境界ではありません。文書量・同時検索数・更新頻度を含めて負荷試験で判断してください。

検索対象が数万件以下で、表記ゆれへの対応や関連度順が不要なら、まず既存DBで実装します。必要な同時検索数と応答時間を満たせる限り、別の全文検索エンジンは追加しません。エンジンを別に立てると、データベースとの二重管理、更新の遅延（登録から検索に出るまでの間）、エンジン自体の版の更新という3つの運用が増えます。在庫数や残高のように、書き込んだ直後に必ず正しい値が見えなければならないデータの検索も、エンジンではなくデータベースに任せます。

データベース内蔵の全文検索で足りるかの判断（SQLite・PostgreSQLで実測）

SQLite FTS5やPostgreSQLの拡張を使えば、別の検索サーバーを追加せずに全文検索を構成できます。必要な応答時間を満たすかは、実際の文書量と負荷で検証します。ただし日本語の扱いには製品ごとに落とし穴があります。

SQLite FTS5：20万件でのLIKEとの速度比較

SQLite 3.34以降のFTS5には、文字列を3文字ずつ切るtrigramトークナイザがあり、日本語でも辞書なしで索引を作れます。平均約54文字の合成文字列20万件をメモリ上に作り、LIKEとFTS5で一致件数を取得する時間（5回の中央値）を比べたコードです。本文取得・関連度順の並べ替え・索引作成時間は測定に含みません。

import sqlite3, random, time, statistics

random.seed(42)
words = ["全文検索", "エンジン", "形態素解析", "転置インデックス", "データベース", "社内文書",
         "議事録", "見積書", "検索", "仕様書", "障害報告", "顧客", "請求", "契約", "設計",
         "レビュー", "手順", "ログ", "サーバー", "更新", "東京都", "京都", "大阪", "会議",
         "資料", "承認", "申請", "在庫", "発注", "品質"]
parts = ["の", "を", "に", "と", "は", "で", "が", "から", "まで", "について"]
rows, kyoto = [], 0
for i in range(200_000):
    ws = [random.choice(words) + random.choice(parts) for _ in range(12)]
    rows.append((i, "".join(ws)))
    kyoto += any(w.startswith("京都") for w in ws)  # 語として「京都」を含む文書

db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE docs(id INTEGER PRIMARY KEY, body TEXT)")
db.execute("CREATE VIRTUAL TABLE docs_fts USING fts5(body, tokenize='trigram')")
db.executemany("INSERT INTO docs VALUES(?, ?)", rows)
db.executemany("INSERT INTO docs_fts(rowid, body) VALUES(?, ?)", rows)

def ms(sql, arg):
    times = []
    for _ in range(5):
        t = time.perf_counter()
        hits = db.execute(sql, (arg,)).fetchone()[0]
        times.append(time.perf_counter() - t)
    return hits, statistics.median(times) * 1000

like = "SELECT count(*) FROM docs WHERE body LIKE '%' || ? || '%'"
match = "SELECT count(*) FROM docs_fts WHERE docs_fts MATCH ?"
print("SQLite", sqlite3.sqlite_version)
for q in ["議事録", "形態素解析", "転置インデックスの", "京都"]:
    h1, t1 = ms(like, q)
    h2, t2 = ms(match, '"' + q + '"')
    print(f"{q}: LIKE {h1}件 {t1:.1f}ms / FTS5 {h2}件 {t2:.1f}ms")
print(f"語として「京都」を含む文書: {kyoto}件")

macOS（Intel Core i9-9880H）のPython 3.9.6・SQLite 3.51.0で実行した出力です。

SQLite 3.51.0
議事録: LIKE 66748件 167.2ms / FTS5 66748件 6.5ms
形態素解析: LIKE 66765件 163.2ms / FTS5 66765件 35.7ms
転置インデックスの: LIKE 7834件 195.3ms / FTS5 7834件 14.6ms
京都: LIKE 112667件 155.0ms / FTS5 0件 0.0ms
語として「京都」を含む文書: 66958件

3文字以上の語では、FTS5は同じ件数を約5〜26倍の速さで返しました。倍率は語によって違い、FTS5側の時間は実行ごとにもぶれます（「形態素解析」は同じデータで繰り返すと14〜36ミリ秒）。一方で2文字の「京都」はFTS5で0件です。これは不具合ではなく仕様で、SQLiteのFTS5のドキュメントは「3文字未満の部分文字列を全文検索クエリに使うと、どの行にも一致しない」と明記しています。日本語は「京都」「契約」「顧客」のように2文字の重要語が多いので、trigramだけで日本語の検索窓を作ると利用者は「検索できない」と感じます。2文字の語はLIKEに切り替える処理をアプリ側に入れてください。LIKE側の112,667件のうち、語として「京都」を含む文書は66,958件で、残りの45,709件は「東京都」の一部に一致しただけの文書でした。部分一致で探す方式の誤ヒットはこの形で起きます。

PostgreSQL：標準全文検索の日本語分割の制約

PostgreSQLにはto_tsvectorと@@演算子による全文検索が標準で入っていますが、組み込みのパーサはdefaultの1種類だけで、日本語の語の区切りを判定できません。PostgreSQL 18.6で次のSQLを実行しました。

SELECT count(*) AS 構成数, bool_or(cfgname ILIKE '%japan%') AS 日本語あり FROM pg_ts_config;
SELECT to_tsvector('simple', '全文検索エンジンの仕組みを解説します');
SELECT to_tsvector('simple', '全文検索エンジンの仕組みを解説します')
       @@ to_tsquery('simple', '全文検索') AS ヒット;

 構成数 | 日本語あり
--------+------------
     30 | f
(1 row)

               to_tsvector
------------------------------------------
 '全文検索エンジンの仕組みを解説します':1
(1 row)

 ヒット
--------
 f
(1 row)

標準の検索構成は30種類で日本語用はありません。文全体が1つの語として索引に入るため、「全文検索」で検索しても一致しません。PostgreSQLで日本語の全文検索をするなら、Groongaを組み込む拡張PGroonga（最新は2026年10月9日の4.1.0）か、2文字単位で索引を作るpg_bigmを入れます。pg_bigmはPostgreSQLのGIN索引を使い、PGroongaは独自の索引方式を持ちます。GIN索引の仕組みと作り方はPostgreSQLのGINインデックスの仕組みと作成方法、MySQLとの全文検索の違いはPostgreSQLとMySQLの違いで比べています。

MySQL：InnoDBのngramパーサ

MySQLはInnoDBのFULLTEXT索引にWITH PARSER ngramを付けると、日本語を文字単位で切って索引化できます。MySQL 8.4のリファレンスによると、切り出す文字数ngram_token_sizeは既定が2、設定できる範囲は1〜10です。既定の2文字ならSQLiteのtrigramのような2文字語の取りこぼしは起きませんが、「京都」で「東京都」を拾う誤ヒットは同じように起きます。

全文検索システム（社内文書検索）の選び方

社員がファイルサーバーやクラウドストレージの文書を探す用途では、エンジン単体では足りません。WordやExcel、PDFから本文を取り出す処理、フォルダを定期的に巡回するクローラー、検索画面、そして「その文書を見る権限がある人にだけ結果を出す」仕組みが要るからです。全文検索システムを選ぶ際は、本文抽出・巡回・検索画面に加え、検索結果の権限制御と認証連携の対応範囲を製品ごとに確認します。

• Fess：Apache License 2.0のOSSで、公式サイトでは最新版が2026年10月15日公開の15.9.0です。内蔵クローラーがHTML・PDF・Office文書からテキストを取り出し、OpenSearchに登録します。15.9.0ではOpenSearchの同梱をやめ、OpenSearch 3.9を基準にしたため、OpenSearchをbin/fess-setup install opensearchで別に入れる必要があります。
• Inazuma Search：個人のPC内の文書を探すデスクトップ向けの無料ソフトで、配布ページによると最新は2026年7月29日の1.3.0です。検索部分にGroonga、Officeファイルからの文字抽出にxdoc2txtを使っています。
• 商用のエンタープライズサーチ製品：アクセス権限の連携、OCRで画像PDFを読む機能、保守サポートを含めて買う形です。比較するときは、対応するファイル形式、ファイルサーバーやMicrosoft 365の権限をそのまま反映できるか、更新した文書が検索に出るまでの間隔、の3点を見積もりの前に揃えてください。

既製品の権限モデルや対応形式が社内の文書管理と合わず、検索を業務システムの一部として組み込みたい場合は、文書管理システム開発として全文検索エンジンを組み込んだ仕組みを作る方法もあります。

Elasticsearchで全文検索を始めるときの手順

Elasticsearchを使って全文検索を構築する場合は、採用判断、環境構築、日本語設定の順に進めます。Elasticsearchは機能が多いため、手順ごとに記事を分けて解説しています。始める順に並べると次のとおりです。

1. 全体像と採用可否の判断：Elasticsearchとは？転置インデックスとシャード設計・ライセンス系列で決める採用可否
2. 手元で起動する：ElasticsearchのDocker構築（単一ノードと3ノードのcompose定義）。自動設定の条件を満たす新規ノードでは、初回起動時にHTTP通信のTLS証明書とelasticユーザーのパスワードが設定されるため、古い記事にあるhttp://localhost:9200へ認証なしで接続する手順は通りません。
3. 日本語のアナライザーを設定する：kuromojiのanalyzer構成と辞書追加、N-gram併用の判断
4. 意味で探す検索を足す：Elasticsearchのベクトル検索（dense_vectorとkNN）

ベクトル検索・ハイブリッド検索との関係

同義語の展開などを設定していないキーワード検索では、「退職手続き」という検索語で「離職の届出」とだけ書かれた文書を見つけにくくなります。この弱点を埋めるのが、文章を数値ベクトルに変換して意味の近さで探すベクトル検索です。ただし、ベクトル検索は型番やエラーコード、人名のような完全一致が欲しい検索に弱く、全文検索を置き換えるものではありません。両方式を組み合わせる方法に、BM25の結果とベクトル検索の結果を合成するハイブリッド検索があり、Elasticsearch・OpenSearch・Solr 10はいずれも1つの製品の中でベクトル索引を扱えます。2つの検索の違いはベクトル検索とセマンティック検索の違い、結果を合成するRRFの仕組みと実装はハイブリッド検索の仕組み・RRF・実装コードで解説しています。

よくある質問

全文検索エンジンとデータベースの違いは何ですか？

データベースのLIKE検索は文字列が一致するかを判定するだけで、関連度スコアは計算しません。構成によっては索引を使え、ORDER BYで更新日順などに並べ替えることもできます。全文検索エンジンは転置インデックスで該当文書を直接引き、BM25などのスコアで関連度の高い順に並べます。本記事の短い合成文字列20万件を使ったメモリ上の件数取得では、試した3文字以上の検索語でSQLite FTS5がLIKEより約5〜26倍速く返しました。データベース内蔵の全文検索でも関連度順に検索できます。専用エンジンを追加するかは、検索品質・負荷・更新反映の要件を既存DBで満たせるかで判断します。

無料で使えるオープンソースの全文検索エンジンはどれですか？

OpenSearch（Apache 2.0）、Apache Solr（Apache 2.0）、Meilisearch Community Edition（MIT）、Typesense（GPL v3）、Groonga（LGPL 2.1）はソフトウェアの費用がかかりません。Elasticsearchも無償機能の対象ソースではAGPLv3を選べますが、配布物の既定はElastic License 2.0なので、他社にサービスとして提供する形で使うときは条項を確認してください。社内文書を探すシステムをOSSで組むならFess（Apache 2.0）が候補です。

全文検索エンジンのシェアやランキングはありますか？

この記事の調査では、全文検索エンジンの市場シェアを示す一次統計は確認できませんでした。開発者の関心の目安としてはGitHubのスター数があり、2026年10月27日時点でElasticsearch 78,400、Meilisearch 59,684、Typesense 27,053、OpenSearch 13,913でした。Solrは2021年にLuceneとリポジトリを分けたため、現在のapache/solrのスター数（1,691）は利用実態を反映しません。スター数は本番での採用数とは一致しないため、選定は規模・運用体制・ライセンスで決めてください。

ElasticsearchとSolrはどちらを選ぶべきですか？

どちらもApache Luceneを基盤にしており、検索の中核機能は共通です。ログ分析や可視化まで含めて使う、情報量の多さを重視するならElasticsearch（またはOpenSearch）、Apache License 2.0が必須でSolrの設定資産があるならSolr 10です。Solr 10はサーバーの動作にJava 21以上を求めるので、古いJava環境のまま更新することはできません。

日本語の全文検索で検索漏れと誤ヒットを減らすには？

形態素解析では未知語の分割によって検索漏れが起きることがあり、N-gramによる部分一致では「京都」で「東京都」を拾うことがあります。検索漏れの原因が未知語や部分一致にある場合は、両方式で索引化し、形態素解析側の一致を優先する構成を検討します。社名・製品名はユーザー辞書に登録し、全角と半角、ひらがなとカタカナの正規化も入れます。SQLiteのtrigramを使う場合は、2文字の語が一致しない仕様に合わせてLIKEへの切り替えを用意してください。

関連記事

• Elasticsearchとは？転置インデックスとシャード設計・ライセンス系列で決める採用可否
• ElasticsearchとOpenSearchの違い｜ライセンス・API互換・機能差から移行先を決める
• Meilisearchとは？Rust製OSS全文検索エンジンの使い方・日本語設定・料金【v1.55対応】
• BM25とは？読み方・計算式とk1・bの意味、Python実装（rank_bm25・bm25s）の落とし穴
• ハイブリッド検索とは？RAGでBM25とベクトル検索を統合する仕組み・RRF・実装コード