製造AI — 工場データがモデルに求めるもの

製造AIの難しさはモデルではなく、データの性質にあります。 工場の信号にはラベルがほとんどなく、運転条件によって分布が変わり、欠損値と0の値では意味が異なります。また、誤答のコストは非対称です — 1件の故障見逃しと100件の誤警報は、それぞれ異なる形で工場に損害を与えます。

本稿では、その性質を起点に、どのような設計が導かれるかを整理します。例はPlantPulse AIの実装から取り上げていますが、論旨は製品に依存せず、製造AI全般に当てはまります。

対象読者

データサイエンティスト、設備エンジニア、AI導入を検討する技術担当者。時系列、埋め込み、RAGなどの用語は説明なしで使用します。製品機能の一覧はAI機能一覧、モデル自体についてはAURA技術ホワイトペーパーを参照してください。

1. 工場の信号は何が違うのか

一般的な機械学習の教科書が前提とする、独立同分布、十分なラベル、通常の欠損処理は、工場ではほとんど成立しません。

性質	何を意味するか	設計への影響
ラベルがない	故障はまれであり、発生した故障について原因まで記録されることはさらに少ない	教師あり学習の分類器より、正常を学習し、そこからの逸脱を測る方式（再構成、予測誤差）が基本となる
運転条件が変わる	負荷、製品、季節、シフトによって「正常」の形が変わる	固定しきい値は、条件が変わった瞬間に誤警報を大量発生させる。判別が難しい正常状態（異常に見える高負荷区間）を別途扱う必要がある
0と「不明」は異なる	「作業指示0件」は測定結果だが、「CMMS接続切断」は測定結果ではない	欠損を0で埋めた瞬間、誰も確認していない設備が「正常」と報告される
信号が階層に属している	1つのタグは、設備、ライン、エリア、サイトの配下にある	「3号ラインのコンプレッサー」という言葉を階層内のノードに変換する段階が、あらゆるクエリの最初の処理となる
原因は順序に現れる	同じ2つの信号でも、どちらが先に上昇するかによって故障が異なる	相関だけを見るモデルでは故障を判別できない。先行、後続を見る必要がある
誤答のコストが非対称である	見逃しは設備を失わせ、誤警報は人の信頼を失わせる	誤警報を見逃しとは別に集計し、警報を抑制する手段を製品側で用意する必要がある

最後の点は過小評価されがちです。誤警報が積み重なる異常検知は、最終的にオペレーターによって無効化されます。 無効化された検知器は何も検知できません — 精度99%のモデルでも、無効化されれば0%です。

2. 層を分ける — 1つの大きなモデルで解決しない

製造AIを「大規模言語モデルにセンサーデータを見せるもの」として設計すると、3つの問題が同時に発生します。秒単位の波形はトークン化するには長すぎ、言語モデルは数値パターンから異常を見つけることに長けておらず、何よりも測定されていない値をもっともらしく生成します。

そのため、処理を性質ごとに分けます。

                      질문 「3라인 압축기 요즘 어때?」
                                  │
   ┌──────────────────────────────▼──────────────────────────────┐
   │ ④ 설명 — 언어모델                                             │
   │    도구를 골라 부르고, 결과와 문서를 읽고, 근거와 함께 답한다        │
   └───────┬──────────────────────┬──────────────────────┬───────┘
           │ 도구 호출             │ 도구 호출             │ 검색
   ┌───────▼────────┐    ┌────────▼────────┐    ┌────────▼────────┐
   │ ③ 시계열 모델    │    │ ② 통계 · 규칙     │    │ 문서 검색 (RAG)   │
   │ 이상 · 예측      │    │ 기준선 편차 · 공식 │    │ 절차서 · 이력     │
   └───────┬────────┘    └────────┬────────┘    └─────────────────┘
           └──────────┬───────────┘
              ┌───────▼────────┐
              │ ① 데이터 원장    │  시계열 · 알람 · 작업지시 · 설비 계층
              └────────────────┘

層	得意なこと	任せないこと
② 統計、ルール	設備の通常時のベースラインに対する偏差、工学公式（OEE、MTBF、ベアリング故障周波数）	多変量パターン
③ 時系列モデル	複数チャネルが組み合わさって作る「形」の異常、短期的な傾向	原因の説明、文書との照合
④ 言語モデル	ツールの選択、結果の統合、手順書との照合、人が理解できる言葉での説明	数値を生成すること

下位層で解決できるものを上位層に渡しません。 ベースラインからの偏差だけで異常区間を判別できた実例があり、そのような区間にモデルは使いません。計算は公式が行い、言語モデルは計算結果を読み取って説明します — 言語モデルがL10寿命を「概算」した瞬間、その回答は検証不能になります。

3. 異常検知 — 正常を学習し、逸脱を測る

ラベルがないため、「故障分類器」を学習させることはできません。代わりに、正常信号を再構成するモデルを用意し、再構成がどの程度外れたかを異常スコアとして使用します。PlantPulseではIBM Granite TSPulseを使用します。

2種類の誤差を併用する

スコアモード	何を測るか	何を検出するか
時間領域の再構成	元信号と再構成結果との差	急変、スパイク、レベルシフト
周波数領域の再構成	スペクトルの差	振動形状の変化 — 平均は変わらなくても「揺れ方」が変化した場合

回転機器の初期故障は、多くの場合、後者に先に現れます。振幅には問題がなくても、特定の周波数帯域が増大し始めます。時間領域だけでは、これを見逃します。

設定したモードが「実際に計算されているか」を確認する

時系列ライブラリによっては、モード一覧のうち1つでもサポートしていれば検証を通過させ、未サポートのモードを例外も警告も出さずに破棄する場合があります。「レベル偏差スコアを有効にした」と記載されていても、実際には何も有効になっていない状態で動作する可能性があります — 実測で確認した事例です（2026-09）。

PlantPulseは各モードを1つずつ個別にライブラリへ問い合わせ、モデルが計算しないモードが1つでも含まれていればロードを拒否します。モデルごとに計算可能なモードの集合が異なるため（再構成モデルと予測モデルでは重複しません）、モデルを変更すると同じ設定でも意味が変わります。

コンテキスト長と短い履歴

TSPulseは512ステップのウィンドウを入力として受け取ります。設備を接続した直後や履歴が短い場合は、ウィンドウが不足します。この場合、2つの選択肢があります。

拒否する — 新規設備は一定期間、判定を受けられない
左側を埋める — 最も古い値を繰り返してウィンドウを埋める（edge padding）

PlantPulseは最低32行あれば後者を選択し、それ未満なら拒否します。埋めれば判定はできますが、埋めた分だけ判定根拠が弱くなります — 履歴の短い設備の異常スコアを、履歴の長い設備と同じ重みで解釈しないでください。

しきい値より「抑制する手段」が重要

しきい値をどれだけ適切に設定しても、現場には頻繁に発生するが問題ではないものが残ります。解決策はしきい値をさらに厳しくすることではなく、オペレーターがそれを抑制できるようにすることです。

頻出項目を発生回数、最終発生時刻とともに表示し、「しきい値引き上げ／ミュート検討」または「観察」を提案する
ミュートは通知とインシデントへの昇格だけを停止し、検知記録は残す。 後から検証するための根拠を失ってはならない
確認処理は一度だけ行う。最初に確認した担当者と時刻を記録する

画面についてはTimeSeries-Insightを参照してください。

4. 予測 — 区間がなければ予測ではない

傾向予測にはTinyTimeMixer(TTM)を使用します。コンテキストは512ステップ、1回で最大96ステップ先まで予測します — モデルがその長さで学習されているため、それを超えるリクエストは暗黙的に切り捨てず拒否します。履歴が512ステップに満たない場合は、利用可能なコンテキスト長まで短縮して実行し、短縮後の値もレスポンスに含めます。

点予測ではなく区間予測

「来週のベアリング温度は78℃」だけでは、あまり役に立ちません。オペレーターが必要とするのは、「10～90%分位区間は72～84℃で、上限が警報線に達する」という情報です（デフォルトの分位数は0.1、0.9です）。PlantPulseは予測後にconformal補正を適用して区間を生成します。

過去の履歴上でウィンドウを移動させながら、「その時点で予測していた場合」の予測値を生成する
その予測値と実際に発生した値との残差を集める
残差の分位数から、現在の予測の上限と下限を決定する

モデル自身に不確実性を申告させるのではなく、この設備において、このモデルが実際にどの程度外れたかを基に区間を決める方法です。分布を仮定しないため、産業信号のように裾の厚いデータに適しています。

欠損を0で埋めると、区間が「欠損の大きさ」になる

平均1500 kPaの圧力タグに欠損があり、それを0で埋めると、そのウィンドウの残差は|1500 − 0|になります。分位数は予測誤差ではなく欠損の大きさによって決まり、区間は不合理なほど広くなります — それでも「区間計算成功」という表示はそのまま付きます。

PlantPulseは、欠損を含むウィンドウと、実測値がまだ存在しない末尾のウィンドウを補正集合から除外します。 残ったウィンドウが必要数に満たない場合は区間を出力せず、その理由をレスポンスに記載します（「履歴を追加送信してください」）。誤った区間より、区間がない方が適切です。

5. サイレント障害 — 製造AIで最も高くつくバグ

製造AIの事故は、多くの場合、エラーが発生しない状況で起きます。サービスは200を返し、ヘルスチェックは正常を示し、数値ももっともらしく見えます。しかし、その数値を生成したのはモデルではありません。

実際に経験した3つのパターンを示します。

パターン	何が起きたか	防止策
フォールバックがモデルとして振る舞う	データ不足でモデルを起動できない場合、単純外挿（drift、seasonal-naive）にフォールバックする。レスポンスは200となる	レスポンスに`model_used`と`fallback_reason`を含める。呼び出し側はそれを読み取って記録する — `NAIVE`の比率上昇自体がシグナルとなる
ランダムな重みがモデル名を名乗る	予測モデルの2世代（R2、R3）は重みのキーが1つも一致しないにもかかわらず、互いのチェックポイントを例外なく読み込む。結果として、445個のパラメーターがすべてランダムに初期化されたモデルが`TTM`の名前を付けて応答する	ロード時に、チェックポイントに存在せず新規作成されたパラメーターが1つでもあれば拒否する
設定エラーが一時的な障害として吸収される	上記の設定エラーがフォールバックに吸収され、「ヘルス正常、予測200、すべての回答が単純外挿」という状態で動作した	障害を2種類に分ける。再試行しても回復しないもの（設定、GPU停止）は500、503として返し、一時的なもの（データ不足）だけをフォールバックする

一般化すると、ルールは1つです — すべての出力に「何がその出力を生成したか」を併記します。 モデルかフォールバックか、区間が計算されたかスキップされたか、何行を基に判定したか。これがなければ、運用中のAIが実際にAIとして動作しているかを誰も確認できません。

ヘルスチェックが示すのは「稼働している」ことだけ

予測設定が誤っていても、同じプロセスが異常検知の提供を続けるため、/healthは正常です。ヘルスチェックに「回答が正しい」ことまで保証させることはできません。そのため、起動ログにモデルのロード結果を1行で記録し（[MODEL_LOAD]、[MODEL_LOAD_FAIL]、[MODEL_WARMUP_FAIL]）、その行を監視します。

6. 原因は順序に現れる — 故障メカニズム

「温度が上昇した」原因は複数あります。ベアリング摩耗、潤滑不足、冷却不良、電気的故障、ファウリングです。これらは値の大きさではなく、何が先に、何が同時に変化したかによって区別されます。

故障	先に現れる信号	後続する信号
ベアリング摩耗	振動上昇	温度が後から上昇、故障周波数の高調波
潤滑不足	潤滑油流量の低下	摩擦熱による温度の急上昇
冷却不良	冷却水流量の低下	温度のみ上昇（振動は正常）
電気的故障	電流不平衡	消費電力と温度が同時に上昇
キャビテーション	広帯域ノイズの急増	吐出低下 → 電力低下

判定規則は次のとおりです。振動が同時に上昇すれば機械的原因の可能性が高く、温度だけが上昇すれば冷却またはファウリングの可能性が高くなります。潤滑油流量が先に低下していた場合、温度の急上昇は原因ではなく結果です。また、他のすべてのモードで電力が上昇する中、電力が低下するのはキャビテーションだけであるため、この1点で判別できます。全体マップ（故障11種類 × 設備18種類）はAURA技術ホワイトペーパーの第5章、第6章にあります。

要点は、同時相関だけでは判別できないということです — 相関は対称ですが、故障は非対称です。そのため、次の2つを併用します。

時間差相互相関。 タグ関係分析では、同時相関が高いペアについて時間差を前後にずらしながら（最大±10サンプル）、相関が最大となる時間差を求めます。それが0でなければ、先行、後続ペアとして出力します
メカニズムの構造を学習させる。 モデルには「症状 → 正解」のペアではなく、時間軸を持つ軌跡を提示します。判定とともに、「温度がD+11で先に上昇し、振動はD+19で後続した — 熱的原因が先行」のような、数値と期間を含む根拠文を出力させます。人が検証できる必要があるためです

単調増加する列は何に対しても「先行」する

分析対象の列を選択する前にテーブル全体を数値化すると、タイムスタンプがナノ秒の整数に変換され、タグと同様に混入します。 単調増加するため、あらゆる値との相関が1に近くなり、診断結果に「timestampが温度に先行する」と入り込みました（2026-07）。時間列と識別子列は先に除外し、変動のない列も除外します — 相関係数を定義できないためです。

過去事例も同じ目的で使用します。同じ形の異常が以前にもあったか（類似異常検索）、同種設備の中で1台だけ異なる動きをしているものがあるか（フリート外れ値）、故障前に見られた信号が現在も現れているか（予兆点検）。いずれも「この設備の過去」と「周辺設備の現在」をベースラインとして使用する方法です。

7. 説明 — 根拠だけに基づいて回答する

言語モデルの役割は、読み取り、選択し、説明することです。1つのクエリは、おおむね次のように処理されます。

① 이름을 ID 로      「3라인 압축기」 → 설비 계층의 노드
② 도구를 고른다      분석 · 이력 · 알람 · 문서 · 사진 중 무엇이 필요한가
③ 데이터를 가져온다  이상 점수 · 건강 지수 · 태그 이력
④ 문서를 더 본다     절차서 · 고장 이력 · 규격
⑤ 모아서 답한다      근거를 붙여서

②～④は1回では完了しません。エージェントはツールの結果を確認し、次のツールを選ぶ処理を繰り返します。この構造で品質を左右する要素は3つあります。

① ツールスキーマ。 モデルが適切なツールを選択し、引数を正しく指定できるかどうかが、そのまま回答品質になります。ツールはデフォルトで無効になっており、有効にしたものだけがエージェントに表示されます。使用しないツールが多いほど、選択精度は低下します。また、プロンプトが長くなるほどモデルがツールを呼び出さなくなることが実測されています — 説明を増やすことが常に有効とは限りません。

② 検索品質が回答品質の上限を決める。 産業文書には、タグ名、部品番号、規格条項のように完全一致が必要な文字列と、「交換周期」＝「保守間隔」のように意味は同じでも表現が異なる語句が混在しています。そのため、キーワード検索（BM25）と意味検索（埋め込み）を併用し、リランカーが候補の中から実際に回答となる箇所を選択します。埋め込み次元は契約として固定します — モデルを変更してもベクトルインデックスを再構築しないためです。パイプラインについてはRAGアルゴリズムを参照してください。

③ 不明であると回答する。 収集されていない値を「正常」と報告せず、コンテキストにない情報は記述しません。これはプロンプトに1行書くだけでは実現できません — 判断保留が正解となる設問を学習データに含める必要があります。AURAの学習データの3分の1が、断定しない回答になっているのはこのためです。

8. どう評価するか — ジャッジモデルを使わない

産業AIにはリーダーボードがありません。また、別の言語モデルに採点させると、もっともらしい誤答が高得点になります。そのため、採点を機械化します。

何を	何に照合するか	注意点
産業計算	公式（工学計算式30系列）	一部系列を学習から完全に除外する — 暗記したものと、実際に解けるものを区別するため
ツール呼び出し	稼働中システムの実スキーマ	選択したツール、引数、多段階の接続を個別に評価する
根拠の遵守	与えられたコンテキスト	コンテキストになかった事実が出力された場合は誤りとする
現場診断	実測データと記録された故障	正解がシステム外部から得られる唯一の軸。判別が難しい正常状態を混在させ、誤警報を見逃しとは別に集計する

さらに、2つの原則を加えます。

ゲートの基準は測定「前」に決める。 結果を見てから基準を決めるのであれば、それは基準ではない
評価データが学習データに漏れていないことを、レビュー担当者自身が確認できなければならない。 数値を信じるよう求めるのではなく、再測定する方法を提供する

9. どこで動かすか — オンプレミスが基本である理由

製造データは通常、工場外へ持ち出せません。 プロセス条件自体が営業秘密であり、ネットワークが閉域網となっている現場も多いためです。そのため、設計は次のようになります。

モデルをデータのある場所へ配置する。 言語モデルは量子化チェックポイント（NVFP4）として1枚のGPUにロードし、OpenAI互換エンドポイントの背後で動作させる。設定にgpt-4oと記載されていても、社内モデルの互換名である
波形は小規模モデルで処理する。 100万パラメーター規模の時系列モデルはGPUなしで動作し、Edgeに配置可能で、設備ごとに個別調整してもコストはほとんどかからない — 1万台の設備に1万個のモデルを用意できる規模である（研究中であり、まだ製品経路には組み込んでいない）
推論とゲートを分離する。 軽量なAPIとGPUを使用する推論サーバーを分ければ、推論処理を別の装置へ移動または増設しても、呼び出し側のアドレスは変わらない
AI専用のデータベースを構築しない。 時系列、リレーショナル、キャッシュにはプラットフォームの元帳を共用する。データが二重化すると、「AIが見た値」と「画面に表示される値」に不整合が生じる

デプロイ構成についてはAIアーキテクチャ、4製品の連携方式については全体構成を参照してください。

導入前に確認すべきこと

製造AIを検討する際に、製品を問わず確認すべき質問です。

質問	望ましい回答
欠損をどう扱うか	0で埋めない。「未測定」として別途報告する
モデルを起動できなかった場合、何が出力されるか	フォールバックするが、フォールバックしたことをレスポンスに記載する
誤警報をどう集計するか	見逃しとは別に集計する。オペレーターが抑制でき、抑制後も記録を残す
予測に区間があるか	ある。また、その区間は実測残差に基づいている
言語モデルが数値を生成するか	生成しない。公式とツールが生成し、言語モデルはそれを読み取る
性能値をどのように測定したか	ジャッジモデルを使わず、基準を先に決め、レビュー担当者が再測定できるようにする
データが外部へ送信されるか	送信されない。閉域網でも同じ構成で動作する

1. 工場の信号は何が違うのか​

2. 層を分ける — 1つの大きなモデルで解決しない​

3. 異常検知 — 正常を学習し、逸脱を測る​

2種類の誤差を併用する​

コンテキスト長と短い履歴​

しきい値より「抑制する手段」が重要​

4. 予測 — 区間がなければ予測ではない​

点予測ではなく区間予測​

5. サイレント障害 — 製造AIで最も高くつくバグ​

6. 原因は順序に現れる — 故障メカニズム​

7. 説明 — 根拠だけに基づいて回答する​

8. どう評価するか — ジャッジモデルを使わない​

9. どこで動かすか — オンプレミスが基本である理由​

導入前に確認すべきこと​

関連資料​