Amazon Kendra→Bedrock Knowledge Bases移行ガイド

1. この記事について

2026年7月時点のAWS公式ドキュメント(docs.aws.amazon.com/kendra/latest/dg/kendra-availability-change.html、what-is-kendra.html)を基準に記述しています。リタイアスケジュールや対応機能は変更される可能性があるため、実際の移行判断・作業前には必ず公式ページを確認してください。

1-1. 本記事のゴール

Kendraのリタイアスケジュールを正確に理解し、自組織のKendraワークロードをBMKBへ移行する手順、失われる機能の代替策、移行タイミングの判断ができる状態を目指します。「連携できる=存続する」ではないという誤解を解いたうえで、実際に手を動かして移行を完了できるレベルまで解説します。

読了後にできること:

• 自組織が保有するKendra index(GenAI Enterprise/Basic Enterprise/Basic Developerのいずれか)が、なぜ・いつまでに移行対象になるかを正確に説明できる
• 利用中のコネクタがBMKBで継続利用できるか、代替が必要かを一覧で判別できる
• Faceted Search・Query Suggestions等、BMKB非対応機能に対する代替策の選択肢を把握できる
• Kendra→BMKBへの移行手順(IAMロール設定からデータソース移行・API呼び出し変更まで)を進められる
• 自組織のワークロードにとって「いつ移行に着手すべきか」を判断基準に基づいて決められる
• 移行時に陥りがちな誤解・失敗パターンを事前に把握し、回避できる

本記事の構成:

各章は独立して参照できるよう構成していますが、初めて本記事を読む場合は§2から順に読むことで、リタイアの正確な理解→機能差の把握→移行実行→判断基準、という流れで無理なく移行計画を立てられます。

1-2. 読者像

想定する読者は大きく2タイプです。

既存Kendra運用者が本記事で解決したい典型的な悩み:

• 自社が使っているindex typeがGenAI Enterprise Editionの場合、本当にリタイア対象なのか確信が持てない
• 現在使っているコネクタがBMKBでそのまま使えるのか、代替が必要なのかを個別に調べる時間がない
• Faceted SearchやCustom Synonymsなど、UIやクエリ体験に組み込んでいる機能が移行後にどうなるか把握できていない
• 移行を「いつ」始めれば間に合うのか、社内で説明できる根拠がない

新規構築の運用者が本記事で解決したい典型的な悩み:

• エンタープライズ検索の選定候補にKendraを挙げていたが、リタイアスケジュールを踏まえて選定から外すべきか判断したい
• BMKBを新規に採用する場合、Kendraからの移行事例で語られる機能ギャップが自社要件に影響しないか事前に確認したい

いずれの読者も、Bedrock Knowledge Basesそのものの使い方(KB作成の基本・RAG概論・ベクトルDB選定)は既知、またはこの後§7で紹介する既存記事を読むことを前提とし、本記事は「移行」という論点に絞って解説します。

本記事が想定していない読者(§7の既存記事が適しています):

• Bedrock Knowledge Basesの作成方法やRAGの基本概念そのものを学びたい方
• Kendraを利用しておらず、Bedrock KBの一般的な構築・運用ノウハウを知りたい方
• ベクトルDBの選定比較(OpenSearch Serverless/Aurora/Pinecone等)を知りたい方

自組織のKendra indexがどのedition(GenAI Enterprise/Basic Enterprise/Basic Developer)に該当するかは、Kendraコンソールのindex詳細画面で確認できます。edition名が不明な場合も、いずれの場合も本記事のスコープ内(全edition対象)であるため、まずは§2でリタイア範囲の全体像を押さえることをおすすめします。

1-3. なぜ今これを書くか

Kendraは2026-06-30にメンテナンスモードへ移行し、07-30に新規受付を終了します。移行先のBMKBはコネクタ数やFaceted Search等で機能差があり、移行は非自明な判断を伴います。AWS公式の移行ガイドは存在しますが、日本語での実務目線の整理はまだ手薄です。

Kendraリタイアの主要マイルストーン(詳細は§2で解説):

このスケジュールは全edition共通です。とりわけ「GenAI Enterprise Editionは連携できるため存続する」という誤解が生じやすい点こそ、本記事を書く最大の動機です。「連携できること」と「リタイア対象から外れること」は別の話であるため、この違いを最初に整理しないまま移行計画を立てると、着手が遅れかねません。

加えて、移行の難易度を左右するもう一つの要因が機能ギャップです。KendraはBMKBより多くのコネクタを持ち、Faceted Search・Query Suggestions・Custom Synonyms・Spell Checking・Incremental Learning・Custom Document Enrichmentといった、UIやクエリ体験に直結する機能を備えています。これらをそのまま「機能が減った」と捉えて移行を先送りするか、代替策込みで移行を進めるかによって、移行後の利用者体験が大きく変わります。この機能ギャップの詳細と代替策は§3で扱います。

移行の要否そのものは選べませんが、着手のタイミングと進め方は選べます。猶予期間があるうちに正確な理解をもとに計画を立てるか、リタイアが迫ってから慌てて対応するかで、移行の品質は大きく変わります。本記事はその判断と実行を支援することを目的としています。

着手を先送りした場合に起きやすいこと(詳細は§6):

• 「GenAI Indexは連携できるから大丈夫」という誤解のまま社内説明を進めてしまい、後から計画を作り直すことになる
• 非対応コネクタの存在に移行直前で気づき、データソース移行の見積もりが崩れる
• Faceted SearchなどKendra固有機能に依存したUIが、移行後に動作しなくなって初めて発覚する
• 並行運用による品質比較の時間を確保できないまま、本番切替を迎えてしまう

これらはいずれも、リタイアの正確な理解と機能ギャップの事前把握があれば避けられる問題です。本記事では§2〜§6でこれらを順に解消していきます。

なお、Bedrock Knowledge Basesの基礎(KB作成の基本/RAG概論/ベクトルDB選定)は既存記事に委譲し、本記事では移行に固有の論点のみを扱います。

Bedrock KBの操作にまだ不慣れな場合は、先に下記の記事で基礎を押さえたうえで本記事に戻ることをおすすめします。移行の実務(§4)は、KB自体の基本操作を理解している前提で解説します。

Bedrock Knowledge Bases 基礎を先に押さえたい方はこちら

2. 前提 — Kendraリタイアの正確な理解

2-1. リタイアタイムラインと「全edition対象」の正確な理解

Kendraのリタイアは2段階のスケジュールで進みます。2026-06-30にメンテナンスモードへ移行し、新機能追加が停止します。既存顧客に対するバグ修正・セキュリティ対応は継続しますが、機能面はこの時点で凍結されます。続く2026-07-30に新規受付が終了し、新規index作成ができなくなります(取得日2026-07-14、docs.aws.amazon.com/kendra/latest/dg/kendra-availability-change.html)。

上記のとおり、2026-06-30と2026-07-30の2つの日付には明確な意味の違いがあります。前者は「機能追加が止まる日」、後者は「新規に使い始められなくなる日」であり、どちらも既存index運用者にとって移行計画の起点となる重要な日付です。

このスケジュールの対象範囲は、GenAI Enterprise Edition・Basic Enterprise Edition・Basic Developer Editionの3 index typeすべてです。特定のeditionだけが対象外になることはありません。

ここで最も誤解されやすいのが、GenAI Enterprise Editionの扱いです。GenAI Enterprise EditionはKendraのindex typeの中でもBedrock Knowledge Basesとの連携機能を備えているため、「GenAI版は連携できるのだから、このままリタイア対象から外れて存続するのではないか」という混乱が生じがちです。しかし実際には、GenAI Enterprise EditionもBasic Enterprise Edition・Basic Developer Editionと同じメンテナンスモード・新規受付終了の対象です。「Bedrock Knowledge Basesと連携できること」と「Kendra自体がリタイア対象から外れること」は別の話であり、連携機能の存在をリタイア対象外の根拠にはできません。

よくある誤解と正しい理解:

この誤解を正確に解いておくことは、社内説明や移行計画の起点として重要です。「GenAI版は残る」という前提のまま計画を進めてしまうと、後から計画の作り直しが必要になります(この失敗パターンの詳細は§6で扱います)。

自組織のindex typeを確認する方法:

自組織で保有するKendra indexがどのeditionに該当するかは、Kendraコンソールの対象index詳細画面の「Edition」欄で確認できます。API経由で確認する場合はDescribeIndexを呼び出し、レスポンスのEditionフィールドを参照してください。どのeditionであっても上記タイムラインの対象であるため、edition名の特定自体よりも「いつまでに何を終えるべきか」の計画づけを優先することをおすすめします。

まずは、自組織が保有するどのindex typeであっても、上記の同一タイムラインに沿って移行が必要になるという前提から出発してください。

「既存顧客はサポート継続」の実務上の意味:

2026-07-30以降も既存indexに対するバグ修正・セキュリティ対応は継続されますが、これは「Kendraを使い続けてよい」という意味ではありません。新規index作成ができない以上、組織の拡張・新規プロジェクトでKendraを選択肢に加えることはできなくなります。また、機能追加は2026-06-30の時点で既に停止しているため、既存indexの運用を続けても機能面の改善は今後見込めません。バグ修正・セキュリティ対応の継続は、あくまで「移行が完了するまでの間、安全に運用を続けられる」という猶予であり、恒久的な選択肢の維持ではない点に注意してください。

よくある質問:

• Q. 猶予期間中は何もしなくてよいか? A. いいえ。新規受付終了(2026-07-30)後は既存indexの運用しかできなくなるため、猶予期間中に§3の機能ギャップ棚卸と§4の移行作業を進めておく必要があります。猶予期間はあくまで「移行を完了させるための時間」であり、様子見のための期間ではありません。
• Q. 一部のindexだけ移行を後回しにできるか? A. 技術的には可能ですが、全indexが同一タイムラインの対象であるため、後回しにしたindexも遅かれ早かれ移行が必要になります。優先度をつけるにしても、全indexの移行完了時期を最初に見積もっておくことをおすすめします。

なぜGenAI Enterprise Editionをめぐる誤解が広がりやすいかというと、Bedrock Knowledge Basesとの連携機能自体はKendra側の製品説明でも紹介されており、「連携機能がある=Bedrock側に取り込まれて存続する」という早合点が起きやすいためです。実際にはこの連携機能とindexそのものの提供終了は別軸の話であるため、社内説明の際はこの2つを明確に切り分けて伝えることが重要です。

§2で押さえておくべきポイントのまとめ:

• 対象はGenAI Enterprise/Basic Enterprise/Basic Developerの3 index typeすべて。例外はない
• 「連携できる」ことと「リタイア対象から外れる」ことは別の話。GenAI Enterprise Editionも例外ではない
• 2026-06-30からメンテナンスモード入り(新機能停止)、2026-07-30に新規受付終了(新規index作成不可)
• 既存顧客へのサポート継続は「安全に運用を続けられる猶予」であって、恒久的な選択肢の維持ではない

この正確な理解を関係者間で共有したら、次は移行先であるBMKBの位置づけを確認します。

2-2. 移行先の位置づけ — BMKB とは(基礎は委譲)

Kendraの移行先はAmazon Bedrock Managed Knowledge Base(以下BMKB)です。BMKBはBedrock Knowledge Basesの中でもAWSがマネージドでインジェストとインデックス管理を担う構成であり、Kendraと同様に「データソースを指定すればマネージドに検索基盤が構築できる」という運用感を引き継げる移行先として位置づけられます。

移行観点でのKendraとBMKBの違い(詳細比較ではなく、移行判断に直結する点のみ):

なお、BMKBはセマンティック検索単独では動作せず、常にハイブリッド検索(セマンティック検索とキーワード検索の組み合わせ)で動作する点は、Kendraからの移行を検討するうえで押さえておくべき基本仕様です。Kendra側でキーワード検索中心の運用をしていた場合も、BMKBに移行するとセマンティック検索の要素が必ず加わることになります。

BMKBの作成手順・チャンク戦略・ベクトルDBの選定といったBedrock Knowledge Bases自体の基礎は、本記事のスコープ外です。§7で紹介する既存記事(bedrock-knowledge-bases-rag-production等)に委譲し、本記事ではKendraからの移行という論点に絞って解説を続けます。

なぜBMKBが自然な移行先なのか:

AWSはKendraのリタイア案内の中で、後継のマネージド検索基盤としてBMKBへの移行を案内しています。両者とも「データソースを接続すればAWS側がインジェストとインデックス管理を担う」というマネージドサービスとしての運用モデルを共有しており、自前でベクトルDBやRAGパイプラインを構築する場合と比べて移行の学習コストを抑えられる点が、BMKBが移行先として妥当とされる理由です。もっとも、検索APIの呼び出し方(KendraのQuery/Retrieve APIとBMKBのRetrieve/RetrieveAndGenerate API)は名称・パラメータともに異なるため、アプリケーション側の呼び出しコードは書き換えが必要です。この呼び出しコードのマッピングは§4で具体的に扱います。

複数indexを運用している場合の考慮点:

Kendraを複数index(例: 部門ごと、用途ごと)で運用していた組織では、移行を機にBMKB側で統合するかどうかを検討する余地があります。データソースの重複が多い場合はBMKBのKnowledge Baseを1つに統合してmetadata filterでアクセス範囲を分離する構成にすると運用負荷を下げられますが、アクセス権限の分離要件が厳しい場合は、Kendra時代と同様に用途ごとに複数のKnowledge Baseを維持する構成のほうが安全です。この統合可否の判断は、§5で扱う移行判断基準の一部として扱ってください。

複数indexを1つのKnowledge Baseに統合する場合は、データソースごとに異なっていたアクセス制御の粒度をmetadata属性としてどう表現し直すか、統合前に設計しておく必要があります。設計を後回しにしたまま統合を進めると、統合後にアクセス制御の抜け漏れが発覚し、Knowledge Baseの再分割が必要になるケースがあります。

リージョン・利用可能なembeddingモデルの確認:

移行先のリージョンでBMKBおよび利用予定のembeddingモデルが提供されているかは、着手前に必ず確認してください。Kendra indexを東京リージョン(ap-northeast-1)で運用していた場合でも、移行先のBMKBを同一リージョンに配置できるか、また利用したいembeddingモデルがそのリージョンで提供されているかは別途確認が必要です。提供されていないリージョンの組み合わせを前提に計画を立ててしまうと、§4の実行段階で作り直しが発生するため、この確認は§2-3のIAM前提整備と並行して済ませておくことをおすすめします。

2-3. 移行に必要な前提・IAM・ゴール状態

移行作業を始める前に、以下の前提を整えておく必要があります。

① IAMロールの信頼ポリシー

BMKBが利用するIAMロールに、bedrock.amazonaws.comをプリンシパルとするAssumeRole信頼ポリシーを設定します。Kendra用に構築済みのIAMロールをそのまま流用できず、BMKB向けに新規のロール(またはポリシー追加)が必要です。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Principal": {
  "Service": "bedrock.amazonaws.com"
},
"Action": "sts:AssumeRole"
 }
  ]
}

② S3へのアクセス権限

データソースとして利用するS3バケットに対する読み取り権限を、上記ロールにアタッチするポリシーとして付与します。Kendra側でS3コネクタを使っていた場合も、権限設定はBMKB用に作り直しが必要です。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": [
  "arn:aws:s3:::your-source-bucket",
  "arn:aws:s3:::your-source-bucket/*"
]
 }
  ]
}

③ embeddingモデルへのアクセス権限

BMKBがベクトル化に使用するBedrock embeddingモデル(Titan Embeddings等)の呼び出し権限を付与します。モデルの東京リージョンでの利用可否は事前に確認してください。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Action": "bedrock:InvokeModel",
"Resource": "arn:aws:bedrock:ap-northeast-1::foundation-model/amazon.titan-embed-text-v2:0"
 }
  ]
}

④ 補足: 暗号化・クロスアカウントの考慮点

S3バケットにSSE-KMSでの暗号化を設定している場合は、上記のS3アクセス権限に加えて、対象KMSキーへのkms:Decrypt権限もロールに付与する必要があります。また、データソースが移行元とは別のAWSアカウントに存在する場合は、バケットポリシー側でBMKB用ロールのARNを許可する設定も併せて必要になります。Kendra側でこれらのクロスアカウント設定をしていた場合も、BMKB用ロールに対して個別に設定し直してください。

⑤ 実行主体(人/CIロール)のiam:PassRole権限

上記①〜④はBMKBサービスロール自体に付与する権限ですが、これとは別に、CreateKnowledgeBaseを実行する人またはCIロールは、対象のBMKBサービスロールに対しiam:PassRole権限(bedrock.amazonaws.comにスコープ)を保有している必要があります。サービスロール自体の設定がすべて正しくても、この実行主体側のiam:PassRoleが不足しているとAPI呼び出し時点で権限エラーになるため、①〜④とは別軸の確認項目として押さえておいてください。

権限設定の実施順序:

1. BMKB用IAMロールを新規作成し、①の信頼ポリシーを設定する
2. ②のS3アクセス権限をロールにアタッチする(暗号化がある場合は④のKMS権限も併せて付与)
3. ③のembeddingモデル権限をロールにアタッチする
4. DescribeKnowledgeBase等の読み取り系APIを使い、ロールで権限エラーが出ないことを最小構成で確認する

この順序で進めることで、§4で解説するCreateKnowledgeBase実行時に権限エラーで手戻りが発生するリスクを事前に潰せます。ロールの権限は最初から広く付与するのではなく、上記4ステップの範囲に絞った最小権限で開始し、実際にエラーが出た箇所だけを都度追加していく進め方をおすすめします。広い権限を先に付与してしまうと、後から不要な権限を洗い出して剥がす作業が発生し、セキュリティレビューの手間も増えます。

前提整備でつまずきやすいエラーと原因:

これらのエラーはいずれも、CloudTrailのイベント履歴やBedrockのエラーメッセージに含まれるAPIアクション名(s3:GetObject・bedrock:InvokeModel等)から原因を特定できます。エラー発生時は上記表と照らし合わせ、該当するステップの権限設定を再確認してください。

移行準備完了のゴール状態チェックリスト:

これらの前提が整った状態を、本記事における「移行準備完了」のゴール状態と定義します。この状態に到達して初めて、§4で解説するCreateKnowledgeBase以降の実行手順に進めます。前提が不足したまま作成を進めるとAPI呼び出しの権限エラーで停止するため、着手前にIAMロールの信頼ポリシーとアクセス権限を洗い出しておくことが、移行作業全体の手戻りを減らす近道です。

なお、これら①〜④の前提整備自体はKendra運用時のIAM設計と重なる部分もありますが、プリンシパルがBMKB(bedrock.amazonaws.com)に変わる以上、Kendra用ロールの流用ではなく必ず新規に設計し直す必要があります。この点を見落として「既存のKendra用ロールにポリシーを追加すればよい」と進めてしまうと、信頼ポリシーの不一致でAssumeRoleが失敗するため注意してください。

ここまでで、リタイアの正確な対象範囲・移行先BMKBの位置づけ・移行に必要な前提の3点が整理できました。次の§3では、この前提を踏まえたうえで、Kendraからの移行時に実際に直面するコネクタ・機能面のギャップを具体的に棚卸していきます。

3. 機能ギャップ — コネクタ32→7と失われる機能の代替策

3-1. コネクタギャップ — 32+ から 7 への棚卸

Kendraは32種類以上のデータソースコネクタを提供していますが、BMKBが直接サポートするコネクタは7種類(S3・Confluence・SharePoint・Web Crawler・Google Drive・OneDrive・Custom)に絞られます(取得日2026-07-14、docs.aws.amazon.com/kendra/latest/dg/kendra-availability-change.html)。

自組織で利用中のコネクタがこの7種類に含まれるかどうかで、移行の進め方が大きく分かれます。

• 7種類に含まれる場合: BMKB側で同種のデータソース設定を作り直すだけで、ほぼそのまま移行できます。認証情報やクロール対象パスの再設定は必要ですが、データ取り込みの仕組み自体は近い形で移行できます。
• 7種類の対象外となる場合(Salesforce・ServiceNow・Jira・データベース系コネクタ等): BMKBに直接取り込む手段がないため、いったんS3経由でデータパイプラインを組み替える必要があります。具体的には、既存システムから定期的にドキュメントをエクスポートしてS3に配置し、BMKBのS3コネクタでインジェストする構成です。この場合、エクスポートの頻度がそのままBMKB側のデータ鮮度の上限になるため、Kendraコネクタが提供していたリアルタイム(または準リアルタイム)同期を期待していた場合は、鮮度要件を再検討する必要があります。

BMKB対応コネクタ7種類の移行時の留意点:

BMKB非対応コネクタの典型例と移行パターン:

Salesforce・ServiceNow・Jira・各種データベース(RDS/Aurora等)・ServiceDesk系コネクタは、いずれもBMKBの7種類には含まれません。これらは前述のとおりS3経由のパイプラインに置き換える必要があり、代表的な実装パターンは以下の2つです。

1. バッチエクスポート方式: 定期実行のバッチジョブ(EventBridge Scheduler + Lambda等)で対象システムからドキュメントをエクスポートし、S3に配置してBMKBのS3コネクタでインジェストする。実装がシンプルな反面、データ鮮度はバッチ間隔に依存する
2. イベント駆動エクスポート方式: 対象システムの変更をイベント(Webhook等)で検知し、都度S3へ書き出してBMKB側のingestion jobをトリガーする。バッチ方式よりデータ鮮度を高く保てるが、実装・運用コストは増える

コネクタの棚卸は、自組織が利用している全データソースを一覧化し、上記7種類との一致・不一致を洗い出すことから始めてください。不一致のデータソースが多いほど、S3経由のパイプライン構築という追加実装の見積もりが移行スケジュールに直結します。

3-2. 失われる6機能と代替策

コネクタ以外にも、KendraがBMKBより多く備えている機能があります。以下の6機能はBMKBでは標準サポートされておらず、必要であれば代替策を自前で組み込む必要があります。

いずれの代替策も、BMKBの標準機能だけでは完結せず、前段または後段に自前のコンポーネントを追加する構成になります。すべての機能を代替する必要があるわけではなく、自組織のUIやワークフローで実際に使われている機能から優先順位をつけて代替策を検討することが現実的です。

代替策の実装コスト目安と検討優先度:

優先度が高くなりやすい2機能の実装ポイント:

• Faceted Search: metadata filter自体はBMKBの標準機能ですが、「どの属性値がいくつヒットするか」という集計(ファセットカウント)はBMKB側で自動提供されません。UI側で候補となる属性値ごとに個別クエリを発行して件数を取得するか、別途OpenSearchのaggregation機能を併用してファセットカウントを算出する実装が必要になります。
• Custom Synonyms: Kendraでは管理コンソールから同義語辞書を登録できましたが、BMKBには同等の機能がありません。クエリを受け付ける層(APIゲートウェイの前段やLambda)で同義語辞書(DynamoDBやS3上のマッピングファイル)を参照し、クエリ文字列を展開してからBMKBに渡す構成が代表的です。

いずれの機能についても、まずは自組織のUIやワークフローで実際に使われている機能から優先順位をつけて代替策を検討することが現実的です。特にFaceted SearchとCustom Synonymsは、検索UIに深く組み込まれているケースが多く、代替策の実装規模が大きくなりやすいため、早期の棚卸をおすすめします。

4. 移行手順 — Kendra から BMKB へ

§2・§3で整理した前提とギャップの棚卸が終わったら、実際にBMKBを構築してKendraからデータとアプリケーションコードを移行します。本章では①IAMロール設定の最終確認から⑤API移行マッピングまでを、boto3(bedrock-agent/bedrock-agent-runtime)のコード例とともに順を追って解説します。

4-1. 移行手順の全体像

以降の4-2〜4-6で、この5ステップを順に解説します。

4-2. ① IAMロール設定の最終確認

§2-3で作成したIAMロール(信頼ポリシー・S3アクセス・embeddingモデル呼び出し権限)が正しく機能するかを、②の実行前に確認します。ロール自体の作成をやり直す必要はなく、既に付与した権限が揃っているかのチェックです。

import boto3

iam = boto3.client("iam")
role_name = "BMKBMigrationRole"

# 信頼ポリシーの確認(Principal が bedrock.amazonaws.com になっているか)
role = iam.get_role(RoleName=role_name)
print(role["Role"]["AssumeRolePolicyDocument"])

# アタッチ済みポリシーの一覧確認
policies = iam.list_attached_role_policies(RoleName=role_name)
for p in policies["AttachedPolicies"]:
 print(p["PolicyName"], p["PolicyArn"])

この時点で信頼ポリシーのPrincipalがbedrock.amazonaws.comになっていない、あるいはS3・embeddingモデルへの権限が不足している場合は、②以降でAccessDeniedExceptionが発生します。§2-3の「前提整備でつまずきやすいエラーと原因」の表と照らし合わせ、不足があればここで解消してから次に進んでください。

4-3. ② CreateKnowledgeBase(type=MANAGED)の実行

BMKBは、KendraのようにAWS側がベクトルストアの管理まで引き受ける「Managed Knowledge Base」構成で作成します。ユーザー側でOpenSearch Serverlessコレクション等を個別にプロビジョニングする必要はなく、storageConfigurationにtype: MANAGEDを指定することで、ベクトルストアの作成・管理をBMKB側に委ねられます。この点がKendraのマネージド運用感を引き継げる理由です(§2-2参照)。

bedrock_agent = boto3.client("bedrock-agent", region_name="ap-northeast-1")

response = bedrock_agent.create_knowledge_base(
 name="kendra-migration-kb",
 description="Kendra GenAI Enterprise Edition からの移行先KB",
 roleArn="arn:aws:iam::123456789012:role/BMKBMigrationRole",
 knowledgeBaseConfiguration={
  "type": "VECTOR",
  "vectorKnowledgeBaseConfiguration": {
"embeddingModelArn": (
 "arn:aws:bedrock:ap-northeast-1::foundation-model/"
 "amazon.titan-embed-text-v2:0"
)
  },
 },
 storageConfiguration={
  "type": "MANAGED",
 },
)

kb_id = response["knowledgeBase"]["knowledgeBaseId"]
print(f"KnowledgeBase作成完了: {kb_id}")

create_knowledge_baseはすぐにCREATINGステータスを返します。後続のデータソース作成を始める前は、get_knowledge_baseでステータスがACTIVEになるまで待機します。

import time

while True:
 kb = bedrock_agent.get_knowledge_base(knowledgeBaseId=kb_id)
 status = kb["knowledgeBase"]["status"]
 if status == "ACTIVE":
  break
 if status == "FAILED":
  raise RuntimeError(f"KnowledgeBase作成失敗: {kb}")
 time.sleep(10)

4-4. ③ データソース設定

§3-1で棚卸したコネクタ種別に応じて、BMKB対応の7コネクタ(S3・Confluence・SharePoint・Web Crawler・Google Drive・OneDrive・Custom)いずれかでデータソースを作成します。ここではKendraで最も利用頻度の高いS3データソースの例を示します。

response = bedrock_agent.create_data_source(
 knowledgeBaseId=kb_id,
 name="kendra-s3-migration-source",
 dataSourceConfiguration={
  "type": "S3",
  "s3Configuration": {
"bucketArn": "arn:aws:s3:::your-source-bucket",
"inclusionPrefixes": ["docs/"],
  },
 },
 vectorIngestionConfiguration={
  "chunkingConfiguration": {
"chunkingStrategy": "FIXED_SIZE",
"fixedSizeChunkingConfiguration": {
 "maxTokens": 300,
 "overlapPercentage": 20,
},
  }
 },
)

data_source_id = response["dataSource"]["dataSourceId"]

§3-1で確認したとおり、BMKB非対応コネクタ(Salesforce・ServiceNow・Jira・データベース系等)を利用していた場合は、この時点でデータソースとして直接指定できません。先にS3経由のパイプライン(バッチエクスポート方式またはイベント駆動エクスポート方式)でデータをS3に集約し、上記と同様にS3データソースとして設定してください。

Kendraの.metadata.json形式のメタデータファイルを流用している場合、BMKB側でもS3コネクタが同名の.metadata.json規約を認識しますが、フィールド名や属性型の定義がKendraとは異なるため、そのまま流用せず属性の対応関係を事前に確認してください。

4-5. ④ ingestion実行・監視

データソース作成後、実際にドキュメントを取り込む(ベクトル化してインデックスに登録する)にはingestion jobを実行します。

response = bedrock_agent.start_ingestion_job(
 knowledgeBaseId=kb_id,
 dataSourceId=data_source_id,
)

ingestion_job_id = response["ingestionJob"]["ingestionJobId"]

while True:
 job = bedrock_agent.get_ingestion_job(
  knowledgeBaseId=kb_id,
  dataSourceId=data_source_id,
  ingestionJobId=ingestion_job_id,
 )
 status = job["ingestionJob"]["status"]
 stats = job["ingestionJob"].get("statistics", {})
 print(f"status={status} stats={stats}")

 if status in ("COMPLETE", "FAILED"):
  break
 time.sleep(15)

statisticsには取り込み対象・成功・失敗ドキュメント数が含まれます。失敗件数が0でないままステータスをCOMPLETEとして放置すると、一部ドキュメントが検索対象から漏れた状態で本番切替を迎えてしまうため、失敗件数が0であることを確認してから次のステップに進んでください。継続的な同期が必要な場合は、EventBridge Scheduler等でstart_ingestion_jobを定期実行する構成にします。

4-6. ⑤ API移行マッピング

最後に、アプリケーション側のAPI呼び出しをKendra用からBMKB用に書き換えます。§2-2で触れたとおり、KendraとBMKBはAPI名称・パラメータ構造が異なるため、単純なエンドポイント差し替えでは動作しません。

APIマッピング対応表:

retrieve呼び出しの例:

bedrock_runtime = boto3.client("bedrock-agent-runtime", region_name="ap-northeast-1")

response = bedrock_runtime.retrieve(
 knowledgeBaseId=kb_id,
 retrievalQuery={"text": "移行対象のワークロードを教えてください"},
 retrievalConfiguration={
  "vectorSearchConfiguration": {
"numberOfResults": 5,
  }
 },
)

for result in response["retrievalResults"]:
 print(result["content"]["text"], result["score"])

retrieve_and_generate呼び出しの例(検索+生成を1回で完結):

response = bedrock_runtime.retrieve_and_generate(
 input={"text": "移行対象のワークロードを教えてください"},
 retrieveAndGenerateConfiguration={
  "type": "KNOWLEDGE_BASE",
  "knowledgeBaseConfiguration": {
"knowledgeBaseId": kb_id,
"modelArn": (
 "arn:aws:bedrock:ap-northeast-1::foundation-model/"
 "anthropic.claude-sonnet-5"
),
  },
 },
)

print(response["output"]["text"])

metadata filter構文の変換例:

KendraのAttributeFilterでは属性名と値をEqualsTo等の演算子でラップしていましたが、BMKBのfilterは演算子キー(equals/andAll等)を先頭へ置く構造になります。

# Kendra: AttributeFilter の例
kendra_filter = {
 "EqualsTo": {
  "Key": "department",
  "Value": {"StringValue": "sales"},
 }
}

# BMKB: 同等の絞り込みを表現するfilterの例
bmkb_filter = {
 "equals": {
  "key": "department",
  "value": "sales",
 }
}

複数条件をAND/ORで組み合わせる場合も、KendraとBMKBでは入れ子構造のキー名(AndAllFilters/andAll等)が異なります。既存のフィルタロジックをそのまま移植するのではなく、条件ごとにBMKBのfilter構文へ書き直したうえで、想定通りに絞り込めるかを実際のクエリで検証してください。

ここまでで、IAM確認からAPI呼び出しの書き換えまで、Kendra→BMKBへの技術的な移行手順が完了しました。次の§5では、この手順を「いつ」「どう」実行に移すかの判断基準を解説します。

5. 移行判断基準 — いつ・どう移行するか

§4で移行手順そのものは実行可能になりましたが、実務上はもう一段階、「いつ着手し、どのタイミングで本番切替してよいと判断するか」という計画づくりが必要です。本章ではリタイア日程からの逆算スケジューリング、並行運用テストの進め方、本番切替前チェックリストの3点を解説します。

5-1. リタイア日程からの逆算スケジューリング

§2-1で確認したとおり、Kendraは2026-06-30にメンテナンスモード、2026-07-30に新規受付終了を迎えます。移行計画は「07-30までに何かをしなければならない」という発想ではなく、新規受付終了後も既存indexの運用自体は継続できることを踏まえたうえで、自組織にとって現実的な移行完了時期を07-30より前に設定し、そこから逆算してスケジュールを組む考え方が実務的です。

逆算スケジューリングの目安:

上記はあくまで目安であり、データソースの種類数・非対応コネクタの有無・Faceted Search等の代替実装の要否によって前後します。特にBMKB非対応コネクタが多い組織や、Faceted Search・Custom Synonymsのような実装コストの大きい代替策(§3-2参照)が必要な組織は、棚卸フェーズの時点で全体スケジュールを長めに見積もっておくことをおすすめします。

5-2. 並行運用テスト — 同一クエリでのKendra/BMKB比較

本番切替前には、KendraとBMKBの双方に同一のクエリセットを投げて結果を比較する並行運用テストを行います。これは「BMKBが動くかどうか」の確認ではなく、「移行後も検索品質が維持できているか」を定量的に確認するための工程です。

比較すべき指標:

並行運用テストの進め方:

1. Kendra運用時の実クエリログから、代表的なクエリセット(利用頻度の高いもの・エッジケースを含むもの)を抽出する
2. 同一のクエリセットをKendraのQuery/Retrieve APIとBMKBのretrieve APIの双方に投げ、結果を並べて記録する
3. 上位結果の妥当性(利用者の期待する文書を含むか)を人手でレビューし、NDCG・MRRを算出する
4. レイテンシを複数回計測し、平均・p95等でKendra運用時と比較する
5. 差分が大きい場合は、チャンキング設定(§4-4のchunkingConfiguration)やembeddingモデルの見直しでチューニングする

BMKBは常にハイブリッド検索を用いて動作するため(§2-2参照)、Kendra側でキーワード検索中心だった場合は、並行運用テストの段階でセマンティック検索の影響による結果の変化が現れやすい点に留意してください。結果が想定と異なる場合は、チャンクサイズやオーバーラップ率(fixedSizeChunkingConfiguration)の調整、あるいはmetadata filterの見直しでチューニングします。

5-3. 本番切替前チェックリスト

並行運用テストの結果が許容範囲に収まったら、本番切替に進みます。切替直前には以下を確認してください。

本番切替は一度に全トラフィックを切り替えるのではなく、可能であれば一部の利用者・一部のクエリ経路から段階的にBMKBへ切り替え、問題がないことを確認しながら範囲を広げる進め方が安全です。切替後もKendra側を即座に廃止せず、ロールバック手順が確認できる期間は並行稼働させておくことをおすすめします。

ここまでで、移行の実行手順(§4)と着手・切替の判断基準(§5)が揃いました。次の§6では、これらを踏まえても実際の移行現場で陥りがちな詰まりポイントとアンチパターンを整理します。

6. 詰まりポイント / アンチパターン

§1-3で挙げた「着手を先送りした場合に起きやすいこと」を踏まえ、実際の移行現場で頻出する4つの詰まりポイントを、原因と回避策とともに整理します。

6-1. 「GenAI版は残る」誤認による先送り

症状: GenAI Enterprise Editionを利用している組織で、「Bedrockと連携できているのだから、このindexはリタイア対象から外れるはずだ」という前提で社内説明を進めてしまい、移行計画そのものが後回しになるパターンです。

原因: §2-1で整理したとおり、連携機能の有無とリタイア対象かどうかは無関係ですが、この2つを混同したまま経営層・関係チームへの説明が進んでしまうと、移行の緊急度が正しく伝わりません。

回避策: 移行計画の初手で、§2-1の「よくある誤解と正しい理解」の表をそのまま社内共有資料に転記し、GenAI Enterprise Editionも含む全edition が同一タイムラインの対象であることを、関係者全員が同じ理解の上でスタートできるようにしてください。誤解が一度広まってから訂正するよりも、計画着手時点で正確な理解を共有するほうがコストは小さく済みます。

6-2. 非対応コネクタの移行漏れ

症状: データソースの棚卸を最初に一度しか行わず、Salesforce・ServiceNow等のBMKB非対応コネクタ(§3-1)の存在に、移行作業がかなり進んだ段階、あるいは本番切替直前になって初めて気づくパターンです。

原因: Kendraで運用中のデータソースが多い組織ほど、棚卸の抜け漏れが発生しやすくなります。特に、部門ごとに個別追加されたデータソースや、一時的に接続して以降忘れられていたデータソースは、棚卸のタイミングで見落とされがちです。

回避策: §3-1で解説したとおり、棚卸は「自組織が利用している全データソースの一覧化」から始める必要があります。KendraコンソールまたはListDataSources APIで、稼働中のデータソースを機械的に全件洗い出してください。目視の記憶だけに頼る棚卸は精度を欠くため避けてください。非対応コネクタが見つかった場合は、§3-1のS3経由パイプライン(バッチエクスポート方式/イベント駆動エクスポート方式)への置き換えが必要になるため、これは§5-1の逆算スケジューリングにおいて棚卸フェーズを長めに確保すべき最大の理由でもあります。

6-3. Faceted Search前提UIの破綻

症状: 検索UIにファセット絞り込み(カテゴリ・日付等の属性によるドリルダウン)を組み込んでいた場合、移行後にファセットの選択肢そのものが表示されなくなり、UIが機能不全に陥るパターンです。本番切替が完了してから利用者からの問い合わせで発覚するケースが多く見られます。

原因: §3-2で整理したとおり、Faceted SearchはBMKBに標準搭載されていません。metadata filterによる絞り込み自体は可能ですが、「どの属性値がいくつヒットするか」というファセットカウントの集計機能がBMKB側に存在しないため、Kendra時代のUIコードをそのまま移植すると、ファセットの選択肢一覧を取得するAPI呼び出しが失敗、またはUIが空のまま表示されます。

回避策: §3-2の「優先度が高くなりやすい2機能の実装ポイント」で触れたとおり、UI側で候補となる属性値ごとに個別クエリを発行して件数を取得するか、OpenSearchのaggregation機能を別途併用してファセットカウントを算出する実装を、本番切替前に用意しておく必要があります。検索UIにファセット絞り込みが組み込まれている場合は、§5-1の棚卸フェーズの時点でこの代替実装をスコープに含めてスケジューリングしてください。「後で対応すればよい」と先送りすると、本番切替後にUIが破綻した状態のまま利用者へ晒されてしまいます。

6-4. metadata schema非整合

症状: Kendraで運用していたmetadata属性(部門・カテゴリ・公開日等)の名称・型が、BMKB側のmetadata定義とずれており、§4-6で書き換えたfilter構文が想定通りに絞り込みを行わない、あるいはエラーになるパターンです。

原因: §4-4で触れたとおり、Kendraの.metadata.json規約とBMKB側のmetadata属性定義は完全には一致しません。特に、Kendraでは文字列として扱っていた属性がBMKB側では別の型として扱われる場合や、複数indexを統合する際(§2-2「複数indexを運用している場合の考慮点」参照)にmetadata属性の命名がデータソースごとに揺れている場合、フィルタが機能しない、あるいは意図しない結果を返す原因になります。

回避策: §4-4のデータソース設定時にmetadata属性の対応表(Kendra側の属性名・型 → BMKB側の属性名・型)を作成し、実際のドキュメントで疎通確認を行ってください。特に複数indexを1つのKnowledge Baseに統合する場合は、統合前にアクセス制御の粒度をmetadata属性としてどう表現し直すかを設計しておく必要があると§2-2で触れたとおり、metadata schemaの設計は移行の早い段階(§5-1の棚卸・計画フェーズ)で固めておくべき論点です。§5-2の並行運用テストの段階でmetadata filterを使ったクエリを必ずテストケースに含め、意図通りに絞り込めることを確認してから本番切替に進んでください。

6-5. 4つの詰まりポイントに共通する回避の原則

上記4つのパターンに共通するのは、いずれも「移行の早い段階(棚卸・計画フェーズ)で正確に把握していれば防げた」問題である点です。§5-1で解説した逆算スケジューリングにおいて棚卸・計画フェーズを軽視せず、§2の正確な理解・§3の機能ギャップ棚卸を関係者間へあらかじめ共有したのち移行に着手することが、これらの詰まりポイントを未然に防ぐ最も確実な方法です。

7. まとめ + Bedrock KB基礎への双方向クロスリンク

7-1. 本記事の到達点

本記事では、Amazon KendraからAmazon Bedrock Knowledge Bases(BMKB)への移行に固有の論点を、以下の流れで解説してきました。

• §2: GenAI Enterprise Editionを含む全edition が2026-06-30メンテナンスモード・2026-07-30新規受付終了の対象であるという正確な理解と、移行に必要なIAM前提の整備
• §3: コネクタ32+種類から7種類への機能ギャップと、Faceted Search・Custom Synonyms等6機能の代替策
• §4: IAMロール確認からCreateKnowledgeBase・データソース設定・ingestion・API移行マッピングまでの実行手順
• §5: リタイア日程からの逆算スケジューリング・並行運用テスト(NDCG/MRR/レイテンシ比較)・本番切替前チェックリスト
• §6: 「GenAI版は残る」誤認・非対応コネクタの移行漏れ・Faceted Search前提UIの破綻・metadata schema非整合という4つの詰まりポイントと回避策

これらを一通り実行すれば、Kendraワークロードの棚卸から本番切替までを自組織で計画・実行できる状態に到達しているはずです。

7-2. 本記事の役割分担 — 移行特化・基礎は委譲先へ

本記事は「Kendra→BMKB移行」という論点に特化しており、Bedrock Knowledge Basesそのものの作成方法・RAGの基本概念・ベクトルDB選定・チャンク戦略の一般論(§1-2で述べたスコープ外領域)は扱っていません。これらの基礎を押さえたい場合は、以下の既存記事を参照してください。

上記3記事とは逆に、Kendraを利用しておらずBMKBを新規に構築したい場合や、移行ではなく最初からBedrock Knowledge Basesを選定したい場合は、本記事で解説した移行固有の論点(リタイア対象範囲・コネクタギャップ・移行手順)は読み飛ばし、上記の基礎記事から読み進めることをおすすめします。

反対に、既にKendraを運用中で移行が必須の状況にある場合は、まず本記事の§2〜§6に沿って棚卸・計画・実行・判断を進め、BMKBの一般的な運用ノウハウが必要になった段階で上記の基礎記事に読み進める、という順序が効率的です。