金型・治具の所在と寿命を追って、手配と補修の時期を出す

処理の起点を決める

毎月1日を起点にします。前月の生産実績が確定したタイミングです。

月次にする理由は、生産実績の確定を待つ必要があるためです。 日次で回しても、実績が未確定ならショット数が動きます。確定した数字で積み上げるほうが、台帳の累計が信頼できます。

ただし、月次だけでは足りない型があります。 月に10万ショット打つような主力の型は、1か月で状況が変わります。残ショットが直近3か月の平均月間ショット数を下回った型は、週次でも見る設計にしてください。貸与の動きがあったときも、臨時の起点にします。

再処理の入口も用意してください。 生産実績は後から訂正されます。累計に上書きし続ける作りにすると、訂正のたびに手で直すことになります。

入力データを集める

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

生産実績： ここが最初の関門です。実績は製品の単位で記録されています。型の単位ではありません。 必要なのは、使用した型番、生産数（良品）、不良数、工場・工程の4つです。不良数を外すと、打った回数を実際より少なく見積もります。

型番の列が実績に無い場合、そこから整えてください。 製品と型が1対1なら製品コードから引けますが、2つの型で作っている場合は、どちらで打ったかが分かりません。

取り数は台帳に持ちます。 ショット数への換算は次の形です。

ショット数 ＝ （良品数 ＋ 不良数） ÷ 取り数

多数個取りの型では、この割り算を落とすと桁が変わります。 4個取りの型で2万個作ったなら、打ったのは5,000ショットです。

金型台帳： この構成でいちばん整備が要るのがここです。次の列が揃っているかを確かめてください。

寿命ショット数の列が無い台帳が、いちばん多いパターンです。 型メーカーの仕様書と、過去に同種の型が何ショットで寿命を迎えたかから決めます。最初は種類ごとの標準値を置き、実績が溜まってから直してください。

貸与の記録： 紙の貸出票のままでは引き当てができません。型番・貸出先・貸出日・返却予定日・返却日・メモの6列を表にするところから始めてください。

返却日が空欄のまま数年経っている行が、必ず出てきます。 実際に返っているのに記録だけ落ちている場合と、本当に相手にある場合があります。この見分けは記録からはできません。

リードタイム： 購買部の発注実績から、種類ごとの標準日数を作ります。表面の補修・研磨なら14日、入れ子の交換なら45日、新規製作なら120日といった形です。社内の決裁に要する日数を、必ず別に足してください。発注日から数えると、決裁で止まっていた期間が抜けます。

AIへ渡す前に整形する

1. 実績の型単位への割り付け … 製品ごとの生産数を、使用した型へ割り付けます
2. ショット数への換算 … 良品数と不良数を足し、取り数で割ります
3. 累計への積み上げ … 型ごとの累計ショット数へ足し込みます
4. 残ショットの計算 … 寿命ショット数から累計を引きます
5. メンテの残ショットの計算 … メンテ周期から、前回メンテ以降の分を引きます
6. 直近3か月の平均稼働の算出 … 3か月分を合計し、3で割ります
7. 寿命到達見込み時期の算出 … 残ショットを月平均で割ります
8. 着手日の逆算 … 到達見込み日からリードタイムと決裁日数を引きます
9. 所在の引き当て … 台帳上の所在と、最後の貸出票の記録を並べます
10. 対象の絞り込み … 判断が要る型だけを抜き出します
11. 分割 … 工場・工程の単位に分けます

6から8が、この構成で「予測」と呼べる部分です。

月平均ショット数 ＝ 直近3か月のショット数の合計 ÷ 3
寿命到達までの月数 ＝ 残ショット数 ÷ 月平均ショット数
着手日 ＝ 寿命到達見込み日 － リードタイム日数 － 決裁に要する日数

当てはめます。寿命50万ショットの型で累計が44万2,000ショットなら、残ショットは5万8,000。直近3か月の合計が3万6,000ショットなら月平均は1万2,000で、寿命到達までは4.8か月です。新規製作の120日に決裁の30日を足した150日、およそ5.0か月を引くと、着手日はすでに過ぎていると分かります。残ショットだけ見れば「まだ5万8,000打てる」型ですが、月平均と突き合わせて初めて、今月動かなければ間に合わないと分かります。

季節性のある製品は、直近3か月では外れます。 夏に多く作る型を2月に見れば、月平均が低く出ます。前年の同じ時期を並べ、大きく違う場合は高いほうを採ります。この外挿は、この記事が設定する計算の手順です。 統計的な寿命分布の理論に基づくものではありません。

10の絞り込みの基準も決めてください。 残ショットが月平均の6か月分を下回った型、メンテの残ショットが1か月分を下回った型、貸出票の返却日が空欄のまま返却予定日を過ぎた型。この3つで、月150件前後になります。

11の分割は、出典に沿った設計上の要請です。 Gemini API の構造化出力には、非常に大きい、または深くネストされたスキーマは拒否されることがあるという制限があります。工場と工程の単位に分け、1回20件から30件で回してください。

AIに処理させる

数える仕事とAIの仕事を、はっきり分けます。

生成AIに任せるのは3つです。

（1）所在の食い違いの検出

台帳上の所在と、最後の貸出票の記録を突き合わせます。台帳は自社なのに貸出票の返却日が空欄なら食い違い、貸出票が見当たらなければ記録の欠落として示します。どちらかを正しいと決めさせないでください。 両方を載せ、区分を location_unknown にします。

（2）備考欄と手書きメモからの注意事項の抽出

「入れ子に微細なクラック、次回は交換」「この型は試作用で量産には使わない」。こうした記述は列になっておらず、機械では拾えません。

（3）区分と優先度の判定

計算結果と注意事項をもとに、5つの区分のどれかに振り分け、1から5の優先度を付け、理由を文章にします。

location_unknown を独立した区分に置くことが重要です。 残ショットが計算できていても、現物がどこにあるか分からなければ動けません。「余裕があるから ok」と混ぜると、この型は誰の目にも留まりません。

undetermined も必ず置いてください。 寿命ショット数が台帳に無い、取り数が分からない、実績に型番が無い。こうした型を無理に判定させると、根拠のない数字が出ます。

寿命の予測精度と、補修か作り直しかの判断は書かせません。 「95％の確度」「この型は作り直すべき」といった記述を禁じます。出せるのは「いつまでに決めるか」までです。

指示内容を固定する

あなたは樹脂成形メーカーの生産技術部で、金型と治具の管理を担当する者です。
今月の点検対象に上がった型について、区分と優先度を付け、理由を書いてください。

【厳守事項】
- ショット数、残ショット数、寿命到達の見込み時期、着手日は、
  計算済みの値として渡します。自分で計算し直さないでください。
- 台帳の記載と貸出票の記録が食い違う場合、どちらが正しいかを
  決めないでください。両方を出力し、区分は location_unknown に。
  所在が確認できない型を「紛失」「廃棄済み」と書かないでください。
- 補修するか作り直すかを判断しないでください。
  「作り直すべき」「補修で足りる」と書かないでください。
  書いてよいのは「いつまでに決める必要があるか」までです。
- 予測の精度や確率を書かないでください。
  「95％の確度で」「ほぼ確実に」と書かないでください。
- 台帳や貸出票に記載がない項目は、推測で補わないでください。
  「一般的にこの種類の型は」と書かないでください。
  記載がなければ「不明」としてください。
- 寿命ショット数、取り数、リードタイムのいずれかが渡されて
  いない場合は、区分を undetermined とし、notes に不足している
  項目を書いてください。仮定を置かないでください。
- notes は、備考欄・貸出票のメモ・保全の記録に
  実際に書かれている内容だけから書いてください。
- 理由の文章には、渡された数値を必ず含めてください。
  「残りが少ない」ではなく「残り58,000ショット、月平均12,000で
  4.8か月後」と書いてください。

【区分】ok（余裕あり）／maintenance_due（メンテ周期に到達）／
replace_soon（着手日が近い）／location_unknown（所在不明）／
undetermined（情報不足）

【優先度】5=着手日を過ぎている、または所在不明で生産予定あり／
4=今月中／3=3か月以内かメンテ到達／2=6か月以内／1=対応不要

【対象の型（計算済みの値）】
{tools_with_calculations}

【台帳の備考欄／貸与の記録と貸出票のメモ】
{ledger_notes}
{loan_records}

【保全・補修の履歴／生産予定】
{maintenance_history}
{production_plan}

「自分で計算し直さないでください」の指示が、この構成では最も重要です。 生成AIに数字を渡すと、検算のつもりで別の数字を出すことがあります。残ショットと着手日は集計側で確定させた値です。ここが動くと設計が崩れます。

「どちらが正しいかを決めない」も外せません。 台帳と貸出票が食い違ったとき、もっともらしいほうを選ばせると、現物の確認が行われないまま話が進みます。

「記載がなければ不明とする」は、台帳の穴を隠させないための歯止めです。 寿命ショット数が空欄の型に、生成AIは「この種類なら50万ショット程度」と埋めてきます。埋まると、台帳が整っていないことに誰も気づきません。

出力形式を固定する

型1点につき、次のスキーマで返させます。

{
  "type": "object",
  "properties": {
    "tool_id": { "type": "string" },
    "location": {
      "type": "object",
      "properties": {
        "ledger": { "type": "string" },
        "last_loan_record": { "type": ["string", "null"] },
        "conflict": { "type": "boolean" }
      }
    },
    "shots_used": { "type": "integer", "minimum": 0 },
    "shots_remaining": { "type": "integer" },
    "est_depletion_month": { "type": ["string", "null"], "format": "date" },
    "lead_time_days": { "type": "integer" },
    "action_by": { "type": ["string", "null"], "format": "date" },
    "status": {
      "type": "string",
      "enum": ["ok", "maintenance_due", "replace_soon",
               "location_unknown", "undetermined"]
    },
    "priority": { "type": "integer", "minimum": 1, "maximum": 5 },
    "notes": { "type": "array", "items": { "type": "string" } },
    "needs_human": {
      "type": "object",
      "properties": {
        "required": { "type": "boolean" },
        "reason": { "type": "string" }
      }
    }
  },
  "required": ["tool_id", "location", "status", "priority", "needs_human"],
  "additionalProperties": false
}

構造化する理由は、この出力が人の目で読まれる前に、機械で並べ替えられるためです。 150件を優先度の順に並べ、区分ごとに分けて生産技術と購買へ配ります。

status を enum で縛ることが、この設計の中心です。 Gemini API の構造化出力では、文字列の enum は分類タスク用に特定の可能な文字列セットを列挙するためのものとされています。5つの区分だけを列挙すれば、「要注意」「経過観察」といった区分が混ざりません。 priority の minimum と maximum は1から5の整数だけを、action_by の format: "date" は日付の構文だけを通します。「来月中」では購買部の予定に載りません。

location を入れ子にしているのは、食い違いを両方残すためです。 貸出票が見当たらない型のために、nullは {"type": ["string", "null"]} のようにtype配列に含める形で指定します。空文字で埋めると、記録が無いのか空欄なのか区別がつきません。

システムへ連携する

出力は一覧と通知として出すだけで、他のシステムへの書き込みは行いません。

購買システムへ発注を自動で起票しないでください。 金型の手配は金額が大きく、起票そのものが決裁の手続きの一部です。 外注先への連絡も自動にしないでください。「貴社に預けている型の所在を確認したい」が機械から飛ぶと、相手には催促や疑いとして受け取られます。

金型台帳への書き戻しは、累計ショット数の列に限ります。 区分や優先度を書き込むと、翌月の計算がその値に引きずられます。

人が確認する

確認は必ず残します。 この構成は判断をしません。

1つ目が最重要です。 所在が確認できない型は、寿命の計算がどれだけ正確でも動かせません。人が問い合わせて現物を確かめる必要があります。

確認を速くするための設計が効きます。

• location_unknown と replace_soon を一覧の上に固定する
• 理由の文章に、残ショットと月平均と到達月をそのまま載せる
• 着手日を過ぎている型に、過ぎた日数を並記する
• 台帳の記載と貸出票の記録を、左右に並べて表示する
• 現物確認の結果を書き込む欄を、一覧の右端に置く

5つ目が、翌月以降に効きます。 現物確認の結果を書き込めば、「協力会社のB社にあった」という情報が記録になり、翌月は location_unknown から外れます。 書き込まないと、同じ型が毎月上がり続けます。

「確認したが問題なかった」も記録してください。 優先度4で上がってきたが、その製品は来期で終わる、という型があります。この結果が残っていれば、翌月は優先度を下げられます。 記録は購買部と共有できる場所に置いてください。

例外に対処する

「優先度5が大量に出る」は、最初の月に必ず起きます。 これまで点検されていなかった型が、まとめて上がるためです。

記録を残す

この記録が、翌月の絞り込みと精度の改善に使われます。

• 月ごとの型別ショット数と、積み上げ後の累計
• 残ショット、月平均ショット数、寿命到達見込み月
• 適用したリードタイムと、逆算した着手日
• 区分、優先度、理由の文章
• 台帳の記載と貸出票の記録、食い違いの有無
• 現物確認の結果と、確認した日
• 補修か作り直しかの判断と、実際の手配日と納入日
• 型が寿命に届いた実績のショット数

最後の項目が、この構成を育てます。 台帳の寿命ショット数は最初は推定値です。実際に何ショットで使えなくなったかを記録していけば、同種の型の寿命を実績で置き換えられます。

「実際の手配日と納入日」も必ず残してください。 リードタイムの標準日数は、ここから更新します。120日と置いた新規製作が実際には160日かかっているなら、着手日の逆算が40日足りていません。 現物確認の結果は、確認した日とセットで残します。閲覧範囲は、生産技術部と購買部に限ってください。