ユースケース:製造業 — 予知保全 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 / 時間基準保全) -- 設備の稼働時間に基づいて定期的に部品を交換する。しかし、この方式には根本的な問題があった。
- 計画外ダウンタイム: 年間 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 週間くらいで交換時期だな」
ソウタはメモを取りながら、工場内を歩き回った。そして、いくつかの重要な事実に気づいた。
- 壊れた温度計 -- 熱処理炉の温度計が 3 台中 1 台壊れたまま放置されている。「予算がなくて」と現場の作業員が言った
- 手書きの点検シート -- 段ボール箱 4 箱分の紙が棚に積まれている。デジタル化されていない過去 10 年分の点検記録
- 振動の伝播 -- 大型プレス機の振動が隣のラインに伝わり、切削精度に影響している。現場は「いつものこと」と慣れてしまっている
- 暗い通路 -- 設備の裏側は照明が不十分で、センサー設置の作業が困難
「山田さん、この手書きの点検シート、全部デジタル化できますか?」
「やってくれるなら助かるよ。でも、俺たちに入力させるのは無理だぞ。タブレットなんて触ったことないやつばかりだ」
この一言が、後のプロジェクトの方向性を大きく変えることになる。
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
endclass 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
endWARNING
製造ラインの自動停止(notify_line_stop)は、人命に関わる判断だ。AI の誤判定でラインを止めれば数千万円の損失になるが、本当に危険な状態を見逃せば人身事故につながる。FDE は「自動停止の閾値をどこに設定するか」について、工場長・保全チーム・安全管理者と徹底的に議論し、段階的に閾値を調整する運用を設計する必要がある。
AWS IoT アーキテクチャ
センサーデータの収集から異常検知、アラート配信までの全体アーキテクチャを AWS 上に構築した。
- 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
endINFO
エッジ処理とクラウド処理の使い分けは、製造業 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 とは異なるテクノロジースタックが存在する。
この階層構造は 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 ヶ月間の運用で、明確な成果が出た。
| 指標 | Before | After | 改善率 |
|---|---|---|---|
| 計画外ダウンタイム | 120 時間/年 | 18 時間/年 | 85% 削減 |
| MTBF | 2,400 時間 | 5,200 時間 | 117% 向上 |
| MTTR | 9 時間 | 2.5 時間 | 72% 短縮 |
| OEE | 72% | 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 軸で評価し、判断根拠をまとめよ。