Amazon Kendra は新規顧客に公開されなくなりました。同様の機能については Amazon Kendra、Amazon Bedrock ナレッジベースを参照してください。[詳細はこちら](https://docs.aws.amazon.com/kendra/latest/dg/kendra-availability-change.html)。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Kendra 可用性の変更
## 概要
慎重に検討した結果、2026 年 6 月 30 日に をメンテナンスモード Amazon Kendra に移行することを決定しました。この日現在、このサービスには新機能や機能開発はなく、2026 年 7 月 30 日現在、このサービスは新しいお客様に公開されていません。
メンテナンスモードでは、サービスは完全にサポートされ、既存のお客様にバグ修正とセキュリティ更新プログラム AWS を提供し続けますが、新機能のリクエストは考慮されなくなります。
お客様は Kendra アプリケーションを移行し、Amazon Bedrock Managed Knowledge Base (BMKB) に新しい検索アプリケーションを実装して、Kendra と同様の機能や、生成 AI およびエージェント AI のユースケース向けのより高度な機能を使用することをお勧めします。Bedrock Managed Knowledge Base は、完全マネージド型 RAG ソリューションで、組み込みコネクタ、スマート解析、ハイブリッド検索によるマネージドベクトルストア、レスポンスの生成 (Retrieve and Generate API を使用）、複数のナレッジベースにわたるマルチステップ推論の実行 (Agentic Retrieval API を使用) 機能を備えています。BMKB では、チャンキング戦略と埋め込みモデルを調整して特定のアプリケーションを最適化したり、レスポンス生成の基盤モデルを選択したりすることもできます。この新しいレベルの機能と柔軟性には、取り込まれたナレッジベースのサイズ、実行されたクエリの数、LLM の使用に基づいて予測可能なコストが伴います。
## 移行ガイダンス
から Amazon Kendra Amazon Bedrock Managed Knowledge Base (BMKB) への移行は、ほとんどのエンタープライズ検索および RAG ワークロードで慎重に計画することで実現できます。すべての Kendra 機能が Bedrock Managed Knowledge Base で直接利用できるわけではありませんが、多くの機能は回避策を通じて実装できます。このガイドでは、アーキテクチャマッピング、API 翻訳、コード例、特徴量ギャップ分析、推奨される回避策など、既存の Kendra のお客様がアプリケーションを BMKB に移行するための包括的なstep-by-stepの移行パスを提供します。
### Amazon Bedrock マネージドナレッジベースの機能
BMKB は RAG パイプライン全体をend-to-end。Amazon Titan Text Embeddings V2、Cohere Embed English v3、Cohere Embed Multilingual v3、Cohere Embed v4、Amazon Nova Multimodal Embeddings などの埋め込みモデルがサポートされており、すべて float32 ベクトルで 1024 ディメンションに固定されています。マネージドベクトルストアは Bedrock によって完全に運用されているため、OpenSearch、Aurora、またはその他のベクトルデータベースをプロビジョニングまたは管理する必要がなくなります。チャンキング戦略には、デフォルト (約 300 トークンで固定サイズ）、固定サイズ (設定可能な maxTokens と overlapPercentage)、階層 (レベル設定の親子）、チャンキングなしが含まれます。セマンティックチャンキングはマネージドナレッジベースではサポートされていません。
BMKB は現在、Amazon S3、Confluence、Microsoft SharePoint、Web Crawler、Google Drive、Microsoft OneDrive、Custom コネクタの 7 つのデータソースコネクタをサポートしています。このサービスは常にハイブリッド検索 (キーワードとセマンティック) を実行し、セマンティックのみの検索モードは提供しません。
**Amazon Kendra と Bedrock マネージドナレッジベースのアーキテクチャ比較**
| 機能 | Kendra | Bedrock マネージドナレッジベース |
| --- | --- | --- |
| ネイティブコネクタ | 32 個以上のコネクタ | 7 コネクタ |
| 埋め込み | 内部で管理 | お客様が選択可能 (Titan V2、Cohere、Nova) |
| ベクトルストア | 内部で管理 | Bedrock によるフルマネージド |
| 検索タイプ | キーワード、セマンティック、またはハイブリッド | ハイブリッド (キーワード \+ セマンティック) |
| RAG のサポート | 外部 LLM 統合が必要 | ネイティブ RetrieveAndGenerate API |
| エージェントの取得 | 利用不可 | ネイティブのマルチイテレーション取得 |
| 最大結果 | 100 パッセージ (API の取得) | 100 の結果 (API の取得) |
## 移行手順
### Amazon Bedrock マネージドナレッジベースのセットアップ
#### ステップ 1: IAM ロールを設定する
データソースにアクセスして埋め込みモデルを呼び出すアクセス許可を Bedrock に付与する IAM ロールを作成します。信頼ポリシーは bedrock.amazonaws.com がロールを引き受けることを許可し、アクセス許可ポリシーには S3 バケットと選択した埋め込みモデルへのアクセスを含める必要があります。
IAM 設定 (Python コード):
```
import boto3
import json
iam = boto3.client('iam')
trust_policy = {
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"Service": "bedrock.amazonaws.com"},
"Action": "sts:AssumeRole"
}]
}
iam.create_role(
RoleName="BedrockKBRole",
AssumeRolePolicyDocument=json.dumps(trust_policy),
Description="Role for Bedrock Managed Knowledge Base"
)
permissions_policy = {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": [
"arn:aws:s3:::your-bucket-name",
"arn:aws:s3:::your-bucket-name/*"
]
},
{
"Effect": "Allow",
"Action": ["bedrock:InvokeModel"],
"Resource": ["arn:aws:bedrock:*::foundation-model/amazon.titan-embed-text-v2:0"]
}
]
}
iam.put_role_policy(
RoleName="BedrockKBRole",
PolicyName="BedrockKBPermissions",
PolicyDocument=json.dumps(permissions_policy)
)
```
#### ステップ 2: マネージドナレッジベースを作成する
CreateKnowledgeBase API を MANAGED 型で使用してナレッジベースを作成します。
```
import boto3
bedrock_agent = boto3.client("bedrock-agent", region_name="us-east-1")
response = bedrock_agent.create_knowledge_base(
name="my-managed-kb",
description="Migrated from Kendra index",
roleArn="arn:aws:iam::123456789012:role/BedrockKBRole",
knowledgeBaseConfiguration={
"type": "MANAGED",
"managedKnowledgeBaseConfiguration": {
"embeddingModelArn": "arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-embed-text-v2:0",
"embeddingModelConfiguration": {
"bedrockEmbeddingModelConfiguration": {
"embeddingDataType": "FLOAT32"
}
}
}
}
)
kb_id = response["knowledgeBase"]["knowledgeBaseId"]
print(f"Created knowledge base: {kb_id}")
```
#### ステップ 3: データソースを設定する
マネージドコネクタ設定を使用して S3 データソースを作成します。
```
response = bedrock_agent.create_data_source(
knowledgeBaseId=kb_id,
name="my-s3-data-source",
description="Product documentation from S3",
dataSourceConfiguration={
"type": "MANAGED_KNOWLEDGE_BASE_CONNECTOR",
"managedKnowledgeBaseConnectorConfiguration": {
"connectorParameters": {
"type": "S3",
"version": "1",
"connectionConfiguration": {
"bucketName": "your-bucket-name",
"bucketOwnerAccountId": "123456789012"
},
"filterConfiguration": {
"inclusionPrefixes": ["documents/"]
}
}
}
},
vectorIngestionConfiguration={
"parsingConfiguration": {
"parsingStrategy": "SMART_PARSING"
}
}
)
data_source_id = response["dataSource"]["dataSourceId"]
print(f"Created data source: {data_source_id}")
```
**注記**
CreateDataSource は、マネージドナレッジベースでは非同期です。データソースのステータスは、通常 2～5 分以内に CREATING から AVAILABLE に移行します。ステータスが AVAILABLE になるまで取り込みに進まないでください。
#### ステップ 4: 取り込みを開始してモニタリングする
ドキュメントの取り込みと完了のポーリングをトリガーします。
```
import time
ingestion_response = bedrock_agent.start_ingestion_job(
knowledgeBaseId=kb_id,
dataSourceId=data_source_id,
description="Initial ingestion"
)
ingestion_job_id = ingestion_response["ingestionJob"]["ingestionJobId"]
print(f"Started ingestion job: {ingestion_job_id}")
while True:
job_response = bedrock_agent.get_ingestion_job(
knowledgeBaseId=kb_id,
dataSourceId=data_source_id,
ingestionJobId=ingestion_job_id
)
job = job_response["ingestionJob"]
status = job["status"]
stats = job.get("statistics", {})
print(f"Status: {status} | Scanned: {stats.get('numberOfDocumentsScanned', 0)} | "
f"Indexed: {stats.get('numberOfNewDocumentsIndexed', 0)} | "
f"Failed: {stats.get('numberOfDocumentsFailed', 0)}")
if status == "COMPLETE":
print("Ingestion complete!")
break
elif status in ("FAILED", "STOPPED"):
print(f"Ingestion {status}: {job.get('failureReasons', [])}")
break
time.sleep(30)
```
## API 移行マッピングとコード例
### API オペレーションマッピング
**Kendra から BMKB への API オペレーションマッピング**
| 運用 | Kendra API | BMKB API | クライアント |
| --- | --- | --- | --- |
| インデックスの作成/KB | kendra.create\_index() | bedrock-agent.create\_knowledge\_base() | kendra → bedrock-agent |
| データソースの追加 | kendra.create\_data\_source(タイプ"S3") | bedrock-agent.create\_data\_source() | kendra → bedrock-agent |
| ドキュメントの同期/取り込み | kendra.start\_data\_source\_sync\_job() | bedrock-agent.start\_ingestion\_job() | kendra → bedrock-agent |
| ドキュメントのバッチ追加 | kendra.batch\_put\_document() | 直接サポートされていない (S3 アップロード \+ 取り込みを使用) | kendra → S3 \+ bedrock-agent |
| パッセージを取得する | kendra.retrieve(QueryText=...) | bedrock-agent-runtime.retrieve() | kendra → bedrock-agent-runtime |
| フィルターで検索する | AttributeFilter: {"EqualsTo": {...}} | フィルター: {"equals": {...}} | 同じパターン、異なる構文 |
| RAG 生成 | 該当なし (外部 LLM が必要) | bedrock-agent-runtime.retrieve\_and\_generate() | 新機能 |
### Retrieve API の移行
前 (Kendra):
```
kendra_client = boto3.client("kendra")
response = kendra_client.retrieve(
IndexId="your-kendra-index-id",
QueryText="How do I configure VPC endpoints?",
AttributeFilter={
"EqualsTo": {
"Key": "_category",
"Value": {"StringValue": "networking"}
}
},
PageSize=10
)
for item in response["ResultItems"]:
print(item["DocumentTitle"])
print(item["Content"])
```
後 (BMKB):
```
bedrock_runtime = boto3.client("bedrock-agent-runtime", region_name="us-east-1")
response = bedrock_runtime.retrieve(
knowledgeBaseId="your-kb-id",
retrievalQuery={
"text": "How do I configure VPC endpoints?"
},
retrievalConfiguration={
"managedSearchConfiguration": {
"numberOfResults": 10,
"filter": {
"equals": {
"key": "category",
"value": "networking"
}
}
}
}
)
for result in response["retrievalResults"]:
print(f"Score: {result['score']}")
print(f"Content: {result['content']['text']}")
print(f"Source: {result['location']['s3Location']['uri']}")
```
主な違いは、クエリテキストが最上位のパラメータからネストされた retrievalQuery.text フィールドに移動し、AttributeFilter が managedSearchConfiguration 内でフィルタリングされ、結果に関連性スコアフィールドが含まれることです。
### RAG に RetrieveAndGenerate を使用する
BMKB はネイティブ RAG 機能を提供するため、取得後に LLM を個別に呼び出す必要がなくなります。
```
response = bedrock_runtime.retrieve_and_generate(
input={
"text": "Explain how to configure VPC endpoints for S3 access"
},
retrieveAndGenerateConfiguration={
"type": "KNOWLEDGE_BASE",
"knowledgeBaseConfiguration": {
"knowledgeBaseId": "your-kb-id",
"modelArn": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0",
"retrievalConfiguration": {
"managedSearchConfiguration": {
"numberOfResults": 5
}
}
}
}
)
# Generated answer with citations
print(response["output"]["text"])
# Source citations
for citation in response.get("citations", []):
for ref in citation.get("retrievedReferences", []):
print(f"Source: {ref['location']['s3Location']['uri']}")
```
この API は、生成された自然言語レスポンスをソースドキュメントを指す引用とともに返し、Kendra がネイティブに提供していない組み込み RAG を提供します。
### メタデータフィルター構文変換
**メタデータフィルター演算子のマッピング**
| Kendra AttributeFilter | BMKB フィルター | 注意事項 |
| --- | --- | --- |
| EqualsTo | equals | 直接マッピング |
| ContainsAll | の (部分) | BMKB がセットメンバーシップを使用する |
| ContainsAny | 情報 | 直接マッピング |
| GreaterThan | greaterThan | 直接マッピング |
| LessThan | lessThan | 直接マッピング |
| GreaterThanOrEquals | greaterThanOrEquals | 直接マッピング |
| LessThanOrEquals | lessThanOrEquals | 直接マッピング |
| NotFilter | notIn/notEquals | 適切な否定を使用する |
| AndAllFilters | andAll | 直接マッピング |
| OrAllFilters | orAll | 直接マッピング |
**注記**
BMKB はstartsWithまたは stringContainsマネージドナレッジベースの演算子をサポートしていません。Kendra アプリケーションがフィルターでワイルドカードまたは部分文字列マッチングを使用している場合は、代わりに完全一致パターンまたは集合メンバーパターンを使用するようにメタデータスキーマを再構築する必要があります。
## 機能のギャップと回避策
すべての Kendra 機能が BMKB で利用できるわけではありません。クエリ提案、ファセット検索、カスタムシノニム、スペルチェック、インクリメンタルラーニング、ドキュメントエンリッチメントは、BMKB の回避策を必要とする機能です。このセクションでは、これらの回避策について説明します。
**クエリ提案 (オートコンプリート)**
Kendra には、インデックス付きドキュメント語彙に基づいてオートコンプリート候補を返す GetQuerySuggestions API が用意されています。BMKB は現在この機能を提供していません。
**回避策:** 組み込みのサジェスタ機能を備えた Amazon OpenSearch Service を使用してカスタムオートコンプリートレイヤーを実装するか、LLM ベースのクエリ完了サービスを使用します。Bedrock エージェントを活用して、取得前に部分的なクエリを再計算することもできます。実用的なアプローチは、ドキュメントコーパスから抽出された一般的なクエリ用語の個別の OpenSearch インデックスを維持し、BMKB 取得を呼び出す前にフロントエンドから提案 API を呼び出すことです。
**ファセット検索**
Kendra は、クエリ API の Facets パラメータを介してドキュメント属性ファセットをサポートし、ファセットごとに最大 10 個のファセット値とドキュメント数を表示します。BMKB のアーキテクチャはファセット検索をサポートしていません。
**回避策:** メタデータフィルタリングを使用してファセットナビゲーションをシミュレートします。.metadata.json サイドカーファイル内の構造化メタデータ属性 (部門、作成者、ドキュメントタイプ、日付範囲) を使用してドキュメントにタグ付けします。既知のメタデータスキーマに基づいてアプリケーション UI にフィルターオプションを提示し、クエリ時に対応するフィルター演算子を適用します。これは動的なファセット数を提供しませんが、ユーザーは結果をカテゴリ別に絞り込むことができます。
```
# Simulating faceted search with metadata filters
response = bedrock_runtime.retrieve(
knowledgeBaseId="your-kb-id",
retrievalQuery={"text": "security best practices"},
retrievalConfiguration={
"managedSearchConfiguration": {
"numberOfResults": 10,
"filter": {
"andAll": [
{"equals": {"key": "department", "value": "engineering"}},
{"equals": {"key": "doc_type", "value": "policy"}}
]
}
}
}
)
```
**カスタムシノニム**
Kendra では、シソーラスファイルを介して検索結果を照合するために、他の用語にマッピングされたビジネス固有の用語のカスタムマッピングを構築できます。BMKB は現在、カスタムシノニムをサポートしていません。
**回避策:** BMKB クエリの前に軽量シノニム拡張サービスを構築します。
+ 既存の Kendra シソーラスファイル (または DynamoDB/S3 のシノニムディクショナリ) を維持する
+ BMKB Retrieve または RetrieveAndGenerate API を呼び出す前に、一致するシノニムを追加してユーザーのクエリを展開します。
+ 例: ユーザーが「DNS の問題」をクエリする場合、アプリケーションは BMKB に送信する前にそれを「DNS Route53 の問題」に書き換えます。
これは特に効果的です。BMKB は常にハイブリッド検索 (キーワード \+ セマンティック) を使用するため、クエリテキストにシノニム用語を追加すると、キーワードディメンションとセマンティックディメンションの両方で一致します。
**スペルチェック**
Kendra は、SpellCorrectionConfiguration を介してインデックス付きドキュメント語彙に基づいて自動スペル修正を提供します。BMKB は現在スペルチェックをサポートしていません。
**回避策:** BMKB にクエリを送信する前に、前処理レイヤーを追加します。スペル修正ライブラリ (SymSpell や TextBlob など) を呼び出すか、クエリ修正のために LLM を呼び出す AWS Lambda 関数を使用します。
```
import boto3
lambda_client = boto3.client("lambda")
def correct_and_retrieve(query_text, kb_id):
# Step 1: Spell-correct the query using a Lambda function
correction_response = lambda_client.invoke(
FunctionName="spell-correction-function",
Payload=json.dumps({"query": query_text})
)
corrected_query = json.loads(correction_response["Payload"].read())["corrected"]
# Step 2: Query BMKB with corrected text
bedrock_runtime = boto3.client("bedrock-agent-runtime")
return bedrock_runtime.retrieve(
knowledgeBaseId=kb_id,
retrievalQuery={"text": corrected_query},
retrievalConfiguration={"managedSearchConfiguration": {"numberOfResults": 5}}
)
```
**増分学習**
Kendra は、クリックスルーシグナルと関連性フィードバックのための SubmitFeedback API をサポートし、時間の経過とともにランキングを改善します。BMKB はこの機能を提供していません。
**回避策:** BMKB の再ランク付けモデルを使用して、クエリ時の関連性を向上させます。ユーザーのクリックシグナルと評価シグナルを外部データストア (DynamoDB など) に保存し、それらのシグナルを使用してメタデータブーストの重みを調整したり、パラメータを再ランク付けしたりするカスタムフィードバックループを構築します。長期的な改善のために、収集された関連性のフィードバックに基づいて、埋め込みモデルを定期的に微調整することを検討してください。
**カスタムドキュメントエンリッチメント**
Kendra は、取り込み中にドキュメントの内容とメタデータを操作する抽出前および抽出後の Lambda フックをサポートしています。BMKB はドキュメント処理にスマート解析を使用しますが、同等の Lambda フックは提供していません。
**回避策:** AWS Step Functions または Lambda を使用して前処理パイプラインを実装し、ドキュメントを BMKB 取り込みのために S3 に配置する前に変換します。このパイプラインは、ドキュメントが BMKB データソースバケットに到達する前に、コンテンツ抽出、メタデータエンリッチメント、PII リダクション、または形式変換を実行できます。
## データソース移行戦略
### コネクタカバレッジギャップ
Kendra は 32 のネイティブコネクタをサポートし、BMKB は 7 をサポートします。BMKB で直接サポートされていないデータソースの場合、Amazon S3 にコンテンツをエクスポートし、BMKB で S3 データソースを設定することをお勧めします。
**サポートされていないコネクタの移行パターン:** API を介してソースシステムからコンテンツを定期的に抽出し、適切なメタデータ JSON サイドカーファイルを使用してドキュメントを S3 バケットに書き込み、BMKB 取り込みジョブをトリガーする自動パイプライン ( AWS Lambda、Step Functions、または Amazon EventBridge スケジューラを使用) を作成します。これにより、Kendra コネクタの定期的な同期動作がレプリケートされます。
### メタデータの移行
Kendra ドキュメント属性は BMKB メタデータ形式に変換する必要があります。Kendra では、属性はインデックスレベルで定義され、取り込み中にドキュメントにアタッチされます。BMKB では、メタデータは S3 のソースドキュメントとともに保存される .metadata.json サイドカーファイルを介して定義され、ファイルあたりの最大サイズは 10 KB です。各属性は、STRING、NUMBER、または BOOLEAN として入力する必要があります。
### チャンキング戦略の選択
(内部的にチャンキングを処理する) Kendra から移行する場合、BMKB のチャンキング戦略を明示的に選択する必要があります。ほとんどの移行シナリオでは、200 個のトークンと 30% の重複を持つ固定サイズ戦略が良い出発点となります。ドキュメントに明確な階層構造 (チャプター、セクション、サブセクション) がある場合は、広範なコンテキストと特定の詳細の両方の取得を改善するために階層チャンキングを検討してください。
## テストと検証
パフォーマンスを評価するには、Kendra と BMKB の両方を並行して実行します。両方のサービスに同一のクエリを送信し、次のディメンションを使用して結果を比較します。関連性の品質 (ゴールデンテストセットに対して NDCG または MRR で測定）、レイテンシー (p50、p95、p99 応答時間）、スループット (ロード中のクエリ/秒）、完全性 (取得予定のドキュメントの割合）。
取り出し品質を評価するテストハーネスを作成します。
```
def compare_retrieval(query, kendra_index_id, bmkb_kb_id):
# Query Kendra
kendra_results = kendra_client.retrieve(
IndexId=kendra_index_id,
QueryText=query,
PageSize=10
)
# Query BMKB
bmkb_results = bedrock_runtime.retrieve(
knowledgeBaseId=bmkb_kb_id,
retrievalQuery={"text": query},
retrievalConfiguration={
"managedSearchConfiguration": {"numberOfResults": 10}
}
)
# Compare overlap in top-10 results
kendra_docs = {r["DocumentId"] for r in kendra_results["ResultItems"]}
bmkb_docs = {r["location"]["s3Location"]["uri"] for r in bmkb_results["retrievalResults"]}
overlap = len(kendra_docs.intersection(bmkb_docs))
print(f"Query: {query}")
print(f"Result overlap: {overlap}/10 documents in common")
return overlap
```
本番稼働用トラフィックを BMKB に切り替える前に、次の点を確認します。すべてのデータソースが取り込まれup-to-date最新の状態でドキュメントに障害がない、メタデータフィルターがすべてのアプリケーションフィルターパターンで期待される結果を生成する、アクセスコントロールの回避策が不正アクセスを正しく制限する、関連性ベンチマークが Kendra のベースライン品質を満たすか超える、アプリケーションエラー処理が BMKB 応答形式を正しく処理する、モニタリングとアラートが BMKB API エラーとレイテンシーに対して設定される。
## 概要
から Bedrock Managed Knowledge Base への移行には Amazon Kendra 、データソースを BMKB に再取り込みし、アプリケーションコードを書き換えて BMKB APIs を使用するという 2 つの主な作業が必要です。BMKB にはRetrieveAndGenerate やエージェント検索などの強力な RAG ネイティブ機能が導入されていますが、ファセット、クエリの提案、カスタムシノニム、増分学習などのエンタープライズ検索機能を使用するお客様は、このガイドで説明されているように回避策を実装する必要があります。
その他の質問がある場合は、 [AWS サポート](https://console.aws.amazon.com/support)にお問い合わせください。