ロードマップと実装ステップ

IoT活用 ITロードマップ（FY2026〜FY2028）3年

IoT基盤 ToBeアーキテクチャ：段階的実装ステップ

IoT Coreの導入ポイント
IoT Coreは「デバイスとクラウドの接点」なので、後から変えにくい認証・トピック設計を最初に固めることが重要です。

1. デバイス認証：1台1証明書
   X.509証明書をデバイスごとに発行します。全デバイスで1枚の証明書を共有すると、1台が漏洩しただけで全台の失効が必要になります。台数が多い場合は、工場出荷時にプロビジョニング用の証明書だけを焼き込み、初回接続時に本番証明書を発行するフリートプロビジョニングを使います。証明書の有効期限切れに備えて、更新の仕組み（Jobsで配信など）も最初から計画しておきます。

2. ポリシー：最小権限＋ポリシー変数
   iot:* や Resource: * は避けます。${iot:Connection.Thing.ThingName} などのポリシー変数を使うと、「自分のThing名のトピックにだけPublish/Subscribeできる」ポリシーを1つ書くだけで全台に適用できます。他のデバイスになりすました送信を防げます。

3. トピック設計
   後から変えるとファームウェア更新が必要になるため、最初に命名規則を決めます。

テレメトリ：dt/{システム}/{拠点}/{デバイスID}/telemetry
コマンド：cmd/{システム}/{デバイスID}/req と .../res

先頭に用途（dt / cmd）、次に範囲の広い順に並べると、ルールやポリシーのワイルドカードが書きやすくなります。トピックはスラッシュ7個（8階層）までに収めてください。ルールエンジンやBasic Ingestの制約があります。

1. メッセージ設計とコスト
   課金は5KB単位のメッセージ数です。1秒ごとに数百バイトを送るより、エッジ（Greengrass）で数秒〜数十秒分をまとめて送るほうがコストを抑えられます。1メッセージの上限は128KBです。ルールに直接流すだけのデータは、トピック名の先頭に $aws/rules/{ルール名}/ を付けるBasic Ingestを使えば、メッセージング料金がかかりません。

2. QoSと再送
   テレメトリは通常QoS 1（少なくとも1回）を使います。QoS 2には非対応です。重複して届く可能性があるので、ペイロードにタイムスタンプとシーケンス番号を入れ、下流で重複を除去できるようにします。新規開発ならMQTT 5を使うと、メッセージ有効期限やユーザープロパティが使えて便利です。

3. ルールエンジン
   SQLでフィルタや変換をしてから、Firehose・Timestream・Lambdaに振り分けます。エラーアクション（失敗したメッセージをS3やSQSへ退避）を必ず設定してください。設定しないと、下流の障害時にデータが黙って消えます。

4. デバイス状態とコマンド

現在の状態や設定値の同期：Device Shadow（デバイスがオフラインでも、希望状態を保持して再接続時に反映）
ファームウェア更新や一括操作：Jobs
単発の即時コマンド：上記のcmdトピックで要求と応答をやり取り

1. クォータと接続の集中
   停電復旧後などに全台が一斉に再接続すると、接続レート上限に当たります。デバイス側の再接続処理にランダムな待ち時間（ジッター付きの指数バックオフ）を入れておきます。大規模な場合は、事前にService Quotasの引き上げを申請します。

2. 監視
   IoT Coreのログ（CloudWatch Logs）を有効にし、ライフサイクルイベント（$aws/events/presence/...）で接続と切断を記録します。これだけで「どのデバイスがオフラインか」を把握できます。セキュリティ監視はフェーズ3でDevice Defenderを入れれば十分ですが、監査機能（証明書の共有や過剰な権限の検出）は早めに入れてもコストはわずかです。

フェーズ1で特に外せないのは、1〜3（証明書・ポリシー・トピック命名）とルールのエラーアクションです。ここは出荷済みデバイスに影響するため、後からの修正コストが最も大きくなります。

Greengrassは「エッジ側の小さなクラウド」です。ハードウェア選定とオフライン時のデータ保持を最初に決めておくのがポイントです。

1. ランタイムとハードウェアの選定
   Greengrass v2のnucleus（Java版）は、メモリ・ストレージに余裕のある産業用PCやゲートウェイ向けです。目安はメモリ数百MB以上です。リソースが限られる機器なら、C実装で軽量なnucleus liteを検討します。対応機能に差があるので、使いたいコンポーネント（Stream Managerなど）が動くかを先に確認してください。ML推論までやるなら、フェーズ4を見越してGPUやNPU付きの機種を選んでおくと、後でハードを入れ替えずに済みます。

2. コンポーネント設計
   処理は「コンポーネント」（レシピ＋成果物）単位でデプロイします。

収集（センサー/PLC読み取り）・加工（集計・フィルタ）・送信を別コンポーネントに分けると、一部だけ更新できます
バージョン番号を厳密に管理し、成果物はS3に置きます
依存ライブラリの多い処理はDockerコンテナで動かすと環境差異を避けられます

1. オフライン動作とバッファリング
   ここがGreengrassを使う最大の理由です。Stream Managerを使うと、回線断の間はローカルディスクにデータを溜め、復旧後にKinesis・S3・SiteWiseなどへ自動で送ります。設計時に決めるべきことは2つです。

何時間分の断に耐えるか → 必要なディスク容量
容量が尽きたら古いデータを捨てるか、新しいデータを捨てるか

1. エッジでの前処理（データ削減）
   生データをすべて送らず、エッジで集約します。

1秒値を1分の平均・最大・最小にまとめて送る
閾値を超えたときだけ生データを送る
正常時は間引き、異常時は全量送信

IoT Coreのメッセージ料金とS3・Timestreamのコストに直結します。

1. 配下デバイスの接続
   センサーなどの小型機器をクラウドに直結させず、Greengrassを中継させる構成も取れます。Client Device AuthとローカルMQTTブローカーのコンポーネントを使い、配下デバイスはLAN内でGreengrassにつなぎます。証明書を持てない古い機器や、Modbus・OPC-UAの機器は、プロトコル変換用のコンポーネントで吸収します。

2. セキュリティ

秘密鍵はTPM/HSMに格納する（PKCS#11プロバイダー対応）。ファイルで置くと機器の盗難時に抜かれます
コンポーネントはroot以外の専用ユーザーで実行する
コンポーネントがAWSにアクセスする権限（Token Exchange Role）は最小限にする。全コアデバイスで共有されるロールなので、広すぎる権限は危険です

1. デプロイと運用
   デプロイは個別のデバイスではなくThingグループ単位で行います。「検証用グループ → 一部拠点 → 全拠点」と段階的に展開すれば、不具合の影響を限定できます。デプロイ失敗時の自動ロールバックも設定しておきます。

2. 監視
   Log Managerコンポーネントでログを CloudWatch Logs に転送し、システムの状態はテレメトリ（CPU・メモリ・ディスク）で監視します。特にディスク残量は、Stream Managerのバッファとログで埋まりやすいため要注意です。

3. ML推論（フェーズ4に向けて）
   モデルはSageMakerなどで学習し、推論はGreengrassのコンポーネントとして配布します。モデルの更新もコンポーネントのバージョンアップとして扱えます。なお、以前使われていたSageMaker Edge Managerはすでに提供終了しているため、古い資料の構成を参考にする場合は注意してください。

フェーズ1で外せないのは、**1（ハード選定）・3（バッファ容量）・6（鍵の保護）**です。現場に設置した後では変えにくい部分なので、PoCの段階で実機を使い、回線断のテスト（ケーブルを抜いて数時間放置→復旧後にデータが欠けずに届くか）までやっておくことをおすすめします。

S3データレイクの設計ポイント
S3データレイクの設計ポイントは、IoTデータの特性（小さいレコードが大量・継続的に届く）を前提に、次の観点で整理します。

1. 取り込み経路：直接書かずにFirehoseを挟む
   IoT CoreのルールからS3に1メッセージずつ書くと、数KBの小さなファイルが大量にできます。これがAthenaの遅延とコスト増の最大の原因です。IoT Core → Amazon Data Firehose → S3 の経路にすれば、Firehoseがバッファリング（例：128MBまたは5分ごと）でまとめて書き込み、Parquet形式への変換もその場で行えます。

2. ゾーン分割

Raw：受信したJSONをそのまま保存（再処理の元データ）
Processed：Parquet化、型の整備、不正値の除去
Curated：集計済み・分析用（日次集計、デバイス別KPIなど）

Rawを残しておけば、変換ロジックを後で変えても作り直せます。

1. パーティション設計
   year=2026/month=10/day=07/hour=09/ のように時刻でパーティションを切るのが基本です。Athenaのクエリはほぼ必ず期間で絞るので、読むデータ量が大きく減ります。デバイスIDをパーティションキーにするのは避けてください。数万台あるとパーティションが細かくなりすぎます。デバイス別に絞りたい場合はParquet内の列で対応するか、工場・拠点などの粗い単位を使います。

2. ファイル形式と圧縮
   分析層はParquet＋Snappy（またはZSTD）が定番です。列指向なので、必要な列だけ読めます。JSONに比べてスキャン量が1/10以下になることも珍しくありません。1ファイルの目安は128MB〜1GBです。

3. カタログ管理
   Glue Data Catalogでテーブルを定義します。時刻パーティションにはPartition Projectionを設定すると、パーティション追加（CrawlerやMSCK REPAIR）の運用が不要になります。更新・削除やスキーマ変更が多い場合は、**S3 Tables（Apache Iceberg）**も選択肢です。小ファイルの自動コンパクションまでマネージドで任せられます。

4. ライフサイクルとコスト

Raw：90日後にGlacier Instant Retrieval、1年後にDeep Archiveへ移行
アクセスパターンが読めないデータはIntelligent-Tieringを使う
Athenaのワークグループでクエリあたりのスキャン上限を設定し、うっかりフルスキャンを防ぐ