SELECT

Snowflake新機能まとめ:2025年夏

By Jeff SkoldbergSep 18, 202516 min read

このページはEnglish、Deutsch、Español、Français、Italiano、Portuguêsでもご覧いただけます。

今月の「What's New in Snowflake」は、2025年7月と8月のアップデートをまとめてお届けします。6月のSnowflake Summit直後の7月はアップデートが比較的少なかったため、2か月分を1本にまとめることにしました。それでもボリュームはかなりのものです。どなたにも刺さる内容が必ずあるはずなので、サイドバーの目次から気になるトピックをぜひ探してみてください。

Snowsight

新しいサイドバー(プレビュー、順次展開中)

Snowflakeは左ナビゲーションサイドバーを再構成し、段階的に展開しています。すでに切り替わったアカウントもあれば、これから切り替わるアカウントもありますが、私が見た限りでは大半のアカウントですでに新サイドバーが利用できる状態です。メニューのグループ分けがすっきりし、実際のチームの作業の流れに沿った構成になりました。最初は少し戸惑い、「databases」や「query history」を見つけるのに数秒かかりましたが、トータルでは新レイアウトがとても気に入っています!

レイアウト:

Shortcuts: よく使うページを最大3つピン留めできます。ドラッグで並べ替えも可能です。
Work with data: Projects、Ingestion、Transformation(dbt、Task History、Dynamic Tables)、AI & ML、Monitoring(query historyはここ!イベントテーブルのGUIビューもこちら)、Marketplace。
Horizon Catalog: Catalog(databasesはここ!)、Data sharing、Governance & security。
Manage: ComputeとAdmin。

ショートカットのピン留め・解除は次のように行います:

下のスクリーンショットはSnowflake公式ドキュメントからの引用で、新旧サイドバーを並べて比較したものです。

ちなみに、新しいグローバル検索をまだ試していない方はぜひ一度使ってみてください。データベース、マーケットプレイス、ドキュメントなど、Snowflake内のあらゆる場所からキーワードを横断検索できます。私自身、探しているものを素早く見つけるのにかなり重宝しています。

Snowsightでセマンティックビューを作成(パブリックプレビュー)

データベースオブジェクトエクスプローラー、またはCortex Analystページから、Snowsight上で直接セマンティックビューを作成・管理できるようになりました。ウィザード形式とYAMLアップロードのどちらでも作成可能です。

開始ポイント:
- 旧サイドバー: Data → Databases → スキーマを選択 → Create → Semantic View、または AI & ML → Cortex Analyst → Create / Upload YAML。
- 新サイドバー: Horizon Catalog → Catalog → Database → スキーマを選択 → create → Semantic View
- または AI & ML → Cortex Analyst から

実際に試したところ、新規セマンティックビューの作成はとても簡単でした。手順は以下のスクリーンショットでご紹介します。

ステップ1: スキーマを開いて「Create」をクリックします。下の画像は新サイドバーで、データベースとスキーマは「Horizon Catalog」配下にあります。

ステップ2: フォーム画面に入力していきます。

Cortex Analystメニューから同じことを行う場合は次の通りです:

補足: SQLでセマンティックビューをクエリする機能もプレビュー中です。詳細はドキュメントをご覧ください。

データエンジニアリング・パイプライン・SQLのアップデート

Dynamic Tables: 外部管理のIcebergからの読み込みに対応(GA)

Dynamic Tablesから、外部カタログで管理されているIcebergテーブルを直接読み込めるようになりました。Icebergを活用するお客様にとって、Snowflakeのデータパイプライン機能の大きな進化と言えます。詳細はドキュメントをご覧ください。

標準テーブルでの構造化型サポート(GA)

BigQueryやDatabricksといった他のデータプラットフォームでは以前から構造化データ型(struct、array、record)が提供されていましたが、Snowflakeではこれまでvariant型でこうしたユースケースをカバーしてきました。

今後は通常のSnowflakeテーブルでもARRAY、OBJECT、MAPを構造化カラムとして定義でき、1カラムあたり最大1,000個のサブカラムを持てます。現時点では、構造化型はDynamic Tables、ハイブリッドテーブル、外部テーブルでは未サポートです。詳細はドキュメントをご覧ください。

Snowpipe Streamingの事前クラスタリング(プレビュー)

Snowpipe Streamingで、取り込み時に行を事前クラスタリングし、クラスタリングキー順にソートされた状態でデータを格納できるようになりました。これにより、頻繁にアクセスされるテーブルのクエリ性能が向上し、自動クラスタリングの負荷も軽減されます。当社ではまだ検証していませんが、自動クラスタリングのコストが大きいお客様にとっては有力なコスト削減策となりそうです。

COPY定義でCLUSTER_AT_INGEST_TIME=TRUEを指定すると、事前クラスタリングが有効になります。ターゲットテーブルにはあらかじめクラスタキーが設定されている必要があります。

CREATE OR REPLACE PIPE TEST_PRECLUSTERED_PIPE
AS
    COPY INTO TEST_PRECLUSTERED_TABLE (num) FROM (
            SELECT $1:num::number as num FROM TABLE(
                DATA_SOURCE(
                    TYPE => 'STREAMING')
        ))
        CLUSTER_AT_INGEST_TIME=TRUE;

COPY FILESコマンド(GA)

COPY FILESは、あるステージから別のステージへオブジェクトを移動するコマンドです。実務での使い方としては、「未処理」フォルダから「処理済み」フォルダへファイルを移動するケースが代表的です。

このような構成にすれば、(Snowflake外で)バケットポリシーを設定するだけで、データライフサイクル管理用のコードを別途書かなくても、一定期間経過後に未処理フォルダを自動的にクリーンアップできます。

たとえば、未処理のデータは30日後に削除、処理済みのデータは60日後にGlacierへアーカイブ、といったポリシーが組めます。こうすることでデータの重複やSnowflake外でのストレージコストを抑えられます。

別ユーザーとしてタスクを実行: EXECUTE AS USER + IMPERSONATE(GA)

タスクの所有者ロールが対象ユーザーに対してIMPERSONATE権限を持っていれば、EXECUTE AS USERを使って特定ユーザーの権限でタスクを実行できるようになりました。行アクセス制御やマスキングなど、下流のポリシーやシステムがユーザーIDに依存しているケースで重宝します。また、ログを後から見返したときに、そのタスクが実際に誰として動いたのかを把握しやすくなります。

以下は新機能のイメージをつかむための簡略例です。ユーザーとロールはすでに存在する前提です。ユーザー、ロール、ウェアハウス、タスク権限の作成まで含めた完全な例は、Snowflakeのドキュメントをご覧ください。

-- IMPERSONATE権限を付与。これが新機能!
GRANT IMPERSONATE ON USER task_user TO ROLE task_role;

USE ROLE task_owner;

-- 別ユーザーとしてタスクを実行
CREATE TASK team_task
  SCHEDULE='12 HOURS'
  EXECUTE AS USER task_user
  AS SELECT 1;

Summitで発表された新しいSnowpipe価格モデル: Business CriticalとVPSでGAに

Summitレポートでも触れた通り、新しいSnowpipeの価格モデルはお客様にとって有利な変更です。旧モデルは「コア単位の秒課金」と「1,000ファイル単位の課金」の2要素で構成されていましたが、新モデルは取り込んだGBあたりの固定クレジット料金に一本化され、シンプルになりました。

この新価格は、Business CriticalおよびVPSのお客様向けにすでにGAとなり、Standard・Enterpriseのお客様にもまもなく展開される予定です。

詳細を正しく押さえるには、クレジット消費表とSnowpipeコストのドキュメントに目を通すことをおすすめします。

Snowpark Connect for Spark と Snowpark Submit(プレビュー)

ひと言で言えば、Apache SparkのジョブをSnowflake上で、コードを書き換えずにそのまま実行できるようになりました。Spark DataFrame、SQL、UDFが対象です。さらにSnowpark Submitを使えば、非対話型のジョブを非同期で送信することもできます。

これらの機能は、Snowflakeへ移行中で、SparkコードをSnowpark APIに書き直したくないSparkユーザーにとって、現実的な橋渡しとなります。

開発には、Jupyter NotebooksやSnowflake Notebooksといった使い慣れたツールが利用できます。詳細はドキュメントをご覧ください。

Snowflake Scripting UDF(GA)

Snowflake ScriptingのロジックをSQL UDF内で使えるようになり、ストアドプロシージャのようにCALLで呼び出すだけでなく、クエリ内からインラインで呼び出せるようになりました。SELECTやINSERTの中で使い回したい、ちょっとした手続き的ヘルパーやカスタムSQL関数にぴったりです。

Snowflake Scriptingは強力なSQLスクリプト言語です。新しいUDF機能の詳細はこちらをご覧ください。

なお、カーソル(declare … c1 cursor for select foo from bar)は動作しない点にご注意ください。とはいえ、カーソルのような行ベースのロジックはSQL関数には不向きなので、この制限はむしろユーザーにとってメリットと言えるかもしれません。

Dynamic Tables: 増分更新でのUNIONサポート(GA)

Snowflakeネイティブのデータパイプライン機能を採用するお客様が増えるなか、Snowflakeは明らかで悩ましかったギャップを一つ埋めました。増分Dynamic Tablesの更新クエリでUNION(distinct)がサポートされるようになり、フルリフレッシュに頼らずに済むマルチソースのマージパターンが広がりました。なお、その他の集合演算子(minus、except、intersectなど)は引き続き増分モードでは未サポートです。

CREATE DYNAMIC TABLE my_dynamic_table
 TARGET_LAG = DOWNSTREAM
 AS
 SELECT * from foo
 -- もうunion allにする必要はない
 union
 select * from bar;

SQL初心者の方へのヒントですが、unionは内部的にdistinctを強制するためクエリ実行が遅くなります。そのためベストプラクティスとしてはunionよりもunion allを優先するのが推奨されます。distinctな結合が本当に必要なときに限り、この新機能を使うようにしてください。

本日時点でSnowflakeのドキュメントにはunion集合演算子のサポートがまだ反映されていませんが、実際にはすでにリリース済みです。🧐

Snowpipeのモニタリングイベントと、Iceberg自動更新イベント(GA)

Snowpipeから、詳細な取り込みイベントが現在のイベントテーブルに発行されるようになりました。パイプの状態変化、ファイル単位の進捗、定期的な取り込みアクティビティのサマリーなどが確認できます。さらに、外部管理のIcebergテーブルが自動更新された際にもイベントが発行されます。

その結果、Snowpipeに到着したステージファイルから、下流のIcebergテーブルが最新状態に保たれるまで、取り込みのライフサイクル全体を1か所で観察できるようになりました。長年の可視性のギャップが解消された格好です。実運用では、詰まったファイルや遅延した更新のトラブルシューティングが大幅に楽になり、データパイプラインのSLAに関するアラートもよりきめ細かく設定できるようになるでしょう。一見地味かもしれませんが、本番の取り込みパイプラインを運用するチームにはすぐにありがたみが伝わる、いわゆる「クオリティ・オブ・ライフ」系の機能だと思います。

機能の詳細はこちらをご覧ください。

Icebergテーブルのターゲットファイルサイズ指定(プレビュー)

Icebergテーブルの作成・変更時に、ターゲットとなるParquetファイルサイズを指定できるようになりました。これによりデータの書き込み方をより細かくコントロールでき、SparkやTrinoなどのエンジンから読み込む際のパフォーマンスも改善できます。

特に、ファイルサイズがクエリ効率を大きく左右するマルチエンジン構成では有用です。ファイルが小さいほど高速で粒度の細かいクエリに向き、大きいほど大規模スキャンのオーバーヘッドを減らせます。Snowflakeをハイブリッドなレイクハウス用途でより柔軟に使えるようにする実用的な一歩だと感じます。

この新機能を使ってIcebergテーブルを作成・変更する例は以下の通りです:

CREATE ICEBERG TABLE my_iceberg_table (
  amount INT,
  name STRING
)
  CATALOG = 'SNOWFLAKE'
  EXTERNAL_VOLUME = 'my_external_volume'
  BASE_LOCATION = 'my_iceberg_table'
  TARGET_FILE_SIZE = '64MB'; -- 新機能!

ALTER ICEBERG TABLE my_iceberg_table
SET TARGET_FILE_SIZE = '128MB';

ALTER LISTING: ターゲットの追加・削除がよりシンプルに(GA)

マーケットプレイスのプロバイダーは、ターゲットセット全体を再送信しなくても、部分的なマニフェストでリスティングのターゲットを追加・削除できるようになりました。多数のアカウント・ロール・組織を扱う際の自動化の複雑さを軽減できます。

AIとセマンティックモデリングのアップデート

セマンティックビューでのプライベートなファクトとメトリクス(一般提供開始)

セマンティックビューを定義する際に、ファクトとメトリクスをPRIVATEとしてマークできるようになりました。プライベート項目はビュー内の計算には使えますが、直接クエリしたり、フィルター条件に使ったりはできません。一方でDESCRIBE SEMANTIC VIEWやGET_DDLには引き続き表示されるので、発見性と監査性は保たれます。「外向きにはビジネス用途で使いやすい綺麗なメトリクスだけを見せ、補助的なファクトや中間メトリクスは隠す」といった使い分けに便利です。個人的には、こんなギャップがあったとは気づいていませんでしたが、これでセマンティックビューはガバナンスを効かせた分析でより本番向きの機能になったと感じます。

CREATE SEMANTIC VIEW my_sales_view
  TABLES (
    orders AS my_db.my_schema.orders PRIMARY KEY (order_id)
  )
  FACTS (
	  -- 新機能
    PRIVATE adjustment_factor AS AVG(orders.adjustment)
  )
  METRICS (
    total_revenue AS SUM(orders.revenue),
    -- 新機能
    PRIVATE adjusted_revenue AS SUM(orders.revenue + adjustment_factor)
  );

AI_EXTRACT関数(プレビュー)

AI_EXTRACTは、非構造化データから構造化フィールドを抽出する関数です。文字列やFILE入力に対応しており、シンプルなプロンプト、または名前とプロンプトのペアでレスポンス形式を定義できます。請求書、契約書、診療記録、マーケティング用PDFなどから、Snowflake内で直接情報を抽出できると考えてください。外部サービスとのやり取りが減り、構造化データに辿り着くまでのパスがシンプルになります。すでにSnowflakeにデータを集約しているチームには有望ですが、プレビュー段階のAI機能であることを忘れずに。私のおすすめは、まずラベル付きのテストデータで性能を見極めること。重要なパイプラインに組み込む前に、どんなガードレールを用意するかをよく検討してください!

例:

-- 構文:
AI_EXTRACT( <text>, <responseFormat> )

-- 構造化された出力を指定する例
AI_EXTRACT( <'非構造化テキストを含むSQLカラム'>,
['address': '市区町村、番地、郵便番号', 'name': '姓と名'] )

-- 自然言語で出力するもう一つの例
-- ここではカラムではなくファイルから抽出します
AI_EXTRACT( <'Snowflake Stage内のPDFファイル'>,
['住所と姓・名を教えて' );\
```\
\
### AI Parse Document レイアウトモード(GA)\
\
[`AI_PARSE_DOCUMENT`](https://docs.snowflake.com/en/user-guide/snowflake-cortex/parse-document#ai-parse-document)のレイアウトモードは、`SNOWFLAKE.CORTEX.PARSE_DOCUMENT`関数を置き換える新しいGA機能です。ドキュメントのレイアウトを、テキストの流れ、テーブル、構造を保持したMarkdownとして抽出します。要するに、PDF(などのファイル)からMarkdownへの変換です!🥳 これにより、チャンク化、RAG、後段のパース処理に流せる綺麗な中間形式が手に入ります。このようなレイアウトを認識したパース処理は、信頼できるドキュメントAIの土台になりそうです。`AI_EXTRACT`と組み合わせれば、生のファイルから構造化された行データへ、より少ないステップで到達できる未来も想像できます。\
\

ML\

Snowflake MLの分散処理: Many Model Training と Distributed Partition Function(一般提供開始)\

Snowflake MLが2種類の分散パターンに対応しました。Many Model Training(MMT)は、Snowpark DataFrameのパーティションごとに別々のモデルを並列で学習します。Distributed Partition Function(DPF)は、Python関数をコンピュートプール内の1つまたは複数のノード上でパーティション単位に実行し、アーティファクトの保存や進捗の追跡まで自動で処理します。これにより、すでに使い慣れたプラットフォーム上でスケールアウトでき、オーケストレーションの手間が大幅に減ります。

もっと深く知りたい方は、データパーティションをまたいだモデル学習とパーティションをまたいだカスタムロジックによるデータ処理のドキュメントが充実しているのでご参照ください。
\

データ品質・オブザーバビリティ・ガバナンス\

Data Metric Function: ACCEPTED_VALUES(GA)\

ACCEPTED_VALUESは、カラムの値が指定したブール式と一致するかを検証し、一致しない行数を返すシステムDMFです。テーブルやビューにスケジュール付きで関連付けることも、SYSTEM$DATA_METRIC_SCANでアドホックに実行することもできます。

カスタムSQLを書かずに、enumやコードセットといった単純な整合性チェックを実装できる、低コストで効果の高い手段です。
\

1-- 構文\
\
2SNOWFLAKE.CORE.ACCEPTED_VALUES ON ( <column>, <lambda-expression> )\
\
3\
\
4-- 例\
\
5ALTER TABLE orders\
\
6  ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.ACCEPTED_VALUES\
\
7    ON (\
\
8      order_status,\
\
9      order_status -> order_status IN ('Pending', 'Shipped', 'Delivered', 'Returned')\
\
10    );\
\
11\
\
12 CALL SYSTEM$DATA_METRIC_SCAN('orders');\
\
13 -- ordersテーブル上のすべてのDMFが返されます\
```\
\
### Snowflake Data Clean Rooms のアップデート(GA)\
\
Data Clean Room(データクリーンルーム)とは、複数の当事者がお互いの生データに直接アクセスすることなく、結合したデータセットを分析できる安全な環境のことです。厳格なクエリ制御とポリシーにより、集計値や匿名化された結果など承認された出力だけを返し、行レベルのデータは決して返さない仕組みになっています。\
\
先月、Snowflakeはデータクリーンルームに4つのアップデートを展開しました。いずれも、クリーンルーム利用時の摩擦を減らす「クオリティ・オブ・ライフ」系のアップデートです。\
\
- **クロスリージョン共有のフローを簡素化**: 別リージョンのコンシューマーからのリクエストを受け入れる際、プロバイダーは`request_laf_cleanroom_requests`と`mount_laf_cleanroom_requests_share`の両方を呼び出す必要がなくなりました。今後は`provider.mount_request_logs_for_all_consumers`を使うだけで済みます。詳細は開発者ガイドの「Implementing activation in your clean room」セクションに記載されています。\
- **インストールの簡素化**: クリーンルームに必要なサービスユーザーをユーザーが手動で作るのではなく、Snowflakeが自動で作成・検証(または既存ユーザーを再利用)するようになりました。これにより、クリーンルームを実際に使い始めるまでのセットアップ手順が減ります。\
- **単一アカウントでのテスト**: 1つのSnowflakeアカウントを、テスト用クリーンルームのプロバイダーとコンシューマーの両方として使えるようになりました。開発・テスト環境にとても便利で、別アカウントを用意することなくクリーンルームのテンプレートを構築・検証できます。Tutorials & samplesページの「Basic UI tutorial, single account」に実例があります。手早く確認したい方はドキュメントもご覧ください。\
- **Cross-Cloud Auto-Fulfillmentの更新頻度を設定可能に**: 異なるクラウドやリージョンにあるプロバイダーとコンシューマー間のデータ更新が、デフォルトで30分ごと(従来の24時間から短縮)になりました。この頻度はさらに設定可能です。ドキュメント参照。\
\
### Write Once, Read Many(WORM)スナップショット(プレビュー)\
\
WORMスナップショットは、テーブル、スキーマ、データベースを対象とした、ある時点での**変更不可**なバックアップです。スナップショットセットを使い、必要に応じてスナップショットポリシーでスケジュールや有効期限を設定できます。**Retention lock**と**Legal hold**により削除からの保護が強化され、特にRetention lockは強力なコンプライアンス保証を目的に設計されています。accountadminであってもこれらのテーブルを削除できないため、認証情報の漏洩やランサムウェアに対しても堅牢な保護が得られます。WORMスナップショットは全エディションで利用可能で、Retention lockとLegal holdはBusiness Critical以上で提供されます。\
\
Time Travelの一段上を行く、ランサムウェア耐性と規制対応の保管のための実用的なコントロールです。バックアップ運用の改善に役立ちそうな機能ですが、まだプレビュー段階なので、Retention lockに依存する前にリストア経路を必ずテストし、ストレージ計画を立てておきましょう。\
\

Snowflake管理\

組織プロファイル(一般提供開始)\

Snowsight上で組織プロファイルを作成・管理し、どのアカウントとロールがプロファイル名義で公開できるかを指定したり、プロファイルのアバターやURL参照で社内向けリスティングをブランディングしたりできるようになりました。Internal Marketplace内での信頼性が高まり、セットアップに必要だった一回限りのSQLが大幅に減ります。大規模な組織でも秩序が感じられるようになり、コンシューマー側にとっても社内データプロダクトの出どころがより明確になります。

\

Tri-Secret Secureのセルフサービス有効化(一般提供開始)\

Snowflakeトレーニングのおさらいですが、Tri-Secret SecureはSnowflakeの暗号化アプローチで、3つの鍵(Snowflake自身の鍵、クラウドプロバイダーの鍵、お客様管理の鍵)を使用します。この3つがすべて揃わなければデータを復号できないため、お客様自身が鍵を無効化することでアクセスを停止できる、直接的なコントロールが手に入ります。Business CriticalおよびVPSで利用可能です。

新しいセルフサービス有効化機能を使えば、ACCOUNTADMINがシステム関数を使って自らTri-Secret Secureを有効化し、お客様管理鍵を運用したり、必要に応じて無効化したりできます。サポートとのやり取りが減り、強力な暗号化コントロールが特別なプロジェクトではなく、アカウント運用の標準的な一部として扱えるようになります。
\

Query Insights: JOINのパフォーマンスと最適化(パブリックプレビュー)\

背景:

Query Insightsは比較的新しい組み込み機能で、非効率なJOINやフィルター不足など、クエリに関する気づきを自動的に提示してくれます。生のプロファイルを読み解かなくても、パフォーマンス改善やコスト削減につながる修正ポイントを、人間が読みやすいヒントとして得られます。

InsightsはSnowsightのQuery History → Query Profileから、またはsnowflake.account_usage.query_insightsビューをクエリすることで確認できます。SELECTのようなサードパーティツールを使えば、専用UIでクエリのインサイトをより見やすく可視化できます。

新機能:

Query Insightsに、JOINのミスや最適化のチャンスを示す新しい気づきが追加され、SnowsightまたはQUERY_INSIGHTSビューから確認できます。JOIN条件の欠落、JOIN結果の爆発、フィルター不足、Search Optimizationの利用状況、スピレッジといったパターンを指摘してくれるので、根本原因の修正がぐっと速くなります。トリアージにはとても役立ちますが、より深い分析にはQuery Profileを併用するのがおすすめです。
\

セマンティックビュー: 任意のスコープでディメンションとメトリクスを一覧表示(GA)\

SHOW SEMANTIC DIMENSIONSとSHOW SEMANTIC METRICSを使い、ビュー、スキーマ、データベース、アカウントなど任意のスコープでセマンティックレイヤーのインベントリを取得できます。特定のメトリクスに対して有効なディメンションの一覧も得られます。これにより、モデルの監査、粒度や関係性の検証ができ、実際に何が使えるのかをチームできちんと把握できるようになります。地味な機能ですが、showコマンドでガバナンス状況を把握する管理者ロールの方々にとっては嬉しいアップデートです。
\

その他のアップデート\

その他の注目アップデートを駆け足でご紹介します:
\

マルチノードMLジョブ - プレビュー\
Create Indexが「Include Columns」をサポート - GA\
Consistency Secretがgenerate_synthetic_dataでオプション扱いに - GA\
セマンティックビューのクエリがプレビューからGAに\
SEARCH_IP関数がIPv6アドレスの検索に対応 - GA\
Trust CenterメールがプレビューからGAに Snowpark Container Services向けの新しいStage Volume - プレビュー\
Microsoft Power Appsコネクター - GA
\

まとめ\

いやはや、2か月でこれだけの機能が登場するとは驚きです!ここで紹介した機能でサポートが必要な場合は、お気軽にお声がけください。

Jeffはデータ&アナリティクスのコンサルタントで、インサイトの自動化やデータを活用したビジネスプロセスのコントロールに15年以上携わってきました。技術面ではSnowflake + dbt + Tableauを得意とし、業界面では公益事業、臨床試験、出版、消費財、製造業での経験があります。お気軽にご連絡ください: [email protected]。\