工場の中だけで動くローカルLLM——図面もデータも、建物の外に出さない設計

「保全担当が、故障コードとマニュアルの写真を公開のチャットAIに貼ってもいいですか?」と現場責任者に聞くと、返事はたいてい「問題ない」か「絶対だめ」のどちらかです。そしてどちらも同じ理由で不十分です。どの情報がどちらなのか、誰も決めていないからです。

社内のサーバーで言語モデルを動かすこと自体は、もう難しくありません。中位クラスのGPUで実用的なオープンウェイトモデルが動き、Ollama、llama.cpp、vLLMなどの道具も成熟しています。難しいのは次の3つです。

1. どのデータを外に出さず、どのデータなら出してよいのか。
2. モデルをプラントネットワークのどこに置くのか。
3. 「外に出ていない」ことを、自社と監査に来る取引先にどう証明するのか。

GPUやメモリの選び方は別記事のハードウェア選定ガイド(英語)にまとめていますので、ここでは扱いません。

1. まず、データを3つに分ける

モデルを選ぶ前に、モデルが見るデータを分類します。

区分	例	処理してよい場所
外部送信してよい	公開データシート、一般的な保全知識	共有クラウドAPIでも可
契約があれば可	社内SOP、重要度の低い報告書	学習利用なしを書面で約束した、自社アカウント内のクラウド
社外に出さない	取引先の図面、工程条件、測定・品質データ、治工具情報、NDA対象のもの全般	自社設備のみ

3番目の区分が、工場とオフィスの大きな違いです。精密部品メーカーにとって、図面・公差・加工条件は製品そのものです。

日本の取引先と仕事をする会社には、もう一つ注意点があります。営業秘密として保護されるには「秘密管理性」が必要ですが、情報を生成AIの提供事業者のような第三者に渡すと、場合によっては秘密管理性が否定され得る、という整理があります(経産省の営業秘密管理指針の趣旨を紹介した解説による)。また、2026年6月に公表された公取委・中小企業庁・特許庁のガイドラインでは、相手方の秘密情報を保有する側が、相手方の事前の明示的な同意なく第三者に開示しないことが示されているとの解説があります。自社のNDAが「AIサービス」を第三者として扱っているかを確認する価値があります(いずれも二次的な解説に基づく整理であり、法的助言ではありません。原文と弁護士で確認してください)。

管理の強さを段階で並べるとこうなります。

1. 共有の外部API
2. 共有APIに学習利用なしの契約を付けたもの
3. 自社のクラウド契約内でのマネージド運用
4. 自社設備(必要ならエアギャップ)

「社外に出さない」区分には4段階目が必要です。ローカルLLMが必要になる理由はここにあります。

2. 現場のLLMは何に向いているか

期待は控えめに。8B〜30B程度のローカルモデルは、自社文書に基づく言語作業には向きますが、万能の神託ではありません。

向いている用途

• 出典付きの保全Q&A:「この主軸カバーの締付トルクは?」に、マニュアルの該当ページを示して答える
• 過去の作業指示書に基づく、故障コード・警報の説明
• 下書き:申し送り、作業指示書への構造化、事故の要約
• 日英中タイ語が混在する文書の検索(キーワード検索が効かない場面)

向いていない用途

• PLCや制御系への書き込み。モデルは読み取り専用にし、操作は必ず人が承認する
• 検証できない数値計算(計算はモデルではなくコードで)
• 出典のない断定的な回答(出典を示せないなら「提案」として扱う)

3. 配置:制御ネットワークの外に置く

flowchart TD
  A["制御ネットワーク PLCと設備"] --> B["読み取り専用データゲートウェイ"]
  B --> C["工場データゾーン ヒストリアンとMES"]
  C --> D["AIゾーン LLMサーバーと文書インデックス"]
  E["マニュアル SOP 作業指示書"] --> D
  D --> F["事務所や現場の利用者"]
  D --> G["全問い合わせと回答の監査ログ"]
  H["インターネット"] -.->|"既定で遮断"| D

モデル選びより重要な設計ルールです。

• 下からは読み取りのみ。AIゾーンはゲートウェイ経由で工場データを読めますが、制御ネットワークへは何も戻しません。
• 外向き通信は既定で拒否。LLMサーバーにインターネットへの経路を持たせず、モデルや更新は管理された手順でオフライン搬入します。
• すべての問い合わせと回答を、参照した文書の箇所とともに記録。これが監査証跡になります。
• 操作は人が承認。モデルは提案し、判断は人が行います。

4. 「出ていない」ことを証明する

「建物の外に出さない」は主張です。取引先や監査人は証拠を求めます。

1. ファイアウォールの証跡:AIゾーンの外向き拒否ルールを書き出してレビューする
2. 実測トラフィック:代表的な1週間のLLMサーバーの通信を取得し、想定外の宛先がないことを示す。ソフトウェア更新のたびに再実施する
3. オフラインの供給網:モデルの入手元を記録し、搬入時にハッシュを確認、バージョンを固定する。フレームワークはリリースごとに既定値が変わるため、更新後に再試験する
4. 隠れたテレメトリの排除:ランタイムと各ライブラリの設定を確認し、更新チェックや利用状況送信を無効化またはファイアウォールで遮断する

5. サイズ感を一段落で

数人の対話利用なら、24GBのGPU1枚で7B〜14Bは余裕を持って、27B〜32Bも4ビット量子化なら動きます(重みに加えて、コンテキスト用に2〜3割のVRAM余裕を見込みます)。限界になるのは、モデルの質よりも同時利用数とコンテキスト長であることが多いです。20人が同時に質問するなら、バッチ処理に強い推論基盤か、追加のハードウェアが必要です。

6. 当社の「提供済み」と「案件ごとの作業」

誤解を避けるために区別します。

• simpliSOCで提供済み:セキュリティアラートを読み、平易な説明と真陽性/偽陽性の見立てを書くローカルLLM。OpenAI互換サーバー(Ollama、llama.cpp、vLLM、LocalAI)で動作し、モデルはオンプレミスで動いてアラート内容はネットワーク外に出ません。支援はトリアージのみで、アラートを自動で閉じたり統合したり抑制したりはせず、アナリストが判断します。詳細はsimpliSOC(英語ページ)をご覧ください。これはセキュリティ運用の道具であり、現場アシスタントではありません。
• 案件ごとに設計:製造業向けのオンプレミスLLM構築(モデル選定、OpenAI互換のAPI層、マニュアル・生産記録に対するRAG、ガードレールと監査ログ、ERP/MES連携)。simpliLLM(英語ページ)をご覧ください。箱売りの製品ではなく個別案件のため、範囲と期間は文書とハードウェア次第です。

検索側の設計はタイ語・日本語業務文書向けRAG(英語)、運用リスクはAI security in production(英語)も参考にしてください。

7. よくある質問(FAQ)

ローカルモデルはクラウドモデルと同じ品質ですか?
最上位クラウドモデルには及びません。マニュアル検索や下書きのような文書ベースの作業なら、適切に文書を与えた小さめのモデルで足りることが多いです。評価は公開ベンチマークではなく、自社の文書と質問で行ってください。

「ローカル」なら安全ですか?
いいえ。第三者への送信というリスクが一つ減るだけです。アクセス制御、パッチ、ネットワーク分離、ログは別途必要です。

モデルに設備を制御させられますか?
お勧めしません。読み取り専用にし、操作は人が承認してください。

GPUは必須ですか?
本格的に使うなら必要です。小さなモデルを1人で使うだけならCPUでも動きますが遅くなります。

日本語・タイ語・中国語の文書は扱えますか?
モデルと文書の種類(スキャン、表、図面は難しい)で品質が変わります。ハードウェアを決める前に、実際の文書サンプルで評価してください。

NDAや営業秘密についての法的助言ですか?
いいえ。契約を確認し、弁護士にご相談ください。

一次・参考資料

• Timewell:図面と生成AI、営業秘密の境界(日本の指針の解説)
• iFactory:工場向けオンプレミスLLMの構成(ベンダーブログ。用途の着想のみ参考)
• IntuitionLabs:24GB GPUでのローカルLLM運用

---

Simplico Co., Ltd. は、タイと日本を中心に、オンプレミスAI、SOC、製造業向けシステムを開発しています。お問い合わせは hello@simplico.net まで。