2026.08.26 データベース

Elasticsearchとは？転置インデックスとシャード設計・ライセンス系列で決める採用可否

Elasticsearchは、Apache Luceneの索引をHTTPとJSONで扱えるようにし、その上へ分散の仕組みを載せた検索エンジンです。導入で詰まるのは検索そのものよりも、シャード本数・ヒープ・同期方式・ライセンス系列といった、後から変えにくい値の決め方にあります。全文検索という技術一般の仕組みと主要OSSの比較、そして日本語解析の実装手順は全文検索エンジンの仕組みと主要OSSを比較した記事が担当するため、ここでは製品としての内部構造と、2026年8月時点の版・ライセンスを踏まえた採用判断に絞ります。

まとめ：着手前に決めておく5つの値と結論

設計の入口で確定させたい値は5つあります。いずれも運用開始後の変更に再投入や停止を伴うため、要件が固まりきる前でも仮の数字を置いておくと後戻りが減ります。

プライマリシャード本数：1シャードが10GB〜50GBに収まる本数。作成後は直接変更できません
レプリカ数とノード台数：可用性を求めるならレプリカ1・マスタ候補3台から
JVMヒープ：総メモリの50%以下、かつ31GB手前。残りはファイルシステムキャッシュへ回します
正本の置き場所：業務データの正本はRDBに残し、検索用の非正規化コピーを持たせる形が既定路線
ライセンス系列：本家の9.5系（Elastic License 2.0／SSPL／AGPLv3の三択）か、分岐したオープンサーチ系か

結論から言えば、検索対象が数百万件を超え、日本語の表記ゆれや同義語まで扱う要件があるなら本家Elasticsearchが妥当な選択になります。逆に対象が単一テーブルで数十万件、要件が前方一致と部分一致の範囲に収まるなら、RDBの全文検索機能や軽量な検索エンジンで足ります。分かれ目は検索機能の差ではなく、クラスタの運用に人手を割けるかどうかです。日本語の文書を扱う場合は、Elasticsearchの日本語全文検索｜kuromojiのanalyzer構成と辞書追加、N-gram併用の判断でanalyzerの組み立てと辞書運用を整理しています。

Elasticsearchの実体｜Luceneの索引に分散を足した層

製品としてのElasticsearchは、検索の中核をApache Luceneに任せ、その周囲を三層で包んだ構造をとります。中心が転置インデックスを持つLuceneの索引、その外側がドキュメント指向のデータモデルとREST API、さらに外側がシャードとレプリカによる分散レイヤです。この切り分けを押さえると、どの設定がどの層に効くのかを判断できます。検索の速さに効くのは内側の索引設計、可用性とスループットに効くのは外側の分散設計、という対応関係になります。

転置インデックスとセグメント｜更新が1秒遅れて見える理由と運用上の注意点

転置インデックスは、文書から単語を引くのではなく、単語から文書番号を引ける形へ反転させた索引です。Luceneはこの索引をセグメントという不変のファイル単位で書き出します。既存のセグメントは書き換えられず、更新は新しいセグメントの追加と古い文書への削除マークで表現され、後からマージによって整理されます。

この構造のため、書き込んだ直後の文書はすぐには検索結果に現れません。既定では1秒間隔でリフレッシュが走り、そこで初めて新しいセグメントが検索対象になります。ニアリアルタイムと呼ばれる挙動で、更新即座の一貫した読み取りを前提にした設計とは相容れないものです。初期ロードのように大量投入する場面では、リフレッシュ間隔を一時的に止めてから戻す手が使えます。

PUT /articles/_settings
{ "index": { "refresh_interval": "-1" } }

投入が終わったら既定値へ戻し、明示的なリフレッシュを一度かければ検索できるようになります。逆に間隔を短くしても、セグメントが小刻みに増えてマージ負荷が上がるだけで、検索が速くなるわけではありません。

ドキュメント指向とマッピング｜text型とkeyword型の分岐

データはJSONのドキュメントとして格納され、フィールドの型はマッピングで決まります。ここで型を取り違えると、直すには再投入が要ります。分岐の中心は2つの型です。text は解析器にかけて単語へ分割し、部分一致や関連度の計算に使います。keyword は解析せず値をそのまま保持し、完全一致・集計・ソートに使います。

商品名のように「検索もしたいが集計もしたい」フィールドは、マルチフィールドとして両方を持たせる書き方が定石になっています。

"name": {
  "type": "text",
  "fields": { "raw": { "type": "keyword" } }
}

明示的なマッピングを与えないと、最初に投入された値から型が推測されます。型が決まると検索側の書き方も決まるため、ElasticsearchのクエリDSLとmatchとtermの分岐と併せて設計してください。数字だけの文字列が数値型として確定してしまう、日付の書式違いで投入が弾かれるといった事故は、この自動推測が原因になりがちです。本番用のインデックスでは、動的マッピングを無効化するか、テンプレートで型を固定しておく運用を勧めます。

クラスタ設計｜シャードとヒープを各公開数値から安全に逆算する

分散レイヤの設計は、感覚ではなく公開されている数値から逆算できます。Elastic社のシャードサイジング指針には具体的な上限が示されており、そこから本数とノード台数が決まります。

プライマリシャード本数｜10GB〜50GBを基準に安全に逆算する手順

指針では、1シャードのサイズを10GB〜50GBへ収め、1シャードあたりの文書数を2億未満に抑える形が示されています。加えてノードあたりのシャード数にも上限があり、frozen階層でない通常のノードでは1000シャード、専用のfrozenノードでは3000シャードが上限です。マスタ候補ノードについては、3000インデックスあたり1GBのヒープが目安とされています。

想定インデックス総量	プライマリ本数の目安	備考
10GB未満	1	分割の利点が出ない
10GB〜100GB	2〜4	1本30GB前後を狙う
100GB〜500GB	5〜12	ノード台数と揃える
500GB超・時系列	日次や週次で分割	データストリーム前提

注意したいのは、シャードが不変であり本数を後から直接変更できない点です。増減にはSplitやShrink、あるいは新しいインデックスを作ってのReindexが必要で、いずれもデータ量に比例した時間と一時的な容量を消費します。読み取りの並列度を上げたいからと最初に本数を多く取る設計は、シャードごとのオーバーヘッドが積み上がってかえって遅くなります。迷ったら少なめに置き、伸びる兆しが見えた時点で分割するほうが安全でしょう。

レプリカとノード役割｜可用性と読み取りの配分を設計する判断軸

レプリカはプライマリの複製で、ノード障害時の引き継ぎ先になると同時に、検索リクエストの受け皿としても働く仕組みです。レプリカ1で可用性の最低線が引け、読み取りが重いなら2まで増やす判断もあり得ます。ただし増やした分だけディスクと投入コストが倍数で乗ってきます。

ノードごとに役割の割り当てが可能です。小規模なうちは全ノードが全役割を兼ねる構成で構いませんが、クラスタ状態の管理が不安定になったら、マスタ候補を3台に固定してデータ処理から切り離します。取り込み前処理が重い場合はingest役割を、集約処理の負荷が高い場合は調整専用ノードを分ける、という順序になります。単一ノード構成は検証用と割り切り、本番では最低3台を前提に見積もってください。

JVMヒープの上限｜半分と31GBという二段の制約を守る理由

ヒープには性質の異なる上限が二段でかかります。ひとつはノード総メモリの50%以下という線で、残りをOSのファイルシステムキャッシュに残すためのものです。Luceneの索引はこのキャッシュ経由で読まれるため、ヒープの取りすぎは検索そのものを遅くする要因です。もうひとつがポインタ圧縮の閾値で、これを超えるとオブジェクト参照が圧縮されなくなり、メモリ効率が落ちます。26GB程度なら安全、環境によっては30GB前後まで有効という説明が公式に示されています。

実務では Xms と Xmx を同値に固定し、総メモリの半分かつ31GBを超えない範囲で決めます。64GBのノードなら31GB、32GBのノードなら16GBという読み替えです。9系ではノードのロールと総メモリから自動でサイズが決まるため、特段の要件がなければ既定のまま運用し、ヒープ逼迫が観測されてから手当てする順序で構いません。稼働後に実測して詰め直す手順はElasticsearchのチューニングと遅いクエリの特定手順にまとめています。

RDBとの役割分担｜業務データの正本をどちらに置くかで線を引く

設計の議論が長引きやすいのが、既存のRDBとの関係です。線引きの基準は機能比較ではなく、正本をどちらに置くかという一点に集約されます。

正本はRDBに残す｜検索用の非正規化コピーを置く構成にする理由

Elasticsearchには、複数の文書にまたがるトランザクションも、外部キーによる整合性の保証も、一意制約もありません。金額や在庫のように整合性が要る値を単独で預けるのは避けたほうが無難です。一方で、結合済みの状態を1文書に持たせ、単語単位で引ける形にしておく処理は得意分野になります。

したがって、業務データの正本はRDBに置き、検索対象のフィールドだけを非正規化してElasticsearch側へ複製する構成が既定路線になります。検索結果として返すのは識別子と表示用の最小項目にとどめ、詳細はRDBから引き直す形にしておくと、索引の再構築も軽く済みます。データベース側の選び方そのものはデータベースの種類と選定基準を整理した記事を参照してください。

同期方式の三択｜二重書き・変更データ取得・洗い替えの実装時の選定基準

複製をどう追従させるかで、運用の手触りが変わります。実装で選ばれるのは次の3方式です。

方式	反映の遅れ	実装の重さ	向く場面
アプリからの二重書き	ほぼ即時	軽い	更新経路が1本
変更データ取得（CDC）	数秒	重い	更新経路が複数
定期バッチで洗い替え	数分〜1日	軽い	マスタ系の参照

二重書きは手軽な反面、片方だけ成功した場合のずれが残る点は弱みです。管理画面や一括取り込みなど更新経路が増えるほど破綻しやすく、途中でCDCへ切り替える判断が要ります。洗い替えは実装が単純で、索引を作り直してから別名を張り替える手順にすれば無停止で入れ替えられます。更新頻度が低いマスタ系のデータなら、この方式で十分に回るでしょう。

RDB内の全文検索で足りる分岐点と専用基盤へ移る判断基準はどこか

PostgreSQLの全文検索型やMySQLのN-gramパーサを使えば、追加の基盤を持たずに部分一致の検索が組めます。対象が単一テーブルで数百万行に収まり、同義語辞書や関連度の細かい調整が要らないなら、この範囲で足ります。両者の全文検索まわりの差はPostgreSQLとMySQLを比較した記事で扱いました。逆に、複数テーブルを結合した結果を横断で検索する、表記ゆれや同義語を辞書で吸収する、絞り込み条件と件数集計を同時に返す、といった要件が入った時点で専用の検索基盤へ寄せる判断になります。

ライセンスの変遷と現行系列｜2026年8月時点の選択肢と判断基準

Elasticsearchの選定では、機能よりライセンスの経緯が論点になる場面があります。社内の配布物へ組み込む場合や、検索機能そのものをサービスとして提供する場合は、系列の違いが契約条件に直結するためです。

Apache 2.0からSSPL、そしてAGPLv3の追加まで

もともとはApache 2.0で提供されていましたが、2021年の7.11でSSPLとElastic Licenseの二重ライセンスへ移行しました。マネージドサービスとして再提供する事業者への対応が背景にあります。その後2024年に、OSI承認のAGPLv3が選択肢として加えられ（8.16の手前の時期）、現在はElastic License 2.0・SSPL 1.0・AGPLv3の三系列から選べる状態です。既定の配布物はElastic License 2.0の条件で提供されます。

自社サービスへ組み込んで利用するだけなら、既定の配布物のままで支障が出る場面は限られます。判断が要るのは、Elasticsearchの機能を第三者へマネージド提供する場合と、ソースを改変した成果物を配布する場合です。該当しそうなら、ソースファイルのヘッダに記載された条件を確認したうえで系列を選んでください。

分岐したオープンサーチ系との違いと寄せ先を決めるための判断基準

2021年のライセンス変更を機に、7.10.2の時点からAWS主導で分岐した派生系列があります。分岐直後はAPIがほぼ共通でしたが、その後は双方が独自に機能を足しており、現在は別実装として扱うのが実態に近い状況です。クライアントライブラリも系列ごとに分かれているため、後から乗り換える際は接続部分の書き直しが発生します。両系列の非互換点とクライアント互換、移行方向ごとに使える手段はElasticsearchとOpenSearchの違いを整理した記事で扱っています。

寄せ先の決め方は単純です。AWS上で運用ごと預けたい、権限管理をIAMへ寄せたいなら派生系列のマネージドサービスが素直で、料金体系と構築手順はAWSのマネージド検索サービスを扱った記事にまとめています。AWS内で他の検索サービスとも見比べるならAWSの検索サービスを比較した記事が早いでしょう。一方、本家が先行して入れる機能を追いたい、あるいはElastic Cloudやオンプレミスを含めて配置を選びたいなら本家系列を選びます。2026年8月時点の本家の最新は9.5系（9.5.2）で、クエリ実行のバッチ化やES|QLの拡張が入りました。

採用してよい条件と、見送ってよい場面を運用体制から線引きする

ここまでの内容を、採用可否の判断として言い切ります。検索エンジンの導入は、機能要件よりも運用体制の話として決めたほうが後悔が少なくなります。

採用条件｜運用に人手を割ける前提が揃っているかを確認する判断軸

次の3条件が揃うなら採用してよいと考えます。第一に、検索対象が数百万件規模へ達し、表記ゆれや同義語を辞書で吸収する要件があること。第二に、絞り込みの条件と件数集計を同じリクエストで返したいこと。第三に、クラスタの監視とバージョン更新へ人手を割ける体制があることです。特に三つ目が抜けると、ディスク逼迫やヒープ逼迫で書き込みが止まる事象に対応できず、検索が止まったまま放置される状態へ陥ります。

体制が読めない段階なら、まずはマネージドサービスで始めて、運用の手触りを掴んでから自前構成を検討する順序が現実的でしょう。設計の初期段階で、シャード本数・同期方式・監視項目の3点を先に紙へ落としておくと、後戻りの幅が小さくなります。こうした検索基盤やデータ基盤の設計と構築はデータ分析基盤構築・MLOps構築支援でも引き受けており、既存のRDBを正本に残したまま検索層だけを切り出す構成の相談も承ります。

見送る場面｜対象が小さいときに運用負荷から代替を選ぶ判断基準

逆に、次のいずれかへ当てはまるなら見送って構いません。検索対象が単一テーブルで数十万件に収まる場合、更新の即時反映が要件として固い場合、運用を担当できるのが1人だけの場合です。前の二つはRDB内の全文検索で足り、最後の場合は運用の軽い検索エンジンを選ぶほうが結果的に回ります。Rust製で単一バイナリとして動く選択肢は軽量な全文検索エンジンを扱った記事で取り上げました。

また、ログの蓄積と業務検索を同じクラスタへ同居させる構成も避けたほうが無難です。ログは時系列で量が膨らみ、保持期間の設計とシャード戦略が業務検索とは別物になります。同居させると、片方の投入負荷がもう片方の検索遅延として現れます。