ひとことで言うと
業務データが入っている PostgreSQL に、vector 列を1本足してベクトルストアにしてしまう選択肢です。Aurora PostgreSQL で pgvector 拡張を有効にし、チャンク本文・埋め込み・メタデータを同じテーブルの同じ行に置きます。
要するに、新しい棚を買わずに既存の棚に1段足す方法です。ベクトル専用ストアを選ぶと、システムが1つ増え、バックアップも権限もネットワークも監視も増えます。Aurora ならすでに運用しているデータベースの作法がそのまま効く——同じトランザクション、同じ IAM、同じスナップショット、同じ Secrets Manager です。
その代わり、ベクトル索引の面倒は自分で見ます。HNSW 索引を張るのも、全文検索用の GIN 索引を張るのも、メタデータ用の GIN 索引を張るのも、SQL を自分で打つ仕事です。
なぜ生まれたか
RAG を足したいだけなのに、多くの構成ではベクトルDBという新しいコンポーネントを1つ増やすことになります。増えるのはストアだけではありません。元データとベクトルの整合をアプリ側で取り続ける責任が生まれ、「文書は消したのにベクトルが残っている」が起きます。同じ行に置いてあれば、これは DELETE 1回で済みます。
Aurora 側の下地としては、ストレージが自動で伸びること（クラスタボリュームは最大 256TiB まで拡張）と、容量を自動調整する Aurora serverless（0.5 ACU 刻みで増減し、プロビジョンドのように「まるごと1インスタンス追加」にならない）があります。ベクトル列はサイズが読みにくいので、この2つが効きます。
| 別のベクトルDBを立てると出てくる作業 | Aurora pgvector 側の受け皿 |
|---|---|
| 元データとベクトルの整合を取り続ける | 同じ行に本文チャンク・埋め込み・メタデータを置く |
| ストアごとに権限・鍵・ネットワークを設計する | 既存の Aurora の IAM / Secrets Manager / VPC に相乗りする |
| 容量計画を新規に立てる | ストレージは自動拡張（最大 256TiB）、コンピュートは Aurora serverless が 0.5 ACU 刻みで追随 |
| メタデータ絞り込みを自前実装する | jsonb の custom_metadata 列 ＋ GIN 索引（Bedrock がこの形を要求します） |
| キーワード検索を別に用意する | to_tsvector に GIN 索引を張る（これが Bedrock KB のハイブリッド検索の実体） |
何に使うか
| 用途 | 使い方 | 関連する試験ドメイン |
|---|---|---|
| Bedrock KB のベクトルストア | bedrock_integration スキーマに id uuid / embedding vector(n) / chunks text / metadata json / custom_metadata jsonb を持つテーブルを作る | D1 |
| ハイブリッド検索 | chunks に to_tsvector の GIN 索引を張る。Bedrock KB がハイブリッド検索に対応する数少ないストアの1つ | D1 |
| メタデータフィルタ | custom_metadata（jsonb）に GIN 索引。数値の範囲フィルタを多用するならキー単位の式インデックス | D1 |
| 業務データとの結合 | ベクトル検索の結果を、同じDB内のマスタテーブルと JOIN する | D1 / D2 |
| コスト調整 | Aurora serverless で、アイドル時の容量を落とす | D4 |
試験でどう問われるか
**Aurora は「ベクトルストアの選択肢」として D1 に出ます。**主役ではありませんが、この条件なら Auroraという分岐がはっきりしているので、条件語を覚えれば確実に取れる側です。加えて、セットアップ要件が具体的（RDS Data API・Secrets Manager・列と索引の形）なので、そこを狙った出題が作りやすい対象でもあります。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| どのベクトルストアを選ぶか | 「すでに PostgreSQL / Aurora を運用している」「新しいデータストアを増やしたくない」「ベクトル検索の結果を業務テーブルと結合したい」→ Aurora pgvector | 「運用負荷を最小にしたい」だけの記述で Aurora を選ぶ（索引設計が自分持ちなので、その要件なら他が有利） |
| ハイブリッド検索が要る | Bedrock KB でハイブリッドに対応するのは Amazon RDS（Aurora）・OpenSearch Serverless・MongoDB（フィルタ可能なテキストフィールドを持つ場合）。Aurora はここに入ります | Pinecone / Redis / S3 Vectors / Neptune Analytics |
| Bedrock から接続できない | RDS Data API が有効になっていない、または Secrets Manager のシークレットが無い。この2つは前提条件です | 「セキュリティグループを開ける」「パブリックアクセスにする」 |
| メタデータで絞れない／遅い | custom_metadata（jsonb）列に GIN 索引が無い。数値の範囲フィルタが多いならキー単位の式インデックスを追加する | 「HNSW の次元数を上げる」「埋め込みモデルを変える」 |
| フィルタを付けると結果が減る | HNSW の反復スキャン（iterative scan）が無効。HNSW 索引を先に走らせてから絞るため、選択性の高いフィルタだと件数が足りなくなります。hnsw.iterative_scan を有効化します（pgvector 0.8.0 以降） | 「numberOfResults を増やす」（根本原因はスキャン側なので効きません） |
| 列の設計を後から直せるか | 直せません。 ナレッジベース作成前に列を用意する必要があり、作成後は更新できないと明記されています | 「あとで ALTER TABLE すればよい」 |
| ベクトルの次元数 | 埋め込みモデルに合わせます。Titan v2 は 1024 / 512 / 256、Titan v1.2 は 1536、Cohere Embed は 1024、Cohere Embed Multilingual v3 は 1024 | 「とりあえず 1536 で作る」（v2 系を選んだ時点で不一致になります） |
| アカウントをまたぐ構成 | Aurora クラスタは、ナレッジベースを作るアカウントと同じアカウントに置く必要があります | 「共有アカウントのDBを参照する」 |
| コスト（D4） | 問い合わせが疎／時間帯で偏る → Aurora serverless（0.5 ACU 刻みで増減し、使った分だけの課金） | 「小さいインスタンスクラスに固定する」 |
「Aurora＝ハイブリッド検索できる側」は暗記しておく価値があります。Bedrock Knowledge Bases でハイブリッド検索に対応するストアは Aurora・OpenSearch Serverless・MongoDB の3つだけで、他を選ぶと指定してもセマンティック検索として実行されます（エラーにならないので、実務では気づきにくい）。そして Aurora 側でハイブリッドを支えている実体は、chunks 列に張った to_tsvector の GIN 索引です。索引を張り忘れた Aurora は、ハイブリッド対応ストアの顔をして中身が伴いません。
実務でどう使うか
- 前提の3点セットは、Aurora PostgreSQL のバージョン・
pgvector0.5.0 以上・RDS Data API です。 公式が挙げるバージョンは 16.1 以上のすべて / 15.4 以上 / 14.9 以上 / 13.12 以上 / 12.16 以上。pgvectorは 0.5.0 以上（HNSW 索引が入ったバージョン）を要求されます。入っているバージョンはSELECT extversion FROM pg_extension WHERE extname='vector';で確認します - 索引は3種類を別々に張ります。 ①ベクトル:
USING hnsw (embedding vector_cosine_ops)②テキスト:USING gin (to_tsvector('simple', chunks))③メタデータ:USING gin (custom_metadata)。このうち1つでも欠けると、対応する検索経路だけが静かに遅くなります ef_constructionは 256 が公式の推奨値です（pgvector0.6.0 以降の並列インデックス構築を使う場合）- 英語コンテンツなら
to_tsvector('english', chunks)を検討します。 公式が「ハイブリッド検索の精度とレイテンシの改善のためにsimpleではなくenglish辞書を」と書いています。日本語には該当する記述がありません - 反復スキャンの設定は、既存セッションには効きません。
ALTER DATABASE ... SET hnsw.iterative_scan = 'relaxed_order';とhnsw.max_scan_tuples = 20000はデータベースレベルで永続しますが、新しいセッションからしか有効になりません。RDS Data API 経由の場合は、コネクションプールのセッションが入れ替わるまで数分待ちます bedrock_userのようなロールを分けて作ります。 公式手順は、専用スキーマbedrock_integrationと専用ロールを作り、そのロールでテーブルを作る流れです。マスタユーザーで全部やる構成は、後で権限を絞れなくなります- メタデータ列を1本にまとめるか、属性ごとに列を立てるかは、取り込み前に決めます。
custom_metadata1列にまとめる方が推奨で、まとめない場合は属性ごとに列を作り、型（text / number / boolean）まで指定しておく必要があります
Aurora のコストは「クエリが来なくても発生する」側です。トークン単価ではなくコンピュートとストレージなので、誰も検索していない夜間もクラスタは動いています。問い合わせが疎な RAG に固定容量のプロビジョンドクラスタを当てると、ベクトル検索そのものより待機時間のほうが高くつきます。Aurora serverless が候補に挙がるのはここです。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Amazon OpenSearch Serverless | 全文検索・ファセット・地理条件・十億規模のベクトルなら OpenSearch。既存の関係データと結合したいなら Aurora。ハイブリッド検索はどちらも可 |
| Amazon S3 Vectors | 問い合わせ頻度が低いワークロード向けの低コスト側。ハイブリッド検索の対応ストアに入っていません。Aurora は入ります |
| Amazon Bedrock Knowledge Bases（マネージド） | ベクトルストアを Bedrock が丸ごと持つ形。自分でDBを持たない代わりに、索引設計に手を入れられません。Aurora は逆 |
| Amazon RDS for PostgreSQL | pgvector 自体は PostgreSQL の拡張ですが、Bedrock KB の前提として案内されているのは Aurora PostgreSQL と RDS Data API の組み合わせです |
| Amazon Neptune Analytics | どちらも「既存データの隣にベクトルを置く」形だが、Neptune は関係をたどる（GraphRAG）用。行と JOIN の世界なら Aurora |
| Aurora serverless と Aurora プロビジョンド | ベクトルストアとしての機能差ではなく容量の決め方の違い。0.5 ACU 刻みで追随するのが serverless |
想起チェック
Q1. 「既存の PostgreSQL 資産があり、新しいデータストアは増やしたくない」。この条件で外れるのはどんな要件が併記されたときですか。
「運用負荷を最小にしたい」「索引設計に手を入れたくない」が併記されたときです。Aurora pgvector は HNSW 索引・GIN 索引を自分で張る前提なので、その要件ならマネージド側が正解になります。
Q2. Bedrock から Aurora のベクトルストアに接続できません。機能の前提として最初に確認する2つは？
RDS Data API が有効かと、Secrets Manager にDB資格情報のシークレットがあるかです。どちらも公式の前提条件で、ネットワーク設定の話ではありません。
Q3. Aurora でハイブリッド検索を成立させている索引は、具体的にどれですか。
chunks 列に張った to_tsvector の GIN 索引です。これが無いとキーワード側の経路が支えられません。ベクトル側の HNSW 索引とは別物です。
Q4. メタデータフィルタを付けると、期待より少ない件数しか返りません。原因と対処は？
HNSW の反復スキャンが無効なためです。HNSW 索引で絞ってからフィルタを適用するので、選択性の高いフィルタでは件数が足りなくなります。hnsw.iterative_scan を有効にします（pgvector 0.8.0 以降。新規セッションから有効）。
Q5. 埋め込みモデルに Titan v2 を選びました。`vector(n)` の `n` はいくつにしますか。
1024 / 512 / 256 のいずれか（選んだ次元に合わせる）です。1536 は Titan v1.2 の値で、v2 に当てると不一致になります。