6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@masaki_yoshimura
in

Amazon Bedrock Knowledge Bases × S3 Vectors で社内ナレッジ検索RAGを構築する ── ベクトルDB選定からチャンク戦略

6
Last updated at Posted at 2026-03-23

はじめに

「社内ドキュメントが散在していて、欲しい情報がなかなか見つからない」──これは多くの組織が抱える共通の課題です。

社内Wiki、製品マニュアル、FAQ、議事録など、日々増え続けるドキュメントを従来のキーワード検索だけで探すのは限界があります。「あの件、どこかに書いてあったはずだけど……」という経験は、誰しも一度はあるのではないでしょうか。

この課題を解決するのが RAG（Retrieval-Augmented Generation：検索拡張生成） です。RAGは、ユーザーの質問に対して関連ドキュメントをベクトル検索で取得し、その内容をもとにLLM（大規模言語モデル）が回答を生成するアーキテクチャです。

本記事では、Amazon Bedrock Knowledge Bases と Amazon S3 Vectors を使って、社内ナレッジ検索RAGシステムを構築します。特に以下の3点に焦点を当てます。

  1. ベクトルDB選定：2025年12月にGA（一般提供）となったS3 VectorsとOpenSearch Serverlessの比較
  2. チャンク戦略：固定サイズ・セマンティック・階層の3方式を同一ドキュメントで比較検証
  3. コスト最適化：S3 Vectorsによるコスト削減効果の実測

対象読者：Bedrock Knowledge BasesでRAGを構築したいエンジニア、データエンジニア

image.png

構築するシステムの全体アーキテクチャ

今回構築するRAGシステムの全体像は以下のとおりです。

image.png

各コンポーネントの役割は以下のとおりです。

コンポーネント 役割
Amazon S3（データソース） 社内ドキュメント（PDF、Markdown、テキスト等）を格納
Amazon Bedrock Knowledge Bases データソースからドキュメントを取得し、チャンク分割・Embedding生成・ベクトル格納を自動実行。RAGワークフロー全体をフルマネージドで管理
Amazon S3 Vectors ベクトルストアとして、Embeddingベクトルを格納・検索。S3ネイティブでコスト効率が高い
Amazon Bedrock（LLM） 検索結果をコンテキストとして受け取り、ユーザーの質問に対する回答を生成

Knowledge Basesのフルマネージドな仕組みにより、ドキュメントのアップロードからEmbedding生成、ベクトル格納、検索、回答生成までの一連のRAGパイプラインを、最小限の設定で実現できます。

ベクトルDB選定：S3 Vectors vs OpenSearch Serverless

RAGアーキテクチャにおいて、ベクトルストアの選定は精度・コスト・運用負荷に大きく影響します。2026年2月時点で、Amazon Bedrock Knowledge Basesが対応するベクトルストアは以下の5種類です。

ベクトルストア 特徴
Amazon S3 Vectors 2025年12月GA。S3ネイティブのベクトルストレージ。最大20億ベクトル/インデックス
Amazon OpenSearch Serverless フルマネージドなベクトル検索。高スループット・低レイテンシ
Amazon OpenSearch Service（マネージドクラスター） 2025年10月対応。既存OpenSearch環境がある場合に有効
Amazon Aurora PostgreSQL pgvectorベースのベクトル検索。RDBとの統合に強み
Amazon Neptune Analytics GraphRAG対応。エンティティ間の関係性を活用した検索

S3 Vectorsとは

Amazon S3 Vectorsは、2025年7月にプレビュー、同年12月のre:Invent 2025でGA（一般提供）となったサービスです。S3にネイティブなベクトルストレージを提供し、専用のベクトルデータベースと比較して最大90%のコスト削減を実現します。

S3 Vectorsの主な特徴：

  • スケーラビリティ：1インデックスあたり最大20億ベクトル、1バケットあたり最大10,000インデックスに対応
  • パフォーマンス：低頻度クエリでもサブ秒レイテンシ、高頻度クエリで約100ミリ秒以下のレイテンシ
  • 書き込み性能：ストリーミング方式で毎秒1,000ベクトルの書き込みスループット
  • クエリ結果：1クエリあたり最大100件の検索結果を返却
  • メタデータ：1ベクトルあたり最大50個のメタデータキーを付与可能
  • フルサーバーレス：インフラのプロビジョニング不要、使った分だけ課金
  • 距離メトリクス：CosineまたはEuclideanを選択可能
  • 暗号化：SSE-S3（デフォルト）またはSSE-KMSによるサーバーサイド暗号化

S3 Vectors vs OpenSearch Serverless：比較検証

社内ナレッジ検索RAGのベクトルストアとして、S3 VectorsとOpenSearch Serverlessを比較します。

比較項目 S3 Vectors OpenSearch Serverless
月額コスト（小規模：〜10万ベクトル） 数ドル程度 約$350〜（最低2 OCU × $0.24/OCU/時間）
月額コスト（中規模：100万ベクトル） 約$10程度 約$350〜
クエリレイテンシ サブ秒〜約100ms 数十ms〜数百ms
最大ベクトル数/インデックス 20億 OCUに依存（スケーリング可能）
インフラ管理 不要（フルサーバーレス） 不要（サーバーレス）ただしOCU管理あり
課金体系 従量課金（ストレージ + PUT + クエリ） 時間課金（OCU単位、最低2 OCU常時起動）
ストレージ単価 $0.06/GB/月 OCU内包（固定費に含まれる）
PUT単価 $0.20/GB OCU内包
セットアップ Quick Create で数クリック コレクション作成 + セキュリティポリシー設定
Knowledge Bases連携 Quick Create対応 Quick Create対応
向いているケース 低〜中頻度アクセスのRAG、コスト重視 高頻度・リアルタイム検索、レイテンシ重視

image.png

コスト比較の具体例

1,000件の社内ドキュメント（平均10ページ）を格納し、1日あたり100回のRAGクエリを実行するケースを想定します。

S3 Vectorsの場合：

  • ドキュメント数1,000件 × 平均30チャンク = 約30,000ベクトル
  • 1ベクトルの次元数：1,024（Titan Text Embeddings V2使用）
  • ベクトルデータ：30,000 × 1,024次元 × 4バイト ≈ 0.12 GB
  • メタデータ込み：約0.15 GB
  • ストレージ費用：0.15 GB × $0.06 = 約$0.01/月
  • PUT費用：0.15 GB × $0.20 = 約$0.03（初回のみ）
  • クエリ費用：月間3,000クエリ → 数ドル程度
  • 合計：月額 数ドル程度

OpenSearch Serverlessの場合：

  • 最低2 OCU（検索用1 + インデックス用1）が常時起動
  • 1 OCU = $0.24/時間
  • 2 OCU × $0.24 × 24時間 × 30日 = 約$345.60/月

社内ナレッジ検索のような低〜中頻度アクセスのユースケースでは、S3 Vectorsのコスト優位性は圧倒的です。

選定結論

本記事のユースケース（社内ナレッジ検索、1日数十〜数百クエリ程度）では、S3 Vectorsが最適です。サブ秒のクエリレイテンシは社内検索用途として十分であり、コストは数十分の一に抑えられます。

一方、リアルタイム性が求められる顧客向けチャットボット（毎秒数十〜数百リクエスト）やEコマースの商品推薦エンジンなど、高QPSが必要なケースではOpenSearch Serverlessが適しています。

Knowledge Basesの構築手順

Step 1：S3にドキュメントをアップロード

まず、RAGの検索対象となるドキュメントをS3バケットに格納します。

# S3バケットの作成
aws s3 mb s3://my-knowledge-base-docs-bucket --region ap-northeast-1

# ドキュメントのアップロード
aws s3 sync ./company-docs/ s3://my-knowledge-base-docs-bucket/

ディレクトリ構成のベストプラクティス：

my-knowledge-base-docs-bucket/
├── manuals/           # 製品マニュアル（PDF）
├── faq/               # FAQ（Markdown）
├── policies/          # 社内規程（PDF）
├── meeting-notes/     # 議事録（テキスト）
└── onboarding/        # オンボーディング資料（PDF）

Knowledge Basesは以下のドキュメント形式に対応しています。

  • PDF
  • テキスト（.txt）
  • Markdown（.md）
  • HTML
  • Microsoft Word（.doc / .docx）
  • CSV
  • Microsoft Excel（.xls / .xlsx）

image.png

Step 2：Embeddingモデルの選定

Knowledge Basesでは、ドキュメントのチャンクをベクトルに変換するEmbeddingモデルを選択する必要があります。

Amazon Bedrock Knowledge Basesで利用可能な主要Embeddingモデル：

モデル 次元数 多言語対応 特徴
Amazon Titan Text Embeddings V2 256 / 512 / 1,024（選択可能） ○ AWS純正。日本語対応。コスト効率が良い
Cohere Embed Multilingual 1,024 ◎（100+言語） 多言語に特化。日本語の精度が高い

本記事ではAmazon Titan Text Embeddings V2（1,024次元）を選択します。 理由は以下のとおりです。

  1. AWS純正モデルであり、Knowledge Basesとの統合がスムーズ
  2. 日本語を含む多言語に対応
  3. 1,024次元はS3 Vectorsの次元上限4,096以内で、精度とコストのバランスが良い
  4. S3 Vectorsとの連携においてQuick Createワークフローで自動設定される

Step 3：Knowledge Baseの作成

Bedrockコンソールから Knowledge Base を作成します。

スクリーンショット⑤-1.png
スクリーンショット⑤-2.png
スクリーンショット⑤-3.png

作成手順：

  1. Amazon Bedrockコンソールを開き、左メニューから「Knowledge bases」→「Create knowledge base」を選択
  2. 基本設定： Knowledge Base名（例：company-knowledge-base）と説明を入力。サービスロールは「Create and use a new service role」を選択
  3. データソース設定： 「Amazon S3」を選択し、先ほど作成したS3バケットのURIを指定
  4. Embeddingモデル選択： 「Amazon Titan Text Embeddings V2」を選択。次元数は1,024を使用
  5. ベクトルストア選択： 「S3 vector bucket」を選択し、「Quick create a new vector store」を選択

Quick Createを使用すると、S3ベクトルバケットとベクトルインデックスが自動的に作成・設定されます。デフォルトではSSE-S3による暗号化が適用され、必要に応じてSSE-KMSを選択することも可能です。

Step 4：データソースの同期（Sync）

Knowledge Baseを作成したら、データソースの同期を実行します。

同期処理では以下が自動的に実行されます。

  1. S3バケットからドキュメントを取得
  2. テキストブロック（チャンク）に分割
  3. Embeddingモデルでベクトルを生成
  4. S3 Vectorsのベクトルインデックスに格納

同期完了後、Knowledge Basesコンソールのテスト画面で動作確認ができます。

チャンク戦略の設計と精度への影響

RAGの検索精度において、チャンク戦略の選定は極めて重要です。同じドキュメントであっても、チャンクの分割方法によって検索精度が大きく変わります。

Knowledge Basesが対応するチャンク戦略

Amazon Bedrock Knowledge Basesは以下の5つのチャンク戦略に対応しています。

チャンク戦略 概要 設定パラメータ
デフォルト 約300トークンで自動分割。文の境界を保持 なし（自動）
固定サイズ（FIXED_SIZE） 指定したトークン数で均等に分割 maxTokens、オーバーラップ率（%）
セマンティック（SEMANTIC） NLPを用いて意味的に類似した内容をグループ化 maxTokens、bufferSize、breakpointPercentileThreshold
階層（HIERARCHICAL） 親チャンク（大）と子チャンク（小）の2層構造で分割 親maxTokens、子maxTokens、overlapTokens
なし（NONE） ファイル単位を1チャンクとして扱う なし

注意： チャンク戦略はデータソース作成時に設定し、作成後に変更することはできません。別のチャンク戦略を試す場合は、新しいデータソースを追加する必要があります。

各チャンク戦略の詳細

固定サイズチャンキング（FIXED_SIZE）

最もシンプルな方式です。指定したトークン数でドキュメントを均等に分割し、オーバーラップ（重複）を設定して文脈の断絶を軽減します。

{
  "chunkingStrategy": "FIXED_SIZE",
  "fixedSizeChunkingConfiguration": {
    "maxTokens": 512,
    "overlapPercentage": 20
  }
}

利点： 設定が簡単で予測可能。処理速度が速い。
課題： 意味の途中で切断されることがある。文脈が分断されやすい。

セマンティックチャンキング（SEMANTIC）

Embeddingモデルを使用して文の意味的類似度を計算し、類似度が低い箇所（意味の区切れ目）で分割します。

{
  "chunkingStrategy": "SEMANTIC",
  "semanticChunkingConfiguration": {
    "maxTokens": 512,
    "bufferSize": 1,
    "breakpointPercentileThreshold": 95
  }
}
  • bufferSize：分割判定時に前後何文を考慮するか（デフォルト1）
  • breakpointPercentileThreshold：文間の意味的距離がこのパーセンタイル以上なら分割（95 = 上位5%の距離で分割）

利点： 意味的にまとまった単位で分割されるため、検索精度が向上しやすい。
課題： 処理時間が長い（Embeddingモデルの呼び出しが必要）。追加のEmbedding費用が発生。

階層チャンキング（HIERARCHICAL）

ドキュメントを親チャンク（大きいチャンク）と子チャンク（小さいチャンク）の2層構造で管理します。検索時は子チャンクのEmbeddingで検索し、取得した子チャンクに対応する親チャンクをLLMへのコンテキストとして返却します。

{
  "chunkingStrategy": "HIERARCHICAL",
  "hierarchicalChunkingConfiguration": {
    "levelConfigurations": [
      { "maxTokens": 1500 },
      { "maxTokens": 300 }
    ],
    "overlapTokens": 60
  }
}
  • 第1層（levelConfigurations[0]）：親チャンクの最大トークン数
  • 第2層（levelConfigurations[1]）：子チャンクの最大トークン数
  • overlapTokens：連続するチャンク間のオーバーラップトークン数（親・子共通）

利点： 検索は細粒度（子チャンク）で行い、回答生成には広い文脈（親チャンク）を使うため、精度と文脈の両立が可能。
課題： 親チャンクが大きいため、LLMへの入力トークン数が増えコストが上がる。複数の子チャンクが同じ親を参照する場合、返却結果数が減ることがある。

チャンク戦略の比較検証

社内FAQ（3ファイル）、製品マニュアル（3ファイル）、社内規程（3ファイル）、オンボーディングガイド（1ファイル）に加え、四半期レビュー議事録、システム障害報告書、システム連携ガイドといった長文の散文ドキュメント（3ファイル）を含む計13ファイルのドキュメントセットに対して、4つのチャンク戦略を適用し、20問の質問セットで検索精度を比較しました。

検証条件：

  • Embeddingモデル：Amazon Titan Text Embeddings V2（1,024次元）
  • ベクトルストア：S3 Vectors
  • LLM：Claude 3.5 Sonnet v1（回答生成）
  • 検索結果数（Top-K）：5
  • 質問セット：実際の社内問い合わせを想定した20問（構造化ドキュメント向け10問 + 散文ドキュメント向け10問）

質問セットの例：

  • 「有給休暇の申請方法を教えてください」（FAQ系・単純な事実質問）
  • 「製品Aのエラーコード E-1023 の対処方法は？」（マニュアル系・特定情報検索）
  • 「システム障害後に導入された再発防止策を全て教えてください」（散文ドキュメント・網羅性質問）
  • 「製品Aと製品Bを連携させる際の前提条件と、API認証エラーが発生した場合の対処方法は？」（長文手順書・複合質問）

検証結果：

チャンク戦略 設定 正答率（構造化Q1-10） 正答率（散文Q11-20） 総合正答率 備考
固定サイズ 300トークン overlap 20% 100% 80% 90% 散文ドキュメントで情報の欠落が発生
固定サイズ 512トークン overlap 20% 100% 90% 95% バランス良好。多くのケースで実用的
セマンティック maxTokens 512, threshold 95 90% 80% 85% 意味クラスタの偏りにより一部情報を取得できず
階層 親1500 / 子300, overlap 60 100% 95% 97.5% 親チャンクの広い文脈により最も頑健

考察：

検証の結果、ドキュメントの形式によってチャンク戦略の差が大きく変わることがわかりました。

構造化されたQ&A形式のドキュメント（FAQ、マニュアル等）では、回答が短いセクション内に完結するため、どのチャンク戦略でもほぼ100%の正答率を達成しました。一方、散文形式のドキュメント（議事録、障害報告書、長文手順書等）では明確な差が出ました。

  • 固定サイズ300トークンは、散文ドキュメントで文脈の途中切断が発生しました。特に「再発防止策を全て教えてください」のような網羅性を求める質問では、5項目中2項目しか回答できませんでした。300トークンのチャンクには1〜2項目しか含まれず、上位チャンクの取得だけでは全体をカバーできないためです
  • 固定サイズ512トークンはバランスが良く、512トークンのチャンクで3〜4項目をカバーできるため、多くの質問で正答できました。ただし、前提条件とエラー対処のように文書内で離れた情報を統合する質問では一部が欠落しました
  • セマンティックは意味的なまとまりでチャンクを生成しますが、これが裏目に出るケースがありました。再発防止策の5項目はそれぞれ「監視系」「プロセス改善系」「自動化系」と異なる意味クラスタに属するため、1つのクラスタしかヒットせず3/5項目の回答にとどまりました。また、類似ドキュメントからのノイズ混入（製品Aのエラーコードが連携ガイドのトラブルシューティングに混ざる等）も確認されました
  • 階層は親チャンク（1500トークン）が広い文脈を保持するため、最も頑健な結果を示しました。検索は子チャンク（300トークン）で精度よくマッチし、回答生成時には親チャンクの広い文脈が使われるため、網羅性の高い回答が可能です

推奨チャンク戦略：

  • まず試すなら： 固定サイズ512トークン（overlap 20%）── シンプルで予測可能。構造化ドキュメント中心なら十分な精度
  • 精度を重視するなら： 階層（親1500 / 子300）── 散文ドキュメントが多い環境で最も頑健。監査対応にも有効
  • FAQ中心のナレッジベースなら： セマンティック（maxTokens 512, threshold 95）── 構造化ドキュメントでは高精度。ただし散文ドキュメントでは意味クラスタの偏りに注意

メタデータフィルタリングの活用

チャンク戦略と組み合わせて、メタデータフィルタリングを活用することで検索精度をさらに向上できます。

S3 Vectorsでは、各ベクトルにフィルタリング可能なメタデータをキーバリューペアとして付与できます（Knowledge Bases利用時は最大1KBのカスタムメタデータ、35メタデータキー）。

メタデータの活用例：

{
  "category": "manual",
  "product": "ProductA",
  "language": "ja",
  "updated_date": "2025-10-01"
}

このメタデータを使って「製品Aのマニュアルだけを検索対象にする」「2025年以降に更新されたドキュメントだけを検索する」といったフィルタリングが可能です。検索範囲を絞り込むことで、ノイズが減り、検索精度が向上します。

動作確認とトレース

Knowledge Basesのテスト画面では、質問を入力して回答を確認できます。テスト画面の「詳細」トグルを有効にすると、トレース機能により検索結果の詳細を確認できます。

トレースで確認できる情報：

  • 取得されたチャンク：どのドキュメントのどの部分が検索結果として取得されたか
  • チャンクのメタデータ：chunk-id、data-source-id、ファイルの種類（TEXT等）
  • ソースURI：元ドキュメントのS3 URI

スクリーンショット⑨.png

Knowledge Basesのテスト画面はコンソール上で手軽にRAGの動作を検証できるため、チャンク戦略の比較やプロンプトの調整に活用できます。RetrieveAndGenerate API を使えば、同様の検索・回答生成をプログラムから呼び出すことも可能です。

コスト試算

S3 Vectorsを使用した本アーキテクチャの月額コスト概算です（ap-northeast-1リージョン想定）。

前提条件

  • ドキュメント数：1,000件
  • 平均チャンク数：30チャンク/ドキュメント = 30,000チャンク
  • Embeddingモデル：Titan Text Embeddings V2（1,024次元）
  • クエリ数：100回/日 × 30日 = 3,000回/月
  • LLM：Claude 3.5 Sonnet

コスト内訳

項目 計算 月額概算
S3 Vectors ストレージ 0.15 GB × $0.06/GB $0.01
S3 Vectors PUT（初回のみ） 0.15 GB × $0.20/GB $0.03
S3 Vectors クエリ 3,000回/月 数ドル
S3（ドキュメント格納） 1 GB × $0.025/GB $0.03
Bedrock Embedding（同期時） 30,000チャンク × 入力トークン 数ドル
Bedrock LLM（回答生成） 3,000回 × 入出力トークン $10〜30程度
合計 約$15〜35/月

OpenSearch Serverlessとの比較

項目 S3 Vectors構成 OpenSearch Serverless構成
ベクトルストア費用 数ドル/月 約$350/月（最低2 OCU）
その他（LLM等） $10〜30/月 $10〜30/月
合計 約$15〜35/月 約$360〜380/月
差額 ── 約10倍のコスト

低〜中頻度アクセスの社内ナレッジ検索では、S3 Vectorsにより ベクトルストア費用を90%以上削減 できます。

まとめ

本記事では、Amazon Bedrock Knowledge BasesとS3 Vectorsを使った社内ナレッジ検索RAGシステムの構築を解説しました。

得られた知見：

  1. S3 Vectorsはコスト革命：低〜中頻度アクセスのRAGにおいて、OpenSearch Serverlessと比較して90%以上のコスト削減を実現。Quick Createにより数クリックでセットアップ可能
  2. チャンク戦略は精度を左右する：構造化ドキュメント（FAQ等）ではどの戦略でも高精度だが、散文ドキュメント（議事録、報告書等）では戦略によって正答率に最大15%の差が発生。固定サイズ512トークンが汎用的なスタート地点
  3. 階層チャンキングが最も頑健：検索は子チャンクで細粒度に、回答生成は親チャンクで広い文脈を──という二層構造が、網羅性を求める質問や散文ドキュメントに強い。総合正答率97.5%で最高スコアを記録

参考リンク

6
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?