Amazon Kendra GenAI Indexとは？料金・制約とBedrock連携の採用判断

Amazon Kendra GenAI Indexは、正式名称を「Amazon Kendra GenAI Enterprise Edition index」というインデックス種別です。2024年12月4日に発表され、ハイブリッド検索と再ランカーモデルを内蔵してRAGの検索工程の精度を引き上げる目的で設計されました。ただし2026年8月時点の前提が2024年当時とは変わっています。Amazon Kendraは2026年6月30日にメンテナンスモードへ移り、2026年7月30日から新規のお客様の受付を終了しました。この記事では、GenAI Indexの単価と容量、東京リージョン非対応と英語コンテンツ限定という制約、Amazon Bedrockナレッジベースへの接続実装を一次情報で整理し、いま採用できるのかまでを判断材料として示します。

まとめ｜GenAI Indexを選べる条件と既存インデックスの扱い

結論から示すと、これからAmazon Kendraを使い始める立場ではGenAI Indexを選べません。2026年7月30日以降、Kendraは新規のお客様に開かれていないためです。すでにKendraを使っている場合はGenAI Indexを引き続き利用できますが、メンテナンスモード下では新機能が追加されないため、現在の制約がそのまま将来の制約になります。

その制約のうち日本企業に効くのは2つです。GenAI Indexは東京リージョンで提供されておらず、扱えるのは英語コンテンツに限られます。つまり日本語の社内文書を横断検索する用途には、そもそも設計上あてはまりません。英語ドキュメントを対象とした既存のRAG基盤を運用中で、Retrieve APIの精度と$0.32/時という単価が要件に合っているなら維持する価値はあります。それ以外の場合、AWSが移行先として案内しているAmazon Bedrock Managed Knowledge Baseが第一候補です。Kendraというサービス全体の受付終了と移行先の選び方はAmazon Kendraの新規受付終了と移行先の判断にまとめてあります。

Amazon Kendra GenAI Indexの正体｜Retrieve API向けに最適化されたインデックス種別

GenAI Indexは独立したサービスではなく、Amazon Kendraのインデックスを作るときに選ぶ3種類のエディションのひとつです。AWS SDKでも独立したAPIは用意されておらず、KendraのCreateIndexを呼ぶ際にEditionへGEN_AI_ENTERPRISE_EDITIONを渡して作成します。boto3 1.42.97でサービスモデルを確認すると、このEditionが取り得る値はDEVELOPER_EDITION・ENTERPRISE_EDITION・GEN_AI_ENTERPRISE_EDITIONの3つでした。

import boto3

kendra = boto3.client("kendra", region_name="us-east-1")

resp = kendra.create_index(
    Name="genai-index",
    Edition="GEN_AI_ENTERPRISE_EDITION",
    RoleArn="arn:aws:iam::123456789012:role/KendraIndexRole",
)
print(resp["Id"])

精度面の中身について、AWSの開発者ガイドはハイブリッド検索（キーワードとベクトル）、セマンティック埋め込み、再ランカーモデルによって構成されると記述しています。見落とされやすいのは、精度の優位が出る範囲です。開発者ガイドは「Retrieve APIとRAGユースケースで最高の精度を提供する」と書く一方、「Query APIの精度はDeveloper EditionおよびEnterprise Editionと比較して同等」とも明記しています。GenAI Indexに変えれば全文検索の体感精度が上がる、という理解は誤りで、効くのはRAGの検索工程です。検索工程そのものの設計はRAGにおけるリトリーバルの仕組みと精度改善の判断基準で扱っています。

もうひとつの設計上の特徴が、インデックスした資産を作り直さずにAWSの生成AIサービス間で使い回せる点です。Amazon Bedrockのナレッジベースにマネージドリトリーバーとして登録でき、エージェントやプロンプトフローと組み合わせられます。Amazon Q Businessから参照することもできます。開発者ガイドと料金ページはいずれも、Kendraでインデックスを作るならGenAI Enterprise Editionを推奨する注記を置いています。

インデックス3種の単価と容量の比較

GenAI Indexは他の2エディションより容量単位が細かく、開始価格が低く設定されています。

数字を読むときの注意点は、含まれる文書量が「件数か抽出テキスト量のいずれか先に到達したほう」で頭打ちになることです。GenAI Indexの1ユニットは20,000件または200MBですが、料金ページは500語1ページが約2KBの抽出テキストに相当すると説明しています。この目安で計算すると200MBはおよそ10万ページ分にあたるため、1文書あたり5ページを超えない構成なら件数の上限に先に当たります。抽出テキスト量は元ファイルのサイズと無関係で、10MBのPowerPointでも抽出テキストが5KB未満になることがある、という注記も公式に置かれています。

GenAI Indexの利用条件｜リージョン・言語・アクセス制御の3つの制限

GenAI Indexは単価が低い代わりに、使える条件が他の2エディションより狭く切られています。採用可否はここで決まります。

提供リージョン｜2025年4月に4リージョンへ拡張・東京は対象外

GenAI Indexを作成できるのは、米国東部（バージニア北部）、米国西部（オレゴン）、欧州（アイルランド）、アジアパシフィック（シドニー）の4リージョンです。発表当初は米国の2リージョンのみでしたが、2025年4月3日にアイルランドとシドニーが追加されました。東京リージョン（ap-northeast-1）と大阪リージョンは対象外のままです。国内にデータを置く要件があるなら、この一点で選択肢から外れます。

この点はドキュメントを読む順序で結論が変わるので注意してください。クォータのページに置かれた注意書きは上記の4リージョンを正しく列挙していますが、インデックス種別を解説するページの制限事項は「米国東部（バージニア北部）と米国西部（オレゴン）でのみ利用可能」という2024年12月時点の記述のままで、2025年4月の拡張に追随していません。アイルランドやシドニーでの構築を検討する際に、この制限事項だけを読んで「使えない」と判断すると誤ります。

英語コンテンツ限定｜他エディションとの言語対応差

開発者ガイドは、GenAI Indexが対応する言語を英語コンテンツのみと明記しています。他の2エディションにこの制限はありません。Kendraのインデックスは既定の英語に加えて34言語のドキュメントを扱え、そのうち中国語・フランス語・ドイツ語・日本語・韓国語・ポルトガル語（ブラジル）・スペイン語の7言語は、キーワード一致にとどまらないセマンティック検索まで対応します。つまり日本語文書の検索精度という点では、Developer EditionやEnterprise Editionのほうが素直に要件を満たします。日本語のマニュアルや議事録、Confluenceの社内Wikiを対象にした検索基盤を作る目的であれば、GenAI Indexは検討対象から外れます。

アクセス制御とコネクタで除外される機能

GenAI Indexで使えなくなる機能のうち、影響が大きいのはアクセス制御まわりです。開発者ガイドが挙げている除外項目は次のとおりです。

• トークンベースのユーザーアクセス制御に非対応
• ユーザーIDおよびグループベースのユーザーアクセス制御に非対応
• CreateAccessControlConfiguration APIが無効
• ユーザーコンテキストによる絞り込みはユーザー属性のみで実施
• データソースコネクタはv2.0のみ対応

社内文書検索では「閲覧権限のある文書だけを返す」ことが要件になりますが、GenAI Indexではその実装手段がユーザー属性による絞り込みに限定されます。既存のIdP連携をトークンで持ち込む設計は成立しません。コネクタについては、2024年12月の発表がGenAI Indexは43のデータソースのコネクタに対応すると案内しており、そのいずれもがv2.0世代に限られます。v1.0世代のコネクタで組んだ既存インデックスを持っている場合、同じ構成のままGenAI Indexへ載せ替えられるとは限らないので、移設前にコネクタの世代を確認してください。Amazon Q Businessと組み合わせる場合は、Q Businessがメールアドレスで文書の閲覧可否を判定する仕様のため、メールアドレスによる絞り込みを使わないデータソースでは公開文書からしか回答が生成されなくなります。

料金の内訳と月額の実額試算

Kendraの課金はクエリ数ではなくインデックスの存在時間に対して発生します。インデックスを作成した時点から削除するまで、検索を一度も実行しなくても課金が続く構造です。GenAI Indexの基本インデックスは$0.32/時なので、30日間動かすと$0.32×720時間で$230.4/月です。これは料金ページの計算例1（15,000件の文書、1日7,000検索、コネクタ不使用）と同額で、基本インデックスの範囲に収まる限りこの金額が下限になります。

規模が大きくなると容量ユニットの追加分が効いてきます。料金ページの計算例2は、200,000件の文書と1日25,000検索（約0.28 QPS）の構成で、基本インデックス$230.4、ストレージユニット9個で$1,620、クエリユニット2個で$100.8、コネクタ$30を足して合計$1,981.2/月と示しています。ストレージ側が費用の8割を占めており、GenAI Indexで見積もりを外すとしたら文書量の見積もりです。

見落としやすいのがコネクタの課金方式です。GenAI Indexのコネクタはインデックスあたり月$30の定額で、月500時間までの同期使用量が含まれます。料金ページは「コネクタを設定していた暦月ごとに課金され、その月に何時間稼働したかにかかわらず日割りされない」と明記しています。月末にコネクタを1本追加しただけでもその月は$30が発生するため、検証環境を短期間だけ立てる使い方とは相性がよくありません。無料利用枠はGenAI Enterprise EditionとBasic Developer Editionが対象で、最初の30日間に最大750時間ぶんが使えますが、コネクタの使用は対象外です。

容量を追加する際の上限はクォータで決まっています。ストレージ容量ユニットは1インデックスあたり50、クエリ容量ユニットは100、データソースコネクタは50、コネクタの同期時間は月500時間、インデックス数はアカウントあたり10が既定値で、いずれも引き上げ申請ができます。ただしGenAI Indexのクォータは、Service Quotasコンソールに表示されないとAWSが注記しています。引き上げ手順の案内は公式内で一本化されておらず、料金ページはコネクタの同期時間についてはService Quotas経由で申請するよう書いています。

Bedrockナレッジベースへの接続｜マネージドリトリーバーとしての実装

GenAI Indexを作る目的の多くは、Amazon Bedrockのナレッジベースから検索先として参照することです。

ナレッジベース登録のAPIとコンソールとの差

ナレッジベースの作成はbedrock-agentクライアントのcreate_knowledge_baseで行います。boto3 1.42.97で確認すると、knowledgeBaseConfigurationのtypeが取り得る値はVECTOR・KENDRA・SQLで、GenAI Indexを使う場合はKENDRAを指定し、kendraKnowledgeBaseConfigurationにインデックスのARNを渡します。

import boto3

bedrock_agent = boto3.client("bedrock-agent", region_name="us-east-1")

resp = bedrock_agent.create_knowledge_base(
    name="kendra-genai-kb",
    roleArn="arn:aws:iam::123456789012:role/BedrockKBRole",
    knowledgeBaseConfiguration={
        "type": "KENDRA",
        "kendraKnowledgeBaseConfiguration": {
            "kendraIndexArn": "arn:aws:kendra:us-east-1:123456789012:index/12345678-1234-1234-1234-123456789012"
        },
    },
)
print(resp["knowledgeBase"]["knowledgeBaseId"])

ここで埋め込みモデルのARNを指定していないのは書き漏らしではありません。サービスモデル上、embeddingModelArnはvectorKnowledgeBaseConfigurationの配下にしか存在せず、KENDRA型の設定には項目自体がないためです。埋め込みはKendra側が内部で持つので、Bedrock側でモデルを選ぶ必要も、ベクトルストアとしてAmazon OpenSearch ServiceやAuroraを用意する必要もありません。注意したいのは、AWS公式の作成手順ページのAPIタブに「knowledgeBaseConfigurationオブジェクトのembeddingModelArnフィールドにベクトル埋め込みモデルのARNを指定する」という説明が残っている点です。これはVECTOR型向けの定型文で、KENDRA型に同じキーを渡すとParamValidationError: Unknown parameter ... must be one of: kendraIndexArnで弾かれます。

APIとコンソールで挙動が違う点が3つあります。1つ目は、APIではあらかじめ作成済みのGenAI Indexが必要で、ナレッジベースの作成と同時にインデックスを作ることはできません。同時作成をしたい場合はコンソールを使います。2つ目は、ルートユーザーではナレッジベースを作成できず、IAMユーザーでのログインが必要です。3つ目は、データソースの追加をBedrockのAPIから実行できないことで、コンソールかKendraのCreateDataSource APIを使います。なおAWSは、GenAI Indexでナレッジベースを構築する章の冒頭に、検索精度とマネージド性の観点からAmazon Bedrock Managed Knowledge Baseを推奨する注記を置いています。

Retrieveの応答に追加されるKendra由来のフィールド

検索の呼び出し自体は通常のナレッジベースと同じで、bedrock-agent-runtimeのretrieveにknowledgeBaseIdとretrievalQueryを渡します。応答の基本構造も標準のナレッジベースと同一で、各結果はcontentを必ず持ち、location・metadata・scoreは返る場合に含まれます。

import boto3

runtime = boto3.client("bedrock-agent-runtime", region_name="us-east-1")

resp = runtime.retrieve(
    knowledgeBaseId="ABCDEFGHIJ",
    retrievalQuery={"text": "VPC endpoint configuration steps"},
)

for item in resp["retrievalResults"]:
    meta = item.get("metadata", {})
    print(meta.get("x-amz-kendra-document-title"))
    print(meta.get("x-amz-kendra-score-confidence"))
    print(item["content"]["text"][:200])

標準のナレッジベースとの違いは、Kendra由来の追加項目がメタデータのキーとして混ざることです。公式が挙げているのはx-amz-kendra-document-title、x-amz-kendra-score-confidence、x-amz-kendra-passage-id、x-amz-kendra-document-idと、Kendraのドキュメント属性であるDocumentAttributesの5項目です。x-amz-kendra-score-confidenceはKendraの信頼度バケットで、値はVERY_HIGH・HIGH・MEDIUM・LOW・NOT_AVAILABLEのいずれかを取ります。生成の前に低信頼の断片を落とす閾値処理を入れるなら、この値が判断材料になります。DocumentAttributesはメタデータのキーと値の組として格納され、Bedrock側のメタデータフィルタで絞り込みに使えます。ただしKendraの応答にこれらの項目が含まれない場合はBedrock側の結果にも現れません。上のコード例でitem["metadata"]ではなくitem.get("metadata", {})を使っているのはこのためです。

新規実装でGenAI Indexを見送るべき条件

メンテナンスモードで固定される制約

2026年6月30日のメンテナンスモード移行によって、Kendraでは新機能や新しい能力の開発が行われなくなりました。既存のお客様に対してバグ修正とセキュリティ更新は継続されますが、新機能の要望は検討対象から外れるとAWSは明言しています。告知の全文と移行先の比較はKendraの新規受付終了と移行先の判断で扱っているため、ここではGenAI Indexへの帰結だけを押さえます。

帰結は単純です。東京リージョンへの展開も日本語コンテンツへの対応も、GenAI Indexでは今後実現しないという前提で設計しなければなりません。2025年4月にアイルランドとシドニーが追加された実績はありますが、それはメンテナンスモード移行前の出来事です。「いずれ日本語に対応するだろう」という見込みで採用するのは避けてください。

既存インデックスをBedrock Managed Knowledge Baseへ移す判断基準

すでにGenAI Indexを運用している場合、急いで捨てる必要はありません。維持を選んでよいのは、対象文書が英語で、米国・アイルランド・シドニーのいずれかにデータを置ける前提が満たされ、絞り込み要件がユーザー属性で足りている場合です。この条件下では、Retrieve APIの精度と$0.32/時の単価は維持する理由になります。

逆に移行を急ぐべきなのは、コネクタの世代更新や新しいデータソースの追加が今後の計画に入っているケースです。v2.0限定という制約は新機能開発が止まった以上そのまま残るため、対応コネクタが増えない前提で棚卸しをすることになります。移行先のAmazon Bedrock Managed Knowledge Baseはコネクタが7種類まで絞られ、検索方式もハイブリッド固定になるなど、機能の差分を埋める作業が必要です。移行先の具体的な実装手順と東京リージョンでの制約はAmazon BedrockでRAGを実装する手順とManaged Knowledge Baseのboto3実装で扱っています。社内向けのチャット形式で使う構成を検討しているならKnowledge Baseを使った社内RAGチャットシステムの実用例もあわせて参照してください。

よくある質問

Amazon Kendra GenAI Indexとは何ですか？

Amazon Kendraで作成できる3種類のインデックスのうち、生成AI用途に最適化された「GenAI Enterprise Edition index」の通称です。ハイブリッド検索・セマンティック埋め込み・再ランカーモデルを内蔵し、RAGで使うRetrieve APIの精度を高めています。2024年12月4日に発表されました。

GenAI Indexは東京リージョンで使えますか？

使えません。利用できるのは米国東部（バージニア北部）、米国西部（オレゴン）、欧州（アイルランド）、アジアパシフィック（シドニー）の4リージョンで、アイルランドとシドニーは2025年4月3日に追加されたものです。東京・大阪は含まれていません。

Kendra GenAI Indexの料金はいくらですか？

基本インデックスが$0.32/時で、20,000件または200MBの抽出テキストと0.1 QPS（約8,000クエリ/日）が含まれます。30日換算では$230.4/月です。追加のストレージユニットは$0.25/時、クエリユニットは$0.07/時、コネクタはインデックスあたり月$30の定額（500同期時間込み・日割りなし）です。

GenAI Enterprise EditionとEnterprise Editionの違いは何ですか？

単価と容量の刻みが異なり、GenAI Enterprise Editionは$0.32/時・20,000件から始まるのに対し、Enterprise Editionは$1.4/時・100,000件からです。精度面ではGenAI Enterprise EditionがRetrieve APIで優位ですが、Query APIの精度は同等とAWSが記述しています。一方でGenAI Enterprise Editionには英語限定・v2.0コネクタ限定・アクセス制御の制限があります。

いまから新しくGenAI Indexを作れますか？

新規のお客様は作成できません。2026年7月30日にKendraが新規のお客様の受付を終了したためです。すでにKendraを利用している場合は引き続き作成・利用できますが、メンテナンスモード下で新機能は追加されません。

関連記事

• Amazon Kendraとは？新規受付終了と移行先の判断【2026年版】
• Amazon BedrockでRAGを実装する手順｜Managed Knowledge Baseのboto3実装と東京リージョンの制約【2026年版】
• リトリーバルとは？RAGの検索工程の仕組みと実装・精度改善の判断基準【2026年版】
• Knowledge Baseを使った社内RAGチャットシステムの実用例