Amazon Quick の Chat Agent や Space で「共有したのに見えない」を防ぐ権限設計ベストプラクティス

クラウド事業統括本部の石川覚です。Amazon Quick では、従来の Amazon QuickSight から引き継いだダッシュボードやデータセットなどのアセットに加えて、スペース、ナレッジベース、チャットエージェントといった新しいリソースを扱えるようになりました。ところが、これらの新しいリソースは従来の共有フォルダによる一括権限管理の対象外であり、それぞれ個別に権限付与が必要です。

この違いを理解しないままカスタムチャットエージェントをチームに展開すると、「エージェントは共有したのに、スペース内のダッシュボードが参照できずエラーになる」といった問題が発生します。本記事では、この問題が起こる仕組みを整理し、Quick Suite 管理者が押さえておくべき権限設計のベストプラクティスを解説します。

最初に結論

先に結論をまとめると、以下のとおりです。

• スペース、ナレッジベース、チャットエージェントは共有フォルダの権限継承の対象外であり、リソースごとに Owner / Viewer を個別に付与する必要があります
• スペースを共有しても、中にリンクされたダッシュボードやナレッジベースへのアクセス権は自動付与されません。 チャットエージェントの回答も、利用者本人が持つ権限の範囲で評価されます
• 「共有したのに見えない」を防ぐには、エージェントを利用するグループに対して、エージェント本体、リンク先スペース、スペース内のアセット、ナレッジベースを同じグループへ揃えて共有します
• 公開前に、権限のないテストユーザーで Resource unavailable が出ないことを確認します

以降で、この結論に至る仕組みと運用のポイントを順に解説します。

従来アセットと新リソースの権限モデルの違い

Amazon Quick の権限管理は、リソースの種類によって大きく 2 つのモデルに分かれます。

**従来のアセット（ダッシュボード、分析、データセット、データソース、トピック）**は、共有フォルダに追加すればフォルダの権限を継承します。なので、共有フォルダを部門やチームのグループに共有しておけば、アセットを追加するだけで権限管理が完結しました。

一方、スペース、ナレッジベース、チャットエージェントは共有フォルダに追加できないため、リソースごとに Owner または Viewer の権限をユーザーやグループへ個別に付与する必要があります。

「共有したのに見えない」が起こる仕組み

スペースの共有は、中のリソースへのアクセス権を付与しない

リソースへのアクセス権を持たないユーザーは、スペース内のトピックやダッシュボードにアクセスできないという制限があります。スペースを共有しても、その中のアセットへのアクセス権が自動的に付与されることはありません。

つまり、スペースを Viewer 権限で共有しても、スペースにリンクされたダッシュボード・トピック・ナレッジベースへの権限は別途必要です。例外はスペースに直接アップロードしたファイルで、こちらはスペースへのアクセス権を持つ全員が参照できます。その理由は、スペースに付随するリソースであるからです。

チャットエージェントは利用者本人の権限で評価される

カスタムチャットエージェントにも同様の原則が適用されます。エージェントの Viewer は「自分がアクセス権を持つリソースの範囲で応答を受け取れる」とあり、リンク済みリソースへのアクセス権がない場合、そのリソースは Resource unavailable と表示されます。

チャットエージェントを共有した後にエージェントにリンクされた各リソースを個別に共有する必要があります。エージェント本体の共有は、あくまで入り口を提供するだけであり、回答の元になるナレッジやデータへの権限は利用者ごとに評価されます。

この関係を図にすると、次のようになります。エージェントを使うグループには、実線の共有（①）だけでなく、点線でつながる先のリソースへの共有（②〜④）まで揃えて付与する必要があります。

権限設計のベストプラクティス

1. グループへの権限付与を基本にする

スペース、ナレッジベース、チャットエージェントの共有は、いずれもユーザーとグループの両方に対応しています。ユーザー個人への付与を積み重ねると、リソースの数だけ管理が困難になるため、「部門、チーム単位、プロジェクトなどのグループを作り、すべてのリソースを同じグループに共有する」ことを原則にします。メンバーの入れ替えはグループへの追加・削除だけで完結します。

2. エージェントとリンク先リソースに「同じグループ」を付与する

エージェントを公開する単位（グループ）を決めたら、そのグループに対しても同じように共有します。

1. チャットエージェント本体（Viewer）
2. エージェントにリンクしたスペース（Viewer）
3. スペースにリンクしたダッシュボード、トピック（個別共有または共有フォルダ経由）
4. スペースにリンクしたナレッジベース（Viewer）

このとき、ダッシュボードの元になるデータセットの権限や行レベルセキュリティ（RLS）の設定も忘れずに確認します。エージェント、スペース、アセット、データセットの順に権限の連鎖のどこか 1 か所でも欠けると、そこが「見えない」原因になります。

3. フォルダ対応アセットは引き続き共有フォルダで管理する

ダッシュボードやトピックなどのフォルダ対応アセットは、従来どおり共有フォルダで一括管理し、そのフォルダをエージェント利用グループへ共有するのが効率的です。「エージェント用アセットフォルダ」をグループに共有しておけば、スペースにリンクするアセットを増やすときも、フォルダに追加するだけで権限が同じになります。

4. 静的なドキュメントはスペースへの直接アップロードを活用する

スペースにアップロードしたファイルは、スペースへのアクセス権を持つ全員が参照できるため、個別の権限付与が不要です。更新頻度の低いマニュアルや FAQ などは、ファイルアップロードで運用すると権限の連鎖を短くできます。ただし、裏を返せば「スペースが見える人には必ず見える」ため、機密度の高いドキュメントを混在させないよう注意が必要です。

5. 公開前に権限のないテストユーザーで動作確認する

エージェント作成者（Owner）は全リソースにアクセスできるため、作成者自身のテストでは権限漏れに気づけません。展開先グループと同じ権限を持つテストユーザーで、想定質問に対して Resource unavailable やエラーが出ないことを確認してから公開します。

6. カスタムアクセス許可で作成できる人を統制する

チャットエージェントの作成権限は Quick Suite 管理者がアクセス許可（Custom permissions）のプロファイルで制御できます。いわゆる、ガードレール戦略です。誰でもエージェントやスペースを作成できる状態では権限設計が形骸化しやすいため、作成者を限定し、命名規則や公開フローとあわせて統制することをおすすめします。

注意点

• ナレッジベースの共有は、すべてのタイプで Viewer ロールに対応していますが、Owner（所有者）として共有できるのは管理者管理の Microsoft SharePoint Online と Google Drive のナレッジベースのみです。また、作成者は常に Owner であり削除できません。
• データソース接続の共有は Quick Suite 管理者のみが実行でき、管理者管理（サービス認証情報）の接続に限られます。
• スペースにリンクしたリソースが外部で削除されても、スペースの利用者には通知されず、利用不可のメッセージが表示されるだけです。定期的な棚卸しで検出する運用を推奨します。
• スペースにリンクできるリソースは、リソースタイプ（ダッシュボード、トピック、ナレッジベース、アクション）ごとに最大 20 個です。

最後に

Amazon Quick では、スペース、ナレッジベース、チャットエージェントが共有フォルダの権限継承の対象外となり、リソースごとの個別付与が必要になりました。エージェントの応答は利用者本人の権限で評価されるため、「エージェント本体、スペース、リンク済みアセット、ナレッジベース」に同じグループを揃えて共有することが、権限エラーを防ぐ最も確実な方法です。

グループ単位の権限付与を原則に、公開前のテストユーザー確認による定期監査を組み合わせて、安心してエージェントを展開できる運用を検討してみてはいかがでしょうか。