「省エネのためにデータを見える化したいが、そもそも工場のデータを外に出せない」——この制約は珍しくありません。本稿では、クラウド前提を外した工場内完結の監視構成と、ローカルLLMでデータを活用する考え方を、利点と運用上の制約の両面から整理します。
電力コストの高騰、省エネ法の定期報告、取引先からのCO2排出量の開示要請——こうした流れの中で、多くの工場が「まずデータを見える化しよう」と動き始めています。ところが着手した途端、思わぬ壁にぶつかることがあります。「そのデータ、クラウドに送っていいのか」という社内からの一言です。省エネのために計測を増やそうとしたはずが、情報セキュリティの議論で止まってしまう。この構図は決して珍しくありません。
ここで大切なのは、「クラウドに送れない」を情報システム部門の過剰な慎重さや、抵抗勢力の言い分として片づけないことだと考えます。多くの場合、その背後には正当な事業上の理由があります。それを解きほぐさないまま「クラウドが使えないなら見える化は無理」と諦めるのは、省エネや原単位管理の機会そのものを手放すことになりかねません。
「送れない」の中身を分解すると、いくつかの異なる事情が混ざっていることが分かります。第一に、顧客との機密保持契約です。特定の製品を作っている工場では、生産数量や稼働パターンそのものが顧客の事業計画を示唆してしまうため、外部サービスへの送信が契約で制限されているケースがあります。第二に、生産技術ノウハウの保護です。設備の運転条件や消費電力の変動は、その工場の競争力の源泉であり、社外のサーバーに蓄積したくないという判断は合理的です。
第三に、調達先・親会社からのセキュリティ要求です。近年はサプライチェーン全体のセキュリティ監査が厳しくなり、「工場ネットワークから外部への常時通信を認めない」という方針が上位から下りてくることがあります。第四に、そもそも工場のOT（制御系）ネットワークがインターネットから物理的に切り離されている、という現実的な事情です。これらは性質が異なるため、「どれに当たるのか」を切り分けることが、次の一手を決める前提になると考えます。
実務で最初にやるべきは、抽象的な「クラウド禁止」を具体的なデータ単位・通信単位に落とすことだと考えます。ひとくちに工場データと言っても、電力量の時系列、生産実績、設備の稼働ログ、検査画像、作業者の動線など、機微度はまったく異なります。すべてを一律に「外に出せない」とすると、実現可能な構成まで塞いでしまいます。逆に、機微なデータを曖昧なまま外部に流すのは論外です。だからこそ、粒度を上げた仕分けが要になります。
実務では、データや通信を「絶対に外へ出せないもの」「匿名化・集約すれば許容されうるもの」「条件付きで外部連携してよいもの」の三つに仕分けると議論が進みやすいと考えます。たとえば、個々の設備の秒単位の消費電力波形は生産ノウハウを含みうるため工場内に留め、月次の総使用電力量のような集約値は社内報告や省エネ法対応のために外へ出す、といった線引きです。検査画像は製品形状が写り込むため最も慎重に扱う、というのが一般的な感覚だと考えられます。
この仕分けは、情報システム部門だけでも、現場だけでも完結しません。何が競争力に直結するかを知る生産技術、契約条件を知る営業・法務、ネットワーク境界を管理する情報システム——この三者の認識を一枚の表に揃えることが、後戻りを防ぐ意味で重要だと考えます。ここを飛ばして技術構成の議論に入ると、作った後で「それは送っていいデータではなかった」という手戻りが起きやすくなります。
もう一つの論点は、「クラウドを使わない＝すべて自前で抱える」ことの重さです。クラウドサービスは、可用性・バックアップ・アップデートといった運用の相当部分を肩代わりしてくれています。それを工場内に持ち込むということは、その運用責任もこちら側に移るということです。この裏返しのコストを直視せずに「オンプレなら安心」と決めると、別の場所で無理が出ると考えます。
外部にデータを出さずに省エネ・原単位管理を回す基本形は、「計測」「収集・保存」「分析・可視化」の三層をすべて工場内に置く構成になると考えます。計測層では、分電盤やブレーカー単位に電力センサー（CTクランプ等）を取り付け、設備ごとの消費電力を拾います。既存設備を改造せずに計測を足せる既存設備への後付けセンシングの考え方は、送信可否とは別に「そもそも配線を触りたくない」という現場でも相性がよいと考えられます。
収集・保存層は、工場内に置いた小型サーバーやエッジ端末が担います。ここでセンサー値・生産実績・稼働ログをローカルのデータベースに書き込み、外部通信を発生させません。エッジAIによる工場内データ処理のように、演算とストレージを現場側に寄せる構成であれば、データがネットワーク境界を越えないまま可視化まで到達しうると考えます。クラウドを使わない完結型の監視については、クラウドを使わない完結型監視でも整理しています。
設備の稼働状態や表示灯・メーターをカメラで読み取り、電力データと突き合わせたい場面もあります。画像は機微度が高い一方で、エッジ側で推論を完結させ「異常あり/なし」「稼働/停止」といった判定結果だけを残し、元画像を外に出さない設計であれば、リスクを抑えつつ活用しうると考えます。ここは元キーエンス画像処理事業部の現場知見 × VLM × Jetsonエッジ × 産業用カメラ × 現場ライティングという組み合わせが効く領域ですが、照明条件や設置角度で読み取り精度は大きく変わるため、現物での検証が前提になります。
この三層を工場内に閉じることで、通信ログ上「外部への送信がない」ことを情報システム部門に示しやすくなります。監査対応の観点でも、境界を越えるデータフローが存在しないという事実は説明が単純です。ただし、これは「工場内で完結できる」という利点であると同時に、後述するように「工場内で全部面倒を見る」という負担の裏返しでもあります。
データを工場内に貯められても、「では、この電力と生産のデータから何が読み取れるのか」を人が毎回グラフとにらめっこするのは負担が大きいのが実情です。ここでLLMに要約・分析を任せたくなりますが、外部のAIサービスにデータを送ることは、まさに本稿の前提に反します。そこで選択肢になるのが、工場内で動くローカルLLMです。機微なデータを工場内に留めたまま活用する考え方は、ローカルLLMで外部送信せず活用でも触れています。
ローカルLLMの現実的な使いどころは、たとえば「先週の設備別電力を要約し、前週比で増えた設備を挙げる」「原単位が悪化した日と生産品目・気温を並べて仮説を出す」「省エネ法の報告に向けた月次コメントの下書きを作る」といった、定型的だが手間のかかる作業の支援だと考えます。外部送信ゼロのまま、担当者の報告負担を軽くする方向に効きうる、という位置づけです。
一方で、正直に書くべき限界があります。工場内で動かせるモデルは、巨大なクラウド上のモデルに比べて規模の制約を受けやすく、複雑な推論や長い文脈の扱いで見劣りする場面がありえます。また、LLMが出した仮説はあくまで仮説であり、「原因はこれです」と鵜呑みにすると誤った改善に走る危険があります。ローカルLLMは判断を代行するものではなく、担当者が現場で確かめる前の「たたき台」を素早く出す道具だと捉えるのが誠実だと考えます。
導入時には、モデルを動かすためのGPUやメモリを備えたエッジ/サーバー機、モデルの選定と更新、社内データに合わせた検索連携（RAG）の設計など、それなりの初期作業が伴います。「ローカルLLMを置けば自動で分析される」わけではなく、何を読ませ、どう問い、出力をどう検証するかという運用設計が伴って初めて価値が出ると考えます。
工場内完結の構成を長く使えるものにするには、いくつかの設計原則を最初に置いておくと良いと考えます。第一に、データの粒度と保存期間を用途から逆算することです。秒単位の波形をすべて何年も貯めれば、工場内ストレージはすぐ逼迫します。異常検知には高頻度データ、原単位管理には分〜時間単位の集約、長期保存は日次サマリ、といった多段の保持方針を最初に決めておくと、後の運用が軽くなります。
第二に、外部通信がないことを技術的に担保し、かつ説明できる状態にすることです。単に「送っていないつもり」ではなく、ネットワークセグメントを分け、外向き通信を遮断し、その設定を情報システム部門と共有しておく。これは監査や社内説明の場面で効いてきます。省エネ法対応などで一部の集約値だけを外に出す必要がある場合も、「どのデータが、どの経路で、どの粒度で出るのか」を一枚の図にしておくことが、後の疑義を防ぐと考えます。
第三に、電力量そのものではなく原単位（製品1個あたり・生産量あたりの消費エネルギー）で見られる設計にすることです。生産量が増えれば電力量も増えるのは当たり前で、総量だけを見ても改善したのか悪化したのかが分かりません。工場内に生産実績データを取り込み、電力と紐付けて原単位を出せる構成にしておくと、拠点間比較や月次比較が意味を持ちます。クラウドに送れない環境でも、この紐付けは工場内で完結して行えると考えます。
ここまで工場内完結の利点を述べてきましたが、公平を期すために制約もはっきり書きます。クラウドを使わないということは、可用性・バックアップ・障害対応・ソフトウェア更新のすべてを工場側で担うということです。エッジ端末が1台壊れたときに誰がどう復旧するのか、データのバックアップをどこに取るのか、といった問いに答えを用意しておかないと、「見える化はできたが、ある日から止まったまま」になりかねません。
拡張性にも独特の制約があります。クラウドなら「使う分だけ増やす」ことが容易ですが、工場内完結では、対象設備を増やすたびに端末やストレージの増設・再設計が要る場面が出てきます。複数拠点に横展開したいときも、各拠点にそれぞれ完結型を置くのか、限られた集約値だけを本社に集めるのか、という設計判断が必要です。ここは「外に出せないデータ」と「拠点比較したいニーズ」がぶつかるところで、仕分け（02節）の結論が効いてきます。
運用負担を丸ごと自社で抱えるのが難しい場合、現実的には「重要なデータは工場内に閉じつつ、監視・保守の仕組みだけは無理のない形にする」という折衷が取られることが多いと考えます。たとえば、機微データは外に出さないが、機器の死活監視のような機微でない情報だけは限定的に扱う、といった線引きです。何を守り、何は運用効率のために許容するか——この判断こそが、完結型を持続させる鍵になると考えます。
工場内完結型の導入で実際につまずきやすい点を、正直に挙げておきます。いずれも「やってみないと分からない」部分を含み、事前に想定しておくだけで回避しやすくなると考えます。
これらはどれも、最初の設計段階で「誰が・何を・どこまで」を言語化しておけば大きく減らせるものだと考えます。逆に、技術構成だけを先に決めてしまうと、後から運用や契約の現実に合わせて作り直すことになりがちです。
最後に、現実的な始め方を示します。おすすめは、いきなり全社基盤を構想せず、対象設備を数台に絞った小さな検証から入ることだと考えます。たとえば「消費電力の大きい設備を2〜3台選び、後付けセンサーで計測し、工場内サーバーに貯めて原単位を可視化する。この間、外部への送信はゼロで運用できるか」を実際に回してみる。ここで、閉じたまま可視化まで到達できるか、運用負担はどの程度か、という肌感覚が得られます。
この段階では、投資額も影響範囲も限定的なので、情報システム部門の合意も取りやすいと考えます。小規模PoCから始める相談のように対象を絞って検証設計を行えば、「外に出せない」という制約を守りながら、見える化と改善のループが工場内で回るかどうかを、机上ではなく現物で確かめられます。うまくいけば横展開の設計に進み、難しければ何が障害かを具体的に特定できます。
重要なのは、完璧な全体像を先に描くことではなく、客観的な把握と現場での検証を出発点にすることだと考えます。電力の実測値、生産実績との紐付け、原単位の推移——この一連が工場内完結で見えるようになれば、クラウドに送れないという制約は、省エネ・原単位管理を諦める理由ではなくなりうると考えます。自社の制約と設備に即した構成を一緒に整理したい場合は、相談するところから始めていただけます。
必ずしもそうではないと考えます。計測・収集・分析を工場内サーバーやエッジ端末で完結させ、外部通信を発生させない構成は技術的に成立しうるためです。ただし可用性やバックアップ、更新といった運用の責任が工場側に寄る制約も同時に生じます。まずは対象設備を絞り、外部送信ゼロで原単位を可視化できるかを現物で検証することが現実的な一歩になりうると考えます。
禁止の理由によって答えは変わると考えます。顧客との機密保持契約、生産ノウハウ保護、親会社のセキュリティ方針、ネットワークの物理分離など、背景は一つではありません。データを『絶対に出せない/集約すれば許容されうる/条件付きで連携可』に仕分けると、実現できる構成が見えてくることが多いと考えられます。まず何が禁止で何が許容かを関係部門で言語化することをおすすめします。
外部に送らず活用できる点は大きな利点ですが、同等とは限らないと考えます。工場内で動かせるモデルは規模の制約を受けやすく、複雑な推論では見劣りする場面がありえます。また出力はあくまで検証前の仮説であり、鵜呑みにすると誤った改善につながりかねません。定型的な要約や報告下書きの支援に用い、判断は現場で確かめる、という位置づけが誠実だと考えます。
機微な生波形は工場内に留め、月次の集約値のような報告に必要な最小限だけを、経路と粒度を明示して外へ出す、という線引きが一つの考え方だと考えます。どのデータがどう出るかを図にして情報システム部門と共有しておくと、監査や社内説明の場面で疑義を防ぎやすくなります。なお報告義務の具体的な数値・適用範囲は、所管省庁の最新の公表資料でご確認ください。
生波形など機微データは各拠点内に閉じつつ、比較に必要な原単位や集約値だけを限定的に集める、という折衷が現実的になりうると考えます。ここは『外に出せないデータ』と『拠点比較したいニーズ』がぶつかる点なので、データの仕分けの結論が設計を左右します。全拠点一律ではなく、何を守り何を許容するかを拠点ごとに決める前提で設計するのがよいと考えます。
クラウドに送れないという制約は、省エネや原単位管理を諦める理由にはなりにくいと考えます。まずは対象設備を数台に絞り、外部送信ゼロで原単位を可視化できるかを現物で確かめるところから。自社の制約と設備に即した構成を一緒に整理します。
工場内完結の構成について相談する