データは貯まっているのに使われていない、という事実から始める

実績分析の議論は、まず現状の数字を置いてから始めたほうが健全です。

収集データを効果的に活用できていると回答した製造業
43%
Rockwell Automation調査（17カ国1,560名／2026年7月28日公開）
MESをERP・PLM・品質・OTと完全統合できている割合
23%
同調査
MES購買要件の第1位に「統合性」を挙げた割合
44%
同調査

導入率93%に対して、活用できているという自己評価が43%です。この差は分析ツールの性能では説明できません。分析されないデータの大半は、そもそも「何かに答えるため」に設計されていないから使えないというのが実装現場での実感です。

たとえば「不良率を下げたい」という目的でMESを導入し、不良数と不良コードを記録したとします。しかし現場で本当に必要だったのは「不良が出た直前の設定変更は誰がいつ行ったか」でした。この問いに答えるには、不良の記録ではなく設定変更イベントのタイムスタンプが必要です。記録項目は目的から逆算しないと、揃っているのに答えられない状態になります。

作る前に「答えるべき問い」を10個書き出す

分析機能の設計を、画面レイアウトから始めてはいけません。次の形式で問いを列挙するところから始めます。

〈誰が〉〈どの頻度で〉〈何を判断するために〉〈どの数字を〉見るか

実際のプロジェクトで出てくる典型例を挙げます。

問い判断者・頻度必要な記録粒度よくある不足
昨日どのラインで何分止まったか製造課長・毎朝停止イベント（開始・終了時刻・理由コード）停止理由が「その他」に集中し分析不能
この不良の増加はいつから始まったか品質技術・週次不良を工程・設備・時間帯で分解できる粒度不良を製番単位でしか持たず時間軸で切れない
段取り替えは標準時間に収まっているか生産技術・月次段取り開始／終了の明示的な打刻段取りと稼働の境界が記録されていない
この製品の実際原価はいくらか原価管理・月次工数・材料消費・設備稼働の指図単位実績工数が日単位の集計で指図に割り当たらない
新人が担当した工程の不良率は高いか製造部長・四半期作業実績に作業者IDと力量ランクが付く作業者が班単位でしか記録されていない

10個書き出すと、必要な記録項目の8割が決まります。そして重要なのは、この表を作った時点で「今のMESでは答えられない問い」が可視化されることです。それが要件になります。

MESの分析とBIの境界をどこに引くか

「MESに分析機能があるならBIは要らないのか」という質問は、ほぼすべてのプロジェクトで出ます。判断基準は次の3点です。

基準1：データがMESの中で完結するか。 稼働・不良・工数のようにMESだけで完結する指標は、MESの標準分析で十分です。一方、「不良による損失金額」は原価マスタがERP側にあるため、MES単体では出せません。複数システムのデータを結合する必要が生じた時点で、BI（またはデータ基盤）の領域です。

基準2：更新頻度と応答性の要求。 現場端末で作業者が見る「今日の進捗」は秒〜分単位の鮮度が要り、MESの中で完結させるべきです。経営が見る月次推移は日次バッチで十分で、BIに寄せられます。

基準3：分析ロジックが変わる頻度。 分析軸を頻繁に変えるなら、MESの固定レポートより外部の分析基盤が適しています。MESのレポート改修はバリデーション対象になる場合があり（規制産業では特に）、改修のたびに検証工数が発生します。

なお、生値の長期保管はMESではなくヒストリアンの役目です。MESに秒単位のセンサ値を貯め込む設計は、性能と保守の両面で無理が来ます。

設計で決める3項目：タイムスタンプ・集計粒度・欠測

分析の信頼性は、次の3つの決めで大半が決まります。ここが曖昧な実績データは、どんな分析ツールを載せても使えません。

1. タイムスタンプの定義

「工程開始時刻」とは、作業者がボタンを押した時刻か、設備が動き始めた時刻か、材料を投入した時刻か。この定義がラインごとに違うと、拠点間の比較が成立しません。さらに、どの時計を正とするか（MESサーバ、PLC、端末）も決めます。設備側の時計がずれていて、停止時間がマイナスになる不具合は珍しくありません。時刻同期はNTPで統一し、収集時にサーバ時刻へ正規化するのが基本です。

2. 集計粒度と再集計の可否

日次サマリを持つのか、イベントだけ持って都度集計するのか。サマリを持つ場合は「過去分の訂正が入ったときに再集計されるか」を必ず決めます。訂正が反映されないサマリは、月次報告と現場の数字が合わない原因の第一位です。

3. 欠測と異常値の扱い

設備が通信断だった時間、作業者が打刻を忘れた工程をどう扱うか。選択肢は「欠測として除外」「直前値で補完」「手入力で補正（証跡付き）」の3つで、指標ごとに決めます。OEEの計画停止と非計画停止の切り分けも同じ問題で、OEEの算出ロジックは定義がずれると拠点間で比較できなくなります。

製品による実装差

分析まわりで製品差が大きいのは、機能の有無ではなく次の3点です。

  • データの外部取り出し口：標準でREST/GraphQL APIやビュー公開があるか、それともCSV出力しかないか。BI連携の工数がここで数倍変わります。Proficy 2026がGraphQLサブスクリプションに対応するなど、近年はストリーム的な取り出し口を持つ製品が増えています。
  • レポート定義の変更に開発が要るか：ノーコードでレポートを追加できる製品と、ベンダー作業が必須の製品があります。規制産業では前者でも変更管理の手続きが必要なので、「誰が変更でき、その記録がどう残るか」まで確認します。
  • AIによる自然言語照会の実装レイヤー：2026年のリリースでは、SiemensがOpcenter MES Medical Device 2607でMendixベースの自然言語AIアプリを提供し、RockwellもPlex Connected Workerに自然言語対話を追加しています。ただしこれらは既存データの照会UIであり、データの粒度が足りなければ答えは出ません。AIを載せる前提でも、この記事の前半で述べた記録設計は省略できません。
分析のために、まずデータレイクを作るべきですか？

順序が逆になりがちな論点です。答えるべき問いが決まっていない段階でデータレイクを作ると、格納だけが進んで活用が始まりません。AVEVAがAVEVA World 2026（2026年5月20日）で引用したGartnerの予測では、AI-readyなデータがないことを理由にAIプロジェクトの60%が2026年までに放棄されるとされています。裏を返せば、必要なのは「量」ではなく「文脈が付いたデータ」です。まず10個の問いに答えられる粒度でMES側の記録を整え、複数システムの結合が必要になった時点で基盤を検討する順序を推奨します。

実績入力の負担を増やさずに分析精度を上げる方法はありますか？

最も効果が大きいのは、人が入力する項目を減らして機械から取る項目を増やすことです。具体的には、①設備の稼働／停止は信号から自動取得し、人は理由コードだけを選ぶ、②数量は計数器やスキャンから取り、人は差異があるときだけ補正する、③時刻は打刻ではなく作業の開始・完了操作から自動生成する、の3点です。特に理由コードは、選択肢を15個以内に絞り、「その他」を選んだ場合は自由記述を必須にすると、後から分類できる形で残ります。選択肢が30個を超えると入力精度が落ちるというのが現場での経験則です。

拠点ごとに指標の定義が違います。統一すべきですか？

すべてを統一する必要はありませんが、経営が比較に使う指標だけは定義を統一する必要があります。現実的な進め方は、指標を「全社共通（定義固定・変更不可）」「拠点任意（定義自由）」の2階層に分け、前者を5〜10個に絞ることです。全社共通の指標は、計算式だけでなく分母の取り方（暦時間か負荷時間か）、除外条件（計画停止、試作分）まで文書化します。ここを曖昧にしたまま拠点横断のダッシュボードを作ると、数字の差が実力差なのか定義差なのか判別できず、議論が定義論争に費やされます。

この記事のテーマ
#データ基盤#ベンチマーク#運用保守

この記事を書いた人

S

株式会社サオス MESソリューション部

DELMIA Apriso を中核とした MES / 製造DX の導入・運用・人材育成を手がけるITコンサルティング企業。ISO 9001:2015 / ISO 27001:2022 認証取得。 日本・中国・米国で製造業のMES導入を手がけた実務者が、欧米・中国の一次情報にあたって書いています。

運営者情報　編集方針　株式会社サオスのサイト