OpenSearch 3の最新バージョンは3.9.0（2026年9月29日リリース）です。OpenSearchは2021年にElasticsearch 7.10.2から分岐したApache License 2.0の検索・分析エンジンで、3系は2025年5月6日の3.0.0から始まりました。3.0でApache Lucene 10とJDK 21必須に移り、その後はおよそ2か月ごとのマイナー版でベクトル検索・エージェント検索・オブザーバビリティの機能を積み増しています。
この記事では3.0から3.9までのリリース履歴、2.xとの違い（破壊的変更）、バージョンの確認方法、2.19を経由するアップグレード手順、サポート期間とLTS、Amazon OpenSearch Serviceで選べる版、ElasticsearchのILMに当たるISMまでを、公式ドキュメントとリリースノート、ローカルで起動した3.9.0の応答で確かめた内容でまとめます。
まとめ：OpenSearch 3の最新バージョンと確認・更新の要点
- 最新は3.9.0（2026年9月29日）。次の3.10.0は2026年11月3日から17日のリリース枠で予定されています。
- 2.xとの最大の違いはLucene 10・JDK 21必須・Java Security Managerの廃止。1.x以前に作ったインデックスは3.xで開けません。
- 2.xから3.xへ上げる前提は2.19.0以上。3.9.0の
GET /応答にもminimum_wire_compatibility_version: 2.19.0と出ます。 - 版の確認は
GET /のversion.number、ノードごとなら_cat/nodes。Dashboardsは本体と同じ版にそろえます。 - 2系に留まるなら2.19系（4.0のGAまで通常保守）。LTSの対象は2.19と3.6で、初回リリースから最低18か月の長期サポートを認定ベンダーとの契約で受ける仕組みです。
- Amazon OpenSearch Serviceで選べる3系の最新は3.7（2026年7月30日対応）で、OSS版より2つ遅れています。
- OpenSearchにILMはなく、同じ役割はISM（
_plugins/_ism）が担います。
OpenSearch 3の位置づけ：Lucene 10とJDK 21へ移ったメジャー版
OpenSearchのメジャー版は、下で動く検索ライブラリApache Luceneのメジャー更新と連動して上がってきました。2.xはLucene 9系、3.0はLucene 10.1.0を採用し、公式のリリース告知も「Lucene 10のリリースが3.0へ移る決定のきっかけになった」と説明しています。3.9.0ではlucene_versionが10.5.1になっています。
OpenSearchはセマンティックバージョニングに従い、破壊的変更はメジャー版でしか入りません。言い換えると、2.xから3.xへの移行は「2.x系の延長」ではなく設定・プラグイン・クライアントを点検し直す作業です。3.x内のマイナー更新（3.6から3.9など）は機能追加が中心で、同じ手順で上げられます。
Elasticsearchとのライセンス・API互換・機能差の比較はElasticsearchとOpenSearchの違い｜ライセンス・API互換・機能差から移行先を決めるで扱っています。ここではOpenSearch 3系の版の違いに絞ります。
OpenSearch 3.0から3.9のリリース履歴と主な新機能
リリース日はopensearch.orgのリリーススケジュールと保守ポリシー、内容はopensearch-buildリポジトリの各版リリースノートから拾っています。
| 版 | リリース日 | 主な変更 |
|---|---|---|
| 3.9.0 | 2026-09-29 | ネイティブのニューラルスパース検索エンジン、FP16ベクトル |
| 3.8.0 | 2026-08-04 | base64でのベクトル投入、MCP対応エージェントの拡大 |
| 3.7.0 | 2026-06-09 | doc valuesでのベクトル取得、ISM Simulate API |
| 3.6.0 | 2026-04-07 | 初のLTS指定、1ビットスカラー量子化 |
| 3.5.0 | 2026-02-10 | エージェントの会話メモリ、Prometheus連携の拡張 |
| 3.4.0 | 2025-12-16 | エージェント検索のUI、集計の高速化 |
| 3.3.0 | 2025-10-14 | 新しいDiscover、エージェント検索 |
| 3.2.0 | 2025-08-19 | gRPC（Protobuf）の正式提供、GPU対応の拡大 |
| 3.1.0 | 2025-06-24 | GPUでのインデックス構築が正式版、star-tree正式版 |
| 3.0.0 | 2025-05-06 | Lucene 10.1、JDK 21必須、Java Security Manager廃止 |
3.9の新機能：ニューラルスパース検索とベクトル圧縮、クラスタ保護
3.9.0の目玉はベクトル検索の軽量化です。ニューラルスパース検索はJVM実装からC++エンジン（SEISMICをJNI経由で呼ぶ）に置き換わり、リリースノートの試験値はスループット39%増、インデックス構築3.3倍速、JVMヒープ8分の1です。knn_vectorは動的マッピングに対応し（オプトイン）、マッピングを先に書かずにベクトルを投入できるようになりました。
メモリ面では16ビット浮動小数点のhalf_float型（floatの約半分）、Faiss向けのbfloat16エンコーダ、2ビット（16分の1）と4ビット（8分の1）のスカラー量子化が加わり、3.6で入った1ビット（32分の1）と合わせて圧縮率と再現率の釣り合いを選べます。運用側では、レイテンシを見てアクション単位の同時実行数を自動調整する保護機能と、時間範囲外のインデックスをコーディネーターが丸ごと飛ばす枝刈り（公式リリースノートに掲載された開発側のローカルベンチマークではテールレイテンシ80%超減）が入りました。
3.6から3.8の新機能：LTS指定とベクトル投入・取得の高速化
3.6.0はOpenSearch Software FoundationのLTSプログラムで最初にLTS指定された版です。機能面では1ビットのスカラー量子化（32倍圧縮）と、OpenTelemetry Collector・Data Prepper・OpenSearch・Prometheus・Dashboardsをまとめて起動するObservability Stackが入りました。
3.7.0はk-NNベクトルを_sourceでなくdocvalue_fieldsで取り出せるようにし、768次元・k=1000の条件で最大5.5倍速いと公表しています。DashboardsからPromQLでPrometheusを直接問い合わせる機能と、ISMのSimulate API（後述）もこの版です。3.8.0はbase64でのベクトル投入（ペイロード74%減・投入スループット最大4.16倍）と、半径検索の再現率改善（平均0.85から0.97）を入れ、MCP（Model Context Protocol）の接続をflow系エージェントにも広げました。
3.1から3.5の新機能：GPU構築・star-tree・エージェント検索
3.0で実験機能だったGPUによるベクトルインデックス構築は3.1.0で正式版になり、CPU比で構築時間9.3分の1・コスト3.75分の1とされています。2.18で実験機能として入ったstar-treeインデックスも3.1で正式提供となり（公式発表では集計を最大100倍高速化）、モデルIDを紐づけるだけで埋め込みフィールドを自動生成するsemanticフィールド型が加わりました。
3.2.0でProtobufによるgRPC通信が正式提供となり、3.3.0では自然文の質問からクエリDSLを組み立てるエージェント検索と、刷新されたDiscover画面が入りました。3.4・3.5はその延長で、エージェント検索のUI、会話メモリ、PPLのコマンド追加が中心です。ベクトル検索そのものの基礎はベクトルデータベースとは？ベクトル化・インデックス構造・製品比較【2026年版】、BM25とベクトルを組み合わせる構成はハイブリッド検索とは？RAGでBM25とベクトル検索を統合する仕組み・RRF・実装コードで解説しています。
OpenSearch 2.xと3の違い：アップグレード前に確認する破壊的変更
公式のBreaking changesページが3.0.0で挙げる変更のうち、既存クラスタで実際に止まりやすいものを本体側とプラグイン側に分けます。
本体・API側の変更：JDK 21と旧インデックス・ID長
- JDK 21が最低要件。同梱JDKを使わず自前のJavaで動かしている環境は、Java 17のままでは起動できません。
- 2.x未満で作られたインデックスは非対応（システムインデックスを含む）。アップグレードの前にreindexが必要です。
compatibility.override_main_response_versionを削除。GET /に7.10.2と名乗らせて古いElasticsearch用クライアントを通す手は使えなくなりました。- Java Security ManagerをJava agentに置き換え。権限はこれまでと同じくポリシーファイルで付与します。
- ドキュメントIDの512バイト上限がBulk APIにも適用。2.xではBulkだけ長いIDが通っていました。
- JSONのネストは1,000段、プロパティ名は50,000単位まで。
nestedクエリの深さはindex.query.max_nested_depth（既定20）で制限されます。 transport-nioプラグインを削除（通信はNettyに一本化）。REST APIからのシステムインデックス直接アクセスも廃止されました。- BM25の既定実装が
LegacyBM25SimilarityからBM25Similarityへ。リリースノートは検索品質は保たれると説明していますが、スコアの絶対値をしきい値に使っている処理は再確認が必要です。
ID長の制限は、ローカルで起動した3.9.0に513バイトのIDをBulkで投げると次のように拒否されました（IDは省略表記）。
POST /_bulk
{"index":{"_index":"t1","_id":"aaaa…(513バイト)"}}
{"f":1}
{"error":{"root_cause":[{"type":"action_request_validation_exception",
"reason":"Validation Failed: 1: id [aaaa…] is too long, must be no longer than 512 bytes but was: 513;"}], …}プラグイン・Dashboards側の変更：k-NN設定・SQL・Gantt
- k-NN：
knn.plugin.enabled、index.knn.algo_param.ef_construction、index.knn.algo_param.m、index.knn.space_typeを削除。NMSLIBエンジンは非推奨になり、FaissかLuceneへの移行が推奨です。 - SQL：
DELETE文、DSL形式のレスポンス、opendistro接頭辞の旧エンドポイントと設定を削除。ページングの既定はPoint in Timeに変わりました。 - Performance Analyzer：根本原因分析の
performance-analyzer-rcaエージェントを削除。詳細はOpenSearch Performance Analyzerとは？有効化・メトリクス取得・性能分析の手順を解説にまとめています。 - Dashboards：Gantt chartを含む
dashboards-visualizationsプラグインと、旧Discoverの切り替え設定を削除。旧形式のノートブック（.opensearch-observabilityインデックス保存）はアップグレード前に移行が必要です。 - searchable snapshotを扱うノードには
warmロールが必須。Query groupはWorkload groupに改名され、APIパスもwlm/workload_groupに変わりました。
OpenSearchのバージョン確認方法：GET /とノード単位の確認
稼働中のクラスタの版はGET /で確認します。本文のリクエスト例はOpenSearch DashboardsのDev Tools形式です。応答例は説明用に抜粋しているため、実行時はリクエスト部分だけを入力してください。ローカルで起動した3.9.0（opensearch-min・JDK 25）の応答は次のとおりでした。
GET /
{
"cluster_name" : "opensearch",
"version" : {
"distribution" : "opensearch",
"number" : "3.9.0",
"build_type" : "tar",
"build_date" : "2026-09-23T01:01:31.883915140Z",
"lucene_version" : "10.5.1",
"minimum_wire_compatibility_version" : "2.19.0",
"minimum_index_compatibility_version" : "2.0.0"
},
"tagline" : "The OpenSearch Project: https://opensearch.org/"
}見るべきはnumberだけではありません。minimum_wire_compatibility_versionはこのノードと同じクラスタに参加できる最も古い版、minimum_index_compatibility_versionは読み込める最も古いインデックスの版で、この2つが「2.19から上げる」「2.x未満のインデックスはreindex」という移行条件そのものです。
ローリングアップグレード中はノードごとに版が混在するので、GET _cat/nodes?v&h=name,version,node.role,cluster_managerで一覧します。インデックスがどの版で作られたかはGET <index>/_settings?humanのindex.version.created_stringに出ます（3.9.0で作ったインデックスは"3.9.0"）。
OpenSearch Dashboardsは接続先のOpenSearchと同じ版にそろえるのが公式の要件です。Dockerではopensearchproject/opensearch:latestと:3のタグが2026年9月29日から3.9.0を指しています。latestは4.0が出れば4系に移るため、本番では:3.9.0のように版を固定してください。
OpenSearch 2.xから3へのアップグレード手順：2.19経由のローリングアップグレード
事前条件：2.19.0以上・旧インデックスのreindex・スナップショット
公式のRolling upgradeページは「3.x.xへのアップグレードに必要な最小クラスタ版は2.19.0」と明記しています。ローリングアップグレードは隣接するメジャー版間しか対応しないため、1.3系なら2.19へ上げてから3.xへ進みます。2.x未満で作られたインデックスは、2.19の段階でreindexしておきます。
OpenSearchのノードはダウングレードできません。戻す手段は新規インストールとスナップショットからの復元だけなので、リモートリポジトリ（S3など）へのスナップショットと設定ファイルの退避を先に済ませます。プラグインは本体とメジャー・マイナー・パッチまで一致した版でないと動かないため、サードパーティ製プラグインに3.x向けのビルドがあるかもこの段階で確認します。
ローリングアップグレードの手順：1台ごとに割り当て停止から再開まで
公式手順は、次の2から5をノード1台ごとに繰り返す形です。割り当てを止めたまま全ノードを入れ替えるのではありません。
GET _cluster/healthでgreenを確認します。- レプリカの割り当てを止め、トランザクションログをフラッシュします。
- クラスタマネージャー候補以外のノードを1台停止し、3.xに置き換えます（Dockerの場合はボリュームを消さずに新しいコンテナへ付け替える）。
_cat/nodesで新しいノードの参加を確認します。- 割り当てを
allに戻し、greenに戻ったことを確認します。 - 残りのノードについて2から5を繰り返し、クラスタマネージャー候補は最後に上げます。
PUT /_cluster/settings
{ "persistent": { "cluster.routing.allocation.enable": "primaries" } }
POST /_flush
# ノード1台を3.xへ置き換え、クラスタへの再参加を確認したあと
PUT /_cluster/settings
{ "persistent": { "cluster.routing.allocation.enable": "all" } }
# greenに戻ったら、次のノードで割り当て停止から繰り返す
GET /_cluster/healthクラスタマネージャー候補を最後にするのは、古い版のマネージャーがいるクラスタには新しいノードが参加できる一方、マネージャーが全員新しい版になると古いノードが参加できなくなるためです。
3.xへ急いで上げないほうがよい場面
次のどれかに当たるなら、2.19に留まって移行を計画するほうが安全です。2.19系は4.0のGAまで通常の保守が続き、後述のLTSの対象でもあるので、急ぐ理由はありません。
- SQLプラグインの
DELETE、Gantt chart、旧ノートブック、transport-nio、RCAエージェントなど、3.0で削除された機能に依存している。 - 使っているサードパーティ製プラグインに3.x向けビルドがない。
- Logstashやクライアントライブラリが
GET /の版番号を見てElasticsearch 7.10.2互換かを判定している。 - 2.x未満で作ったインデックスが大きく、reindexの時間とディスクを確保できていない。
OpenSearchのサポート期間とLTS：2.19と3.6の選び方
opensearch.orgのMaintenance Policyでは、各メジャー版は「次のメジャー版が保守に入るまで」か「1年」の長い方の期間、保守対象になります。2026年10月1日時点の表では2系の最終版は2.19.6で状態はMaintenance、保守の終了予定は「4.0のGA」です。2.19.7は2026年10月13日から20日の枠で予定されています。
2026年に始まったLTSプログラムは、認定ベンダーが提供する長期サポートで、対象は2.19と3.6から始まりました。公式の対象範囲はOpenSearch本体・Dashboards・Securityプラグインで、期間は各版の初回リリースから最低18か月です。契約は利用者と認定ベンダーの間で結び、公表されている基準ではHigh・Criticalの脆弱性は公開から30日以内、Medium以上は60日以内に修正されます。
つまり「3.6に固定すれば18か月放置できる」わけではありません。LTSを使うなら認定ベンダーと契約して修正版を受け取り続けることが前提で、契約しないなら通常の保守が続く系列（3系は最新マイナー、2系は2.19.x）のパッチを当て続けます。版の選び方は、必要な新機能に加えて、不具合修正・セキュリティ修正がどの版に提供されるかで決めてください。
Amazon OpenSearch Serviceの対応バージョン：3.7とOSS版の差
Amazon OpenSearch Serviceは2026年7月30日にOpenSearch 3.7への対応を発表しました。OSS版の最新3.9.0とは2マイナー版の差があり、マネージド版は1・3・5・7のように飛び飛びで対応してきています。開発者ガイドの対応バージョン一覧は2026年10月1日時点で3.5までの記載のままなので、最新の対応状況はWhat’s Newとコンソールのバージョン選択で確認してください。
AWS上の2.19は標準サポートが2027年11月7日まで、延長サポートが2030年11月7日までと案内されています。3.1以降の終了日は未発表です。料金体系や構築手順はAmazon OpenSearch Serviceとは？料金体系・構築手順・運用のポイントまで徹底解説で扱っています。
OpenSearchのILM相当はISM：3.xでのライフサイクル管理
ElasticsearchのILM（Index Lifecycle Management）はOpenSearchにはありません。3.9.0でGET _ilm/policyを投げるとno handler found for uri [/_ilm/policy]が返ります。同じ役割を担うのがIndex State Management（ISM）プラグインで、ポリシーは状態（state）・アクション（action）・遷移（transition）からなる状態機械として書きます。
次のポリシーはlogs-*に一致する新しいインデックスへ自動で付き、作成から1分以上経過したことをジョブが確認するとwarm状態に移って読み取り専用にします（検証用に短くしています）。
PUT _plugins/_ism/policies/logs_policy
{
"policy": {
"description": "logs policy",
"default_state": "hot",
"states": [
{ "name": "hot", "actions": [],
"transitions": [ { "state_name": "warm", "conditions": { "min_index_age": "1m" } } ] },
{ "name": "warm", "actions": [ { "read_only": {} } ], "transitions": [] }
],
"ism_template": { "index_patterns": ["logs-*"], "priority": 100 }
}
}3.9.0でこのポリシーを登録してlogs-000001を作り、GET _plugins/_ism/explain/logs-000001を見ると、状態がwarm、メッセージがSuccessfully set index to read-onlyになり、インデックス設定にblocks.write: trueが付きました。ISMのジョブは既定の5分間隔に0〜60%のジッターが加わるため、通常は5〜8分間隔で実行されます。条件成立と遷移・アクション完了は同時ではありません（検証ではplugins.index_state_management.job_intervalを1分にしています）。
3.7で入ったSimulate APIを使うと、ポリシーを付ける前に、想定される状態・次のアクション・遷移条件の判定結果を、インデックスを変更せずに確認できます。作成直後のインデックスに対しては次のように「条件未達」が返りました。
POST _plugins/_ism/simulate
{ "policy_id": "logs_policy", "indices": ["logs-*"] }
{"simulate_results":[{"index_name":"logs-000002","is_managed":false,
"current_state":"hot","transition_evaluation":[{"state_name":"warm",
"condition_met":false,"condition_type":"min_index_age",
"current_value":"1s","required_value":"1m"}],"next_state":null}, …]}ILMのphase（hot・warm・cold・delete）とISMのstateは名前が似ていますが、ISMのstateは自由に命名でき、遷移も任意の状態間に張れます。ILMの5フェーズとの対応を考えるときはElasticsearchのILM｜5フェーズの設計とmin_ageの起点・データストリームとの使い分けと並べて読むと差がわかります。
よくある質問
OpenSearchの最新バージョンはいくつですか？
2026年10月1日時点の最新は3.9.0（2026年9月29日リリース）です。2系の最新は2.19.6です。次の3.10.0は2026年11月3日から17日の枠で予定されています。
OpenSearch 2.xから3.xへ直接アップグレードできますか？
2.19.0以上からなら直接ローリングアップグレードできます。2.18以前は先に2.19へ上げてください。2.x未満で作られたインデックスは、3.xへ上げる前にreindexが必要です。
OpenSearch 3.0はJava 17で動きますか？
動きません。3.0.0から最低要件はJDK 21です。tarballやDockerイメージには対応するJDKが同梱されているので、自前のJavaを指定していなければ意識する必要はありません。
OpenSearch DashboardsのバージョンはOpenSearch本体とそろえる必要がありますか？
必要です。公式のDocker手順はDashboardsの版を接続先のOpenSearchノードの版と一致させるよう求めています。本体を3.9.0に上げたらDashboardsも3.9.0にします。
OpenSearchとElasticsearchの違いは何ですか？
OpenSearchはElasticsearch 7.10.2から分岐したApache License 2.0のプロジェクトで、2024年からはLinux Foundation傘下のOpenSearch Software Foundationが運営しています。APIは分岐時点の互換を残しつつ別々に進化しているため、ライセンスと機能差を確認して選びます。
