ひとことで言うと
MongoDB互換のドキュメントDBです。5.0以降のインスタンスベースクラスタはネイティブのベクトル検索を持ち、JSONドキュメントとベクトル埋め込みを同じコレクションに同居させられます。
要するに、書類棚に虫眼鏡を内蔵した形です。もともとJSON文書を柔軟に出し入れする棚（DocumentDB）に、「似た文書を意味で探す」虫眼鏡（$vectorSearch）が標準装備された。専用の検索エンジンを別に建てなくても、棚の中で完結します。
なぜ生まれたか
すでにMongoDB互換のドキュメントDBに製品カタログやユーザープロファイルを持っている場合、ベクトル検索のためだけに別のデータストアへ移行したくないという要求があります。DocumentDBはこれに対して、既存のコレクション構造の上にベクトルインデックスを足す形で応えています。
| 起きる不便 | DocumentDBでの解決 |
|---|---|
| 既存のJSON文書構造と別に、ベクトル専用DBを増やしたくない | 同一コレクションにベクトルフィールドを追加するだけで済む |
| インデックス方式（速度と精度のトレードオフ）を選びたい | HNSW（高精度・構築遅め）とIVFFlat（構築速いが学習ステップが必要）を選択可能 |
| ミリ秒級の応答速度が要る | インデックスによる近似最近傍探索でミリ秒応答 |
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| 自前RAGのベクトルストア | 既存コレクションにベクトルフィールドを追加し、$vectorSearchで検索 | D1 |
| 商品レコメンド・パーソナライゼーション | 商品ベクトルとの類似度でレコメンドを生成 | D1 |
| Bedrock Knowledge Basesのベクトルストア | 不可。KBの公式ベクトルストア一覧には含まれない | — |
試験でどう問われるか
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| 既存のMongoDB互換資産の上でRAGを組みたい | DocumentDB（5.0以降）のネイティブベクトル検索を使う自前構成 | 「MongoDB互換ならBedrock KBに直結できる」（KBが公式サポートするのはMongoDBAtlasであり、DocumentDBは対象外） |
| インデックス構築が速い方を優先したい | IVFFlat（学習ステップなし、データロード後に作る） | HNSW（精度は高いが構築が遅い） |
| クエリ精度を優先したい | HNSW（多層グラフで探索、学習ステップ不要） | IVFFlat（クラスタ数の調整をミスると精度が落ちやすい） |
「MongoDB互換だからBedrock Knowledge Basesに使える」は誤りです。KBが公式サポートするのはサードパーティのMongoDB Atlasであって、AWSのAmazon DocumentDBはKBのベクトルストア一覧に入っていません。DocumentDBでRAGを組む場合は自前の検索レイヤーとして実装します。
実務でどう使うか
- インデックスなしでもベクトル検索自体は可能。 その場合は総当たりの厳密最近傍探索になり、精度は完全ですが本番の速度要件には向きません。インデックスは速度と引き換えに再現率(recall)を犠牲にするトレードオフです
- ベクトルは最大2,000次元までインデックス可能。 インデックスなしなら16,000次元まで格納だけはできますが、検索に使うなら次元数の上限を意識する必要があります
- IVFFlatは事前にデータをロードしてから作るのが定石。 クラスタリングに基づくインデックスのため、空の状態で作ると効果が薄くなります
ハマりどころ: probes（IVFFlat）やefSearch（HNSW）といった検索時パラメータは、値を上げるほど再現率は上がりますが速度は落ちます。デフォルト値（efSearchは40）のまま「精度が低い」と判断する前に、この調整余地があることを思い出す必要があります。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| MongoDB Atlas | Atlas＝Bedrock Knowledge Basesが公式サポート。DocumentDB＝サポート外（自前構成のみ）。同じMongoDB互換でも配達契約が違う |
| Amazon Aurora（KBのベクトルストア） | 既存資産がリレーショナルならAurora、ドキュメント（JSON）指向ならDocumentDBが自前構成の候補になる |
| Amazon Neptune Analytics | DocumentDBは文書単位の類似検索。Neptune Analyticsはグラフの関係性を跨いだ検索（GraphRAG）。「関連性を辿る」要求が出たらNeptune側 |
想起チェック
Q1. 既存のMongoDB互換資産をそのままBedrock Knowledge Basesのベクトルストアにできますか？
Amazon DocumentDBはできません。KBが公式サポートするMongoDB系はサードパーティのMongoDB Atlasのみです。DocumentDBでRAGを組むなら自前の検索レイヤーとして実装します。
Q2. インデックス構築を速くしたいが、学習ステップなしで使いたい。HNSWとIVFFlatどちらを選びますか？
HNSWです。多層グラフ構造を使うため学習（トレーニング）ステップが不要で、データロード前でもインデックスを生成できます。IVFFlatはクラスタリングの学習ステップが必要です。