Snowflake命名規則ベストプラクティス|ウェアハウス・ユーザー・ロール

Snowflake命名規則ベストプラクティス|ウェアハウス・ユーザー・ロール Snowflake
2026.05.07

はじめに:なぜ「名前の付け方」が大事なの?

こんにちは!Snowflakeを使い始めると、ウェアハウス・ユーザー・ロールがどんどん増えていきますよね。最初は「WH1」「test_user」「role_a」みたいに気軽に作ってしまいがちですが、運用が進むとこんな悩みが出てきます。

  • 「このウェアハウス、誰が何のために使ってるんだっけ?」
  • 「このロール、本番用?開発用?」
  • 「コスト分析しようにも、名前から用途が分からない…」

こうした問題を防ぐ最強の予防策が 命名規則(ネーミングルール) です。この記事では、Snowflake公式が推奨する考え方を踏まえつつ、初心者でもすぐ真似できる名前の付け方をやさしく紹介します。

Snowflake命名規則ベストプラクティス|ウェアハウス・ユーザー・ロール

共通ルール:Snowflakeにおける名前の基本

まず大前提として、Snowflakeの識別子(オブジェクト名)はデフォルトで大文字に正規化されます。つまり my_wh も MY_WH も同じものとして扱われます。そこで実用的なルールはこちらです。

  • 大文字+アンダースコア区切り(SCREAMING_SNAKE_CASE)で統一する
  • ダブルクォートで囲む特殊文字や日本語名は避ける(運用が複雑になります)
  • 短すぎず、長すぎず。「種別_用途_環境_サイズ」のように構造化

ウェアハウスの命名規則

ウェアハウスはコスト直結リソースなので、用途・環境・サイズが一目で分かる名前にしましょう。フォーマット例はこちら。

<用途>_<部門/チーム>_<環境>_<サイズ>_WH

例:
ETL_FINANCE_PRD_M_WH      -- 経理部のETL用、本番、Mサイズ
BI_MARKETING_DEV_S_WH     -- マーケのBI用、開発、Sサイズ
ADHOC_ANALYST_PRD_L_WH    -- アナリストのアドホック分析用

こうしておくと、後でウェアハウス使用状況の可視化を行う際に「どのチームがいくら使っているか」をSQLでサクッと集計できます。リソースモニターを割り当てるときも、名前で対象を絞りやすくなりますよ。

ユーザーの命名規則

ユーザーは「人間用」と「サービスアカウント用(BIツールやETLツールから接続するもの)」で分けるのがおすすめです。

-- 人間ユーザー: メールやAD名と揃える
TANAKA_TARO
SUZUKI_HANAKO

-- サービスアカウント: SVC_ プレフィックス
SVC_TABLEAU_PRD
SVC_AIRFLOW_ETL
SVC_FIVETRAN_INGEST

SVC_ プレフィックスを付けるだけで、「このユーザーは自動化処理用だから削除してはいけない」と一目で分かります。退職者の棚卸しもラクになりますね。

ユーザーの命名規則の解説図

ロールの命名規則

ロールは RBAC(ロールベースアクセス制御) の中核です。Snowflakeでは「機能ロール(権限の塊)」と「アクセスロール(オブジェクト単位の権限)」を分けるのがベストプラクティス。

-- 機能ロール: ユーザーに割り当てる
FINANCE_ANALYST_ROLE
MARKETING_ENGINEER_ROLE

-- アクセスロール: オブジェクト権限を束ねる
DB_SALES_RO_ROLE   -- SALES DBの読み取り専用
DB_SALES_RW_ROLE   -- SALES DBの読み書き

RO(Read Only)、RW(Read Write)、FULL のような権限種別を付けておくと、GRANT/REVOKE文を書くときの取り違えが激減します。

注意点:後から変更は意外と大変

オブジェクト名は ALTER ... RENAME TO で変更できますが、BIツールやスクリプトのハードコードを直す手間がかかります。最初の小さなプロジェクトのうちにルールを決めて、ドキュメント化しておきましょう。

まとめ

命名規則は地味ですが、運用が長くなるほど効いてくる「未来の自分への投資」です。今日から 用途_環境_サイズ_WH、SVC_、_RO_ROLE などのパターンを取り入れて、見通しの良いSnowflake環境を育てていきましょう!

参考リンク

関連記事