なぜ「破壊者」と呼ばれるのか──課金の単位を変えた
産業ソフトウェアの価格は伝統的に、タグ数（接続する信号点数）・クライアント数・ユーザー数で決まってきました。工場を広げるほど、画面を増やすほど、費用が積み上がる構造です。Inductive AutomationのIgnitionはこれを壊しました。1サーバライセンスで、タグ・接続・同時デザイナー・Webクライアントがすべて無制限。端末を10台増やしても、ラインを1本足しても、ライセンス費は変わりません。
この価格体系が効くのは導入の力学です。従来モデルでは「まず対象工程を絞って費用を抑える」という交渉が導入設計を歪めがちでした。無制限モデルでは、小さく始めて広げる際の増分費用がほぼ読めるため、展開計画を技術都合だけで組めます。MES業界全体がサブスクリプションへ移行しつつある中でも（MESライセンスの地殻変動の記事）、「無制限」を明示するIgnitionの体系は依然として異質であり、それが「破壊者」と呼ばれる理由です。
技術面ではSQL・Python・OPC UA・MQTTというオープン技術に立脚し、インストールから開発開始までが速いことも、試してから決める文化と相性よく働いてきました。
Ignition単体はMESではない──Sepasoftが埋める層
重要な整理として、Ignition本体はSCADA/HMI/IIoT基盤であって、MESではありません。工程実績・OEE・トレーサビリティ・スケジューリングといったMES/MOMの業務機能は本体に含まれず、それを埋めるのがSepasoftのMESモジュール群です。
Sepasoftのモジュールは、OEE／ダウンタイム、Track & Trace（トレーサビリティ）、SPC（統計的工程管理）、バッチ手順、有限能力スケジューリング、SAP ERPインターフェース、多拠点統括のMES Enterprise、分析基盤SepaIQなどで構成されます。最大の特徴は、SCADAの画面とMESの実績管理を同一の開発環境（デザイナー）で作れることです。通常は別製品・別ベンダー・別画面になるHMI/SCADA層とMES層の間の統合作業と二重開発が、この構成では原理的に発生しません。Sepasoft側もタグ・クライアント数無制限のライセンスを踏襲しており、拠点や端末の追加費用が読みやすい点は共通です。
この組み方が向く工場・向かない工場
Ignition＋Sepasoftは「安いMESパッケージ」ではなく、「設計と実装を自分たち（または実装パートナー）が握る構築基盤」です。向き不向きははっきりしています。
向くのは、設備データ収集から始めてMES機能へ段階的に育てたい工場、端末・拠点数が多くユーザー課金型ではコストが合わない工場、そして社内または近隣に実装を担えるエンジニアリング力がある組織です。OEEモジュールだけで始め、後からTrack & TraceやSPCを足す進め方が製品構成として自然にできます（MESのスモールスタートの記事）。
向かないのは、業務プロセスまで含めた完成品を求める組織です。パッケージMESが持つ業種テンプレートや帳票群に相当するものは、この構成では実装して作ります。つまり浮いたライセンス費は、相応のエンジニアリング費に振り替わります。
UNS時代の追い風──「前段のデータ基盤」としての価値
近年この構成への注目を押し上げているのが、Unified Namespace（UNS）というアーキテクチャ潮流です。工場の全データをMQTTブローカー上の統一名前空間に発行し、MESもERPも分析基盤もそこを参照する設計で、IgnitionはOPC UAとMQTT（Sparkplug）を標準搭載するため、UNSのハブとして使われる代表的な製品になっています（Unified Namespaceの記事、MQTT Sparkplug Bの記事）。
この文脈では、Ignitionは「MESの代替」ではなく「MESの前段レイヤー」です。実際、欧米ではIgnitionでデータ収集とUNSを整備し、MES機能はSepasoftで組む拠点もあれば、別のMESパッケージを上に載せる拠点もあります。日本企業にとっての現実的な使い方も同じで、既存MESを持つ工場が設備接続層・可視化層だけIgnitionで刷新する部分適用は、全面置き換えより導入障壁が低い入り口になります。「組むMES」という選択肢は、コンポーザブルMESという業界の大きな流れの、最も実装が具体的な形のひとつと言えます（コンポーザブルMESの記事）。
よくある質問
IgnitionとSepasoftは同じ会社の製品ですか？
別会社です。IgnitionはInductive Automation、MESモジュールはSepasoftという独立企業の製品で、SepasoftがIgnitionプラットフォーム上で動作するサードパーティモジュールを開発・販売する公式な関係にあります。契約・サポートは製品ごとになるため、導入時は両社（および実装パートナー）の責任分界を確認する必要があります。
日本の工場でこの構成は現実的ですか？
技術的には可能ですが、実装パートナーの確保が前提条件です。両製品とも日本では国内パートナー経由の提供で、日本語ドキュメントや国内導入実績の厚さは欧米と同等ではありません（2026年8月時点の公開情報での評価）。海外拠点、特に北米拠点で先行採用して社内に知見を作り、その後に国内適用を検討する順序が、リスクの小さい進め方です。北米ではこの構成を扱えるSIerの層が厚いため、拠点主導の導入が成立しやすい環境にあります。
