RAGはマネージドか自前か — 制御とコストで選ぶ判断軸（Bedrock Managed KB）
RAGを自前で組むか、Amazon Bedrock Managed Knowledge Base に載せるかを、制御性・コスト構造・運用負荷・移植性のトレードオフで意思決定するための判断軸を整理します。マネージドが何を引き受けるかを公式情報で正確に押さえたうえで、マネージドを常に正解とはしない中立の立場で、自前を選ぶべき場面とその送り先まで示します。
- #RAG
- #Bedrock Managed Knowledge Base
- #マネージド
- #build vs managed
- #意思決定
- #ベクトルストア
- #TCO
- #ロックイン
- #SRE
RAG（Retrieval-Augmented Generation、検索で補強した生成）を本番で動かすとき、ベクトルストアを選ぶより一段手前に効く分岐があります。検索基盤や取り込みパイプラインを自前で組むのか、マネージドサービスに載せて運用を委ねるのか、という選択です。2026年6月17日にAmazon Bedrock Managed Knowledge Base（以下、Managed KB）が一般提供（GA）となり、東京を含む8リージョンで使えるようになりました。「委ねる」が現実的な選択肢に昇格したことで、この分岐はより重要になっています。本記事は機能紹介ではなく、自前で握るか・マネージドに寄せるかをどう決めるかの判断軸に重心を置きます。マネージドを常に正解とはしない、中立の立場で整理します。
RAGの構成要素と「持つ／持たない」の境界
判断の土台として、RAGを4つのレイヤーに分けて眺めると、build（自前）とmanagedの境界が見えてきます。取り込みと解析（parse）、ベクトルストア、検索ロジック、オーケストレーションの4層です。ここで重要な前提を一つ置きます。この4レイヤーは境界を理解するための「教えレンズ」であって、製品として層を一つずつ個別に差し替えられるわけではありません。
AWS公式ドキュメントは、Bedrock Knowledge Basesを2つのタイプで提供すると明記しています。Managed KBは、データの取り込み・インデックス化・保存・検索の基盤をAmazon Bedrockが管理します。そのうえで主要なカスタマイズは残されており、データソースを接続すると、埋め込み・再ランキング・推論はサービス管理のモデルが既定で使われ、自前モデルを選ぶこともできます。取り込みでは6種のネイティブコネクタ（Amazon S3／SharePoint／Confluence／Google Drive／OneDrive／Web Crawler）と、データ型ごとに最適な解析方法を自動選択するSmart Parsing、複雑な問い合わせをサブクエリに分解して複数ナレッジベースを横断し反復検索するAgentic Retrievalが標準で備わります。
一方のSelf-managed KBは、ベクトルストア（Amazon OpenSearch Serverless、Amazon Aurora、Amazon Neptuneなど）を含むRAGパイプラインを自分で構築・運用するタイプです。自前のベクトルデータベースを持てるのはこのSelf-managed KBの役割で、Managed KBではできません。逆に、サードパーティコネクタやドキュメント単位の権限、AgentCore Gatewayとのネイティブ統合といった機能はManaged KBだけで使えます。実装上の選択は、この2タイプのどちらにするかであって、図1のセルを自由に組み合わせるものではない、という点を押さえてください。
判断軸① 制御性・要件適合
最初の軸は、どこまで自分で握りたいかです。独自のチャンク分割、特殊な再ランキング、込み入ったメタデータフィルタ、マルチテナント分離といった要件を細部まで握りたい場合は、Self-managed KBが向きます。一方、標準的なエンタープライズRAG（社内ドキュメントを検索して回答に使う、といった用途）であれば、Managed KBで足りる場面が多くなります。Managed KBの内部でも、埋め込み・再ランキング・推論には自前モデルを選べる余地があるため、「全部おまかせか、全部自前か」の二択ではなく、部分的なカスタマイズは効きます。まず自分の要件が標準の範囲に収まるかを見極めるのが出発点です。
判断軸② コスト構造（TCO）
次の軸はコストの構造です。ここは原価のかたちが両者で異なる点が要点になります。Managed KBは前払いのない純粋な従量課金で、課金はおおむね「索引したデータ量」と「リトリーブ（検索）の回数」の2軸です（Agentic Retrievalを使う場合は上乗せがあります）。プロビジョニングの下限がないため、使った分だけの費用に近づきます。これに対して自前のベクトルストアは、常時稼働させる最低キャパシティの固定費が出やすい構造です。
この違いから、トラフィックの量で損益が分かれます。低〜中トラフィックで運用を持ちたくない場合は、固定費を抱えないManaged KBが有利になりやすく、逆に高QPS（毎秒の問い合わせ数が多い）や特殊な検索要件がある場合は、自前で作り込んだほうが効く場面もあります。具体的な料金額は改定されるため本記事には載せませんが、自前構成でのコスト試算の進め方は別記事に整理しています。自前を検討する段階に来たら、RAGアーキテクチャのTCO設計の記事で原価の組み立てを確認してください。
判断軸③ 運用負荷・スイッチングコスト
3つ目の軸は、運用にどれだけ手をかけるか、そして後から乗り換えやすいかです。Managed KBはベクトルDB・取り込みパイプライン・検索基盤を保有しないため、運用負荷が下がります。加えて、既存のBedrock Knowledge BasesのAPI（Retrieve／StartIngest／StopIngest／IngestKnowledgeBaseDocuments）と同一で、コード変更なし・ナレッジベースIDの差し替えだけで移行できる、と公式が明記しています。これはスイッチングコストの低さにつながります。
ただし正確に理解すべきは、この同一API移行はナレッジベース全体（既存KBとManaged KBの入れ替え）の話だという点です。「Managed KBの一部のレイヤーだけを後から自前に差し替える」という操作は公式機能ではありません。実態はManaged KBとSelf-managed KBという2タイプの選び直し、つまり再アーキテクチャです。運用に手をかけたくないならManaged、運用も含めて自分でコントロールしたいならSelf-managed、という整理になります。
意思決定：判断木で選ぶ
ここまでの3軸を、一つの分岐として組み立てます。
判断の順序はこうです。まず、カスタムな検索ロジックや特殊なフィルタ、細かなコスト最適化を自分で握る必要があるか。握る必要があるなら自前（Self-managed KB）に進みます。この分岐に来た方は、ベクトルストアの選定軸をベクトルストア選定の記事で、コスト設計を前掲のTCOの記事で確認すると、次の一手が具体化します。握る必要がなく、運用を委ねたい・速く立ち上げたい・乗り換えやすさを重視するなら、Managed KBが第一候補になります。マネージドを常に正解とはしませんが、要件が標準の範囲に収まるなら、まず委ねて始める合理性は高いといえます。
明日できる一歩と落とし穴
実践の入り口としては、まずManaged KBで最小構成のRAGを立て、制御が必要になった層が出てきたらSelf-managed KBへ再アーキする、という段階戦略が取りやすい形です。これはあくまで「設計上の戦略」であり、同一APIゆえアプリ側の改修は小さく抑えられますが、製品機能としての「層単位の差し替え」ではない点を、もう一度確認してください。これを「マネージドでも層だけ差し替えられる」と誤解すると、実装で行き詰まります。
公式に記載のない事項は断定しないことも大切です。旧来の自己構成型ナレッジベースはSelf-managed KBとして併存する旨はドキュメントに記載がありますが、ナレッジベースのサイズ・ドキュメント数・クエリレートの具体的な上限は本記事の参照範囲には明示がなく、Service Quotasなどで時点ごとに確認する前提で進めてください。なお、マネージドに載せても回答品質の検証は自分の責務として残ります。検証をリリースゲートに組み込む設計は生成AIの評価をリリースゲートにする記事を、本番運用全体の組み立ては生成AIエージェントの本番運用の記事を参考にしてください。
まとめ
RAGは、ベクトルストアの選定に入る前に「自前で組むか、マネージドに寄せるか」を意思決定しておくと、後の判断が一貫します。選ぶ軸は、①制御性・要件適合、②コスト構造、③運用負荷・スイッチングコストの3つでした。いずれもマネージドを常に正解とはせず、自分の要件がどこで標準を超えるかを見極める作業です。4レイヤーは境界を理解する教えレンズで、実装上の選択は公式の2タイプ（Managed／Self-managed）であること、「層だけ後から自前化」は再アーキになることを外さなければ、実装でつまずきにくくなります。なお、知識・RAG層のこの論点と対になるのが、エージェントの実行基盤（オーケストレーション）層をマネージドにするか自前にするかという論点です。これは別記事で扱います。各サービスの仕様・料金は改定されうるため、適用前に公式の最新情報をあわせてご確認ください。