mybook

ユースケース:製造業 — 予知保全 IoT プラットフォームの構築

油の匂いがする現場へ

「ソウタ、来月から東洋精機のプロジェクトに入ってもらう」

Arclight AI のオフィスで、カイがプロジェクト概要書をテーブルに広げた。自動車部品メーカー「東洋精機」 -- 年間売上 3,000 億円、国内 5 工場に 80 本の生産ライン。計画外ダウンタイムによる損失が年間 40 億円に達し、経営課題として AI 活用を検討しているという。

「EC やSaaS のプロジェクトとはまるで違う世界だ。油の匂いがして、機械の音が鳴り響く。そこにリアルなデータがある」

カイの目は真剣だった。

「製造業の FDE は、現場に立てるかどうかで勝負が決まる。コードが書けるだけじゃ足りない。工場の保全員と同じ目線で設備を見て、同じ音を聴いて、初めてまともなシステムが作れる」

ソウタは EC 業界のプロジェクトには慣れていた。だが製造業は初めてだ。生産ラインの停止が何を意味するのか、まだ実感がない。

「年間 120 時間の計画外ダウンタイムって、具体的にはどういう状態ですか?」

「たとえば深夜 2 時にプレス機のベアリングが焼き付く。生産ラインが止まる。保全員が駆けつけて原因を特定するのに 2 時間、部品の手配に 4 時間、交換作業に 3 時間。その間、後工程のラインも止まる。1 時間あたりの損失は約 3,300 万円だ」

ソウタは息を呑んだ。EC サイトのダウンタイムとは桁が違う。

INFO

製造業における計画外ダウンタイムのコストは、直接的な生産損失だけではない。納期遅延によるペナルティ、緊急部品調達のプレミアムコスト、品質低下リスク、そして顧客(自動車メーカー)からの信頼失墜まで含めると、表面的な数字の 2〜3 倍に膨らむことが多い。


顧客プロフィール -- 東洋精機の現状

ソウタはプロジェクト開始前に、東洋精機の現状を徹底的に整理した。

企業概要

  • 事業内容: 自動車部品製造(エンジン部品、トランスミッション部品、ブレーキ部品)
  • 年間売上: 3,000 億円
  • 工場: 国内 5 拠点(群馬本社工場、栃木工場、静岡工場、三重工場、福岡工場)
  • 生産ライン: 80 本(プレス、切削、研磨、熱処理、組立)
  • 従業員: 約 8,000 名(うち保全チーム 120 名)

保全の現状

現在の保全方式は TBM(Time-Based Maintenance / 時間基準保全) -- 設備の稼働時間に基づいて定期的に部品を交換する。しかし、この方式には根本的な問題があった。

Loading diagram...
  • 計画外ダウンタイム: 年間 120 時間(損失 40 億円)
  • MTBF(平均故障間隔): 2,400 時間(目標 4,000 時間)
  • MTTR(平均修復時間): 9 時間(目標 3 時間)
  • OEE(総合設備効率): 72%(業界トップは 85% 以上)
  • 過剰保全: まだ使える部品を定期交換しており、年間 2 億円の無駄が発生

さらに深刻なのが、ベテラン保全員の退職ラッシュだ。120 名の保全チームのうち、30 年以上の経験を持つベテランが 18 名。そのうち 12 名が今後 3 年以内に定年退職を迎える。彼らの「音で異常を聴き分ける」「振動の微妙な変化を手で感じ取る」といった暗黙知が、組織から失われようとしていた。

WARNING

製造業の保全における暗黙知の消失は、単なる人材不足の問題ではない。ベテランが 30 年かけて蓄積した「この音がしたら 3 日以内にベアリングが壊れる」という経験則は、マニュアルに書けない。AI による異常検知は、この暗黙知をデータで再現する試みでもある。


ディスカバリーフェーズ -- 工場の「音」を聴く

製造業特有のヒアリング

ソウタは東洋精機の群馬本社工場で、最初のヒアリングに臨んだ。会議室には 4 名のキーステークホルダーが揃っている。

  • 田中工場長 -- 生産計画の最終責任者。ダウンタイム削減の KPI を背負っている
  • 鈴木生産技術部長 -- 設備導入・改善の責任者。新技術に対して慎重
  • 佐藤品質保証部長 -- 不良率と品質基準の番人。「品質に影響するなら反対」
  • 山田保全チームリーダー -- 現場のベテラン。勤続 32 年、設備の音で異常を察知する

「まず現状の保全プロセスを教えていただけますか?」

ソウタが切り出すと、山田が口を開いた。

「うちは 3 ヶ月ごとの定期点検と、6 ヶ月ごとの部品交換が基本。でも正直、壊れる前に交換できてるのは半分くらい。残りは突発故障だよ」

「突発故障のとき、原因特定にどれくらいかかりますか?」

「ものによるな。俺が見ればだいたい 30 分でわかる。でも若い連中は 2〜3 時間かかることもある」

鈴木部長が補足した。

「山田の技術は属人的なんです。彼が休みの日に故障が起きると、復旧に倍の時間がかかる。これが最大のリスクです」

ソウタは EC 業界でのヒアリングとの違いを痛感した。Web サービスなら「レスポンスタイムは?」「エラー率は?」と聞けばデータが返ってくる。だが製造業では、最も重要な情報がベテランの頭の中にしかない。

工場見学 -- 机上では見えないもの

ヒアリングの翌日、ソウタは山田に連れられて工場フロアに足を踏み入れた。

最初に感じたのは音だった。プレス機の重低音、切削機の金属音、コンベアのモーター音。それらが混ざり合って、工場全体が一つの巨大な楽器のように鳴っている。

次に匂い。切削油の甘い匂い、金属粉の鉄っぽい匂い、グリスの匂い。EC のオフィスでは嗅いだことのない匂いだ。

「あの 3 番プレス、ちょっと音が高いな」

山田が立ち止まった。ソウタにはどのプレス機の音が違うのか、まったくわからない。

「音が高い?」

「ベアリングが摩耗してくると、回転音の周波数が上がるんだ。あと 2 週間くらいで交換時期だな」

ソウタはメモを取りながら、工場内を歩き回った。そして、いくつかの重要な事実に気づいた。

  1. 壊れた温度計 -- 熱処理炉の温度計が 3 台中 1 台壊れたまま放置されている。「予算がなくて」と現場の作業員が言った
  2. 手書きの点検シート -- 段ボール箱 4 箱分の紙が棚に積まれている。デジタル化されていない過去 10 年分の点検記録
  3. 振動の伝播 -- 大型プレス機の振動が隣のラインに伝わり、切削精度に影響している。現場は「いつものこと」と慣れてしまっている
  4. 暗い通路 -- 設備の裏側は照明が不十分で、センサー設置の作業が困難

「山田さん、この手書きの点検シート、全部デジタル化できますか?」

「やってくれるなら助かるよ。でも、俺たちに入力させるのは無理だぞ。タブレットなんて触ったことないやつばかりだ」

この一言が、後のプロジェクトの方向性を大きく変えることになる。


PoC フェーズ -- IoT × 異常検知の実装

センサーデータ収集パイプライン

ソウタは PoC の対象として、群馬本社工場の第 1 プレスラインを選んだ。10 台のプレス機に振動、温度、電流、圧力の 4 種類のセンサーを取り付け、リアルタイムでデータを収集する。

まず、センサーデータを格納するモデルを設計した。

class SensorReading < ApplicationRecord
  belongs_to :device
  belongs_to :production_line
 
  # device_id:       デバイス識別子
  # sensor_type:     vibration / temperature / current / pressure
  # value:           センサー値(float)
  # recorded_at:     計測タイムスタンプ
  # anomaly_detected: 異常検知フラグ
  # anomaly_score:   異常スコア(0.0〜1.0)
 
  enum :sensor_type, {
    vibration: 0,
    temperature: 1,
    current: 2,
    pressure: 3
  }
 
  scope :anomalies, -> { where(anomaly_detected: true) }
  scope :for_device, ->(device_id) { where(device_id: device_id) }
  scope :recent, -> { where(recorded_at: 24.hours.ago..) }
  scope :by_type, ->(type) { where(sensor_type: type) }
 
  validates :value, presence: true, numericality: true
  validates :sensor_type, presence: true
  validates :recorded_at, presence: true
end
class Device < ApplicationRecord
  belongs_to :production_line
  has_many :sensor_readings, dependent: :destroy
  has_many :maintenance_predictions, dependent: :destroy
  has_many :alerts, dependent: :destroy
 
  # name:             設備名(例: "第1プレス機 PP-001")
  # device_type:      設備種別(press / lathe / grinder / furnace)
  # installed_at:     設置日
  # last_maintained_at: 最終保全日
  # status:           稼働状態(running / warning / stopped / maintenance)
 
  enum :status, {
    running: 0,
    warning: 1,
    stopped: 2,
    maintenance: 3
  }
 
  def hours_since_maintenance
    return 0 unless last_maintained_at
    ((Time.current - last_maintained_at) / 1.hour).round(1)
  end
end

異常検知サービス

次に、センサーデータから異常を検知するサービスを構築した。ベテラン保全員の「音が高い」という感覚を、統計的な Z スコアで再現する。

class AnomalyDetector
  THRESHOLDS = {
    vibration:   { warning: 2.0, critical: 3.5 },
    temperature: { warning: 2.5, critical: 4.0 },
    current:     { warning: 1.8, critical: 3.0 },
    pressure:    { warning: 2.0, critical: 3.5 }
  }.freeze
 
  WINDOW_SIZE = 720 # 直近12時間(1分間隔のデータ)
 
  def initialize(device)
    @device = device
    @baseline = BaselineCalculator.new(device)
  end
 
  def analyze(readings)
    readings.map do |reading|
      z_score = calculate_z_score(reading)
      severity = determine_severity(reading.sensor_type, z_score)
 
      {
        reading_id: reading.id,
        z_score: z_score.round(3),
        severity: severity,
        recommended_action: recommend_action(severity, reading.sensor_type),
        confidence: calculate_confidence(readings.size)
      }
    end
  end
 
  private
 
  def calculate_z_score(reading)
    baseline = @baseline.for_sensor(reading.sensor_type)
    return 0.0 if baseline.std_dev.zero?
 
    (reading.value - baseline.mean) / baseline.std_dev
  end
 
  def determine_severity(sensor_type, z_score)
    thresholds = THRESHOLDS[sensor_type.to_sym]
    abs_score = z_score.abs
 
    if abs_score >= thresholds[:critical]
      :critical
    elsif abs_score >= thresholds[:warning]
      :warning
    else
      :normal
    end
  end
 
  def recommend_action(severity, sensor_type)
    case severity
    when :critical
      "即座に設備停止・点検を実施してください(#{sensor_type}異常)"
    when :warning
      "次回の定期保全時に重点点検を推奨します(#{sensor_type}注意)"
    else
      "異常なし"
    end
  end
 
  def calculate_confidence(sample_size)
    # サンプル数が少ないと信頼度が下がる
    [sample_size.to_f / WINDOW_SIZE, 1.0].min.round(2)
  end
end

保全予測サービス

異常検知の次のステップは、「いつ壊れるか」を予測することだ。過去の劣化パターンから、故障までの残存時間を推定する。

class MaintenancePrediction
  DEGRADATION_PATTERNS = {
    bearing:  { slope: -0.015, failure_threshold: 0.2 },
    belt:     { slope: -0.008, failure_threshold: 0.3 },
    motor:    { slope: -0.012, failure_threshold: 0.25 },
    hydraulic: { slope: -0.010, failure_threshold: 0.15 }
  }.freeze
 
  def predict_failure(device)
    recent_readings = device.sensor_readings
                            .where(recorded_at: 30.days.ago..)
                            .order(:recorded_at)
 
    return no_prediction if recent_readings.size < 100
 
    health_score = calculate_health_score(recent_readings)
    degradation_rate = calculate_degradation_rate(recent_readings)
    component = identify_degrading_component(recent_readings)
 
    pattern = DEGRADATION_PATTERNS[component]
    return no_prediction unless pattern
 
    remaining_life = estimate_remaining_life(
      health_score, degradation_rate, pattern
    )
 
    {
      device_id: device.id,
      estimated_failure_date: remaining_life[:date],
      confidence: remaining_life[:confidence],
      health_score: health_score,
      degrading_component: component,
      recommended_action: determine_action(remaining_life),
      estimated_cost_if_ignored: calculate_failure_cost(device)
    }
  end
 
  private
 
  def calculate_health_score(readings)
    # 複数センサーの加重平均で総合健全性を算出
    scores = readings.group_by(&:sensor_type).map do |type, type_readings|
      detector = AnomalyDetector.new(type_readings.first.device)
      results = detector.analyze(type_readings.last(10))
      normal_ratio = results.count { |r| r[:severity] == :normal }.to_f / results.size
      [type, normal_ratio]
    end.to_h
 
    weights = { "vibration" => 0.4, "temperature" => 0.25,
                "current" => 0.2, "pressure" => 0.15 }
 
    scores.sum { |type, score| score * weights.fetch(type, 0.25) }.round(3)
  end
 
  def determine_action(remaining_life)
    days = remaining_life[:days]
 
    if days <= 3
      "緊急: #{days}日以内に故障の可能性。即座に保全計画を立ててください"
    elsif days <= 14
      "計画保全: #{days}日以内の保全を推奨。部品の事前手配を開始してください"
    elsif days <= 30
      "経過観察: 約#{days}日の残存寿命。次回定期保全で重点点検してください"
    else
      "正常: 当面の保全不要。定期モニタリングを継続してください"
    end
  end
 
  def no_prediction
    { estimated_failure_date: nil, confidence: 0.0,
      recommended_action: "データ不足: 予測に必要なデータが蓄積されていません" }
  end
end

アラート配信

異常を検知したら、適切な相手に適切な方法で通知する。製造現場では、通知の遅れが数千万円の損失につながる。

class AlertDispatcher
  ESCALATION_RULES = {
    normal:    [],
    warning:   [:dashboard, :slack],
    critical:  [:dashboard, :slack, :sms],
    emergency: [:dashboard, :slack, :sms, :line_stop]
  }.freeze
 
  def dispatch(alert)
    channels = ESCALATION_RULES[alert.severity.to_sym] || []
 
    channels.each do |channel|
      send("notify_#{channel}", alert)
    rescue StandardError => e
      Rails.logger.error("[AlertDispatcher] #{channel} 送信失敗: #{e.message}")
      fallback_notify(alert, channel)
    end
 
    schedule_escalation(alert) if alert.critical? || alert.emergency?
  end
 
  private
 
  def notify_dashboard(alert)
    ActionCable.server.broadcast(
      "factory_#{alert.device.production_line.factory_id}",
      { type: "alert", payload: alert.as_json }
    )
  end
 
  def notify_slack(alert)
    SlackNotifier.post(
      channel: "#factory-alerts",
      text: format_alert_message(alert),
      icon_emoji: severity_emoji(alert.severity)
    )
  end
 
  def notify_sms(alert)
    on_call = OnCallSchedule.current_engineer(alert.device.production_line)
    SmsGateway.send(
      to: on_call.phone_number,
      body: "【#{alert.severity.upcase}#{alert.device.name}: #{alert.message}"
    )
  end
 
  def notify_line_stop(alert)
    # PLC にライン停止信号を送信(安全系統経由)
    PlcGateway.send_stop_signal(
      production_line: alert.device.production_line,
      reason: alert.message,
      initiated_by: "ai_predictive_maintenance"
    )
    Rails.logger.warn("[LINE_STOP] #{alert.device.production_line.name} 自動停止")
  end
 
  def schedule_escalation(alert)
    # 30分以内に対応がなければ上位者にエスカレーション
    AlertEscalationJob.set(wait: 30.minutes).perform_later(alert.id)
  end
end

WARNING

製造ラインの自動停止(notify_line_stop)は、人命に関わる判断だ。AI の誤判定でラインを止めれば数千万円の損失になるが、本当に危険な状態を見逃せば人身事故につながる。FDE は「自動停止の閾値をどこに設定するか」について、工場長・保全チーム・安全管理者と徹底的に議論し、段階的に閾値を調整する運用を設計する必要がある。

AWS IoT アーキテクチャ

センサーデータの収集から異常検知、アラート配信までの全体アーキテクチャを AWS 上に構築した。

Loading diagram...
  • IoT Core: MQTT プロトコルでセンサーデータを受信。デバイス認証に X.509 証明書を使用
  • Kinesis Data Streams: 1 秒間隔のセンサーデータをリアルタイムストリーミング
  • Lambda: データの前処理(ノイズ除去、欠損値補完、単位変換)
  • Timestream: 時系列データベースに生データを保存。最大 1 年間のリテンション
  • SageMaker: 異常検知モデルの推論エンドポイント。Random Cut Forest アルゴリズム
  • Rails App: 異常検知結果の集約、アラート配信、ダッシュボード表示

工場環境の特殊性 -- IT の常識が通じない世界

PoC を進める中で、ソウタは製造業特有の壁に次々とぶつかった。Web サービスの世界では当たり前のことが、工場ではまったく通用しない。

ネットワーク制約

「ソウタさん、センサーのデータが 10 分間途切れてます」

運用開始 3 日目にして、最初のトラブルが発生した。原因は単純 -- 工場内の Wi-Fi が不安定だったのだ。

金属製の設備が林立する工場フロアは、電波にとって最悪の環境だ。反射、干渉、遮蔽が至るところで発生する。さらに、大型モーターの起動時には電磁ノイズが発生し、通信が瞬断する。

ソウタは AWS IoT Greengrass を導入し、エッジ側でデータをバッファリングする仕組みを構築した。

class EdgeDataBuffer
  MAX_BUFFER_SIZE = 10_000
  SYNC_INTERVAL = 30.seconds
  CRITICAL_PRIORITY = 0
  NORMAL_PRIORITY = 10
 
  def initialize(device_id)
    @device_id = device_id
    @buffer = PriorityQueue.new
    @network_available = true
  end
 
  def push(reading)
    priority = reading[:anomaly_detected] ? CRITICAL_PRIORITY : NORMAL_PRIORITY
 
    if @buffer.size >= MAX_BUFFER_SIZE
      # バッファ満杯時は正常データを捨ててでも異常データを保持
      drop_lowest_priority if priority < @buffer.peek_lowest_priority
    end
 
    @buffer.push(reading, priority)
    attempt_sync if @network_available
  end
 
  def attempt_sync
    return if @buffer.empty?
 
    batch = @buffer.pop_batch(100)
    CloudSyncClient.send_batch(@device_id, batch)
    @network_available = true
  rescue NetworkError => e
    @network_available = false
    @buffer.push_all(batch) # 送信失敗したデータをバッファに戻す
    schedule_retry
    Rails.logger.warn("[EdgeBuffer] ネットワーク障害: #{e.message}")
  end
 
  def schedule_retry
    # 指数バックオフで再試行(最大5分間隔)
    RetryScheduler.exponential_backoff(
      initial: SYNC_INTERVAL,
      max: 5.minutes,
      callback: method(:attempt_sync)
    )
  end
end

INFO

エッジ処理とクラウド処理の使い分けは、製造業 IoT の最重要設計判断の一つだ。判断基準は 3 つ -- レイテンシ要件(安全に関わる判断は 100ms 以内)、帯域コスト(1 センサーあたり 1 秒間隔で月 2.6GB)、可用性要件(ネットワーク断でもローカルで動き続けるか)。

安全規制と現場の制約

工場にセンサーを設置する作業は、オフィスにサーバーを置くのとはわけが違った。

「ここは危険区域だから、防爆仕様じゃないセンサーは設置できないよ」

山田が指差したのは、有機溶剤を使う洗浄工程のエリアだった。ISO 45001(労働安全衛生マネジメント)に基づく危険区域の分類があり、使用できる電子機器が厳しく制限されている。

ソウタは安全管理者と 3 回のミーティングを重ね、センサーの設置場所を 1 台ずつ承認してもらった。EC サイトのサーバー増設なら 5 分で終わるクラウドコンソールの操作が、工場では 3 週間の承認プロセスになる。

現場の IT リテラシーと抵抗感

もう一つの壁は、現場作業員の反応だった。

「また新しいシステムか。去年も何か入れたけど、結局誰も使ってないぞ」

50 代のベテラン作業員の言葉に、ソウタは胸を刺された。過去に導入されたタブレット点検システムは、入力が面倒で 3 ヶ月で放置されたという。

ソウタはカイに相談した。

「現場の人たちに使ってもらえる気がしません。タブレットのログイン画面で 5 分かかる人もいます」

「だったら、使わせるな」

カイの回答は意外だった。

「最初から全員に使わせようとするな。まず山田さんだけに見せろ。山田さんが『これは使える』と言えば、現場は自然についてくる」

OT/IT 融合の課題

製造現場には PLC(Programmable Logic Controller)と SCADA(Supervisory Control and Data Acquisition)という、IT とは異なるテクノロジースタックが存在する。

Loading diagram...

この階層構造は Purdue Model と呼ばれ、セキュリティの観点から IT ネットワークと OT ネットワークを厳密に分離している。IoT センサーのデータをクラウドに送るには、この壁を安全に越える設計が必要だった。

ソウタは OT ネットワークには一切触れず、独立したセンサーネットワークを構築する方針を選んだ。既存の PLC/SCADA に手を入れると、生産ラインへの影響リスクがあるからだ。

「PLC のデータも取り込めれば精度が上がるんですが...」

「わかるけど、最初から完璧を目指すな。まずセンサーデータだけで価値を証明しろ。PLC 連携は Phase 2 だ」

カイの判断は明快だった。

INFO

OT/IT 融合プロジェクトでは「既存の OT システムに触らない」という制約を最初に受け入れることが重要だ。OT システムの変更は工場全体の稼働に影響し、承認に数ヶ月かかる。独立したセンサーネットワークで素早く価値を証明し、信頼を得てから段階的に統合する戦略が FDE の定石だ。


成果測定 -- 工場が変わる

PoC 開始から 6 ヶ月。群馬本社工場の第 1 プレスラインで、予知保全システムが本格稼働した。

最初の成功体験

稼働 2 週間目の深夜、システムが warning アラートを発報した。

「PP-003 プレス機、振動の Z スコアが 2.3 に上昇。ベアリング劣化の兆候。推定残存寿命: 12 日」

翌朝、山田がプレス機を確認した。

「...確かに、ちょっと音が変わってるな。よく気づいたじゃないか、このシステム」

山田が初めてシステムを認めた瞬間だった。計画的に部品を手配し、週末の定期メンテナンス枠で交換。計画外停止ゼロ。

この一件が転機になった。山田が若手保全員に「このシステムのアラートは信用していい」と言い始めたのだ。

数値で見る成果

6 ヶ月間の運用で、明確な成果が出た。

Loading diagram...
指標BeforeAfter改善率
計画外ダウンタイム120 時間/年18 時間/年85% 削減
MTBF2,400 時間5,200 時間117% 向上
MTTR9 時間2.5 時間72% 短縮
OEE72%88%16pt 向上
予知保全精度--92%偽陽性率 8%
過剰保全コスト2 億円/年0.6 億円/年70% 削減

ROI: 8 ヶ月で投資回収。初期投資(センサー、エッジデバイス、クラウド基盤、開発費)約 1.2 億円に対し、年間削減効果は約 35 億円。

ベテランが最強の味方になった日

最も重要な成果は、数字には表れない部分にあった。

山田は当初、AI に対して懐疑的だった。「機械の声は俺が一番よく知ってる。コンピューターに何がわかる」

しかし、システムが山田でも気づかなかった異常を 2 回検知したことで、態度が変わった。

「俺の耳じゃ拾えない周波数帯の変化を、こいつは捕まえるんだな。俺の経験とこいつのデータを組み合わせれば、もっと精度が上がるはずだ」

山田は自ら「異常パターンのラベリング」に協力し始めた。30 年の経験に基づいて「この振動パターンはベアリングの内輪劣化」「これはベルトの伸び」とアノテーションをつけていく。AI の精度は飛躍的に向上した。

ソウタはこの経験を、カイにこう報告した。

「製造業のプロジェクトで一番大事なことがわかりました。技術の話をする前に、現場のベテランを味方にすること。彼らの暗黙知が AI のラベルデータになるし、彼らが認めたシステムは現場に定着する」

カイは静かにうなずいた。

「それが FDE の仕事だ。コードを書くことじゃない。現場の人間と AI の間に橋を架けることだ」

INFO

製造業 AI プロジェクトの成否を分ける最大の要因は、技術の精度ではなく「現場のベテランが味方になるかどうか」だ。ベテランの暗黙知は最高のラベルデータであり、ベテランの一言は最強の社内マーケティングになる。FDE は技術者である前に、現場の信頼を勝ち取る「通訳者」でなければならない。


演習問題

演習 1: 工場見学チェックリスト

製造業の顧客を初めて訪問する際の工場見学チェックリストを、以下の 5 カテゴリ各 4 項目、計 20 項目で作成せよ。

  • 設備: 設備の種類、稼働状況、メーカー・型式、設置年数
  • 環境: 温度・湿度、騒音レベル、照明、危険区域の分類
  • データ: 既存のセンサー有無、PLC/SCADA の種類、ログの保存状況、ネットワーク環境
  • : 保全チームの人数・年齢構成、シフト体制、IT リテラシー、キーパーソン
  • プロセス: 保全の種類(TBM/CBM)、点検記録の形式、故障時の対応フロー、部品在庫管理

演習 2: 操作マニュアル設計

IT リテラシーが低い工場作業員でも使える操作マニュアルの構成を設計せよ。以下の制約を守ること。

  • 1 ページあたりの手順は最大 3 ステップ
  • すべての手順にスクリーンショットまたは写真を添付
  • 文字サイズは 14pt 以上
  • 専門用語には必ず平易な説明を併記
  • 「困ったときは」セクションを各ページに設置

演習 3: エッジ vs クラウド判断基準

以下の 4 つの処理について、エッジ処理とクラウド処理のどちらが適切か判断し、理由を述べよ。

処理レイテンシ要件データ量セキュリティ
安全停止判定10ms 以内OT ネットワーク内
日次レポート生成数分許容IT ネットワーク
リアルタイム異常スコア算出1 秒以内エッジ→クラウド
月次の劣化トレンド分析数時間許容IT ネットワーク

それぞれについて、レイテンシ、帯域コスト、可用性、セキュリティの 4 軸で評価し、判断根拠をまとめよ。