--- title: "ElasticsearchとOpenSearchの違い｜ライセンス・API互換・機能差から移行先を決める" url: "https://www.issoh.co.jp/tech/details/17013/" published: 2026-08-26 updated: 2026-08-27 categories: ["データベース"] publisher: "株式会社一創" --- # ElasticsearchとOpenSearchの違い｜ライセンス・API互換・機能差から移行先を決める ElasticsearchとOpenSearchは、2021年まで同じソースコードだった検索エンジンです。分岐から5年が経ち、いまは「似ているが取り替えは効かない別実装」という距離感になりました。製品としてのElasticsearchの内部構造やシャード設計は[Elasticsearchの転置インデックスとシャード設計を扱った記事](https://www.issoh.co.jp/tech/details/17011/)が担当するため、ここでは2つの系列の差そのものと、どちらへ寄せるかの判断材料に絞って整理します。 ## まとめ：先に決める4点と、寄せ先の結論 比較を始める前に、判断の分かれ目になる4点を先に置いておきます。いずれも後から変えると再投入や接続部分の書き直しを伴うため、要件が固まる前でも仮置きしておくと後戻りが減ります。 - **ライセンス系列**：OpenSearchはApache 2.0の単一。Elasticsearchは既定配布のElastic License 2.0にSSPL 1.0とAGPLv3を加えた三択 - **有償機能に払うか**：フィールド単位のアクセス制御・シングルサインオン・アラート・異常検知は、Elasticsearchでは有償階層、OpenSearchでは無償の同梱 - **接続層の作り**：クライアントライブラリは系列ごとに分かれており、共通化はできません。乗り換え時は接続部分の書き換えが確定します - **移行の方向**：Elasticsearch 7.11以降からOpenSearchへのインプレース移行経路は用意されておらず、逆方向も同様。実務は再投入になります 結論から言えば、AWS上で運用ごと預けたい、権限管理をIAMへ寄せたい、そして追加費用なしでアクセス制御とアラートまで揃えたいならOpenSearchが素直な選択になります。逆に、ES|QLのような本家が先行して入れる機能を追いたい、Elastic Cloudやオンプレミスを含めて配置を選びたいならElasticsearchです。分かれ目は検索性能の優劣ではなく、有償階層に払うか、AWSの運用へ寄せるかという調達側の条件にあります。2026年8月時点の最新は本家が9.5.2（2026-08-20）、OpenSearchが3.8.0（2026-08-05）で、どちらも活発に版を重ねています。 ## フォークの経緯｜7.10.2で分かれてからの5年で何が変わったか この2つを比べるときにまず押さえたいのは、分岐点がバージョン7.10.2だという事実です。ここまでは同じコードなので、その時点のAPIや概念はほぼ共通しています。逆に言えば、7.11以降に本家へ入った機能はOpenSearchには存在せず、OpenSearchが独自に足した機能も本家にはありません。 ### 分岐点は7.10.2｜共通の土台がどこまで続くかを製品の版で押さえる 2021年2月、Elasticsearchは7.11でApache 2.0からSSPLとElastic Licenseの二重ライセンスへ移行しました。マネージドサービスとして再提供する事業者への対応が背景にあります。これを受けてAWSは、Apache 2.0だった最後の版である7.10.2を基点にフォークし、同年7月にOpenSearch 1.0を出しました。可視化のKibanaも同じ時点から分かれ、OpenSearch Dashboardsという別名で開発が続いています。 つまり「共通の土台」は7.10.2相当までです。ドキュメント指向のデータモデル、転置インデックス、シャードとレプリカ、`_doc`や`_search`といった基本のエンドポイントは両系列で同じ形をしています。ここが、移行を検討したときに「そのまま動きそう」に見える理由でもあり、実際に細部で詰まる原因でもあります。 ### 2024年の2つの動き｜AGPLv3の追加と財団移管で前提が変わった 2024年には、両系列の前提を変える動きが続けて起きました。ひとつは2024年8月29日、ElasticがELv2とSSPLに加えてAGPLを選択肢として追加すると発表したことです。既存の利用条件を削るものではなく、選べる系列が増えたという形になっています。 もうひとつは2024年9月16日、OpenSearchがLinux Foundation傘下のOpenSearch Software Foundationへ移管されたことです。所有権はAmazonから財団へ移り、プレミアメンバーにはAmazon Web Servicesに加えてSAPとUberが名を連ねました。「AWSの製品だから将来が読めない」という当初の懸念は、この移管でかなり薄まったと見てよいでしょう。分岐当初の判断材料のまま検討を止めている場合は、この2点を入れ直してから比べ直すことをすすめます。 ## ライセンス条件の差｜Apache 2.0の単一系列と三系列の選択 ライセンスは、2つの系列で最も性質が違う部分です。OpenSearchはApache 2.0のみで、再配布もマネージド提供も条件の判断がほぼ要りません。一方のElasticsearchは三系列から選ぶ形になっており、どれを選ぶかで検討事項が変わります。 | 観点 | Elasticsearch | OpenSearch | | ------------ | -------------------- | ------------------ | | 提供ライセンス | ELv2・SSPL 1.0・AGPLv3 | Apache 2.0のみ | | 既定の配布物 | Elastic License 2.0 | 同左（単一） | | 第三者へのマネージド提供 | 系列の選択と確認が要る | 条件の制約なし | | 改変物の配布 | 選んだ系列の条件に従う | Apache 2.0の条件のみ | | ガバナンス | Elastic社 | Linux Foundation傘下 | 自社サービスへ組み込んで使うだけなら、Elasticsearchの既定配布のままで支障が出る場面は限られます。条件の確認が要るのは2つで、検索機能を第三者へマネージドサービスとして提供する場合と、ソースを改変した成果物を配布する場合です。このどちらかに当たりそうなら、ソースファイルのヘッダに書かれた条件を読んだうえで系列を決めてください。ライセンス変遷そのものの詳細は[Elasticsearchの製品解説記事](https://www.issoh.co.jp/tech/details/17011/)に置いています。 ## API互換性｜共通で動く範囲と書き換えが必要になる非互換点を見極める 「クエリはだいたい通る」という感覚は、半分だけ正しいものです。7.10.2までに存在したコアAPIは両系列で同じ形をしているため、単純な全文検索や集計であれば、送るJSONを変えずに通ることが多くあります。詰まるのはその外側、つまり管理系APIとプラグイン由来のAPI、そして各系列が後から入れた破壊的変更です。 ### OpenSearch側の破壊的変更｜版ごとに実名で洗い出しておく OpenSearchの破壊的変更は公式に版ごとの一覧が出ています。移行や併用を検討するなら、次の点を先に確認しておくと事故が減ります。 - **2.0.0**：`type`パラメータを全エンドポイントから削除。非包括的用語を非推奨とし、master相当の呼称はcluster managerへ - **2.18.0**：k-NNの既定エンジンがNMSLIBからFaissへ。`cosinesimil`を明示指定なしで使うとインデックス時にベクトルが単位長へ正規化されるため、格納値と入力値が一致しなくなります - **3.0.0**：最小JDKが21。2.x より前に作られたインデックスは非対応で、アップグレード前のリインデックスが必須 - **3.0.0**：システムインデックスへのREST経由アクセスを廃止。ドキュメントIDの512バイト上限をBulk APIでも一律に適用 - **3.0.0**：JSONのネスト深さを1,000段、プロパティ名を50,000単位までに制限。NMSLIBエンジンを非推奨とし、FaissまたはLuceneを推奨 とくに扱いに注意が要るのは3.0.0のインデックス版の制約です。1.x時代から動かし続けているクラスタは、アップグレード前にリインデックスの計画を立てる必要があります。バルク投入のIDが長い場合も、3.0.0で弾かれるようになるため事前に洗い出しておくと安全です。版ごとの新機能側の整理は[OpenSearch 3.0の新機能をまとめた記事](https://www.issoh.co.jp/tech/details/6592/)に置いています。 ### Elasticsearch側の独自路線｜本家だけに入った層をどう見るか 本家側は、分岐後に問い合わせ言語と検索体験の層を厚くしました。代表がES|QLで、8.11でテクニカルプレビューとして入り、8.14（2024年6月）で一般提供になっています。パイプでつなぐ記法の問い合わせ言語で、ログ調査のような探索的な使い方を想定した設計です。OpenSearch側にはPPLとSQLのプラグインがあり、目的は近いものの文法も実装も別物になっています。 インデックスのライフサイクル管理も名前とAPIが分かれました。本家はILM、OpenSearchはISM（Index State Management）で、後者はプラグイン配下の`_plugins/_ism`にぶら下がります。ホット・ウォーム・コールドという段階の考え方は共通していても、ポリシー定義のJSONは互換ではありません。移行時はここが書き換え対象になると見ておいてください。 ## 機能差｜セキュリティ・アラート・ベクトル検索で分かれる実装範囲を比べる 機能の比較で意味があるのは「あるかないか」より「無償で使えるかどうか」です。Elasticの自己管理向けサブスクリプション表を見ると、実運用で欲しくなる機能の多くがPlatinum以上に置かれています。OpenSearchは同種の機能をプラグインとして無償で同梱しており、ここが調達の判断に直結します。 | 機能 | Elasticsearch | OpenSearch | | --------------------- | ------------- | ----------- | | フィールド単位の制御 | Platinum以上 | 無償で同梱 | | ドキュメント単位の制御 | Platinum以上 | 無償で同梱 | | LDAP・Active Directory | Platinum以上 | 無償で同梱 | | SAML・OpenID Connect | Platinum以上 | 無償で同梱 | | アラート通知 | Watcherは有償 | Alertingが無償 | | 機械学習の異常検知 | Platinum以上 | 無償で同梱 | | クラスタ間レプリケーション | Platinum以上 | 無償で同梱 | 誤解しやすいのは、Elasticsearchの無償階層でも通信の暗号化とロールによる権限管理は使えるという点です。差が出るのはその先で、部署ごとに見えるフィールドを変える、社内の認証基盤とつなぐ、閾値超過を自動で通知するといった要件に入った瞬間に有償階層が視野に入ります。逆に、そこまで要らない小さな検索用途なら、この表の差はコストに響きません。 ### ベクトル検索の実装差｜エンジン選択と既定値が変わる条件に注意する ベクトル検索はどちらの系列も持っていますが、実装の入口が違います。本家は`dense_vector`フィールドとkNN検索を本体機能として提供し、OpenSearchはk-NNプラグインでFaissとLuceneのエンジンを選ぶ形です。前述のとおり既定エンジンは2.18.0でNMSLIBからFaissへ変わり、3.0.0でNMSLIBは非推奨になりました。古い記事の設定例をそのまま持ち込むと、既定値の変更に足をすくわれます。本家側の設定は[Elasticsearchのベクトル検索](https://www.issoh.co.jp/tech/details/17035/)で、dense\_vectorの定義からkNNクエリまで整理しています。 検索基盤をそのまま生成AIの検索層へ広げる構想があるなら、埋め込みの生成をどちらに寄せるかも先に決めておきたいところです。外部のモデルで作った埋め込みを投入するだけなら差は小さく、クラスタ内で推論まで回したいならOpenSearchのML Commons、本家の学習済みモデル連携という別系統の比較になります。設計の当てはめを含めた相談は[データ分析基盤構築・MLOps構築支援](https://www.issoh.co.jp/service/ai/data-platform/)で受けています。 ## クライアントとツールの互換｜接続部分で書き換えが発生する理由 実装者にとって一番はっきりした違いは、クライアントライブラリが系列ごとに分かれている点です。しかも、単に分かれているだけではありません。本家の公式クライアントには接続先が本家かどうかを検査する仕組みが入っており、他系列のクラスタへは意図的に繋がらないようになっています。 ### 製品チェックの仕組み｜公式クライアントが接続先を判定して弾く条件 本家のクライアントは、応答に含まれる`x-elastic-product`ヘッダを確認します。値が`Elasticsearch`でなければ、接続先が想定した製品ではないと判断して例外を投げる仕様です。Python版であれば`UnsupportedProductError`が送出され、そこで処理が止まります。挙動としては明確なので、原因の切り分け自体は難しくありません。 ``` from elasticsearch import Elasticsearch es = Elasticsearch("https://opensearch.example.internal:9200") es.info() # UnsupportedProductError: # the server is not Elasticsearch ``` OpenSearch側にも、かつては応答のバージョンを7.10.2と偽って返す`compatibility.override_main_response_version`という設定がありました。版チェックを持つ古いLogstash OSSやFilebeat OSSを繋ぐための橋渡しでしたが、1.xで非推奨となり、3.0.0で削除されています。つまり2026年時点では、この設定を当てにした延命はできません。系列専用のクライアントへ差し替えるのが唯一の道です。 ### 接続層の設計｜乗り換えの費用を先に下げておく実装の基本的な型 系列を将来乗り換える可能性があるなら、アプリからクライアントを直接呼ばず、薄いラッパを1枚挟んでおくと差し替えの範囲が限定されます。ラッパが受け持つのは接続の生成と認証、そして例外の変換までにとどめ、クエリのJSONはアプリ側で組み立てる形が扱いやすい構成です。 ``` class SearchClient: def __init__(self, driver): self._driver = driver # opensearchpy or elasticsearch def search(self, index, body): return self._driver.search(index=index, body=body) ``` 収集側のツールも系列ごとに異なる構成です。本家はBeatsとLogstash、OpenSearch側はData Prepperが標準的な選択肢で、Fluent BitやFluentdのように双方の出力プラグインを持つものもあります。ログ基盤を組むなら、収集エージェントを系列非依存のものに寄せておくことで、後から検索エンジン側だけを入れ替えられる構成です。AWS上での構築手順と料金の考え方は[AWSのマネージド検索サービスを扱った記事](https://www.issoh.co.jp/tech/details/3610/)にまとめています。 ## 移行と寄せ先の判断｜採用してよい条件と見送る場面の線引きを先に定める ここまでの差を踏まえて、実際にどちらへ寄せるかを決めます。先に移行の現実解を確認し、そのうえで採用条件を言い切ります。 ### 移行の経路｜方向ごとに使える手段と使えない手段を版別に分ける OpenSearchの移行手引きが想定しているのは、Elasticsearch OSSの系列までです。5.xなら5.6と6.8を経てリインデックスし7.10.2へ、6.xなら6.8を経て7.10.2へ、7.xなら直接という経路が示されています。裏を返すと、ライセンス変更後の7.11以降や8系・9系からのインプレース移行経路は用意されていません。なお、同じ製品の中で版を上げる工程は[Elasticsearchのバージョンアップと移行](https://www.issoh.co.jp/tech/details/17023/)で扱っています。 | 移行の方向 | 使える手段 | 注意点 | | --------------- | ------- | ------------- | | ES OSS 7.10.2から | 公式の移行経路 | 設定とプラグインは要確認 | | ES 7.11以降から | 再投入が前提 | マッピングを作り直す | | ES 8系・9系から | 再投入が前提 | ILMのポリシーは移せない | | OpenSearchから本家へ | 再投入が前提 | プラグイン設定は移せない | 再投入の具体的な手段は2つあります。ひとつは移行先クラスタでリモート指定のリインデックスを実行し、旧クラスタから直接読み出す方法。もうひとつは、元データを持つRDBや実データの置き場から作り直す方法です。後者は時間がかかる代わりに、マッピングとアナライザを設計し直せる利点があります。データの正本を検索エンジンの外に置いていれば、この選択が取れます。 ### 採用条件｜OpenSearchへ寄せてよい場面を条件で確定させる 次の3条件のうち2つ以上に当てはまるなら、OpenSearchへ寄せて構いません。第一に、稼働先がAWSに固まっており、権限管理をIAMへ寄せたいこと。第二に、フィールド単位のアクセス制御・シングルサインオン・アラート・異常検知のうち複数が要件に入っていて、有償階層の予算を確保しづらいこと。第三に、ライセンスの条件判断そのものを社内で持ちたくないことです。 逆にElasticsearchを選ぶ条件も明確です。ES|QLのように本家が先行して入れる機能を業務で使う予定がある、Elastic Cloudとオンプレミスを含めて配置先を選びたい、あるいは既存の運用ノウハウとBeats・Logstash資産が社内に厚く積み上がっている。このいずれかに当たるなら、無理に乗り換える理由はありません。有償階層の費用は、上の表にある機能を自前で作る工数と比べて判断してください。 ### 見送る場面｜どちらも導入しないほうがよい規模と運用条件を線引きする 両方とも見送ってよい場面もあります。検索対象が単一テーブルで数十万件までにとどまり、要件が前方一致と部分一致の範囲で足りるなら、RDBの全文検索機能で済みます。クラスタの運用に人手を割けない体制で、なおかつマネージドサービスの費用も通らないなら、導入しても運用が続きません。この線引きの前段にある全文検索そのものの仕組みと他のOSSとの比較は[全文検索エンジンの仕組みと主要OSSを比較した記事](https://www.issoh.co.jp/column/details/2866/)を参照してください。 ## よくある質問 ### OpenSearchはElasticsearchのクエリをそのまま実行できますか？ 7.10.2までに存在したコアAPIの範囲であれば、多くのクエリはそのまま通ります。ただし管理系のAPIとプラグイン由来のAPIは別物で、OpenSearch 2.0.0で`type`パラメータが削除されるなど破壊的変更も入っています。ライフサイクル管理のポリシーもILMとISMで互換がないため、そのまま移せません。 ### Elasticsearchの公式クライアントでOpenSearchに接続できますか？ 接続できません。公式クライアントは応答の`x-elastic-product`ヘッダを検査し、値が一致しなければ例外を投げて処理を止めます。回避策として使われていた`compatibility.override_main_response_version`はOpenSearch 3.0.0で削除されたため、系列専用のクライアントへ差し替えるのが唯一の解です。 ### OpenSearchへ移行するとライセンス費用はゼロになりますか？ ソフトウェアの利用料という意味ではゼロになります。ただしマネージドサービスを使えばインスタンスとストレージの料金が発生し、自前で建てればサーバ費と運用の人件費が乗ります。有償階層の削減額と、移行そのものにかかる工数を並べて比べてください。 ### スナップショットを使って相互に移行できますか？ 双方向で使えるとは考えないでください。OpenSearchの移行手引きが想定しているのはElasticsearch OSSの系列までで、7.11以降や8系・9系からの経路は示されていません。逆方向はさらに前提がなく、リモート指定のリインデックスか、正本からの作り直しが現実解になります。 ### ベクトル検索はどちらが有利ですか？ 用途によって変わるため、一方が優れているとは言えません。外部で生成した埋め込みを投入して近傍検索するだけなら差は小さく、どちらでも実装できます。クラスタ内で推論まで完結させたい場合や、エンジンをFaissとLuceneから選びたい場合はOpenSearch側の作りが噛み合いやすい構成です。 ## 関連記事 - [Elasticsearchとは？転置インデックスとシャード設計・ライセンス系列で決める採用可否](https://www.issoh.co.jp/tech/details/17011/) - [OpenSearch 3.0の新機能](https://www.issoh.co.jp/tech/details/6592/) - [AWSのマネージド検索サービスとは？料金体系・構築手順・運用のポイント](https://www.issoh.co.jp/tech/details/3610/) - [AWS検索サービスの選び方（CloudSearch・Algolia・Kendra比較）](https://www.issoh.co.jp/column/details/2687/) - [全文検索エンジンとは？仕組み・主要OSS比較とElasticsearch実装【2026年版】](https://www.issoh.co.jp/column/details/2866/) --- 出典: [ElasticsearchとOpenSearchの違い｜ライセンス・API互換・機能差から移行先を決める]()（株式会社一創）