2026年2月にリリースされたSnowflakeの新機能・変更点のまとめ #SnowflakeDB
2026年2月にリリースされたSnowflakeの新機能・変更点のまとめ記事になります。
※注意事項：本記事ではすべての情報についての記述はせず、特筆すべきだと感じた情報だけピックしております。基本的には以下の情報を参考にしておりますので、全ての最新情報を確認したい場合は下記のURLからご確認ください。
10.6 Release Notes: Feb 23, 2026-Feb 27, 2026
Apache Iceberg™ tables: 階層パスによるパーティション書き込み(パブリックプレビュー)
Snowflake から Iceberg テーブルの書き込み時に、階層パスレイアウトを使用できるようになりました。
この機能は、Snowflake が管理の Iceberg テーブルと、外部管理の Iceberg テーブルの両方でサポートされています。
詳細は以下をご参照ください。
データ品質：テーブル所有者以外でも DMF をテーブルに関連付けられるように（一般提供）
DMF をテーブルに関連付けるには、テーブルの所有者権限が必要でしたが、所有者権限はなくとも、参照権限のあるユーザーで DMF をテーブルに関連付けられるようになりました。これにより、テーブルの所有者でなくてもデータ品質チェックを作成できるようになります。
具体的には、参照権限のあるユーザーで関連付け時にEXECUTE AS ROLEとして、関連付けに使用するロールを指定することでこの操作が可能となります。
詳細は以下をご参照ください。
Feb 25, 2026: Account Usage CORTEX_AGENT_USAGE_HISTORY ビュー が一般提供
Cortex エージェントの使用履歴を確認できる CORTEX_AGENT_USAGE_HISTORY ビューが ACCOUNT_USAGE スキーマに追加されました。
ビューの各行はエージェントへの呼び出しを表し、一部カラムやレコードの抜粋ですが、以下のようにトークンの内訳などの情報も表示されます。
なお、このビューには、Snowflake Intelligence からのリクエストは含まれません。
>SELECT
START_TIME,
END_TIME,
USER_NAME,
REQUEST_ID,
AGENT_NAME,
TOKEN_CREDITS,
TOKENS,
TOKENS_GRANULAR,
CREDITS_GRANULAR
FROM
SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AGENT_USAGE_HISTORY;
+-------------------------------+-------------------------------+----------------+--------------------------------------+--------------------+---------------+--------+-----------------------------------------------------+-----------------------------------------------------+
| START_TIME | END_TIME | USER_NAME | REQUEST_ID | AGENT_NAME | TOKEN_CREDITS | TOKENS | TOKENS_GRANULAR | CREDITS_GRANULAR |
|-------------------------------+-------------------------------+----------------+--------------------------------------+--------------------+---------------+--------+-----------------------------------------------------+-----------------------------------------------------|
| 2026-02-26 01:38:10.183 -0800 | 2026-02-26 01:38:17.082 -0800 | <user> | 3b9a6e99-5911-4a22-a08c-0fc0aaef2164 | ANALYST_TEST_AGENT | 0.061045260 | 22613 | [ | [ |
| | | | | | | | { | { |
| | | | | | | | "3b9a6e99-5911-4a22-a08c-0fc0aaef2164": { | "3b9a6e99-5911-4a22-a08c-0fc0aaef2164": { |
| | | | | | | | "cortex_agents": { | "cortex_agents": { |
| | | | | | | | "claude-sonnet-4-5": { | "claude-sonnet-4-5": { |
| | | | | | | | "cache_write_input": 22292, | "cache_write_input": 0.05773628, |
| | | | | | | | "input": 2, | "input": 0.00000414, |
| | | | | | | | "output": 319 | "output": 0.00330484 |
| | | | | | | | } | } |
| | | | | | | | }, | }, |
| | | | | | | | "start_time": "2026-02-26 01:38:10.183 -0800" | "start_time": "2026-02-26 01:38:10.183 -0800" |
| | | | | | | | } | } |
| | | | | | | | } | } |
| | | | | | | | ] | ] |
+-------------------------------+-------------------------------+----------------+--------------------------------------+--------------------+---------------+--------+-----------------------------------------------------+-----------------------------------------------------+
Feb 25, 2026: Account Usage SNOWFLAKE_ INTELLIGENCE_ USAGE_ HISTORY ビュー (一般提供)
Snowflake Intelligence を操作するたびに消費されるクレジット数を確認できる SNOWFLAKE_INTELLIGENCE_USAGE_HISTORY ビューが ACCOUNT_USAGE スキーマに追加されました。
ビューの各行はエージェントへの呼び出しを表し、CORTEX_AGENT_USAGE_HISTORY と同様にトークンの内訳などの情報も表示されます。
なお、このビューには、Cortex エージェントから発信されたリクエストは含まれません。
Feb 24, 2026: 予算のユーザー定義アクション
クレジット消費が予算で設定した閾値に達した際に、自動的にストアドプロシージャを呼び出すことができるようになりました。
これにより、ウェアハウスの一時停止やカスタムアラートの送信などのアクションを自動化できます。
トリガーは以下の2種類のクレジット消費ベースと、閾値（予算制限に対するパーセンテージ）を組み合わせて設定できます。
- 予測クレジット消費に基づくトリガー
- 実際のクレジット消費に基づくトリガー
予算にカスタムアクションを追加するには、ADD_CUSTOM_ACTION メソッドを使用します。以下は公式ドキュメントの例ですが、対象のストアドプロシージャや引数、トリガーを指定します。
-- 支出が予算制限の 75% に達すると予測されるときに呼び出されるように、alert_teamストアド プロシージャを予算に関連付け
CALL budget_db.sch1.my_budget!ADD_CUSTOM_ACTION(
SYSTEM$REFERENCE('PROCEDURE', 'code_db.sch1.alert_team(string, string, string)', 'SESSION', 'USAGE'),
ARRAY_CONSTRUCT('admin@example.com', 'Budget Alert', 'Spending at 75% of budget limit'),
'PROJECTED',
75);
関連付けできるストアドプロシージャに要件もあるためご注意ください。
また、ユーザー定義アクションと併せて「サイクル開始アクション」も追加され、予算の月次期間が始まり支出が0にリセットされるタイミングで、自動的にストアドプロシージャを呼び出すこともできるようになりました。
これにより、前の月にユーザー定義アクションで一時停止したウェアハウスを、新しい月の初めに再び有効化するなどの後処理も設定可能となります。このアクションは、1つの予算につき1つだけ設定できます。
詳細は以下をご参照ください。
Feb 24, 2026: アカウントへの privatelink-only アクセスが一般提供
アカウントへのパブリックアクセスを無効にできる、PrivateLink のみのアクセスの適用が一般提供となりました。
プライベート接続を構成済みのアカウントで、SYSTEM$ENFORCE_PRIVATELINK_ACCESS_ONLY 関数を実行することで、Snowflake アカウントへの接続に、プライベートエンドポイントのみを使用するように強制できます。この状態でパブリック URL にアクセスすると「HTTP - 404 account not foundHTTP - 404 account not found」となり、アカウントの存在を示す情報も提供されません。
詳細は以下をご参照ください。
Feb 24, 2026: Snowflake Postgres (一般提供)
Snowflake 上で PostgreSQL 互換のデータベースインスタンスを作成・管理できる機能が一般提供となりました。
各インスタンスは Snowflake が管理する 専用の仮想マシン上の Postgres サーバーとして動作し、既存の Postgres クライアントやツールから接続して利用できます。
インスタンス作成時は、インスタンスサイズ、ストレージ容量、Postgres のメジャーバージョンなどを指定します。また、インスタンスは指定のクラウドリージョン内の新規のネットワーク上で稼働し、ファイアウォールルール（ネットワークポリシー/ルール）や PrivateLink もサポートされています。
執筆時点で国内であれば、AWS Tokyo・Azure Tokyo のアカウントで利用できます。
詳細は以下をご参照ください。
Feb 23, 2026: Simplified setup for Data Quality Monitoring
Snowsight 上でデータ品質チェックを設定できる以下の機能がパブリックプレビューとなりました。あわせて、Cortex Data Quality として、Cortex AI を活用した品質チェックの自動提案の機能も追加されています。
本機能については以下の記事で紹介されていますので、こちらもあわせてご参照ください。
Feb 23, 2026: Snowsight のグループ化されたクエリ履歴 (一般提供)
Snowflake では、query_hash と query_parameterized_hash として、過去のクエリ履歴の中から類似したクエリを特定し、グループ化してパフォーマンスの傾向やコストのパターンを分析するために使用されるハッシュ値が提供されています。
- query_hash
- 実行された SQL そのもの（正規化されたテキスト）に基づいて計算されるハッシュ値
- query_parameterized_hash
- クエリ内のリテラルをパラメーター化した状態で計算されるハッシュ値
- 例：WHERE 句で検索条件の値だけが異なる場合、それらのクエリはすべて同じquery_parameterized_hash となる
今回のアップデートで、 AGGREGATE_QUERY_HISTORY ビューに記録された情報に基づき、クエリの使用状況とパフォーマンスを監視できるビューが追加されました。AGGREGATE_QUERY_HISTORY ビューでは、繰り返し実行される SQL は1分間隔で集計されます。そのため、特に、少数の異なるステートメントを高スループットで繰り返し実行する Unistore のようなワークロードの監視と分析に有効とされています。
詳細は以下をご参照ください。
10.5 Release Notes: Feb 16, 2026-Feb 19, 2026
SAML2 federated authentication で metadata URL のサポート
SAML2 セキュリティ統合を作成する際に、IdP のメタデータURLを指定できるようになりました。
以下は公式ドキュメントの例ですが、METADATA_URL に IdP のメタデータ URL を指定します。これにより、Snowflake 側で証明書を含む IdP の構成設定が動的に取得され、手動で証明書を文字列として貼り付ける必要がなくなります。
また、IdP 側で定期的に証明書がローテーションされた際も、ALTER SECURITY INTEGRATION REFRESH METADATA_URL コマンドを実行することで新しい証明書情報を Snowflake に同期できるようになります。
CREATE SECURITY INTEGRATION my_idp
TYPE = saml2
ENABLED = true
METADATA_URL = 'https://integrator-26580.okta.com/app/ex2kbcS30N697/sso/saml/metadata'
SAML2_SNOWFLAKE_ISSUER_URL = 'https://<orgname>-<account_name>.privatelink.snowflakecomputing.com'
SAML2_SNOWFLAKE_ACS_URL = 'https://<orgname>-<account_name>.privatelink.snowflakecomputing.com/fed/login';
詳細は以下をご参照ください。
DUPLICATE_COUNT DMF で複数列の指定が可能に
DUPLICATE_COUNT データメトリック関数の機能が強化されました。
以前は、単一の列の重複数しか返すことができませんでしたが、この DMF をテーブルに関連付けることで、指定した列の組み合わせが重複している行の数を取得できるようになりました。
結果は、重複している組み合わせの種類数を返します。
-- 複数列での重複カウント（テーブルにDMFを関連付け）
ALTER TABLE DMF_TEST_TABLE
ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.DUPLICATE_COUNT
ON (first_name, last_name);
Feb 19, 2026: Machine learning experiments (一般提供)
機械学習モデルのトレーニング結果を評価する際に使用できる Snowflake Machine Learning Experiments が一般提供となりました。
Snowsight の「 AI & ML » Experiments」からアクセスでき、作成済みのモデルについて、使用する特徴量ごとの比較などを行えます。
詳細は以下をご参照ください。
Feb 18, 2026: 動的テーブル更新時のユーザーとセカンダリ ロール指定
動的テーブルにおいて、所有者ロールの権限だけでなく「特定のユーザーの権限」および「セカンダリロール」を組み合わせてリフレッシュを実行できるようになりました。
具体的には、動的テーブルに EXECUTE AS USER を指定することで、従来の SYSTEM ではなく、指定した名前付きユーザーとしてリフレッシュ処理が実行されるように構成できます。
権限など一部抜粋ですが、以下のように設定できます。
-- ロールの準備
CREATE ROLE IF NOT EXISTS DT_OWNER_ROLE;
-- 必要な権限の付与
-- 指定されるユーザーには、動的テーブルの所有者ロールが付与されている必要がある
GRANT ROLE DT_OWNER_ROLE TO USER <user>;
-- 動的テーブルの所有者ロールにIMPERSONATE権限を付与
GRANT IMPERSONATE ON USER <user> TO ROLE DT_OWNER_ROLE;
-- ロール切替
USE ROLE DT_OWNER_ROLE;
-- 動的テーブル作成
CREATE OR REPLACE DYNAMIC TABLE SALES_SUMMARY_USER_EXEC
TARGET_LAG = '1 minute'
WAREHOUSE = COMPUTE_WH
EXECUTE AS USER <user> -- ユーザー指定
USE SECONDARY ROLES ALL -- セカンダリロールを有効化
AS
SELECT
・
・
下図はクエリ履歴の画面ですが、これまでは更新時に SYSTEM ユーザーとなっていた箇所が、EXECUTE AS USER で指定のユーザーでの操作となります。
更新が SYSTEM ユーザーではなく、指定した特定のユーザーとなるため、誰のどの権限でその処理が行われたかを追跡しやすくなります。
また、セカンダリロールの利用により、権限が複数のロールに分散している場合（例：プライマリロールでテーブルへアクセスし、セカンダリロールで仮想ウェアハウスへアクセスする など）でも、1つのリフレッシュセッションに統合して実行できるようになります。
詳細は以下をご参照ください。
Feb 18, 2026: 行タイムスタンプが一般提供
テーブル内の各行が最後に更新（コミット）された日時を記録できる 行タイムスタンプが一般提供となりました。
同じトランザクション内で変更された行は同じタイムスタンプを持ち、異なるトランザクションの行はコミットされた順序で記録されます。機能を有効化したテーブルのMETADATA$ROW_LAST_COMMIT_TIMEカラムから確認できます。
>-- 行タイムスタンプ有効でテーブル作成
CREATE OR REPLACE TABLE ROW_TS_TEST (
record_id STRING,
client_timestamp TIMESTAMP_LTZ,
data_value NUMBER
) ROW_TIMESTAMP = TRUE;
-- データ挿入（各INSERTで異なるタイムスタンプが記録される）
INSERT INTO ROW_TS_TEST VALUES('record-1', CURRENT_TIMESTAMP(), 100);
-- 1秒待機
CALL SYSTEM$WAIT(1);
INSERT INTO ROW_TS_TEST VALUES('record-2', CURRENT_TIMESTAMP(), 200);
CALL SYSTEM$WAIT(1);
INSERT INTO ROW_TS_TEST VALUES('record-3', CURRENT_TIMESTAMP(), 300);
-- 行タイムスタンプの確認
SELECT
record_id,
client_timestamp,
METADATA$ROW_LAST_COMMIT_TIME AS row_commit_time,
data_value
FROM ROW_TS_TEST
ORDER BY row_commit_time;
+-----------+-------------------------------+-------------------------------+------------+
| RECORD_ID | CLIENT_TIMESTAMP | ROW_COMMIT_TIME | DATA_VALUE |
|-----------+-------------------------------+-------------------------------+------------|
| record-1 | 2026-03-02 19:40:46.019 -0800 | 2026-03-02 19:40:46.877 -0800 | 100 |
| record-2 | 2026-03-02 19:40:48.096 -0800 | 2026-03-02 19:40:48.478 -0800 | 200 |
| record-3 | 2026-03-02 19:40:49.657 -0800 | 2026-03-02 19:40:50.780 -0800 | 300 |
+-----------+-------------------------------+-------------------------------+------------+
行タイムスタンプはテーブル単位で機能を有効化しますが、 スキーマやデータベースレベルで ROW_TIMESTAMP_DEFAULT = TRUEと設定することで、新しく作成されるテーブルで自動的に有効化できます。
また、SYSTEM$SET_ROW_TIMESTAMP_ON_ALL_SUPPORTED_TABLES を使用することで、アカウント/データベース/スキーマ単位で既存のテーブルに対して一括で有効化も可能です。
詳細は以下をご参照ください。
Feb 16, 2026: Sharing Streamlit in Snowflake apps (パブリックプレビュー)
Streamlit アプリを共有するために2種類の URL が提供されました。
- App-builder URL
- Snowsight のインターフェースを含めて表示する URL
- コンテナランタイムとウェアハウスランタイムの両方のアプリで利用可能
- App-viewer URL
- Snowsight のインターフェースを隠し、アプリ画面のみを表示する URL
- ビジネスユーザーなどに閲覧専用として共有する際に適している
- この URL が利用できるのはコンテナランタイムのアプリのみ
- ※公式ドキュメントには上記のように記載がありますが、ウェアハウスランタイムでも App-viewer URL にアクセスすると下図のようにアプリ画面のみ表示されました
下図は App-viewer URL にアクセスした際の画面です。共有ボタンや編集用のメニューは表示されません。
その他、コンテナランタイム版であれば、ユーザーに以下のように設定することで、アプリビューアー URL のみへのアクセスに制限することも可能です。
ALTER USER <user_name> SET ALLOWED_INTERFACES = (STREAMLIT);
詳細は以下をご参照ください。
10.4 Release Notes: Feb 09, 2026-Feb 13, 2026
IS_ROLE_ACTIVATED 関数
現在のセッションで対象のアカウントロールがアクティブであるかを判定できる IS_ROLE_ACTIVATED 関数が追加されました。基本的な動作は以下の通りです。
-- セッションポリシー作成（セカンダリロールを無効化）
CREATE SESSION POLICY IF NOT EXISTS block_secondary_roles
ALLOWED_SECONDARY_ROLES = (); -- 空配列 = セカンダリロール使用不可
-- アカウントレベルでセッションポリシーを適用
ALTER ACCOUNT SET SESSION POLICY block_secondary_roles;
-- IS_ROLE_ACTIVATED の動作確認
USE ROLE ACCOUNTADMIN;
-- ACCOUNTADMINはSECURITYADMINを継承
>SELECT SYS_CONTEXT('SNOWFLAKE$SESSION', 'IS_ROLE_ACTIVATED', 'SECURITYADMIN') AS securityadmin_active;
+----------------------+
| SECURITYADMIN_ACTIVE |
|----------------------|
| TRUE |
+----------------------+
-- ACCOUNTADMINはSYSADMINを継承
>SELECT SYS_CONTEXT('SNOWFLAKE$SESSION', 'IS_ROLE_ACTIVATED', 'SYSADMIN') AS sysadmin_active;
+-----------------+
| SYSADMIN_ACTIVE |
|-----------------|
| TRUE |
+-----------------+
-- SECURITYADMINとSYSADMINは階層関係に無い
USE ROLE SECURITYADMIN;
>SELECT SYS_CONTEXT('SNOWFLAKE$SESSION', 'IS_ROLE_ACTIVATED', 'SYSADMIN') AS sysadmin_active;
+-----------------+
| SYSADMIN_ACTIVE |
|-----------------|
| FALSE |
+-----------------+
-- セッションポリシーの無効化（セカンダリロールを使用可）
USE ROLE ACCOUNTADMIN;
ALTER ACCOUNT UNSET SESSION POLICY;
-- このユーザーはSYSADMIN権限があるので、セカンダリーロールが有効（デフォルトでALL）なことでアクティブ扱いとなる
USE ROLE SECURITYADMIN;
>SELECT SYS_CONTEXT('SNOWFLAKE$SESSION', 'IS_ROLE_ACTIVATED', 'SYSADMIN') AS sysadmin_active;
+-----------------+
| SYSADMIN_ACTIVE |
|-----------------|
| TRUE |
+-----------------+
詳細は以下をご参照ください。
Feb 13, 2026: Security Essentials スキャナーパッケージのオンデマンド実行
Snowflake アカウントのセキュリティモニタリング機能である Trust Center で提供される Security Essentials スキャナーパッケージをユーザー側で任意のタイミングで実行できるようになりました。
このスキャナーパッケージは、デフォルトで有効化されており、無効にすることはできません。また、固定スケジュールで定期的に実行されますが、この実行にはサーバーレスコンピューティングのコストは発生しません。
今回のアップデートにより、ユーザー側でオンデマンド実行可能ですが、この場合は、サーバーレスコンピューティングのコストが発生するためご注意ください。
詳細は以下をご参照ください。
Feb 12, 2026: Strong Authentication Hub がパブリックプレビュー
Snowflake アカウントの将来的なパスワードによる単一要素認証の廃止の準備に向けて使用できるツールとして、Strong Authentication Hub がパブリックプレビューとなりました。
Trust Center の Overview タブ内にこの項目が追加されています。
以下の情報を確認できます。
- Strong authentication progress
- 特定の認証の問題とリスクのあるユーザー数を表示
- Enforcement rollout timeline
- 各マイルストーンのタイミングを確認できる
各タブで詳細を表示することで、過去 90 日以内に特定のアプリケーション (Fivetran, dbt, Power BI など) 経由でパスワードのみを使用してログインしたユーザーなど対応が必要なユーザーを確認可能です。
次回以降のロールアウトは、動作変更バンドルではなく、アカウントごとに個別で適用される予定となっているのですが、必要に応じて Enforcement rollout timeline の詳細メニューから適用日を延長することができるようです。
詳細は以下をご参照ください。
Feb 06, 2026: Cortex Code data science and machine learning skill (パブリックプレビュー)
Cortex Code CLI にデータサイエンスと機械学習スキルが追加されました。
このスキルでは Model Registry との対話や、Snowpark Container Services 上での推論の実行など Cortex Code が Snowflake の機械学習・データサイエンス機能をどのように利用するか定義されています。
機能（スキル）も Cortex Code に組み込まれているため、Cortex Code CLI を新規インストールするか、最新バージョンにアップデートすることで利用可能です。
詳細は以下をご参照ください。
Feb 06, 2026: Snowflake Horizon Catalog で定義されたSnowflake 管理の Apache Iceberg テーブルの外部クエリエンジンのサポート(一般提供)
Apache Spark などのオープンな Iceberg REST プロトコルをサポートする外部クエリエンジンから、Snowflake 管理の Apache Iceberg テーブルに対してクエリできるようになりました。
オープンな Iceberg REST プロトコルのサポートにより、単一のベンダーに依存しない、マルチエンジン戦略の検討が期待できます。
Horizon Catalog エンドポイントを使用して、Iceberg テーブルをクエリするため、このリクエストに対して課金されます。API リクエストは 100 万回の呼び出しごとに 0.5 クレジットがクラウド サービスとして課金されます。
詳細は以下をご参照ください。
10.3 Release Notes: Feb 02, 2026-Feb 05, 2026
所有者権限コンテキストにおける INFORMATION_SCHEMA と SHOW / DESCRIBE コマンドの実行許可
所有者権限で実行されるコンテキスト（所有者権限のストアドプロシージャ、Snowflake Native Apps、Streamlitアプリなど）において、データベースのメタデータや内部情報を取得するコマンドのサポート範囲が拡大されました。
具体的には、これまで制限されていた以下のコマンドが、条件付きで実行可能になりました。
- SHOW および DESCRIBE コマンド
- 大半の SHOW および DESCRIBE コマンドが許可されるようになりましたが、現在のセッションや現在のユーザーに関する固有の情報を読み取るコマンドは例外として引き続きブロックされます
- INFORMATION_SCHEMA へのアクセス
- 履歴情報を取得する以下の関数は引き続きアクセスが制限されています
- QUERY_HISTORY
- QUERY_HISTORY_BY_*
- LOGIN_HISTORY_BY_USER
- 履歴情報を取得する以下の関数は引き続きアクセスが制限されています
詳細は以下をご参照ください。
Feb 05, 2026: Notebooks in Workspaces (一般提供)
Workspace 内で Notebook の開発・実行ができる機能が一般提供となりました。
ノートブックが Workspaces 内の ファイルとして扱われることで、以下のような操作が容易になります。
- フォルダ作成・ファイルアップロードなどのファイル管理（プロジェクト構成を作れる）
- ノートブックを タブで開いて編集/実行
- ノートブック単体ではなく、周辺ファイルを含めた複数ファイルでの開発
特徴として Notebooks in Workspaces は、Snowpark Container Services による Container Runtime 上で動作します。そのため、SQL 実行用のウェアハウスとは異なるコンピュートリソースでノートブックを動作させることができ、AI/ML ワークロードを想定した実行環境として利用できます。
詳細は以下をご参照ください。
Feb 02, 2026: Cortex Code CLI (一般提供)
Snowflake ネイティブの AI コーディングエージェントである Cortex Code CLI が一般提供となりました。
エージェント型アシスタントとして、SQL開発、データ探索、アカウント管理などをサポートしています。ロール、権限、スキーマ、SQL構文などを理解し、コード生成・変更が可能です。
SQL ファイルだけでなく Notebook, dbt Projects に関する YAML ファイルの編集も可能で、Snowflake 以外にも、dbt, Apache Airflow もサポートされています。
前提として、利用にはアカウントでクロスリージョン推論が有効になっていれば、すべての商用アカウントで利用可能です。
詳細は以下をご参照ください。
Feb 02, 2026: Cortex Code in Snowsight (パブリックプレビュー)
Snowsight 上で環境構築不要ですぐに使用できる Cortex Code in Snowsight がパブリックプレビューとなりました。
詳細は以下をご参照ください。
Feb 02, 2026: Snowsight での外部ボリュームの管理がパブリックプレビュー
Snowsight で「Catalog > External data」より外部ボリュームを管理できるようになりました。
外部ボリュームに関する各種操作を GUI で行えます。
詳細は以下をご参照ください。
Feb 01, 2026: ORGANIZATION_USAGE の新しいプレミアムビュー
組織アカウントで使用できる ORGANIZATION_USAGE スキーマに以下のプレミアムビューが追加されました。組織内のクレジット消費について、アカウント横断で分析できるようになります。
- METERING_HISTORY
- 組織内の各アカウントの時間ごとのクレジット使用量を確認できるビュー
- QUERY_ATTRIBUTION_HISTORY
- 組織内のウェアハウスで実行された特定のクエリに計算コストを確認できるビュー
詳細は以下をご参照ください。
Behavior Change Log
2026_01 バンドルが提供開始 ※デフォルトは無効化
10.1 （2026/1/19 - 2026/1/23 リリース）で、2026_01 バンドルが提供開始となりました。先に挙動を確かめたい場合には手動でバンドルを有効化してテスト可能です。
このバンドルは、2026年3月のリリースでデフォルトで有効化される予定となっています。
2025_07 バンドルがデフォルトで有効化
10.1 （2026/1/19 - 2026/1/23 リリース）で、2025_07 バンドルがデフォルトで有効化されました。
このバンドルは、2026年3月のリリースで一般的に有効化される予定となっています。
Modern Data Stack全般の最新情報
Snowflakeも含め、Modern Data Stack 全般の最新情報についても、定期的にブログにまとめて投稿されています！こちらもぜひご覧ください。
