QuickSight のアクセスはロールとリソース共有で決まる

QuickSight で最初に戸惑いやすいのが、権限まわりです。
Admin ロールが付いているのに、他の人が作ったダッシュボードが一覧に出てこない。
設定ミスに見えますが、そうではありません。

QuickSight では「その人がどんなユーザーか（ロール）」と「そのアセットが誰に共有されているか」が別々の軸になっていて、Admin ロールが効くのは前者（ロールの軸）だけ。
共有されていないダッシュボードは、Admin でも見えません。

この記事で整理したいのは次の3つです。

• アクセスできるかどうかは「ロール」と「リソース共有」の掛け算で決まること
• それぞれの軸が何を決めているのか
• なぜ「Admin なのに見えない」が起きるのか

この記事は「ロール × リソース共有」の2軸に絞ります。グループ／フォルダ（2軸を大人数・大量に配る仕組み）、IAM 権限との境界、共有の競合解決、RLS/CLS、埋め込み（embedded analytics）は扱いません。

アクセス可否は2軸の掛け算

QuickSight でアセットにアクセスできるかどうかは、次のように考えると整理しやすいです。

アクセス可否 = ロール × リソース共有

掛け算なので、どちらか片方が欠けると結果は 0 のまま。
ロールが強くても共有されていなければ見えないし、共有されていてもそのアセットを扱えるロールでなければ操作できません。

2つの軸はそれぞれこう分かれます。

• 軸1「ロール」: その人がアカウント上でどんな種類のユーザーか
• 軸2「リソース共有」: そのアセットを誰が見る／編集できるか

以降でこの2軸を1つずつ見ていきます。

軸1 ロール ─ その人が何をできる種類のユーザーか

ロールは、その人がアカウント全体で「どんな種類のユーザーか」を決める軸です。
大きく3種類あります²。

• Reader（閲覧者）: 用意されたダッシュボードを見る・データを照会する人
• Author（作成者）: それに加えて、データセットやダッシュボードを自分で作れる人
• Admin（管理者）: さらにアカウント全体を管理できる人（ユーザーの招待やロール変更、契約プランの管理など）²

上位のロールは下位のロールができることを含みます。
Admin は Author と Reader のできることも一通りできる、という関係です。

（各ロールには Pro 版もありますが、ここでは「上乗せ機能のある版がある」くらいの理解で先に進みます。）

軸2 リソース共有 ─ そのアセットを誰が見る／編集できるか

もう1つの軸が、個々のアセット（ダッシュボードやデータセットなど）を「誰に見せるか／編集させるか」を決めるリソース共有です。

共有のレベルは、細かい違いはあるものの、おおまかに2段階でとらえられます。呼び名はアセットの種類ごとに変わります。

• Viewer（表示者）: 見るだけ
• Owner（所有者）・Co-owner（共同所有者）: 編集もできる

ただし「2段階」はあくまで理解のための近似です。
UI 上は Viewer / Co-owner / Owner といった代表的なラベルで見えますが、実際に何ができるかはアセット種別ごとの設定で決まり、名前も操作範囲もアセットによって違います³⁴⁵。
たとえば分析(analysis)は、同じアカウント内のユーザー／グループに権限を選んで共有する形になっています⁶。

もう1つ、どのレベルを付与できるかは共有相手のロールにも左右されます（軸1と軸2の接点）。具体例は次の「掛け算」の表で見ます。

掛け算で読み解く「Admin なのに見えない」

2つの軸がそろったので、最初の「Admin なのに見えない」を掛け算で読み解きます。
同じダッシュボードでも、自分のロールと共有レベルの組み合わせで見え方はこう変わります。

ロール ＼ 共有レベル	未共有	Viewer で共有	Owner・Co-owner で共有
Reader	見えない	閲覧のみ	付与できない※
Author	見えない	閲覧のみ	編集・共有・削除まで
Admin	見えない	閲覧のみ	編集・共有・削除まで

※ ダッシュボードの共有では、Reader に付与できるのは Viewer までです³。付与ルールはアセットごとに変わるので、これはダッシュボードの例と考えてください。

表の左端の列を縦に見ると、ロールが Reader でも Author でも Admin でも、未共有なら「見えない」で並びます。
これが「Admin なのに見えない」の正体です。

Admin が与えるのはアカウントの管理操作ができる権限で、個々のアセットを見る権限とは別の軸です²。
だから共有されていないダッシュボードは、Admin だろうと表示されません。
逆に言えば、見えるようにするのに必要なのはロールを上げることではなく、そのアセットを共有してもらうこと。
切り分けるべきはそこです。

まとめ

• アクセス可否は「ロール × リソース共有」の掛け算。どちらか片方が欠ければ結果は 0（見えない・操作できない）
• ロール＝アカウント上でどんな種別のユーザーか、リソース共有＝そのアセットを誰に見せる／編集させるか。効く軸が違う
• 「見えない」ときに上げるべきはロールではなく、そのアセットを共有してもらうこと
• 共有はアセット単位の粗い制御。次はこれを行単位まで絞り込む RLS（行レベルセキュリティ）へ進みます

関連記事

QuickSight の権限を「認証 → 認可 → RLS → IAM 境界」の順にたどる入口記事です。

• 1本目 QuickSight のログイン方式を整理する（認証）
• 2本目 QuickSight のアクセスはロールとリソース共有で決まる（認可）（本記事）
• 3本目 QuickSight の行レベルセキュリティ(RLS)とは
• 4本目 QuickSight の権限と IAM の関係を整理する（IAM 境界）

1. 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/ ↩

2. Amazon Quick ユーザー種別とロール（6ロール・IAM/Admin ロールの権限二分表を含む・現行 /quick/ ドキュメント） - https://docs.aws.amazon.com/quick/latest/userguide/user-types.html ↩ ↩² ↩³

3. ダッシュボードへのアクセス権限付与（Viewer/Co-owner・Reader/グループは Viewer のみ・Author は Viewer/Co-owner） - https://docs.aws.amazon.com/quick/latest/userguide/share-a-dashboard-grant-access-users.html ↩ ↩²

4. データセットの共有 - https://docs.aws.amazon.com/quicksight/latest/user/sharing-data-sets.html ↩

5. Amazon QuickSight のリソース権限（プリンシパル上限100・アカウントルート ARN による template クロスアカウント共有） - https://docs.aws.amazon.com/quicksight/latest/developerguide/resource-permissions.html ↩

6. 分析の共有（同一アカウント内限定） - https://docs.aws.amazon.com/quicksight/latest/user/sharing-analyses.html ↩