Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
新卒3年目の後悔〜機械学習モデルジョブの運用を頑張った話〜
Search
camay
June 19, 2025
Technology
0
440
新卒3年目の後悔 〜機械学習モデルジョブの運用を頑張った話〜
白金鉱業 Meetup Vol.19@六本木(若手データサイエンティスト交流会)(
https://brainpad-meetup.connpass.com/event/354926/)の登壇資料です
camay
June 19, 2025
Tweet
Share
More Decks by camay
See All by camay
Lakebaseを使ったAIエージェントを実装してみる
kameitomohiro
0
140
SnowflakeとDatabricks両方でRAGを構築してみた
kameitomohiro
1
850
SPCSでMLflow~初心者によるMLOps事始め~
kameitomohiro
0
150
Other Decks in Technology
See All in Technology
インフラ寄りSREの生存戦略
sansantech
PRO
0
330
使いたいMCPサーバーはWeb APIをラップして自分で作る #QiitaBash
bengo4com
0
2k
Reach American Airlines®️ Instantly: 19 Calling Methods for Fast Support in the USA
flyamerican
1
170
Yahoo!しごとカタログ 新しい境地を創るエンジニア募集!
lycorptech_jp
PRO
0
120
SEQUENCE object comparison - db tech showcase 2025 LT2
nori_shinoda
0
150
Lazy application authentication with Tailscale
bluehatbrit
0
220
生まれ変わった AWS Security Hub (Preview) を紹介 #reInforce_osaka / reInforce New Security Hub
masahirokawahara
0
480
OPENLOGI Company Profile for engineer
hr01
1
34k
ビギナーであり続ける/beginning
ikuodanaka
3
760
Operating Operator
shhnjk
1
590
ビズリーチが挑む メトリクスを活用した技術的負債の解消 / dev-productivity-con2025
visional_engineering_and_design
3
7.8k
ゼロからはじめる採用広報
yutadayo
3
970
Featured
See All Featured
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
960
Building Applications with DynamoDB
mza
95
6.5k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Building Adaptive Systems
keathley
43
2.7k
It's Worth the Effort
3n
185
28k
The Language of Interfaces
destraynor
158
25k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Building an army of robots
kneath
306
45k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Agile that works and the tools we love
rasmusluckow
329
21k
A better future with KSS
kneath
238
17k
Transcript
新卒3年目の後悔 〜機械学習モデルジョブの運用を頑張った話〜 DATUM STUDIO株式会社 データエンジニア部 亀井友裕 2025/6/19 白金鉱業 Meetup Vol.19@六
本木(若手データサイエンティスト交流会)
© 2025 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 1
今回話すこと、話さないこと 話すこと 話さないこと 機械学習モデルの運用が辛かった話(経緯と結果、反省とか) 機械学習モデルの運用でうまくいった部分 (成功には再現性がないが、失敗には再現性がある)
© 2025 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 2
自己紹介 亀井 友裕(社会人4年目) 会社 DATUM STUDIO 株式会社 主な 業務経験 データパイプラインの構築(Databricks) 需要予測モデルの運用(Databricks) RAGの精度改善(AWS) コミュニティ SnowVillage(Snowlfakeユーザー会) JEDAI(Databricksユーザー会) X @Camay119 (アイコンは→)
© 2025 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 3
経緯 • 新卒2年目の終わり頃 • 機械学習モデル開発案件にジョイン • 1つの環境にて、2人のメンバーで開発を進める • 新卒3年目に入り、上記案件が運用フェーズに移行 • 運用メンバーのジョインを見据えて、環境を分離しよう!
© 2025 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 4
環境分離をしました dev, stg, prdに環境分離(画像はイメージです) https://docs.databricks.com/aws/en/machine-learning/mlops/mlops-stacks
© 2025 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 5
想定していた環境の使われ方 開発環境で動作確認 → 検証環境でテスト → 本番リリース というオーソドックスな流れを想定 具体的な運用ルールは決めず、とりあえず運用を開始 https://docs.databricks.com/aws/en/machine-learning/mlops/mlops-stacks ✓ 開発環境 * 機能の開発 & 軽い動作確認 ✓ 検証環境 * 本格的なテスト(あわよくば自動化) ✓ 本番環境 * バグが出ないようにしたい
© 2025 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 6
よし!環境分離もできたし、運用頑張っていくぞ!!
© 2025 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 3ヶ月後。。。
© 2025 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 8
実際の環境の使われ方 やりたかったことが全く達成されない地獄のような開発フロー https://docs.databricks.com/aws/en/machine-learning/mlops/mlops-stacks ✓ 開発環境(想定内) * 機能の開発 & 軽い動作確認 ➢ 使われない検証環境(想定外) * 「devで動作確認したので大丈夫です」 ➢ バグが発生しまくる本番環境 (想定外 and ヤバい) * 正常性を担保するため、ジョブ実行 とダッシュボードを目検で確認 & slackにスクショ掲載(ツラい) *問題が発生すればhotfixで直す ➢ 無駄に煩雑なデプロイ手順 * 検証環境なんて使われてないのに、 なんでstg用のconfig書き換えて stgブランチにPR出すんだ...
© 2025 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 9
モヤつきを言語化できないまま約6ヶ月運用を続け、 結局そのまま運用を別担当に引き継いでしまった...
© 2025 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 10
一体何が悪かったんだろう…
© 2025 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 11
PJ離脱から半年、 当時の状況を改めて整理して一つの結論にたどり着いた
© 2025 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 12
それは…
© 2025 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 13
https://docs.databricks.com/aws/en/machine-learning/mlops/mlops-stacks ✓ 開発環境(想定内) 機能の開発 & 軽い動作確認 ➢ 無駄に煩雑なデプロイ手順 * 検証環境なんて使われてないのに、 なんでstg用のconfig書き換えて stgブランチにPR出すんだ... ➢ バグが発生しまくる本番環境 (想定外 and ヤバい) * 正常性を担保するため、ジョブ実行 とダッシュボードを目検で確認 & slackにスクショ掲載(ツラい) *問題が発生すればhotfixで直す ➢ 使われない検証環境(想定外) * 「devで(新規機能の)動作確認を したので大丈夫です」 大体こいつが悪い
© 2025 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 14
どういうこと? 新規機能の動作確認のみを実施し、既存機能や後続ジョブの正常確認はやったりやらなかったり… → 検証環境にて疎通確認することで防げたインシデントがたくさんあった 既存機能や後続ジョブの動作確認が、必須確認項目に 入っていない 要件が決まってからデプロイするまでのフローチャート 検証環境で「後続のジョブまで一度全部通す」というフローを 毎回通っていれば、たくさんのインシデントが防げたはず
© 2025 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 15
どうしてこんなことに? 運用開始前の解像度の低さと、運用整備の仕組みづくりに工数を割けなかったのが主な原因 どういう経緯で こうなったのか どうして 改善されなかったのか 運用設計が甘かった 「環境分離をしよう!」という方針はあったが、具体的な運用ルールやデプロイフローが定義されていなかった 誤った成功体験 本番環境でバグが出たけどhotfixでリカバリができたので、「最悪hotfixでなんとかなる」という誤った成功体験が積み重なってしまった 運用整備の優先度が低かった 顧客要望度の高い新規機能開発が優先され、運用ルールの整備にまで手が回らなかった 場当たり(かつ手間がかかる)対応が定着してしまった 「とりあえず目検+Slackにスクショ貼り付けで故障率下がってそうだし、今はそれで十分」という暗黙の了解のもと、既存フローが定着してしまった
© 2025 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 16
こうすればよかったんじゃないか? 初期設定と改善をサボらない どういう経緯で こうなったのか どうして 改善されなかったのか 運用設計が甘かった 「環境分離をしよう!」という方針はあったが、具体的な運用ルールやデプロイ手順が定義されていなかった → デプロイ・確認手順を最初に明文化しておくべきだった 誤った成功体験 本番でバグが出たけど、hotfixでリカバリができたので、「最悪hotfixでなんとかなる」という誤った成功体験が積み重なってしまった → hotfix対応が発生する度に、原因と再発防止の仕組みを考えるべきだった 運用整備の優先度が低かった 顧客要望度の高い新規機能開発が優先され、運用ルールの整備にまで手が回らなかった → 「品質維持のための整備作業」にも開発リソースを割り当てる運用計画にすべきだった 場当たり(かつ手間がかかる)対応が定着してしまった 「とりあえず目検+Slackにスクショ貼り付けで故障率下がってそうだし、今はそれで十分」という暗黙の了解のもと、既存フローが定着してしまった → 目検運用は一時的と定義して代替策を用意すべきだった
© 2025 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. ご清聴ありがとうございました