段ボール・ラベル・緩衝材などの包装資材の翌月の使用量を、生産計画と過去の使用実績から見込み、発注の時期と量の案を購買に渡す

処理の起点を決める

毎週月曜の朝に、Apps Script の時間主導型トリガーで動かします。 公式のページでは、時間主導型のトリガーは毎分から月1回までの間隔で設定でき、実行の時刻はわずかにずれることがある（9時と決めても9時台のどこかで動く）とされています。発注の案は朝のうちに見られれば足りるので、ずれは問題になりません。

月に1回ではなく、毎週動かすのには理由があります。 生産計画は月の途中で週に1〜2回変わり、印刷の入った段ボールの3〜4週間という調達期間は、月1回の見直しでは間に合わない変化を生みます。 毎週動かせば、計画が増えた週のうちに期限日が前に出たことが分かります。

動かす前に、生産計画のシートが貼り直されているかを確かめます。 生産計画のシートの更新日時が前回の実行より古ければ、計算はせずに担当者へ「計画が更新されていません」と知らせます。古い計画で発注の案を出すと、見た目は正しい案が、ずれた数字のまま購買に渡ります。

入力データを集める

質を決めるのは、原単位表の有効期間の列です。 荷姿が変わって1ケースの入数が12個から10個になると、同じ製品でも段ボールの使用数が変わります。原単位表に有効期間が無いと、過去の補正係数を古い原単位で計算してしまい、係数そのものが狂います。

計画変更の連絡のシートは、今回新しく作ります。 営業・品質保証・生産管理が、計画に影響する連絡を受けたら1行ずつ貼る場所です。メールの受信箱をそのまま読ませる形にしないのは、関係の無いメールが大半で、取引先の情報も混ざるためです。貼る人がいることで、AIに渡す範囲が決まります。

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

Apps Script は、生産計画・原単位表・在庫表・発注一覧・資材マスタのシートを getValues() でまとめて読みます。公式のページでは、getValues() は範囲の値を二次元の配列で返し、setValues() は範囲と同じ大きさの二次元の配列を書き込むとされています。読み書きはシートごとに1回ずつにして、計算は配列の上で行います。

翌々月の計画まで読むのは、調達期間の長い資材のためです。 印刷の入った段ボールは、翌月の分を今週発注しても間に合わないことがあり、翌々月の初めに使う分の期限日が、今月のうちに来ます。 翌々月の計画がまだ仮のものでも、仮のまま使い、案の側に「仮の計画に基づく」と印を付けます。

生成AIは UrlFetchApp.fetch で呼び、muteHttpExceptions を true にします。 公式のページでは、こうすると失敗の応答でも例外を投げずに中身を返すとされ、エラーの中身を記録に残せます。

AIへ渡す前に整形する

1. 計画の単位をそろえる … 生産計画がケースと個の混在で出る製品は、原単位表の単位（ケース）にそろえます
2. 原単位表の有効期間で引く … 生産日ごとに、その日に有効な原単位を使います。荷姿の変更の前後で別の行になります
3. 共用の資材をまとめる … 無地の段ボールやテープのように複数の製品が使う資材は、製品ごとの使用量を資材コードで足し上げます
4. 出庫実績の外れ値を除く … 棚卸の差の調整や、別の倉庫への移動として記録された出庫は、補正係数の計算から外します
5. 週ごとに分ける … 生産日をもとに、使用量を週ごとに分けます。在庫が割る日を週の単位で見るためです
6. 連絡の本文を絞る … 計画変更の連絡のうち、直近8週の分だけを渡します。署名や引用の部分は落とします
7. 資材の一覧を添える … 生成AIには、資材コードと名称、版の番号の一覧だけを添えます。在庫や仕入先は渡しません

4番目を省くと、補正係数が意味の無い数字になります。 帳簿を合わせるための調整の出庫を使用量として数えると、その資材は「いつも2倍使う」ことになり、翌月に2倍発注されます。 出庫先のラインの列が空の行を除く、といった決まりで外します。

補正係数の式は、単純にしておきます。 過去6か月の「実際の出庫量 ÷ 理論の使用量」を資材ごとに出し、1.00を下回る資材は1.00として扱います。 下回るのは、原単位表の誤りか出庫の記録漏れのどちらかで、見込みを減らす理由にはしません。こうした資材には「原単位を確かめる」の印を付けます。

AIに処理させる

させるのは、計画変更の連絡を読み、どの資材に、どの種類の変化が、いつから起きるかを書き出すことだけです。 使用量の計算も、補正係数も、期限日も、Apps Script の式で出します。

1行目と2行目が、AIを使う理由です。 連絡は「来月15日からAシリーズの表示が新しくなります」のように製品の呼び名で書かれ、資材コードはありません。 呼び名から段ボールとラベルを当てるのは、規則では書きにくい作業です。

3行目がいちばん起きやすい失敗です。 「来月から」を1日と書くと、Apps Script はその日から新版の使用量を数え、旧版の資材が半月分足りなくなります。 書かれていなければ date_unknown にして、担当者が送り主に確かめます。

指示内容を固定する

あなたは食品工場の生産管理の担当者で、包装資材の発注の案を作る前に、
計画変更の連絡を読んで、影響する資材を洗い出す立場です。
渡された連絡と資材の一覧だけを見て書き出してください。推測で埋めないでください。

【書き出すこと】
連絡1件ごとに、影響する資材ごとに次を書いてください。
- material_code：資材の一覧のコード。当てられなければ空にし、
  status を material_unknown にする
- change_type：version_change（版替え）／new_product（新製品）／
  promotion（販促の限定品）／pack_change（荷姿の変更）／
  discontinue（生産の中止）／other のどれか
- effective_date：連絡に書かれた切替日・開始日。YYYY-MM-DD で書く
- evidence：判断のもとにした連絡の一文を、そのまま写す

【厳守事項】
- 数量や使用量を書かないでください。連絡に数量が書かれていても、
  quantity_note に原文のまま写すだけにしてください。計算しないでください。
- 日付が「来月から」「月の半ばごろ」としか書かれていない場合は、
  effective_date を空にし、status を date_unknown にしてください。
  1日や15日に決めないでください。
- 製品名から資材を当てるときは、資材の一覧の名称に書かれた製品名と
  一致するものだけを当ててください。似た名前の資材に寄せないでください。
- 1つの連絡が複数の資材に関わる場合は、資材ごとに1行にしてください。
- 旧版の資材をいつまで使うか、発注を止めるべきかは書かないでください。
- 包装資材に関係の無い連絡は、change_type を other、
  status を not_related にしてください。

【予測が外れた資材】{deviated_materials}
上の資材について、連絡の中に関係しそうな記述があれば related_notes に
evidence を写してください。無ければ no_related_note としてください。

【資材の一覧】{material_list}
【計画変更の連絡】{notes}

「数量を書かない」を最初に置いているのは、連絡に数量が書かれていることが多いためです。 「販促品を5,000ケース追加」と書かれていると、AIは段ボールの枚数まで計算して返そうとします。原単位を知らないまま計算した数字は、式の答えと食い違い、どちらを信じるかで担当者が迷います。 数量は原文のまま写させ、計算は Apps Script に任せます。

出力形式を固定する

次の形のJSONで受け取ります。 Gemini API の構造化出力（response_format に mime_type: application/json と schema を渡す方式）を使い、形を固定します。

{
  "changes": [
    {
      "note_id": "",
      "material_code": "",
      "change_type": "version_change | new_product | promotion | pack_change | discontinue | other",
      "effective_date": "",
      "quantity_note": "",
      "status": "ok | material_unknown | date_unknown | not_related",
      "evidence": ""
    }
  ],
  "deviations": [
    { "material_code": "", "related_notes": [""], "status": "found | no_related_note" }
  ]
}

1つ目の理由は、Apps Script がそのまま使える形で受け取れることです。 material_code と change_type と effective_date がそろっていれば、版替えの日より後の旧版の使用量を0にし、新版の使用量をその日から数える、という処理を式で書けます。

2つ目は、印の付け方を規則で持てることです。 発注の案の各行には、次の印を付けます。

late は他の印より先に出します。 今発注しても間に合わない資材は、仕入先に納期を早められるか相談するか、生産の順番を入れ替えるかを、その日のうちに決める必要があります。 発注の案のシートでは、late の行を一番上に並べます。

公式のページでは、出力は構文として正しいJSONになるが、値の正しさはアプリケーションの側で確かめる必要があるとされています。material_code が資材の一覧に無いコードだったり、effective_date が日付として読めなかったりしたときは、その行を check_note にして、Apps Script の計算には使いません。

システムへ連携する

発注一覧と在庫表には、この構成から書き込みません。 書き込み先は発注の案のシートだけで、購買の発注一覧に行を足すのは、確かめが済んだ案を見た購買の担当者です。 見込みの誤りが、そのまま発注残として在庫の計算に入ることはありません。

人が確認する

生産管理の担当者が見るのは、印の付いた品目だけです。 印の無い品目は、一覧で品目数と発注の合計金額の目安を流し見ます。

1. late を先に見る … 購買と相談し、仕入先に納期を相談するか、生産の順番を入れ替えるかを決めます
2. version を見る … 旧版をいつまで使い、新版をいつから使うかを品質保証と確かめます。旧版の発注量は、切替日までの使用量に絞られているかを見ます
3. plan_change と check_note を見る … 連絡の evidence を読み、日付が分からないものは送り主に確かめます
4. factor_moved と check_bom を見る … 補正係数が動いた理由を、出庫の記録と原単位表で確かめます。原単位表の誤りなら、表のほうを直します
5. space を見る … 棚の上限を超える資材は、発注を2回に分けるか、仕入先に分納を頼みます
6. 案を確定する … 確かめた結果を案のシートに書き、購買へ渡します

目標は、160品目をならして1品目9分です。 印の無い品目は数十秒、late や version の付いた品目は他の部署とのやり取りで20〜30分かかります。

例外に対処する

いちばん上と2行目が、この構成の数字を守る行です。 計画が古いことも、原単位表に無い製品があることも、計算は止まらずに進んでしまい、もっともらしい数字が出ます。 止めるか、印を付けるかを決めておかないと、気づくのは包装ラインで箱が足りなくなったときです。

記録を残す

• 実行の日時、使った生産計画の版（貼った日時と貼った担当者）
• 資材ごとの理論の使用量、補正係数、見込んだ使用量、期限日、発注量の案、付いた印
• Gemini API に渡した連絡の範囲と、応答のJSONの全文
• 担当者が案を直した記録 … どの品目を、いくつからいくつに、なぜ直したか
• 購買が実際に発注した数量と日付（発注一覧から月末に写す）
• 翌月の実際の出庫量と、見込んだ使用量の差

4つ目と最後の行が、この構成を育てる材料です。 担当者がいつも同じ資材の量を増やしているなら、補正係数に入っていない使い方があります。どの資材の見込みが外れやすいかが、勘ではなく記録として残ります。