SECTION 01PLCとは何か — 半世紀続く産業の心臓部
PLC（Programmable Logic Controller）は、工場の機械を制御するために専用設計された産業用デジタルコンピュータである。1960年代後半に米国Bedford Associates社が「MODICON」として開発し、それまで工場の制御を担っていた電磁リレー盤を置き換えるために生まれた。
現在のPLCは、センサやスイッチからの入力信号を読み取り、あらかじめ書き込まれた制御プログラムを決定論的なスキャンサイクル（通常 1〜10 ms）で実行し、モータ・バルブ・ソレノイドなどのアクチュエータを駆動する装置として、世界中の工場の心臓部に据えられている。
PLCが半世紀以上にわたり産業界の標準であり続ける理由は、単にプログラム可能であることではなく、次の4つの特性を同時に満たす設計思想にある。
出典: Wikipedia: Programmable Logic Controller / TSL Automation: Complete Guide to PLC
SECTION 02PLCのハードウェア構成
一般的なモジュラー型PLCは、複数のモジュールをラックに装着して構成される。各モジュールは独立した機能を持ち、用途に応じて自由に組み替えられる設計になっている。
主要なPLCベンダ
世界市場では Siemens（独 / S7シリーズ）、Rockwell Automation（米 / Allen-Bradley）、三菱電機（日 / MELSEC）、オムロン（日 / SYSMAC）、シュナイダーエレクトリック（仏 / Modicon）などが主要ベンダとして競合している。日本国内のFA市場では三菱電機、オムロン、キーエンス、安川電機などが高いシェアを持つ。
SECTION 03プログラミング言語 — ラダーだけではない
PLCのプログラミング言語といえば「ラダーロジック」を想起する技術者が多いが、実際には国際標準 IEC 61131-3 で5つの言語が定義されている。
| 言語 | 形式 | 特徴・主な用途 |
|---|---|---|
| LD（Ladder Diagram） | グラフィカル | 電磁リレー回路を模した縦書きの梯子状ダイアグラム。ビット論理・インターロックに最適で、最も普及している。 |
| FBD（Function Block Diagram） | グラフィカル | 機能ブロックを線で結ぶ。プロセス制御、PID演算、データフロー処理に向く。 |
| ST（Structured Text） | テキスト | Pascal風の高級言語。演算・条件分岐・複雑なロジックに強い。近年採用が増加。 |
| SFC（Sequential Function Chart） | グラフィカル | フローチャート風の状態遷移記述。工程順序制御に最適。 |
| IL（Instruction List） | テキスト | アセンブリ風の低水準言語。IEC 61131-3 第3版（2013）で非推奨化され、廃止傾向。 |
実務上は ビット論理とインターロックはLD（ラダー）、複雑な演算と状態遷移は ST や SFC という混在運用が一般的である。ただしベンダ間で方言が大きく、三菱の GX Works で書いたコードを Siemens TIA Portal にそのまま移植することはできない。これがエンジニアリングコストの大きな要因になっている。
SECTION 04通信プロトコル — レイヤを分けて理解する
「Ethernet」「I/O」「CC-Link」「PLCリンク」といった用語はしばしば混在して語られるが、これらは 異なるレイヤ に属する概念であり、並列に並べて比較することはできない。
| 用語 | レイヤ | 位置づけ |
|---|---|---|
| Ethernet | 物理層 / データリンク層 | IEEE 802.3 で規格化された物理的な接続規格。RJ-45 ケーブル、光ファイバ等を含む。 |
| I/O | ハードウェア | 入出力点そのもの。プロトコルではなく、24VDC / 4-20mA 等の電気信号レベル。 |
| PLCリンク | PLC間通信 | 三菱電機の MELSECNET 等、PLC同士でデータを共有する仕組み。 |
| CC-Link | フィールドバス（ファミリ） | 三菱主導のオープン規格群。CC-Link（RS-485系）、CC-Link IE、CC-Link IE TSN（Ethernet系）まで世代がある。 |
産業用Ethernetの主要プロトコル
汎用Ethernet の物理層の上に、産業制御向けの決定論的プロトコルを乗せたものが「産業用Ethernet」である。代表的なものは以下の通り。
| プロトコル | 主導ベンダ | 特徴 |
|---|---|---|
| EtherNet/IP | Rockwell 系 (ODVA) | CIP プロトコルを Ethernet に乗せたもの。北米で広く普及。 |
| PROFINET | Siemens 系 (PI) | 欧州標準。決定論的なリアルタイム通信を実現。 |
| EtherCAT | Beckhoff 系 (ETG) | 超低遅延（マイクロ秒級）。サーボモーション制御に強い。 |
| CC-Link IE TSN | 三菱電機系 (CLPA) | 最小通信周期 31.25μs。日本国内で広く採用。 |
| Modbus TCP | Schneider / オープン | シンプルで軽量。決定論性は低いが導入が容易。 |
| OPC UA | OPC Foundation | 上位IT連携の標準。製造現場とITシステムの統合に必須。 |
SECTION 05PLCとPC／Jetsonの本質的な違い
汎用性ではPC（Jetson含む）が圧倒的に勝る。しかしPLCが消滅しないのは、両者が そもそも異なる仕事に最適化された装置 だからだ。
両者の関係を分かりやすく例えると、PLCは「街中の信号機」、PC／Jetsonは「スマートフォン」 に近い。
信号機の本質は「決まった動きを、絶対に間違えず、止まらずに続ける」こと。誰も派手な機能を期待しないし、毎年アップデートも要らない。だが信号機が1基止まれば、交差点はパニックになり、事故が起きる。PLCも同じで、地味で単機能だが 「絶対に動き続けること」が存在価値 である。
一方 スマートフォンは「何でもできる、新しいアプリを次々入れられる、AIも動かせる」 ことが本質。だが時々フリーズするし、5年で買い替える。Jetsonも同じで、最新のVLMや画像処理を載せられるが、24時間365日・10年間ノンストップで信号制御を任せるには向かない。
人体に例えるなら、PLCは「自律神経・反射神経」、PCは「大脳」 に近い。心臓を止めないこと・反射的に手を引っ込めることは自律神経が担い、考えたり判断したりすることは大脳が担う。両方あって初めて人は動く。工場も同じで、PLC（反射）とPC／AI（思考）の役割分担が前提となる。
決定論的制御に特化
- 応答時間が ms 単位で 保証
- RTOS + 専用ハード設計
- 機能安全認証取得
- 10〜20年の稼働実績
- 産業用 I/O 直結
汎用処理・AI推論に特化
- Ubuntu / Linux ベース
- GPU による画像処理・AI
- 応答時間の最悪値は 非保証
- 豊富なソフトウェア資産
- 進化速度が速い
ここで重要なのは、「Jetsonがリアルタイム制御に向かない」 という技術的事実である。標準のLinuxはソフトリアルタイムであり、カーネルスケジューラのジッタやI/O待ちで応答時間がばらつく。RT-Linuxパッチを適用すれば改善するが、それでもPLC同等の決定論的保証は得られない。
SECTION 06PLCが必要な理由 — 4つの存在条件
PLCが必要かどうかは、次の4つの軸のうち 一つでも当てはまるか で判定できる。汎用PCで代替できない領域は、この4軸のいずれかに該当する。
| 判定軸 | 内容 | 該当する代表ケース |
|---|---|---|
| ①決定論性 | 応答時間が ms / μs 単位で保証される必要がある | サーボ多軸同期、プレス機、印刷機、高速搬送 |
| ②機能安全認証 | 人がケガする危険を防ぐための国際規格認証が必要 | 安全扉、非常停止、両手操作スイッチ、ロボット周辺 |
| ③長期稼働 | 24/365 稼働 + 10年保守を前提とする基幹設備 | 生産ライン全体の制御、コアプロセス装置 |
| ④既存互換 | 既設備が既にPLCで動いており、触る方がリスク | 既存ラインのほぼ全て（保守互換性の維持） |
ユースケース別判定例
| ユースケース | ① | ② | ③ | ④ | 判定 |
|---|---|---|---|---|---|
| サーボ駆動の組立機 | ○ | ○ | ○ | ○ | PLC必須 |
| プレス機の安全制御 | ○ | ○ | ○ | ○ | セーフティPLC必須 |
| 既存ラインの稼働監視 | × | × | △ | ○ | PLC前提で接続 |
| 視覚検査機（新規構築） | × | × | △ | × | Jetson で代替可 |
| 検査結果による排出機構 | × | △ | △ | △ | アクチュエータ部のみPLC |
| データ収集 → AI分析 | × | × | × | △ | PLCへの接続側として必要 |
「PLCが必要な理由は応答速度だけではない」。応答速度がシビアな現場は実は全体の少数派であり、PLCが残り続ける本当の理由は ②機能安全認証 + ④既存互換 の方が大きい。新規参入者がPLCを置き換えようとして失敗するのは、ほぼ常にこの2軸を軽視するためである。
SECTION 07機能安全認証とは何か
機能安全とは、「装置が壊れても、人が死なないようにする」ための国際規格に基づく設計思想である。単に動作することではなく、故障時にも安全側に倒れる ことを定量的に保証する。
主要な機能安全規格
| 規格 | 対象 | 評価指標 |
|---|---|---|
| IEC 61508 | 電気・電子・PE系の基本規格 | SIL（Safety Integrity Level）1〜4 |
| ISO 13849 | 機械の制御システム安全 | PL（Performance Level）a〜e |
| IEC 62061 | 機械の電気制御の機能安全 | SIL 1〜3 |
| ISO 26262 | 自動車（車載ECU） | ASIL A〜D |
「SIL 3 / PL e」と表記される製品は、1時間あたりの危険側故障率が 10⁻⁷ 未満（1000万時間に1回未満）を保証する設計である。これは認証機関（TÜV、UL等）による第三者試験を経て初めて得られる。
「PCでも認証取得できるか？」
理論上は可能だが、現実的なコストとリードタイムが大きな障壁となる。
- 認証取得コスト: 数千万〜数億円
- 認証期間: 1〜3年
- ソフトウェアも対象: 通常の Linux / Python は対象外、コードを一行ずつ検証
結果として、認証済みのセーフティPLC（三菱、Siemens、Omron等が販売）を購入する方が、コスト・期間ともに圧倒的に有利となる。
「そもそも認証は必要か？」
| ケース | 必要性 | 根拠 |
|---|---|---|
| EUに機械を輸出 | 法的に必須 | EU機械指令 2006/42/EC（CEマーキング） |
| 日本国内の機械（人が触る） | 実質必須 | 労働安全衛生法、厚労省の機能安全推奨 |
| 産業ロボット・プレス機 | 必須 | 業界規格 + PL法 |
| 自動車（車載ECU） | 必須 | ISO 26262 |
| 視覚検査機（人体に直接危険なし） | 対象外 | — |
出典: Wikipedia: IEC 61508 / TÜV Rheinland: 機能安全認証 / 厚生労働省: 機能安全パンフレット
SECTION 08工場におけるPLCの位置 — Purdue 4階層モデル
製造業の現場は伝統的に「Purdueモデル」と呼ばれる4階層構造 で整理される。PLCはこの階層の中で「制御層」に位置し、現場のセンサ群と上位ITシステムを繋ぐ 結節点 として機能している。
重要なのは、PLCが 単に制御を実行する装置ではなく、データのハブ として既にこの位置に「座っている」という事実である。工場のデータを取りたい時に、この結節点を無視することはできない。
SECTION 09設備からデータを取得する3つの方法
既存の工場設備からデータを取得する実装パターンは、大きく3つに分類できる。実務では複数を組み合わせて使うのが一般的である。
PLC内蔵 OPC UA サーバを使う
最新世代のPLC（Omron NX102、Siemens S7-1500、Rockwell ControlLogix等）は OPC UAサーバを内蔵 している。PLCの変数を直接読み出せるため、追加ハードが不要。
[PLC] ──── OPC UA ────▶ [Edge Device / Cloud] ↑ OPC UA Server 内蔵
エッジゲートウェイを後付け
OPC UA非対応のPLCに対して、間にプロトコル変換ゲートウェイを挟む。既存設備への接続では最も一般的な手法。
[Legacy PLC] ── Modbus / CC-Link ──▶ [Gateway] ── OPC UA / MQTT ──▶ [Edge / Cloud]
代表的な製品例:
- Hilscher netIOT Edge Gateway: PROFINET / EtherNet/IP → OPC UA 変換
- BLIIoT BL102: Siemens / Mitsubishi / OMRON / AB / Schneider 対応。100台のPLCから4000データポイントを同時収集可能
- Advantech ADAM-6717、Moxa、Siemens IOT2050、Red Lion FlexEdge DA50D
- MachineMetrics: MTConnect / OPC-UA / Modbus 対応のクラウド型プラットフォーム
PLCを介さずセンサを直接追加
PLCに繋がっていない測定（後付け振動センサ、電力計、温度ロガー等）を別系統で取得する。PLCに触れずに済むため保全部門の許可が得やすい のが利点。
[Wireless Sensor] ── LoRa / WiFi ──▶ [Edge / Cloud]
実務では パターンB（既存PLCからゲートウェイで取得）と パターンC（後付けセンサ）の併用 が現実解となるケースが多い。既存設備のPLCからは稼働状況・生産数・アラーム履歴を、追加センサからは振動・温度・電流などのコンディションデータを取得する設計である。
出典: BLIIoT BL102 PLC Gateway / OPC Connect: Connecting PLCs with OPC UA / MachineMetrics: IIoT Gateways
SECTION 10AI／LLM時代の連携アーキテクチャ
PLCを「置き換える」のではなく、PLCに「ドッキングする」設計が現実解である。さらに重要なのは、ハードウェアの層ではなく その上位の "データを料理する層" に勝ち筋があるということだ。
3つの戦略オプション
| 戦略 | 内容 | 勝ち目 |
|---|---|---|
| A. PLCを置き換える | Jetson + 制御ソフトウェアでPLCの仕事を取りに行く | 低 認証・実績不足が壁 |
| B. ドッキング用ハードを売る | エッジゲートウェイ製品を製造販売する | 中 既存競合が多数 |
| C. データの "料理レイヤ" を取る | 取得は既存ゲートウェイに任せ、VLM/LLMで意味づけ・対処提案を提供 | 高 未成熟領域 |
"料理レイヤ" の具体像
LLMによる製造業データ分析は2024〜2025年に研究・製品化が立ち上がったばかりの新興領域である。すでに F7i.ai、Algomox、MachineMetrics などのプレイヤーが市場形成を始めているが、まだ 確立されたデファクト・ソリューションは存在しない。
| パターン | 処理内容 |
|---|---|
| 異常検知の意味づけ | 数値の異常をLLMが自然言語で説明（例:「振動0.8G、電流上昇 → ベアリング摩耗の前兆」） |
| マルチモーダル統合 | 検査画像 + PLC稼働ログ + 保全記録を統合解釈し、根本原因を推定 |
| 保全コパイロット | 保全員の自然言語問いに、過去事例を検索して回答（「前回同じ症状の時、何を交換した？」） |
| ナラティブ報告 | 1日の稼働ログをLLMが自動で報告書化（朝礼用サマリ等） |
出典: F7i.ai: LLM in Manufacturing 2025 / MDPI: LLM for Predictive Maintenance (2025) / Algomox: LLM in Predictive Maintenance
SECTION 11Nsightのアプローチ — PLCドッキング型 × オンプレLLM
Nsightが提供するのは、既存のPLC設備を活かしたまま、ラズパイ・Jetson・産業用PCを「ドッキング」させて現場データを安全に吸い上げ、オンプレミスのLLMで分析・示唆出しまで自動化する 仕組みである。PLCを置き換えることなく、既存投資を守りながら工場をAI化する設計思想を取っている。
なぜ「ドッキング型」なのか
新規ラインを丸ごと作り変えられる工場は稀である。多くの現場では、10〜20年動き続けているPLCが既に存在し、保全部門も含めてその運用に最適化されている。ここを置き換える提案は、工場側にとって 「リスク」と「移行コスト」 でしかなく、本来得たい「データ活用による改善」までたどり着けない。
Nsightは 既存PLCを尊重する。PLCはそのまま動かし続け、必要な情報だけを Modbus / CC-Link / OPC UA / EtherNet/IP 経由で取り出し、隣に置いた小型コンピュータ（ラズパイ・Jetson・産業用PC）で集約・処理する。現場の制御リスクをゼロに保ったまま、データの価値だけを引き上げる構成である。
なぜ「オンプレLLM」なのか
工場のデータは、企業にとって 外に出してはいけない最重要資産 である。生産レシピ、不良率、稼働パターン、顧客の納品情報 — これらが外部クラウドや海外のLLMサーバを経由することに対し、製造業の経営層・情シス・OT部門の警戒は強い。
Nsightは オンプレミス（工場内）でLLMを動かす 構成を標準としている。Jetson AGX Orin や産業用PCの上で、軽量化された日本語LLMを動かし、データを工場の外に一切出さずに分析・示唆まで完結させる。これにより、セキュリティ・コンプライアンス・通信コスト・遅延の全ての懸念を同時に解消する。
Nsight提供範囲の整理
| レイヤ | 使用ハード | Nsightが提供する価値 |
|---|---|---|
| データ取得 | ラズパイ / Jetson / 産業用PC | 既存PLCのプロトコル（三菱MC / CC-Link / EtherNet/IP / Modbus等）に対応し、現場の制御に影響を与えずにデータを引き出す |
| 視覚検査 | Jetson + 産業用カメラ | VLMハイブリッド検査（ルール + CNN + VLM）。既存PLCに判定結果を返却し、排出機構を駆動 |
| データ統合 | エッジコンピュータ内 | PLC稼働ログ・センサ値・検査画像を同一タイムラインで結合。前処理・正規化 |
| LLM解析 | Jetson AGX Orin / 産業用PC | オンプレLLMによる異常の意味づけ・原因推定・対処提案・自然言語レポート生成 |
| UI / 連携 | タブレット / PC | 保全コパイロット、現場ダッシュボード、既存PLCへのフィードバック |
①既存PLCは触らない（保全部門と保守契約を守る） / ②データは工場の外に出さない（オンプレLLM） / ③制御の責任分界を曖昧にしない（PLC = 決定論的制御、エッジ = AI処理、明確に分離） / ④小さく始めて段階的に拡張（PoCから商用展開まで同一アーキテクチャで）
SECTION 12チーム — 現場知見とセキュリティを束ねる
「工場にAIを導入する」という言葉は数年前から繰り返されているが、現場で機能するシステムを構築するには、AI技術だけでは決定的に不足する。製造現場のドメイン知識 と、OT／ITセキュリティの設計力 — Nsightはこの2つを社内に持つことで、机上の提案ではなく現場で動く実装を届けている。
製造現場の "翻訳者"
キーエンス画像処理事業部にて開発エンジニアとして従事していたメンバーが、製造業の現場と最新AI技術の橋渡しを担う。画像処理機・センサ・PLC連携の実装経験を通じて蓄積された 「現場で何が動くか／動かないか」 の感覚は、机上のAI提案では到達できない領域である。
三菱MC、CC-Link、EtherNet/IP、SLMP等、日本の製造業で多用されるプロトコル群への対応も、この実装経験の延長線上にある。
OT/IT セキュリティの設計力
アクセンチュアにてセキュリティコンサルタントとして従事していたメンバーが、工場データの取り扱い設計を担う。製造業のデータは 機密性・完全性・可用性 の3軸全てが極めて高いレベルで要求される領域であり、安易なクラウド送信や外部API連携は経営リスクに直結する。
ネットワーク分離・アクセス制御・データフロー設計・コンプライアンス対応まで含めた、製造業に最適化されたセキュリティアーキテクチャを設計する。
この2つの強みが組み合わさることで、Nsightは 「現場で動き、かつ安全に運用できる」AI導入 を提供できる。AI技術単独でもなく、セキュリティコンサル単独でもなく、両者を内製化しているからこそ実現できる統合価値である。
SECTION 13まとめ — マクロとミクロの視座
本稿の論点を、マクロ（全体像）とミクロ（実装判断）の2軸で再整理する。
マクロな視座 — なぜPLCは消えないのか
ミクロな視座 — 実装時の判断軸
PLCは半世紀かけて産業に深く根を張った基幹インフラであり、AI時代になっても消滅することはない。重要なのは 「置き換える」ではなく「並走させる」 という設計思想の転換である。
新しい価値は、PLCの上に重ねる "料理レイヤ" — つまり VLM / LLM によってデータに意味を与え、現場の意思決定を加速するソフトウェアの層から生まれる。ハードウェアの戦いではなく、データ解釈と業務改善の戦いに勝負の場所が移っている。
既存PLCにAIを"ドッキング"する取り組み、
ご相談ください。
「PLCのデータを活用したいが、置き換えは現実的でない」
「クラウド送信なしで、工場内で完結する AI 活用をしたい」
「視覚検査と稼働データを統合して、原因分析まで自動化したい」
こうしたテーマに対し、Nsightは PLCドッキング型 × オンプレLLM のアプローチで具体的な解決策を設計します。既存設備への影響をゼロに抑えながら、データを資産に変える取り組みを、小さく始めて段階的に拡張できます。