製造業の設備能力カレンダー導入｜生産スケジューラーの要件と受入試験

製造業で設備能力カレンダーを生産スケジューラーに導入するなら、「稼働日を登録できるか」だけでは足りません。通常シフト、休憩、祝日、計画保全、設備ごとの例外が同時にある日に、有限能力の空き時間を正しく計算し、理由を説明できることが要点です。本稿はタイ工場を想定し、設備と資源グループのカレンダー設計、例外の優先順位、RFPとFAT/SATでの検証方法を具体化します。製品一般の優劣ではなく、導入前に自社の時間ルールを定義するための実務手順です。

設備能力カレンダーが曖昧だと、有限能力計画も曖昧になる

生産スケジューラーは製造指図を設備、作業者、治工具と時刻に割り当てます。しかし、割当先の設備がいつ稼働できるかを表すカレンダーが不正確なら、計算を有限能力に設定しても現場で実行できる計画にはなりません。土曜日を通常稼働として登録したまま工場が休みになれば、休日へ仕事が入ります。昼休みを能力に含めれば、その時間帯に段取りを始める計画が生まれます。計画保全が設備単位で登録されていなければ、その機械は見かけ上空いています。問題は最適化アルゴリズムの能力ではなく、投入する利用可能時間の定義にあります。

MicrosoftのOperations resources資料は、資源の稼働時間がカレンダーによって定まり、資源グループの能力は所属資源の能力の合計で計算されること、有効期間のないカレンダーが計画を妨げることを説明しています。一方、OracleのProduction Calendars資料は、工場、作業区、個別資源に対するカレンダーとシフト例外を区別します。どちらも「設備をいつ使えるか」は製品の設定階層と例外に依存することを示しています。これらは各製品の仕様であり、他社製品へそのまま一般化してはいけません。導入時は採用候補の実機で優先順位と計算結果を確認します。

本稿の範囲は、設備能力カレンダーという時間の入力に絞ります。生産スケジューラー全体の評価軸は生産スケジューラー比較ガイド、設備・人員・材料を同時に制約にする設計は有限能力計画の導入ガイドを参照してください。カレンダー単独で材料、資格、段取り順序のすべてを表現しようとすると、意味の分からない例外が増えます。

最初に「能力」の単位を決める

グループ能力と設備能力を混同しない

例えば切断機AとBを「切断」資源グループに入れても、各機械の稼働可否は別です。グループの標準シフトが08:00–17:00でも、Aだけ14:00–16:00に保全停止することがあります。グループの日次能力を単純に2台×8時間とする設計では、この停止を表せません。一方、工程レベルの粗い計画なら「切断工程全体は何時間受け入れられるか」で十分な場合もあります。RFPには、どの業務判断をグループの時間枠で行い、どの判断を設備IDの時間枠で行うかを書き分けます。

MicrosoftのOperations schedulingは資源グループへの予約を、Job schedulingは個々のジョブへの資源割当を説明しています。したがって、同じ「能力カレンダー」でも計画粒度によって期待する挙動が変わります。初回導入で日次工程能力と分単位の設備割当を同じ受入試験で混ぜると、どの層でずれたか分からなくなります。まず計画粒度、時間単位、最小スロット幅を明示します。

時間、数量、効率を別の項目にする

稼働時間は「いつ開いているか」、能力率や効率は「開いている時間にどれほど処理できるか」、製造時間は「この品番・ロットに何時間必要か」です。これらを同じ「能力」という列へ押し込むと、保全停止と低速運転の区別が消えます。設備が完全停止なら利用可能時間を閉じる。速度が半分なら、対応する製品仕様に従って処理時間または能力率を見直す。前者の不具合を後者で埋める運用は避けます。Microsoftはジョブの予約時間について、実行時間と段取り時間を効率百分率で調整する式を示していますが、計算式は対象製品で確認が必要です。

設計会議では、工程の標準時間、品番別速度、段取り、収率、並列台数、共有治具のどれが時間カレンダーの外にあるかを一覧にします。カレンダーを「何でも入れる箱」にしないことが、後の保守費用を抑えます。

シフト・休憩・休日をどう表すか

通常週と設備固有の稼働を分ける

通常週には、曜日ごとの始業・終業、交替勤務、休憩、夜勤の日跨ぎを登録します。工場全体で同じ勤務表なら共通テンプレートを使い、設備固有の違いだけを例外として管理するのが運用しやすい構成です。ただし「全設備が同じ」という前提は設備台帳と現場で照合します。連続炉だけ24時間、検査機は平日日勤、共有フォークリフトは別勤務という工場では、共通テンプレートを無理に一つへ統合してはいけません。

MicrosoftのScheduling engine performance資料は、似た内容の資源別カレンダーを大量に分けると読み込みとキャッシュに負担が出ること、1日の稼働時間スロットを細かくし過ぎると性能に影響することを説明しています。これは「休憩を省け」という意味ではありません。計画判断を変える休憩は明示し、結果に影響しない細分化を避ける、という製品で検証すべき設計観点です。

祝日・臨時操業・振替稼働の「日付」を明確にする

祝日のCSVを登録できても、どの工場、どの設備、どのシフトに適用されるかが曖昧では危険です。タイ国内に複数拠点があり、拠点ごとに休日や振替操業の決定が違う場合、全国共通の一行だけでは足りません。祝日登録時には、対象拠点、対象資源、現地日付、変更理由、承認者、承認日時、有効期間を一緒に残します。夜勤が前日から翌日に跨る場合、休日開始時刻を暦日00:00で切るのか、勤務開始日にひも付けるのかも定義します。

Oracleの公式資料では製造カレンダーのシフトと例外が工場のタイムゾーンで解釈されると明記されています。これは越境工場で特に重要です。本社PCのタイムゾーンやクラウドサーバーのUTCを、工場の現地時刻と無自覚に混ぜてはいけません。FAT/SATでは同じイベントを画面、API、出力CSVで表示し、UTC保存値を現地時刻へ変換した後も停止区間が一致することを確かめます。

休憩は「生産不可」か「特定作業だけ可」かを決める

設備は昼休みに自動運転を続けるが、材料投入や検査には作業者が必要、という現場があります。このとき設備カレンダーを昼休みで閉じると、自動運転可能な工程まで止まります。逆に開いたままにすると、作業者不在でも段取りを割り付ける可能性があります。設備と作業者を別資源として扱い、工程が要求する組合せを指定するか、対象工程だけに停止ルールを設けるか、製品仕様と運用工数で決めます。「昼休みをカレンダーへ登録した」の一文では要件が完結しません。

夜勤についても、23:00–07:00のシフトと01:00–01:30の休憩をどう日付に帰属させるかを現場と合意します。開始日基準と終了日基準が混在すると、前日の保全例外と翌日の稼働枠が重なります。シフトIDと現地開始・終了時刻を保持し、画面では日跨ぎを一続きの枠として見せるほうが誤読を減らせます。

計画保全・故障・特別稼働の例外を設計する

例外には種類、範囲、期間、承認を持たせる

設備停止を「カレンダーの空白」にすると、後から理由を追えません。計画保全、故障、品質保留、金型待ち、電力停止、臨時操業を区別し、それぞれ対象設備、開始・終了、発生源、承認者、変更履歴を持たせます。ただし全てを設備カレンダーで閉じる必要はありません。品質保留が品番限定なら、設備全体を停止扱いにすると過剰制約です。例外は「この資源を使えない時間」なのか、「この品番・工程だけ作れない条件」なのかでモデルを分けます。

OracleのCreate a Shift Exceptionは、シフト追加、変更、削除、分割という製品固有の例外操作を示しています。RFPでは操作名だけを要求せず、「日曜にAだけ稼働、同日Bは停止」「既存シフトの中ほどだけ保全」のような結果で要求を記述します。ベンダーには標準機能、設定、拡張のどれで表すかと、画面上の適用順序を説明してもらいます。

例外の優先順位を一枚の決定表にする

同じ時刻に複数の例外がかかるときの扱いは、導入初期に決めます。例として「安全停止・故障による閉鎖」「承認済み計画保全」「明示的に承認した臨時操業」「工場休日」「通常シフト」の順を検討できます。臨時操業が休日を上書きできるのは、承認時に対象設備と期間を明示した場合だけです。ただしこれはTOMAS TECHの設計例であり、製品共通の固定ルールではありません。休日の臨時操業を許すなら、休日より臨時操業を優先できる権限と期間が必要です。保全停止中の臨時操業を禁止するなら、誰が例外を入力しても停止が勝つことをテストします。

この表には、同じ対象への二重登録、終了時刻が開始時刻より前、期間外のカレンダー参照、承認前の仮登録も加えます。入力検証で拒否するのか、警告し計画から除外するのかは運用方針として決定します。未承認の停止情報を完全に無視すると危険ですが、未承認の臨時操業を自動で有効化するのも危険です。停止と開放で既定動作を分ける選択肢があります。

有効期間と版を管理する

設備能力カレンダーは「今日の設定」だけではありません。来月から夜勤を一つ増やす、旧設備を月末で撤去する、繁忙期だけ土曜稼働にする、といった将来変更を計画計算に反映する必要があります。カレンダー割当には開始日と終了日を持たせ、同じ設備に同時刻の矛盾する有効版を置かないようにします。MicrosoftのOperations resources資料も資源に割り当てるカレンダーの有効日と失効日、および重複禁止を説明しています。ただし製品ごとに版管理方法は異なります。

設定を上書きするだけでは「先週発行した計画が当時どのカレンダーで作られたか」を再現できません。計画の発行時にカレンダー版ID、適用例外の版、タイムゾーン、計算時刻、計算エンジンの設定を記録するか、少なくとも追跡可能な参照を残します。将来のシフト変更が入ったら、どの計画を再計算し、どの確定済み作業を動かしてはいけないかも決めます。カレンダー変更は単なるマスタ更新ではなく、納期回答に影響する業務変更です。

変更承認は生産管理だけに閉じないほうがよい場合があります。保全は停止窓、現場は実際の出勤、品質は検査設備、営業は約束納期を持ちます。例えば保全停止の開始を1時間前倒しすると、段取り済みの仕事が影響を受けます。誰が変更を提案し、誰が承認し、誰が影響計画を再発行するかをRACIで記述します。緊急停止だけは事後承認を認める場合でも、イベント発生時刻と承認時刻を区別して保存します。

有限能力での計算を小さな例で検算する

次はTOMAS TECHが説明のために作った仮定例で、特定製品の計算仕様や実工場の実績ではありません。月曜の加工機M1の通常枠を08:00–17:00、休憩を12:00–13:00とし、利用可能時間は8時間です。火曜も同じ8時間ですが、火曜14:00–16:00に計画保全を登録すると、その日の利用可能時間は6時間になります。水曜は工場休日で0時間です。月曜から水曜までの合計は8＋6＋0＝14時間です。

ここに月曜開始の注文Aが設備M1を6時間、注文Bが5時間必要だとします。段取りや材料待ちはないと仮定します。Aが休憩を挟んで継続できる仕事なら、月曜08:00–12:00の4時間と13:00–15:00の2時間、計6時間を使います。月曜の残りは15:00–17:00の2時間です。Bも非稼働時間で中断・再開できる設定なら、月曜の2時間と火曜08:00–11:00の3時間で計5時間となり、火曜11:00に完了します。両注文の負荷は6＋5＝11時間、対象期間の利用可能時間は14時間なので、総量にも矛盾はありません。火曜14:00–16:00の保全には仕事が入りません。

一方、Bに「開始後は連続5時間必要」という条件があるなら、月曜15:00–17:00は2時間、火曜08:00–12:00は4時間、13:00–14:00は1時間、16:00–17:00は1時間で、3日間に連続5時間の枠はありません。対象期間の能力14時間はAとBの所要時間合計11時間を3時間上回りますが、Bをこの期間に割り付けることはできません。これはカレンダーの合計能力と実際の着手可能時刻が違うことを示します。休憩中に自動運転を続けられるか、仕事をどの条件で中断できるかは工程と製品設定ごとに決めます。受入試験では総能力だけでなく、開始・中断・再開・終了時刻まで照合してください。

さらに、効率80％を適用する設定なら、標準時間5時間の予約が5×100÷80＝6.25時間になる方式もあります。これはMicrosoftのJob schedulingが示す式に沿った説明例です。すべてのAPSに同じ式を適用してはなりません。RFPでは「処理時間、効率、段取り、休憩をどの順に計算するか」を質問し、数値が合うだけでなく画面の根拠が再現できるかを確かめます。

RFPに書くべき設備カレンダー要件

RFPの「カレンダー対応：あり／なし」というチェック欄では運用差を判定できません。候補ベンダーへ同じデータと期待結果を渡し、標準設定で再現する部分と追加開発が必要な部分を分けて回答してもらいます。最低限、次の項目を一つの要件表にまとめます。

見積依頼では、設備数だけでなく「カレンダーの種類×将来の週数×例外の頻度」を渡します。毎日現場判断で例外を変える工場と、年一回の休日登録だけで済む工場では、同じ設備数でも運用負荷が違います。ライセンス料だけで判断せず、マスタ管理、保全システム連携、設定変更、教育、計算性能の試験工数を分けて見積もります。段取りや材料制約も含めた製品選定全体は前述の比較ガイドと組み合わせます。

FAT/SATで落としてはいけない受入試験

FATでは設定済み環境に固定した試験データを投入し、期待結果と計算結果を比較します。SATでは現場の勤務表、設備停止の入力経路、担当者の権限、端末表示と再計画の手順を検証します。両方とも「画面にカレンダーが表示された」だけでは合格にしません。仕事がどこに割り付いたかと、割り付かなかった理由が重要です。

MicrosoftのNot enough capacity errorの公式手順も、該当資源、関連カレンダー、スケジューリング設定、実際の空き能力を順番に確認します。したがって障害対応画面では「能力不足」だけの一文より、どの資源のどの期間・どの設定が原因候補かを追えることが有用です。製品にその説明機能があるかはFATで確認します。

受入試験の期待値は、導入側が表計算や手計算で先に用意します。ベンダーの画面を見てから期待値を変えると、テストではなくデモの追認になります。ケースごとに入力ファイル、画面キャプチャ、計算ログ、計画版、判定者、再試験結果を一組として保存します。SATでは実際の設備担当者が「変更申請→承認→再計算→発行→現場確認」の一連の操作を行います。

連携と運用責任を決めてから本番化する

設備能力カレンダーの正本をどこに置くかを決めます。勤務シフトは人事や勤怠システム、計画保全はCMMS/EAM、製造指図はERP、実績はMESという構成なら、APSへ流す項目と頻度を明確にします。現場で設備停止が発生したとき、MESの停止実績をそのまま将来カレンダーへ延長する設計は危険です。故障発生、復旧見込み、承認済み停止期間、実際の復旧を区別し、誰の入力が将来計画を変えるかを定めます。

API連携では、イベントID、設備ID、開始・終了のタイムゾーン、イベント種別、更新時刻、取り消し、再送を扱います。通信が失敗したときに古いカレンダーで計画を発行してしまわないよう、最後の同期時刻と未反映件数を画面に表示します。インターフェースが復旧して過去の停止イベントが再送されても、同じイベントを二重に閉鎖しないことを試験します。複数の部門が同じ停止時間を別々に登録する場合は統合規則が必要です。

本番後は、保全担当が停止予定を提出し、生産管理が計画影響を確認し、現場管理者がシフト例外を承認し、システム担当がエラーと連携を監視する、といった分担を置きます。最初の数週間は「カレンダー変更後に再計算されなかった指図」「発行済み計画と現場実績の差」を日次で見ると設定漏れが見えます。改善指標は導入前に定義し、計画の時間内完了率、直前変更件数、手修正時間、例外登録のリードタイムなどから少数を選びます。外部企業の改善率を自工場のROIに代入しません。

FAQ：生産スケジューラーの設備能力カレンダー

設備能力カレンダーと生産計画カレンダーは同じですか？

使い分けが必要です。生産計画カレンダーが工場全体の営業日や納期計算日を示す場合でも、設備能力カレンダーは設備・資源グループの利用可能な時間帯と例外を示します。同じ休日を参照していても、設備固有の保全停止や夜勤は別に管理します。製品によって名称と継承関係が異なるため、設定画面と実際の割付結果を合わせて確認します。

休日と保全停止が重なったらどちらを優先しますか？

「両方とも閉じる」だけなら割付結果は同じですが、原因表示と後日の臨時操業で差が出ます。休日を解除して稼働させても、保全停止は残るべきかを決定表で定義します。停止理由と承認履歴を別イベントとして保存するほうが、後から変更を追いやすくなります。

有限能力スケジューリングならシフト変更は自動反映されますか？

必ずしもそうではありません。連携先の更新、カレンダー再生成、計画の再計算、発行済み計画の扱いが必要な製品があります。MicrosoftのFinite capacity planning資料は製品固有の設定条件と、能力が変動するシフトでは計算時間に注意が必要な場面を明記しています。「有限能力をオンにした」だけで可変シフトが正しく処理されると推定せず、対象製品の資料と実ケースで確認します。

APSの設備カレンダーをRFP・FAT・SATでどう確認しますか？

RFPではシフト、休憩、休日、設備別保全、優先順位、有効期間、タイムゾーン、監査を結果ベースの要件として書きます。FATでは固定データと手計算の期待値で割付時刻を照合し、SATでは現場の入力、承認、再計画、指図発行まで通します。例外を追加した後、既存予約がどう変わり、理由がどう表示されるかまで合格基準にします。

まとめ

設備能力カレンダーの導入は、休日を一覧へ入力する作業ではありません。資源グループと設備の時間階層、シフトと休憩、計画保全や臨時稼働の例外、有効期間と優先順位を決め、有限能力の結果を時刻単位で検算する仕事です。RFPで期待する割付を文章化し、FATで固定データ、SATで現場操作を確かめます。製品固有の挙動を思い込みで埋めず、同じ試験ケースで確認することが、導入後の手修正を減らす近道になります。

タイ工場の勤務表や設備停止の情報をどうスケジューラーに載せるか検討中であれば、対象設備を一群に絞ったカレンダー要件と受入試験の整理からお問い合わせいただけます。製品選定前の段階でも相談可能です。

参照資料

• Microsoft Learn: Operations resources
• Microsoft Learn: Improve scheduling engine performance
• Microsoft Learn: Operations scheduling
• Microsoft Learn: Job scheduling
• Microsoft Learn: Finite capacity planning and scheduling
• Microsoft Learn: Fix the not enough capacity error
• Oracle: How You Manage Production Calendars
• Oracle: Create a Shift Exception

本稿の計算例、優先順位表、受入試験は説明用の設計例です。実装可否と計算順序は採用する製品の版・設定で確認してください。