「三菱Qシリーズ生産終了」の全体像Business Impact 製造現場・ITベンダー・SIer・クラウド、各プレイヤーへの影響を俯瞰する
工場界隈のSNSタイムラインが「Qシリーズ生産終了マジ?」でザワついている。だが本当に読むべきなのは、"いつ壊れるか"ではなく"いつ計画を立てられるか"だ。MELSEC-QのEOLは、日本の製造現場に「設備更新の強制イベント」を発生させ、その波紋は現場(エンドユーザー)・三菱電機・SIer・ITやクラウドのベンダーまで広く及ぶ。単なる部品交換にとどまらず、IT/OT融合とデータ基盤刷新という産業全体の構造変化の引き金になる。事実ベースで、その全体像を整理する。
1. まず事実 — Qシリーズは「型式ごと」に段階的EOL
三菱電機のMELSEC-Qシリーズは、後継のiQ-Rシリーズへ「システムとして」置き換わる位置づけで、型式ごとに段階的な生産終了が進行している [1]。重要なのは、"Qシリーズ全部が同時に終わる"わけではない点だ。修理対応期限は型式ごとにバラバラで、そこが最大の落とし穴になる。
公式の技術通報を整理すると、冗長化CPU・周辺(Q12PRHCPU/Q25PRHCPU/Q65WRB/QC10TR/QC30TR)は受注終了2022年8月31日→生産中止2022年9月30日、修理対応期限は2029年9月28日(生産中止後7年)である [2]。一方、後発のユニバーサルモデルQCPU(14型式)は受注終了2026年9月30日・生産中止2026年10月30日・修理対応2033年10月31日まで延び、終了理由は「一部部品の入手困難で生産体制の維持が難しい」ことによる [3]。

C Controller(Q06CCPU-V)は2029年5月30日、MELSECWinCPUは2029年3月30日 [4]。中核モジュールの修理対応期限が「概ね2029年」に集中する一方、型式によっては2033年まで延びるため、リプレース計画では型式別通報の個別確認が必須となる。
2. なぜ「単純載せ替え」で終わらないのか
Q→iQ-Rは、プラモの部品交換のようにはいかない。CPU構成・二重化方式・ベース寸法・ネットワーク・エンジニアリングツール(GX Works3)がQと異なるため、"そのまま挿し替え"は基本できない [5]。設計更新+ツール更新+試験の三段構えが必要になり、これが「見積で椅子から落ちた」の元凶だ。
だが、この"どうせ作り直し"こそがクラウドベンダーの入口になる。三菱電機自身がiQ-Rを「生産現場のデータを収集・分析する製品」と位置づけ、情報のデジタルトランスフォーメーションが不可欠だと述べている [6]。つまりPLC更新の意思決定に、最初から「データ活用」の議論が組み込まれている。
3. 市場規模 — 更新需要を下支えする成長基調
リプレース需要の背景市場は大きい。世界PLC市場は2025年に約126.6億ドル、2034年に約218.3億ドルへ拡大する見込み [7]。日本のファクトリーオートメーション・産業制御市場は2035年までCAGR 9.9%で378億ドルに達する見込みで、リプレース需要が下支えする [8]。

更にその上流にある市場も成長していることが読み取れる。世界のスマートファクトリー市場は2024年約1,027億ドルから2033年に2,343.6億ドル、CAGR 9.6%と予測される [9]。産業IoT市場は2025年の約5,144億ドルから2035年に約2兆4,302億ドルへ、CAGR 16.8%で拡大する [10]。

4. 「2025年の崖」との合流 — OT側の崖が来る
ここに政策の文脈が重なる。経産省の「2025年の崖」は、レガシーシステムを放置するとDXが実現できず、2025年以降に最大で年間12兆円の経済損失が生じる可能性を警告したものだ [11]。しかもこの警告は2018年のDXレポートが起点であり、2025年経過後も経産省「レガシーシステムモダン化委員会」で刷新が継続課題であることが示されている [12]。
この崖は当初ITの基幹系を主眼としていたが、製造現場では制御系(OT)のレガシーPLC老朽化が並行する。Qシリーズの修理対応が概ね2029年で区切られることで、ITレガシー(2025年の崖)とOTレガシー(Q修理期限〜2029年)が時期的に重なり、日本製造業では2020年代後半に制御系リプレース+DX投資が集中する構造的な需要窓が形成される。
5. なぜ更新が「クラウド移行の同時検討」を誘発するのか
根本理由はIT/OT融合(コンバージェンス)にある。これは、業務ネットワーク・データ基盤・クラウド(IT)と、PLC・SCADA・DCS・HMI(OT)という歴史的に分断されてきた二領域を統合することを指す [13]。PLCのプロトコル(OPC UA対応など)が更新される瞬間は、まさにOT側の「接続点」が刷新される瞬間であり、クラウドと結線する最適タイミングとなる。
iQ-R世代は、更新時に「現場とITの協調」を織り込むよう設計されている。先進情報モジュールはIT系とPLCの間のデータ連携を実現し、現場とIT側の協調を可能にする [14]。更新をきっかけに、OPC UA/MQTT対応・SCADA近代化・予知保全・データ収集基盤刷新という4テーマが相互連動し、一体で検討される。
6. 技術的な核心はプロトコル変換層 — クラウド接続の実際
更新後のOTデータをどこへ流すかは複数の選択肢があるが、いずれもプロトコル変換層が要になる。一例として、AWSはGreengrass(エッジランタイム)+IoT SiteWise(産業データモデリング)+IoT Core(汎用接続)の階層構成でOTデータ取り込みを提供し、SiteWise EdgeはModbus等のレガシープロトコルソースをゲートウェイ経由で取り込む [15]。iQ-RのOPC UAサーバモジュールと自然に結線できる。
ただし本質的な難所は「プロトコル変換層」にある。MELSEC固有のMC Protocolを、現場のタイミングやコンテキストを失わずにクラウドの取り込みパイプラインへ橋渡しすることが核心で、汎用IoT SDKでは接続断・データ不整合に陥る [16]。推奨される中核パターンは「OPC UA + MQTT」の組み合わせで、これが近代的な産業データパイプラインの事実上の標準アーキテクチャとされる [17]。

プロトコルサポートが決定的な差別化要素で、Modbusが約40%のシェア、OPC UAが年25%成長という状況にある [18]。この変換層こそ、Greengrass+SiteWise+データレイク/生成AIというクラウドスタックが価値を発揮する領域だ。
7. 競合構図 — ベンダーごとの立ち位置
OT-to-cloud領域は各ベンダーの主戦場になっている。特徴を整理する。
| ベンダー | 中核アプローチ | 特記事項 |
|---|---|---|
| AWS | Greengrass+SiteWise+IoT Core | ハード一体型Monitronは2024年10月に新規提供終了 [19]。AVEVAと複数年SCAでOT-SIer網を強化 [20] |
| Microsoft Azure | Azure IoT Operations(Arc対応K8s上の統一データプレーン) | 2024年11月GA。OTデータをMicrosoft Fabric連携でIT/OT・AI統合 [21] |
| Google Cloud | Manufacturing Data Engine+Cortex Framework | IoT Core廃止後、データ文脈化に特化。接続層はClearBlade等パートナー依存 [22] |
| 三菱電機 | e-F@ctory / Edgecross(エッジ層) | 「生産現場」「ITシステム」「エッジコンピューティング」の3階層 [23]。設置ベースとエッジ層の主権が強み |
| PTC/AVEVA | 産業ソフト、クラウド中立を装いつつ両陣営 | PTC ThingWorxはAzure寄り [24]、AVEVAはAWSと戦略提携 |
三菱電機はFA機器の設置ベースとエッジ層の主権が強みで、クラウドベンダーはこのエッジ層より上位(データ集約・分析)で価値を出す構図となる。単独で「制御→機械→エッジ→クラウド→業務アプリ」の全域をカバーできるベンダーは存在せず、SIer/専門家との連携が必須という認識が共有されている [25]。
8. 各プレイヤーへの影響と、取るべき動き
EOLの波紋は立場ごとに意味が異なる。まず製造現場(エンドユーザー)内部では、3つの意思決定主体が異なる論理で動く点が最大の難しさだ。
- 工場保全部門(OT側):24時間365日の安定稼働が最優先で、稼働中の設備交換は極めて困難 [26]。EOLは「止まるリスク」の問題で、クラウドは二次的関心。
- IT部門:「2025年の崖」で刷新を迫られるレガシー基幹の当事者。DX推進側だが、OT設備の停止権限は持たない。
- 経営層:投資対効果と経営リスク(人手不足・技能継承)で判断 [27]。
この3者の合意形成が、EOL対応が単純に進まない根本原因だ。保全部門には「止めないこと」、IT部門には「データ統合とレガシー刷新」、経営層には「人手不足解決とROI」と、それぞれ響く軸が違う。どのプレイヤーが提案するにせよ、単一の技術論では3者の合意は成立しない。
越えるべき障壁と打ち手
最大の障壁は「止められない工場」と「セキュリティ懸念」だ。前者には本番ラインを止めないデータ収集のみの非侵襲アプローチから入り、EOL更新のタイミングにデータ収集ゲートウェイを組み込むのが摩擦最小の導入経路になる。後者は、「工場はインターネットから隔離されているから安全」の前提がもはや通用しない現実 [28]を逆手に取り、「クラウド化=統合セキュリティ強化」という文脈でOT専用セキュリティパートナーと組んで懸念を機会へ転換する。
プレイヤー別の立ち回り
エンドユーザー(製造業)は、2029年の修理期限から逆算し、2026〜2028年を計画期と位置づけるのが現実的だ。壊れてからではなく計画的に更新の窓を使えば、単なる延命ではなく「データ活用まで含めた投資」に転換できる。三菱電機にとっては後継iQ-Rへの正当な移行需要であり、e-F@ctoryを軸に現場〜エッジ層の主権を握る好機になる。SIerは設計更新+ツール移行+試験という工数を担う中核で、三井情報のように「IoTプラットフォーム構築支援 on AWS」を提供する連携が既に確立している [29]。ITやクラウドのベンダーは、汎用IaaSではなく製造ユースケース特化のサービスと業界専門知識・専用パートナー網のセットで価値を出す [30]。単独で「制御→機械→エッジ→クラウド→業務アプリ」の全域をカバーできる者はおらず、この構造変化はどのプレイヤーにとっても「連携なしには取れない」性質を持つ。
結論:「Qシリーズ、まだ動いてるから大丈夫」——その油断が2029年前後にデカい請求書になって返ってくる。だがこれは誰か一社の話ではない。EOLの修理期限から逆算できる"更新の窓"は、製造現場にとっては計画的なDXの好機であり、三菱電機・SIer・ITベンダーにとっては協働で取り組む数少ない構造需要だ。壊れてから慌てるのではなく、崖の手前で全体像を描いて動く——それが2020年代後半の製造業に共通する勝負どころになる。
References
- [1] https://eu-assets.contentstack.com/v3/assets/blt5412ff9af9aef77f/blt8646b50eaab6ae11/65f00cf7bb278f04079df6eb/EOL-PLC-240112-1934-SCA_(MELSEC_Q_Series_CPU).pdf
- [2] https://www.mitsubishielectric.com/fa/document/technews/plc/fa-a-0315/faa0315a.pdf
- [3] https://www.mitsubishielectric.com/fa/document/technews/plc/fa-a-0418/faa0418a.pdf
- [4] https://www.mitsubishielectric.com/fa/document/technews/plc/fa-a-0293/faa0293a.pdf
- [5] https://note.com/kawayasblog/n/ndc7e5057df23
- [6] https://www.advance.mitsubishielectric.com/advance/pdf/2023/182_TR3.pdf
- [7] https://www.gii.co.jp/report/fbs1954827-programmable-logic-controller-plc-market-size.html
- [8] https://www.dreamnews.jp/press/0000341013/
- [9] https://www.marketresearch.co.jp/insights/smart-factory-market-straits/
- [10] https://www.precedenceresearch.com/industrial-iot-market
- [11] https://www.brother.co.jp/product/biz/business-navi/column/product-logistic/use41/index.aspx
- [12] https://www.meti.go.jp/press/2025/05/20250528003/20250528003.html
- [13] https://softwaretoolbox.com/resources/what-is-it-ot-convergence
- [14] https://www.mitsubishielectric.com/fa/products/cnt/plcr/pmerit/it_connect/index.html
- [15] https://docs.aws.amazon.com/iot-sitewise/latest/userguide/configure-modbus-source.html
- [16] https://snipcol.hashnode.dev/how-to-extract-mitsubishi-melsec-plc-data-to-azure-iot-hub-2026
- [17] https://www.hivemq.com/blog/opc-ua-mqtt-bridge-ot-protocols-industrial-data/
- [18] https://inhandgo.com/blogs/solutions/industrial-iot-edge-computer-buyers-guide-2026-protocols-applications-amp-selection-criteria
- [19] https://aws.amazon.com/es/monitron/features/
- [20] http://www.prnewswire.com/news-releases/aveva-and-amazon-web-services-announce-multi-year-strategic-collaboration-to-accelerate-industrial-intelligence-in-the-cloud-302775669.html
- [21] https://techcommunity.microsoft.com/blog/iotblog/resource-guide-making-physical-ai-practical-for-real%E2%80%91world-industrial-operations/4512224
- [22] https://cloud.google.com/blog/topics/manufacturing/tata-steel-enhances-equipment-and-operations-monitoring-with-google-cloud
- [23] https://www.mitsubishielectric.co.jp/fa/solutions/efactory/
- [24] http://support.ptc.com/help/thingworx/azure_connector_scm/en/thingworx_scm_azure/opc_ua/c_azure_connector_for_industrial_iot.html
- [25] https://biztechmagazine.com/article/2026/08/why-manufacturing-ecosystems-win-building-scalable-partner-architectures-industrial-data
- [26] https://miyoshidenko.co.jp/blog/cubicle/181016
- [27] https://www.upr-net.co.jp/articles/knowledge/iot/case-study-manufacturing-industry/
- [28] https://www.ntt-at.co.jp/column/ot-security-guide.html
- [29] https://www.mki.co.jp/news/solution/20200917_1.html
- [30] https://aws.amazon.com/jp/manufacturing/

