MES に状態が記録されていても、なぜ製造現場の停滞を説明できないのか

適用階層：群制御・協調層 / MES-WCS 協調停滞診断
代表対象：製造現場の協調停滞診断モジュール

推奨引用：

全野南政 / Nansei Zenno，
『MES / WCS 協調停滞診断モジュール事例：MES に状態が記録されていても、なぜ製造現場の停滞を説明できないのか』，
公開事例，Public Case Version 1.7，2026-10-03，
https://zennns.com/jp/cases/collaborative-stagnation-diagnosis/

MES と WCS には、通常、タスク、設備、搬送、資源、ステーションなどに関する多くの運転情報が記録されている。

たとえば、稼働中タスクが 42 件あり、そのうち 17 件が継続待機または未実行になっているとする。実行主体はオンラインで、ステーション要求も存在し、一部の経路は利用可能である。共有資源は一部占有されているものの、システム全体の停止を直接説明できるような単体設備の重大アラームは発生していない。

この状態が続くと、タスクの滞留と複数主体の待機が長時間化し、協調実行能力が低下する。

本事例では、このような状態に対して「継続可能な協調実行状態への移行」を目標状態入口として設定し、MES、WCS、実行主体、経路資源、許可、ステーション状態を同じ協調判定の対象として整理する。

群制御・協調層では、入口ごとの CAE-SDB 判定に加えて、群全体として停滞が成立しているか、また現在の停滞がどの構造に該当するかも分析する。これらは別の分析結果として保持し、制御優先度調停で合わせて扱う。

本事例は、次の9ステップに沿って説明する。

1. 現在状態
2. 目標状態 / 目標状態入口
3. PCN：関連状態取得と C / A / E 状態マッピング
4. 前制御判定と群制御・協調分析
5. 制御優先度調停
6. 複数経路制御
7. 現在の入口に対する制御結果
8. 制御経路の実行 / 後続の目標状態入口と実行結果
9. 状態遷移判定履歴

基礎概念については、以下を参照できる。

• 中核概念
• TPCA / PCN 状態遷移前制御アーキテクチャ｜ホワイトペーパー

事例対象

本事例の対象は、MES / WCS 協調停滞診断モジュールである。

本モジュールは製造現場の協調層に位置し、MES のタスクとステーション要求、WCS のスケジューリングと搬送タスク、AGV / AMR などの実行主体状態、経路・共有資源状態、区域許可・安全許可、ステーション受入状態、下流状態、群全体の運転指標を扱う。

AGV / AMR の群制御搬送は代表的な適用場面の一つである。本事例では、より一般的な製造現場の協調停滞を対象とし、複数の単体設備に明確な故障がなくても、システム全体として実行が継続できない状態を扱う。

図：協調停滞診断モジュールは、MES、WCS、搬送主体、ステーション、経路資源、許可状態、下流状態を取得し、同一の協調状態遷移に関連付ける。

以下の数量と状態の組合せは、本公開事例を説明するための例示値であり、特定の実案件データではない。群全体の停滞判定に用いる具体的な閾値、継続時間窓、完全な構造分類ルールは、本公開事例では扱わない。

1. 現在状態

現在、システムは完全停止には至っていない。

稼働中タスク 42 件のうち、25 件は実行済みまたは進行中で、17 件は継続待機または未実行となっている。実行主体はオンラインで、ステーション要求も存在する。重大な設備アラームは発生しておらず、一部の経路も利用可能である。

一方で、複数の主体が継続して待機し、一部のタスクは長時間未実行のまま残っている。

現在状態は、協調実行が継続的に阻害されている状態として扱う。

群全体として停滞が成立しているか、また現在の阻害がどのような構造によって生じているかは、後続の分析で判定する。

2. 目標状態 / 目標状態入口

本事例では、システム全体の協調実行状態を対象とする。

目標状態は、

継続可能な協調実行状態

である。

対応する目標状態入口は、

継続可能な協調実行状態への移行

である。

継続可能な協調実行状態とは、現在のタスク、実行主体、資源、許可、経路、ステーションの関係が、システム全体として次の処理を継続できる状態を指す。

PCN は、現在の協調状態とこの目標状態入口の間に配置される。

以降の状態マッピング、CAE-SDB 判定、群全体の停滞判定、構造分類、制御処理は、この協調入口を基準として行う。

3. PCN：関連状態取得と C / A / E 状態マッピング

PCN は、現在の協調入口に直接関係する状態を各システムから取得し、今回の状態遷移で担うエンジニアリング上の役割に基づいて C / A / E 状態マッピングを行う。

本事例では、タスク存在を C、資源ロック状態と安全許可を A、実行主体オンライン、搬送経路利用可能状態、ステーション受入状態を E に関係する状態として扱う。

入口に直接関係する状態は CAE-SDB 判定へ入力する。

これとは別に、群全体の運転状態から未実行率、補助実行率、エネルギー補給率、許可未成立率などの群指標を算出し、停滞判定と構造分類に使用する。

群指標は群制御・協調層の分析情報として扱い、CAE-SDB 判定結果には含めない。

4. 前制御判定と群制御・協調分析

今回の例では、タスクが存在し、実行主体はオンラインで、安全許可も成立している。一部の経路は利用可能で、ステーションにも実行要求がある。

資源ロック状態はシステム間で同期していない。

現在の協調入口では、資源ロックを A：許可状態として扱う。

資源ロック用インターフェース自体は確立されているが、運転中のロック状態にシステム間の不一致があり、現在の入口に対する有効な許可根拠として使用できない。

この状態を A-D と判定する。

CAE-SDB 判定結果：
A-D

判定内容：
資源ロック状態がシステム間で同期しておらず、
現在の協調入口に対する有効な許可根拠として使用できない

群制御・協調層では、複数のタスクと実行主体の運転状態を集約して分析する。

本事例では、群全体の未実行率が停滞判定条件を満たしている。補助実行率は資源競合型の特徴を示しており、エネルギー補給率に偏りはない。許可未成立率からも、割当制約型を主要因と判断する特徴は認められない。

分析結果は次のとおりである。

群全体の停滞判定：
成立

停滞構造分類：
資源競合型

A-D は現在の協調入口に関係する状態判定であり、「停滞成立 / 資源競合型」は群制御・協調層の分析結果である。

それぞれの結果を保持したまま、制御優先度調停へ入力する。

本公開事例では、具体的な比率閾値、継続時間窓、完全な構造分類ルールまでは扱わない。

関連定義については、以下を参照できる。

• なぜ CAE-SDB なのか？——目標状態入口前の二軸構造化分析法
• なぜ MES / WCS は状態を記録できても、停滞の理由を説明できないのか？

5. 制御優先度調停

制御優先度調停の時点では、資源ロック状態に A-D があり、群全体の停滞判定は成立、停滞構造は資源競合型となっている。安全許可は成立している。

この状態から協調実行を回復させるには、資源ロック状態の不整合と資源競合の双方に対応する必要がある。

本事例では、資源ロック状態の不整合解消を優先し、あわせて影響経路の調整と影響タスクの再割当てを行う。

優先処理：
資源ロック状態の不整合解消

同時に行う調整：
搬送経路調整
タスク再割当て

6. 複数経路制御

制御優先度調停の結果に基づき、今回の協調入口では次の処理を複数経路制御として構成する。

• 資源解放
• 搬送経路調整
• タスク再割当て

本事例では、これらを協調層の調整処理として扱う。

どのシステムが資源解放を実行するか、どのスケジューリングシステムがタスクを再割当てするか、経路変更を自動実行するか、人による確認を必要とするかは、既存の MES、WCS、スケジューリングシステム、現場制御システムのインターフェース、責任分担、制御権限によって決まる。

実際の制御実行は、それぞれの既存システムの責任範囲に従う。

7. 現在の入口に対する制御結果

現在の目標状態入口は「継続可能な協調実行状態への移行」である。

この入口に対する制御結果は、

現時点では移行しない

となる。

資源ロック状態に A-D があり、群全体の停滞も資源競合型として成立しているため、必要な調整処理を先に実行する。

調整後、協調状態が継続可能な条件へ回復したかを、更新後の状態に基づいて再判定する。

8. 制御経路の実行 / 後続の目標状態入口と実行結果

選択された調整処理は、対応する制御権限を持つ既存システムが実行する。

処理の進行に伴い、資源ロック状態はシステム間で再同期され、共有資源の占有関係が再調整される。影響経路は再設定され、影響タスクは再割当てされる。

本事例では、処理完了後に次の状態となったものとする。

資源ロック状態：
再同期

主要搬送経路：
利用可能状態へ復帰

影響タスク：
再割当て完了

継続待機または未実行タスク：
減少

群全体の未実行率：
停滞判定条件を下回る

実行結果として、資源ロック関係の再同期、主要搬送経路の復帰、影響タスクの再割当て完了、群全体の未実行状態の減少を記録する。

これらは次回判定に使用する新しいエンジニアリング状態事実となる。

現在のシステムが「継続可能な協調実行状態」へ移行できるかどうかは、更新後の状態を使って同じ入口で再判定する。

代替搬送経路、退避経路、異常系への分岐など、別の目標状態または目標実行経路が選択された場合は、新しい目標状態入口を設定し、対応する PCN が独立して前制御判定を行う。

9. 状態遷移判定履歴

今回の協調入口については、次のような状態遷移判定履歴（PCN Trace）を記録できる。

この履歴では、MES、WCS、実行主体、資源、許可システムに分散していた状態を、同じ協調入口の判定に関連付けている。

入口レベルの A-D と、群制御・協調層の「群全体の停滞判定 = 成立 / 停滞構造分類 = 資源競合型」は、それぞれ別の分析結果として記録する。

そのうえで、制御優先度調停、複数経路制御、実行結果までを同じ状態遷移判定履歴に関連付ける。

後続処理によって新しい目標状態入口が成立した場合は、その入口を担当する PCN が新しい状態遷移判定履歴を記録する。

PCN Trace の詳細については、以下を参照できる。

なぜ PCN Trace は新しいエンジニアリングデータなのか？

事例まとめ

本事例の開始時点では、タスクが存在し、実行主体はオンラインで、ステーション要求もあり、一部経路は利用可能である。単体設備には重大アラームがない。

一方、複数タスクが継続して未実行となり、複数主体が待機し、システム全体の協調実行は阻害されている。

目標状態入口を「継続可能な協調実行状態への移行」として整理すると、資源ロック状態の非同期が現在の入口における A-D として現れる。

群全体の運転データからは停滞判定が成立し、停滞構造は資源競合型と判断される。

これらの結果に基づき、資源ロック状態の不整合解消を優先し、搬送経路調整とタスク再割当てを行う。処理後は、資源ロック関係が再同期し、主要搬送経路が利用可能状態へ復帰し、群全体の未実行状態が減少する。

本事例によって明確になるエンジニアリング情報

本事例では、分散していた状態を一つの目標状態入口に関連付け、協調入口に関係する状態について CAE-SDB 判定を行う。同時に、群全体の停滞判定と構造分類を別の分析結果として保持し、制御優先度調停で両者を扱う。

状態、判定、停滞構造、制御、実行結果を同じ状態遷移判定履歴に記録することで、MES、WCS、搬送主体、共有資源、許可システムに分散していた情報を、一連のエンジニアリング関係として追跡できる。

さらに読む

• なぜ MES / WCS は状態を記録できても、停滞の理由を説明できないのか？
• なぜ CAE-SDB なのか？——目標状態入口前の二軸構造化分析法
• なぜ PCN は TPCA の最小エンジニアリングノードなのか？
• なぜ PCN Trace は新しいエンジニアリングデータなのか？
• 複数の PCN はどのように状態遷移前制御ネットワークを形成するのか？
• なぜ OEE の後に PCN が必要なのか？
• TPCA / PCN 状態遷移前制御アーキテクチャ｜ホワイトペーパー

バージョン情報

本稿は、TPCA / PCN を MES / WCS 協調停滞診断へ適用した公開事例である。

• Public Case Version 1.0：2026-06-30 公開。
• Public Case Version 1.2：2026-08-20。PCN、CAE-SDB 判定結果、制御優先度調停、複数経路制御、状態遷移判定履歴の表現を統一。
• Public Case Version 1.3：2026-08-21。時間情報 T および状態インスタンスに関する説明を追加。
• Public Case Version 1.4：2026-08-25。CAE-SDB 二軸構造に基づいて事例表現を統一し、停滞判定、構造分類、CAE-SDB 判定結果の処理順序を整理。
• Public Case Version 1.5：2026-09-10。共通の9ステップの分析手順に基づいて本文を再構成。現在状態と群全体の停滞判定の順序を明確化し、診断モジュールと既存制御システム間の実行責任境界を整理。
• Public Case Version 1.6：2026-09-30。複数経路制御後の処理関係を明確化。群全体の未実行率、群全体の補助実行率、群全体のエネルギー補給率、群全体の許可未成立率など、群制御・協調層で用いる指標表現を整理。
• Public Case Version 1.7：2026-10-03。日本語表現を整理し、群指標、制御処理、状態遷移判定履歴の記述を統一。

著者：全野南政 / Nansei Zenno