Tableau Cloud の権限モデルを完全理解
サイトロール・プロジェクト・権限ルールの階層

Tableau Cloud の権限は3階層で考える

サイトロール・プロジェクト権限・権限ルールの違い

Tableau Cloud の権限管理が分かりにくく感じられる最大の理由は、性質の異なる3種類の制御が同時に存在していることにあります。 最初にこの3種類を切り分けて整理しておくと、以降の話が一気に見通しやすくなります。

ひとつめがサイトロールです。Creator・Explorer・Viewer といったロールは、ユーザーがそのサイト全体で実行できるアクションの 上限を定めます。たとえば Viewer ロールを持つユーザーは、どのプロジェクトに対して何を許可されていても、ワークブックを 新規にパブリッシュすることはできません。サイトロールは「天井」を決める仕組みだと捉えると分かりやすいです。

ふたつめがプロジェクト単位の権限です。Tableau Cloud では、ワークブックやデータソースを格納する入れ物としてプロジェクトを 使います。プロジェクトに対してユーザーやグループ単位で権限を付与すると、その配下のコンテンツに既定値として継承されます。

みっつめが個別の権限ルールです。各ワークブック・ビュー・データソースに対して、Web 上での編集・ダウンロード・コメントなど 細かいアクションごとに権限を上書きできます。

「サイトロールが上限を決め、プロジェクト権限が初期値を決め、権限ルールが個別の例外を許す」という3層構造をひとつのモデルとして 覚えておくと、試験問題でも実務でも判断に迷いにくくなります。

階層構造の全体図（サイト→プロジェクト→ワークブック→ビュー）

権限の継承先となるコンテンツも階層構造になっています。Tableau Cloud では、サイトの下にプロジェクトがあり、プロジェクトの中に ワークブック・データソース・フローなどが格納され、ワークブックの中に複数のビューが含まれます。

権限はこの階層に沿って上から下へと流れていきます。プロジェクトに付与された権限はワークブックへ、ワークブックに付与された権限は ビューへ既定値として継承されるイメージです。継承の途中で個別ルールにより上書きされることもあれば、後述するプロジェクトロックに よって配下が完全に固定されることもあります。

階層が深くなるほど例外が増えやすいため、組織として権限を管理する側は「なるべく上位の階層でまとめて制御し、個別ルールに頼りすぎない」 運用が望ましいといえます。

サイトロール早見表 — Creator / Explorer / Viewer の境界線

3つのロールが「できること」の上限

Tableau Cloud の代表的なサイトロールを、できることの上限という観点で整理します。サブスクリプション体系上は Creator / Explorer / Viewer の3つを軸に押さえておけば、実務の大半はカバーできます。ただし試験では、この3ロールに加えて 「Explorer」と「Explorer (Can Publish)」の違い（パブリッシュ可否）、および「Unlicensed」ロールが問われる場合があるため、 両者を区別して覚えておくと安心です。

この表で重要なのは、上位ロールが下位ロールの操作をすべて含むという入れ子の関係です。Creator は Explorer ができることをすべて行え、 Explorer は Viewer の操作をすべて行えます。逆に下位ロールから上位ロールの操作はできません。

ロール選定でよくある誤解

実務でよく見かける誤解のひとつが「権限ルールで Web Edit を Allow にすれば Viewer でも編集できる」というものです。先ほどの 3層構造を思い出すと、サイトロールは天井を決める仕組みでした。Viewer ロールにはそもそも Web Edit を実行する権利が含まれていないため、 権限ルールで Allow を設定しても編集はできません。

もうひとつよくあるのが「Explorer であればすべてのプロジェクトでダッシュボードを新規作成できる」という誤解です。実際には Explorer がダッシュボードを作成できるかどうかは、対象プロジェクトの権限設定に依存します。サイトロールが上限を許しているだけで、 プロジェクト権限と組み合わせて初めて操作が可能になります。

サイトロールは「最大値」、プロジェクト権限と権限ルールは「実際に許す範囲」と覚えておくと、こうした誤解を避けやすくなります。

3階層モデルの基礎は学習単元「権限モデルの設計」で復習できます。

権限の継承と上書きの仕組み

既定では上位プロジェクトの権限が継承される

Tableau Cloud では、新しいワークブックをプロジェクトにパブリッシュすると、原則としてそのプロジェクトに設定された権限ルールが 既定値としてワークブックに適用されます。さらにそのワークブック配下のビューにも権限が伝わります。

この既定値はパブリッシュ時に明示的に上書きすることもできます。たとえば「このワークブックだけは特定のグループに編集を許可したい」 という場合、ワークブック単位で権限ルールを追加・変更できます。ただし上書きを繰り返すと、誰がどこで何を許可したのかが追跡しづらくなり、 運用負荷が高まる原因になります。

権限管理の基本姿勢としては「プロジェクトに付与した既定値で大半のケースをカバーし、本当に必要な場合だけ個別の権限ルールで上書きする」 運用が推奨されます。

プロジェクトロックで権限を固定する

組織として権限を厳密に統一したい場合に活躍するのがプロジェクトロックです。プロジェクトをロックすると、そのプロジェクト配下の ワークブック・データソース・ビューの権限がプロジェクトレベルの設定に固定されます。コンテンツ作成者がワークブック単位で権限ルールを 変更することはできなくなり、プロジェクトの設定だけが正となる状態が保たれます。

プロジェクトロックには2段階あることに注意が必要です。通常の「ロック」はそのプロジェクト直下のコンテンツのみを固定し、 入れ子になったサブプロジェクトは個別に権限を設定できる状態のまま残ります。配下のサブプロジェクトまで含めてすべて固定したい場合は、 「ロック（ネストしたプロジェクトを含む）」を選択する必要があります。部門→チーム→年度のように階層化したプロジェクト構成では、 どちらを選んだかで効果範囲が大きく変わります。

ここで誤解されやすいのが「プロジェクトをロックすると配下のワークブックを誰も閲覧できなくなる」というものです。ロックはアクセスを 遮断する仕組みではなく、権限を固定する仕組みです。プロジェクトに対して「Finance グループに閲覧を許可」と設定されていれば、 ロック後も Finance グループはワークブックを閲覧できます。

機密性の高い財務データや人事データを扱うプロジェクトでは、プロジェクトロック（ネストしたプロジェクトを含む）を併用して権限の 例外を作らせない運用が一般的です。

Allow / Deny / Unspecified の3つの値

権限ルールでは、各アクションに対して Allow（許可）・Deny（拒否）・Unspecified（未指定）の3つの値を割り当てられます。 Allow は明示的な許可、Deny は明示的な拒否、Unspecified は未指定の状態で継承元の値がそのまま反映されます。

Allow と Deny が同じユーザーやグループ間で混在する場合、単純に「Deny が常に勝つ」わけではありません。Tableau が有効権限を 決定する評価順序は次のとおりです。まずユーザー個人に対するルールは、そのユーザーが所属するグループのルールよりも優先されます。 たとえば「Marketing グループには Deny、特定ユーザー個人には Allow」と設定されていれば、個人の Allow がグループの Deny を 上書きし、そのユーザーは許可されます。次に、複数グループのルールが競合する場合（片方のグループが Allow、もう片方が Deny）は、 グループ同士の競合として Deny が優先されます。最後に、ユーザー・グループのどこにも指定がない場合は Unspecified（未指定）と なり、これは実質的に拒否として扱われます。権限の判定で迷ったときは「①個人ルールはグループルールより優先される」 「②グループ同士が競合する場合は Deny が勝つ」「③どこにも指定がなければ拒否扱いになる」という3段階の評価順序に 立ち戻ると整理しやすくなります。

認定コンテンツとデータ品質の警告で「信頼できるレポート」を可視化する

組織内に発行されたコンテンツが増えてくると、ユーザーは「このダッシュボードの数字を信用していいのか」「このデータソースは 公式版なのか」を判断する手がかりを必要とするようになります。Tableau Cloud にはこの判断を助ける2つの仕組みが用意されています。

ひとつめが認定コンテンツ（Certification）です。サイト管理者または認定権限を持つユーザーが、データソースやワークブックに 「認定済み」バッジを付与できます。バッジ付きのコンテンツは検索結果や一覧で強調表示されるため、ユーザーは公式版を迷わず選べるようになります。

ふたつめがデータ品質の警告（Data Quality Warning）です。データが古い・不完全である・抽出更新が失敗しているといった注意を、 コンテンツに対して明示的に表示できます。なおこの機能はTableau Catalog（Data Managementライセンス、Tableau Enterprise/Cloud+等に 含まれる）が必要な機能であり、Tableau Cloudの契約だけで標準的に使えるわけではない点に注意してください。

この2つは性質が正反対だという点を押さえておく必要があります。認定は「信頼できる」という肯定的な情報を伝え、データ品質の警告は 「注意が必要」という否定的な情報を伝えます。試験では「信頼できる公式データソースをユーザーが識別しやすくする機能はどれか」という 問いに対して認定コンテンツを選ばせる形式や、「データが古くなっている可能性をユーザーに通知する目的で使う機能」を問う形式で 出題されることがあります。

なお認定バッジは信頼性の表示機能であり、アクセス制御の機能ではありません。「未認定ユーザーは閲覧できなくなる」といった動作は 発生しないため、権限制御とは別レイヤーの概念として整理しておきましょう。

部門別プロジェクト分けの実例 — Finance・Marketing・全社共有

権限モデルの理解を深めるには、実際の組織でどのようにプロジェクトを切るかをイメージするのが近道です。中規模企業を想定した 一例を挙げます。

「Finance」プロジェクトには、財務関連の機密性が高いダッシュボードを格納します。Finance グループにのみ閲覧と Web Edit を許可し、 他部門のユーザーはそもそもプロジェクトを参照できないように構成します。さらにプロジェクトロックを有効化し、コンテンツ作成者が 個別に権限ルールを上書きできないようにすることで、機密性を強固に守ります。

「Marketing」プロジェクトには、キャンペーン分析や広告効果のダッシュボードを置きます。Marketing グループには Web Edit と Download を許可しつつ、全社の Viewer ユーザーには閲覧のみを許可することで「全社で見える共有資産」と「自部門で編集できる 作業領域」を両立させます。

「全社共有」プロジェクトには、全従業員が参照する経営 KPI ダッシュボードや、人事の汎用レポートを置きます。全社の Explorer / Viewer に閲覧を許可しますが、編集権限はサイト管理者に限定します。さらに公式版のデータソースには認定バッジを付与し、 ユーザーが迷わず使えるようにします。

このように部門・用途ごとにプロジェクトを切り、命名規則を統一して運用すると、コンテンツ数が増えても誰がどこを管理しているかが 明確に保たれます。プロジェクトを入れ子構造にして「部門→チーム→年度」のように階層化することも可能で、Tableau Cloud のサイトが 大規模化したときの整理に有効です。

命名規則・階層設計の原則は学習単元「コンテンツガバナンス」で解説しています。

Tableau Certified Data Analyst 試験で問われる典型パターン

Tableau Certified Data Analyst 試験の「公開と管理ドメイン」では、ここまで紹介した権限モデルが直接の出題対象になります。 代表的な出題パターンを3つに分けて整理します。

パターン1はプロジェクトロックの動作を問う問題です。「プロジェクトにロックを設定した場合の動作として最も適切なものはどれか」 という形式で、「配下コンテンツの権限がプロジェクト設定に固定される」を選ばせます。「配下のワークブックが閲覧できなくなる」 「データソースのみに権限が適用される」といった誤った選択肢に惑わされないことが重要です。

パターン2はサイトロールと権限ルールの優先順位を問う問題です。「Viewer サイトロールのユーザーに対し権限ルールで Web Edit を Allow に設定した場合の結果はどれか」という問いで、「サイトロールが上限を決めるため編集できない」を選ばせる形式が頻出です。 サイトロール＝実行可能アクションの上限・権限ルール＝個別コンテンツの細分制御という二層構造の理解度が問われます。

パターン3は認定コンテンツとデータ品質の警告の使い分けです。「信頼できる公式データソースをユーザーが識別しやすくする機能は どれか」では認定コンテンツを、「データが古くなっている可能性をユーザーに通知する目的で使う機能」ではデータ品質の警告を選ばせます。 両者の用途が正反対であることを押さえておけば確実に得点できます。

加えて Allow / Deny / Unspecified の3値の優先関係や、グループと個人の権限が混在したときの挙動も出題対象です。 Tableau Certified Data Analyst 試験は60問（このほか採点対象外の問題が最大5問）の全選択式で、こうした判断問題が 安定して出題されるため、本記事の3層構造をひと通り頭に入れておけば「公開と管理ドメイン」の大半を取りこぼしなく対応できます。

「Tableau Server / Tableau Cloudでのコンテンツの公開と管理」ドメイン全体の配点はTableau Certified Data Analyst試験の配点とロードマップで整理しています。直前期の総復習はTableau Data Analyst認定試験 出題範囲の傾向と対策でまとめて確認できます。

※ 本記事はTableau Certified Data Analyst試験の学習を支援する目的で作成しています。 Tableau Cloud の権限モデルの仕様や試験の最新情報はSalesforce（Tableau）の公式ドキュメントをご確認ください。 Tableau・Salesforceは各社の商標または登録商標です。