Amazon Kendraとは？新規受付終了と移行先の判断【2026年版】

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

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

結論から。2026年7月30日以降に新しくKendraを契約する道はありません。すでにインデックスを持つアカウントだけが引き続き使えます。

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

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

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

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

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

AWSは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を2026年6月30日付でメンテナンスモードに置くと告知しました。この日以降、サービスの新機能や新しい能力の開発は行われません。

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

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

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

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

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

サービス終了の期日は現時点で公表されていない、という点も押さえておく必要があります。無期限の保証ではなく、移行計画を立てる猶予が与えられている状態と読むのが妥当でしょう。

新規案件から外れた影響｜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の利用を推奨してきました。

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

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

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

見落としやすいのがコネクタです。GenAI Enterprise Editionの場合、インデックスあたり月額30 USDの固定料金に加え、同期の実行中は1時間あたり0.35 USD、スキャンした文書100万件あたり1 USDが加算されます。

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

試算してみます。GenAI Enterprise Editionを1本、ストレージとクエリを各1ユニットで30日回すと、基本0.32にストレージ0.25とクエリ0.07を足して毎時0.64 USD、月およそ461 USD。ここへコネクタの30 USDと同期時間分が乗る計算になります。

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

GenAI Enterprise Editionのインデックスが使えるのは、バージニア北部・オレゴン・アイルランド・シドニーの4リージョンだけです。2024年12月の発表から2025年4月のアイルランドとシドニー追加を経て、東京リージョンには来ませんでした。国内にデータを置く要件のある案件では、この時点で候補から外れます。

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

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

AWSは移行ガイドを公式ドキュメント内に用意しています。差分を機能単位で見ていきます。

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

BMKBはRAGパイプライン全体をマネージドで抱えます。埋め込みモデルはTitan Text Embeddings V2、Cohere Embed English v3、Cohere Embed Multilingual v3、Cohere Embed v4、Amazon Nova Multimodal Embeddingsから選択でき、いずれも1024次元のfloat32で固定です。

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

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

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

呼び出し側の差分は3点。クエリ文字列がトップレベル引数からretrievalQuery配下へ移り、AttributeFilterが取得設定内のfilterへ変わり、結果に関連度スコアが付きます。

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

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

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

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

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

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

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

BMKBで足りる条件｜S3中心・6コネクタ・RAG用途に収まる案件の輪郭

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

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

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

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

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

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

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

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

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

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

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

よくある質問

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

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を超えるでしょう。インデックスは作成から削除まで課金が続き、空でもクエリゼロでも止まりません。コネクタを使う場合はさらに月30 USDの固定費と同期時間分が加算されます。

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

精度の高いGenAI Enterprise Editionのインデックスは、バージニア北部・オレゴン・アイルランド・シドニーの4リージョン限定です。国内にデータを留める要件があるとGenAI Indexは選べません。Basic系インデックスの提供リージョンはAWS公式のエンドポイントと制限の一覧で確認してください。移行先のBedrock Managed Knowledge Baseは2026年6月17日のGA時点で東京リージョンに対応しており、この制約は解消されます。

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の既存顧客である必要があり、そのうえリージョンも4つに限られます。既存顧客がGenAI IndexをBedrock knowledge basesの取り込み口として使っている構成は、当面そのままで支障ありません。ただしKendra側に新機能が載らない前提で、コネクタ依存の棚卸しだけは先に済ませておくと、後の移行判断が速くなります。

関連記事

• Amazon Kendra GenAI Indexの新機能と主要ポイント：GenAI Indexの機能面を掘り下げて扱いました
• BedrockとKendraを使ったRAGの実装方法：移行前の構成をコード付きで確認できます
• AWS検索サービスの選び方：Kendraを含む4つの選択肢を横並びで比べています
• RAGとは：検索と生成を組み合わせる仕組みの前提知識です
• Amazon S3 Vectors APIとは：ベクトル保存を自前で持つ場合の選択肢になります