結論：保守が続くOSS MESコアは、確認できた範囲でqcadooのみ
2026年8月時点で、「MESの中核機能（作業指示・実績収集・ロット追跡・品質記録）を備え、かつ開発が継続している」オープンソースプロジェクトとして確認できたのは、ポーランド発のqcadoo MESがほぼ唯一でした。GitHub上で2025年12月5日にバージョン3.1.0がリリースされており、1万7千超のコミット履歴を持つ、中小企業向けの生産管理・製造実行アプリケーションです。ライセンスはGNU AGPLv3です。
一方、検索で「オープンソースMES」として名前が挙がる他のプロジェクトは、確認すると次のいずれかでした。
| プロジェクト | 実態（2026年8月確認） | ライセンス |
|---|---|---|
| qcadoo MES | 中小企業向けMES。v3.1.0（2025年12月5日）。開発継続中 | AGPLv3 |
| Apache StreamPipes | MESではなく産業IoTデータの接続・分析ツールボックス。v0.98.0（2025年12月15日）。開発継続中 | Apache 2.0 |
| Eclipse BaSyx | MESではなくAAS（アセット管理シェル）実装のミドルウェア。Eclipse財団プロジェクトとして継続中 | Eclipse系 |
| industry4.0-mes（中国系） | OSS版はデモ・サポート・質問対応の停止を明記し、商用版へ誘導。実質的に休眠 | 明記なし |
つまり「OSS MES」を検索して出てくるリストの大半は、（1）MESではない周辺ツール、（2）商用版への誘導窓口としてのOSS、（3）休眠リポジトリ、のいずれかで構成されています。「成熟したOSS MESのエコシステムが存在する」という前提そのものが誤りであり、この事実確認が本記事の最大の成果物です。
なぜMESコアはオープンソース化しないのか
ERP（Odoo Community、ERPNextなど）やBI（Grafanaなど）には強力なOSSが育ったのに、MESコアには育っていません。構造的な理由を挙げます。以下は本誌の分析であり推測を含みます。
- 買い手の中心が規制産業・保守的産業である：MESの支出が大きい医薬・自動車・半導体では、監査証跡・バリデーション・長期サポートの保証が調達条件になります。「コミュニティがサポート」では監査に回答できません
- 要件が業種ごとに乖離しすぎている：Webサーバーやデータベースと違い、MESの「共通コア」は薄く、価値の大半が業種固有機能（秤量、SMT実装、バッチレコード）に宿ります。汎用OSSとして開発リソースを集める焦点が定まりません
- 開発者コミュニティが形成されにくい：MESを触るエンジニアの多くはSIerやベンダーの業務として関わっており、個人が自宅で工程実績システムを書く動機は乏しい。OSSを育てる夜と週末の開発力が集まりません
- 収益化パスがサポート販売しかない：MESは導入時の設計・接続工数が本体であり、OSS＋サポートのモデルは結局SI受託と同じコスト構造になります。中国系プロジェクトがOSS版を凍結して商用版へ誘導したのは、この経済性の帰結と読めます
OSSが本当に活きるのは「MESの周辺レイヤー」である
MESコアのOSSが不毛である一方、MESを取り巻くレイヤーではOSSが実務の主役になっています。
- データ収集・接続層：Apache StreamPipesはOPC UA・MQTT・Kafkaに対応し、非エンジニアがデータストリームを接続・分析できるツールボックスとして開発が続いています。Unified Namespaceの構築でMQTTブローカーやNode-REDなどのOSSを使う構成は、欧米では標準的な選択肢です
- 標準実装層：Eclipse BaSyxはAAS（アセット管理シェル）のリファレンス実装として、デジタルツインやDPP対応の実証で使われています
- 可視化・分析層：ダッシュボードやレポーティングは商用MESでもGrafanaなどOSSとの連携が公式機能になりつつあります
つまり現実的なアーキテクチャは、「実行と証跡の中核＝商用MESまたは受託開発」「その前後のデータ配管と可視化＝OSS活用」というハイブリッドです。OSSでコストを下げられる場所は確かに存在しますが、それはMESそのものではありません。
「無料のMES」を探す前に、何のコストを下げたいのかを分解する
OSS MESへの期待の正体は、多くの場合「ライセンス費を削りたい」ではなく「総額が見えない受託開発への不安」です。だとすれば、打ち手はOSSだけではありません。
- ライセンス費が問題なら、中小製造業向けの低価格帯MESやSaaS型の月額製品が比較対象になります
- 作り込みコストが問題なら、ローコード／ノーコードMESが「自社で作る」選択肢を提供します
- ベンダー依存が問題なら、データ可搬性の契約条項で出口を確保する方が、OSSの自己保守より総コストは低くなります
よくある質問
OdooやERPNextの製造モジュールはMESとして使えませんか？
生産指図・作業オーダー・簡易的な工程実績の記録までは可能で、小規模工場の「生産管理のデジタル化」には現実的な選択肢です。ただし設備接続、リアルタイムの実績収集、系譜（ジェネアロジー）追跡、監査証跡といったMES固有の機能は限定的で、ERPの製造モジュールとMESは守備範囲が異なります。この線引きは要件定義の段階で明確にすべきです。
OSS MESが将来成熟する可能性はありますか？
可能性は否定しませんが、本記事で挙げた構造要因（規制産業中心の需要、業種依存の強さ、開発者コミュニティの不在、収益化の難しさ）は短期に解消しないと考えます（推測）。むしろ現実的なシナリオは、MESコアの商用が続く一方で、データ配管・標準実装・可視化のOSS領域が拡大し、商用MESの守備範囲が相対的に縮むことです。OSSの動向を追うならMESコアではなく周辺レイヤーを見るべきです。
