現実の生産計画 — 工場は教科書通りには動かない
あなたは月曜の朝、自慢の最適化システムを導入したばかりの工場長。
全自動で完璧な計画が出てくるはずだった。
火曜、A 機械が壊れる。
水曜、急ぎの注文 5 件が飛び込む。
木曜、原料納入が 1 日遅れる。
金曜、ベテラン作業員 1 人が休みを取った。
最適化システムは、もう何が「最適」だかわからない顔をしている。
これが現実の工場だ。
ベンチマークの世界では、処理時間は確定値、機械は壊れず、需要は朝に確定する。
本物の工場では、どれもウソだ。
この章では、教科書 JSP のその先に踏み込む。
「ジョブ列を計算した」と言ってから始まる、もう一つの戦い。
8.1 計画は階層構造
そもそも「生産計画」は一つの問題じゃない。 時間スケールの違う計画が階段状に積み重なっている。
8.2 教科書 JSP に降ってくる 10 の追加制約
ベンチマークと現実の差はとてつもなく大きい。
現実の工場では、教科書 JSP にこういう制約が乗ってくる:
- 🔁 段取り時間: 「赤の次に白を作るには 30 分の洗浄が必要」
- ⏰ カレンダー: 機械は 8:00〜17:00 だけ、土日休み、12:00〜13:00 は昼休み
- 👷 人: 機械があってもオペレーターがいないと動かない
- 📦 調達: 原料が届くまで開始できない
- ⏳ 賞味期限: 加工後 N 時間以内に次工程へ (食品、めっき)
- 📐 ロット制約: 最小バッチ、品種家族
- 🎯 品質: 材料ロットで処理時間が変動
- 🤝 同期: 2 つの工程が同時に動かないといけない
- 🚫 禁止組合せ: アレルゲン製品の後は洗浄必須
- 🔧 段取り人員: 段取りは人を取る。並列段取りに上限
こうした制約はすべての組み合わせで発生する。
「段取り時間付き × 人員シフト付き × カレンダー付き」みたいな複合は当たり前。
だから教科書 JSP より、ずっと表現力の高いモデリングが必要になる。
8.3 不確実性を 2 × 2 で整理する
モデルがどんなに完璧でも、入力にブレがあれば計画は脆い。
不確実性を 4 種類に整理しておくと、対処法が見えてくる。
8.4 Rolling Horizon — 「未来は刻んで計画する」
④ への対処法、それが Rolling Horizon。
APS パッケージはほぼ例外なくこの設計を取っている。
発想はシンプル: 「未来全部を一気に詳細計画しない」。
時間軸を窓で切って、窓を前進させながら何度も再計画する。
3 つのゾーン
① 凍結ゾーン (frozen zone): 直近の数時間〜1日。 原料は払い出され、現場は動いている。もう動かさない。
② 詳細最適化ゾーン: 1〜数日。分単位の精度で機械別シーケンスまで決める。 CP-SAT / ALNS が走る。
③ プレビューゾーン: 1〜数週間。粗いモデルで「容量や在庫が破綻しないか」だけ確認。 詳細ゾーンが終局的に収まるよう、ここを境界条件として渡す。
落とし穴 — End-of-horizon 効果詳細ゾーンの終端で「ジョブを全部詰め込んで終わり!」みたいな解になり、 翌期に大きな手戻りが起きる。これが定番の罠。
プレビューゾーンを置く、終端ペナルティをかける、終端在庫の目標を制約に入れる、で防ぐ。
8.5 再計画のタイミング — いつ走らせる?
| 戦略 | トリガ | 性格 |
|---|---|---|
| 定期型 | 毎日 6:00、毎週月曜など | 運用が単純、現場が予測できる。緊急対応は弱い |
| イベント駆動 | 故障・受注・遅延などで都度 | 現実に即応。だが計画が頻繁に変わって現場が混乱しがち |
| 閾値型 | 逸脱が閾値を超えたとき | 必要なときだけ。閾値の調整が難しい |
| ハイブリッド | 定期 + 緊急のみイベント | 実務で最も多い ⭐ |
再計画のスタイル: 完全 vs 修復
完全再計画
白紙から最適化。質は高いが、結果が前計画と大きく異なる → 現場が混乱。
最小修復
前計画を可能な限り保持し、最小の変更で実行可能化。連続性は高いが、最適性は妥協。
実務でバランスする答え: 「凍結帯は固定、その先は完全再計画、ただし前計画との変更量にペナルティ」。
8.6 多目的最適化 — 「全部同時に最小化」は不可能
現実の生産計画では、これらを同時に小さくしたい:
- makespan を縮めたい
- 遅れを減らしたい
- 段取り時間を減らしたい
- 在庫を少なくしたい
だが当然、トレードオフがある。 段取りを減らそうとロットを大きくすると、makespan が伸びる、みたいな。
すべて同時に最小化はできない。
実務でいちばん使える: 辞書順
理論的にはいろいろあるが (加重和、ε-制約、NSGA-II)、現場で最も使いやすいのは 辞書順 (lexicographic):
- まず納期遵守 (ΣT_j) を最小化
- その下でmakespan を最小化
- さらにその下で段取り を最小化
業務での優先順位がそのままアルゴリズムになる。説明もしやすい。
8.7 説明可能性 — 「なぜこの計画?」
本番投入の最大の敵は性能ではなく 信頼だ。
「ALNS の重み更新の結果ですね」と言われて、現場リーダーは納得しない。
| レベル | 説明の内容 | 必要な実装 |
|---|---|---|
| L1: 結果だけ | 「これがインプット、これが計画」 | ガントチャート |
| L2: 制約と影響 | 「M3 が金曜午後ふさがっていたから、Jを翌週へ」 | クリティカルパスの可視化、制約タグ |
| L3: 反実仮想 (What-if) | 「M3 をもう一台増やすと makespan が 4 時間縮みます」 | パラメータを変えて再計算する UX |
「説明可能性は別タスク」と思いがちだが、これは最適化エンジンの設計判断に直結する。
L2 を出すには、解と一緒にクリティカルパスを返す API が必要。
L3 には What-if 分析の UX が必要。
8.8 商用 APS パッケージの教訓
| 製品 | 得意 | 苦手 |
|---|---|---|
| Asprova (Japan) | 製造業ドメイン、UI | パラメータ地獄 (数百の設定) |
| FLEXSCHE (Japan) | 柔軟なルール記述 | プラットフォーム型、導入次第 |
| Quintiq / DELMIA | 表現力、独自 DSL | 独自言語によるロックイン |
| SAP APO / IBP | 大規模 ERP 統合 | 個別最適化の精度 |
| Kinaxis / RapidResponse | What-if が強い | 最適化能力は別物 |
業界の闇APS パッケージ導入プロジェクトの9 割は「うまくいかなかった」と業界調査で報告される。
主因は技術ではなく、業務側が制約と目的を整理しきれないこと。
最適化システムを入れる前に、「制約と目的関数を文書化できるか」を組織能力として確認すべし。
8.9 設計の最初に決めること
生産計画システムを設計する最初の段階で、決めるべき項目のチェックリスト:
- 計画階層: 上位 (MPS) と下位 (APS) の境界はどこ?
- 計画粒度: タスクの最小単位 (分・時間・日)?
- 計画期間と凍結ゾーン: 何時間先まで凍結、何日まで詳細、何週まで概略?
- 再計画の頻度とトリガ: 定期? イベント? ハイブリッド?
- 目的関数の優先順位: 辞書順? 重み付き和?
- 不確実性: 確定モデル + 再計画? 確率モデル?
- 制約の硬さ: ハード? ソフト (ペナルティ)?
- ソルバー: CP-SAT? MIP? ALNS? ハイブリッド?
- 説明可能性: L1 / L2 / L3 どこまで?
- What-if: 必要? UI まで? エンジンのみ?
- 性能 SLA: 何分以内に応答?
- 計画スナップショット: 履歴保存・比較・復元できるか?
8.10 この章の振り返り
- 生産計画は階層構造。本書の主戦場はその底辺だが、上から制約が降ってくる。
- 現実は教科書 JSP に10 以上の追加制約を載せてくる。
- 不確実性は 4 象限。計画的揺らぎはモデルに、高頻度サプライズは Rolling Horizon で。
- Rolling Horizon は 凍結 / 詳細 / プレビューの 3 層構造。
- 多目的は辞書順が実務最強。
- 説明可能性 (L1〜L3) は本番運用の鍵。最初に設計目標を決める。
- APS パッケージ導入の 9 割が失敗する。原因はだいたい業務側の準備不足。