公開2026.07.30更新2026.09.18 20 人が閲覧（直近 30 日） AI

Amazon Kendraとは？新規受付終了と移行先BMKBの判断をboto3コード付きで解説【2026年版】

Amazon Kendraは、社内に散らばった文書を自然言語の質問で横断検索できるAWSのマネージド検索サービスです。ただし2026年6月30日付でメンテナンスモードへ移り、7月30日からは新規顧客の受付を停止しました。これから検索基盤を組む案件では、もう選べません。本記事では、Kendraが何をするサービスなのか、3種のインデックスと時間課金の構造、既存顧客に残された保守範囲、そしてAWSが移行先に指名したBedrock Managed Knowledge Baseとの機能差分までを、実装と費用の観点で並べます。移行の手を動かす段では、IAMロールの作成からナレッジベース作成・取り込み・検索呼び出しまでを、公式ドキュメント記載のCLIとboto3のコードで追います。

まとめ：新規受付停止後にKendraを選べる条件と移行先の第一候補

結論から。2026年7月30日以降に新しくKendraを契約する道はありません。Kendraを検索側に使えたAmazon Q Businessも同様に新規受付を終了しており、その機能・料金と移行先の判断はAmazon Q Businessとは？新規受付終了後の代替と料金・移行の判断にまとめました。すでにインデックスを持つアカウントだけが引き続き使えます。

これから組むならAmazon Bedrock Managed Knowledge Base（以下BMKB）が第一候補になります。AWSのWhat’s newによれば2026年6月17日にGAとなり、東京リージョンでも動きます。RAGの応答生成までRetrieveAndGenerateひとつで完結し、ベクトルストアを自前で用意する必要もありません。

ただし乗り換えは等価交換ではありません。ネイティブコネクタは32種から大きく減り、ファセット検索・カスタムシノニム・スペル訂正・クエリサジェスト・増分学習・ドキュメント拡張の6機能には自前の回避策が要ります。既存顧客が移行時期を決める軸は、この6機能への依存度です。

もうひとつ、日本国内の案件で確認が必要なのは、対応リージョンと言語の制限です。精度が最も高いKendra GenAI Enterprise Editionインデックスは、2026年9月18日時点の公式ドキュメントで提供が2リージョンに限られ、しかも英語コンテンツのみの対応と明記されています。日本語文書を対象にするなら、既存顧客であってもGenAI Indexは選択肢から外れます。

Amazon Kendraの定義｜自然言語で社内文書を横断検索するマネージド検索基盤

何を引き受けるサービスなのか。公式ドキュメントの定義から確かめます。

キーワード一致ではなく意味的類似で文書チャンクを順位付ける検索方式

AWSはKendraの開発者ガイドで、Kendraを「自然言語処理と深層学習モデルを用いたマネージドな情報検索およびインテリジェント検索サービス」と定義しています。従来のキーワード検索と異なり、テキストチャンクや文書が問い合わせに関連するかどうかを、意味的・文脈的な類似度とランキング機能で判定する設計です。

語の一致を数えません。「VPCエンドポイントの設定手順」と問えば、その語を含まない「プライベート接続の構成方法」という見出しの文書も候補に上がってきます。

複数のデータリポジトリをひとつのインデックスへ接続し、文書を取り込んでクロールする構成が基本形。取り込んだメタデータで検索体験を作り込める点が、単純な全文検索との差になります。

Factoid・Descriptive・自然言語クエリという3類型への回答範囲

答えられる質問は3つの型に分かれます。1つ目はFactoid、つまり誰が・何を・いつ・どこでという事実質問で、単語やフレーズで返せるもの。FAQデータやインデックス済み文書から抽出されます。

2つ目はDescriptive。「Echo Plusをネットワークに接続する方法」のように、答えが1文や1段落、あるいは文書全体になる質問を指します。

3つ目がキーワードと自然言語の混ざった曖昧なクエリです。「keynote address」のようにaddressが複数の意味を持つ語でも、文脈から意図を推定して結果を返す挙動が公式ドキュメントに明記されています。この3類型のどれを主に想定するかで、後述のインデックス選定とメタデータ設計が変わってきます。

自前の全文検索基盤との境界｜Kendraが引き受ける範囲と残る実装作業

引き受けてもらえるのは、意味検索モデルの学習と推論、インデックスの運用、コネクタによる同期スケジュールまで。埋め込みモデルの選定もチャンク分割の設計も内部に隠れています。埋め込みモデルの選び方を自分で決められないことは、精度が出ないときの打ち手が減ることと同義です。

手元に残るのは、アクセス制御の設計、メタデータのスキーマ定義、検索UIの実装、再同期の運用管理です。AlgoliaやElasticsearchを含めたAWS検索サービスの選び分けでは、この境界をどこに引くかで候補が入れ替わります。

もうひとつ。Kendraには他の検索サービスの結果を意味的に並べ替えるIntelligent Rankingという使い方もあり、既存の検索基盤を残したまま精度だけ足す構成も取れました。

2026年6月のメンテナンスモード移行と7月30日新規受付停止の告知内容

ここが本記事の主題です。告知の中身を条文の粒度で押さえます。

告知の中身｜機能開発の停止と新規顧客受付の停止という2段階の期日

AWSはAmazon Kendra availability changeというページで、Amazon Kendraを2026年6月30日付でメンテナンスモードに置くと告知しました。この日以降、サービスの新機能や新しい能力の開発は行われません。

期日は2段階に分かれています。2026年6月30日にメンテナンスモードへ移行し、2026年7月30日にサービスが新規顧客の受付を停止する流れ。告知の中では、利用したい場合は7月30日より前にサインアップするよう案内されていました。

メンテナンスモード中もサービス自体は完全にサポートされます。ただし新機能のリクエストは、今後いっさい検討されません。

既存インデックスの扱い｜バグ修正とセキュリティ更新が続く保守範囲

既存顧客に対しては、AWSがバグ修正とセキュリティ更新の提供を継続すると明言しています。稼働中のインデックスが即座に止まる話ではありません。

とはいえ、機能追加の止まった基盤は時間とともに周辺サービスとの落差が開きます。BMKB側には取り込み時のスマートパーシングや複数ナレッジベースを横断する多段推論（Agentic Retrieval）が載る一方、Kendraにはもう載りません。

サービス終了の期日は現時点で公表されていない、という点も押さえておく必要があります。無期限の保証ではなく、移行計画を立てる猶予が与えられている状態と読むのが妥当でしょう。同じ型で2024年に新規受付を終えたAmazon Forecastの提供状況と移行判断では、2年たってもサンセットの期日は示されていません。

新規案件から外れた影響｜AWS上でRAGを組む選択肢の再編と移行期限

AWS上で社内文書のRAGを組む場合、これまではKendra、Bedrock Knowledge Bases、自前のベクトルデータベースという3択でした。Kendraが抜けた結果、マネージドで完結させたい案件はBMKBへ寄ります。

AWSの推奨も明快です。既存のKendraアプリケーションは移行し、新規の検索アプリケーションはBMKB上で実装するよう公式ドキュメントが述べています。理由として挙がっているのは、生成AIとエージェンティックAIのユースケースに向けたより高度な機能群でした。

移行作業の実体は、BedrockとKendraを組み合わせたRAGの実装手順で扱った構成を、BMKB側のAPIへ置き換えていく工程になります。

インデックス3種の機能差と時間課金の構造｜GenAI Indexを含む料金比較

Kendraの費用は文書数ではなく、プロビジョニングした時間で決まります。

エディション別の単価比較｜基本料金・ストレージ・クエリユニット単価

インデックスは3種類です。GenAI Enterprise Edition、Basic Enterprise Edition、Basic Developer Edition。AWSは精度の観点から、GenAI Indexの利用を推奨してきました。単価はKendraの公式料金ページの2026年9月18日時点の記載です。

インデックス種別	基本料金	ストレージ単価	クエリ単価
GenAI Enterprise	0.32 USD 毎時	0.25 USD 毎時	0.07 USD 毎時
Basic Enterprise	1.4 USD 毎時	0.7 USD 毎時	0.7 USD 毎時
Basic Developer	1.125 USD 毎時	追加購入不可	追加購入不可

Basic Developer Editionは検証用の位置づけで、本番ワークロードには推奨されていません。追加ユニットも買えない構成です。

課金はインデックスを作成した瞬間から削除するまで続きます。空でもクエリがゼロでも止まりません。無料枠はBasic Developer EditionとGenAI Enterprise Editionについて、最初の30日で最大750時間ぶんが用意されていました。

コネクタ同期の課金｜月額固定30 USDと同期時間・スキャン件数の従量分

見落としやすいのがコネクタです。公式料金ページの現行記載では、GenAI Enterprise Editionはインデックスあたり月額30 USDの定額で、月500時間までの同期実行を含みます。同期時間あたり0.35 USDとスキャン文書100万件あたり1 USDという従量単価が乗るのは、Basic EnterpriseとBasic Developerの2エディションです。エディションを取り違えると試算が桁で狂います。

無料枠にコネクタは含まれません。検証段階でも、SharePointやConfluenceを繋いだ時点で課金が始まります。

試算してみます。GenAI Enterprise Editionを1本、ストレージとクエリを各1ユニットで30日回すと、基本0.32にストレージ0.25とクエリ0.07を足して毎時0.64 USD、月およそ461 USD。ここへコネクタの30 USDが乗る計算になります。移行先の費用感と並べたい場合は、AWS Bedrockの料金体系を突き合わせてください。

GenAI Indexの提供リージョンとBedrock・Q Businessからの利用

ここは2026年9月18日時点で現況を取り直しました。公式ドキュメントのGenAI Enterprise Editionインデックスの制限には、提供がUS East（バージニア北部）とUS West（オレゴン）だけと明記されています。東京リージョンには来ませんでした。国内にデータを置く要件のある案件では、この時点で候補から外れます。Basic系を含む提供リージョンはAWS一般リファレンスのエンドポイント一覧で確認できます。

リージョン以上に効いてくる制限が、同じページに並んでいます。GenAI Enterprise Editionインデックスは英語コンテンツのみをサポートし、v2.0のデータソースコネクタしか受け付けず、トークンベースのアクセス制御もユーザーIDとグループに基づくアクセス制御も使えません。CreateAccessControlConfigurationも無効です。日本語の社内規程を検索させたい案件では、精度以前にここで止まります。

作成したGenAI IndexはAmazon Q BusinessとBedrockナレッジベースのマネージドリトリーバーの双方から参照でき、自社データを使った生成AIアプリケーションの取り込み口になります。機能の詳細はKendra GenAI Indexの機能と既存インデックスとの違いにまとめました。

Bedrock Knowledge Baseへの移行で埋まる差分と移植できない6機能

AWSは移行ガイドをKendraの開発者ガイド内に用意しています。差分を機能単位で見ていきます。

アーキテクチャ対応表｜コネクタ数・埋め込みモデル・検索方式の差分

BMKBはRAGパイプライン全体をマネージドで抱えます。埋め込みモデルは既定でサービス管理のモデルが使われ、モデル選定も次元数の設定も不要です。自前で選ぶ場合はTitan Text Embeddings V2、Cohere Embed English v3、Cohere Embed Multilingual v3、Cohere Embed v4、Amazon Nova Multimodal Embeddingsから指定でき、いずれも1024次元のfloat32で固定になります。画像・音声・動画をそのまま扱うマルチモーダル埋め込みには、TwelveLabs Marengo Embed 3.0が使えます。

比較項目	Amazon Kendra	BMKB
ネイティブコネクタ	32種	10種（カスタム含む）
埋め込みモデル	内部で固定	既定はサービス管理
ベクトルストア	内部で管理	Bedrockが管理
検索方式	意味・語句・混合	混合のみ
応答生成	外部のLLMが必要	API単体で完結
多段検索	なし	Agentic Retrieval
取得上限	100パッセージ	100件

コネクタ数は資料によって食い違います。2026年6月17日のGA告知では6種、移行ガイドの対応表では7種、そしてマネージドナレッジベースの作成手順ではS3・Box・Confluence Cloud・Confluence Data Center・SharePoint Online・Google Drive・OneDrive・ServiceNow・Web Crawler・カスタムの10種が並んでいます。増え続けている途中なので、要件定義の段階では移行ガイドの表ではなく作成手順ページを見てください。

検索方式に選択肢がない点は注意が要ります。BMKBは常にハイブリッド検索で動き、意味検索だけに絞るモードを持ちません。移行後の全体像としては、Knowledge Baseで社内RAGチャットを組んだ構成例が近い形になります。

提供リージョンとGovCloudの機能差｜東京で動く範囲を先に確かめる

マネージドナレッジベースが使えるのは、公式の対応リージョン表によればus-east-1・us-west-2・eu-west-1・eu-west-2・eu-central-1・ap-northeast-1・ap-southeast-2・us-gov-west-1の8つです。東京（ap-northeast-1）が入っているため、Kendra GenAI Indexで越えられなかった国内データの要件はここで解けます。

ただしGovCloud（US-West）だけは機能が削られています。データソースはS3コネクタのみ、文書単位のアクセス制御（aclEnabled）とクエリ時のACLフィルタは使えず、サービス管理の埋め込み・リランキング・エージェンティック検索も提供されません。自前のBedrock埋め込みモデルを渡す前提になります。

リージョン選定はチャンク設計より先に決める項目です。後から東京へ寄せると、取り込みもインデックスも作り直しになります。

API書き換えの実際｜Retrieve系呼び出しとフィルタ構文の対応関係

コードの書き換えは機械的に進められる部分です。kendra.create_indexはbedrock-agent.create_knowledge_baseへ、データソース追加はcreate_data_sourceへ、同期のstart_data_source_sync_jobはstart_ingestion_jobへ対応します。検索のkendra.retrieveに対応するのは、Bedrockのエージェントランタイム側のretrieveです。文書を直接投入するbatch_put_documentだけは対応するAPIがなく、S3へ置いてから取り込みジョブを回す形に組み替えます。

フィルタ演算子はEqualsToがequals、ContainsAnyがinという具合にほぼ1対1で対応しますが、startsWithとstringContainsはマネージドナレッジベースに存在しません。前方一致や部分一致でメタデータを絞っている実装は、完全一致か集合所属の形へスキーマごと組み替える必要があります。メタデータ自体もサイドカーの.metadata.jsonへ移り、1ファイル10KBの上限と、文字列・数値・真偽値の3型という制約が付きます。

移植できない6機能｜ファセット検索・シノニム・スペル訂正の回避策

AWSが移行ガイドで「回避策が要る」と名指ししている機能は6つあります。

クエリサジェスト：GetQuerySuggestions相当のAPIがなく、補完用の索引かLLMによる補完層を前段に挟む
ファセット検索：動的な件数表示は再現できず、メタデータ属性とフィルタで代替する
カスタムシノニム：類義語辞書を前段に置き、クエリ文字列へ同義語を足してから投げる
スペル訂正：Lambdaで前処理し、補正後のクエリをBMKBへ渡す
増分学習：クリックログをDynamoDBへ貯め、再ランクのパラメータ調整に回す
ドキュメント拡張：取り込み前のS3投入パイプラインをStep FunctionsやLambdaで組む

ハイブリッド検索が常時有効なぶん、シノニム展開はクエリ文字列に語を足すだけで語句側と意味側の両方に効きます。ここは移植コストの軽い部類。逆にファセットの動的な件数表示は原理的に再現できないため、検索UIの仕様変更まで含めた判断が要ります。

boto3とCLIによるManaged Knowledge Base作成・S3取り込み手順

ここからは手を動かす工程です。公式ドキュメントに載っているコードを、詰まりやすい順序で並べ直します。

IAMロールの信頼ポリシーと埋め込みモデル呼び出し権限を先に作る

最初に作るのはIAMロールです。信頼ポリシーでbedrock.amazonaws.comにロールの引き受けを許可し、権限ポリシーでS3の読み取りと埋め込みモデルの呼び出しを許します。移行ガイドが載せているPythonは次の形です。

import boto3, 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)
)

サービス管理の埋め込みモデルだけで進めるなら、bedrock:InvokeModelを自分のロールに持たせる必要はありません。自前モデルへ切り替える可能性があるかどうかで、ここの書き方が変わります。

CreateKnowledgeBaseをMANAGED型で叩くときの必須と禁止の引数

ナレッジベースの作成はCreateKnowledgeBaseをtypeにMANAGEDを指定して呼びます。AWS CLIのcreate-knowledge-baseなら設定をJSONファイルに外出しする形が読みやすいでしょう。

aws bedrock-agent create-knowledge-base \
  --name "my-managed-kb" \
  --role-arn "arn:aws:iam::123456789012:role/BedrockKBRole" \
  --description "Migrated from Kendra index" \
  --knowledge-base-configuration file://kb-config.json

# kb-config.json（サービス管理の埋め込みモデルを使う場合）
{
    "type": "MANAGED",
    "managedKnowledgeBaseConfiguration": {
        "embeddingModelType": "MANAGED"
    }
}

引数の組み合わせに一箇所だけ罠があります。embeddingModelTypeを省くとMANAGEDが既定で選ばれますが、MANAGEDのときはembeddingModelArnもembeddingModelConfigurationも指定してはいけません。逆にCUSTOMを選んだ場合は両方とも必須です。移行ガイドのサンプルはembeddingModelArnを直に書いているので、そのまま写すとCUSTOM扱いになります。

もう一点、CUSTOM埋め込みで作ったナレッジベースではマネージドリランカーが使えません。埋め込みモデルの種別は作成後に変更できず、切り替えるにはナレッジベースを作り直す必要があります。

データソース作成からAVAILABLE待ちと取り込みジョブ起動までの順序

ナレッジベースができたらデータソースを作り、ステータスがAVAILABLEになるのを待ってから取り込みジョブを回します。create_data_sourceはマネージドナレッジベースでは非同期で、CREATINGからAVAILABLEまで通常2〜5分。ここを待たずに取り込みへ進むと失敗します。

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

res = bedrock_agent.create_data_source(
    knowledgeBaseId=kb_id,
    name="my-s3-data-source",
    dataSourceConfiguration={
        "type": "MANAGED_KNOWLEDGE_BASE_CONNECTOR",
        "managedKnowledgeBaseConnectorConfiguration": {
            "connectorParameters": {
                "type": "S3",
                "version": "1",
                "connectionConfiguration": {
                    "bucketName": "your-bucket-name",
                    "bucketOwnerAccountId": "123456789012"
                }
            }
        }
    },
    vectorIngestionConfiguration={
        "parsingConfiguration": {"parsingStrategy": "SMART_PARSING"}
    }
)
ds_id = res["dataSource"]["dataSourceId"]

job = bedrock_agent.start_ingestion_job(
    knowledgeBaseId=kb_id, dataSourceId=ds_id, description="Initial ingestion"
)
print(job["ingestionJob"]["ingestionJobId"])

チャンク戦略はKendraから移るときに自分で決める項目です。移行ガイドは固定長200トークン・オーバーラップ30%を出発点として挙げています。コンソールの既定チャンクは約300トークンの固定長で、階層チャンクやチャンクなしも選べますが、マネージドナレッジベースはセマンティックチャンキングには対応していません。文書に章立てがはっきりある場合だけ階層チャンクを試す順序がよいでしょう。

Retrieve呼び出しの書き換えとメタデータフィルタ移植で詰まる箇所

取り込みが終わったら検索側です。Kendraのクライアントコードとの差分を、実際の呼び出し形で並べます。

取得設定の入れ子の変更｜マネージド用の検索設定キーへの移行手順

Kendraのretrieveでは、クエリ文字列がトップレベル引数でした。BMKBではretrievalQuery配下へ移り、件数とフィルタはマネージドナレッジベース専用の検索設定キーの下に入ります。公式のクエリ手順にあるとおり、従来のベクトル検索設定キーはカスタムナレッジベース専用なので、マネージド側で指定すると弾かれます。

# Before（Kendra）
kendra = boto3.client("kendra")
res = kendra.retrieve(
    IndexId="your-kendra-index-id",
    QueryText="How do I configure VPC endpoints?",
    AttributeFilter={"EqualsTo": {"Key": "_category",
                                  "Value": {"StringValue": "networking"}}},
    PageSize=10
)

# After（BMKB）
rt = boto3.client("bedrock-agent-runtime", region_name="ap-northeast-1")
res = rt.retrieve(
    knowledgeBaseId="your-kb-id",
    retrievalQuery={"text": "How do I configure VPC endpoints?"},
    retrievalConfiguration={
        "managedSearchConfiguration": {
            "numberOfResults": 10,
            "filter": {"equals": {"key": "category", "value": "networking"}}
        }
    }
)
for r in res["retrievalResults"]:
    print(r["score"], r["content"]["text"][:80])

戻り値の形も変わります。ResultItemsではなくretrievalResultsで、各要素に関連度スコアが付きます。Kendraの信頼度バケットに依存した閾値ロジックを書いていた場合、スコアの連続値へ読み替える作業が発生する点は見積もりに入れてください。

フィルタ演算子の対応とstartsWith不在で作り直すメタデータ設計

演算子はEqualsToがequals、GreaterThanがgreaterThan、AndAllFiltersがandAllという具合に素直に対応します。NotFilterはnotInかnotEqualsへ、ContainsAllはinで近似する形です。

問題はstartsWithとstringContainsで、マネージドナレッジベースには存在しません。たとえば文書IDの接頭辞で部門を判別していた実装は、接頭辞をそのままメタデータの独立した属性として持ち直す必要があります。ファセットの代替も同じ発想で、部門・作成者・文書種別・日付範囲を.metadata.jsonへ構造化して置き、UI側は既知のスキーマから選択肢を出す形に寄せます。

# ファセットの代替（複数条件のAND）
res = rt.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"}}
            ]}
        }
    }
)

RetrieveAndGenerateで外部LLM呼び出しを1本に畳む書き換え

Kendraでは検索結果を受けてから自分でLLMを呼んでいました。BMKBはRetrieveAndGenerateが検索と生成を一度に返し、引用元も付いてきます。

res = rt.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:ap-northeast-1::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0",
            "retrievalConfiguration": {
                "managedSearchConfiguration": {"numberOfResults": 5}
            }
        }
    }
)
print(res["output"]["text"])
for c in res.get("citations", []):
    for ref in c.get("retrievedReferences", []):
        print(ref["location"]["s3Location"]["uri"])

切り替え前にKendraとBMKBを並走させ、同じクエリを両方へ投げて上位10件の重なりを数えるのが確実です。関連度はNDCGやMRR、応答時間はp50・p95・p99、網羅性は期待文書の再現率という4軸で見ます。評価セットの作り方はRAG評価の指標と手順にまとめました。ベクトル保存まで自前で持つ構成を比べたい場合はAmazon S3 Vectors APIも選択肢に入ります。

AWSでエンタープライズ検索を新規に組む場合の採用判断と見送り条件

ここから先は判断です。条件を切って言い切ります。

BMKBで足りる条件｜S3中心・標準コネクタ・RAG用途に収まる案件

新規案件でKendraを選べない以上、実際の分岐は「BMKBで足りるか、自前のベクトル基盤を組むか」に移ります。BMKBで足りるのは、次の3条件が揃うときです。文書の供給元がS3か、Box・Confluence・SharePoint・Google Drive・OneDrive・ServiceNow・Web Crawlerの範囲に収まること。ファセットやサジェストを検索UIで要求されないこと。そして東京リージョンで要件が満たせること。

この3条件を満たすなら、迷わずBMKBを選んでください。ベクトルストアの運用が消え、応答生成まで1つのAPIで済みます。チャンク設定は移行ガイドが挙げる固定長200トークン・オーバーラップ30%から始めれば大きく外しません。

要件定義の段階で検索精度の目標値と評価データを揃えておくと、後戻りが減ります。設計から実装まで任せたい場合は生成AI開発・AI受託開発でご相談ください。RAGの仕組みそのものを先に押さえたい方はRAGとは何かからどうぞ。

Kendraを継続する既存顧客の条件｜32コネクタとファセットへの依存度

既存顧客が急いで移行すべきか。判断軸は依存度ひとつです。

移行を急がなくてよいのは、Kendra独自の32種コネクタで直接繋いでいるデータソースが多く、かつファセット検索やクエリサジェストを検索UIの中核に据えている構成。BMKBへ移すと、コネクタごとにS3への書き出しパイプラインを自作し、UIの仕様も変える二重の工事になります。バグ修正とセキュリティ更新は続くのですから、当面はKendraに置いたままでかまいません。

逆に、S3の文書だけをインデックスしてRetrieve APIで引いている構成なら、今すぐ移して差し支えありません。書き換え箇所はクライアント名とパラメータ構造だけ。応答生成を外部のLLM呼び出しで自作していた部分は、RetrieveAndGenerateへ寄せるとコードがむしろ減ります。

採用を見送る3つの場面｜東京リージョン必須・小規模文書・説明責任

第一に、データを国内リージョンから出せない案件で、GenAI Indexを前提に設計すること。提供は2リージョンで東京は含まれず、英語コンテンツのみという制限も重なるため要件を満たせません。既存顧客であってもここは変わらないため、Basic系での構成か、BMKBの東京リージョンを取ります。

第二に、文書が数百件規模で更新も稀なケース。インデックスを1本立てただけで月400 USDを超える固定費が走る以上、この規模ではPostgreSQLの全文検索やマネージドな検索エンジンで足ります。料金構造と構築手順はAWSのマネージド検索エンジンサービスの料金と運用にまとめました。

第三に、検索結果の順位について説明責任を負う領域。意味検索のランキング根拠は内部に隠れており、なぜこの文書が1位なのかを条文レベルで説明する要件は満たせません。ここはルールベースのスコアリングを併用するか、順位計算を自前で持つ設計へ切り替えるべき場面です。

よくある質問

Amazon Kendraの検討時に実際に検索されている質問へ、2026年9月18日時点の公開情報をもとに答えます。

Amazon Kendraは今から新規に契約できますか？

できません。AWSは2026年7月30日からAmazon Kendraが新規顧客の受付を停止すると告知しており、この日以降に初めて使い始める道は閉じています。すでにインデックスを保有しているアカウントであれば、引き続き利用もスケールも可能です。新規に社内検索やRAGの基盤を組むなら、AWSが移行先として案内しているAmazon Bedrock Managed Knowledge Baseを検討してください。

Amazon Kendraの料金は最低いくらから発生しますか？

GenAI Enterprise Editionを1本立て、ストレージとクエリを各1ユニットで運用すると毎時0.64 USD、30日換算でおよそ461 USDが下限になります。Basic Enterprise Editionなら基本1.4 USDに各ユニット0.7 USDが乗り、同条件で月2,000 USDを超えるでしょう。インデックスは作成から削除まで課金が続き、空でもクエリゼロでも止まりません。コネクタを使うGenAI Enterprise Editionでは、さらに月30 USDの定額（月500時間までの同期を含む）が加算されます。

Amazon Kendraは東京リージョンで使えますか？

精度の高いGenAI Enterprise Editionのインデックスは、2026年9月18日時点の公式ドキュメントではUS East（バージニア北部）とUS West（オレゴン）の2リージョン限定です。国内にデータを留める要件があるとGenAI Indexは選べません。Basic系インデックスの提供リージョンはAWS一般リファレンスのエンドポイント一覧で確認してください。移行先のBedrock Managed Knowledge Baseはap-northeast-1を含む8リージョンに対応しており、この制約は解消されます。

日本語の社内文書をKendra GenAI Indexで検索できますか？

できません。GenAI Enterprise Editionインデックスの制限として、英語コンテンツのみをサポートすると公式ドキュメントに明記されています。日本語の規程や議事録を対象にするなら、既存顧客であってもBasic Enterprise Editionを使うか、移行先のBMKBで組むことが必要です。GenAI Indexにはほかにも、v2.0コネクタのみ対応、トークンベースおよびユーザーIDとグループに基づくアクセス制御が非対応という制限が付きます。

BMKBのコネクタはKendraの代わりとして足りますか？

供給元によります。マネージドナレッジベースの作成手順に並ぶのはS3・Box・Confluence Cloud・Confluence Data Center・SharePoint Online・Google Drive・OneDrive・ServiceNow・Web Crawler・カスタムの10種で、Kendraの32種には届きません。この範囲外のシステムは、APIで中身を吸い出してメタデータJSONとともにS3へ書き、取り込みジョブを起動するパイプラインを自作する形になります。移行ガイドの対応表は7種のままなので、件数は作成手順ページ側で確かめてください。

KendraからBedrock Managed Knowledge Baseへの移行はどこから手を付けますか？

IAMロールの作成からです。Bedrockのサービスプリンシパルがロールを引き受けられる信頼ポリシーと、S3読み取りおよび埋め込みモデル呼び出しの権限を付けたうえで、create_knowledge_baseをMANAGED型で実行します。次にデータソースを作り、ステータスがAVAILABLEになってから取り込みジョブを起動する順序。データソース作成は非同期で、AVAILABLEまで通常2〜5分かかります。切り替え前にKendraとBMKBを並走させ、同じクエリでNDCGやMRRを比較しておくと判断がぶれません。

Kendra GenAI IndexとBMKBのマネージドナレッジベースはどちらを選ぶべきですか？

新規に組むならBMKB一択です。GenAI Indexを新たに作るにはKendraの既存顧客である必要があり、そのうえリージョンも2つ、対応言語も英語に限られます。既存顧客がGenAI IndexをBedrockナレッジベースの取り込み口として使っている構成は、当面そのままで支障ありません。ただしKendra側に新機能が載らない前提で、コネクタ依存の棚卸しだけは先に済ませておくと、後の移行判断が速くなります。