LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

エッジコンピューティングは、データを生む端末の近くでデータを処理し、クラウドへは必要な結果だけを送る構成の考え方です。工場の設備の異常をその場で検知して止める、店舗のカメラ映像を現場で集計する、利用者に近い拠点でWebの応答を返す、といった場面で使われています。

本記事では、システムの設計や運用を担当するエンジニアと、IT投資を判断する担当者に向けて、どこを「エッジ」と呼ぶのか、クラウドとどう使い分けるのか、拠点が増えたときにつまずきやすい更新と監視の点を、NISTやETSIの文書と各クラウドの公式ドキュメントで確かめながら整理します。

エッジコンピューティングとは

NIST SP 500-325（2018年3月）は、エッジコンピューティングを、端末とその利用者を含むネットワークの層とし、センサーや計測機器のようなネットワークにつながる機器の上で計算する能力を提供するものと説明しています。同じ文書は、端末と集中型のクラウドの間に置く層を「フォグコンピューティング」と呼び、その計算を受け持つ機器の例としてゲートウェイ、スイッチ、ルーター、サーバー、仮想マシンを挙げています。^*1

もっとも、NIST自身が、文書を作った時点ではこれらの概念の区別に合意が無かったと書いています。実務では、端末から現場のゲートウェイ、通信事業者の設備までをまとめて「エッジ」と呼ぶことが多くあります。ETSIは、通信網の側に計算の場所を置く方式をMEC（Multi-access Edge Computing）として標準化しており、ネットワークのエッジでクラウドの計算能力とIT環境をアプリケーションの開発者に提供するもので、超低遅延と広い帯域が特徴だと説明しています。対象は移動通信網に限らず、固定回線や無線LANも含みます。^*2

総務省の令和7年版情報通信白書は、MECを、クラウドとデバイスの間でやりとりするデータを、通信ネットワークのエッジにあるエッジサーバーで処理する技術と説明し、主なユースケースとして映像伝送や映像分析、遠隔操作・遠隔操縦、エネルギーのリアルタイム制御、XR、自動運転を挙げています。^*3 令和8年版では、民間の調査を基に、日本のエッジコンピューティングの市場規模を2025年に前年比14.0％増の127億ドルと推計し、2031年には261億ドルまで拡大すると予測しています。^*4

「エッジ」と呼ばれる4つの場所

「エッジ」がどこを指すかは、話す人や製品によって変わります。クラウドのリージョンより手前を、端末に近い順に次の4つの場所に分けて考えると、比べやすくなります。

現場に置く形にも幅があります。AWS IoT GreengrassとAzure IoT Edgeは、コンテナなどにまとめたアプリケーションを現場の機器へ配って動かし、監視するための仕組みです。これらに対し、AWS OutpostsはAWSの基盤とサービスを利用者の施設まで広げるフルマネージドのサービスで、42Uのラックや1U・2Uのサーバーの形で置かれ、AWSが運用・監視・管理します。^*5 Azure Stack Edge Pro GPUも、Microsoftが送り届けるクラウド管理型の機器で、仮想マシンやコンテナを動かせます。^*6

都市の近くの拠点では、Cloudflare Workersが、数百の拠点に分散した数千台の機械の上で利用者のコードを動かします。^*7 AWS Local Zonesは、計算やストレージなど一部のAWSのリソースを大都市や産業の中心の近くに置き、利用者へ低い遅延で応答するための仕組みです。^*8 拠点にコンテンツを置いて配るキャッシュの設計は「CDNキャッシュ戦略の設計を外注」で扱っています。

クラウドとの使い分け

クラウドが得意なのは、データを1か所に集め、大きな計算資源で処理し、まとめて管理することです。エッジに処理を移すのは、それでは困る事情があるときです。判断の材料は次の4つに分けられます。

• 遅延：設備の停止や遠隔操作のように、往復にかかる時間が処理の結果を左右する
• 帯域：カメラ映像や高頻度の計測値のように、すべて送ると回線の容量と通信の費用が足りなくなる
• 社外へ送れないデータ：個人のデータや工場の機密を、現場や特定の地域に置いておく必要がある
• 切断への備え：回線が切れても、現場の制御や記録を止められない

公式ドキュメントにも、この4つがそのまま現れます。Azure IoT Edgeの説明は、生産ラインで起きた緊急事態にできるだけ早く応えるために異常検知をエッジで動かす例と、テラバイト単位の生データを送らずに現場で整えて集計し、結果だけをクラウドへ送って帯域の費用を抑える例を挙げています。^*9 AWS Local Zonesは、医療や金融などの分野でデータの所在に関する要件を満たす用途を挙げ、Azure Stack Edge Pro GPUは、データを送る前に個人のデータを取り除く前処理を用途に挙げています。

反対に、どれにも当たらないなら、拠点ごとに機器を置いて保守する手間をかけてまでエッジにする理由は弱くなります。エッジには判断や前処理だけを置き、データの蓄積や分析、学習はクラウドで行う分け方が、多くの構成の出発点になります。IoTの全体の構成と費用は「IoTシステム開発を外注する費用と進め方」で扱っています。

具体例：距離から往復の時間を見積もる

遅延がどれだけ距離に左右されるかは、光ファイバーの中を光が進む速さから見積もれます。真空中の光速は、CODATAの値で秒速299,792,458メートルと定義されています。^*10 ここでは光ファイバーの屈折率をおよそ1.47と仮定し、ファイバーの中の光は真空中の1.47分の1の速さで進むとして計算します。

C = 299_792_458        # 真空中の光速（m/s）
N = 1.47               # 光ファイバーの屈折率（仮定）
v_km_per_ms = C / N / 1000 / 1000  # ファイバー中を1ミリ秒で進む距離（km）

print(f"1ミリ秒で進む距離: {v_km_per_ms:.0f} km")
for km in [1, 50, 500, 1000, 9000]:
    rtt_ms = 2 * km / v_km_per_ms  # 往復の伝搬時間
    print(f"{km:>5} km 先との往復: {rtt_ms:7.3f} ms")

# 出力
# 1ミリ秒で進む距離: 204 km
#     1 km 先との往復:   0.010 ms
#    50 km 先との往復:   0.490 ms
#   500 km 先との往復:   4.903 ms
#  1000 km 先との往復:   9.807 ms
#  9000 km 先との往復:  88.261 ms

1ミリ秒で進むのはおよそ204kmで、1,000km先との往復には、伝わるだけで約9.8ミリ秒かかります。この値は、ケーブルが2点を直線で結んでいるとした場合の最小の値です。実際の経路は直線より長く、ルーターやスイッチでの処理、待ち行列、サーバーの処理時間が加わるため、測った往復時間はこれより長くなります。

光より速くは届かないという下限が分かると、遠いリージョンでは要件を満たせない処理を早めに見分けられます。往復を数ミリ秒に収めたい制御なら、数百km先のリージョンでは伝わる時間だけで目標の大半を使ってしまいます。逆に、往復に数十ミリ秒かかっても困らない処理であれば、遅延はエッジに移す理由になりにくく、帯域やデータの置き場所の事情で判断することになります。

具体例：通信が切れても動かす

通信が切れても動くことを求めるなら、クラウドへ送るデータを現場でいったん溜めておく仕組みが要ります。Azure IoT Edgeは、一度IoT Hubと同期した後は、機器とその配下の機器が、通信が途切れたり無かったりしても動き続けられるとしています。切れている間、上りのメッセージは現場に保存され、つながり直すと保存した順に届けられます。ただし、保存できる量はメッセージの有効期限（TTL）の設定とディスクの空きで決まります。^*9

次のコードは、この「溜めておき、つながったら送る」動きを最小の形で書いたものです。保存の上限を3件、有効期限を5秒とし、1秒目から4秒目まで通信が切れ、9秒目につながり直す場面を流しています。

from collections import deque

class Uplink:
    def __init__(self, cap, ttl):
        self.q, self.cap, self.ttl = deque(), cap, ttl
    def send(self, now, msg, online):
        self.q.append((now, msg))
        while len(self.q) > self.cap:   # 保存できる件数を超えたら古い順に捨てる
            print("破棄(容量):", self.q.popleft()[1])
        while online and self.q:
            t, m = self.q.popleft()
            print("破棄(期限):" if now - t > self.ttl else "送信:", m)

up = Uplink(cap=3, ttl=5)
for now, online in [(0, True), (1, False), (2, False), (3, False), (4, False), (9, True)]:
    up.send(now, f"t={now}", online)

# 出力
# 送信: t=0
# 破棄(容量): t=1
# 破棄(容量): t=2
# 破棄(期限): t=3
# 送信: t=4
# 送信: t=9

切れている間に4件目が入った時点で、最も古い1秒目のデータが捨てられています。つながり直した9秒目にも、上限を超えた2秒目と、有効期限の切れた3秒目が捨てられました。どのデータなら捨ててよいか、捨てたことをどう記録するかは先に決めておきます。上限と有効期限は、想定する切断の長さとデータの発生量から逆算して決めます。

拠点が増えたときの更新と監視

つまずきやすいのは、拠点が数十、数百と増えた後のソフトウェアの更新です。AWS IoT Greengrassの配布（デプロイ）は継続的で、部品や設定を変えると、対象のすべての機器へ自動で送られます。誤った設定もそのまま全台へ届くため、配る速さと止める条件を先に決めておきます。次は、AWSのドキュメントにある配布の設定例から、その部分を抜き出したものです。^*11

{
  "deploymentPolicies": {
    "failureHandlingPolicy": "ROLLBACK"
  },
  "iotJobConfiguration": {
    "abortConfig": {
      "criteriaList": [{"action": "CANCEL", "failureType": "ALL",
        "minNumberOfExecutedThings": 100, "thresholdPercentage": 5}]
    },
    "jobExecutionsRolloutConfig": {
      "exponentialRate": {"baseRatePerMinute": 5, "incrementFactor": 2,
        "rateIncreaseCriteria": {"numberOfSucceededThings": 5}},
      "maximumPerMinute": 50
    }
  }
}

failureHandlingPolicyをROLLBACKにすると、機器での更新に失敗したときにその機器が元の設定へ戻ります。この例では、最初は1分あたり5台に配り、5台が成功するごとに速さを2倍にし、上限を1分あたり50台としています。100台以上に配った時点で失敗が5％に達すると、配布を取り消します。Cloudflare Workersにも、新しい版へ流す要求の割合を少しずつ増やし、問題があれば前の版へ戻せる段階的な配布の仕組みがあります。

監視にも落とし穴があります。Azure IoT Edgeの説明では、機器がオフラインの間は配布の状態をポータルへ報告できないため、インターネットにつながっていない機器の状態がポータル上で200 OKのまま残ることがあるとされています。^*9 管理画面の表示だけに頼らず、機器から最後にデータが届いた時刻を記録し、一定の時間届かない拠点を知らせる監視を別に置いておきます。Cloudflare Workersは、コードを動かす単位が入れ替わることがあるため、書き換わる状態をグローバルな変数に置かないよう勧めています。

機器とランタイムの寿命も、拠点の数だけ管理が要ります。AWSはAWS IoT Greengrass Version 1のサポートを2026年10月7日に終えるとしています。^*11 AWS Outpostsは、リージョンとの間のサービスリンクに、コンピュートラック1台あたり500Mbps以上の冗長な接続と、往復175ミリ秒以内の遅延を求めています。^*5 回線の品質とランタイムの更新の予定は、拠点ごとの台帳で管理します。

外部に委託するときに確認しておきたい点

エッジの構成を外部に委託するときは、まず4つの判断の材料のどれのためにエッジへ処理を置くのかを、要件の文書に書いてもらいます。往復の時間の目標、送るデータの量、現場に残すデータ、切断を許す長さが数字で決まっていれば、場所の選び方と機器の大きさを後から見直せます。

そのうえで、拠点が増えたときの配布の手順（段階的に配る速さと取り消す条件）、機器から最後にデータが届いた時刻の監視、切断中に溜めるデータの上限と捨てる規則、ランタイムのサポート終了への備えが、設計書と試験の項目に入っているかを確かめます。学習済みのモデルを現場の機器で動かす場合の軽量化や機器の選び方は「エッジAI・エッジ推論の実装を外注で進める」で扱っています。

まとめ：エッジコンピューティングで確かめておきたい3つの点

エッジコンピューティングで確かめておきたい点は3つです。第一に、どこを「エッジ」と呼ぶかは文書や製品で違い、端末・現場のゲートウェイやサーバー・通信事業者の局舎・都市の近くの拠点のどこに処理を置くのかを決めること。第二に、遅延・帯域・社外へ送れないデータ・切断への備えのどれのためにエッジへ移すのかを数字で示し、遅延は光の速さから下限を見積もること。第三に、拠点が増えた後の段階的な配布と取り消しの条件、最後にデータが届いた時刻の監視、切断中に溜めるデータの上限を、設計の最初に決めておくことです。

よくある質問

出典

1. *1　参考：NIST「SP 500-325 Fog Computing Conceptual Model」（2018年3月）（https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.500-325.pdf）。出典：1.1節の概念の区別に合意が無いとの記述、2.1節のフォグコンピューティングの定義、2.2節のフォグノードの例、付録AのEdge computingの定義とフォグとの違いを参照（2026年10月確認）
2. *2　参考：ETSI「Multi-access Edge Computing (MEC)」（https://www.etsi.org/technical-groups/mec/）。出典：MECの概要（ネットワークのエッジでのクラウドの計算能力の提供、超低遅延と広い帯域、固定回線や無線LANも対象）を参照（2026年10月確認）
3. *3　参考：総務省「令和7年版 情報通信白書」第Ⅱ部第1章第8節3 エッジコンピューティング（https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r07/html/nd218300.html）。出典：MECの説明と主なユースケースを参照（2026年10月確認）
4. *4　参考：総務省「令和8年版 情報通信白書」第Ⅱ部第1章第8節3 エッジコンピューティング（https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r08/html/nd218300.html）。出典：日本のエッジコンピューティングの市場規模の推計と予測（株式会社マーケットリサーチセンターの調査を基に作成）を参照（2026年10月確認）
5. *5　参考：Amazon Web Services「What is AWS Outposts?」「Connectivity through service link」（https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html）。出典：Outpostsの概要、42Uのラックと1U・2Uのサーバー、サービスリンクの帯域と往復遅延の要件（service-links.html）を参照（2026年10月確認）
6. *6　参考：Microsoft「What is Azure Stack Edge Pro with GPU」（https://learn.microsoft.com/en-us/azure/databox-online/azure-stack-edge-gpu-overview）。出典：クラウド管理型の機器であること、仮想マシンとコンテナの実行、送る前に個人のデータを取り除く前処理の用途を参照（2026年10月確認）
7. *7　参考：Cloudflare「How Workers works」「Gradual deployments」（https://developers.cloudflare.com/workers/reference/how-workers-works/）。出典：Workersが数百の拠点に分散した数千台の機械で動くこと、isolateが入れ替わるため書き換わる状態をグローバルに置かないとの勧め、段階的な配布（gradual-deployments）を参照（2026年10月確認）
8. *8　参考：Amazon Web Services「What is AWS Local Zones?」（https://docs.aws.amazon.com/local-zones/latest/ug/what-is-aws-local-zones.html）。出典：Local Zonesの概要と、低遅延・データの所在の要件を満たす用途を参照（2026年10月確認）
9. *9　参考：Microsoft「What is Azure IoT Edge」「Understand extended offline capabilities for IoT Edge devices」（https://learn.microsoft.com/en-us/azure/iot-edge/about-iot-edge）。出典：IoT Edgeの概要と生産ラインの異常検知・帯域の費用の例、1.5 LTSのサポート終了日、オフライン時のメッセージの保存とTTL・ディスク容量の制限、ポータルの状態が200 OKのまま残ること（offline-capabilities）を参照（2026年10月確認）
10. *10　参考：NIST「CODATA Value: speed of light in vacuum」（https://physics.nist.gov/cgi-bin/cuu/Value?c）。出典：真空中の光速 299 792 458 m/s（定義値）を参照（2026年10月確認）
11. *11　参考：Amazon Web Services「What is AWS IoT Greengrass?」「How AWS IoT Greengrass works」「Create deployments」（https://docs.aws.amazon.com/greengrass/v2/developerguide/what-is-iot-greengrass.html）。出典：Greengrassの概要とVersion 1のサポート終了日、配布が継続的で対象の全機器へ送られること（how-it-works.html）、failureHandlingPolicyとiotJobConfigurationの設定例（create-deployments.html）を参照（2026年10月確認）

Tweet