予兆保全AIシステム
FORESIGHT - 予兆保全AIシステム 開発報告
ビジョン:品質・稼働データから「壊れる前の異変」を掴み、突発停止ゼロを目指す
1. 現在の課題(Problem)
三田工場の保全業務で日常的に発生している課題を整理しました。
1-1. 突発停止(ドカ停)が予測できない
設備の異常は「止まってから」初めて発覚する。停止後に原因を調査し、部品交換・復旧を行う後手の対応が常態化している。突発停止は計画外の生産ロスを生み、ライン全体の稼働率を直撃する。
1-2. 品質不良の兆候を見落としている
複数の計測結果を担当者が個別に確認しているが、「わずかな変化」は目視や単純な閾値管理では見逃しやすい。不良が顕在化してから気づくため、流出リスクと手戻りコストが生じる。
1-3. データはあるのに予測に使えていない
Snowflakeには品質計測データが蓄積されているが、「どの変化が故障の前兆か」を判断するルールを人が定義し続けることは困難。データの価値が十分に活かされていない。
現状の保全フロー:
├── 設備が停止する / 品質不良が発生する ← 異常が顕在化してから気づく
├── 原因調査(人力) ← 時間がかかる
├── 部品交換・復旧作業 ← 計画外の停止ロス
└── → 「壊れたら直す」後手の保全が続く2. FOURESIGHTでこう変わる(Solution)
| # | 現状(BEFORE) | 導入後(AFTER) |
|---|---|---|
| 1 | 設備が止まってから異常を認識 | AIが事前に異変を検知し、止まる前に保全担当者へ通知 |
| 2 | 閾値管理では「わずかな変化」を見落とす | 多モデルアンサンブルが複合的な異常パターンを孤立点として検出 |
| 3 | データ分析は属人的・事後的 | 安定期をベースラインに自動学習し、継続的に判定 |
| 4 | 通知手段がなく担当者が気づけない | メール自動通知(Amazon SNS)で異常時に即アラート |
| 5 | ダッシュボードで傾向を見る手段がない | Webアプリで異常率トレンドを可視化(今後実装) |
FOURESIGHTの処理構成
FORESIGHT
└── データ収集・前処理
├── Snowflakeから複数計測値を取得
└── Amazon S3へ転送・前処理
│
├── AIモデル群(アンサンブル)
│ ├── RandomForest
│ ├── IsolationForest
│ ├── XGBoost
│ ├── LocalOutlierFactor
│ ├── PCA_Mahalanobis
│ ├── LightGBM
│ └── DBSCAN
│ ↓
├── 異常スコア統合(上位モデルを組み合わせ)
│
└── 判定結果
├── 正常 → 記録のみ
└── 異常検知 → Amazon SNS → メール通知複数モデルの判定を統合することで、単一モデルでは見落とす「微細な違和感」をとらえます。
3. システム全体像
┌──────────────┐ ┌──────────────┐ ┌──────────────────────┐ ┌──────────────┐
│ 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に覚えさせる仕組み。設備が安定稼働していた期間のデータを学習データとして指定し、各モデルが正常パターンを習得する。
学習データ設定(例: 2025/12/15〜2026/1/10)
↓
7種類のモデルが「正常状態」を学習
↓
それ以外の期間のデータを入力すると
「どれだけ正常から外れているか」を自動スコアリングこれまでの単純な閾値管理では見逃していた複合的な変化を、孤立点(Anomaly Point)として検出します。
4-2. 多モデルアンサンブル判定
単一モデルの弱点を補うため、7種類のアルゴリズムを組み合わせて診断。各モデルの判定を統合し、上位モデルの結果を重み付けして最終スコアを算出。
計測データ(複数チャンネル)
↓
┌─────────────────────────────────────────┐
│ RandomForest IsolationForest XGBoost │
│ LOF PCA_Mahalanobis LightGBM DBSCAN │
└─────────────────────────────────────────┘
↓ 各モデルの異常スコアを統合
最終異常判定(正常 / 要注意 / 異常)4-3. 異常検知時のリアルタイム通知
Amazon EventBridgeが定期的にLambdaをトリガー。Lambda上でAI判定を実行し、異常を検知した場合はAmazon SNS経由で保全担当者へ即時メールを送信。
Lambda判定完了
├── 正常 → 結果をS3に記録
└── 異常スコア閾値超過
↓
Amazon SNS → メール送信
(保全担当者へ:対象ライン・日時・スコア)4-4. 異常率トレンド可視化(検証済み)
各日付における「モデルグループ別の異常率」を時系列グラフで表示。トラブル発生前の「荒れ」と、メンテナンス後の「安定」を可視化し、予兆保全の有効性を実証。
異常率グラフ(Anomaly Rate Trend by Date)
├── Model_Group 0〜3 を色分け表示
├── トラブル前:各モデルが80〜100%の高異常率
├── メンテナンス後:急激に0〜5%へ収束
└── → 「壊れる前に荒れていた」ことを事後検証で確認5. 外部システム連携
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)
目指す世界
┌──────────────────────┐
│ AIが異変を検知 │ ← 人が気づく前に自動検出
└──────────┬───────────┘
↓
┌──────────────────────┐
│ 保全担当者へ即時通知 │ ← メール・将来はアプリ通知
└──────────┬───────────┘
↓
┌─────┐ ┌──────┐ ┌──────────┐
│原因 │ │対応 │ │計画的 │ ← データで判断・計画保全へ
│確認 │ │スケジュール│ │メンテナンス│
└─────┘ └──────┘ └──────────┘
↓
┌──────────────────────┐
│ 突発停止ゼロ・ │
│ 品質不良の未然防止 │
└──────────────────────┘具体的に実現したいこと
Webアプリによる可視化
- 異常率トレンドグラフをブラウザで確認
- ライン・設備別の異常履歴ダッシュボード
- QUICKとの連携(稼働データ + 予兆データの統合表示)
適用範囲の拡大
- 現在の検証ラインから三田工場全ラインへ展開
- 対象計測データの種類を拡充
AIモデルの継続改善
- 新たなトラブル事例を学習データに追加し精度向上
- リアルタイム推論(現在はバッチ)への移行
9. 開発ロードマップ
Phase 1: AIパイプライン構築 [DONE] Phase 2: Webアプリ実装 [NEXT] Phase 3: 全展開・高度化 [FUTURE]
────────────────────────── ────────────────────────── ──────────────────────────
✓ Snowflake→S3データ連携 □ 異常率トレンドダッシュボード □ 全ライン展開
✓ 7種類のAIモデル実装 □ ライン・設備別フィルタ □ QUICKとの統合表示
✓ アンサンブル判定ロジック □ 異常履歴の一覧・検索 □ リアルタイム推論
✓ Amazon SNSメール通知 □ 通知設定のUI管理 □ Teamsアラート連携
✓ Amazon EventBridge制御 □ モデル精度のモニタリング □ 他工場への横展開
✓ 有効性の事後検証(実トラブル) □ AIモデルの自動再学習まとめ
- 品質計測データを7種類のAIアンサンブルモデルで分析し、「閾値管理では見えない予兆」を検出する仕組みを構築済み
- 実際のトラブル事例への事後検証で**「故障前に異常率が急上昇していた」** ことを実証。予兆保全の有効性を確認
- その先にWebアプリ化・全ライン展開を通じ、「壊れたら直す」から「予兆で防ぐ」保全文化への転換を実現する
FORESIGHT データが語る、故障の予兆を見逃さない。
FORESIGHT - 予兆保全AIシステム 開発報告
ビジョン:品質・稼働データから「壊れる前の異変」を掴み、突発停止ゼロを目指す
1. 現在の課題(Problem)
三田工場の保全業務で日常的に発生している課題を整理しました。
1-1. 突発停止(ドカ停)が予測できない
設備の異常は「止まってから」初めて発覚する。停止後に原因を調査し、部品交換・復旧を行う後手の対応が常態化している。突発停止は計画外の生産ロスを生み、ライン全体の稼働率を直撃する。
1-2. 品質不良の兆候を見落としている
複数の計測結果を担当者が個別に確認しているが、「わずかな変化」は目視や単純な閾値管理では見逃しやすい。不良が顕在化してから気づくため、流出リスクと手戻りコストが生じる。
1-3. データはあるのに予測に使えていない
Snowflakeには品質計測データが蓄積されているが、「どの変化が故障の前兆か」を判断するルールを人が定義し続けることは困難。データの価値が十分に活かされていない。
現状の保全フロー:
├── 設備が停止する / 品質不良が発生する ← 異常が顕在化してから気づく
├── 原因調査(人力) ← 時間がかかる
├── 部品交換・復旧作業 ← 計画外の停止ロス
└── → 「壊れたら直す」後手の保全が続く2. FOURESIGHTでこう変わる(Solution)
| # | 現状(BEFORE) | 導入後(AFTER) |
|---|---|---|
| 1 | 設備が止まってから異常を認識 | AIが事前に異変を検知し、止まる前に保全担当者へ通知 |
| 2 | 閾値管理では「わずかな変化」を見落とす | 多モデルアンサンブルが複合的な異常パターンを孤立点として検出 |
| 3 | データ分析は属人的・事後的 | 安定期をベースラインに自動学習し、継続的に判定 |
| 4 | 通知手段がなく担当者が気づけない | メール自動通知(Amazon SNS)で異常時に即アラート |
| 5 | ダッシュボードで傾向を見る手段がない | Webアプリで異常率トレンドを可視化(今後実装) |
FOURESIGHTの処理構成
FORESIGHT
└── データ収集・前処理
├── Snowflakeから複数計測値を取得
└── Amazon S3へ転送・前処理
│
├── AIモデル群(アンサンブル)
│ ├── RandomForest
│ ├── IsolationForest
│ ├── XGBoost
│ ├── LocalOutlierFactor
│ ├── PCA_Mahalanobis
│ ├── LightGBM
│ └── DBSCAN
│ ↓
├── 異常スコア統合(上位モデルを組み合わせ)
│
└── 判定結果
├── 正常 → 記録のみ
└── 異常検知 → Amazon SNS → メール通知複数モデルの判定を統合することで、単一モデルでは見落とす「微細な違和感」をとらえます。
3. システム全体像
┌──────────────┐ ┌──────────────┐ ┌──────────────────────┐ ┌──────────────┐
│ 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に覚えさせる仕組み。設備が安定稼働していた期間のデータを学習データとして指定し、各モデルが正常パターンを習得する。
学習データ設定(例: 2025/12/15〜2026/1/10)
↓
7種類のモデルが「正常状態」を学習
↓
それ以外の期間のデータを入力すると
「どれだけ正常から外れているか」を自動スコアリングこれまでの単純な閾値管理では見逃していた複合的な変化を、孤立点(Anomaly Point)として検出します。
4-2. 多モデルアンサンブル判定
単一モデルの弱点を補うため、7種類のアルゴリズムを組み合わせて診断。各モデルの判定を統合し、上位モデルの結果を重み付けして最終スコアを算出。
計測データ(複数チャンネル)
↓
┌─────────────────────────────────────────┐
│ RandomForest IsolationForest XGBoost │
│ LOF PCA_Mahalanobis LightGBM DBSCAN │
└─────────────────────────────────────────┘
↓ 各モデルの異常スコアを統合
最終異常判定(正常 / 要注意 / 異常)4-3. 異常検知時のリアルタイム通知
Amazon EventBridgeが定期的にLambdaをトリガー。Lambda上でAI判定を実行し、異常を検知した場合はAmazon SNS経由で保全担当者へ即時メールを送信。
Lambda判定完了
├── 正常 → 結果をS3に記録
└── 異常スコア閾値超過
↓
Amazon SNS → メール送信
(保全担当者へ:対象ライン・日時・スコア)4-4. 異常率トレンド可視化(検証済み)
各日付における「モデルグループ別の異常率」を時系列グラフで表示。トラブル発生前の「荒れ」と、メンテナンス後の「安定」を可視化し、予兆保全の有効性を実証。
異常率グラフ(Anomaly Rate Trend by Date)
├── Model_Group 0〜3 を色分け表示
├── トラブル前:各モデルが80〜100%の高異常率
├── メンテナンス後:急激に0〜5%へ収束
└── → 「壊れる前に荒れていた」ことを事後検証で確認5. 外部システム連携
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)
目指す世界
┌──────────────────────┐
│ AIが異変を検知 │ ← 人が気づく前に自動検出
└──────────┬───────────┘
↓
┌──────────────────────┐
│ 保全担当者へ即時通知 │ ← メール・将来はアプリ通知
└──────────┬───────────┘
↓
┌─────┐ ┌──────┐ ┌──────────┐
│原因 │ │対応 │ │計画的 │ ← データで判断・計画保全へ
│確認 │ │スケジュール│ │メンテナンス│
└─────┘ └──────┘ └──────────┘
↓
┌──────────────────────┐
│ 突発停止ゼロ・ │
│ 品質不良の未然防止 │
└──────────────────────┘具体的に実現したいこと
Webアプリによる可視化
- 異常率トレンドグラフをブラウザで確認
- ライン・設備別の異常履歴ダッシュボード
- QUICKとの連携(稼働データ + 予兆データの統合表示)
適用範囲の拡大
- 現在の検証ラインから三田工場全ラインへ展開
- 対象計測データの種類を拡充
AIモデルの継続改善
- 新たなトラブル事例を学習データに追加し精度向上
- リアルタイム推論(現在はバッチ)への移行
9. 開発ロードマップ
Phase 1: AIパイプライン構築 [DONE] Phase 2: Webアプリ実装 [NEXT] Phase 3: 全展開・高度化 [FUTURE]
────────────────────────── ────────────────────────── ──────────────────────────
✓ Snowflake→S3データ連携 □ 異常率トレンドダッシュボード □ 全ライン展開
✓ 7種類のAIモデル実装 □ ライン・設備別フィルタ □ QUICKとの統合表示
✓ アンサンブル判定ロジック □ 異常履歴の一覧・検索 □ リアルタイム推論
✓ Amazon SNSメール通知 □ 通知設定のUI管理 □ Teamsアラート連携
✓ Amazon EventBridge制御 □ モデル精度のモニタリング □ 他工場への横展開
✓ 有効性の事後検証(実トラブル) □ AIモデルの自動再学習まとめ
- 品質計測データを7種類のAIアンサンブルモデルで分析し、「閾値管理では見えない予兆」を検出する仕組みを構築済み
- 実際のトラブル事例への事後検証で**「故障前に異常率が急上昇していた」** ことを実証。予兆保全の有効性を確認
- その先にWebアプリ化・全ライン展開を通じ、「壊れたら直す」から「予兆で防ぐ」保全文化への転換を実現する
FORESIGHT データが語る、故障の予兆を見逃さない。