IoT機器がクラウドにつながらないときの確認手順：機器・通信・認証を分けて調べる

センサーの値が管理画面に出ない。昨日まで動いていた機器がオフラインになった。そんなとき、「インターネットにはつながるから機器の故障だ」と決めてしまうと、別の場所にある問題を見落とします。

IoTでは、機器の通信、クラウドへの認証、データの送信、受信後の処理がそれぞれ別の段階です。どこまで進んだかを記録すると、機器メーカー、ネットワーク担当、クラウド担当へ具体的に調査を引き継げます。

この記事は、企業の設備担当者・IT担当者・導入を支援するIT企業向けです。IPネットワークを使う機器やゲートウェイが、MQTT／HTTPSなどでクラウドへ接続する構成を想定します。AWS IoT CoreとAzure IoT Hubの公式資料を例にしますが、必要なポート、認証方式、確認画面は製品ごとに異なります。

生産設備や安全に関わる機器では、再起動や試験信号の送信が運転へ影響する場合があります。最初は表示・設定値・既存ログの確認にとどめ、制御指令の送信や配線変更は設備の管理者と調整してください。

1. 「機器がオフライン」と「データが見えない」を分ける

• 1台だけか、同じ拠点の全台か、別拠点にも発生しているか。
• 機器が直接クラウドへ接続するのか、ゲートウェイを経由するのか。
• 接続自体が失敗するのか、接続済みだがデータが届かないのか。
• 最後に正常だった時刻と、直前の停電、回線・機器設定・証明書・クラウド設定の変更。

ゲートウェイ配下の機器がまとめて見えないなら、個々のセンサーだけでなくゲートウェイと上位回線も確認対象です。1台だけでも、その機器固有の認証情報や接続条件が関係するため、故障とは断定できません。

管理画面の「接続中」という表示も、現在のデータ到着と同じ意味とは限りません。たとえばAzure IoT HubのconnectionStateには更新条件と遅延があります。機器側の接続ログ、最後の送信記録、クラウド側の受信時刻を分けて確認してください。Microsoft：デバイス接続状態の監視

2. 現地では、電源・回線・機器設定の現在値を見る

機器の電源、警告表示、有線LANのリンク、Wi-Fiや携帯回線の接続状態を、対象製品の手順で確認します。表示色だけで故障箇所を判断せず、型番と表示内容を残してください。

• IPアドレス、ネットワーク設定、既定のゲートウェイ、DNS参照先。
• 実際に使用している有線LAN／Wi-Fi／携帯回線。
• 接続先のホスト名、プロトコル、ポート、機器ID。
• ファームウェアや通信ソフトのバージョン。

工場内LANと事務所LAN、来客用Wi-Fiなどは接続条件が違うことがあります。同じ建物のPCでWebサイトを開けても、IoT機器からの通信が許可されているとは限りません。

この段階では、工場出荷状態への初期化、適当な固定IPへの変更、携帯回線の設定変更を試さないでください。元の設定や登録情報が失われると、別の復旧作業が必要になることがあります。

3. DNSと時刻は、通信と認証をつなぐ確認点

接続先の名前が正しいか

クラウド担当者が管理している正式なエンドポイントと、機器に設定されたホスト名を照合します。本番と検証用、アカウントやリージョン、端末接続用と管理用を取り違えていないか確認してください。AWS IoT Coreでも、正しいデバイスエンドポイントの確認が診断の入口です。AWS：接続問題の診断

Windows 11の保守PCを同じ経路・接続条件で試験に使える場合は、次のようにDNSを確認できます。PCからの補助試験であり、機器自身のDNSや通信の成功を証明するものではありません。

Resolve-DnsName -Name device-endpoint.example.com -DnsOnly

名前は説明用です。管理担当者が確認した実際のホスト名に置き換えます。返らない場合は入力、DNS参照先、名前照会の経路を確認します。返った場合も正しい接続先か構成情報と照合します。Microsoft：Resolve-DnsName

機器の時計が合っているか

現在時刻、タイムゾーン、同期元、最後に同期できた時刻を機器側で確認します。停電や長期間の停止後に時計が戻っていないかも確認してください。

TLSでは証明書の有効期間を確認するため、機器の時計がずれていると接続に影響することがあります。AWSも機器の時刻同期を案内しています。AWS：IoT Coreのセキュリティ上の推奨事項

記録の時刻が端末側とクラウド側で違う場合は、時差と時計のずれを区別します。生産記録などへの影響を確認せず時刻を飛ばすのではなく、同期方式と同期先への到達性を管理者が調べます。

4. TCP接続に成功しても、TLSや機器認証はまだ別

必要なポートは機器の設定とクラウドの仕様から確認します。Azure IoT HubではMQTTは8883、MQTT over WebSocketsは443ですが、すべての製品がこの組み合わせを使うわけではありません。Microsoft：IoT Hubのプロトコルとポート

通常の直接TCP接続で8883を使うと確認できた構成なら、保守PCから次の補助試験ができます。

Test-NetConnection -ComputerName device-endpoint.example.com -Port 8883 -InformationLevel Detailed

• TcpTestSucceeded : True：そのPCから表示された接続先へTCP接続が成立しています。TLS、機器認証、データ送信の成功までは分かりません。
• TcpTestSucceeded : False：名前解決、経路、送信制御、待受状態などが確認対象です。ファイアウォールだけが原因とは断定できません。

プロキシ経由や、PCと機器でVLAN・通信許可が違う構成では、実際の機器経路を再現していない場合があります。Microsoft：Test-NetConnection

「8883が通らないので443に変える」だけでは解決しません。AWS IoT Coreでは443もプロトコル・認証方式・ALPNの組み合わせがあります。対応していない機器のポート番号だけを変更しないでください。AWS：デバイス通信プロトコル

5. TLS・認証エラーなら、証明書の役割を分ける

• クラウドの身元を機器が確認するための情報：接続先名、信頼するCA、対応TLSバージョンなど。
• 機器の身元をクラウドが確認するための情報：端末ID、クライアント証明書、トークンなど、製品が採用する方式。

AWS IoT CoreのX.509認証では、端末の証明書が登録され、有効な状態で、期限内であることなどを確認します。別の正常機器の秘密鍵をコピーせず、対象機器に割り当てられた登録を照合します。AWS：X.509クライアント証明書

Azure IoT Hubでは、サーバー証明書を検証するための信頼情報と、デバイス認証の条件を確認します。証明書更新後だけの問題では、信頼ストアや古い証明書への固定設定も調査対象です。Microsoft：IoT HubのTLS対応

証明書検証を無効化したり、秘密鍵・接続文字列・トークンをオンラインの診断サイトへ貼ったりしないでください。認証情報の再発行や端末の再登録は別の変更作業として、稼働中接続や復旧手順への影響を確認してから進めます。

6. 接続できても届かない場合は、クラウド側の処理をたどる

接続成功のログがあるなら、機器の送信記録、クラウドの受信記録、その後のルーティング・保存・画面表示を順に確認します。管理画面に値が出ないという理由だけで、回線を調べ直し続けないことが大切です。

AWS IoT Coreでは接続と送信・購読などの許可が分かれています。接続できても、目的のトピックへ送信できるとは限りません。対象機器、操作、トピックを照合し、全操作・全リソースを許可する変更で試さないでください。AWS：IoTポリシーのアクション

Azure IoT Hubでも受信後のルートや転送先の状態・エラーを調べる方法があります。送信時刻と受信・転送記録を照合します。Microsoft：メッセージルーティングの診断

切断と再接続が繰り返される場合はクライアントIDの重複も確認します。AWS IoT CoreのMQTTでは、同一クライアントIDで別クライアントが接続すると既存接続が切断されます。試験ツールに本番と同じIDを入力して試さないでください。AWS：接続許可とクライアントID

ログが未設定・保存期限切れなら、過去の原因を確定できない場合があります。ログの有効化は費用・保存先・情報管理を確認した別作業として計画します。

7. 相談時は、どこまで確認できたかを渡す

• 機器・ゲートウェイのメーカー、型番、ソフトウェアの版。
• 影響する台数・拠点と、正常に動く機器との違い。
• 最後に正常だった時刻、エラーの時刻・タイムゾーン。
• 接続経路、クラウド、プロトコルとポート。
• DNS、時刻、TCP、TLS、認証のどこまで確認できたか。
• エラーコード、最後の送信・受信時刻、直前の変更。
• 実施済みの操作、設備側の操作制限、関係する保守窓口。

認証情報そのものは載せず、ログや機器IDを渡す方法は担当者と確認します。再起動や試験データ送信が必要なら、制御・計測・請求など後続処理への影響も確認してください。

復旧後はオンライン表示だけでなく、必要なデータが所定の間隔で届き、保存・表示まで進むことを確かめます。未送信データの扱いも機器とアプリケーションの仕様に沿って確認します。

ソルブネオへご相談いただく場合も、まずは機器の種類、症状、影響範囲をお知らせください。機器側・現地ネットワーク・クラウド側の確認結果を分けておくと、関係する担当者と調査を進めやすくなります。相談する