Snowflake 命名規則・開発ルールのたたき台（dbt前提）

Snowflake を複数人のチームで使い始めると、必ずぶつかるのが「命名がバラバラで検索性・可読性が落ちる」という問題です。この記事では dbt 前提・DEV / PROD の2環境構成を想定した、命名規則と開発ルールのたたき台を整理します。すでに Snowflake を触っているチームが、自分たちのルールを決める際の出発点として使えることを目指しています。

命名スタイルの基本方針

最初に決めるべきは大文字・小文字と区切り文字のスタイルです。ここでは snake_case（小文字）への統一を推奨します。

Snowflake は非クォート識別子を内部的にすべて大文字へ正規化する仕様があります。つまり DDL 上で小文字で書いても、実体としては SNAKE_CASE に変換されます。この挙動自体は避けられないため、「DDL ソースコード上は小文字で統一して書く」というルールにするのが現実的です。クエリツールでの視認性や Git 差分の可読性が上がります。

もう一つ注意したいのが予約語との衝突です。date type value のようなカラム名は将来 Snowflake の組み込み関数・キーワードと衝突するリスクがあるため、event_date record_type のように接尾辞を付けて回避します。

環境・レイヤー分離の設計

環境分離とデータレイヤー分離は別軸の問題です。ここでは「DB で環境を分け、スキーマでレイヤーを分ける」方式を採用します。

<ENV>_<DOMAIN>          -- データベース
  └─ RAW                -- 生データ（Extract/Loadそのまま、変更不可）
  └─ STAGING            -- 型変換・リネームのみ
  └─ INTERMEDIATE        -- 結合・中間集計
  └─ MART                -- BI/分析用の最終成果物

例えば DEV_ANALYTICS.RAW、PROD_ANALYTICS.MART のような構成になります。

この分け方には2つの利点があります。1つは環境ごとに DB を分けることで権限管理（ROLE 付与）が DB 単位で完結し、DEV での誤操作が PROD に波及するリスクを構造的に減らせること。もう1つはスキーマでレイヤーを分けることで、dbt の generate_schema_name やモデルディレクトリ構成と自然に対応することです。

環境数は必要になったタイミングで増やせます。まずは DEV / PROD の2段階で始め、ステージング環境が必要になれば STG_ANALYTICS を追加するだけで拡張できる設計にしておくと、初期のオーバーエンジニアリングを避けられます。

データベース・スキーマの命名

対象	規則	例
Database	`<env>_<domain>`	`prod_analytics`, `dev_analytics`
Schema	レイヤー名固定語彙	`raw`, `staging`, `intermediate`, `mart`

テーブル・ビューの命名

dbt を前提とする場合、dbt コミュニティで広く使われている接頭辞規則をそのまま採用するのが合理的です。独自ルールを作るよりも、他プロジェクトの資料やオンボーディング資料を流用しやすくなります。

対象	規則	例
Raw テーブル	`<source_system>__<entity>`	`salesforce__opportunities`
Staging	`stg_<source>__<entity>`	`stg_salesforce__opportunities`
Intermediate	`int_<domain>__<verb句>`	`int_orders__joined_customers`
Mart（テーブル）	`fct_<entity>` / `dim_<entity>`	`fct_orders`, `dim_customers`

ビューについては vw_ のような接頭辞は原則付けません。テーブルかビューかは実装詳細であり、呼び出し側（他のモデルや BI ツール）が意識する必要がないという考え方です。Fact / Dimension に分類しづらいものだけ、rpt_（レポート専用）のような例外接頭辞を許可します。

カラムの命名

対象	規則	例
主キー	`<entity>_id`	`order_id`
外部キー	参照先の主キー名をそのまま	`customer_id`
真偽値	`is_` / `has_` 接頭辞	`is_active`, `has_subscription`
日時	`_at`（タイムスタンプ）/ `_date`（日付のみ）	`created_at`, `order_date`
金額	通貨単位が明確な接尾辞	`amount_usd`, `price_jpy`
dbt標準メタカラム	接頭辞 `_` で明示	`_loaded_at`, `_dbt_updated_at`

外部キーは「参照先の主キー名をそのまま使う」のがポイントです。テーブルが変わっても同じ意味のカラムは同じ名前になるため、JOIN 条件を書くときに迷いません。

ウェアハウスの命名

<env>_<team_or_purpose>_wh

prod_etl_wh（ELT処理用、自動サスペンド短め）
prod_bi_wh（BIツール接続用、マルチクラスタ許容）
dev_adhoc_wh（開発者の一時利用）

意図的にウェアハウスサイズを名前に含めていません。ALTER WAREHOUSE でサイズを変更した際にリネームが発生しないようにするためです。用途ベースの命名にしておくと、コスト最適化のためのサイズ変更が気軽に行えます。

ロールの命名と RBAC 設計

<env>_<domain>_<access_level>_role

dev_analytics_transform_role
dev_analytics_read_role
prod_analytics_transform_role（dbt実行用）
prod_analytics_read_role
prod_analytics_admin_role

Snowflake が推奨する RBAC パターンに沿い、「機能ロール（transform, read）」と「アクセスロール」を分離し、ユーザーへは機能ロールを直接付与しません。DEV には admin_role を作らず、開発者は transform_role で作業できる範囲に留めます。PROD への書き込み操作は CI/CD 経由の transform_role のみに限定し、人間のユーザーには基本的に read_role のみを付与するのが安全です。

ステージ・ファイルフォーマット・パイプ

対象	規則	例
Stage	`<source>_stage`	`s3_salesforce_stage`
File Format	`<形式>_format`	`csv_format`, `json_format`
Pipe	`<entity>_pipe`	`orders_pipe`
Task	`<entity>_<動詞>_task`	`orders_refresh_task`
Stream	`<entity>_stream`	`orders_stream`

dbt モデル層のルール

ディレクトリ構成はスキーマレイヤーに対応させる

models/
  staging/<source>/stg_<source>__<entity>.sql
  intermediate/int_<domain>__<desc>.sql
  marts/<domain>/fct_<entity>.sql
  marts/<domain>/dim_<entity>.sql

dbt_project.yml の generate_schema_name はカスタムマクロで上書きし、環境プレフィックスを付けない設定にします。dbt はデフォルトで target.schema にカスタムスキーマ名をサフィックスとして付加する挙動をするため、そのままだと raw staging intermediate mart という固定スキーマ名からズレてしまいます。
1 staging model = 1 source table を徹底し、sources.yml で RAW スキーマのテーブルを定義します。
モデルからの RAW スキーマへの直接参照を禁止し、source() / ref() のみを許可します。これは sqlfluff の dbt ルールなど lint ツールで機械的にチェック可能です。

開発ルール（運用面）

命名規則だけでなく、それを維持するための運用ルールもセットで決めておくと形骸化しにくくなります。

DDL 変更はマイグレーション管理を通す: dbt や Schemachange などのツールを経由し、手動の CREATE / ALTER は DEV のみ許可、PROD では禁止する
PR レビューを必須にする: SQL 変更は最低1名のレビューを通す
命名の例外には理由をコメントで残す: 例えば -- 予約語のためsuffix追加 のように、なぜ規則から外れているかを明示する
PII / 機微カラムにはタグ付けを必須にする: Snowflake の TAG 機能を使い、マスキングポリシーと連動させる

まとめ

Snowflake の命名規則は「DB で環境を分け、スキーマでレイヤーを分ける」という構造を軸に、dbt の標準的な接頭辞（stg_ int_ fct_ dim_）をそのまま採用するのが、独自色を出しすぎず運用しやすい落としどころです。ウェアハウスやロールの命名にも環境・用途を織り込むことで、権限管理やコスト管理がしやすくなります。

ここで挙げた内容はあくまでたたき台です。実際の組織では利用しているツール構成やチーム規模によって調整が必要になるため、まずは小さく決めて、運用しながら改善していくのがおすすめです。