[新機能]Feature Policy Rules が一般提供となったので TEMPORARY テーブルとサーバーレスタスクの作成だけをブロックしてみた

[新機能]Feature Policy Rules が一般提供となったので TEMPORARY テーブルとサーバーレスタスクの作成だけをブロックしてみた

Snowflake の Feature Policy に条件付きルール機能が GA となりました。本記事では、rules による柔軟なオブジェクト作成制御と DESC FEATURE POLICY の動作を検証し、サーバーレスタスクや一時テーブルの禁止など実用的なポリシー設計を試してみました。
2026.08.23

かわばたです。

2026年8月16日にFeature Policy Rules が一般提供となりました。

本記事では、rules によるオブジェクト作成の条件付きブロックと、同時に GA となった DESC FEATURE POLICY の出力を検証します。

【公式ドキュメント】
Feature Policy Rules
https://docs.snowflake.com/en/user-guide/feature-policies

https://docs.snowflake.com/en/sql-reference/sql/desc-feature-policy

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

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

Feature Policy Rules の概要

Feature Policy は「そのコンテナ内でどのオブジェクトを作成できるか」を制御するガバナンス機能です。適用単位はユーザーやロールではなく、データベース・Personal Database・Native App というコンテナです(アカウントレベルでの一括適用も可能)。

今回の GA で、従来のタイプ単位ブロックに加えて rules による条件付きブロックが書けます。

従来: BLOCKED_OBJECT_TYPES_FOR_CREATION 新: rules (YAML body)
粒度 オブジェクトタイプ単位の all-or-nothing リクエスト属性による条件付き
タスクを一切作らせない サーバーレスタスクだけ禁止
対象タイプ TASKS, DATABASES, WAREHOUSES 等 12種 TABLE, VIEW, STAGE, FUNCTION, PROCEDURE 等に拡大

rules はポリシー定義の AS $$ ... $$ に YAML で記述します。block_when の SQL 式が TRUE と評価された作成リクエストがブロックされます。

CREATE FEATURE POLICY <name>
  [ BLOCKED_OBJECT_TYPES_FOR_CREATION = ( <type> [ , ... ] ) ]
  AS $$
    blocked_creation_rules:
      - object_type: <OBJECT_TYPE>
        block_when: "<SQL式>"
  $$;

式の中では SYS_CONTEXT('SNOWFLAKE$REQUEST', 'GET_OBJECT_PROPERTY', '<プロパティ>') で作成リクエストの属性を参照します。プロパティは IS_TEMPORARY / IS_TRANSIENT / WAREHOUSE / EXTERNAL_VOLUME / DATABASE / SCHEMA の6種類で、戻り値はすべて文字列です(Boolean 系は = 'TRUE' と比較します)。

前提条件

  • ポリシー作成: ポリシー格納先スキーマへの CREATE FEATURE POLICY 権限
  • ポリシー適用: アカウントへの APPLY FEATURE POLICY 権限と、適用する Feature Policy への APPLY または OWNERSHIP 権限
  • エディション要件はドキュメントに明記されていません(トライアルアカウントで動作を確認済み)

検証は2026年8月21日および23日(日本時間)に AWS 東京リージョンのアカウントで実施しています。ロールはすべて ACCOUNTADMIN です。

事前準備

ポリシー格納用 DB と適用対象 DB を作成します。

USE ROLE ACCOUNTADMIN;

CREATE OR REPLACE DATABASE FP_POLICY_DB;   -- ポリシー格納用
CREATE SCHEMA FP_POLICY_DB.POLICIES;
CREATE OR REPLACE DATABASE FP_TEST_DB;     -- 適用対象
CREATE OR REPLACE DATABASE FP_TEST_DB2;    -- 優先順位検証用

試してみた

従来型: タイプ単位の all-or-nothing

比較のため、まず従来の BLOCKED_OBJECT_TYPES_FOR_CREATION でタスク作成を禁止します。

CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TASKS_ALL
  BLOCKED_OBJECT_TYPES_FOR_CREATION = (TASKS)
  COMMENT = 'Block all task creation (legacy style)';

ALTER DATABASE FP_TEST_DB
  SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TASKS_ALL;

ウェアハウス指定タスクを作成してみます。

CREATE TASK FP_TEST_DB.PUBLIC.T_WH
  WAREHOUSE = COMPUTE_WH SCHEDULE = '60 MINUTE' AS SELECT 1;

2026-08-23_22h15_25

サーバーレスタスク(WAREHOUSE 指定なし)も同じエラーでブロックされ、テーブル作成は成功しました。タイプ単位のためタスクは全部か無かの制御になります。

注目すべきは、ACCOUNTADMIN でもブロックされる点です。Feature Policy はロールではなく DB というコンテナに効くため、管理者の操作も例外になりません。

次の検証のため解除しておきます。

ALTER DATABASE FP_TEST_DB UNSET FEATURE POLICY;

rules: TEMPORARY テーブルだけブロックできる

GA の本命である rules を試します。IS_TEMPORARY プロパティを条件に、TEMPORARY テーブルの作成だけを禁止します。

CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TEMP_TABLES
  COMMENT = 'Block only temporary tables'
  AS $$
    blocked_creation_rules:
      - object_type: TABLE
        block_when: "SYS_CONTEXT('SNOWFLAKE$REQUEST', 'GET_OBJECT_PROPERTY', 'IS_TEMPORARY') = 'TRUE'"
  $$;

ALTER DATABASE FP_TEST_DB
  SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TEMP_TABLES;

2026-08-23_22h16_17

3種類のテーブルを作成した結果です。

CREATE TABLE FP_TEST_DB.PUBLIC.T2 (ID INT);            -- 成功
CREATE TEMPORARY TABLE FP_TEST_DB.PUBLIC.T3 (ID INT);  -- ブロック (003001)
CREATE TRANSIENT TABLE FP_TEST_DB.PUBLIC.T4 (ID INT);  -- 成功

2026-08-23_22h16_59

2026-08-23_22h17_18

2026-08-23_22h17_48

TEMPORARY だけがブロックされました。TRANSIENT は IS_TEMPORARY に該当しないため成功します(TRANSIENT も止めるなら IS_TRANSIENT の条件を追加します)。従来型では不可能だった「テーブルは許可、ただし一時テーブルだけ禁止」が実現できています。

rules: サーバーレスタスクだけブロックできる

タスクの WAREHOUSE プロパティは、ウェアハウス指定がないサーバーレスタスクで NULL になります。これを条件にすると、コスト統制の定番要望「サーバーレスタスクだけ禁止」を実装できます。

CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_SERVERLESS_TASKS
  COMMENT = 'Block only serverless tasks'
  AS $$
    blocked_creation_rules:
      - object_type: TASK
        block_when: "SYS_CONTEXT('SNOWFLAKE$REQUEST', 'GET_OBJECT_PROPERTY', 'WAREHOUSE') IS NULL"
  $$;

適用しようとしたところ、エラーになりました。

ALTER DATABASE FP_TEST_DB
  SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_SERVERLESS_TASKS;

2026-08-23_22h18_54

1つのデータベースに直接バインドできる Feature Policy は1つです。既存の DB レベルポリシーがある状態で FORCE を付けずに SET するとエラーになります。今回は FORCE を指定して直接置き換えます。

-- FORCE で既存の DB レベルポリシーを直接置き換える
ALTER DATABASE FP_TEST_DB
  SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_SERVERLESS_TASKS
  FORCE;

2026-08-23_22h19_27
タスクを2パターン作成した結果です。

-- ウェアハウス指定タスク → 成功
CREATE TASK FP_TEST_DB.PUBLIC.T_WH
  WAREHOUSE = COMPUTE_WH SCHEDULE = '60 MINUTE' AS SELECT 1;

-- サーバーレスタスク → ブロック (003001)
CREATE TASK FP_TEST_DB.PUBLIC.T_SERVERLESS
  SCHEDULE = '60 MINUTE' AS SELECT 1;

2026-08-23_22h20_51

2026-08-23_22h21_24

狙いどおり、ウェアハウス指定タスクは作成でき、サーバーレスタスクだけがブロックされました。

名前付き条件で複数タイプに同じ条件を使い回せる

conditions で名前を付けた式は、block_when_any で複数のルールから参照できます。従来型パラメータとの併用も可能です。

CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TEMP_AND_WH
  COMMENT = 'Named condition + legacy param combined'
  BLOCKED_OBJECT_TYPES_FOR_CREATION = (WAREHOUSES)
  AS $$
    conditions:
      - name: is_temp
        expression: "SYS_CONTEXT('SNOWFLAKE$REQUEST', 'GET_OBJECT_PROPERTY', 'IS_TEMPORARY') = 'TRUE'"
    blocked_creation_rules:
      - object_type: TABLE
        block_when_any:
          - is_temp
      - object_type: STAGE
        block_when_any:
          - is_temp
  $$;

ALTER DATABASE FP_TEST_DB UNSET FEATURE POLICY;
ALTER DATABASE FP_TEST_DB
  SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TEMP_AND_WH;
CREATE TEMPORARY TABLE FP_TEST_DB.PUBLIC.T6 (ID INT);  -- ブロック
CREATE TEMPORARY STAGE FP_TEST_DB.PUBLIC.S_TEMP;       -- ブロック (Create STAGE denied)
CREATE STAGE FP_TEST_DB.PUBLIC.S1;                     -- 成功

2026-08-23_22h22_21

2026-08-23_22h22_47

2026-08-23_22h23_10

テーブル・ステージの両方で TEMPORARY だけがブロックされました。一方、併用した WAREHOUSES は効きませんでした。

CREATE WAREHOUSE FP_TEST_WH WITH WAREHOUSE_SIZE = 'XSMALL' INITIALLY_SUSPENDED = TRUE;

2026-08-23_22h23_40

ウェアハウスはアカウントレベルオブジェクトで、作成は DB コンテナの外の操作です。そのため DB にバインドしたポリシーでは制御されません。ドキュメントでも、アカウントレベルオブジェクトタイプは Native App にバインドした場合のみ有効とされています。

DESC FEATURE POLICY: policy_definition に YAML が表示される

同時に GA となった DESC FEATURE POLICY で rules を確認します。

DESC FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_SERVERLESS_TASKS;

2026-08-23_22h24_31

policy_definition プロパティに、設定した YAML のポリシー定義が表示されます。今回の検証環境では、rules を持たないポリシーを DESC すると policy_definition 行自体が表示されませんでした。

適用状況の確認には SHOW と POLICY_REFERENCES を使います。IN は「その場所に作成されたポリシー」、ON は「適用されているポリシー」で、ON の結果には適用先を示す set_on カラムが付きます。

SHOW FEATURE POLICIES IN DATABASE FP_POLICY_DB;  -- 作成した4ポリシーが一覧表示
SHOW FEATURE POLICIES ON DATABASE FP_TEST_DB;    -- 適用中の1ポリシーのみ (set_on = DATABASE)

SELECT POLICY_NAME, POLICY_KIND, REF_ENTITY_NAME, REF_ENTITY_DOMAIN, POLICY_STATUS
FROM TABLE(FP_POLICY_DB.INFORMATION_SCHEMA.POLICY_REFERENCES(
  POLICY_NAME => 'FP_POLICY_DB.POLICIES.BLOCK_TEMP_AND_WH'));

2026-08-23_22h26_05

適用の優先順位を確認する

通常のデータベースでは、DB レベルのポリシーがアカウントレベル(FOR ALL DATABASES)のポリシーより優先されます。アカウント全体を縛りつつ、特定 DB だけ空ポリシーで制限解除する公式記載のテクニックを試します。

ALTER DATABASE FP_TEST_DB UNSET FEATURE POLICY;

-- アカウント内のすべての通常の DB に TEMPORARY テーブル禁止を適用
ALTER ACCOUNT
  SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_TEMP_TABLES FOR ALL DATABASES;

CREATE TEMPORARY TABLE FP_TEST_DB.PUBLIC.T8 (ID INT);

2026-08-23_22h27_33

FP_TEST_DB2 でも同じエラーになりました。DB 適用時とはメッセージが異なり、アカウントポリシー起因であることと確認コマンドが示されます。

次に「何もブロックしない」空ポリシーを作成し、FP_TEST_DB にだけ適用します。空リスト () で作成できました。

CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_NOTHING
  BLOCKED_OBJECT_TYPES_FOR_CREATION = ()
  COMMENT = 'Empty policy to lift account-level restrictions';

ALTER DATABASE FP_TEST_DB
  SET FEATURE POLICY FP_POLICY_DB.POLICIES.BLOCK_NOTHING;

CREATE TEMPORARY TABLE FP_TEST_DB.PUBLIC.T8 (ID INT);   -- 成功
CREATE TEMPORARY TABLE FP_TEST_DB2.PUBLIC.T9 (ID INT);  -- 引き続きブロック

2026-08-23_22h28_25

2026-08-23_22h28_50

DB レベルの空ポリシーがアカウントレベルより優先され、FP_TEST_DB だけ制限が解除されました。なお今回の検証環境では、アカウント適用中に SHOW FEATURE POLICIES ON ACCOUNToptions カラムへ {"target_scopes":["ALL_DATABASES"]} が表示されました。

検証後はアカウントレベルの適用を解除します。

ALTER ACCOUNT UNSET FEATURE POLICY FOR ALL DATABASES;

つまずいたところ

評価できない式は作成時に拒否される

WAREHOUSE プロパティは TASK 以外の作成リクエストでは常に NULL です。これを TABLE のルールで等価比較すると、実行時ではなくポリシー作成時に拒否されました。

CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.NULL_TRAP2
  AS $$
    blocked_creation_rules:
      - object_type: TABLE
        block_when: "SYS_CONTEXT('SNOWFLAKE$REQUEST', 'GET_OBJECT_PROPERTY', 'WAREHOUSE') = 'COMPUTE_WH'"
  $$;

2026-08-23_22h31_18

object_type: ALL でも同じエラーです。対象タイプで評価しようがない式は作成段階で弾かれます。

NULL 評価は fail-closed でブロックされる

作成時バリデーションを通った式でも、実行時に NULL と評価されるケースがあります。TASK に WAREHOUSE = 'COMPUTE_WH' の条件を付けてサーバーレスタスクを作成すると、NULL = 'COMPUTE_WH' は NULL になります。

CREATE FEATURE POLICY FP_POLICY_DB.POLICIES.NULL_TRAP3
  AS $$
    blocked_creation_rules:
      - object_type: TASK
        block_when: "SYS_CONTEXT('SNOWFLAKE$REQUEST', 'GET_OBJECT_PROPERTY', 'WAREHOUSE') = 'COMPUTE_WH'"
  $$;

-- (FP_TEST_DB に適用後)
CREATE TASK FP_TEST_DB.PUBLIC.T_B SCHEDULE = '60 MINUTE' AS SELECT 1;

2026-08-23_22h32_06
FALSE のときだけ許可、TRUE と NULL はブロックという fail-closed の挙動で、NULL の場合は専用のエラーメッセージになります。実際に COMPUTE_WH 指定(TRUE)はブロック、別ウェアハウス指定(FALSE)は成功でした。「条件に該当しなければ許可されるはず」という感覚で書くと、NULL の分岐で意図せずブロックされるため注意が必要です。

制限事項・注意点

制限事項・注意点
  • バインド中のポリシーは CREATE OR REPLACE / DROP できません。変更は ALTER FEATURE POLICY を使い、削除は先に適用を解除します
  • ポリシー定義に CLONE 句は使えません
  • rules の式でテーブル等の DB オブジェクトや副作用のある関数は参照できません
  • アカウントレベルのポリシー参照をレプリケーションする場合、ポリシーの格納 DB をレプリケーショングループに含めないと適用先で強制されません

最後に

Feature Policy Rules により、オブジェクト作成の制御が「タイプ丸ごと」から「条件付き」に進化しました。サーバーレスタスクや一時テーブルだけの禁止など、コスト統制・ガバナンスの実用的なポリシーを ACCOUNTADMIN 含む全ユーザーに強制できます。NULL 評価が fail-closed でブロックになる点だけは、ポリシー設計時に注意してください。

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


Snowflake World Tour Tokyo 2026に参加しませんか?

Snowflakeの国内最大級イベント「Snowflake World Tour Tokyo」が2026年9月10日(木)・11日(金)にグランドプリンスホテル新高輪にて開催されます。
最新のAI・データ活用事例やライブデモを体感できる無料イベントです。

Snowflake World Tour Tokyoイベントに参加する


Snowflake Community Awards ファイナリストに選出されました

DevelopersIO で Snowflake 記事を執筆している かわばた が、Snowflake Community Awards「RISING COMMUNITY LEADER OF THE YEAR」部門・APJ枠のファイナリストに選ばれました。
最終選考の30%はコミュニティ投票です。記事がお役に立っていたようでしたら、9月15日(火)までにぜひ一票お願いします。フォームの「(4 of 6) RISING COMMUNITY LEADER OF THE YEAR」で Tomohiro Kawabata | Classmethod, Japan を選択、2分ほどで完了します。

投票フォームを開く


Snowflakeの導入支援はクラスメソッドに!

クラスメソッドでは Snowflake の導入を支援しております。
製品の詳細や支援の内容についてお気軽にお問い合わせください。

Snowflakeの詳細を見る

この記事をシェアする

関連記事