QuickSight で最初に戸惑いやすいのが、権限まわりです。
Admin ロールが付いているのに、他の人が作ったダッシュボードが一覧に出てこない。
設定ミスに見えますが、そうではありません。
QuickSight では「その人がどんなユーザーか(ロール)」と「そのアセットが誰に共有されているか」が別々の軸になっていて、Admin ロールが効くのは前者(ロールの軸)だけ。
共有されていないダッシュボードは、Admin でも見えません。
この記事で整理したいのは次の3つです。
- アクセスできるかどうかは「ロール」と「リソース共有」の掛け算で決まること
- それぞれの軸が何を決めているのか
- なぜ「Admin なのに見えない」が起きるのか
この記事は「ロール × リソース共有」の2軸に絞ります。グループ/フォルダ(2軸を大人数・大量に配る仕組み)、IAM 権限との境界、共有の競合解決、RLS/CLS、埋め込み(embedded analytics)は扱いません。
QuickSight は Amazon Quick へ改称・移行が進んでいますが、ロールや共有の考え方は変わらないとされています1。この記事は検索のしやすさを優先して「QuickSight」表記で通します。
アクセス可否は2軸の掛け算
QuickSight でアセットにアクセスできるかどうかは、次のように考えると整理しやすいです。
アクセス可否 = ロール × リソース共有
掛け算なので、どちらか片方が欠けると結果は 0 のまま。
ロールが強くても共有されていなければ見えないし、共有されていてもそのアセットを扱えるロールでなければ操作できません。
2つの軸はそれぞれこう分かれます。
- 軸1「ロール」: その人がアカウント上でどんな種類のユーザーか
- 軸2「リソース共有」: そのアセットを誰が見る/編集できるか
以降でこの2軸を1つずつ見ていきます。
軸1 ロール ─ その人が何をできる種類のユーザーか
ロールは、その人がアカウント全体で「どんな種類のユーザーか」を決める軸です。
大きく3種類あります2。
- Reader(閲覧者): 用意されたダッシュボードを見る・データを照会する人
- Author(作成者): それに加えて、データセットやダッシュボードを自分で作れる人
- Admin(管理者): さらにアカウント全体を管理できる人(ユーザーの招待やロール変更、契約プランの管理など)2
上位のロールは下位のロールができることを含みます。
Admin は Author と Reader のできることも一通りできる、という関係です。
Admin が与えるのは「アカウントの管理権限」であって、「すべてのダッシュボードを見る権限」ではありません。
ユーザー管理や容量調整はできても、個々のダッシュボードが見えるかどうかは別の話。このズレが「Admin なのに見えない」の伏線になります。
(各ロールには Pro 版もありますが、ここでは「上乗せ機能のある版がある」くらいの理解で先に進みます。)
軸2 リソース共有 ─ そのアセットを誰が見る/編集できるか
もう1つの軸が、個々のアセット(ダッシュボードやデータセットなど)を「誰に見せるか/編集させるか」を決めるリソース共有です。
共有のレベルは、細かい違いはあるものの、おおまかに2段階でとらえられます。呼び名はアセットの種類ごとに変わります。
- Viewer(表示者): 見るだけ
- Owner(所有者)・Co-owner(共同所有者): 編集もできる
ただし「2段階」はあくまで理解のための近似です。
UI 上は Viewer / Co-owner / Owner といった代表的なラベルで見えますが、実際に何ができるかはアセット種別ごとの設定で決まり、名前も操作範囲もアセットによって違います345。
たとえば分析(analysis)は、同じアカウント内のユーザー/グループに権限を選んで共有する形になっています6。
もう1つ、どのレベルを付与できるかは共有相手のロールにも左右されます(軸1と軸2の接点)。具体例は次の「掛け算」の表で見ます。
掛け算で読み解く「Admin なのに見えない」
2つの軸がそろったので、最初の「Admin なのに見えない」を掛け算で読み解きます。
同じダッシュボードでも、自分のロールと共有レベルの組み合わせで見え方はこう変わります。
| ロール \ 共有レベル | 未共有 | Viewer で共有 | Owner・Co-owner で共有 |
|---|---|---|---|
| Reader | 見えない | 閲覧のみ | 付与できない※ |
| Author | 見えない | 閲覧のみ | 編集・共有・削除まで |
| Admin | 見えない | 閲覧のみ | 編集・共有・削除まで |
※ ダッシュボードの共有では、Reader に付与できるのは Viewer までです3。付与ルールはアセットごとに変わるので、これはダッシュボードの例と考えてください。
表の左端の列を縦に見ると、ロールが Reader でも Author でも Admin でも、未共有なら「見えない」で並びます。
これが「Admin なのに見えない」の正体です。
Admin が与えるのはアカウントの管理操作ができる権限で、個々のアセットを見る権限とは別の軸です2。
だから共有されていないダッシュボードは、Admin だろうと表示されません。
逆に言えば、見えるようにするのに必要なのはロールを上げることではなく、そのアセットを共有してもらうこと。
切り分けるべきはそこです。
まとめ
- アクセス可否は「ロール × リソース共有」の掛け算。どちらか片方が欠ければ結果は 0(見えない・操作できない)
- ロール=アカウント上でどんな種別のユーザーか、リソース共有=そのアセットを誰に見せる/編集させるか。効く軸が違う
- 「見えない」ときに上げるべきはロールではなく、そのアセットを共有してもらうこと
- 共有はアセット単位の粗い制御。次はこれを行単位まで絞り込む RLS(行レベルセキュリティ)へ進みます
関連記事
QuickSight の権限を「認証 → 認可 → RLS → IAM 境界」の順にたどる入口記事です。
- 1本目 QuickSight のログイン方式を整理する(認証)
- 2本目 QuickSight のアクセスはロールとリソース共有で決まる(認可)(本記事)
- 3本目 QuickSight の行レベルセキュリティ(RLS)とは
- 4本目 QuickSight の権限と IAM の関係を整理する(IAM 境界)
-
Amazon QuickSight が Amazon Quick Suite へ発展(2025-10-09 ロールアウト・権限/API は変更なしと明記) - https://aws.amazon.com/blogs/business-intelligence/reimagine-business-intelligence-amazon-quicksight-evolves-to-amazon-quick-suite/ ↩
-
Amazon Quick ユーザー種別とロール(6ロール・IAM/Admin ロールの権限二分表を含む・現行
/quick/ドキュメント) - https://docs.aws.amazon.com/quick/latest/userguide/user-types.html ↩ ↩2 ↩3 -
Amazon QuickSight のリソース権限(プリンシパル上限100・アカウントルート ARN による template クロスアカウント共有) - https://docs.aws.amazon.com/quicksight/latest/developerguide/resource-permissions.html ↩