2026年2月18日の Snowflake Feature Update で、Dynamic Tables に EXECUTE AS USER が追加されました。
本記事では、この新機能を実際に触ってみた上で、Dynamic Table の更新権限設計がどう変わるのかを整理します。
はじめに
Snowflake の Dynamic tables は、定義した SQL の結果を自動的に更新してくれる仕組みです。Task や Stream を使ったオーケストレーションを最小限にしつつ、データ変換処理を自動更新（refresh）として Snowflake 内で運用できる点が特徴です。
2026年2月18日の Feature Update で追加された EXECUTE AS USER により、Dynamic Tables のrefreshを特定のユーザーとして実行できるようになり、権限や監査の考え方を整理しやすくなっています。
この EXECUTE AS USER を実際に試しながら、refresh 時の権限が どのように評価されるのか（Owner ロールとセカンダリロールの関係）、そして運用で注意が必要な IMPERSONATEなどの前提条件も含めて、更新権限の設計ポイントを整理します。
EXECUTE AS USERとは何か？
2026年2月のアップデートで追加された「EXECUTE AS USER」は、Dynamic Tablesのリフレッシュを「特定のユーザー」の権限コンテキストで実行可能にする機能です。
従来は SYSTEM（システムユーザー）側の文脈で refresh が動作していましたが、EXECUTE AS USER により、Ownerロールの権限を土台にしつつ、指定ユーザーの属性や権限（特にセカンダリロール）を組み合わせて実行できるのが特徴です。
具体的には、以下の3つのポイントが重要になります。
「Ownerロール ＋ ユーザーのセカンダリロール」の組み合わせ
リフレッシュ実行時のプライマリロールは Dynamic Table のOwnerロールが担い、その上で指定ユーザーに付与されているセカンダリロールが有効化され、両方の権限を合わせた状態で処理が行われます。
※USE SECONDARY ROLES ALL を指定することで、複数ロールにまたがる権限をまとめ直す手間を減らせます。
ユーザー基準でのセキュリティポリシー評価
マスキングポリシーや行アクセスポリシーは、指定した実行ユーザーのコンテキストで評価されます。
そのため「Ownerロールには見えているが、実行ユーザーには隠されているデータ」は、リフレッシュ後のテーブルでも意図どおりにマスキングされた状態になります。
実行主体の明確化と監査対応
refresh は SYSTEM ではなく指定ユーザーに帰属するため、「誰の権限で更新が行われたか」を追いやすくなり、監査・ガバナンス面の説明がしやすくなります。
※なお EXECUTE AS USER を利用するには、Ownerロールによる IMPERSONATE などの要件があり、満たさない場合 refresh が失敗し得ます。
実際に使ってみる
本章では、Dynamic Tables の refresh が「Owner ロール＋指定ユーザーのセカンダリロール」という形で評価される点を、簡単な構成で検証します。
事前準備
まず、権限の「組み合わせ効果」を証明するために、あえて役割を分離した環境を構築します。
- ロールの作成: Dynamic Table管理用の test_role（オーナー）と、データ閲覧用の data_reader_role を用意
- ユーザーの作成: 実行主体となる user_b を作成し、上記2つのロールを両方付与
- 権限の切り分け: 元テーブルの SELECT 権限は data_reader_role にのみ付与し、オーナーである test_role 単体ではデータが見えない状態を意図的に作成
Dynamic tablesの作成
まずはオーナーロール（test_role）で通常の Dynamic Table を作成します。
※作成の瞬間には、定義された SQL を展開するためにオーナー自身に元テーブルへのアクセス権が必要となるため、一時的に権限を付与して実行します。
CREATE OR REPLACE DYNAMIC TABLE verification_dt
TARGET_LAG = '1 minute'
WAREHOUSE = test_wh AS
SELECT * FROM test_db.test_schema.raw_table;実行ユーザの指定
今回の核となる設定です。リフレッシュの実行主体を user_b に指定し、かつそのユーザーが持つセカンダリロールをすべて適用するように設定します。
ALTER DYNAMIC TABLE verification_dt
SET EXECUTE AS USER user_b USE SECONDARY ROLES ALL;この USE SECONDARY ROLES ALL を指定することで、指定したユーザーのプライマリロールだけでなくセカンダリロールもリフレッシュ時に有効化されます。これにより、複雑な権限を一つのロールに統合し直す手間が省けます。
リフレッシュ実行に必要な権限の付与
設定後にリフレッシュが走ると、以下のようなエラーが発生することがあります。
Cannot refresh dynamic table... because IMPERSONATE privilege on the user USER_B is not granted to the owner role.これは、オーナーロールが勝手に他のユーザーになりすますことを防ぐためのセキュリティガードレールです。この機能を成立させるためには、管理者（ACCOUNTADMIN）による明示的な許可が必要です。
USE ROLE ACCOUNTADMIN;
GRANT IMPERSONATE ON USER user_b TO ROLE test_role;プロパティの設定だけでなく、この権限付与のプロセスをセットで行うことが、本機能を正常に稼働させるための必須要件となります。
リフレッシュ履歴の確認
権限付与後、リフレッシュが実行されたタイミングで管理画面（Snowsight）の履歴を確認します。
以下が更新履歴の画面になります。
履歴の詳細を確認すると、実行ユーザーが指定した「user_b」になっていることが確認できます。
オーナーである 「test_role」 が元テーブルへのアクセス権を持っていない状態でも、リフレッシュが成功していれば、「user_b」 のセカンダリロール（data_reader_role）の権限が正しく合算されて動作している証明となります。
まとめ
今回の検証を通じて、EXECUTE AS USER は単にログ上の名前を変えるだけではなく、Dynamic Table の owner role（primary）を土台にしつつ、指定ユーザーの権限（特に secondary roles）を組み合わせて refresh を実行できる強力な機能だと整理できました。
特に、マスキングポリシーや行アクセスポリシーが指定したユーザー基準で評価される点は、今後のガバナンス設計において重要なポイントになるでしょう。
