【Snowflake】カスタムロールはなぜSYSADMIN配下に集約するのか

はじめに

Snowflakeを触りはじめて、最初に多くの人がつまずくのが「ロール設計」です。

トライアルやPoCの段階では、つい ACCOUNTADMIN のまま全部やってしまいがちですよね。テーブルもウェアハウスも、なんならユーザー作成まで。動くは動くのですが、これは本番運用に持っていくと必ず壊れる設計です。

公式ドキュメントを読むと、何度も繰り返し出てくるフレーズがあります。

「カスタムロールはSYSADMIN配下に集約しましょう」

この記事では、その「なぜ」を初心者向けに掘り下げます。SQLは最小限にとどめ、思想と理由にフォーカスします。

対象読者

• Snowflakeをトライアル・PoC段階で触っている方
• とりあえずACCOUNTADMINで作業してしまっている方
• 本番運用に向けてロール設計を学びたい方

前提知識

• Snowflakeの基本的なオブジェクト（データベース・スキーマ・テーブル・ウェアハウス）の概念
• RBAC（ロールベースアクセス制御）という言葉を聞いたことがある程度でOK

本記事は2026年5月時点のSnowflake公式ドキュメントを参照しています。詳細は必ず公式の最新情報をご確認ください。

参考リンク

Snowflakeのシステムロールを整理する

まず前提として、Snowflakeにはあらかじめ用意された「システムロール」が5つあります¹。これは削除も改変もできません。

ロール	主な役割	ざっくり言うと
ORGADMIN	組織レベルの管理	複数アカウントを束ねる「組織」の管理者
ACCOUNTADMIN	アカウント最上位	全権限を持つ。神の権限
SECURITYADMIN	グローバルな権限管理	あらゆる権限の付与・剥奪ができる
USERADMIN	ユーザーとロールの作成	ユーザー・ロールを生み出す係
SYSADMIN	オブジェクトの管理	ウェアハウス・DB・テーブルを管理する係
PUBLIC	デフォルトロール	全ユーザーに自動付与される

このうち本記事のキーマンは SYSADMIN と USERADMIN / SECURITYADMIN です。

重要な責務分離：「人」と「モノ」は別の係が管理する

Snowflakeのロール設計思想を一言で表すと、こうです。

• 「人（ユーザー・ロール）の管理」 = USERADMIN / SECURITYADMIN
• 「モノ（ウェアハウス・DB・テーブル）の管理」 = SYSADMIN

この「人とモノを別の係で管理する」考え方は、AWSのIAMでも、Azure RBACでも、Linuxのsudo設計でも共通する 責務分離（Separation of Duties） の基本原則です。Snowflakeはそれをシステムロールという形で最初から強制してくれている、と捉えるとわかりやすいですね。

結論：カスタムロールをSYSADMIN配下に集約する3つの理由

ここからが本題です。なぜカスタムロールは SYSADMIN 配下に集約するのか。理由は3つあります。

理由1：SYSADMINがすべてのオブジェクトを管理できるようになる

Snowflakeには、見落としがちな重要なルールがあります。

オブジェクトを作成したロールが、そのオブジェクトの「所有者」になる。

たとえば MY_CUSTOM_ROLE でテーブルを作ると、そのテーブルの所有者は MY_CUSTOM_ROLE になります。

ここで問題が起きます。MY_CUSTOM_ROLE を SYSADMIN に紐付けていないと、SYSADMIN ですらそのテーブルに手出しできなくなるのです。

公式ドキュメントには、こう書かれています。

逆に、カスタムロールがロール階層を通じてSYSADMINに割り当てられていない場合、システム管理者はそのロールが所有するオブジェクトを管理できません。

これは運用上かなり厄介です。誰かが退職した、ロールを整理したい、本番障害が起きた──そんなときに SYSADMIN で対応できないと、いちいち ACCOUNTADMIN に切り替える羽目になります。

理由2：「ロール管理」と「オブジェクト管理」の責務分離を維持できる

理由1の対策として「じゃあ SECURITYADMIN や ACCOUNTADMIN 配下に紐付ければいいのでは？」と思うかもしれません。

これはアンチパターンです。

カスタムロールを SECURITYADMIN や ACCOUNTADMIN 配下に紐付けると、責務分離が崩れます。

• SECURITYADMIN は本来「権限管理」専門のロール
• そこにデータアクセスの権限が混ざると、最小権限の原則が破綻する

公式ドキュメントも明確にこれを諫めています。

システム定義ロールに追加の権限を付与することは可能ですが、推奨されません。システム定義ロールはアカウント管理に関連する権限を持つように作成されています。ベストプラクティスとして、アカウント管理権限とエンティティ固有の権限を同じロールに混在させることは推奨されません。

SYSADMIN は「モノを管理する係」として最初から設計されているので、ここに紐付けるのが筋が通っているわけです。

理由3：将来のメンテナンスコストを下げる

最後はじわじわ効いてくる理由です。

PoC段階では2〜3個しかないカスタムロールも、本番運用が始まると10個、20個と増えていきます。チーム別、案件別、データソース別、読み取り専用／書き込み可など、組み合わせで膨らみます。

このとき、全カスタムロールが SYSADMIN 配下にぶら下がっているという規律があれば:

• 棚卸しがしやすい（SYSADMIN から辿れば全部見える）
• 新メンバーへの説明がシンプル（「SYSADMINツリーを見て」で済む）
• Snowsightのロールグラフが意味のある形で可視化される

逆に、ところどころ SECURITYADMIN 配下にあったり、孤立したロールが混ざっていると、把握も監査も難しくなります。

実装イメージ：アクセスロール × 機能ロール

ここで一例だけSQLを示します。考え方を掴むためのものなので、コピペで本番運用しないでください。

Snowflakeで広く使われる設計パターンは「アクセスロール × 機能ロール」の二層構造です。

• アクセスロール: 「何ができるか」を定義（例: db_sales_reader = salesDBの読み取り）
• 機能ロール: 「誰が使うか」を定義（例: analyst = アナリスト職）

機能ロールにアクセスロールを束ねて付与し、機能ロールを SYSADMIN 配下に紐付ける。これが基本形です。

role_hierarchy_example.sql

-- USERADMIN でロールを作成する
USE ROLE USERADMIN;

-- アクセスロール（できることベース）
CREATE ROLE db_sales_reader;
CREATE ROLE db_sales_writer;

-- 機能ロール（職務ベース）
CREATE ROLE analyst;
CREATE ROLE data_engineer;

-- 階層を組む：アクセスロール → 機能ロール → SYSADMIN
GRANT ROLE db_sales_reader TO ROLE analyst;
GRANT ROLE db_sales_reader TO ROLE data_engineer;
GRANT ROLE db_sales_writer TO ROLE data_engineer;

-- ★ ここが本記事のキモ：機能ロールを SYSADMIN 配下に集約
GRANT ROLE analyst       TO ROLE SYSADMIN;
GRANT ROLE data_engineer TO ROLE SYSADMIN;

これで SYSADMIN から analyst も data_engineer も辿れるようになり、その下のアクセスロールが管理するオブジェクト全部を SYSADMIN で操作できる、という階層が完成します。

実際のオブジェクト権限の付与（GRANT SELECT ON ... TO ROLE db_sales_reader など）は、別途SECURITYADMINやアクセスロール所有者の責任で行いますが、それは本記事のスコープを超えるので割愛します。

カスタムロールを「孤児」にしないために

最後に、よくある失敗例を Diff で示します。

USE ROLE USERADMIN;
CREATE ROLE etl_admin;

- -- ❌ ここで終わると etl_admin は「孤児ロール」になる
- -- SYSADMINからは見えず、管理できない

+ -- ⭕ 必ず SYSADMIN 配下に紐付ける
+ GRANT ROLE etl_admin TO ROLE SYSADMIN;

たった1行ですが、これがあるかないかで運用の見通しが大きく変わります。チームで決めておくべきルールはシンプルです。

「カスタムロールを作ったら、その場で SYSADMIN に GRANT する」

まとめ

本記事の要点を振り返ります。

• Snowflakeのシステムロールは「人を管理する係（USERADMIN/SECURITYADMIN）」と「モノを管理する係（SYSADMIN）」に責務分離されている
• カスタムロールを SYSADMIN 配下に集約する理由は3つ
  1. SYSADMINがオブジェクトを管理できるようにするため
  2. 責務分離を維持するため
  3. 将来のメンテナンスコストを下げるため
• ACCOUNTADMIN や SECURITYADMIN 配下にカスタムロールをぶら下げるのはアンチパターン
• 実装は「アクセスロール × 機能ロール」の二層構造が一般的

1. 厳密には ORGADMIN と PUBLIC を含めるかで5〜6個と数え方が変わりますが、ここでは主要ロールに絞っています。 ↩