加工機ごとの切削工具の使用記録から交換時期を見込み、翌週に交換が要る工具と在庫の手配の一覧を毎週作る

処理の起点を決める

トリガーは2本に分けます。 1本は毎日夜に動く読み分け、もう1本は金曜の朝に動く集計です。

読み分けは ClockTriggerBuilder の everyDays(1) と atHour(22) で組みます。atHour() を使うときは everyDays() などの頻度の指定が要り、実行は指定の時刻のあたりで少しずれます。 夜のうちに終わればよい処理なので、ずれは問題になりません。

集計は everyWeeks(1) と onWeekDay(ScriptApp.WeekDay.FRIDAY)、atHour(7) です。金曜の朝にしているのは、その日の午後に班長が一覧を見て、夕方までに購買課が発注できるようにするためです。 金曜の夕方に作ると、発注が翌週に回ります。

集計を読み分けと同じトリガーにまとめないでください。 1回の実行は6分までで、30台分の集計に読み分けまで載せると、交換の記録が多かった週だけ途中で止まります。 止まった週にかぎって一覧が出ない、という壊れ方は気づきにくいものです。

入力データを集める

質を決めるのは、3つ目の工具の一覧です。 日報にあるのは「どの部品を何個加工したか」で、どの工具を何回使ったかではありません。 部品の品番から工具を引く対応表が無ければ、加工数を工具に割り振れません。

被削材の区分は、寿命を分けて数えるための列です。 同じエンドミルでも、炭素鋼とステンレスでは寿命がまったく違います。区分を持たずにまとめて計算すると、ステンレスの多い機械だけ交換が遅れます。 区分は「炭素鋼／合金鋼／ステンレス／アルミ／鋳鉄」くらいの粗さで足ります。

交換の記録の「理由」は、自由記述のままにします。 選択式にすると記録は楽になりますが、「欠けたが、加工数はほぼ寿命だった」のような中間の事情が消えます。 読み分けはAIにさせるので、書き手には思ったとおり書いてもらいます。

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

すべて同じスプレッドシートの中にあるので、SpreadsheetApp で読むだけです。読み分けは「まだ印の無い交換の記録」だけを対象にします。 印を付けた行は二度と読まないので、毎晩の件数は、その日に入った交換の数（1日に数件〜十数件）で済みます。

寿命1件は「前回の交換から今回の交換までの加工数」です。 交換の記録に加工数を書かせるのではなく、日報から足し上げて出します。 作業者に加工数を書かせると、数え方が人によって変わります。

Gemini API は UrlFetchApp.fetch() で呼びます。 method を post、contentType を application/json、headers にAPIキーを入れ、muteHttpExceptions を true にして、失敗したときも応答の中身を読めるようにします。APIキーはスクリプト プロパティに置きます。 スクリプト プロパティはそのスクリプトのすべての利用者で共有されるので、スクリプトの編集権限は製造課の管理者だけにします。

AIへ渡す前に整形する

1. 機械と工具番号の表記をそろえる … 「MC-03」「MC3」「3号機」を工具の一覧の表記に寄せる。寄せられないものは読み分けに回さず、unmatched にする
2. 同じ交換の二重の記録をまとめる … 同じ機械・工具番号で10分以内に2件あれば、後の1件を重複として印を付ける
3. 前回の交換の無い工具を分ける … 記録を始めて最初の交換は、起点が無いので寿命として数えない
4. 加工数を工具に割り振る … 日報の部品の品番から工具の一覧を引き、その工具の累計に足す
5. 被削材の区分を付ける … 工具の一覧の区分を、寿命1件ごとに写す
6. 理由のメモの前後の空白と改行を落とす … 内容は変えない

3番目を飛ばすと、寿命が極端に長い1件が混ざります。 記録を始める前から使っていた工具は、本当は何個加工したかが分かりません。 起点の無い1件目は、母数から外すと最初に決めておきます。

AIに処理させる

させるのは、交換の記録1件ごとに、理由のメモを読んで「寿命の母数に入れるか」の印を付けることだけです。

breakage を入れないのは、欠けは寿命とは別の原因で起きるからです。 折れた工具の加工数を寿命として数えると、中央値が下がり、まだ使える工具まで早めに替えることになります。 欠けの件数は別に数え、多い品番は加工の条件を見直す材料にします。

preventive も入れません。 連休前に替えた工具は、寿命に達する前に外しています。入れると寿命が短く出て、予防で替えるほど次の予防が早まるという回り方になります。

1行目が、この構成の線引きです。 AIは読み分けだけ、数字は Apps Script です。見込みが外れたときに、どの記録をどう数えたかを後から追えるのは、計算が式で書かれているからです。

指示内容を固定する

あなたは機械加工の工場で、切削工具の交換の記録を整理する担当です。
交換の記録1件ごとに、理由のメモを読み、交換の理由の区分を1つ選んでください。
寿命の計算はしないでください。区分を選ぶだけです。

【区分】
- wear_life ...... 摩耗で替えた。加工面が荒れた、寸法が外れた、バリが出た、
                   音や振動が変わった、刃先が丸くなった など
- breakage ....... 欠けた、折れた、チッピングした
- setup_change ... 段取り替え・品番の切り替えで外した
- trial .......... 新しい工具・新しい切削条件を試すために替えた
- preventive ..... まだ使えるが、連休前・長時間の無人運転前などに予防で替えた
- unclear ........ メモから理由が読み取れない

【厳守事項】
- メモに書かれていることだけで選んでください。書かれていない理由を推測しないでください。
- 「交換」「新品」「替えた」とだけ書かれ、理由が無い場合は unclear にしてください。
  wear_life を選ばないでください。
- 摩耗と欠けの両方が書かれている場合は breakage にし、note にその旨を書いてください。
- 「予定どおり」「定期」とだけ書かれている場合は preventive にしてください。
- evidence には、区分を選ぶ根拠にしたメモの文字列をそのまま写してください。
- 加工数・寿命・交換の時期について、何も書かないでください。
- 区分に迷った場合は unclear を選んでください。迷ったときに wear_life を選ばないでください。

【交換の記録】
{records}
（1件ごとに record_id、機械、工具番号、工具の品番、理由のメモ）

「理由が無い場合に wear_life を選ばない」を明記しないと、ほとんどが wear_life になります。 工具の交換の大半は摩耗なので、何も言わなければ多いほうに寄せます。寄せた1件ずつは当たっていることが多くても、外れた1件が寿命の母数に入ります。

「寿命の計算をしない」を冒頭と末尾の2か所に書いているのは、記録に加工数の数字が書かれていることがあるからです。 数字があると、AIは寿命を言い当てようとします。

出力形式を固定する

次の形のJSONで受け取ります。 スキーマは response_format の schema に渡し、label は enum で6つに限ります。

{
  "results": [
    {
      "record_id": "R-2026-10-07-014",
      "label": "wear_life | breakage | setup_change | trial | preventive | unclear",
      "evidence": "仕上げ面にむしれ、寸法+0.02",
      "note": ""
    }
  ]
}

JSONで受ける1つ目の理由は、印をそのまま交換の記録のシートの列に書き戻せることです。 label は寿命の計算の絞り込みにそのまま使い、evidence は班長が印を直すときの根拠として同じ行に残します。

2つ目は、enum で印の種類を固定できることです。 自由文で返すと「摩耗（軽度）」「摩耗のため」のような書き方の揺れが出て、絞り込みから漏れます。

金曜の集計は、Apps Script が次の2つの一覧をシートに書き出します。

下側の値を使うのは、中央値で見込むと半分の工具が見込みより先に寿命になるからです。 どこを下側とするか（下から4分の1、など）は、欠けが出たときの損失の大きさで工場ごとに決めます。

システムへ連携する

在庫表と発注の仕組みには書き込みません。 手配の候補は別のタブに出すだけで、発注の数を決めて在庫表の「発注中」を更新するのは購買課です。 書き込みを足すと、見込みの外れがそのまま発注になります。

一覧はメールに本文で貼らず、シートへのリンクだけを送ります。 班長が「班長の判断」の列を埋め、購買課がそれを見て発注する、という流れを同じシートの上で完結させるためです。

人が確認する

1. 班長が交換予定の一覧を見る … 翌週の加工の予定と照らし、替える・見送る・前倒しを入れます。新しい品番、被削材が変わる加工、無人運転の長い日は、見込みより早めに替える側に寄せます
2. 根拠の弱い工具を先に見る … few_samples と wide_spread の付いた工具は、見込みの数字よりも班長の経験を優先します
3. unclear の交換の記録を片づける … 書いた作業者に理由を聞いて、印を付け直します。週に数件のうちに片づけないと、母数の外にたまり続けます
4. 購買課が手配の候補を見る … 納期に間に合わない品番は、代替の品番か、他の機械からの融通を班長と相談します

目標は、1台5分です。 一覧を上から見て、判断の列を埋めるだけで済む状態にします。5分で終わらない週は、few_samples が多いか、工具の一覧が古くなっています。

例外に対処する

上の3行が、運用で毎週出るものです。 どれもAIの誤りではなく、工具の一覧と交換の記録の書き方の問題です。 判定の精度を上げるより、工具の一覧を最新に保つほうが見込みは当たります。

失敗した実行は、「Summary of failures for Apps Script」という件名のメールで知らされます。 宛先はトリガーを作ったアカウントなので、そのアカウントのメールを製造課の誰かが読むようにしておきます。

記録を残す

• 交換の記録の各行に、読み分けの印（label）と根拠（evidence）、印を付けた日時と、人が直したかどうか
• 金曜ごとの交換予定の一覧と手配の候補（タブを週ごとに残す）
• 班長の判断の列（替える／見送る／前倒し）と、実際に替えた日
• 見込みの「あと何日」と、実際の交換までの日数の差
• 使った寿命の母数の件数と、中央値・下側の値（品番・被削材ごと）

4つ目が、この構成を育てる記録です。 見込みより早く替えた工具が多い品番は、下側の値の取り方が甘いか、母数にまだ欠けがまざっています。3か月分たまると、どの品番の見込みが当てにならないかが分かります。

1つ目の「人が直したかどうか」も消さずに残します。 班長が unclear を wear_life に直した件数が多い週は、指示の書き方より、作業者のメモの書き方に手を入れる時期です。どちらを直すかを、この記録で決めます。