ひとことで言うと
RAG の面倒な部分（文書の解析・チャンク分割・埋め込み生成・ベクトルインデックスへの書き込み・検索・引用付きの生成）を、パイプラインを組まずに済ませるための仕組みです。Retrieve で検索結果だけを取ることも、RetrieveAndGenerate で回答まで作らせることもできます。
要するに、司書付きの書庫です。OpenSearch や Aurora を自分で組むのは「棚を借りて司書は自分で雇う」こと。Knowledge Bases は棚と司書がセットで、しかも司書はどの本の何ページから取ってきたかを必ず添えて返します（引用）。
だから試験の分岐は「棚が要るのか、司書ごと要るのか」です。棚だけ欲しい（自前のチャンク戦略・自前の再ランク）なら OpenSearch を直接使う選択肢が正解になります。
なぜ生まれたか
| 自前で RAG を組むと出てくる作業 | Knowledge Bases 側の受け皿 |
|---|---|
| PDF・PPTX・スキャン文書のテキスト化 | パーサの選択（基盤モデルによるパース／Bedrock Data Automation パーサ） |
| 文書をどう切るか | チャンク戦略（デフォルト／固定長／階層／セマンティック／分割しない） |
| 埋め込みモデルの選定と次元合わせ | Titan Embeddings・Cohere Embed の対応表と、ベクトルストア側の次元設定 |
| ベクトルインデックスの作成と同期 | データソース同期（取り込みジョブ） |
| 検索結果をプロンプトにどう入れるか | オーケストレーション／生成プロンプトテンプレート |
| 「その回答の根拠は？」への回答 | 引用（citation）の自動付与 |
要点は**「モデルを再学習させずに自社データを使う」**ことです。公式ドキュメントも費用対効果の理由として、独自データを使うためにモデルを継続的に学習させる必要がなくなる点を挙げています。D1 が31%と最大配点なのは、この「食わせ方と探し方」がアプリの品質をほぼ決めてしまうからです。
何に使うか
まずマネージドか、カスタマー管理かを選びます。ここが最初の分岐で、後段の選択肢が変わります。
| Managed Knowledge Base | Customer-managed Knowledge Base | |
|---|---|---|
| ベクトルストア | Bedrock が管理（ストレージの自動スケール） | 自分で用意（OpenSearch Serverless / OpenSearch マネージドクラスタ / S3 Vectors / Aurora / Neptune Analytics / Pinecone / Redis Enterprise Cloud / MongoDB Atlas） |
| コネクタ | S3・SharePoint・Confluence・Google Drive・OneDrive・Web Crawler | S3 など（サードパーティコネクタは非対応） |
| 文書単位のアクセス制御（ACL） | 検索時に適用（Web Crawler を除く） | 非対応 |
| AgentCore Gateway 連携 | ネイティブ統合（MCP ツールとして呼べる） | 非対応 |
| 高度な取り込み | Smart Parsing（文書種別ごとに解析方式を自動選択）、マルチモーダル | 自分で設定する |
| 検索 | Agentic Retrieval（複雑なクエリの分解・複数KBへの反復検索・十分性の評価） | 自分で組む |
試験でどう問われるか
D1 の 1.4（ベクトルストア設計）と 1.5（検索の設計）がほぼそのままここです。「精度が出ない」「取りこぼす」というシナリオに対して、どのつまみを回すかが問われます。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| 型番・製品コードで検索すると当たらない | 完全一致の語が効かない → ハイブリッド検索（overrideSearchType: HYBRID） | 埋め込みモデルを変える／チャンクサイズを大きくする |
| 検索は当たるが文脈が足りず回答が浅い | 小さいチャンクで拾い、広い文脈を渡したい → 階層チャンク（子で検索し親で返す） | 固定長チャンクのサイズだけ大きくする（今度は検索精度が落ちる） |
| 「最新版の文書だけを対象に」 | 更新日などの属性で絞る → メタデータフィルタ（greaterThan 等） | 古い文書をデータソースから削除する運用案 |
| 「AとBのどちらが多い？」型の複合質問 | 単一クエリでは根拠が揃わない → クエリ分解（QUERY_DECOMPOSITION） | numberOfResults を増やす |
| 上位に無関係な結果が混ざる | 取得後に並べ替えたい → リランカーモデル | 検索件数を減らす |
| 回答が検索結果から離れる（ハルシネーション） | 根拠との整合を機械で見たい → Guardrails の contextual grounding check | temperature を下げる（Guardrails のノート） |
| ユーザーごとに見せる文書を変えたい | 文書単位の権限 → Managed Knowledge Base の ACL フィルタ | KB をユーザーごとに作る案／アプリ側で後からフィルタする案 |
| バイナリ埋め込みでコストを下げたい | ストレージを削りたい → OpenSearch Serverless / マネージドクラスタ（バイナリ対応はこの2つだけ） | S3 Vectors（浮動小数点のみ）／Aurora |
ハイブリッド検索は「どこでも使える」わけではありません。対応は Amazon RDS・OpenSearch Serverless・MongoDB で、かつフィルタ可能なテキストフィールドを持つ場合に限られます。条件を満たさないベクトルストアでは、HYBRID を指定してもセマンティック検索にフォールバックします（エラーにならないので気づきにくい）。「ハイブリッドにしたのに完全一致が効かない」というシナリオは、ここを見ています。
実務でどう使うか
- チャンク戦略は後から変えられないつもりで選ぶ。 選べるのはデフォルト（約300トークン・文の区切りを尊重）／固定長（トークン数＋オーバーラップ率）／階層（親と子＋オーバーラップトークン数）／セマンティック（最大トークン・バッファサイズ・ブレークポイント百分位）／分割しない。セマンティックチャンクは基盤モデルを使うので追加コストがかかります
- 「分割しない」を選ぶと引用のページ番号が失われます。 ページ番号のメタデータ（
x-amz-bedrock-kb-document-page-number）が付かず、そのフィールドでのフィルタもできません。1ファイル＝1チャンクにしたいなら、事前にファイルを分けておくのが定石です - 階層チャンクでは戻る件数が要求より少なくなります。
numberOfResultsは子チャンクの数に対応し、同じ親を持つ子は最終的に親チャンクに置き換えられるためです。「5件要求したのに3件しか来ない」はバグではありません - 返却件数の既定は最大5件。 RAG の精度が出ないときに最初に触られるつまみですが、増やすほど入力トークンが伸びて課金も伸びます
- OpenSearch Serverless でメタデータフィルタを使うなら、インデックスのエンジンは
faiss。nmslibで作ってしまっているとフィルタが使えず、インデックスを作り直すしかありません - クロスリージョン推論を有効にすると、データがリージョンをまたいで共有されうると公式に明記されています。データ所在地の制約がある案件では、スループットのためだけに安易に有効化しないこと
ベクトルストアごとの地雷: S3 Vectors は浮動小数点のみ（バイナリ埋め込み不可）で、カスタムメタデータはベクトルあたり 1KB・35キーまで。階層チャンクとの併用は推奨されていません（親子関係がメタデータとして載るため上限に当たる）。Aurora ではメタデータ列に GIN インデックスが要り、フィルタを使うなら HNSW の反復スキャン有効化が推奨されます。「ベクトルストアはどれでも同じ」で設計すると、取り込みジョブが例外で落ちてから気づきます。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| OpenSearch Service を直接使う | KB＝取り込みから引用付き生成まで面倒を見る。OpenSearch 直＝インデックス設計・チャンク・再ランクを全部自分で決められる。「細かい制御が要る」と書いてあれば後者 |
| Amazon Kendra | Kendra は検索サービスそのもの。KB は Kendra GenAI インデックスをベクトルストアの代わりに使うこともできる（対立ではなく接続関係） |
| Amazon Q Business | Q は完成品の社内検索アシスタント。KB は自分のアプリに組み込む部品 |
| ファインチューニング | KB は知識を差し替える手段。ファインチューニングは振る舞い・文体を変える手段。「最新の社内文書に基づいて答えたい」なら常に RAG 側 |
| AgentCore Memory | Memory はそのユーザーとの会話から学ぶ。KB は組織の文書を引く。個人化と根拠付けは別の問題（AgentCore のノート） |
| Guardrails | KB は「正しい根拠を渡す」。Guardrails は「渡した根拠から外れていないか検査する」。RAG の品質はこの2つの合わせ技 |
想起チェック
Q1. Managed と Customer-managed を分ける実務上の一番の違いは？
ベクトルストアを自分で持つかどうか、そしてそれに伴ってサードパーティコネクタ・文書単位の ACL・AgentCore Gateway 連携が使えるかどうかです。これらは Managed 限定です。逆に、ベクトルインデックスの構成やパースを自分で握りたいなら Customer-managed。
Q2. 「検索の当たりは良いが、回答の文脈が足りない」ときのチャンク戦略は？
階層チャンクです。小さい子チャンクで精度よく当てて、返すときは親チャンクに置き換えて広い文脈をモデルに渡します。副作用として、返却件数が要求値より少なくなることがあります。
Q3. `overrideSearchType: HYBRID` を指定しても効かないことがあるのはなぜ？
ベクトルストアが対応していないからです。ハイブリッドは Amazon RDS・OpenSearch Serverless・MongoDB で、フィルタ可能なテキストフィールドを持つ場合のみ。条件を満たさないとセマンティック検索に静かにフォールバックします。
Q4. 「引用にページ番号を出したい」とき、選んではいけないチャンク戦略は？
**「分割しない（no chunking）」**です。ページ番号のメタデータが付かず、引用にも出せず、そのフィールドでのフィルタもできません。