ハノーバーメッセ2026 OPC Foundationブースでその全体像を一気に把握 — セキュリティからAI・FX・Safetyまで #HM26
「標準規格のブースがここまで大きく設置されている、これこそがハノーバーメッセの醍醐味やと心底思う」
ハノーバーメッセ2026の3日目、OPC Foundationのブースを訪問してきました。会場の片隅に技術団体のブースがあるのだろう、くらいに想像していたのですが、実際は 予想を遥かに超える大規模な展示 。Process Industry向けのOPAアーキテクチャから、OPC UA over MQTT、Cloud Library、AI向け情報モデル、Field eXchange、Safetyまで、現在のOPC Foundationが手を伸ばしている領域がほぼ全て網羅されている空間でした。
しかも今回、特に幸運だったのが、 横河電機の方にブース内を丁寧にご案内いただけた こと。OPC Foundationブースは複数のメンバー企業の展示が並んでいる構成になっていて、その中で横河電機が「Open Process Automation（OPA）」というオープンシステムのコンセプトを大きく打ち出していたのが目を引きました。
本記事は、OPC UAという規格の全体像と、横河電機が深く関わっているOPAの取り組みを軸に、ブースを巡りながら見聞きしてきた内容をまとめていきます。
なぜ今、OPC UAが製造業の共通言語になりつつあるのか
OPC UAは、製造業のIT-OTを繋ぐ通信規格として、 いまや事実上のデファクトスタンダード になりつつあります。ハノーバーメッセ会場を歩いていても、主要ベンダーのブースでは「OPC UA対応」が共通の前提として語られている空気感が、随所で感じられました。
今年のハノーバーメッセで特に印象に残っていたのが、ヨーロッパ圏でのOPC UAの普及スピード感です。アテンドいただいた横河電機の方の言葉を借りると、こんな話がありました。
特に欧州では、OPC UAの採用がかなり進んできています。さらに、EU CRAの本格適用が近づいており、今後はセキュリティをしっかり考慮していない製品は、市場で受け入れられにくくなるだけでなく、規制上の問題にもなり得ます。
そう考えると、認証や暗号化、証明書管理などを標準的に扱えるOPC UAは、セキュリティ面で非常に重要な技術になっていくと思います。
EU CRA（Cyber Resilience Act） というのは、欧州で施行される「サイバーレジリエンス法」のことで、デジタル製品にセキュリティ要件を課す規制です。こうした流れの中で、セキュリティ機能が組み込まれているOPC UAは、欧州製造業におけるセキュアな産業通信の有力な選択肢として、存在感を高めています。
横河電機のOpen Process Automation — 「特定ベンダーに縛らないシステム」を推進
ブースの中で個人的に一番驚いたのが、横河電機が「Open Process Automation（OPA）」というオープンシステムのコンセプトを大々的に打ち出していたことです。
OPAというのは、ざっくり言うと 「特定ベンダーに縛られないプロセスオートメーションシステム」 を実現するためのコンソーシアム活動です。元々は ExxonMobilが推進元 となって、オイル＆ガス系の事業者を中心に「特定ベンダーロックインから脱却したい」というニーズから立ち上がった取り組みで、その仕様の中核として通信プロトコルにOPC UAが採用されています。
横河電機の方の説明をそのまま引用させていただくと、こうなります。
弊社は従来から、専業の産業システム領域に強みを持っています。たとえば横河の既存システムでは、自社の制御ステーション、自社のHMI、自社のエンジニアリング環境を組み合わせ、安定性と信頼性を重視したシステムを提供してきました。
一方で、今回目指している方向性は、それとは少し異なります。従来型の産業システムは、導入後に特定ベンダーの製品体系に依存しやすく、結果として「一度入れると他の選択肢に移りにくい」という印象を持たれることがあります。
これに対して、私たちが提案したいのは、オープンシステムという考え方です。特定のベンダーに過度に依存するのではなく、複数のベンダーの機器やソフトウェアを柔軟に組み合わせながら、お客様にとって最適なシステムを構築するというアプローチです。
つまり、従来のように「ベンダーが決めた枠組みにお客様を合わせる」のではなく、「お客様の設備や運用に合わせて、必要な技術を選択できる」産業システムを実現しようとしています。
これは率直に驚きました。日本の製造業ベンダーの文脈だと、自社のDCSや制御ステーションでお客様を囲い込むビジネスモデルが王道で、そこを自ら崩しに行く取り組みを大々的に打ち出している、というのはなかなか思い切った話です。
実際にブースには、横河電機のコントローラーと他社（Phoenix Contactなど）のデバイスが並んで置かれていて、メーカーがバラバラの機器同士が、OPC UAを共通言語にして同じシステムとして動作しているデモが展示されていました。
機器も全部バラバラだけど、みんなOPC UAを喋るから、機器がバラバラでもちゃんとそれぞれ通信できます。テクノロジーも全然違っていて、従来の制御システムではなくコンテナ化されている。
コンテナ化された制御アプリケーションがOPC UAで疎結合に繋がる、という構成は、IT寄りのエンジニアにとっても親しみやすい設計で、OTのアーキテクチャがITの世界観に近づいてきていることを実感しました。
横河電機がOPAに関わり始めたのは 2016年 。日本国内ではOPAに本格的に取り組んでいる会社は他にほぼなく、横河電機が突出して先行している領域だそうです。さらに、このOPAのオープンシステム向けに新設された専用認証（O-PAS向けのOPC UA認証）を、 横河電機が世界で初めて取得している とのこと。
O-PAS標準では、オープンな制御システムを実現するために、通信基盤としてOPC UAを採用し、その上にO-PAS向けの情報モデルを定義しています。
弊社のOpreX Open Automation SI Kitは、このO-PAS標準で定義されたOPC UAプロファイル、OCF-001: O-PAS Connectivity Frameworkへの適合認証を、プロセス産業で初めて取得しました。
この認証は、OPC UAによる標準的な通信に加え、O-PASに基づく情報モデルと相互運用性に対応していることを示すものです。つまり、特定ベンダーに依存しないオープンシステムを構築するうえで、重要な技術的マイルストーンになります。
OPC UAという技術規格と、オープンシステムという思想・コンセプトの両方が組み合わさった領域に、日本のベンダーである横河電機が早い段階から参画し、認証取得という具体的な形でも先頭を切っているというのは、個人的にとても印象的な事実でした。
横河電機がOPAでプロセスオートメーション領域を中心に展開しているのも、もともと横河電機のDCSが強いのがプロセス領域だからだそうで、技術的なバックグラウンドと、新しいビジネスモデルの方向性がきれいに重なっているのは納得感のある展開だと感じました。
OPC UAのセキュリティ — Modbus・MQTTSとの比較
ブース全体を通して何度も話題に上がっていたのが、OPC UAのセキュリティ性です。
OTの世界で長く使われてきたModbusと比較すると、OPC UAのセキュリティ的な優位性ははっきりしています。横河電機の方の説明をまとめると、こんな構図でした。
- Modbus: 従来型のModbus TCPでは、プロトコル自体に暗号化や相互認証の仕組みが組み込まれていないため、ネットワーク上の通信内容が見えやすく、アクセス制御を別の仕組みに頼る必要がある。
- OPC UA: OPC UAは、証明書ベースの認証、メッセージ署名、暗号化を標準仕様として備えており、適切に設定すれば、なりすまし・盗聴・改ざんに対する防御層を通信プロトコルのレベルで構築できる。
従来型のOT通信では、ネットワークに入られてしまうと、通信内容を覗かれたり、不正なコマンドを送られたりするリスクがありました。特に暗号化や相互認証を持たないプロトコルでは、通信保護をネットワーク分離やファイアウォールなど外側の仕組みに頼る必要があります。
一方、OPC UAは、証明書ベースの認証、メッセージ署名、暗号化といった防御層を仕様として持っています。つまり、単に「ネットワークを守る」だけでなく、通信そのものを守る設計になっている点が大きな違いです。
クラウド連携のシナリオでも、MQTTSで暗号化することは可能ですが、OPC UAはさらに踏み込んで、 鍵管理の仕組みやメッセージ自体の暗号化を体系として持っている のが強みになっています。
証明書管理（GDS）— 工場単位、ライン単位、CA of CAまで
OPC UAのセキュリティを支える証明書管理の話も、現場で運用に悩む人にはとても刺さる内容でした。
工場内には大量のデバイスがあり、それぞれに個別に証明書を発行・更新していたら、運用が破綻するレベルの工数になります。OPC UAでは、これを解決するために GDS（Global Discovery Server） という仕組みが用意されています。
全てのデバイスで証明書を個別に交換・更新しようとすると、接続相手ごとの信頼設定や、有効期限切れに伴う更新タイミングの調整が必要になり、台数が増えるほど運用負荷が大きくなります。そうした証明書の発行・更新・信頼リスト配布を集中的に管理できる仕組みとして、GDSが用意されています。
工場単位でGDSを立てることもできるし、ライン単位で構成することもできる。さらに、 CA of CAという階層構造 も組めるので、工場の上にさらに「グループ全体の親玉」のような管理階層を作れる、という話でした。
工場単位でもできますし、ライン単位でもできます。そこはデバイスの数とどう管理したいか次第。さらに、CA of CAなんていうこともできます。工場のさらに上に、グループ全体の親玉のような階層を置ける。
これは大規模工場・複数拠点を抱える製造業のお客様にとって、証明書管理の現実解として非常に効きそうな仕組みでした。
OPC UA for AI — 情報モデルとAIの親和性
ブース後半に展示されていたのが、OPC UA for AIという、OPC UAの情報モデルをAIに活用しやすくする取り組みです。
OPC UAの強みのひとつが、単なる通信プロトコルではなく、 データ構造そのものを「情報モデル」として標準化している 点にあります。センサーの生データだけが流れてくるのではなく、 タグ付け・意味付けされた構造化データ としてやり取りされるので、データを受け取った側が意味を理解しやすくなる、という設計思想です。
これがAIとの相性が良い、というのは直感的にも分かりやすい話です。横河電機の方の言葉を借りると、
情報モデル自体は、もともとAIのために作られたというより、装置やシステムごとにバラバラだったデータの意味を、みんなで揃えた方がいいよね、という考えから整備されてきたものです。結果的に、構造化されていて意味付けもあるので、AIとも相性のいいデータ構造になっていますよね。
センサーから値だけ吸い上げて、意味付けはクラウド側で別途やる、というのが従来のIoTのパターンでしたが、OPC UAでは、標準化された情報モデルを使うことで、意味付けされた構造化データを扱いやすくなるため、後段のAI処理を進めやすくなる。
機器の状態センサーデータと稼働率を紐付けて分析する、といったユースケースを実装するときに、情報モデルが標準化されているメリットは大きいと感じました。
ただし、現実の運用では「OPC UAでデータを上げて、というのは分かったが、何のためにそのデータを上げるかが見えていない」という装置メーカー側の悩みもセットで聞こえてきました。
よく聞くのは、「OPC UAでデータを上げてほしい」と言われるものの、そのデータを何のために使うのか、装置メーカー側から見るとまだ十分に見えていない、という声です。
これは日本の製造業のお客様の現場感覚にも非常に近い話で、「規格は揃えました、それで何ができるんですか？」という問いに対して、ユースケース側の整備が追いついていない、という構図はまだまだ各所で残っています。
OPC UA Cloud LibraryとCloud Initiative Reference Architecture
クラウド時代を見据えた取り組みとして、OPC UA Cloud LibraryとUA Cloud Initiative Reference Architectureも展示されていました。
UA Cloud Initiative Reference Architectureは、クラウドでOPC UAを活用する際の参考アーキテクチャやリファレンス実装を公開するもので、MES、ERP、時系列データベース、可視化（Grafana等）まで含めた構成例が示されています。
クラウドでホストするときに、データベースも含めてOPC UA全体的にこんな感じでアーキテクチャを組んだら、いい感じで実装できそうだな、という雰囲気を醸し出している。クラウドの中でOPC UAの情報モデルを活用するときに必要な、Information ModelやAddressSpaceを共有・再利用しやすくする取り組みです。
クラウド上にゼロから組み立てると意外と悩むIT-OTの繋ぎ込み部分について、参考実装が用意されているのは、特に最初の一歩を踏み出したいユーザーにとってありがたい構成です。
ワーキンググループのメンバー一覧を見ると、 主要なクラウドベンダーがほぼ揃っていて 、OPC UAが「OTの中だけで閉じる規格」ではなく、 クラウドエコシステムとの接続を前提に進化している ことが見て取れます。
OPC UA via REST — REST APIでアクセスできるプロトタイプ
個人的にブースで一番テンションが上がったのが、OPC UA via REST、つまりREST API経由でOPC UAのデータにアクセスできるプロトタイプの展示です。
OPC UAは元々、OT領域で広く使われる標準プロトコルなので、IT側のエンジニアからすると「触れるまでの敷居がそれなりに高い」という印象がありました。それが REST APIで叩けるようになる と、AWS側のサービスでも、 API Gatewayやロードバランサーといった既存のIT基盤と組み合わせやすくなる 、という世界が見えてきます。
もしOPC UAサーバーの機能や産業データをREST APIとして呼び出せるようになれば、クラウド側では既存のIT基盤と組み合わせやすくなります。たとえばAWSであれば、API Gateway、ロードバランサー、認証・認可、監視といった、一般的なWeb API向けのサービス群と接続しやすくなります。
OPC UAをそのまま受けようとすると、IoT Coreのような専用のサービスだけでは扱いきれないケースも多く、SiteWiseのような別系統のサービスを組み合わせる必要が出てきます。これがRESTで叩けるなら、より汎用的なAWSのサービス群でハンドリングできるようになる。
方向性としては非常に魅力的ですが、現時点ではまだプロトタイプ的な段階に近く、本格的な実装事例はこれからだと思います
と、ご案内いただいた方も笑いながらおっしゃっていて、まだプロトタイプ段階ですが、夢のあるアーキテクチャです。実装が広がってくると、IT系のエンジニアにとってのOPC UAの敷居が一気に下がる可能性を感じました。
Digital Product Passport with OPC UA — トレーサビリティの規格化
欧州主導で進んでいるDigital Product Passport（DPP）の文脈でも、OPC UAがインフラとして組み込まれています。
DPPは、製品ごとに「どこで・誰が・どのように」作ったか、原材料から カーボンフットプリントまでのトレーサビリティ情報 を、デジタルに紐付けて流通させる仕組みです。SAPブースでもDPPは大きく取り扱われていましたが、 その情報を機器側から拾い上げるプロトコル層として、OPC UAが選択肢のひとつとして用意されている 、という構図です。
製造現場で発生する製造記録・品質データ・トレーサビリティ情報を、OPC UAの情報モデルに乗せて上位に流す、という流れがそのままDPP対応のインフラとして使える、というのは、規格が早期から押さえているからこその強みでした。
OPC UA for Field eXchange（FX）— コントローラー同士がフラットに通信する世界観
ブース後半に展示されていて、これはまだあまり日本では知られていないのでは、と感じたのが、OPC UA for Field eXchange（FX）です。
OPC UA FXは、 コントローラー同士が「フラットに」OPC UAで通信するための拡張規格 です。従来のOPC UAは、基本的にTCP/IPの上に乗ったクライアントサーバー型でしたが、 フィールド機器が大量にネットワーク参加するシーンでは、それでは捌ききれない 。
さすがにデバイスがOPC UAを喋るようになってきたら、1台1台、サーバークライアント方式で繋いでいったらセッションが持たない。なので、全部Pub/SubのUDPでやりましょう、と。
クラシックなコントローラーもUDPでPub/Subを喋れるようにして、コントローラー同士が直接OPC UAでやり取りできる仕組みを作っている、というのがOPC UA FXです。
これが何が面白いかというと、従来の制御システムでは「上にボスのようなコントローラーがいて、それを介して情報がやり取りされる」という階層構造が一般的だったのが、FXによってコントローラー同士がフラットに直接繋がる世界観になる、という点です。
FXになると全部フラットに繋がる。ボスはいなくなる、という世界観です。
ブースには、OPC UA FXに対応した各社のコントローラーが並べて展示されていて、 三菱、オムロン、富士電機など、日本のメーカーの製品もしっかり載っていました 。OPC UA FX対応の流れが、すでに日本の主要PLCベンダーにも広がっているのは、現地で並べて見て初めて実感できた事実でした。
旧来のOTアーキテクチャは、上位から下位への階層的なメッセージングが基本でしたが、FXによって徐々にフラットなネットワーク型に変わっていく。これは現場の構成を大きく変える話で、日本でも追いかけておく価値のあるトピックです。
OPC UA Safety — 機能安全領域への拡張
最後に展示されていたのが、OPC UA Safety。機能安全（Safety）領域への拡張です。
OPC UA Safetyは、安全関連の通信をOPC UAの枠組みで扱うための拡張で、 機能安全に求められる確実性・冗長性を満たした上で、OPC UAの情報モデルやセキュリティ機能と統合される 、という位置付けです。
OTの世界では、Safety通信はそれ自体が独立した規格・ベンダー固有プロトコルで実装されてきましたが、ここもOPC UAでカバーする方向に進んでいる、というのが今のOPC Foundationの方向性。 「製造業の通信規格を1本に統一する」 という、ある意味壮大な野心が、Safetyの領域にまで及んでいることが見て取れる展示でした。
OPC UAのデファクトスタンダードとしての優位性と存在感
ブース全体を巡って感じたのは、OPC UAという規格が、当初想像していたよりも遥かに広い領域をカバーする「製造業の共通言語」になっていた、ということです。
- セキュリティ：Modbusとの圧倒的な差。証明書管理（GDS、CA of CA）まで運用設計済み
- クラウド連携：OPC UA over MQTT、OPC UA Cloud Library、Cloud Initiative Reference Architecture
- AI連携：情報モデルが構造化されているのでAIと自然に組み合わせやすい
- REST API化：IT基盤からも素直に叩けるプロトタイプが進行中
- Digital Product Passport：欧州のトレーサビリティ規制への対応基盤
- OPC UA FX：コントローラー同士がフラットに通信する次世代OTアーキテクチャ
- OPC UA Safety：機能安全領域への拡張
これら全てが 「OPC UA」のひと言で括られて、ひとつのブースに同居している というのは驚きですね。
そしてもう一つ強く印象に残ったのが、 横河電機がこのオープンエコシステムの最前線にしっかり立っている という事実です。Open Process Automationを2016年から取り組み、世界で最初のOPA向けOPC UA認証を取得し、自社のDCSビジネスとは別軸で、特定ベンダーに縛られないオープンシステムを正面から提案している。日本の製造業ベンダーがグローバルなオープン化コンソーシアムでこうした位置を獲っているケースとして、私自身もっと知っておくべきだったなと感じました。
SAPブースでもOPC UAは「IT-OT接続の中核プロトコル」として明確に位置付けられていましたし、AWSブースの5層リファレンスアーキテクチャでも、Data層の中核にOPC UAが置かれていました。 ベンダーを問わず、OPC UAが現場の共通言語として収束してきている流れ は、お客様にAI・クラウド活用を提案する立場としても、確実に押さえておきたい潮流です。
OPC Foundationのブースは、規模感としては今回のハノーバーメッセでも上位に入るレベルの巨大ブースで、規格団体の展示としてここまで作り込まれているのは予想外でした。製造業のIT-OT接続に関わる方は、次回ハノーバーメッセに行く際は、ぜひ訪問リストに入れることをおすすめします。
最後に、複雑な規格の全体像を、ITよりの私にも分かるレベルまで丁寧に紐解いていただいた、横河電機の担当者の方に、心から感謝です。本当にありがとうございました。
それでは今日はこのへんで。濱田孝治（ハマコー）でした。
参考資料
- OPC Foundation（OPC UA公式サイト）
- Open Process Automation Forum — The Open Group
- Cloud Initiative — OPC Foundation
- OPC UA FX（Field eXchange）Release Candidate 1 Completed — OPC Connect
- Safety — OPC Foundation
- Ecodesign for Sustainable Products Regulation — European Commission — ESPR / Digital Product Passportを含む
- Open Process Automation™ — Yokogawa Electric Corporation — 横河電機のOPAへの取り組み紹介ページ
- Yokogawa Obtains Certification to O-PAS Standard's OPC UA Profile, an Industry First — Yokogawa Europe — 2026年4月16日付プレスリリース
