AIモデル・需要予測

MistralのTimestral。需要予測の「幅」を、発注判断にどう使うか

株式会社本質 · 2026.10.16 · 約5分

来週は100個売れる。そう予測されても、100個を仕入れればよいとは限りません。売り切れたら翌日に補充できる商品と、次の入荷まで2週間かかる商品では、決め方が変わります。

10月15日、Mistralが時系列予測モデル「Timestral」を公開しました。時間順に並んだ数値から先を予測するモデルで、需要や設備の状態などを対象にしています。公式発表

今回、本質が注目したのは、予測を一つの数字で返して終わらない点です。モデルが見込む下振れと上振れを、担当者の発注判断へどう渡すか。そこまで考えると、試すべき仕事が絞れます。

同じ100個でも、備え方は変わる

Timestralは、予測される値の分布を21の分位点で出力します。分位点は、モデルが見込む分布を小さい値から順に区切った目安です。中央の予測に加え、低め・高めの需要を見比べられます。過去の数値だけでなく、あらかじめ分かっている将来の条件も入力できます。モデルカード

ここからは、発注業務を想定した本質の仮の例です。Timestralで実測した数字ではありません。

週単位の販売数を予測する例として、ある商品の来週の予測が、中央値では100個だったとします。同じ分位点で見た低め・高めの目安が90〜110個なのか、60〜150個なのか。中央の数字は同じでも、後者では仕入れを一度に決める前に、追加発注できる日や納品までの日数を確かめたくなります。

予測が広く散らばるなら、最初の発注を抑えて途中で追加できるようにする。補充が間に合わない商品なら、欠品したときに失う売上と、余ったときの保管・廃棄を比較する。どちらも、予測モデルだけでは決まらない仕事です。

また、「幅が出た」こと自体は、信頼できる確率が得られた証明にはなりません。高めの目安を実績が頻繁に超えるなら、その目安を発注の根拠にするには見直しが必要です。図が精密に見えるほど、実際にどれくらい外れるのかを先に確かめたいところです。

本質なら、まず一つの商品群で、過去の発注日まで時計を戻した比較を提案します。その時点で手に入っていた情報だけで予測し、実際の販売数や欠品、余剰と照らし合わせます。

予定されていたセールや休業日は使えても、後から分かった売上や、当日になって確定した条件を混ぜると、当時はできなかった判断まで正解に見えてしまいます。Timestralの公開実装でも、過去だけで分かる情報と、予測する期間まで既知の情報を分けて渡す設計です。公開リポジトリ

比較相手は、いま担当者が使っている方法にします。前週の同じ曜日の販売数、直近の平均、既存の発注ルールなどです。同じ期間・同じ情報で比べ、予測誤差が小さくなったかに加え、発注を変えたら欠品や余剰がどう動くかを見ます。

ここで、販売数をそのまま需要と扱ってよいかも確認します。在庫が切れて売れなかった日は、記録された販売数だけでは、本当は何個欲しかったのか分かりません。欠品日を見分けずに学習や評価へ入れると、売れなかった理由を取り違えるおそれがあります。

担当者に渡す画面も、予測グラフだけで終わらせません。「次の補充日まで足りる見込みか」「高めの需要に備えたうえで、低めの需要にとどまったら何個余るか」を、現在庫や入荷予定と一緒に見られる形にする。実務で使えるかは、この比較ができるかで変わります。

公開実装はCPUとGPUで推論でき、モデルには複数のサイズがあります。自社の数値データで動かすためのコードと重みが提供されています。ただし、これは完成済みの発注アプリではありません。データの整形や、現在庫・入荷予定との接続は別に用意します。実行方法

利用条件も、コードとモデルの重みで異なります。コードはApache 2.0、重みはModified MITです。重みのライセンスには会社や雇用主の売上規模に関する制限があるため、通常のMITと同じ条件だと見なさず、利用主体と原文を確認してください。重みのライセンス

本質では、今回のモデルを自社データで検証していません。どの商品で精度が上がるか、発注の手間や損失が減るかは、まだ分かりません。

試す入口としては、欠品と余剰の両方を記録でき、発注を変えた結果を追える商品群が向いています。モデルの順位から導入先を決めるより、「次の発注で、どの判断を良くしたいか」を一つ決める。その問いがあれば、新しい予測モデルを試す意味もはっきりします。

予測の出力を実際の業務判断につなげる設計や、既存データとの接続は、本質のAI・システム開発支援でもご相談いただけます。

本記事は2026年10月16日に確認した一次資料の要約と、本質の活用提案です。