DatabricksとAmazon Quickで補充自動化

補充業務の難所は長く予測そのものにあったが、基盤モデルの登場でカタログ全体の需要を項目ごとの調整なしに予測できるようになり、ボトルネックは「良い予測」と「その予測に基づく発注」の間の断絶へ移った。予測は統制されたデータ基盤に、供給余力は別の運用フィードにあり、発注の担当者はどちらにもログインできない。AWSが示したのはこの断絶を埋める仕組みだ。

構成は4段階で、DatabricksのMany Model ForecastingがChronos-2を動かして7日需要を予測し、Genie Agentが急増SKUを洗い出し、Amazon QuickがS3 Tables上の供給余力と突き合わせて最安の供給元を選び、定型なら発注、賄えなければ人による確認チケットを起票する。予測・供給フィード・発注APIはそれぞれの系に置いたまま、商品キーで必要な時点だけ結合する設計で、ETLや同期ジョブを挟まない。Genieの質問は実行ごとにSQLを再生成するため、急増判定のクエリを固定して数値の下限を明示し、同じ問い合わせが同じ結果を返すようにしている点も運用上の要諦だ。

成否を分けるのは、単一サプライヤーが7日分の供給を賄えるかどうかという切り分けで、自動化できる定型案件と人に残す例外の境界がここに引かれる。予測モデルには下流が縛られておらず、より良い予測に差し替えても仕組み自体は陳腐化しにくいとみられる。実運用では自動発注の権限をどこまで広げるかが焦点になる。