Amazon Q Business本番運用Vol2｜Q Apps・プラグイン・ガードレール分析

1. この記事について — Amazon Q Business を「使われ続ける」基盤に育てる

1-1. 本記事のゴール

Amazon Q Business を導入した直後、管理者が最初に感じるのは「動いているのに、使われていない」という違和感です。コネクタを設定し、IAM Identity Center を統合し、Web experience も公開した。検索は動く。でも、現場から「使いにくい」という声が届く。特定の質問に答えられない。どのくらい使われているのかすらわからない。こうした運用フェーズ特有の課題は、構築フェーズのドキュメントには書かれていません。

Vol1 が解決したこと: 「繋いで検索できる」状態の構築

Vol1 では以下の構築フェーズを完成させました。

• データソースコネクタ(S3 / SharePoint / Confluence 等)を設定し、社内文書をインデックス化
• IAM Identity Center を統合し、組織のユーザー/グループで Q Business へのアクセス制御を確立
• ビルトインプラグイン(Jira / ServiceNow 等)を設定し、Q&A に加えてアクション実行を有効化
• ガードレールの基礎設定で不適切なトピックを大まかにブロック

この状態は「検索基盤として機能している」ことを意味しますが、本番運用として「使われ続ける」状態とは異なります。構築直後は精度・ガバナンス・コスト・可視化の 4 つの課題が未解決のまま残ります。

接続できた、その先: 本番運用で浮上する 4 つの課題

構築が完了した後の現場では、以下の課題が次々に浮上します。

1. 精度の課題: 「検索して回答は返ってくるが、的外れなことがある」「最新ドキュメントより古い情報が優先されている」
2. コストの課題: 「全員 Pro で費用が予算を超えた」「誰が本当に Pro の機能を使っているのかわからない」
3. ガバナンスの課題: 「Q Apps を全社展開したいが、野良アプリやプロンプトインジェクションのリスクが怖い」
4. 可視化の課題: 「利用率を上司に報告できない」「答えられていない質問が何なのかわからず改善できない」

Vol2 はこれら 4 つの課題に正面から答えます。解決策は単発の設定変更ではなく、「分析 → 改善 → 再評価」という継続的な運用ループとして設計するのが本記事の一貫したテーマです。

Vol2 の学習パス(§2-§7)

本記事は以下の順序で運用改善テーマを展開します。各セクションは独立して参照可能ですが、順に読むことで「コスト最適化 → 現場展開 → 高度な機能設計 → 品質チューニング → 可視化」という改善ループの全体像を把握できます。

記事を読み終えた時点で、読者はこれら 6 つの運用改善サイクルを自走させる設計知識と具体的な手順を手に入れます。「なんとなく動いている」から「メトリクスで継続的に改善できる」状態へのステップアップが本記事の目的です。

各セクションは相互に連携しています。たとえば §7 の Analytics で検出した未回答クエリは §6 の relevance tuning や新たなコネクタ追加(Vol1)へのインプットになり、§5 のガードレール監視で検出した誤ブロックは §5 の設定見直しに戻ります。単発の設定作業ではなく、運用ループとして機能させることが重要です。

1-2. 読者像

本記事は、Amazon Q Business の導入フェーズを終えた方、あるいは導入を進めながら「その後」を見据えている AWS 管理者・情報システム担当・生成 AI 活用推進者を主な対象としています。

具体的には次のような課題を抱えている方です。

• 精度の課題: コネクタを設定して検索は動いているが、回答精度が想定より低く改善方法がわからない
• ガバナンスの課題: Q Apps を全社展開したいが、野良アプリや不適切なプロンプトのリスクをコントロールしたい
• コストの課題: ライセンスを全員 Pro にしているが、コストの適正化ができていない
• 可視化の課題: 利用状況を把握できておらず、「誰がどんな質問をしているか」「答えられていない質問はどれか」が見えていない
• プラグインの課題: ビルトインプラグインは動いているが、カスタムプラグインの本番設計に踏み込めていない
• ガードレールの課題: 初期設定のガードレールのまま本番稼働しており、過剰ブロックや設定漏れが不安

本記事は AWS のサービス基礎知識を前提とし、IAM・S3・CloudWatch などの基本的な操作に慣れている方を想定しています。Amazon Q Business 固有の概念(アプリケーション / データソース / インデックス / Web experience / ガードレール)については Vol1 で解説済みのため、本記事では説明を省略します。

Vol1 未読の方は、先に Vol1 でコネクタ設定・IAM Identity Center 統合・プラグイン基礎を確認してから本記事をお読みいただくと、内容を最大限に活用できます。

1-3. 本シリーズの位置づけと Vol1 との棲み分け

本シリーズ「AWS Amazon Q Business企業検索 本番運用」は、Amazon Q Business を企業の「使われ続ける」検索基盤として育てるための実践ガイドです。

Vol1(構築フェーズ) では、データソースコネクタの設定・IAM Identity Center との統合・ビルトインプラグインの活用・ガードレールの基礎概念を扱い、「社内データを自然言語で検索できる状態」を構築しました。Vol1 では Lite/Pro の概要、各コネクタの対応サービス一覧、QuickSight Q のイントロも提供しています。

Vol2(本記事、運用改善フェーズ) では、構築した基盤の上に運用改善レイヤを積み重ねます。Q Apps の現場展開・カスタムプラグインの上級設計・ガードレールの本番チューニング・relevance tuning を活用した検索精度改善・Analytics dashboard を通じた利用状況分析 — これらは「繋いで動かす」次の段階です。Vol1 で扱った内容(コネクタ一覧・ビルトインプラグイン catalog・QuickSight Q イントロ)は本記事では再掲しません。

他シリーズとの差分: Amazon Bedrock Knowledge Bases / Bedrock Agents 系の記事は、LLM の呼び出し・プロンプトエンジニアリング・カスタムエージェント構築に特化しています。本シリーズは Amazon Q Business の managed な検索体験・ガバナンス機能・組織向け展開設計に特化しており、対象が異なります。

以下の判断軸でシリーズを選んでください。

Vol1 と Vol2 の対応関係まとめ

本シリーズは Amazon Q Business の機能アップデートに合わせて内容を更新します。最新の AWS 公式ドキュメントも併せてご参照ください。

Vol1: コネクタ・IAM Identity Center・プラグイン設計を読む

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

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

2-1. 前提環境

本章は Vol1 で構築済の環境を前提としています。以下の状態が整っていることを確認してください。

Vol1 完了状態(本章の前提)

• Amazon Q Business アプリケーション(1つ以上)作成済
• データソースコネクタ(S3 / SharePoint / Confluence 等)設定・インデックス同期済
• IAM Identity Center 統合済・ユーザー/グループ割り当て済
• Web experience 作成済・エンドユーザーアクセス確認済
• ビルトインプラグイン基礎設定(Jira / ServiceNow 等)完了済

Vol2 で追加が必要な設定と権限

IAM Identity Center のユーザーデータが Q Business の課金単位に直接紐づくため、ユーザー登録状況を事前に棚卸ししておくと tier 設計がスムーズです。

2-2. サブスクリプション tier 設計(Lite / Pro の割当判断)

Amazon Q Business は IAM Identity Center ユーザー単位で Lite / Pro を割り当て、月次で課金されます。2025年時点の料金は Lite: $3/ユーザー/月、Pro: $20/ユーザー/月 です(料金は変動する可能性があります。最新情報は AWS 公式料金ページをご確認ください)。

Lite / Pro の機能差(設計判断に直結する主要機能)

ユーザー役割別の tier 割当設計

全員に Pro を付与するのは「全員に最高グレードのオフィスチェアを配布する」ようなものです。機能要件を起点に tier を決定します。

コスト試算例: 100名組織

パターン A: 全員 Pro
  100名 × $20 = $2,000/月

パターン B: 役割別最適化(Lite 80名 + Pro 20名)
  80名 × $3 + 20名 × $20 = $240 + $400 = $640/月

削減効果: $1,360/月 (約 68% コスト削減)
年間換算: 約 $16,320 の削減

現実的な組織では「Pro が必要な機能を使うのは全体の 20-30%」であることが多く、設計次第で大幅なコスト最適化が可能です。

インデックス課金(参考)

Q Business のコストはサブスクリプションだけではありません。インデックス単位(IU)の課金も発生します。Starter tier / Enterprise tier でインデックス IU 単価が異なります。大規模ドキュメント群を扱う場合はインデックス選択も含めてコスト計画を立ててください。詳細は AWS 公式料金ページをご参照ください。

2-2-1. インデックス課金の詳細試算

インデックス単位(IU)の課金は、サブスクリプション費用に加算される変動コストです。Q Business のインデックス tier は Starter と Enterprise の 2 種類で、用途規模に応じて選択します。

IU 課金の月額換算(24時間 × 30日)

Starter tier:
  $0.14/IU/時 × 24時間 × 30日 = $100.8/IU/月

Enterprise tier:
  $0.25/IU/時 × 24時間 × 30日 = $180.0/IU/月

インデックスの IU 数はドキュメント総数・ファイルサイズ・更新頻度に依存します。初期展開時は Starter tier の最小構成から始め、ドキュメント量・検索負荷の実績に合わせて拡張するアプローチが推奨されます。

2-2-2. 総コスト試算: サブスクリプション + インデックス

100名組織の典型的なコストを 3 パターンで比較します。インデックスは Starter tier 1 IU の前提です。

補足: パターン C(全員 Lite)は Q Apps 作成・カスタムプラグイン・QuickSight Q 連携が使えません。高度機能を活用する組織では最低限の Pro 枠が必要です。費用対効果のバランスが最も高いのは パターン B になるケースが多いです。

2-2-3. Lite → Pro 昇格 runbook

ユーザーの役割変更(一般社員 → 部門リーダー等)で Pro tier への昇格が必要になった際の手順です。

Lite → Pro 昇格手順

Step 1: IAM Identity Center のグループ設定確認
  AWS Console → IAM Identity Center → グループ
  Pro 用グループ(例: "Q-Business-Pro")の存在を確認

Step 2: 対象ユーザーをグループ移動
  Lite グループ(例: "Q-Business-Lite")から対象ユーザーを削除
  Pro グループ(例: "Q-Business-Pro")に対象ユーザーを追加

Step 3: Q Business 側の反映確認
  Amazon Q Business コンソール → アプリケーション → ユーザーと権限
  対象ユーザーのサブスクリプション tier が "Pro" に更新されていることを確認
  (通常 5〜15 分で反映)

Step 4: 機能有効化確認
  対象ユーザーの Web experience にログイン
  Q Apps タブが表示されること → 作成・編集機能の確認
  カスタムプラグインが設定されている場合は実行権限の確認

Step 5: 課金反映の記録
  tier 変更は翌課金サイクルから反映されます
  変更日時・対象ユーザー・変更理由を管理台帳に記録

2-2-4. コスト最適化の追加シナリオ

季節変動ユーザー(プロジェクト別割当)

繁忙期にのみ Q Apps や高度なプラグインが必要となるプロジェクト型ユーザーには、プロジェクト期間中のみ Pro tier を割り当て、完了後に Lite へ戻すサイクル管理が有効です。

例: 年度末閉鎖業務チーム (3ヶ月のみ Pro が必要)
  Pro 10名 × $20 × 3ヶ月 = $600
  残り 9ヶ月は Lite 継続
  Lite 10名 × $3 × 9ヶ月  = $270
  年間コスト合計  = $870

  通年 Pro の場合: 10名 × $20 × 12ヶ月 = $2,400
  → 年間 $1,530 削減(63% コスト削減)

部門別コスト配賦

複数部門が Q Business を共用する場合、Pro ライセンス費用を部門別に配賦する仕組みをコスト管理部門と連携して設計します。IAM Identity Center のグループを部門単位で設計しておくと、各グループのユーザー数から部門別費用を月次で算出しやすくなります。

2-2-5. AWS Budgets + Cost Explorer による費用監視

Q Business のコストは AWS Cost Explorer でサービス別フィルタを使って監視できます。

Cost Explorer での Q Business 費用確認

AWS Budgets でのアラート設定

月額費用が設計目標値を超えた場合にアラートを受け取るには、以下の Budget を作成します。

Budget 設定例:
  名称: Q-Business-Monthly-Cost-Alert
  予算タイプ: コスト
  期間: 月次
  閾値: 予算額の 80% で SNS / Email 通知
  フィルタ: サービス = Amazon Q Business

費用が設計した tier 配分と乖離している場合(例: Lite 想定ユーザーが Pro で課金されている)は、IAM Identity Center のグループ割り当てを即座に確認します。

2-3. コスト最適化のゴール状態

tier 設計の最終ゴールは「機能要件ベースで tier が割り当てられており、不要な Pro ライセンスがゼロの状態」です。以下のチェックリストで評価できます。

tier 設計の完了チェック

• [ ] IAM Identity Center の全ユーザーに対して用途を確認し、Pro 必要/不要を判定した
• [ ] Q Apps 作成権限が必要なユーザー(業務部門リーダー・IT 担当)のみ Pro を割り当てた
• [ ] 「ひとまず全員 Pro」という暫定設定が残っていない
• [ ] 新入社員・退職者の tier 変更を IAM Identity Center 側の定期棚卸しプロセスに組み込んだ
• [ ] コスト最適化後の月次料金試算を記録し、上長・経営層へ説明できる状態にした

tier 変更の運用

ユーザーの役割が変わった場合(例: 一般社員 → 部門リーダーで Q Apps 作成が必要になった)は、IAM Identity Center のグループ管理から Pro グループへ移動することで tier が切り替わります。変更は翌課金サイクルから反映されます。

次のステップ

サブスクリプション設計が完了したら、Pro ユーザーが最初に活用する機能として Q Apps の展開設計(§3) に進みます。Q Apps のガバナンス設計は、Pro ライセンスを割り当てた業務部門リーダーが最初に体験する機能です。早期に展開することで、組織全体の Q Business 活用を促進できます。

3. Q Apps — ノーコード生成AIアプリの展開とガバナンス

3-1. Q Apps の作成とライブラリ共有

Q Apps は Amazon Q Business 上で動作するノーコードの生成 AI アプリケーション構築・共有機能です。一般提供(GA)済みで、業務ユーザー自身がプログラミング知識なしにインタラクティブなアプリを作成・公開できる。作成と実行には Pro tier が必要であり、Lite ユーザーはライブラリに公開された既存アプリも利用できない。

作成アプローチ — 会話生成 vs フォーム定義

会話からのワンクリック生成は最も手軽なアプローチです。Q Business との会話中に「この会話からアプリを作成(Create app from conversation)」を選択すると、対話内容を解析して Q App の骨格が自動的に生成される。繰り返し行っている定型的な問い合わせパターンをアプリ化する出発点として最適です。生成されたアプリはそのまま公開でき、カードを追加・削除して調整もできます。

フォーム UI のゼロ定義では、空白のキャンバスにカードを追加しながら構築する。利用可能なカード種別を以下に整理する。

カードを組み合わせることで、「人事規則 FAQ アプリ」「製品仕様書の要約アプリ」「IT サポートチケット起票アプリ」のような用途特化型アプリを標準化できる。現場部門が繰り返すルーチン的な問い合わせをアプリとして封じ込めることで、Q Business の活用度が部門間で均一化される効果がある。

ライブラリへの公開とタグ管理

作成済みの Q App は組織のライブラリへ公開する。公開時にタグ(例: 「人事」「法務」「IT サポート」「プロジェクト管理」)を付与しておくと、他の Pro ユーザーがライブラリ内でカテゴリ絞り込み検索できる。タグは複数付与可能で、業務ドメインと対象ユーザー層(「マネージャー向け」「営業向け」)を組み合わせたラベリングが検索性を高める。

ライブラリは追加システムなしに現場展開できる配布チャネルです。IT 管理者が個々のアプリを展開する代わりに、現場の Pro ユーザー自身がアプリを作成・公開する分散型の開発体制が実現する。ただし誰でも公開できる状態では品質管理や情報漏洩のリスクが生じるため、次節で述べる管理者ガバナンスが必要になる。

アクセス制御とガードレールの継承

Q Apps は Q Business アプリケーションのアクセス制御リスト(ACL)とガードレール設定をそのまま引き継ぎます。特定のデータソースへのアクセス権を持たないユーザーが Q App を通じて問い合わせても、対象データは回答に含まれません。設定済みのトピックブロックやコンテンツフィルタリングルールも Q Apps の出力へ適用されます。既存のガバナンスが追加のセキュリティ設定なしで Q Apps にも自動的に機能する点は、IT 管理者が現場での Q Apps 展開を承認しやすくする重要な特性です。

3-2. 管理者ガバナンス(Verified / ラベル / 有効化制御)

Q Apps のガバナンスは、アプリの品質管理・分類・ユーザー操作権限の 3 層で構成される。

アプリ検証(App Verification)と Verified バッジ

管理者はライブラリ内のアプリを個別に審査し、品質・セキュリティ基準を満たしたアプリに「Verified(検証済み)」バッジを付与できる。エンドユーザーはバッジの有無を目印に、組織として承認されたアプリと個人作成のアプリを区別できる。Verified バッジは信頼性の証明として機能し、野良アプリが混在するライブラリ内でも安全なアプリを識別しやすくする。

バッジの付与・剥奪は管理者のみが実行できる。定期的にライブラリをレビューし、利用されていないアプリや情報が古くなったアプリを非公開化または削除することで、ライブラリの品質を維持する運用が推奨される。

カスタムラベルによる分類管理

カスタムラベルは、組織固有の分類体系でアプリをタグ付けする仕組みです。管理者が「承認済み」「パイロット中」「非推奨」「部門限定」などのラベルを定義し、各アプリに付与する。利用者はライブラリでラベルによるフィルタリングを行え、目的のアプリを素早く見つけられる。タグが業務ドメイン(人事・法務など)を表すのに対し、カスタムラベルはライフサイクルや承認状態を表す運用で両者を補完させるのが機能的に分かりやすい。

Web Experience ユーザーの Q Apps 操作権限制御

管理者は Q Business の Web Experience 設定で、ユーザーグループごとの Q Apps 操作権限を制御できます。主な設定項目は以下の 2 つです。

Q Apps 作成の有効化・無効化
作成を無効化すると、対象のユーザーグループはライブラリにある既存アプリを実行できるが、新規アプリの作成・ライブラリ公開はできなくなる。パイロット展開の初期段階で特定のアプリ作成者グループのみへ作成権限を付与し、品質確認後に全社展開する段階的な導入計画として有効です。

Q Apps 実行の有効化・無効化
実行を無効化すると、対象ユーザーには Q Apps タブ自体が表示されなくなる。Q Apps 機能を特定の部門や役割に限定展開したい場合、または機能展開の準備が整うまでは一切露出させたくない場合に使用する。

Q Apps メトリクスと利用状況の可視化

Q Apps の利用状況は Analytics dashboard の Q Apps 専用タブで確認できる。アプリごとの実行回数・ユニークユーザー数・週次利用トレンドなどのメトリクスが可視化される。このデータを活用して、現場に定着しているアプリと使われていないアプリを特定する。利用率の高いアプリは Verified バッジを付与してさらに普及を促進し、利用率が低いアプリは現場ヒアリングを行ってカードの見直しやユースケースの再設計を検討する。Q Apps の Analytics は追加コストなしにコンソールで確認できる。

4. カスタムプラグイン深掘り — OpenAPI 設計・認証・アクション設計

4-1. OpenAPI スキーマと description 設計(アクション選択精度)

カスタムプラグインの中核は「Q Business が自然言語から正しいアクションを選択する精度」です。この選択精度を決定するのが、OpenAPI スキーマの description フィールドと operationId の設計品質です。

Q Business のアクション選択メカニズム

ユーザーがプラグイン対応のリクエストを入力すると、Q Business は登録された OpenAPI スキーマ内の全アクションの description を参照し、最も意図に合ったエンドポイントを選択して API を呼び出す。description が曖昧であれば誤ったアクションが実行され、description が具体的であれば多様な言い回しのリクエストにも適切に対応できる。

description 設計のベストプラクティス

動詞主体の具体的記述が最も効果的です。

良い記述例:

"Retrieve a Jira issue by issue key (e.g. PROJ-123) to check its current status,
assignee, priority, or comments."

避けるべき記述例:

"Get issue."

効果的な description を書くための 3 つのポイントを以下に示す。

• ユーザーが実際に使いそうな言い回しを description にパラフレーズして含める
• 具体的な入力例(issue key の形式など)を記述してアクション特定精度を上げる
• 「いつこのアクションを使うべきか」の判断文脈を 1〜2 文で添える

operationId の命名規約も選択精度に寄与する。get_issue・create_issue・update_issue のように動詞+目的語の形式で統一し、全アクション間で重複を避ける。

エンドポイント分割設計 — 1 プラグイン = 1 責務

複数の操作を 1 つのエンドポイントに詰め込む設計はアクション選択精度を著しく低下させる。「create or update」「search and filter」のような複合責務を 1 つのアクションに持たせると、Q Business がどちらを操作すべきか判断しにくくなる。エンドポイントは操作ごとに分割し、1 つのエンドポイントは 1 つの責務のみを担う設計を徹底する。

1 アプリに登録できるプラグインは最大 3 個(Pro tier)の制約があるため、プラグイン単位の機能スコープを事前に設計しておくことが重要です。例えば Jira 連携プラグインは「課題の検索・取得」「課題の作成」「課題の更新」を 3 つの別アクションとして 1 プラグインに定義し、ServiceNow 連携を別プラグインとして切り出す設計が現実的です。

Jira 連携の上級設計

カスタムフィールドマッピングでは、OpenAPI スキーマの requestBody に Jira のカスタムフィールド(customfield_XXXXX)パラメータを定義し、description に「Sprint への割り当てに使用する」「ストーリーポイントを設定する」と明記する。Q Business がスプリント割当や見積もりの文脈でこのパラメータを活用できるようになる。

JQL 検索アクションの設計では、JQL 構文の具体例を description に含めることでクエリ精度が向上する。記述例: "Execute a Jira issue search using JQL syntax. Example: project = PROJ AND status = 'In Progress' AND assignee = currentUser()" のように、実際の構文例を埋め込むと Q Business が JQL クエリを正確に組み立てやすくなる。

ServiceNow 上級設計

承認フローをプラグインに組み込む場合、承認依頼の作成と承認状態の確認を別アクションとして分割設計する。

1 つのアクションに複数の操作を持たせると選択精度が低下するだけでなく、デバッグも困難になります。アクションの境界を「1 操作 = 1 HTTP メソッド + 1 エンドポイント」で設計することが保守性の高いプラグインの基本です。

エラーハンドリングとフォールバック設計

OpenAPI スキーマの responses に 4xx・5xx のエラーレスポンス定義を追加しておくと、Q Business がエラー時にユーザーへ適切な説明を返しやすくなる。特に 400 Bad Request には具体的なエラーメッセージスキーマを定義し、Q Business がエラー内容をユーザーに伝えられるよう設計する。

タイムアウトはカスタムプラグインの呼び出し先エンドポイント側で制御する。外部 API のレイテンシが高い場合は、エンドポイント側のタイムアウト値を Q Business セッションのタイムアウトより短く設定する。プラグイン実行が失敗した場合、Q Business は通常の検索にフォールバックする動作がデフォルトで機能するため、プラグイン障害が致命的なサービス停止になりにくい点はプラグイン設計の安全網として機能する。

4-2. 認証設定の本番運用(OAuth2 / API key / Secrets Manager)

カスタムプラグインの本番運用では、外部 API へのアクセス情報を安全に管理する体制が必須です。

認証方式の選定基準

Q Business カスタムプラグインがサポートする認証方式は 3 種類ある。用途に応じて選定し、本番環境では必ず適切な方式を採用する。

No Auth(認証なし)は開発・テスト環境、または VPC 内の社内 API で追加認証が不要なエンドポイントへのアクセスに限定する。本番環境で外部 SaaS に接続する用途には使用しない。

API Key 方式は固定のアクセスキーを持つ外部サービスとの連携に使用する。プラグイン設定画面へのキーの直接入力は禁止されており、必ず AWS Secrets Manager にシークレットとして格納した上で、その ARN をプラグイン設定の参照フィールドに入力する。

OAuth 2.0 方式は、ユーザーごとに異なるアクセス権限が必要なサービス(Jira Cloud・ServiceNow など)に適用する認証フローです。クライアント ID とクライアントシークレットを Secrets Manager で管理し、Q Business が実行時に自動的にトークンを取得する。

AWS Secrets Manager との統合

シークレット管理の一元基盤として Secrets Manager を使用する。Secrets Manager に登録したシークレットの ARN をプラグイン設定の指定フィールドに入力すると、Q Business は API 呼び出し時に Secrets Manager から最新値を自動取得する。

Secrets Manager の自動ローテーションを有効化することで、定期的なシークレットの更新を自動化できます。ローテーション後も Q Business は次回の API 呼び出し時に新しい値を取得するため、プラグイン設定の手動更新は不要です。

Q Business が Secrets Manager にアクセスするには、Q Business サービスロールに secretsmanager:GetSecretValue 権限が必要です。リソース指定は特定の Secret ARN に絞ることで最小権限の原則を維持する。

エンドポイントのネットワーク要件

カスタムプラグインが呼び出す外部エンドポイントは、Q Business からアクセス可能な状態でなければならない。

パブリックエンドポイントの場合は、外部 SaaS(Jira Cloud・ServiceNow SaaS 版など)への標準的なインターネット経由アクセスで動作します。追加のネットワーク設定は不要です。

プライベートエンドポイントへのアクセスが必要な場合は、VPC connector を設定して Q Business から VPC 内のリソースへのプライベート接続を確立する。オンプレミスに設置した ServiceNow や自社開発 API が VPC 内に存在する場合の構成です。VPC connector の設定には、対象 VPC・サブネット・セキュリティグループの指定が必要であり、ネットワークチームとの連携が必要になるケースが多い。

重要な制約事項の再確認

制約を事前に把握した上でプラグイン設計を進めることで、本番リリース直前に仕様上の制約に直面するリスクを回避できる。

5. ガードレール本番チューニング — グローバル/アプリ単位制御と運用

5-1. トピックブロック/ブロックワードの運用設計

Amazon Q Business のガードレールは「グローバルコントロール」と「アプリ単位制御」の2層構造です。本番チューニングでは「何をどの層で制御するか」の設計判断が運用コストに直結します。

グローバルコントロール vs アプリ単位制御 — 設計判断軸

「どの部門・用途であっても許してはならない」制約(個人情報漏洩リスク、法令違反、機密カテゴリへの言及)はグローバルコントロールに集中させます。一方「営業部門用アプリでは競合他社比較を禁止する」「HR アプリでは給与水準の具体的な回答を制限する」といった業務固有の制約はアプリ単位制御に委ねます。

この2層設計により、グローバル設定の変更が全アプリに即時反映され、アプリ単位の実験的設定が他アプリに波及しないという安全な運用環境が整います。

パイロット運用から本番への段階的厳格化

ガードレールをパイロット運用から本番に移行する際、最大の失敗パターンは「最初から厳格な設定を全社展開する」ことです。過剰ブロックは業務上必要な質問まで遮断し、Q Business の利用率低下を招きます。推奨される段階的厳格化の手順は以下の通りです。

1. パイロット期間(1〜2週間): 限定ユーザーに展開し、ブロック発動ログを収集する。拒否メッセージは「詳しくは〇〇部門にお問い合わせください」のような誘導型にする
2. ログ分析フェーズ: CloudWatch Logs Insights でブロック発動クエリを精査し、「誤検知(業務上有効な質問が誤ってブロックされた)」と「正検知(意図通りブロックできた)」を分類する
3. ブロックリスト精緻化: 誤検知が多いトピックブロックは「除外フレーズ」を追加し、正検知に集中するよう調整する
4. 迂回テスト: ブロック対象の言い回しを変えた質問で迂回できないか検証する。迂回パターンが見つかればトピック定義のフレーズを拡充する
5. 本番展開: パイロット結果を反映した設定で全社展開し、継続モニタリングに移行する

拒否メッセージ設計 — ユーザーを適切な手段に誘導する

ブロック時の拒否メッセージは、ユーザーを別の適切な手段へ誘導する文言にします。「回答できません」で終わるメッセージより「この内容については〇〇ポータルをご参照ください」という形式がユーザーの離脱を防ぎます。部門別アプリでは、拒否メッセージに問い合わせ先のリンクを含めることで、ユーザー体験を損なわずに制約を伝えられます。

引用必須化による信頼性確保

グローバル設定で「回答にはソース文書の引用を含める」を有効にすることで、全アプリで統一した回答信頼性基準を確保できます。引用が表示されない場合、ユーザーは回答の根拠を確認できず、誤情報を鵜呑みにするリスクが高まります。引用必須化はガードレール設定の中でも費用対効果が最も高い設定の一つです。

ブロックワードの運用設計

ブロックワードはトピックブロックより単純ですが、単語ベースの完全一致であるため意図しないブロックが起きやすい点に注意が必要です。「給与」という単語を単独でブロックすると「給与計算システムの使い方」といった正当な業務質問もブロックされます。ブロックワードは文脈に関わらずブロックが適切な語(外部開示禁止のコードネーム・内部開発名等)に限定することを推奨します。

5-2. ブロック発動の監視と最適化ループ

CloudWatch ログ出力の設定

ガードレールのブロック発動を監視するには、まず Amazon Q Business の CloudWatch ログ出力を有効化します。コンソール → アプリケーション選択 → 「CloudWatch logging」セクションから会話ログと CloudTrail 監査ログを有効化してください。ブロック発動イベントは BlockedResponses として記録されます。

CloudWatch ログが有効化されると、以下のメトリクスを取得できます。

Logs Insights によるブロック傾向分析

CloudWatch Logs Insights で以下のクエリを実行すると、過去7日間のブロック発動パターンを把握できます。

fields @timestamp, queryText, blockReason, topicName
| filter eventType = "GUARDRAIL_BLOCK"
| stats count() as blockCount by topicName
| sort blockCount desc
| limit 20

このクエリで「どのトピックブロックが最も発動しているか」を把握し、意図しない誤検知が多いトピックについては定義の見直しを検討します。特定のトピックが突出してブロック数が多い場合は、定義フレーズが広すぎる可能性を疑います。

Analytics dashboard との連携

Amazon Q Business コンソールの Analytics dashboard では「Blocked queries」セクションでブロックワードを含んだクエリの傾向を視覚的に確認できます。CloudWatch の詳細ログと組み合わせることで、次の判断が可能になります。

• ブロック過多(業務質問が遮断される): トピックブロックの定義フレーズを絞り込み、除外条件を追加する。またはアプリ単位制御に降格させ、グローバルコントロールから外す
• 迂回多発(ブロック設計をすり抜ける): トピック定義のフレーズ群を拡充し、言い換えパターンをカバーする

フォールバックポリシーの閾値設計

ガードレールの「Response settings」では、LLM が回答に自信を持てない場合のフォールバック動作を設定できます。閾値を厳しく設定しすぎると、本来回答できるはずの業務質問まで「回答できません」として処理されます。推奨設定: パイロット期間は閾値を緩めに設定して多く回答させ、ハルシネーションが実際に問題化した場合のみ閾値を厳格化します。閾値変更のたびにブロック率をモニタリングし、業務 Q&A の完遂率が低下していないか確認します。

運用フィードバックループの確立

ガードレールの運用は「設定して終わり」ではなく、継続的なフィードバックループが必要です。

モニタリング(CloudWatch + Analytics) → 分析(誤検知/正検知/迂回パターン特定)
→ 調整(ブロックリスト精緻化/閾値変更) → 展開 → モニタリング

このループを月次で回すことで、ガードレールはユーザーの実際の利用パターンに追従し、業務を妨げない精度に進化します。運用チームが Analytics dashboard を定期的にレビューする仕組みを確立することが、このループを継続させる鍵です。

6. 検索精度評価・チューニング — relevance tuning と metadata boosting

6-1. relevance tuning の仕組み(native retriever)

Amazon Q Business の検索精度向上には relevance tuning(旧 metadata boosting)が有効です。relevance tuning は native retriever を使用しているアプリケーション限定の機能です。Kendra retriever を使用している場合は利用できないため、まず retriever の種別を確認してください。

relevance tuning の基本概念

Amazon Q Business は、ユーザーのクエリに対して関連文書を取得する際、デフォルトではコンテンツの意味的類似度(セマンティック検索)を主要スコアとして使用します。relevance tuning を使うと、document attribute(文書に付与されたメタデータフィールド)への重み付けを追加し、特定の属性を持つ文書を優先的にランキング上位に持ってくることができます。

たとえば _data_source_id(データソース識別子)への重み付けを調整することで、特定のデータソースからの文書を検索結果の上位に表示させることができます。

document attribute への重み付け設定手順

relevance tuning は Amazon Q Business コンソール → アプリケーション → Retriever → 「Relevance tuning」セクションから設定します。

実装上の注意点として、重み付けを設定する前に 各データソースのインデックスフィールドマッピングが正しく設定されていることを確認します。インデックスフィールドマッピングが未設定の属性は、重み付けを設定しても効果がありません。

検索精度を高めるメタデータ設計

relevance tuning の効果は、データソース同期時に付与するメタデータの質に依存します。実際の精度改善に効くメタデータ属性の例を示します。

メタデータ設計の段階でどの属性が検索精度に効くかを設計しておくことで、relevance tuning の効果を最大化できます。

カスタムシノニムの活用

Amazon Q Business では、業務固有の略称や同義語をシノニム辞書として登録できます(native retriever 対応確認要)。たとえば「QA→品質管理」「NDA→秘密保持契約」といったマッピングを定義することで、検索クエリの表記ゆれに対応し、同一文書への到達率を高められます。シノニム辞書は CSV 形式で作成し、データソース設定からアップロードします。登録後は次回インデックス同期時から反映されます。

6-2. recency boost と data source 優先度の設計

recency boost: 最新文書を優先する設定

recency boost は、文書の作成日(_created_at)または最終更新日(_last_updated_at)を基に、新しい文書ほどスコアをブーストする機能です。relevance tuning の設定画面から以下の期間を選択して適用します。

選択の目安: 回答の「鮮度」が重要な用途(技術情報・法改正対応文書等)には短期設定、長期的に参照される文書(社内規程・設計書等)には長期設定を適用します。

「古い文書がより正確」なケース(過去の契約書・アーカイブ事例)では recency boost は逆効果になります。文書の性質に合わせてデータソースごとに設定を変えることを推奨します。

data source 優先度: 最大5ソースへの優先度設定

Amazon Q Business では、アプリケーションに接続したデータソース(最大5つ)に対して、検索結果内での優先度(Priority)を段階的に設定できます。優先度が高いデータソースからの文書は、同等のセマンティックスコアを持つ他ソースの文書よりも上位に表示されます。

優先度設計の例

社内ヘルプデスク向けアプリを想定した場合の優先度設計例。

検索精度の測定方法

relevance tuning の効果を定量評価するには、以下の方法を組み合わせます。

1. Analytics dashboard の「未回答クエリ」レビュー: 検索結果が返せなかったクエリを確認し、対象文書のメタデータ設計またはデータソース接続を見直す
2. ユーザーフィードバック(サムアップ/サムダウン)の傾向分析: 低評価回答の共通パターン(特定のデータソース・文書タイプ・クエリ種別)を特定する
3. テストクエリセットの運用: 定期的に同一クエリ集を実行し、上位表示文書の変化を追跡する。relevance tuning 設定変更前後の比較が可能になる

文書取得に関するトラブルシュート

検索精度の問題として混同されやすいのが、ファイルの閲覧権限設定(ACL)に起因する問題です。以下の2パターンが典型的なトラブルケースです。

ケース1: 参照できるはずの文書が検索結果に出ない

データソース同期時のユーザー権限情報がインデックスに正しく反映されていないケースが多いです。対処方法は以下の通りです。

• データソースの「Access control」設定を確認し、ユーザー/グループのマッピングが IAM Identity Center のユーザー属性と一致しているか検証する
• データソースを「Full sync」で再同期し、権限情報をインデックスに強制更新する
• コンソールの「Data source sync history」でエラーログを確認し、特定ファイルやフォルダへの解決エラーがないか調査する

ケース2: 参照できないはずの文書が表示される

対象データソースの「Use ACL」設定が有効になっているか確認します。デフォルトで無効になっているデータソースタイプが存在するため要注意です。過去に「全員に公開」設定でインデックス同期した履歴がある場合は Full sync で再インデックスします。

7. 利用状況分析 — Analytics dashboard と QuickSight Q 連携

7-1. Analytics dashboard のメトリクスと会話インサイト

Amazon Q Business の Analytics dashboard は 2024年12月に一般提供(GA)開始された、
追加コストなしで利用できる管理コンソール上の分析機能です。「実際に誰が・どのように使っているか」を
定量で把握できるため、初期展開後の利用状況診断や継続的な改善計画の立案に欠かせない起点となります。

7-1-1. 4 種類のコアメトリクス

Analytics dashboard が提供する 4 種類のコアメトリクスを把握することで、
サービスの浸透度と品質を多角的に評価できます。

コンソール上では期間フィルタ(最大 90 日)をかけてグラフ表示できます。
部門別 web experience を複数運用している場合はアプリケーションごとに画面を切り替えて
メトリクスを確認してください。

会話数と会話あたりクエリ数を組み合わせることで、現状を 4 象限で診断できます。

7-1-2. 未回答クエリのレビューとデータギャップ特定

「未回答クエリ」はシステムが「回答できなかった」または「情報なし」として返したクエリの一覧です。
Analytics dashboard 上でそのリストをエクスポートし、以下の 3 パターンに分類することで
データギャップや改善優先度を特定できます。

パターン A: データソース不足
その質問に答えられるドキュメントがまだ接続されていません。
未回答クエリのキーワードを抽出し、対応するドキュメントが格納されたソースを特定して
Vol1 §3 の手順でコネクタを追加します。

パターン B: 同期遅延・ACL 問題
ドキュメントは存在するが正しく取り込まれていないケースです。
CloudTrail イベントと同期ログを照合し、ACL 継承エラーや権限設定のズレを修正します。
同期ジョブのステータスが FAILED または PARTIALLY_SUCCEEDED になっていないかを定期的に確認します。

パターン C: クエリのあいまいさ
検索意図が一般すぎて精度改善だけでは対処が難しいケースです。
ユーザー向けのプロンプトガイドやサンプルクエリ集を整備し、
より具体的な質問方法を案内します。

7-1-3. ブロックワード含有クエリの監査

ガードレールで設定したブロックワードがクエリに含まれた場合、
システムはそのクエリをフォールバックポリシーに基づき拒否または変更した応答を返します。
Analytics dashboard はブロックワード含有クエリ数とその内容を記録しているため、
次の 3 つの運用が可能です。

1. 過剰ブロックの検出
   業務上適切なはずのクエリが弾かれていないか確認します。
   業務文脈で正当なワードが誤ブロックされていないかを精査します。

2. ブロック率の週次追跡
   全クエリに対するブロック率を週次で追跡し、ブロックワード設定の有効性を測定します。
   ブロック率が想定より高い場合は §5-1 のトピックブロック閾値を見直します。

3. ガードレール調整の根拠化
   体感ではなく実データに基づいて §5 のチューニングを実施することで、
   「なぜこの設定にしたか」を監査ログとして残せます。

ブロック率が高止まりしている場合は §5-1 のトピックブロック設定を見直し、
拒否メッセージをより明確にして利用者の混乱を防ぎます。

7-1-4. Q Apps メトリクス

Q Apps の利用状況も Analytics dashboard で確認できます。
アプリ別の実行回数・ユニークユーザー数を把握することで、
「よく使われるアプリ」と「作成されたが放置されているアプリ」を識別できます。

放置アプリが多い場合は §3-2 で設定した管理者ガバナンス
(Verified バッジ / カスタムラベル) を活用し、推奨アプリを前面に出すライブラリ整理を検討します。
特定の Q Apps だけが突出して使われている場合は、そのアプリを「公式推奨アプリ」として
ハイライト表示を設定し、利用者の導線を整備します。

7-2. 改善フィードバックループ(分析 → コネクタ/精度/ガードレール改善)

Analytics dashboard の真価は「見える化」だけでなく、
その結果を改善アクションへと繋げるフィードバックループにあります。
3 軸で週次または月次の改善サイクルを設計することを推奨します。

7-2-1. 未回答クエリ → データソース追加・同期修正

未回答クエリを起点とした改善フローは以下のように設計します。

未回答クエリ一覧エクスポート
 ↓
分類: データソース不足 / 同期問題 / クエリあいまい
 ↓
データソース不足 → コネクタ追加 (Vol1 §3 参照)
同期問題  → ACL 設定確認・クロールスケジュール修正
クエリあいまい  → relevance tuning またはユーザー教育
 ↓
1〜2 週後に同カテゴリの未回答クエリ数が減少したか確認

このループを 1〜2 ヶ月継続するだけで、初期展開時に答えられなかった業務質問の多くへ回答できるようになります。

7-2-2. 低精度クエリ → relevance tuning 調整

「回答は返るが的外れ」と感じる場合は §6 の relevance tuning を調整します。
Analytics ではユーザーのフィードバック(👍/👎)も集計されるため、
ネガティブフィードバックが多い質問カテゴリを特定して優先的に対処できます。

ユーザーフィードバック(👎)が多いクエリを抽出
 ↓
そのクエリが参照するドキュメントの document attribute を確認
 ↓
relevance tuning でそのドキュメントカテゴリの重みを調整
 ↓
2 週間後の👎率を再確認

ユーザーフィードバックが集まるまでは、管理者が代表的なクエリを手動で評価し、
「正しく答えられているか」を確認する定性チェックを並行して実施します。

7-2-3. 誤ブロック → ガードレール調整

ブロックワード含有クエリのレビューで業務上適切なクエリが誤ブロックされていた場合は、
§5-1 のブロックワードリストまたはトピックブロックの条件を精緻化します。

1. 誤ブロッククエリのパターンを抽出する
2. ブロックワードのうち文脈依存で問題ない単語をリストから除外する
3. トピックブロックの「例文」を追加して判定精度を高める
4. 1 週間後のブロック率と誤ブロック数を再確認する

この改善ループを §5・§6・§7 の 3 軸で回すことで、運用開始直後は荒削りだった
Q Business 環境が次第に「使われ続ける」高品質な基盤へと成長します。

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

8-1. 詰まりポイント

本番運用で実際に遭遇しやすい 8 つの詰まりポイントと対処法をまとめます。

詰まり①: Q Apps で作成したアプリが共有できない

症状
Q Apps でアプリを作成したが、他のユーザーのライブラリに表示されない。
組織内で見つからないと報告を受ける。

原因
– web experience の admin controls で「ライブラリへの公開」が無効になっている
– 管理者の承認(Verified バッジ)が未取得のアプリはライブラリへの公開対象外になっている

対処
1. Q Business コンソール → Applications → [アプリ名] → Q Apps → admin controls を開く
2. 「Allow users to publish Q Apps to the library」が無効であれば有効化する
3. 承認フローを設ける場合は管理者が Verified バッジを付与する運用を確立する
4. ライブラリ公開後、対象ユーザーのロールに Q Apps 実行権限が付与されているか確認する

詰まり②: カスタムプラグインの OpenAPI スキーマを S3 に置いたが認識されない

症状
カスタムプラグイン作成時に S3 バケットの OpenAPI スキーマ URL を指定したが、
「スキーマを読み込めない」エラーが発生する。

原因
– Q Business サービスに S3 バケットへの読み取りアクセス権限が付与されていない
– バケットポリシーがパブリックアクセスをブロックしており、サービス側からアクセスできない

対処
1. S3 バケットポリシーに Q Business サービスプリンシパルへの s3:GetObject 許可を追加する
2. バケットはプライベートのまま維持し、IAM ロール経由で読み取りを許可する
3. スキーマファイルが有効な OpenAPI 3.0 形式であることをローカルで検証してから再アップロードする

詰まり③: Relevance tuning を設定したが効果が出ない

症状
document attribute に重みを設定したが、検索結果のランキングが変わらない。
設定前後で回答の質に差が感じられない。

原因
– relevance tuning は native retriever 限定の機能であり、Enterprise index (Kendra ベース) を
使用している環境には適用されない
– attribute のインデックスフィールドマッピングが正しく設定されていない

対処
1. Q Business コンソールで使用中のリトリーバーが「Amazon Q Business native retriever」
であることを確認する
2. Enterprise index 使用中の場合は native retriever への切り替えを検討する
3. attribute のインデックスフィールドマッピングが正しく設定されているか再確認する

詰まり④: ガードレールのトピックブロックが想定外のクエリも弾く

症状
特定のトピックをブロック設定したところ、業務上必要なクエリまで
拒否されてしまう。

原因
– トピックブロックの説明文が広義すぎるため、関連するすべてのクエリが対象に含まれる
– フォールバックポリシーの拒否閾値が低すぎる

対処
1. トピックブロックの「定義文」を具体的に絞り込み、ブロック対象の範囲を明確化する
2. 「例示クエリ」を追加してシステムがブロック対象をより正確に学習するよう補助する
3. §7-1-3 の Analytics dashboard でブロック率を監視しながら段階的に閾値を調整する
4. 部門単位で web experience を分ける場合は、部門ごとに異なるガードレール設定を適用する

詰まり⑤: Analytics dashboard で「未回答クエリ」が多い

症状
展開後、Analytics dashboard の未回答クエリ数が全体の 30% 以上を占めており、
利用者から「使えない」との声が上がっている。

原因
– 未回答クエリの多くがデータソースの同期失敗に起因している
– ACL 継承エラーにより、ドキュメントは存在するが検索インデックスに含まれていない

対処
1. コンソールでデータソースの同期ジョブステータスを確認し、FAILED なら原因ログを精査する
2. IAM Identity Center と各データソースの ACL 継承設定を再確認する
3. 手動で同期を再実行し、同期後に同じクエリが回答できるようになるか確認する
4. 短期的にはデータソースの自動同期頻度を高め、鮮度を保つ設定に変更する

詰まり⑥: Pro tier に切り替えたのにカスタムプラグインが使えない

症状
ユーザーを Lite から Pro に変更したはずなのに、カスタムプラグインの実行ボタンが
表示されない、または権限エラーが発生する。

原因
– IAM Identity Center のユーザーグループ割り当てが更新されていない
– web experience 側でカスタムプラグインの使用を許可するロール設定が未完了

対処
1. IAM Identity Center → Applications → [Q Business アプリ] → Assigned users and groups を開く
2. 対象ユーザーが Pro ロールのグループに割り当てられているか確認し、必要であれば再割り当てする
3. 変更後、ユーザーはブラウザのキャッシュをクリアして Q Business にサインインし直す
4. プラグインが特定の web experience にのみ有効化されている場合は、
ユーザーが正しい web experience にアクセスしているか確認する

詰まり⑦: Q Apps 作成時に「権限がない」エラー

症状
一般ユーザーが Q Apps を作成しようとすると権限エラーが表示される。

原因
– web experience で Q Apps の作成機能が無効化されている
– ユーザーが Q Apps 作成に必要な Pro ライセンスを持っていない

対処
1. Q Business コンソール → Applications → [アプリ名] → web experiences → [対象 WE]→ Q Apps settings を開く
2. 「Allow users to create Q Apps」が有効化されているか確認し、無効であれば有効化する
3. ユーザーが Pro サブスクリプションであることを IAM Identity Center で確認する
4. 特定グループのみ作成を許可する場合は、IAM Identity Center のグループポリシーで制御する

詰まり⑧: Analytics dashboard のデータが表示されない

症状
Q Business を展開してしばらく経つが、Analytics dashboard にグラフや数値が何も表示されない。

原因
– Analytics dashboard はリアルタイムではなく、データ収集開始から最大 24 時間の遅延がある
– 展開直後や検索利用が少ない場合はグラフが空白になることがある

対処
1. 展開から 24 時間以上経過しているか確認する。経過していない場合は翌日に再確認する
2. 実際に会話を数件実行し、データが蓄積されてから再度 dashboard を確認する
3. それでも表示されない場合は IAM ロールに CloudWatch Logs への書き込み権限が
付与されているか確認する

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

本番運用でよく陥るアンチパターンと、その正解パターンを対比形式で整理します。

❌ アンチパターン1: Q Apps で builtin plugin をそのまま呼び出すアプリを作る

問題点
builtin plugin (Jira, ServiceNow 等) に特定操作を頼り切った Q Apps は、
プラグイン設定変更や認証切り替えの影響を直接受けて動作不能になります。
また、業務フローに特化した体験が生まれず「ただ検索できるアプリ」にとどまりがちです。

✅ 正解パターン
カスタムプラグインと組み合わせて業務フロー特化アプリを設計します。
例えば「社内規定 Q&A → 申請フォーム起動 → Jira チケット作成」という一気通貫フローを
1 つの Q Apps にまとめることで、利用者の操作ステップを削減します。

❌ アンチパターン2: ガードレールを全社同一設定で適用する

問題点
法務部門・営業部門・一般社員で「ブロックすべき話題」は異なります。
単一の厳格なガードレールで全社をカバーしようとすると、特定部門で必要な
情報アクセスがブロックされ、「使えない AI」というレッテルが貼られます。

✅ 正解パターン
部門別の web experience を作成し、ガードレールをアプリ単位にカスタマイズします。
部門のユースケースに合わせてトピックブロックの「例示クエリ」も記述し、
判定精度を部門ごとに最適化します。

❌ アンチパターン3: Relevance tuning の重み付けを勘で設定する

問題点
直感だけで recency boost を最大にすると、古いドキュメントが軒並み検索から排除されます。
年次更新される規定書類が「古い」と判定されて表示されなくなる事例があります。

✅ 正解パターン
Analytics dashboard で未回答クエリと低評価クエリを分析してから
優先データソースや attribute 重みを設定します。変更ごとに Analytics で効果を検証する
サイクルを作り、「なぜこの重みにしたか」を記録して属人化を防ぎます。

❌ アンチパターン4: Pro プランを全ユーザーに適用してコスト超過

問題点
Q Apps やカスタムプラグインを使う機会がほぼない一般社員に
Pro ($20/user/月) を割り当て続けると、利用実態に見合わないコストが発生します。
100 人規模でも Pro/Lite の使い分けで月数十万円以上の差が生じます。

✅ 正解パターン
役割別にライセンスを割り当てます。一般情報検索のみの社員は Lite ($3/user/月)、
管理者・ヘビーユーザー・プラグイン/Q Apps 作成者のみ Pro に絞ります。
§2-2 の設計フローに沿って利用機能要件ベースでユーザーを分類してから移行します。

❌ アンチパターン5: Q Business Vol1 と Vol2 を別々の導入プロジェクトとして計画する

問題点
Vol1(接続基盤)と Vol2(運用改善)を独立したプロジェクトで進めると、
Vol1 で設定したコネクタ・ガードレール・IAM 設定が Vol2 フェーズで要件変更を余儀なくされ、
手戻りが大きくなります。

✅ 正解パターン
Vol1(接続基盤) → Vol2(運用改善)を段階的ロードマップで一体設計します。
Vol1 のコネクタ設計・IAM Identity Center 構成・ガードレール基礎設定が
Vol2 の Q Apps / プラグイン深掘り / Analytics 活用の前提になることを考慮して
最初から拡張性を持たせて設計します。

❌ アンチパターン6: Analytics の未回答クエリを放置する

問題点
Analytics dashboard を「見るだけ」にして改善に活かさないと、
利用者の不満は蓄積し続けます。検索精度が低いと判断したユーザーが利用をやめ、
会話数が減少するという負のサイクルに入ります。

✅ 正解パターン
§7-2-1 の改善フィードバックループを月次で回します。未回答クエリの分類と
データソース追加・同期修正を定型作業として運用カレンダーに組み込みます。

8-3. まとめと Vol3 予告

Vol2 で習得した運用改善ループ

本記事では、Vol1 で構築した Amazon Q Business 企業検索基盤を
「使われ続ける」ものに育てるための 6 つの運用改善ステップを解説しました。

運用改善の「3 軸ループ」を定着させる

Vol2 のコアメッセージは 「分析 → 特定 → 改善 → 検証」のループを定型化することです。

• Analytics dashboard: 週次で会話数・未回答クエリ・ブロック率を確認する
• relevance tuning: 月次でフィードバックデータを元に重み調整する
• ガードレール: 四半期ごとにブロック発動ログをレビューしてトピックブロックを精緻化する

この 3 軸が定型の運用タスクとして回り始めると、Q Business は「初期展開して放置」ではなく
「継続的に改善される生きた基盤」へと変貌します。
Q Apps が現場に浸透し、Analytics が週次のレビュー習慣となったとき、
Vol1 で苦労した初期構築の価値が初めて最大化されます。

Vol3 予告: 大規模運用・マルチテナント・監視設計

次の Vol3 では、数百〜数千ユーザー規模での Amazon Q Business 大規模運用に踏み込みます。
複数部門・複数 web experience のマルチテナント設計、
IAM Identity Center と SCIM プロビジョニングを組み合わせた自動ユーザー管理、
CloudWatch による Q Business メトリクスの監視ダッシュボード構築などを取り上げる予定です。
Vol2 の「運用改善ループ」を組織横断で仕組み化するフェーズとして位置づけます。

Vol1: 企業検索基盤の構築編に戻る