次世代検索エンジン 2026 — Meilisearch・Typesense・Elasticsearch・OpenSearch・Quickwit・Vespa 徹底比較(Elastic 後の風景)

プロローグ — Elasticsearch は今も巨人だが、風景は散らばった

2018 年、「検索エンジンは何にするか」の答えは事実上一つだった。Elasticsearch。ELK はログも Elasticsearch、サイト検索も Elasticsearch、推薦も(何とかして)Elasticsearch で回した。

2026 年に同じ問いを投げると、答えは少なくとも 5 方向に分かれる。

• 「in-app 検索なら Meilisearch か Typesense、わざわざ ES は使わない」
• 「ログ検索は Quickwit に移しました。S3 にそのまま置くコスパが凄い」
• 「Elastic ライセンスのせいで OpenSearch に行きました。AWS にいるなら自然」
• 「推薦・RAG・real-time AI serving は Vespa。他は追いつけない」
• 「やはり Elasticsearch。v3 ライセンスも許容範囲、ESQL がいい」

この記事は 2026 年 5 月時点で検索エンジンを率直に比較する。各エンジンの強み・弱み、そしてあらゆる所に入り込んだ hybrid search(フルテキスト + ベクトル + reranker)の現実、そして「いつ何を選ぶか」の意思決定フレームワークまで。

一行先取り結論:「フルテキスト vs ベクトル」の二分法はもう過去。2026 年の正解はほぼ常に hybrid。問題は誰が hybrid を一番滑らかにやってくれるか。

1 章 · 道具地図 — 七つ +α

まず道具を分類する。カテゴリが混ざらないように。

ほとんどの人は一度に全部評価しない。シナリオを三つ — in-app 検索、ログ検索、RAG 検索 — に絞ると候補が自然に狭まる。

• in-app 検索 — サイト検索・商品検索・ドキュメント検索。Meilisearch・Typesense・Algolia・Elasticsearch・OpenSearch。
• ログ・オブザーバビリティ — トレース・メトリック・ログ。Quickwit・Elasticsearch・OpenSearch・Loki。
• RAG・real-time AI — 埋め込み + フルテキスト + reranker。Vespa・Elasticsearch・OpenSearch・Weaviate・Qdrant・pgvector、加えて Meilisearch hybrid。

2 章 · Elasticsearch — 巨人は生きている

Elasticsearch は死んでいない。むしろ 2024〜2025 に二つの方法で反撃した。

2.1 ライセンス — SSPL/Elastic License v2 から AGPL/Elastic v3 へ

2024 年後半、Elastic は Elasticsearch と Kibana を AGPL v3(Elastic License v2 と並行)で再オープンソース化した。OpenSearch 陣営への明確なシグナルであり、OSS 寄りクラウド(Bonsai・Elastic Cloud・セルフホスト)に再び活気をもたらした。ただし AWS のマネージド Elasticsearch サービスが戻ってくる意味ではない — AWS は OpenSearch に全リソースを注いだ状態だ。

ライセンスの要点。

• AGPL v3 — 真の OSS。ただしサービスとしてホストする場合、修正コードの公開義務。
• Elastic License v2 — マネージド SaaS として再販売しない限り自由に使える。
• 二者択一 — 利用者がどちらかで受け取る。

2.2 ESQL — SQL ライクな新クエリ言語

Elasticsearch 8.11+ で ESQL(Elasticsearch Query Language)が GA。Lucene のクエリ DSL を直接書く代わりに、パイプベースの SQL ライク構文で同じ仕事をする。

FROM logs-*
| WHERE @timestamp > NOW() - 1 hour AND http.status >= 500
| STATS count(*) BY service.name
| SORT count DESC
| LIMIT 10

ESQL の意味はシンプル。「ログ・メトリック領域で Elasticsearch が OLAP に近づいた」 — Apache Doris・ClickHouse のような分析エンジンと競合できる表面を持ったというサイン。ESQL は転置インデックスではなく統計・集計に最適化された経路を使う。

2.3 ベクトル検索・hybrid が一級市民

8.x 後半から dense vector フィールドと HNSW インデックス、BM25 + kNN の hybrid 検索が標準機能だ。learning_to_rank・ELSER(Elastic が学習した sparse 埋め込み)も提供され、別途ベクトル DB なしで RAG パイプラインの中心に置く価値のある選択肢になった。

2.4 Elasticsearch の強み・弱み

• 強み:あらゆるシナリオに使える万能性、豊富なエコシステム(Kibana・Logstash・Beats・Fleet・APM)、ES 8.x の hybrid・ESQL。
• 弱み:運用の複雑さ(JVM・shard・replica・ノード調整)、価格、コールドデータコスト。大量ログを全部 hot tier に置こうとするとコストがすぐ恐ろしくなる。

3 章 · OpenSearch — AWS フォークの政治学と技術学

2021 年の ES SSPL 化に反発して AWS がフォークした OpenSearch は、5 年経って「フォーク」ではなく独立プロジェクトだ。2026 年の現状。

• ガバナンス — 2024 年 9 月、AWS は OpenSearch プロジェクトを Linux Foundation 傘下の OpenSearch Software Foundation へ移管した。SAP・Uber・Aiven・Atlassian などが founding member として参加。「AWS only プロジェクト」という認識を破り、マルチベンダーガバナンスを作った変化として大きい。
• 互換性 — OpenSearch は Elasticsearch 7.10 で分岐し、それ以降は API 互換は 1:1 ではない。ただしクライアントライブラリレベルでは依然として両対応の部分が多い。
• ベクトル — opensearch-knn プラグインで HNSW・IVF・k-NN をサポート。Faiss・Lucene バックエンドの選択可能。
• OpenSearch Dashboards — Kibana フォーク。機能ペースは Kibana より一歩遅いが追いついている。

OpenSearch を選ぶ理由はだいたい二つ。

1. AWS に住んでいてマネージド検索を使う — Amazon OpenSearch Service が最も自然な選択。
2. Elastic License v2 の SaaS 再販売制限を避ける必要がある — 自社サービスの一部として検索エンジンを露出するマネージド検索ベンダー。

ほとんどの in-app・ログシナリオで ES と OpenSearch の機能はほぼ同等。ただし ESQL のような ES の新機能が OpenSearch には別の形(PPL — Piped Processing Language)で入ってくるため、どちらかのクエリ言語にコードが書かれている場合、移行コストがある。

4 章 · Meilisearch — Rust が作ったシンプルさの美学

Meilisearch は in-app 検索に特化した Rust 製検索エンジンだ。2026 年 5 月時点で v1.13+ 系。一言で言うと 「Algolia 的体験をセルフホストで」。

4.1 なぜ人気か

• 単一バイナリ — Rust でビルドされた静的バイナリ 1 つ。JVM なし、依存関係なし。
• 設定ほぼゼロで起動 — meilisearch 一行で立ち上げて、JSON ドキュメントを POST すれば即検索可能。
• タイポ許容・prefix・ハイライト・ファセット・同義語 — in-app 検索に必要な物のほぼ全てが標準搭載。
• JS・React・Vue SDK が滑らか — InstantMeiliSearch のようなツールで 5 分あれば UI に繋がる。

4.2 2026 年の新機能 — Vector・Hybrid

Meilisearch は v1.6 で dense vector 検索を導入し、2025 年に embeddings・rerankers・hybrid が安定化した。

// Meilisearch 1.x — hybrid 検索
const results = await client.index('products').search('blue runners', {
  hybrid: {
    embedder: 'openai',
    semanticRatio: 0.7,
  },
  limit: 20,
})

semanticRatio: 0.7 は「ベクトル 70%、BM25 30% の加重で混ぜる」。0 ならフルテキストのみ、1 ならベクトルのみ。

4.3 Meilisearch の強み・弱み

• 強み:最もシンプルな運用、最も速い起動、in-app 検索に必要な物がほぼ全て標準、エッジ・セルフホスト寄り。
• 弱み:分散・シャーディングが ES ほど成熟していない(マルチノードクラスタリングが後回し)、ログ検索・OLAP シナリオには不向き、非常に大きな単一インデックス(数億ドキュメント以上)は ES の方が安定。

選ぶ場面 — 商品カタログ・ドキュメント検索・ブログ検索・小〜中規模の in-app 検索。Algolia をセルフホストで置き換えたいほぼ全てのケース。

5 章 · Typesense — C++ が作ったもう一つの in-app 強者

Typesense は C++ で書かれた検索エンジンだ。Meilisearch と同じシナリオを狙うが、思想が少し違う。

5.1 Meilisearch との違い

• 言語 — Meilisearch は Rust、Typesense は C++。どちらも単一バイナリ。性能はほぼ互角。
• 分散 — Typesense は最初から Raft ベースの分散クラスタリングをサポート。マルチノード HA が v0.x から一級市民。
• マルチテナンシー — 1 クラスターに複数コレクション、コレクション毎に API key の search scope を狭めるパターンが滑らか。SaaS の in-app 検索にフィット。
• 可視化ツール — Typesense Dashboard は ES Kibana ほどではないが、ツール自体がシンプルなので大規模ダッシュボードが要らない。

5.2 2026 年の新機能 — Conversational・Vector・Hybrid

Typesense は v0.25+ からベクトル検索・hybrid・自然言語検索を導入。「Conversational search」 — LLM と組み合わせて自然言語の質問に直接答えるエンドポイント — も v28.x で GA。

const result = await client.collections('products').documents().search({
  q: 'red running shoes under 100',
  query_by: 'name,description,embedding',
  vector_query: 'embedding:([], k: 50, alpha: 0.4)',
})

alpha: 0.4 は Meilisearch の semanticRatio と同じ概念。フルテキストとベクトルの加重。

5.3 Typesense の強み・弱み

• 強み:分散クラスタリングが一級市民、マルチテナント寄り、非常に速いレスポンス、整理された SDK。
• 弱み:コミュニティが Meilisearch より少し小さい(絶対的に小さいわけではない)、一部の自然言語・タイポ寄りシナリオで Meilisearch がやや滑らか。

選ぶ場面 — SaaS のマルチテナント in-app 検索、最初から分散が必要な in-app 検索。

6 章 · Quickwit — S3-native ログ検索と Datadog 買収

Quickwit は検索エンジン風景で最近の最大事件。Rust 製のログ検索特化エンジンで、オブジェクトストレージ(S3・GCS・Azure Blob)を一次ストレージとして使う点で ES と決定的に違う。

6.1 なぜ重要か — 「S3 にそのまま置くコスパが凄い」

ES でログを運用した人は知っている。時系列データを hot tier に置くと SSD が際限なく必要で、frozen tier・スナップショット・ILM 設定は運用負荷の半分を占める。

Quickwit のモデルは正反対。

• インデックスファイル(splits)を S3 にそのまま置き、検索時に 必要な部分だけ取得する。
• コンピュートとストレージが完全分離。検索ノードは stateless。インデックスノードのみ少しの状態。
• 単価は S3 価格。つまり EBS/SSD 比で一桁分の一。

6.2 2024 年 Datadog 買収 — その後

2024 年 10 月、Datadog が Quickwit を買収した。買収後 Quickwit OSS がどうなるかが市場の最大の関心事だったが、2025〜2026 にかけて答えは「維持される。ただしコア開発は Datadog 内部のログ・トレースシステムにより深く入る」。

• OSS 本体 — Apache 2.0 ライセンスで維持。GitHub リポも活発に更新。
• 商用クラウド — Quickwit Cloud は新規受付終了。代わりに Datadog のマネージドログが Quickwit ベースで動く。
• 新規採用リスク — 買収後、OSS の「公式マネージド」オプションが消えた形。セルフホストする自信があれば依然として最高の選択肢だが、「管理者なしでただ使いたい」会社には警告サイン。

6.3 Quickwit のデータモデル

ES と違う点二つ。

1. append-only な時系列中心 — 更新は制限的。ログ・トレースに最適化。
2. schema-less が一級市民 — JSON をそのまま受けてインデックス。動的フィールドマッピングが ES より滑らか。

クエリは Elasticsearch DSL に似た形もサポートし、OpenTelemetry・Jaeger・Grafana との統合が一級。

6.4 Quickwit の強み・弱み

• 強み:S3-native で圧倒的コスト効率、ログ・トレースシナリオに最適化、OpenTelemetry/Grafana 統合、stateless 検索ノード。
• 弱み:in-app 検索には不向き(更新が弱い)、Datadog 買収後 OSS マネージドが消えた、フルテキスト以外の機能(ベクトル・集計の一部)は ES ほど豊かではない。

選ぶ場面 — ログ・トレース・オブザーバビリティ検索、S3 にコールドデータまで全部置きたい時。

7 章 · Vespa — 本物の AI serving 検索

Vespa は興味深い位置にある。Yahoo! の社内検索・推薦インフラとして始まり、2017 年にオープンソース化、2023 年に Verizon Media から Vespa.ai としてスピンオフ。2026 年時点で v8.x。

Spotify・Wikipedia・Pinterest のような所の検索・推薦システムが Vespa で動く。何が特別か。

7.1 他の検索エンジンとの決定的違い

• テンソルが一級市民 — 埋め込み・多次元テンソルをインデックス/ストレージ/クエリで直接扱う。ベクトル検索が付加機能ではなくコア。
• ranking パイプラインが一級市民 — first-phase・second-phase・global-phase ranking が構造的にある。ONNX・TensorFlow モデルを ranking 段階で直接実行。
• real-time write + serving — インデックスとサービングが同じノード。リアルタイム更新が滑らか。

これが RAG・推薦・real-time AI serving に強い理由。

7.2 ColBERTv2 — Vespa が最も滑らかに扱う reranker

ColBERTv2 は dense retrieval と cross-encoder reranking の効率的な中間点。トークン毎の埋め込みで late interaction を計算するが、Vespa はこれを一級市民として扱う — インデックスに ColBERT テンソルを直接保存し、ranking 段階で効率的な MaxSim 計算をする。

7.3 Vespa の強み・弱み

• 強み:本物の AI serving 検索、テンソル・埋め込み・モデルが一級市民、リアルタイム更新、巨大スケールで実証済。
• 弱み:学習曲線が急、運用複雑度が ES より大きい、小規模 in-app 検索には過剰、マネージドオプション(Vespa Cloud)以外のセルフホスト運用負荷。

選ぶ場面 — 推薦システムの中核、RAG の本物の中核、検索と ranking 両方が ML モデルで動く所。

8 章 · Algolia・Sonic・Apache Doris・StarRocks — その他の風景

8.1 Algolia — SaaS サイト検索の依然 1 位

Algolia にはセルフホストオプションがない。SaaS のみ。それが強みでもあり弱みでもある。

• 強み:非常に速いレスポンス(グローバルエッジ CDN)、運用負荷ゼロ、最も成熟した InstantSearch UI キット。
• 弱み:コストが急増しやすい(レコード数・クエリ数ベース課金)、データ主権の制約、セルフホスト不可。

選ぶ場面 — トラフィックが少なく素早くリリースする in-app 検索、サイト検索・ブログ検索。トラフィック・レコード数が増えると Meilisearch・Typesense に移行するパターンが多い。

8.2 Sonic — 極端に軽い自動補完

Sonic は Rust 製の極端に軽い検索エンジン。「自動補完・suggest」に特化。SQLite 的なインデックスファイルでメモリ使用量がほぼゼロ。

• 強み:非常に軽い、起動が速い。
• 弱み:フルテキスト検索がシンプル、ファセット・ハイライトが限定的、ベクトルなし。

選ぶ場面 — 検索がほぼ自動補完で、メイン検索は別ツールが処理する時。2026 年時点で Meilisearch・Typesense がほぼ全ての自動補完を上手く処理するため、Sonic の領域は小さくなった。

8.3 Apache Doris・StarRocks — OLAP が検索を侵食

Doris・StarRocks・ClickHouse のようなカラム型 OLAP が転置インデックス・テキスト検索をサポートし始めて、「分析データの中で検索も」という新シナリオが開けた。特にログ・イベントデータのように分析と検索が同じデータで起きる場合に魅力的。

• 強み:一つのシステムで分析と検索。
• 弱み:フルテキスト検索の滑らかさ(ランキング・同義語・ファセット)は ES ほど成熟していない。

選ぶ場面 — 分析が中心で検索は付加。メインのサイト検索をこれで回すのはまだ無理がある。

9 章 · Hybrid Search — 2026 年の標準

「フルテキスト検索 vs ベクトル DB」の二分法はもう過去。2026 年の検索は ほぼ常に hybrid。その構造を解きほぐす。

9.1 hybrid の三層

1. retrieval (一次検索)
   - BM25 (フルテキスト、字句マッチ)
   - Dense vector (意味ベース、embedding ANN)
   - 二つの結果を RRF か加重和で結合

2. reranking (二次並び替え)
   - cross-encoder または ColBERT 系モデル
   - 上位 50〜200 件のみ再並び替え
   - 高価だが品質に大きく寄与

3. business logic (三次並び替え)
   - 人気度・新規性・パーソナライゼーション・ビジネスルール

この三層をどう実装するかがエンジンごとに違う。

9.2 RRF (Reciprocal Rank Fusion) — hybrid 標準の結合

二つの ranked list(BM25 結果・ベクトル結果)をどう合わせるか。最も一般的な方法が RRF。

RRF_score(d) = sum( 1 / (k + rank_i(d)) )  for each ranker i

k は通常 60。シンプルだが非常に堅牢。ES・OpenSearch・Vespa・Meilisearch・Typesense 全てが RRF かその変種をサポート。

9.3 Reranker — Cohere Rerank・Voyage・ColBERT

• Cohere Rerank — Cohere が学習した cross-encoder。API 呼び出し。クエリ毎課金。最も一般的な選択。
• Voyage AI rerankers — voyage-rerank シリーズ。Cohere の直接競合。一部ドメインでより良い。
• Vespa の ColBERTv2 — late interaction 方式。モデルがインデックスに埋め込まれて reranker が外部 API に依存しない。
• オープンソース rerankers — bge-reranker・mxbai-rerank・jina-rerank。セルフホスト。

reranking は通常 retrieval 結果の上位 50〜200 件にのみ適用する。それ以上はコストが爆発。

9.4 hybrid サポート比較表

10 章 · フルテキスト vs ベクトル DB vs 両方 — 意思決定フレームワーク

10.1 フルテキストだけで十分な場合

• 商品カタログ — SKU・名前・タグが正確に一致。意味検索の必要性が低い。
• ログ・トレース — 正確なキーワード・識別子マッチングがコア。
• 開発者ツール検索 — コード・識別子・完全一致。

→ Meilisearch・Typesense・Quickwit・Elasticsearch・OpenSearch の中でシナリオに合う物。

10.2 ベクトルだけで十分な場合

ほぼない。純粋なベクトル検索は短いクエリ・完全一致・識別子検索に弱い。 キーワード検索が同時に可能な環境がほぼ常に良い。

例外 — 画像・音声・動画類似度検索のようにテキストインデックスがないケース。この時は Pinecone・Qdrant・Milvus・Weaviate・LanceDB のような純粋ベクトル DB が自然。

10.3 hybrid が正解の場合(ほとんど)

• サイト検索の意味拡張 — "blue runners" → ランニングシューズ検索。
• RAG 検索 — ユーザー質問から文脈ドキュメント取得。
• 社内ドキュメント・ナレッジベース検索 — 同義語が多くキーワードが流動的。
• 推薦システムの 1 段階 candidate 生成。

→ Vespa・Elasticsearch・OpenSearch・Meilisearch hybrid・Typesense hybrid の中でシナリオと運用負荷のバランスで。

11 章 · 能力マトリクス — 一目で見る比較

12 章 · シナリオ別推奨 — in-app・ログ・RAG

3 シナリオを決定木で解く。

12.1 In-app 検索(サイト・商品・ドキュメント)

- トラフィック少なく速くリリース: Algolia
- セルフホスト、シンプル: Meilisearch
- セルフホスト、マルチテナント: Typesense
- ES/OS 既存、運用可能: Elasticsearch / OpenSearch
- 検索が ML で ranking される: Vespa (運用負荷を受容)

12.2 ログ・オブザーバビリティ

- コスト最優先、データ量大: Quickwit (セルフホスト)
- マネージド、AWS: Amazon OpenSearch Service
- マネージド、マルチクラウド: Elastic Cloud, Grafana Cloud Loki
- Datadog 既に利用中: Datadog (内部 Quickwit)

12.3 RAG・real-time AI serving

- 1段階 retrieval のみ: Meilisearch/Typesense hybrid + 外部 reranker
- 本格 ranking pipeline 必要: Vespa
- ES/OS 既存、運用可能: ES/OS dense_vector + reranker
- 画像・音声中心: Pinecone/Qdrant/Milvus/Weaviate
- Postgres が真実の源: pgvector + 外部 reranker

13 章 · 実例 — どこで何が使われているか

• Spotify — Vespa が検索・推薦の中核。曲・アーティスト・プレイリストの ranking。
• Wikipedia — 検索は Elasticsearch ベース(CirrusSearch)、一部の推薦で Vespa を実験。
• Pinterest — 推薦に Vespa、一部の検索に Elasticsearch。
• HackerNews 検索 — Algolia(長年のパートナーシップ)。
• Datadog ログ検索 — Quickwit(買収後内部吸収)。
• GitHub Code Search — Blackbird(自社エンジン)。2023〜2024 に ES から移行。
• GitLab 検索 — Elasticsearch。
• Notion 検索 — 自社実装 + ElasticSearch + ベクトル DB hybrid。
• Shopify — Elasticsearch ベース商品検索 + 自社 ML ranking。
• 小規模 SaaS — Algolia または Meilisearch・Typesense。

この分布から見えるパターン。

• 大規模推薦・ランキング → Vespa または自社構築。
• 大規模フルテキスト・ログ → Elasticsearch。
• ログ専用・コスト最適 → Quickwit/Datadog。
• in-app 検索 → Algolia・Meilisearch・Typesense。
• 既に AWS → OpenSearch。

14 章 · 運用コスト・複雑度 — 本当のコストはどこにあるか

エンジン選択で最もよく無視される変数が運用コスト。ライセンス価格ではなく、人の時間 + インフラ + データ移動コストだ。

14.1 インフラコスト

おおよその一桁差。

• Quickwit (S3 ベース) — 1x(基準)。
• Meilisearch・Typesense (単一ノード) — 同程度、データ量次第。
• Elasticsearch・OpenSearch (hot tier SSD) — 5〜10x(大規模ログ)。
• Algolia (レコード課金) — 小規模で安く、大規模で非常に高い。
• Vespa Cloud — 中〜上位。

14.2 運用時間コスト

• Algolia — ほぼなし(SaaS)。
• Meilisearch・Typesense — ほぼなし(単一バイナリ、運用シンプル)。
• OpenSearch・Elasticsearch — 大(shard・ノード・ILM・調整)。
• Vespa — 非常に大(学習曲線・運用複雑度)。
• Quickwit — 中(オブジェクトストレージ運用 + セルフホスト)。

14.3 移行コスト

• フルテキスト → フルテキスト(例:ES → Meilisearch) — 中程度。
• フルテキスト → AI serving(例:ES → Vespa) — 非常に大。
• in-app → ログエンジン(例:Algolia → Quickwit) — ほぼ意味なし(シナリオが違う)。

ライセンスが高そうだからとエンジンを引き剥がす前に、移行 + 運用時間 + 学習コストを合計して見る。

エピローグ — 検索はフルテキストでもベクトルでもない、検索だ

2026 年 5 月の検索風景を一行で要約すると。

「Elasticsearch は依然巨人で、in-app とログが分離し、AI serving は Vespa が獲り、あらゆる所に hybrid が入った」

意思決定チェックリスト

• シナリオは何か? — in-app / ログ / RAG / 推薦のいずれかに絞る。
• 運用人員はいるか? — いなければマネージド SaaS (Algolia・Elastic Cloud・OpenSearch Service)。
• セルフホストするなら誰が運用するか? — シンプルさ優先なら Meilisearch/Typesense。
• AGPL ライセンスは許容か? — でなければ OpenSearch。
• ログコストが爆発しているか? — Quickwit を検討。
• 検索に ML ranking モデルが入るか? — Vespa。
• hybrid が必要か? — ほぼ常に yes。どのエンジンが一番滑らかか見る。
• ベクトル DB が本当に必要か? — テキストが伴うなら hybrid エンジンの方が良い。

アンチパターン

1. 「Elasticsearch が全部やってくれる」 — 全シナリオを ES で — 運用コストがすぐ爆発。
2. 「ベクトル DB 一つで hybrid もフルテキストも」 — キーワードマッチの精度が崩れる。
3. 「Quickwit で in-app 検索」 — 更新が弱い、シナリオミスマッチ。
4. 「Vespa で全検索」 — 運用複雑度が in-app 検索には圧倒的に過剰。
5. 「Algolia で無限にスケール」 — レコード数が数千万超えればセルフホスト検討。
6. 「OS == ES」と仮定 — 7.10 以降の API・機能差が蓄積。
7. 「hybrid 使わなくても十分」 — 2026 年のユーザー期待値はそうではない。

次回予告

次の候補 — Vespa 最初の 90 日 — Spotify 風推薦システムのセルフホストガイド、Quickwit セルフホスト — S3・Kubernetes 上にログ検索を作る、Meilisearch + Cohere Rerank で 1 時間 RAG。

「検索はデータベースではない。検索はユーザー体験だ。ツールはその先で選ばれる」

— 次世代検索エンジン 2026、終わり。

参考 / References

• Meilisearch 公式
• Meilisearch GitHub
• Meilisearch Hybrid Search Docs
• Typesense 公式
• Typesense GitHub
• Typesense Vector & Hybrid Search
• Elasticsearch 公式
• Elasticsearch AGPL Announcement (Aug 2024)
• Elasticsearch ESQL Documentation
• Elasticsearch Vector Search
• OpenSearch 公式
• OpenSearch Software Foundation
• OpenSearch k-NN Plugin
• Quickwit GitHub
• Quickwit Datadog Acquisition (Oct 2024)
• Vespa 公式
• Vespa GitHub
• Vespa ColBERT Tutorial
• Algolia 公式
• Sonic GitHub
• Apache Doris
• StarRocks
• ClickHouse Full-Text Search
• Cohere Rerank
• Voyage AI Rerankers
• BGE Reranker
• Reciprocal Rank Fusion Paper
• Weaviate
• Qdrant
• Milvus
• LanceDB
• pgvector
• GitHub Blackbird (Code Search) Engineering Blog