Snowflake JDBC Driver 4.3.1、grpc-java更新とGCS/Azure PUT修正を公開

Snowflake は 2026年6月16日、JDBC Driver 4.3.1 のリリースノートを公開しました。grpc-java の更新、shaded JAR からの古い AWS SDK v1 参照除去、GCS/Azure PUT 周りの修正が中心です。

要点

• grpc-java が 1.81.0 から 1.82.0 に更新されました。
• shaded JAR から古い com.amazonaws.util.Base16 / Base64 参照が取り除かれ、snowflake-jdbc-thin が AWS SDK v1 参照を含むように見える問題が解消されます。
• GCS-backed internal stage の PUT で、SPCS pods on GCP からメタデータエンドポイントへ到達しようとして不透明な invalid_gcs_credentials になる問題が修正されています。
• Azure PUT で BlobServiceClient を毎回作っていたことによるメモリリークが修正されています。

今回の更新で変わること

今回の Snowflake JDBC Driver 4.3.1 は、単なるバージョン番号更新ではなく、依存関係、セキュリティスキャン、クラウドストレージへの PUT 処理、メモリ利用に関わる保守更新です。まず grpc-java が 1.81.0 から 1.82.0 に更新されています。Java アプリケーションやETL基盤が Snowflake JDBC Driver を組み込んでいる場合、依存関係の解決、既存ライブラリとの競合、CI/CD の脆弱性スキャン結果に影響する可能性があります。

shaded JAR の変更も実務上重要です。リリースノートでは、古い com.amazonaws.util.Base16 / Base64 のバイトコード参照を取り除くため、未使用の SFBinary と SFBinaryFormat クラスを同梱 snowflake-common アーティファクトから除外したと説明されています。これにより、セキュリティスキャナーが snowflake-jdbc-thin に AWS SDK v1 参照が含まれると誤検知する問題が減る見込みです。セキュリティレビューで古いAWS SDK参照が検出され、例外申請や説明に時間を使っていたチームにとっては、ノイズ削減につながる更新です。

GCS-backed internal stage の PUT 修正は、Google Cloud 上の SPCS pods から Snowflake へデータを送る構成に関係します。公式リリースノートでは、GCS SDK のアプリケーション既定認証情報プローブが metadata.google.internal に到達しようとし、SPCS 内では到達できないため、不透明な invalid_gcs_credentials エラーになっていた問題が説明されています。4.3.1 では、GCS_ACCESS_TOKEN がある場合に明示的な認証情報を常に設定し、メタデータ確認を抑止するようになりました。あわせて、https:// スキーム接頭辞を持たないカスタムGCSエンドポイントの扱いや、例外を握りつぶさず元の例外を連鎖させてログに残す修正も含まれます。

Azure PUT のメモリリーク修正も、長時間稼働するバッチや大量ロード処理では見逃せません。従来は各 PUT が新しい BlobServiceClient を作り、その下層の reactor-netty スタックを解放するAPIがないため、メモリリークにつながっていました。今回の修正では、Azure SDK HttpClient と ConnectionProvider をセッション内の PUT で共有し、セッション終了時に破棄する形になっています。Azure Blob Storage 経由のステージ操作や大きなデータ転送を行う環境では、ドライバー更新後にメモリ使用量、接続数、PUT 処理の安定性を確認したいです。

したがって、この更新は JDBC 接続を使うアプリケーションの通常保守であると同時に、クラウドストレージ連携とセキュリティスキャン運用の改善として読む必要があります。Snowflake への接続自体が普段安定している環境でも、GCS、Azure、SPCS、thin driver、依存関係スキャンに関係するチームは、4.3.1 の適用計画と検証観点を明確にしたいです。

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

• Java アプリケーションやETLが Snowflake JDBC Driver を直接または間接的に固定していないか
• snowflake-jdbc-thin に対するセキュリティスキャンの AWS SDK v1 関連指摘が変わるか
• GCS-backed internal stage PUT を SPCS pods on GCP から使うワークロードがあるか
• Azure PUT を長時間または大量に実行するジョブで、メモリ使用量と接続の安定性が改善するか
• カスタムGCSエンドポイントを使っている場合、スキーム接頭辞の扱いを含めて接続テストを行うか

今回の更新が関係する人

Snowflake JDBC Driver を使う Java アプリ、ETL、BI 接続を管理する開発チームに関係します。特に、共通ライブラリとしてドライバーを配布している組織では、代表的な接続パターンをまとめて検証したいです。

Java アプリケーションの運用、CI/CD、依存関係管理、セキュリティスキャンを担当するチームにも関係します。GCS-backed stage、SPCS on GCP、Azure Blob Storage 経由の PUT を使う環境では、単なる依存関係更新として流さず、クラウドストレージ連携の再確認を行う必要があります。

結局、今回の更新をどう読むべきか

今回の更新は、Snowflake そのものの新機能というより、Java 系の接続基盤を健全に保つための更新です。ドライバーを共有しているアプリケーションが多いほど、依存関係、セキュリティスキャン、GCS/Azure PUT、ロールバック方法を先に洗い出してから適用したいです。