この記事のポイント
OEE = 時間稼働率 × 性能稼働率 × 良品率で算出。85%はJIPM TPM Excellence Award自己評価票に参考値として登場する水準で、業界普遍の基準ではない
7大ロスは停止系・速度系・品質系の3群に整理し、それぞれ時間稼働率・性能稼働率・良品率のどこを削るかを紐付ける
現場で改善が続かない主因は「データ収集の主観性」「指標定義のバラつき」「打ち手の現場定着」の3層構造
AI活用は可視化→原因特定→予測→自律対応の4段階で、フェーズを飛ばして自律対応から入ると失敗する
AI×OEE改善は現状把握→ロス特定→PoC→ライン展開→全社展開の5ステップで、対象ラインの機会損失規模に応じてROIを試算

Microsoft MVP・AIパートナー。LinkX Japan株式会社 代表取締役。東京工業大学大学院にて自然言語処理・金融工学を研究。NHK放送技術研究所でAI・ブロックチェーンの研究開発に従事し、国際学会・ジャーナルでの発表多数。経営情報学会 優秀賞受賞。シンガポールでWeb3企業を創業後、現在は企業向けAI導入・DX推進を支援。
OEE(Overall Equipment Effectiveness/設備総合効率)は、公益社団法人日本プラントメンテナンス協会(JIPM)がTPM活動の中で提唱した設備KPIで、時間稼働率×性能稼働率×良品率の掛け算で算出します。
JIPMのTPM Excellence Award自己評価票ではOEEの参考値として75%・85%といった水準が示されており、ISO 22400-2にもKPI定義が採用された国際標準の指標です。
本記事では、OEEの計算式と7大ロス、現場で改善が続かない構造的な論点、AIを使う4つのパターン、AI予知保全との結節点、5ステップの進め方、国内外の代表事例までを、製造課長・生産技術の目線で2026年7月時点の最新情報で解説します。
目次
OEEとは?設備を「使いこなせているか」を1つの数字で表す指標
現場でOEE改善が詰まる論点——数字は出るが打ち手が続かない構造的な理由
OEE改善にAIを使う4つのパターン——可視化・原因特定・予測・自律対応
AI予知保全がOEEに効く理由——チョコ停・故障・速度低下の削減事例
AI×OEE改善プロジェクトの投資対効果と進め方——5ステップ
AI×OEE改善の事例とリファレンス——ダイキン×日立、Sight Machine、Microsoft Fabric、AVEVA
OEEとは?設備を「使いこなせているか」を1つの数字で表す指標

OEE(Overall Equipment Effectiveness/設備総合効率)とは、生産設備が本来の能力に対してどれだけ有効に稼働しているかを、時間・速度・品質の3つの側面から1つの数値に統合した設備KPIです。
公益社団法人日本プラントメンテナンス協会(JIPM)がTPM(Total Productive Maintenance)活動の中で1970年代に提唱し、ISO 22400-2:2014やIATF 16949にも標準指標として取り込まれています。
計算構造は「時間稼働率×性能稼働率×良品率」の掛け算で、各指標がそれぞれ80%でもOEEは51.2%にしかならないため、どの1指標が落ちても全体スコアが大きく削られる特性を持ちます。
「設備を新しくしたのに生産量が思うように伸びない」「稼働率だけ見ていて改善打ち手が続かない」——こうした現場感を持つ製造課長・生産技術にとって、OEEは投資判断とライン改善を同じ言語で扱うための共通指標として機能します。
OEEが2026年に再注目される理由

OEE自体は1970年代からある概念ですが、2026年時点で再び議論の中心になっているのは、現場データ基盤とAIの組み合わせによって指標と改善サイクルの距離が一気に縮まったからです。
- データ基盤の成熟:IoTセンサー・Microsoft Fabric等のデータ基盤で、OEEの3指標をリアルタイム計算し変動要因を秒単位で追跡できる環境が整った
- AIエージェントの登場:OEE低下の予兆検知・停止要因の一次分析・保全指示の起票までを自動化できる余地が広がった
ここでのポイントは、従来は月次で回していた「算出→議論→改善」のサイクルを、日次・シフト単位まで短縮して結び直す動きが加速している、という点です。
具体的なAI活用パターンや予知保全の効き方は後段の「OEE改善にAIを使う4つのパターン」「AI予知保全がOEEに効く理由」で扱います。
OEEの計算式——時間稼働率×性能稼働率×良品率と参考水準
OEEを扱ううえで最初に押さえておきたいのが、3つの下位指標の定義と、目安値の根拠です。
計算式そのものはシンプルですが、各指標の分母・分子をどう置くかが工場ごとに揺れるため、他社比較や自社の月次推移を語る際に食い違いが起きやすい部分でもあります。
以下の表で、OEEを構成する3指標の計算式と削られる要因を整理しました。
| 指標 | 計算式 | 削られる要因 |
|---|---|---|
| 時間稼働率(Availability) | 稼働時間 ÷ 負荷時間 | 故障・段取り替え・立ち上がり(社内ルールでダウンタイム扱いのチョコ停) |
| 性能稼働率(Performance) | (基準サイクルタイム × 加工数) ÷ 稼働時間 | 速度低下・チョコ停・空運転 |
| 良品率(Quality) | 良品数 ÷ 加工数 | 不良・手直し・立ち上がり時の初期不良 |
OEEは、この3指標をそのまま掛け算して算出します。各指標が90%でもOEEは72.9%、80%なら51.2%、70%なら34.3%にまで落ちる構造です。1つの指標が突出して悪いというより、3指標のバランスで全体スコアが決まるという点が改善設計上の重要な性質になります。

時間稼働率——負荷時間の定義でスコアが変わる
時間稼働率は、負荷時間(生産する予定だった時間)に対して、実際に設備が動いていた時間の割合です。
計算式は「稼働時間 ÷ 負荷時間 × 100」。ここで議論になりがちなのが、負荷時間から何を除くかという点です。
- 除くのが一般的: 計画的な保全時間、休憩、朝礼、生産計画のない時間
- 議論になる: 段取り替え時間、立ち上がり時間、計画的マイナー停止
段取り替えを負荷時間から除いてしまうと、時間稼働率は見かけ上高くなりますが、段取り替え自体の改善優先度が下がってしまいます。JIPMの標準運用では、段取り替えは負荷時間に含めて時間稼働率を圧迫させ、改善対象として明示するのが原則です。

性能稼働率——基準サイクルタイムの設定が難所
性能稼働率は、実際の稼働時間の中で本来の生産スピードがどれだけ出せていたかを示します。
計算式は「(基準サイクルタイム × 加工数)÷ 稼働時間 × 100」。ここで問題になるのが、基準サイクルタイムを何に置くかです。
過去実績の平均値に置くと、既に速度低下している状態を「基準」として固定してしまい、性能低下ロスが見えなくなります。
OEEの標準的な定義では、設備の設計能力(カタログ値のIdeal Cycle Time)または速度ロスを含まない最短実測値を基準に置きます。これによって、経年劣化・段取り劣化・軽微な速度低下が性能ロスとして可視化される仕組みです。基準を現実に合わせて緩めると、性能ロスが数値上に現れなくなりOEEが実力より高く見えてしまうため、設計値ベースに置くのが原則になります。

良品率と、稼働率・可動率の混同を避ける
良品率は「良品数 ÷ 加工数 × 100」で、廃棄・手直し品を除いた率です。立ち上がり時の初期不良や、設備劣化に起因する寸法誤差なども含まれます。
ここで注意したいのが、稼働率(Availability)と可動率(べきどうりつ)を混同しないことです。
トヨタ生産方式の可動率は「必要な時に動かせる能力」を示す別概念で、OEEの時間稼働率とは分母の置き方が違います。他社ベンチマークで「稼働率90%」という数字を見たときに、それがOEEの時間稼働率なのか、可動率なのか、単に設備通電時間の割合なのかを、必ず定義側から確認してから比較する必要があります。

85%の位置付け——TPM Award自己評価票の参考値
OEEの目安値としてしばしば引用される「85%」という数字は、JIPMのTPM Excellence Award自己評価票に参考値として登場する水準で、TPMの提唱者である中島清一氏の著作にも記載されています。
自己評価票の参考欄(自己採点の対象外)では、生産性向上の評価例としてOEE 75%・85%といった水準が示されています。ただしJIPM公式の解説自体は「適切な目標値は製品・工程・設備によって異なる」と明記しており、業界普遍のベンチマークとして扱えるものではない点に注意が必要です。
多品種少量生産の工場では段取り替え頻度が高く、時間稼働率が構造的に伸びにくいという事情もあります。実務では、同一ライン・同一製品での月次推移を第一の見方にし、他社数値や参考値との絶対比較は補助的に扱うのが現実的です。


TPM活動3年で設備総合効率が55.7%→80.6%に24.9pt改善した工場事例(出典:JIPMプラントエンジニア会員サイト)
上の棒グラフはJIPMがTPM活動事例として紹介している工場のOEE推移で、3年(N年→N+3年)で55.7%から80.6%へ24.9pt増(相対で約1.45倍)に達しています。画像内の「24.9% UP」表記は「24.9ポイント増」を意味しており、「相対で24.9%増加」ではない点は読み解きの際に注意してください。始点と終点しか示されていないため途中経過は不明ですが、単年で一気に到達する打ち手ではなく中期でロス削減サイクルを回し続けた成果である点が読み取れます。
OEEを下げる7大ロス——どの指標にどのロスが紐付くか
OEE改善で対策の入り口となるのが「7大ロス」の分類です。
7大ロスは、TPMの中で設備の効率を削る要因を7カテゴリに分解した枠組みで、JIPM由来の実務標準として国内外で定着しています。改善打ち手の議論をする際に「どのロスに効くのか」を先に整理することで、単なる「原因分析」で終わらず具体的な行動につながります。


TPM活動で整理される16大ロスの全体構造。黄色帯の7大ロスがOEE低下の直接要因(出典:日本プラントメンテナンス協会)
TPMでは設備効率だけでなく、人の効率(管理・動作・編成等の5大ロス)・原単位効率(歩留・エネルギー・型/治工具の3大ロス)まで含めて16大ロスとして整理しています。本記事で扱う7大ロスはこのうち設備効率を直接削る7つ(黄色帯)で、まずはここから着手して数値効果を作り、人・原単位系のロス削減に横展開する流れが一般的です。
7大ロスと3指標の対応マップ
以下の表で、7大ロスがどのOEE指標を削るかを整理しました。
| ロス | 内容 | 削る指標 |
|---|---|---|
| 故障ロス | 設備が壊れて停止する時間ロス | 時間稼働率 |
| 段取り・調整ロス | 品種切替・金型交換に伴う停止 | 時間稼働率 |
| 刃具交換ロス | 消耗品交換に伴う停止 | 時間稼働率 |
| 立ち上がりロス | 始業時・休憩後の暖機や試運転 | 時間稼働率+良品率 |
| 速度低下ロス | 本来速度より遅く動いている状態 | 性能稼働率 |
| チョコ停ロス | 短時間の一時停止・空運転 | 性能稼働率(社内の停止時間閾値を超えた場合はダウンタイムとして時間稼働率に計上) |
| 不良・手直しロス | 不良品発生と手直し工数 | 良品率 |
この対応マップから読み取れるのは、時間稼働率を下げているのは主に停止系ロス、性能稼働率を下げているのは速度系ロス、良品率を下げているのは品質系ロスという構造です。OEEスコアが低い工場ほど、まず3指標のうちどれが特に低いかを確認し、対応する7大ロス群から優先着手するのが定石になります。

停止系ロス——故障・段取り・立ち上がりの位置づけ
停止系ロスは、設備が「動いていない時間」を作るロス群です。
故障ロスは突発停止による生産機会損失で、半導体工場では1時間の装置停止で約1,300万円の機会損失、大手自動車工場では10分間のライン停止が工場長レベルの問題になるとオムロンの解説でも示されているように、1件あたりの経済インパクトが大きいロスです。
段取り・調整ロスは、品種切替に伴う金型交換や生産パラメータ変更に伴う停止で、多品種少量生産の工場ほど影響が大きくなります。近年はシングル段取り(10分未満)を目指すSMED活動が実務で広がっており、AI活用の側でも段取り手順の最適化・作業支援エージェントの適用余地が出てきています。
立ち上がりロスは、始業時・休憩後・保全後の再起動で暖機や試運転を必要とする時間で、時間稼働率と良品率の両方を削る特殊なロスです。初期の不安定な期間を短縮できれば2指標が同時に改善するため、優先度は高い一方で対策の難度も高い部類に入ります。

速度系ロス——速度低下とチョコ停の実態
速度低下ロスは、本来のサイクルタイムより遅く動いている状態で、経年劣化・受注減による意図的な速度落とし・段取り劣化などが主因です。
チョコ停ロスは、短時間で復帰できる軽微な停止で、1回あたりの影響は小さいものの発生頻度が高くなると累計影響が大きくなります。
チョコ停の厄介さは、現場で「停止」として記録されないケースが多いことです。「オペレーターが軽く触ればすぐ復帰する」レベルの停止は日報に載らず、性能稼働率が低いままの原因がわからないという状況が発生します。ここは後述する「詰まる論点」で改めて掘り下げます。

品質系ロス——不良・手直しと歩留まりの関係
不良・手直しロスは、廃棄・手直しが必要になった生産品による損失です。歩留まり(良品率)とほぼ同義で扱われますが、OEEの計算上は「加工数のうち良品となった割合」で厳密に定義されます。
このロスは金額換算がしやすい一方、根本原因が設備由来・材料由来・作業手順由来・環境要因(温湿度・粉塵)と多岐にわたるため、原因特定に時間がかかりやすいロスでもあります。AI活用の観点では、後述する「原因特定パターン」との相性が良い領域です。

【関連記事】
外観検査AIとは?製造現場の品質保証を変える基本能力と選び方を解説
現場でOEE改善が詰まる論点——数字は出るが打ち手が続かない構造的な理由
OEEの計算式と7大ロスの分類を理解しても、実際の現場では改善が続かないケースが多く見られます。
原因は「知識が足りない」のではなく、指標を回すための前提が現場側で整っていないという構造的な問題にあります。ここではAI総合研究所が製造業のDX支援で頻繁に遭遇する、詰まる論点を整理します。

データ収集の主観性——記録されないチョコ停
OEEを計算するには、稼働時間・停止時間・停止理由・生産数・良品数といったデータが必要です。
多くの工場では、これらを日報や停止理由コードに手入力で記録しています。ところがオペレーターは「軽く触って復帰した1〜2分のチョコ停」を停止として記録しない、「速度低下していても目標数に達していれば異常視しない」という運用になりがちです。
この結果、OEEを計算しても「時間稼働率が想定より高いのに、実生産量は目標に届かない」という辻褄が合わない状態が発生します。性能稼働率が下がる要因が数字に現れず、改善打ち手の議論に入れないという詰まりです。
打開策としては、PLCデータ・センサーデータからチョコ停・速度低下を自動検出する仕組みに切り替えるのが基本です。PLC × AIによる異常検知や、リアルタイム稼働ダッシュボードによる補完が現実的な打ち手になります。

指標定義のバラつきで工場間比較ができない
同じ企業グループ内でも、工場ごと・ラインごとにOEEの計算方法が異なるケースがよくあります。
- ある工場は段取り替えを負荷時間から除外、別工場は含める
- ある工場は基準サイクルタイムをカタログ値、別工場は過去実績平均
- ある工場は計画的保全を負荷時間から除外、別工場は含める
この状態でOEEの数値だけを並べても、「うちの工場は88%だからA工場より優秀」という比較が実質意味を持たないという詰まりが生じます。
改善打ち手の水平展開も難しくなり、「B工場で成功した施策をA工場に持ち込みたいが、そもそも指標の見方が違う」という状況が発生します。
打開策は、グループ全体でOEE定義を統一するガバナンス活動を先に走らせることです。ISO 22400-2の定義を参照点にすると、社内議論が「JIPMベース vs ISOベース」の折衷ではなく、国際標準に寄せる形でシンプルに整理できます。

打ち手の現場定着——決めた対策が翌月には形骸化
OEE低下要因が特定でき、対策会議で打ち手が決まっても、翌月にはその打ち手が現場で忘れられている——これも実務で頻繁に発生する詰まりです。
原因は「対策が現場作業に組み込まれていない」ことにあります。段取り手順の変更、保全周期の見直し、チェックリストの追加といった打ち手は、口頭伝達だけでは現場に定着しにくく、シフト交代や担当者の異動で消えてしまいます。
打開策は、対策を標準作業書・保全計画・作業指示書に落とし込み、実行のたびに記録が残る仕組みにすることです。ここでもAIによる作業支援エージェント(作業手順の音声・タブレット案内、実行ログの自動記録)が有効な選択肢になります。

【関連記事】
製造業の属人化をAIで解消!暗黙知を形式知化する3手法を解説
数値化前と打ち手後の両端が抜けている構造
3つの詰まりを俯瞰すると、OEE改善が続かない工場は、中央の「数値化と改善会議」だけが整っていて、両端の「データ収集の質」と「打ち手の現場定着」が抜けているという共通構造を持ちます。
いきなり全社共通の高機能ダッシュボードを導入しても、両端が抜けていれば数字は動きません。順序としては、まずデータ収集の自動化とOEE定義の統一を先に整え、そこにダッシュボード・AI分析を載せ、最後に打ち手の現場定着を仕組み化するのが現実的です。

OEE改善にAIを使う4つのパターン——可視化・原因特定・予測・自律対応
OEE改善におけるAIの使い方は、成熟度に応じて4パターンに整理できます。
このフレームは、実務でPoC→ライン展開→全社展開を進めるときに「今、自社はどこにいるのか」を判断する軸として機能します。フェーズを飛ばして最上位から入ると失敗するという点が、多くの現場で見落とされがちなポイントです。

可視化——手集計をリアルタイムダッシュボード化
最初のパターンは、日報や表計算ソフトで集計していたOEEを、IoT・PLC連携によるリアルタイムダッシュボードに置き換える段階です。
具体的には、PLCから稼働信号・生産数・停止信号を自動収集し、Microsoft Fabric・Power BI・Databricksなどのデータ基盤上でOEEを分単位で計算し、現場の大型モニタや管理者のPCに常時表示します。
このパターンの価値は、「先月のOEE」ではなく「今この瞬間のOEE」を議論の起点にできることです。加えて、日報作成・集計にかかっていた工数を削減できるため、生産技術・生産管理の月次業務を軽くできます。
導入時の落とし穴は、「ダッシュボードを作ったが誰も見ない」という状態です。表示するだけでは意味がなく、閾値割れ時のアラート・現場責任者のスマホ通知・週次レビュー会議での定型議題化までを設計に含める必要があります。

【関連記事】
製造現場のリアルタイム可視化!帳票AIダッシュボードでの分析方法を解説
原因特定——低下要因のドリルダウン
可視化が回り始めると、次に必要になるのが「なぜOEEが下がったのか」の原因特定です。
このパターンでは、生成AIエージェントが稼働ログ・停止理由コード・センサーデータを横断して、OEE低下時の共通パターンを自動抽出します。「昨日15時のライン3のOEE低下は、段取り替え後3回連続で発生した金型温度異常が主因」という一次分析を、シフト内で提示する運用が想定される到達点です。
技術的には、RAGによる過去トラブル履歴の参照、MCP経由のPLC・MES連携、時系列AI基盤モデル(NV-Tesseractなど。NIMは早期アクセス提供)による異常検知・分類・予測が組み合わせで使われます。
このパターンの導入価値は、生産技術・保全担当が原因調査に費やしていた時間を大幅圧縮できることです。一次分析までをAIが済ませ、人間は打ち手判断に集中できます。

予測——故障・チョコ停の予兆検知
第3段階が予測パターンです。
センサーデータ・稼働パターン・過去故障履歴を機械学習モデルに学習させ、故障・チョコ停・品質不良の予兆を実発生前に早期検知します(早期検知できる時間幅は設備・モデル・データ収集頻度によって変動)。予知保全(Predictive Maintenance)と呼ばれる領域で、AI×OEE改善の中核となる打ち手です。
設備劣化が故障・速度低下・品質不良の共通原因になっている工程では、時間稼働率(故障・段取り予兆)・性能稼働率(チョコ停予兆)・良品率(品質不良予兆)の3指標すべてに波及し得るため、単一の投資でOEE全体を押し上げられる場合があります。詳細は次のH2で扱います。

自律対応——エージェントが判断・実行
最上位が自律対応パターンです。
AIエージェントが予兆検知だけでなく、保全指示の起票・生産スケジュール調整・段取り替え順序の再計算・オペレーターへの指示提示まで自動実行します。人間はエージェントの判断結果を承認するかどうかの判断だけを行う運用形態です。
2026年6月にSight Machineが発表した「Agentic Manufacturing Platform」は、この自律対応パターンへ段階移行するプラットフォームの例で、AI Agent Crewsと呼ばれる複数エージェントがKPI改善につながる仮説を継続的に立て、プロセス専門家に検証・承認を求める運用として設計されています。Microsoft Fabric・Azureとネイティブ連携する設計で、既存データ基盤の上に載せる形で導入できるのが特徴です。
ただし、このパターンをいきなり導入するのは非現実的です。パターン1〜3のデータ基盤・原因特定・予測モデルが整った上で、限定領域から段階展開するのが実務での定石になります。

4パターンの成熟度マップで現在地を見立てる
4パターンを段階マップとして並べると、自社が今どこにいるかを判断する軸になります。
- パターン1(可視化): リアルタイム稼働データが基盤に集約され、OEEがダッシュボードで見える状態
- パターン2(原因特定): 低下要因の一次分析がAIから返ってきて、担当者はレビューと判断に集中
- パターン3(予測): 故障・不良・チョコ停の予兆が事前アラートとして届く
- パターン4(自律対応): エージェントが保全指示・スケジュール調整まで実行し、人間は承認判断
パターン4に進む前提として、パターン1〜3の運用が安定していることが要件になります。
AI予知保全がOEEに効く理由——チョコ停・故障・速度低下の削減事例
前セクションのパターン3(予測)の中核をなすのが、AI予知保全です。
AI予知保全は故障の突発停止(時間稼働率)と劣化に伴うチョコ停・速度低下(性能稼働率)に直接効き、設備劣化が品質不良の原因になっている工程では良品率にも波及し得る打ち手です。工程ごとに効き方は違いますが、条件が揃えば単一の投資で複数のロスを同時に押し下げられます。

予知保全と3指標の結節点
以下の表で、AI予知保全が3指標のどこにどう効くかを整理しました。
| OEE指標 | 削られる要因 | AI予知保全の効き方 |
|---|---|---|
| 時間稼働率 | 突発故障による長時間停止 | 故障予兆検知で計画停止に置き換え、復旧時間を短縮 |
| 性能稼働率 | 経年劣化に伴う速度低下・チョコ停 | センサー相関の変化から劣化を早期検知し、性能ロス前に部品交換 |
| 良品率 | 設備劣化に伴う寸法誤差・初期不良 | 品質不良の予兆パターンを検知し、不良発生前に段取り再調整 |
設備劣化が故障・速度低下・品質不良の共通原因になっている工程では、単一の投資で3指標に波及するため、AI予知保全はOEE改善プロジェクトの投資対効果が可視化しやすい場合があります。プロジェクト提案時に「時間稼働率のみ改善」ではなく「OEE 3指標のいずれにも波及し得る」という切り口で試算を組めるため、経営層の意思決定を得やすいという特性です。

実装アプローチ——センサー相関で正常モデル化
AI予知保全の標準的な実装は、振動・温度・電流・音などの複数センサーから相関パターンを機械学習し、正常稼働状態のモデルを作る方式です。
正常モデルからの逸脱をリアルタイムで検知し、逸脱パターンから故障・劣化の種類を推定します。1台の設備で扱うセンサーの本数・種類は業種と装置構成によって幅がありますが、複数センサーを同時に扱うため、単一しきい値監視では対応できない領域を機械学習モデルがカバーします。
技術的には、時系列AI基盤モデル(NVIDIAのNV-Tesseractなど。NIMは早期アクセス提供)や、振動解析特化のAI(振動解析AI)が2026年時点の実装候補です。従来はセンサーメーカー独自のAIモデルが主流でしたが、汎用時系列AI基盤の登場で、異種設備データを共通基盤で分析する選択肢が広がっています。

実務での定着——検知後のワークフロー設計が本命
AI予知保全の技術は成熟しつつある一方で、実務で定着するかどうかを分けるのは検知後のワークフロー設計です。
予兆アラートが出ても、保全担当が翌週まで気づかない、部品調達が間に合わない、生産計画の調整ができないという状態では、AIの予測が生かされません。
実務で回している工場は、以下のワークフローが整っています。
-
予兆検知→保全指示の自動起票: CMMS(保全管理システム)にAI検知結果を連携し、保全指示を自動生成
-
部品在庫との照合: 交換が必要な部品の在庫を自動チェックし、不足なら発注申請
-
生産スケジュールとの調整: 計画停止のタイミングを、生産計画・段取り替え計画と組み合わせて最適配置
この「検知→指示→調整」の一連の流れをAIエージェントが担う設計が、パターン4「自律対応」に接続する現実的な入口になります。

【関連記事】
AIによる予知保全とは?仕組み・国内事例・主要ツール比較を2026年最新動向で解説
AI×OEE改善プロジェクトの投資対効果と進め方——5ステップ
AI×OEE改善プロジェクトを社内で提案・実行する際の、投資対効果の目安と進め方の5ステップを整理します。
先に見た「詰まる論点」を踏まえると、いきなり全社展開ではなく、限定ラインで実効性を検証してから広げるのが失敗しない進め方です。

投資対効果の考え方——機会損失規模で決まる
AI×OEE改善プロジェクトの投資対効果は、業界ベンチマークで断定できるものではなく、対象ラインの機会損失規模と、ロス削減余地の掛け算で試算します。
試算の骨格は次の3要素です。
- 初期投資: IoTセンサー・データ基盤構築・AIモデル開発(対象ライン規模と既存インフラの活用度で大きく変動するため、対象ラインごとに個別見積りが必要)
- 月次運用費: データ基盤ライセンス・AIモデル運用(規模に応じたサブスクリプション費用)
- 削減効果: ダウンタイム時間の金額換算+日報集計工数の削減+保全コストの最適化
1時間あたりの機会損失が大きい大型設備・24時間稼働ラインでは、ダウンタイム削減の金額インパクトが大きく回収期間を短縮しやすい構造です。逆に小規模ライン・断続稼働ラインは絶対額での効果が薄くなるため、対象ライン選定が投資判断の起点になります。
社内提案時は、自社ラインの実測ロス金額と削減見込みから試算し、他社ベンチマーク数値は補助的な参照にとどめるのが実務的です。他社事例の削減率をそのまま自社ラインに当てはめると、前提条件(稼働形態・設備構成・データ収集の成熟度)の違いで大きくブレます。

進め方5ステップ
以下がAI×OEE改善プロジェクトの標準的な進め方です。
ステップ1: 現状OEEの正確な把握
まず、対象ラインの現行OEEを正確に測定します。既存日報ベースのOEEが実態と乖離している場合、簡易的にでもPLCデータからOEEを計算し直し、真の現在地を確認します。
同時に、OEE計算の定義(負荷時間の扱い・基準サイクルタイム・良品判定基準)を文書化します。この定義がないと、後のステップで施策効果の測定が揺らぎます。
ステップ2: ボトルネックロスの特定
現行OEEを3指標に分解し、どの指標が最も低いか、その裏にある7大ロスのどれが支配的かを特定します。
チョコ停・速度低下の実態がわからない場合は、パターン1(可視化)の簡易導入で一定期間の稼働データを取得し、実データからボトルネックを判定します。
ステップ3: 限定ラインでのAI PoC
特定した支配的ロスに対して、AI活用パターン1〜3のどれで打ち手を作るかを決めます。多くの場合、パターン1(可視化)+パターン2(原因特定)+パターン3(予測・予知保全)の組み合わせで、1ラインを対象に一定期間のPoCを実施します(データ収集開始からモデル評価までの期間はラインの稼働特性で変動)。
このフェーズの成功指標は、対象ラインで事前に合意した改善幅の目標(現行OEEから何pt引き上げるか)に届いたかどうかです。目標未達の場合は、パターン選択・データ収集の粒度・打ち手の現場定着のいずれかに課題があります。
ステップ4: 同種ラインへの展開
PoCで実効性が確認できたら、同種設備・同種プロセスのラインへ展開します。ここで重要なのが、PoCで培った「AI検知→保全指示→生産計画調整」のワークフローをテンプレート化することです。
展開ラインで再度ゼロから設計するのではなく、テンプレートを適用して短期間で稼働させます。ゼロから設計した初回ラインと比べ、展開ラインは大幅に短い期間で立ち上げられます。
ステップ5: 全社展開と自律対応への段階移行
複数ラインで安定運用ができた段階で、全社展開に進みます。同時に、パターン4(自律対応)への段階移行を検討する時期に入ります。
自律対応は、保全指示の自動起票→保全計画の自動調整→生産スケジュール調整と段階的に権限を広げるのが定石です。全工程を一気に自律化するのではなく、承認プロセスを残しつつ範囲を広げるアプローチが失敗を減らします。

プロジェクト失敗の3パターン
進め方で失敗するパターンも整理しておきます。実務で頻発するのは以下の3つです。
-
いきなり全社展開: PoC段階を飛ばして全ライン一斉導入。データ収集の質やワークフロー設計が現場で揺らぎ、数値が動かない
-
可視化だけで止まる: パターン1のダッシュボードを作って満足し、パターン2〜3に進まない。「見える化はできたが打ち手が変わらない」状態
-
AI技術投資が先行: 高度な予測AIを先に導入して、データ収集の質・OEE定義の統一・現場ワークフローが後回しになる。AIモデルの精度が上がらず頓挫
3つとも、共通する根本原因は「順序を守らない」ことにあります。データ収集→定義統一→可視化→原因特定→予測→自律対応の段階を、対象ライン単位で確実に踏むのが実務での正解です。

AI×OEE改善の事例とリファレンス——ダイキン×日立、Sight Machine、Microsoft Fabric、AVEVA
国内外で先行するAI×OEE改善の4例を、導入事例・試験運用・製品発表・参照設計の4種類の状態を横断する形で整理します。
各例で使われている技術・現時点で公開されている情報・出典を明示し、自社での適用可能性を判断する材料としてください。

ダイキン×日立——堺製作所の設備故障診断AI
ダイキン工業と日立製作所は、2025年4月からダイキンの堺製作所において工場の設備故障診断を支援するAIエージェントの試験運用を開始しました。
ダイキンのOT(Operational Technology)ナレッジと日立のIT技術を融合したエージェント設計で、事前実証(5種類の設備×各5件、熟練保全技術者2名による評価)では10秒以内に90%以上の精度で原因・対策を回答する結果が確認されています。海外工場での技術者確保・育成が困難という背景から、暗黙知の形式知化と迅速な故障診断の両立を狙った取り組みです。
日立側では別の関連サービスとして、日立産機システムが2025年12月18日にHMAX Industry「現場サポートAIナビ」の外部提供を開始しています。空気圧縮機・給水ポンプ・産業用インクジェットプリンターなどFitLive®接続機器が対応範囲で、稼働データ・取扱説明書・サービスエンジニアのノウハウを構造化したデータベースをエージェントが参照する構成です。ダイキンとの共同検証で使われた技術がそのまま製品化されたと公式に説明されているわけではないため、ここでは同じ「保全ドメインの生成AIエージェント」文脈で並ぶ関連事例として扱います。

Sight MachineのAgentic Platform
米国Sight Machineは2026年6月11日、Agentic Manufacturing Platformを発表しました。
AI Agent Crewsと呼ばれるエージェント群が、スループット・品質・コスト等のKPIについて継続的に仮説を立て、プロセス専門家に検証と承認を求める運用として設計されています。従来、データエンジニアが数か月かけて構築していたセマンティックモデル(信号→資産→プロセス→KPIのマッピング)を、プロセス専門家がAIエージェントと対話しながら数日で構築できる点が特徴で、先行して発表されたAI Agent Crewsの説明でも「AIの推奨内容を人が確認し、段階的に自律範囲を広げる」アプローチが示されています。
Microsoft Azure・Microsoft Fabric・Microsoft Teams・Databricksとネイティブ連携する設計で、既存データ基盤の上に載せる形で導入できます。

Microsoft Fabricで組む予知保全リファレンス
Microsoftは、Fabricのリアルタイム分析基盤を使った製造業向け予知保全のリファレンスアーキテクチャを公式に公開しています。稼働センサーデータをEventstreamで取り込み、Eventhouseに時系列DBとして蓄積し、KQLクエリや機械学習モデルで異常検知・故障予測を行い、Real-Time Dashboardsで可視化、Activatorで条件トリガーによる通知を出す構成です。
このアーキテクチャは特定顧客の導入事例ではなく、Fabric上で予知保全を組む際の参照設計として位置づけられています。個別の改善数値は現場ごとに異なりますが、参照設計に沿ってストリーミング取り込み・時系列蓄積・ダッシュボード表示・アラート配信を段階的に組み上げられるのが利点です。


Fabric Real-Time IntelligenceのApache Kafka接続設定画面。稼働データのストリーミング取り込みを構成できる(出典:Microsoft Fabric公式)
AVEVA Insightの稼働率改善事例
AVEVA Insightは、産業クラウドプラットフォーム上でOEE・エネルギー・稼働状況を統合分析するソリューションです。
導入事例として、Schneider Electricは全ライン生産性向上・運用効率12%向上・設備ダウンタイム44%削減を実現、Leggett & Plattではダウンタイム・OEE・労務効率の改善機会を特定した実績が公開されています。ROCA Groupは、AVEVA公式のプレゼンテーションで、Industry 4.0ロードマップの中核にOEE改善とエネルギー効率化を据えたことを公表しています。
AVEVAは製造業のプロセス自動化領域で長く実績を持つベンダーで、上記のようにグローバルで複数の稼働率改善事例が公開されています。


AVEVA Insightの資産ダッシュボード。左メニューに「OEE Analysis」「Equipment Efficiency」を備え、リアルタイム値・トレンド・異常検知アラートを1画面で表示(出典:AVEVA Insight公式)
4例から得られる設計上の示唆
導入事例・試験運用・製品発表・参照設計を並べて見ると、AI×OEE改善プロジェクトを組む際の設計上の示唆が3点浮かびます。
- 既存基幹システムとの接続: OEEダッシュボード単体で終わらせず、MES・CMMS・ERPと接続して業務フローに組み込む設計を推奨方針として置く
- 段階導入: 限定ライン・限定工場から始め、実効性を確認してから展開する設計を推奨方針として置く
- AIと人間の役割分担: AIが検知・分析を担い、人間が最終判断・承認を行う設計(Sight Machineの発表ドキュメントでも段階的な自律範囲拡大が明記)
これらの示唆は、これから導入を進める企業にとっての設計上の当たり所として機能します。特に「基幹システムとの接続」は、OEEプロジェクトの投資対効果を左右する要素として、初期設計段階で組み込みたい論点です。

【関連記事】
スマートファクトリー完全ガイド|仕組み・成熟度4段階・2026年Agentic AI動向を解説
OEE改善を業務Agentで自動化するなら
OEE改善は、指標を可視化するだけでは現場の打ち手に変換されません。AI予知保全で検知した予兆を、保全指示の起票・部品在庫との照合・生産スケジュール調整まで自動でつなぐ設計ができて、初めて改善サイクルが回り始めます。指標・データ基盤・業務Agent実行層を一体で設計する運用基盤が必要です。
このレイヤーを担うのが、Teamsから呼び出せる製造業向けのAIエージェント基盤です。AI総合研究所のAI Agent Hubは、Fabric OneLakeの稼働データを業務特化Agentが読み書きし、OEE改善サイクルを製造現場と業務システムを跨いで回せる運用基盤として機能します。
- 予知保全の予兆を保全Agentが自動起票
記事で扱ったAI予知保全モデルの検知結果を、Teams上のAgentが保全指示の起票・部品在庫照合・作業員アサインまでワンストップで実行。「アラート止まり」から「アクションまで完遂」へ移行できます。
- 稼働・不良・段取りの3データを跨いだ改善提案
7大ロスに紐づく稼働データ・品質データ・段取り時間をFabric OneLakeで統合し、Agentが原因特定と対策提案を横断実施。生産計画Agentとも接続してスケジュール調整まで自動化できます。
- 既存MES・PLM・ERPを置き換えずAgent層で接続
Teamcenter・SAP・Oracleなどの既存基幹を維持したまま、その上に業務Agent層を重ねる構成。既存投資を守りながらOEE改善ワークフローを実装できます。
- データは100%自社Azureテナント内、実行ログは監査証跡として保存
稼働ログ・原価情報など製造業の中核データはAIの学習対象から完全除外。Azure Managed Applicationsとして自社テナント内で動作が完了する設計です。
AI総合研究所の専任チームが、OEE指標の可視化から業務Agent連携、改善サイクル運用まで一貫して支援します。製造業向けAI Agent Hubのページで、OEE改善Agent実装例をご確認ください。
OEE改善を業務Agent自動化へ
予知保全から生産計画までを一気通貫
OEEダッシュボードで終わらせず、AIが検知した予兆や停止要因を保全指示・段取り替え・生産スケジュール調整までつなぐ設計が改善サイクルを回す鍵です。製造業向けAI Agent Hubで、稼働データ・予知保全・業務Agent接続を1つの基盤で設計・構築できます。
まとめ
本記事では、OEE(設備総合効率)について、計算式と7大ロス・現場で改善が続かない構造的な論点・AI活用4パターン・AI予知保全との結節点・進め方5ステップ・国内外事例までを、2026年7月時点の最新情報で解説しました。
2026年時点で押さえておくべきポイントは次の3つです。
- OEE = 時間稼働率 × 性能稼働率 × 良品率の掛け算構造で、85%はJIPM TPM Excellence Award自己評価票の参考値であり業界普遍の基準ではない
- 改善が続かない主因はデータ収集の主観性・指標定義のバラつき・打ち手の現場定着の3層で、中央の分析だけを整えても両端が抜けていれば数字は動かない
- AI活用は可視化→原因特定→予測→自律対応の4パターンを段階的に進め、対象ラインの機会損失規模でROIを試算し限定ラインPoCから展開する
まずは自社の対象ライン1本で現状OEEの正確な把握から着手し、支配的な7大ロスに対応するAI活用パターンを選ぶのが、投資対効果の高い第一歩になります。OEEはもはや「月次レポートの数値」ではなく、AIエージェントと現場をつなぐ共通言語として設計し直すタイミングに入っています。













