給食センターの献立と残食量の記録から、翌月の献立の料理ごとの残食量を予測し、仕込みの予備分と献立の見直し案を出す

処理の起点を決める

毎月10日の夜に、翌月分をまとめて動かします。 栄養教諭が献立案を献立作成のソフトに入れ終える締め切りを9日にしておき、その翌日の夜に予測を出します。翌朝、見直し表がセンターの共有フォルダに置かれている状態にします。

献立の確定会議までに、見直しを1回はさめる日程にします。 予測が会議の当日に出ても、組み合わせを入れ替える時間がありません。10日に出して、15日ごろの会議で確定する流れが、献立の作り方に合います。

月の途中にもう1回、学校ごとの喫食数が固まった時点で動かし直します。 学校行事や学級閉鎖で喫食数が変わると、予備分の量（率ではなく量）が変わるためです。このとき、献立と予測の残食率は変えず、量だけを計算し直します。

学習のやり直しは、3か月に1回にします。 毎月学習し直すと、たまたま残食が多かった月に引っ張られます。新しい学期の初めに傾向が変わることが多いので、4月・9月・1月の前に学習し直すのが目安です。

入力データを集める

質を決めるのは、料理マスタです。 献立作成のソフトと記録表で料理名の付け方が揺れていると、同じ料理の過去の記録が拾えず、モデルは毎回「初めて出る料理」として予測します。 第3章の（a）の問題は、AIを入れても料理マスタが無ければそのまま残ります。

残食量は、学校ごと・料理ごとの重さです。 学級ごとの記録があっても、この構成には入れません。学級の単位まで下げると、少人数の学級では特定の児童・生徒の食べ方に近づくためです。

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

献立作成のソフトからは、献立を表の形（CSV）で書き出します。書き出しの列の並びは、ソフトの版が上がると変わることがあるので、列名で読み込みます。 残食量の記録表と喫食数の一覧は、スプレッドシートを決まった名前で書き出して、共有フォルダに置きます。

予測するのは残食量ではなく、残食率（残食量 ÷ 配缶量）です。 学校によって人数が10倍違うので、量のまま学習すると大きな学校の傾向に引っ張られます。率で学習し、量に戻すのは最後の段にします。 量に戻すときは、予測の残食率に、確定した喫食数から計算した配缶量を掛けます。喫食数が月の途中で変わっても、率の予測はそのまま使い回せます。 環境省の調査でも、残食率は「出席した人数分の学校給食の提供量に対する、食べられずに残された給食の量の割合」として扱われています。

AIへ渡す前に整形する

1. 料理名をそろえる … 献立と記録表の料理名を料理マスタの表記ゆれの一覧と照らし、料理コードを付けます。付かなかった料理名は一覧にして、栄養教諭がマスタに足します
2. 配缶量が0や空の行を外す … 記録の入れ忘れです。率が計算できないので学習に使いません
3. 残食量が配缶量を超える行を外す … 食缶の重さの引き忘れなど、量り方の誤りです
4. 行事の日に印を付ける … 遠足・運動会の当日と翌日、短縮授業の日は残食の出方が違うので、項目として渡します
5. 過去の残食率を項目にする … 同じ料理コードの前回の残食率、同じ学校での直近3回の平均。予測する日より前の記録だけから計算します
6. 組み合わせを項目にする … その日の主菜の調理法、汁物の有無、揚げ物の品数、デザートの有無
7. 季節と曜日を項目にする … 月、曜日、長期休みの明けから何日目か

5番目を間違えると、予測が実際より良く見えます。 平均を出すときに予測する日の記録まで混ぜると、答えを見ながら予測していることになります。学習のときも予測のときも、「その日より前」の記録だけで計算する関数を1つ作り、両方から同じものを呼びます。

4番目の行事の印は、人が入れる項目です。 予定表から自動で取れない学校が多いので、給食担当が月に1回、学校からの連絡をまとめて入れます。入れ忘れると、遠足の翌日の残食が「料理のせい」として学習されます。 過去2年分の行事の印は、学校の年間行事予定から最初に一度だけまとめて入れます。

AIに処理させる

させるのは、学校 × 日 × 料理ごとの残食率を、中央の値（0.5の分位点）と多めの値（0.8の分位点）で予測することです。 2つのモデルを別々に学習させます。

学習の検証は、時間の順を守って行います。 scikit-learn の TimeSeriesSplit は、時間の順に並んだデータを学習と検証に分ける仕組みで、公式のページによれば、ほかの交差検証の方法では未来のデータで学習して過去のデータで評価することになるため不適切とされています。k回目の分割では最初のk個の区間を学習に、k＋1個目を検証に使います。

検証の区間は1か月ずつにし、gap で学習の区間の最後を空けます。 gap は学習の区間の終わりから検証の前に除く件数です。翌月を予測する実際の使い方では、直近の数日の記録がまだ集計されていないので、その状態に合わせます。

3行目は、プログラムの側で下限を持たせます。 中央の値の予測が低くても、予備分の率は調理の責任者が決めた下限を下回らないようにします。予測が外れて足りなくなった日の損失は、残食が減った分よりはるかに大きいからです。

検証で見るのは、全体の当たり具合だけではありません。 料理の区分ごと、学校種（小学校・中学校）ごとに、中央の値と実績の差の平均を出します。主菜は当たるのに副菜は外れる、中学校だけ外れるといった偏りは、全体の数字では見えません。偏りが出た区分は、印を付けやすくする（wide の基準を下げる）ことで、人の目に回します。

多めの値（0.8）の当たり方も確かめます。 実績の残食率が多めの値を超えた日が、検証の区間のおよそ2割に収まっていれば、分位点の推定がおおむね働いています。5割を超えるようなら、多めの値が低すぎ、予備分を下げる規則が危うくなります。 その場合は規則を使わず、予測を参考の数字としてだけ出す段階に戻します。

指示内容を固定する

この構成は生成AIを使わないため、AIへの文章の指示はありません。代わりに、モデルの設定と、予測の後の規則をこの形で書いておきます。 担当が替わっても、何を決めてあるかが読めるようにするためです。

【モデルの設定】
- 目的の値: 残食率（残食量 ÷ 配缶量）。0〜1
- モデル: HistGradientBoostingRegressor
    中央の値 … loss="quantile", quantile=0.5
    多めの値 … loss="quantile", quantile=0.8
- カテゴリの項目: 料理の区分、主材料、調理法、味付けの系統、学校、曜日
  （データフレームの列の型を category にして渡す）
- 欠けた値: 初めて出る料理の「前回の残食率」は NaN のまま渡す。平均で埋めない
- 検証: TimeSeriesSplit（1か月ずつ、gap は直近の未集計の日数）

【予測の後の規則】
- 予備分の率の案 = 調理の責任者が決めた基準の率 −（基準の残食率 − 中央の値）× 係数
    ただし、料理の区分ごとの下限を下回らない
    多めの値が基準の残食率を超える料理は、予備分を下げない
- 印を付ける日:
    中央の値が、その料理の区分の過去の75パーセンタイルを超える
    または 予測の幅が 0.10 を超える
    または 初めて出る料理を含む
- 入れ替えの候補:
    印を付けた料理と同じ料理コードで、残食率が低かった過去の日を最大3つ
    その日の主菜・汁物・デザートを並べる
- 出さないもの: 1人分の量の変更、献立の差し替えの決定、学級ごとの数字

「平均で埋めない」を明記しているのは、埋めると初めて出る料理が平均的な料理として予測されるからです。 初めて出る料理こそ、人が見るべき日です。NaN のまま渡し、別の規則で必ず印を付けます。

係数と下限は、調理の責任者と決める値です。 最初は係数を小さくし、予備分の率がほとんど動かない状態から始めます。実績と比べて足りなくなった日が出ないことを確かめてから、少しずつ上げます。

出力形式を固定する

センターの共有フォルダに、次の2つの表を置きます。

【見直し表（1行＝センター × 日 × 料理）】

【学校別の表（1行＝学校 × 日 × 料理）】

{
  "date": "2026-11-12",
  "center": "第2センター",
  "school_code": "E07",
  "dish_code": "SD-0142",
  "dish_name": "ひじきの煮物",
  "served_kg_plan": 18.4,
  "waste_rate_p50": 0.21,
  "waste_rate_p80": 0.29,
  "past_count": 9,
  "flags": ["high"],
  "event": ""
}

1つ目の理由は、見るべき行が flag で決まることです。 栄養教諭は見直し表を flag で絞り込んで開き、空の行は流し見で終わります。全行を読む設計にしないことが、10分に収まる条件です。

2つ目は、past_count を出すことです。 同じ料理が過去に何回出たかで、予測をどこまで信じてよいかが変わります。9回なら参考になり、1回なら見当に近いということを、数字で示します。

3つ目は、センター全体と学校ごとを分けることです。 予備分は調理の段階で決めるのでセンター全体の値で足り、学校ごとの値は配缶の量を見直すときに使います。

システムへ連携する

献立作成のソフトへは書き込みません。 予備分の率の案は見直し表に出すだけで、確定した率を調理の指示書に写すのは調理の責任者です。プログラムが献立や指示書を直接変える経路を作らないことで、誤った予測がそのまま調理に届くことを防ぎます。

人が確認する

人が開くのは flag の付いた行だけです。 1センター1日分の献立で、印が付くのは1〜2品という想定です。

1. new_dish を先に見る … 初めて出る料理です。予測は参考にとどめ、似た料理の記録を栄養教諭が自分で確かめます
2. high を見る … 残食率が高く出た料理です。alt_days の過去の日の組み合わせを見て、入れ替えるかを決めます
3. wide を見る … 予測の幅が広い料理です。予備分の率を下げる案が出ていても、採るのは記録が増えてからにします
4. 決めたことを記録する … 予備分の率を案のとおりにしたか、組み合わせを入れ替えたか

例えば、ひじきの煮物に high が付いた日です。 alt_days に、同じ料理が残食率の低かった過去の日が3つ並び、そのうち2つは主菜がカレーではなく焼き魚の日だったと分かります。栄養教諭は、主菜を入れ替えるか、ひじきの煮物を別の日に移すかを、食材の発注の締め切りと栄養価の計算を見ながら決めます。表が示すのは手がかりまでです。

4番目を省かないでください。 案を採った日と採らなかった日を分けて記録しておかないと、翌月の実績が出たときに、予測が外れたのか、人が案を採らなかったのかが分かりません。

例外に対処する

上から2行目は、締め切りを守らせるための決まりです。 前月の献立のまま予測を出すと、見直し表がそれらしく見えるぶん、誤った表で確定会議が進みます。 出さないほうが安全です。

記録を残す

• 予測に使った献立案・残食量の記録・喫食数の書き出しの、そのときの版
• 学習したモデルの設定と、学習に使った期間、検証の結果（料理の区分ごとの外れ方）
• 見直し表と学校別の表の全行
• 人が決めたこと … 予備分の率を案のとおりにしたか、組み合わせを入れ替えたか
• 翌月の実績が入ったあとの、予測と実績の差（料理ごと）
• 料理マスタに足した料理名と、足した日

4つ目と5つ目を並べて持つのが、この構成のいちばんの成果物です。 案を採った日に残食が減ったのか、足りなくならなかったのかが、1年分たまると、ベテランの見当がどこまで正しかったかが数字で分かります。 異動があっても、その記録は残ります。