OEEの算出ロジック、定義がずれると拠点間で比較できない

同じ設備が78.6%にも62.9%にもなる

まず、比較不能がどう起きるかを具体的に見ます。同一機種の設備を持つ2拠点が、それぞれ自拠点の慣行でOEEを計算した場合の例です。

上の例では、拠点Aが78.6%、拠点Bが62.9%と表示されます。設備の実力は同じです。この状態で「拠点Bの改善が遅れている」と結論づけると、改善資源の配分を誤ります。

しかも厄介なのは、この5項目のうち現場が意識しているのはせいぜい1つか2つだという点です。残りは実装時にエンジニアが決めた既定値のまま動いており、誰も選択したことを覚えていません。OEEを拠点間で比較する意思があるなら、これらを明示的に決める作業を必ず通す必要があります。定義がずれる理由そのものはOEE（設備総合効率）はMESで改善するのかで扱っているので、ここでは実装側の論点に絞ります。

ISO 22400を出発点にすると、議論が3分の1で済む

自社で定義を一から議論すると、用語の合意だけで数か月かかります。出発点として使えるのが国際標準です。

ISO 22400-1:2014「Overview, concepts and terminology」が概念と用語を、ISO 22400-2:2014「Definitions and descriptions」がKPIの定義と計算式を規定しています。時間要素（planned busy time、actual production time など）が名前付きで定義されているため、「うちで言う稼働時間はこれのことです」と対応づけるだけで議論が進みます。

標準を使う正しいやり方は、そのまま採用することではなく、差分だけを文書化することです。

ISO 22400-2 の定義を基準とする。ただし当社では、需要不足による停止を planned busy time から除外する。この点が標準との差分である。

この1文があれば、後から誰が見ても計算の前提が分かります。逆に、標準を参照せずに自社用語だけで定義書を作ると、ベンダーやグループ会社との会話のたびに翻訳作業が発生します。

標準側の実装も進んでいます。工作機械向けのOPC UA情報モデルである umati / OPC 40501 は、ISO 22400準拠のKPI算出に対応しており、仕様は無償公開されています。設備側が標準準拠のKPIを出せるなら、MESが独自に計算する部分を減らせます。標準の中身はISO 22400、MESのKPIを標準で定義するで扱う予定です。

実装の中心は、設備状態の状態機械

OEEの計算式そのものは単純です。実装で難しいのは、設備が今どの状態にあるかを一意に決めることです。

図に示した2つの原則が、実装の核心です。

原則1：状態は常に排他。すべての状態の時間を合計すると、必ず暦時間に一致しなければなりません。合計が合わない実装は、どこかで時間が二重計上されているか、抜けています。稼働レポートの数字が合わないという相談の大半は、ここが原因です。

原則2：同時に成立した条件は、優先順位で1つに決める。段取り作業中に設備が故障した、材料待ちで停止している最中に後工程も詰まった——現実にはこうした重複が日常的に起きます。優先順位ルールを明文化していないと、MES製品ごとの既定値がそのまま社内標準になり、製品を入れ替えた瞬間に数字が変わります。

もうひとつ決めるべきなのが、チョコ停の閾値です。何秒未満の停止をDownとして計上せず、性能ロスとして扱うか。設備信号を自動収集すると、それまで人が記録していなかった数秒〜数十秒の停止が全部乗ってきます。閾値は「30秒」「1分」「3分」のいずれかが実務でよく使われますが、重要なのは値そのものより、閾値を変えたときに時間稼働率と性能稼働率のあいだで時間が移動するだけで、OEEの総合値はほとんど変わらないという性質を理解しておくことです。停止の記録設計はダウンタイムの記録と分析で扱っています。

時間バケットの境界と、事後修正の扱い

状態が正しく取れていても、集計の境界で数字はずれます。実装で決めるべき境界は3つです。

境界1：シフト跨ぎ。22時50分に始まった停止が、23時のシフト交代をまたいで23時20分まで続いた場合。前シフトに20分計上するか、両シフトに10分ずつ分割するか。分割しない実装では、シフト別のOEE合計と日次のOEEが一致しなくなります。日跨ぎ・月跨ぎでも同じ問題が起きるため、「イベントは境界で分割する」を原則に据えるのが安全です。

境界2：オーダー跨ぎ。同じ設備で複数のオーダーを連続して流したとき、停止をどのオーダーに帰属させるか。設備視点のOEEとオーダー視点の実績で数字が食い違う原因になります。設備視点を正とし、オーダー別は参考値と割り切る運用が実務的です。

境界3：カレンダーの定義。「1日」が00:00〜24:00なのか、夜勤開始の20:00からなのか。多拠点で時差がある場合、現地時間で集計するか、本社時間に揃えるか。グローバル展開では必ず問題になる項目です。マルチサイトMESの設計、共通と個別を分けるで扱う論点と直結します。

そして最も見落とされるのが、事後修正（retroactive edit）の扱いです。現場は翌日になってから「昨日の停止理由が違っていた」と修正します。このとき、

• すでに確定・報告済みの日次OEEを再計算して上書きするのか
• 修正履歴を残したうえで、確定値は動かさないのか
• 修正可能な期間を何日に設定するのか

を決めていない実装が非常に多く見られます。推奨は「確定日を設ける」構成です。翌営業日の正午に前日分を確定し、それ以降の修正は履歴として残すが確定値は動かさない。確定後に重大な誤りが見つかった場合のみ、権限者の承認で再確定する。この設計にしておくと、月次で報告した数字が後から変わる事態を防げます。

拠点間で揃える「OEE定義書」12項目

複数拠点で比較可能な数値を作るなら、次の12項目を1枚の文書にまとめ、全拠点で同じものを使ってください。逆に言えば、この12項目が揃っていないOEEは比較できません。

この文書を作る作業は、通常2〜3か月かかります。ただし作らなければ、拠点間の数字は永久に比較できません。マルチサイト展開のプロジェクトでは、テンプレート設計の初期フェーズにこの作業を組み込んでください。後から揃えようとすると、すでに各拠点が自分の数字で目標を設定しており、定義変更が「評価が下がる」という話に変質して合意できなくなります。

よくある質問

拠点ごとに事情が違うので、定義を完全に統一するのは無理では？

完全に統一する必要はありません。現実的な進め方は2階層にすることです。全拠点共通の「比較用OEE」を12項目の定義書どおりに1本計算し、これは拠点の裁量では変えられないものとします。加えて、拠点ごとの改善活動に使う「運用用OEE」を別に持ち、こちらは拠点の事情に合わせて定義してよいことにします。同じ測定データから2種類の集計を出すだけなので、実装コストはほとんど増えません。重要なのは、経営会議やベンチマークに使う数値がどちらなのかを明示することです。1本にまとめようとすると合意できませんが、2本に分ければ「比較用は共通、運用用は自由」という形で決着します。

設備からの信号だけでOEEを自動計算できますか？

時間稼働率と性能稼働率は自動化できますが、停止理由の分類と不良の判定は自動化できません。信号が示すのは「止まっている」ことだけで、それが故障なのか材料待ちなのか後工程詰まりなのかは、信号の組み合わせから推定するか、人が入力するしかありません。実装としては、状態の判定（止まっているか動いているか）を自動化し、理由の付与を人が行う分担が標準です。ただし、材料待ちと後工程詰まりは、前後工程の設備状態から自動判定できることが多いため、ここは自動化の余地があります。自動化率を上げる順序は、状態判定 → Starved/Blockedの自動推定 → 故障種別の自動分類（設備アラームコードとの紐づけ）です。最後の段階は設備側のアラーム体系の整備が前提になります。

OEEの計算をMESで行うか、BIツールで行うか、どちらがよいですか？

状態の判定と時間の積算はMES、可視化と多次元分析はBI、という分担が原則です。理由は、状態の判定にはイベントの順序と排他性の保証が必要で、これはリアルタイムにイベントを受け取っているMES側でしか正しくできないためです。BIツールで生データから状態を再構成しようとすると、境界の分割やイベントの重複解決を都度実装することになり、レポートごとに数字が違うという事態を招きます。MES側で状態と時間バケットまでを確定させ、BIにはその確定済みデータを渡す構成にします。BIで行うのは、期間・設備・品種・シフトといった軸での集計と可視化に限定します。この分担にしておくと、レポートが増えても数字の整合性が保たれます。

この記事を書いた人

S

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

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

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