ひとことで言うと
社内データを対象にした RAG チャットアプリを、検索・生成・引用表示・アクセス制御まで組み上がった状態で受け取るマネージドサービスです。Amazon Bedrock の上に構築されていて、管理者がやるのは「どのデータソースを繋ぐか」と「どこまで答えさせるか」の設定だけになります。
要するに、社員証で入れる範囲が人によって違う社内図書館です。司書（Q Business）は蔵書を全部把握していますが、あなたに読み上げるのはあなたの社員証で入れる書架のものだけ。しかも「これは3階の書庫のこの資料に書いてありました」と出典を必ず添えます。司書に権限表を手渡す必要はなく、各書架（SharePoint / S3 / Salesforce など）に元々貼ってある入室許可を、司書が巡回して覚えている——この巡回がアイデンティティクローラです。
なぜ生まれたか
同じものを Bedrock で自作すると、実は生成の部分が一番簡単で、詰まるのは権限です。SharePoint のサイト権限、Salesforce のレコード共有、S3 のプレフィックス単位の許可——これらは表現形式がバラバラで、しかも人事異動のたびに動きます。ベクトルストアに埋め込みを入れる時点で ACL を一緒に持ち、検索時にユーザーの所属グループへ解決してフィルタする層を、データソースの数だけ書くことになります。
Q Business は、この層をコネクタごとの標準機能として持ち込みました。ACL は文書と一緒にインデックスされ、ローカルのユーザー／グループIDは内部でフェデレーテッドID にマッピングされて User Store に格納されます。認証は IAM Identity Center 側に寄せてあるので、社内ディレクトリの変更がそのまま回答範囲に効きます。
| 自前 RAG で自分が書くもの | Q Business での扱い |
|---|---|
| コネクタ（各 SaaS の API・ページング・差分検出） | 組み込みコネクタ＋同期モード（full / new or modified / change log） |
| 権限の取り込みと正規化 | ACL インデックス＋アイデンティティクローラ＋User Store |
| クエリ時の権限フィルタ | リトリーバが「認可とアクセス制御に従って」文書を選ぶ |
| 出典表示・ハルシネーション対策 | 回答に引用が付く／ハルシネーション緩和は応答を照合して自動訂正 |
| 「社内データに無い質問」の扱い | グローバルコントロールで、企業データのみ／LLM 知識も可 を切り替え |
| 会話履歴の保持 | 30日保持。その間は続きから再開できる |
試験より先に知っておくべき前提: Amazon Q Business は新規のお客様には提供されていません。AWS は既存顧客向けにバグ修正とセキュリティ更新は続けるものの、新機能の要望は受け付けないと明記しており、移行先として Amazon Quick を案内しています（既存インデックスを Quick に繋ぐ BYOI 経路あり）。試験ガイドの In-Scope には Q Business / Q Business Apps と Amazon Quick が両方載っているので、出題としては生きています。
何に使うか
| 用途 | 使い方 | 関連する試験ドメイン |
|---|---|---|
| 社内ヘルプデスク（IT・人事・福利厚生） | データソースを繋ぎ、Web エクスペリエンスの URL を配る | D2 |
| 権限を尊重した社内検索・要約 | ACL・アイデンティティクローラを有効にして定期同期 | D3 |
| 既存の Kendra 資産の再利用 | Kendra をリトリーバとして Q Business アプリに指定する | D1 / D2 |
| 業務アクションの実行 | プラグイン経由でサードパーティアプリにチケット起票などをさせる | D2 |
| 定型業務のアプリ化 | Amazon Q Apps を作って共有する（タスク自動化アプリ） | D2 |
| 公開向けの匿名アシスタント | 匿名アプリケーション（ユーザー認証なしで使える形態） | D2 |
| 回答範囲・話題の統制 | グローバルコントロール／トピックレベルコントロール | D3 |
| ISV への安全なデータ提供 | データアクセサで検証済み ISV に Q インデックスから取得させる | D3 |
| 既存アプリへの埋め込み | 埋め込み、ブラウザ拡張、Slack / Microsoft Teams / Office 連携 | D2 |
試験でどう問われるか
論点は2つに集約されます。「RAG を自分で組むか、Q Business を買うか」の分岐（D2）と、「ユーザーごとに見える範囲をどう担保するか」（D3）です。後者は Q Business が他の選択肢と決定的に違う場所なので、ここが書いてあるシナリオはほぼ Q Business が正解に寄ります。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| 社内文書 QA を最小の開発工数で | 「既製のチャット UI が要る」「コネクタを書きたくない」「数週間で出したい」 → Q Business | Bedrock Knowledge Bases ＋ Lambda ＋ 自前フロントの構成（動くが、要件が「最小工数の完成品」なら過剰） |
| 回答をユーザーの権限内に限定したい | 「営業は営業の案件しか見えないこと」「元のシステムの権限を継承すること」 → ACL・アイデンティティクローラを有効にした Q Business | Bedrock Guardrails（入出力の内容フィルタであって、誰が何を見られるかの制御ではない）／「回答にユーザー名を渡してプロンプトで注意させる」案 |
| ID 基盤の選択 | 従業員向け・複数 AWS アプリと統合・正確な課金 → IAM Identity Center（組織インスタンス推奨） | 「IAM Federation（OIDC / SAML）でも同じ」——使えますが、他の AWS アプリとの統合によるスケールが制限されると公式が明記 |
| 権限変更が回答に反映されない | ACL はクロールのたびに更新される → 定期的な再同期を設計する | 「User Store を直接編集して直す」（公式は特権操作扱いで、データソース側での変更を推奨） |
| 社内データに答えが無いとき | 「社外の一般知識で答えてはならない」 → グローバルコントロールで企業データのみに限定 | 既定のままでよいとする案（アプリ作成時は LLM 知識からの応答生成が既定で有効） |
| 特定の話題だけ扱いを変えたい | 「給与の話題は答えさせない」「一部のグループにだけ許可」 → トピックレベルコントロール（適用するユーザー・グループを指定できる） | Guardrails for Bedrock のトピック拒否を Q Business の設定として選ぶ |
| 回答の裏取りを利用者にさせたい | 各回答に出典引用が付く／矛盾する回答があれば両方の詳細を出す | 「LLM-as-a-judge を組む」（それは D5 の評価の話で、実行時の引用表示ではない） |
| 社外 SaaS に社内知識を使わせたい | 検証済み ISV に限定して共有 → データアクセサ（IAM Identity Center の認可コード＋PKCE、または信頼されたトークン発行者） | インデックスをエクスポートして渡す案／ISV に IAM ユーザーを発行する案 |
| 従業員ではなく一般公開向け | 認証を前提にしない → 匿名アプリケーション | 「全員を IAM Identity Center に登録する」 |
1問拾える境目: ACL とアイデンティティクローリングは、一度有効にすると無効に戻せません（公式明記）。「まず全社公開で立ち上げて、後から権限を効かせる／外す」という運用前提のシナリオは、この一点で選択肢が絞れます。なお ACL を持たない文書を公開文書として取り込みたい場合は、元のデータソース側で公開扱いにしておくのが公式の手順です。
実務でどう使うか
- 課金は「ユーザーのサブスクリプション」と「インデックス容量」の2本立てです。使っていないユーザーのサブスクリプションが残っていると、質問が0件でも払い続けます。サブスクリプションの作成・アップグレードは管理者しかできません
- IAM Identity Center のアカウントインスタンスを複数アカウントに置くと、アカウントごとに別々に課金されます。IAM フェデレーションを複数アカウントで使う場合も同じです。組織インスタンスに寄せる理由はここにもあります
- データソースを追加しただけでは同期は始まりません。 初回は明示的に
Sync nowを押す必要があります - 文書削除セーフガードを設定しておきます。クローラの失敗やデータソースの一時停止で「消えたように見える」状態になったとき、削除率がしきい値を超えると削除フェーズごとスキップされ、インデックスが空になる事故を防げます。0% なら一切削除しない、100% なら無制限
- User Store の更新は特権操作として扱います。 同名グループを作り直してメンバーを変えると、そのグループを含む文書 ACL に影響します。退職者と同じメールアドレスを新入社員に再利用する場合、古いユーザーを User Store から削除しないと、その利用者の API 呼び出しが拒否されます
- コネクタの認証情報は Secrets Manager 経由です。オンプレミス系コネクタでは、シークレット内のエンドポイント情報と設定側のエンドポイントの一致が検査されます（混乱した代理問題への対策）。エンドポイントを変えたら新しいシークレットを作り直します
- フィールドは 2048 文字で切り捨てられます。長いメタデータをそのまま属性に流すと、フィルタ条件が意図通りに効きません
移行を考えるときの実務上の落差: Amazon Quick への BYOI 移行では、Q Apps・アクション・Q Business のチャットガードレールは引き継がれません。また S3 の扱いが逆で、Q Business は ACL ファイルに現れないプレフィクスを全員アクセス可として扱うのに対し、Quick は ACL の無い文書をそもそも取り込みません。同じ設定を移すと、前者では見えていたものが後者では消えます。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Amazon Bedrock Knowledge Bases | Knowledge Bases は自分のアプリに組み込む RAG の部品。Q Business は利用者が直接使う完成品。権限フィルタを自分で書くかどうかが分かれ目 |
| Amazon Kendra | Kendra は検索サービスで、Q Business のリトリーバとして使える（＝競合ではなく部品になれる）。「回答を生成して引用を付けるチャット」まで含むのは Q Business |
| Amazon Q Developer | 相手が違います。Q Business は業務データを使う従業員、Q Developer はコードを書く開発者。同じ「Q」でもユーザーガイドから別物です |
| Amazon Quick | Q Business の後継。新規はこちら。構造化データの分析（QuickSight 連携）・Flows・Spaces まで含む広い製品 |
| Bedrock Guardrails | Guardrails は内容（有害表現・トピック・PII）を止める。Q Business の ACL は誰に見せるかを決める。層が違うので、どちらかで他方は代替できません |
| Q Business のガードレール | 名前は同じでも Bedrock Guardrails とは別機能。グローバルコントロール（企業データのみ／ファイルアップロード可否／ハルシネーション照合）とトピックレベルコントロールの2階建て |
| Amazon Q Apps | Q Business の中の機能で、利用者がタスク特化のアプリを作って共有するもの。基盤モデルを直接叩く開発ではありません |
想起チェック
Q1. 「営業担当には自分の担当案件の情報しか回答させない」。Bedrock Guardrails では答えにならない理由は？
Guardrails は入出力の内容を検閲する仕組みで、誰がどの文書にアクセスできるかは判定しません。必要なのは、データソースの ACL をインデックスして、クエリ時にユーザーの ID・グループへ解決してフィルタする経路です。
Q2. Q Business が「社内データに無いことは答えない」状態になるのは、既定ですか。
既定ではありません。 アプリケーションを作成した時点では、LLM の知識からの応答生成が有効になっています。企業データのみに限定するには、グローバルコントロールで明示的に切り替えます。
Q3. 「まず権限なしで全社公開し、様子を見てから ACL を有効にする」という進め方の問題は？
ACL とアイデンティティクローリングは、有効にした後で無効に戻せません。 順序としては先に有効化して同期し、公開文書は元のデータソース側で公開扱いにしておくのが公式の手順です。
Q4. 人事異動でグループが変わったのに、Q Business の回答範囲が古いままです。まず何を疑いますか。
データソースの再同期です。ACL の変更はコンテンツをクロールするたびに反映されるので、同期スケジュールが止まっていれば古い権限のまま回答します。User Store を直接いじって帳尻を合わせるのは公式が推奨していません。
Q5. 認証させたくない一般公開のアシスタントを Q Business で作りたい。何を選びますか。
匿名アプリケーションです。ユーザー認証を必要としない形態で、より広い相手に提供できます。全員を IAM Identity Center に登録する必要はありません。