IoT (Internet of Things)

この用語をシェア

概要：IoT（Internet of Things）とは何か

IoT（Internet of Things、日本語表記「モノのインターネット」）とは、従来インターネットに接続されていなかった家電・産業機械・車両・センサーなどの物理的な「モノ」に通信機能を組み込み、ネットワーク経由でデータを収集・送信し、遠隔から監視・制御できるようにする仕組みの総称です。一言でまとめると「モノ自体がデータの発信源となり、ネットワークを介して人やシステムと情報をやり取りする社会基盤」です。

IoTという概念は1999年に英国の技術者ケビン・アシュトン氏がRFID（ICタグ）を用いたサプライチェーン管理の文脈で提唱したとされます。その後、スマートフォンの普及、通信モジュールの低価格化、クラウドサービスの成熟を経て、家庭向けのスマートホームから工場・農業・医療・都市インフラまで幅広い分野で実用化が進みました。産業分野に特化したIoTは「IIoT（Industrial IoT、産業用IoT）」と呼ばれ、一般消費者向けIoTとは要求される可用性やセキュリティ水準が異なるため区別されることがあります。

IoTは単一の技術ではなく、センサー・通信プロトコル・クラウドやエッジのデータ処理基盤・アプリケーションを組み合わせたシステムアーキテクチャです。本ページはエッジコンピューティングのカテゴリに属するため、特に「IoTが生み出す大量のデータをどこで（クラウドかエッジか）処理するか」という設計判断に重点を置いて解説します。

仕組み・アーキテクチャの詳細解説

IoTシステムは一般に「デバイス層」「通信層」「データ処理層（クラウド／エッジ）」「アプリケーション層」の4層で整理されます。以下、それぞれの層で行われる技術選定を具体的に見ていきます。

デバイス層：センサーとアクチュエーター

温度・湿度・照度・振動・加速度・GPS位置情報などを取得するセンサーと、モーターやバルブ、リレーなど物理的に対象を動かすアクチュエーターがデバイス層を構成します。多くのデバイスはARM Cortex-M系のマイクロコントローラや、Raspberry Pi・Arduinoのようなシングルボードコンピュータ上で動作し、消費電力・コスト・演算性能のトレードオフの中で機種選定が行われます。バッテリー駆動の屋外センサーでは、数年単位の電池寿命を実現するために、常時通電せず定期的にスリープと起動を繰り返す「間欠動作」を前提とした設計が定石です。

通信層：用途に応じたプロトコルの使い分け

IoTの通信規格は、データ量・到達距離・消費電力の要件によって使い分けられます。近距離・省電力用途ではBluetooth Low Energy（BLE）やZigbeeが、家庭内の高速通信にはWi-Fiが使われます。広域かつ低消費電力を狙う場合は「LPWA（Low Power Wide Area）」と呼ばれる規格群が採用され、代表例としてLoRaWAN、NB-IoT、Sigfoxがあります。LPWAは電池駆動のまま数年単位の運用を狙える反面、通信できるデータ量が小さく、頻繁に大容量データを送る用途には不向きという制約があります。近年は5G RedCap（Reduced Capability）のように、5Gの特長を維持しつつモジュールコストと消費電力を抑えた規格の採用も進んでおり、フル規格の5Gモジュールを使うほどではないが、LPWAでは帯域が足りない中間的な用途を埋める選択肢として注目されています。

メッセージングプロトコルとしては、軽量なPublish/Subscribe型の「MQTT」が最も広く使われ、通信リソースが極めて限られる組み込み機器向けには「CoAP（Constrained Application Protocol）」が使われます。以下は、工場設備の振動センサーがMQTTでデータを送信する際の典型的なトピック構成とペイロード例です。

Topic: factory/lineA/press-machine-03/vibration
Payload:
{
  "device_id": "press-machine-03",
  "timestamp": "2026-07-07T09:12:33Z",
  "vibration_mm_s": 4.8,
  "temperature_c": 42.1,
  "status": "normal"
}

データ処理層：クラウドとエッジの使い分け基準

IoTシステム設計で最も判断が分かれるのが「データをクラウドで処理するか、エッジ（現場に近い場所）で処理するか」という論点です。判断基準は主に(1)レイテンシ（許容できる遅延）、(2)帯域幅（回線容量と通信コスト）、(3)コスト（デバイス側の演算コストとクラウド利用料のバランス）の3点です。

実務では、全データをクラウドに送るのではなく、エッジ側で異常検知や前処理（フィルタリング・集計・圧縮）を行い、要約されたデータや異常イベントのみをクラウドに送る「ハイブリッド構成」が定石です。これにより通信コストを抑えつつ、クラウド側では複数拠点のデータを横断した学習・分析に集中できます。

アプリケーション層：可視化・自動化・デジタルツイン

収集・処理されたデータは、ダッシュボードによる可視化、閾値超過時のアラート通知、機械学習モデルによる異常検知・予知保全、さらには物理設備をソフトウェア上に再現する「デジタルツイン」との連携に使われます。AWS IoT Core、Azure IoT Hubなどのクラウドサービスが、デバイス管理からデータ処理・可視化までを一気通貫で提供しています。なお、Google Cloud IoT Coreは2023年8月に提供終了となっており、Googleは現在、パートナー企業のIoTソフトウェアと組み合わせる形にシフトしています。プラットフォーム選定時はサービスのライフサイクル（提供継続性）も確認すべき項目の一つです。

具体的なユースケース

IoTの活用は家庭向けから重工業まで幅広く、業界ごとに要求されるレイテンシや信頼性の水準が大きく異なります。代表的な事例を整理します。

製造業の予知保全では、モーターやポンプの振動波形をエッジ側でリアルタイム解析し、正常範囲からの逸脱を検知した時点でアラートを上げる構成が一般的です。全振動波形をクラウドに送信すると回線負荷とストレージコストが大きくなるため、エッジ側で特徴量抽出（周波数解析など）を行い、要約データのみを送る設計が定石とされています。自動運転では障害物検知やブレーキ判断をミリ秒単位で行う必要があるため、クラウド往復の通信遅延は許容されず、車載コンピュータ（エッジ）での即時処理が前提となります。

スマートシティ分野では、街灯にLED化とIoTによる調光制御を組み合わせ、人通りに応じて明るさを自動調整することで、一律点灯の場合と比べて消費電力を抑えられる取り組みが各地で進んでいます。交通分野では、交差点の車両感知センサーと信号制御を連携させ、交通量に応じて信号サイクルを動的に変える「適応制御」の実証も行われています。小売業では、棚センサーで欠品を自動検知し発注を早めることで機会損失を減らす取り組みが広がっていますが、店舗数が多いほど映像・タグデータの通信量が課題になりやすく、店舗内エッジでの一次処理が現実的な選択肢になります。

メリットと導入における注意点

メリット

• これまで人手や定期点検に頼っていた状態把握を、センサーによる連続監視に置き換えられ、異常の早期発見につながる。月次・週次といった点検周期の間に発生した異常も見逃しにくくなる。
• 現場に人を派遣せずに遠隔から監視・制御でき、点検コストや移動時間を削減できる。特に遠隔地や危険区域にある設備では、この効果が大きい。
• 蓄積したセンサーデータを分析することで、故障予兆の検知（予知保全）や業務プロセスの改善につなげられる。壊れてから直す「事後保全」から、壊れる前に手を打つ「予知保全」への転換が可能になる。
• エッジ処理と組み合わせることで、通信コストを抑えながらリアルタイム性の高い自動制御を実現できる。全データをクラウドに送る場合に比べ、回線帯域とクラウド利用料の両方を圧縮できる。

デメリット・注意点

• デバイス台数が数百〜数万台規模になると、ファームウェア更新や証明書管理などの運用負荷が急増する（デバイス管理の複雑化）。台数が少ないうちは手動運用でも回るが、規模拡大時に管理基盤への投資が後手に回りやすい。
• 通信が途絶する現場（地下・山間部・電波干渉のある工場内）では、データ欠損やリアルタイム性の低下が起こりうる。通信断時にデバイス側でデータを一時保持し、復旧後に再送するバッファリング設計が必要になる。
• 安価なデバイスほどセキュリティ機能が簡素な場合があり、初期パスワードの使い回しやファームウェア未更新が侵入経路になりやすい。過去には初期パスワード未変更のIoT機器が大規模なボットネットに悪用された事例が知られており、調達段階でのセキュリティ要件確認が欠かせない。
• 複数ベンダーの機器・プロトコルが混在すると相互運用性の確保が課題になる（Matter/Threadなどの標準化が進行中ではあるが、既存の古い機器は対応していないことも多い）
• センサーが個人の位置情報やバイタルデータを扱う場合、個人情報保護法などの法規制対応が必要になる。取得するデータの範囲と保存期間を必要最小限に絞る設計判断が求められる。

混同されやすい用語・類似技術との違い

IoTとM2M（Machine to Machine）の違い

M2Mは機械同士が人を介さずに直接通信する仕組みを指し、専用回線や1対1の通信が中心でした。IoTはM2Mの概念を包含しつつ、インターネットやクラウドを前提とし、多数のデバイスが標準化されたプロトコルとAPIを通じてクラウド上のアプリケーションと連携する、より開かれたアーキテクチャである点が異なります。

IoTとIIoT（産業用IoT）の違い

IIoTはIoTの中でも製造業・エネルギー・物流など産業分野に特化した領域を指す言葉です。一般消費者向けIoT（スマート家電など）と比べ、IIoTでは可用性（24時間365日の連続稼働）、耐環境性（防塵・防水・高温対応）、既存の産業用制御システム（SCADA、PLC）との連携が強く求められる点が特徴です。

IoTとエッジコンピューティングの違い

IoTは「モノがネットワークにつながりデータをやり取りする仕組み」そのものを指す概念であるのに対し、エッジコンピューティングは「そのデータをどこで処理するか」という計算アーキテクチャの選択肢の一つです。IoTがデータの発生源だとすれば、エッジコンピューティングはそのデータをクラウドに送る前に現場近くで処理する手段であり、両者は「対象」と「処理方式」という別のレイヤーの概念です。IoTの普及によってデータ量が爆発的に増えたことが、エッジコンピューティングが必要とされる直接の背景になっています。

IoTとデジタルツインの違い

デジタルツインは、実世界の設備や工程をソフトウェア上に忠実に再現し、シミュレーションによって挙動を予測・検証する技術です。IoTはそのデジタルツインに現実のセンサーデータを継続的に流し込む「データ供給源」の役割を担うことが多く、両者は競合する技術ではなく組み合わせて使われる関係にあります。IoTだけではデータを収集・可視化するにとどまりますが、デジタルツインと組み合わせることで、実際に設備を止めずに条件を変えた場合の挙動をシミュレーションする、といった一段進んだ活用が可能になります。

実務導入のポイント

• 小規模PoCから始める：本番導入前に少数のデバイスで通信環境・データ品質・運用フローを検証し、想定外の電波干渉やデータ欠損を洗い出す。現場の壁材や設置場所によって電波の届き方は大きく変わるため、机上検討だけでなく実機での電波測定を必ず行うことが望ましい。
• OTA（Over-The-Air）更新を前提に設計する：現地に人を派遣せずファームウェアを更新できる仕組みがないと、脆弱性対応や機能追加のたびに運用コストが跳ね上がる。デバイス数が数百台を超えた時点で、手動更新は現実的でなくなることが多い。
• セキュリティ・バイ・デザイン：デバイス出荷時の初期パスワード変更強制、通信のTLS暗号化、証明書ベースのデバイス認証を最初から組み込む。後からセキュリティ機能を追加するのは既存デバイスの入れ替えが必要になり、コストと手間が大きくなりやすい。
• データのライフサイクルを設計する：生データ・要約データ・アラートイベントのどれをどこにどれだけ保存するかを決めておかないと、ストレージコストが想定外に膨らむ。全センサーの生データを永続保存するのではなく、直近データのみ生データで保持し、それ以前は集計値のみ残すといった段階的な保存方針が現実的である。
• 通信規格は要件から逆算する：省電力・広域が必要ならLPWA、リアルタイム性が必要ならWi-Fiや5Gというように、業務要件を先に固めてから通信方式を選ぶ。複数の候補技術を並行して机上比較するだけでなく、実際の設置環境で通信テストを行い、電波干渉やパケットロス率を確認したうえで最終決定するのが定石である。
• ベンダーロックインを避ける：特定クラウドベンダー固有のプロトコルやSDKに深く依存すると、将来的なプラットフォーム移行が困難になる。MQTTのような標準プロトコルを軸に設計し、クラウド固有機能への依存度を意識的に管理しておくと、後々の選択肢を狭めずに済む。

よくある質問（FAQ）

この用語についてもっと詳しく

IoT (Internet of Things)に関するご質問や、システム導入のご相談など、お気軽にお問い合わせください。