製造業のAIを再設計する ― NVIDIA DGX SparkとEdge-Firstという発想

生成AIがクラウドを前提に進化してきた中で、製造業、特に工場や研究開発部門は常に固有の制約を抱えてきた。機密性、通信品質、レイテンシ、設備とのリアルタイム連携、コスト。これらはクラウドのLLMでは解き切れない課題だ。顧客の課題にこたえるには、「AIを現場に置く」という発想にいたるのは必然だろう。

ローカルでLLMを動かすメリットを考える

上述した通り、まずはセキュリティ、通信品質、レイテンシ、リアルタイム性、コストの観点で整理してみる。

機密性

クラウドで動作するLLMを工場や製造現場に導入しようとした場合、最初に出てくるのが「この情報を工場の外に出して、本当に大丈夫なのか？」という不安だ。製造業では特に顕著で、図面、レシピ、工程条件、研究データなど、外に出したくない情報が山ほどある。こういった懸念を取り除くという点で、LLMをローカルで動かすことそのものが大きな価値になると考えている。

ローカル環境であれば、外部と切り離された状態で、現場のデータを現場の人が意図した範囲だけで扱える。データがどこにも出ていかないという事実は、機密性を重視する現場にとって非常に重要だ。安心して使えるLLMであることは、機能以前の前提条件だと言っていい。

通信品質

製造現場は都市部のオフィスとは違い、通信環境が常に安定しているとは限らない。工場が地方に立地していたり、建屋が厚い鋼材で囲まれていたり、大型設備が無線を遮蔽したりと、ネットワークが前提にならない場面は多い。とくに、生産ラインの奥まった位置や隔離エリアでは「そもそもクラウドに接続できない」環境すら珍しくない。

また、製造業にとって、試作品の評価データや未発表の材料特性情報は極めてセンシティブであり、PCや外部ネットワークの扱いに厳格なルールが設けられている現場も少なくない。

さらに、海外にも目を向けると通信断が日常的に起こる地域もある。クラウドに問い合わせている途中で処理が途切れてしまうと、AIを業務に組み込むこと自体が難しくなる。こうしたハードな環境では、そもそもクラウド前提のAIを安定運用することができず、必然的に、外部接続を前提としないローカルで動くLLMが、もっとも確実に動かせる選択肢になる。

レイテンシ、設備とのリアルタイム連携

製造現場のLLM適用で大きな壁になるのがレイテンシ。クラウドベースのLLMは、どうしてもネットワーク越しの往復が発生するため、応答が安定しない。1 秒の遅延でも問題にならない業務もあるが、製造ラインでは事情が違う。異常検知、品質チェック、設備ログ解析などは、その場で返してくれることが作業効率に直結する。

また、実際にはレイテンシの「平均値」よりも「最悪値」が問題になる。普段は 300ms で返ってきていても、ときどき 3 秒かかるようでは、現場のオペレーションには組み込めない。クラウドはどうしてもネットワークやサービス側の変動があり、最悪値のブレを完全になくすことはできない。

ローカルでLLMを動かすメリットは、この最悪値をほぼゼロにできる点だ。処理はすべて工場内で完結するため、応答時間が安定し、リアルタイム性の要求が高い用途にも適用しやすくなる。PLC → Edge PC（LLM）→ 設備制御・作業者支援 という処理がすべて工場内で完結し、機器とAIが“同じレイヤー”で動くことで、リアルタイム性を損なわずに活用できる。状態監視、異常の早期検知、工程データの要約、作業者への即時フィードバックなど、将来的にLLMがラインのサイクルタイムに直接入り込めるようになるのは、ローカルLLMならではの強みだ。

コスト

コスト構造の違いも、ローカルとクラウドを比較する上で重要な論点だ。クラウドAIは従量課金が前提で、入力トークン・出力トークンの量に応じて利用料が積み上がる。実験段階では気にならなくても、日々の生産データや設備ログ、品質検査結果を継続的に処理し始めると、利用量が急激に増えていく。長期的に見ると、「便利だが継続利用の予測が立ちにくい」という不安が残る。

一方でローカルLLMは、初期投資としてハードウェア購入が必要になるものの、運用コストはほぼ電気代のみで、追加推論に費用は発生しない。大量のデータを日次・週次で処理する用途や、現場でリアルタイムに呼び出す用途では、ローカルの方が明確にコスト最適化しやすい。

たとえば、設備1台あたり数千～数万行のログが毎日生成される現場では、クラウドのトークン課金と比較してローカル推論のコストメリットは非常に大きい。「使えば使うほど安い」というローカルの特性は、製造業のようにデータ量が多い環境と相性がよい。

ハードウェアはどうするのか問題

NVIDIA DGX Sparkのようなコンパクトで高性能なGPU環境が登場したことで、エッジ側で実用的なLLMやマルチモーダルAIを動かすことが現実になった。クラウド依存の構成では難しかった、PLC／センサー／Excelツール群との密結合も視野に入る。つまり製造現場の速度感に合わせた設計が可能になる。

さらに、近年は 軽量かつ高性能なオープンモデル が次々に登場している。Llama系、Mistral系、Phi系、そしてローカル実行に最適化された gpt‑oss 系モデル など、数十億〜百数十億パラメータのモデルがエッジでも十分な推論性能を発揮し、現場で使うには十分な実用LLMになりつつある。これにより、従来はクラウドでしか動かせなかった処理を、現場に持ち込める環境が整い始めてきた。

ということで、とりあえず試すために購入したのはNVIDIA DGX Sparkを2台。同じチップを搭載した他メーカー製のモデルも存在するが、今回、ハードウェアとしての完成度と、プロダクト全体から漂う堅牢さ・プレミアム感に惹かれたのだ。ハードとして格好いい方がやる気出るでしょ。

価格は2台で150万円を超えるので、個人で購入するのは少し覚悟が必要であるが、工場設備として考えると大きな負担にはならないだろう。

LLMを動かす

まずチャットとしてLLMを動かすのは非常に敷居が低い。ほぼGUIで完結できるので、スマートフォンの初期設定の方が面倒なくらいだ。

ここでは手順についての解説はしないが、大まかには

本体の初期設定 ＞LM Studioのインストール > モデルのダウンロードの3つの工程にわかれる。

本体の初期設定はUSBマウスとキーボード、モニタを接続して、手順に沿って進めるだけなので、1時間もあれば終わる。LM Studioもダウンロードページに行ってLinux Arm版のアプリをダウンロードする。最後に、LM Studioからモデルを選択してインストールすれば終わり。おそらくLM Studioでチャットが使えるようになるまで数時間で終わるはずだ。

モデル

今回はOpenAIの gpt-oss 20Bと120Bをインストールした。

gpt-oss 20B ― 現場で使うには十分すぎる汎用LLM

gpt-oss 20B は、20B（200億パラメータ）で、約13万トークンという比較的長いコンテキストに対応しているのが特徴。製造業で扱うテキスト、例えば、評価レポート、試験記録、品質管理手順、設備ログの説明を丸ごと渡して解釈できる。実際に使ってみるとローカルでの回答の速さが驚くほど高速だ。本当に推論しているのかと疑いたくなるレベルで返ってくるので、AI AgentやRAGと組み合わせることで、ユースケースの幅はかなり広くなりそうだ。

gpt-oss 120B ― 大規模モデルが必要なケースで真価を発揮

gpt-oss 120B は、その名の通り 120B（1,200億パラメータ） の大規模モデルで、20Bよりも文章理解力・推論能力・曖昧な質問への対応力が大きく向上している。特に、複数の文脈をまたぐ説明や、抽象度の高い推論タスクでは 20B との差が明確に出る印象だ。

装置マニュアル・工程仕様書・品質要件など複雑で、前提の多いドキュメントを、

• 工程全体の流れを踏まえた説明
• 複雑な現象に対する因果関係の推定
• 過去の複数のレポートをまたぐ要因分析
• 曖昧な問い合わせに対しても破綻しない回答

といったタスクでは、120B の表現力と推論の余裕が役に立つだろう。例えばAI Agentがインプットされたデータをもとに、軽い日常業務は 20B に任せ、難度の高い判断や要約は 120B に切り替える、といった運用が自然だと思う。

ファインチューニングという選択肢

ローカルLLMの利点のひとつに、自社データを使ってモデルをファインチューニングできる点がある。クラウドモデルではセキュリティや規約の制約から難しかったが、ローカル環境であれば、設備ログ、品質レポート、手順書、技術ナレッジといった製造現場ならではのデータを用いて、モデルを自社専用に最適化できる。

例えば、

• 社内固有の専門用語・略語の意味を理解する
• 「工程名 → 具体的手順」のような文脈を自然に解釈できる
• 過去のトラブルを学習し、似た症状への回答精度が上がる
• 安全・品質基準など、現場ルールに従った回答ができる

これにより、汎用LLMでは難しかった各工場・各工程の事情を理解した回答を可能にする。特にgpt‑oss系モデルは軽量ファインチューニング（LoRA / QLoRA）との相性が良く、20B であれば DGX Spark クラスのEdge GPUでも十分に再学習が回る。

汎用AIをただ置くのではなく、現場専用AIを自分たちで育てる、これこそが Edge‑First の最大の醍醐味だ。

おわりに

クラスメソッドは、クラウドLLMだけでなく、ローカルの技術も織り交ぜながら、現場の痛みに寄り添ったソリューションをこれからも開発していきます。