ひとことで言うと
索引の中身を一切見せない、企業内文書向けのマネージド検索です。埋め込みモデルもチャンクサイズもベクトルストアも選べません。その代わり、多数のデータソースコネクタと、ユーザーの権限に応じた結果のフィルタリングが最初から付いています。
要するに、社内の資料室に司書を1人雇う契約です。資料の並べ方も検索の仕組みも司書が決めるので、こちらは指定できません。頼めるのは「この棚（SharePoint、S3、Confluence…）も見ておいて」と、「この人には見せていい資料だけ出して」の2つです。
この2つ目が Kendra の本体です。ベクトルストアを自分で組む構成では、権限ごとの出し分けは自分で書く仕事になります。
なぜ生まれたか
企業内検索の難所は、検索の精度そのものより接続と権限です。文書は SharePoint・S3・Confluence・データベースに散らばっていて、しかも誰が何を見てよいかが元のシステム側に定義されています。単純に全部を1つの索引に流し込むと、権限の壁を越えた検索結果が出てしまいます。Kendra はここを引き受ける形で作られました——コネクタが同期を担い、ユーザーコンテキストのフィルタが出し分けを担います。
一方で、生成AIの側が Kendra の設計を追い越しました。索引の中身を選べないことが、RAG では制約になります。埋め込みモデルもチャンク戦略も選べず、回答生成は別に組む必要があります。AWS は Kendra をメンテナンスモードに移し、Amazon Bedrock Managed Knowledge Base への移行を推奨する立場を取りました。
| 時期 | 何が起きたか |
|---|---|
| 2026-06-30 | メンテナンスモード開始。 以降、新機能・新規能力の開発は行われません（既存顧客向けのバグ修正とセキュリティ更新は継続） |
| 2026-07-30 | 新規顧客への提供を終了。 公式の推奨は「Kendra アプリケーションの移行と、新規の検索アプリケーションは Amazon Bedrock Managed Knowledge Base で実装すること」 |
何に使うか
| 用途 | 使い方 | 関連する試験ドメイン |
|---|---|---|
| RAG のリトリーバー | Retrieve API。最大 200トークンワードの長さのパッセージを、最大100件まで返す | D1 |
| 企業内検索アプリ | Query API。抽出型の質問応答・ファセット・ソート・ブール検索・ワイルドカード・スペルチェック・クエリサジェスト | D2 |
| 権限に応じた出し分け | ユーザーコンテキストフィルタ（トークンベースのアクセス制御／ユーザーID・グループベース） | D1 / D2 |
| Bedrock / Q Business からの再利用 | GenAI Enterprise Edition 索引を、Bedrock Knowledge Bases のマネージドリトリーバーとして、あるいは Amazon Q Business から使う | D1 / D2 |
| 他の検索エンジンの結果の並べ替え | Amazon Kendra Intelligent Ranking（セマンティック検索の能力だけを借りて、他サービスの検索結果を再ランクする） | D1 |
| チャットボットの検索バックエンド | Amazon Lex の AMAZON.KendraSearchIntent | D2 |
試験でどう問われるか
Kendra は「自前でベクトル検索を組むか、マネージド検索に預けるか」の分岐に出ます。そして 2026年のメンテナンスモード入り以降、新規設計のシナリオで Kendra が正解になる場面はほぼ無くなりました。したがって出題の重心は、「Kendra を選ばせる引っかけ」を見抜くことと、既存 Kendra からの移行で何が失われるかに移ります。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| 新規の RAG／検索アプリを設計する | Bedrock Managed Knowledge Base（公式の移行推奨先）。マネージド RAG・組み込みコネクタ・スマートパース・ハイブリッド検索・RetrieveAndGenerate・エージェンティックリトリーバルまで含みます | Kendra。「多様な社内リポジトリを横断検索したい」と書かれると選びたくなりますが、新規顧客には提供されていません |
| 既存 Kendra からの移行で、何が素直に移らないか | クエリサジェスト（オートコンプリート）・ファセット検索・カスタムシノニム・スペルチェック・インクリメンタルラーニング・カスタムドキュメントエンリッチメント。いずれも回避策が要ります | 「そのまま移行できる」と書いた選択肢 |
| コネクタが足りない | Kendra は 32のネイティブコネクタ、Bedrock Managed KB は 7（S3 / Confluence / SharePoint / Web Crawler / Google Drive / OneDrive / カスタム）。未対応のソースは S3 へエクスポートして取り込むのが推奨パターン | 「コネクタが無いので移行できない」 |
| RAG に使うなら Query か Retrieve か | Retrieve。Query の抜粋は既定で100トークンワードまで、Retrieve は200トークンワードのパッセージを最大100件。LLM に渡す文脈としては後者 | Query API を RAG のリトリーバーに使う |
Retrieve にしたら機能が消えた | Retrieve は高度なクエリ構文・スペル修正・ファセット・クエリサジェスト・インクリメンタルラーニングに非対応。分析ダッシュボードにも出ません | 「Retrieve は Query の上位互換」 |
| どの索引タイプか | RAG／Retrieve の精度が要件 → GenAI Enterprise Edition（ハイブリッド検索・セマンティック埋め込み・リランカーモデル）。PoC 用途 → Developer Edition（本番非推奨） | 本番ワークロードに Developer Edition（キャパシティを追加できません。追加できるのは Enterprise Edition だけ） |
| 文書レベルのアクセス制御が要件 | GenAI Enterprise Edition 索引は、トークンベースのユーザーアクセス制御も、ユーザーID・グループベースのアクセス制御もサポートしません（CreateAccessControlConfiguration API も無効）。使えるのはユーザー属性による絞り込みだけです | 「最も精度が高いので GenAI 索引を選ぶ」——精度要件だけ見て選ぶと、権限要件で破綻します |
| GenAI 索引のリージョン・言語 | 米国東部（バージニア北部）と米国西部（オレゴン）のみ、英語コンテンツのみ、v2.0 コネクタのみ対応 | 「東京リージョンで日本語の社内文書に使う」 |
| 既存の検索基盤（OpenSearch 等）の関連度だけ上げたい | Amazon Kendra Intelligent Ranking。索引を置き換えず、他の検索サービスの結果をセマンティックに再ランクします | Kendra 索引を新たに作って全文書を再取り込みする |
| 課金の効き方 | プロビジョンされた索引に対して課金されます。空でクエリが1本も来ていなくても発生します（無償利用枠の期間を過ぎた後） | 「使った分だけなので PoC を放置してよい」 |
この試験で Kendra の名前が選択肢に出たら、まず「新規か既存か」を読み直してください。「これから作る」シナリオでの正解は原則 Bedrock Managed Knowledge Base 側です。一方で Kendra が今も正解になる残り2つの場面があります——①すでに Kendra 索引を持っている顧客の話（GenAI Enterprise Edition 索引は Bedrock Knowledge Bases や Q Business から再構築せずに使い回せます）と、②Intelligent Ranking（他の検索エンジンの結果を再ランクするだけで、Kendra を索引として使わない構成）です。
実務でどう使うか
RetrieveはQueryとキャパシティユニットを共有します。 別枠ではないので、RAG のトラフィックを足すと検索アプリ側のスループットを食います。Developer Edition ではキャパシティを追加できませんRetrieveの結果は分析ダッシュボードに出ません。 「RAG の検索がどう当たっているか」を Kendra のコンソールから見る運用は成立しないので、ログと評価は自分で持つ必要があります- 信頼度スコアバケットは英語のみです。 日本語コンテンツで「信頼度で足切りする」設計を置くと、当てにできる材料がありません
- 移行時のチャンク戦略は自分で選ぶことになります。 Kendra はチャンクを内部で処理しますが、移行先では明示的に決めます。公式が移行の出発点として挙げているのは**固定長200トークン・オーバーラップ30%**です
- メタデータの持ち方が変わります。 Kendra は索引レベルで属性を定義しますが、移行先では S3 に
.metadata.jsonのサイドカーファイルを置く形になり、1ファイルあたり最大10KB、型は STRING / NUMBER / BOOLEAN です startsWith/stringContainsに相当するフィルタは移行先にありません。 ワイルドカードや部分一致でフィルタしている Kendra アプリは、メタデータスキーマ自体を完全一致・集合所属の形に組み直す必要があります- 並行稼働で比べてから切り替えます。 公式が挙げる比較軸は、関連度（ゴールデンテストセットに対する NDCG / MRR）・レイテンシ（p50 / p95 / p99）・スループット・網羅率です
メンテナンスモードは「明日止まる」という意味ではありません。公式は、既存顧客に対してバグ修正とセキュリティ更新は継続すると明記しています。止まるのは新機能の開発と、新規顧客の受け入れです。したがって実務上の判断は「今すぐ剥がす」ではなく「新しく載せない」——既存の Kendra アプリを慌てて壊す理由にはなりませんが、次の要件を Kendra の上に積むのはやめる、という線引きになります。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Amazon Bedrock Knowledge Bases | Kendra は索引の中身を隠す。KB は埋め込みモデル・チャンク戦略・ベクトルストアを選ばせる。しかも KB には RetrieveAndGenerate があり、Kendra には回答生成が無い（外部 LLM が要る） |
| Amazon OpenSearch Service | OpenSearch はインデックス設計を全部自分で握る。Kendra は何も握らない代わりにコネクタと権限フィルタが付く。この2つは「マネージドの度合い」の両端 |
| Amazon Q Business | Q Business はエンドユーザーが使うアシスタントそのもの。Kendra は検索の部品。Kendra GenAI 索引を Q Business から使う構成もあるので、包含関係で覚える |
| Kendra Intelligent Ranking | Kendra 索引を作る話ではありません。他の検索サービスの結果を再ランクする別の使い方です。「索引は既存のものを使いたい」の答えになります |
Query API と Retrieve API | Query は検索アプリ向け（抜粋・FAQ・ファセット・サジェスト）。Retrieve はRAG 向け（長いパッセージを大量に）。機能は Retrieve のほうが少ない |
| GenAI Enterprise / Enterprise / Developer | 精度は GenAI が最上位ですが、アクセス制御は GenAI が最も制限的。Developer は本番非推奨でキャパシティ追加も不可 |
想起チェック
Q1. 「複数の社内リポジトリを横断検索する仕組みを新規に作る」。Kendra が正解にならない理由を1文で言えますか。
2026年7月30日以降、新規顧客に提供されていないためです（同年6月30日にメンテナンスモード入り）。公式の推奨先は Amazon Bedrock Managed Knowledge Base です。
Q2. それでも Kendra が正解になりうる2つの場面は？
①既に Kendra 索引を持っている場合（GenAI Enterprise Edition 索引は Bedrock Knowledge Bases や Q Business から再構築なしで使えます）、②Intelligent Ranking で他の検索サービスの結果を再ランクする構成です。
Q3. 「最高精度が要るので GenAI Enterprise Edition 索引を選ぶ」。どんな要件が併記されていたら、この判断は破綻しますか。
文書レベルのアクセス制御です。GenAI 索引はトークンベースのアクセス制御もユーザーID・グループベースのアクセス制御もサポートせず、使えるのはユーザー属性による絞り込みだけです。リージョン（米国2つのみ）と言語（英語のみ）も同様の落とし穴です。
Q4. RAG のリトリーバーに `Retrieve` を選びました。代わりに失うものを3つ挙げられますか。
ファセット・クエリサジェスト・スペル修正（ほかに高度なクエリ構文とインクリメンタルラーニング）です。加えて Retrieve のクエリは分析ダッシュボードに現れません。
Q5. Kendra から移行するとき、メタデータのフィルタで最初に組み直しが必要になるのはどんな条件ですか。
ワイルドカードや部分一致でフィルタしている場合です。移行先には startsWith / stringContains に相当する演算子が無いため、完全一致か集合所属で表せるスキーマに作り替えます。