第2章の全体像
第4版の第2章は、クラウドとエッジ、IoTゲートウェイ、データ駆動型システムという見出しで構成されています。以下はテキスト本文ではなく、見出しと一次資料から当サイトが論点を整理したものです。
- 集
収集
現場のデータを集める
- 蓄
蓄積
集めたデータをためる
- 析
分析
データから判断の材料を得る
- 返
フィードバック
分析の結果で現実の動きを変える
変わった現実を再び収集
集めたデータで現実の動きを変える循環として理解すると、第3章のデータ活用とつながる。
| 見出し（章立て） | 論点 | 関連する章 |
|---|---|---|
| クラウドとエッジ | 処理の配置、IaaS/PaaS/SaaS、フォグ、MEC | 第1章・第4章 |
| IoTゲートウェイ | 集約・プロトコル変換・前処理・デバイス管理 | 第4章・第7章 |
| データ駆動型システム | 収集→蓄積→分析→フィードバックの循環、デジタルツイン | 第3章 |
押さえる用語と対比
| 用語 | 要点 | 対比する相手 |
|---|---|---|
| IaaS | 仮想マシンやストレージなど基盤を借りる。OSから上は利用者の管理 | PaaS（実行環境まで事業者が管理） |
| SaaS | アプリケーションをそのまま使う | IaaS（自由度は高いが管理も多い） |
| フォグコンピューティング | クラウドとデバイスの間の層で分散処理（NIST SP 500-325） | エッジ（デバイスや現場のすぐそば） |
| MEC | 通信事業者網の端に計算資源を置く（ETSIの標準化） | パブリッククラウド |
| ストリーム処理 | 届いた順に逐次処理し、即応する | バッチ処理（まとめて後で処理） |
| デジタルツイン | 現実の対象を仮想空間に写し、状態を同期させる | 単なるシミュレーション（同期がない） |
エッジ・フォグ・クラウドの詳しい比較は エッジ・フォグ・クラウドの違い、ゲートウェイは IoTゲートウェイ、処理方式は ストリーム処理とバッチ処理 で扱っています。
第2章を読むときの視点
第2章の問題は、「ある要件のとき、処理をどこに置くのが適切か」という形にすると理解を確かめやすくなります。当サイトの問題でも、遅延・通信量・プライバシー・計算量の4つの観点を組み合わせた設問を多く作っています。
遅延が厳しい制御はエッジ、大量データを横断する学習はクラウド、その中間で複数の現場をまとめる処理はフォグやMEC、という基本の配置を押さえたうえで、例外にも目を向けてください。例えば、学習はクラウドで行い、学習済みモデルをエッジに配って推論だけを現場で行う構成は、両者の長所を組み合わせた典型例です。
クラウドのサービスモデルでは、利用者と事業者の管理範囲の境目が問われやすいと当サイトは見ています。IaaSならOSから上、PaaSならアプリとデータ、SaaSなら設定と利用、というように、利用者の責任範囲を層ごとに書き出すと混乱しません。この境目はセキュリティの責任分担（第7章）ともつながります。
データ駆動型システムは、集めたデータで現実の動きを変える循環として理解すると、第3章のデータ活用とも自然につながります。
- クラウド大量データを横断する学習集約
- フォグ・MECその中間で、複数の現場をまとめる処理中間
- エッジ遅延が厳しい制御。学習済みモデルでの推論現場
学習はクラウド、推論はエッジという組み合わせが典型例。
当サイトの整理です。
間違えやすい点
| よくある誤解 | 正しい理解 |
|---|---|
| PaaSではOSのパッチを利用者があてる | PaaSではOSや実行環境は事業者の管理範囲 |
| フォグとエッジは全く同じ言葉 | 重なる部分はあるが、フォグはクラウドとの間の階層を強調する |
| MECはクラウド事業者のサービス名 | ETSIで標準化が進んだ、通信網の端で計算する枠組み |
| デジタルツインは3D表示のこと | 要点は現実との継続的なデータ同期で、見た目は本質ではない |
具体例で確かめる：管理範囲と処理の置き場所
サービスモデルは、NIST SP 800-145 の定義をもとに「利用者が管理するもの」を層ごとに並べると一目で違いが分かります（○が利用者の管理範囲。当サイトの整理）。
データ量 ＝ 台数 × 1秒あたりの測定回数 × 1回あたりのバイト数
- 11,000台 × 1,000回/秒 × 2バイト ＝ 2,000,000バイト/秒（約2MB/秒）
- 2ビットに直すと 約2MB × 8 ＝ 約16Mbps
- 3エッジで1台あたり数十バイトの特徴量だけを送れば、数十分の一以下に減る
生データは約16Mbps
全部をクラウドへ送る前に、エッジで特徴量に絞ることを考える。
数値は当サイトが作った説明用の例です。
| 管理するもの | オンプレミス | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| アプリケーションの設定・データ | ○ | ○ | ○ | ○ |
| アプリケーション本体 | ○ | ○ | ○ | ― |
| ミドルウェア・実行環境 | ○ | ○ | ― | ― |
| OS | ○ | ○ | ― | ― |
| サーバ・ストレージ・ネットワーク | ○ | ― | ― | ― |
処理の置き場所の例として、1,000台の振動センサが毎秒1,000回測定する工場を考えます。1回あたり2バイトなら、全体で毎秒約2MB（約16Mbps）の生データになります。これを全てクラウドへ送る代わりに、エッジで1秒ごとの最大値・平均値などの特徴量（例えば1台あたり数十バイト）だけを送れば、通信量は数十分の一以下に減ります。一方、異常の判定基準を作り直す学習には長期間の生データが要るため、学習はクラウド、推論はエッジという分担が合理的です。
よくあるミスは、SaaSでは利用者に責任が一切ないと考えることです。アカウントの管理や、どのデータを入れるかの判断は、どのモデルでも利用者側に残ります。
他の章とのつながり
第2章の内容は、第4章の通信方式と第7章のセキュリティの両方と深く関わります。処理をエッジに寄せれば通信量は減りますが、現場に置く機器が増えるぶん、物理的な盗難や改ざんへの対策が必要になります。逆にクラウドに寄せれば管理は集約できますが、通信の遅延と費用が増えます。
このように、配置の選択には必ず長所と短所がセットで伴います。当サイトでは、エッジ・フォグ・クラウドそれぞれについて「得意なこと」「苦手なこと」「代表的な使い方」の3行をまとめておく方法をすすめています。
ゲートウェイについても同様で、プロトコル変換、データの集約と間引き、一時保存、デバイスの管理と更新の中継といった役割を挙げ、それぞれが通信とセキュリティのどちらに効くかを考えると理解が深まります。
学習の順番と時間の目安
以下は 当サイトの目安 です。
- IaaS・PaaS・SaaSの管理範囲を表にして覚える（1時間）
- エッジ・フォグ・クラウド・MECを「遅延・規模・設置場所」で比べる（1時間）
- ゲートウェイの役割を4つ挙げられるようにする（30分）
- データ駆動型の循環とデジタルツインを例で説明する（30分）
- 問題演習と誤答の見直し（1〜2時間）
腕試しは IoT中級の無料お試し で、本番に近い形式の問題を解けます。
確認問題（オリジナル）
問1 NIST の定義によるPaaSの説明として、最も適切なものはどれか。
ア：利用者は完成したアプリを使い、設定以外はほぼ何も管理しない／イ：利用者は仮想マシンを借り、OSやミドルウェアも自分で管理する／ウ：利用者は開発したアプリを配置し、基盤のOSやサーバは管理しない／エ：利用者は自社の建物に機器を置き、全ての層を自分で管理する
正解：ウ。イはIaaS、アはSaaS、エはオンプレミスの説明です。
問2 工場の設備データから異常を数ミリ秒で検知し、機械を止めたい。処理の配置として最も適切なものはどれか。
ア：全データを遠隔のクラウドへ送り、クラウドで判定させる／イ：設備の近くのエッジで判定し、結果だけをクラウドへ送る／ウ：データを一日分まとめて保存し、夜間にバッチで判定させる／エ：判定は人が画面を見て行い、システムは表示だけを担う
正解：イ。アは往復の遅延が大きく、ウとエは即時性の要件を満たせません。
問3 デジタルツインの説明として、最も適切なものはどれか。
ア：クラウドのデータを二か所に複製して保管するバックアップ／イ：現実とは切り離して、仮定の条件だけで動かす計算モデル／ウ：同じ機器を二台並べ、故障に備えて二重化した構成のこと／エ：現実の対象の状態をデータで継続的に同期させた仮想モデル
正解：エ。イは同期がない一般的なシミュレーション、ウは冗長化、アはバックアップの説明です。