AWS IoT FleetWise

解決する課題

• 車両には多数のセンサーやECUがあり、信号の名称や形式が車種・メーカーごとにバラバラで、横断的にデータを扱えない
• すべての信号を常時クラウドへ送ると通信量とコストが膨大になり、現実的に収集しきれない
• 走行データを分析や機械学習に使いたいが、収集・標準化・転送の基盤を自前で構築・運用する負担が大きい

主要概念と用語

• 信号カタログ（Signal Catalog）: 車両から取得できる信号を共通の語彙として定義したもの。車種を横断して標準化の基準になる
• 車両モデル（Vehicle Model / モデルマニフェスト）: 特定の車種が持つ信号の集合を定義したテンプレート。同型の車両に再利用する
• デコーダマニフェスト: 生のバス信号（CAN や OBD-II など）を信号カタログの標準信号へ変換する方法を定義したもの
• 車両（Vehicle）: クラウド上に登録される個々の車両の表現。車両モデルとデコーダマニフェストに紐づく
• キャンペーン（Campaign）: どの信号を、どんな条件で、どこへ収集するかを定義した収集計画。クラウドから車両へ配信される
• エッジエージェント: 車載側で動作するソフトウェア。AWSの参照実装を基に利用者が開発・試験・配布・更新し、キャンペーンに従って信号をデコード・収集する
• 収集スキーム: 条件成立時に集めるか、一定間隔で集めるかといった収集の方式

仕様・制限・クォータ

• クラウド側の信号定義、キャンペーン配信、取り込み基盤はマネージドだが、車載エッジエージェントはAWSの参照実装を基に利用者が開発・試験・配布・更新する
• 車両の生信号はデコーダマニフェストで標準信号へ変換され、車種が違っても共通の名前でデータを扱える
• 収集はキャンペーンで制御し、特定の条件が成立したときだけ集める方式や、一定間隔で集める方式を選べる
• 収集データはAmazon S3へ保存できる。Amazon Timestream for LiveAnalyticsは2025年6月20日から新規顧客を受け付けていないため、既存の利用資格がある場合だけ候補にする
• 信号カタログの信号数、キャンペーン数、車両数などには上限がある。具体的な数値は変動するため、最新値は公式ドキュメントで確認する
• 対応する車載プロトコルや地域（リージョン）には範囲があるため、利用前に対応状況を確認する

内部の仕組み

横にスクロール

AWS IoT FleetWise は、車両側のデータ収集からクラウドでの集約までを一連の流れとして提供します。まずクラウド上で信号カタログを定義し、車両から取得しうる信号を共通の語彙として標準化します。次に車種ごとの車両モデルで、その車種が持つ信号の集合を表現し、デコーダマニフェストで CAN や OBD-II といった生のバス信号を標準信号へ変換する方法を定義します。これにより、メーカーや車種が異なっても、クラウドでは同じ信号名でデータを扱えます。

実際の収集はキャンペーンで制御します。キャンペーンには、どの信号を、どんな条件で集めるかを定義し、クラウドから対象車両のエッジエージェントへ配信します。AWSは参照エッジエージェントを公開していますが、車載環境に合わせた開発、試験、配布、更新、切断中の保存と再送は利用組織の責任です。エージェントは信号をデコードし、条件成立時だけ周辺データを集めることで通信量を抑えます。収集結果はS3等へ届け、分析・可視化や機械学習の入力として利用します。

設計パターン / ベストプラクティス

• 信号カタログを全社共通の語彙として設計し、車種ごとの差異はデコーダマニフェスト側で吸収する
• 常時収集は避け、イベント条件付きのキャンペーンで必要な場面のデータに絞って通信量とコストを抑える
• 異常診断やインシデント解析の用途では、トリガー前後の周辺データを含めて収集できるよう条件を設計する
• 長期保存や機械学習の学習データはS3へ集約し、時系列基盤は利用資格、保持、検索、移行性を比較して選ぶ
• 車両モデルとデコーダマニフェストはバージョンを管理し、車載ソフトの更新と整合させて段階的に展開する

運用・監視

• CloudWatch でデータ収集のスループットやエラー、キャンペーン配信の状況を監視する
• 車両ごとの収集状態やエージェントの稼働を確認し、データ欠落や未配信のキャンペーンを早期に検知する
• デコーダマニフェストや車両モデルの変更が既存車両に与える影響を把握し、変更は段階的に適用する
• 収集先への書き込み失敗に備え、送り先側の権限や容量、エラーハンドリングを点検する

コスト

• 主なコストは収集対象の車両数、収集するデータ量、データメッセージの件数などの組み合わせで構成される
• 常時全信号を集めるとデータ量と通信が増えるため、条件付きキャンペーンで必要なデータに絞ることがコスト最適化の要になる
• 収集先のS3や分析基盤など、連携する他サービス側のストレージ・処理コストも別途かかる
• 料金は変動するため、最新の単価は公式の料金ページで確認する

セキュリティ

• アクセス制御は IAM で行い、最小権限の原則に従って信号カタログ・車両・キャンペーンへの操作権限を付与する
• 車両とクラウド間の通信は TLS で保護され、保存データは KMS で暗号化される
• 車両の登録や認証は IoT の仕組みと整合させ、不正なデバイスからの収集を防ぐ
• 操作の監査には CloudTrail を利用し、誰がいつ何を操作したかを記録する
• 走行データは位置情報など機微なデータを含みうるため、収集範囲とアクセス権限を慎重に設計する

関連サービス・比較

ハンズオン / CLI例

# 信号カタログを作成（標準信号の語彙を定義）
aws iotfleetwise create-signal-catalog \
  --name "GlobalCatalog" \
  --nodes file://nodes.json

# 車両モデル（モデルマニフェスト）を作成
aws iotfleetwise create-model-manifest \
  --name "SedanModel" \
  --signal-catalog-arn <signal-catalog-arn> \
  --nodes '["Vehicle.Powertrain.EngineSpeed"]'

# 収集計画（キャンペーン）を作成
aws iotfleetwise create-campaign \
  --name "EngineSpeedCampaign" \
  --signal-catalog-arn <signal-catalog-arn> \
  --target-arn <vehicle-or-fleet-arn> \
  --collection-scheme file://collection-scheme.json