🤖

成長できるMLOps -SWT Tolyo2025の振り返り-

に公開
機械学習
Snowflake
MLOps
zennfes2025free
idea

はじめに

この記事は2025年9月11日・12日に開催された Snowflake World Tour Tokyo 2025（SWT）の振り返り記事です。
SWTには今回が初参加でしたが、スポンサーセッションに登壇する機会を頂いたこと、SnowVillage主催のコミュニティブース運営にも関われたこと（あまり戦力にはなれませんでしたが…）、などなど沢山の経験がありました。
どのセッションも学びが多く、EXPOでのデモも刺激的でしたが、私は登壇を通じて自分が関わってきたプロジェクトを改めて見直す良い機会になったと感じています。

この記事では、特にMLOpsに関して、SWT前に整理していた内容を中心にまとめます。

セッション概要

今回のセッションでは、「業務システムをSnowflakeを中心にリプレイスするプロジェクト」 の軌跡をご紹介しました。
大きく三本立ての内容となっています。

  • プロジェクトの推進体制
  • Snowflakeを業務システムに活用するアーキテクチャ
  • データ民主化とMLOpsの道のり

オンデマンド配信はこちら
(めちゃくちゃ緊張していて恥ずかしい...)

MLOpsとは

MLOpsは、MLモデルの開発からビジネスでの実運用までを含んだサイクルを継続的に繰り返す仕組みです。
私は、下図のように大きく3つのサイクルで1つの取り組みが成立すると考えています。そして、どこかのサイクルで頓挫する取り組みも許容されるべきだと思います（必ずしもこの3つのサイクルを完遂することがMLOpsの目的ではないため）。
MLOps概念図
セッションではこの考え方をベースに話を組み立てました。

MLOpsが難しいと感じるのは何故か

MLOps自体は2017年辺りから提唱されています。
少し古い情報ですが、2021年に公開されたこちらの白書では50~70%の組織でMLOpsを含めたAI導入に失敗しているとの報告があります。
現在はもうちょっとMLOpsに成功している企業は増えていると思いますが、依然として難しい取り組みであることには変わりません。
私は組織内でMLOpsが定着しない理由は二つあると感じています。

精度偏重のKPI設定

すでに何かしらの予測（ルールベースや重回帰などの簡単なモデル）を行っており、システムのリプレイスに伴ってMLモデルを導入しようという動きは沢山あると思います。
既存システムの上に業務が成立しており、KPIに予測精度が含まれている場合、リプレイスに合わせて予測精度の新旧比較が行われることは避けられません。新しくMLモデルを導入するとなれば、期待が高まりますが、本番環境にデプロイできるようなモデルでは往々にして精度が出ません。
これは予測に使うデータパイプラインが担保できる品質に限界があることや、処理の再現性を確保するためにアドホックな処理が避けられ、MLモデルにとって解釈性の高いデータが作成されない等の原因があるためです。
MLOpsでは予測精度の変動を許容しなければなりません。

ML課題とビジネス課題のズレ

MLモデルが解くべき問題と、ビジネス上の課題は必ずしも一致しません。
MLモデルはどんな問題でも解ける（推論できる）という代物ではないため、業務で欲しい情報とMLモデルが提供する情報には必ず解離が発生します。特に、これまで予測を行っていなかった業務にMLを導入する場合、予測データを業務で使うデータの形に変換する仕組みがなければ、「なんだか使いにくいなぁ」となり、現場に浸透しません。
MLOpsのサイクルではMLモデルが本番環境で稼働することまでを対象にしますが、それだけではビジネスに根付くことはありません。予測結果を利用可能な形に変形するところまでを考慮に入れたサイクルを描くべきです。

使ってもらえるMLOpsを目指すために

単純に予測精度だけを追い求めてしまうと、早々に挫折することになります。
「精度よくないな～」から「あてにならないな～」という評価はすぐ下されてしまいます。
それでは進歩の芽がある取り組みでも、誰も支持してくれなくなり、取り組みが潰えてしまいます。
MLOpsを評価するためには精度以外も指標に加えるべきです。
例えば「予測精度は落ちるかもしれないが、MLモデルを導入したことによって、予測業務に関するマスタメンテナンスの時間が減った」といったような効果です。MLOpsを導入するメリットや目的を（完ぺきでなくても良いので）いち早くユーザー部門と共有することが大事だと考えています。

また、予測データが「そのままビジネスに使える形ではない」ということにも気を払う必要があります。どれだけ良い予測が出ていても、何らかのアクションの根拠になるようなデータでないと、誰も使ってくれません。
「予測データ」と「使えるデータ」には乖離があることを理解し、このギャップを埋める努力はエンジニア部門・ユーザー部門双方から行うべきです。この時大事なのは形式ばった仕様書ではなく、あくまで対話の姿勢を崩さないということだと感じています。

  • エンジニアがロジックを作成
  • できあがったデータをユーザーが確認
  • 違和感をエンジニアにフィードバック

この流れを定期的に繰り返すことで、予測データは徐々に「使えるデータ」へと進化していきます。
基本的には1回gitにコミットする度に、ユーザー側にデータを確認してもらうような頻度で繰り返してきました。
私の環境では、データサイエンティスト・MLエンジニア・データエンジニアといった明確な役割分担はありません。むしろ、各メンバーが守備範囲を限定せず、柔軟にプロジェクトに関わるスタイルを取っています。
このやり方が、結果的にMLOpsとビジネスをつなぐ橋渡しになっていると感じています。
MLOpsは、他社の成功事例を真似するだけでは自社で成功しません（定着しません）。
理想論を語ることも大切ですが、エンジニアとユーザーが同じ目線で、着実に二人三脚することが何よりも重要だと実感しており、私たちも道半ばですが地道に進んでいます。

おまけ：SnowflakeとMLOps

最後にML関連のアップデートで気になったものをいくつか紹介します。
Snowflake高田さんのセッションがよくまとまっていて良かったです。

  • ML実験トラッキング（PrPr）
    ML実験に関する情報を保存しておけるようです。これは期待大。
  • Hugging Face Modelデプロイメント（PrPr soon）
    事前学習済みのモデルを、ワンクリックでモデルレジストリに保管できるようになるらしい🤗
  • コンテナランタイムによるベイズ最適化を利用したHPO（GA?）
    ランダムサーチとグリッドサーチだけだと思ってたのに、いつの間にできるようになったんや…???

Discussion