追記: 2026年6月11日の最新情報
2026年6月11日時点で、Amazon OpenSearch Serverlessのscale-to-zeroドキュメントと公式料金ページを確認しました。次世代OpenSearch Serverlessを見る時は、「Compute相当のOCUが0になること」と「保存データの課金が別に残ること」を分けて読む必要があります。
- Developer Guideでは、NextGen collection groupsは指定がなければindexingとsearchの最小OCUが0になり、すべてのcollectionで10分間リクエストがない場合にcompute resourcesが0 OCUへ下がると説明されています。この10分のidle periodは設定変更できません。
- Searchとindexingはそれぞれ独立して0から復帰します。トラフィック再開時にはcapacityが戻るまで初回リクエストに10〜30秒程度の遅延を見込む説明があるため、低頻度利用には向きますが、常に低遅延が必要な検索とは分けて評価してください。
- 公式料金ページでは、NextGen collectionsのcomputeとstorageは別課金で、OCUはcollection group単位で秒単位の粒度により課金され、hot storageはGB月単位で別に課金されると説明されています。scale-to-zeroは「使っていないcomputeを抑える仕組み」であり、検索基盤全体が無料になるという意味ではありません。
AIエージェント向け検索基盤として検討する場合は、検索頻度、初回応答の許容遅延、storage量、再取り込みの手間、既存collectionからの移行条件を並べて確認すると判断しやすくなります。
出典: AWS Big Data Blog「The next generation of Amazon OpenSearch Serverless: Built from the ground up for agents」、Amazon OpenSearch Service Developer Guide「Scale to zero for Amazon OpenSearch Serverless」、AWS「Amazon OpenSearch Service Pricing」。
このテーマをもう少し広げて見るなら、Amazon Bedrock AgentCore RuntimeのInteractive Shellsとは：AIエージェントを端末から調査・デバッグする前に確認すべきこと と OpenAI GPT-5.5/GPT-5.4とCodexのAmazon Bedrock一般提供とは：導入前に見るAPI・リージョン・料金 も合わせて確認してください。エージェント検索基盤を運用する時に、Runtime側をどう調査・デバッグするかを合わせて確認できます。
3行まとめ
リクエスト停止後にCompute相当のOCU usageが0になる説明を、storage課金とは分けて確認します。
キーワード検索とベクトル検索のどちらを使うかを、検索対象と権限条件から決めます。
既存コレクションをそのまま切り替えるのではなく、新しいcollectionへ再取り込みする前提で見ます。
取り込み側と検索側のOCUを分け、hot storage、監視、上限設定も別に確認します。
モデル側だけでなく、検索結果を返すOpenSearch側の遅延、課金、権限、監視を分けて見ると判断しやすくなります。
AWSは2026年5月28日、AIエージェント向け検索・ベクトル検索基盤として、次世代Amazon OpenSearch Serverlessを一般提供したと発表しました。
読むべきポイントは、Scale-to-zeroで何が0になるのか、SEARCHとVECTORSEARCHのどちらを使うのか、既存コレクションからの移行がインプレースではなくreindex前提になるのか、という4点です。
日本のAWS利用者は、BedrockやAgentCoreのモデル側だけでなく、検索結果を返すOpenSearch側の遅延、OCU課金、hot storage、権限、監視を分けると、AIエージェント基盤の設計を判断しやすくなります。Amazon Watch JapanはAmazonおよび関係会社とは非提携の独立サイトとして、公式資料で確認できる範囲を整理します。
次世代OpenSearch Serverlessで何が変わったのか
インスタンス、ストレージ、シャード、バージョン、メンテナンスなどを強く意識する運用です。
従来のServerless collectionとして、次世代版への移行条件を分けて確認します。
collection、collection group、OCU、データアクセス、ネットワーク、暗号化、課金単位を先に見ます。
検索対象データ、検索方式、権限、遅延、コスト、移行方法をモデル選定とは分けて確認します。
次世代版はAIエージェント向けの検索・ベクトル検索基盤として説明されていますが、採用判断は運用単位の違いから始めます。
次世代Amazon OpenSearch Serverlessは、OpenSearchを使った検索、ベクトル検索、AIエージェント向け検索バックエンドを、より短い作成時間と自動スケーリングで使えるようにする更新です。AWS News Blogでは、次世代版が「AI agents」を構築する顧客向けのフルマネージドな検索・ベクトルエンジンとして説明されています。
ここで大事なのは、OpenSearchという名前だけで既存のOpenSearch Serviceドメイン、従来のOpenSearch Serverless Classic collections、次世代Serverless NextGen collectionsを混ぜないことです。同じ検索基盤でも、運用者が見るべき項目は変わります。ドメイン運用ではインスタンス、ストレージ、シャード、バージョン、メンテナンスを強く意識します。一方、Serverlessではcollection、collection group、OCU、データアクセス、ネットワーク、暗号化、課金単位を先に見ることになります。
公式発表で確認できること
根拠
AWS News BlogとAWS日本語ブログでは、次世代OpenSearch Serverlessが2026年5月28日に発表され、一般提供として説明されています。AWSは、次世代版がアイドル時にゼロへスケールダウンし、秒単位でリソースを作成し、従来世代より最大20倍速く容量をスケールできると説明しています。また、ピーク容量に合わせてOpenSearch Serviceクラスターをプロビジョニングする構成と比べ、最大60%のコスト削減につながる可能性があるとも示しています。
ただし、この「最大60%」は、すべての環境で自動的に得られる保証ではありません。検索やインデックス処理が常時走るサービスでは、ゼロへ落ちる時間が短くなります。逆に、開発環境、夜間や休日に使わない社内検索、断続的に問い合わせが来るRAG基盤では、Scale-to-zeroの効果を検証する価値があります。
AIエージェント向けという言葉をどう読むか
条件
AIエージェント向け検索基盤と聞くと、すぐにモデルやプロンプトの話に行きたくなります。しかし、OpenSearch Serverless側でまず見るべきなのは、検索対象データ、検索方式、権限、遅延、コスト、移行方法です。
たとえば、社内文書を参照するエージェントでは、ベクトル検索だけでは足りないことがあります。部署、顧客、契約、地域、更新日などのメタデータで絞り込む必要があるからです。商品検索やFAQ検索でも、意味的に近い文書を返すだけでなく、型番、在庫、公開範囲、古い情報の除外が欠かせません。
モデル選定や互換APIの運用は、すでに公開済みの<a href="https://amzn-watch.blog.mo-gmo.com/amzn-25-bedrock-redesigned-console-openai-anthropic-apis/" rel="noopener">Amazon Bedrock新コンソールの記事</a>で整理しています。この記事では、モデルが参照する検索バックエンドとして、OpenSearch Serverlessをどう見ればよいかに絞ります。
需要シグナルとして見える周辺の動き
注意点
今回の話題は、AWS News Blog、AWS日本語ブログ、AWS Big Data Blogで続けて取り上げられています。さらにVercel、Kiro、OpenSearch Agent Skills、Claude Code、Cursorといった開発導線も公式ブログで触れられており、AIアプリケーションを作る入口として検索基盤の需要が強まっていることが分かります。
ただし、VercelやKiroの名前が出ているからといって、採用判断の主語をツール連携に置くと危うくなります。OpenSearch Serverlessを使うかどうかは、まずデータがどこにあり、どの検索方式が必要で、どの程度の遅延とコストを許容できるかで判断します。周辺ツールは、その判断を実装しやすくする入口と考えるのが自然です。
Scale-to-zeroは何を0にするのか
0になる対象はOCU usageです。hot storage、ログ、再インデックス中の重複は別に確認します。
次世代OpenSearch Serverlessの目立つポイントはScale-to-zeroです。AWS Big Data Blogでは、リクエストが10分間来ない場合にcompute resourceを解放し、OCU usageが0になると説明されています。さらに、トラフィックが戻ると、おおむね10秒で容量が戻るとされています。
ここで注意したいのは、ゼロになる対象です。ゼロになるのはComputeに相当するOCUであり、保存済みデータそのものの課金が消えるという意味ではありません。Pricingページでは、ComputeとStorageが別に課金され、hot storageはGB-monthで別に扱われると説明されています。
Indexing OCUとSearch OCUを分けて見る
確認項目
OpenSearch ServerlessのComputeはOpenSearch Compute Units、つまりOCUで測られます。PricingページのNextGen Collections説明では、ComputeはOCU-hoursとして表示され、データインデックス用と検索用の2つのラベルで見えるとされています。
これは実務上かなり重要です。検索がほとんどなくても、継続的な取り込みや再インデックスが走っていればIndexing OCUが使われます。逆に、取り込みが止まっていても、エージェントやアプリケーションが頻繁に検索すればSearch OCUが使われます。請求や監視を見るときは、OpenSearch Serverless全体の費用という1行だけでなく、IndexingとSearchを分けて確認する必要があります。
AIエージェントの本番運用では、この分離が効いてきます。夜間に大量の文書を取り込み、日中に検索が増える構成では、IndexingとSearchのピーク時間がずれるかもしれません。常時取り込みと常時検索が重なる構成では、Scale-to-zeroよりも上限設定、監視、検索精度、タイムアウト設計のほうが重要になります。
10分間の非アクティブ後に何を見るか
評価基準
AWS Big Data Blogのウォークスルーでは、collection groupがスケールダウンした後、currentCapacity.search.capacityInOcuとcurrentCapacity.indexing.capacityInOcuが0になることを確認する流れが示されています。コンソール上でも、Indexing capacityとSearch capacityのチャートを見る説明があります。
本文執筆時点でこの記事は実アカウントでの検証ログを掲載していません。そのため、「筆者環境で何秒だった」という実測値は書きません。導入判断で見るべきなのは、公式ブログの説明を前提に、自社環境で次の項目を測ることです。
| 確認項目 | 見る理由 |
|---|---|
| 10分間の非アクティブ後にSearch OCUが0になるか | 検索が止まる時間帯にComputeが下がるかを見る |
| 10分間の非アクティブ後にIndexing OCUが0になるか | 取り込み処理が残っていないかを見る |
| 初回検索の応答遅延 | 容量復帰時の待ち時間がユーザー体験に影響するかを見る |
| リトライとタイムアウト | 最初のリクエストが数秒待つ可能性を吸収できるかを見る |
| 監視とアラーム | 0 OCU自体より、復帰失敗や遅延増加を検知できるかを見る |
Scale-to-zeroが効きやすい用途、効きにくい用途
上振れと下振れ
Scale-to-zeroが効きやすいのは、使わない時間がはっきりあるワークロードです。開発用の検索基盤、試用中のRAG、社内ナレッジ検索、夜間にほとんど検索されない管理ツール、イベント前後だけ使う問い合わせ検索などは候補になります。
一方で、常時アクセスがある公開検索、継続的にデータを取り込むログ基盤、高頻度にエージェントが検索するカスタマーサポート、短い応答時間が厳しく求められるプロダクトでは、0 OCUになる時間が少ないかもしれません。その場合は「ゼロまで落ちるか」より、「ピーク時にどれだけ安定してスケールするか」「Search OCUとIndexing OCUをどう監視するか」を見るべきです。
また、Scale-to-zeroの復帰時には、おおむね10秒で容量が戻るという公式説明があります。ユーザー操作の直後に必ず検索するプロダクトでは、この復帰待ちを許容できるかが論点になります。スケジュールされたバッチやキャンペーン前に軽いクエリで温める、といった運用が必要になるかもしれません。
SEARCHとVECTORSEARCHのどちらを選ぶか
SEARCHとVECTORSEARCHは勝敗ではなく用途差です。ログ分析や時系列用途は、対応collection typeを別に確認します。
次世代OpenSearch Serverlessでは、SEARCHとVECTORSEARCHのcollection typeが重要です。AWS Big Data Blogでは、NextGen architectureがSEARCHとVECTORSEARCHをサポートし、TIMESERIESはlaunch時点ではサポートされないと説明されています。
この点は、AIエージェントやRAGを考える読者ほど見落としがちです。AIエージェントといっても、すべてがベクトル検索ではありません。正確なキーワード一致、フィルタ、日付範囲、権限、カテゴリ、ハイブリッド検索が必要な場合もあります。
SEARCHは正確な検索と絞り込みの基盤として見る
条件
SEARCHを選ぶ場面は、文書、FAQ、商品情報、社内ナレッジ、サポート記事などを、キーワードや構造化条件で検索したいときです。AIエージェントが裏側で検索を呼ぶ場合でも、ユーザーの権限、部署、契約、地域、更新日、公開状態といった条件で絞り込むことはよくあります。
ベクトル検索だけに寄せると、意味的には近いが権限外の情報、古い情報、違う地域の情報が返る可能性があります。SEARCHは、そうした条件をきちんと守るための土台になります。エージェントが回答を作る前に、正しい対象だけを候補にできるかを見てください。
VECTORSEARCHは埋め込み検索のバックエンドとして見る
確認項目
VECTORSEARCHは、埋め込みベクトルを使った類似検索に向いています。AWSのDeveloper Guideでは、vector search collectionでスケーラブルな類似検索を実行でき、機械学習を使った検索体験や生成AIアプリケーションを、基盤のベクトルデータベース運用なしに構築できると説明されています。
検証では、埋め込みモデル、ベクトル次元、k-NNクエリ、メタデータフィルタ、再ランキング、更新頻度、検索結果の説明可能性を分けて見ます。特に社内文書RAGでは、近い文書が返るかだけでなく、「回答に使ってよい文書だけが返っているか」「最新の文書が優先されているか」「同じ意味の言い換えに強いか」を確認する必要があります。
OpenSearch Serverlessのvector engineは、k-nearest neighbor searchを使う説明がDeveloper Guideにあります。用途としては、文書検索、画像検索、商品推薦、異常検知などが挙げられています。ただし、どの埋め込みモデルでどの精度になるかは、公式発表だけでは決まりません。自社データで評価セットを作り、検索結果と回答品質を測る必要があります。
TIMESERIES用途は別に考える
注意点
ログ分析や時系列データの検索を主目的にしている場合は、NextGenのSEARCH/VECTORSEARCHとTIMESERIESを混同しないでください。AWS Big Data Blogでは、TIMESERIESはlaunch時点でサポートされないと説明されています。
つまり、ログ分析、メトリクス、長期の時系列監視を含む用途では、従来のOpenSearch構成や別のAWSサービスを含めて検討する必要があります。AIエージェントの検索バックエンドとしてのOpenSearch Serverlessと、運用ログ基盤としてのOpenSearchは、同じ名前でも判断軸が違います。
既存環境から移す前に見る条件
- 1用途とcollection typeを確認
SEARCH、VECTORSEARCH、TIMESERIESなど、移行対象の用途を分けます。
- 2新しいcollection groupを用意
本番、検証、顧客、サービスの分離単位を先に決めます。
- 3新しいcollectionを作成
mapping、認証、network policy、data access policyを検証します。
- 4データを再取り込み
データ量、所要時間、再取り込み中の費用、切り戻しを確認します。
- 5アプリの接続先を切り替え
既存クエリが同じ結果を返すか、監視とエラー処理を含めて確認します。
queriesとindex mappingsを使える可能性があっても、移行対象、reindex時間、認証、監視、切り戻しは別々に検証します。
次世代OpenSearch Serverlessは、既存のOpenSearch利用者にとって魅力的に見えます。しかし、移行を「ボタン1つのアップグレード」と見てはいけません。AWS Big Data Blogでは、新しいcollection groupとcollectionを作成し、データをreindexする流れが示されています。
この説明から読むべきことは、既存コレクションの中身をそのまま次世代アーキテクチャへ切り替える話ではない、という点です。導入判断では、移行対象、データ量、reindex時間、切り戻し、endpoint差し替え、認証、監視を別々に検証する必要があります。
インプレース変更ではなくreindex前提で見る
根拠
既存のClassic collectionsから移す場合は、新しいcollection groupとcollectionを作り、そこへデータをreindexする前提で計画します。Big Data Blogでは、queriesとindex mappingsは同じまま使え、主な変更はcollection endpointだと説明されています。これは移行のハードルを下げる材料ですが、無条件に安全という意味ではありません。
実務では、次のような確認が必要です。
| 確認対象 | 確認する理由 |
|---|---|
| index mapping | 既存のmappingがそのまま使えるかを見る |
| query | 既存アプリの検索クエリが同じ結果を返すかを見る |
| reindex時間 | 切り替え前に必要なデータ同期時間を見積もる |
| endpoint | アプリ、バッチ、監視、権限設定の差し替え範囲を見る |
| 並行稼働 | 新旧環境を同時に動かして差分を見られるか確認する |
| 切り戻し | 本番切替後に問題が出たとき戻せるかを決める |
endpoint差し替えだけで終わらない項目
確認項目
公式説明では、queryとindex mappingsが同じで、collection endpointの変更が中心だとされています。とはいえ、本番システムではendpoint以外にも確認が必要です。IAM、data access policy、network policy、encryption policy、クライアント側の署名、タイムアウト、リトライ、監視、アラーム、ログ、コスト配賦が関係します。
AIエージェントが検索を呼び出す場合は、認証情報管理も重要です。AgentCoreやBedrock側の認証情報管理は、<a href="https://amzn-watch.blog.mo-gmo.com/amzn-21-agentcore-identity-secrets-manager/" rel="noopener">AgentCore IdentityとSecrets Managerの記事</a>で扱っています。OpenSearch Serverlessの移行では、検索基盤そのものだけでなく、エージェントがどの権限でどのデータへアクセスするかも同時に見てください。
OpenSearch Serviceドメインからの移行は別の論点
注意点
OpenSearch ServiceドメインからServerlessへ移す場合は、Classic collectionsからNextGenへ移すよりも論点が増えます。インスタンスタイプ、シャード、ストレージ、専用マスター、スナップショット、VPC、メンテナンス、バージョン、プラグイン、既存の運用手順が変わるからです。
この記事では、OpenSearch Serviceドメインからの完全移行手順までは扱いません。まずは、次世代OpenSearch Serverlessが自社の検索用途に合うか、小さな試用でSEARCHまたはVECTORSEARCHのcollectionを作り、データを少量入れて、応答、コスト、監視、権限を確認するのが現実的です。
課金単位はcollection group、OCU、hot storageで分ける
AIエージェント運用では、IndexingとSearchのピーク時間がずれるか、常時重なるかで見え方が変わります。
次世代OpenSearch Serverlessの費用を見るときは、Scale-to-zeroだけを見ないでください。Pricingページでは、NextGen Collectionsについて、ComputeとStorageは別課金であり、ComputeはOCUで測られると説明されています。さらに、Computeはcollection group levelでOCU-hoursとして請求され、per-second granularityで扱われるとされています。
ここから分かるのは、コスト管理の主語がcollection groupになることです。複数のcollectionsが同じcollection group内でOCUを共有するため、設計によってはコスト効率が上がります。一方で、複数用途を同じgroupへ入れると、どのワークロードが費用や負荷を増やしたのかを丁寧に見る必要が出ます。
OCU-hoursはIndexingとSearchで分かれる
確認項目
Pricingページでは、ComputeのOCU-hoursにデータインデックス用と検索用の2つのラベルが見えると説明されています。請求を読むときは、検索費用が高いのか、取り込み費用が高いのかを分けて見てください。
RAGでは、取り込みと検索の負荷が違うタイミングで発生します。大量の文書を一度に埋め込み、インデックスへ投入するフェーズではIndexing側が動きます。ユーザーやエージェントが問い合わせるフェーズではSearch側が動きます。どちらが費用を押し上げているかを分けると、改善策も変わります。
collection group共有は便利だが、分離設計も必要
条件
すべてのcollectionsを同じcollection groupに入れると、OCU共有のメリットを得やすくなるかもしれません。しかし、本番と検証、顧客別、機密度別、ワークロード別に分けたほうがよい場合もあります。
たとえば、試用目的の取り込みが本番検索の遅延に影響するなら、groupを分ける検討が必要です。顧客ごとに請求や監査を分けたい場合も、同じgroupに詰め込むと後から説明しにくくなります。Scale-to-zeroを最大化するだけでなく、障害時の切り分けやコスト説明まで考えて分けるのが現実的です。
0 OCUでもstorageは残る
注意点
Scale-to-zeroはComputeの話です。データを保存している限り、hot storageのGB-monthは別に確認する必要があります。大量の文書やベクトルを保持する場合、検索が止まってOCUが0になっても、データ量に応じたstorageの費用は残ります。
また、移行時には新旧環境を並行稼働することがあります。その間はデータを二重に持つ可能性があります。reindex中の一時的な増加、検証用collectionの削除忘れ、CloudWatchや周辺ログの費用も確認してください。OpenSearch Serverlessを試すときは、作成だけでなく削除手順も検証チケットに入れるべきです。
Vercel、Kiro、OpenSearch Agent Skillsをどう位置づけるか
OpenSearch collectionを作成または接続する入口として、プロトタイプまでの時間を短くできる可能性があります。
agentic IDEは検索アプリのプロトタイプや設計確認を進める導線として見ます。
OpenSearchの知識やベストプラクティスをエージェントワークフローへ持ち込む候補です。
モデル、推論、エージェント実行、認証、ワークフローの話として、検索バックエンドとは切り分けます。
AWSアカウント、ネットワーク、データアクセス、監査、コスト、削除、バックアップ、エラー処理を確認します。
回答が間違ったときは、モデルの推論、検索結果、権限、古い文書の混入を分けて調べる必要があります。
AWS News Blogでは、Vercel consoleから新しいOpenSearch collectionを作成したり、既存のOpenSearch Serverless collectionへ接続したりできると説明されています。また、Claude Code、Cursor、Kiro、OpenSearch Agent Skillsのような開発導線も紹介されています。
これは、OpenSearch Serverlessが単独の検索サービスとしてだけでなく、AIアプリケーションの作成フローに近づいていることを示す材料です。ただし、ツール名を見て採用を決めるのではなく、検索基盤の要件を満たせるかを先に見てください。
Vercel連携はプロトタイプ導線として見る
条件
Vercelを使ってAIアプリやWebアプリを作るチームにとって、Vercel console内でOpenSearch collectionを扱える導線は便利です。プロトタイプから検索バックエンドを付けるまでの時間が短くなり、開発者がAWSコンソールと行き来する負担を減らせる可能性があります。
一方で、本番導入では、Vercel側の作成体験だけでなく、AWSアカウント、ネットワーク、データアクセス、監査、コスト、削除、バックアップ、アプリ側のエラー処理を確認します。入口が簡単になるほど、裏側の権限と費用の確認を後回しにしないことが大切です。
KiroやAgent Skillsは設計確認の入口として扱う
注意点
OpenSearch Agent Skillsは、OpenSearchの知識やベストプラクティスをエージェントワークフローに持ち込むためのリポジトリとして紹介されています。KiroやCursor、Claude Codeのようなagentic IDEと組み合わせることで、検索アプリのプロトタイプや設計確認を進めやすくなる可能性があります。
ただし、スキルやIDEが検索品質、権限、コスト、障害対応を自動で保証するわけではありません。設計を助ける道具として使い、最終的には自社データ、評価セット、IAM、network policy、data access policy、監視、請求を確認してください。
BedrockやAgentCoreとは役割を分ける
切り分け
BedrockやAgentCoreは、モデル、推論、エージェント実行、認証、ワークフローの話です。OpenSearch Serverlessは、エージェントが参照する検索・ベクトル検索のバックエンドです。両方を混ぜると、どこで問題が起きたか分からなくなります。
たとえば、回答が間違っている場合、モデルの推論が悪いのか、検索結果が悪いのか、権限で必要な文書が除外されているのか、古い文書が上位に来ているのかを分けて調べる必要があります。エージェントをStep Functionsなどのワークフローに組み込む観点は、<a href="https://amzn-watch.blog.mo-gmo.com/amzn-27-step-functions-agentcore-reasoning-step/" rel="noopener">Step FunctionsのAgentCore推論ステップの記事</a>も合わせて読むと整理しやすくなります。
導入前チェックリスト
料金、リージョン、提供条件、対応collection typeは変わる可能性があるため、導入前に公式情報を再確認します。
次世代OpenSearch Serverlessを試すなら、いきなり本番移行を考えるより、試用環境で小さく確かめるのが安全です。特に、AIエージェントやRAGの検索基盤は、検索結果がそのまま回答品質や権限事故につながります。
以下のチェックリストは、公式情報で確かめられる項目と、実アカウントで試すべき項目を分けるためのものです。2026年6月7日時点の公式情報をもとにしていますが、料金、リージョン、提供条件、対応collection typeは変わる可能性があるため、導入前にPricingページとDeveloper Guideを再確認してください。
今すぐ確認する項目
確認項目
| 項目 | 確認すること |
|---|---|
| 用途 | 社内検索、RAG、商品検索、FAQ、ログ分析などの主目的を分ける |
| collection type | SEARCHかVECTORSEARCHか、TIMESERIESを含まないかを見る |
| データ量 | 文書数、ベクトル数、更新頻度、削除頻度を把握する |
| 権限 | ユーザー、部署、顧客、サービスごとのアクセス境界を決める |
| 移行 | 新規collection groupとcollectionを作りreindexする前提で計画する |
| 費用 | Indexing OCU、Search OCU、hot storageを分けて見る |
ここで用途が曖昧なままなら、OpenSearch Serverlessを作る前に検索要件を決めたほうがよいです。AIエージェントという言葉だけでは、SEARCHなのかVECTORSEARCHなのか、あるいは従来ドメインを残すべきなのか判断できません。
小さな試用で確認する項目
評価基準
試用時には、公式ブログの説明を自分のワークロードで確かめます。10分間の非アクティブ後にIndexingとSearchのOCUが0になるか、初回アクセス時の遅延が許容できるか、reindexにどれくらい時間がかかるかを見てください。
検索品質の検証も必要です。RAGなら、代表的な質問セットを作り、返ってきた文書、回答の根拠、権限、古い情報の混入を確認します。商品検索なら、型番、カテゴリ、在庫、地域、価格帯の絞り込みが正しく効くかを見ます。FAQなら、言い換え、曖昧な質問、短い質問、誤字を含む質問で結果を比べます。
本番前に確認する項目
下振れ
本番前には、障害時の切り戻し、旧endpointとの並行稼働、監視、アラーム、コスト上限、削除手順を決めます。Scale-to-zeroは魅力的ですが、それだけで本番採用を決めるのは危険です。
特に、エージェントが自動で検索し、回答や操作につなげる場合は、検索結果の誤りがユーザー体験や業務判断に影響します。必要な文書が返らない、権限外の文書が混ざる、古い文書が上位に出る、初回検索が遅い、コストが急に増えるといった下振れを想定してください。
2026年6月のAmazonとAWS関連トピックは、<a href="https://amzn-watch.blog.mo-gmo.com/monthly-topics-2026-06/" rel="noopener">2026年6月 重要トピックまとめ</a>にも整理しています。Bedrock、AgentCore、OpenSearch、Vercel連携のように複数サービスがつながる話題は、単独記事だけでなく月次ページで流れを見ると追いやすくなります。
更新履歴と非提携表記
2026年6月7日に公式ブログ、製品ページ、Pricingページ、Developer Guideを確認しています。
一般提供、Scale-to-zero、SEARCH/VECTORSEARCH、移行条件、OCU課金の確認項目を整理しています。
AMZN株価、時価総額、短期的な市場反応、投資助言は扱いません。
Amazon Watch JapanはAmazon.com, Inc.およびその関係会社とは非提携です。
サービス名、商標、公式発表は各権利者に帰属します。導入判断では最新の公式情報を確認してください。
2026年6月7日、AWS News Blog、AWS日本語ブログ、AWS Big Data Blog、Amazon OpenSearch Service製品ページ、Pricingページ、Developer Guideを確認し、次世代Amazon OpenSearch Serverlessの一般提供、Scale-to-zero、SEARCH/VECTORSEARCH、移行条件、OCU課金の確認項目を整理しました。
この記事は投資助言ではありません。AMZN株価、時価総額、短期的な市場反応ではなく、Amazon OpenSearch Serverlessを利用者、開発者、導入企業がどう確認するかを中心にしています。Amazon Watch JapanはAmazon.com, Inc.およびその関係会社とは非提携です。商標、サービス名、公式発表は各権利者に帰属します。
次に読むなら
参照した主な情報源
- AWS News Blog, "Introducing the next generation of Amazon OpenSearch Serverless for building your agentic AI applications", 2026年6月7日確認: https://aws.amazon.com/blogs/aws/introducing-the-next-generation-of-amazon-opensearch-serverless-for-building-your-agentic-ai-applications/
- Amazon Web Services ブログ, "AI エージェントアプリケーションを構築する次世代 Amazon OpenSearch Serverless の発表", 2026年6月7日確認: https://aws.amazon.com/jp/blogs/news/introducing-the-next-generation-of-amazon-opensearch-serverless-for-building-your-agentic-ai-applications/
- AWS Big Data Blog, "The next generation of Amazon OpenSearch Serverless: Built from the ground up for agents", 2026年6月7日確認: https://aws.amazon.com/blogs/big-data/the-next-generation-of-amazon-opensearch-serverless-built-from-the-ground-up-for-agents/
- Amazon OpenSearch Service製品ページ, 2026年6月7日確認: https://aws.amazon.com/opensearch-service/
- Amazon OpenSearch Service Pricing, 2026年6月7日確認: https://aws.amazon.com/opensearch-service/pricing/
- Amazon OpenSearch Serverless Developer Guide, 2026年6月7日確認: https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless.html