--- title: "エッジAIとクラウドAIの違い｜遅延・費用・オフライン耐性で決める使い分け" url: "https://www.issoh.co.jp/column/details/17615/" published: 2026-09-15 updated: 2026-09-15 categories: ["AI"] publisher: "株式会社一創" --- # エッジAIとクラウドAIの違い｜遅延・費用・オフライン耐性で決める使い分け エッジAIとクラウドAIの違いは、AIの推論をどこで走らせるかにあります。ただ、この説明だけで構成が決まった案件はほとんどありません。現場で決め手になるのは、端末を何台置くか、1台あたり何回推論させるか、通信が切れている間どこまで業務を止めずにいられるか、という3つの条件です。この記事では、両者を遅延・通信量・機密・運用の4軸で並べたうえで、AWSとMicrosoftが公表している単価と仕様をもとに、費用が入れ替わる分岐点とハイブリッド構成の線引きを示します。エッジ化を見送ってクラウドAIのままにしたほうが安く収まる条件まで扱います。 ## まとめ：エッジAIとクラウドAIの違いが効くのは端末台数と推論頻度が増えた後 先に結論を置きます。端末が1台か2台で、通信が安定していて、1秒程度の遅れを業務が許容できるなら、クラウドAIのままで足ります。エッジAIの利点が費用にまで及ぶのは、台数が増えて通信量が積み上がってからです。 費用構造が逆向きだからです。クラウドAI側は接続とメッセージと推論が従量課金で、端末台数にほぼ比例して月額が伸びます。AWS公式のIoT Greengrass料金ページ（2026年9月15日時点）では、AWS IoT Coreのメッセージ課金が100万件あたり1 USD、接続課金が1,000,000接続分あたり0.08 USDと示されています。対してエッジAI側は端末の購入と設置作業が先に立ち、月額は端末管理の分だけです。同じページのGreengrass Coreデバイスは米国東部バージニア北部リージョンで1台あたり月額0.16 USDで、台数が増えても単価は動きません。 オフラインで動くという触れ込みにも、仕様上の上限があります。Microsoft公式のAzure IoT Edgeドキュメントでは、クラウドへ送れなかったメッセージの保持時間（time to live）の既定値は7,200秒、つまり2時間です。設定で伸ばせますが、既定のまま置けば「2時間までなら切れていい」という設計になります。止まってよい時間を先に決めてから方式を選ぶ順序になります。 実務での答えは、どちらか一方ではなくハイブリッドです。線の引き方は単純で、1件の判断に必要な材料がその端末の中で閉じるならエッジ、複数拠点や過去データを突き合わせないと答えが出ないならクラウドへ送ります。 ## エッジAIとクラウドAIを分ける推論の実行場所とデータが動く経路の違い 両者の設計差は、カメラやセンサーが取ったデータがどこまで動くかに現れます。動かす距離が長いほど、遅延も通信費も機密の露出も増えます。 ### 端末内で推論を完結させるエッジAIと、サーバーへ送って推論するクラウドAIの処理経路 クラウドAIは、端末が取得した画像や信号をそのままクラウドへ送り、サーバー側のモデルが推論し、結果を端末へ返します。往復の通信が1回の判断ごとに発生するため、判断の速さはネットワークの状態に左右される仕組みです。カメラ映像のように1件あたりのデータが重いほど、通信量がそのまま費用になります。 エッジAIは、推論そのものを端末やその近くの機器で走らせます。外へ出るのは推論結果や集計値だけで、元の映像を送らない構成も取れます。判断はネットワークの外側で完結し、回線が切れても推論は止まりません。その代わり、載せられるモデルの規模は端末の演算性能とメモリで頭打ちになります。仕組みとモデル軽量化の詳細は[エッジAIとは？クラウドAIとの違い・仕組み・実装の判断基準](https://www.issoh.co.jp/tech/details/13390/)で扱っているため、この記事では選択の側に集中します。 拠点側にサーバーを置いて複数の端末をまとめて処理する中間の形もあります。そちらは[エッジコンピューティングとは？仕組み・クラウドとの違いから導入判断まで](https://www.issoh.co.jp/column/details/15366/)の領分です。 ### 学習はクラウド・推論はエッジという役割分担が定着した理由と変換の実際 モデルの学習と推論は、必要な計算量が二桁以上違います。学習はGPUを並べて数時間から数日回す処理で、端末側では現実的に走りません。そのため、学習はクラウド、推論はエッジ、という分担が定着しました。 分担を成立させているのが、学習済みモデルを端末向けに変換する工程です。Google公式の[LiteRTドキュメント](https://developers.google.com/edge/litert)（2026年9月15日時点）では、LiteRTはTensorFlow Liteの後継として位置づけられ、Android・iOS/macOS・Web・デスクトップ・組み込みとIoTを対応先に挙げています。NPUによる実行先はGoogle Tensor・Intel・Qualcomm・MediaTek・Samsungが示されており、端末側の推論を専用回路へ逃がす道は公式に用意済みです。変換手順と量子化の選び方は[TensorFlow Lite（LiteRT）とは](https://www.issoh.co.jp/tech/details/16870/)で詳しく書いています。 この分担がある以上、「エッジAIにするとモデルを自社で育てられなくなる」という心配は当たりません。育てるのはクラウド側で、端末へ配るのは変換後のモデルです。 ## 遅延・通信量・機密・運用の4軸で並べたエッジAIとクラウドAIの得手不得手 メリットとデメリットを同じ数だけ並べても選べません。実務で効く順に4軸へ絞り、どちらが有利かを条件付きで示します。 ### 4軸比較表：遅延と通信量はエッジ有利、モデル規模と運用はクラウド有利 次の表は、同じ処理をどちらに置いたときに何が変わるかを整理したものです。優先順位は上から下へ下がります。 | 軸 | エッジAI | クラウドAI | 判断材料 | | -------- | --------------- | -------------- | --------------- | | 遅延 | 通信を挟まず端末内で完結 | 往復の通信時間が毎回加算 | 1件の判断に許される時間 | | 通信量と通信費 | 結果だけ送れば激減 | 元データを送るぶん台数比例 | 1台あたりの送信頻度とデータ量 | | 機密データの移動 | 映像を外へ出さない構成が可能 | 送信経路と保管先の審査が必要 | 個人情報や図面を含むか | | モデル規模 | 端末の演算性能とメモリで頭打ち | 大規模モデルをそのまま利用 | 必要な精度と入力の複雑さ | | 運用と更新 | 全端末への配信と世代管理が発生 | サーバー側の差し替えで完了 | 設置台数と保守体制 | | 初期費用 | 端末購入と設置作業が先行 | ほぼ不要で従量課金から開始 | 投資回収までの許容期間 | 表の下2行、つまり運用と初期費用でクラウドAIが有利である点は見落とされがちです。エッジAIの導入が止まる原因は、性能不足より現地作業と更新配信の手間にあります。この運用負担がどの段階で表に出るのかは[エッジAIのメリット・デメリット｜低遅延と引き換えに増える運用負荷の実際](https://www.issoh.co.jp/column/details/17617/)で整理しました。 ### 「速い」「安全」を数値に置き換えるときに確かめる2つの実測値 エッジAIの説明で使われる「速い」は、2つの数値に分解できます。1つは推論そのものにかかる時間で、これは載せる端末の演算性能で決まります。NVIDIA公式のJetsonモジュール一覧（2026年9月15日時点）では、[Jetson Orin Nanoが最大67 TOPS・消費電力7Wから25W](https://developer.nvidia.com/embedded/jetson-modules)、Orin NXが最大157 TOPS、AGX Orinが最大275 TOPSという段構成です。同じ「エッジAI」でも土台の規模は4倍以上開きます。世代ごとの選定基準は[NVIDIA Jetsonとは](https://www.issoh.co.jp/tech/details/16173/)、演算回路そのものの実効性能の見方は[NPUとは](https://www.issoh.co.jp/tech/details/16171/)で整理しています。 もう1つは通信の往復時間です。こちらは推論性能をいくら上げても縮みません。クラウドAIで1件あたり200ミリ秒かかっている処理のうち、通信が150ミリ秒を占めているなら、端末側へ寄せて削れるのはその150ミリ秒ぶんです。逆に通信が20ミリ秒しか占めていないなら、エッジ化しても体感は変わりません。「安全」も同様に、外へ出るデータの種類と保管先で判断します。漠然とした安心ではなく、映像そのものを送らずに済むかどうかが分かれ目です。 ## 台数と推論頻度で逆転するエッジAIとクラウドAIの費用構造と分岐点の求め方 競合記事が触れないのがここです。どちらが安いかは固定ではなく、端末台数と推論頻度で入れ替わります。公表単価をそのまま当てはめれば、分岐点は自社の条件で計算できます。 ### クラウドAI側の費用：接続とメッセージの従量課金が台数と送信頻度に比例する AWS公式の[AWS IoT Greengrassの料金ページ](https://aws.amazon.com/jp/greengrass/pricing/)（2026年9月15日時点）に、端末をクラウドへつなぐ側の単価が示されています。AWS IoT Coreの接続課金は1,000,000接続分あたり0.08 USD、メッセージ課金は100万件あたり1 USDです。推論そのものの課金はモデルごとに別体系になるため、ここでは単価が明示されている接続とメッセージだけで比べます。 仮にカメラ100台が1秒に1回ずつ結果をクラウドへ送るとすると、月間のメッセージは100台×86,400回×30日でおよそ2億5,900万件、メッセージ課金だけで約259 USDになります。1秒に1回を5秒に1回へ落とせば約52 USDです。通信そのもののデータ転送量と推論の従量課金はこれとは別に積み上がります。台数と頻度の掛け算がそのまま請求額になる、という構造だけ押さえてください。 ### エッジAI側の費用：端末の初期費用が先行し、月額は台数に比例しにくい エッジAI側は逆の形です。同じ料金ページで、Greengrass Coreデバイスの管理料は米国東部バージニア北部リージョンで1台あたり月額0.16 USD、無料利用枠として1年間、毎月最初の3台ぶんが含まれます。100台なら月額16 USDで、送信頻度を上げても管理料は動きません。 その代わり、端末の購入費と設置作業が先に出ます。Jetsonのどの段を選ぶかで1台あたりの単価は大きく変わり、消費電力の幅も7Wから130Wと広い範囲です。屋外や工場内では電源と熱の条件が先に決まっているため、性能だけで段を選べない場面もあります。ハードウェアの選定と設置まで含めた見積りの内訳は[エッジAI開発会社の選び方](https://www.issoh.co.jp/column/details/16488/)で扱っています。 ### 分岐点の出し方：月間推論回数と端末台数から損益が入れ替わる線を引く手順 自社条件での分岐点は、次の順で出せます。 1. 端末台数と、1台あたりの1日の推論回数を確定する 2. クラウドAI案の月額を、メッセージ件数×単価＋データ転送量＋推論の従量課金で積む 3. エッジAI案の初期費用を、端末単価×台数＋設置作業費で積む 4. エッジAI案の月額を、端末管理料＋モデル更新の配信運用費で積む 5. 初期費用の差を、月額の差で割って回収月数を出す 回収月数が端末の想定利用年数を超えるなら、その案件はクラウドAIのままが合理的です。判断を鈍らせるのは4番目の運用費で、見積り段階で抜けやすい項目でもあります。台数が数十台を超える構成なら、[AI/IoTソリューション](https://www.issoh.co.jp/service/ai/iot/)のように端末側の実装と運用設計をまとめて引き受ける先に、初期費用と月額の両方を一度出させたほうが早く決まります。 ## オフラインで動くという説明の実体：保持時間と再同期の仕様が決める停止許容 エッジAIの利点として通信断への強さが挙がりますが、どこまで耐えるのかを数値で書いた解説はほとんど見当たりません。プラットフォームの既定値を見れば、耐えられる時間は先に決まっています。 ### メッセージ保持の既定は7,200秒：止まってよい時間の上限が設定値で決まる Microsoft公式の[Azure IoT Edgeをオフラインで操作するドキュメント](https://learn.microsoft.com/ja-jp/azure/iot-edge/offline-capabilities)（2026年9月15日時点）には、推論やモジュールの動作自体は無期限に継続できると書かれています。制約がかかるのは、クラウドへ送れなかったメッセージのほうです。保持時間を決める `timeToLiveSecs` の既定値は7,200秒、つまり2時間で、それを過ぎたメッセージは有効期限切れになります。設定上の最大値は整数の上限、およそ20億秒まで伸ばせます。 この既定値をそのまま使うと、「2時間以内に回線が戻る前提の設計」を選んだことになります。山間部の設備点検や船舶のように復旧に半日かかる現場なら、保持時間を伸ばしたうえでローカルストレージの空き容量も併せて設計しなければ、データは静かに消えます。再接続後は保存された順序どおりに配信されると明記されているため、順序の入れ替わりを心配する必要はありません。 ### 親デバイス1台あたり子100台という既定値が現場の台数設計を先に縛る もう1つ、構成を縛る既定値があります。同じドキュメントによれば、親デバイス1台が持てる子デバイスは既定で最大100台、edgeHubモジュールの `MaxConnectedClients` で変更します。子デバイスが持てる親は1台だけです。 センサーが数百個ある工場で、ゲートウェイを1台に集約する設計を描いていると、この既定値で足を掬われます。あわせて確認したいのがバージョンのサポート期限で、同ドキュメントではサポート対象がIoT Edge 1.6 LTS、IoT Edge 1.5 LTSのサポートは2026年11月10日に終了すると示されています。端末を数百台配ってからバージョンを上げる作業は、構築時の見積りに入っていないことが多い負担です。 ## エッジとクラウドの間に線を引くハイブリッド構成の条件と見送りの判断基準 「両方を使い分けるハイブリッドが主流」で終わる記事は多いものの、どこに線を引くかまで書いたものは少数です。ここは言い切ります。 ### 線引きの基準：1件の判断に必要な材料がその端末の中で閉じるかどうか 判断の材料がその端末の入力だけで揃うならエッジ、他の端末や過去データとの突き合わせが要るならクラウドへ送ります。外観検査の良否判定、侵入検知、機械の異常音の検出は前者です。店舗横断の需要予測、複数拠点の設備を比べた劣化傾向の分析、対話履歴を踏まえた応答生成は後者になります。 この基準で分けると、多くの案件は「端末で一次判定し、閾値を超えたものだけクラウドへ上げる」形に落ち着きます。通信量は大きく減り、クラウド側は集計と再学習に専念できる構成です。端末側で完結させる言語モデルの構成を検討しているなら、必要スペックの考え方は[ローカルLLMとは](https://www.issoh.co.jp/column/details/12964/)が参考になります。 ### エッジAIを見送ってクラウドAIのままで足りる3つの条件と台数の目安 次の3つがすべて当てはまる案件は、エッジ化しないほうが安く、早く立ち上がります。 - 端末が10台以下で、増設計画が1年以内にない - 1件の判断に1秒程度かかっても業務が回る - 送信するデータに、外部へ出せない個人情報や図面が含まれない この条件下でエッジ化を選ぶと、端末費と設置作業費を先払いしたうえ、更新のたびに現地作業が発生します。台数が増えた段階で端末側へ移す順序で構いません。逆に、3つのうち機密の条件だけが外れる場合は、台数が少なくてもエッジ側を検討する価値があります。データの所在は費用では代替できないためです。 ### 現場で起きる失敗パターン：端末の世代が混在してモデル更新が止まる状態 エッジAIで最も多い詰まり方は、性能不足ではありません。増設のたびに違う世代の端末を買い足し、3年目に「この新モデルは古い端末に載らない」となって更新が止まる状態です。Jetsonだけを見ても67 TOPSから275 TOPSまで段があり、量子化の方式も端末側の対応で変わります。 避け方は決まっています。初期の段階で載せる端末の型番と世代を固定し、増設時も同じ型番を追加する。型番を変える必要が出たら、その時点で全台の更新計画を作り直す。導入例ごとの構成の違いは[エッジAIの導入事例](https://www.issoh.co.jp/column/details/16490/)にまとめてあります。 ## よくある質問 エッジAIとクラウドAIの使い分けについて、相談の場で繰り返し挙がる質問をまとめました。 ### エッジAIとクラウドAIの違いを一言で説明するとどうなりますか？ 推論を端末の中で走らせるのがエッジAI、クラウド上のサーバーで走らせるのがクラウドAIです。違いはこの実行場所ですが、選択を分けるのは場所そのものではありません。端末台数、1台あたりの推論頻度、通信断をどれだけ許容できるかの3条件です。台数が少なく通信が安定している案件ではクラウドAIのほうが安く早く立ち上がり、台数が増えて通信量が積み上がるほどエッジAI側が有利に転じます。 ### エッジAIとクラウドAIはどちらが安いですか？ 台数と送信頻度で入れ替わります。クラウドAI側は従量課金のため、端末が増えるほど月額が伸びます。AWS公式の料金ページでは、AWS IoT Coreのメッセージ課金は100万件あたり1 USDです。エッジAI側は端末購入と設置作業が先行するものの、Greengrass Coreデバイスの管理料は米国東部バージニア北部リージョンで1台あたり月額0.16 USDと、頻度を上げても動きません。初期費用の差を月額の差で割って回収月数を出し、端末の想定利用年数と比べるのが確実です。 ### エッジAIのデメリットは何ですか？ 実務で効くのは3つです。載せられるモデルの規模が端末の演算性能とメモリで頭打ちになること、端末の購入費と設置作業費が先に出ること、そしてモデル更新を全台へ配信する運用が発生することです。中でも見積りから漏れやすいのが3番目で、台数が数百に達した後で更新作業が回らなくなる詰まり方をします。端末の型番を初期段階で固定しておくと、この負担はかなり抑えられます。 ### クラウドAIから後からエッジAIへ移行できますか？ できます。むしろ台数が少ないうちはクラウドAIで精度と業務フローを固め、台数が増えた段階で端末側へ移す順序が定石です。移行時の作業は、学習済みモデルを端末向けの形式へ変換し、量子化などで軽くしたうえで、推論結果の差分を確認する流れになります。逆に最初からエッジ前提で組むと、モデルを差し替えるたびに現地作業が必要になり、精度を詰める段階の試行回数が落ちます。 ### エッジAIとエッジコンピューティングは何が違いますか？ エッジコンピューティングは、処理を端末やその近くで行うという構成の考え方全体を指します。エッジAIはその中で、AIの推論を端末側で走らせるものを指す言葉です。つまりエッジAIはエッジコンピューティングの一部にあたります。拠点側にサーバーを置いて複数端末のデータをまとめて処理する構成もエッジコンピューティングですが、そこでAI推論を行っていなければエッジAIとは呼びません。 ## 関連記事 - [エッジAIとは？クラウドAIとの違い・仕組み・実装の判断基準を解説](https://www.issoh.co.jp/tech/details/13390/)：推論処理の流れとモデル軽量化の技術要素を実装目線で扱っています - [エッジAIの導入事例｜業種別の使いどころと自社適用の判断基準](https://www.issoh.co.jp/column/details/16490/)：どの用途がエッジ側へ寄せられているかを導入例から確認できます - [エッジAI開発会社の選び方｜依頼前に決める要件と費用内訳](https://www.issoh.co.jp/column/details/16488/)：端末調達と設置まで含めた見積りの内訳を整理しています - [エッジコンピューティングとは？仕組み・クラウドとの違いから導入判断まで](https://www.issoh.co.jp/column/details/15366/)：拠点側インフラの層で見た設計判断を扱っています - [NPUとは？CPU・GPUとの役割分担とTOPSの実効性能・採用判断](https://www.issoh.co.jp/tech/details/16171/)：端末側の演算性能をどう読むかの基準になります --- 出典: [エッジAIとクラウドAIの違い｜遅延・費用・オフライン耐性で決める使い分け]()（株式会社一創）