Amazon Q Business本番運用Vol1｜コネクタとプラグイン

1. この記事について — Amazon Q Business 企業検索を本番運用するということ

社内の情報は今や SharePoint・Confluence・Salesforce・Jira・Slack・S3 など多数のシステムに分散しています。「あのドキュメントがどこにあるか」「あの仕様は最新か」「あのインシデントの対処法は誰が知っているか」——こうした問いに答えを得るまでに、社員が費やす時間は相当なものになります。

Amazon Q Business が解決しようとしているのはこの問題です。40 種以上のコネクタで各システムを接続し、単一のチャットインターフェースから社内ナレッジを横断検索できるエンタープライズ向け RAG アシスタントとして、2024 年 4 月 30 日に GA（一般提供開始）しました。

ただし「GA したから使える」と「本番品質で運用できる」は別の話です。エンタープライズ環境で Q Business を安全・安定・コスト効率よく運用するには、次のような判断を積み重ねる必要があります。

• どのコネクタを使い、差分同期と全量同期をどう組み合わせるか
• ACL 継承が機能しているか——権限のないユーザーに機密文書の内容が漏れていないか
• IAM Identity Center のどのインスタンス種別を選び、TIP をどう実装するか
• プラグインで外部システムを操作させるが、3 個制限と Pro 限定の制約をどう設計に組み込むか
• Starter と Enterprise のどちらのインデックスを選び、index units をいくつ確保するか

これらに対して「なんとなく動いているから OK」では本番運用とは言えません。本シリーズはこうした判断軸を体系化し、設計根拠を持って Q Business を本番運用するためのリファレンスです。

1-1. 本記事のゴール

Vol1 を読み終えると、次の設計判断を根拠を持って下せる状態になります。

習得できるスキル

1. コネクタ選定と同期設計 — 40 種以上のプレビルトコネクタ（S3、SharePoint Online、Confluence、Salesforce、ServiceNow、Jira、Slack、Microsoft Teams など）から要件に合う種類を選択し、フル同期・差分同期のスケジュールを本番水準で設計できる

2. ACL 継承の実装と検証 — コネクタが文書本体とアクセス制御リスト (ACL) を同時にインデックスする挙動を理解し、ユーザーごとのドキュメントレベル権限フィルタリングが正しく機能することを document-level sync reports で確認できる

3. IAM Identity Center 連携 — ワークフォースユーザーの管理から、トラステッドアイデンティティ伝播 (TIP)・トラステッドトークンイシュアー (TTI) を経て、Chat/ChatSync API での identity-aware な認証・認可フローをエンド・ツー・エンドで設計できる

4. プラグイン本番構築 — Jira Cloud・ServiceNow のビルトインプラグインによる issue/incident 操作の設定方法と、OpenAPI スキーマを使ったカスタムプラグインの接続制約（1 アプリ最大 3 プラグイン）を本番品質で実装できる。Plugin は Pro サブスクリプション限定の機能です

5. ガードレール設計 — グローバルコントロールとトピックレベルコントロールを組み合わせ、業務要件（社外秘トピックのブロック・LLM ナレッジへのフォールバック許可など）に合わせた応答制御ポリシーを設計できる

6. コストと容量の最適化 — Lite ($3/user/月) / Pro ($20/user/月) の機能差と、Starter index / Enterprise index の index units 単位での容量試算を行い、TCO（総所有コスト）を最小化する構成を判断できる

Vol1 のゴールを一言で言えば、Q Business を「なんとなく使う」から「設計根拠を持って本番運用する」への転換です。

Amazon Q Business のアーキテクチャ全体像（本シリーズとの対応）

Q Business の本番構成は大きく 5 つのレイヤーで構成されます。本シリーズはこれらを順番に深掘りしていきます。

この 5 レイヤーを正しく設計し連携させることが、エンタープライズ生成 AI 検索を「PoC で動いた」から「本番で信頼できる」に引き上げる鍵です。図1 はこれらのレイヤーを一枚に収めたアーキテクチャ全体像です。本文を読み進めながら図1 を参照することで、各コンポーネントの接続関係を把握できます。

1-2. 読者像

本記事は次のような方を主な対象としています。

主たる読者

• 社内情報検索基盤・ナレッジ管理システムの設計・構築を担当する IT アーキテクトおよびプラットフォームエンジニア
• AWS を使った生成 AI / RAG の PoC を越えて、本番環境への展開を進めているエンジニアチーム
• SharePoint Online・Confluence・Salesforce・Jira・ServiceNow・Slack など複数のデータソースを横断検索できる社内基盤を検討・構築中のチーム
• IAM Identity Center を既に導入しており、これに Q Business を組み合わせた本番構成を設計しようとしているインフラエンジニア

前提とする知識

本記事が扱わないこと

• Amazon Q Developer: コード補完・CLI 支援・IDE 統合の機能。Q Business とは独立したサービスです
• 自前 RAG の構築: Amazon Bedrock ナレッジベースと OpenSearch Serverless を使った独自 RAG の実装手順
• 入門ハンズオン: Q Business を初めて触る方は AWS 公式チュートリアルを先にご参照ください
• QuickSight 固有の詳細設定: §6 で概要を紹介しますが、QuickSight 単体の設定は本シリーズでは扱いません
• マルチアカウント・Organizations 設計: Vol3 以降で扱う予定です。本記事では単一アカウント構成を前提とします

上記の「扱わないこと」の大半は、別の専門シリーズや AWS 公式ドキュメントで十分にカバーされています。本シリーズが Q Business の本番運用実装に特化することで、読者は他リソースとの重複なく最短で実装知識を習得できます。

1-3. 本シリーズの位置づけと既存記事との棲み分け

Amazon Q Business については、当ブログの「Bedrock 生成AIアプリ層 本番運用編 Vol2」ですでに紹介しています。あの記事では Amazon Q Developer・Q Business・Bedrock Data Automation・カスタムモデルを横断的に概観し、Q Business が「どんなサービスか (what)」を説明しています。

本シリーズが扱うのは「どう本番運用するか (how to operate)」です。

概観記事が「全体地図」だとすれば、本シリーズは「現地での工事手順書」の位置づけです。具体的には次の粒度まで掘り下げます。

シリーズ構成（第33軸）

本シリーズは Amazon Q Business の本番運用を体系化する専門シリーズとして位置づけています。

• Vol1（本記事）: コネクタ設計・ACL 継承・IAM Identity Center 連携・プラグイン・ガードレール・QuickSight 連携
• Vol2（公開済）: Q Apps・カスタムプラグイン深掘り・ガードレールチューニング・分析
• Vol3 以降: マルチアカウント展開・カスタム UI 開発・エンタープライズ規模の設計パターン（予定）

各 Vol は独立して読める構成になっていますが、Vol1 → Vol2 の順に読むとコンポーネントの理解が積み上がります。特定のテーマ（例: コネクタのみ知りたい）がある場合は目次から該当セクションへ直接アクセスしてください。

同じ高度を繰り返さないために、「Q Business とは何か」の概観部分の再説明は最小限にとどめます。概観から確認したい方は下のリンクを先にご覧ください。

関連記事：Bedrock 生成AIアプリ層の本番運用（Q Developer/Business 概観編）

検索基盤を自前構築する場合：OpenSearch Service 本番運用 Vol1を読む

2. 前提・サブスクリプション設計・料金最適化

2-1. 前提環境

Amazon Q Business を本番構築するには、次のリソースと権限が事前に準備されている必要があります。

必要な AWS リソース

なぜ IAM Identity Center が必須なのか

Q Business はワークフォースユーザー（従業員）ベースのサービスであり、認証・認可の中心に IAM Identity Center を置く設計になっています。理由は次の 3 点です。

1. ACL 継承の主体: コネクタから取り込んだドキュメントのアクセス制御は、IAM Identity Center のユーザー・グループ情報に紐づきます。ユーザーが閲覧権限を持つドキュメントからのみ回答が返されます

2. 会話 API の認証: Chat・ChatSync・ListConversations など主要 API は identity-aware Signature V4 認証が必要であり、呼び出し元のユーザー ID を IAM Identity Center で解決します

3. サブスクリプション管理: Lite / Pro のサブスクリプションはユーザー単位で管理され、IAM Identity Center のユーザーが割り当て対象となります

必要な IAM 権限（デプロイ担当者向け）

qbusiness:CreateApplication
qbusiness:CreateIndex
qbusiness:CreateDataSource
sso:CreateApplicationAssignment
sso:PutApplicationAccessScope
iam:CreateServiceLinkedRole
iam:PassRole

対応リージョンの確認方法

Q Business のリージョン対応状況は AWS 公式のサービスエンドポイント一覧で随時更新されます。東京リージョン（ap-northeast-1）は 2024 年後半に対応済みです。本番構築前に必ず最新のリージョン一覧を AWS 公式ページで確認してください。

IAM Identity Center インスタンスの種類と選択

IAM Identity Center には「組織インスタンス」と「アカウントインスタンス」の 2 種類があります。

• 組織インスタンス: AWS Organizations の管理アカウントで有効化する。複数アカウント・複数アプリで IAM IC を共有でき、サブスクリプション重複排除の恩恵を最大限に受けられる。本番環境では組織インスタンスが推奨。
• アカウントインスタンス: 単一アカウント内でのみ有効。Organizations を使っていない環境や検証用途に向いている。

一度アカウントインスタンスで作成した Q Business アプリケーションを後から組織インスタンスに移行することはできないため、本番設計時に最初から組織インスタンスを選択することを強く推奨します。

2-2. サブスクリプションtier（Lite / Pro）

Q Business は 2024 年 4 月 30 日の GA と同時に、正式なサブスクリプション体系が確立しました。

tier の基本構造

サブスクリプションは Lite ($3/user/月) と Pro ($20/user/月) の 2 段階で、月額ユーザー単位の課金です。

Plugin と Q Apps は Pro 限定 — 設計上の注意点

プラグイン（Jira Cloud・ServiceNow・カスタム OpenAPI など）は Pro サブスクリプションのユーザーのみが利用できます。Lite ユーザーがプラグインを呼び出そうとすると実行時エラーになります。プラグインを使う可能性があるユーザーは設計段階で Pro に分類しておく必要があります。

Q Apps（自然言語でアプリを自動生成する機能）は 2024 年 7 月 1 日以降 Pro 限定に変更されました。Q Apps を社内展開する場合は対象ユーザー全員を Pro にする必要があります。

実運用での tier 使い分け指針

全社一律 Lite  → チャット・文書検索のみ、アクション実行が不要な場合
全社一律 Pro→ プラグインで Jira/ServiceNow 起票も行う場合
部門別混在  → ITヘルプデスク担当は Pro、一般閲覧ユーザーは Lite

部門別に tier を混在させる際は、IAM Identity Center でのグループ管理とサブスクリプション割り当てを連動させて管理します。コンソールまたは CLI でユーザー・グループ単位のサブスクリプション割り当てが可能です。

IAM Identity Center 共有時のサブスクリプション重複排除

同一 IAM Identity Center インスタンスを複数の Q Business アプリケーションで共有している場合、同一ユーザーへのサブスクリプションは重複排除され、最高 tier で 1 回のみ課金されます。

例: あるユーザーが「社内ポータル用アプリ (Pro)」と「営業支援アプリ (Lite)」の両方に割り当てられている場合、課金は Pro ($20) の 1 回だけです。

これに対して IAM Federation（非 IAM IC）を使う場合は IdP ごとに課金されます。複数アプリを展開する場合に組織インスタンスの IAM Identity Center を共有するアーキテクチャを選択することの経済的メリットはここにあります。

実際のサブスクリプション割り当て方法

コンソールから設定する手順は次の通りです。

1. Amazon Q Business コンソール → 対象アプリケーション → User subscriptions タブを開く
2. Add users and groups → IAM Identity Center のユーザー・グループを検索して選択する
3. tier（Lite / Pro）を選択して保存する

CLI を使う場合:

aws qbusiness create-subscription \
  --application-id <app-id> \
  --principal-id <user-or-group-id> \
  --type PRO

--type には LITE または PRO（大文字）を指定します。

tier 変更時の挙動

既存ユーザーの tier を Lite から Pro に変更すると、変更後すぐにプラグイン機能が利用可能になります。逆に Pro から Lite に変更した場合、プラグインアクションは次回チャット開始時から利用できなくなります。進行中のチャットセッションには遅延が生じる可能性があるため、tier 変更はメンテナンス時間帯に行うことを推奨します。

2-3. インデックスタイプ（Starter / Enterprise）と料金最適化

2 種類のインデックスタイプ

Q Business は Starter index と Enterprise index の 2 種類を提供しています。インデックスタイプは Q Business アプリケーション作成時に選択し、後から変更することはできません。

index units (IU) による容量管理

インデックスの容量は index units (IU) 単位で管理します。IU 数はアプリケーション作成後にコンソールから増減できますが、自動スケーリングは行われません。容量が上限に達すると新規ドキュメントの取り込みが停止するため、月次でのモニタリングが必須です。

IU の上限に近づいた際のアラートには CloudWatch メトリクスを利用します。

メトリクス名: IndexCapacityPercentageUsed
しきい値例 : 80% を超えたら SNS 通知

料金の 2 軸構造

Q Business の月額費用は「ユーザーサブスクリプション費用」と「インデックス容量費用」の 2 軸で構成されます。

月額費用 = ユーザーサブスクリプション + インデックス容量
= (Lite ユーザー数 × $3 + Pro ユーザー数 × $20)
  + (IU 数 × 単価 × インデックスタイプ係数)

単価の目安（2024 年 4 月 GA 時点）:
– Lite ユーザー: $3.00/user/月
– Pro ユーザー: $20.00/user/月
– Starter index: 約 $0.14/IU/時間（月換算 約 $100/IU）
– Enterprise index: 約 $0.25/IU/時間（月換算 約 $180/IU）

最新の料金は必ず AWS 公式料金ページ で確認してください。

コスト最適化の実戦判断（5 項目）

1. 最小 IU 数から始める: インデックスを作成する際はデフォルトの IU 数を鵜呑みにせず、実際の文書数に合わせた最小値から開始する。増設は後からいつでも可能。

2. Starter vs Enterprise の移行タイミング: PoC や部門展開フェーズでは Starter index から始め、文書数が 10 万件を超えた段階で Enterprise index のアプリを新規作成して移行を計画する。インデックスタイプの変更はアプリ再作成が必要なため、早期に移行判断の閾値を決めておく。

3. 不要なデータソースの同期停止: 使われていないコネクタの同期スケジュールを「停止 (disabled)」にする。同期はインデックス容量に影響しないが、古い文書によるノイズ（権限情報の陳腐化・不要検索結果）を防げる。

4. Pro の定期棚卸し: 四半期ごとにユーザーの利用状況（プラグイン使用回数・Q Apps 利用状況）を管理者ダッシュボードで確認し、プラグインを全く使っていない Pro ユーザーを Lite に降格させる。

5. IAM IC 共有の徹底: 複数アプリを展開する場合は必ず同一の IAM Identity Center 組織インスタンスを共有し、ユーザーのサブスクリプション重複排除を確実に機能させる。

コスト試算の例

シナリオ A: 100 ユーザー、Lite 混在、Starter index 1 IU

ユーザーコスト : Lite 80名 × $3 + Pro 20名 × $20 = $240 + $400 = $640/月
インデックス  : Starter 1 IU × $100 = $100/月
合計: 約 $740/月

シナリオ B: 100 ユーザー全員 Pro、Enterprise index 1 IU

ユーザーコスト : Pro 100名 × $20 = $2,000/月
インデックス  : Enterprise 1 IU × $180 = $180/月
合計: 約 $2,180/月

プラグインを使うユーザーが限定されている場合、Lite/Pro の混在運用でシナリオ A と B の差額（約 $1,440/月）を節約できます。年間では約 $17,000 の差になる計算です。

インデックスタイプの選定フロー

文書数 〜 5 万件  → Starter index 1 IU で開始
文書数 5〜10 万件 → Starter index 2 IU で様子見 → 伸びが続くなら Enterprise へ計画
文書数 10 万件超  → Enterprise index 1 IU で開始
複数部門 横断 → Enterprise index を推奨（IU あたりの容量が大きく管理しやすい）

Starter index は IU あたりの料金が安い一方、スケールアウト時に IU 数が多くなると Enterprise より割高になるケースがあります。初期展開から 1 年以内に全社展開が見込まれる場合は最初から Enterprise index を選択する方が移行コストを省けます。

3. データソースコネクタ設計 — 40種以上のコネクタとACL継承

Amazon Q Business は外部データソースと接続するためのコネクタレイヤーを持ち、企業内に分散したドキュメントや構造化データを統一された検索インデックスに集約する。コネクタが担う役割は文書の取り込みだけでなく、各データソース固有の権限情報（誰がどのドキュメントを読めるか）を同時に取り込む点にある。

3-1. プレビルトコネクタの全体像と同期方式

Amazon Q Business が標準提供するプレビルトコネクタは 40 種以上に上る。主要なものを次の表にまとめる。

コネクタが対応していない独自システムへ接続する場合は カスタムコネクタを利用する。Amazon Q Business Connector SDK を使ってデータフィードを実装し、独自ソースからドキュメントを push または pull でインデックスに送り込める。

同期スケジューリング

データソースとインデックスの同期には次の 2 種類がある。

• オンデマンド同期: マネジメントコンソールや API を使って任意のタイミングで実行する。初回クロールやテスト時に活用する。
• スケジュール同期: 一定間隔（毎時・毎日・毎週など）で定期実行する。差分クロール（Incremental Sync）に対応しているコネクタでは変更ドキュメントのみを処理し、フルクロールよりも効率的に同期できる。

差分クロールへの対応はコネクタによって異なる。S3 の場合は Last Modified タイムスタンプ、Confluence は更新タイムスタンプを利用して変更分のみを取得する。

同期ジョブのトラブルシュート

同期ジョブの失敗は CloudWatch Logs に出力される。また、マネジメントコンソールの document-level sync reports を参照すると、ドキュメントごとに「成功」「エラー」「スキップ」の状態とその理由を確認できる。

よくある失敗原因として次のものが挙げられる。

1. サービスアカウントの期限切れ: データソース接続に使うサービスアカウントのパスワードや OAuth アプリのシークレットが期限切れになると同期が停止する。Secrets Manager でローテーション設定をしておくと自動更新できる。
2. ネットワーク到達性の問題: オンプレミスデータソースへの接続には、VPC 内に配置したコネクタエージェント経由での接続が必要になる場合がある。
3. API スロットリング: 大規模インデックスの初回クロール時に同期スケジュールを短く設定しすぎると、データソース側の API がスロットリングエラーを返すことがある。初回クロール完了後にスケジュールを設定するか、フルクロールとスケジュール同期の頻度を分けて設定する。

3-2. ACL継承とドキュメントレベルアクセス制御

Amazon Q Business が他の汎用 RAG ソリューションと大きく異なる点のひとつが、ACL クローリングのデフォルト有効化です。コネクタはドキュメントの本文・メタデータとともに、そのドキュメントへの閲覧を許可されたユーザーやグループの情報（ACL）を同時にインデックスに格納する。

権限フィルタリングの仕組み

ユーザーが Amazon Q Business のチャットインターフェースで質問すると、バックエンドでは次のフローが動く。

1. ユーザーの ID を IAM Identity Center から解決し、所属グループを取得する
2. 検索結果の候補文書に対してユーザーの所属グループと ACL を照合する
3. そのユーザーが閲覧権限を持つ文書のみを回答の根拠として使用する

コネクタ側で権限のないドキュメントは、たとえインデックスに存在していても回答には利用されない。権限の壁を API レイヤーではなく検索レイヤーで実現しているため、アプリケーション側で追加のフィルタリングロジックを実装する必要がない。

グループ同期と属性の引き継ぎ

SharePoint や Confluence などは、ドキュメントの閲覧権限をグループ単位で管理することが多い。Amazon Q Business のコネクタは、こうした ドキュメントレベルのグループ権限を同期する。IAM Identity Center のグループとデータソース側のグループを対応づけることで、グループ追加・削除の変更が次回同期時に自動的に反映される。

ACL クローリングの注意点

• ACL クローリングは コネクタごとに設定可能。特定のデータソースで全文書を検索対象にしたい場合は ACL クローリングを無効化できるが、運用上は推奨されない。
• S3 の場合、デフォルトではバケットポリシーやオブジェクトの ACL を直接参照できないため、メタデータ JSON ファイルで閲覧許可ユーザーを明示する方法が推奨される。
• 権限変更はリアルタイムには反映されない。次回の同期が完了するまでは旧権限が有効である点に注意する。

権限変更が頻繁に発生する組織では、オンデマンド同期を権限変更のトリガーと連動させる仕組みを検討すると、インデックスと実際の権限状態とのずれを最小化できる。

4. IAM Identity Center 連携 — 認証とドキュメントレベル認可

Amazon Q Business は IAM Identity Center をユーザー管理の基盤として利用する。従業員アカウントの一元管理・グループ属性の伝播・会話 API へのセキュアな呼び出しを実現する仕組みが、IAM Identity Center を中心に構成されている。

4-1. トラステッドアイデンティティ伝播（TIP）の仕組み

通常の Sig V4 との違い

AWS の API 呼び出しでは通常、呼び出し元は IAM ロールや IAM ユーザーの認証情報で署名した Sig V4 ヘッダーを付与する。このとき「誰が呼び出したか」は IAM エンティティで識別される。

Amazon Q Business の会話 API は、この通常の Sig V4 に加えてエンドユーザーの ID 情報を署名に組み込む必要がある。これがアイデンティティ認識型 Sig V4（identity-aware Sig V4）と呼ばれる方式で、IAM Identity Center から発行されたユーザーコンテキストが署名に含まれる。

対象 API には以下が含まれる。

• Chat
• ChatSync
• SearchRelevantContent
• ListConversations
• GetConversation
• ListMessages

これらの API を呼び出す際は、アプリケーション側で IAM Identity Center のユーザーセッション情報を取得し、アイデンティティ認識型の署名を生成するライブラリを利用する。

TIP のプライバシー保護

TIP を使うことで、エンドユーザーの ID 情報はバックエンドの検索処理にまで伝達される。検索レイヤーでは、そのユーザーが実際に参照できる文書だけが候補になる。これにより次の効果が得られる。

• 参照外文書の非表示: ユーザーが読めない文書は回答の根拠に使われない
• アプリ側フィルタ不要: アプリケーションコードでの権限チェックを追加実装しなくてよい
• 監査証跡: バックエンド側の操作にユーザー ID が紐づくため、誰が何を検索したかを追跡できる

前提条件: IAM Identity Center の設定

TIP を利用するには次の設定が必要です。

1. 組織インスタンスまたはアカウントインスタンスの IAM Identity Center を有効化する
2. Amazon Q Business アプリケーションを IAM Identity Center インスタンスに関連づける
3. ユーザーとグループを IAM Identity Center に登録する（外部 IdP からの SCIM プロビジョニング、または手動登録）
4. アプリケーションへのユーザーおよびグループの割り当てを行う

4-2. トラステッドトークンイシュアーと監査（CloudTrail）

トラステッドトークンイシュアー（TTI）の役割

企業が Okta・Azure AD・Google Workspace などの外部 ID プロバイダー（IdP）を使ってユーザー認証を行っている場合、IdP が発行した OIDC トークンを AWS の IAM ロールセッションに変換する仕組みが必要になる。これがトラステッドトークンイシュアー（TTI）の役割です。

TTI は IAM Identity Center に設定するオブジェクトで、信頼できる外部 IdP のエンドポイント URL と発行者識別子を登録する。アプリケーションが外部 IdP の OIDC トークンを AWS に提示すると、IAM Identity Center が検証した上で一時的な IAM ロールセッションを発行する。このセッションにはエンドユーザーの ID 属性（ユーザー名・グループ）が含まれた状態で付与される。

フローのステップを整理すると次のようになる。

1. エンドユーザーが外部 IdP でサインインし、OIDC アクセストークンを取得する
2. アプリケーションが取得したトークンを AssumeRoleWithWebIdentity API に渡す
3. IAM Identity Center の TTI が外部 IdP トークンを検証し、IAM ロールの一時認証情報を発行する
4. アプリケーションはこの一時認証情報を使ってアイデンティティ認識型 Sig V4 署名を行い、Amazon Q Business の会話 API を呼び出す

CloudTrail による監査

Amazon Q Business に対する API 呼び出しは、CloudTrail のデータイベントとして記録される。TIP を使っている場合、CloudTrail のログにはエンドユーザーの IAM Identity Center ユーザー識別子が含まれる。

記録される情報の例として次のものが挙げられる。

• 呼び出し API 名（ChatSync、SearchRelevantContent など）
• 呼び出し元 IAM エンティティ（アプリケーション側のロール）
• IAM Identity Center ユーザー識別子（エンドユーザー）
• ソース IP アドレス・リージョン・タイムスタンプ

この情報を組み合わせることで、「どのユーザーが」「いつ」「何を検索したか」を事後に追跡できる。社内情報の不正検索や情報漏洩疑いが発生した際の調査に活用できる。

監査ログ活用の実戦ポイント

CloudTrail ログを活用する際は以下の構成が有効です。

• CloudWatch Logs への転送: データイベントログを CloudWatch Logs に転送し、ユーザー別・API 別のクエリを CloudWatch Logs Insights で発行する
• Athena による分析: S3 に蓄積した CloudTrail ログに対して Athena でアドホッククエリを実行し、特定ユーザーの操作履歴を抽出する
• Amazon Security Lake との統合: Security Lake を使って複数サービスのログを正規化・集約し、一元的なセキュリティ監視基盤を構築する

運用上は、ログの保持期間ポリシーと CloudTrail ログファイルの整合性検証を設定した上で稼働させることが推奨される。

5. プラグインとアクション — Jira / ServiceNow / カスタム

5-1. ビルトインプラグインのアクション

Amazon Q Business のプラグインは、チャット内の自然言語指示から直接ビジネスシステムを操作する機能です。ユーザーが「Jira で本番障害の issue を作ってください」と入力するだけで、Q Business がプラグインを呼び出し Jira Cloud に issue を起票する。検索（情報取得）と操作（アクション実行）を1つのチャット画面で完結できることが、単純な RAG 検索との大きな差別化ポイントです。

利用可能なビルトインプラグイン（2025年時点）

Jira Cloud プラグインの詳細アクション

Jira のビルトインプラグインは以下の操作をサポートする。

• issue 作成（Create Issue）: プロジェクト・タイプ・タイトル・説明・担当者を指定して issue を起票する。Q Business が会話コンテキストからフィールドを自動補完するため、入力コストを大幅に削減できる。
• issue 読取（Get Issue）: issue キーを指定し、現在のステータス・担当者・コメントを取得する。
• issue 検索（Search Issues）: JQL クエリや自然言語フレーズで issue を一覧取得する。「今週アサインされたバグ一覧を教えて」のような指示に対応する。
• issue 削除（Delete Issue）: 誤登録 issue を削除する。プロダクションでの誤削除リスクを考慮し、アクション実行前に確認ダイアログを挟む設計を推奨する。
• ステータス変更（Transition Issue）: issue を In Progress・Done 等のステータスへ遷移させる。
• スプリント操作（Sprint Operations）: アクティブスプリントへの issue 追加・スプリント情報取得に対応する。

ServiceNow プラグインの詳細アクション

ServiceNow のビルトインプラグインは、ITSM の中核であるインシデント管理と変更リクエスト管理を両方カバーする。

• インシデント作成（Create Incident）: 重大度・カテゴリ・短い説明を指定してインシデントを起票する。運用チームがチャットだけで初動対応を記録できる。
• インシデント更新（Update Incident）: 解決メモの追加・ステータス遷移・担当グループ変更が可能です。
• インシデント検索（Search Incidents）: 状態フィルタや優先度フィルタで一覧を取得する。「未解決の Priority 1 インシデントは？」のような質問に即答できる。
• 変更リクエスト作成（Create Change Request）: 標準変更・通常変更のリクエストを起票する。
• 変更リクエスト更新（Update Change Request）: 承認ステータス更新・実施スケジュール変更に対応する。

プラグインの設定手順

1. Amazon Q Business コンソール → 対象アプリケーション → Plugins タブを開く
2. Add plugin → ビルトインプラグイン一覧から選択（例: Jira Cloud）
3. OAuth 2.0 認証情報（Client ID / Secret）または Service Account トークンを入力する。認証情報は AWS Secrets Manager への保存が推奨です。コンソールが Secrets Manager ARN を直接受け付けるため、平文トークンをコンソールに貼る必要がない。
4. 有効にするアクションスコープを選択して保存する

プラグイン設定のトラブルシュートポイント

• 接続テスト失敗: OAuth エンドポイント URL が組織のカスタムドメインかどうかを確認する。Jira Cloud のサイト URL が https://{org}.atlassian.net 形式でないと認証が通らない。
• アクション呼び出し失敗（403）: プラグインで設定した OAuth スコープが要求アクションを含んでいるか確認する。Jira の場合、issue 作成・削除には write:jira-work スコープが必要です。
• Pro 限定エラー: Lite サブスクリプションのユーザーはプラグイン呼び出しが不可です。「You need a Pro subscription to use plugins」のようなメッセージが表示された場合はサブスクリプション tier を確認する。
• アクション実行タイムアウト: 外部 API のレスポンスが遅い場合は Q Business 側でタイムアウトが発生する。プラグインが依存する外部 API のレイテンシを事前に計測し、P99 が 5 秒以内に収まることを確認する。

5-2. カスタムプラグイン（OpenAPIスキーマ）と制約

ビルトインプラグインに含まれない社内 API や SaaS をカスタムプラグインで接続できる。カスタムプラグインは OpenAPI 3.0（Swagger）スキーマを使って API 仕様を Q Business に伝える仕組みです。

OpenAPI スキーマの定義方法

スキーマには以下の要素を記述する。

• openapi: "3.0.0" バージョン宣言
• servers: API のベース URL
• paths: 公開するエンドポイント（パス・メソッド・パラメータ・レスポンス）
• components.schemas: リクエスト/レスポンスのデータモデル

スキーマの提供方法は2種類ある。

1. S3 バケット格納: スキーマ JSON/YAML を S3 にアップロードし、コンソールで S3 URI を指定する。スキーマの更新が容易でバージョン管理にも使いやすい。
2. インラインエディタ: コンソールのインラインエディタに直接 YAML を貼り付ける。小規模テスト向きです。

S3 格納の場合は、Amazon Q Business サービスロールに s3:GetObject 権限が必要です。

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::your-plugin-schemas/*"
}

重要制約（本番設計前に必ず確認）

カスタムプラグインで呼び出す API が認証を要する場合は OAuth 2.0 または API キーを設定できる。API キーは AWS Secrets Manager に格納し、コンソールで Secrets Manager ARN を参照する形式が推奨です。

カスタムプラグインの開発ポイント

OpenAPI スキーマの description フィールドは Q Business が自然言語指示とアクションを紐づける重要な情報源です。エンドポイントと各パラメータの description を具体的に記述することで、Q Business が適切なアクションを選択する精度が向上する。例えば "Creates a new Jira issue in the specified project" のように目的を明確に書く。

カスタムプラグインが呼び出す API はパブリックインターネット経由でアクセス可能である必要がある。VPC プライベートエンドポイントのみで提供される社内 API に直接接続できないため、API Gateway または Application Load Balancer を経由してパブリックエンドポイントを公開する設計が必要になる。

6. ガードレールと QuickSight 連携

6-1. ガードレール — グローバル／トピックレベルコントロール

Amazon Q Business のガードレールは「アプリケーションが何を答えてよいか・何を答えてはならないか」を管理者が宣言的に制御する仕組みです。コンソールの Application environment → Guardrails で設定する。

グローバルコントロール

グローバルコントロールは、アプリケーション全体に適用されるデフォルト動作を制御する。主な設定項目は次の通りです。

• Response settings（応答設定）:
• Retrieval mode のみ: データソースから取得した文書を根拠にした回答のみを許可する。LLM 自身の学習済み知識を使った回答を禁止する。社内文書にない情報を回答させたくない場合に使用する。

• LLM フォールバック許可: データソースに回答根拠が見つからない場合に LLM の汎用知識を使った回答を許可する。一般的なテクニカル Q&A と社内文書を組み合わせる構成に向いている。

• 引用表示（Citations）: 回答に参照したソース文書のタイトルと URL を添付する設定。ユーザーが回答の根拠を即座に確認できるため、エンタープライズ用途では基本的に有効化が推奨される。

• ハルシネーション抑制: Q Business はデータソース文書を根拠に回答を生成するため、Retrieval mode を厳密化することでハルシネーションを体系的に抑制できる。

LLM フォールバック設定の選択指針

本番運用では段階的なアプローチが有効です。まず LLM フォールバック許可でパイロット稼働させてユーザーフィードバックを収集し、文書整備が進んだら Retrieval モードへ切り替える。

トピックレベルコントロール

トピックレベルコントロールでは、特定のトピックに対する回答を管理者がブロックできる。設定手順は以下の通りです。

1. コンソール → Guardrails → Blocked topics を開く
2. Add blocked topic → トピック名と説明文を入力する
3. そのトピックに関する質問を受け取ったとき、Q Business が返す拒否メッセージ（カスタマイズ可能）を設定する
4. 保存すると即座にアプリケーションへ反映される

具体的なユースケースは次の通りです。

• 競合他社比較の禁止: 競合への言及をブロックし、「本サービスに関する質問にお答えします」と返す。
• 法的アドバイスのブロック: 法務部門が関与すべきトピックをブロックし、担当部署へのエスカレーション文を返す。
• 財務予測の禁止: 社員向けアシスタントで財務予測系の質問をブロックし、IR 担当へ誘導する。

ガードレールのモニタリング

ガードレール適用状況は Amazon CloudWatch メトリクスで監視できる。トピックブロック発動回数のメトリクスをモニタリングすることで、どのトピックが頻繁にブロックされているかを把握し、ガードレール設定の最適化に役立てられる。CloudWatch Logs Insights でブロックされたクエリの傾向を定期的に分析することを推奨する。

6-2. Amazon Q in QuickSight 連携（生成BI）

Amazon Q in QuickSight は Amazon Q の機能として（2024年4月30日 GA）提供される生成 BI 機能です。QuickSight ダッシュボードに対して自然言語で質問でき、可視化の作成・更新・要約を対話的に行える。

主な機能

• Executive Summary（経営サマリー）: ダッシュボードをワンクリックで経営者向けサマリー文章に変換する。会議前の準備時間を短縮できる。
• 自然言語 Q&A（Build Visual）: 「先月の地域別売上を棒グラフで見せて」のような自然言語入力から、QuickSight が自動でビジュアルを生成・追加する。
• マルチビジュアル回答: 1 つの質問に対して複数のビジュアルを同時生成し、比較分析をサポートする。
• Data Stories: 複数のビジュアルを組み合わせた自動ナラティブを生成する。

Reader Pro プランとの関係

Amazon Q in QuickSight の生成 AI 機能（Executive Summary・Build Visual・マルチビジュアル回答）は Reader Pro プランが必要です。通常の Reader ライセンスでは生成 AI 機能が無効になる。

QuickSight への Q 有効化手順

1. QuickSight コンソール → Manage QuickSight → QuickSight Q を開く
2. Enable Q → Reader Pro へのアップグレードプロンプトに従う
3. データセットに対して Q のインデックスを作成する
4. ユーザーが BI ダッシュボード上で「Q」アイコンをクリックして使用開始する

本番導入時の注意点

• QuickSight の Q はデータセット単位でインデックスを作成する。インデックス対象外のデータセットには Q で質問できないため、Q の恩恵を受けたいデータセットを事前にリストアップして全てインデックスを設定する。
• Executive Summary は大規模ダッシュボード（ビジュアル 20 個以上）では生成に時間を要する場合がある。ユーザー向け案内で期待値を調整する。
• コスト試算: Reader Pro は Reader より追加料金が発生する。生成 AI 機能を使う実際のユーザー数を見積もり、Reader / Reader Pro を適切に割り当てることでコストを最適化する。
• データセットの品質: Q in QuickSight の回答精度は、データセットの列名・説明文・フィールドの型設定に影響される。列名を人間が読みやすい名称に整備し、フィールドの説明を設定しておくことで、自然言語クエリとデータ列の紐づけ精度が向上する。

7. 実戦統合パターン — 企業検索基盤の本番構成

Q Business の本番導入は「いきなり全コネクタ接続」ではなく、段階的なデータソース追加戦略が成功率を高める。ここでは社内ナレッジ横断検索とアクション連携を両立する本番構成パターンを示したうえで、Q Business・AgentCore・Bedrock の役割分担、マルチアカウント展開のガバナンス設計まで解説する。

7-1. 統合シナリオ：社内ナレッジ横断検索＋アクション

社内情報システムに散在する文書を Q Business で統合検索し、チャットから直接アクションを起票する構成は、多くの企業が最初に目指すユースケースだ。Confluence Cloud・SharePoint Online・Jira Cloud を束ねた本番構成例を段階別に示す。

Phase 1: コアナレッジの取り込み（目安 2 週間）

まず社内で最も参照頻度の高い 1〜2 データソースから開始する。社内 Wiki（Confluence Cloud）や社内ポータル（SharePoint Online）は Q Business のプレビルトコネクタが用意されており、接続工数が最も少ない。

• Confluence Cloud コネクタ: OAuth アプリを Atlassian 管理コンソールで登録 → スペースキーを絞り込みフィルタに指定 → index units をページ数 × 平均ドキュメントサイズで見積もる
• ACL クローリング: デフォルト有効のまま稼働させる。Confluence のスペース単位権限がページ単位権限に継承され、Q Business 上でも同じ権限範囲で検索結果が制御される
• 同期スケジュール: まず差分同期を 30 分間隔でテスト稼働。エラーが出ない場合は 15 分間隔に調整し、スロットリングの有無を再確認する

Phase 1 の完了条件は「自分がアクセス権を持つ文書のみ検索ヒットすること」の動作確認だ。意図せず権限外文書が検索結果に現れた場合は ACL クローリング設定とグループマッピングを最優先で修正する。

Phase 2: ビジネスシステムの接続（目安 4 週間）

ナレッジ取り込みが安定したら Jira Cloud・ServiceNow Online コネクタを追加し、プラグインアクションを有効化する。

• Jira コネクタ: プロジェクトキー・課題タイプでフィルタリングし、業務ドメインに関係する課題のみをインデックスに含める。全課題をインデックスすると容量が急増するため絞り込みが重要
• ServiceNow コネクタ: ナレッジベース記事を優先的に取り込む。インシデント本文は機密度が高い場合も多く、ACL 設計を確認してから追加を判断する
• プラグイン設定: ユーザーが Pro サブスクリプションであることを確認してから Jira プラグインを追加 → issue 作成アクションを Q Chat と連携させる。「この調査結果を Jira に起票して」という自然言語指示で Jira issue が自動作成される状態を目指す

Phase 3: 横断統合の最適化（目安 2 週間）

• 応答品質評価: PutFeedback API でユーザーが付けたフィードバック（サムズアップ/ダウン）を収集し、インデックス重み付けの改善に活用する
• 容量調整: CloudWatch メトリクス IndexCapacityUsage を週次で確認し、80% を超えたら index units の追加を検討する
• ガードレール調整: 実際のユーザー質問ログを分析し、正当な業務質問がトピックブロックで誤って弾かれていないか確認する。過剰ブロックは利用率低下に直結するため「何をブロックするか」とともに「何は許可するか」を明示する

既存社内システムとの統合手順

イントラネット上の静的 HTML ページを取り込む場合、Web Experience コネクタまたはカスタムコネクタ（OpenAPI スキーマ）を選択する。静的サイトの場合は HTML ファイルを S3 バケットに配置して S3 コネクタで取り込む経路が最もシンプルだ。

社内グループウェア（Google Workspace）の場合は Google Drive コネクタを使用する。サービスアカウントに対象ドライブの閲覧権限を付与し、Google グループを ACL として継承させる。マイドライブの個人ファイルはインデックス対象外にすることで情報リスクを低減できる。

Box・Dropbox・OneDrive については Q Business のプレビルトコネクタが用意されており、OAuth 認証フローで接続できる。社内ポータルやイントラネットサイトは Web Experience コネクタを活用し、クロール対象の URL パターンを正規表現でフィルタリングして取り込み範囲を制御する。

7-2. Q Business / AgentCore / Bedrock の役割分担マップ

企業 AI 基盤を設計する際、Q Business・AgentCore・Bedrock の適切な役割分担が長期的な保守性を左右する。三者は代替ではなく補完関係にある。

Q Business — エンタープライズ検索（社内文書 RAG）

• ユースケース: 社内文書横断の自然言語検索・要約・Q&A、プラグインを通じた限定的なアクション実行
• 強み: 既製コネクタ（40 種以上）、ACL 継承、IAM Identity Center 統合、管理者向けコンソール、Pro/Lite の 2 tier
• 限界: 複雑なマルチステップエージェント処理や外部 API の高度なオーケストレーションには適していない。プラグインは最大 3 個の制約がある

AgentCore — エージェント実行基盤（多様なタスク自動化）

• ユースケース: 複数ツール・API を横断するタスク自動化、マルチステップ推論、長期セッション管理
• 強み: 任意のツール統合、Bedrock モデルの柔軟な選択、長期記憶、セッション状態管理
• Q Business との連携: Q Business の検索結果を AgentCore のツール入力として活用することで、「社内文書を参照しながら複雑なワークフローを自動実行する」高度な統合が実現できる

Bedrock — 基盤モデル API（カスタムアプリ構築）

• ユースケース: 独自の生成 AI アプリケーション、Bedrock Knowledge Base による独自 RAG 構築、モデルのファインチューニング
• 強み: モデル選択の自由度（Claude / Titan / Llama 等）、Bedrock Knowledge Base（開発者向け柔軟 RAG）
• Q Business との違い: Bedrock Knowledge Base は API 開発者向けで ACL 継承を自前実装する必要がある。Q Business はエンタープライズ向けマネージドサービスで ACL 継承・コネクタ・IAM IC 統合が内包されている

Q Business をバックボーンとしたエージェント拡張パターン

Q Business をフロントエンドのエンタープライズ検索レイヤーとして活用し、より複雑なタスク自動化が必要な場合のみ AgentCore に委譲する分離設計が推奨される。

社内ユーザー（自然言語チャット）
│
▼
Q Business（社内文書 RAG + プラグインアクション）
│ 複雑なマルチステップ処理が必要な場合
▼
AgentCore（カスタムエージェント + ツールオーケストレーション）
│ 基盤モデル選択・追加推論
▼
Bedrock Claude / Titan 等

この階層設計では「Q Business で解決できるか？」を最初に判断し、プラグイン 3 個制限や RAG 以上の複雑な処理が必要な場合のみ AgentCore レイヤーに処理を委ねる。Q Business の管理性（コネクタ・ガードレール・ACL 継承）を維持しながら、より高度なエージェント機能を段階的に追加できる構成だ。

7-3. マルチアカウント展開のガバナンス設計

大規模組織では事業部門ごとに AWS アカウントを分離しつつ Q Business アプリケーションを統合管理したいニーズが生じる。

IAM Identity Center 共有インスタンス戦略

AWS Organizations 管理アカウントで IAM Identity Center インスタンスを作成し、メンバーアカウントから委任管理で参照させる構成が推奨される。

• サブスクリプション重複排除: 同一 IAM Identity Center インスタンスを複数の Q Business アプリケーションが共有すると、ユーザーは最高 tier で 1 回のみ課金される。部門ごとに IAM Identity Center を分割すると重複排除が効かず課金が増加するため要注意
• 中央 IdP 連携: 社内 Active Directory・Okta・Azure AD を Organizations 単位で一元接続し、各部門の Q Business アプリがユーザー属性（部署・グループ）を継承できるようにする

アカウント分離と Q Business アプリケーション配置の指針

タグ戦略とコスト配分

各 Q Business アプリケーションに CostCenter・Department・Environment タグを付与し、AWS Cost Explorer でサブスクリプション課金とインデックス課金を部門別に可視化する。月次の部門別コストレポートを自動出力する仕組みを整えることで、インデックス容量の肥大化を早期に検知できる。タグポリシーを Organizations で強制することで、タグ漏れによるコスト配分不能を防ぐ。

8. 詰まりポイント・アンチパターン・まとめ

Q Business の本番運用では、設計時には見えなかったハマりポイントが実装・運用フェーズで次々と顔を出す。ここでは実務でよく遭遇する詰まりポイント 7 件と、設計段階で避けるべきアンチパターン 6 件を、症状・原因・対処の形式で整理する。

8-1. 詰まりポイント 7 選

① コネクタ同期で ACL が正しく継承されない問題とデバッグ手順

症状: 同期完了後、本来アクセス権のないユーザーへ文書が露出する、または権限を持つユーザーでも検索ヒットしない。

原因:

• コネクタの ACL クローリング設定が意図せず「無効」に変更されているケース
• データソース側（Confluence・SharePoint）でグループ構造が変更されたが、差分同期では ACL 更新が遅延するケース
• IAM Identity Center のグループとデータソース側グループの名前が大文字小文字の不一致等で同期されていないケース

対処手順:

1. AWS コンソール → Q Business → データソース → 最新同期ジョブの「ドキュメントレベル同期レポート」を開き、ACL 取得エラーが記録されていないか確認する
2. コネクタ設定で「ACL クローリング」が有効になっているか再確認する
3. BatchPutDocument API を使い、テスト用ドキュメントに ACL を明示して投入し、GetDocument でインデックス上の ACL を検証する
4. IAM Identity Center のユーザー・グループ属性マッピングがデータソース側と一致するか突き合わせる
5. フル同期を手動実行して ACL が正しく再取得されるか確認する。差分同期だけでは ACL 変更が反映されない場合がある

② IAM Identity Center 未設定で Chat API が認証エラーになるケース

症状: Q Business アプリを作成し ChatSync API を呼び出すと AccessDeniedException または 401 エラーが返る。

原因: Q Business の Chat・SearchRelevantContent 等の identity-aware API は、IAM Identity Center を通じたトラステッドアイデンティティ伝播（TIP）が前提。IAM ロールの Sig V4 署名だけでは不十分で、ユーザーコンテキストの埋め込みが必要。

対処手順:

1. アプリケーション設定で IAM Identity Center インスタンスが紐付いているか確認する
2. 呼び出しコードでトラステッドトークンイシュアー（TTI）を通じてユーザー ID を Sig V4 認証ヘッダーに組み込む実装になっているか確認する
3. CloudTrail で qbusiness.amazonaws.com のイベントを確認し、ユーザー識別子がログに記録されているか検証する
4. AWS ドキュメントの「Trusted identity propagation」セクションのサンプルコードと自実装を照合する

③ プラグイン 3 個制限を超えた際のエラーとアーキテクチャ再設計

症状: 4 つ目のプラグインを追加しようとすると LimitExceededException: Plugin limit reached が返る。

原因: Q Business アプリケーションあたりのプラグイン上限は 3 個（ビルトイン・カスタム合算）。

対処手順:

1. 既存プラグインのアクション利用状況をログで分析し、月次で利用ゼロのプラグインは削除候補として検討する
2. 同種のツール連携を 1 つのカスタムプラグイン（OpenAPI スキーマ）にまとめられないか設計を見直す
3. 3 個制限を超えるアクション群が必要な場合は、AgentCore を別レイヤーで用意し Q Business のプラグインは最高優先度 3 件に絞り込む分離アーキテクチャへの移行を検討する

④ Lite tier でプラグインが使えないと気づかず設計してしまった問題

症状: Lite サブスクリプションのユーザーがプラグインアクション（Jira issue 作成等）を実行しようとするが、プラグインタブが表示されない、または「この機能は利用できません」と表示される。

原因: プラグイン・Q Apps は Pro サブスクリプション専用機能。Lite ユーザーはチャットと基本検索のみ利用可能。Pro 必須機能を設計に組み込んでいながら、ライセンス設計を Lite ベースで行っていた場合に本番直前で発覚する。

対処手順:

1. プラグインを利用するユーザーグループの IAM Identity Center グループに Pro サブスクリプションを割り当てる
2. Lite と Pro が混在する環境では、Q Business の「サブスクリプション管理」でユーザー単位の tier を確認する
3. 設計段階で「誰がどのアクションを使うか」を整理し、Pro ライセンス数をコスト計画に明示する。プロジェクト開始時点でこの確認を必須ステップにすることが再発防止になる

⑤ インデックス容量（index units）の見積もりミスによるコスト超過

症状: 月次の AWS 請求でインデックス容量課金が想定の 2〜3 倍になっている。

原因:

• ドキュメント数は想定内でも、ページあたりサイズの大きい PDF・PowerPoint が多数インデックスされた
• Starter index（最大 50 万ドキュメント）で足りると想定していたが、実際には Enterprise index が必要だった
• ファイルタイプ設定を怠り、画像・動画・圧縮ファイル等の非テキストバイナリまでインデックスに含まれた

対処手順:

1. コネクタの「ファイルタイプフィルタ」を設定し、PDF・Word・PowerPoint・テキスト系に絞り込む
2. CloudWatch メトリクス IndexCapacityUsage をダッシュボードに追加し、80% 超でアラームを発報するよう設定する
3. Starter index と Enterprise index の容量・単価差を公式料金ページで再確認し、実ドキュメント数と照合して tier を選択し直す
4. 定期的に「同期レポート」のドキュメント数推移を確認し、急増した場合はコネクタフィルタを見直す

⑥ QuickSight Q 連携で Reader Pro ライセンスが必要と気づくタイミング

症状: QuickSight のダッシュボードで Amazon Q（生成 BI）機能を有効化したが、一部ユーザーに「Executive summary が利用できません」と表示される。

原因: Amazon Q in QuickSight の executive summary・自然言語 Q&A・マルチビジュアル回答は QuickSight Reader Pro ライセンスが必要。従来の Reader ライセンスでは利用不可であり、全社展開後に初めて気づくケースが多い。

対処手順:

1. QuickSight 管理画面で対象ユーザーのライセンスタイプを確認し、Reader Pro に変更する
2. Reader Pro の追加コストを Q Business Pro サブスクリプションと合わせて総コスト試算に組み込む
3. 全社展開前にパイロットグループ（20〜50 名）で Reader Pro を試用し、ROI を検証してから横展開する計画を立てる

⑦ ガードレールでトピックブロックしたのに迂回回答される場合の対処

症状: ガードレールのトピックブロックに特定のテーマを設定したが、言い回しを変えた質問には回答されてしまう。

原因: Q Business のガードレールはキーワードマッチングと意味的類似度の組み合わせで機能するが、意図を言い換えた質問には漏れが生じる場合がある。また「LLM の知識へのフォールバック」を有効にしている場合、社内インデックスに該当情報がなければ LLM がそのまま応答する経路が残る。

対処手順:

1. Response settings の「LLM 知識へのフォールバック」オプションを「無効」にする。社内インデックス回答に限定することで LLM が直接応答する経路を遮断できる
2. トピックブロックの description を詳細に記述し、類義語・言い換えパターンも列挙する
3. 定期的に「プロービングテスト」を実施し、ガードレールの実効性を検証する運用プロセスを設ける。テスト結果は変更ログと紐付けて記録する

⑧ コネクタ認証情報の期限切れによる同期停止

症状: 数ヶ月間安定稼働していたコネクタが突然同期エラーを出し始め、ドキュメントが更新されなくなる。同期ジョブのステータスが「Error」になり、最終更新日が止まっている。

原因: コネクタの認証情報（OAuth トークン・サービスアカウントキー・APIキー等）には有効期限が設定されていることが多い。Confluence や Google Drive の OAuth アプリはトークンの有効期限（通常 60〜180 日）切れにより認証が失敗する。Salesforce・ServiceNow などでは API ユーザーのパスワードポリシーが定期変更を要求する場合がある。

対処手順:

1. AWS コンソール → Q Business → データソース → 同期履歴を開き、エラーメッセージに「Authentication failed」「Token expired」「Invalid credentials」等が含まれているか確認する
2. コネクタ設定の「認証情報」セクションで、Secrets Manager に格納されているシークレットの最終更新日を確認する。期限切れが疑われる場合は認証情報を再発行し、シークレットを更新する
3. Google Drive・Confluence OAuth の場合: データソース管理画面でコネクタを「切断 → 再接続」し、新たな OAuth 認可フローを実行する
4. 予防策として、AWS Secrets Manager の「ローテーション」機能と CloudWatch アラームを組み合わせ、シークレット更新期限が近づいた際に Slack や SNS へ通知するモニタリングを設計する

8-2. アンチパターン → 正解変換 6 選

❌ アンチパターン1: Lite tier で全機能を使おうとする

→ ✅ 正解: Pro tier が必要な機能を事前に確認してから設計する

設計段階でプラグイン・Q Apps の利用を想定しているにもかかわらず、コスト削減を優先して全ユーザーを Lite で契約すると、本番直前に機能不足が発覚する。プロジェクト開始時に「誰がどの機能を使うか」を整理し、プラグイン利用者のみ Pro を選択するハイブリッド設計が現実解だ。Lite ユーザーにはチャット検索を提供し、アクション起票が必要なユーザーのみ Pro に絞り込むことでライセンスコストを最適化できる。

❌ アンチパターン2: Q Business を Bedrock Agents の代替として使う

→ ✅ 正解: 検索/RAG=Q Business、タスク実行=AgentCore/Bedrock で役割を分離する

Q Business はエンタープライズ向けの社内文書 RAG。複雑な外部 API オーケストレーションや長期にわたるマルチステップ推論には設計上適していない。「なんでも Q Business で実現しよう」とすると、プラグイン 3 個制限やコネクタ中心のアーキテクチャに縛られ、AgentCore・Bedrock Agents で容易に実現できるユースケースを無理に Q Business に押し込む設計迷走が起こる。役割を明確に分離することで、それぞれの強みを活かせる。

❌ アンチパターン3: すべてのコネクタを Enterprise index に入れる

→ ✅ 正解: 利用頻度/重要度で Starter/Enterprise を使い分けコスト最適化する

「確実を期して」全データソースを Enterprise index に接続すると、ほとんど参照されないデータソースのインデックス費用が積み上がる。コネクタごとのアクセスログ（CloudWatch）を定期的に分析し、参照頻度の低いデータソースは Starter index に移行するか、フルテキストインデックスから除外してメタデータ検索のみにとどめる判断を四半期ごとに行うことが重要だ。

❌ アンチパターン4: ガードレールを「すべてのトピックをブロック」に設定する

→ ✅ 正解: フォールバックポリシーを設計し業務質問を妨げない

セキュリティを優先するあまり、ガードレールのトピックブロックを過剰に設定すると、業務上正当な質問まで弾かれ、ユーザーが Q Business を使わなくなる。「何をブロックするか」だけでなく「何を許可するか」をポジティブリストで定義し、ブロック時のフォールバックメッセージを具体的な代替手段（担当部署への問い合わせ先等）に誘導する設計が定着率を高める。ガードレール設定後は必ずテストセットで意図した動作を確認する。

❌ アンチパターン5: IAM IC なしで Federation 設定をゼロから作る

→ ✅ 正解: 既存 IdP（AD/Okta 等）との連携からスタートする

「IAM Identity Center を使いたくない」という理由で独自の SAML Federation を Q Business に直接設定しようとするケースがある。しかし Q Business の TIP・ACL 継承・サブスクリプション重複排除はいずれも IAM Identity Center との統合を前提に設計されている。既存の Active Directory や Okta は IAM Identity Center と AD Connector または外部 IdP 接続で短時間に接続できる。IAM IC を通じた標準経路を選択することで、長期的なメンテナンスコストを大幅に削減できる。

❌ アンチパターン6: 同期スケジュールを最小間隔（5 分）で全コネクタに設定する

→ ✅ 正解: データ更新頻度に合わせて同期間隔を調整しスロットリングを回避する

「常に最新情報を検索できるようにしたい」という要求から、全コネクタの差分同期を 5 分間隔に設定すると、データソース API のスロットリングリミットに到達し同期ジョブがエラーで失敗し始める。リアルタイム性が必要なデータソース（Jira 課題等）は 15〜30 分間隔、ほぼ静的なナレッジ（社内規程文書等）は日次または週次同期で十分だ。コネクタごとの更新頻度を分析し、適切な同期スケジュールを設計することがシステム安定性の基盤になる。

8-3. まとめと Vol2 予告

Vol1 の学習パス振り返り

本記事 Vol1 では Amazon Q Business の本番運用を支える要素を体系的に解説した。

• サブスクリプション設計: Lite/Pro の機能差とインデックス容量課金の 2 軸を理解し、コスト最適化の設計基盤を構築する
• データソースコネクタ: 40 種以上のプレビルトコネクタの同期方式と ACL 継承のデータフローを把握し、段階的なデータソース追加戦略で安定稼働を実現する
• IAM Identity Center: トラステッドアイデンティティ伝播（TIP）による identity-aware API と CloudTrail 監査でセキュアなエンタープライズ検索基盤を構築する
• プラグインとアクション: Jira/ServiceNow のビルトインプラグインと OpenAPI スキーマによるカスタムプラグインを 3 個制限の中で最大活用する設計を身につける
• ガードレールと QuickSight 連携: トピックレベルコントロールで情報リスクを抑制しつつ、生成 BI による自然言語 Q&A で意思決定を支援する
• 実戦統合パターン: Q Business / AgentCore / Bedrock の役割分担を明確にし、マルチアカウントガバナンスで大規模展開に対応する
• 詰まりポイント・アンチパターン: 実務でよく遭遇する 7 つのハマりパターンと 6 つのアンチパターン→正解変換

Q Business を本番環境に導入する際には「まず小さく始め、ACL 継承と IAM Identity Center の接続を確実に検証してから横展開する」アプローチが成功率を最も高める。今日から始める最初のステップは、最も参照頻度の高い社内 Wiki（Confluence または SharePoint）の 1 コネクタを接続し、ACL 継承が正しく動作することを確認することだ。

本シリーズで解説した詰まりポイントとアンチパターンは、実際の本番導入で繰り返し発生するパターンだ。特に「Lite/Pro の機能差を事前に確認しないまま設計を進める」「コネクタ認証情報の期限切れ監視を後回しにする」「ガードレールを設定して終わりにする（定期的な有効性検証を怠る）」の 3 点は見落としやすく、本番後に大きな手戻りを生む。設計フェーズからこれらのリスクを明示的にチェックリスト化して管理することが、安定した Q Business 運用の基盤になる。

Vol2 予告: 本番運用の継続改善

Vol2 では運用フェーズに入った Q Business のチューニングと継続改善を扱う。

• 監視とアラート: CloudWatch メトリクス・ダッシュボード設計、同期エラーの自動検知と対応フロー
• インデックス品質改善: PutFeedback を活用した応答精度の向上サイクルと評価指標の設計
• コスト最適化の深掘り: index units の動的調整、不要コネクタの棚卸しプロセス、部門別コスト配分
• Q Business API 統合: Q Business を社内ポータルや業務アプリに組み込むカスタム UI 実装パターン
• マルチアプリ戦略の深掘り: 部門別 Q Business アプリの統合運用と IAM Identity Center 共有インスタンスの最適化事例

Vol1 で構築した土台の上に Vol2 の継続改善サイクルを積み重ねることで、Q Business は導入直後の「試験的な検索ツール」から「社内ナレッジインフラ」へと昇格する。月次のインデックス品質レビューとユーザーフィードバック収集を運用サイクルに組み込み、Q Business を組織の知的資産に変えていこう。

Q Business の強みは、40 種以上のコネクタによるデータ統合の容易さ、ACL 継承による情報の安全な公開範囲制御、IAM Identity Center との統合による既存認証基盤の活用にある。これらの強みを最大限に引き出す設計と運用の知識が、Vol1 を通じて手に入る。

エンタープライズ検索の成否は技術的な正確さだけでなく、「ユーザーが実際に使い続けるか」にかかっている。コネクタ・ACL・ガードレールが正しく機能した上で、応答の精度と速度がユーザーの期待に応えてはじめて社内定着が実現する。Vol2 ではその継続改善のサイクルを深掘りする。

関連：Bedrock本番運用Vol3(Guardrails高度化・Prompt management・Nova生成)を読む