セルフホスト検索エンジン 2026 完全ガイド - Meilisearch・Typesense・Manticore・OpenSearch・Vespa・ParadeDB・Orama・Elasticsearch 徹底解説

プロローグ — 検索はふたたびインフラになった

2010年代半ば、検索はSaaSの時代だった。Algoliaがインデックス・ランキング・UIウィジェットをまとめて売り、「自前で検索を書く会社などいない」というフレーズがSaaSの営業資料に定着していた。

2026年の風景はまったく違う。

• Algoliaは依然として首位だが、検索100万回あたり約1.0〜1.4 USDという料金体系は、ECやメディアにとって重すぎる。
• Elasticがライセンスを Elastic License 2.0 に変更したのち、AWSがOpenSearchをフォークして育てた結果、ALv2系OSS陣営は二つに割れた。
• Meilisearch 1.13、Typesense 27、Manticore Search 6.x が「Algolia代替」として定着した。
• ParadeDB はPostgresの中でBM25検索を完結させる新しいアプローチを作った。
• Orama(旧Lyra)はTypeScriptで書いた検索をブラウザ・エッジ・サーバーで動かす。
• AI時代のRAG需要が爆発し、ベクトル・BM25・ハイブリッドを一つのエンジンでさばく流れが固まった。

本稿は2026年のセルフホスト検索エンジン地形を、なぜセルフホストするのか、どのエンジンがどのワークロードに合うのか、韓国語・日本語のトークナイザはどこで効くのか、RAGとベクトル検索はどう絡むのか、まで一気通貫で整理する。

第1章 · なぜセルフホスティングか — コスト・統制・カスタマイズ

セルフホストを選ぶ三つの理由から。

第一に コスト。Algoliaは検索100万回あたり約1.0〜1.4 USD、レコード数も別課金。ECで1日100万検索なら月3〜5万 USD。Elastic CloudのSearch Premiumティアもノードあたり月数百 USDから。MeilisearchやTypesenseを自前運用すれば、EC2 r6g.large 一台(月約80 USD)で同じトラフィックを捌ける。

第二に データ統制。検索クエリはユーザー意図がもっとも濃く現れるデータだ。医療・金融・法務はSaaSに流した瞬間にコンプライアンス負担が増す。EUのDSA・DSPなど新規規制も検索ログの処理地点を問う。

第三に カスタマイズ。トークナイザ・ランキング・同義語・ストップワード・フィールドブースティングを自由に変えるには、結局エンジン内部に手を入れることになる。日本語や韓国語のような形態素解析が必要な言語では特にそう。

この三軸の重みが2024年から急速にセルフホスト側に動いた。

第2章 · Algolia — マネージド検索のスタンダード

まずは比較の基準としてAlgoliaを整理する。

NeuralSearchは2023年にリリースされたベクトル+レキシカルのハイブリッドだ。データはそのままで埋め込みインデックスだけ追加するため、別途ベクトルDBが要らない。DocSearchはオープンソースのドキュメントサイトに無料で導入されるAlgoliaのサブセット。

問題は価格。トラフィックが増えるほど検索1件あたりのマージンをAlgoliaが取る。セルフホスト勢の台頭はこの構造への反応だ。

第3章 · Meilisearch 1.13 — フランス発の「簡単な検索」

Meilisearchは2018年にパリで始まったMITライセンスの検索エンジン。Rust製で、ひと言要約は「Algoliaのように簡単で、セルフホストできる」。

# Dockerで一行起動
docker run -p 7700:7700 getmeili/meilisearch:v1.13

# インデックス投入 — JSON塊をPOST
curl -X POST 'http://localhost:7700/indexes/products/documents' \
  -H 'Content-Type: application/json' \
  --data-binary @products.json

# 検索
curl 'http://localhost:7700/indexes/products/search' \
  -H 'Content-Type: application/json' \
  --data-binary '{"q":"shoes","limit":5}'

特徴は以下の通り。

• タイポ許容: 編集距離1〜2の自動マッチ。「shoees」が「shoes」にヒットする。
• インスタント検索: キーストロークごとに約50ms応答が目標。平均p99で50ms以下。
• 多言語: ICUトークナイザがデフォルト、韓国語・日本語・中国語を自動判定。
• AI検索ベータ: 1.6でエンベッダ、1.13でハイブリッド検索が正式版。
• シングルノード優先: クラスタリングはv2で本格導入予定。

もっとも早く採用されるシナリオはSaaSアプリ内検索、ドキュメントサイト、中小ECだ。分散が弱いのでインデックスが100GBを超えると別のエンジンを検討すべき。

第4章 · Typesense 27 — Algoliaのオープンソース・クローン

Typesenseは2019年に始まったGPLv3の検索エンジン。C++製で、AlgoliaのAPI・ランキング・UIウィジェットをほぼそのまま踏襲。2024年のv27でクラスタリング・ベクトル検索・会話的検索まで揃えた。

# docker-compose.yml
services:
  typesense:
    image: typesense/typesense:27.0
    environment:
      TYPESENSE_API_KEY: xyz
      TYPESENSE_DATA_DIR: /data
    volumes:
      - ./typesense-data:/data
    ports:
      - 8108:8108

# コレクション作成
curl 'http://localhost:8108/collections' \
  -X POST \
  -H 'X-TYPESENSE-API-KEY: xyz' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "products",
    "fields": [
      {"name": "title", "type": "string"},
      {"name": "price", "type": "float"},
      {"name": "embedding", "type": "float[]", "num_dim": 768}
    ]
  }'

TypesenseはMeilisearchよりも クラスタリングが自然。Raftベースのレプリケーションで3ノードから安定運用できる。instantsearch.js と直接互換な点も強み。AlgoliaからTypesenseに移るECが多い理由だ。

第5章 · Manticore Search — Sphinxの正統後継

Manticore Searchは1990年代のSphinx Searchの正統後継だ。GPLv3、C++で、フルテキスト検索エンジンとして最古参の一つ。

-- ManticoreはSQLインターフェースが本拠地
CREATE TABLE products (
  title TEXT,
  description TEXT,
  price FLOAT,
  category STRING
);

INSERT INTO products VALUES (1, 'Red shoes', '...', 99.99, 'shoes');

SELECT * FROM products WHERE MATCH('red');

特徴は以下の通り。

• SQLファースト: MySQLワイヤープロトコルをそのまま受けるのでSQLクライアントから接続できる。
• フルテキスト表現: フレーズ、近接、ワイルドカード、正規表現。
• RTインデックス: リアルタイム挿入・更新。
• パーコレーション: ドキュメントでなくクエリ側を保存しておく逆向き検索。
• ベクトル検索: 6.xで追加、HNSWベース。

MeilisearchやTypesenseより チューニングの幅が大きい。インデクサ・ランカー・トークナイザを深く触れるし、大量テキストでも速い。ただし学習曲線は急。

第6章 · OpenSearch 2.x — AWSによるElasticsearchフォーク

2021年にElasticがライセンスを Elastic License 2.0 に変えたのを受け、AWSがElasticsearch 7.10のソースをフォークして作ったのがOpenSearchだ。ALv2のままで維持される。

# Helmチャートで3ノードクラスタを起動
helm install opensearch opensearch/opensearch \
  --set replicas=3 \
  --set persistence.size=100Gi

# インデックス作成
curl -X PUT 'localhost:9200/products' -H 'Content-Type: application/json' -d '{
  "mappings": {
    "properties": {
      "title": {"type": "text", "analyzer": "nori"},
      "price": {"type": "float"},
      "embedding": {"type": "knn_vector", "dimension": 768}
    }
  }
}'

OpenSearchが2.xで揃えた目玉は Neural Search。インジェスト時に埋め込みパイプラインをかませて自動でベクトルを生成し、クエリでBM25とベクトルをRRFで束ねる。

RRF(k=60) が二つのスコアを合成するデフォルト式だ。

OpenSearchの強みは分散性能。100ノード級クラスタ、1PBインデックス、マルチテナント運用まで実績がある。難点はメモリ・ディスクコストとJVMチューニング負担。ログ検索と兼用なら圧倒的に強い選択肢。

第7章 · Elasticsearch 8.x / 9.0 — ライセンスがまた分かれた本家

Elasticsearch本家は8.xから9.0に移る段階で、Vector Search(KNN)、ESQL(SQL風クエリ言語)、Search AI Platformを揃えた。

[Elasticsearch 9.0 の要点]
- ESQL: 新クエリ言語、パイプライン表現
- KNN: HNSWベースのベクトル検索、GPUアクセラレーションはベータ
- Semantic search: ELSER埋め込みを内蔵
- Search AI: RAGパイプラインを内蔵
- License: Elastic License 2.0 または SSPL を選択

もっとも大きな変化は AGPLライセンスの追加。2024年8月から ELv2・SSPL・AGPLv3 の三択になった。事実上OSS陣営に復帰するシグナルと読める。

Elasticsearchはやはり もっとも豊富な機能セットを持つ。機械学習、APM、セキュリティ、RUMまでElastic Stack(ELK)として束ねられる。ただしOpenSearchとの互換性は7.10以降だんだん離れている。

第8章 · Solr 9 — クラシック・エンタープライズの矜持

Apache Solrは2004年に始まったLucene由来のOSS検索エンジンで、最古参に近い。9.0でJava 11対応、SolrCloudのZooKeeper依存を緩めた。

<!-- managed-schema.xml -->
<field name="title" type="text_ko" indexed="true" stored="true"/>
<fieldType name="text_ko" class="solr.TextField">
  <analyzer>
    <tokenizer class="solr.KoreanTokenizerFactory"/>
    <filter class="solr.LowerCaseFilterFactory"/>
  </analyzer>
</fieldType>

Solrの強みは チューニング自由度。トークナイザ・フィルタ・ランカーをXMLで連ねて組み立てられ、韓国語Mecab-ko、日本語Kuromoji、中国語ICUなどがそろっている。

LINE Yahooは日本語検索をSolrで長く運用しており、2024年から徐々にVespaへ移行中だ。運用性・UXでElasticsearchに押されてSolrの市場は縮小したが、緻密なチューニングが必要なエンタープライズではいまだ現役。

第9章 · Vespa.ai — ヤフー発のランキングエンジン

Vespaはヤフーが2017年にオープンソース化した検索・ランキング基盤。ALv2、C++コア。ひと言要約は「BM25+ベクトル+ランキングモデルを一箇所で」。

# schema.sd — Vespaのスキーマ DSL
schema product {
  document product {
    field title type string {
      indexing: index | summary
      index: enable-bm25
    }
    field embedding type tensor(x[768]) {
      indexing: attribute | index
      attribute {
        distance-metric: angular
      }
    }
  }

  rank-profile hybrid inherits default {
    first-phase {
      expression: bm25(title) + closeness(embedding)
    }
  }
}

Vespaの差別化点は ランキングモデルをエンジン内部で回せる こと。ONNXモデルを添付して二段ランキング(first-phase、second-phase)を走らせられ、GBDT・MLP・トランスフォーマーまで使える。

ヤフーの広告・ニュース・メール検索はすべてVespa上で動く。テンソル演算をファーストクラスで扱う数少ないOSS検索エンジンだ。ただし学習曲線は非常に大きく、小規模チームには重い。

第10章 · Quickwit・Tantivy・Bleve・Whoosh — ライブラリ/特化エンジン

Quickwit はログ検索特化。オブジェクトストレージ(S3、GCS)上で直接インデックス検索を行うため「ストレージとコンピュートの分離」が成立し、ログ1TBあたりでElasticsearch比10倍以上安いと謳う。2024年にDatadogが買収し、機能の一部はDatadog内部検索に取り込まれつつある。

Tantivy はRust製のLucene風ライブラリ。他のエンジン(Meilisearch、ParadeDB、Quickwit)が内部に組み込んで使う。

Bleve はGoのフルテキスト検索ライブラリ。CouchDBの検索エンジンがBleveベース。

Whoosh は純Pythonの検索ライブラリ。性能より学習・小道具向け。

第11章 · ParadeDB・pg_search — Postgres内で完結

ParadeDBは2023年に始まった、PostgresにBM25フルテキスト検索を載せる拡張だ。中核は pg_search 拡張。

-- pg_searchをインストール後
CREATE EXTENSION pg_search;

-- BM25インデックス
CREATE INDEX product_search_idx ON products
USING bm25 (id, title, description)
WITH (key_field='id');

-- クエリ
SELECT id, title, paradedb.score(id) AS score
FROM products
WHERE title @@@ 'red shoes'
ORDER BY score DESC
LIMIT 10;

ParadeDBの強みは 一つのデータベース内で完結 すること。

• 別途の検索エンジンを運用しない — Postgres 一台で済む。
• ETL/CDCパイプラインがない — トランザクション内でインデックスが更新される。
• 権限、トランザクション、JOIN をそのまま活用できる。

pgvector と組み合わせれば BM25+ベクトルのハイブリッドまでPostgres一台で処理できる。Postgresに検索対象データの9割以上が乗っているなら、ParadeDBは非常に強い選択肢になる。

第12章 · Orama(旧Lyra) — TypeScript製の組み込み検索

Oramaは2022年にLyraの名前で始まり2023年にリブランドした、TypeScript製の検索エンジン。ブラウザ・エッジ・サーバーどこでも動く。

import { create, insert, search } from '@orama/orama'

const db = create({
  schema: {
    title: 'string',
    price: 'number',
    embedding: 'vector[768]',
  },
})

await insert(db, { title: 'Red shoes', price: 99.99, embedding: [...] })

const results = await search(db, {
  term: 'shoes',
  properties: ['title'],
  limit: 5,
})

特徴は以下の通り。

• ピュアJavaScript: 依存ゼロ、npm install 一発。
• 組み込み: インデックスをシリアライズして静的ホスティングに同梱すれば、そのまま検索できる。
• ベクトル + BM25: どちらも対応、ハイブリッドも。
• Cloudflare Workers、Bun、Node、Deno すべて対応。

小規模ドキュメントサイト、JAMstack、静的ECカタログにとてもよく合う。インデックスが数十万規模になるとメモリ・ロード時間で壁にぶつかる。

第13章 · 検索エンジンの形 — 転置インデックス・ベクトル・ハイブリッド

3つの核となる形を押さえる。

まず 転置インデックス(Inverted Index)+ BM25。

documents:
  doc1: "red shoes"
  doc2: "blue shirt"
  doc3: "red shirt"

inverted index:
  "red"    -> [doc1, doc3]
  "shoes"  -> [doc1]
  "blue"   -> [doc2]
  "shirt"  -> [doc2, doc3]

クエリ「red shirt」では red と shirt のポスティングリストを積集合し、BM25(doc, query) で並べる。50年近くの検索の標準だ。

次に ベクトル + ANN。

埋め込みモデル -> 768次元ベクトル
HNSWグラフに挿入
クエリも埋め込み -> ANN検索 -> 上位K件

セマンティック検索はここから始まる。「ランニングシューズ」と「スニーカー」が一致するのは、ベクトル空間での距離のおかげだ。

最後に ハイブリッド(BM25 + ベクトル + RRF)。二つのスコアを Reciprocal Rank Fusion で合成する。RRF(k=60) が基本式。2025年以降はほぼ全エンジン(OpenSearch、Vespa、Elastic、Meilisearch、Typesense、ParadeDB)が標準オプションとして持つ。

第14章 · マルチテナンシーとシャーディング

大規模な検索エンジンは結局二つの軸に行き着く — シャーディングとレプリケーション。

Elastic/OpenSearch はインデックスをNシャードに分割し、各シャードをR個複製する。データは hot-warm-cold ティアで動かす。ホットノードはSSD、コールドノードはオブジェクトストレージ寄りに置く。

Vespa はコンテンツクラスタをグループとディストリビュータで構成し、その上をコンテナクラスタがクエリを振る。

Meilisearch/Typesense はインデックス単位でノードを分けてマルチテナンシーを実現する。テナント = インデックス = フィルタキー。小さなテナントなら一つのインデックスにマルチテナントキーで詰め、大きなテナントなら分離。

ParadeDB はPostgresのパーティショニングとRLSをそのまま活用する。テナントごとに schema もしくは RLS ポリシーで分離。

第15章 · ジオ検索・ファセット・オートコンプリート

検索UIの定番3機能を押さえる。

ジオ検索。Elastic は geo_point マッピング、Meilisearch は _geo フィールド、Typesense は geopoint。どれも「この座標から X km 以内」のようなフィルタを支える。ECの店舗検索、デリバリーアプリ、不動産がこの上に成り立つ。

ファセット検索。色・サイズ・ブランドのようなサイド絞り込みフィルタだ。Meilisearch は facets、Typesense は facet_by、Elastic は aggregations。Algoliaが作って標準になったUIパターン。

オートコンプリート/インスタント検索。Meilisearchの instant-meilisearch、Typesenseの typesense-instantsearch-adapter がAlgoliaの instantsearch.js をそのまま受ける。キーストロークごとに50ms以内で返すのが標準。

その上に 同義語(Synonyms) と ストップワード(Stop Words) がフィールド単位で設定される。「TV」=「テレビ」=「television」を同一トークンにし、日本語の助詞「は・を・が」などはインデックスから除外する具合だ。

第16章 · 韓国語・日本語・中国語のトークナイザ

英語は空白で切れば済むが、CJKはそうはいかない。

韓国語。

• Mecab-ko: MeCabベースの形態素解析。SolrとElastic双方が対応。
• Nori: Elasticが作った韓国語アナライザ。7.x以降は内蔵プラグイン。
• Open Korean Text (OKT): Twitterベースの韓国語解析器、略語・新語に強い。

入力: "빨간 운동화를 샀다"
Noriトークン: [빨갛다(VA), 운동(NNG), 운동화(NNG), 사다(VV)]

助詞・語尾を分離し、名詞・動詞を原形に戻すのが要点。

日本語。

• Kuromoji: Solr/Lucene陣営の標準。比較的軽くて速い。
• Sudachi: ワークスアプリケーションズ製の形態素解析器。語彙が大きい。
• MeCab: 最古参の日本語形態素解析器。C++。

入力: "赤い靴を買った"
Kuromoji出力: [赤い, 靴, を, 買っ, た]

中国語。

• jieba: もっとも広く使われるPython製の中国語解析器。Elastic・Solrプラグインあり。
• ICU: Unicode標準に基づく多言語トークナイザ。精度は低いが多言語対応。

トークナイザを間違えると検索品質が一瞬で崩れる。日本語で「靴」を入力したのに「靴下」が引っかからない、「テントを張る」が「テント + 張る」に正しく切れない、といった失敗が現実に起きる。日本語検索をするならトークナイザは交渉不能の最優先決定事項だ。

第17章 · クラスタサイジング — シャード・レプリカ・ティア

大規模検索クラスタの目安。

• シャードサイズ: 30〜50GB。小さすぎるとオーバーヘッド、大きすぎるとリバランスが遅くなる。
• ノードあたりシャード数: ホットシャードは1〜3個。多すぎるとJVMヒープが破綻する。
• レプリカ数: 2が標準。3はPB級。
• JVMヒープ: ノードメモリの50%、最大31GB。それ以上はGCが壊れる。
• ディスク: ノードあたりホットはSSD、コールドはHDDかS3寄り。

Elastic・OpenSearchはILM(Index Lifecycle Management)でhot → warm → cold → deleteを自動化する。30日ホット、60日ウォーム、1年コールドのようなポリシーがよくある。

第18章 · 2026年のAI検索

検索の次のページはAIだ。

Algolia NeuralSearch はBM25とベクトルをRRFで合成し、ユーザー意図に近い結果を返す。2023年のリリース以降ECで急速に定着した。

Vespa Hybrid は一つのクエリの中でBM25、ベクトル、MLランカーを動かせる最も表現力の高い方式だ。

OpenSearch Neural Search はインジェスト時に埋め込みパイプラインをかませ、クエリ側でRRFで束ねる。モデルはBYOM(Bring Your Own Model)方式でONNX/HuggingFaceを差し込む。

Meilisearch + Embedders はv1.13で正式版になった。OpenAI・Cohere・HuggingFaceのエンベッダを設定するだけで自動的にベクトルインデックス化される。

Typesense Conversational Search はRAGを検索エンジンに内蔵した形。ユーザー質問 → 検索 → LLMによる合成回答までを一つのAPIで完結させる。

第19章 · RAGと検索の合流

検索はRAGのretrieval段階そのものだ。

[User Query]
      |
      v
[Embedder] -- クエリ埋め込み
      |
      v
[Hybrid Search] -- BM25 + vector + RRF
      |
      v
[Reranker]  -- Cohere Rerank, bge-reranker など
      |
      v
[Context Builder] -- 上位K件をLLMに注入
      |
      v
[LLM]      -- Claude / GPT / Llama
      |
      v
[Answer]

RAG親和性が高いセルフホストエンジンは三つ。

• ParadeDB: Postgres + pg_search + pgvector。一つのDB内でメタデータ・フルテキスト・ベクトルをすべて処理。
• Meilisearch + Embedders: もっとも早く立ち上がり、ハイブリッドが内蔵。
• Vespa: 最も表現力の高いランキング、多段モデルにも対応。

ElasticとOpenSearchも強力だが運用負担が大きい。10万ドキュメント未満のRAGならMeilisearchやParadeDBで十分なケースが多い。

第20章 · ケーススタディ — 韓国と日本

韓国。

• NCsoft: ゲーム内検索をElasticsearchで長く運用。2024年からGenAI検索にOpenSearchを追加。
• Coupang: カタログ検索がElasticsearchベース。韓国語トークナイザは自社開発。
• Naver: 自社検索エンジンが主役だが、外部検索ではElasticも併用。

日本。

• Mercari: 出品カタログ検索がElasticsearchベース。Kuromojiのチューニングが深い。
• LINE Yahoo: Solrで長く運用し、2024年から段階的にVespaへ移行。
• Sansan: 名刺データ検索がElasticsearch + 自社トークナイザ。

共通点は二つ。第一に 大規模では最終的に Elastic/OpenSearch/Vespa に行き着く。第二に 言語別のトークナイザに最も投資する。Nori・Kuromojiのベースに辞書追加、新語対応、ドメイン名詞追加を重ねるところが差になる。

第21章 · コストマトリクス

1日100万検索、インデックス50GBを目安とした粗い試算。

あくまで概算で、トラフィックパターン(ピーク対平均)、インデックス頻度、バックアップ/DR要件で2〜3倍変動する。

第22章 · パフォーマンス比較

ベンダー公表値と独立ベンチマークから(2025年時点)。

• Meilisearch: 100万ドキュメント、p99 50ms以下(シングルノード)。
• Typesense: 100万ドキュメント、p99 30〜50ms(3ノードクラスタ)。
• Elasticsearch: 1000万ドキュメント、p99 100〜200ms(3ノード、シャードチューニング前提)。
• OpenSearch: Elasticsearchと同等、Neural Search追加で +20ms 程度。
• Vespa: 1億超のドキュメントでも p99 100ms以下(大規模クラスタ)。
• ParadeDB: 100万ドキュメント、p99 50〜100ms(単一Postgresインスタンス)。
• Manticore: 100万ドキュメント、p99 30〜80ms。

性能だけ見ると大差はない。差は チューニング労力 と インデックスサイズが伸びたときのスケール に出る。100万件までならどのエンジンでも速い。1億件からは Elastic/OpenSearch/Vespa の分散運用実績が圧倒的に勝る。

第23章 · ユースケース別ガイド

第24章 · 移行パターン

よくある3経路。

Algolia → Typesense。API互換のおかげで最も滑らか。instantsearch.js をそのまま残し、アダプタだけ差し替える。コストが10分の1程度に下がるのが普通。

Elastic → OpenSearch。ALv2ライセンスだけが目的のケース。7.10まではAPI同一、それ以降は徐々に離れている。7.x からの移行が最も簡単で、8.x → OpenSearch 2.x は移行ツールが要る。

Elastic → Vespa。ランキングモデルやテンソル演算が中核なら。スキーマ・クエリDSLが全く異なるので実質的に再構築だ。

移行時に最も重要なのは インデックスパイプラインの再現性。検索品質を測る標準クエリセット(NDCG、MRR)を事前に作っておき、新エンジンで同じスコアを測ることで後退なしに切り替えられる。

第25章 · 運用ベストプラクティス

最後に運用面を整理して締める。

• インデックスは非同期で。Kafka・Redpanda・SQS を前段に置き、検索エンジンはコンシューマとして消費。インデックス障害が本業に飛び火しないように。
• インデックスノードと検索ノードを分ける。小さなクラスタでもインデックス負荷と検索負荷は異なるリソースを使う。
• 検索品質を測る。クリック率、ゼロ結果率、平均深さを四半期で計測。NDCG@10 / MRR をドメインクエリセットで。
• インデックスのバージョン管理。blue/green インデックスで無停止再インデックス。alias で切り替え。
• バックアップ。インデックスのスナップショットと元データの双方。インデックスだけバックアップするとスキーマ変更時に復元できない。
• モニタリング。クエリ遅延(p50/p99)、インデックスキュー長、ディスク使用量、JVMヒープ(該当する場合)。検索のゼロ結果率はビジネスKPIでもある。

検索エンジンは一度刺さると簡単には動かせない。最初にトークナイザ、ライセンス、分散モデルを正しく選ぶことが5年分の労力を節約する。

第26章 · エピローグ — 検索はふたたび面白くなった

2010年代の検索は「Algoliaを使えば終わり」だった。2020年代初頭の検索は「Elasticクラスタ運用記」だった。2026年の検索はどちらでもない。

小さなチームは Meilisearch や ParadeDB で1週間以内に検索を立ち上げる。中規模チームは Typesense や OpenSearch でクラスタを回す。大規模チームは Vespa や Elastic の上にMLランカーを載せる。AI/RAGチームは検索エンジンの上にエンベッダとリランカーを足して一つのパイプラインに束ねる。

要点は 選択肢が豊かになった ことだ。SaaSしか答えがなかった時代は終わり、OSSしか答えがなかった時代も終わった。ドメイン・トラフィック・言語・予算という4変数に合わせて道具を選ぶ — それが2026年の検索エンジニアリングだ。

参考資料

• Meilisearch Documentation
• Typesense Documentation
• Manticore Search Documentation
• OpenSearch Documentation
• Elasticsearch 8.x Documentation
• Apache Solr Reference Guide
• Vespa.ai Documentation
• Quickwit Documentation
• Tantivy GitHub
• ParadeDB pg_search
• Orama Documentation
• Algolia NeuralSearch
• Elastic License 2.0 Changes
• OpenSearch Neural Search
• Nori Korean Analyzer
• Kuromoji Japanese Analyzer
• BM25 Wikipedia
• HNSW Paper (Malkov 2016)
• Reciprocal Rank Fusion (Cormack 2009)
• Vespa Ranking Documentation
• Open Korean Text
• Sudachi Japanese Tokenizer