エッジAI×SLMで変わる製造現場：具体的な活用例5選

結論：製造現場のSLMはネット接続ゼロで動くAIとして使う

製造現場でAI活用が進まない理由の一つは、工場内のネットワーク環境の問題だ。クラウドAPIを前提にしたAIサービスは、通信遅延・セキュリティポリシー・通信断リスクが障壁になる。SLMをエッジデバイスに展開すると、これらの問題を根本的に回避できる。クラウドに問い合わせるのではなく、現場の機械の隣に置いたサーバーで処理が完結する。

本記事では、製造現場でSLMをエッジで動かす具体的なユースケース5つと、それを実現するためのハードウェア選定・PoC設計・コスト感を整理する。

SLMとLLMの違い・用途の使い分け全般についてはSLMとLLMの比較記事も合わせて読んでほしい。

製造現場でSLMをエッジで使う理由

製造現場にはクラウドAIを使いにくくする固有の条件がいくつかある。

ネットワーク環境の制約が最も根本的だ。工場内の生産ライン近くでは、電磁ノイズや構造上の理由からWi-Fiが不安定な区域が多い。有線ネットワークは設備の配線に制約されている。クラウドAPIを使うシステムはこうした環境で接続が断たれると停止する。エッジデバイスにSLMを乗せれば、ネット接続の有無に関係なく動作できる。

リアルタイム処理の要件も重要だ。設備の異常を検知してオペレーターに知らせるようなシステムでは、クラウド往復の遅延が許容されない場合がある。クラウドAPIのレスポンスタイムは通常1〜3秒程度だが、センサーデータの異常判定を毎秒行うような処理には不向きだ。エッジで処理すれば、ネットワーク遅延の変数を排除できる。

生産データの機密保持も理由になる。生産計画・品質データ・設備の稼働状況は競争上の機密情報だ。これらをクラウドAPIに送信することへの懸念は、製造業では特に強い。SLMをオンプレミスのエッジデバイスで動かすと、データが社外に出ない。

製造現場でのSLM活用例5選

活用例1：作業手順の音声ガイド

製造ラインの作業者が、タブレットや音声インターフェースで「この部品の取り付け手順は？」と尋ねると、SLMが作業標準書に基づいて手順を音声で案内する。

従来は紙のマニュアルを探したり、ベテランのオペレーターに聞いたりしていた。SLMをエッジで動かすことで、両手がふさがった状態でも音声入力で手順を確認できるようになる。作業中断時間が1回あたり3〜5分程度あるとすると、1日数十回の確認作業では時間の削減効果が大きい。

精度を上げるには、作業標準書を文書として整備してSLMに読み込ませるRAG構成が有効だ。SLMとRAGを組み合わせた社内検索の記事で解説した構成を、エッジデバイス上で動かす形になる。

活用例2：設備異常の一次診断

センサーが検知した設備の異常値を入力として、SLMが過去のトラブルシュートデータに基づいて考えられる原因と初期対処を出力する仕組みだ。

たとえば「温度センサーが上限値を超えた」「振動値が通常の1.5倍を記録した」などの情報を受け取り、「冷却水の詰まり可能性あり、フィルター点検を実施してください」のような一次回答を返す。すべての故障を自動診断するわけではなく、保全担当者が来るまでの間にオペレーターが最初に確認すべき点を絞り込む補助として使う。

この用途では、過去の設備トラブル記録と対処法をSLMのコンテキストに入れるRAG構成が重要だ。故障モードと対処のデータが蓄積されているほどシステムが実用的になるため、既存のトラブル管理システムからのデータ連携が前提になる。

活用例3：報告書の自動生成

シフト終了時に作業者が音声や短文で作業内容・異常・注意事項を入力すると、SLMが定型の報告書フォーマットに整形して出力する。

製造現場では日報・シフト引き継ぎ書・品質記録など、定型書類の記入に費やす時間が一人あたり1日30〜60分に及ぶ場合がある。SLMによる自動整形で記入時間を半分以下に減らせる可能性がある。記載漏れの自動チェックも組み込める。

重要なのは、SLMの出力を「完成品」として使うのではなく、作業者が確認・修正してから確定する「下書き生成」として位置づけることだ。事実と異なる内容が報告書に混入するリスクを防ぐために、人間のチェックを手順に組み込む必要がある。

活用例4：作業指示の多言語翻訳

外国籍の作業者が増えている製造現場では、作業指示書の多言語対応がコストと時間のかかる課題になっている。SLMをエッジで動かして、日本語の作業指示を英語・中国語・ベトナム語などに即時翻訳するシステムを組み込める。

翻訳用途では汎用性より専門用語への対応が重要だ。製造業の機械名・手順の動詞・安全上の注意表現を正確に翻訳できるよう、用語集をRAGのデータとして持たせる、あるいはファインチューニングで対応する方法がある。翻訳精度については定期的に現場確認が必要で、安全に関わる指示の翻訳には必ず専門家のレビューを入れる運用が不可欠だ。

活用例5：点検チェックリストの自動生成

設備のモデルや点検タイミングを入力として、過去の点検記録・整備マニュアル・メーカー推奨点検項目に基づいて、その設備専用の点検チェックリストをSLMが自動生成する。

定期点検の際、複数の設備に対してそれぞれ紙のチェックリストを管理する手間が省ける。設備の更新や整備記録の変化を文書に反映すれば、チェックリストも自動的に更新される。点検結果をSLMに入力して、次回の重点確認箇所を提案させる拡張も可能だ。

必要なハードウェア：エッジサーバーと産業PCの選択

製造現場のエッジAIには、一般的なオフィスPC環境と異なる要件がある。

温度・粉塵・振動への耐性が必要な産業用途では、ファンレスで動作する産業PC、または防塵防水規格を持つエッジサーバーが必要になる。一般的なコンシューマー向けGPU搭載PCでは、製造現場の環境仕様を満たせないことがある。

SLMの推論に使われる主なエッジデバイスとしては次のカテゴリがある。

NVIDIAのJetsonシリーズは、CUDA対応のGPUを内蔵したエッジデバイスだ。Jetson AGX Orinは64GBモデルで7Bクラスのモデルが実用速度で動く。産業環境向けのキャリアボードと組み合わせて使うことが多い。

Intel NUCの産業版は、小型でスタンダードなx86アーキテクチャのため、既存のソフトウェア資産が活かしやすい。GPU拡張カードを搭載することでSLMの推論速度を向上できる。

ARM系のSoCを使ったファンレス産業PCは、消費電力と耐環境性のバランスが良い選択肢だ。ただし対応するSLMのソフトウェアスタックの確認が必要になる。

どのハードウェアを選ぶかより先に、使うSLMのサイズと必要な応答速度を決めることが重要だ。3Bモデルであれば廉価なエッジデバイスでも対応できるが、7B以上になると必要なメモリとGPU性能が大きく上がる。

PoC設計のポイント

製造現場へのSLM導入でPoC（概念実証）を設計する際に重要な点を4つ挙げる。

対象ラインと対象タスクを一つに絞る。最初から工場全体への展開を目指すと、変数が多すぎて何が問題か分からなくなる。一つの工程・一つのタスクに絞り、そこで効果と品質を確認してから展開範囲を広げる。

評価指標を定量で設定する。「使いやすかった」という定性評価だけでは本番展開の判断ができない。応答時間（3秒以内を目標にするなど）・回答の正答率・作業者の操作完了率などを事前に設定し、PoC期間中に計測する。

現場の作業者を設計に巻き込む。SLMへの入力方法・回答のフォーマット・エラー時の動作など、現場での使い勝手は机上では分からない部分が多い。作業者数人にプロトタイプを試してもらい、どこで詰まるかを観察することが最も効果的だ。

ネットワーク非接続環境でのテストを必ず実施する。PoCを社内ネットワークがある環境で開発して、現場に持ち込むと動かないというケースを防ぐ。開発段階から切断環境での動作確認を手順に組み込む。

コスト感

エッジSLM導入のコスト構造は大きく3つに分かれる。

初期ハードウェアコストは、エッジデバイス1台あたり20万〜80万円程度が目安だ。NVIDIA Jetson AGX Orinのキャリアボード込みの産業用構成で50〜80万円、x86の産業PCに外付けGPUを加えた構成で30〜50万円程度が参考値だが、仕様によって幅が大きい。最新の価格は各メーカーに確認してほしい。

SLMのソフトウェアコストは、Llama・Gemma・Phi-4 Miniなどのオープンソースモデルを使う場合は基本的に無料だ。ただし商用利用に関するライセンス条件の確認は必須だ。一部のモデルは利用規模や用途に制限がある。エンタープライズ向けのサポートやカスタマイズを求める場合は、モデルプロバイダーとの契約コストが発生する。

保守・運用コストは見落とされやすい。モデルの更新・精度の監視・文書データの追加・ハードウェアの保守対応などを含めた年間コストは、初期投資の15〜25%程度を見込むことが一般的な目安だ。エッジデバイスを複数台展開する場合は、デバイス管理とモデル配信の仕組みも必要になる。

生成AI全般の費用対効果の考え方については生成AI導入の費用対効果を解説した記事が参考になる。

まとめ

製造現場でのSLM活用は、クラウドAIが前提にしているネットワーク接続・データ送信・APIコスト構造のすべてを変えられる点が価値だ。作業手順ガイド・設備異常診断・報告書生成・多言語翻訳・点検リスト生成という5つのユースケースは、どれも既存の業務の延長に位置づけられる。まずネットワーク制約とリアルタイム要件を確認して、一つのラインの一つのタスクでPoCを設計することが現実的な始め方になる。