Amazon Q in Connectのエージェント支援機能において、ナレッジアクセス制御はエージェント単位では不可です
困っていること
Amazon Q in Connect のコンテンツセグメンテーション機能を使って、エージェント単位でナレッジベースのアクセス制御を実装できるか確認したいです。
背景・目的
コンタクトセンターでは、エージェントを複数のクラス（権限レベル）に分類して運用しており、ナレッジベースへのアクセス制御が必要です。
理由は以下の通りです。
- 機密情報や特別対応手順へのアクセス制限（セキュリティ・コンプライアンス）
- エージェントのスキルレベルに応じた適切な情報提供（品質担保）
- 必要最小限の情報のみ表示することによる業務効率化
そのため、エージェントのクラスに応じて参照可能なドキュメントを制限したいと考えています。
理解している内容
以下の機能と実装方法について理解しています。
- データソースにタグを付与し、問い合わせに関連するドキュメントを絞り込む「コンテンツセグメンテーション」機能が利用可能
- フロー内でLambdaを呼び出し、UpdateSession APIでタグフィルタリングを実行することで絞り込みが可能
参考資料：
- Amazon Q in Connectのコンテンツセグメンテーションによるタグを使用したナレッジの絞り込みを試してみた | DevelopersIO
- Content Segmentation - Amazon Q in Connect Workshop
確認したいこと
通話中のフロー内でUpdateSession APIを使用する際、エージェントごとに異なるタグフィルタを適用し、参照可能なドキュメントを個別に制御することは可能でしょうか。
回答
結論：エージェント単位でのタグフィルタ適用はできません。ただし、キュー単位での適用は可能です。
UpdateSession APIによるタグフィルタの適用は、問い合わせのセッション単位で行われます。
問い合わせフロー内で処理している段階では、問い合わせはまだキューにルーティングされておらず、どのエージェントが対応するか決まっていません。そのため、エージェント単位でのタグフィルタ設定はできません。
代替案：キュー単位での制御
ただし、エージェントは必ずいずれかのキューに配置されています。
そのため、問い合わせフローでルーティング先のキューを決定する際に、UpdateSession APIを呼び出してセッションにタグフィルタを適用することで、そのキューで問い合わせを処理するエージェントは、フィルタリングされたコンテンツのみを参照できるようになります。
エージェント単位にタグフィルタを適用することはできませんが、セッションがルーティングされるキューごとに適用するタグフィルタを切り替えるよう問い合わせフローを構成することで、間接的にアクセス制御を実現できます。
具体的なフロー構成
問い合わせフローでは、以下のような構成になります。
- キュー転送前に条件分岐を実行（例：顧客の問い合わせ内容やIVR選択に基づく分岐）
- 各分岐先で、Lambda関数を呼び出してUpdateSession APIを実行し、分岐先ごとに異なるタグを適用
- タグ適用後、それぞれ対応するキューに転送
例えば、一般的な問い合わせは「一般エージェントキュー」へ、機密情報を含む問い合わせは「上級エージェントキュー」へルーティングする場合、以下のように設定します。
- 一般エージェントキューへの転送前：基本レベルのナレッジのみ表示されるタグを適用
- 上級エージェントキューへの転送前：基本レベル＋機密レベルのナレッジが表示されるタグを適用
この構成により、キュー単位で間接的にエージェントのクラスに応じたアクセス制御を実現できます。
考慮点
ただし、この方法には以下などの考慮点があります。
- 同一キューに異なる権限レベルのエージェントを配置できず、柔軟な運用ができない
- キューごとにエージェントを固定配置するため、リソース配分が非効率（混雑キューがあっても他キューの空きエージェントが対応不可）
- 権限レベルの追加・変更時にキュー作成やフロー修正が必要で、管理・拡張コストが高い
最後に
Amazon Q in Connectのコンテンツセグメンテーション機能では、現時点では、エージェント単位での直接的なタグフィルタリングはできません。
しかし、キュー単位での制御を活用することで、エージェントのクラス（権限レベル）に応じたナレッジベースへのアクセス制御を実現できます。具体的には、権限レベルごとにキューを分け、各キューにルーティングされる際に適切なタグフィルタを適用する問い合わせフローを構成することで、間接的にアクセス制御を実現できます。
柔軟性の欠如やリソース配分の非効率性などのデメリットもあるため、自社のコンタクトセンターの運用要件や規模を踏まえて、この方法が適切かどうかを検討してください。
