Amazon Q Business

解決する課題

社内のナレッジは、ファイルサーバー、Wiki、チケット管理、CRM、メールなど多くのシステムに分散しています。従業員が必要な情報を探すには複数のツールを横断して検索し、見つけた内容を読み込んで要約する手間がかかります。全文検索を導入しても、キーワードが一致するだけで「結局どれが答えなのか」は人が判断する必要がありました。

Amazon Q Business は、これらの分散したデータを生成AIアシスタントに接続し、自然言語の質問に対して要約された回答を出典付きで返すサービスです。

• 複数の業務システムを横断して横串で検索し、答えそのものを文章で提示する
• 回答には**参照元（出典）**が添えられ、根拠をたどって確認できる
• 利用者ごとのアクセス権限を尊重し、本人が見てよい情報だけを回答に使う
• 要約・草案作成・分類などの作業を、専用のチャットUIや埋め込みで実行できる

検索エンジンのように「候補を並べる」のではなく、根拠を示しながら「答えを作る」点が中心的な価値です。位置づけとしては、汎用の開発者向けアシスタント Amazon Q Developer に対し、こちらは業務知識に特化した社内向けアシスタントにあたります。

主要概念と用語

• アプリケーション: Q Business を利用する単位。データソース、ユーザー、設定をまとめて保持する
• データソース / コネクタ: 社内システムを接続する仕組み。各種SaaSやストレージに対応したコネクタでドキュメントを取り込む
• インデックス: 取り込んだドキュメントを検索・回答生成のために整理・格納する内部の蓄積
• リトリーバー: 質問に関連するドキュメントを取り出す検索コンポーネント。生成AIが回答を組み立てる元になる
• アイデンティティ統合: 利用者をIDプロバイダーと連携して識別し、その人の権限に基づいて回答を制限する仕組み
• プラグイン: チケット起票や承認など、外部システムへの操作（アクション）を会話から実行する拡張
• ガードレール（トピックコントロール）: 回答してよい範囲や避ける話題を管理者が制御する設定
• ドキュメントの属性（メタデータ）: アクセス制御やフィルタに使う、各ドキュメントに付随する情報

仕様・制限・クォータ

• 多数のビルトインコネクタが提供され、ストレージ、Wiki、チケット、CRM、コラボレーションツールなどに接続できる。対応コネクタの一覧はリージョン・タイミングで変わる
• 利用はユーザー単位のサブスクリプションで、機能範囲の異なるプランが用意される
• 取り込めるドキュメント数、データソース数、同期の頻度などにアカウント単位のクォータがあり、多くは引き上げ申請が可能
• 提供リージョンは限定的で、利用したい機能やコネクタが対象リージョンで使えるか事前確認が必要
• 回答生成に使う基盤モデルや対応言語は提供側が管理し、利用者がモデルを直接選ぶ前提のサービスではない

変動しやすい上限値や対応コネクタ、提供リージョンは公式ドキュメントで最新値を確認してください。

内部の仕組み

Amazon Q Business は、データの取り込み、検索（リトリーバル）、回答生成を組み合わせた、いわゆる検索拡張生成（RAG）の仕組みをマネージドに提供します。

まずコネクタが各データソースをクロールしてドキュメントを取り込み、インデックスに格納します。このとき各ドキュメントには、誰がアクセスできるかといった権限情報やメタデータも一緒に取り込まれます。同期はスケジュールや差分更新で継続的に行われ、元データの変更が回答へ反映されます。

利用者が質問すると、リトリーバーが質問に関連するドキュメントを取り出し、その人のアクセス権限でフィルタします。取り出した内容を文脈として基盤モデルに渡し、要約された回答と参照元を生成します。

• 回答は取り込んだ社内データに根拠を持たせて生成され、出典が添えられる
• アクセス制御は取り込み時の権限情報に基づき、本人が閲覧できない文書は回答に使われない
• プラグインを使うと、回答だけでなく外部システムへのアクション実行まで会話の中で行える

利用者は基盤モデルのホスティングやベクトル検索の構築を意識せず、コネクタ設定とアクセス連携に集中できます。

設計パターン / ベストプラクティス

• 権限のミラーリング: 元システムのアクセス制御をそのまま回答へ反映させるため、IDプロバイダーとアイデンティティ統合を正しく設定する
• 小さく始めて広げる: 価値の高い少数のデータソースから接続し、回答品質を確認しながらコネクタを増やす
• メタデータの整備: 部門・機密区分・更新日などの属性を付け、フィルタや鮮度判断に使えるようにする
• ガードレールの設定: 回答してほしくない話題や機微な領域を管理者が制御し、想定外の回答を抑える
• アクションは段階導入: プラグインによる外部操作は影響が大きいため、参照系から始め、更新系は慎重に広げる

運用・監視

• 同期状況の監視: 各データソースの同期ジョブが成功しているか、取り込み件数やエラーを定期的に確認する
• 回答のフィードバック: 利用者の評価（役立った・役立たなかった）を集め、品質の低い領域を特定する
• アクセスログの確認: 誰がどの質問をしたかを記録し、想定外の利用や情報露出の兆候を監視する
• メトリクスやイベントを CloudWatch に連携し、同期失敗やエラー率にアラートを設定する

コスト

課金は主に、利用するユーザー数のサブスクリプションに対して発生します。プランによって使える機能の範囲が異なり、インデックスの容量や追加機能で費用が変わる場合があります。サーバーを自前で持たない反面、利用者が増えるほどサブスクリプション費用が積み上がる点に注意します。

• 実際に使う利用者だけにライセンスを割り当て、休眠ユーザーの費用を避ける
• 価値の低いデータソースを接続したままにせず、不要なコネクタを整理する
• パイロットで効果を測ってから全社展開し、過大なプランを避ける

具体的な料金やプラン内容は変動するため、公式の料金ページで最新を確認してください。

セキュリティ

• アイデンティティ統合: IAM Identity Center などと連携して利用者を識別し、本人の権限に基づいて回答を制限する
• アクセス制御の継承: 取り込んだドキュメントの権限情報を尊重し、閲覧権のない情報を回答に出さない
• 暗号化: 保管・転送時のデータを暗号化し、KMS による鍵管理に対応する
• ガードレール: 機微な話題や禁止領域を管理者が制御し、回答範囲を絞る
• 監査: 利用ログを記録し、誰が何を尋ねたかを追跡できるようにする

関連サービス・比較

検索・回答の基盤として近い Amazon Kendra と混同されがちですが、役割が異なります。Kendra はアプリに組み込むエンタープライズ検索のエンジン（部品）で、Q Business は権限統合やチャットUI、アクションまで含んだ業務アシスタントの完成形です。

ハンズオン / CLI例

# Q Business アプリケーションの一覧を確認
aws qbusiness list-applications \
  --query "applications[].{Id:applicationId,Name:displayName,Status:status}"

# 指定アプリのインデックス一覧を取得
aws qbusiness list-indices \
  --application-id 12345678-90ab-cdef-1234-567890abcdef \
  --query "indices[].{Id:indexId,Name:displayName,Status:status}"

# 指定アプリのデータソース一覧を取得（接続状況の確認に使う）
aws qbusiness list-data-sources \
  --application-id 12345678-90ab-cdef-1234-567890abcdef \
  --index-id 87654321-ba09-fedc-4321-098765fedcba \
  --query "dataSources[].{Id:dataSourceId,Name:displayName,Status:status}"