ひとことで言うと
全文検索エンジンのドキュメントの中に、ベクトル（knn_vector フィールド）が同居しているストアです。1件のドキュメントが本文テキスト・数値・日付・geo_point とベクトルを同時に持つので、意味の近さと構造的な条件を1回のクエリで併せて効かせられます。
要するに、ベクトルDBではなく検索エンジンです。公式のフィルタ例がそのまま性格を表しています——「このベクトルに近い物件で、かつ price が 3000 以下で、かつ指定座標から100マイル以内」を1本の knn クエリで書けます。
ベクトル専用ストアは「意味が近い順」しか返せません。OpenSearch が試験で勝つのは、キーワード・メタデータ・地理条件がベクトルと同じ土俵に乗っている場面です。
なぜ生まれたか
ベクトル検索のために別のデータベースを立てると、同じ文書が2箇所に分裂します。本文とメタデータは検索エンジン、ベクトルはベクトルDB。すると「意味が近くて、かつ部署が engineering のもの」を出すのに、両方を叩いて突き合わせるアプリ側のコードが要ります。公式が「データ型を同じ場所に置くこと（colocating the data types）が複雑さを減らし、データの二重持ち・バージョン互換・ライセンスの問題を避ける」と書いているのは、この分裂への回答です。
もう1つは運用の重さです。プロビジョンドのドメインはインスタンス数・シャード・メモリを自分で決めます。OpenSearch Serverless はここを分解し、インデックス（取り込み）とサーチ（検索）のコンピュートを分離して、インデックスの実体を S3 に置く構成にしました。取り込みと検索を別々にスケールでき、リソースの取り合いも起きません。
| 自前で組むと出てくる不便 | OpenSearch 側の受け皿 |
|---|---|
| ベクトルとメタデータが別ストアに分かれる | 同じインデックスに knn_vector と text / long / geo_point を同居させる |
| 埋め込み生成をアプリ側で書く | AI コネクタ（Amazon Bedrock / SageMaker AI / Hugging Face / 自前モデル）と取り込みパイプラインで、検索エンジン側に寄せる（OpenSearch 2.9 以降の semantic search） |
| パイプラインの設定自体が面倒 | 2.19 以降の automatic semantic enrichment が、テキストフィールドのスパースエンコーディングを自動生成する |
| クラスタのサイジングとシャード設計 | OpenSearch Serverless（インデックスとサーチのコンピュートを分離し、S3 を一次ストレージにする） |
| 使っていない時間も課金が続く | NextGen ベクトル検索コレクションは、アイドル時にインデックスもサーチも 0 までスケールする |
何に使うか
| 用途 | 使い方 | 関連する試験ドメイン |
|---|---|---|
| RAG のベクトルストア | OpenSearch Serverless の vector search コレクション、またはプロビジョンドドメインの k-NN インデックスを Bedrock Knowledge Bases のベクトルストアに指定する | D1 |
| ハイブリッド検索 | キーワード（生テキスト）とベクトルを併用する。Bedrock KB からは overrideSearchType: HYBRID | D1 / D4 |
| フィルタ付きセマンティック検索 | knn クエリの filter に range / geo_distance / query_string を入れる | D1 |
| 埋め込み生成の内製化 | AI コネクタで Bedrock / SageMaker AI のモデルを呼び、取り込み時にベクトル化する | D1 / D2 |
| 検索品質・レイテンシの監視 | CloudWatch のドメインメトリクス（k-NN の統計を含む） | D4 / D5 |
| コスト階層化 | UltraWarm / コールドストレージ（読み取り専用データ向け）。k-NN インデックスは 2.17 以降のドメインで移行できる | D4 |
試験でどう問われるか
D1（配点31%）の「ベクトルストア設計」「検索設計」の中心にいます。問われ方は「OpenSearch とは何か」ではなく、Aurora pgvector・S3 Vectors・Neptune Analytics・マネージド Knowledge Base と並べて、どれを選ぶかです。分岐を作っている条件は、ほとんどが公式が明記している対応・非対応なので、そこを覚えれば取れます。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| Bedrock KB でハイブリッド検索を使いたい | 公式が対応と明記しているのは Amazon RDS（Aurora）・OpenSearch Serverless・MongoDB で、しかもフィルタ可能なテキストフィールドを持つ場合に限られます。それ以外のストアではクエリはセマンティック検索に落ちます | Pinecone / Redis Enterprise Cloud / S3 Vectors / Neptune Analytics を選ばせる。「ハイブリッドにしたい」と書いてあるのにストアがこれらなら、その選択肢は成立しません |
| メタデータフィルタが効かない | ベクトルインデックスのエンジンが nmslib になっている。faiss で作り直す（または Bedrock にインデックスを自動作成させる） | 「IAM 権限を追加する」「次元数を変える」 |
| Serverless でコレクションを作る | vector search コレクションを選ぶ。search / time series コレクションでは k-NN 型インデックスが作れません。コレクション型は作成後に変更できません | 「全文検索も要るので search コレクションにする」（k-NN が使えず詰みます） |
| バイナリ埋め込みを保存したい | 公式が「バイナリベクトルを保存できる唯一のストア」と書いているのが OpenSearch Serverless と OpenSearch マネージドクラスタです | S3 Vectors（浮動小数点のみと明記）／Aurora |
| KB のベクトルストアにマネージドドメインを使う | ネットワークは Public access が必須。VPC の中に置いたドメインは Knowledge Base ではサポートされません | 「セキュリティ要件があるので VPC 内に置く」（要件としては正しく見えるが、この構成では通りません） |
| KB のドメインのバージョン | k-NN インデックスの作成に 2.13 以上、バイナリ埋め込みを使うなら 2.16 以上 | 「最新でなくても動く」 |
startsWith でメタデータを絞りたい | 公式が「OpenSearch Serverless のベクトルストアでのみサポート」と書いています | Aurora / S3 Vectors（S3 Vectors は startsWith と stringContains が使えないと明記） |
| チャンク戦略・リランクを自分で組みたい | 取り込みパイプラインと検索パイプラインを自分で持てる OpenSearch を直接使う | Bedrock Knowledge Bases（パイプラインを預ける側なので、細かい介入の要件とは向きが逆） |
| 埋め込みモデルを検索エンジン側から呼びたい | AI コネクタ（Bedrock / SageMaker AI）＋ neural search。2.9 以降 | Lambda を書いて自前でベクトル化する（できますが、要件が「設定で済ませたい」ならこちらは外れます） |
| コスト（D4） | アイドル時間が長い／クエリが疎 → NextGen コレクションの 0 スケールと32x 圧縮（既定）。読み取り専用の古いデータ → UltraWarm / コールドストレージ | プロビジョンドドメインのインスタンスを小さくする（止まらないので、疎なワークロードでは効きません） |
「ハイブリッド検索」はこの試験で最も差が付く分岐です。シナリオに製品番号・型番・社内の略語・人名といった「意味では近づけない語」が出てきたら、それはベクトル単独では落ちる合図で、ハイブリッドを要求しています。そのときストア側がハイブリッドに対応していない選択肢は、他がどれだけ正しそうでも外れます——Bedrock KB では Aurora・OpenSearch Serverless・MongoDB の3つだけです。逆に「ハイブリッドにしたのに効かない」と書かれていたら、疑うのはフィルタ可能なテキストフィールドの有無です。
実務でどう使うか
kとsizeは両方指定します。sizeを省くと、k件は「クエリ全体でk件」ではなくシャードごと・セグメントごとにk件返ります。kの最大は 10,000 ですpost_filterを併用すると、返る件数がkを下回ります。 公式の例でも 2件が1件に減っています。「絞り込むと結果が消える」の典型がこれです- 次元数の上限は、見ているページで数字が違います。 k-NN のページは
knn_vectorを「最大10,000個の float のリスト」、ベクトル検索とServerless のページは「16,000次元まで」と書いています。1つの数字を暗記して現場に持ち込まず、使う経路のドキュメントで確かめてください - Serverless の Classic と NextGen は別物です。 Classic は既定エンジンが
nmslib、warmup/stats/ モデル学習 API とインラインスクリプトが非対応、リフレッシュ間隔60秒。NextGen はengine/modeの指定自体が不要で、リフレッシュ間隔10秒、既定で 32x 圧縮（1x / 2x / 8x / 16x / 32x から選択可）、検索レスポンスから元ベクトルが既定で除かれます（_source: trueで戻せます）。NextGen の 32x 圧縮インデックスでは radial search が使えません - 200 OCU を超えるスケールは AWS Support への申請が要ります（Classic のベクトル検索コレクションで、数百万〜十億規模のベクトルを扱う場合）
- プロビジョンドドメインでは、グラフのメモリが静かに天井を打ちます。 OpenSearch Service はインスタンス RAM の半分を Java ヒープに使い（上限32GiB）、k-NN は既定でその残り半分の 50% まで使います。RAM 32GiB のインスタンスなら 8GiB（32×0.5×0.5） が目安で、
KNNGraphMemoryUsageメトリクスがこれを超えると性能が落ちます knn.memory.circuit_breaker.enabledとknn.circuit_breaker.triggeredは OpenSearch Service では変更できません。 他の k-NN 設定は_cluster/settingsから変えられます- ウォーム層に移した k-NN インデックスでは、キャッシュクリアとウォームアップ API がブロックされます。 最初のクエリで S3 からグラフを落としてメモリに載せる挙動になるので、移した直後の1発目が遅いのは仕様です
コレクション型は後から変えられません。「とりあえず search コレクションで作って、あとでベクトルも入れる」ができない設計です（search / time series では k-NN 型インデックスを作れません）。加えて、マネージドドメインから Serverless コレクションへの自動移行は存在せず、再インデックスが必要です。ここは PoC の入口で間違えると作り直しになります。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Amazon Bedrock Knowledge Bases | KB はパイプラインごと預ける側。OpenSearch は棚だけ貸す側。KB のベクトルストアとして OpenSearch を指定する構成もあるので、「対立」ではなく「層が違う」 |
| Aurora（pgvector） | 既存の PostgreSQL 資産・トランザクション・JOIN があるなら Aurora。全文検索・ファセット・地理条件・大規模な k-NN が要るなら OpenSearch |
| Amazon S3 Vectors | 公式が「問い合わせ頻度が低いワークロードに向く」と書いている低コスト側。バイナリ埋め込み非対応・startsWith / stringContains 非対応。低レイテンシで叩き続けるなら OpenSearch |
| Neptune Analytics（GraphRAG） | ベクトル索引を持つが本体はグラフ。関係をたどる検索が要件なら Neptune、類似度＋条件なら OpenSearch |
| Amazon Kendra | Kendra は索引と検索の中身を隠したマネージド検索。OpenSearch はインデックス設計を自分で握る。なお Kendra は2026年に新規顧客の受付を終了しています |
| OpenSearch Serverless（Serverless 内の型違い） | vector search / search / time series は用途で分かれた別物。k-NN が要るなら vector search 一択 |
想起チェック
Q1. Bedrock Knowledge Bases で「キーワードと意味の両方で当てたい」。ベクトルストアの選択肢を3つに絞れますか。
Amazon RDS（Aurora）・OpenSearch Serverless・MongoDB の3つで、しかもフィルタ可能なテキストフィールドを持つ場合だけです。それ以外のストアでは、指定してもクエリはセマンティック検索として実行されます。
Q2. OpenSearch Serverless でベクトル検索を始めるとき、最初に間違えると取り返しがつかない選択は？
コレクション型です。vector search を選ばないと k-NN 型インデックスが作れず、しかも作成後に型は変更できません。search / time series では k-NN が使えません。
Q3. Bedrock KB でメタデータフィルタを設定したのに結果が絞れません。OpenSearch Serverless 側で最初に見る場所は？
ベクトルインデックスのエンジンが nmslib になっていないかです。faiss で作り直すか、Bedrock にインデックスを自動作成させます。
Q4. `knn` クエリで `k: 10` を指定したのに、想定よりずっと多く返ってきました。何を忘れましたか。
size の指定です。size を併記しないと、k はクエリ全体ではなくシャードごと・セグメントごとに効きます。
Q5. RAM 32GiB のインスタンスで k-NN グラフに使える目安の容量は？ その根拠は？
約 8GiB です。RAM の半分が Java ヒープ（上限32GiB）に取られ、k-NN は既定でその残り半分の 50% までを使うため、32×0.5×0.5 になります。超過は KNNGraphMemoryUsage メトリクスで見ます。