🚀
OpenSearch Serverlessに新世代が！？長年の課題を解決する「NextGen」とは

hisanoya
2026/05/31に公開
AWS
OpenSearch
tech
 はじめにこんにちは！hisanoyaです！

2026年5月28日、Amazon OpenSearch Serverless に大きなアップデートが入りました。Amazon OpenSearch Serverless が世代交代し、新アーキテクチャ「NextGen」が登場しました。これに伴って、これまでの Serverless は「Classic」と呼ばれることになります。
https://aws.amazon.com/jp/blogs/news/the-next-generation-of-amazon-opensearch-serverless-built-from-the-ground-up-for-agents/
https://aws.amazon.com/jp/blogs/news/introducing-the-next-generation-of-amazon-opensearch-serverless-for-building-your-agentic-ai-applications/
OpenSearch Serverless は、サーバーレスらしい使い勝手を追求しながら進化を続けてきたサービスです。これまでの Classicでも多くのユースケースで活用されてきましたが、今回の NextGen アップデートでは、よりサーバーレスらしい体験を実現するためのアーキテクチャレベルの刷新が行われました。
本記事では、これまでの Classic がどういうものだったかを振り返りつつ、NextGen で何が変わって、何が嬉しくなったのかを見ていきます。最後には実際に NextGen を触ってみた検証結果も載せていますので、ぜひ最後までご覧ください。

 これまでの OpenSearch Serverless（Classic）はどういう仕組みだったかまずは振り返りから。Classic アーキテクチャは、ざっくり次のような構造になっていました。



ポイントを整理すると、
Indexing OCU と Search OCU はそれぞれローカルディスクに Index を持つ
データ自体は最終的に S3 に永続化されるが、OCU は実質的にローカル状態を持つ（=ステートフル）
つまり、コンピュート（OCU）とストレージ（ローカル Index）が密結合だったのが Classic の本質的な特徴です。
なるほど、「NextGen で何が変わったか」のセクションが別にあるから、ここはあくまで Classic の制約を説明するセクションとして残したい、でもネガティブすぎないように、ということですね。

 Classic の構造上の制約Classic は多くのユースケースで活用されてきましたが、アーキテクチャ上の特性として以下の2点がありました。

 ① 最小 2 OCU の常時稼働Classic では、アカウント内の最初のコレクションに対して最小 2 OCU が常時必要でした（インデックス作成 0.5 × 2 + 検索 0.5 × 2 で計 2 OCU、冗長構成の場合）。トラフィックがない時間帯でもこの分の課金が発生するため、アイドル時間が長いワークロードではコスト面で考慮が必要でした。
東京リージョンの単価で計算すると、この最小構成だけで月額 $487（約 7.3万円 ※$1=150円換算） になります。

 ② スケールが分単位新しい OCU を追加する際、ローカルディスクのブートストラップ（既存データを S3 から取得してマウント）が必要なため、スケールアップに分単位の時間がかかっていました。急峻なトラフィックスパイクに対しては、キャパシティの追加に時間がかかってしまうケースがありました。
これらは Classic のコンピュートとストレージが密結合であることに起因する構造的な制約です。

 次世代（NextGen）は何を変えたのかNextGen は、ここまで挙げた課題を アーキテクチャレベルで解決 しています。新アーキテクチャは以下のような構造です。



Classic の図と並べてみると違いがわかるかと思いますが、OCU（Workers）からローカルの Index ボックスが消え、代わりに Shared Storage という共有ストレージ層が両者の間に挟まっています。

 何が変わったか：分離アーキテクチャNextGen の核心は、コンピュートとストレージの完全分離です。

Workers（OCU）はステートレス化された
もう自分のローカルディスクに Index を持たない


Shared Storage 層が新設された
Indexing OCU・Search OCU の両方からアクセス可能
高耐久性で設計され、コンピュートとは独立してデータを保持

ぱっと見「Shared Storage が増えただけ」に見えますが、これがアーキテクチャの根本を変えています。

 なぜこの変更で「0までスケール」と「秒単位スケール」が可能になるのか
 ① ゼロまでスケールできる理由Classic では、各 OCU が自分のローカルディスクに Index をマウントしていたため、OCU を消すとデータも失われ、復旧のためには S3 から取り直す必要がありました。このため、常に最小 2 OCU を立てておく必要がありました。
NextGen では、データは OCU の外側にある Shared Storage 上に保持されます。OCU を全部解放してもデータには影響しないため、10分アイドルした時点で OCU をすべて解放できます。コンピュートを安全に解放できるのは、ストレージを分離したことによる性質です。

 ② 秒単位でスケールアップできる理由Classic では、新しい OCU を追加するたびに、ローカルディスクのブートストラップ（S3 からデータを取得してマウント）が必要で、これに分単位の時間がかかっていました。
NextGen では、OCU はステートレスなため、Shared Storage をマウントするだけで処理を開始できます。重い状態を持たないことが、秒単位スケールを可能にしています。
「0スケール」「秒スケール」という性質は、すべて Shared Storage 層を導入してコンピュートとストレージを分離した、という1つの設計判断から導かれています。

 NextGen が使えるシーンNextGen Serverless が向いているワークロードは、基本的に Classic Serverless と同じです。負荷にムラがあり、ピーク以外の時間はあまり動いていない、というプロファイルのワークロードに適しています。
AI エージェント / RAG のベクトル検索バックエンド
社内検索・ナレッジベース（業務時間帯にアクセスが集中し、夜間・休日は静か）
SaaS のテナント別検索（テナントごとの利用量にばらつきがある）
開発・ステージング環境
イベント駆動のログ分析
Classic でもこうしたワークロードに対応できていましたが、NextGen ではゼロまでスケールインできるようになったことで、アイドル時間の長いワークロードでのコスト効率がさらに改善されています。また、秒単位のスケーリングにより、バースト時の追従性も向上しました。
Serverless の共通の利点として、クラスターのノード管理やシャード設計を気にせず使える点も健在です。「検索基盤は欲しいが、運用に手間をかけたくない」というニーズには引き続き有力な選択肢です。
一方で、常にトラフィックがある定常的な検索ワークロードや、大量データを扱うケースでは、Managed Cluster（Provisioned）の方がコスト面・性能面で適していることもあります。自分のワークロードの特性に合わせて選択しましょう。
なお、ゼロスケールからの起動には 10〜30 秒程度のコールドスタートが発生します。これについては後述しますが、ユースケースによっては考慮が必要です。

 コストについてClassic と NextGen の単価を比較すると以下の通りです（2026年5月時点・東京リージョン、詳細は公式料金ページを参照）：


リソース
Classic
NextGen


OCU（Indexing / Search / GPU すべて同一）
$0.334 / OCU時
$0.334 / OCU時

ストレージ
$0.026 / GB月
$0.36 / GB月

OCU 単価は Classic と NextGen で同一（東京リージョン: $0.334/OCU時）です。NextGen はストレージ単価が Classic より高めに設定されていますが、検索ワークロードでは OCU コストが支配的になるケースが多く、ゼロスケールできる NextGen の方がアイドル時間の多いワークロードでは総額で有利になりやすい構造です。
なお、OpenSearch Serverless は Database Savings Plans の対象にもなっているため、利用パターンが安定してきた段階で長期コミットに切り替えることで、オンデマンド単価からさらにコストを削減することも可能です。

 注意点（導入前に押さえておきたいポイント）導入前に押さえておきたいポイントもあります

 コールドスタートNextGen は10分アイドルすると OCU が 0 まで落ち、次のリクエストで容量を立ち上げ直すのに 約10〜30秒 かかります（その間のリクエストはキューイングされるので破棄はされません）。
RAG / AI エージェント用途では、LLM の推論自体が検索よりも時間のかかる処理になることが多いため、この起動時間が体感上のボトルネックになるケースは限られるかと思います。
一方で、即時応答が求められるユースケースでは考慮が必要です。そういった場合は、定期的なウォームアップ（軽量クエリの投入）、Minimum OCU を 0 より上に設定する、あるいはマネージドクラスターを選択する、といった対応が考えられます。

 既存 Classic からは手動移行既存の Classic コレクションは NextGen に自動移行されません。新しいコレクショングループ + コレクションを作り、データをReindex（OpenSearch Ingestion 推奨）で移したうえで、アプリ側のエンドポイントを差し替える形になります。
クエリやマッピングはそのまま流用できるので、実質的な作業はエンドポイント切り替えのみですが、本番運用中だとデータ量次第でダウンタイムや二重書き込みの設計が必要になるのでご注意ください。

 Bedrock Knowledge Base はまだ Classic2026年5月29日時点で、Amazon Bedrock Knowledge Base のベクトルストアとして OpenSearch Serverless を選ぶと、作られるのは Classic コレクションです。NextGen の「待機課金ゼロ」の恩恵は Bedrock Knowledge Base 経由ではまだ受けられないため、当面は Classic の最小課金（東京で約 $487 / 月〜）が乗る前提になるのでご注意ください。

 その他
時系列（TIMESERIES）コレクションは未対応。ログ分析・APM 系は引き続き Classic かマネージドクラスター

 やってみた：NextGen の挙動を実際に見てみる実際にコレクションを作っていくつかリクエストを投げながら、CloudWatch で挙動を観察してみました。

 NextGen を作成してみたまず OpenSearch Serverless の Collection を作成しようと思います。画面の通り、Collection を作成しようとするとデフォルトで NextGen になっており、Switch to Classic で引き続き Classic も使えるようになっています。上記で記述した通り、現状は検索とベクトル検索のワークロードのみの対応になります。



Collection の作り方としては、以下の通り Express Create と 標準作成 があります。



Express Create ではネットワーク・暗号化・アクセスポリシーが自動で構成され、数秒でアクティブになります。試しに触ってみたい時や、デフォルト設定で問題ない用途ではこれが一番早いです。後から個別に設定を上書きすることもできます。Express Create の場合でも Indexing capacity (OCUs) と Search capacity (OCUs) はどちらも Minimum が 0 になっていることがお分かりいただけるかと思います。
標準作成 では、ネットワーク・暗号化・アクセスポリシーを自分で指定したうえで、Collection Group の min/max OCU まで明示的に設定できます。



NextGen ではコレクショングループが必須で、同じグループに属するコレクションは OCU を共有します。標準作成では、既存のグループを選ぶか新しく作成するかを選び、新規作成する場合に Indexing / Search それぞれの min/max OCU を指定できます。
本番運用では VPC エンドポイントや独自 KMS キーを使うケースがあるので、その場合は標準作成を選ぶことが多いかと思います。

 OCU の挙動を見てみるそれでは、0スケールが実際にできるのかみてみましょう。

何もリクエストを送っていない状態では、IndexingOCU も SearchOCU も 0 です。そこに最初の bulk write と検索リクエストを投げると、



08:00 までは両方とも 0 だった OCU が、リクエストを受けたタイミングで IndexingOCU が 1、SearchOCU が 2 に立ち上がっています。
そのまま時間を空けたり、再びリクエストを送ったりを繰り返してみると、



リクエストが来たら立ち上がり、10分ほどアイドルが続けばまた 0 に落ちる、という挙動が繰り返されています。Classic では常時確保されていた最小OCUが、NextGen ではアクティビティが上がればスケールアップするのはもちろん、アクティビティがなければしっかりと0OCUまでスケールダウンしていることがわかります。

 コールドスタートのレイテンシーを実際に試してみた次に、ゼロから立ち上がるときのレイテンシーを IngestionRequestLatency と SearchRequestLatency で見てみます。実際に bulk insert と検索リクエストを投げて、どのくらいコールドスタートがかかるかを検証してみましょう。
Ingestion 側：



最初の bulk write リクエストで IngestionRequestLatency が 15,285ms（約15秒）まで上がり、その後の継続的なリクエストでは数百msの通常レンジまで落ちています。
Search 側：



検索側も同様で、SearchRequestLatency が 16,830ms（約17秒）になった後、通常 Latency に戻っています。
実測でも 15〜17秒程度はかかるので、ゼロから立ち上がるときの初回リクエストはこれくらいの待ちが発生するものとして設計しておく必要があります。
コールドスタートのタイミングが事前にわかっている場合は、ウォームアップしておくと最初のリクエストの重さを吸収できます。例えば朝9時から社内ナレッジ検索が叩かれ始めるなら、8:55 頃に軽量クエリ（size=1 の match_all など）を1回投げておく、バッチ処理の開始10分前にウォームアップ用のリクエストを仕込んでおく、といった対応が有効です。
逆にコールドスタートを許容できる用途（RAG / AI エージェントのように LLM 推論時間に隠れる用途）なら、ウォームアップは不要です。

 まとめ今回は OpenSearch Serverless の世代交代について、Classic からの進化ポイント、NextGen の仕組み、コスト感、実際の挙動まで見てきました。
NextGen では待機課金ゼロや秒単位スケールが加わり、対応できるワークロードの幅がさらに広がっています。特に「バースト + 待機」のプロファイルを持つワークロードでは、想像以上に効くアップデートだと思います。
一方で、すべてのワークロードに Serverless が最適というわけではなく、24/7 で常時稼働するケースや大量データを扱うケースなど、Managed Cluster の方が向いている場面もあります。最適解はワークロード次第なので、自分のユースケースに合わせて検討してみてください。
公式ドキュメントはこちら。Express Create を使えば数秒で立ち上がるので、まずは気軽に触ってみるのもおすすめです。ユースケース的に合いそうであれば、ぜひ使ってみてください！それでは！