Snowflake 2026年5月19日のリリースノート解説: dbt Projects と Batch Cortex Search

Snowflake は Recent feature updates で、2026年5月19日の dbt Projects on Snowflake updates と、2026年5月18日の Batch Cortex Search (General availability) を公開しました。Snowflake 上で dbt 開発を運用するチームと、Cortex Search を大規模なオフライン検索・照合処理に使いたいチームの両方に関わる更新です。

要点

• Snowflake Recent feature updates に、5月19日の dbt プロジェクト更新が掲載された
• 5月18日には バッチ Cortex Search が 一般提供 になった
• CORTEX_SEARCH_BATCH テーブル function により、多数の fuzzy-match queries を単一 SQL statement で実行できる
• バッチ search は entity resolution、audience matching、deduplication、clustering などの高スループット offline workload を想定している
• interactive search traffic と競合しない dedicated serverless compute を使うため、検索サービス運用と バッチ workload の分離がしやすくなる

今回のリリースノートで語られていること

Snowflake の 5月18日付リリースノートでは、バッチ Cortex Search の 一般提供 が案内されています。CORTEX_SEARCH_BATCH テーブル function を使うと、Cortex Search サービス に対して多数の fuzzy-match queries を一つの SQL statement で実行できます。Snowflake は用途として、entity resolution、audience matching、deduplication、clustering のような high-スループット offline workloads を挙げています。これらは、ユーザーが画面から検索する interactive ユースケース ではなく、既存データ同士を大量に照合し、候補を作り、重複や類似性を処理する裏側のデータ処理です。

重要なのは、バッチ Cortex Search が dedicated serverless compute を使う点です。Snowflake の説明では、バッチ search 用の compute は自動で起動し、interactive search traffic とは独立して scale します。そのため、リアルタイム検索に使っている Cortex Search サービス と、夜間・定期・大量処理の バッチ query が同じ処理能力を取り合う構成を避けやすくなります。さらに、serving で suspended になっている サービス に対しても query できるため、バッチ job のためだけに index を active に維持する必要がない、という運用上の意味もあります。

使い方としては、既存の Cortex Search サービス に対して LATERAL join と CORTEX_SEARCH_BATCH を使い、query 列を渡して ranked results を テーブル として受け取る形が示されています。これは、SQL パイプライン の中に semantic / fuzzy search 的な照合処理を組み込みたいチームにとって扱いやすい形です。たとえば、顧客名や企業名の名寄せ、商品・広告オーディエンスの類似照合、CRM や サポート チケット の重複検出、自由記述データのクラスタリングなどで、検索結果を後続の SQL 処理や ガバナンス ワークフロー に渡しやすくなります。

5月19日の dbt Projects on Snowflake updates は、Snowflake の Recent feature updates に掲載された更新です。Snowflake は dbt プロジェクト on Snowflake を Snowflake 内で dbt プロジェクト object として扱い、dbt Core version、実行履歴、デプロイ・実行操作を Snowflake 側に寄せる方向で継続的に更新しています。既存の4月ブログ記事や過去の dbt プロジェクト一般提供記事とは別に、5月19日の公式更新として読んでおく必要があります。

対象になりそうなチーム

• Cortex Search を検索 UI だけでなく、名寄せ・重複排除・類似照合に使いたい data engineering team
• Snowflake 上で SQL パイプライン と AI / search ワークフロー を近づけたい platform team
• dbt プロジェクト on Snowflake を使って dbt 実行と Snowflake ガバナンス を近づけたい analytics engineering team
• バッチ workload と interactive search workload の compute 分離を気にする operations / FinOps team

実務で確認したいポイント

バッチ Cortex Search を試す場合は、まず既存の Cortex Search サービス に対し、どの列を query として渡し、ranked results をどの後続テーブルに保存するかを決めます。entity resolution や deduplication では、検索結果をそのまま正解とみなすのではなく、score threshold、確認待ち行列、例外処理、証跡として残す期間を設計する必要があります。interactive search と バッチ search が競合しにくい構成になったとしても、バッチ job の頻度、入力件数、serverless compute コスト は別途測る必要があります。

dbt プロジェクト on Snowflake については、既存の dbt Cloud / Core / CI 実行と Snowflake 内の dbt プロジェクト object をどう棲み分けるかが論点になります。Snowflake 内で実行履歴や version 情報を見られるようになるほど、analytics engineering の運用は Snowflake 権限、監査、変更管理と密接になります。既存の Git ワークフロー、package 管理、環境差分、ロールバック 手順と衝突しないかを確認したいところです。

結局、この更新をどう見るべきか

今回の Snowflake 更新は、Cortex Search を大規模なデータ処理の部品として使う道を広げるものです。バッチ Cortex Search の 一般提供 によって、検索を UI 体験だけでなく、SQL パイプライン 内の照合・重複排除・クラスタリング処理として扱いやすくなります。dbt プロジェクト の更新も含め、Snowflake は開発・検索・変換処理をアカウント内の運用モデルへ寄せ続けているため、利用チームは便利さだけでなく、権限、コスト、変更管理、既存 CI/CD との接続を合わせて確認する必要があります。