Amazon Q Business→Amazon Quick移行ガイド｜BYOIでインデックス引き継ぎ

1. この記事について

社内でAmazon Q Businessをすでに本番運用しているチームにとって、2026-07-31の新規受付終了は「いつか対応すればよい話」ではありません。既存顧客へのサポートは継続されますが、新機能のリクエストは受け付けられなくなるため、今後の機能追加や改善は後継サービスであるAmazon Quick側でしか受けられなくなります。つまり、Q Businessを使い続けるという選択肢は「現状維持のまま先細る」ことを意味します。

一方で「Amazon Quickへ移行する」と一口に言っても、実際に手を動かす段になると迷う点が数多くあります。

• Amazon QuickはQ Businessと「連携できる別サービス」なのか、それとも「後継そのもの」なのか、正確な関係性をどう理解すればよいか
• 既存のQ Businessインデックスをゼロから作り直さずに引き継ぐには、どの機能(BYOI)をどう使えばよいか
• IAM Identity Center(IDC)を使っている場合と使っていない場合で、ID・ACL移行の手順はどう変わるか
• Q Appsで作り込んだ社内アプリは、Quick Flowsへどう移行すればよいか
• Guardrails・Actions・User StoreなどBYOIの対象外となる機能は、Quick側でどう代替すればよいか
• 移行作業中もエンドユーザーが業務で使い続ける既存のQ Business環境を止めずに、どう並行稼働させればよいか

本記事はこれらの疑問に、AWS公式ドキュメントの一次情報に基づいて順番に答えていきます。数値や仕様については推測を避け、公式ドキュメントを取得日とともに明記したうえで解説します。

1-1. 本記事のゴール

本記事を読み終えると、次の判断と作業を根拠を持って進められる状態になります。

1. リタイアタイムラインとAmazon Quickの位置づけの正確な理解 — 2026-07-31新規受付終了という期限と、Amazon Quickが「Q Businessのnext evolution(後継)」であって「別サービスとの連携」ではないという関係性を、誤解なく説明できる
2. BYOI中心の段階移行設計 — Quickセットアップ→BYOIでの既存インデックス接続→native/MCPデータソース追加→ID/ACL移行→Q Apps移行という移行ステップを、自社の構成に当てはめて計画できる
3. ID/ACL移行の実務 — IAM Identity Center利用時(seamless)と非利用時(権限粒度の復元作業が必要)の違いを理解し、document-level ACLの移行を計画できる
4. Q Apps→Quick Flows移行の勘所 — BYOI経由では移行されないQ Appsを、Quick Flowsへ個別に移行する際の考え方を把握できる
5. 機能ギャップの代替策 — Guardrails・Actions・User StoreなどBYOI非対象の機能について、Quick側の代替手段を選定できる
6. 詰まりポイントの事前回避 — 「別サービスだから移行不要」という誤認や、非IDC環境での権限粒度喪失など、移行時に陥りやすい落とし穴を事前に把握し回避できる

本記事のゴールを一言で言えば、「Q Business終了を漠然とした不安のまま迎えるのではなく、根拠を持ってAmazon Quickへ段階移行できる状態」を作ることです。

本記事の構成

本記事は次の流れで、Q Businessの正確な理解からAmazon Quickへの移行実務までを解説します。§2で前提を正確に理解したうえで、§3以降は実際の移行作業の順番に沿って読み進められる構成にしています。

1-2. 読者像

本記事は「Q Businessをこれから使い始める方」向けの入門記事ではなく、「既にQ Businessを運用しており、リタイアに伴う移行を実務として進める必要がある方」を主な対象としています。

主たる読者

• 既存のAmazon Q Business利用者で、2026-07-31のリタイアに伴う移行対応を求められているエンジニアや管理者
• 企業検索・RAG・Q Appsを運用しており、既存インデックスやデータソース資産をゼロから作り直さずに引き継ぎたいチーム
• IAM Identity Centerを使った権限管理を既に構築しており、移行後もドキュメントレベルのアクセス制御を維持したい担当者
• これから企業向け生成AIアシスタントを新規構築する運用者で、最初からAmazon Quickでの構成を検討している方

特に、複数のデータソースコネクタを本番稼働させ、IAM Identity Centerと連携したドキュメントレベルのアクセス制御を運用しているチームほど、移行時に検討すべき論点が多くなります。本記事はそうした「移行の難易度が高いケース」を念頭に、シンプルな構成にも応用できる形で解説を進めます。

前提とする知識

本記事が扱わないこと

• Q Businessの基礎(企業検索の仕組み・コネクタの選定・プラグイン・ガードレールの一般解説)は、既存2記事(§7でクロスリンク)へ委譲します
• Amazon Quickの機能全般(QuickSight由来の分析機能など、移行に直接関係しない部分)は本記事のスコープ外です
• 移行後のAmazon Quick運用・チューニングの詳細は、本記事では扱いません
• Amazon Quickをゼロから新規導入するケース(Q Businessを利用していない場合)の初期構築手順は、本記事では扱いません

すでにQ Business基礎編(Vol1/Vol2)をお読みの方は、そのまま本記事の§2から読み進めることで、リタイア対応に必要な情報へ最短で到達できます。まだQ Businessに触れたことがない方は、まず基礎編で企業検索・コネクタ・Q Appsの全体像を把握したうえで本記事に戻ることをおすすめします。

1-3. なぜ今これを書くか

Amazon Q Businessは2026-07-31に新規受付を終了します。既存顧客へのサポート自体は継続されますが、新機能のリクエストは受け付けられなくなるため、実質的にAmazon Quickへの移行が既定路線になります。

ここで見落とされがちなのが、Amazon QuickとQ Businessの関係性です。Amazon Quickは「QuickSightの進化形であるAmazon Quick Suite(2025-10導入)の一部」であり、単なる連携先の別サービスではなく、Q Businessのnext evolution(後継)にあたります。この関係性を正確に理解しないまま移行を進めると、「Q Businessと連携できる別サービスを追加で契約する」といった誤った意思決定につながりかねません。

この表の右列を押さえておくだけでも、社内での意思決定の説明資料や、移行計画の前提として十分に機能します。逆にここを誤解したまま進めると、既存インデックスを活かせるはずのBYOIを使わず、不要にゼロから作り直す判断をしてしまうリスクがあります。

さらに、後継のAmazon QuickはBYOI・MCP・Quick Flowsなど機能構成が変わっています。そのため移行手順も自明ではありません。AWS公式には移行ガイドがありますが、日本語での実務目線の整理はまだ手薄な状況です。本記事は公式一次情報に基づき、この空白を埋めることを目的としています。

移行の検討を先送りにするほど、実際に手を動かせる期間は短くなっていきます。新規受付終了はあくまで「新規のQ Business契約や新機能リクエストが受け付けられなくなる」タイミングであり、その後も既存環境自体はサポートが継続されますが、機能面でAmazon Quickとの差は開く一方です。BYOIによる無停止での段階移行が可能な今のうちに移行計画を固めておくことで、後になって慌てて全面移行するリスクを避けられます。

なお、Q Business自体の基礎(企業検索/コネクタ/プラグイン/Q Apps/ガードレールの一般解説)は既存記事ですでに解説済みのため、本記事では再解説せず既存2記事へ委譲します。

本記事の内容は取得日時点(2026-07-16)のAWS公式ドキュメントに基づいています。Amazon Quickは発展中のサービスです。今後も画面や仕様は変更される可能性があります。実際に移行作業を行う際は、必ず最新のAWS公式ドキュメントをあわせてご確認ください。

Amazon Q Business 基礎を先に押さえたい方はこちら

2. 前提 — Q Businessリタイアの正確な理解とAmazon Quickの位置づけ

2-1. リタイアタイムラインと後継Amazon Quickの正確な理解

Amazon Q Businessのリタイアと、後継であるAmazon Quickの関係を、公式ドキュメントの一次情報に基づいて正確に整理します。

リタイアタイムラインの正確な理解

• 2026-07-31以降、Amazon Q Businessは新規のお客様への提供を終了します。この日までに申し込んだお客様は、これまで通りサービスを利用できます
• 既存のQ Businessアプリケーションはリタイア後も引き続き完全にサポートされ、AWSはバグ修正とセキュリティアップデートの提供を継続します
• 一方で、新機能のリクエストは受け付けられなくなります。つまりQ Businessは「動作は保証されるが、機能面ではこれ以上進化しない」状態に固定されます

AWS公式ドキュメントは、この状況に対して「Q Businessと同等の機能、かつ生成BI・エージェント型AIユースケース向けのより高度な機能を持つAmazon Quickへ、Q Businessアプリケーションを移行し、新規の生成AI/エージェント型AIソリューションはAmazon Quick上に構築すること」を推奨しています。

「連携」ではなく「後継」である理由

ここが最も誤解されやすいポイントです。Amazon Quickは、AWS公式ドキュメントにおいて明確に “the next evolution of Amazon Q Business”(Amazon Q Businessのnext evolution)と位置づけられています。ドキュメント・エンタープライズアプリ・データベース・データウェアハウス・リアルタイムのインターネット情報といった企業データへシームレスにアクセスできる統合プラットフォームとして説明されており、Q Businessという製品ラインが名前とアーキテクチャを変えて発展的に引き継がれた、という関係です。

Amazon Quickには次の機能が統合されています。

これらはいずれも、2025年10月に導入されたQuickSightの進化形であるAmazon Quick Suiteの一部として提供されています。Q Businessが持っていた「企業データに基づくAIアシスタント」としての役割は、Amazon Quickの中核機能として引き継がれつつ、QuickSight由来のBI機能やFlowsによる自動化機能が新たに統合された形です。

Q Business機能とAmazon Quick機能の対応関係

なお、Amazon Quickは2026年3月にAWS東京リージョン(ap-northeast-1)での提供を開始しています(出典: AWS公式What’s New、2026年3月、取得日2026-07-16)。すでにQ Businessを東京リージョンで運用しているチームも、リージョンをまたぐことなく移行を検討できます。この「同一アカウント・同一リージョン」という前提は、次の2-2以降で扱うBYOI移行の必須条件でもあるため、後続のセクションで改めて確認します。

「Quick」「QuickSight」「Quick Suite」の名称整理

社内での意思決定資料に本記事を引用する際、似た名称が並んでいて混乱しやすいため、ブランド名の位置づけを整理しておきます。

「QuickSightがなくなってQuickになった」わけではありません。QuickSightが持っていたBI機能を土台に、Q Business由来の企業データ検索・チャット機能やFlowsの自動化機能を統合し、Quick Suite全体の一部として「Amazon Quick」という製品名に再編されました。このように理解すると整理しやすくなります。本記事では、AWS公式ドキュメントの表記に合わせて「Amazon Quick」という名称で統一して解説します。

よくある疑問への回答

移行検討の初期段階でよく挙がる疑問を、公式ドキュメントに基づいて整理しておきます。

• Q: 2026-07-31を過ぎると、既存のQ Businessアプリケーションはすぐに使えなくなりますか?
  A: いいえ。既存のアプリケーションは引き続き完全にサポートされ、バグ修正・セキュリティアップデートも継続します。使えなくなるのは「新規申し込み」と「新機能のリクエスト」であり、既存環境がすぐに停止するわけではありません
• Q: 今すぐAmazon Quickへ移行しないと業務に支障が出ますか?
  A: 即座に支障が出るわけではありません。ただし、新機能はAmazon Quick側にしか追加されなくなるため、機能面での差は時間の経過とともに開いていきます。BYOIによる無停止移行が可能な今のうちに計画を進めておくことが推奨されます
• Q: これからQ Businessを新規で検討している場合はどうすればよいですか?
  A: 2026-07-31以降は新規申し込みができなくなるため、新規導入する場合は最初からAmazon Quickでの構成を検討することが公式に推奨されています
• Q: 既存のQuickSightを使っていれば、Amazon Quickは自動的に使えますか?
  A: いいえ。Amazon QuickはQuick Suiteの一部として提供される製品ですが、公式移行ガイドでは「Quickへのサブスクリプション作成」が独立したセットアップ手順(3-1)として案内されています。既存のQuickSight利用有無にかかわらず、Amazon Quickとしてのセットアップを個別に行う必要があります

2-2. 移行アプローチの全体像 — BYOI中心の段階移行

Q BusinessからAmazon Quickへの移行は、AWS公式ガイドにおいて「BYOI(Bring Your Own Index)を起点とした段階移行」が推奨アプローチとして示されています。既存のQ Business運用を止めることなく、まずBYOIで最速にQuickへアクセスできる状態を作り、そこから段階的に機能を広げていく設計です。

移行の全体ステップ

各ステップの目的を一文で整理すると次のようになります。

• Step1: Amazon Quick自体の器(サブスクリプション)を用意する
• Step2: 既存のQ Businessインデックスを、作り直さずにQuickへ接続する
• Step2a: BYOIでは引き継がれない/対象外のデータソースを、Quickネイティブに接続し直す
• Step2b: ネイティブ対応コネクタが存在しないデータソースを、MCP経由で接続する
• Step3: ユーザー・グループのアクセス権を、Quick側へ再現する
• Step4: Q Appsで作り込んだ社内アプリを、Quick Flowsへ作り直す

このうちStep2(BYOI)は「オプション」と公式ドキュメントに明記されている点に注意が必要です。BYOIを使わず、最初からQuick上でデータソースをネイティブに接続し直す(Step2aから始める)という選択肢も用意されています。ただし、既存のQ Businessインデックスに投資してきたコネクタ設定やインデックス済みデータをそのまま活かせる点で、多くのケースではBYOIから着手するほうが移行コストを抑えられます。

並行稼働という設計思想

BYOIでQ BusinessインデックスをQuickに接続しても、既存のQ Businessアプリケーション自体には一切影響しません。Q Businessチャットプロファイルがそのままレプリケートされ、管理者や選定したユーザーがQuick側の体験を試しながら、Q Business側は従来通り稼働を続けられます。この「無停止での並行稼働」が、BYOIアプローチの最大の利点です。

段階移行が推奨される理由

一気に全データソースをQuickへ移行するのではなく、BYOIを起点とした段階移行が推奨されている背景には、次のような実務上の理由があります。

• リスクの低減: Q Business側を稼働させたまま並行運用できるため、Quick側で問題が見つかっても既存の業務利用に影響しません
• 比較検証がしやすい: 同じ質問に対するQ BusinessとQuickの回答品質(引用の正確さ・回答の網羅性・関連性)を、管理者や選定ユーザーで比較しながら移行判断ができます
• 全データソースを一度に移行する必要がない: 公式ガイドでも「必要に応じて、時間をかけてデータソースをQuickインデックスへ移行する」という表現が使われており、BYOIで接続した状態を長期的に維持することも選択肢の一つです

この設計思想を理解しておくと、「移行=即座に全面切り替え」という誤った前提でスケジュールを組んでしまうリスクを避けられます。

匿名アクセス/API統合を使っている場合の注意

Q BusinessをAPI経由でカスタムアプリケーションに統合している、または匿名アクセスを利用している場合は、本記事で扱う標準的な移行ステップの対象外です。個別の移行方式についてAWS Supportへ相談することが、公式ガイドで推奨されています。該当する場合は、次のステップへ進む前に、AWS Supportへの相談を済ませてください。

2-3. 移行前提とインベントリ

本格的な移行作業(§3以降)へ進む前に、以下の前提条件を満たしているか、また既存Q Business環境の棚卸しができているかを確認します。

アカウント/リージョン要件

• Q BusinessインデックスとAmazon Quickインスタンスは、同一のAWSアカウント・同一のAWSリージョンに存在している必要があります
• Amazon Quickにおける管理者権限を保持している必要があります
• IAM Identity Center(IDC)を使う構成の場合は、IDCが有効化・設定済みであり、Q BusinessとQuickの両方が同一リージョンの同一IDCインスタンスを介して認証する構成になっている必要があります

アイデンティティプロバイダーの判定

BYOIは「IDC実装」と「非IDC実装」の2種類の認証構成に対応しています。どちらの構成に該当するかは、後続のBYOI接続手順(§3-2)やID/ACL移行(§4)の進め方を左右するため、着手前に判定しておく必要があります。

非IDC実装の場合、「全Quickユーザーが接続済みインデックスへ自動的にアクセスできる」という挙動は、Q Business側で個別に設定していたユーザー/グループ単位のアクセス制御が、BYOI接続だけでは引き継がれないことを意味します。この点の詳細な対処は§4で扱います。

なお、IAM Identity Centerを利用している場合、AWSは同一のIDCインスタンスを共有する複数のQ Businessアプリケーション間でサブスクリプションの重複請求を排除し、各ユーザーが最も高いサブスクリプションレベルでのみ課金される仕組みを提供しています。この仕組みはAmazon Quickへ移行した後もIDC基盤を引き継ぐため、IDC実装を選ぶ場合はコスト面でも移行がスムーズになりやすい、という判断材料になります。

既存Q Businessリソースの棚卸し

移行計画を立てる前に、AWS CLIで既存のQ Business構成をエクスポートし、カタログ化しておきます。

# Q Businessアプリケーション内の全データソースを一覧表示
aws qbusiness list-data-sources \
  --application-id <your-application-id> \
  --index-id <your-index-id>

# 各データソースの詳細設定を取得
aws qbusiness get-data-source \
  --application-id <your-application-id> \
  --index-id <your-index-id> \
  --data-source-id <your-data-source-id>

これらのコマンドで取得したコネクタ構成は、移行計画を立てる際の参照情報になります。あわせて、次の項目についても棚卸ししておくと、§3以降の移行作業や§4・§5で扱う課題への対処を計画しやすくなります。

棚卸しチェックリスト

この棚卸しを移行着手前に済ませておくことで、BYOI接続後に「どの機能がまだQuick側で未整備か」を漏れなく把握でき、§4・§5で扱う個別対応にスムーズに進められます。

非IDC実装を採用する場合は、データソースごとのアクセス権(どのグループがどのデータソースにアクセスできるか)もあわせて棚卸ししておくことを推奨します。次のように、データソース単位でグループの一覧を取得できます。

# 特定データソースにアクセス可能なグループを一覧表示
aws qbusiness list-groups \
  --application-id <your-application-id> \
  --index-id <your-index-id> \
  --data-source-id <your-data-source-id>

このコマンドで取得したデータソース単位のグループ一覧は、§4でQuick側のナレッジベース・Space単位の権限を設計する際の元データになります。非IDC実装では、BYOI接続だけでは個別のアクセス制御が引き継がれないため、この棚卸しを先に済ませておくことが後続作業の前提になります。

§2のまとめ

ここまでで、次の3点を確認しました。

1. Amazon Quickは「連携できる別サービス」ではなく、Amazon Q Businessのnext evolution(後継)です
2. 移行はBYOIを起点とした段階移行が推奨されており、全データソースを一度に移行する必要はない
3. 移行着手前に、アカウント/リージョン要件・アイデンティティプロバイダーの判定・既存リソースの棚卸しを済ませておく必要がある

これらの前提が整った状態で、次の§3では実際にAmazon Quickをセットアップし、BYOIで既存インデックスを接続する具体的な手順を解説します。

3. 移行手順 — Quickセットアップと BYOI 接続

3-1. Step1: Amazon Quickのセットアップ

Amazon Quickの利用には、まずサブスクリプションの作成(セットアップ)が必要です。手順は次の通りです。

1. AWSマネジメントコンソールにサインインし、Analyticsカテゴリ、またはコンソール検索で「Quick」を開きます。画面にはAWSアカウント番号が確認用に表示されます
2. Quickアカウントの一意な名前を入力します。あわせて、サービスおよび利用状況の通知を受け取る通知先メールアドレス(アカウント所有者またはグループ宛)を入力します
3. 初期データストレージ容量(SPICE)に使用するAWSリージョンを選択します。このリージョンは、2-3で確認したQ Businessインデックスのリージョンと一致させる必要があります(BYOIの前提条件)
4. Quickへの接続に使う認証方式を選択します。選択肢は次の4つです
5. パスワードベース、またはシングルサインオン
6. IAM Identity Center
7. シングルサインオンのみ
8. Active Directory
9. 選択内容を確認し、「アカウントの作成」を選択します
10. 作成完了後、「Quickへ移動」を選択してコンソールを開きます

この時点でBYOIをまだ使わず、ネイティブにデータソースを接続し直す方針であれば、Step2をスキップして3-3(Step2a)へ進むことができます。

3-2. Step2: BYOIで既存Q Businessインデックスを接続

BYOIは必須でなくオプションのステップですが、既存インデックスをゼロから作り直さずに引き継げる、最も移行コストの低い経路です。本記事のスコープにおける差別化の中核でもあるため、具体的な手順を示します。

実施手順

1. Amazon QuickコンソールにAdminまたはAdmin Pro権限のユーザーでサインインします
2. 「Knowledge bases(ナレッジベース)」に移動します
3. 「Create knowledge base(ナレッジベースの作成)」を選択します
4. データソースとして「Amazon Q Business」を選択します
5. 接続したいAmazon Q Businessインデックスを一覧から選択します
6. ナレッジベースの名前と説明を入力します
7. 「Create」を選択して作成を完了します

作成が完了すると、Q Businessのチャットプロファイルがそのままレプリケートされ、管理者や選定したユーザーがQuick側の体験を試せるようになります。この間、Q Business側は一切影響を受けず、従来通り稼働を継続します。

対応する認証タイプ

BYOIは、2-3で判定したIDC実装/非IDC実装のいずれにも対応しています。

• IDC実装: Q Business側がAWS_IAM_IDCで認証している構成。QuickとQ Businessが同一のIDCインスタンスを介して認証します。ナレッジベース作成時点では、選択したQ Businessインデックスへのアクセス権を持つユーザーにのみ自動的にアクセスが付与されます。それ以外のユーザーへアクセスを広げるには、Q Business/Quick双方のコンソールで個別に権限設定が必要です
• 非IDC実装: Q Business側がAWS_QUICKSIGHT_IDPで認証している構成。Quick側はネイティブID/AWS Managed Microsoft AD/IAM連携のいずれかで認証します。この構成では、全Quickユーザーが接続済みインデックスへ自動的にアクセスできる点に注意が必要です

BYOIの制約(必ず事前に把握すべき事項)

上記のうち「Q Apps・Actions・ガードレールが対象外」という制約が、後続の§4(ID/ACL・Q Apps移行)・§5(機能ギャップ)で扱う課題の出発点になります。

3-3. Step2a: ネイティブデータソースの追加接続

BYOIで接続した既存インデックスに加えて、あるいはBYOIを使わずゼロから、Quickのネイティブ連携でデータソースを追加接続できます。Quickのコンソールは、目的に応じて連携先を2つのカテゴリに分けて管理しています。

• Knowledge: Q&Aやインサイト抽出のためのデータソース接続(ナレッジベース)
• Connectors: 外部アプリケーションを操作するアクション連携(Action connector)

セットアップ画面は、選択する連携先・サブスクリプション・既存の連携状況に応じて内容が変わります。連携先によって対応する組み合わせ(アクション限定・ナレッジベース限定・両方対応)が異なる点にも注意してください。たとえばGoogle Driveはアクションとナレッジベース作成の両方に対応しますが、Web Crawlerはナレッジベース作成のみに対応する、といった違いがあります。

サブスクリプション要件

連携の設定(Action connectorの作成・ナレッジベースのセットアップ・連携設定の管理)には、Enterpriseサブスクリプションが必要です。Professionalサブスクリプションのユーザーは、共有された既存の連携を利用できますが、新規の連携設定はできません。

設定例: Google Driveの場合

ナレッジベースとしてのセットアップ:

1. コンソールで「Knowledge」を選択
2. Google Driveを見つけ、追加(+)アイコンを選択
3. 認証方式を選択し、サインインフローを完了
4. ナレッジベースの名前と説明を入力
5. インデックス対象のファイル・フォルダを選択し、「Create」を選択

Action connectorとしてのセットアップ:

1. コンソールで「Connectors」を選択
2. 「Create for your team」タブを選択
3. Google Driveを見つけて選択
4. コネクタの名前を入力(説明は任意で追加)
5. 接続タイプとOAuth設定を選択し、認証セットアップを完了
6. 利用可能なアクションを確認し、「Publish」を選択

他の連携先についても、基本的な流れは共通です。個別の設定項目はQuickのユーザーガイドで連携先ごとに確認してください。

3-4. Step2b: MCPによる非対応データソースの接続

Q Businessで使っていたデータソースコネクタの中には、Quickにネイティブな対応コネクタが存在しないものもあります。この隙間を埋めるのが、Model Context Protocol(MCP)を使った連携です。MCPはAIアプリケーションが外部ツール・データソースと通信するためのオープンな標準規格で、QuickがMCPクライアントとして、リモートのMCPサーバーが公開する構造化ツール(データベースへの問い合わせ、API呼び出し、サードパーティサービスとの連携など)を呼び出します。オープン標準であるため、対応先ごとに個別の統合を開発する必要がありません。

MCP連携のセットアップ(4ステップウィザード)

Quickコンソールは、MCP連携の設定を4段階のウィザードで進めます。

1. Quickコンソールで「Integrations」→「Add」→「Model Context Protocol (MCP)」を選択し、連携名・説明・MCPサーバーのエンドポイントURLを入力します
2. 認証方式(User OAuth/Service-to-Service/認証なし)を選択し、対応する認証情報を入力します
3. Quickが対象のMCPサーバーに接続し、利用可能なツールを自動検出してActionとして登録します。検出結果を確認します
4. 必要に応じて、連携を他のユーザーと共有します

検証済みのMCP連携

ネイティブコネクタを持たないサービスのうち、次のものはAWSによって検証済みのMCP連携として提供されています。

• Visier(ピープルアナリティクス)
• HuggingFace(MLモデル・データセット)
• Intercom(カスタマーメッセージング)
• Linear(プロジェクト管理)
• PagerDuty Advance(インシデント対応・SREワークフロー)

これらの検証済みMCP連携は、いずれもChat AgentsとFlowsからの利用に対応していますが、ナレッジベースのインデックス対象としては利用できません(ドキュメントインデックス用途にはネイティブコネクタまたはBYOIを使う必要があります)。

MCPの制約(移行計画で必ず考慮すべき事項)

移行時の推奨アプローチ

ネイティブコネクタが存在しないQ Business接続先を移行する場合は、まず検証済みMCP連携が存在するかを確認します。存在しない場合は、対象サービスがMCPサーバーを提供しているか、あるいはそのサービスのAPIをラップするカスタムMCPサーバーを自前で構築できるかを検討します。この順序で検討することで、すべてのエンタープライズデータソースへの接続性を維持しながら、Quickの高度な機能を活用できます。

なお、アイデンティティ/アクセス制御の移行(既存Q BusinessのユーザーやグループのアクセスをどうQuick側へ引き継ぐか)とQ Apps→Quick Flowsへの移行については、次の§4で扱います。

4. アイデンティティ/アクセス制御と Q Apps の移行

4-1. IDC実装の移行 — シームレスな引き継ぎ

2-3で判定したアイデンティティプロバイダーの種類によって、ID移行の難易度は大きく変わります。IAM Identity Center(IDC)を利用している場合が、最もシンプルな移行パスです。

2-3で触れた通り、IAM Identity Centerを利用している場合、AWSは同一のIDCインスタンスを共有する複数のQ Businessアプリケーション間でサブスクリプションの重複請求を排除し、各ユーザーが最も高いサブスクリプションレベルでのみ課金される仕組みを提供しています。この同一のアイデンティティ基盤が、そのままAmazon Quickへも引き継がれるため、IDC実装ではユーザー移行がシームレスに完了します。追加のスクリプトや個別のユーザーマッピング作業は不要で、Q Business側で構築していたIDCベースのアクセス制御が、そのままQuick側でも有効になります。

4-2. 非IDC実装の移行 — 権限粒度の復元作業が必要

一方、IAM連携・ネイティブID・AWS Managed Microsoft ADなど、非IDC実装を採用している場合は、より複雑な移行作業が必要です。

3-2で確認した通り、非IDC実装では、BYOI接続時に全Amazon Quickユーザーが接続済みのQ Businessインデックスへ自動的にアクセスできるという挙動になります。これは、Q Business側でデータソースごとに設定していたユーザー/グループ単位のアクセス制御が、BYOI接続だけでは引き継がれず、インデックスレベルでの個別アクセス制御が失われることを意味します。

この権限粒度を復元するには、次の2ステップの対応が必要です。

1. 既存のアクセス制御をエクスポート — 2-3で棚卸しした aws qbusiness list-groups の結果をもとに、どのデータソースにどのグループがアクセスできるかのマッピングを作成する
2. Quick側でナレッジベースをアクセスレベルごとに分割し、Space単位で権限を再現 — アクセス権が異なるデータソースごとに別々のナレッジベースを作成し、Quick Spaces内で該当グループにのみ共有設定を行う

AWS公式ガイドは、この移行パターンを自動化する参考実装として、次のような処理フローを示しています(呼び出し先のリソース名やAPIは自社の構成に合わせて調整が必要です)。

import boto3

qbusiness = boto3.client('qbusiness')

APPLICATION_ID = '<your-q-business-application-id>'
INDEX_ID = '<your-q-business-index-id>'

# Step1: Q Business側のデータソース一覧と、各データソースにアクセス可能な
# グループのマッピングをエクスポートする
data_sources = qbusiness.list_data_sources(
 applicationId=APPLICATION_ID,
 indexId=INDEX_ID
)['dataSources']

access_map = {}
for ds in data_sources:
 groups = qbusiness.list_groups(
  applicationId=APPLICATION_ID,
  indexId=INDEX_ID,
  dataSourceId=ds['dataSourceId']
 )
 access_map[ds['displayName']] = [
  g['groupName'] for g in groups.get('items', [])
 ]

# Step2: access_mapを元に、データソースごとにQuick側のナレッジベースを
# 分割作成し、対応するグループにのみSpace共有設定を適用する
# (Quick側の権限付与はコンソール操作またはQuick APIで実施する)

この処理の要点は、「Q Business側のデータソース単位のアクセス権マッピングをエクスポートし、Quick側では同じ粒度をナレッジベースの分割とSpace共有で再現する」という考え方です。非IDC実装を採用している組織は、この復元作業を移行計画の工数に必ず織り込んでおく必要があります。

4-3. document-level ACL の移行

Amazon Quickは、S3・Confluence Cloud・SharePoint・Google Driveのナレッジベースについて、document-level ACL(ドキュメント単位のアクセス制御)に対応しています。この対応により、Q BusinessとQuickの間のアクセス制御ギャップは大幅に縮まります。

S3ナレッジベースの場合、ACLの設定方法は次の2種類が用意されています。

各ACLエントリは、次の3項目で構成されます。

• Name: USERの場合はメールアドレス、GROUPの場合はグループ名
• Type: USER または GROUP
• Access: ALLOW または DENY

必ず把握すべき制約

• ACLはナレッジベース作成時に有効化する設定であり、作成後に変更できません。有効化するかどうかは、作成前に確定させる必要があります
• 設定時には、グローバルACLファイルの格納場所(S3パス)と、任意でメタデータファイルのフォルダ場所を指定します
• すべてのACLは、ナレッジベース作成者のQuickネームスペース内で解決されます

Q Businessとの挙動差(移行時の最重要ポイント)

Amazon Quickは、ACLエントリが紐付いていないドキュメントを取り込みません。これはQ Businessよりも厳格なデフォルト挙動です。Q BusinessはACLファイルに記載のないS3プレフィックスについて全ユーザーにアクセスを許可する挙動でしたが、Quickはその逆で「ACL未設定=非表示」という安全側のデフォルトを採用しています。

このため、Q Business運用時代にACLファイルへの記載が漏れていたドキュメントがあると、Quick移行後にそのドキュメントが検索結果からサイレントに除外されます。移行前に、全ドキュメントへACLエントリが明示的に設定されているかを必ず確認してください。

なお、Quickがまだネイティブのdocument-level ACLクローリングに対応していないコネクタについては、4-2と同様にアクセスレベルごとにナレッジベースを分割し、Spaces単位でチーム/ロールレベルの権限を割り当てる方式で代替します。

4-4. Q Apps → Quick Flows への移行

Q Appsは3-2で確認した通りBYOIの対象外のため、Quick Flowsへ個別に移行する必要があります。AWS公式ガイドが示す移行手順は、Quickの生成AI機能を使ってQ Appsの構造をFlow向けのプロンプトへ変換する、次のような流れです。

1. Quickブラウザ拡張機能のハンバーガーメニューから「Go to Web App」を選択し、Q Businessのウェブアプリケーションを開く
2. 左メニューの「Apps」から、移行したいQ Appを選択する
3. Quickブラウザ拡張機能の「+」アイコン(Chat with this tab)を選択し、そのQ Appの構造・ロジックをQuickに解析させる
4. 次のプロンプトをQuickに入力し、Flow化のためのプロンプトを生成させる

I am migrating this Amazon Q App (Q App name) into Quick as a Quick Flow.
Create a prompt that I can paste into Quick that would recreate this Q App
as a Quick Flow. Using your best effort: Identity the data sources (Company
knowledge or General knowledge) and map to Quick Flows step types (e.g.
Quick data, General knowledge, or Web search). Identity any action steps
that are utilized and map them to the available action connector within
Quick. Determine the sequence of steps in which the Flow is executed and
how each card in Q Apps will be represented in Quick Flows. Ensure the
prompts used within the Q App are copied verbatim. Output this prompt as
markdown and only output the prompt.

1. 生成されたプロンプトをコピーし、QuickのWebアプリケーションで「Flows」→「Create Flow」を開く
2. テキストボックスへプロンプトを貼り付け、「Generate」を選択する
3. 「Run Mode」で挙動をテストしながら、各ステップのプロンプト・出力設定(デフォルトはVersatility and Performance)・creativityレベル(再現性が必要なステップほど低く設定)を調整する
4. Q Appの挙動を満足に再現できるまで、テストと調整を繰り返す
5. 「Share and Publish」を選択し、ユーザーへ公開する

移行できない機能への対応

Q Appsの一部機能、特にフォーム(forms)は現時点でQuick Flowsに存在せず、移行時に再現されません。フォームベースのQ Appを運用している場合は、Quickの構造化入力機能で代替するか、フォーム対応がQuick Flowsに追加されるまで該当のQ Appを維持することを検討してください。

5. 機能ギャップと代替策

5-1. Guardrails・Actions — BYOI非対象と代替策

3-2で確認した通り、Q Businessのガードレール(グローバル制御・トピック単位の制御)とActions(プラグイン経由のアクション実行)は、BYOIの対象に含まれません。つまり、Q Business側で設定していたコンテンツフィルタリングルール・ブロック対象トピック・カスタムアクション設定は、BYOI接続だけではQuickに引き継がれません。

代替策

• ガードレール: Quickのネイティブなガバナンス設定を使い、コンテンツ統制ポリシーを再構築します。BYOI経由での自動引き継ぎができない以上、Quick側で改めてトピック制御・ブロックルールを定義し直す必要があります
• Actions: アクションベースのワークフローは、Quick Flowsへ移行します。Quick Flowsはサードパーティのビジネスアプリケーションおよび3-3/3-4で扱ったAWSサービスコネクタとの連携に対応しており、Q Business Actionsが担っていた役割を引き継げます

ここで注意すべきなのは、BYOI接続直後の時点では、Quick側にガードレールが未設定の状態でQ Businessとの回答比較検証が行われてしまうリスクです。ガードレールの移植は自動では行われないため、比較検証の前にQuick側のガバナンス設定を済ませておく必要があります(詳細は§6で扱います)。

5-2. User Store — ナレッジベース/Spaceレベル管理への移行

Q Businessは、データソース横断でユーザー・グループ管理を一元化する「User Store」機能を提供していました。一方、Amazon Quickではユーザー管理が中央集権的なストアではなく、ナレッジベース単位で行われる設計になっています。

代替策

• IAM Identity Centerのグループと、QuickのSpace単位の共有機能を組み合わせてユーザーアクセスを管理します
• ナレッジベースをチーム/ロールごとに整理し、Space共有によって、どのグループがどのコンテンツ集合にアクセスできるかを制御します

この設計変更は、4-2で扱った非IDC実装における権限粒度の復元とも密接に関連します。「データソースへのアクセス権をどう再現するか」という課題は、User Store代替の観点でも、ID/ACL移行の観点でも、結局はナレッジベースの分割設計とSpace共有設計に帰着します。移行計画を立てる際は、この2つの課題をまとめて「ナレッジベース/Space設計」として一体で検討することをお勧めします。

§5のまとめ

6. 詰まりポイント / アンチパターン

ここまでの移行手順を正しく理解していても、実際の移行作業では見落としやすい落とし穴があります。§2-§5で扱った内容と関連付けながら、代表的なアンチパターンを整理します。

6-1. 「別サービスだから移行不要」という誤認

2-1で整理した通り、Amazon QuickはQ Businessと連携する別サービスではなく、Q Businessのnext evolution(後継)です。この関係性を誤解したまま「うちはQuickを使っていないから関係ない」と放置すると、2026-07-31以降Q Business自体はサポートが継続されるものの新機能が一切追加されなくなるという事実に気づかないまま、機会損失を積み重ねることになります。移行検討の第一歩は、この誤解を組織内で解いておくことです。

6-2. 非IDC環境での権限粒度喪失の見落とし

4-2で扱った通り、非IDC実装ではBYOI接続直後に全Quickユーザーが接続済みインデックスへアクセスできる状態になります。この挙動を事前に把握していないと、「BYOIを接続しただけで安全に移行が完了した」と誤認したまま、本来アクセス権のないユーザーに機密情報が閲覧可能な状態を放置してしまうリスクがあります。2-3の棚卸しと4-2のナレッジベース分割を、BYOI接続と同じタイミングで計画に組み込んでおく必要があります。

6-3. ACL未設定ドキュメントの意図しない除外

4-3で扱った通り、Amazon QuickはQ Businessと異なり、ACLエントリが紐付いていないドキュメントを取り込みません。Q Business運用時代にACLファイルへの記載が漏れていたドキュメント群は、Quick移行後に何の警告もなく検索結果から欠落します。「移行したのに検索結果の件数が減っている」と気づいた時には、すでに一定期間ユーザーに不完全な検索結果を提示してしまっていた、という事態になりかねません。移行前に、全ドキュメントのACLエントリ網羅性を検証しておくことが不可欠です。

6-4. ガードレール未移植のままの比較検証

5-1で触れた通り、BYOIはガードレールを引き継ぎません。この点を見落とし、Q Business側では有効だったトピックブロックや不適切表現フィルタが無効な状態のまま、Quick側の回答をエンドユーザーへ公開してしまうと、ガバナンス水準の低下に気づかないまま運用が進んでしまいます。AWS公式ガイドも、BYOI接続後の比較検証時に「Q Businessで設定したガードレールはBYOI経由では適用されない」点を明示的な確認項目として挙げています。比較検証は、回答品質だけでなくガバナンス設定の同等性も含めて行ってください。

6-5. MCP制約の見落とし

3-4で扱った通り、MCP連携には固定60秒のタイムアウト・カスタムHTTPヘッダー非対応・ツールリストの静的性・ステップアップ認可非対応という制約があります。特に処理に時間のかかるAPI呼び出しを想定しているデータソースをMCP経由で接続する場合、60秒タイムアウトによるHTTP 424エラーを想定していないと、本番投入後に断続的な失敗が発生し、原因調査に時間を取られることになります。MCP接続を計画する際は、対象APIの典型的な応答時間を事前に確認しておいてください。

6-6. カットオーバー前チェックリストの未実施

AWS公式ガイドは、Q Business側のURLを無効化する前に確認すべき項目として、次の5点を挙げています。

• 全ユーザーがQuickへ移行し、正常に認証できること
• 応答品質がQ Businessの基準を満たしている、または上回っていること
• Q AppsがすべてQuick Flowsとして再現されていること
• 該当するナレッジベースにdocument-level ACLが設定されていること
• ネイティブ非対応データソースのMCP連携が正常に機能していること

これらを確認しないままQ Business環境を停止すると、移行漏れに気づいた時点で切り戻しが困難な状態に陥るリスクがあります。カットオーバーは、このチェックリストを全項目クリアしてから実施してください。

7. まとめ + Q Business基礎への双方向クロスリンク

本記事では、Amazon Q Businessの2026-07-31リタイア(新規受付終了)を起点に、後継であるAmazon Quickへの移行を、BYOIを中心とした段階移行の観点から実務目線で解説してきました。ここまでの内容を振り返ります。

1. リタイアタイムラインと後継関係の正確な理解(§2) — Amazon Quickは「連携できる別サービス」ではなく、Q Businessのnext evolution(後継)であること
2. BYOI中心の段階移行設計(§2-§3) — 既存のQ BusinessインデックスをBYOIで無停止のまま接続し、ネイティブデータソース(§3-3)・MCP連携(§3-4)を組み合わせて段階的に機能を広げる設計
3. ID/ACL移行の実務(§4) — IDC実装ではシームレスな移行が可能な一方、非IDC実装では権限粒度の復元がナレッジベース分割+Space共有という形で必要になること。document-level ACLはQ Businessより厳格なデフォルト挙動を持つこと
4. Q Apps→Quick Flows移行(§4) — ブラウザ拡張機能を使ったプロンプト生成方式での個別移行と、forms機能が未対応である点
5. 機能ギャップの代替策(§5) — Guardrails/Actions/User StoreというBYOI非対象機能について、Quickネイティブガバナンス・Quick Flows・IDCグループ+Space共有という代替手段
6. 詰まりポイントの事前回避(§6) — 「別サービスだから移行不要」という誤認、非IDCでの権限粒度喪失、ACL未設定ドキュメントの除外、ガードレール未移植、MCP制約、カットオーバー前チェックの見落とし、という6つのアンチパターン

これらを押さえておくことで、「Q Business終了を漠然とした不安のまま迎える」のではなく、BYOIによる無停止移行を起点に、根拠を持って段階的にAmazon Quickへ移行できる状態を作れます。移行はカットオーバーで終わりではなく、5-2で触れたナレッジベース/Space設計を継続的にチューニングしていくプロセスでもあります。

Q Business基礎編への橋渡し

本記事はAmazon Quickへの移行に特化しており、Q Business自体の基礎(企業検索の仕組み・データソースコネクタの選定・プラグイン・ガードレールの一般解説)は扱っていません。すでに本番運用中のQ Business環境の全体像を体系的に押さえたい方、あるいはこれからQ Businessの基礎から学びたい方は、次の既存2記事をあわせてご覧ください。

なお、両記事とも「Q Businessは今後どうなるのか」という観点から本記事への導線を設けています。