画像検査・監視システムをエッジ（Jetson等の現場端末）で動かすかクラウドで動かすか。レイテンシ・通信コスト・データ秘匿・通信環境・モデル更新の観点から判断軸を整理し、両者を組み合わせる現実的な設計を解説します。
画像検査や現場監視にAIを使おうとすると、必ずと言ってよいほど「処理をどこで動かすか」という問いに突き当たります。カメラで撮った画像をその場の端末で判定するのか、いったんクラウドへ送って判定するのか。一見すると技術者だけの話に見えますが、実際にはレイテンシ・通信費・情報セキュリティ・現場の回線品質・運用負荷といった、経営判断に近い論点が絡み合っています。
この問いがここ数年で急に重くなった背景には、いくつかの構造的な変化があると考えられます。1つは、画像認識やVLM（Vision Language Model）のような大きなモデルが扱えるようになり、「どこに置けば現実的に動くのか」という配置設計そのものが性能を左右するようになったことです。もう1つは、現場側の端末——たとえばNVIDIA Jetsonのようなエッジ向けの計算機——が実用的な推論性能を持つようになり、クラウドに送らなくても相応の処理がその場で完結しうる選択肢が増えたことです。
素朴に考えると、「クラウドは計算資源が潤沢だから全部クラウドでよいのでは」と思えます。しかし検査ラインのように1秒未満で合否を返さなければならない用途では、画像をクラウドへ送って結果を待つ往復時間が許容できないことが珍しくありません。逆に「現場で完結するエッジがすべて優れている」と考えると、モデルの更新や複数拠点の横展開、不良傾向の分析といった作業が一気に重くなります。
つまり、どちらか一方に寄せる設計は多くの現場で無理が出やすいと考えられます。本記事では、二者択一として捉えるのではなく「何をエッジに、何をクラウドに置くか」を分けて設計するための判断軸を整理します。なお、ここで述べる考え方は製造業DXをどこから始めるかという全体設計の議論とも地続きの話だと位置づけられます。
エッジとクラウドの使い分けを考えるとき、実務上は次の5つの軸でトレードオフを見るのが整理しやすいと考えます。重要なのは、どれか1つだけで結論を出すと後から行き詰まりやすいという点です。それぞれを現場条件に当てはめ、重み付けして総合判断することが前提になります。
検査ラインで1個ずつ合否を返す、フォークリフトの接近を即座に検知して警告する——こうした用途では、判定の遅れがそのまま機会損失や安全リスクになります。クラウドへ画像を送って結果を待つ往復には、回線状況によってばらつきのある遅延が乗ります。即時性が要件の中心にある場合は、推論をエッジ側に置くことが有力な候補になると考えられます。
高解像度の画像や動画を常時クラウドへ送り続けると、通信量と費用が無視できない規模になる可能性があります。とくに複数ラインに多数のカメラを設置する構成では、全フレームをアップロードする設計は現実的でないことが多いと考えられます。エッジ側で判定し、必要な情報（合否結果、不良画像、メタデータ）だけをクラウドへ送る方が、帯域と費用の両面で扱いやすい場合があります。
製品図面が写り込む検査画像、人物が映る監視映像などは、社外（クラウド）へ出すこと自体に社内規程や取引先要件の制約がかかる場合があります。データを現場内に留めたい要件が強いほど、エッジ側で完結させる設計の価値が高まると考えられます。一方で、適切な暗号化やアクセス制御を前提にクラウド活用が許容される現場もあり、ここは技術だけでなく組織のルールに左右される論点です。
前のセクションで挙げた3つに加え、運用が始まってから効いてくるのが残りの2軸です。導入前の比較表では軽視されがちですが、実際の運用ではここで差が出ることが少なくないと考えます。
工場の奥や倉庫の一角、屋外のゲート付近など、そもそも通信が安定しない場所は珍しくありません。回線が瞬断したときにクラウド依存の構成だと検査や監視そのものが止まってしまう可能性があります。エッジ側で推論が完結していれば、通信が一時的に切れても現場の判定は継続でき、復旧後に結果をまとめて送る、といった運用が組みやすいと考えられます。可用性を重視する現場ほど、エッジ側の自律性が効いてきます。
逆に、クラウド側に強みが出るのがモデルの更新と管理です。新しい不良パターンに対応するためにモデルを学習し直す、複数拠点へ同じモデルを配る、各拠点の判定結果を集めて傾向を分析する——こうした作業は、中央に集約されたクラウド基盤の方が圧倒的に回しやすいと考えられます。エッジ端末が現場に散在するほど、「どの端末がどのバージョンのモデルで動いているか」を管理する仕組みが重要になります。
ここまで見ると分かるとおり、レイテンシ・通信コスト・通信安定度はエッジ寄りに、モデル更新・横展開・分析はクラウド寄りに最適点が出やすい傾向があります。つまり軸によって望ましい方向が逆を向くため、単一の正解は存在しません。だからこそ「推論はエッジ、学習と管理はクラウド」のように役割を分ける発想が、多くの現場で落としどころになりやすいと考えられます。
5つの軸を踏まえると、多くの検査・監視システムでは推論（その場の判定）をエッジに、学習・管理・分析をクラウドに置くハイブリッド構成が現実的な出発点になると考えます。役割を分けることで、即時性と可用性を確保しつつ、モデルの育成や横展開のしやすさも両立しやすくなります。
近年は、軽量な検知モデルをエッジで動かしつつ、判断に文脈や言語的な解釈が必要な部分をVLMで補う、といった組み合わせも検討されるようになってきました。たとえばエッジVLM-OCRのように、現場端末側で文字や対象を捉えつつ、より高度な解釈を要する処理を上位で扱う設計です。すべてを1つの大きなモデルで処理しようとせず、役割に応じてモデルと配置を分けることが、性能と運用性の両立につながる可能性があると考えます。
設計方針が決まっても、実際の現場には「すでに動いているライン」「既設のカメラやPLC」「限られた設置スペースと電源」といった制約が必ず存在します。エッジ／クラウドの配置設計は、これらの物理的な現実とすり合わせて初めて実装に落ちると考えます。
多くの現場では、ラインを全面的に作り直すのではなく、既存設備に検査・監視機能を後付けする形が現実的です。エッジAIの後付け（レトロフィット）では、既設ラインを大きく止めずにカメラとエッジ端末を追加し、必要な判定をその場で動かすアプローチが取られます。この場合、エッジ側で完結させる設計の方が、既存システムへの影響を抑えやすい傾向があると考えられます。
Jetonのようなエッジ計算機を選ぶ際も、カタログ上の推論性能だけでは判断しきれません。設置環境の温度・粉塵・振動、電源と配線、既存機器との信号のやり取り、冷却の余裕——こうした条件が、実際に安定稼働するかを左右します。ハードウェア統合の観点では、モデルが要求する計算量と、現場で確保できる電力・放熱・スペースの折り合いを早い段階で確認しておくことが重要だと考えます。
付け加えると、エッジかクラウドかという配置の話は、照明・レンズ・カメラ配置といった撮像設計と切り離せません。撮像が安定しなければ、どこで推論しても判定はばらつきます。配置設計の前提として、まず現場で安定した画像が取れる条件を固めることが先決だと考えられます。
エッジ／クラウドの使い分けを検討する際、現場で繰り返し見られるつまずき方があります。先回りして避けることで、後戻りのコストを抑えられる可能性があります。
ここまで判断軸と設計の考え方を整理してきましたが、最終的にエッジとクラウドのどこに何を置くかは、現物・現場での検証を通じて確かめる前提だと考えます。撮像点数・1個あたりに許される判定時間・現場回線の安定度・秘匿要件は、工場や倉庫ごとに大きく異なるためです。
カタログスペックや一般論だけで配置を決めると、現場固有の条件——たとえば想定より不安定な回線や、思いのほか厳しい秘匿要件——を見落とし、最適点を外す可能性があると考えられます。だからこそ、小さく現物で確かめてから広げる順序が有効だと考えます。AI検査の試験導入でつまずきやすい論点は目視検査の限界と解決の方向性とも重なります。
Nsightには、キーエンス画像処理事業部で検査の現場と撮像設計に携わってきた監修者が在籍しています。エッジとクラウドの使い分けは、技術スペックの比較だけでなく、撮像・照明・現場運用・組織のルールまで含めて初めて答えが出る論点だと考えています。私たちは結論を一方的に示すのではなく、現物・現場での検証を通じて、その現場にとっての最適な配置を一緒に確かめていく進め方を大切にしています。
1個ずつ即時に合否を返す必要があり、回線断でも止めたくない検査ラインでは、推論をエッジ側で完結させる構成が有力な候補になると考えられます。ただしモデルの更新や複数ライン展開、不良傾向の分析はクラウド側が回しやすいため、推論はエッジ・学習と管理はクラウド、という役割分担が現実的な出発点になりやすいです。最終的な配置は現物検証で確かめる前提です。
技術的には可能な場合もありますが、応答時間・通信コスト・回線の安定度・データ秘匿の観点で制約が出やすいと考えられます。とくに高解像度画像を多数のカメラから常時送る構成では、通信量と費用が無視できない規模になる可能性があります。即時性や可用性が要件の中心にある場合は、エッジ側での処理を組み合わせる方が現実的なことが多いです。
カタログ上の推論性能だけでなく、設置環境の温度・粉塵・振動、確保できる電源と放熱、既存機器との信号のやり取り、設置スペースを併せて確認することが重要だと考えます。モデルが要求する計算量に対して現場で確保できる電力・冷却が足りないと、安定稼働しない可能性があります。ハードウェア統合の観点で早めにすり合わせることをおすすめします。
エッジ端末が現場に散在している場合、更新手段やバージョン管理の仕組みを事前に設計しておかないと、改善のたびに現地作業が発生しやすくなります。クラウド側でモデルを学習・管理し、各エッジへ配布できる仕組みを前提にしておくと、不良パターンの追加などに対して改善サイクルを回しやすくなると考えられます。
レイテンシ・通信コスト・データ秘匿・現場の通信環境・モデル更新のしやすさという5軸で、その現場で何が譲れない制約かを先に洗い出すことをおすすめします。そのうえで、実際のワークと現場条件で小さく現物検証を行い、応答時間や通信量を実測してから配置を確定する順序が有効だと考えます。机上のスペック比較だけでは最適点を外す可能性があります。
撮像点数・許容判定時間・回線・秘匿要件は現場ごとに異なります。元キーエンス画像処理事業部出身の監修者とともに、実際のワークと現場条件で最適な配置を検証します。
現物検証・相談を申し込む