AWS IoT本番運用Vol2｜Events×Analytics×TwinMaker×Fleet

§1 なぜ IoT Vol2 か — IoT階層 (Edge/Connect/Event/Analyze/Digital Twin) + IoT二部作開始ナビ

AWS IoT の世界は、単純なデバイス接続にとどまらない。センサーデータがクラウドに届いた後、「何が起きたか」を検知し、「何を意味するか」を分析し、「どう見えるか」を可視化し、「移動体から何を収集するか」を管理する層が必要になる。

Vol1 では IoT Core / Greengrass / SiteWise / Device Defender を用いたデバイス接続・データ収集の基盤を構築した。本 Vol2 では、その上位層として IoT Events / IoT Analytics / IoT TwinMaker / IoT FleetWise の 4 サービスを本番運用パターンで解説する。

IoT 6層アーキテクチャ全景

AWS IoT のサービス群は以下の 6 層に分類できる。

+-------------------------------------------------------+
|  Layer 6: Mobility (モビリティ層)  |
|  IoT FleetWise -- 車両データ収集・Signal catalog  |
+-------------------------------------------------------+
|  Layer 5: Digital Twin (デジタルツイン層)|
|  IoT TwinMaker -- 3D可視化・Entity階層・GenAI統合 |
+-------------------------------------------------------+
|  Layer 4: Analyze (分析層)|
|  IoT Analytics -- Pipeline・Datastore・Notebook分析  |
+-------------------------------------------------------+
|  Layer 3: Event (イベント層)  |
|  IoT Events -- Detector Model・State machine・Actions|
+-------------------------------------------------------+
|  Layer 2: Connect (接続層) Vol1 担当  |
|  IoT Core・Greengrass・SiteWise・Device Defender  |
+-------------------------------------------------------+
|  Layer 1: Edge (エッジ層) Vol1 担当|
|  Greengrass Edge Runtime・ローカル処理・OTA |
+-------------------------------------------------------+

Vol1 は Layer 1-2 を担当した。本 Vol2 は Layer 3-6 を一気に解説する。

Vol1 との差別化と縦深化の関係

Vol1 (デバイス接続層) は「デバイスをつなぐ」基盤を扱った。本 Vol2 (イベント・分析・デジタルツイン・モビリティ層) は「つながったデータを活かす」上位層に特化する。

Vol1 基盤が完成しているチームが Vol2 に進む構成となっている。Vol1 未読者は先に IoT本番運用 Vol1 を読了することを推奨する。

本記事の対象読者

• IoT Core/Greengrass による接続基盤を構築済みの SRE
• Detector Model / State machine による複雑イベント検知を実装したいエンジニア
• 工場・プラントの 3D デジタルツインを TwinMaker で構築したい IoT アーキテクト
• 車両・モビリティ系データパイプラインを FleetWise で設計したいチーム

本記事の 4 大テーマ

本記事は §2-§5 の 4 本柱を主軸に構成する。

1. §2 IoT Events — Detector Model と State machine でデバイス故障パターンをイベント検知
2. §3 IoT Analytics — Channel/Pipeline/Datastore/Notebook でテレメトリデータを分析基盤化
3. §4 IoT TwinMaker — Workspace/Entity/Scene/GenAI Connector で 3D デジタルツイン構築
4. §5 IoT FleetWise — Signal catalog/Vehicle model/Campaign/Edge agent で車両データ収集

Vol2 が解決する 4 つの課題

IoT 本番運用で「Vol1 の基盤を構築したがここで詰まっている」という典型的なケースを整理する。

課題1: 機器故障の複雑なイベント検知

IoT Core のルールエンジンは「温度 > 80℃ なら SNS 送信」のような単一条件アラートに向いている。しかし「5 分間で 3 回連続閾値超過」「Normal → Warning → Critical という状態遷移管理」など、複数メッセージにまたがる状態管理はルールエンジン単独では実装が複雑になる。IoT Events の Detector Model がこの問題を解決する。

課題2: テレメトリデータの分析基盤構築

大量のセンサーデータを S3 に保存したはよいが、データ品質が悪い (欠損値・外れ値)、変換・エンリッチメントが必要、Athena クエリのパフォーマンスが悪い、Notebook 分析したい ―― このような分析基盤の課題に対し、IoT Analytics の Pipeline/Channel/Datastore/Dataset/Notebook が一気に解決する。

課題3: 設備の 3D デジタルツイン可視化

工場・プラントの設備をリアルタイムで 3D 可視化したい。CAD データを活かしつつ、センサーデータをリアルタイムにオーバーレイしたい。GenAI と統合して異常箇所を自然言語で問い合わせたい ―― こういった要件に対し、IoT TwinMaker の Workspace/Entity/Scene/GenAI Connector が対応する。

課題4: 車両・モビリティデータの大規模収集

コネクテッドカー・建機・物流車両の CAN バス信号を効率的に収集したい。全データを送信するとコストが莫大になる。エッジ側でフィルタリングしクラウドへは必要なシグナルのみ送りたい ―― IoT FleetWise の Signal catalog/Campaign/Edge agent がこの課題に対応する。

IoT サービス間のデータフロー

Vol1 の基盤 (IoT Core/Greengrass) と Vol2 の上位層がどのようにデータを連携するか、全体のデータフローを示す。

[デバイス/センサー]
  |
  | MQTT/HTTPS
  v
[IoT Core] ← Greengrass がエッジでブリッジ
  |
  +--[ルールエンジン]--> [IoT Events]: 状態管理・アラート
  |  |
  |  v
  |  [SNS/SQS/Lambda] : 通知・後続処理
  |
  +--[ルールエンジン]--> [IoT Analytics]: データ収集・変換
  |  |
  |[Datastore/S3]
  |  |
  |[SageMaker Notebook]
  |
  +--[SiteWise]--------->[IoT TwinMaker]: 3Dデジタルツイン
  |  |
  |[Scene/GenAI Connector]
  |
[FleetWise Edge Agent]-------->[IoT FleetWise]: 車両データ収集
|
 [Signal catalog/Campaign]
|
 [Timestream/S3]

本記事の読み方

各章は独立して参照できる設計だ。ただし、初回読了時は §2 → §3 → §4 → §5 の順番で読むことを推奨する。

• SRE / 運用エンジニア: §2 (イベント検知) と §6 (詰まり7選) を優先
• データエンジニア: §3 (IoT Analytics) と §7 (アンチパターン演習) を優先
• IoT アーキテクト: §2-§5 を全章通読した上で §8 のクロスリンクナビを参照
• モビリティ/車両担当: §5 (IoT FleetWise) から読み始めて §2-§3 に戻る

次節 §2 では、IoT Events の Detector Model を軸に、フルマネージドなイベント検知・応答パターンを解説する。

§2 IoT Events 本番運用 — Detector Model × State machine × Input × Actions × Multi-detector

IoT Events とは

AWS IoT Events はフルマネージドなイベント検知・応答サービスだ。IoT Core や他のソースから届くセンサーデータストリームを監視し、デバイスの状態遷移 (故障・閾値超過・復旧) を Detector Model として定義することで、複雑なイベント検知ロジックをサーバーレスに実行できる。

独自の状態遷移ロジックを Lambda で実装する場合と比べ、IoT Events は以下の点で優位性を持つ。

• State machine ネイティブ: 状態 (State) と遷移条件 (Condition) を JSON/Terraform で宣言的に定義
• Multi-detector: デバイスごとに独立したインスタンスを自動管理。10,000 台規模でも追加実装不要
• マネージドスケール: デバイス数増加に対してインフラ管理不要
• 組み込みアクション: SNS / SQS / Lambda / IoT Core / DynamoDB / Firehose へのアクションを設定済みコネクタで接続

Detector Model のコア概念

Detector Model は以下の 4 要素で構成される。

Detector Model
+-- State (状態)
|+-- OnEnter Actions  : 状態に入ったとき実行するアクション
|+-- OnInput Events: 状態内でのイベント定義 (条件 + アクション + 遷移先)
|+-- OnExit Actions: 状態を出るとき実行するアクション
+-- Input
|+-- IoT Core ルールエンジン / BatchPutMessage / HTTP API から送信
+-- Key (Multi-detector キー)
|+-- deviceId 等のフィールドでインスタンスを分割
+-- Role ARN
 +-- IoT Events が SNS / Lambda / DynamoDB 等を呼び出す権限

State (状態): 機器の現在の状態を表す。例: Normal / Warning / Critical / Recovery。

Event (イベント): 状態内で評価する条件と、条件が真のときに実行するアクション・遷移先の組み合わせ。

Condition: $input.SensorInput.temperature > 80.0 のような式言語 (IoTEvents expression) で記述。

Variable: Detector Model 内部に保持できる変数。カウンタや累積値の管理に使用する。

State machine 設計パターン

典型的な機器監視の State machine を例示する。

状態遷移図 (工場設備温度監視)

[Normal] ---- temp > 80 ----> [Warning]
  |
[Normal] <---- temp < 75 ------+
 |
 +--- temp > 95 ---> [Critical]
 |
[Recovery] <---- temp < 75 ------------+
 |
 +--- (30秒継続) ---> [Normal]

設計のポイントは「状態数を最小化すること」だ。State machine は直感的だが、状態数が増えると遷移条件が指数的に複雑化する。実務では以下を意識する。

• 状態は 5-7 個以内に抑える
• Condition 式は AND/OR の入れ子を 2 段階以内
• Variable を活用して State 数を削減 (例: エラー回数カウンタで State 分岐を減らす)

Input 設計

IoT Events への入力は 3 経路から選択する。

本番では IoT Core ルールエンジン経由 が最も一般的だ。ルールの SQL で必要なフィールドのみ抽出し、Input スキーマに合わせてシェーピングする。

SELECT
  topic(3) AS deviceId,
  temperature,
  pressure,
  timestamp() AS ts
FROM 'factory/+/sensors/data'

Actions 設計

Detector Model の各 State で設定できる Action は以下の通り。

アクションの 冪等性 は設計上の必須要件だ。IoT Events は at-least-once 保証のため、同一アクションが複数回呼ばれる可能性がある。Lambda 側で DynamoDB 条件付き書き込みを使うなど、冪等性を担保する実装が必要になる。

Multi-detector によるスケーリング

Multi-detector は IoT Events の最大の特徴の一つだ。Detector Model に key (例: deviceId) を設定すると、デバイスごとに独立した Detector インスタンスが自動生成される。

Multi-detector 概念図

DeviceID: sensor-001 --> Detector Instance [sensor-001] (状態: Normal)
DeviceID: sensor-002 --> Detector Instance [sensor-002] (状態: Warning)
DeviceID: sensor-003 --> Detector Instance [sensor-003] (状態: Critical)
 ...
DeviceID: sensor-N--> Detector Instance [sensor-N](状態: Normal)

インスタンスは初回メッセージ到達時に自動作成され、タイムアウトまたは明示的な削除で消滅する。10,000 台規模でも追加のスケーリング設定は不要だ。

課金単位: インスタンスの評価回数 (メッセージ処理数) とインスタンス時間。インスタンス数が増えるほど費用が線形増加する点に注意する。

Terraform による Detector Model 定義

resource "aws_iotevents_input" "sensor_input" {
  name = "SensorTemperatureInput"

  definition {
 attribute {
json_path = "deviceId"
 }
 attribute {
json_path = "temperature"
 }
 attribute {
json_path = "pressure"
 }
  }
}

resource "aws_iotevents_detector_model" "temperature_monitor" {
  name= "TemperatureMonitor"
  role_arn  = aws_iam_role.iotevents_role.arn
  evaluation_method  = "SERIAL"

  definition {
 initial_state_name = "Normal"

 state {
state_name = "Normal"

on_input {
  events {
 event_name = "CountWarning"
 condition  = "$input.SensorTemperatureInput.temperature > 80"
 actions {
set_variable {
  variable_name = "warningCount"
  value= "$variable.warningCount + 1"
}
 }
  }
  transition_events {
 event_name = "WarningTransition"
 condition  = "$input.SensorTemperatureInput.temperature > 80"
 next_state = "Warning"
 actions {
sns {
  target_arn = aws_sns_topic.iot_alerts.arn
  payload {
 content_expression = "'Warning: Device ' + $input.SensorTemperatureInput.deviceId + ' temperature exceeded 80C'"
 type= "STRING"
  }
}
 }
  }
}
 }

 state {
state_name = "Warning"

on_enter {
  events {
 event_name = "LogWarningEntry"
 actions {
dynamo_d_bv2 {
  table_name = aws_dynamodb_table.device_states.name
  payload {
 content_expression = "{'deviceId': $input.SensorTemperatureInput.deviceId, 'state': 'Warning'}"
 type= "JSON"
  }
}
 }
  }
}

on_input {
  transition_events {
 event_name = "RecoverNormal"
 condition  = "$input.SensorTemperatureInput.temperature < 75"
 next_state = "Normal"
 actions {
sns {
  target_arn = aws_sns_topic.iot_alerts.arn
  payload {
 content_expression = "'Recovered: Device ' + $input.SensorTemperatureInput.deviceId"
 type= "STRING"
  }
}
 }
  }

  transition_events {
 event_name = "EscalateCritical"
 condition  = "$input.SensorTemperatureInput.temperature > 95"
 next_state = "Critical"
 actions {
lambda {
  function_arn = aws_lambda_function.emergency_handler.arn
  payload {
 content_expression = "{'deviceId': $input.SensorTemperatureInput.deviceId, 'action': 'EMERGENCY_SHUTDOWN'}"
 type= "JSON"
  }
}
 }
  }
}
 }

 state {
state_name = "Critical"

on_input {
  transition_events {
 event_name = "RecoverFromCritical"
 condition  = "$input.SensorTemperatureInput.temperature < 75"
 next_state = "Normal"
  }
}
 }
  }
}

IoT Core ルールエンジンとの連携設定

resource "aws_iot_topic_rule" "forward_to_events" {
  name  = "ForwardToIoTEvents"
  enabled  = true
  sql= "SELECT topic(3) AS deviceId, temperature, pressure, timestamp() AS ts FROM 'factory/+/sensors/data'"
  sql_version = "2016-03-23"

  iot_events {
 input_name = aws_iotevents_input.sensor_input.name
 role_arn= aws_iam_role.iot_rule_role.arn
 batch_mode = false
 message_id = "$${topic(3)}"
  }
}

message_id に deviceId を指定することで、Multi-detector のキーと一致させ、デバイスごとのインスタンスルーティングを確立する。

CloudWatch 連携によるモニタリング

IoT Events は以下のメトリクスを CloudWatch に自動送信する。

メトリクス名説明
DetectorModels/Errors  Detector Model 評価エラー数
DetectorModels/Messages処理メッセージ数
DetectorModels/ThrottledMessages スロットリング数
Inputs/Messages  Input 受信メッセージ数

推奨アラーム設定:

resource "aws_cloudwatch_metric_alarm" "iotevents_errors" {
  alarm_name = "IoTEvents-DetectorModel-Errors"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 1
  metric_name= "Errors"
  namespace  = "AWS/IoTEvents"
  period  = 60
  statistic  = "Sum"
  threshold  = 0
  alarm_actions = [aws_sns_topic.iot_alerts.arn]

  dimensions = {
 DetectorModelName = aws_iotevents_detector_model.temperature_monitor.name
  }
}

次節 §3 では、収集されたテレメトリデータを分析基盤に取り込む IoT Analytics の Pipeline/Datastore/Notebook パターンを解説する。

§3 IoT Analytics 本番運用 — Pipeline × Channel × Datastore × Dataset × SQL × Notebook分析

AWS IoT Analytics は、IoT デバイスから収集した大量の時系列データを処理・保存・分析するためのフルマネージドサービスだ。IoT Core の Rules Engine から直接メッセージを受信し、Pipeline でデータ変換・エンリッチメントを施した後、Datastore に蓄積する。Dataset の SQL クエリや SageMaker Notebook との連携で、機械学習パイプラインや時系列予測まで完結した分析基盤を構築できる。

§3-1. IoT Analytics アーキテクチャ概要

IoT Analytics のデータフローは Channel → Pipeline → Datastore → Dataset の 4 コンポーネントで構成される。

IoT Core (MQTT)
 │
 ▼
Channel ─────────────────────────────────────── メッセージ取込口
 │  MQTT Rule → IoT Analytics Action
 │  バッチ入力 (BatchPutMessage API) 対応
 │  S3 ソース (過去データ一括インジェスト) 対応
 │
 ▼
Pipeline ────────────────────────────────────── データ変換・エンリッチ
 │  Activities (最大 25 個まで連鎖可能):
 │  ① channelActivity(入力チャネル指定)
 │  ② filterActivity (不要メッセージ除去)
 │  ③ mathActivity(温度単位変換 / 計算フィールド追加)
 │  ④ selectAttributesActivity (必要フィールドのみ抽出)
 │  ⑤ deviceRegistryEnrichActivity (Device Registry メタデータ付与)
 │  ⑥ addAttributesActivity(静的フィールド付加)
 │  ⑦ removeAttributesActivity (不要フィールド削除)
 │  ⑧ lambdaActivity (カスタム変換 / 外部 API 呼出)
 │  ⑨ datastoreActivity (出力先 Datastore 指定)
 │
 ▼
Datastore ───────────────────────────────────── 圧縮・パーティション保存
 │  Service-managed S3 / Customer-managed S3 を選択
 │  ファイル形式: JSON or Parquet
 │  保持期間: unlimited / 日数指定
 │
 ▼
Dataset ─────────────────────────────────────── 分析用データセット生成
 SQL クエリ実行 (Presto 互換)
 Container 実行 (SageMaker ECR イメージ)
 スケジュール実行 / デルタウィンドウ
 SageMaker Notebook から直接アクセス可

この直線型パイプラインが IoT Analytics の核心だ。デバイスからのメッセージを Channel で受け取り、Pipeline で変換・エンリッチし、Datastore に蓄積する。Dataset の SQL で時系列集計・異常値抽出・ML 用特徴量生成が一気に実現する。

§3-2. Channel 設計 — IoT Core/MQTT 連携

Channel は IoT Analytics へのメッセージ取込口だ。IoT Core の Rules Engine に以下の Action を定義することで、MQTT トピックからのメッセージを直接 Channel に流し込む。

{
  "sql": "SELECT * FROM 'factory/+/sensor/temperature'",
  "actions": [
 {
"iotAnalytics": {
  "channelName": "iot_sensor_channel",
  "roleArn": "arn:aws:iam::123456789012:role/IoTAnalyticsRole"
}
 }
  ]
}

バッチ入力と S3 ソース: リアルタイム MQTT 以外に、BatchPutMessage API を使ったバッチ投入や、S3 バケットに蓄積済みの CSV/JSON をソースとする構成も選べる。大量の過去データを一括インジェストする際は BatchPutMessage と S3 ソースを組み合わせるのが効果的だ。

Terraform による Channel 定義:

resource "aws_iotanalytics_channel" "sensor" {
  name = "iot_sensor_channel"

  channel_storage {
 service_managed_s3 {}
  }

  retention_period {
 number_of_days = 90
  }

  tags = {
 Environment = "production"
  }
}

§3-3. Pipeline Activity 設計 — 変換チェーンの構築

Pipeline は複数の Activity を連鎖させてデータを変換する。Activity の順序設計が性能とコストを大きく左右する。filterActivity を最前列に配置して不要メッセージを早期除去することが、後続 Activity の処理コスト削減の基本だ。

実践的な Activity チェーン例: 工場センサーから届く生データに対し、デバイスメタデータ付与・単位変換・不要フィールド削除を行う Pipeline:

resource "aws_iotanalytics_pipeline" "sensor_pipeline" {
  name = "sensor_transform_pipeline"

  pipeline_activities {
 channel {
name= "channelActivity"
channel_name = aws_iotanalytics_channel.sensor.name
next= "filterActivity"
 }
  }

  pipeline_activities {
 filter {
name= "filterActivity"
filter = "temperature > -50 AND temperature < 200"
next= "mathActivity"
 }
  }

  pipeline_activities {
 math {
name= "mathActivity"
attribute = "temperature_celsius"
math= "(temperature - 32) * 5 / 9"
next= "deviceRegistryEnrichActivity"
 }
  }

  pipeline_activities {
 device_registry_enrich {
name = "deviceRegistryEnrichActivity"
attribute  = "device_info"
thing_name = "$${iot:thingName}"
role_arn= aws_iam_role.iot_analytics.arn
next = "selectAttributesActivity"
 }
  }

  pipeline_activities {
 select_attributes {
name = "selectAttributesActivity"
attributes = [
  "device_id",
  "temperature_celsius",
  "humidity",
  "timestamp",
  "device_info"
]
next = "datastoreActivity"
 }
  }

  pipeline_activities {
 datastore {
name  = "datastoreActivity"
datastore_name = aws_iotanalytics_datastore.sensor.name
 }
  }
}

Lambda Activity の使いどころ: 標準 Activity で対応できない複雑な変換 (外部 REST API 呼出し、暗号化処理、独自スコアリング) は lambdaActivity を使う。ただし Lambda Activity はメッセージ 1 件ごとに Lambda を同期呼出しするため、高頻度メッセージ環境ではコストと遅延が急増する。バッチ処理可能な変換は前後の Activity で前処理してから Lambda に渡し、呼出回数を最小化する設計が必須だ。

§3-4. Datastore 設計 — 保存形式とストレージ選定

Datastore は分析の性能とコストを決定するコンポーネントだ。Service-managed S3 と Customer-managed S3 の選択、および JSON/Parquet のファイル形式選択が最も重要な設計判断になる。

Service-managed S3 vs Customer-managed S3:

本番環境では Customer-managed S3 を推奨する。データ保持コストを S3 Intelligent-Tiering や Glacier で最適化でき、Athena からの直接クエリも可能になる。

Terraform による Datastore (Parquet / Customer-managed S3):

resource "aws_iotanalytics_datastore" "sensor" {
  name = "sensor_datastore"

  datastore_storage {
 customer_managed_s3 {
bucket  = aws_s3_bucket.iot_analytics.bucket
key_prefix = "sensor-data/"
role_arn= aws_iam_role.iot_analytics.arn
 }
  }

  file_format_configuration {
 parquet_configuration {
schema_definition {
  columns {
 name = "device_id"
 type = "string"
  }
  columns {
 name = "temperature_celsius"
 type = "double"
  }
  columns {
 name = "humidity"
 type = "double"
  }
  columns {
 name = "timestamp"
 type = "string"
  }
}
 }
  }

  retention_period {
 number_of_days = 365
  }
}

Parquet 形式を選ぶと、列指向ストレージにより Dataset の SQL クエリで必要な列だけをスキャンできるため、大量データ環境でのクエリコストが大幅に低下する。スキーマが安定した本番 IoT データでは Parquet + Customer-managed S3 が標準的な選択だ。

§3-5. Dataset — SQL クエリと Container 実行

Dataset は Datastore のデータに対して SQL クエリを実行し、分析用データセットを生成するコンポーネントだ。スケジュール実行とデルタウィンドウを組み合わせることで、定期的な差分抽出が可能になる。

resource "aws_iotanalytics_dataset" "daily_anomaly" {
  name = "daily_anomaly_dataset"

  actions {
 action_name = "SqlAction"
 query_action {
sql_query = <<-SQL
  SELECT
 device_id,
 AVG(temperature_celsius)  AS avg_temp,
 MAX(temperature_celsius)  AS max_temp,
 MIN(temperature_celsius)  AS min_temp,
 COUNT(*)AS message_count
  FROM sensor_datastore
  WHERE __dt >= current_date - interval '1' day
  GROUP BY device_id
  HAVING MAX(temperature_celsius) > 80
OR MIN(temperature_celsius) < -10
SQL
filter {
  delta_time {
 offset_seconds= -3600
 time_expression  = "from_iso8601_timestamp(timestamp)"
  }
}
 }
  }

  triggers {
 schedule {
expression = "cron(0 6 * * ? *)"
 }
  }

  content_delivery_rules {
 destination {
s3_destination_configuration {
  bucket= aws_s3_bucket.iot_analytics.bucket
  key= "datasets/daily_anomaly/!{iotanalytics:scheduleTime}.json"
  role_arn = aws_iam_role.iot_analytics.arn
}
 }
  }
}

Container Dataset — SageMaker 統合: 機械学習モデルを使った予測・分類を Dataset 生成に組み込む場合は Container Dataset を使う。SageMaker でトレーニング済みのモデルを ECR イメージとして指定し、Dataset 生成時に ML 推論を実行できる。時系列予測 (DeepAR / Prophet) や異常スコアリングをパイプラインに組み込む際に有効だ。

§3-6. Notebook 連携 — SageMaker Jupyter 統合

IoT Analytics は SageMaker Jupyter Notebook と直接統合できる。Notebook から boto3 の iotanalytics クライアントで Dataset のデータを読み込み、時系列分析・異常検知・予測モデル構築をインタラクティブに実施できる。

import boto3
import pandas as pd
import json
import urllib.request

client = boto3.client("iotanalytics", region_name="ap-northeast-1")

response = client.get_dataset_content(
 datasetName="daily_anomaly_dataset"
)

# Dataset content は S3 presigned URL で提供される
url = response["entries"][0]["dataURI"]
with urllib.request.urlopen(url) as f:
 data = [json.loads(line) for line in f.readlines()]

df = pd.DataFrame(data)
print(df.describe())

時系列分析の代表的なパターンは以下の 3 通りだ。

① トレンド分析:
デバイスごとの温度移動平均 (window=24h) を計算し、
基準値からの乖離 (> 2σ) を異常候補としてフラグ付け

② 季節性分解:
statsmodels の seasonal_decompose で
日次・週次サイクルを分離し、残差成分で異常検知

③ 予測モデル構築:
Prophet / DeepAR で時系列予測を実行し、
実測値が予測範囲を外れた時点をアラート対象に設定

SageMaker Autopilot と Container Dataset を組み合わせると、特徴量エンジニアリングから ML モデル構築・推論まで IoT Analytics パイプライン内で完結できる。

§3-7. コスト設計

IoT Analytics はメッセージ処理量とストレージ量で課金される。

主要課金モデル (ap-northeast-1 目安):
– Channel 取込: 約 $0.08 / GB (最初の 10 GB/月は無料枠あり)
– Pipeline 処理: 約 $0.05 / GB
– Datastore 保存: Customer-managed S3 の場合は S3 コストのみ
– Dataset SQL クエリ: スキャン量ベースで課金 (Parquet で最大 90% 削減可)

Reserved capacity は月間 1 TB 以上の処理を継続的に行う場合に有効で、最大 70% のコスト削減効果がある。Parquet 形式 + Customer-managed S3 + S3 Intelligent-Tiering を組み合わせると、大規模環境での総保有コストを大幅に圧縮できる。

IoT Analytics でデータを蓄積・分析する仕組みが整ったら、次はデジタルツインの中核となる IoT TwinMaker でリアルタイム 3D 可視化と GenAI 連携を実装する。

§4 IoT TwinMaker 本番運用 — Workspace × Entity × Component × Scene × GenAI Connector

AWS IoT TwinMaker は、物理的な施設・機器・プロセスのデジタルツインをクラウド上で構築するフルマネージドサービスだ。工場の製造ライン、ビルのインフラ設備、データセンターのサーバーラックなど、現実世界の「状態」をリアルタイムにモデル化し、3D Viewer での可視化・異常検知・運用意思決定を支援する。IoT SiteWise や Timestream に蓄積されたリアルタイムデータと 3D モデルを紐付けることで、「グラフで異常を検知し、3D ビューで対象機器を瞬時に特定する」オペレーション体験が実現できる。

§4-1. IoT TwinMaker アーキテクチャ概要

IoT TwinMaker の論理構造は Workspace → Entity → Component → Scene の 4 層で構成される。

Workspace ────────────────────────────────────── 最上位リソースグループ
 │  リージョン×アカウント単位で分離
 │  S3 バケット (3D モデル / メタデータ保存先)
 │  IAM ロール (データソースへのアクセス権)
 │
 ├── Entity ──────────────────────────────── 現実世界のオブジェクト表現
 ││  例: FactoryLine_A / Machine_001 / Sensor_T01
 ││  階層構造: Factory → Line → Machine → Sensor
 ││  親子関係で物理的な包含関係をモデル化
 ││
 │└── Component ────────────────────────── データソース接続定義
 │ │  ComponentType: データスキーマ定義 (再利用可能な型)
 │ │  データソースコネクタ:
 │ │ IoT SiteWise (リアルタイム Asset Property)
 │ │ Timestream(カスタム時系列データ)
 │ │ S3  (静的メタデータ / 設計図)
 │ │ Lambda (カスタムデータソース)
 │ └── プロパティ値がリアルタイムで参照される
 │
 └── Scene ────────────────────────────────── 3D ビジュアライゼーション
  │  GLTF モデルファイル (S3 に保存)
  │  Tag/Cesium (Entity を 3D シーンにオーバーレイ)
  │  OverlayWidget (温度 / 圧力 / 状態ゲージ)
  └── GenAI Connector (Bedrock Claude 連携)

§4-2. Workspace 設定

Workspace は IoT TwinMaker の最上位リソースグループだ。Workspace ごとに S3 バケットと IAM ロールを設定する。IAM ロールにはデータソース (SiteWise / Timestream) へのアクセス権を付与する。

resource "aws_s3_bucket" "twinmaker" {
  bucket = "iot-twinmaker-workspace-prod"
}

resource "aws_iottwinmaker_workspace" "factory" {
  workspace_id = "factory-digital-twin"
  s3_location  = aws_s3_bucket.twinmaker.arn
  role= aws_iam_role.twinmaker_workspace.arn
  description  = "工場ラインデジタルツイン"

  tags = {
 Environment = "production"
  }
}

resource "aws_iam_role" "twinmaker_workspace" {
  name = "iottwinmaker-workspace-role"

  assume_role_policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = { Service = "iottwinmaker.amazonaws.com" }
 }]
  })
}

resource "aws_iam_role_policy" "twinmaker_workspace" {
  name = "iottwinmaker-workspace-policy"
  role = aws_iam_role.twinmaker_workspace.id

  policy = jsonencode({
 Version = "2012-10-17"
 Statement = [
{
  Effect = "Allow"
  Action = [
 "s3:GetObject", "s3:PutObject",
 "s3:DeleteObject", "s3:ListBucket"
  ]
  Resource = [
 aws_s3_bucket.twinmaker.arn,
 "${aws_s3_bucket.twinmaker.arn}/*"
  ]
},
{
  Effect = "Allow"
  Action = [
 "iotsitewise:GetPropertyValue",
 "iotsitewise:GetPropertyValueHistory",
 "iotsitewise:GetAssetPropertyValue"
  ]
  Resource = "*"
},
{
  Effect = "Allow"
  Action = [
 "timestream:Select",
 "timestream:DescribeTable",
 "timestream:ListMeasures"
  ]
  Resource = "*"
}
 ]
  })
}

§4-3. Entity / Component 階層設計 — デジタルツインモデリング

Entity は物理オブジェクトのクラウド表現だ。Component は Entity に付属するデータソース接続定義を持ち、IoT SiteWise・Timestream・S3・Lambda のいずれかからリアルタイムデータを取得する。ComponentType でスキーマを先に定義し、各 Entity の Component で再利用するのが設計の基本だ。

ComponentType 定義:

resource "aws_iottwinmaker_component_type" "temperature_sensor" {
  workspace_id= aws_iottwinmaker_workspace.factory.workspace_id
  component_type_id = "TemperatureSensor"
  description = "温度センサーコンポーネント型"

  property_definitions {
 property_name = "temperature"
 data_type {
type = "DOUBLE"
 }
 is_time_series = true
  }

  property_definitions {
 property_name = "sensorId"
 data_type {
type = "STRING"
 }
 is_required_in_entity = true
  }

  functions {
 function_name = "dataReader"
 implemented_by {
lambda {
  arn = aws_lambda_function.twinmaker_data_reader.arn
}
 }
  }
}

Entity 階層定義 (Factory → Line → Machine):

resource "aws_iottwinmaker_entity" "factory_a" {
  workspace_id = aws_iottwinmaker_workspace.factory.workspace_id
  entity_id = "FactoryLine-A"
  entity_name  = "製造ライン A"
  description  = "第1工場 製造ラインA"
}

resource "aws_iottwinmaker_entity" "machine_001" {
  workspace_id  = aws_iottwinmaker_workspace.factory.workspace_id
  entity_id  = "Machine-001"
  entity_name= "プレス機 001"
  parent_entity_id = aws_iottwinmaker_entity.factory_a.entity_id

  components {
 component_name = "TemperatureSensor"
 component_type_id = aws_iottwinmaker_component_type.temperature_sensor.component_type_id

 properties {
property_name = "sensorId"
value {
  string_value = "sensor-T001"
}
 }
  }
}

データソースコネクタとして IoT SiteWise を使う場合、ComponentType の functions.dataReader に AWS マネージドコネクタ com.amazon.iotsitewise.connector を指定すると、SiteWise Asset Property との直接バインドが可能だ。Lambda 実装を書かずに SiteWise のリアルタイム値を Entity プロパティとして参照できるため、SiteWise 既存ユーザーにとって最も省力な構成になる。

§4-4. Scene 設計 — 3D Viewer × GLTF × OverlayWidget

Scene は 3D ビジュアライゼーションの定義だ。GLTF 形式の 3D モデルファイルを S3 にアップロードし、Scene 定義で Entity との紐付けと OverlayWidget を設定する。Scene 定義は JSON 形式で S3 に保存する。

{
  "version": "1.0",
  "unit": "meters",
  "nodes": [
 {
"id": "factory-node",
"name": "製造ライン A",
"transform": {
  "position": [0, 0, 0],
  "rotation": [0, 0, 0],
  "scale": [1, 1, 1]
},
"components": [
  {
 "type": "ModelRef",
 "uri": "s3://iot-twinmaker-workspace-prod/models/factory_line_a.gltf",
 "modelType": "GLTF"
  },
  {
 "type": "Tag",
 "valueDataBinding": {
"dataBindingContext": {
  "entityId": "Machine-001",
  "componentName": "TemperatureSensor",
  "propertyName": "temperature"
}
 }
  }
]
 }
  ],
  "rootNodeIndexes": [0]
}

OverlayWidget: 温度・圧力・回転数などのリアルタイム値を 3D モデル上にゲージ表示できる。警告閾値を超えると Widget の色が赤に変わる設定が可能で、オペレーターが 3D ビューを見るだけで設備状態を把握できるインターフェースになる。

§4-5. GenAI Connector — TwinMaker × Bedrock 連携

AWS IoT TwinMaker の GenAI Connector は Bedrock の Claude モデルとデジタルツインを統合し、自然言語でのデータ問い合わせと異常検知支援を実現する機能だ。

自然言語クエリの仕組み:

① オペレーター: 「昨日から機械 001 の温度が高い原因は何か」と自然言語で入力
② GenAI Connector が TwinMaker の Entity/Component スキーマを Claude に渡す
③ Claude が適切な時系列クエリを生成し、
Timestream / SiteWise からデータを取得
④ Claude が取得データを解析し、
根本原因候補を自然言語でオペレーターに回答

IAM 権限設定 — Bedrock InvokeModel 追加:

resource "aws_iam_role_policy" "twinmaker_bedrock" {
  name = "twinmaker-bedrock-policy"
  role = aws_iam_role.twinmaker_workspace.id

  policy = jsonencode({
 Version = "2012-10-17"
 Statement = [
{
  Effect = "Allow"
  Action = [
 "bedrock:InvokeModel",
 "bedrock:InvokeModelWithResponseStream"
  ]
  Resource = "arn:aws:bedrock:ap-northeast-1::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0"
}
 ]
  })
}

異常検知支援として、Dataset で生成した日次異常レポートを Claude に渡し「通常範囲から逸脱しているセンサーと考えられる原因」を自然言語レポートとして出力するパターンが実用的だ。Lambda でレポートを定期実行し、結果を SNS 経由で担当者にメール通知する構成が本番でよく使われる。

§4-6. Grafana 連携 — IoT TwinMaker Grafana Plugin

IoT TwinMaker Grafana Plugin を使うと、Grafana ダッシュボードに TwinMaker の 3D Scene を埋め込み、時系列グラフと 3D ビューを同一画面に表示できる。

Grafana データソース設定:

{
  "name": "IoT TwinMaker",
  "type": "grafana-iot-twinmaker-datasource",
  "jsonData": {
 "workspaceId": "factory-digital-twin",
 "assumeRoleArn": "arn:aws:iam::123456789012:role/grafana-twinmaker-role",
 "defaultRegion": "ap-northeast-1"
  }
}

Grafana パネルで entityId・componentName・propertyName を指定すると、Entity のリアルタイムプロパティをグラフ表示できる。3D Scene Panel と時系列グラフパネルを組み合わせると、「グラフで異常を検知 → 3D ビューで対象機器を特定 → GenAI Connector で原因分析」という一気通貫のオペレーションダッシュボードが完成する。

§4-7. コスト設計

IoT TwinMaker は Workspace 数・Entity 数・Scene 閲覧時間で課金される。

主要課金モデル (ap-northeast-1 目安):
– Workspace: 約 $10.00 / 月 (Workspace 単位で固定費発生)
– Entity: 約 $0.01 / Entity / 月 (最初の 10 Entity は無料枠あり)
– Scene 閲覧: セッション時間ベースで課金 (分単位)
– データソースクエリ: 各データソース (SiteWise/Timestream) の課金に加算

本番運用では Entity の粒度設計がコストを左右する。センサー 1 つを 1 Entity にすると 1,000 センサー規模で月額 $10 の Entity 費用になるが、設備 (Machine) を Entity とし各センサーを Component にまとめると Entity 数を大幅に削減できる。物理的な機器単位を Entity 粒度の基本とし、センサーは Component として集約するアーキテクチャが最もコスト効率が高い。

IoT Analytics でデータを蓄積・分析し、IoT TwinMaker で 3D デジタルツインとして可視化する基盤が整った。次の §5 では、コネクテッドビークル向けのデータ収集基盤 IoT FleetWise の本番設計を解説する。

§5 IoT FleetWise 本番運用 — Vehicle model × Signal catalog × Campaign × Edge agent ★山場2

AWS IoT FleetWise は、車両・産業機械の OBD-II / CAN bus データを大規模にクラウド収集するフルマネージドサービスだ。
車両側に Edge Agent を組み込み、Signal Catalog で定義した信号を Campaign で選択収集し、S3 / Timestream に送信する。
従来の自前テレマティクス基盤では、CAN バスデコーダー実装・接続断時バッファ管理・スケール対応が個別開発となり運用コストが高騰していた。
FleetWise はこれらをマネージドレイヤーで吸収し、「何の信号をどの条件で収集するか」というビジネスロジックに集中できる設計思想を持つ。

主要ユースケース:
– 自動車メーカー: OBD-II 診断データ (エンジン温度・RPM・燃費) の大規模フリート収集
– 建設・農業機械: CAN bus センサーデータ (油圧・負荷・位置) の予兆保全分析
– 商用トラック: 走行距離・ブレーキ圧・タイヤ空気圧の遠隔モニタリング
– EV フリート: バッテリー SOC・充電ステータス・熱管理データのリアルタイム収集

IoT FleetWise 公式ドキュメント

5-1. Signal Catalog 設計 — 信号定義の組織標準化

Signal Catalog は FleetWise の中核となる信号ライブラリだ。OBD-II / CAN / アクチュエーター信号を一元定義し、
Vehicle Model や Campaign から参照される。VSS (Vehicle Signal Specification) 準拠の階層構造で管理する。

信号タイプ:

VSS 準拠の階層構造例:

Vehicle
├── Speed # 車速 (km/h)
├── Powertrain
│├── Engine
││├── Speed  # エンジン RPM
││├── Coolant.Temperature# 冷却水温度 (°C)
││└── Oil.Temperature # エンジンオイル温度 (°C)
│└── FuelSystem
│ └── SupplyPressure  # 燃料供給圧力 (kPa)
├── Chassis
│├── Brake.PedalPosition # ブレーキペダル踏み込み量 (%)
│└── Axle.Row1.Wheel.Tire.Pressure  # タイヤ空気圧 (kPa)
└── Body.Lights.Beam.Low.IsActive # ロービーム ON/OFF

Terraform: Signal Catalog 作成:

resource "aws_iotfleetwise_signal_catalog" "fleet" {
  name  = "vehicle-signal-catalog"
  description = "OBD-II / CAN bus 信号カタログ"

  node {
 branch {
fully_qualified_name = "Vehicle"
description = "車両ルートノード"
 }
  }
  node {
 branch {
fully_qualified_name = "Vehicle.Powertrain.Engine"
 }
  }
  node {
 sensor {
fully_qualified_name = "Vehicle.Speed"
description = "車速"
unit  = "km/h"
data_type= "DOUBLE"
min= 0.0
max= 300.0
 }
  }
  node {
 sensor {
fully_qualified_name = "Vehicle.Powertrain.Engine.Speed"
description = "エンジン回転数"
unit  = "rpm"
data_type= "DOUBLE"
min= 0.0
max= 8000.0
 }
  }
  node {
 sensor {
fully_qualified_name = "Vehicle.Powertrain.Engine.Coolant.Temperature"
description = "冷却水温度"
unit  = "celsius"
data_type= "DOUBLE"
min= -40.0
max= 130.0
 }
  }
}

Signal Catalog の設計原則: OBD-II PID コードと VSS 名称のマッピングは社内標準ドキュメントで管理し、
チーム横断で統一する。信号定義は後から変更しにくいため、初期設計に時間をかけることが長期運用コスト削減に直結する。

5-2. Vehicle Model — 車両モデル定義とネットワークインターフェース

Vehicle Model は Signal Catalog のサブセットを使用する車両テンプレートだ。
ネットワークインターフェース (CAN bus / OBD-II) と信号デコード方式を定義する。

ネットワークインターフェース種別:

Terraform: Vehicle Model 定義 (OBD-II デコーダー付き):

resource "aws_iotfleetwise_vehicle_model" "standard_vehicle" {
  name= "standard-vehicle-model"
  description  = "標準乗用車モデル (OBD-II)"
  signal_catalog_arn = aws_iotfleetwise_signal_catalog.fleet.arn

  model_manifest_actions = ["ACTIVE"]

  network_interfaces {
 interface_id = "obd-interface-1"
 type= "OBD_INTERFACE"
 obd_interface {
name= "obd-main"
request_message_id = 2015
 }
  }

  signal_decoders {
 fully_qualified_name = "Vehicle.Speed"
 type  = "OBD_SIGNAL"
 interface_id= "obd-interface-1"
 obd_signal {
pid_response_length = 2
service_mode  = 1
pid  = 13
scaling = 1.0
offset  = 0.0
start_byte = 0
byte_length= 1
bit_mask_length  = 8
bit_right_shift  = 0
 }
  }

  signal_decoders {
 fully_qualified_name = "Vehicle.Powertrain.Engine.Speed"
 type  = "OBD_SIGNAL"
 interface_id= "obd-interface-1"
 obd_signal {
pid_response_length = 2
service_mode  = 1
pid  = 12
scaling = 0.25
offset  = 0.0
start_byte = 0
byte_length= 2
bit_mask_length  = 16
bit_right_shift  = 0
 }
  }

  signal_decoders {
 fully_qualified_name = "Vehicle.Powertrain.Engine.Coolant.Temperature"
 type  = "OBD_SIGNAL"
 interface_id= "obd-interface-1"
 obd_signal {
pid_response_length = 2
service_mode  = 1
pid  = 5
scaling = 1.0
offset  = -40.0
start_byte = 0
byte_length= 1
bit_mask_length  = 8
bit_right_shift  = 0
 }
  }
}

Vehicle Model のバージョン管理戦略: 信号デコーダーの変更は Vehicle Model の新バージョン作成が必要だ。
既存 Campaign への影響を最小化するため、旧バージョンと並行稼働させるブルー/グリーン移行を採用する。

5-3. Campaign 設計 — データ収集ジョブと収集モード選択

Campaign はいつ・どの信号を・どこに送るかを定義するデータ収集ジョブだ。
TIME_BASED (一定間隔収集) と TRIGGER_BASED (条件トリガー) の 2 モードがある。

収集モード比較:

Terraform: Campaign 定義 (TRIGGER_BASED — 冷却水温度異常検知):

resource "aws_iotfleetwise_campaign" "engine_anomaly" {
  name= "engine-anomaly-detection"
  description  = "冷却水温度 100°C 超過時のエンジン異常収集"
  signal_catalog_arn = aws_iotfleetwise_signal_catalog.fleet.arn
  target_arn= aws_iotfleetwise_fleet.main.arn
  collection_scheme  = "TRIGGER_BASED"

  trigger_config {
 condition_based_collection_scheme {
condition_expression = "$variable.`Vehicle.Powertrain.Engine.Coolant.Temperature` > 100.0"
trigger_mode= "RISING_EDGE"
condition_language_version = 1
 }
  }

  signals_to_collect {
 name = "Vehicle.Speed"
 minimum_sampling_interval_ms = 500
  }
  signals_to_collect {
 name = "Vehicle.Powertrain.Engine.Coolant.Temperature"
 minimum_sampling_interval_ms = 250
  }

  data_destination_configs {
 timestream_config {
timestream_table_arn = aws_timestreamwrite_table.vehicle_data.arn
execution_role_arn= aws_iam_role.fleetwise_timestream.arn
 }
  }

  post_trigger_collection_duration = 30000

  approval_status = "APPROVE"
}

Terraform: Campaign 定義 (TIME_BASED — 通常走行ログ / S3 送信):

resource "aws_iotfleetwise_campaign" "normal_driving_log" {
  name= "normal-driving-log"
  collection_scheme  = "TIME_BASED"
  signal_catalog_arn = aws_iotfleetwise_signal_catalog.fleet.arn
  target_arn= aws_iotfleetwise_fleet.main.arn

  time_based_collection_scheme {
 period_ms = 30000
  }

  signals_to_collect {
 name = "Vehicle.Speed"
 minimum_sampling_interval_ms = 1000
  }

  data_destination_configs {
 s3_config {
bucket_arn  = aws_s3_bucket.vehicle_data.arn
prefix= "driving-logs/"
data_format = "JSON"
storage_compression_format = "GZIP"
 }
  }

  approval_status = "APPROVE"
}

Campaign 設計の要点: minimum_sampling_interval_ms で Edge Agent の過剰サンプリングを防ぐ。
S3 行き (長期保存・Athena 分析) と Timestream 行き (リアルタイム分析) を用途別に Campaign 分割するのが
運用ベストプラクティスだ。承認 (APPROVE) 後はフリート全車両へ Over-The-Air で自動配信される。

5-4. Edge Agent — 車両組み込みと接続断時動作

AWS IoT FleetWise Edge Agent はオープンソース (Apache 2.0) の C++ 実装だ。
Raspberry Pi / NXP i.MX / Renesas R-Car など Linux ベースの車載 ECU にビルドして組み込む。

Edge Agent 主要機能:

接続断時のデータフロー:

[通常時]
Edge Agent → IoT Core (mTLS) → Campaign 定義に従いリアルタイム送信

[接続断時]
Edge Agent → SQLite ローカルバッファ (persistencyPartitionMaxSize 上限まで蓄積)
 ↓ 再接続成功
Edge Agent → IoT Core → バッファ分を FIFO 順に送信
 ↓ バッファ上限超過
Edge Agent → 古いデータから自動破棄 (Eviction policy: OLDEST_FIRST)

Edge Agent 主要設定 (config.json の staticConfig 抜粋):

{
  "staticConfig": {
 "bufferSizes": {
"encodedSignalBufferSize": 10000,
"rawCANFrameBufferSize": 10000
 },
 "persistency": {
"persistencyPath": "/var/aws-iot-fleetwise/",
"persistencyPartitionMaxSize": 524288000
 },
 "mqttConnection": {
"endpointUrl": "YOUR_ENDPOINT.iot.ap-northeast-1.amazonaws.com",
"clientId": "${VIN}",
"collectionSchemeListTopic": "$aws/iotfleetwise/vehicles/${VIN}/collection_schemes",
"decoderManifestTopic": "$aws/iotfleetwise/vehicles/${VIN}/decoder_manifests",
"canDataTopic": "$aws/iotfleetwise/vehicles/${VIN}/signals",
"certificate": "/etc/aws-credentials/certificate.pem.crt",
"privateKey": "/etc/aws-credentials/private.pem.key",
"rootCA": "/etc/aws-credentials/AmazonRootCA1.pem"
 }
  }
}

接続断対応の設計指針:
– persistencyPartitionMaxSize: 典型的な接続断時間 × 想定データ量で算出 (例: トンネル 5 分 × 1 MB/分 = 最低 5 MB)
– バッファ上限は車載ストレージ容量の 20% 以内に収める
– VIN を ClientId に使用し、車両ごとの接続を一意に識別する
– 再接続後のバースト送信レートは IoT Core のスロットリング設定で制御する

5-5. Timestream 連携 + Grafana リアルタイム分析

IoT FleetWise → Amazon Timestream の連携で、車両データを時系列データベースに格納しリアルタイム分析できる。

Terraform: Timestream テーブルと IAM ロール:

resource "aws_timestreamwrite_database" "vehicle_db" {
  database_name = "vehicle-telemetry"
}

resource "aws_timestreamwrite_table" "vehicle_data" {
  database_name = aws_timestreamwrite_database.vehicle_db.database_name
  table_name = "vehicle-signals"

  retention_properties {
 memory_store_retention_period_in_hours  = 24
 magnetic_store_retention_period_in_days = 365
  }
}

resource "aws_iam_role" "fleetwise_timestream" {
  name = "fleetwise-timestream-role"
  assume_role_policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
Effect = "Allow"
Principal = { Service = "iotfleetwise.amazonaws.com" }
Action = "sts:AssumeRole"
 }]
  })
}

resource "aws_iam_role_policy" "fleetwise_timestream" {
  role = aws_iam_role.fleetwise_timestream.id
  policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
Effect= "Allow"
Action= ["timestream:WriteRecords", "timestream:DescribeEndpoints"]
Resource = aws_timestreamwrite_table.vehicle_data.arn
 }]
  })
}

Timestream クエリ例 (Grafana パネル向け):

SELECT
  time,
  measure_value::double AS coolant_temp_celsius
FROM "vehicle-telemetry"."vehicle-signals"
WHERE
  measure_name = 'Vehicle.Powertrain.Engine.Coolant.Temperature'
  AND vehicleId = 'VIN-001'
  AND time > ago(1h)
ORDER BY time ASC

Grafana Amazon Timestream プラグインでこのクエリをパネル化し、フリート全体のヒートマップを構築できる。
リアルタイム監視はメモリストア、バッチ集計は S3 Athena から参照する 2 層クエリアーキテクチャが最適解だ。

5-6. コスト設計 — Vehicle 登録費 × Campaign データ量 × Timestream 書き込み

FleetWise の主要課金項目:

コスト試算例 (1,000 台フリート / 1 ヶ月):

Vehicle 登録: 1,000 台 × $1.00 = $1,000
TIME_BASED (30 秒間隔 / 5 信号):
  1.2 MB/台/時 × 720 時間 × 1,000 台= 864 GB → $216,000
TRIGGER_BASED (発火率 10% に絞った場合):
  864 GB × 0.10 =  86 GB →  $21,600

→ TRIGGER_BASED 移行でデータ収集コスト 90% 削減が可能

TIME_BASED の全データ収集は開発・検証フェーズのデバッグ用途に限定し、
本番フリートは TRIGGER_BASED Campaign を基本とするコスト設計を徹底する。

§5 で習得した FleetWise 4 本柱 (Signal Catalog / Vehicle Model / Campaign / Edge Agent) は車両データ収集の設計土台となる。
次の §6 では FleetWise を含む IoT 4 サービス横断で、現場で頻発する詰まりポイント 7 選を図解する。

§6 詰まりポイント7選 図解 (Mermaid01 判断ツリー)

IoT Vol2 の4サービス (Events/Analytics/TwinMaker/FleetWise) を本番運用する際に頻出する詰まりポイントを7パターンに体系化した。各パターンは「症状 → 原因 → 解決策」の構造で示す。まず全7パターンを一枚の判断ツリーで俯瞰する。

flowchart TD
  A[IoT Vol2 問題発生] --> B{IoT Events Detector Model?}
  B -->|Yes| C[State machine最小化+Multi-detector確認]
  B -->|No| D{IoT Analytics Pipeline?}
  D -->|Yes| E[Activity数/Lambda変換コスト確認]
  D -->|No| F{TwinMaker Scene?}
  F -->|Yes| G[3Dモデルサイズ最適化確認]
  F -->|No| H{FleetWise Campaign?}
  H -->|Yes| I[Trigger-based収集+Signal絞り込み確認]
  H -->|No| J{コスト超過?}
  J -->|Yes| K[Reserved capacity/Edge同期頻度確認]
  J -->|No| L{データ品質問題?}
  L -->|Yes| M[Pipeline欠損値/外れ値処理確認]
  L -->|No| N[Edge agent接続断バッファ動作確認]

詰まり1: Detector Model 複雑化罠 — State machine 肥大化と Multi-detector スケーリング設計

症状: Detector Model の State 数が 20 を超えたあたりから、状態遷移の可読性が急激に低下しデバッグに時間がかかる。さらに同一モデルで 1,000 台以上のデバイスを管理しようとしたとき、単一 Detector では処理が詰まり始める。

原因: Detector Model はアラーム・正常・警告など論理上は単純な状態を無計画に追加していくと State 数が線形増加する。IoT Events は 1 Detector Model インスタンスが 1 論理エンティティ (デバイス1台分) に対応するため、物理デバイス数 = Detector インスタンス数となり課金も線形増加する。

解決策: State machine を「正常 / 警告 / 異常」の 3 状態以内に収め、複雑な条件分岐は Lambda Actions でオフロードする。複数デバイスをまとめて管理したい場合は key フィールドで Multi-detector を構成し、デバイスごとに独立したインスタンスを自動生成させる。

{
  "detectorModelDefinition": {
 "states": [
{
  "stateName": "Normal",
  "onInput": {
 "transitionEvents": [
{"eventName":"toWarning","condition":"$input.sensor.temp > 70","actions":[],"nextState":"Warning"}
 ]
  }
},
{
  "stateName": "Warning",
  "onInput": {
 "transitionEvents": [
{"eventName":"toAlarm","condition":"$input.sensor.temp > 90","actions":[{"sns":{"targetArn":"arn:aws:sns:ap-northeast-1:123456789012:iot-alerts"}}],"nextState":"Alarm"},
{"eventName":"toNormal","condition":"$input.sensor.temp < 60","actions":[],"nextState":"Normal"}
 ]
  }
},
{
  "stateName": "Alarm",
  "onInput": {
 "events": [{"eventName":"SendAlert","actions":[{"lambda":{"functionArn":"arn:aws:lambda:ap-northeast-1:123456789012:function:emergency-handler"}}]}],
 "transitionEvents": [
{"eventName":"toNormal","condition":"$input.sensor.temp < 60","actions":[],"nextState":"Normal"}
 ]
  }
}
 ],
 "initialStateName": "Normal"
  },
  "key": "deviceId"
}

詰まり2: IoT Analytics Pipeline activity 罠 — Lambda 変換コスト爆発とバッチ遅延

症状: IoT Analytics Pipeline の Lambda activity を多用したところ、メッセージ数に比例して Lambda 実行コストが急増した。また Lambda 内で外部 API を呼ぶ処理を入れたため、Pipeline のレイテンシが数秒に達し、Notebook 分析のリアルタイム性が失われた。

原因: Pipeline の Lambda activity はメッセージ 1 件ごとに Lambda を同期呼び出しする設計のため、1 日 100 万メッセージ × Lambda 実行単価が直接コストに反映される。外部 API 呼び出しを Lambda 内で行うとその応答待ちが Pipeline のスループットを制限する。

解決策: 単純なフィールド変換は Math activity や AddAttributes activity で処理し、Lambda は複雑なビジネスロジックにのみ使う。バッチ的に変換が必要な場合は Dataset の SQL クエリ層で変換し、Lambda 実行回数を削減する。

resource "aws_iotanalytics_pipeline" "sensor_pipeline" {
  name = "sensor-pipeline"

  pipeline_activities {
 channel {
name= "ChannelActivity"
channel_name = aws_iotanalytics_channel.sensor.name
next= "FilterActivity"
 }
  }

  pipeline_activities {
 filter {
name= "FilterActivity"
filter = "temp > 0 AND temp < 200"
next= "MathActivity"
 }
  }

  pipeline_activities {
 math {
name= "MathActivity"
attribute = "temp_f"
math= "temp * 1.8 + 32"
next= "DatastoreActivity"
 }
  }

  pipeline_activities {
 datastore {
name  = "DatastoreActivity"
datastore_name = aws_iotanalytics_datastore.sensor.name
 }
  }
}

詰まり3: TwinMaker Scene 最適化 — 大規模 3D モデルのブラウザパフォーマンス低下

症状: 工場全体の 3D CAD データ (GLB 形式 500MB 超) を TwinMaker Scene に取り込んだところ、Grafana TwinMaker パネルのロードに 30 秒以上かかり、ブラウザのメモリ使用量が 4GB に達してクラッシュするケースが出た。

原因: TwinMaker Scene の 3D モデルは S3 から直接ブラウザにストリームされる。巨大な GLB ファイルを 1 ファイルで管理すると初期ロード量が膨大になる。また高ポリゴンモデルをそのまま使うと GPU レンダリング負荷が高くなる。

解決策: 3D モデルを階層ごとに分割し、必要なエリアだけをロードする LOD (Level of Detail) 設計を採用する。GLB ファイルは draco 圧縮を適用し 90% 以上のサイズ削減を図る。TwinMaker の Entity/Component 階層でロード順序を制御し、初期表示には低解像度モデルを使う。

Scene 設計原則:
  GLB ファイル分割: エリア単位 (建物棟 / フロア / ライン)
  draco 圧縮: 500MB → 30-50MB 目標
  LOD 3段階:
 遠距離 (Low)- 10,000 ポリゴン以下
 中距離 (Medium) - 50,000 ポリゴン以下
 近距離 (High)  - 200,000 ポリゴン以下
  Entity 階層: Factory → Building → Floor → Machine (4 階層)
  初期ロード: Low-LOD モデルのみ
  インタラクション後: 該当 Entity のみ High-LOD へ切り替え

詰まり4: FleetWise Campaign コスト — 全信号収集 vs 選択的収集の判断基準

症状: FleetWise Campaign を「全 Signal 収集 / 常時アップロード」で設定したところ、車両 1 台あたりの月次データ転送コストが想定の 10 倍以上になった。クラウドへのアップロード量も膨大で Analytics の Datastore コストも跳ね上がった。

原因: 車両 CAN バスは毎秒数千シグナルを生成する。これを全量 / 常時アップロードすると 1 台あたり数 GB/日のデータ転送が発生する。FleetWise の課金モデルはクラウド転送データ量に比例するため、全量収集は設計ミスとなる。

解決策: Campaign の収集条件を conditionBasedCollectionScheme (Trigger ベース) に変更し、異常条件 (急加速 / 急減速 / 異常温度) が発生した前後数秒間のデータのみを収集する。通常時は低頻度サンプリング (1Hz) に抑える。

resource "aws_iotfleetwise_campaign" "vehicle_anomaly" {
  name= "vehicle-anomaly-campaign"
  signal_catalog_arn = aws_iotfleetwise_signal_catalog.main.arn
  target_arn= aws_iotfleetwise_fleet.main.arn

  collection_scheme {
 condition_based_collection_scheme {
condition_language_version  = 1
expression= "$variable.VehicleSpeed > 120 || $variable.BrakeForce > 80"
minimum_trigger_interval_ms = 5000
trigger_mode = "ALWAYS"
 }
  }

  signals_to_collect {
 name = "Vehicle.Speed"
 max_sample_count = 100
 minimum_sampling_interval_ms = 100
  }

  signals_to_collect {
 name = "Vehicle.BrakeForce"
 max_sample_count = 100
 minimum_sampling_interval_ms = 100
  }

  post_trigger_collection_duration = 5000
}

詰まり5: コスト最適化罠 — IoT Analytics Reserved capacity と FleetWise Edge 同期頻度

症状: IoT Analytics のコストが月に急増した。調査すると Pipeline の処理量に対して Reserved capacity を過大設定していた。一方 FleetWise の Edge agent が 1 分おきにクラウドと同期しており、通信コストが高止まりしていた。

原因: IoT Analytics の Reserved capacity はスループット保証のための購入済み処理能力で、未使用でも課金される。実際のメッセージレートより大きく設定すると無駄になる。FleetWise Edge agent のクラウド同期頻度はデフォルトで短く設定されているケースがあり、Campaign 更新が頻繁でない場合は短い同期間隔は不要なコストになる。

解決策: IoT Analytics は実際のメッセージレートを CloudWatch Metrics (IncomingMessages) で計測し、Reserved capacity を実測値 + 20% バッファで設定する。FleetWise Edge agent の同期間隔は Campaign 更新頻度に合わせ、運用フェーズでは 15 分〜1 時間に延長する。

IoT Analytics コスト最適化チェックリスト:
  1. CloudWatch: PipelineActivities/IncomingMessages を 2 週間計測
  2. ピークメッセージ/秒 x 1.2 = 適切な Reserved capacity
  3. Reserved capacity は月単位購入 → 削減は翌月から反映
  4. Pipeline activity の Lambda 呼び出し数を最小化 (詰まり2参照)

FleetWise Edge 同期コスト最適化:
  開発/テスト期: 1-5 分同期 (Campaign 検証目的)
  本番稼働期: 15-60 分同期 (Campaign 更新は事前計画)
  緊急更新が必要な場合のみ即時同期を手動トリガー

詰まり6: Edge 同期 — FleetWise Edge agent 接続断時のデータバッファ動作

症状: 車両がトンネルや地下駐車場に入り LTE 接続が切れると、FleetWise のデータが欠損すると思っていた。しかし期待とは異なり、接続断中のデータが一部しか保存されていないケースが発生した。

原因: FleetWise Edge agent は接続断中のデータをローカルストレージにバッファするが、バッファサイズとデータ保持期間に上限がある。デフォルト設定では 24 時間分を保持するが、高頻度収集 Campaign が動作中の場合は 30 分程度で満杯になることがある。また Edge agent プロセスが再起動 (OTA 更新 / OS クラッシュ) した場合、メモリ内バッファは失われる。

解決策: Edge agent の永続化バッファ (Persistent queue) を有効にし、ストレージに書き込む設定にする。バッファサイズは収集データレート × 想定接続断時間で計算し、十分な容量を確保する。

{
  "staticConfig": {
 "bufferSizes": {
"dtcBufferSize": 100,
"encodedSignalBufferSize": 10000,
"rawCANFrameBufferSize": 10000
 },
 "threadIdleTimes": {
"inspectionThreadIdleTimeMs": 50,
"socketCANInterfaceThreadIdleTimeMs": 50,
"canDecoderThreadIdleTimeMs": 50
 },
 "persistencyPath": "/var/aws-iot-fleetwise",
 "persistencyUploadRetryIntervalMs": 10000
  }
}

詰まり7: データ品質 — IoT Analytics Pipeline 欠損値・外れ値処理パターン

症状: IoT Analytics の Dataset から取得したデータで機械学習モデルを学習させたところ、センサー故障時の null 値や 9999 (エラーコード) が混入し、モデル精度が大幅に低下した。Pipeline に入力時点でのフィルタリングが不十分だった。

原因: IoT デバイスはセンサー故障時に null、-1、9999、0 などをエラーコードとして送信するが、Pipeline の Filter activity だけでは全パターンを事前定義できない。欠損値は Dataset の SQL クエリ層だけでは後処理が複雑になる。

解決策: Pipeline の Filter activity で明示的な異常値範囲を除外し、Lambda activity で統計的外れ値検出 (物理限界値チェック) を実装する。欠損値はフォワードフィル (前値補完) か、欠損フラグを付加して下流で判定させる方針を統一する。

import json

def lambda_handler(event, context):
 messages = []
 for msg in event.get("messages", []):
  payload = msg.get("payload", {})
  temp = payload.get("temp")

  # 明示的エラーコード除外
  if temp is None or temp in (-1, 9999, 0):
payload["temp"] = None
payload["temp_quality"] = "MISSING"
  # 物理限界値チェック (センサー範囲: -40 〜 150 °C)
  elif temp < -40 or temp > 150:
payload["temp"] = None
payload["temp_quality"] = "OUT_OF_RANGE"
  else:
payload["temp_quality"] = "VALID"

  msg["payload"] = payload
  messages.append(msg)

 return {"messages": messages}

§7 アンチパターン → 正解パターン変換演習 (5問)

IoT Vol2 の4サービスに関する典型的なアンチパターンを5問の演習形式で学ぶ。各問は「状況説明 → アンチパターン → 正解パターン → 解説」の構造で構成する。

Q1: Rules engine 単独 → IoT Events Detector Model (複雑状態管理 / State machine 設計)

状況: 工場の温度センサーが「正常 → 警告 → 危険」と状態遷移する。初期実装では IoT Core の Rules engine で Lambda を呼び出し、DynamoDB に状態を書き込んで状態遷移を管理していた。

アンチパターン: Lambda + DynamoDB で状態機械を自前実装

# Lambda で DynamoDB に状態を書き込み / 読み取りして状態遷移を管理
def lambda_handler(event, context):
 device_id = event["deviceId"]
 temp = event["temperature"]
 # DynamoDB から現在状態を取得
 current_state = get_state_from_dynamodb(device_id)
 # 手動で状態遷移ロジックを実装
 if current_state == "Normal" and temp > 80:
  new_state = "Warning"
  send_alert(device_id, "Warning")
 elif current_state == "Warning" and temp > 95:
  new_state = "Critical"
  trigger_emergency(device_id)
 # DynamoDB に状態を書き込み (競合状態リスクあり)
 save_state_to_dynamodb(device_id, new_state)

正解パターン: IoT Events の Detector Model で状態機械をマネージドに管理

resource "aws_iotevents_detector_model" "factory_monitor" {
  name  = "FactoryTemperatureMonitor"
  role_arn = aws_iam_role.iotevents.arn
  evaluation_method = "SERIAL"

  definition {
 initial_state_name = "Normal"

 state {
state_name = "Normal"
on_input {
  transition_events {
 event_name = "ToWarning"
 condition  = "$input.SensorInput.temperature > 80"
 next_state = "Warning"
 actions {
sns { target_arn = aws_sns_topic.alerts.arn
  payload { content_expression = "'Warning triggered'" type = "STRING" }
}
 }
  }
}
 }

 state {
state_name = "Warning"
on_input {
  transition_events {
 event_name = "ToCritical"
 condition  = "$input.SensorInput.temperature > 95"
 next_state = "Critical"
 actions {
lambda { function_arn = aws_lambda_function.emergency.arn
  payload { content_expression = "'{}'" type = "STRING" }
}
 }
  }
  transition_events {
 event_name = "ToNormal"
 condition  = "$input.SensorInput.temperature < 75"
 next_state = "Normal"
 actions {}
  }
}
 }

 state {
state_name = "Critical"
on_input {
  transition_events {
 event_name = "RecoverToNormal"
 condition  = "$input.SensorInput.temperature < 70"
 next_state = "Normal"
 actions {}
  }
}
 }
  }
  key = "deviceId"
}

解説: IoT Events の Detector Model は State machine をマネージドに管理する。DynamoDB への状態書き込み / 競合状態リスク / Lambda コールドスタートによるレイテンシを排除できる。key = "deviceId" により 10,000 台スケールでも追加インフラ不要。

Q2: 自前 ETL Lambda → IoT Analytics Pipeline (フルマネージド / コスト予測可能)

状況: IoT デバイスからのセンサーデータを S3 に保存し、Lambda でバッチ変換してから Athena で分析していた。Lambda の実行時間が長く、コスト予測が困難だった。

アンチパターン: Lambda + S3 + Athena の自前 ETL パイプライン

# アンチパターン: Rules engine → Lambda → S3 の自前 ETL
resource "aws_iot_topic_rule" "to_lambda" {
  name = "SensorToLambda"
  enabled = true
  sql  = "SELECT * FROM 'sensors/+/data'"

  lambda {
 function_arn = aws_lambda_function.etl_transformer.arn
  }
}
# Lambda で複雑な変換 + S3 書き込み → Athena クエリ
# 問題点: Lambda 実行時間が長い / コスト予測困難 / スケール時の並列度管理が複雑

正解パターン: IoT Analytics Pipeline でフルマネージド変換

resource "aws_iotanalytics_channel" "sensor" {
  name = "sensor-channel"
}

resource "aws_iotanalytics_pipeline" "sensor" {
  name = "sensor-pipeline"

  pipeline_activities {
 channel {
name= "ChannelInput"
channel_name = aws_iotanalytics_channel.sensor.name
next= "FilterBadData"
 }
  }
  pipeline_activities {
 filter {
name= "FilterBadData"
filter = "temperature > -40 AND temperature < 150"
next= "ConvertTempF"
 }
  }
  pipeline_activities {
 math {
name= "ConvertTempF"
attribute = "temperature_f"
math= "temperature * 1.8 + 32"
next= "StoreDatastore"
 }
  }
  pipeline_activities {
 datastore {
name  = "StoreDatastore"
datastore_name = aws_iotanalytics_datastore.sensor.name
 }
  }
}

resource "aws_iotanalytics_datastore" "sensor" {
  name = "sensor-datastore"
  datastore_storage {
 customer_managed_s3 {
bucket= aws_s3_bucket.analytics.bucket
key_prefix  = "iot-analytics/"
role_arn = aws_iam_role.iotanalytics.arn
 }
  }
}

解説: IoT Analytics Pipeline は自動スケールするフルマネージドサービスで、Lambda の自前管理を不要にする。Filter / Math / AddAttributes など組み込み activity で標準的な変換をカバーし、Lambda activity はカスタムロジックにのみ絞れる。コストは処理メッセージ数に比例するため予測が容易になる。

Q3: 静的 3D CAD 図 → IoT TwinMaker (デジタルツイン × リアルタイム更新 / GenAI 連携)

状況: 工場設備の監視に静的な 3D CAD 図をスライドで共有していた。設備の状態変化を確認するたびに担当者が現地確認していた。

アンチパターン: 静的 CAD ビューワーで設備状態を人手確認

アンチパターン構成:
  センサー → CloudWatch → アラーム → メール通知 → 担当者が手動で CAD 図と照合
  問題点:
 - リアルタイム性がない (アラームから確認まで数分〜数時間)
 - 設備間の関係性が可視化できない
 - 異常の根本原因特定に時間がかかる

正解パターン: IoT TwinMaker で設備状態をリアルタイム 3D 可視化

resource "aws_iottwinmaker_workspace" "factory" {
  workspace_id = "factory-digital-twin"
  role= aws_iam_role.twinmaker.arn
  s3_location  = "arn:aws:s3:::${aws_s3_bucket.twinmaker.bucket}"
}

resource "aws_iottwinmaker_entity" "production_line" {
  workspace_id = aws_iottwinmaker_workspace.factory.workspace_id
  entity_id = "production-line-01"
  entity_name  = "ProductionLine01"

  component {
 component_name = "TemperatureSensor"
 component_type_id = "com.example.TemperatureSensorComponent"
 properties = {
"temperature" = jsonencode({
  value = {
 expression = "$\{com.amazonaws.iot.timestream.query.TelemetryData.temperature}"
  }
})
 }
  }
}

解説: IoT TwinMaker は 3D モデルにリアルタイムのセンサーデータを重ねて表示できる。Grafana の TwinMaker パネルでブラウザから確認でき、設備の色変化でアラーム状態を即座に可視化する。GenAI Connector (Bedrock Claude) との統合で、異常原因を自然言語で問い合わせることも可能になる。

Q4: 全データ収集 → IoT FleetWise selective signal (コスト削減 / トリガーベース収集)

状況: 車両の全センサーシグナルを常時アップロードする Campaign を設定したところ、車両 100 台で月次の AWS コストが予算の 5 倍に達した。

アンチパターン: 全 Signal / 常時収集 Campaign

# アンチパターン: 全シグナルを常時アップロード
resource "aws_iotfleetwise_campaign" "all_signals" {
  name= "all-signals-always"
  signal_catalog_arn = aws_iotfleetwise_signal_catalog.main.arn
  target_arn= aws_iotfleetwise_fleet.main.arn

  collection_scheme {
 time_based_collection_scheme {
period_ms = 1000  # 1秒ごと全シグナル = 1台あたり数GB/日
 }
  }
  # signals_to_collect を省略 = 全シグナル収集
  # 100台 x 数GB/日 = 数TB/日のデータ転送コスト
}

正解パターン: 条件トリガーベースで必要なシグナルのみ収集

# 通常時: 診断目的の低頻度サンプリング
resource "aws_iotfleetwise_campaign" "baseline" {
  name= "vehicle-baseline"
  signal_catalog_arn = aws_iotfleetwise_signal_catalog.main.arn
  target_arn= aws_iotfleetwise_fleet.main.arn

  collection_scheme {
 time_based_collection_scheme {
period_ms = 60000  # 1分に1回のみ
 }
  }

  signals_to_collect {
 name = "Vehicle.CurrentLocation.Latitude"
 minimum_sampling_interval_ms = 60000
  }
  signals_to_collect {
 name = "Vehicle.Speed"
 minimum_sampling_interval_ms = 60000
  }
}

# 異常時: 条件トリガーで詳細収集
resource "aws_iotfleetwise_campaign" "anomaly" {
  name= "vehicle-anomaly-detail"
  signal_catalog_arn = aws_iotfleetwise_signal_catalog.main.arn
  target_arn= aws_iotfleetwise_fleet.main.arn

  collection_scheme {
 condition_based_collection_scheme {
condition_language_version  = 1
expression= "$variable.Vehicle.Speed > 130 || $variable.Vehicle.BrakeTemp > 300"
minimum_trigger_interval_ms = 10000
trigger_mode = "ALWAYS"
 }
  }

  signals_to_collect {
 name = "Vehicle.Speed"
 minimum_sampling_interval_ms = 100
  }
  signals_to_collect {
 name = "Vehicle.BrakeTemp"
 minimum_sampling_interval_ms = 100
  }
  signals_to_collect {
 name = "Vehicle.EngineRPM"
 minimum_sampling_interval_ms = 100
  }

  post_trigger_collection_duration = 10000
}

解説: 2 Campaign 構成 (通常時: 低頻度ベースライン / 異常時: 条件トリガー詳細) により、収集データ量を 95% 以上削減できる。異常条件発生から 10 秒後までのデータを保存するため、根本原因分析に必要なデータは確保できる。

Q5: オンプレ車両データ分析 → FleetWise + Analytics 連携 (マネージド / スケール)

状況: 車両から収集したデータを自社サーバーで集約し、Python スクリプトで分析していた。車両台数が 1,000 台を超えたところで自社サーバーの処理能力が限界に達した。

アンチパターン: 自社サーバー集約 + Python バッチ分析

アンチパターン構成:
  車両 → LTE → 自社サーバー (IoT Gateway) → ローカル DB → Python バッチ分析
  問題点:
 - 自社サーバーのスケールアップが必要 (コスト / 運用負荷)
 - バッチ分析のリアルタイム性がない
 - サーバー障害時にデータ欠損リスク
 - 車両台数増加で線形コスト増加

正解パターン: FleetWise + IoT Analytics のフルマネージド連携

# FleetWise から S3 経由で IoT Analytics Datastore へ連携
resource "aws_iotfleetwise_campaign" "analytics_feed" {
  name= "analytics-feed"
  signal_catalog_arn = aws_iotfleetwise_signal_catalog.main.arn
  target_arn= aws_iotfleetwise_fleet.main.arn

  collection_scheme {
 time_based_collection_scheme {
period_ms = 5000
 }
  }

  data_destination_configs {
 s3_config {
bucket_arn= aws_s3_bucket.vehicle_data.arn
data_format  = "PARQUET"
prefix = "vehicle-data/"
storage_compression_format = "GZIP"
 }
  }

  signals_to_collect {
 name = "Vehicle.Speed"
 minimum_sampling_interval_ms = 1000
  }
  signals_to_collect {
 name = "Vehicle.FuelLevel"
 minimum_sampling_interval_ms = 5000
  }
}

# S3 → IoT Analytics Channel へのルート (IoT Core Rule経由)
resource "aws_iot_topic_rule" "fleetwise_to_analytics" {
  name = "FleetwiseToAnalytics"
  enabled = true
  sql  = "SELECT * FROM 'fleetwise/+/data'"

  iot_analytics {
 channel_name = aws_iotanalytics_channel.vehicle.name
 role_arn  = aws_iam_role.iot_analytics_rule.arn
  }
}

# Analytics Dataset で集計分析
resource "aws_iotanalytics_dataset" "fleet_summary" {
  name = "fleet-daily-summary"

  content_delivery_rules {
 destination {
s3_destination_configuration {
  bucket= aws_s3_bucket.analytics_results.bucket
  key= "fleet-summary/!{iotanalytics:scheduleTime}/data.csv"
  role_arn = aws_iam_role.iotanalytics.arn
}
 }
  }

  actions {
 action_name = "SqlAction"
 query_action {
sql_query = "SELECT deviceId, AVG(speed) as avg_speed, MAX(speed) as max_speed, AVG(fuel_level) as avg_fuel FROM vehicle_datastore WHERE __dt > current_date - interval '1' day GROUP BY deviceId"
 }
  }

  triggers {
 schedule {
expression = "cron(0 1 * * ? *)"
 }
  }
}

解説: FleetWise が車両データを S3 に Parquet 形式で保存し、IoT Analytics がそのデータを取り込んで分析する。自社サーバーが不要になり、車両 10,000 台に増加しても AWS 側が自動スケールする。IoT Analytics の Notebook 機能で SageMaker との連携も容易になり、燃費予測・異常検知モデルを迅速に構築できる。

§8 まとめ + IoT二部作開始 + 49記事化告知 + 全軸クロスリンクナビ

8-1. 4本柱まとめ — IoT Events × Analytics × TwinMaker × FleetWise

本記事では AWS IoT Vol2 として、Vol1 (IoT Core / Greengrass / SiteWise / Device Defender) のデバイス接続層の上に構築される「イベント検知・分析・デジタルツイン・モビリティ」の4サービスを体系的に解説した。

IoT Events — Detector Model による複雑状態管理

IoT Events の核心は Detector Model だ。State machine を「正常 / 警告 / 異常」の3状態に収めることで可読性と保守性を担保できる。Multi-detector の key フィールドにより、10,000 台規模のデバイス群でもインフラ追加なしに独立した状態管理インスタンスを自動生成できる。Actions (SNS / Lambda / DynamoDB / Firehose) の冪等性設計は at-least-once 保証の IoT Events では必須の考慮事項だ。アンチパターンである「Lambda + DynamoDB による自前状態機械」を Detector Model に置き換えることで、競合状態リスクを排除しスケールを自動化できる。

IoT Analytics — フルマネージド分析パイプライン

IoT Analytics の Pipeline は Channel → Filter/Math/AddAttributes → Datastore の直列構成でメッセージ変換を自動化する。Lambda activity の多用はコスト爆発を招くため、標準 activity で処理できる変換は Lambda を使わないことが鉄則だ。Customer-managed S3 Datastore を選択することでデータの所有権を維持しつつ、Dataset の SQL クエリで柔軟な集計分析ができる。SageMaker Notebook との統合により、IoT データの機械学習パイプラインを短期間で構築できる。

IoT TwinMaker — 3D デジタルツインでリアルタイム可視化

IoT TwinMaker の Workspace / Entity / Component 階層はデジタルツインの設計図だ。Entity 階層 (Factory → Building → Floor → Machine) で物理空間を論理的にモデル化し、Component で各 Entity のリアルタイムデータを紐付ける。大規模 3D Scene は GLB ファイルをエリア単位に分割し draco 圧縮を適用することでブラウザのパフォーマンス問題を回避する。GenAI Connector (Bedrock Claude) との統合により、設備の異常原因を自然言語で問い合わせる次世代監視が実現できる。

IoT FleetWise — 車両データ収集を Trigger ベースで最適化

IoT FleetWise の Signal catalog は CAN/OBD-II シグナルの標準化辞書であり、Vehicle model と Campaign で車両データ収集を制御する。全シグナル / 常時収集は数TB/日のコスト爆発を招く。conditionBasedCollectionScheme で異常条件発生時のみ詳細収集し、通常時は 1Hz 以下の低頻度ベースライン収集に絞る 2-Campaign 構成が本番運用のベストプラクティスだ。Edge agent の persistencyPath を永続ストレージに設定することで、接続断中のデータバッファ消失を防ぐ。

§6+§7 の学習ポイント

詰まり7選では、Detector Model State 肥大化・Pipeline Lambda コスト爆発・TwinMaker Scene 巨大化・FleetWise 全データ収集・コスト設定ミス・Edge 接続断バッファ・データ品質欠損値の7パターンを対処法とともに整理した。演習5問では IoT Events / Analytics / TwinMaker / FleetWise の各サービスへの移行パターンを Terraform コードで実践した。

IoT Vol2 の4サービスはそれぞれ独立して使えるが、組み合わせることで真の価値を発揮する。IoT Core (Vol1) のデータを IoT Analytics で蓄積し、IoT Events で異常を検知し、IoT TwinMaker でリアルタイムに可視化し、IoT FleetWise で車両データを加える。この統合アーキテクチャが「AWS IoT 縦断設計」だ。Vol1 と Vol2 の両方を習得することで、デバイス接続から価値抽出までの全工程を自ら設計できるようになる。

IoT Vol2 本番導入チェックリスト

IoT Vol2 の4サービスを本番環境に導入する前に、以下のチェックリストで設計の抜け漏れを確認する。

8-2. IoT 二部作開始 + Vol1↔Vol2 双方向ナビ

8-3. AWS 本番運用シリーズ 49 記事化達成 + 全 20 軸全容

8-4. IoT 二部作マップ + 全軸接続図 (Mermaid02)

graph LR
  IOT2[IoT Vol2 第19軸縦深化] --> IOT1[IoT Vol1 IoT Core/Greengrass]
  IOT2 --> GM[Game/Media Vol1 第20軸]
  IOT2 --> DB[Database Vol1-4]
  IOT2 --> CON[Container Vol1-3]
  IOT2 --> DEV[DevOps Vol1-3]
  IOT2 --> OBS[Observability Vol1-2]
  IOT2 --> AI[AI/ML Vol1-3]
  IOT2 --> ANL[Analytics Vol1]
  IOT2 --> SRV[Serverless Vol1-2]
  IOT2 --> SEC[Security Vol1-3]
  IOT1 --> IOT2
  IOT2 --> STG[Storage Vol1-2]
  IOT2 --> SF[Step Functions Vol1-3]

IoT Vol2 は第19軸の縦深化巻として、Vol1 (デバイス接続層) と双方向に連携しながら、他の全軸とも接続している。IoT Analytics は Analytics / AI/ML / Storage と連携し、IoT TwinMaker は AI/ML (GenAI Connector) / Observability と接続する。IoT FleetWise は Container (Edge コンテナ) / Serverless (Lambda トリガー) / DevOps (OTA 配信パイプライン) と組み合わせることで本番グレードのモビリティ基盤が完成する。

全軸接続図が示す通り、IoT は孤立したサービス群ではない。他の全軸のサービスと深く連携することで、スマートファクトリー・コネクテッドカー・インフラ監視などのユースケースを実現する総合的なプラットフォームだ。IoT Vol1 と Vol2 の二部作を組み合わせることで、エッジのデバイスから AWS クラウドの AI 分析基盤までを一本の線で繋いだシステムを設計できる。本シリーズを通じて、AWS IoT の設計力を段階的に高めていってほしい。

8-5. 関連記事 ep-btn + 次のステップ

本記事で構築した IoT Vol2 の知識を活かすための関連記事を以下に示す。IoT Analytics の分析基盤をさらに深めたい方は Analytics Vol1 へ、TwinMaker GenAI Connector を活用したい方は AI/ML Vol3 へ進むことを推奨する。

IoT Vol1 — IoT Core × Greengrass × SiteWise × Device Defender

Game/Media Vol1 — AppStream 2.0 × MediaConvert × MediaLive × GameLift

Database Vol4 — Aurora DSQL × Limitless × DynamoDB Strong

IoT Vol2 で学んだ4サービス (Events/Analytics/TwinMaker/FleetWise) は、それ単体では機能しない。Vol1 で構築した IoT Core × Greengrass の接続基盤があって初めて真の価値を発揮する。

デバイス接続 (Vol1) → イベント検知 (IoT Events) → データ分析 (IoT Analytics) → デジタルツイン可視化 (IoT TwinMaker) → 車両データ収集 (IoT FleetWise) — この一連の流れが AWS IoT の「縦断アーキテクチャ」だ。本記事がその全体像を理解し、本番設計力を高める一助となれば幸いだ。

次に取り組むべきステップ

本記事を読み終えた SRE / IoT エンジニアへ、次のアクションを提案する。

• IoT Events をまず試す: IoT Core の Rules engine で Lambda を使って状態管理しているワークロードがあれば、Detector Model への移行候補だ。既存 Lambda の状態数を棚卸しし、3 状態に整理できるか検証するところから始める。
• IoT Analytics Pipeline を評価する: 自前 Lambda ETL のコストを CloudWatch Logs Insights で計測し、IoT Analytics の Pipeline に置き換えたときのコスト削減を試算する。Channel + Pipeline + Datastore の Terraform テンプレートは §3 のコードをそのまま流用できる。
• TwinMaker の Grafana パネルを試す: AWS コンソールの TwinMaker で無料の Workspace を作成し、サンプル Entity を 1 件追加して Grafana パネルで表示するまでを 1 時間で体験できる。まず動くものを見てから設計を深めることを推奨する。
• FleetWise の Signal catalog 設計を先行する: Vehicle model と Campaign は Signal catalog が先にないと設計できない。CAN/OBD-II の標準シグナル定義を調査し、自社車両に必要な Signal 一覧を事前に整理してから Terraform に進む。

AWS 本番運用シリーズは今後も各軸の縦深化 Vol を追加していく。第20軸の公開もぜひ期待してほしい。次の記事もぜひ購読してほしい。

本記事を最後まで読んでくれたエンジニアへ: IoT Vol2 で解説した技術は、現場の課題を解決するためにある。Detector Model で工場の異常を早期検知し、IoT Analytics でデータドリブンな意思決定を実現し、TwinMaker でリモート監視を高度化し、FleetWise で車両データをコスト効率よく収集する — これらはすべて実装可能だ。まず一つを選んで動かしてみてほしい。

IoT Vol1 と Vol2 の二部作を完読したエンジニアは、AWS IoT の全体設計図を頭の中に持っている。この知識を活かして、現場のデバイス接続から分析・可視化まで一気通貫のシステムを設計してほしい。