前提：規制は「制約」ではなく「与件」として扱う
中国拠点のMESアーキテクチャを規定する規制側の条件は、2024年3月22日施行の「促进和规范数据跨境流动规定」以降、リスクベース・アプローチへ転換しています。B2Bの日系工場の多くは年間累計10万人未満の非センシティブ個人情報の移転として申告免除の枠に収まります。規制の中身は中国のデータ越境規制は緩和されているで詳述しました。本記事では、その条件を与件として、実装で決めなければならない設計判断だけを扱います。
設計上、規制から導かれる制約は実質的に次の2つに集約されます。
- 個人が特定できるデータ（作業者ID・氏名・生体情報と紐づいた実績）は、中国域内に留めるのが最も安全で、越境させる場合は個別同意・通知・PIA（個人情報保護影響評価）が必要になる
- 重要データ（重要数据）に該当すると判定された場合は安全評価が必要になるが、製造業の多くの業種でカタログが未確定であり、該当性が後から変わり得る
2番目が設計に効きます。「後から域内に閉じ込めなければならなくなる可能性」を織り込んだ構成にしておく必要がある、ということです。
データ種別ごとに置き場所を決める
最初にやるべきは、MESが扱うデータを種別に分解し、それぞれの配置を決めることです。「MESのデータ」と一括りにすると設計できません。
| データ種別 | 配置 | 理由と設計上の注意 |
|---|---|---|
| 設備の生信号・時系列（PLC／SCADA由来） | 中国域内 | 量が大きく越境の帯域コストが見合わない。重要データ判定の対象になり得る |
| ロット・工程の実績（作業者ID紐付き） | 中国域内 | 作業者IDと紐づいた瞬間に個人情報になる。ここが設計上の最大の分岐点 |
| ロット・工程の実績（作業者ID非紐付き） | 域内保持＋集計を本社へ | 個人情報に当たらない。粒度をどこで落とすかを設計で決める |
| 品目・BOM・工程マスタ | 本社が正、域内にレプリカ | 統一しないとグローバル分析が成立しない。配布方向は片方向にする |
| KPI定義・計算ロジック | 本社が正 | 定義がずれると拠点比較が無意味になる（ISO 22400の記事） |
| 集計済みKPI（日次・ロット単位） | 本社へ送信 | 個人情報を含まない粒度まで落としてから送る |
| 帳票テンプレート・画面定義 | 域内 | 中国式の税務・環境・安全報告フォーマットに合わせる必要がある |
| ユーザーアカウント・権限 | 域内（本社と分離） | 統合IDaaSを使う場合、認証情報の越境が発生しないか要確認 |
| 監査証跡（audit trail） | 域内 | 等級保護の要求と、規制当局への提出に備える |
この表で最も重要なのは、実績データを「作業者ID紐付き」と「非紐付き」に分けて設計するという点です。多くのMESはロット実績に作業者を必ず記録しますが、本社へ送る集計の段階でこれを落とすのか、そもそも別テーブルに分けて持つのかで、後の運用負荷が大きく変わります。
推奨は別テーブルに分けて持ち、本社送信用のビューには最初から含めない構成です。集計時に落とす設計だと、新しいレポートを作るたびに個人情報の混入チェックが必要になります。
3つの構成パターンと、選択の条件
実装の全体像には、大きく3つのパターンがあります。
パターンCは、回線が切れると中国拠点の操業が止まるという可用性の問題も抱えます。中国から日本へのインターネット接続は品質が安定しないことがあり、MESのように秒単位の応答が要る用途では専用線やクラウド専用接続が前提になります。この時点でコストがパターンBを上回ることが少なくありません。
パターンBの実装で必ず詰まる5つの論点
第一に、マスタ配布の方向を片方向に固定することです。 品目・BOM・工程マスタは本社が正、中国はレプリカ。中国側で追加した拠点固有品目は、本社マスタに登録してから配布し直す運用にします。双方向同期にすると、コード衝突とマージ競合が必ず発生し、数年で誰も手を出せない状態になります（マルチサイトMESの設計）。
第二に、拠点固有の属性を「拡張フィールド」で吸収することです。 中国拠点にしかない検査項目や帳票項目は必ず出ます。これを本社マスタの標準項目に追加していくと、他拠点にとって無意味な項目が増え続けます。拠点固有属性は拡張領域に隔離し、本社の分析対象外と明示するのが定石です。
第三に、時刻の扱いです。 中国標準時（UTC+8）と日本標準時（UTC+9）の1時間差は、日次締めのKPIで必ず問題になります。実績データはUTCで保持し、表示のみタイムゾーン変換するのが原則ですが、「日次」の区切りをどちらの現地時間で切るかは業務判断です。稼働率や生産数量を拠点間で比較する際、この定義がずれると数字が合いません。
第四に、送信の粒度と頻度です。 日次バッチか、準リアルタイムか。準リアルタイムを選ぶと、集計前のデータが越境する経路が生まれやすくなります。推奨は域内で集計を完了させてから送る設計です。集計処理を本社側に置くと、生データを送る必要が生じます。
第五に、監査証跡の分離です。 誰がいつ何を変更したかの記録は域内に残す必要がありますが、本社の内部統制でも参照が必要になります。監査証跡そのものを越境させず、本社からのオンデマンド照会（必要時に域内システムへ問い合わせる）にするのが現実的です。
製品選定の基準がどう変わるか
このアーキテクチャを前提にすると、MES製品の評価軸に次の項目が加わります。機能一覧では判別できない項目ばかりである点に注意してください。
| 確認項目 | 落ちる製品の例 |
|---|---|
| データのホスティングリージョンを選択できるか | SaaS専用でリージョン固定の製品 |
| 同一製品で拠点ごとに独立インスタンスを立てられるか | マルチテナント前提でテナント分離ができない製品 |
| マスタの片方向配布・バージョン管理の仕組みを標準で持つか | 単一サイト前提の製品（配布を自作することになる） |
| 集計処理をインスタンス内で完結できるか | 分析機能がクラウド側にしかない製品 |
| 中国域内のインフラ（国産クラウド・国産DB）で動作保証があるか | 特定の海外クラウド前提の製品 |
| 中国語（簡体字）UIと中国式帳票の標準対応 | 翻訳ファイル提供のみで帳票は個別開発の製品 |
グローバルテンプレート型の運用を設計思想に組み込んだ製品、たとえばDELMIA Aprisoのように本社でプロセスモデルを定義して各拠点へ配布・バージョン管理する仕組みを持つ製品は、この観点では有利です。一方で、拠点ごとにインスタンスを立てる構成はライセンス費が線形に増えるため、費用面の検証が別途必要になります。
信創（国産化代替）要求がある拠点では、この評価軸に加えてスタック全体の認証が要求されます。OS・DB・CPUまで含めた組み合わせ認証が必要になるため、外資製品は「アプリは動くが認証が通らない」という形で落ちます（信創とMES選定の記事）。この場合はパターンAへ倒すか、中国拠点のみ別製品にするかの判断になります。
域内保持と本社連携を両立させるアーキテクチャ設計を、日中バイリンガル体制でご支援します。
よくある質問
中国拠点だけ別のMES製品にするのは、悪い設計ですか？
条件次第です。悪くないケースは、①本社側でマスタとKPI定義を統一でき、②中国拠点から送られる集計データのスキーマを本社が定義でき、③拠点数が少ない場合です。この3条件が揃えば、実行系の製品が違っても本社の分析は成立します。悪くなるのは、製品が違うことを理由にマスタとKPI定義まで分かれてしまうケースです。そうなると拠点間比較ができなくなり、中国拠点の状況が本社から見えなくなります。統一すべきは製品ではなく、マスタ・KPI定義・実績データモデルの3つです。
等級保護（等保2.0）はアーキテクチャにどう影響しますか？
等級によって影響の大きさが変わります。2級であればネットワーク分離・アクセス制御・ログ保管といった一般的なセキュリティ要求の範囲に収まり、アーキテクチャの骨格を変えるほどではありません。3級になると、年次の測評（監査）が必須になるほか、対象システムの範囲確定、ログの保管期間、運用体制の文書化まで求められます。設計上は、測評の対象範囲をMESのインスタンス単位で切れるようにしておくことが重要です。本社の基盤と密結合させると、測評の範囲が本社側まで広がりかねません。パターンBが有利なのはこの点でもあります。
