ベクトルDBを自前管理しないRAG — Bedrock マネージドナレッジベースと既存KB・自前の使い分け

RAG（外部データを検索して回答に使う仕組み）を本番運用しようとすると、ベクトルデータベースの運用や取り込みパイプラインの保守が重くのしかかります。2026年6月17日にGA（一般提供開始）した Amazon Bedrock マネージドナレッジベースは、こうした検索インフラを自前管理せずに本番級のRAGを構築できるフルマネージド型のサービスです。アジアパシフィック（東京）でも提供されており、今すぐ案件で使える選択肢になりました。本記事では、既存の「Bedrock Knowledge Bases」や自前構築と何が違うのかを、運用負荷とコストの観点で使い分けられるよう整理します。

RAGの構成要素と「管理しない」という選択肢

一般的なRAGは、データの取り込み → ベクトル化（埋め込み生成）→ 格納（ベクトルDB）→ 検索 → 生成、という流れで動きます。自前で組む場合、このうちベクトルDBの運用、取り込みパイプラインの整備、検索精度を上げる再ランクの調整などを、すべて自分で抱えることになります。PoC（試作）までは動いても、本番で安定運用する段で負荷が跳ね上がるのはこの部分です。

そこで出てくるのが「構成要素ごと任せる」という選択肢です。Bedrock マネージドナレッジベースは、このパイプラインの大半を肩代わりします。生成AIアプリ全体をどの順で組むかは Bedrockで生成AIアプリを本番化する実装地図 も参照してください。

Bedrock マネージドナレッジベースとは

Bedrock マネージドナレッジベースは、企業データに根拠づけ（グラウンディング）した本番級RAGを、ベクトルDBや検索インフラを管理せずに構築できるフルマネージド型のサービスです。主な特徴は次のとおりです。

• 6種類のネイティブコネクタ：Amazon S3／SharePoint／Confluence／Google Drive／OneDrive／Web Crawler に対応し、データソースを自動同期します。
• ハイブリッド検索と agentic retrieval：単純なベクトル検索に加え、複数ステップ（マルチホップ）の複雑なクエリに対して、クエリのプランニング・中間応答の評価・再ランクを自動でオーケストレーションします。
• AgentCore とのネイティブ統合：Amazon Bedrock AgentCore の Gateway ターゲットとして統合され、MCP（Model Context Protocol）でツールとして公開できます。権限の自動生成と可観測性も備えます。
• マルチモーダル対応：テキストだけでなく、動画・音声・画像も扱えます。

推奨される構成タイプは「Unstructured Vector Store KB」です。ここで重要なのは、ベクトルストアや埋め込みモデル、再ランクモデル、基盤モデルの選定をサービスが既定で自動管理する点です。つまり利用者はこれらを構築・選定する必要がありません。なお、内部で使われる基盤モデルの具体名は公式に名指しされていないため、本記事では特定のモデル名は挙げません（自動選定される、という事実のみを示します）。

既存「Bedrock Knowledge Bases」との違いと移行

すでに提供されている「Bedrock Knowledge Bases」とは置き換え・廃止の関係ではなく、フルマネージド型の新しいオファリングとして地続きに位置づけられています。両者の関係を押さえると移行の見通しが立ちます。

• API互換：既存KBと同じAPI（Retrieve / StartIngest など）で動きます。
• 移行はコード変更不要：新しいナレッジベースのIDを指すだけで切り替えられます。
• 追加機能：データ型ごとに最適なパース戦略を自動判定する Smart Parsing、AgentCore Gateway へのネイティブ統合、MCP 対応によるツールの自動discovery などを備えます。

ここが「違い」の核心です。既存KBはベクトルストアを自分で選んで用意します（S3 Vectors／OpenSearch Serverless／Aurora（PostgreSQL）／Neptune Analytics／Pinecone など）。一方、マネージドナレッジベースはこの選定を行わず、サービスがまとめて抽象化します。「ベクトルストアを選べない」ことは制約にも見えますが、自前管理をなくすという点ではむしろ差別化点です。

料金とコスト設計

マネージドナレッジベースの料金は、2軸＝インデックス済みデータサイズ＋retrieval（検索）回数で構成され、オンデマンド・前払いなしです（2026年6月時点の参考値。利用前に公式の最新料金を確認してください）。

課金項目	レート（公式値・2026年6月時点）
インデックスストレージ	$5.00 / GB（raw data）/ 月
標準 Retrieval	$1.00 / 1,000 API calls
Agentic Retrieval	$4.00 / 1,000 calls ＋ underlying Retrieve $1.00 / 1,000 calls

注意点は agentic retrieval のコストです。1回の agentic retrieval は内部で複数回の Retrieve を呼ぶため、$4.00/1,000 に加えて underlying 分（$1.00/1,000）がホップ数に応じて積み上がります。固定の掛け算で見積もれるものではなく、クエリの複雑さによって標準 retrieval より割高になりえます。マルチホップの精度が必要な場面に絞って使うのが、コスト設計の基本になります。

クォータは、マネージドナレッジベース専用の行が現時点で公開されていないため、既存の Bedrock Knowledge Base のクォータが適用される、と考えるのが安全です（例：ナレッジベース 100／アカウント、データソース 5／ナレッジベース、Retrieve 20リクエスト／秒、取り込みファイル 50MB など）。いずれも公式の最新値を確認してください。

どれを選ぶか：既存KB／Managed KB／自前の使い分け

実務では「マネージドが正解」と一律に決まるわけではありません。案件要件（運用負荷・コスト・制御の自由度・本番までの速度）で3者を使い分けます。

観点	Managed KB（全部任せる）	既存KB（自分で選ぶ）	自前（LangChain＋ベクトルDB）
運用負荷	最小（パイプライン肩代わり）	中（ベクトルストアは自分で運用）	大（すべて自前で保守）
ベクトルストア選択	不可（自動管理）	可（S3 Vectors／OpenSearch／Aurora 等）	完全に自由
コスト最適化の余地	retrieval設計で調整	ストレージ選定で最適化しやすい	設計次第で最大だが手間も最大
本番までの速度	最速	中	遅い
向くケース	早く本番化したい・運用を持ちたくない	コストと制御を握りたい	独自要件・細かい作り込みが必要

判断の軸はシンプルです。早く本番化したい・運用負荷を持ちたくないなら Managed KB、コストと制御を握りたいなら既存KB、独自の作り込みが要るなら自前です。とくにコスト最適化を重視する場合は、既存KBで Amazon S3 Vectors を自分で選び、大規模インデックスのクエリ料金を抑える設計が現実的な選択肢になります。検索対象データに業務上の意味を付与して精度を底上げしたい場合は、S3アノテーション も併せて検討できます。

まとめ

Bedrock マネージドナレッジベースは、ベクトルDBを自前管理しないフルマネージドRAGという新しい選択肢です。使い分けの指針は次の3点です。

1. 迷ったら、まず Managed KB で最速に本番化する
2. コストと制御の要件が固まったら、既存KB＋S3 Vectors でコスト最適化に寄せる
3. 独自要件が強ければ自前構築を選ぶ

RAGの「検索」層を要件に合わせて選べるようになると、生成AIの実装案件で上流から構成を設計できる幅が広がります。各サービスの料金・仕様・提供リージョンは流動的なため、導入時は公式の最新情報を必ず確認してください。