「要件定義書を読ませれば同等のものができる」という前提には注意が必要です。要件定義書に加えて既存システムの実データを受け取り、出力結果を突き合わせながら進める形をご提案します。
工場の生産計画を、無理のない形にならす作業です。日ごとに各設備や作業者へ割り当てた仕事量を集計し、こなせる量を超えている日の仕事を、空いている日や別の設備に移します。
| 手段 | 代償・条件 |
|---|---|
| 前倒し（早めに作る） | 在庫と置き場所が増える |
| 後ろ倒し（遅らせる） | 納期に間に合うことが条件 |
| 別の設備・ラインに振り替える | その設備で作れる品目に限られる |
| 能力を増やす | 残業・休日出勤・外注のコストが増える |
仕事を動かすときに守るべき条件（制約）が多くあります。納期、材料の入荷日、前の工程が終わっているか、品目を切り替えるときの段取り替えの時間、まとめて作る単位（ロット）、保管期限、作業者のスキルなどです。
品目や設備が増えると、Excel と担当者の経験では追いつかなくなります。急な注文や設備トラブルのたびに計画を作り直すことになり、担当者しか計画を組めない状態にもなりやすいです。
製造業の生産管理は、だいたい次の流れで回っています。
山崩しシステムは、この流れの「山積み→山崩し」を自動化・支援する仕組みです。パッケージ製品では「生産スケジューラ」と呼ばれる製品群（Asprova、FLEXSCHE など）がこの役割を担うことが多く、基幹システム（ERP）から受注・在庫・マスタを受け取って計画を作り、基幹システムへ返します。
お客様の既存システムがどの段階かによって、同等品を作る難しさが大きく変わります。最初に確認したい点です。
| 部署 | 想定される関わり |
|---|---|
| 化成・金属 | 計画の対象になる部門・ライン。制約の性質が部門ごとに違う可能性がある |
| 生産管理 | システムを毎日使って計画を作る、実際の利用者 |
| 経営企画 | 山積みの結果から慢性的に足りない設備を把握し、設備投資や人員計画を判断する立場と推測。要確認 |
生産管理の担当者が毎日開くメイン画面を想定しています。「自動山崩し」を押すと、能力オーバーが解消された計画案に切り替わります。
能力オーバー
4件
納期遅れリスク
1件
在庫増（前倒し分）
0ロット
数値・設備名はすべて説明用の架空のものです。
マスタには、品目、工程の順番、設備ごとの能力、稼働カレンダー、段取り時間などが入ります。
| 画面 | 役割 |
|---|---|
| 山積み画面 | 設備・日ごとの負荷を一覧で確認し、自動山崩しを実行する（上の画面） |
| ガントチャート | 設備ごとに個々の作業を時間軸に並べて表示する。ドラッグで手修正できる |
| シミュレーション | 「設備を1台増やしたら」「土曜に稼働したら」を比べる。経営企画向け |
| マスタ管理 | 品目、設備能力、稼働カレンダー、優先ルールを登録・変更する |
| 予実比較 | 計画と実績の差を見て、能力の設定を見直す |
| 要素 | 内容 |
|---|---|
| 画面 | Web アプリ。社内のブラウザから使う形 |
| 山崩しエンジン | Python と数理最適化ライブラリ（Google OR-Tools など）で実装する。計算結果が毎回同じになり、理由を追える作りにする |
| 連携 | 基幹システムとは CSV の取り込み・書き出しから始め、必要に応じて API 連携に移行する |
Claude は開発を速くするために使います。具体的には、要件定義書の読み込みと整理、仕様の抜け漏れの洗い出し、プログラムとテストの作成を担当させます。
山崩しの計算そのものは Claude に毎回判断させず、決まったロジックで処理する設計にします。生産計画では、同じ入力なら同じ結果が出ることと、なぜその結果になったかを説明できることが必要だからです。
「なぜこの受注を月曜に動かしたのか」を日本語で説明する機能や、担当者が「火曜のプレス1号機をもう少し空けて」とチャットで指示すると計画案を作り直す機能を加えられます。既存システムの再現にこうした機能を加えると、お客様の言う「自社仕様へのカスタマイズ」の提案材料にもなります。
MATLAB でも山崩しの計算はできます。Optimization Toolbox に整数を含む最適化問題を解く関数（intlinprog）があり、山崩しを数式に落とせば解けます。ただし MATLAB の得意分野は数値計算、シミュレーション、制御設計、研究開発で、製造業でも主に開発・技術部門が使っています。生産管理部門が毎日使う業務システムの土台として選ばれることはあまりありません。
| MATLAB | Python（OR-Tools など） | 生産スケジューラ製品 | |
|---|---|---|---|
| 山崩しの計算 | できる（追加の Toolbox が必要） | できる | 標準機能 |
| 業務システム化 | 不得意。社内配布には MATLAB Compiler や Production Server などの追加ライセンスが必要 | 得意。Web アプリや DB 連携の部品が豊富 | 製品の範囲内で設定する |
| 費用 | 本体と Toolbox が有償。利用者や配布形態で増える | 無償（商用ソルバーを使う場合は有償） | 製品ライセンスが有償 |
| カスタマイズ | 自由 | 自由 | 製品の仕様に縛られる |
| 保守できる人 | 社内の技術者に限られがち | 多い | ベンダー依存 |
業務システムとして作るなら、弊社は Python を第一候補にします。「同等のシステムを作って自社仕様にカスタマイズする」という目的にも、Python が一番合っています。
既存システムが MATLAB 製なら、そのソースコードが要件定義書よりも正確な仕様書になります。コードを受け取れれば再現の精度は大きく上がり、Python への移植も現実的です。Claude は MATLAB のコードも読み書きできます。
要件定義書は通常「何をするか」までしか書かれていません。どの品目を優先して動かすか、前倒しは何日まで許すか、ロットを分割してよいか、段取り替えをどう扱うかといった細かいルールは、設計書やプログラムの中、または計画担当者の頭の中にあることが多いです。要件定義書だけで作ると、「だいたい同じ動き」はしても「同じ結果」にはならない可能性が高いです。
同じデータを入れたときに既存システムと同じ計画が出ることを「同等」とするのか、計画として妥当なら多少の差は許すのかを決める必要があります。前者の場合は、既存システムに入れたデータと出てきた結果の実例が必須です。
一般的に、化成はバッチ処理、配合、タンク容量、洗浄といった制約が中心です。金属は設備ごとの加工時間や段取り替えが中心になります。1つの仕組みで両方扱うことはできますが、制約の定義は部門ごとに必要なので、対象範囲は大きくなります。検証段階ではどちらか一方に絞るのが現実的です。
既存システムの出力を計画担当者が手で直している場合、その判断はシステムにも要件定義書にも書かれていません。生産管理部門へのヒアリングが必要です。
既存システムがパッケージ製品や外部ベンダーの開発品なら、要件定義書を類似システムの開発に使ってよいか、契約上の確認が必要です。要件定義書を AI に読み込ませることがお客様の社内規程に反しないかも、事前に確認が必要です。なお、Claude は法人向けの利用形態であれば、入力データがモデルの学習に使われません。
受注・在庫・マスタのデータを基幹システムからどう受け取るかで、開発範囲が変わります。品目数、設備数、計画期間によって計算時間も変わります。
要件定義書を読み込み、そのまま再現できる部分と情報が足りない部分を一覧にします。そのうえで、ゴールと対象範囲をお客様と合意します。資料受領後1〜2週間が目安です。
1部門・1工程に絞り、過去の実データで既存システムの山崩し結果と比べます。どこまで一致したかと、差が出た理由を報告します。
対象部門を広げ、お客様の自社仕様を追加し、既存システムとつなぎます。
金属部門の特定ラインについて、過去3か月分のデータで既存システムと同じ山崩し結果を再現できるか検証し、差が出た箇所の理由を説明できる状態にする
資料が揃った段階で、生産管理のご担当者に1時間ほどヒアリングできると、見立ての精度が大きく上がります。