AIP-C01で最大配点の分野1、その中核がRAGの検索側の設計です。「どうチャンクするか」「どのベクトルストアを選ぶか」「検索精度をどう上げるか」——本番のRAGアプリの品質はほぼここで決まり、試験でも設計判断が正面から問われます。この記事では、チャンク戦略／埋め込みモデル／ベクトルストア8種の選択肢／ハイブリッド検索とリランカー／同期とスケール設計を、公式試験ガイド（Task 1.4・1.5）とAWSドキュメントの一次情報で解説します。RAGの基礎概念からの人は先に RAGとBedrock Knowledge Bases【AIF-C01】 をどうぞ。
ステップ①：チャンク戦略——分割の仕方で検索精度が決まる
Amazon Bedrockナレッジベースは、データ取り込み時に文書をチャンクへ分割してから埋め込みます。公式がサポートする戦略は次のとおりです（AWSドキュメント「How content chunking works」準拠）。
| チャンク戦略 | 仕組み | 使いどころ |
|---|---|---|
| デフォルト | 約300トークンで分割。文の境界を尊重し文が途中で切れない | まず動かす初期構成 |
| 固定サイズ | チャンクあたりの最大トークン数とオーバーラップ率（%）を指定 | チャンク粒度を明示的に制御したいとき |
| 階層（Hierarchical） | 親チャンクと子チャンクの入れ子。検索は精密な「子」で行い、FMに渡す際は文脈の広い「親」に置き換える | 規程・マニュアルなど構造のある長文（「精密検索」と「豊かな文脈」の両立） |
| セマンティック | 文間の意味的な距離で切れ目を判定（最大トークン・バッファサイズ・分割しきい値を指定）。FMを使うため追加コストが発生 | 話題の切り替わりが重要な文書 |
| チャンクなし | 1文書＝1チャンク。事前に自分でファイル分割しておく前提 | FAQ集など既に1件ずつ完結している文書 |
| カスタム（Lambda） | Lambda関数で独自の分割・変換ロジックを実装 | 表・コード混じりなど特殊フォーマット |
試験の判断軸はシンプルで、「文書の構造と検索要件に分割方法を合わせる」です。章・節構造のある長文に固定サイズを機械適用すると文脈が分断される——これが典型的なひっかけです。なお階層チャンクはS3ベクトルバケットとの併用が非推奨（親子関係のメタデータがサイズ上限に達しやすい）という組み合わせ制約も公式ドキュメントに明記されています。
ステップ②：埋め込みモデルの選定
チャンクをベクトルに変換するのが埋め込み（エンベディング）モデルです。AWSの代表はAmazon Titan Text Embeddings V2で、ポイントは出力次元を選べること——既定の1024に加えて512・256次元も選択できます（ナレッジベース公式ドキュメントに明記）。次元が大きいほど表現力は上がりますが、ストレージと検索コストも増えるため、「ドメインへの適合性と次元数のトレードオフ」が試験ガイド（スキル1.5.2）の言う選定基準です。
- 次元数とコストはトレードオフ——精度要件を満たす最小の次元を選ぶのがコスト最適
- ストア側の対応も確認——例えばバイナリベクトル埋め込みを保存できるのはOpenSearch（Serverless／Managed）のみ（公式ドキュメント）。埋め込みの選択がストアの選択を制約する
- 大量文書のベクトル化はバッチ生成——Lambda関数で埋め込みをバッチ処理するパターン（スキル1.5.2）
ステップ③：ベクトルストアの選択肢——8種を整理
Bedrockナレッジベースが公式にサポートするベクトルストアは、AWSネイティブ5種＋サードパーティ3種です（公式セットアップドキュメント準拠・2026年7月時点）。
| ベクトルストア | 特徴と選びどころ |
|---|---|
| Amazon OpenSearch Serverless | クイック作成対応の定番。バイナリベクトル対応。VPCエンドポイントでプライベート化可能 |
| Amazon OpenSearch Managed Cluster | 既存ドメインを活用。k-NNインデックス（エンジンはfaiss）で構成 |
| Amazon S3 Vectors | 低コスト志向の新顔。インフラのプロビジョニング不要で大規模ベクトルを耐久保存、サブ秒クエリ。クエリ頻度が低いワークロード向け（浮動小数点のみ対応） |
| Amazon Aurora PostgreSQL（pgvector） | 使い慣れたRDBでベクトル検索。カスタムメタデータ列＋GINインデックスでフィルタリング |
| Neptune Analytics（GraphRAG） | グラフ＋ベクトルの融合。エンティティ間の関係を辿る検索が効くドメイン（人・組織・製品のつながり等） |
| Pinecone／Redis Enterprise Cloud／MongoDB Atlas | サードパーティ製。既存契約・既存データがあるなら選択肢（認証情報はSecrets Manager経由で連携） |
選定軸は3つ——①クエリ頻度とコスト（低頻度ならS3 Vectors、常時高負荷ならOpenSearch）、②既存資産（PostgreSQL運用チームならAurora）、③検索の性質（関係性を辿るならGraphRAG）。「とにかくマネージドで最速に」ならクイック作成つきのナレッジベース＋OpenSearch Serverlessが既定解です。
メタデータ設計——検索の適合率を底上げする
ベクトルの類似度だけに頼らず、メタデータでの絞り込み（フィルタリング）を併用するのがProfessional級の設計です（スキル1.4.2）。
- 何を持たせるか——文書のタイムスタンプ、著者情報、タグによるドメイン分類など。「2025年度の規程だけから検索」「営業部門の文書に限定」が可能になる
- ストアごとの実装——S3 Vectorsは1ベクトルあたり最大1KB・35キーのメタデータ（超過すると取り込みジョブがエラー）。Auroraはカスタムメタデータ列にGINインデックスを作成して高速フィルタ
- ソース帰属にも効く——回答の引用元表示（どの文書のどの部分か）はメタデータがあってこそ
検索精度の仕上げ：ハイブリッド検索とリランカー
ベクトル検索は言い換えに強い一方、型番・製品名・条文番号のような「完全一致すべき固有文字列」に弱いという弱点があります。そこで——
- ハイブリッド検索——キーワード検索（字句一致）とベクトル検索（意味）を組み合わせ、両方の強みを取る（スキル1.5.4）。OpenSearchのセマンティック検索＋キーワードの併用が代表例
- リランカー（再ランキング）——Amazon BedrockのRerank APIは、クエリとチャンク群を受け取って関連度スコアで並べ直す専用モデルを提供。ナレッジベースのRetrieve／RetrieveAndGenerate呼び出しに組み込むと、既定の順位づけを上書きできます。「少数だが高関連の結果」だけをFMに渡せるため、精度向上と同時にコスト・レイテンシー削減にも効く（公式ドキュメント。対象はテキストデータのみ）
- クエリ側の加工——検索前にクエリを拡張（同義語の追加）・分解（複合質問を分割）・変換するパイプラインをBedrock＋Lambda＋Step Functionsで構成（スキル1.5.5）
運用の設計：鮮度・スケール・アクセス統一
- 鮮度（スキル1.4.5）——ベクトルストアの中身は放っておくと古くなる。増分更新メカニズム・リアルタイム変更検出・自動同期ワークフロー・定期更新パイプラインで「最新の正しい情報」を維持する
- スケール（スキル1.4.3）——大規模化したらOpenSearchのシャーディング戦略、ドメイン特化のマルチインデックス、階層型インデックスで検索性能を保つ
- アクセスの統一（スキル1.5.6）——ベクトル検索を関数呼び出しインターフェイスやMCPクライアント経由で公開し、エージェントやアプリから一貫したパターンで利用できるようにする（MCPの実装は エージェンティックAI実装 を参照）
確認クイズ（本番形式・3問）
Q1. 社内マニュアル（章・節構造の長文）のRAGで「検索は精密にしたいが、FMに渡すコンテキストは前後を含めて広く取りたい」。この要件に最も合うBedrockナレッジベースのチャンク戦略はどれか？
Q2. 数億件のベクトルを保存するが、検索は月次のバッチ分析でしか実行しない。ストレージコストを最小化したいときのベクトルストアはどれか？
Q3. RAGの検索結果20件をそのままFMに渡しているが、無関係なチャンクが混ざり回答品質が低く、入力トークンコストも高い。最も直接的な改善はどれか？
よくある質問（FAQ）
Q. チャンクサイズはいくつが正解ですか？
A. 万能の正解はありません。目安として、デフォルト（約300トークン）から始めて検索品質を測り、文脈不足なら階層チャンク、話題の混在が問題ならセマンティックへ——と文書の性質に合わせて調整します。試験でも「数値の暗記」ではなく「文書構造との対応づけ」が問われます。
Q. 埋め込みモデルは後から変更できますか？
A. 埋め込みモデル（や次元数）を変えると、既存ベクトルとの互換性がなくなるため原則として全データの再ベクトル化（再取り込み）が必要です。ベクトルストア側もモデルの次元に合わせて構成するため（Neptune Analyticsではグラフ作成時に次元が固定、など）、モデル選定は最初に慎重に行いましょう。
Q. GraphRAGは普通のRAGと何が違うのですか？
A. 通常のRAGが「意味が近いチャンク」を探すのに対し、GraphRAG（Neptune Analytics）はエンティティ間の関係（グラフ）を辿って関連情報を集められるのが違いです。「A社の子会社の製品の不具合履歴」のように、つながりを何段も辿る質問に強くなります。
まとめ
- チャンク戦略は文書構造に合わせる：構造のある長文＝階層、意味の切れ目重視＝セマンティック（追加コスト）、完結文書＝チャンクなし
- ベクトルストアは頻度・コスト・既存資産・検索の性質で選ぶ：定番＝OpenSearch Serverless、低頻度大規模＝S3 Vectors、RDB資産＝Aurora（pgvector）、関係探索＝GraphRAG
- 精度の仕上げはメタデータフィルタ＋ハイブリッド検索＋リランカー。リランカーは精度とコスト・レイテンシー削減を両立
- 運用では増分更新での鮮度維持とシャーディング／マルチインデックスでのスケールを設計に織り込む
出典（2026年7月11日閲覧）：AWS公式試験ガイド（AIP-C01）Task 1.4／1.5、How content chunking works for knowledge bases、Prerequisites for your own vector store、Improve the relevance of query responses with a reranker model。
コメント