[新機能]Snowflake提供タグ（Snowflake-provided tags）がパブリックプレビューとなったので試してみた

かわばたです。

2026年8月31日にSnowflake-provided tagsがPublic Previewとなりました。
すべてのアカウントの SNOWFLAKE.TAGS スキーマに、ガバナンス用途の既製タグが6種類自動作成される機能です。

https://docs.snowflake.com/en/user-guide/object-tagging/snowflake-provided-tags

これまでコストセンターや機密度のタグはアカウントごとに CREATE TAG で設計・運用していましたが、この機能により全アカウント共通の語彙をそのまま使えます。実際に試してみたので、手順と確認結果をまとめます。

【追記】
Snowflake Community Awards の「RISING COMMUNITY LEADER OF THE YEAR」部門・APJ枠のファイナリストに選ばれました。
詳細は下記よりご確認ください。

https://dev.classmethod.jp/articles/snowflake-community-awards-finalist-activities-review/

機能概要

Snowflake提供タグは、Snowflakeがすべてのアカウントの SNOWFLAKE.TAGS スキーマに自動作成する既製タグです（本記事では以降「提供タグ」と表記します）。ユーザーによる作成・削除はできません。提供されるのは以下の6種類です。

性質はタグごとに異なり、以下の4分類で捉えるとわかりやすいです。

• 許可値が固定: CERTIFICATION_STATUS
• 許可値が初期定義され、追加・削除可能: SENSITIVITY / ENVIRONMENT
• 許可値の事前定義なし（任意の文字列）: COST_CENTER / PROJECT
• 値ではなく特殊動作を制御: SKIP_TAG_PROPAGATION

なお、自動分類機能で使われる SNOWFLAKE.CORE の分類システムタグ（SEMANTIC_CATEGORY 等）とは別物なのでご注意ください。

ユーザー定義タグとの差分

従来のユーザー定義タグとの主な違いは以下です。

想定ユースケース

提供タグの語彙をそのまま使うと、以下のようなガバナンス運用を標準タグだけで始められます。

• 機密データの保護: SENSITIVITY にタグベースマスキングポリシーを紐付けて自動マスク（後述の検証で実施）
• コスト配賦: COST_CENTER / PROJECT をウェアハウス等に付与し、タグ別にコストを集計
• データ資産の認証運用: CERTIFICATION_STATUS でレビュー状態を管理し、利用者が CERTIFIED のデータを選別
• 環境の明示: ENVIRONMENT で本番・開発リソースを区別し、棚卸しや誤操作防止に活用

コスト配賦は、ACCOUNT_USAGE の TAG_REFERENCES とメータリング系ビュー（WAREHOUSE_METERING_HISTORY 等）を結合して集計する公式パターンがあります。公式Docの例はユーザー定義タグを使用していますが、今回の検証で、ウェアハウスへの SNOWFLAKE.TAGS.COST_CENTER 付与も可能なことを確認しました。

https://docs.snowflake.com/en/user-guide/cost-attributing

制限事項

• 2026年9月2日時点ではPublic Previewの機能です。GAまでに仕様が変わる可能性があります
• 提供タグの削除と、SNOWFLAKE.TAGS スキーマへのタグ追加はできません
• CERTIFICATION_STATUS の許可値は OOB_TAG_ADMIN でも変更できません
• SKIP_TAG_PROPAGATION とタグ自動伝播はEnterprise Edition以上が必要です
• 検証環境では SKIP_TAG_PROPAGATION による伝播停止が再現しませんでした（後述）

検証環境

• Snowflake: Trialアカウント AWS東京リージョン
• エディション: Enterprise Edition
• 必要な権限: ACCOUNTADMIN（アプリケーションロールの付与、検証用オブジェクト作成）

事前準備

検証用のDB・スキーマと、PII相当カラムを含む顧客テーブル（20レコード）を作成します。

USE ROLE ACCOUNTADMIN;
USE WAREHOUSE COMPUTE_WH;

CREATE DATABASE IF NOT EXISTS PROVIDED_TAGS_VERIFY_DB;
CREATE SCHEMA IF NOT EXISTS PROVIDED_TAGS_VERIFY_DB.VERIFY;
USE SCHEMA PROVIDED_TAGS_VERIFY_DB.VERIFY;

-- 検証用テーブル（ECサイトの顧客データ）
CREATE OR REPLACE TABLE CUSTOMERS (
    CUSTOMER_ID   NUMBER        COMMENT '顧客ID',
    CUSTOMER_NAME VARCHAR(100)  COMMENT '氏名（PII相当）',
    EMAIL         VARCHAR(200)  COMMENT 'メールアドレス（PII相当）',
    PHONE         VARCHAR(20)   COMMENT '電話番号（PII相当）',
    PREFECTURE    VARCHAR(20)   COMMENT '都道府県',
    PLAN_TYPE     VARCHAR(20)   COMMENT '契約プラン',
    SIGNUP_DATE   DATE          COMMENT '登録日',
    MONTHLY_FEE   NUMBER(10,0)  COMMENT '月額料金'
);

INSERT INTO CUSTOMERS VALUES
    (1,  'Taro Yamada',    'taro.yamada@example.com',    '090-1111-0001', 'Tokyo',    'PREMIUM',  '2025-01-15', 3000),
    (2,  'Hanako Sato',    'hanako.sato@example.com',    '090-1111-0002', 'Osaka',    'STANDARD', '2025-02-01', 1500),
    (3,  'Ichiro Suzuki',  'ichiro.suzuki@example.com',  '090-1111-0003', 'Aichi',    'FREE',     '2025-02-14', 0),
    (4,  'Yuki Tanaka',    'yuki.tanaka@example.com',    '090-1111-0004', 'Hokkaido', 'STANDARD', '2025-03-03', 1500),
    (5,  'Kenji Watanabe', 'kenji.watanabe@example.com', '090-1111-0005', 'Fukuoka',  'PREMIUM',  '2025-03-20', 3000),
    (6,  'Mika Ito',       'mika.ito@example.com',       '090-1111-0006', 'Tokyo',    'FREE',     '2025-04-01', 0),
    (7,  'Shota Kato',     'shota.kato@example.com',     '090-1111-0007', 'Kanagawa', 'STANDARD', '2025-04-18', 1500),
    (8,  'Aoi Kobayashi',  'aoi.kobayashi@example.com',  '090-1111-0008', 'Kyoto',    'PREMIUM',  '2025-05-02', 3000),
    (9,  'Ren Yoshida',    'ren.yoshida@example.com',    '090-1111-0009', 'Hyogo',    'FREE',     '2025-05-25', 0),
    (10, 'Sakura Yamamoto','sakura.yamamoto@example.com','090-1111-0010', 'Tokyo',    'STANDARD', '2025-06-10', 1500),
    (11, 'Daiki Nakamura', 'daiki.nakamura@example.com', '090-1111-0011', 'Saitama',  'PREMIUM',  '2025-06-28', 3000),
    (12, 'Rin Hayashi',    'rin.hayashi@example.com',    '090-1111-0012', 'Chiba',    'FREE',     '2025-07-07', 0),
    (13, 'Sota Shimizu',   'sota.shimizu@example.com',   '090-1111-0013', 'Osaka',    'STANDARD', '2025-07-19', 1500),
    (14, 'Mei Mori',       'mei.mori@example.com',       '090-1111-0014', 'Miyagi',   'PREMIUM',  '2025-08-04', 3000),
    (15, 'Haruto Ikeda',   'haruto.ikeda@example.com',   '090-1111-0015', 'Hiroshima','FREE',     '2025-08-22', 0),
    (16, 'Yua Hashimoto',  'yua.hashimoto@example.com',  '090-1111-0016', 'Tokyo',    'STANDARD', '2025-09-09', 1500),
    (17, 'Kaito Abe',      'kaito.abe@example.com',      '090-1111-0017', 'Niigata',  'PREMIUM',  '2025-09-30', 3000),
    (18, 'Hina Ishikawa',  'hina.ishikawa@example.com',  '090-1111-0018', 'Okinawa',  'FREE',     '2025-10-11', 0),
    (19, 'Yamato Ogawa',   'yamato.ogawa@example.com',   '090-1111-0019', 'Nagano',   'STANDARD', '2025-10-27', 1500),
    (20, 'Koharu Goto',    'koharu.goto@example.com',    '090-1111-0020', 'Shizuoka', 'PREMIUM',  '2025-11-15', 3000);

試してみた

提供タグを確認する

まず SNOWFLAKE.TAGS スキーマの中身を確認します。

SHOW TAGS IN SCHEMA SNOWFLAKE.TAGS;

6種類のタグが表示されれば問題ありません。owner が SNOWFLAKE、owner_role_type が APPLICATION になっており、通常のロールでは所有・削除できない構造だとわかります。

SENSITIVITY のコメントには「Enterprise Edition以上なら ALTER TAG SNOWFLAKE.TAGS.SENSITIVITY SET PROPAGATE = ON_DEPENDENCY_AND_DATA_MOVEMENT ON_CONFLICT = ALLOWED_VALUES_SEQUENCE で自動伝播を有効化できる」という案内が入っていました。
初期状態の許可値は、RESTRICTED、CONFIDENTIAL、INTERNAL、PUBLIC の順（機密度の高い順）に定義されています。ON_CONFLICT = ALLOWED_VALUES_SEQUENCE を設定した場合はこの順序で伝播時の競合が解決され、先に定義された値が優先されます。

タグを付与して参照する

スキーマ・テーブル・カラムのそれぞれに付与します。

-- スキーマへ付与（配下のオブジェクトに継承される）
ALTER SCHEMA PROVIDED_TAGS_VERIFY_DB.VERIFY SET TAG SNOWFLAKE.TAGS.ENVIRONMENT = 'DEVELOPMENT';

-- テーブルへ3タグまとめて付与
ALTER TABLE CUSTOMERS SET TAG
  SNOWFLAKE.TAGS.CERTIFICATION_STATUS = 'IN REVIEW',
  SNOWFLAKE.TAGS.COST_CENTER = 'DATA-PLATFORM',
  SNOWFLAKE.TAGS.PROJECT = 'CUSTOMER-ANALYTICS';

-- カラムへ付与
ALTER TABLE CUSTOMERS MODIFY COLUMN EMAIL SET TAG SNOWFLAKE.TAGS.SENSITIVITY = 'CONFIDENTIAL';
ALTER TABLE CUSTOMERS MODIFY COLUMN PHONE SET TAG SNOWFLAKE.TAGS.SENSITIVITY = 'CONFIDENTIAL';
ALTER TABLE CUSTOMERS MODIFY COLUMN CUSTOMER_NAME SET TAG SNOWFLAKE.TAGS.SENSITIVITY = 'INTERNAL';

SYSTEM$GET_TAG で設定値が返れば問題ないです。

SELECT SYSTEM$GET_TAG('SNOWFLAKE.TAGS.CERTIFICATION_STATUS', 'PROVIDED_TAGS_VERIFY_DB.VERIFY.CUSTOMERS', 'table');

TAG_REFERENCES テーブル関数では、APPLY_METHOD 列でタグがどのように付与されたかを確認できます。

SELECT TAG_NAME, TAG_VALUE, LEVEL, OBJECT_NAME, APPLY_METHOD
FROM TABLE(PROVIDED_TAGS_VERIFY_DB.INFORMATION_SCHEMA.TAG_REFERENCES('PROVIDED_TAGS_VERIFY_DB.VERIFY.CUSTOMERS', 'TABLE'))
ORDER BY TAG_NAME;

実行結果は以下のとおり。直接付与したタグは MANUAL、スキーマから継承した ENVIRONMENT は INHERITED になっています。

カラム単位の一括確認は TAG_REFERENCES_ALL_COLUMNS を使います。テーブル・ビューのいずれを対象にする場合も、第2引数には TABLE を指定します。

許可値が定義されているタグに、許可値以外の値を設定するとエラーになります。

ALTER TABLE CUSTOMERS SET TAG SNOWFLAKE.TAGS.ENVIRONMENT = 'INVALID_ENV';

権限モデルを確認する

提供タグの権限は、通常のタグ権限ではなく SNOWFLAKE アプリケーションのアプリケーションロール3種で管理します。

SHOW GRANTS OF APPLICATION ROLE の実行結果では、今回のアカウントにおいて OOB_TAG_ADMIN → OOB_TAG_APPLY → OOB_TAG_READ の順の包含関係を確認できました。上位を付与すれば下位の権限も含まれます。

SHOW GRANTS OF APPLICATION ROLE SNOWFLAKE.OOB_TAG_READ;
-- granted_to APPLICATION_ROLE PUBLIC / OOB_TAG_APPLY などが表示される

許可値をカスタマイズする

OOB_TAG_ADMIN を付与したロールで、SENSITIVITY に許可値を追加してみます。

USE ROLE TAG_ADMIN_ROLE;
USE SECONDARY ROLES NONE;

ALTER TAG SNOWFLAKE.TAGS.SENSITIVITY ADD ALLOWED_VALUES '__VERIFY_20260902__';

SHOW TAGS で許可値に追加されたことを確認し、追加値でのタグ付与も成功しました。検証後は DROP ALLOWED_VALUES で元に戻しています。

ALTER TAG SNOWFLAKE.TAGS.SENSITIVITY DROP ALLOWED_VALUES '__VERIFY_20260902__';

ENVIRONMENT でも同様に、許可値の追加と DROP ALLOWED_VALUES による復元ができました。

一方、CERTIFICATION_STATUS の許可値変更は OOB_TAG_ADMIN でも拒否されます。

ALTER TAG SNOWFLAKE.TAGS.CERTIFICATION_STATUS ADD ALLOWED_VALUES 'MY_STATUS';

提供タグの許可値はアカウント全体で共有される設定となります。

タグ自動伝播とSKIP_TAG_PROPAGATIONを確認する

タグ自動伝播と組み合わせて試します。タグ自動伝播とタグベースマスキングポリシーはEnterprise Edition以上の機能です（タグの付与・参照自体は全エディションで可能）。まず伝播設定つきのユーザー定義タグで、伝播の基本動作を確認します。

USE ROLE ACCOUNTADMIN;
USE SCHEMA PROVIDED_TAGS_VERIFY_DB.VERIFY;

CREATE OR REPLACE TAG DATA_ORIGIN
  PROPAGATE = ON_DEPENDENCY_AND_DATA_MOVEMENT
  COMMENT = 'Propagation verification tag (user-defined)';
ALTER TABLE CUSTOMERS SET TAG DATA_ORIGIN = 'CRM';

-- ビュー（オブジェクト依存関係による伝播）
CREATE OR REPLACE VIEW CUSTOMERS_VIEW AS
SELECT CUSTOMER_ID, CUSTOMER_NAME, EMAIL, PLAN_TYPE FROM CUSTOMERS;

-- CTAS（データ移動による伝播）
CREATE OR REPLACE TABLE CUSTOMERS_COPY AS SELECT * FROM CUSTOMERS;

TAG_REFERENCES で確認します。

SELECT TAG_NAME, TAG_VALUE, APPLY_METHOD
FROM TABLE(PROVIDED_TAGS_VERIFY_DB.INFORMATION_SCHEMA.TAG_REFERENCES('PROVIDED_TAGS_VERIFY_DB.VERIFY.CUSTOMERS_VIEW', 'TABLE'))
WHERE TAG_NAME = 'DATA_ORIGIN';

ビュー・CTAS先の両方に APPLY_METHOD = PROPAGATED で DATA_ORIGIN が付いていれば問題ありません。

INSERT（データ移動）による伝播は、後述の SKIP_TAG_PROPAGATION 検証の中で確認します。

次に、提供タグ自体への伝播設定です。SENSITIVITY のコメントに記載されていた推奨コマンドをそのまま実行します。

ALTER TAG SNOWFLAKE.TAGS.SENSITIVITY SET PROPAGATE = ON_DEPENDENCY_AND_DATA_MOVEMENT ON_CONFLICT = ALLOWED_VALUES_SEQUENCE;
ALTER TABLE CUSTOMERS SET TAG SNOWFLAKE.TAGS.SENSITIVITY = 'RESTRICTED';

CREATE OR REPLACE TABLE CUSTOMERS_COPY3 AS SELECT * FROM CUSTOMERS;

-- カラム単位の伝播確認
SELECT TAG_NAME, TAG_VALUE, LEVEL, COLUMN_NAME, APPLY_METHOD
FROM TABLE(PROVIDED_TAGS_VERIFY_DB.INFORMATION_SCHEMA.TAG_REFERENCES_ALL_COLUMNS('PROVIDED_TAGS_VERIFY_DB.VERIFY.CUSTOMERS_COPY3', 'TABLE'))
WHERE TAG_NAME = 'SENSITIVITY'
ORDER BY COLUMN_NAME;

設定は成功しました。ソース側は、テーブルへ RESTRICTED を直接付与し、EMAIL 等のカラムには先ほどの手順で CONFIDENTIAL 等を直接付与済みの状態です。CTAS先を TAG_REFERENCES_ALL_COLUMNS で確認すると、直接付与していたタグがテーブル・カラムの両レベルとも PROPAGATED で伝播していました。

CTAS先のテーブル自体には、ソーステーブルの RESTRICTED が PROPAGATED で付いています。カラムタグのないカラムに表示される RESTRICTED は、そのテーブルタグの継承（INHERITED）です。

最後に SKIP_TAG_PROPAGATION です。公式Docの記載どおり、伝播を止めたい下流オブジェクトに空文字列で設定します。この時点で CUSTOMERS_COPY / CUSTOMERS_VIEW には DATA_ORIGIN が伝播済みです。

ALTER TABLE CUSTOMERS_COPY SET TAG SNOWFLAKE.TAGS.SKIP_TAG_PROPAGATION = '';
ALTER VIEW  CUSTOMERS_VIEW SET TAG SNOWFLAKE.TAGS.SKIP_TAG_PROPAGATION = '';

設定後にソースへ新しい伝播タグを追加し、SKIP設定先へ伝播しないことを確認します。

-- ソースに2つ目の伝播タグを追加（SKIP設定後に追加したタグとして区別する）
CREATE OR REPLACE TAG DATA_QUALITY
  PROPAGATE = ON_DEPENDENCY_AND_DATA_MOVEMENT;
ALTER TABLE CUSTOMERS SET TAG DATA_QUALITY = 'VALIDATED';

-- SKIP設定済みテーブルへデータ移動（INSERT）を発生させる
INSERT INTO CUSTOMERS_COPY SELECT * FROM CUSTOMERS WHERE CUSTOMER_ID <= 2;

-- 確認: DATA_QUALITY が付いていなければ期待どおり
SELECT TAG_NAME, TAG_VALUE, APPLY_METHOD
FROM TABLE(PROVIDED_TAGS_VERIFY_DB.INFORMATION_SCHEMA.TAG_REFERENCES('PROVIDED_TAGS_VERIFY_DB.VERIFY.CUSTOMERS_COPY', 'TABLE'))
ORDER BY TAG_NAME;

SELECT TAG_NAME, TAG_VALUE, APPLY_METHOD
FROM TABLE(PROVIDED_TAGS_VERIFY_DB.INFORMATION_SCHEMA.TAG_REFERENCES('PROVIDED_TAGS_VERIFY_DB.VERIFY.CUSTOMERS_VIEW', 'TABLE'))
ORDER BY TAG_NAME;

期待は「設定前に伝播済みの DATA_ORIGIN は残り、設定後の DATA_QUALITY は伝播しない」でした。しかし実測では、ビュー（依存関係）・テーブル（INSERTによるデータ移動）の両方に DATA_QUALITY が PROPAGATED で付いてしまいました。

検証後は、提供タグの伝播設定を元に戻しておきます。実行後の SHOW TAGS で propagate が NONE、on_conflict が None に戻ることを確認済みです。

ALTER TAG SNOWFLAKE.TAGS.SENSITIVITY UNSET PROPAGATE;

検証環境では SKIP_TAG_PROPAGATION の伝播停止を再現できなかった

公式Docの仕様では「オブジェクトに設定すると、そのオブジェクトへの以後のタグ伝播をすべて一時停止する（伝播済みタグは削除しない・UNSETで再開）」と説明されています。しかし2026年9月2日時点の検証環境では、公式仕様と異なり、設定後のタグ伝播も発生しました。実測結果は以下です。

• 設定前に伝播済みだったタグ（DATA_ORIGIN）が削除されず残ることは、仕様どおり確認できた
• 設定後にソースへ追加した伝播タグ（DATA_QUALITY 等）が、依存関係（ビュー）経由で伝播した
• 同じタグが、INSERT（データ移動）経由でも伝播した
• ユーザー定義タグ・提供タグ（SENSITIVITY）のどちらの伝播でも止まらなかった
• SKIP_TAG_PROPAGATION を設定したオブジェクトをソースにCTASした場合も、下流オブジェクトへのタグ伝播は止まらなかった（下記SQL）

-- SKIP設定済みの CUSTOMERS_COPY をソースに CTAS
CREATE OR REPLACE TABLE CUSTOMERS_CHAIN AS SELECT * FROM CUSTOMERS_COPY;

-- 確認: 伝播タグは CUSTOMERS_CHAIN にも PROPAGATED で付いた
SELECT TAG_NAME, TAG_VALUE, APPLY_METHOD
FROM TABLE(PROVIDED_TAGS_VERIFY_DB.INFORMATION_SCHEMA.TAG_REFERENCES('PROVIDED_TAGS_VERIFY_DB.VERIFY.CUSTOMERS_CHAIN', 'TABLE'))
ORDER BY TAG_NAME;

設定自体は TAG_REFERENCES 上で SKIP_TAG_PROPAGATION が空文字列・APPLY_METHOD = MANUAL として確認でき、設定から数分待っても挙動は変わりませんでした。なお SKIP_TAG_PROPAGATION タグ自体が下流へ伝播しないことは確認できています。

本結果は、2026年9月2日時点の特定アカウント・リージョン・Preview環境における観測結果であり、すべてのアカウントで同じ挙動になることを示すものではありません。Preview中の制限、または検証条件による差異の可能性があり、今回の結果だけで仕様不具合とは断定できません。ただし現時点で SKIP_TAG_PROPAGATION を前提とした伝播除外設計は、少なくともGAまでは慎重に扱った方が良さそうです。

ユースケース: SENSITIVITY にマスキングポリシーを紐付ける

想定ユースケースの代表として、タグベースマスキングポリシー（Enterprise Edition以上）との組み合わせを試します。

https://docs.snowflake.com/en/user-guide/tag-based-masking-policies

タグ値を SYSTEM$GET_TAG_ON_CURRENT_COLUMN で判定するポリシーを作成し、提供タグに紐付けます。

-- タグ値で判定するマスキングポリシー
CREATE OR REPLACE MASKING POLICY SENSITIVITY_STRING_MASK AS (VAL STRING) RETURNS STRING ->
  CASE
    WHEN SYSTEM$GET_TAG_ON_CURRENT_COLUMN('SNOWFLAKE.TAGS.SENSITIVITY') IN ('RESTRICTED', 'CONFIDENTIAL')
      THEN '*** MASKED ***'
    ELSE VAL
  END;

-- 提供タグへ紐付け
ALTER TAG SNOWFLAKE.TAGS.SENSITIVITY SET MASKING POLICY SENSITIVITY_STRING_MASK;

紐付けは成功しました。SENSITIVITY を付与済みのカラムを含むテーブルを参照します。

SELECT CUSTOMER_NAME, EMAIL, PHONE FROM CUSTOMERS;

CONFIDENTIAL を付与したメール・電話番号だけがマスクされ、INTERNAL の氏名は表示されたままなら問題ありません。提供タグの許可値が、そのまま保護レベルの共通語彙として機能します。

このポリシーはロール条件を入れていないため、全ロールでマスクされます。実運用では IS_ROLE_IN_SESSION 等のロール条件を組み合わせて、許可ロールのみ実データを参照できるようにします。なお、1つのタグに紐付けられるマスキングポリシーはデータ型ごとに1つまでです。今回のポリシーはSTRING型向けのため、MONTHLY_FEE などのNUMBER型カラムは対象外です。NUMBER型も保護する場合は、NUMBER型用のポリシーを作成して同じタグに紐付けます。

最後に

Snowflake提供タグを試して、共通語彙のタグ付与・アプリケーションロールによる権限管理・許可値カスタマイズ・伝播設定まで確認できました。タグ設計の初期コストが下がるので、まずは SENSITIVITY と ENVIRONMENT の付与から始めるのがおすすめです。SKIP_TAG_PROPAGATION はプレビュー中の挙動にご注意ください。

Snowflake-provided tagsを利用するメリットは下記にあると思います。

• タグ設計・作成が不要ですぐ使え、全アカウントで同じ名前・同じ許可値の共通語彙になる
• 権限管理がアプリケーションロール3種（OOB_TAG_READ / OOB_TAG_APPLY / OOB_TAG_ADMIN）に集約され、設計不要
• 誤削除の心配がない

この記事が何かの参考になれば幸いです！