Snowflake、dbt Projects更新とBatch Cortex Search GAを公開

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 の linked-feature-update として、5月19日の dbt Projects 更新が新しく見える
• 5月18日には Batch Cortex Search が General availability になった
• CORTEX_SEARCH_BATCH table function により、多数の fuzzy-match queries を単一 SQL statement で実行できる
• batch search は entity resolution、audience matching、deduplication、clustering などの高スループット offline workload を想定している
• interactive search traffic と競合しない dedicated serverless compute を使うため、検索サービス運用と batch workload の分離がしやすくなる

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

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

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

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

5月19日の dbt Projects on Snowflake updates は、Recent feature updates の linked-feature-update として新しく表示されています。個別ページ本文は今回の取得環境では詳細本文を安定取得できませんでしたが、Snowflake は dbt Projects on Snowflake を Snowflake 内で dbt project object として扱い、dbt Core version、実行履歴、デプロイ・実行操作を Snowflake 側に寄せる方向で継続的に更新しています。今回の監査では、5月19日の native linked-feature-update として候補化し、既存の4月ブログ記事や過去のdbt Projects GA記事とは別単位として扱っています。

対象になりそうなチーム

• Cortex Search を検索 UI だけでなく、名寄せ・重複排除・類似照合に使いたい data engineering team
• Snowflake 上で SQL pipeline と AI / search workflow を近づけたい platform team
• dbt Projects on Snowflake を使って dbt 実行と Snowflake governance を近づけたい analytics engineering team
• batch workload と interactive search workload の compute 分離を気にする operations / FinOps team

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

Batch Cortex Search を試す場合は、まず既存の Cortex Search Service に対し、どの列を query として渡し、ranked results をどの後続テーブルに保存するかを決めます。entity resolution や deduplication では、検索結果をそのまま正解とみなすのではなく、score threshold、review queue、例外処理、監査用の保存期間を設計する必要があります。interactive search と batch search が競合しにくい構成になったとしても、batch job の頻度、入力件数、serverless compute cost は別途測るべきです。

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

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

今回の Snowflake 更新は、Cortex Search を大規模なデータ処理の部品として使う道を広げるものです。Batch Cortex Search の GA によって、検索を UI 体験だけでなく、SQL pipeline 内の照合・重複排除・クラスタリング処理として扱いやすくなります。dbt Projects の更新も含め、Snowflake は開発・検索・変換処理をアカウント内の運用モデルへ寄せ続けているため、利用チームは便利さだけでなく、権限、コスト、監査、既存 CI/CD との接続を合わせて見ておくべきです。