翌週の出荷量を予測して物流センターの日別の必要人員を決める

処理の起点を決める

水曜の処理は、前日までの実績が取り込まれたことを確認してから始めます。 途中の日が欠けると、前後の値から補われた件数で学習されます。

入力データを集める

天気は入れません（理由は前処理）。

データの取得方法を決める

実績： WMSから毎晩CSVで出し、Python から BigQuery の表へ読み込みます。販促予定： 荷主には専用の共有アドレスへ送ってもらいます。メールの取得方法は環境によって違うため個別に決めます。

生産性： 作業実績から、工程別・荷主別の「1人時あたりの処理件数」を直近8週の中央値で出し、毎週更新します。平均でなく中央値にするのは、障害の日などの極端な値を避けるためです。

祝日： HOLIDAY_REGION = 'JP' で日本の祝日の効果を扱います。含まれる日は公開テーブル bigquery-public-data.ml_datasets.holidays_and_events_for_forecasting で確認でき、足りない休みは custom_holiday で追加できます（日次データの場合）。

AIへ渡す前に整形する

1. 「暦日×拠点×荷主」の表にする … 予測する数値は、稼働日の出荷件数ではなく暦日ごとの受信件数にします。土日祝も注文は届くので行が欠けません。このモデルは欠けた日を前後から直線で補うため、出荷休みの行を抜くと、実在しない出荷があった日として学習されます
2. 販促の列を作る … 人が確認した予定から、promo_flag（施策がある日は1）、promo_scale（記載された倍率から1を引いた値）、preorder_ship（予約商品の一斉出荷日）を作ります
3. 空欄を0で埋める … 特徴量の空欄は列全体の平均で埋められ、ほかの荷主の値が混ざります。施策のない日は必ず0にします
4. 予測時点で値が分からない要因は入れない … このモデルは予測する日の特徴量の値を渡して予測します。10日後の天気は分からないので、人の補正に回します
5. 期間と外れ値を整える … 直近2〜3年分で足りるとされているため学習は直近3年までにし、棚卸日や障害の日は生産性の計算から外します

AIに処理させる

出荷件数を生成AIに予測させないでください。 時系列モデルは予測値と予測区間を返し、内訳も確認できます。生成AIに件数を聞くと、根拠を確かめられない数値が計画に入ります。

ML.FORECAST の予測値は予測区間の上限と下限の平均で、区間の広さは confidence_level（既定0.95）で決まります。人員計画では0.8から始め、第8章で実績が区間の外に出た割合を見て調整します。 ML.EXPLAIN_FORECAST は、予測を傾向・週の季節性・祝日の効果・特徴量ごとの寄与（重み×値）に分けて返します。説明文の材料はこの数値です。

換算と人数は次の式で計算します。生産性は荷主ごとに違うため、荷主別に人時を出してから合計します。

稼働日Dの出荷件数 ＝ 前の稼働日の締め後の受信 ＋ 間の出荷休みの日の受信 ＋ D日の締めまでの受信
  （締め前後の割合は、荷主別・曜日別の直近8週の実績から出す）
必要人時（工程ごと）＝ 予測出荷件数 ÷ 1人時あたりの処理件数
必要人数（工程ごと）＝ 必要人時 ÷ 1人あたりの実働時間（切り上げ）

計算例です（実働7.5時間）。予測値9,600件なら、ピッキング（150件／人時）は64.0人時で9人、梱包（110件／人時）は87.3人時で12人、出荷（400件／人時）は24.0人時で4人、合わせて25人です。上限11,200件では28人、下限8,300件では22人です。この3通りを人に渡します。

指示内容を固定する

荷主から届いた販促・セールの連絡から、出荷の予測に使う項目を取り出してください。

【厳守事項】
- 本文に書かれていることだけを取り出してください。
- 期間、対象、見込み規模のうち、書かれていない項目は null にしてください。
  「例年並み」「大型」などの表現から数値を推測しないでください。
- 規模に数値（「通常の2倍」など）がある場合だけ、scale_value に倍率を入れてください。
- 年のない日付は受信日より後で最も近い日とし、year_inferred を true にしてください。
- 施策が複数あれば分け、根拠の原文を source_quote に引用してください。

【荷主コード】{shipper_id}　【受信日】{received_date}　【本文】{mail_body}

「表現から数値を推測しない」の1行が重要です。 「大型セール」に生成AIが「2倍程度」と補うと、その倍率がそのまま予測に入ります。説明文の指示では、「与えられた数値だけを使う」「理由は内訳に数値がある項目からだけ書き、天候など内訳にない理由を書かない」「人数の増減の判断を書かない」を守らせます。

出力形式を固定する

{"shipper_id": "S03",
 "campaigns": [
   {"type": "sale | coupon | free_shipping | preorder_ship | other",
    "start_date": "2026-09-24", "end_date": "2026-09-27",
    "year_inferred": false, "target": "秋物アウター全品",
    "scale_value": 2.0, "source_quote": ""}
 ]}

Gemini API の構造化出力では、選択肢（enum）、日付の形式、null を許す型、数値の最小・最大を指定できます。ただし公式ドキュメントも、値の妥当性はアプリ側で検証するよう求めています。 開始日が終了日より後といった値は、プログラムで弾いて人へ回します。

システムへ連携する

Python から BigQuery へSQLを送り（client.query_and_wait()）、モデルを作り直して予測を受け取ります。

CREATE OR REPLACE MODEL `wh.orders_xreg`
OPTIONS (MODEL_TYPE = 'ARIMA_PLUS_XREG', TIME_SERIES_TIMESTAMP_COL = 'order_date',
  TIME_SERIES_DATA_COL = 'orders', TIME_SERIES_ID_COL = ['site_id', 'shipper_id'],
  DATA_FREQUENCY = 'DAILY', HOLIDAY_REGION = 'JP', HORIZON = 14) AS
SELECT order_date, site_id, shipper_id, orders, promo_flag, promo_scale, preorder_ship
FROM `wh.daily_orders` WHERE order_date >= DATE '2023-09-09';

SELECT * FROM ML.FORECAST(MODEL `wh.orders_xreg`,
  STRUCT(14 AS horizon, 0.8 AS confidence_level),
  (SELECT * FROM `wh.future_promo`));  -- 予測する日の販促の列を渡す

予測は CREATE MODEL の実行時に行われ、ML.FORECAST は結果を取り出すだけです。 人員計画表には、日付・拠点・工程ごとに予測件数と3通りの人数、説明文、注意（未確認の販促など）を書き出します。派遣発注数の欄は空欄にし、計画担当が記入します。

人が確認する

人が行うのは3つです。運用が安定しても変えません。

1. 販促情報の確認 … 原文と見比べ、規模が null の施策は荷主に問い合わせます。確認前の情報は予測に使いません
2. 人数の決定 … 3通りの人数に、天候や社員の応援の余力を加味して決めます
3. 派遣発注数の確定 … 発注は契約と費用が伴い、来てもらう人の予定にも関わります。自動で確定させたり、派遣会社へ自動で送ったりしないでください

幅の使い方は先に決めます。例：「派遣は予測値で発注し、上限との差は社員の応援で吸収する。大型セールの初日だけは上限で発注する」。ルールを決めずに幅だけ渡すと、担当者ごとに判断が割れ、属人化が戻ります。

例外に対処する

記録を残す

• モデルを作り直した日時と学習期間、予測値・上限・下限
• 取り出した販促情報と、人が直した内容
• 決めた人数、補正の理由、派遣の発注数
• 実績の出荷件数と、実績から逆算した必要人数（実績件数 ÷ 生産性）

最後の項目がこの構成の中心です。 発注した人数との差を日別に残すと、人が余った日・足りなかった日が数字で分かります。