2026.08.22 プロトコル

OPC UAとは？情報モデルとOPC Classicとの違い・採用判断を実装目線で解説

OPC UAは、産業機器のデータを機種やベンダをまたいで同じ形で読み書きするための通信規格で、国際標準ではIEC 62541として定められています。転送方式だけを規定する仕組みではありません。値の意味・データ型・階層関係を持つ情報モデルを標準の一部として抱え込んでいる点が、ModbusやMQTTとの決定的な差になります。この記事では、アドレス空間の構造、OPC Classic（DA・AE・HDA）との違い、証明書とSecurityPolicyの設定順序、PubSubとOPC UA FXの現在地、そして製造現場のデータ収集に入れるかどうかの線引きを、2026年8月22日時点の仕様書と実装の版数をもとに整理します。

まとめ：OPC UAの守備範囲とOPC Classicからの移行判断

結論から示します。OPC UAが引き受ける範囲は「設備の値を、型と意味と時刻を保ったまま、認証と暗号化を伴って上位システムへ渡す」ところまでです。値を運ぶだけならModbus TCPで足り、大量の点を細い回線で流すだけならMQTTで足ります。OPC UAを選ぶ理由は、タグ名の突き合わせ作業と機種ごとの変換処理を、規格側の情報モデルへ押し込めることにあります。

採用の線引きははっきりしています。接続先の設備ベンダが三社以上に分かれ、かつ収集した値を生産管理やMESで意味づけして使うなら採用する価値があります。逆に、単一ベンダのPLCから数十点を拾って可視化するだけなら過剰でしょう。証明書の配布と失効管理、名前空間の設計、コンパニオン仕様の取り込みという運用負荷が、可視化だけの案件では回収できません。

版数の現況も押さえておきます。中核仕様は1.05系で、部ごとに版が分かれています。フィールド層まで広げるOPC UA FX（UAFX）はPart 80から84の1.00系で、2026年3月時点でRelease Candidate V1.00.04が完了した段階です。フィールド層を当面担う既存規格との関係は、産業用ネットワークとは？フィールドバスと産業用Ethernetの分類・規格選定を実装目線で解説で選定軸から整理しています。

OPC UAをIEC 62541として定める仕様の構造と三つの層

OPC UAは三つの層で捉えると理解が早まります。バイト列を運ぶトランスポート、機器の値をノードの集合として並べる情報モデル、Read・Write・Browseといった操作の意味を規定するサービスの三層です。仕様書はこれらを番号付きの「Part」に分けて公開しており、全部を読む必要はありません。上位へ渡す経路の設計まで含めるなら、監視制御側の作り方をまとめたSCADAの構成要素とプロトコル選定と並べて読むと、OPC UAがどの層を担うのかが掴めます。

1.05系まで版が分かれるPart構成と実装時に読む順序の目安

公式リファレンスサイトで版数を確認すると、部ごとに数字がずれています。2026年8月22日時点では次の通りでした。

Part 1 Overview and Concepts：1.05.06（全体像と用語）
Part 4 Services：1.05.07（クライアントが呼ぶ操作の定義）
Part 8 Data Access：1.05.07（工業値のデータ型と品質）
Part 14 PubSub：1.05.06（多対多配信のモデル）
Part 7 Profiles：1.05.02（公開日2022-11-01・適合性の単位）

読む順序は、Part 1で用語を揃え、Part 4で操作を掴み、実装対象に応じてPart 8かPart 14へ進む流れが無駄になりません。Part 7は製品選定の場面で効きます。ベンダが「OPC UA対応」と書いていても、どのConformance Unitを満たすかはPart 7のプロファイル単位で決まるためです。対応表を出せないベンダの実装は、たいてい限定的です。

opc.tcpバイナリとHTTPS経由で変わる接続方式とポート4840

接続経路はURLのスキームで切り替わります。工場内で使われるのはほぼopc.tcpのバイナリ方式で、既定ポートは4840番。IANAにも登録された番号で、ファイアウォールの穴あけ申請ではこれが基準です。TLSで包むHTTPS方式は4843番を使います。

実務ではバイナリ方式を既定に置いてください。工業値のような小さなデータを高頻度で運ぶ場合、JSONは同じ内容で数倍のバイト数になります。ただし制御系から情報系へ抜ける経路にプロキシやWAFが挟まる構成では、opc.tcpが素通りできません。境界にゲートウェイを置き、内側をバイナリ、外側をHTTPSまたはMQTTへ変換する二段構成にしてください。

アドレス空間に並ぶノードの構造と情報モデルをたどる参照の経路

クライアントが最初に見るのは、値そのものではなくアドレス空間です。ノードが階層状に並び、フォルダをたどる要領で目的の変数へ降りていきます。この構造がOPC UAの本体で、他のIoTプロトコルとの差が生まれる場所です。

NodeIdの名前空間インデックスと識別子で決まるノードの一意性

すべてのノードはNodeIdで一意に指されます。NodeIdは名前空間インデックスと識別子の組で、たとえば名前空間2番のString型識別子「Line1.Temp01」という形。名前空間0番はOPC UAが標準で定める領域で、型定義やサーバ診断ノードが入っています。ベンダ独自の情報や自社設備の実体は1番以降です。

ここに実装上の落とし穴があります。名前空間インデックスはサーバ起動時に決まる相対番号で、構成が変わると番号がずれるためです。クライアントに数値を直書きすると、設備の増設やファーム更新のあとで一斉に読めなくなります。NamespaceArrayを読み、名前空間URIから現在のインデックスを引き直す実装にしておけば事故を避けられる。数値ではなくURIを設定値として持つ、が鉄則です。

ObjectTypeとVariableTypeによる型定義と参照のたどり方

ノードには種類があり、値を持つVariable、まとまりを表すObject、その型を定義するVariableTypeとObjectTypeが基本です。ノード同士はReferenceで結ばれ、参照にも種類があります。親子関係はHasComponentやOrganizes、型との対応はHasTypeDefinition。クライアントはBrowseサービスで参照をたどって目的のノードへ到達します。

型定義があると何が変わるのか。「射出成形機」というObjectTypeを定義しておけば、機番が10台に増えても型を手がかりに同じ構造として一括処理でき、1台ごとのタグ名対応表が不要になります。型を作らずVariableをフラットに並べただけのサーバは、通信仕様としてはOPC UAでも、運用の手間がModbusのタグ表と変わりません。移行の効果はこの型設計に懸かっています。

NodeSet2 XMLでコンパニオン仕様を取り込む手順と注意点

情報モデルはNodeSet2形式のXMLとして配布され、サーバ起動時に読み込ませます。業界団体が定義した既製の情報モデルがコンパニオン仕様で、工作機械・ロボット・射出成形機など領域ごとに分かれています。OPC Foundationは2026年4月20日のプレスリリースで、コンパニオン仕様が430件超に達し、これらをMarkdownやRAG向けチャンク、ベクトル埋め込み、MCPおよびREST照会用のインターフェースへ変換する取り組みを公表しました。

取り込みで詰まるのは依存関係です。多くのコンパニオン仕様はDI（Device Integration）仕様を土台にしており、読み込み順序を間違えるとノードの解決に失敗します。土台から順に積めば大半の起動エラーは消えます。自社独自の項目は既製の型を継承した派生型として自社名前空間に置き、既製ノードを直接書き換えないでください。仕様の版が上がったときに差分を当て直せなくなります。

OPC Classicとの違いとDCOM依存から離れた通信構造の変化

OPC UAの前身がOPC Classicです。1996年策定のOPC（OLE for Process Control）を起点とする仕様群で、現在も稼働中の設備に数多く残っています。名前は地続きですが、通信の土台は別物。日本の製造業における通信標準化の流れは、ORiNをめぐる標準化の経緯を追うと背景が見えてきます。

DCOM前提のOPC Classicで詰まる遠隔接続と権限設定

OPC ClassicはMicrosoftのCOMとDCOMの上に構築されているため、サーバもクライアントもWindowsに縛られます。同一マシン内なら安定して動きますが、別マシンへ跨いだ瞬間に難易度が跳ね上がる。DCOMは接続時に動的ポートを割り当てる方式で、ファイアウォールでは広い範囲を開ける必要が生じるためです。両端のWindowsで同一のローカルアカウントとパスワードを揃える作り込みも要ります。

OPC UAはこれらを設計から外し、独自のセキュアチャネルとセッションの二段構成へ移りました。OSにも依存しません。Linuxの産業用ゲートウェイやコントローラ内蔵サーバを選べるのは、この構造変更の結果です。

DA・AE・HDAの三仕様が単一のアドレス空間へ統合された形

OPC Classicは目的ごとに別々の仕様でした。OPC UAはこれらを一つのアドレス空間に統合し、同じセッションから扱えます。対応関係は次の通りです。

OPC Classic	担当範囲	OPC UAでの扱い
DA（Data Access）	現在値の読み書き	Part 8 と Variableノード
AE（Alarms & Events）	警報と事象の通知	Part 9 とEventNotifier
HDA（Historical Access）	履歴値の取得	Part 11 とHistoryRead

統合の効果は接続数に表れます。Classicでは現在値・警報・履歴で別々のサーバへ繋ぐ構成が普通でしたが、OPC UAでは一つのエンドポイントに集約できます。単なる新旧の置き換えではなく、接続の設計そのものが変わると捉えるのが正確です。

既存のClassic資産をラッパーで残す場合と作り直す場合の分岐

移行の現実解は二つです。一つはOPC UAラッパーを挟み、既存のClassicサーバを外からOPC UAに見せる方式。もう一つはコントローラ側の内蔵OPC UAサーバへ切り替え、Classicを外す方式です。

三年以内に設備更新の計画があるなら、ラッパーへ投資せず内蔵サーバへ直行してください。ラッパーはDCOMの制約を内側に抱え続けるため、権限設定の運用負荷が消えません。更新まで七年以上かかる大型設備で、かつClassicサーバが数台に限られるなら、ラッパーで橋渡しする判断が合理的でしょう。全台を一斉に切り替える計画は、停止時間の確保が難しい現場では失敗します。区画ごとに区切って移す方が完走します。

証明書とSecurityPolicyの選択で決まる通信の保護設定

OPC UAのセキュリティは、接続のたびに証明書を交換する前提で組まれています。設定項目は多いものの、押さえる順序は決まっています。

Basic128Rsa15とBasic256が非推奨になった理由と現行の選択

SecurityPolicyは暗号アルゴリズムの組み合わせに付けた名前で、サーバとクライアントが同じ名前を選べないと接続が成立しません。旧来広く使われたBasic128Rsa15とBasic256は、ハッシュにSHA-1、鍵長にRSA 1024ビットを用いるため、仕様1.04の時点で非推奨になりました。

SecurityPolicy	状態	新規構築での扱い
Basic128Rsa15	1.04で非推奨	選ばない
Basic256	1.04で非推奨	選ばない
Basic256Sha256	現行・広く実装	下限として許容
Aes128_Sha256_RsaOaep	現行	既定の候補
Aes256_Sha256_RsaPss	現行・最も強い	長期運用向け

選定の実務は、接続先の機器が対応する範囲との交差で決まります。古いコントローラがBasic256Sha256までしか持たない場合、そこだけを下限に合わせ、上位系はAes256_Sha256_RsaPssで固める分離構成にします。すべてを最も弱い機器に合わせる設計は避けてください。

アプリケーションインスタンス証明書の相互信頼と失効の運用管理

OPC UAではサーバとクライアントの双方がアプリケーションインスタンス証明書を持ち、互いに相手の証明書を信頼リストへ入れて初めて通信が成立します。初回接続が拒否されるのは正常な動作。拒否リストに置かれた相手の証明書を、管理者が信頼側へ移す運用が前提です。

台数が増えると自己署名証明書の手配りは破綻します。接続点が20を超えたら、GDS（Global Discovery Server）や社内CAによる発行へ移してください。証明書には有効期限があり、切れた瞬間に設備からの収集が止まります。期限の一覧化とアラート設定は導入時の作業計画に必ず含めてください。監視の抜けが原因の停止は、暗号設定の不備よりも多く起きています。

MessageSecurityModeとユーザー認証を分けて設定する順序

設定を混同しないために、次の順で決めます。前半の三つは「アプリケーション同士の信頼」、四番目は「誰が操作しているか」の話で層が違います。

MessageSecurityModeを決める（None・Sign・SignAndEncrypt）
SecurityPolicyを決める（暗号アルゴリズムの組）
アプリケーション証明書を交換し、双方の信頼リストへ登録する
ユーザー認証方式を決める（匿名・ユーザー名とパスワード・X.509証明書）

制御系の閉じたネットワークではSignのみ、情報系へ跨ぐ経路はSignAndEncryptという使い分けが現実的でしょう。書き込み権を持つセッションでは必ずユーザー認証を有効にしてください。

PubSubとOPC UA FXが広げる伝送方式と適用範囲の現在地

従来のOPC UAは一対一のクライアント・サーバ通信でしたが、Part 14で多対多の配信モデルが加わりました。要求と応答が対になる同期通信に対し、PubSubは発行側が宛先を知らずに送り出す非同期通信です。指令の書き込みはクライアント・サーバ型、周期的な計測値の配信はPubSub型、と役割で分けます。

MQTTブローカーを挟むPubSub構成と情報モデルの持ち方

ブローカ経由のPubSubでは、MQTTやAMQPの上にOPC UAのDataSetMessageを載せます。エンコーディングはJSONを選べるため、受け口が既にMQTTで組まれている環境へそのまま流し込める構成。MQTTのPub/Sub構造とQoSの選び方を押さえておくと、トポロジ設計が具体的になります。

注意すべきは情報モデルの扱いです。PubSubで流れるのはDataSetとして切り出した値の並びであり、アドレス空間そのものは流れません。受け手が意味を解くには、DataSetMetaDataを別途配布するか事前に共有しておく必要があります。MQTTブリッジを噛ませた構成で「値は来るが使えない」と詰まる原因は、たいていこのメタデータの設計漏れです。MQTT側で構造の宣言まで規約化する選択肢もあり、その考え方はSparkplug Bとは？MQTT上の産業データ規約と状態管理を実装目線で解説にまとめています。

UAFX Part 80から84の公開状況とTSN標準の位置づけ

OPC UA FX（UAFX）は、コントローラ同士やコントローラと機器の間の通信までOPC UAで統一する拡張です。2026年8月22日時点の版数はPart 80が1.00.03、Part 81が1.00.04、Part 82が1.00.03でした。OPC Foundationの会報は2026年3月に、Release Candidate V1.00.04の完了を伝えています。1.00系の完成へ向けた途中段階、という位置づけです。

土台となるネットワーク側は前進しました。産業オートメーション向けのTSNプロファイルであるIEC・IEEE 60802:2026が、Edition 1.0として2026年6月に発行されています。ただし2026年8月時点でUAFX対応をうたう製品は限られます。既存の産業用イーサネット規格を置き換える計画を今すぐ立てる段階ではなく、次の設備更新の要件に「UAFX対応の見通し」を確認項目として入れておく程度が妥当でしょう。

製造現場のデータ収集でOPC UAを採用する条件と見送る場面

ここまでの仕様を踏まえ、入れるべきかどうかを判断します。曖昧に「状況次第」とは書きません。条件を切って言い切ります。

接続先の設備ベンダが三社以上に分かれる現場で効く標準化の効果

OPC UAが投資に見合うのは、接続先の設備ベンダが三社以上に分かれ、かつ収集データを生産管理やMESで突き合わせて使う場合です。ベンダごとに専用ドライバを用意する構成では、機種が増えるたびに個別開発が積み上がります。情報モデルを標準側へ寄せておけば、追加は同じ型のノードを増やす作業に収束します。

既にDCSが入っている工場では、上位への値の渡し方が別の論点になります。制御系に触れずデータだけを取り出す経路設計は、DCSからMESへ実績値を渡す構成で扱っている通り、OPC UAサーバ経由とヒストリアン経由の二択。秒単位の監視が要るならOPC UA、日次の集計で足りるならヒストリアンからの抽出です。取り出した値を指図と実績に紐づける受け手の設計はMESシステムとは？製造実行システムの11機能とISA-95レベル3の実装要件で扱っています。

センサ数十点の可視化だけならOPC UAを見送る判断とその代替

見送るべき場面もはっきりしています。単一ベンダのPLCから数十点を拾ってダッシュボードに出すだけなら、OPC UAは過剰です。証明書の配布と失効管理、名前空間の設計、ライセンス費用が乗るのに対し、得られるのは体裁だけ。この規模ならModbus TCPで読み、ゲートウェイでMQTTへ載せる方が構築期間も運用工数も短く済みます。

もう一つの見送り条件は、収集した値を人が見るだけで終わる場合です。他システムとの突き合わせが発生しないなら、型定義に労力を割く意味が薄くなります。どこから手を付けるかを整理したい段階なら、先にスマートファクトリーの5階層と投資判断の線引きを見て、収集層に投資する順番が来ているかを確認してください。

open62541とasyncua・node-opcuaの現行版と選定の基準

自前で実装する場合、主要なオープンソーススタックは三つです。2026年8月22日時点の公開版は次の通りでした。

スタック	言語	現行版と公開日
open62541	C（C99）	v1.5.7・2026-08-20
asyncua	Python	2.0.1・2026-06-29
node-opcua	TypeScript	2.178.0・2026-08-20

選定の基準は動作させる場所で決まります。組込みボードやゲートウェイに載せるならopen62541、既存のPythonデータ基盤へ繋ぎ込むならasyncua、Node.js製の収集サーバに同居させるならnode-opcuaという振り分けが素直でしょう。ライセンス条件は実装ごとに異なるため、組み込む前に確認してください。収集基盤の構築を外部に任せる選択肢なら、AI・IoTソリューションの受託開発で対応範囲を確認できます。

OPC UAの学習順序・既存設備の接続についてよくある質問への回答

導入検討と実装の現場で繰り返し挙がる質問をまとめました。

OPC UAとMQTTはどちらを選べばよいですか？

目的が違うため、択一ではありません。MQTTは軽量な配信の仕組みで、値の意味づけは持ちません。OPC UAは情報モデルを持ち、型と単位と品質コードを伴って値を渡します。設備側の意味づけが要るならOPC UA、細い回線で大量の点を運ぶならMQTT、両方必要ならOPC UA PubSubをMQTTの上に載せる構成が答えです。

OPC UAの読み方と正式名称は何ですか？

「オーピーシー・ユーエー」と読み、正式名称はOPC Unified Architectureです。国際規格としてはIEC 62541シリーズにあたります。「OPC-UA」「OPCUA」といった表記も同じものを指しますが、OPC Foundationの文書では「OPC UA」と分かち書きされています。

古いPLCにOPC UAサーバが入っていない場合はどうしますか？

プロトコル変換ゲートウェイを挟みます。Modbus TCPやベンダ固有プロトコルで読んだ値を、ゲートウェイ側のOPC UAサーバのアドレス空間へ載せる方式です。情報モデルはゲートウェイ側で設計することになります。機器を更新せず標準化の効果を先取りできる一方、変換分の遅延とゲートウェイの単一障害点化は設計に織り込んでください。挟む機器の選定軸と発注時の要件定義はIoTゲートウェイとは？プロトコル変換の役割とクラウド直結との使い分けで扱っています。

OPC UAの通信は暗号化しないと使えませんか？

MessageSecurityModeをNoneにすれば暗号化なしでも通信できます。ただし本番運用で選ぶべきではありません。制御系の閉じた区画ならSign（改ざん検知のみ）、情報系へ跨ぐならSignAndEncryptを既定にしてください。Noneは検証環境と初期の疎通確認に限定する運用が安全です。