マネージドなKB（Amazon Bedrock Managed Knowledge Bases）がGAされましたね！
今までもS3にデータをぶち込んで同期ボタンをポチッ、だったので「管理している」という感覚はそんになかったのですが、いざセルフマネージド→マネージドKBに載せ替えてみると、地味な落とし穴がいくつかあったので記事にしました。
TL;DR
- APIは「互換です」と謳われているがコードの一部変更が必要な場合あり
- Bedrock Evaluations（RAG評価ジョブ）はManaged型に未対応（2026年7月時点）
- retrieveで応答されるチャンクの粒度がセルフ/マネージドで異なる場合がある
この記事のKB比較は、どちらもチューニング一切なしの素のデフォルト設定同士の比較です。その前提で読んでください
「移行」じゃなくて「新規作成」
Managed KBへの引っ越しに、型変換APIは存在しません。「ポチッと変換」を期待していたのですが、UpdateKnowledgeBase のドキュメントにも、KBのtypeは作成後に変更できないとハッキリ書いてあります。
なので実際の乗り換えはこんな流れになります。
- 同じS3バケットを指すManaged KBを新規作成する
- セルフマネージドとマネージドの両方に同じ質問を投げて、検索結果を比較する
- 問題なければ、アプリの参照先KB IDを切り替える
- セルフマネージドKBを削除する
移行というより、並行稼働からの乗り換えに近いですね。引っ越しというより「隣に新居を建ててから旧居を解体する」スタイルです。
☠️ ズッコケ①：呼び出しコードの修正が発生するパターン
AWS公式ブログでは、APIオペレーションはそのまま使えると説明されています。
既存のアプリケーションとの一貫性を維持する: Bedrock Knowledge Bases API（
Retrieve、StartIngest、StopIngest、IngestKnowledgeBaseDocuments）を既に使用している場合、Managed Knowledge Base は同じ API を使用するため、移行にはコードの変更は不要で、新しいナレッジベース ID を指定するだけで済みます。
しかし今回はメタデータでフィルタリングしていたため、変更が必要でした。
「え、互換って言ったじゃん！」って思いません？思いますよね？私は思いました。
| クエリの内容 | 乗り換え時のコード変更 |
|---|---|
retrievalConfiguration を指定しない単純なテキストクエリ |
不要。KB IDの差し替えだけで動く |
フィルタ・numberOfResults・overrideSearchType 等を指定しているクエリ |
必要。キー名の書き換えが要る |
書き換えの内容は、検索設定オブジェクトのキー名変更です。APIリファレンスを見ると、vectorSearchConfiguration と managedSearchConfiguration が最初から並列の別フィールドとして定義されているのがわかります。
"retrievalConfiguration": {
- "vectorSearchConfiguration": {
- "filter": {"equals": {"key": "department", "value": "人事総務部"}},
- "overrideSearchType": "HYBRID"
- }
+ "managedSearchConfiguration": {
+ "filter": {"equals": {"key": "department", "value": "人事総務部"}}
+ }
}
overrideSearchType はManaged KBに存在しないので削除します（検索戦略は内部で自動選択されます。「私に任せなさい」というAWSの強い意志を感じますね）。
判断基準は「フィルタを使っているか」ではなく、vectorSearchConfiguration というキー自体を明示しているかどうかです。
☝️ 予約メタデータフィールドの名前も変わる
マネージドKBのレスポンスの metadata を眺めていると、_chunk_id や _created_at のようなアンダースコア始まりのキーが目に入ります。これはBedrockが自動付与する予約メタデータフィールドで、公式ドキュメントによると、KBの型によって命名規則そのものが違います。
| KBタイプ | 予約フィールドの命名規則 | 例 |
|---|---|---|
| Customer-managed |
x-amz-bedrock プレフィックス |
x-amz-bedrock-kb-data-source-id、x-amz-bedrock-kb-document-page-number
|
| Managed | アンダースコア（_）プレフィックス |
_source_uri、_data_source_id
|
どちらの型でも、予約フィールドをユーザー側で上書きすることはできません。地味な違いに見えますが、ソースURIやデータソースIDをメタデータ経由で拾って、画面表示やフィルタに使っているコードがあると、乗り換えた瞬間にキー名が丸ごと変わります。ここも立派な書き換え対象です。
☝️ メタデータフィルタリング自体はそのまま使えました
.metadata.json サイドカーファイルによるメタデータ付与自体は、クラスメソッドさんの記事でも実際に試されています。
☠️ ズッコケ②：RAG評価ジョブがManaged KBに未対応
さて、セルフマネージドとマネージドのスコアを客観的に比べようと、Bedrock Evaluations（create-evaluation-job --application-type RagEvaluation）を使うつもりでした。
「評価もAWSにお任せだ！」と意気揚々とジョブを作ったんですが……2026年7月時点ではManaged KBに対応していません。
まずコンソールのクイックスタートからManaged KBを対象にジョブを作ると、即座に失敗します。
Incompatible configuration: vectorSearchConfiguration is not supported for
managed knowledge bases. Use managedSearchConfiguration instead.
あれ、このエラーメッセージ、さっきも見たな……？
選んだKBの型に関係なく vectorSearchConfiguration: {} が組み立てられていました。つまりコンソールのウィザードがKBのtypeを見ていないんですね。
サーバー側のエラーメッセージが managedSearchConfiguration を名指しで案内していることから、API自体は認識しているけどクライアントSDKの定義が追いついていないと推測しました。
ということで、仕方がないので両KBへ同じ質問を直接投げるLambdaを自作して、手動比較に切り替えました。
良い方法があればこっそり教えてください🙄
セルフKBとマネージドKBに同じ10問を投げて比較してみた
社内規程に関する質問10問を、セルフマネージドKB・マネージドKB双方のLambdaに投げて（最大10件取得・チャンク全文）、結果を見比べました。違いが出た観点ごとに一言でまとめると、こうなります。
| 観点 | 結果 |
|---|---|
| 原文への到達 | 両者とも全問で到達。答えの載っている文書はどちらも毎回引き当てており、検索精度そのものに大差なし |
| チャンクの粒度 | セルフマネージドは検索結果が文書丸ごと返ってくる（裏でBedrockが親チャンクに差し替えている）。マネージドは条文単位に細分。本質的な違いはここ |
| 応答時間 | 全10問でセルフマネージドが速い。複数回実行しても傾向は同じで、平均はおおむねセルフマネージド500ms前後、マネージド700ms前後 |
☁️ なぜセルフマネージド検索結果は「文書丸ごと」なのか
公式ドキュメントはこちら。
動き的には階層化チャンキングの挙動なのですが、特に指定していないので、標準チャンキングになるはず……。
一方のマネージドKBは、この親置換をしていません。ヒットした構造チャンク（Smart Parsingによる条文単位のチャンク）をそのまま返しています。10件要求すれば毎回きっちり10件返ってくるのも、Bedrockが返却時に何も差し替えていないからです。(と解釈)
| セルフマネージドKB（S3 Vectors・デフォルト構成） | マネージドKB | |
|---|---|---|
| チャンキングの実体 | 約300トークンの子チャンクに分割 | Smart Parsing |
| 検索でヒットする単位 | 子チャンク | 構造チャンク |
| Retrieveが返す内容 | ヒットした子チャンクを親チャンク（文書丸ごと）に差し替えて返す | ヒットした構造チャンクをそのまま返す |
こちらについては原因特定に至らなかったため、別記事で深掘りしたいと思います
乗り換えてみて感じたこと
Managed KBの一番の魅力は、ベクトルストアの構築や運用がまるごと要らなくなる身軽さだと思います。
ただ、乗り換えるなら次の3点は事前に見積もっておきたいところです。
- APIオペレーション自体は互換でも、フィルタやハイブリッド検索を使っているならコードの書き換えが避けられないこと
- チャンクの粒度が変わる可能性があるため、しっかりとした検証が必要なこと
- Bedrock EvaluationsがManaged型では使用できないため、自前での検証が必要なこと
この3つを織り込んでおけば、乗り換え自体はそれほど怖い作業ではありません。
ぜひ皆さんはスマートに乗り換えてください！