Snowflake、dynamic tablesにadaptive refresh modeとcustom incrementalを追加

Snowflake は 2026年5月26日付の Recent feature updates で、dynamic テーブル に関する 2 つの 公開プレビュー を追加しました。ひとつは adaptive refresh mode、もうひとつは custom incremental dynamic テーブル です。どちらも、動的テーブルを単なる便利な自動更新 テーブル としてではなく、より複雑な変換 パイプライン の実行基盤として使う流れを強める更新です。

要点

• Adaptive refresh mode for dynamic テーブル が 公開プレビュー になった
• Custom incremental dynamic テーブル が 公開プレビュー になった
• 既存の dynamic テーブル 運用では、refresh mode、incremental eligibility、コスト、failure handling の見直しが必要になる
• streams / tasks / stored procedures で実装していた一部 パイプライン を dynamic テーブル に寄せる候補が増える
• Snowflake の Recent feature updates では同じ 5月26日に Iceberg external engine write サポート 一般提供 も並んでおり、データパイプライン と open テーブル 運用の両方が動いている

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

Snowflake の 2026年5月26日更新では、Recent feature updates の先頭に dynamic テーブル 関連の 2 項目が追加されています。Adaptive refresh mode for dynamic テーブル は 公開プレビュー として掲載され、dynamic テーブル の refresh behavior をより柔軟に扱う方向の更新です。dynamic テーブル は、SELECT 定義と target lag をもとに Snowflake が更新を管理する仕組みですが、実際の運用では、query shape、data volume、upstream changes、遅延 requirement によって full refresh と incremental refresh の選び方が コスト と 信頼性 に直結します。

Custom incremental dynamic テーブル も 公開プレビュー です。従来、dynamic テーブル は SQL 定義を Snowflake が解釈し、incremental refresh できるかどうかを判断する性格が強い機能でした。custom incremental の方向性は、より複雑な パイプライン logic や、streams / tasks で細かく制御していた処理を、dynamic テーブル の枠組みに取り込む余地を広げるものとして読めます。これにより、data engineering team は「どの変換を dynamic テーブル に移せるか」を再評価する必要があります。

実務で重要なのは、プレビュー だからといって単純に試すだけでは足りない点です。dynamic テーブル は upstream テーブル の変更、refresh history、target lag、ウェアハウス / serverless compute、query compatibility、監視 と結びつきます。adaptive refresh mode や custom incremental を使う場合、期待した incremental behavior になっているか、full refresh に fallback して コスト が跳ねないか、refresh failure をどう検知するか、スキーマ change 時にどう扱うかを確認しなければなりません。

また、同じ Recent feature updates には Snowflake-managed Apache Iceberg テーブル への external query engine write サポート 一般提供 も並んでいます。これは、Snowflake が managed データパイプライン と open テーブル / external engine 連携 の両方を強化していることを示します。dynamic テーブル は Snowflake 内部の継続的変換、Iceberg external writes は外部 compute との接続という違いがありますが、どちらも data platform の「どこで変換し、どこで管理し、どこで監査するか」という設計に関わります。

対象になりそうなチーム

• Snowflake dynamic テーブル を本番 パイプライン に使っている data engineering team
• streams / tasks / stored procedures から dynamic テーブル への移行を検討している platform team
• refresh コスト、遅延、failure アラート、リネージ、access history を管理する operations / ガバナンス team

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

まず、既存 dynamic テーブル の refresh mode、target lag、refresh duration、failure history、コスト を棚卸ししてください。adaptive refresh mode を試す場合は、before / after で refresh behavior と compute コスト を比較できるようにします。custom incremental dynamic テーブル は、streams / tasks で明示的に差分処理している パイプライン のうち、SQL で表現できるものから候補を選ぶのがよさそうです。

プレビュー 機能なので、本番適用前には ロールバック 方針も必要です。期待通り incremental にならない場合、full refresh が高コストになる場合、または downstream SLA に影響する場合に、既存 tasks / streams へ戻せる設計にしておくべきです。

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

今回の Snowflake dynamic テーブル 更新は、継続的変換 パイプライン をより Snowflake-native に寄せるための重要な プレビュー です。便利な自動更新 テーブル としてだけでなく、運用可能な パイプライン primitive として評価する段階に入っています。導入判断では、機能可否よりも refresh behavior、コスト、監視、ロールバック を中心に検証するのが現実的です。