AIエージェントより地味なMLが今おもしろい。数理最適化と時系列予測の話

「次のプロジェクト、エージェント系で」

今年に入って、この言葉を何回聞いただろう。要件を聞くと、タスク分解して、ツール呼んで、ループして。構造は毎回だいたい同じだ。

正直、飽きた。

しかも困るのが、「実際どう実装したか」の話になると、急に語れる人がいなくなることだ。テーマは溢れてる、実装知見は少ない。仕事でそれを痛感してから、逆に気になり始めたのが数理最適化と時系列予測だった。

LLMが”使えない”問題、改めて見えてきた

在庫の発注量を決める。配送ルートを組む。需要の波に合わせて人員を配置する。

これにLLMを突っ込んでも、答えは出ない。というか、出ても検証できない。「なぜその数字なのか」を説明できないまま本番に入れるのは、現場的にアウトだ。

エージェントを一周した人たちが、静かに数理最適化や時系列モデルに戻ってきてる。最近そう感じてる。そして正直、その方が話が深い。

半年前、需要予測モデルの精度改善を任された。LightGBMに特徴量を突っ込んで、検証データでRMSEが下がった。「よし」と思って本番に入れた。

翌月、GW前後の予測が壊滅した。

連休明けの需要を過小評価して、欠品が出た。残差を見ると一目瞭然で、祝日前後に外れが集中してた。「祝日ダミー入れてたのに」と思ったが、問題はそこじゃなかった。連休の長さによって需要の動き方が変わるのに、ダミー変数ではその差を拾えていなかった。

直し方も一度失敗した。連休日数を特徴量に追加したら、今度はモデルが「長い連休＝需要増」と過剰に学習して、次の連休で逆方向に外れた。需要が増えるカテゴリと減るカテゴリが混在してたのに、それを区別せず突っ込んでいたのが原因だった。

結局、カテゴリ別に残差のパターンを見直して、特徴量を再設計した。検証で「外れ方が説明できる状態」になるまで、2週間かかった。

別の案件で、配送コスト最小化をPuLPで実装した。制約条件を書いて、ソルバーを回して、解が出た。

動いたと思ったら、現場に「使えない」と言われた。

解は数学的に正しい。でも、現実の制約を落としていた。ドライバーの拘束時間、車両ごとの積載限界、得意先の受け入れ時間帯。これらを全部モデルに入れようとすると、制約が増えすぎて解が出なくなる。実行不能になる。

そこで考え方を変えた。「最適解」を出すのではなく、「現行より10%コストを削れる、現場が納得できる解」を出すことをゴールにした。制約を段階的に緩めて、ヒューリスティックと組み合わせた。完璧ではないけど、使われる解になった。

数理最適化で一番学んだのは、「解が出ること」と「使われること」は別問題だということだ。

実装してなくても書ける。それだけだと思う。

概念を整理して、サンプルコードを動かして、図を描けば記事になる。需要予測の「外れ方の分析」や最適化の「現場との摺り合わせ」は、実際にやらないと書けない。だから記事が少ない。

実装知見が薄いテーマは、時間が経つと淘汰される。今がその手前だと思う。

流行を追わなかった分野に、まだ書けることが残ってる。そして書ける人も、まだ少ない。