製造業の設備故障診断ボット：Dify Knowledge Base + Workflow による実践設計ガイド

はじめに

製造業の現場では、設備トラブルが発生するたびにベテラン技術者が呼び出され、経験と勘に頼った対応が繰り返されている。しかし、熟練者の高齢化・退職が進む中、この属人的な故障対応モデルは持続可能ではない。設備マニュアル、SOP、過去の修理記録、アラームコード一覧――これらの情報は社内に存在するものの、分散・非構造化された状態では、現場の即応性に結びつかない。

本稿では、Dify の Knowledge Base（ナレッジベース）と Workflow を組み合わせ、製造業設備の故障診断アシスタントを構築する方法を、アーキテクチャ設計からチューニングまで実践的に解説する。

背景と課題

製造業における故障対応の現実

なぜ Dify が適しているのか

Dify は以下の点で製造業の故障診断シナリオに適合する。

• Knowledge Base による複数ナレッジソースの統合管理
• Workflow によるルーティング・条件分岐の視覚的設計
• セルフホスト（Docker Compose） によるオンプレミス・閉域網デプロイ
• Rerank や Score Threshold など、検索パラメータの細かいチューニング
• HTTP Request ノード を通じた MES / SCADA 等の外部システム連携

全体アーキテクチャ

flowchart TD
    A[現場担当者の問い合わせ] --> B[Dify Chatbot / API]
    B --> C{質問分類ノード}
    C -->|設備仕様| D[KB: 静的知識]
    C -->|標準手順| E[KB: SOP・アラームコード]
    C -->|過去事例| F[KB: 修理記録・ナレッジ]
    C -->|現在状態| G[HTTP Request: MES/SCADA]
    D --> H[回答生成ノード]
    E --> H
    F --> H
    G --> H
    H --> I[構造化回答出力]
    I --> J{信頼度チェック}
    J -->|高| K[現場担当者へ回答]
    J -->|低| L[エスカレーション: 保全チームへ通知]

ナレッジベースの階層構造設計

設計思想：4 層モデル

すべてのドキュメントを 1 つの Knowledge Base に投入するのは、製造業では致命的なアンチパターンである。情報の性質に応じて Knowledge Base を分割し、質問タイプごとに検索先を切り替える「階層型ナレッジ設計」を推奨する。

第 1 層：設備静的知識ベース

役割: 「この設備は本来どう動くべきか」に答える。

Chunk 戦略: 章・サブシステム・部品モジュール単位で分割。固定文字数分割は避ける。

第 2 層：標準操作・故障対応知識ベース

役割: 「この異常が出たら、標準ではどう対処するか」に答える。

Chunk 戦略: アラームコード単位、手順段落単位で分割。1 チャンクが 1 つの対処パスに対応するのが理想。

第 3 層：歴史的事例知識ベース

役割: 「過去に似た症状が出たとき、実際にはどう解決したか」に答える。

Chunk 戦略: 1 件の故障 = 1 チャンク。メタデータとして設備ID・日付・アラームコードを付与。

第 4 層：リアルタイム補助情報（外部連携）

役割: 「今この設備はどういう状態か」に答える。Knowledge Base に入れるのではなく、Workflow の HTTP Request ノードでリアルタイム取得するのが望ましい。

Workflow 設計の詳細

質問分類ノード（LLM ノード）

ユーザーの入力を受け取り、以下の 4 カテゴリに分類する。

System Prompt:
あなたは製造業設備の問い合わせ分類エンジンです。
ユーザーの質問を以下のカテゴリに分類してください。

1. SPEC - 設備の仕様・原理・構造に関する質問
2. SOP - 標準手順・アラームコード・点検に関する質問
3. CASE - 過去の故障事例・修理履歴に関する質問
4. STATUS - 現在の設備状態・稼働状況に関する質問

カテゴリ名のみを出力してください。複数該当する場合はカンマ区切りで出力。

条件分岐ノード

分類結果に応じて、検索先の Knowledge Base を切り替える。Dify Workflow の IF/ELSE ノード または Question Classifier ノード を利用する。

IF category contains "SPEC" → Knowledge Retrieval(静的知識KB)
IF category contains "SOP"  → Knowledge Retrieval(SOP・アラームKB)
IF category contains "CASE" → Knowledge Retrieval(事例KB)
IF category contains "STATUS" → HTTP Request(MES/SCADA API)

複数カテゴリの場合は並列検索し、結果をマージして回答生成ノードに渡す。

回答生成ノード（LLM ノード）

System Prompt:
あなたは製造業の設備保全エキスパートアシスタントです。
以下のフォーマットで回答してください。

## 初期判断
[症状に対する第一印象]

## 考えられる原因（優先度順）
1. ...
2. ...
3. ...

## 推奨する確認手順
1. ...
2. ...

## 確認すべきログ・センサー・部品
- ...

## エスカレーション判断
[人手による対応が必要かどうかの判断]

注意事項:
- 推測の域を出ない場合は明示すること
- 安全に関わる作業は必ず「有資格者による実施」を注記すること
- 検索結果に該当情報がない場合は「該当情報なし」と明示すること

検索パラメータのチューニング

チューニングの考え方

製造業の故障診断では、「一つのパラメータ設定ですべての質問タイプに対応する」ことは現実的でない。質問カテゴリごとに最適なパラメータが異なるためである。

推奨パラメータ設定

チューニング記録テンプレート

実際のチューニングでは、以下のような記録を残すことを推奨する。

Chunk 設計の実践ポイント

アラームコードドキュメントの Chunk 例

---
alarm_code: E-401
equipment: 油圧ユニット HU-200
severity: WARNING
---

## E-401: 油圧圧力低下

### 症状
油圧系統の圧力が設定値を下回った場合に発報。設備は低速運転を継続するが、加工精度が低下する可能性がある。

### 考えられる原因
1. 油圧ポンプの摩耗
2. リリーフバルブの設定ずれ
3. 油圧ホースからのリーク
4. 作動油の劣化（粘度低下）

### 対処手順
1. 油圧計で実測圧力を確認
2. ポンプ周辺の油漏れを目視確認
3. 作動油のサンプリング検査を実施
4. 異常が認められた場合、ラインを停止し保全チームに連絡

メタデータの付与

Dify の Knowledge Base にドキュメントをアップロードする際、以下のメタデータをファイル名やドキュメント説明に含めると検索精度が向上する。

• 設備 ID / 設備名
• アラームコード（該当する場合）
• 文書カテゴリ（マニュアル / SOP / 事例 / 点検表）
• 最終更新日

オンプレミスデプロイの考慮事項

Docker Compose によるセルフホスト

製造業の工場環境では、インターネット接続が制限されるケースが多い。Dify はセルフホスト版（Docker Compose）を提供しており、閉域網での運用が可能である。

# docker-compose.yml 抜粋（LLM プロバイダ設定例）
services:
  api:
    environment:
      # ローカル LLM を使用する場合（Ollama 等）
      - OLLAMA_API_BASE=http://ollama-server:11434
      # または vLLM を使用する場合
      - OPENAI_API_BASE=http://vllm-server:8000/v1
      - OPENAI_API_KEY=dummy

ローカル LLM の選択肢

閉域網で運用する場合は、Embedding モデルもローカルでホストする必要がある点に注意。

運用フローと継続改善

フィードバックループの設計

flowchart LR
    A[故障発生] --> B[ボットに問い合わせ]
    B --> C[回答を確認]
    C --> D{解決?}
    D -->|Yes| E[解決記録を KB に追加]
    D -->|No| F[保全チームが対応]
    F --> G[対応結果を工単に記録]
    G --> E
    E --> H[ナレッジベース更新]
    H --> I[検索精度が向上]

定期的なメンテナンス項目

導入ステップ

1. Phase 1（2-3 週間）: アラームコード一覧と主要 SOP を Knowledge Base に投入。基本的な Q&A ボットとして稼働開始。
2. Phase 2（1-2 ヶ月）: 過去の修理工単・故障記録を構造化して追加。質問分類ノードを導入し、検索先の自動振り分けを実装。
3. Phase 3（2-3 ヶ月）: MES / SCADA 連携の HTTP Request ノードを追加。リアルタイム状態を踏まえた回答が可能に。
4. Phase 4（継続）: 現場フィードバックを基にナレッジとパラメータを継続改善。

まとめ

製造業の設備故障診断ボットは、単にマニュアルをアップロードして終わりではない。知識の階層化、質問タイプに応じた検索ルーティング、Chunk 設計の最適化、そして運用フェーズでの継続的なナレッジ蓄積――これらを一体として設計することで、初めて現場で使われるツールになる。

Dify の Knowledge Base + Workflow の組み合わせは、この要件に対して十分な柔軟性を提供する。特にセルフホスト版を活用すれば、製造業特有のセキュリティ要件（閉域網・データ外部送信禁止）にも対応可能であり、エンタープライズ導入のハードルを大きく下げることができる。

最も重要なのは、このプロジェクトを「AI 導入プロジェクト」としてではなく、「現場知識の構造化プロジェクト」として位置づけることである。暗黙知をいかに検索可能な資産に変換するか――その設計品質が、ボットの実用性を決定づける。