高度計画スケジューリングソフトウェア：APSを評価する方法

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-12

高度計画スケジューリング（APS）ソフトウェアは、現実の制約を反映したスケジュールを作成します。自社のニーズの定義方法、APSツールの比較方法、そして自社データでの検証方法を解説します。

Automatically translated with AI from the original post. Read the English original

高度計画スケジューリングソフトウェア（一般にAPSと呼ばれます）は、設備稼働時間、シフト、スキル、工具、資材といった現実の制約に適合する生産計画を算出します。何を作り、いつ資材が必要になるかを示すだけの計画から一歩進んだものです。本ガイドは、APSが必要かどうかを判断し、ベンダーに評価基準を決められることなく選択肢を評価しなければならない生産計画担当者や運用責任者を対象としています。

重要なポイント

• 高度計画スケジューリングソフトウェアは、MRPの機能に能力ベースの日程計画と順序計画を加えるものです。これにより、競合する受注や限られた資源を計画に組み込めます。
• 製品を見る前に、課題を定義してください。競合する受注がいくつあるか、計画がどのくらいの頻度で崩れるか、そして実際の制約が何かを明確にします。
• 何かを購入する前に、ERPシステムが有限能力計画について既に何をできるかを確認してください。その機能の一部は、有効化した資源に限られています。
• ツールは、制約のモデリング、透明性、計画担当者による調整のしやすさ、再計画の安定性、マスターデータを整理された状態に保つための工数という観点で評価してください。
• 自社データで検証してください。過去の1週間を再現し、ツールのスケジュールと実際に起きたことを比較します。

高度計画スケジューリングソフトウェアとは何ですか？

ASCMが引用しているAPICS用語集では、APSシステムを、計画およびスケジューリング機能を最適化するために高度な数理アルゴリズムやロジックを用いるコンピュータプログラムと説明しています。これは広義の定義です。より実務的な定義は、Fraunhofer IPAの論文（ドイツ語の文献、筆者による翻訳）に見られます。同論文は、APSを、ネットワークレベルのサプライチェーンマネジメント、生産レベルの製造実行システムと並べ、企業レベルのERPと合わせて位置づけています。さらに、計画ロジックの3つのステップも説明しています。

MRPは、当初の形では資材所要量の算出のみを行います。次の段階では負荷に基づく能力所要量を加えますが、同じ資源を奪い合う受注は依然として考慮されません。APSは能力ベースの日程計画と順序計画を加えるため、競合する受注や資材の入手状況が結果に反映されます。ここに本質的な違いがあります。所要量の一覧ではなく、実際に運用可能なスケジュールが得られます。

本記事は購入者の視点で、最初に決めるべきこと、重要な評価基準、そして検証方法を解説します。用語そのものの簡単な定義については、当サイトの高度計画スケジューリングの項目をご覧ください。

APSは、ERPと現場の間のどこに位置しますか？

ISAは、ISA-95を、物流システムと製造制御システムを統合するための国際規格のセットとして説明しています。そのモデルでは、ERPシステムが置かれる事業計画と物流はレベル4です。MESを含む製造オペレーション管理はレベル3です。APSは通常、その中間で機能します。上位から受注とマスターデータを受け取り、スケジュールを作成し、それを現場に引き渡します。

Fraunhofer IPAは、品目マスタ、部品表、工程表といった計画データについては、通常ERPがマスターになると指摘しています。つまり、データ作業をどこで行うべきかが分かります。ERP上のこれらのレコードが誤っていれば、どのAPSを使っても、誤ったものを非常に効率よくスケジュールしてしまいます。

同じ論文は、APS市場とMES市場が大きく重なっていると指摘しています。現場での作業指示の割り当てを誰が担当するのかを、早い段階で確認してください。製造実行システムは、実際に起きたことを記録します。APSは、次に何が起きるべきかを決定します。両方が作業リストの管理を主張すると、計画担当者と監督者は2つのリストを見て仕事をすることになります。

どのような課題を解決する必要がありますか。

Fraunhofer IPAは、ソフトウェアを評価する前に、まずアプリケーションの重点領域と要件を定義することを勧めています。通常は、現状分析と大まかなコンセプトを作成することで行います。次の質問を使って検討してください。

1. 同じ少数のリソースを、何件の受注が取り合っていますか。少数であれば、スプレッドシートで十分な場合もあります。
2. シフト中に計画はどのくらいの頻度で崩れ、その原因は何ですか。機械の停止、材料の欠品、特急受注などでしょうか。
3. 実際の制約は何ですか。機械、熟練作業者、工具、炉、試験台などでしょうか。
4. 段取り時間は作業の順序に依存しますか。依存する場合、順序付けには実質的な価値があります。
5. 現在、誰がスケジュールを作成していますか。作成にどのくらい時間がかかり、どのくらいの頻度で作り直していますか。
6. ツールに何を決めてほしいですか。また、どの判断を計画担当者に残しておきますか。

次に、既存のERPで何ができるかを確認します。例えば、Microsoftは、Dynamics 365 Supply Chain Managementにおける有限能力計画およびスケジューリングを文書化しています。この機能を使うと、利用可能な能力に収まらない計画オーダーは、能力が確保できる日付まで後ろ倒しされます。ただし、この機能は有効化したリソースに対してのみ効果があり、有限として扱う日数を定める時間フェンスを使用します。また、Microsoftは、ほとんどの製造業者にとって1日のフェンスは短すぎる可能性が高いと警告しています。さらに、シフトに基づく能力のように、要件に応じて能力が変動する場合には、有限能力を使うべきではないとも述べています。制約がそのような性質を持つなら、ベンダーと話す前に重要なことが分かったことになります。ご利用のERPは異なる場合もあるため、その文書でも同種の制限がないか確認してください。関連する考え方である有限能力スケジューリングが、これらすべての基礎になります。

APSを互いに区別する基準は何ですか。

機能一覧は似て見えます。実際にツールを区別するのは、次の基準です。

• 制約のモデル化: 実際の制約を表現できますか。機械、スキルを持つ作業者、工具、シフトカレンダー、段取りが順序に依存する場合、材料の払い出しなどを扱えるかを確認してください。
• 透明性: 計画担当者は、ある作業がなぜそこに配置されているのかを確認できますか。説明できないスケジュールは、現場での最初の議論に耐えられません。
• 優先順位ルール: ベンダーの支援を受けなくても、ルール（納期、顧客、段取り削減など）を変更できますか。
• 手動による上書き: 計画担当者は作業を手動で移動できますか。システムはその操作を記録し、他の作業を再チェックしますか。手動で移動した後、スケジュールの残りの部分がどうなるかを確認してください。
• 再計画の挙動: 障害発生後の再計画では、変更が必要な部分だけを変えるべきです。毎回すべてを組み替えるスケジュールは、現場では使えません。Fraunhofer IPAは、計画を完全に予定どおり実行することは決してできないとも指摘しています。そのため、実績と計画の差異に対する許容範囲が必要です。
• データインターフェース: 受注、工程表、進捗データはどのように取得され、誰がそのインターフェースを保守しますか。
• 実行時間: 実際のデータ量で、完全な計画の作成にどのくらい時間がかかりますか。Fraunhofer IPAは、実行時間が分単位になると夜間のみの計画実行は疑問があると述べています。ただし、必ず自社のデータ量で検証してください。
• ワットイフ分析: 実際の日程に触れずに、シナリオを試せますか?
• 計画担当者の工数: マスターデータとルールを維持するのに、どれだけ時間がかかりますか?
• 数年間のコスト: ライセンス、インターフェース、マスターデータの作業、トレーニング、アップグレード。

ベンダーに何を確認すべきか?

最初の打ち合わせで、次の点を確認してください。具体的な回答が得られれば良い兆候です。曖昧な回答も、それ自体が情報になります。

• サンプル工場ではなく、当社のデータから作成したスケジュールを見せてもらってください。
• 10時に機械が停止したらどうなりますか? 何が変わり、何が変わらないのでしょうか?
• 段取り時間が作業順序に依存する場合、どのように扱いますか?
• 当社のルールのうち、計画担当者だけで変更できるものはどれですか?
• 手動での上書きは、どのように記録され、レビューされますか?
• 当社にどの程度のデータ品質を求めますか? データが欠けている場合はどう対応しますか?
• ERPと現場システムとのインターフェースは、誰が責任を持ちますか?
• 同様の生産形態(受注生産型、反復生産型、バッチ生産型)のお客様は、通常どこで苦労していますか?
• 契約を終了する場合、モデル、ルール、データをエクスポートできますか?

購入前に、APSをどのように検証しますか?

リプレイを使いましょう。マーケティング上の売り文句と自社への適合性を切り分ける、最も低コストな方法です。

1. 実際に過去に起きた、通常レベルのトラブルがあった週を選んでください。
2. その週の開始時点の受注、ルーティング、稼働カレンダー、リソースを読み込みます。
3. ツールにスケジュールを作成させます。
4. 実際に起きたこと、および計画担当者が作成したスケジュールと比較します。比較項目は、納期遅延の受注数、段取り回数、残業時間、制約工程のアイドル時間です。
5. 制約工程で2時間の停止が発生するなど、障害を注入し、再計画で何が変わるかを確認します。
6. 計画担当者に1日使ってもらい、信頼できない点や理解できない点をすべて記録してもらいます。

開始前に成功基準について合意してください。そうしないと、結果が出た後で議論が紛糾します。

例: 架空の数値によるリプレイ

この例は、リプレイ結果の読み方を示すために作成した架空のものです。実測結果ではありません。

計画担当者が実際に対応した週には、120件の受注があり、そのうち14件が納期遅延していました。ツールが作成したスケジュールでは、納期遅延は9件でした。ベンダーならここで成功と判断するでしょう。しかし慎重なチームは、ツールが「改善した」とする5件の受注を検証します。そのうち2件は、実際にはその週の大半で停止していた機械に依存していました。ツールは入力データに停止情報が含まれていなかったため、それを知りませんでした。1件は、工程時間が楽観的すぎるルーティングに依存していました。実質的な改善は2件だけでした。正直な結論は「ツールは おそらく優れているが、当社のデータには埋めるべき欠落がある」というものです。どちらの結果であっても、有益な発見です。

導入には何が必要ですか?

ソフトウェアよりも、主にデータと責任の所在が必要です。

• 整理されたルーティング、工程時間、段取り時間、稼働カレンダーです。まずデータ整備を計画し、ベンダーのスライドではなく、その作業量に基づいてプロジェクトのスケジュールを設定してください。
• マスターデータと スケジュールルールについて、担当者を明確に決めておく必要があります。
• 1つの領域から始めましょう。多くの場合は制約工程周辺が適しています。計画担当者がその出力を信頼できるようになってから、範囲を広げます。
• 現場からのフィードバックが必要です。具体的には、着手数、完了数、廃棄数、停止情報です。これがないと、スケジュールは数日で実態からずれていきます。
• 導入初期の数か月は、週次で計画遵守率をレビューしてください。Power BI などのレポートツールで、計画値と実績値を比較できます。

よくある間違い

• 適合性ではなく機能で選んでしまう。 課題が1つの制約工程である場合、多数のモジュールが並んだ長いリストは役に立ちません。
• ERPの確認を省略する。 ERPで一部の要件がすでに対応できている可能性があります。
• デモデータを信用してしまう。 サンプル工場でのデモは、ツールが良好なケースでどう動くかを示すにすぎません。
• マスターデータを軽視する。 誤った工程時間からは、見た目は整っていても誤ったスケジュールが生成されます。
• 計画担当者を運用から外してしまう。 計画担当者は上書きできなければならず、その理由も把握できなければなりません。
• APSとMESの責任範囲が曖昧になる。 作業リストが2つあると、真実も2つになってしまいます。
• 完璧な計画を期待する。 計画は必ず逸脱します。許容範囲と再計画の手順を組み込んでおきましょう。

Polarisが適している領域

制約付きで実行可能な計画が必要な場合、iFAKT Polaris も候補の一つとして検討できます。iFAKT は Polaris を、生産向けの AI とデジタルツインを組み合わせたものと説明しています。その Polaris Optimizer モジュールは、製品・工程・リソースのナレッジグラフを、リアルタイムの ERP データ、リソースの稼働状況、シフト、ゾーン、スキル、キャパシティといった制約に基づいて、実行可能で最適化された生産計画に変換します。ボトルネックの検出、受注の優先順位付け、障害の影響分析、再最適化も行えます。適合するかどうかは、お客様の工程とデータ次第です。そのため、上記のリプレイテストを、まずは狭い範囲で試してください。

関連して検討したいトピック

• 複数拠点のスケジューリング。工場間でリソースや受注を共有している場合は、スケジュールを1つのチームが管理するのか、各拠点が個別に管理するのかを決めてください。
• 多品種少量・受注生産型の業務。固有の工程経路やエンジニアリングのリードタイムによって、スケジューリングツールが扱うべき内容は大きく変わります。
• 需要シグナル。顧客からの受注や変更がスケジュールにどれくらい速く反映されるかによって、再計画の頻度が決まります。
• スケジューリングとエネルギー。工場によっては、エネルギーコストをスケジューリングの入力条件として扱いたいと考えています。問題になる前に、ツールがそれに対応しているかを確認しておきましょう。

次のステップ

高度な計画・スケジューリングソフトウェアの評価は、課題を文書化し、過去1週間分のデータでリプレイできる状態にしておくと格段に進めやすくなります。直近の1週間分の受注、工程経路、カレンダーのデータを取得し、次回のベンダーとの打ち合わせでそれをテストケースとして使ってください。