モデルを「出す」ことをゴールにしない — 運用後に牙を剥くデータドリフトの話 | コラム

PoCが成功しても、本番化には時間がかかる

「PoCでは高い精度が出た。なのに本番化になぜか時間がかかる」——このギャップに心当たりのある方は多いのではないでしょうか。

原因はさまざまですが、私たちが実際に手を焼いたのは、運用してみないと分からないデータ分布のskew（偏り） でした。季節性のあるユーザー行動を予測するプロダクトでの話です。

このプロジェクトでは、Click RateやCV Rateといった予測対象そのものに季節ごとの変化がありました。加えて、流入してくるユーザーの属性自体も季節によって変化するのではないか、という仮説を持っていました。

厄介なのは、こうした揺れは短期間のPoCデータだけを見ていても気づきにくいということです。特定の季節だけモデルが「当てやすくなる」「当てにくくなる」という現象は、実際に運用期間をまたいでみて初めて輪郭がはっきりします。

幸い、このプロジェクトではPoCの時点で時系列を加味したEDA（探索的データ分析）を行い、季節によって予測精度に差が出ることを事前に確認できていました。

ここで重要だったのは、「精度の出るモデルを1つ出して終わり」にしなかったことです。PoCの結果を見た時点で、「これは運用後も継続的に監視し、学習し続ける仕組みが必要だ」という方向に設計を切り替えました。

季節変動という仮説は、データを眺めているだけでは確信が持てません。そこで現場のドメイン知識を持つ方に「そうした季節性の影響は実際にあり得るか」を確認しました。

結果、現場側でも同様の感覚があることが分かり、ドメイン知識をデータからも検証するというプロセスを踏むことになりました。この、データサイドの仮説と現場の肌感覚をすり合わせる工程が、後の特徴量設計に直結することになります。

実際に運用に入れた仕組みは、大きく4つです。

いきなり全自動を目指さず、手動→自動という段階を踏んだのは、運用の実感を積んでから仕組みを固めるためでした。

PoC開始から、自動再学習まで含めた運用が安定するまでには、おおよそ3〜6ヶ月かかりました。この期間を短いと見るか長いと見るかは立場によりますが、「モデルを1つ出して終わり」の感覚でスケジュールを引いていたら、確実に見誤っていた期間です。

もしPoC段階の自分にアドバイスできるなら、こう伝えます。

まず、現場でドメイン知識を持つ方に、季節性や流入データの傾向変化について早い段階でインタビューすること。 そこから「判断の軸として重要なデータ（特徴量）は何か」を洗い出しておくべきだった、と。

データだけを見て仮説を立てるよりも先に、現場の知見を起点に検証すべき変数の当たりをつけておく。それだけで、PoCの設計そのものがもっと筋の良いものになっていたはずです。

PoCのゴールは「精度の出るモデルを出すこと」ではありません。運用後も学び続けられる仕組みを設計することが、本当のゴールです。

データ分布のskewは、多くの場合、運用してみるまで正体を現しません。だからこそ、PoCの時点で「運用後に何が変わりうるか」を先回りして問い、現場の知見と照らし合わせておくことが、本番化までの時間を大きく左右します。