2026年7月にリリースされたSnowflakeの新機能・変更点のまとめ #SnowflakeDB
2026年7月にリリースされたSnowflakeの新機能・変更点のまとめ記事になります。
※注意事項：本記事ではすべての情報についての記述はせず、特筆すべきだと感じた情報だけピックしております。基本的には以下の情報を参考にしておりますので、全ての最新情報を確認したい場合は下記のURLからご確認ください。
July 30, 2026: 動的テーブルのAdaptiveリフレッシュモードが一般提供
2026年5月にパブリックプレビューとなっていた動的テーブルのAdaptiveリフレッシュモード（REFRESH_MODE = ADAPTIVE）が一般提供されました。
動作の仕組み
通常はインクリメンタルリフレッシュで動作しつつ、上流の変更量が多くインクリメンタルリフレッシュがフルリフレッシュより大幅に高コストになると内部ヒューリスティクスが判定した場合、自動的に動的テーブルを再初期化します。再初期化後は通常のインクリメンタルリフレッシュに戻ります。
ベーステーブルが普段は小規模な変更を受けるものの、時折バルクロード（INSERT OVERWRITE 等）が行われるようなワークロードで、手動介入なしにリフレッシュ戦略を自動で切り替えられます。公式ドキュメントでは、インクリメンタル系ワークロードで優先的に使用するリフレッシュモードとしてADAPTIVEが推奨されています。
詳細は以下をご参照ください。
July 29, 2026: Data Quality Monitoring Dashboardがパブリックプレビュー
アカウント全体のデータ品質の状態をSnowsight上で一元的に確認できるData Quality Monitoring Dashboardがパブリックプレビューとして提供開始されました。
主な機能
- 健全なテーブルの割合やモニタリングカバレッジのサマリー表示
- ボリューム異常・鮮度（freshness）異常・データ品質Expectationの失敗を含む、オープンなデータ品質インシデントの一覧表示
- Cortex Codeを使ったAI支援の根本原因調査
- スキーマ単位のメトリクス確認と、自動的な鮮度・ボリューム異常検知スコープの管理
なお、本機能の利用にはEnterprise Edition以上が必要です。
詳細は以下をご参照ください。
July 27, 2026: AI_EXTRACT / AI_PARSE_DOCUMENTが暗号化ステージ・ネットワーク制限アカウントに対応
AI_EXTRACTおよびAI_PARSE_DOCUMENTの対応範囲が拡大されました（プレビュー）。
- クライアント側暗号化（client-side encryption）を使用するステージ上のドキュメントを処理可能に（サーバー側暗号化は従来からサポート済み）
- PrivateLinkやネットワークポリシーでステージへのパブリックアクセスを制限しているアカウントでも両関数を利用可能に
セキュリティ要件の厳しい環境でドキュメントAIを導入する際の障壁が下がるアップデートです。
詳細は以下をご参照ください。
July 27, 2026: カスタムインクリメンタル動的テーブルが一般提供
2026年5月にパブリックプレビューとなっていた CUSTOM_INCREMENTAL リフレッシュモードが一般提供されました。動的テーブルへのデータ変更適用ロジック（MERGE や INSERT）をユーザー側で記述でき、Snowflakeが各リフレッシュ時にそれを実行します。
標準のリフレッシュモードでは増分化できない変換パターンに対して、動的テーブルの宣言的な管理・スケジューリング基盤を維持したまま、変更の反映方法を正確に制御できます。
詳細は以下をご参照ください。
July 27, 2026: QUERY_HISTORYビューにagent_typeカラムを追加
Account Usage / Organization UsageのQUERY_HISTORYビューと、Information SchemaのQUERY_HISTORYテーブル関数に agent_type カラムが追加されました。クエリを直接呼び出した（起点となった）エージェントの種類を識別でき、AIエージェント経由のクエリの監査・コスト分析がしやすくなります。
agent_typeの値
| 値 | 意味 |
|---|---|
CORTEX_AGENT |
永続的な名前付きCortex Agentによるクエリ |
CORTEX_LITE_AGENT |
REST API / CoCoクライアント経由のステートレスなエージェントによるクエリ |
EXTERNAL_AGENT |
SERVICE_AGENTユーザータイプまたはカスタムOAuth統合を使うサードパーティエージェントによるクエリ |
| NULL | エージェント以外のクエリ |
2026年7月27日から約1週間かけて全アカウントへ段階的にロールアウトされます。
詳細は以下をご参照ください。
簡易検証結果（検証環境: AWS_AP_NORTHEAST_1）
まず、Account UsageのQUERY_HISTORYに AGENT_TYPE（TEXT型）が追加されていることを確認できました。
SELECT column_name, data_type
FROM SNOWFLAKE.INFORMATION_SCHEMA.COLUMNS
WHERE table_schema = 'ACCOUNT_USAGE'
AND table_name = 'QUERY_HISTORY'
AND column_name ILIKE '%AGENT%';
| COLUMN_NAME | DATA_TYPE |
|---|---|
| AGENT_TYPE | TEXT |
Account Usageで直近7日を集計すると、次のように種別ごとに分離できました。CoCo（Cortex Code）から実行したクエリはドキュメントの記載どおり CORTEX_LITE_AGENT として記録されます。
検証してみて実務上ポイントだと感じたのは以下の2点です。
- Information Schemaのテーブル関数でも参照可能。
QUERY_HISTORY_BY_USER()などでもagent_typeが返るため、Account Usageのレイテンシ（最大45分）を待たずに直後のクエリで確認できます。動作確認や開発中のデバッグにはこちらが便利です。 role_nameと併せると監査クエリがそのまま書ける。agent_type IS NOT NULLで絞り込めば、どのユーザーがどのロール・ウェアハウスでエージェント経由のクエリを流したかを一覧化できます。エージェント経由クエリのコスト按分やアクセス監査のベースクエリとして即使えます。
SELECT start_time, user_name, role_name, agent_type,
warehouse_name, execution_status, LEFT(query_text, 120) AS query_text_head
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE agent_type IS NOT NULL
AND start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
ORDER BY start_time DESC;
なお、検証したアカウントでは CORTEX_AGENT / EXTERNAL_AGENT のクエリが発生していなかったため、これらの値については未確認です。
July 24, 2026: CoCoのSkill / Plugin共有がパブリックプレビュー
Cortex Code（CoCo）のスキル・プラグインを、同一Snowflakeアカウント内で共有・検索・インストールできる機能がパブリックプレビューとして提供開始されました。
主な特徴
- スキル / プラグインを Cortex Extension オブジェクトとして公開し、
snow://形式のURIで参照 - アクセス制御（RBAC）とカタログ上の検出可能性（Discoverability）を独立に制御可能
- ACCOUNTADMINによる認定（certification）、アクセス制御、直近28日間の利用テレメトリの確認に対応
個人が作り込んだスキルをチームの資産として流通させ、組織のお墨付き（Certifiedバッジ）まで表現できる仕組みです。
詳細は以下をご参照ください。
July 23, 2026: dbt Projects on Snowflakeの環境変数・Private Gitパッケージサポート
dbt Projects on Snowflakeで、env.yml 設定ファイルによる環境変数管理とプライベートGitリポジトリのパッケージ取得がサポートされました。
主な特徴
env.ymlで複数の名前付き環境を定義。プレーンテキスト値・SQLで算出する値・Snowflakeマネージドシークレットに対応env.ymlはdbt起動前にセッションの実行コンテキストで解決されるため、CURRENT_USER()やCURRENT_ROLE()を使った開発者ごとの設定分離が可能DEFAULT_ENVIRONMENT/ENVIRONMENTによる環境選択と、ENV_VARSによる実行時オーバーライドに対応- Snowflakeシークレット・ネットワークルール・外部アクセス統合を使った、プライベートGitリポジトリへの
dbt deps認証をサポート
Workspaces、デプロイ済みdbtプロジェクトオブジェクト、CoCo Desktopで利用できます。Snowflake CLIのフラグを使用する場合はCLI 3.21以降が必要です。
詳細は以下をご参照ください。
July 23, 2026: SERVICE_AGENTユーザータイプが一般提供
自動化されたAIエージェントが独自のアイデンティティでSnowflakeと対話するための新しいユーザータイプ SERVICE_AGENT が一般提供されました。
主な特徴
- このタイプのユーザーのセッションでは
IS_AGENT_ACTIVATEDが自動的にTRUEを返すため、「エージェント利用時のみマスキングを強化する」といったポリシー制御と組み合わせ可能 - SPIFFE/SPIREを含むWorkload Identity Federationに対応
- SQLまたはSCIM APIで作成・管理可能
人間のユーザーともサービスユーザーとも異なる「エージェント」という主体を、ID管理の第一級市民として扱えるようになるアップデートです。同日リリースの agent_type カラム（QUERY_HISTORY）と組み合わせると、エージェント経由のアクセスの識別・監査を一貫して設計できます。
詳細は以下をご参照ください。
July 23, 2026: SHOW CORTEX BASE MODELSが一般提供
アカウントで利用可能なCortexのベースモデルをSQLで一覧表示できる SHOW CORTEX BASE MODELS コマンドが一般提供されました。
各モデルのライフサイクルステータス、リージョン別の可用性、廃止予定日・サポート終了日を確認でき、モデル採用や移行前のチェックに使えます。出力はモデルRBACの権限付与に基づいてフィルタリングされるため、「現在のロールで実際に使えるモデル」を判断できる点もポイントです。
詳細は以下をご参照ください。
簡易検証結果（検証環境: AWS_AP_NORTHEAST_1）
SHOW CORTEX BASE MODELS; を実行するだけで95行が返り、name / model_type / lifecycle_status / available_regions / legacy_date / eol_date が確認できました。ライフサイクルステータス別に集計すると以下の内訳でした。
| lifecycle_status | model_cnt |
|---|---|
| GA | 44 |
| (NULL) | 28 |
| EOL | 14 |
| PUPR | 4 |
| PRPR | 4 |
| INTERNAL | 1 |
July 22, 2026: MCPサーバーのExternal OAuth・OAuthスコープ設定が一般提供
SnowflakeのMCPサーバーを組織の既存IdPと統合できる機能が一般提供されました。
追加されたパラメータ
| パラメータ | 説明 |
|---|---|
OAUTH_AUTHORIZATION_SERVER |
認可サーバーとして使用するExternal OAuthセキュリティ統合を指定 |
OAUTH_SCOPES_SUPPORTED |
Protected Resource Metadataエンドポイントで公開するOAuthスコープを指定 |
これにより、ClaudeやCursor、ChatGPTなどのMCPクライアントが、Snowflake OAuthの代わりに企業IdPで認証できるようになります。なお、指定したセキュリティ統合を削除・無効化した場合、Protected Resource Metadataは空の authorization_servers を返し、Snowflake OAuthへの自動フォールバックは行われない点に注意が必要です。
詳細は以下をご参照ください。
July 22, 2026: 単一のALTER DYNAMIC TABLE ... REFRESHで複数の動的テーブルをリフレッシュ可能に
単一の ALTER DYNAMIC TABLE ... REFRESH 文で、カンマ区切りで指定した複数の動的テーブルを一括リフレッシュできるようになりました。
主な特徴
- 指定した全テーブルの上流依存関係を統合し、単一のデータタイムスタンプで一貫性を保って更新
- 複数テーブルが共有する上流テーブルのリフレッシュは正確に1回だけ実行
SCHEDULER = DISABLE で外部オーケストレータから手動リフレッシュを行う運用では、テーブル間のデータ整合性の担保が課題でしたが、このアップデートで複数テーブルを整合の取れた状態で更新しやすくなりました。
詳細は以下をご参照ください。
July 21, 2026: タグベースのデータ保護ポリシーがパブリックプレビュー
集約ポリシー・行アクセスポリシー・プロジェクションポリシー・結合ポリシーの4種類のデータ保護ポリシーを、タグに割り当てられる機能がパブリックプレビューとして提供開始されました。
タグが付与されたオブジェクトに対してポリシーが自動的に適用されるため、個々のテーブル・列へのポリシー適用を人手で管理することなく、属性ベース（ABAC）のデータ保護を大規模に展開できます。マスキングポリシーでは従来からタグベースの適用が可能でしたが、対象が4種類のポリシーに広がった形です。
詳細は以下をご参照ください。
July 20, 2026: OIDCフェデレーション認証がパブリックプレビュー
OpenID Connect（OIDC）準拠のIdPを使ったフェデレーションSSOを CREATE SECURITY INTEGRATION で構成できる機能がパブリックプレビューとして提供開始されました。
主な特徴
- カスタムのOIDC準拠IdPに加え、Google / Microsoftをマネージドプロバイダーとして構成可能
- 認証ポリシーによるログイン方法の制限に対応
- 外部認証後にSnowflake側でMFAを強制することも可能
なお、複数のOIDC統合、またはOIDCとSAML2の併用にはidentifier-first loginが必須です（無効の場合はSAML2かOIDCのどちらか一方のみ有効化できます）。Microsoft利用時はEntra IDユーザーの同意と、登録アプリでの email クレーム発行設定が必要です。
詳細は以下をご参照ください。
July 20, 2026: 動的テーブルのFrozen RegionへのDMLが一般提供
動的テーブルの凍結領域（Frozen Region）内の行に対して、INSERT / UPDATE / MERGE / DELETEのDML文で直接変更を加えられる機能が一般提供されました。
動的テーブルは通常、クエリ結果を宣言的に維持するため直接のDMLはできませんが、FROZEN WHERE で定義した凍結領域（リフレッシュ対象外の確定済みデータ）に限り、DMLによる修正が可能になります。GDPR対応の行削除や過去データの個別修正といったユースケースを、アクティブ領域の再計算をトリガーせずに実行できます。
詳細は以下をご参照ください。
July 20, 2026: パススルーポリシーを持つ動的テーブルのインクリメンタルリフレッシュ維持が一般提供
ベーステーブルにマスキングポリシーや行アクセスポリシーが設定されていても、動的テーブルがインクリメンタルリフレッシュを維持できるケースが拡大されました。
従来は CURRENT_ROLE() や IS_ROLE_IN_SESSION() などの許可リスト掲載関数を使うポリシーのみがインクリメンタルリフレッシュと互換でしたが、任意のポリシーであっても、そのポリシーがリフレッシュロールに対してパススルー（リフレッシュロールが全行・全列に制限なくアクセス可能）であれば、インクリメンタルリフレッシュを維持できるようになりました。
ガバナンスポリシーを適用したソーステーブルの上に動的テーブルパイプラインを構築する際、フルリフレッシュへのフォールバックによるコスト増を避けやすくなります。
詳細は以下をご参照ください。
July 16, 2026: VOLATILEスカラーUDFの動的テーブル・インクリメンタルリフレッシュ対応が一般提供
Python / Java / Scala / JavaScript / SQLで作成したVOLATILEスカラーUDFが、動的テーブルのインクリメンタルリフレッシュ（INCREMENTAL・AUTO・ADAPTIVEの各モード）でサポートされました。
従来はVOLATILE UDFを含むクエリはインクリメンタルリフレッシュの対象外でしたが、本アップデートにより既存UDF資産を活かした動的テーブルパイプラインを増分処理で運用しやすくなりました。なお、インクリメンタルリフレッシュではVOLATILE UDFはSELECT句内での使用のみ許可されます。
詳細は以下をご参照ください。
July 15, 2026: ユーザーの名前付きキーペア管理が提供開始
キーペア認証の公開鍵を「名前付きキーペア」としてSQLで管理できるようになりました。
主な特徴
ALTER USER ... ADD KEY PAIR/MODIFY KEY PAIR/ROTATE KEY PAIR/REMOVE KEY PAIRで登録・変更・ローテーション・削除が可能SHOW USER KEY PAIRSで一覧確認が可能- 各キーペアは固有の名前を持ち、ロール制限と有効期限を設定可能
従来の RSA_PUBLIC_KEY / RSA_PUBLIC_KEY_2 ユーザープロパティによる管理（最大2鍵）の改良版で、レガシー方式も引き続きサポートされます。キーのローテーション運用が SQL コマンドとして一級化された点が実運用上のメリットです。
詳細は以下をご参照ください。
July 14, 2026: 24オブジェクトタイプでCREATE OR ALTERが一般提供
オブジェクトが存在しなければ作成し、存在すればステートメントの定義に一致するように変更する CREATE OR ALTER が、テーブル・ビュー・スキーマなど24種類のオブジェクトタイプで一般提供されました。
同じスクリプトを何度実行しても安全な冪等性を持つため、Gitでオブジェクト定義を管理して繰り返し適用する宣言的なデプロイワークフローや、CI/CDパイプラインでの利用に特に有用です。
詳細は以下をご参照ください。
簡易検証結果（検証環境: AWS_AP_NORTHEAST_1）
TABLE / VIEW / TASK / SCHEMA の4種類で挙動を確認しました。
まずテーブルを作成してデータを投入し、同じ CREATE OR ALTER TABLE を定義だけ変えて再実行しました。
-- v1: 初回は CREATE として動作
CREATE OR ALTER TABLE COA_DEMO (
ID NUMBER(10,0) NOT NULL,
NAME VARCHAR(50),
CREATED_AT TIMESTAMP_NTZ DEFAULT CURRENT_TIMESTAMP()
) COMMENT = 'v1: 初回作成';
INSERT INTO COA_DEMO (ID, NAME) VALUES (1, 'Alice'), (2, 'Bob');
-- v2: 2回目は ALTER として動作（NAME拡張 / 列追加 / CREATED_AT削除 / CLUSTER BY追加）
CREATE OR ALTER TABLE COA_DEMO (
ID NUMBER(10,0) NOT NULL,
NAME VARCHAR(100),
EMAIL VARCHAR(200) COMMENT '追加した列',
IS_ACTIVE BOOLEAN DEFAULT TRUE
) CLUSTER BY (ID)
COMMENT = 'v2: NAME拡張 / EMAIL・IS_ACTIVE追加 / CREATED_AT削除';
v2実行後のデータは以下のとおりで、既存2行は保持されたまま列定義だけが差分適用されました。
| ID | NAME | IS_ACTIVE | |
|---|---|---|---|
| 1 | Alice | NULL | TRUE |
| 2 | Bob | NULL | TRUE |
SHOW TABLES でも cluster_by = LINEAR(ID)、comment がv2の内容に更新され、created_on は初回作成時のまま（＝作り直しではない）ことが確認できました。
検証してみて実務上ポイントだと感じたのは以下の4点です。
-
定義に書かなかった列は削除される。v2で
CREATED_ATを書かなかった結果、この列は削除されました。CREATE OR ALTERは「あるべき最終状態」を宣言する文なので、部分的な差分だけを書く用途には使えません。既存の列を残したい場合は必ず定義に含める必要があります。 -
DEFAULT付きで追加した列は既存行にも反映される。IS_ACTIVE BOOLEAN DEFAULT TRUEを追加したところ、既存の2行にもTRUEが入りました。 -
非互換な型変更は失敗し、しかも「部分適用の可能性あり」の警告が出る。
IDをNUMBER(10,0)からVARCHAR(10)に変えて実行すると、以下のエラーになりました。CREATE OR ALTER execution failed. Partial updates may have been applied. ... Error message: SQL compilation error: cannot change column ID from type NUMBER(10,0) to VARCHAR(10)
エラーメッセージにあるとおり、CREATE OR ALTER TABLE は完全な原子性を保証せず、失敗時に一部の変更が適用されている可能性があります。本番環境では、非互換な型変更や列削除を含む変更を直接適用せず、事前に検証環境で影響範囲を確認したうえで、失敗時に再実行または明示的な ALTER TABLE で復旧できる手順を用意しておくことをおすすめします。
July 13, 2026: Dynamic Icebergテーブルのクローンが一般提供
Dynamic Icebergテーブルのクローンが一般提供されました。
主な特徴
- 新しいDynamic Icebergテーブルとして、またはSnowflake管理Icebergテーブル（静的スナップショット）としてクローン可能
- データベース・スキーマのクローン時に、従来は暗黙的にスキップされていたDynamic Icebergテーブルがクローンに含まれるように
環境複製やバックアップ用途でデータベースクローンを使っている場合、クローン結果に含まれるオブジェクトが変わるため、運用手順への影響を確認しておきましょう。
詳細は以下をご参照ください。
July 13, 2026: Snowpark Container ServicesのBackup Instance Typesがパブリックプレビュー
コンピュートプールのプライマリインスタンスファミリーが容量不足で確保できない場合に、バックアップのインスタンスファミリーへ自動フォールバックする機能がパブリックプレビューとして提供開始されました。
主な特徴
BACKUP_INSTANCE_FAMILIESパラメータで優先順位付きのバックアップ候補リストを定義- insufficient capacity error（ICE）を返す代わりに、候補を順に試行してプロビジョニング
SHOW NODES IN COMPUTE POOLで各ノードが実際にどのインスタンスファミリーで起動したかを確認可能
なお、各ノードは実際にプロビジョニングされたインスタンスタイプのレートで課金される点に注意してください。
詳細は以下をご参照ください。
July 10, 2026: Online Feature Storeがパブリックプレビュー
Snowflake Postgresを基盤とした低レイテンシのオンライン特徴量提供機能がパブリックプレビューとして提供開始されました。不正検知・レコメンデーション・パーソナライゼーションといったリアルタイムMLアプリケーションに最新の特徴量を提供できます。
主な特徴
- バッチ / ストリーム / リアルタイムのFeature Viewに対応
- REST API経由のイベント取り込みと、リアルタイムモデル推論との統合
- Feature Groupによる学習・サービング双方の特徴量の一元化
snow featureCLIによる宣言的ワークフロー- Snowsightでのモニタリング（オフライン更新、ストリーム取り込み、オンラインサービングのメトリクス）
詳細は以下をご参照ください。
July 9–15, 2026: Per-user quotasがプレビュー
週次リリース10.24で、ユーザー単位のクレジット上限を強制できるPer-user quotasがプレビューとして提供開始されました。
主な特徴
SNOWFLAKE.CORE.QUOTAオブジェクトを作成し、タグベースで対象ユーザーをスコープ- ユーザーあたりの上限（クレジット）を月次（UTC暦月）・日次で設定可能。月次上限と日次上限は独立して評価され、両方を設定できます
- 対象ドメインはWAREHOUSE / AI FUNCTION / SNOWFLAKE INTELLIGENCE / CORTEX AGENT / CORTEX CODE
- AI系ドメインでは、上限到達時に該当ユーザーの新規リクエストを自動ブロック可能（WAREHOUSEドメインはブロック非対応）
- しきい値通知と、任意のストアドプロシージャを実行するカスタムアクションに対応
従来のBudgetがアカウント・オブジェクト単位の監視・通知だったのに対し、「特定ユーザーのコスト暴走を止める」ところまで踏み込めるのが大きな違いです。
詳細は以下をご参照ください。
July 9–15, 2026: Semantic View Materializationsがパブリックプレビュー
週次リリース10.24で、セマンティックビューのマテリアライゼーションがパブリックプレビューとして提供開始されました。
セマンティックビューの選択したディメンション・メトリクスを事前計算しておくことで、クエリ時にベーステーブルをスキャンする代わりにマテリアライズ済みの結果から読み取り、パフォーマンスを向上させます。異なるディメンション・メトリクスのサブセットを持つ複数のマテリアライゼーションを追加できます。
なお、マテリアライゼーションが効くのは SEMANTIC_VIEW 構文などのSemantic SQLとしてセマンティックビューを経由するクエリです。Cortex AnalystやCortex Agentsなどがセマンティックビューを経由せず物理SQLで直接テーブルをクエリする場合は、マテリアライゼーションの恩恵を受けない点に注意してください。
詳細は以下をご参照ください。
July 3, 2026: Cortex Search向けResource Budgetsが提供開始
Cortex Searchサービスのクレジット消費をリソースバジェットで制御できる機能が提供開始されました。月次の支出上限を設定し、上限超過時にはアクセスの取り消しやサービスの一時停止などの自動アクションを実行できます。
Cortex Searchはインデックス維持・サービングでクレジットを継続消費するため、検証環境での作りっぱなしのサービスによる想定外コストの防止にも有効です。
詳細は以下をご参照ください。
July 2, 2026: メタデータベースの機密データ分類推奨がパブリックプレビュー
機密データを含む可能性が高いデータベースを、メタデータに基づいて特定するレコメンデーション機能がパブリックプレビューとして提供開始されました。
Snowsightのデータベース詳細ページに推奨バナーが表示され、そこからそのまま分類（classification）を有効化できます。分類結果はTrust Centerの「Data Security」でレビューできます。どのデータベースから分類を始めるべきか、の初動判断を支援する機能です。
詳細は以下をご参照ください。
July 1, 2026: Snowflakeワークロードから外部サービスへアクセスするWorkload Identity Federationが一般提供
Snowflakeが外部サービスへの認証時にOIDCプロバイダーとして機能する、アウトバウンド方向のWorkload Identity Federationが一般提供されました。
利用の流れ
WORKLOAD_IDENTITY_FEDERATION型のシークレットを作成- 発行者URLと主体識別子を外部サービス側と共有して信頼関係を確立
SYSTEM$ISSUE_WORKLOAD_IDENTITY_FEDERATION_TOKEN関数で短期のIDトークンを取得し、外部サービスへの認証に使用
外部サービス連携のためにAPIキーなどの長期クレデンシャルをSnowflake側に保持する必要がなくなります。「外部からSnowflakeへ」のWIFと合わせて、双方向のシークレットレス連携が揃いました。
詳細は以下をご参照ください。
Behavior Change Log
2026_06 バンドルのPreviewが公開 ※デフォルト無効
2026年7月22日に2026_06バンドルのPreviewが公開されました。公式ドキュメントでは、10.26リリース（2026年7月24日〜28日予定）でデフォルト無効として導入され、その後の2026年8月リリースでデフォルト有効化、さらにその後のリリースでGenerally Enabledへ移行する予定と案内されています（全18項目）。
影響が大きい変更としては以下が挙げられます。
- INTERVALリテラルで複数形の単位修飾子を認識（既存SQLの解釈に影響する可能性）
- 同一クラウド・同一リージョン範囲におけるCortex Cross-Region Inferenceのグローバル有効化
- dbt Projects on Snowflakeの単一のmutable live versionへの移行
- Anaconda共有リポジトリのパッケージ利用にアクセスロールが必須化
- スケールファクター8のウェアハウスでQAS（Query Acceleration Service）をデフォルト有効化
2026_05 バンドル ※デフォルト無効
2026年6月の10.21リリースでデフォルト無効として導入済みのバンドルです（全4項目）。先に挙動を確かめたい場合には手動でバンドルを有効化してテスト可能です。
特に「Snowflake管理のApache Icebergテーブルがレプリケーション / フェイルオーバーグループでデフォルトでレプリケーション対象になる」変更は、ストレージコストやDR構成への影響が大きいため、事前のテストをおすすめします。
2026_04 バンドルがデフォルト有効化
10.21（2026年6月12日〜18日）で、2026_04バンドルがデフォルトで有効化されました。
Generally Enabled（全アカウントで有効化）への移行は、2026年6月以降の後続リリースで予定されています（スケジュールは変更される可能性があります）。
CORTEX_MODELS_ALLOWLIST廃止とembeddingモデルRBAC強制 ※Pending
Cortexのモデルアクセス制御をモデルRBACに一本化する変更です。アカウントパラメータ CORTEX_MODELS_ALLOWLIST が廃止され、これまでRBAC強制の対象外だったembeddingモデル（AI_EMBED、Cortex Search）にもモデルRBACが適用されます。
変更前: Cortexの呼び出し時にまずモデルRBACを確認し、ロールが SNOWFLAKE.MODELS の該当モデルオブジェクトへのアクセスを持たない場合は CORTEX_MODELS_ALLOWLIST にフォールバックする、という二段構えでした。embeddingモデルにはRBACが強制されていませんでした。
変更後: モデルアクセスはモデルRBACのみで決まります。CORTEX_MODELS_ALLOWLIST は認可判定で参照されなくなり、設定できる値は 'None' だけになります。
段階的なロールアウトが予定されています。
| 時期 | 内容 |
|---|---|
| 2026年8月5日 | CORTEX_MODELS_ALLOWLIST を新しい値に変更できなくなる（'None' への変更のみ可）。'All' のアカウント（新規アカウントのデフォルト）は、CORTEX-MODEL-ROLE-ALL アプリケーションロールが SNOWFLAKE.PUBLIC を通じて自動付与される |
| 2026年8月17日〜9月4日 | 既存アカウントに対し、allowlist設定をモデルRBACのアプリケーションロールへマッピングする一度限りの移行が実施される（embeddingモデルを含む） |
| 2026年9月8日頃 | 2026_07バンドルを通じて、allowlistベースのアクセス制御の削除とembeddingモデルへのモデルRBAC強制が提供開始予定。バンドルのdefault opt-out期間として開始される予定 |
| 2026年10月13日頃 | 2026_07バンドルがdefault opt-inへ移行予定 |
| 2026年11月18日 | ロールアウト完了予定。CORTEX_MODELS_ALLOWLIST は完全に廃止 |
※上記の予定日は変更される可能性があります。最新のスケジュールは公式Behavior Change Logを確認してください。
Modern Data Stack全般の最新情報
Snowflakeも含め、Modern Data Stack 全般の最新情報についても、定期的にブログにまとめて投稿されています！こちらもぜひご覧ください。
