MES / WCS 協調停滞診断モジュール事例

なぜ MES に状態が記録されていても、製造現場の停滞理由を説明しにくいのか？

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

推奨引用形式：

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

MES では、タスク、設備、ステーション、材料、アラーム、生産数量、生産実績などを記録できる。

WCS では、搬送タスク、車両状態、経路状態、資源占有状態、スケジューリング結果などを記録できる。設備システムでは運転、待機、アラーム、インターロックなどを記録でき、HMI には Ready、Waiting、Blocked、Pending などの運転状態が表示される。

しかし、多設備・多タスク・多システムが連携する製造現場では、次のような状態が発生することがある。

• タスクは生成されているが、実行が長時間進まない。
• 搬送主体はオンラインで、ステーションにも要求があるが、補給や搬送が継続的な実行につながらない。
• 個々の設備に明確な故障がなくても、システム全体のスループット低下が続く。
• MES、WCS、PLC、搬送主体、ステーションに状態記録があっても、協調処理がどこで阻害されているかを短時間で特定しにくい。
• オーダ変更、資源競合、許可待ち、下流受入待ち、手動確認、エネルギー補給などが同時に影響する。

本事例で扱う中心的な問いは、次のとおりである。

現在のシステムが、なぜ協調実行を継続できる状態へ移行できないのか。

本事例では、この問題を群制御協調層における 1 回の状態遷移として捉え、次の 9 ステップで整理する。

1. Current State（現在状態）

2. Target State（目標状態） / Target State Entry（目標状態入口）

3. PCN（前制御ノード）
   関連状態取得 + C / A / E 状態マッピング

4. 前置判定と群制御協調分析
   ├─ S / D / B 判定
   │  → CAE-SDB Result（CAE-SDB 判定結果）+ T（時間情報）
   └─ 群集約指標
      → 協調停滞の識別
      → 停滞構造の分類

5. Arbitration（制御優先度調停）

6. Multipath Control（複数経路制御）

7. Target State Entry に対する制御結果

8. 選択された制御経路の実行 → Execution Result（実行結果）

9. PCN Trace（PCN 状態遷移判定履歴）

この 9 ステップによって、

現在の協調状態から協調実行を継続できる状態へ移行しようとする 1 回の要求が、どの状態に基づいて判定され、協調停滞がどのように識別・分類され、どの制御を経て、どのような結果になったか

を一連の処理として確認できる。

基本概念については、以下を参照。

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

事例対象

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

本モジュールは製造現場の協調層に配置し、MES、WCS、搬送システム、設備ユニット、ステーション、バッファ、経路資源、許可システム、現場の実行主体などから関連状態を取得する。

AGV / AMR の群制御搬送を代表的な適用場面とし、次のような協調システムにも展開できる。

• 無人フォークリフトおよび自動搬送システム
• 複数設備による協調生産
• ラインサイド供給およびバッファ制御
• ステーション待機および受入制御
• 経路資源の競合
• エリア許可および資源ロックの調整
• 臨時オーダおよび優先度切替
• エネルギー補給の集中による実行能力低下

本事例では、TPCA / PCN の共通工程に加えて、群制御協調層に固有の処理として、群集約指標、協調停滞の識別、停滞構造の分類を扱う。

図：MES / WCS 協調停滞診断モジュールは製造現場の協調層に配置し、MES、WCS、搬送主体、設備、経路資源、ステーション、バッファ、安全・許可システムなどから関連状態を取得する。

1. Current State（現在状態）

本事例は、製造現場に有効なタスクと実行主体が存在しているものの、協調実行が継続的に阻害されている状態から開始する。

Current State は、例えば次のように整理できる。

Current State：

有効なタスクが存在
  +
実行主体がオンライン
  +
一部のタスクが継続的に未実行
  +
Waiting / Blocked / Pending 状態が継続
  +
協調実行が阻害されている

現場では、さらに次のような状態が同時に見えることがある。

ステーションに要求がある
搬送主体は移動可能
一部の経路は利用可能
単体設備に重大なアラームはない
一部のタスクは実行されている

この時点では、「協調実行が阻害されている」という現在状態を確認する。

群全体として停滞と判定できるか、どの停滞構造に該当するかは、後続の群制御協調分析で判定する。

また、今回の分析に含めるタスク、実行主体、資源、許可、ステーションの範囲を明確にし、同一の協調実行単位として扱う。

2. Target State / Target State Entry（目標状態・目標状態入口）

今回の Target State（目標状態）は、

Target State：協調実行を継続できる状態

とする。

対応する Target State Entry（目標状態入口）は、

Target State Entry：協調実行を継続できる状態への移行

である。

ここでいう「協調実行を継続できる状態」とは、タスク、実行主体、経路、資源、許可、ステーション、下流受入、結果書き戻しなどが相互に整合し、協調処理を継続できる状態を指す。

PCN は、現在の協調状態と Target State Entry の間に配置する。

Current State
協調実行が阻害されている状態
    ↓
PCN（Pre-Control Node / 前制御ノード）
協調実行を継続できる状態への移行前判定
    ↓
Target State Entry
協調実行を継続できる状態への移行
    ↓
Target State
協調実行を継続できる状態

以降の C / A / E 状態マッピング、S / D / B 判定、群制御協調分析、Arbitration（制御優先度調停）、Multipath Control（複数経路制御）は、すべてこの Target State Entry に対応付ける。

PCN と Target State Entry の関係については、以下を参照。

なぜ PCN は TPCA の最小エンジニアリングノードなのか？

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

協調停滞では、単一設備の状態だけでなく、複数のタスク、実行主体、資源、経路、ステーション、許可、下流受入などを確認する必要がある。

PCN は、「協調実行を継続できる状態への移行」に関係する状態を各システムから取得する。

取得した状態を、今回の Target State Entry における役割に基づいて C / A / E の状態変数領域へ整理する。

C = Condition（条件状態）
A = Authority（許可状態）
E = Execution Chain（実行チェーン状態）

本事例では、例えば次のように整理できる。

例えば、

タスク状態 → C：条件状態
エリア許可 → A：許可状態
ステーション受入状態 → E：実行チェーン状態

と整理できる。

タスク状態は C：Condition（条件状態）、資源ロックやエリア許可は A：Authority（許可状態）として異なる状態変数領域へ整理し、それぞれに必要な判定を行う。

また、搬送主体がオンラインであっても、経路、ステーション、バッファ、下流受入などが継続できなければ、E：Execution Chain（実行チェーン状態）に関係する問題となる。

群集約指標は、これらの個別状態を群全体の観点から把握するため、後続の群制御協調分析で生成する。

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

関連状態取得と C / A / E 状態マッピングの後、同じ Target State Entry に対して次の二つの処理を行う。

A. S / D / B 判定
   → CAE-SDB Result（CAE-SDB 判定結果）+ T（時間情報）

B. 群制御協調分析
   → 群集約指標
   → 協調停滞の識別
   → 停滞構造の分類

CAE-SDB 判定と群制御協調分析は、基本的に別の評価として整理し、それぞれの結果を後続の Arbitration（制御優先度調停）へ渡す。

4.1 S / D / B 判定

PCN は、今回の Target State Entry に必要な関連状態に対して S / D / B 判定を行う。

S = Structure（構造完全性）
D = Dynamics（動的時系列有効性）
B = Boundary（制御境界）

本事例における代表的な確認内容は次のとおりである。

C / A / E の状態変数領域と S / D / B の判定特性を組み合わせることで、9 つの CAE-SDB 判定座標を構成できる。

本事例では、「協調実行を継続できる状態への移行」という Target State Entry に対して、代表的なエンジニアリング上の問題を次のように整理できる。

この 9 つの判定座標は、今回の Target State Entry において発生し得る状態判定上の問題を整理するために使用する。

1 回の状態遷移前制御で、9 つすべての CAE-SDB Result を形成する必要はない。

今回の Target State Entry に対して対応する判定ルールが定義され、判定に必要な根拠を取得でき、実際に S / D / B 判定を行った場合に、その結果として該当する CAE-SDB Result を形成する。

例えば、

資源ロックのインターフェース：接続済み
資源ロック状態：長時間未更新

という状態を考える。

この資源ロック状態が今回の Target State Entry で A：Authority（許可状態）にマッピングされ、D 判定の結果、現在の判定根拠として使用できないと判断された場合、

A-D：
資源ロック状態を、今回の Target State Entry に対する
有効な許可状態として使用できない

という CAE-SDB Result（CAE-SDB 判定結果）を形成できる。

また、

下流ステーション：受入可能
状態更新：長時間なし

という状態が E：Execution Chain（実行チェーン状態）にマッピングされている場合は、

E-D：
下流受入状態を、今回の Target State Entry に対する
有効な実行チェーン状態として使用できない

と整理できる。

さらに、

ステーション受入状態：現在有効
ステーション容量：事前に定義した上限に到達

という状態について、対応する B 判定を行った場合は、

E-B：
現在有効なステーション受入能力が、
今回の協調実行入口に対する制御境界に達している

という CAE-SDB Result を形成できる。

S / D / B は C / A / E の状態変数を分析するための判定特性であり、対応する判定が実際に行われ、その結果が得られた場合に CAE-SDB Result を形成する。

時間情報 T は、今回使用した状態および判定結果と関連付けて保持する。

4.2 群集約指標

単体状態だけでは、群全体の協調状態を把握しにくい場合がある。

そのため、本事例では複数の実行主体、タスク、資源、許可などの状態を集約し、群集約指標を生成する。

代表的な指標には、次のようなものがある。

群全体の未実行率
群全体の補助実行率
群全体のエネルギー補給率
群全体の許可未成立率

必要に応じて、経路資源占有、ステーション受入、重要タスクの継続未実行なども群全体の状態を把握するための情報として扱う。

群全体の未実行率は、有効な実行要求が存在する中で、実行へ移行していない主体の割合を群単位で把握するための指標である。

群全体の補助実行率は、直接的なタスク実行ではなく、移動、迂回、待避、資源取得などの補助的な動作状態にある主体の割合を把握するための指標である。

群集約指標の具体的な算出式、分母定義、閾値は、対象システムに応じて設定する。

群集約指標は、主として群制御協調分析に使用する。なお、特定の群集約指標について、今回の PCN における C / A / E の役割が明確に定義され、対応する S / D / B 判定が設定されている場合は、その判定結果を CAE-SDB Result（CAE-SDB 判定結果）として形成することもできる。

4.3 協調停滞の識別

群集約指標を生成した後、現在の協調阻害状態が、群全体として協調停滞の判定条件を満たしているかを確認する。

例えば、次のような状態関係を確認する。

有効なタスクが存在
        +
複数の実行主体が有効な実行状態へ移行しない状態が継続
        +
群集約指標が事前に定義された判定条件を満たす
        ↓
協調停滞を識別

判定条件を満たした場合は、

協調停滞の識別結果：協調停滞あり

とする。

条件を満たしていない場合は、現在の協調阻害状態として記録し、この時点では群全体の協調停滞とは判定しない。

4.4 停滞構造の分類

協調停滞と判定した場合は、群集約指標、タスク、許可、資源、実行状態、CAE-SDB Result（CAE-SDB 判定結果）などから、停滞構造を整理する。

本事例では、代表的な停滞構造を次の 4 種類に分ける。

割当制約型

代表的な状態：

• 有効なタスクが存在する。
• 複数の実行主体が長時間実行へ移行していない。
• タスク割当、許可、資源解放、資源ロックなどに関係する状態が実行開始条件を満たしていない。

資源競合型

代表的な状態：

• 実行主体が移動、迂回、待機、共有資源の取得などを継続している。
• 経路、交差点、自動扉、エレベータ、ステーションなどの共有資源に競合が発生している。
• 補助的な実行が多い一方で、有効タスクの進行率が低下している。

エネルギー偏在型

代表的な状態：

• 多数の実行主体が同じ時間帯に充電またはその他のエネルギー補給状態へ移行している。
• 実タスクへ割り当て可能な実行主体の比率が低下している。
• エネルギー補給状態の分布が協調実行能力に影響している。

未確定型

現在取得できている関連状態、群集約指標、CAE-SDB Result（CAE-SDB 判定結果）などから、いずれの型にも明確に分類できない場合は、未確定型として記録する。

その場合は、対象時間帯の状態記録を拡充し、後続の確認・分析に利用する。

未確定型
→ 関連状態・群集約指標の記録を拡充
→ 後続の分析
→ 新しい停滞パターンを確認

ここでいう停滞構造の分類は、群制御協調層における現象整理であり、S：Structure（構造完全性）とは別の処理である。

図：PCN では、関連状態に対する CAE-SDB 判定と、群集約指標から行う協調停滞の識別・停滞構造の分類をそれぞれ形成し、両方の結果を Arbitration（制御優先度調停）へ渡す。

5. Arbitration（制御優先度調停）

1 回の Target State Entry では、次のような複数の結果や制約が同時に存在する場合がある。

CAE-SDB Result（CAE-SDB 判定結果）
協調停滞の識別結果
停滞構造の分類結果
重要な許可
安全上の制約
その他の制御制約

例えば、本事例で次の状態が確認されたとする。

CAE-SDB Result（CAE-SDB 判定結果）：
  A-D
  資源ロック状態を現在の判定根拠として使用できない

群集約指標：
  群全体の未実行率が停滞識別条件を満たす

協調停滞の識別結果：
  協調停滞あり

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

重要な許可：
  安全許可は成立

Arbitration（制御優先度調停）では、次の情報をもとに、今回の Target State Entry に対する制御上の優先関係を処理する。

• CAE-SDB Result（CAE-SDB 判定結果）
• 協調停滞の識別結果
• 停滞構造の分類結果
• 重要な A：Authority（許可状態）
• 安全上の制約
• 今回の Target State Entry に適用する制御ルール
• 選択可能な制御経路

重要な A は、Target State Entry に対する独立した必要制約となる。

例えば、重要な安全許可が成立していない場合は、他の状態が条件を満たしていても、協調実行を継続できる状態への移行を許可しない。

Arbitration が扱うのは、

複数の判定結果、群全体の協調停滞状態、制御制約が同時に存在するとき、どの処理を優先するか

である。

6. Multipath Control（複数経路制御）

Arbitration の結果に基づいて、PCN は今回の Target State Entry に対する Multipath Control（複数経路制御）を形成する。

代表的な制御経路には、次のようなものがある。

通常実行の継続
待機
タスク再割当要求
資源解放要求
経路・通行権の調整要求
流量制限
バッファ振り分け
下流調整
エネルギー補給方針の調整
手動確認
移行禁止
異常隔離
詳細記録

例えば、次の状態が確認されているとする。

協調停滞の識別結果：
  協調停滞あり

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

CAE-SDB Result（CAE-SDB 判定結果）：
  A-D
  資源ロック状態を現在の判定根拠として使用できない

この場合、制御優先度調停の結果として、例えば次の Multipath Control を形成できる。

Multipath Control：

資源解放要求
  +
経路調整要求
  +
タスク再割当要求

本モジュールは、今回の Target State Entry に対する構造化された制御結果、制御要求、または調整要求を形成する。

実際の資源解放、タスク再割当、経路変更などの群制御処理は、既存の WCS、スケジューリングシステム、または現場制御システムが、それぞれのインターフェースと制御権限に基づいて実行する。

PCN
  → 判定
  → Arbitration
  → Multipath Control / 制御要求
        ↓
既存 WCS / スケジューリングシステム / 制御システム
  → 実際の群制御処理

7. Target State Entry（目標状態入口）に対する制御結果

今回の代表状態を次のように整理する。

タスク = 存在
実行主体 = オンライン
資源ロック状態 = 判定根拠として使用不可
安全許可 = 成立
群全体の未実行率 = 停滞識別条件を満たす
協調停滞の識別結果 = 協調停滞あり
停滞構造の分類 = 資源競合型

これに対して、

CAE-SDB Result（CAE-SDB 判定結果）：A-D

が形成され、Arbitration の結果として、

Multipath Control：

資源解放要求
  +
経路調整要求
  +
タスク再割当要求

が選択されたとする。

今回の「協調実行を継続できる状態への移行」という Target State Entry に対する制御結果は、

Target State Entry に対する制御結果：
協調実行を継続できる状態への移行を保留する

となる。

この工程では新たな制御経路の選択は行わず、第 5 工程の Arbitration と第 6 工程の Multipath Control で形成した結果を、今回の Target State Entry に対する制御結果として明確にする。

8. 選択された制御経路の実行 → Execution Result（実行結果）

今回選択された制御経路は、

資源解放要求
  +
経路調整要求
  +
タスク再割当要求

である。

これらの要求を受け、既存の WCS、スケジューリングシステム、または現場制御システムが実際の処理を行う。

今回の Target State Entry では移行を保留
    ↓
異常な資源占有や失効した資源ロックを解消
    ↓
経路・通行権を再調整
    ↓
影響を受けたタスクを再割当
    ↓
新しい協調運転状態を形成

処理後、例えば次の状態になったとする。

資源ロック = 整合した状態へ回復
主要経路 = 利用可能
影響タスク = 再割当完了
群全体の未実行率 = 停滞識別条件未満

この場合の Execution Result（実行結果）は、

Execution Result：
  資源ロックと経路割当が整合した状態へ回復し、
  影響を受けたタスクが再び実行可能となった

と記録できる。

その後、再び「協調実行を継続できる状態への移行」が要求された場合は、新しい Current State から同じ Target State Entry に対して改めて判定を行う。

9. PCN Trace（PCN 状態遷移判定履歴）

PCN Trace には、1 回の Target State Entry に対して、判定に使用した状態、CAE-SDB Result（CAE-SDB 判定結果）、群制御協調分析の結果、Arbitration、Multipath Control、Target State Entry に対する制御結果、Execution Result（実行結果）を関連付けて記録する。

本事例の記録例を次に示す。

【PCN】：
  協調実行入口 PCN

【Current State（現在状態）】：
  協調実行阻害 / 複数主体の待機が継続

【Target State（目標状態）】：
  協調実行を継続できる状態

【Target State Entry（目標状態入口）】：
  協調実行を継続できる状態への移行

【主な関連状態】：
  タスク = 存在
  実行主体 = オンライン
  資源ロック状態 = 判定根拠として使用不可
  安全許可 = 成立
  下流受入 = 可能

【C / A / E 状態マッピング】：
  タスク状態 → C：条件状態
  資源ロック状態 → A：許可状態
  下流受入状態 → E：実行チェーン状態

【S / D / B 判定】：
  資源ロック状態
    → D：動的時系列有効性
    → 長時間未更新のため判定根拠として使用不可

【CAE-SDB Result（CAE-SDB 判定結果）】：
  A-D

【群集約指標】：
  群全体の未実行率 = 停滞識別条件を満たす
  経路資源の占有率 = 高い状態が継続

【協調停滞の識別結果】：
  協調停滞あり

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

【重要な許可】：
  安全許可 = 成立

【Arbitration Result（制御優先度調停結果）】：
  資源競合に関係する判定結果を優先して処理
  協調実行を継続できる状態への移行を保留

【Multipath Control（複数経路制御）】：
  資源解放要求
    +
  経路調整要求
    +
  タスク再割当要求

【Target State Entry に対する制御結果】：
  協調実行を継続できる状態への移行を保留

【選択された制御経路】：
  資源解放要求
    → 経路調整要求
    → タスク再割当要求

【制御実行主体】：
  既存 WCS / スケジューリングシステム / 現場制御システム

【Execution Result（実行結果）】：
  資源ロックと経路割当が整合した状態へ回復し、
  影響を受けたタスクが再び実行可能となった

【時間情報】：
  T

【履歴識別子】：
  PCN-COLLAB-XXXX

この PCN Trace から、

どの状態が協調実行を阻害していたか、群全体として協調停滞と判定されたか、どの停滞構造に分類されたか、どの制御経路が選択され、その実行結果がどうなったか

を一つの履歴として確認できる。

PCN Trace を継続して蓄積することで、例えば次の内容を分析できる。

• 停滞が頻発する Target State Entry
• 協調停滞の構造分布
• 許可や資源ロックに関係する反復問題
• 経路やステーションにおける協調問題
• エネルギー補給状態の偏り
• 頻発する CAE-SDB Result（CAE-SDB 判定結果）
• 頻発する Multipath Control
• 制御経路と Execution Result の関係
• エンジニアリング変更前後の変化
• 未確定型として記録された事象の後続分析

さらに、長期的には次のような観点で比較できる。

どの Target State Entry で停滞が頻発しているか
どの停滞構造が多く発生しているか
どの CAE-SDB Result と
どの停滞構造が同時に発生しやすいか
どの制御経路が繰り返し選択されているか
選択した制御と Execution Result の間にどのような関係があるか

PCN Trace の工程上の意味については、以下を参照。

• なぜ PCN Trace は新しいエンジニアリングデータなのか？
• 複数の PCN はどのように状態遷移前制御ネットワークを形成するのか？
• なぜ OEE の後に PCN が必要なのか？

事例まとめ

MES、WCS、設備、搬送システムには、タスク、実行主体、経路、資源、ステーション、許可など、多くの状態がすでに記録されている。

本事例では、それらを「協調実行を継続できる状態への移行」という明確な Target State Entry に対応付け、次の 9 ステップとして整理した。

1. Current State（現在状態）

2. Target State（目標状態） / Target State Entry（目標状態入口）

3. PCN（前制御ノード）
   関連状態取得 + C / A / E 状態マッピング

4. 前置判定と群制御協調分析
   ├─ S / D / B 判定
   │  → CAE-SDB Result（CAE-SDB 判定結果）+ T（時間情報）
   └─ 群集約指標
      → 協調停滞の識別
      → 停滞構造の分類

5. Arbitration（制御優先度調停）

6. Multipath Control（複数経路制御）

7. Target State Entry に対する制御結果

8. 選択された制御経路の実行 → Execution Result（実行結果）

9. PCN Trace（PCN 状態遷移判定履歴）

本事例では、CAE-SDB と群制御協調分析を別の処理として扱う。

CAE-SDB では、

C / A / E
×
S / D / B

の二軸から 9 つの判定座標を構成し、今回の Target State Entry に関係する状態判定上の問題を整理する。実際の運転では、今回の入口に定義された判定ルールに基づいて必要な CAE-SDB Result を形成する。

一方、群制御協調分析では、

群集約指標
→ 協調停滞の識別
→ 停滞構造の分類

によって、群全体の協調実行状態を分析する。

したがって、両者の役割は次のように整理できる。

CAE-SDB
  → 今回の Target State Entry に関係する状態を
    C / A / E と S / D / B の二軸で構造化判定する

群制御協調分析
  → 群全体の運転状態を集約し、
    協調停滞とその構造を分析する

両方の結果は Arbitration で統合され、Multipath Control、Target State Entry に対する制御結果、実際の群制御処理、PCN Trace へつながる。

この構成により、Waiting、Blocked、Pending などの状態表示に加えて、

どの Target State Entry で
どの状態が関係し
どの CAE-SDB Result が形成され
群全体として停滞と判定されたか
どの停滞構造であったか
どの制御経路が選択され
実際にどのような結果となったか

を同一の技術的な文脈で確認できる。

さらに読む

• なぜ 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 Result、Arbitration、Multipath Control、PCN Trace の表記を統一
• Public Case Version 1.3：2026-08-21 時間情報 T および状態遷移単方向性に関する説明を追加
• Public Case Version 1.4：2026-08-25 CAE-SDB の二軸構造に合わせて事例全体を整理し、停滞識別、構造分析、CAE-SDB Result、Arbitration、Multipath Control の処理関係を統一
• Public Case Version 1.5：9 ステップ構成をもとに本文を再構成

著者：全野南政 / Nansei Zenno