Snowflake CLI 3.17.0 リリース解説: Native Apps と Apps Deploy の運用面が整理された

Snowflake は 2026年5月11日に Snowflake CLI 3.17.0 を公開しました。今回の更新は、Snowflake Native Apps、Snowflake Apps Deploy、workload identity、custom image、DCM、接続設定の権限管理に関係するため、CLI を CI/CD や開発者ワークフローに組み込んでいるチームは確認しておきたい内容です。

要点

• snow app command group が Native Apps と Snowflake Apps Deploy の両方を扱うようになった
• snowflake.yml の entity type に応じて bundle、deploy、validate、open、events、teardown などの挙動が選ばれる
• snow app setup、snow connection generate-workload-identity-token、snow custom-image validate、snow dcm purge が追加された
• secondary roles、SPCS service drop の --force、DCM upload performance、connector-python 4.4.0 更新も含まれる
• 将来の Snowflake CLI では strict configuration file permissions が必須化される予定で、事前検証用の環境変数が案内された

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

Snowflake CLI 3.17.0 の中心は、アプリケーション開発と運用自動化の境界を整理する更新です。snow app が Snowflake Native Apps と Snowflake Apps Deploy の両方を扱うようになり、同じサブコマンドでも snowflake.yml の entity type によって実行対象が切り替わります。これは、Snowflake 上で配布型アプリ、内部向けアプリ、運用ツールを扱うチームにとって、コマンド体系を単純化する一方で、設定ファイルの正確性がより重要になる変更です。

workload identity token の生成コマンドも見逃せません。AWS、GCP、Azure、OIDC provider を前提にした token 生成は、CI/CD やワークロード実行環境から Snowflake へ接続する設計に関係します。長期 credential を避け、実行環境の identity を使って短命 token を扱う方向へ寄せたいチームにとって、CLI 側の標準コマンドとして使えることは運用上の意味があります。

custom image validation は、Snowpark Container Services やコンテナ化された実行環境を扱うチームに効きます。entrypoint、environment variables、Python packages、dependency health を検証でき、任意で Grype vulnerability scanning も走らせられるため、デプロイ前の品質ゲートとして使いやすくなります。DCM 関連では purge command、manifest target validation、file upload performance 改善が入り、Declarative Change Management を試しているチームの運用確認点が増えています。

また、snowflake-connector-python 4.4.0 への更新と strict configuration file permissions の予告は、セキュリティ運用に直結します。将来の CLI で設定ファイル権限が必須化される前に、SNOWFLAKE_CLI_FEATURES_ENFORCE_STRICT_CONFIG_PERMISSIONS=1 を使って現行環境が耐えられるかを確認できます。ローカル開発者だけでなく、CI runner、build agent、共有端末、container image 内の設定ファイル権限も点検対象です。

対象になりそうなユーザー・チーム

• Snowflake CLI を CI/CD、dbt、アプリ配布、運用自動化に使う platform team
• Snowflake Native Apps または Snowflake Apps Deploy を扱う開発チーム
• workload identity や OIDC を使って Snowflake 接続を統制したいセキュリティ / SRE チーム
• SPCS custom image や DCM projects を検証しているデータ基盤担当

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

まず、既存の snow app workflow が experimental hidden command や feature flag に依存していないか確認します。3.17.0 では snow __app と ENABLE_SNOWFLAKE_APPS が取り除かれているため、社内ドキュメント、CI script、developer onboarding 手順に古い呼び出しが残っていると失敗する可能性があります。

次に、snowflake.yml の entity type を明示的に確認します。Native Apps と Apps Deploy のどちらとして扱われるかで、bundle、deploy、validate の意味が変わります。複数チームが同じ repository を触る場合は、設定ファイルのレビューを pull request の必須確認項目に入れるのが安全です。

workload identity や secondary roles を使う場合は、接続設定と role activation の挙動を staging で検証します。ALL / NONE の secondary roles 指定は便利ですが、既存の SQL や deployment script が暗黙の secondary role に依存している場合、権限不足が表面化することがあります。

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

Snowflake CLI 3.17.0 は、派手な UI 機能ではなく、Snowflake 上のアプリ、コンテナ、DCM、認証、接続設定を日常運用に載せるための土台を整える更新です。CLI を単なる手元ツールとして使っている場合より、CI/CD や platform engineering の共通部品として使っているチームほど、早めに検証する価値があります。