Snowflake、外部query engineからのIceberg tables書き込みをGA

Snowflake は 2026年5月26日付の Recent feature update として、Snowflake-managed Apache Iceberg テーブル を外部 query engine から書き込む機能が 一般提供 になったと発表しました。Snowflake Horizon カタログ の単一 エンドポイント と Snowflake の既存 ユーザー / 役割 / ポリシー / authentication を使い、Iceberg REST protocol をサポートする外部エンジンから Snowflake-managed Iceberg v2 / v3 テーブル を読み書きできるようになります。

要点

• Snowflake-managed Apache Iceberg テーブル への外部 query engine からの write サポート が 一般提供 になった
• Apache Spark など、Iceberg REST protocol をサポートする外部エンジンから read / write できる
• Snowflake Horizon カタログ の単一 エンドポイント と既存の Snowflake ユーザー、役割、ポリシー、authentication を利用する
• 外部エンジン接続の認証 option として、OpenID Connect (OIDC) による Workload Identity Federation (WIF) も追加された
• Lakehouse / open テーブル format を使うチームでは、Snowflake 管理 テーブル と外部 compute の役割分担を再設計する候補になる

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

Snowflake の 2026年5月26日 feature update は、Snowflake-managed Apache Iceberg テーブル に対する外部 query engine からの write サポート が 一般提供 になったことを案内しています。対象は Snowflake-managed Iceberg v2 / v3 テーブル で、外部 query engine が open Iceberg REST protocol をサポートしていれば、Snowflake Horizon カタログ 経由で読み書きできます。Snowflake は例として Apache Spark を挙げています。重要なのは、外部 engine から直接 テーブル を扱う場合でも、単一の Horizon カタログ エンドポイント と Snowflake の ユーザー、役割、ポリシー、authentication を使う構成として説明されている点です。

これは、Iceberg を「Snowflake の外にある open テーブル format」としてだけ使うのではなく、Snowflake が管理する Iceberg テーブル を、外部 compute と Snowflake ガバナンス の両方から扱う方向の更新です。Spark などの既存処理基盤を持つチームにとっては、重い変換や既存 job を外部 engine に残しながら、カタログ、ポリシー、authentication、テーブル 管理を Snowflake 側へ寄せる選択肢になります。逆に、すべての処理を Snowflake compute に移す前提ではないため、lakehouse / data platform の設計に柔軟性が出ます。

同時に、write サポート が 一般提供 になると、運用上の確認点も増えます。外部 engine からの書き込みは、読み取り専用連携よりも テーブル consistency、concurrency、スキーマ evolution、partition / ファイル layout、ロールバック、監査、権限境界に強く関わります。Snowflake-managed テーブル である以上、Snowflake 側の ガバナンス と外部 compute 側の job control が矛盾しないようにする必要があります。たとえば Spark job がどの identity で Horizon カタログ に接続し、どの 役割 / ポリシー が適用され、失敗時にどのログを見るのかを運用手順として決める必要があります。

今回の update は、外部 engine 接続の authentication option として Workload Identity Federation (WIF) with OpenID Connect (OIDC) も追加しています。これは long-lived secret を置くより、workload identity に基づいて認証を組む方向に近い更新です。外部 compute から Snowflake-managed Iceberg テーブル に書き込む場合、認証情報 管理は大きなリスク点になるため、WIF / OIDC の選択肢は セキュリティ / platform team にとって重要です。

Snowflake は 5月7日にも Apache Iceberg version 3 サポート 一般提供 を Recent feature updates に出していました。今回の 5月26日更新は、それに続いて「Iceberg テーブル を外部 engine と Snowflake ガバナンス の間でどう使うか」をより実務寄りに進めるものです。Iceberg を採用するチームは、format の互換性だけでなく、カタログ、access control、write path、オブザーバビリティ を一体で設計する必要があります。

対象になりそうなチーム

• Spark などの外部 compute と Snowflake-managed Iceberg テーブル を併用したい data platform team
• Iceberg REST カタログ、Horizon カタログ、Snowflake ガバナンス の役割分担を設計する architecture team
• OIDC / Workload Identity Federation を使った workload authentication を管理する セキュリティ / platform operations team

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

まず、どの external query engine から write するのか、その engine が Iceberg REST protocol をどの範囲でサポートしているのかを確認します。次に、Snowflake 側の 役割、ポリシー、authentication と、外部 engine 側の job identity、deployment environment、再実行 / failure behavior を突き合わせる必要があります。

本番採用前には、スキーマ evolution、concurrent writes、failed job の cleanup、ファイル compaction、ロールバック、監査ログ、コスト attribution を検証してください。特に複数 engine から同じ テーブル に write する場合は、所有者と変更 window を明確にしないと、open テーブル format の利点より運用複雑性が上回る可能性があります。

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

Snowflake-managed Iceberg テーブル への外部 engine write サポート 一般提供 は、Snowflake と外部 lakehouse compute を組み合わせたい組織にとって重要な更新です。Snowflake を ガバナンス / カタログ の中心に置きつつ、Spark などの既存 compute を使い続ける設計が取りやすくなります。ただし、write path を開く更新なので、権限、identity、失敗時の復旧、監査を設計してから段階的に広げるべきです。