[レポート]Snowflake MLの最新情報とMLOpsの効率的な運用ガイド #SWTTokyo25

2025年9月11日～2025年9月12日に、「SNOWFLAKE WORLD TOUR 2025 - TOKYO」が開催されました。

https://www.snowflake.com/ja/world-tour/tokyo/

本記事はセッション「Snowflake MLの最新情報とMLOpsの効率的な運用ガイド」のレポートブログとなります。

登壇者

• Snowflake合同会社
  • 高田 雅人 氏

セッション内容

• 一般的な ML のプラットフォームの課題
  • 通常の ML に関わる運用は DWH とプラットフォームが分かれている
    • これにより、ネットワークのボトルネック、ガバナンスや運用に関わる追加の工数や手間が発生する
  • 属人化
    • ML プラットフォームを運用すると、データサイエンティストが独自のロジックを生み属人化しやすい（例：この特徴量どこから？なぜ使用？）
• Snowflake 上で ML プラットフォームを一元管理するメリット
  • コスト効率化
    • 単一のプラットフォームなのでデータの移動が無い
    • 試行時のコンピューティングリソースのスケールも容易
  • コンテナを使用できる
    • コンテナの方もスケーラブルになりつつある
    • コンテナでは GPU を使用できる
  • 信頼性・セキュリティ
    • ロール中心で管理できる
  • 柔軟性
    • PyPI への接続
    • OSS の ML モデルの使用
    • Snowpark や ML Jobs による外部からの Snowflake へのアクセス

モデルのライフサイクルと関連機能

以降は、ML モデルのライフサイクルに沿って関連する機能やベストプラクティスを紹介。

開発

• 開発時のベストプラクティス
  • コンテナランタイム（CR）の使用
    • Snowflake Notebooks も現在は CR で動作する
    • 今後は CR にシフトしてい行く方針
  • CR しかない機能も出てきている
    • データコネクタ API、トレーニング API、マルチノードの分散トレーニング
  • Notebook で CR を使用するメリット
    • カスタムライブラリの使用
    • コスト効率の良さ（最も小さなサイズでウェアハウスランタイムの10分の1）
    • GPU を使用できる
      • Deep Learning や LLM の fine-tuning
    • リアルタイム推論
• 各種機能の紹介
  • 分散学習 API
    • 特定のモデルについて、Snowflake 上で分散学習が可能
    • データ量が膨大、パラメーターが多岐にわたるようなケースに向いている
  • Data Connector API
    • CR 上のメモリにデータを展開するための機能
      • Snowflake のマイクロパーティションから CR のメモリに展開することができる
    • PyTorch, TensorFlow, Pandas やオーディオファイル、イメージファイルのような非構造データにも対応
  • Data Science Agent
    • ML のコード開発に使用できる Copilot 機能
    • 自然言語で問い合わせをすると、Snowflake に合わせたコードが生成される

オーケストレーション

以下の関連機能があり、これらの使用を推奨。

• ML ジョブ
  • ローカルや外部に存在する ML 関連のコードを、Snowflake 上で実行するための機能
  • Snowflake 内で完結しないオーケストレーションの課題を解決し、CI/CD パイプラインなどから Snowflake の CR アクセスして、データ前処理やモデル学習といった処理を実行する際に使用できる
  • Python ライブラリとして提供されており、既存のコードを変更することなく、外部から Snowflake のコンピューティングリソースを利用できる
• モデルレジストリ
  • Snowflake 内でモデルと関連するメタデータを管理するための機能
  • Snowflake の機能（ML/LLM モデルなど）だけでなく、Scikit-learn や PyTorch といった主要なオープンソースライブラリで作成された外部モデルも一元管理できる
  • 外部で学習したモデルをモデルレジストリに登録することで、UDF として SQL や Python API から簡単に呼び出せる
    • 既存のモデルを Snowflake に移行する際も、モデルレジストリの API を活用することで、容易に持ち込める
  • モデルレジストリに登録しないと、モデル監視、ガバナンス、リネージといった MLOps 関連の機能が利用できないケースもある
• 特徴量ストア
  • データサイエンティストが作成する特徴量の属人化を防ぐための機能
  • チームで ML 開発を行う際に、特徴量の重複作成を防ぎ、共通の特徴量を再利用しやすくする
  • オンラインストアにも対応し、Web サービスなどから高速にデータを取得したい場合に活用できる

デプロイ

• ML モデルはそれぞれ適切な方法でデプロイする
  • バッチ処理：モデルレジストリを利用してデプロイ
    • モデルサービング：モデルレジストリから CR 上にデプロイするとオンライン推論にも対応（API を提供している）
  • オンライン推論：今後は数百ミリ秒単位の推論も可能に
  • Many model：データのパーティションごとにモデルを自動生成・デプロイする機能

運用

• 開発と本番の分離
  • ML コードや CI/CD パイプライン自体を環境ごとに修正することは避け、ブランチを使って環境を切り替える
• リソース管理
  • リソースモニター、予算、タグ機能を使って、ML パイプラインのコストを日次で可視化・管理する

監視

• モデル モニタリング
  • モデルレジストリの add_monitor API を設定することで、デプロイしたモデルのパフォーマンスを日常的に監視できる
  • 監視結果は Snowsight 上で可視化され、複数のモデルの比較も可能
• モデルの説明性
  • 別の API を使用することで、SHAP 値などのモデルの説明性を取得できる
• データ・MLリネージ
  • モデルレジストリや特徴量ストアを利用することで、カラムレベルでのリネージ情報を確認できる

さいごに

Snowflake ML の最新情報とベストプラクティスを ML モデルのライフサイクルに沿って紹介いただいたセッションでした。

個人的に特に印象的だったのでは、ML モデルの開発にコンテナランタイム（CR）を推奨されている点でした。
今後、ML モデル開発は CR の方へシフトする流れもあってか、こちらでしか提供されない機能もあるため、Snowflake のコンテナ機能周りもキャッチアップしていければと思いました。