IoT活用を検討する企業では、センサーや設備、業務端末のデータを安全に収集し、業務改善や遠隔監視につなげたい一方で、自社でMQTTブローカーを構築・運用すべきか、それともクラウドのマネージドサービスを使うべきかで悩むケースが少なくありません。総務省の情報通信白書でも、IoT・AI等のシステムやサービスを導入している企業は12.4％、導入予定を含めると約2割にのぼるとされています（※1）。

特に本番運用では認証・監視・コスト・障害対応まで含めた設計が必要です。本記事ではAWS IoT Coreの役割や構成、料金、運用上の注意点を整理し、自社IoT基盤への適合性やPoCから本番化までの進め方を解説します。

※参照1:総務省｜令和3年版 情報通信白書｜企業におけるIoT・AI等のシステム・サービスの導入・利用状況

まず結論｜AWS IoT Coreはデバイス接続・認証・AWS連携を担うIoT基盤

AWS IoT Coreは、IoTデバイスとクラウドを安全に接続し、受信したデータを各種AWSサービスへ連携するマネージドサービスです。単なるMQTTブローカーにとどまらず、デバイス認証、メッセージング、データのルーティング、状態管理、遠隔運用までを一体的に提供する点が特徴です。

そのため、IoT基盤の中核として機能し、スケーラブルかつセキュアなデバイス接続を実現できます。AWS公式でも、IoTはデバイスを他のデバイスやクラウドサービスに接続するサービス群として位置付けられています。

AWS IoT Coreが向いているケース

AWS IoT Coreは、以下のような要件を持つ企業・プロジェクトに適しています。

• デバイス数の増加を見据え、接続基盤の構築・運用を自社で抱えたくない場合
• MQTTを用いた双方向通信により、リアルタイムなデータ連携や制御を行いたい場合
• X.509証明書とポリシーによる厳密な認証・アクセス制御を実現したい場合
• AWS Lambda、Amazon S3、Amazon DynamoDBなどと連携し、データ処理や蓄積を迅速に構築したい場合
• Device ShadowやAWS IoT Jobsなどの標準機能を活用し、デバイス管理や遠隔更新まで一元化したい場合

自社MQTTブローカーや他サービスを検討すべきケース

要するに、AWS IoT Coreは「安全なデバイス接続とAWS連携を短期間で実現したい企業」に向いています。一方で、接続要件が限定的な場合や、独自要件が非常に強い場合は、自前構築や他クラウドとの比較が欠かせません。

• 要件が単純で、データ送信以外の機能がほとんど不要
• クラウド接続より、閉域網やオンプレ環境の制約が強い
• MQTTブローカー周辺の認証・監視・更新機能をすでに自社で持っている
• AWS依存を抑え、他クラウドや独自基盤を優先したい
• 通信量や接続数が大きく、料金最適化を厳密に行いたい

AWS IoT Coreとは何か｜IoT基盤における役割と適用範囲

AWS IoT Coreとは、インターネットに接続されたデバイスが、クラウドアプリケーションや他のデバイスと安全にやり取りするためのマネージドサービスです。対応プロトコルには、MQTT、MQTT over WebSocket、HTTPSなどがあり、デバイスとアプリケーション間の通信を支える中心機能を提供します。

情シス・IT企画が押さえるべき適用領域とユースケース

AWS IoT Coreの適用領域は、単なるデータ収集にとどまりません。実務では、以下のようなユースケースで検討されます。

• センサーからのテレメトリ収集
• 設備の稼働監視と異常検知
• 現場機器の遠隔制御
• 業務端末や製品の状態管理
• OTA更新や証明書更新の遠隔運用

総務省の調査でも、企業がIoT・AI等の導入で目指す主な目的は「効率化・業務改善」が81.3％と最も高く、次いで「顧客サービスの向上」「事業の全体最適化」とされています。IoT基盤の選定は、単に技術要素を見るのではなく、こうした業務目的との接続で判断することが重要です（※2）。

※参照2:総務省｜令和3年版 情報通信白書｜企業におけるIoT・AI等のシステム・サービスの導入・利用状況

AWS IoT Coreでできること・別途設計が必要なこと

AWS IoT Coreでできることは明確です。

• デバイス接続の受け口を持つ
• 認証と認可を行う
• メッセージをルーティングする
• デバイス状態を保持する
• ジョブ配信で遠隔更新を管理する

一方で、次の領域は別途設計が必要です。

• 業務アプリケーションの画面や操作性
• ダッシュボードや分析基盤
• 製造工程での秘密鍵保護
• 保守員の現地作業フロー
• 24時間365日の運用体制

つまり、AWS IoT CoreはIoT基盤の中核ですが、業務システム全体を単独で完成させるサービスではありません。基盤と業務側の責任範囲を分けて考えることが、導入判断の第一歩です。

AWS IoT Coreの構成イメージ

AWS IoT Coreの基本構成は、「デバイス接続」「認証」「メッセージ受信」「ルールによる振り分け」「保存・処理・監視」の流れで整理できます。

多数のデバイスからのデータを処理し、AWS内の各サービスや他デバイスへ柔軟にルーティングできる点が特徴です。

デバイスからクラウド連携までの全体像

• デバイスがMQTT、HTTP、WebSocketで接続
• AWS IoT Coreが証明書認証とポリシー判定を実施
• メッセージブローカーがPub/Subで配信
• IoT Rulesがデータを各AWSサービスへ連携
• CloudWatchなどで監視・可観測性を確保

データを用途ごとに振り分ける仕組み

• Rules Engineは、受信したメッセージを条件に応じて各サービスへ振り分ける機能です。
• DynamoDBへの書き込み、S3への保存、Lambdaの実行、Kinesisへの送信、CloudWatchへの記録などを柔軟に組み合わせられます。
• 主な活用例は以下の通りです。
• 温度データをS3へ長期保存する
• 最新状態をDynamoDBへ保持する
• 閾値超過時のみLambdaを起動する
• 高頻度データをKinesisに流す
• 通知系イベントだけを別経路へ分離する

デバイスの状態管理と遠隔操作の仕組み

運用面で重要なのが、デバイスの状態管理と遠隔操作を実現する機能です。

Device Shadowは、デバイスがオフラインでもクラウド側で状態を保持できる仕組みで、desired・reported・deltaを使って状態差分を管理します。

またAWS IoT Jobsを使うと、ソフトウェア更新や再起動、証明書ローテーションなどの処理を複数デバイスへ一括配布できます。OTA更新を想定する場合は、初期段階から設計に含めることが重要です。

AWS IoT Coreのメリット・デメリット

AWS IoT Coreのメリットは、スケーラビリティ、運用負荷軽減、セキュリティ設計のしやすさにあります。多数のデバイスとメッセージを扱えるだけでなく、X.509証明書による認証、メッセージルーティング、状態管理、遠隔ジョブ配信までを一貫して利用できます。

メリット（スケーラビリティ・運用負荷軽減・セキュリティ）

• マネージドサービスのため、MQTTブローカーの運用負荷を抑えやすい
• 証明書認証とポリシーで安全性を高めやすい
• Device Shadow、IoT Rules、AWS IoT Jobsなど周辺機能が豊富
• AWSサービスとの連携が早く、PoCから本番への移行を進めやすい

Experienceの観点では、AWS公開事例も参考になります。NestléはAWS IoT Coreを活用したIoTプラットフォームで、97か国・280万台超のデバイスを接続し、累計21億件のデータポイントを取り込みながら、開発期間を「数か月から数週間」へ短縮したと公表しています（※3）。

※参照3：Nestlé Efficiently Scales to 2.8 Million Connected Devices with AWS IoT

デメリット（コスト構造・設計難易度・ベンダーロックイン）

• AWS IoT Core料金は従量課金であり、台数増加や高頻度通信で膨らみやすい
• トピック設計、QoS、証明書更新、アクセス制御など設計論点が多い
• AWSサービス連携が深いほど、他基盤への移行は容易ではない

そのため、導入時は「短期的に使えるか」ではなく、「3年後も運用できるか」という視点で判断する必要があります。

AWS IoT Coreの代替案と比較

IoT基盤の選定では、AWS IoT Coreだけでなく、自前MQTTブローカーや他クラウドとの比較が欠かせません。重要なのは、単純な機能比較ではなく、認証、運用、拡張、コストをまとめて見ることです。

自前MQTTブローカー（Mosquitto/EMQX等）との違い

自前MQTTブローカーは自由度が高い一方、次の領域を自社で担う必要があります。

• 認証基盤の構築
• 冗長化と障害対応
• 監視と可観測性
• 証明書更新や秘密鍵管理
• OTA更新や状態管理の追加実装

これに対し、AWS IoT Coreは、接続・認証・ルーティング・状態管理をマネージドにまとめやすいのが特徴です。

Azure IoT Hub・他クラウドとの違い

Azure IoT Hubも、マネージドなIoTハブとして比較対象になります。Azure IoT HubはDevice Twinやデバイス管理機能を持ち、数百万台規模の接続を想定しています。一方で、料金はIoT Hubユニット数と日次メッセージ上限を軸に考える必要があり、必要な機能がStandardティアに限定されるケースがあります。

マネージドサービスと自前構築の判断軸

判断軸は、以下の3点で整理すると分かりやすくなります。

• 初期構築コストだけでなく、3年総保有コストで比較する
• 証明書認証や権限管理を誰が運用するか明確にする
• Device ShadowやOTA更新まで必要かを先に整理する

比較軸	AWS IoT Core	自前MQTTブローカー	Azure IoT Hub
接続基盤	マネージド	自社構築	マネージド
認証	X.509証明書、ポリシー	実装次第	SAS / X.509
状態管理	Device Shadow	別実装が必要	Device Twin
運用更新	AWS IoT Jobs	別実装が必要	ジョブ機能あり
コストの見方	接続課金・メッセージ課金	インフラ固定費中心	ユニット課金＋メッセージ量

デバイス接続とMQTT通信の設計ポイント

AWS IoT Coreは、MQTT、HTTP、WebSocketに対応しています。設計では、プロトコルを選ぶ前に、双方向性、常時接続性、クライアント実装制約を整理することが重要です。

対応プロトコル（MQTT/HTTP/WebSocket）と選定基準

使い分けの目安は次の通りです。

• MQTT：軽量で双方向のPub/Subが必要な場合
• HTTP：単方向送信が中心で実装を簡素化したい場合
• WebSocket：ブラウザ系クライアントを扱いたい場合

Thing / Thing Type / Thing GroupとデバイスID設計

実運用では、デバイスを単に接続するだけでなく、管理単位をどう切るかが重要です。

Thing：個々のデバイス実体
Thing Type：機種やモデルの分類
Thing Group：運用単位や拠点単位のまとまり

この設計が曖昧だと、証明書管理、ジョブ配信、障害切り分けが複雑になります。

トピック設計（命名規則・階層・マルチテナント）

トピック設計は、AWS IoT Coreの成否を左右する重要ポイントです。AWS公式でも、トピックは階層化でき、ワイルドカードによる購読が可能ですが、予約トピックや設計の一貫性に注意が必要とされています。

設計時は、次の観点を押さえるべきです。

• 何のデータか、誰のデータかが分かる命名にする
• テナント、拠点、機種、デバイスIDの階層を統一する
• 制御系トピックとテレメトリ系トピックを分ける
• 将来の拡張を見越して固定しすぎない
• 個人情報をトピック名に含めない

QoS・セッション維持・メッセージ信頼性の考え方

AWS IoT CoreはMQTT v3.1.1とv5.0をサポートし、QoSは0と1に対応します。QoS 2には対応していません。永続セッションを使うと、切断中のQoS 1メッセージやサブスクリプション情報を保持できます。

設計上の注意点は以下の通りです。

• QoS 1は重複受信を前提に実装する
• 順序保証に依存しすぎず、タイムスタンプやバージョンで補う
• client IDの衝突を防ぐ
• 再接続時のメッセージ流量も考慮する

Pub/Sub権限制御と不要データを抑える設計

MQTTの強みはPub/Subですが、権限制御を粗くすると情報漏えいリスクが高まります。Topicごと、Thingごとにpublish / subscribe権限を細かく分け、不要なデータ購読を避けることが基本です。必要に応じてRules Engineで必要な項目だけを再配信する設計も有効です。

証明書認証とセキュリティ設計

IoT基盤では、認証・認可の設計が後回しになりやすい一方、実際には最も早く固めるべき領域です。AWS IoT Coreでは、X.509証明書によるデバイス認証と、AWS IoTポリシーによる認可が基本になります。

X.509証明書の発行・登録・ローテーション

証明書運用の原則はシンプルです。

• 1デバイス1証明書を基本にする
• 有効期限を管理する
• ローテーション手順を決める
• 盗難・漏えい時に失効できる状態にしておく

また、デバイス側の時刻がずれていると、証明書の有効期限判定に失敗するため、時刻同期も重要です。

AWS IoTポリシーと最小権限の設計

AWS IoTポリシーでは、接続、Publish、Subscribe、Receiveなどの権限を制御できます。最小権限の原則に従い、デバイスごとに必要な操作だけを許可する設計が基本です。

具体的には、以下を意識します。

• 接続できるclient IDを限定する
• Publish先のトピックを限定する
• Subscribe先のトピックを限定する
• 共通ポリシーを乱用せず、管理単位を整理する

JITP / JITR / Fleet Provisioningの使い分け

大量配備を前提とする場合、手動登録では限界があります。そのため、初回接続時の自動登録方式を選ぶことが重要です。

• JITR：証明書登録の自動化を中心に考える場合
• JITP：証明書登録に加え、Thingやポリシー作成まで自動化したい場合
• Fleet Provisioning：大量デバイスへ初回接続時に証明書や秘密鍵を安全に払い出したい場合

AWS公式では、Fleet Provisioningにより、初回接続時にAWS側で証明書と秘密鍵を安全に生成・配布できると説明されています。また、JITPではCA証明書とテンプレートを用い、接続時にThing作成やポリシー適用まで自動化できます。

証明書失効・盗難時の封じ込め手順

実運用では、証明書を「配る」ことより、「止める」ことの方が重要です。失効時対応としては、次の手順を事前に決めておくべきです。

• 該当証明書の無効化
• 関連Thingやポリシーの影響範囲確認
• 不正接続ログの確認
• 代替証明書の再払い出し
• 現地交換や再プロビジョニングの実施

AWS IoT Device Defenderによるセキュリティ監視

AWS IoT Device Defenderは、設定監査と異常検知を行うマネージドなセキュリティ監視サービスです。過剰な権限を持つポリシーや、通常と異なる接続パターン、異常な通信量などを検知できます。

本番運用では、次の用途で有効です。

• ポリシー設定の棚卸し
• 想定外の接続先や通信傾向の検知
• アラートのCloudWatch / SNS連携
• セキュリティ監査の継続運用

AWSサービス連携で実現する構成例

AWS IoT Coreの価値は、接続だけでなく、受けたデータをすぐに業務処理へつなげられる点にあります。Rules Engineを使うと、受信データをフィルタリング、変換しながら各種AWSサービスへ連携できます。

IoT Rulesによるデータ加工・蓄積・リアルタイム分析の実現

代表的な構成は次の通りです。

• Lambda：メッセージ加工、閾値判定、通知処理
• Amazon S3：生データやログの長期保存
• Amazon DynamoDB：最新ステータス保持
• Amazon Kinesis Data Streams：高頻度データのリアルタイム処理

Device Shadowでオフライン時の状態管理を行う

デバイスが常時オンラインとは限らないIoTでは、状態管理が重要です。Device Shadowを使うと、クラウドアプリはデバイスが切断中でもdesired stateを更新でき、再接続時にデバイスが差分を受け取れます。

AWS IoT JobsでOTA更新・遠隔操作を管理する

AWS IoT Jobsは、ファームウェア更新、アプリ配布、再起動、証明書更新、保守コマンド実行などを一括管理できます。PoC段階では後回しにされがちですが、本番運用を見据えるなら早い段階から考慮すべき機能です。

運用・監視・料金で注意すべきポイント

AWS IoT Coreを本番利用するうえで、見落とされやすいのが監視と料金設計です。PoCでは問題なく見えても、台数や通信量が増えると、接続課金、メッセージ課金、ルール実行、シャドウ更新などが積み上がります。

CloudWatch・IoTログ・メトリクスの監視設計

監視では、次の観点を最初から定義する必要があります。

• 接続失敗や認証失敗を検知できるか
• ルール実行失敗を追跡できるか
• 想定以上の通信量増加を検知できるか
• セキュリティ異常を可視化できるか
• 運用担当へエスカレーションできるか

IoT Rulesのトラブルシュートでも、CloudWatch Logsの有効化が推奨されています。

AWS IoT Core料金を左右する要素（接続課金・メッセージ課金・Rules）

AWS IoT Core料金で特に見落としやすい要素は以下です。

• 接続課金：接続時間が長いほど増える
• メッセージ課金：送受信回数とサイズで増える
• Device Shadow：更新回数が多いほど増える
• Rules関連：転送先や評価回数で影響する
• 周辺サービス：S3、Lambda、DynamoDB側の料金も別途発生する

AWS公式の料金ページでは、接続数、メッセージサイズ、シャドウ利用などを前提にした試算例が公開されています。検討時は、台数だけでなく「1台あたり何分つながるか」「1日何回送るか」「1メッセージ何KBか」で見積もることが重要です。

運用体制と役割分担（情シス・開発・現地保守）

本番運用では、技術よりも責任分担が問題になることがあります。最低限、以下の役割を整理しておくべきです。

• 情シス：基盤監視、権限管理、インシデント統制
• 開発：アプリ改修、ルール設計、ジョブ定義
• 現地保守：機器交換、再登録、証明書入れ替え
• セキュリティ担当：監査、失効対応、異常通信確認

PoCから本番化までの進め方

PoCの目的は、「つながること」の確認ではありません。本番化に向けて、技術要件、運用要件、費用要件を早期に洗い出すことです。

PoCで検証すべき項目（接続安定性・遅延・運用負荷）

PoCでは、次の項目を優先的に確認します。

• 接続安定性：切断・再接続時の挙動
• 遅延：制御要件を満たせるか
• 通信量：想定負荷でコストがどう変わるか
• 証明書運用：登録・更新・失効が回るか
• 監視：障害や異常を運用側で検知できるか

本番移行のチェックリスト（セキュリティ・監視・SLA）

項目	PoCで確認すること	本番前に固めること
認証	証明書で安定接続できるか	ローテーション・失効手順
通信	MQTT / HTTP / WebSocketの適合性	Topic標準、QoS設計
状態管理	Device Shadowが必要か	desired / reported運用ルール
更新	Jobsで配信可能か	OTA更新手順、ロールバック
監視	異常を見つけられるか	CloudWatch、通知、当番体制
料金	1台あたり単価	年間予算、増加時シミュレーション

社内説明・稟議で整理すべき比較軸

稟議では、技術機能だけでは通りません。次の比較軸を用意すると説明しやすくなります。

• 自前MQTTブローカーと比べた運用負荷
• AWS IoT Coreを使うことで削減できる作業
• 証明書認証や最小権限によるリスク低減
• PoC後に本番へ展開できる現実性
• 3年総保有コストでの優位性

IoT基盤設計でよくある失敗と外注判断

IoT基盤は、最初のPoCが成功しても、本番で失敗することがあります。よくある原因は、接続以外の設計を後回しにすることです。

内製で失敗しやすいポイント（証明書管理・設計複雑化）

代表的な失敗例は以下の通りです。

• Topic設計を場当たりで決めてしまう
• 証明書更新や失効手順が決まっていない
• Device ShadowやJobsの役割分担が曖昧
• 開発・運用・現地保守の責任範囲が不明確
• コスト試算をPoC時点で行っていない

外部支援を検討すべきタイミング

• PoCはできたが、本番設計に不安がある
• 量産配備や複数拠点展開を予定している
• 証明書認証やセキュリティ監査に自信がない
• AWS連携を前提に、最短で構成を固めたい

PoC・本番化を成功させるための体制づくり

IoT基盤は、単独の技術導入ではなく、継続運用を伴う仕組みです。したがって、PoCの段階から「誰が運用するのか」「異常時に誰が止めるのか」「証明書を誰が更新するのか」を決める必要があります。基盤選定と同じくらい、体制設計が成功要因になります。

AWS IoT Coreでよくある質問

Q:AWS IoT CoreとMQTTブローカーの違いは何ですか？

A:MQTTブローカーは主にメッセージ中継の仕組みです。一方でAWS IoT Coreは、MQTTに加えて、証明書認証、ポリシー制御、Rules Engine、Device Shadow、Jobsなどを備えたIoT基盤です。

Q:AWS IoT Core料金は何で決まりますか？

A:主に接続課金、メッセージ課金、Device Shadow利用、Rules利用などで決まります。台数だけでなく、接続時間、通信頻度、メッセージサイズが大きく影響するため、PoC段階から見積もりが必要です。

Q:証明書はどのように管理・更新すべきですか？

A:1台ごとに一意のX.509証明書を割り当て、有効期限、ローテーション、失効対応を標準化するのが基本です。大量配備ではJITPやFleet Provisioningの活用も有効です。

まとめ

AWS IoT Coreは、デバイス接続、MQTT通信、証明書認証、AWS連携、状態管理、遠隔運用をまとめて担えるIoT基盤です。導入判断では、「つながるかどうか」ではなく、「トピック設計、最小権限、監視、運用体制、AWS IoT Core料金まで含めて本番で回るか」を見ることが重要です。

PoCでは、接続安定性、遅延、証明書運用、監視、費用を検証し、本番移行に必要な論点を先に洗い出すべきです。自社要件に合う構成を見極めるには、IoT基盤とAWS活用の両方に強いパートナーであるテクノプロへぜひご相談ください。