AWSがKendra・Q Businessなど多数サービスを7月30日に新規受付停止｜手元のRAG・社内検索提案書を8日で検証する方法

結論：7月30日以降「新規では使えないサービス」を前提にした提案書が、いま日本中の決裁箱に入っている

AWSは2026年6月30日、Amazon Kendra、Amazon Q Business、Amazon Bedrock Agents Classic、Amazon Cognito Sync、AWS Directory Service(Simple AD)、Amazon SageMaker AIの複数機能(Ground Truth、Model Monitor、Clarify、Debugger等)を含む多数のサービスを「メンテナンスモード」に移行すると発表しました。AWS公式の提供状況アップデートによれば、これらのサービスは2026年7月30日を境に、新規顧客が利用を開始できなくなります。正確な境界日はサービスごとに微妙に異なり、公式ドキュメントによればKendraは「7月30日から新規顧客の受け入れを停止(申込は7月30日より前まで)」、Q Businessは「7月31日から新規不可(登録は7月30日まで)」です。既存顧客は継続利用でき、バグ修正とセキュリティ更新も提供され続けますが、新機能の開発は行われません。本記事公開日(7月22日)から数えて、新規利用の窓が閉じるまで残り8日です。

経営判断として重要な点は2つです。第一に、いま社内で稟議中・見積もり中のAI導入提案が、この「終わりの始まり」が宣告されたサービスを前提にしていないかを、7月30日を待たずに確認する必要があります。Kendraは社内文書検索・RAG(検索拡張生成)の定番、Q Businessは社内AIアシスタントの定番として、2025年から2026年前半にかけて日本のSIer・開発会社の提案書で定番構成として採用されることの多いサービスでした。数カ月前に受け取った提案書がこれらを中核に据えている場合、その提案は構築した瞬間から後継機能が積まれない基盤の上に立つことになります。第二に、すでにKendraやQ Businessを本番利用している企業は、即時の停止リスクはないものの、最終的なサポート終了日は現時点で未発表であり、移行先の選定と撤退計画を「期限を切られる前」に自社ペースで進められる今が、最も条件の良いタイミングです。

本記事では、(1)「メンテナンスモード」という言葉の正確な意味と発注者への実害、(2)手元の提案書・見積書がリスクを含んでいないかを非エンジニアでも見分ける方法とベンダーへの確認質問テンプレ、(3)既存利用企業の撤退ロードマップの作り方、(4)廃止サイクルの速いクラウドAIを前提にした要件定義・契約の書き方、の4点を解説します。なお、AIツールの突然の提供終了にどう備えるかという一般論はOpenAI Atlas終了に学ぶAIツールの撤退計画で扱っており、本稿はAWSの今回の発表に固有の「提案書検証」と「RAG基盤の移行」に焦点を絞ります。

この記事を読むべき人

• 社内検索・RAG・チャットボットの提案書や見積書を現在受け取っている、または稟議中の経営者・決裁者
• Amazon KendraやAmazon Q Businessをすでに本番利用しており、今後の扱いを判断する必要がある企業のIT責任者
• AWS前提のAI開発をベンダーに委託中で、構成にどのサービスが使われているか正確に把握していない発注担当者
• 情シスが0〜1名で、クラウドサービスの「終了告知」を自社で追い切れないと感じている中堅・中小企業の役員
• 今後のAI投資で「作ったものが数年で基盤ごと陳腐化する」リスクを契約でどう抑えるか知りたい経営企画・法務担当者

何が起きたか：対象サービスと「メンテナンスモード」の正確な条件

発表の概要

2026年6月30日、AWSは多数のサービスの提供状況変更を一斉に発表しました。週刊AWS(2026/6/29週)とAWS公式アナウンスで確認できる、AI・認証関連の主な対象サービスは次のとおりです。

このほか、AWS Mainframe Modernization(Self-Managed)やAWS Systems Manager Application Manager等の運用系サービスも同時にメンテナンスモード入りが告知されています。全リストは上記のAWS公式アナウンスをご確認ください。

「メンテナンスモード」の正確な意味 — 即停止ではない、しかし「現状維持」でもない

Amazon Kendraの公式ドキュメントは、メンテナンスモードの条件を明確に定義しています。Kendraの場合、2026年6月30日をもって新機能・新能力の開発が終了し、2026年7月30日から新規顧客の受け入れが停止されます(公式ドキュメントは「利用したい場合は7月30日より前に申し込むように」と明記しています)。一方で、既存顧客に対しては「サービスは完全にサポートされ続け、バグ修正とセキュリティ更新は提供され続ける」と明記されています。Amazon Q Businessの公式ドキュメントも同様に、既存顧客へのサポート・バグ修正・セキュリティ更新の継続を明言しています。

つまりメンテナンスモードとは、「明日サービスが止まる」という話ではありません。整理すると次の3層です。

1. 止まらないもの: 既存環境の稼働、バグ修正、セキュリティ更新、AWSサポート
2. 止まるもの: 新機能・新能力の開発、新しい機能リクエストの受付、新規顧客の利用開始
3. 未確定のもの: 最終的なサポート終了日(現時点で未発表。ただしメンテナンスモードは経験則上、終了告知に先立つ段階として扱われることが多い)

ここで経営者が押さえるべきは、**「止まらないから安心」ではなく「新機能が積まれない基盤は、AI領域では実質的に劣化していく」**という点です。生成AI周辺は数カ月単位で検索精度・対応データ形式・セキュリティ機能が進化しています。競合他社が新世代のRAG基盤で精度を上げていく中、自社だけ機能凍結されたサービスに留まることは、相対的な後退を意味します。

発注者に生じる3つの実害

この発表が「AWSを使っている企業の話」で済まないのは、次の3つの実害が発注側に生じるからです。

実害1: 提案・見積もりの前提の陳腐化。 2026年前半までにベンダーから受け取った社内検索・RAG・チャットボットの提案書は、KendraやQ Businessを中核コンポーネントとして描いているものが少なくありません。7月30日を過ぎると、その構成は新規には構築できなくなります。提案書の日付が数カ月前なら、前提が崩れていないかの再確認が必須です。

実害2: 駆け込み構築のリスク。 「7月30日までに使い始めれば既存顧客扱いになる」ことを理由に、契約を急がせる提案が成立し得ます。しかし、機能凍結が宣告されたサービスの上に、これから数千万円規模のシステムを新規構築することが自社の利益になるケースは限定的です。駆け込みが正当化されるのは、既にKendra前提で開発が相当程度進んでいる等の特殊な状況に限られます。

実害3: 既存システムの移行コストの発生。 すでに利用中の企業は、いずれ移行の判断を迫られます。後述のとおり、AWS公式の移行先(KendraならBedrock Managed Knowledge Base、Q BusinessならAmazon Quick)は機能が1対1で対応しておらず、移行には再設計・データ再取込・精度検証の工数がかかります。この費用を誰が負担するのかは、現行の保守契約の書きぶりに依存します。

手元の提案書・見積書を8日で検証する — 非エンジニアのための見分け方

構成図のどこを見るか

提案書の技術構成は難解に見えますが、今回の確認に必要なのは「単語探し」です。次の手順で15分あれば一次スクリーニングができます。

1. システム構成図・アーキテクチャ図のページを開く。 箱と矢印で描かれた図の、箱の中のサービス名を確認します。
2. 次の単語を探す: 「Kendra」「Q Business」「Bedrock Agents」(※「Bedrock Knowledge Bases」「Bedrock AgentCore」は別物で、今回の対象外。なお後述の移行先「Bedrock Managed Knowledge Base(BMKB)」は、この対象外のKnowledge Basesをさらにフルマネージド化した新しい提供形態で、こちらも廃止対象ではありません)、「Cognito Sync」(※「Cognito」単体は対象外。「Sync」が付くものだけが対象)、「Simple AD」、「Ground Truth」「Model Monitor」。
3. 見積書の明細も確認する。 構成図に書かれていなくても、見積明細のライセンス費・利用料の行に「Kendra インデックス利用料」「Q Business ユーザーライセンス」等が載っていることがあります。
4. 「検索」「ナレッジ」「社内文書」を担う箱が何かを特定する。 RAG提案の心臓部は検索基盤です。そこがKendraなら、提案の中核が対象サービスだということです。

一つでも該当があれば「リスクあり」ではなく「ベンダーに確認が必要」という判定です。該当サービスが周辺的な役割なら軽微な設計変更で済みますし、中核なら提案の再設計が必要です。その切り分けはベンダーへの質問で行います。

ベンダーに送る確認質問テンプレ

以下をそのままメールで送れる形にしました。ポイントは、技術の議論ではなく責任と費用の所在を文書で確認することです。

1. 本提案の構成に、2026年6月30日にAWSがメンテナンスモード入りを発表したサービス(Amazon Kendra、Amazon Q Business、Bedrock Agents Classic等)は含まれていますか。含まれる場合、どのコンポーネントですか。
2. 含まれる場合、後継サービス(Bedrock Managed Knowledge Base等)での再提案は可能ですか。その場合の見積もり差分(初期費用・月額利用料の両方)を提示してください。
3. 仮に現構成のまま進めた場合、将来AWSがサポート終了日を発表した際の移行費用は、貴社・当社どちらの負担になりますか。現行の契約書・保守契約のどの条項が根拠になりますか。
4. 本提案で採用している各クラウドサービスについて、提供元の廃止・仕様変更が発生した場合の対応方針(通知義務・代替提案義務・費用分担)を契約書に明記できますか。
5. 貴社がこの構成を提案した時点で、AWSのサービスライフサイクル(メンテナンスモード入りの可能性)をどう評価していましたか。

質問5は意地悪に見えるかもしれませんが、重要な選別質問です。Kendraのメンテナンスモード入り自体は6月30日の発表で初めて確定した情報なので、それ以前の提案を責めることはできません。しかし、発表から3週間以上経過した現在もベンダー側から何の連絡もなく提案が放置されているなら、そのベンダーの「提案後のフォロー体制」そのものが弱いという判断材料になります。逆に、発表直後に「構成を見直したい」と自発的に連絡してきたベンダーは信頼に値します。

回答をどう評価するか

• 「既存顧客は使い続けられるので問題ありません」だけで終わる回答は不十分です。新規構築の場合、7月30日までに利用開始しなければそもそも「既存顧客」になれませんし、なれたとしても機能凍結の影響は残ります。
• 「後継サービスで再提案します」と即答できるベンダーは、AWSの発表を追跡し移行パスを検討済みということです。ただし再見積もりの差分が不透明なまま金額だけ膨らむ場合は、差分の内訳(何が高くなり、何が安くなるのか)の説明を求めてください。
• 移行費用の負担について「その時に協議」としか答えないベンダーとは、契約前に負担ルールを文書化すべきです。後述の出口条項を参照してください。

既存利用企業の撤退ロードマップ — 移行先の選定軸と進め方

すでにKendraやQ Businessを本番利用している企業は、慌てる必要はありませんが、放置も禁物です。サポート終了日が未発表の今は、裏を返せば締切に追われずに移行先を比較検討できる期間です。終了日が発表されてからの移行は、ベンダーの繁忙と重なり、価格交渉力も失われます。

移行先候補の3類型と選定軸

類型A: AWS内の後継サービスへ移行する。 AWS公式は、KendraからはAmazon Bedrock Managed Knowledge Baseへ、Q BusinessからはAmazon Quickへの移行を推奨しています。データやIAM(権限管理)の資産を活かせるのが利点です。ただし機能は1対1対応ではありません。Kendra公式ドキュメントの移行ガイドによれば、Kendraが32種類以上のネイティブコネクタを持つのに対しBedrock Managed Knowledge Baseは7種類で、検索候補表示(オートコンプリート)、ファセット検索、カスタムシノニム、スペル訂正などは回避策の実装が必要とされています。自社が使っている接続先(kintone、Box、社内DB等)が後継でサポートされるかは、移行判断の最初の確認事項です。Q Business→Quickについても、公式ガイドは既存インデックスを持ち込むBYOI(Bring Your Own Index)による段階移行を案内していますが、ガードレール(回答制御)設定やQ Appsは引き継がれず作り直しが必要と明記されています。

類型B: 他クラウド・他SaaSのRAG基盤へ移行する。 Azure AI SearchやGoogle Cloud(Vertex AI Search)等、他社の同等サービスへの乗り換えです。AWSロックインからの脱却や、既にMicrosoft 365中心の企業がAzure側へ寄せる合理性がある場合に検討します。ただしIAM・ネットワーク・監視といったAWS側の周辺資産を作り直すコストが乗るため、「Kendraの移行」単体ではなくクラウド戦略全体の話になります。

類型C: 自前RAG(OSS+汎用ベクトルDB)に切り替える。 検索エンジンやベクトルDBをOSSや汎用マネージドサービスで構成し、特定ベンダーのAI製品への依存を最小化する道です。廃止リスクへの耐性は最も高い一方、構築・運用の技術力が必要で、情シスが薄い企業が内製で選ぶべき道ではありません。選ぶ場合は、運用まで含めて伴走できる開発パートナーの存在が前提です。

選定軸は次の5つで採点することを推奨します: (1)現在使っているデータ接続先が移行先でサポートされるか、(2)権限管理(誰がどの文書を検索できるか)を再現できるか、(3)月額コストの試算(移行先は課金体系が変わるため「同じ使い方でいくらか」を必ず試算)、(4)自社の運用体制で回るか、(5)その移行先自体の存続性(今回の教訓として、移行先がまた数年で廃止されないかの見立て)。

撤退ロードマップの標準形

1. 現状棚卸し(〜2週間): 対象サービスをどの業務・どのシステムが使っているか、データ量、接続先、利用ユーザー数、権限設定を一覧化します。ベンダー任せで構築した場合、この棚卸し自体を現行ベンダーに依頼し、成果物として文書で受け取ってください。
2. 移行先の比較選定(〜1カ月): 上記5軸で2〜3候補を比較します。現行ベンダーの提案だけで決めず、少なくとも構成と概算の妥当性を第三者に確認させることを推奨します。現行ベンダーには「自社が構築しやすい移行先」を選ぶ動機があるからです。
3. 小規模検証(1〜2カ月): 本番データの一部で移行先の検索精度を検証します。重要なのは、移行前後で同じ質問セットを両方に投げ、回答品質を並べて比較することです。Kendra公式の移行ガイド自体も、新旧を並行稼働させて同一クエリで比較検証するアプローチを示しています。精度検証の合格基準(例: 業務上重要な質問50問で現行と同等以上)を事前に文書化してからテストしてください。
4. 並行運用と切替(1〜3カ月): 一斉切替ではなく、部門単位で新基盤に移し、問題があれば旧環境に戻れる状態を保ちます。既存顧客としてのKendra/Q Business利用は継続できるので、並行期間を焦って短縮する必要はありません。
5. 旧環境の停止と契約整理: 切替完了後、旧環境の課金を止め、データの完全削除を確認します。削除証明の取得までがロードマップです。

この一連の進め方は、RAGに限らずデータ基盤全般の移行と共通の型です。全社のデータをどこに集め、どのAIから参照させるかという設計から見直したい場合は、データ基盤・BI構築の考え方も参照してください。

「クラウドAIは廃止サイクルが速い」前提の要件定義・契約 — 出口条項の書き方

今回の発表から得るべき最大の教訓は、個別サービスの話ではありません。生成AI関連のクラウドサービスは、従来の業務システム基盤よりも明らかに短いサイクルで統廃合されるという前提を、要件定義と契約に織り込むことです。Kendraは2019年発表、Q Businessは2023年発表のサービスです。基幹システムなら10年使う前提で投資しますが、AI領域では「中核サービスが数年単位で世代交代する」ことを異常事態ではなく通常運転として扱う必要があります。

具体的には、今後のAI開発の委託契約・要件定義に次の観点を入れることを推奨します。

• 採用サービスのライフサイクル明示: 要件定義書に、採用する各クラウドサービスの提供開始年と、提供元の廃止ポリシー(告知から終了までの標準期間)を記載させる。
• 抽象化レイヤーの要求: アプリケーションが特定サービスのAPIを直接呼ぶのではなく、検索・生成の呼び出し部分を差し替え可能な構造にすることを要件化する。これにより移行時の改修範囲が「接続部分」に限定されます。
• 出口条項(契約): 「採用サービスの提供元が新規受付停止・メンテナンスモード・終了を発表した場合、受託者は30日以内に影響評価と代替案を書面で提示する」「移行開発は別途見積もりとするが、影響評価と代替案提示は保守料金の範囲内とする」といった条項です。移行費用そのものをベンダー負担にする条項は現実には受け入れられにくいですが、「評価と代替提案までは無償・迅速」を義務化するだけで、放置されるリスクは大きく下がります。
• データ可搬性の担保: 取り込んだ文書・メタデータ・権限設定を標準形式でエクスポートできることを検収条件に含める。移行のたびにデータ整備をやり直すのが、実は移行費用の大きな部分を占めるからです。

こうした「壊れにくい発注」の設計は、個別のシステム開発というより、AI活用全体の要件定義の問題です。自社のAI開発をこの観点で組み立てたい場合はAI開発・生成AI導入支援で扱っています。

よくある質問(FAQ)

Q1. 7月30日を過ぎるとKendraやQ Businessは使えなくなるのですか?

いいえ。既存顧客は継続利用でき、AWSはバグ修正とセキュリティ更新の提供を公式に明言しています。停止するのは「新規顧客の利用開始」と「新機能の開発」です。ただし最終的なサポート終了日は現時点で未発表であり、いずれ移行判断が必要になる可能性を前提に計画すべきです。

Q2. いま提案を受けている構成にKendraが入っています。7月30日までに契約して駆け込むべきですか?

原則として推奨しません。機能凍結が宣告された基盤に新規投資しても、遠くない将来に移行費用が二重にかかる公算が大きいためです。ベンダーに後継サービス(Bedrock Managed Knowledge Base等)での再提案と見積もり差分を求めるのが基本です。例外は、既に開発が相当程度進んでいて手戻り費用が移行費用を上回る場合です。

Q3. AWS公式の移行先に移れば、いまと同じことができますか?

完全には一致しません。AWS公式ドキュメント自身が機能差を明記しており、例えばKendraの32種類以上のコネクタに対しBedrock Managed Knowledge Baseは7種類で、ファセット検索や検索候補表示などは回避策の実装が必要です。Q BusinessからAmazon Quickへの移行でも、ガードレール設定やQ Appsは引き継がれません。「公式後継=同等」と思い込まず、自社が使っている機能の対応表をベンダーに作らせることが重要です。

Q4. ベンダーから今回の発表について何も連絡がありません。問題でしょうか?

提案中・保守契約中の構成に対象サービスが含まれているなら、発表から3週間経って連絡がないのは体制面の懸念材料です。本文の確認質問テンプレを送り、回答の速さと具体性でベンダーのフォロー能力を評価してください。含まれていない場合は連絡がなくても不自然ではありません。

Q5. サポート終了日が未発表なら、急いで動く必要はないのでは?

「移行完了」を急ぐ必要はありませんが、「棚卸しと移行先選定」は今始めるべきです。終了日が発表されてから動くと、同じ判断を締切に追われながら、移行需要で混み合うベンダー相手に行うことになり、費用も交渉力も不利になります。締切前の今は、比較検討と価格交渉を自社ペースでできる期間です。

Q6. そもそも自社のシステムがどのAWSサービスを使っているか分かりません。

ベンダー構築の場合は珍しいことではありません。現行ベンダーに「利用中のAWSサービス一覧と、各サービスの提供状況(GA/メンテナンスモード/終了予定)」の提出を依頼してください。保守契約があれば通常はその範囲で対応可能な依頼です。回答が得られない・著しく遅い場合は、第三者による構成の棚卸しを検討するタイミングです。

GXOに相談すべきタイミング

今回のようなクラウド側の一方的なライフサイクル変更では、現行ベンダーだけに判断を委ねると、「ベンダーが作りやすい移行先」に誘導されるリスクが構造的に存在します。次のいずれかに当てはまるなら、利害関係のない第三者を一度挟む価値があります。

• 受け取っている提案書に対象サービスが含まれているか自社で判別できない、あるいはベンダーの回答の妥当性を評価できない
• Kendra/Q Businessを本番利用中で、移行先の比較(AWS内後継/他クラウド/自前RAG)を現行ベンダーの提案抜きで一度整理したい
• 移行見積もりを受け取ったが、金額の妥当性と「何にいくらかかるのか」の内訳を第三者に検証してほしい
• 今後のAI投資で、サービス廃止に耐える構成と契約(出口条項)を発注前に設計しておきたい

GXOのAIアセスメントでは、現行構成の棚卸し、対象サービスの依存度評価、移行先の比較整理、ベンダー見積もりのセカンドオピニオンを、開発の受注とは切り離した立場で行っています。移行そのものの設計・開発体制が必要な場合はAI開発支援、検索基盤にとどまらず全社のデータの置き場所から見直す場合はデータ基盤構築支援が対応範囲です。

7月30日の新規停止までに全てを決める必要はありませんが、「手元の提案書に対象サービスが入っているかの確認」だけは今週中に終えることをお勧めします。確認の結果に不安があれば、お問い合わせからご相談ください。状況の整理だけでも構いません。

参考文献

• アマゾン ウェブ サービス ジャパン「週刊AWS – 2026/6/29週」
• AWS「AWS Service Availability Updates」(2026年6月)
• AWS「Amazon Kendra availability change」(公式ドキュメント)
• AWS「Amazon Q Business availability change」(公式ドキュメント)