メインコンテンツへスキップ
三田工場 技術サイト
undefined icon

予兆保全AIシステム

活用LV.4🏭 社内サーバー

FORESIGHT - 予兆保全AIシステム 開発報告

ビジョン:品質・稼働データから「壊れる前の異変」を掴み、突発停止ゼロを目指す


1. 現在の課題(Problem)

三田工場の保全業務で日常的に発生している課題を整理しました。

1-1. 突発停止(ドカ停)が予測できない

設備の異常は「止まってから」初めて発覚する。停止後に原因を調査し、部品交換・復旧を行う後手の対応が常態化している。突発停止は計画外の生産ロスを生み、ライン全体の稼働率を直撃する。

1-2. 品質不良の兆候を見落としている

複数の計測結果を担当者が個別に確認しているが、「わずかな変化」は目視や単純な閾値管理では見逃しやすい。不良が顕在化してから気づくため、流出リスクと手戻りコストが生じる。

1-3. データはあるのに予測に使えていない

Snowflakeには品質計測データが蓄積されているが、「どの変化が故障の前兆か」を判断するルールを人が定義し続けることは困難。データの価値が十分に活かされていない。

text
現状の保全フロー:
├── 設備が停止する / 品質不良が発生する  ← 異常が顕在化してから気づく
├── 原因調査(人力)                    ← 時間がかかる
├── 部品交換・復旧作業                  ← 計画外の停止ロス
└── → 「壊れたら直す」後手の保全が続く

2. FOURESIGHTでこう変わる(Solution)

# 現状(BEFORE) 導入後(AFTER)
1 設備が止まってから異常を認識 AIが事前に異変を検知し、止まる前に保全担当者へ通知
2 閾値管理では「わずかな変化」を見落とす 多モデルアンサンブルが複合的な異常パターンを孤立点として検出
3 データ分析は属人的・事後的 安定期をベースラインに自動学習し、継続的に判定
4 通知手段がなく担当者が気づけない メール自動通知(Amazon SNS)で異常時に即アラート
5 ダッシュボードで傾向を見る手段がない Webアプリで異常率トレンドを可視化(今後実装)

FOURESIGHTの処理構成

text
FORESIGHT
└── データ収集・前処理
    ├── Snowflakeから複数計測値を取得
    └── Amazon S3へ転送・前処理

        ├── AIモデル群(アンサンブル)
        │   ├── RandomForest
        │   ├── IsolationForest
        │   ├── XGBoost
        │   ├── LocalOutlierFactor
        │   ├── PCA_Mahalanobis
        │   ├── LightGBM
        │   └── DBSCAN
        │       ↓
        ├── 異常スコア統合(上位モデルを組み合わせ)

        └── 判定結果
            ├── 正常 → 記録のみ
            └── 異常検知 → Amazon SNS → メール通知

複数モデルの判定を統合することで、単一モデルでは見落とす「微細な違和感」をとらえます。


3. システム全体像

text
┌──────────────┐    ┌──────────────┐    ┌──────────────────────┐    ┌──────────────┐
│  Snowflake   │ ─→ │  Amazon S3   │ ─→ │  AWS Lambda          │ ─→ │ Amazon SNS   │
│ (計測データ) │    │ (前処理・     │    │  予測/学習モデル     │    │              │
│              │    │  学習データ)  │    │  異常検知アルゴリズム │    │              │
└──────────────┘    └──────────────┘    └──────────────────────┘    └──────┬───────┘
                                                  ↑ ↓                       │
                                         ┌──────────────────┐               ↓
                                         │ Amazon EventBridge│       保全担当者へ
                                         │ (スケジュール/    │       メール通知
                                         │  イベント制御)   │
                                         └──────────────────┘
                                                              ↓(今後)
                                                       ┌──────────────┐
                                                       │   Webアプリ  │
                                                       │ 異常率トレンド│
                                                       └──────────────┘

技術スタック

レイヤー 技術
データソース Snowflake(品質・計測データ)
ストレージ Amazon S3(データ転送・前処理・学習データ)
AI推論 AWS Lambda(Python)+ 多モデルアンサンブル
イベント制御 Amazon EventBridge(定期実行・トリガー)
通知 Amazon SNS(メール)
フロントエンド Webアプリ(今後実装)

4. 主要機能の詳細

4-1. 安定期ベースライン学習

「正常とはどういう状態か」をAIに覚えさせる仕組み。設備が安定稼働していた期間のデータを学習データとして指定し、各モデルが正常パターンを習得する。

text
学習データ設定(例: 2025/12/15〜2026/1/10)

7種類のモデルが「正常状態」を学習

それ以外の期間のデータを入力すると
「どれだけ正常から外れているか」を自動スコアリング

これまでの単純な閾値管理では見逃していた複合的な変化を、孤立点(Anomaly Point)として検出します。

4-2. 多モデルアンサンブル判定

単一モデルの弱点を補うため、7種類のアルゴリズムを組み合わせて診断。各モデルの判定を統合し、上位モデルの結果を重み付けして最終スコアを算出。

text
計測データ(複数チャンネル)

┌─────────────────────────────────────────┐
│ RandomForest  IsolationForest  XGBoost  │
│ LOF  PCA_Mahalanobis  LightGBM  DBSCAN │
└─────────────────────────────────────────┘
  ↓ 各モデルの異常スコアを統合
最終異常判定(正常 / 要注意 / 異常)

4-3. 異常検知時のリアルタイム通知

Amazon EventBridgeが定期的にLambdaをトリガー。Lambda上でAI判定を実行し、異常を検知した場合はAmazon SNS経由で保全担当者へ即時メールを送信。

text
Lambda判定完了
  ├── 正常 → 結果をS3に記録
  └── 異常スコア閾値超過

      Amazon SNS → メール送信
      (保全担当者へ:対象ライン・日時・スコア)

4-4. 異常率トレンド可視化(検証済み)

各日付における「モデルグループ別の異常率」を時系列グラフで表示。トラブル発生前の「荒れ」と、メンテナンス後の「安定」を可視化し、予兆保全の有効性を実証。

text
異常率グラフ(Anomaly Rate Trend by Date)
  ├── Model_Group 0〜3 を色分け表示
  ├── トラブル前:各モデルが80〜100%の高異常率
  ├── メンテナンス後:急激に0〜5%へ収束
  └── → 「壊れる前に荒れていた」ことを事後検証で確認

5. 外部システム連携

text
Snowflake                          FORESIGHT(AWS)
┌──────────────────┐              ┌──────────────────────────┐
│ 品質計測データ    │  ──転送──→  │ Amazon S3                │
│ (複数チャンネル)│              │ (前処理・学習データ管理)│
└──────────────────┘              └──────────────────────────┘

                                  ┌──────────────────────────┐
                                  │ AWS Lambda               │
                                  │ 7種類のAIモデルで判定    │
                                  └──────────────────────────┘

                         Amazon EventBridge(スケジュール制御)

                                  ┌──────────────────────────┐
                                  │ Amazon SNS               │
                                  │ 異常時 → メール通知       │
                                  └──────────────────────────┘
  • Snowflake連携: 生産ラインの品質計測データを自動取得
  • S3管理: 生データ・前処理データ・学習データ・ツール判定結果を一元管理
  • Lambda推論: サーバーレスで AI判定を実行。スケーラブルかつ低コスト
  • EventBridge: 定期実行・条件トリガーでパイプラインを自動制御
  • SNS通知: 担当者へのメール通知をコードなしで設定・管理

6. 実装済みの価値

価値 詳細
データパイプライン完成 Snowflake→S3→Lambda→SNSの一気通貫パイプラインを構築済み
予兆検知の有効性実証 実際のトラブルデータで「故障前に異常率が急上昇」することを確認
閾値管理の限界を突破 7モデルのアンサンブルにより、従来手法では見逃す微細な異変を検出
自動通知基盤の完成 異常検知時に保全担当者へ即時メール通知する仕組みが稼働済み
ベースライン学習の仕組み 安定期を指定して「正常とは何か」をAIに学習させる手法を確立

7. 検証結果

AIモデル有効性の検証

2025年に発生した突発停止・品質不良事例に対し、事後検証を実施。

検証項目 結果
トラブル発生前(2025/10〜12月中旬)の異常率 80〜100%(全モデルで高水準)
メンテナンス後(2026/1月以降)の異常率 0〜5%(急激に安定)
使用モデル数 7種類(RandomForest / IsolationForest / XGBoost / LOF / PCA / LightGBM / DBSCAN)
モデルグループ数 4グループ

「案の定、トラブルが起きる前は大きく荒れていた」 — AIが事前に異変を捉えていたことが事後検証で実証された。

現時点のパイプライン状況

項目 状況
データ収集(Snowflake→S3) 稼働中
AI推論(Lambda) 検証済み
異常通知(SNS) 設定済み
Webアプリ 未実装(今後)
本番ライン適用 検証段階

8. FOURESIGHTで描く未来(Benefit)

目指す世界

text
┌──────────────────────┐
  │  AIが異変を検知       │  ← 人が気づく前に自動検出
  └──────────┬───────────┘

  ┌──────────────────────┐
  │  保全担当者へ即時通知 │  ← メール・将来はアプリ通知
  └──────────┬───────────┘

  ┌─────┐ ┌──────┐ ┌──────────┐
  │原因  │ │対応   │ │計画的    │  ← データで判断・計画保全へ
  │確認  │ │スケジュール│ │メンテナンス│
  └─────┘ └──────┘ └──────────┘

  ┌──────────────────────┐
  │  突発停止ゼロ・       │
  │  品質不良の未然防止   │
  └──────────────────────┘

具体的に実現したいこと

Webアプリによる可視化

  • 異常率トレンドグラフをブラウザで確認
  • ライン・設備別の異常履歴ダッシュボード
  • QUICKとの連携(稼働データ + 予兆データの統合表示)

適用範囲の拡大

  • 現在の検証ラインから三田工場全ラインへ展開
  • 対象計測データの種類を拡充

AIモデルの継続改善

  • 新たなトラブル事例を学習データに追加し精度向上
  • リアルタイム推論(現在はバッチ)への移行

9. 開発ロードマップ

text
Phase 1: AIパイプライン構築 [DONE]    Phase 2: Webアプリ実装 [NEXT]        Phase 3: 全展開・高度化 [FUTURE]
──────────────────────────            ──────────────────────────            ──────────────────────────
✓ Snowflake→S3データ連携              □ 異常率トレンドダッシュボード          □ 全ライン展開
✓ 7種類のAIモデル実装                 □ ライン・設備別フィルタ               □ QUICKとの統合表示
✓ アンサンブル判定ロジック             □ 異常履歴の一覧・検索                □ リアルタイム推論
✓ Amazon SNSメール通知                □ 通知設定のUI管理                    □ Teamsアラート連携
✓ Amazon EventBridge制御              □ モデル精度のモニタリング             □ 他工場への横展開
✓ 有効性の事後検証(実トラブル)                                             □ AIモデルの自動再学習

まとめ

  1. 品質計測データを7種類のAIアンサンブルモデルで分析し、「閾値管理では見えない予兆」を検出する仕組みを構築済み
  2. 実際のトラブル事例への事後検証で**「故障前に異常率が急上昇していた」** ことを実証。予兆保全の有効性を確認
  3. その先にWebアプリ化・全ライン展開を通じ、「壊れたら直す」から「予兆で防ぐ」保全文化への転換を実現する

FORESIGHT データが語る、故障の予兆を見逃さない。

FORESIGHT - 予兆保全AIシステム 開発報告

ビジョン:品質・稼働データから「壊れる前の異変」を掴み、突発停止ゼロを目指す


1. 現在の課題(Problem)

三田工場の保全業務で日常的に発生している課題を整理しました。

1-1. 突発停止(ドカ停)が予測できない

設備の異常は「止まってから」初めて発覚する。停止後に原因を調査し、部品交換・復旧を行う後手の対応が常態化している。突発停止は計画外の生産ロスを生み、ライン全体の稼働率を直撃する。

1-2. 品質不良の兆候を見落としている

複数の計測結果を担当者が個別に確認しているが、「わずかな変化」は目視や単純な閾値管理では見逃しやすい。不良が顕在化してから気づくため、流出リスクと手戻りコストが生じる。

1-3. データはあるのに予測に使えていない

Snowflakeには品質計測データが蓄積されているが、「どの変化が故障の前兆か」を判断するルールを人が定義し続けることは困難。データの価値が十分に活かされていない。

text
現状の保全フロー:
├── 設備が停止する / 品質不良が発生する  ← 異常が顕在化してから気づく
├── 原因調査(人力)                    ← 時間がかかる
├── 部品交換・復旧作業                  ← 計画外の停止ロス
└── → 「壊れたら直す」後手の保全が続く

2. FOURESIGHTでこう変わる(Solution)

# 現状(BEFORE) 導入後(AFTER)
1 設備が止まってから異常を認識 AIが事前に異変を検知し、止まる前に保全担当者へ通知
2 閾値管理では「わずかな変化」を見落とす 多モデルアンサンブルが複合的な異常パターンを孤立点として検出
3 データ分析は属人的・事後的 安定期をベースラインに自動学習し、継続的に判定
4 通知手段がなく担当者が気づけない メール自動通知(Amazon SNS)で異常時に即アラート
5 ダッシュボードで傾向を見る手段がない Webアプリで異常率トレンドを可視化(今後実装)

FOURESIGHTの処理構成

text
FORESIGHT
└── データ収集・前処理
    ├── Snowflakeから複数計測値を取得
    └── Amazon S3へ転送・前処理

        ├── AIモデル群(アンサンブル)
        │   ├── RandomForest
        │   ├── IsolationForest
        │   ├── XGBoost
        │   ├── LocalOutlierFactor
        │   ├── PCA_Mahalanobis
        │   ├── LightGBM
        │   └── DBSCAN
        │       ↓
        ├── 異常スコア統合(上位モデルを組み合わせ)

        └── 判定結果
            ├── 正常 → 記録のみ
            └── 異常検知 → Amazon SNS → メール通知

複数モデルの判定を統合することで、単一モデルでは見落とす「微細な違和感」をとらえます。


3. システム全体像

text
┌──────────────┐    ┌──────────────┐    ┌──────────────────────┐    ┌──────────────┐
│  Snowflake   │ ─→ │  Amazon S3   │ ─→ │  AWS Lambda          │ ─→ │ Amazon SNS   │
│ (計測データ) │    │ (前処理・     │    │  予測/学習モデル     │    │              │
│              │    │  学習データ)  │    │  異常検知アルゴリズム │    │              │
└──────────────┘    └──────────────┘    └──────────────────────┘    └──────┬───────┘
                                                  ↑ ↓                       │
                                         ┌──────────────────┐               ↓
                                         │ Amazon EventBridge│       保全担当者へ
                                         │ (スケジュール/    │       メール通知
                                         │  イベント制御)   │
                                         └──────────────────┘
                                                              ↓(今後)
                                                       ┌──────────────┐
                                                       │   Webアプリ  │
                                                       │ 異常率トレンド│
                                                       └──────────────┘

技術スタック

レイヤー 技術
データソース Snowflake(品質・計測データ)
ストレージ Amazon S3(データ転送・前処理・学習データ)
AI推論 AWS Lambda(Python)+ 多モデルアンサンブル
イベント制御 Amazon EventBridge(定期実行・トリガー)
通知 Amazon SNS(メール)
フロントエンド Webアプリ(今後実装)

4. 主要機能の詳細

4-1. 安定期ベースライン学習

「正常とはどういう状態か」をAIに覚えさせる仕組み。設備が安定稼働していた期間のデータを学習データとして指定し、各モデルが正常パターンを習得する。

text
学習データ設定(例: 2025/12/15〜2026/1/10)

7種類のモデルが「正常状態」を学習

それ以外の期間のデータを入力すると
「どれだけ正常から外れているか」を自動スコアリング

これまでの単純な閾値管理では見逃していた複合的な変化を、孤立点(Anomaly Point)として検出します。

4-2. 多モデルアンサンブル判定

単一モデルの弱点を補うため、7種類のアルゴリズムを組み合わせて診断。各モデルの判定を統合し、上位モデルの結果を重み付けして最終スコアを算出。

text
計測データ(複数チャンネル)

┌─────────────────────────────────────────┐
│ RandomForest  IsolationForest  XGBoost  │
│ LOF  PCA_Mahalanobis  LightGBM  DBSCAN │
└─────────────────────────────────────────┘
  ↓ 各モデルの異常スコアを統合
最終異常判定(正常 / 要注意 / 異常)

4-3. 異常検知時のリアルタイム通知

Amazon EventBridgeが定期的にLambdaをトリガー。Lambda上でAI判定を実行し、異常を検知した場合はAmazon SNS経由で保全担当者へ即時メールを送信。

text
Lambda判定完了
  ├── 正常 → 結果をS3に記録
  └── 異常スコア閾値超過

      Amazon SNS → メール送信
      (保全担当者へ:対象ライン・日時・スコア)

4-4. 異常率トレンド可視化(検証済み)

各日付における「モデルグループ別の異常率」を時系列グラフで表示。トラブル発生前の「荒れ」と、メンテナンス後の「安定」を可視化し、予兆保全の有効性を実証。

text
異常率グラフ(Anomaly Rate Trend by Date)
  ├── Model_Group 0〜3 を色分け表示
  ├── トラブル前:各モデルが80〜100%の高異常率
  ├── メンテナンス後:急激に0〜5%へ収束
  └── → 「壊れる前に荒れていた」ことを事後検証で確認

5. 外部システム連携

text
Snowflake                          FORESIGHT(AWS)
┌──────────────────┐              ┌──────────────────────────┐
│ 品質計測データ    │  ──転送──→  │ Amazon S3                │
│ (複数チャンネル)│              │ (前処理・学習データ管理)│
└──────────────────┘              └──────────────────────────┘

                                  ┌──────────────────────────┐
                                  │ AWS Lambda               │
                                  │ 7種類のAIモデルで判定    │
                                  └──────────────────────────┘

                         Amazon EventBridge(スケジュール制御)

                                  ┌──────────────────────────┐
                                  │ Amazon SNS               │
                                  │ 異常時 → メール通知       │
                                  └──────────────────────────┘
  • Snowflake連携: 生産ラインの品質計測データを自動取得
  • S3管理: 生データ・前処理データ・学習データ・ツール判定結果を一元管理
  • Lambda推論: サーバーレスで AI判定を実行。スケーラブルかつ低コスト
  • EventBridge: 定期実行・条件トリガーでパイプラインを自動制御
  • SNS通知: 担当者へのメール通知をコードなしで設定・管理

6. 実装済みの価値

価値 詳細
データパイプライン完成 Snowflake→S3→Lambda→SNSの一気通貫パイプラインを構築済み
予兆検知の有効性実証 実際のトラブルデータで「故障前に異常率が急上昇」することを確認
閾値管理の限界を突破 7モデルのアンサンブルにより、従来手法では見逃す微細な異変を検出
自動通知基盤の完成 異常検知時に保全担当者へ即時メール通知する仕組みが稼働済み
ベースライン学習の仕組み 安定期を指定して「正常とは何か」をAIに学習させる手法を確立

7. 検証結果

AIモデル有効性の検証

2025年に発生した突発停止・品質不良事例に対し、事後検証を実施。

検証項目 結果
トラブル発生前(2025/10〜12月中旬)の異常率 80〜100%(全モデルで高水準)
メンテナンス後(2026/1月以降)の異常率 0〜5%(急激に安定)
使用モデル数 7種類(RandomForest / IsolationForest / XGBoost / LOF / PCA / LightGBM / DBSCAN)
モデルグループ数 4グループ

「案の定、トラブルが起きる前は大きく荒れていた」 — AIが事前に異変を捉えていたことが事後検証で実証された。

現時点のパイプライン状況

項目 状況
データ収集(Snowflake→S3) 稼働中
AI推論(Lambda) 検証済み
異常通知(SNS) 設定済み
Webアプリ 未実装(今後)
本番ライン適用 検証段階

8. FOURESIGHTで描く未来(Benefit)

目指す世界

text
┌──────────────────────┐
  │  AIが異変を検知       │  ← 人が気づく前に自動検出
  └──────────┬───────────┘

  ┌──────────────────────┐
  │  保全担当者へ即時通知 │  ← メール・将来はアプリ通知
  └──────────┬───────────┘

  ┌─────┐ ┌──────┐ ┌──────────┐
  │原因  │ │対応   │ │計画的    │  ← データで判断・計画保全へ
  │確認  │ │スケジュール│ │メンテナンス│
  └─────┘ └──────┘ └──────────┘

  ┌──────────────────────┐
  │  突発停止ゼロ・       │
  │  品質不良の未然防止   │
  └──────────────────────┘

具体的に実現したいこと

Webアプリによる可視化

  • 異常率トレンドグラフをブラウザで確認
  • ライン・設備別の異常履歴ダッシュボード
  • QUICKとの連携(稼働データ + 予兆データの統合表示)

適用範囲の拡大

  • 現在の検証ラインから三田工場全ラインへ展開
  • 対象計測データの種類を拡充

AIモデルの継続改善

  • 新たなトラブル事例を学習データに追加し精度向上
  • リアルタイム推論(現在はバッチ)への移行

9. 開発ロードマップ

text
Phase 1: AIパイプライン構築 [DONE]    Phase 2: Webアプリ実装 [NEXT]        Phase 3: 全展開・高度化 [FUTURE]
──────────────────────────            ──────────────────────────            ──────────────────────────
✓ Snowflake→S3データ連携              □ 異常率トレンドダッシュボード          □ 全ライン展開
✓ 7種類のAIモデル実装                 □ ライン・設備別フィルタ               □ QUICKとの統合表示
✓ アンサンブル判定ロジック             □ 異常履歴の一覧・検索                □ リアルタイム推論
✓ Amazon SNSメール通知                □ 通知設定のUI管理                    □ Teamsアラート連携
✓ Amazon EventBridge制御              □ モデル精度のモニタリング             □ 他工場への横展開
✓ 有効性の事後検証(実トラブル)                                             □ AIモデルの自動再学習

まとめ

  1. 品質計測データを7種類のAIアンサンブルモデルで分析し、「閾値管理では見えない予兆」を検出する仕組みを構築済み
  2. 実際のトラブル事例への事後検証で**「故障前に異常率が急上昇していた」** ことを実証。予兆保全の有効性を確認
  3. その先にWebアプリ化・全ライン展開を通じ、「壊れたら直す」から「予兆で防ぐ」保全文化への転換を実現する

FORESIGHT データが語る、故障の予兆を見逃さない。