SiLA 2とLADSの違い｜実験自動化ではどう選び、組み合わせるか

SiLA 2とOPC UA LADSは、どちらもメーカーの異なる実験装置をつなぎやすくするための標準です。そのため「どちらを選べばよいのか」「同じ装置に両方必要なのか」と迷いやすいのですが、両者は同じ問題をまったく同じ方法で解いているわけではありません。

先に結論を示すと、研究ワークフローから装置の機能を呼び出すことを中心に考えるならSiLA 2、装置の構造・状態・結果・保守情報をOPC UAの産業基盤へ統合するならLADSが有力です。ただし、これは排他的な選択ではありません。既存設備、上位システム、保守体制が異なる大規模な研究環境では、同じ低レベルドライバーの上に両インターフェースを設ける構成も成立します。

重要なのは規格名から決めるのではなく、「上位システムが何を知り、何を操作し、どの責任を負うか」を先に決めることです。

SiLA 2とLADSを一言で整理する

項目	SiLA 2	OPC UA LADS
中心となる考え方	装置やソフトウェアが提供するサービス／機能	装置の情報モデルと、その機能・状態・資産情報
代表的な単位	Feature、Command、Property	Device、Component、Function、Functional Unit、Program Manager
通信基盤	HTTP/2、Protocol Buffers、gRPCへのマッピング	OPC UAのAddressSpace、Service、Subscription、Method、Event
得意な入口	「この装置に何をさせられるか」	「この装置は何で構成され、いま何が起きているか」
主な親和性	研究ワークフロー、ラボソフトウェア、サービス指向設計	OT、PLC、SCADA、MES、資産・保守管理、OPC UA基盤

SiLA Associationは、SiLA 2をサービス指向の規格として説明し、Feature Definition Languageで機能を定義します。Core仕様はFeature、設計規則、データ型、エラー、セキュリティ、Discoveryなどを扱い、Mapping仕様は抽象的なFeature定義をProtocol BuffersとgRPCへ対応付けます［1］［2］［3］。

LADSは、OPC UA上に分析・実験装置向けの共通情報モデルを定義するCompanion Specificationです。Hardware ViewとFunctional Viewを持ち、装置・部品、機能、処理単位、プログラム、状態、結果、保守情報を表現します［4］［5］。

両規格を含むSCPI、PLC、メーカーSDKの全体的な役割は、実験自動化の通信・制御・標準を整理するで先に俯瞰できます。

共通する目的：メーカー固有APIへの依存を減らす

両者に共通するのは、装置ごとに異なる通信コマンドやSDKを上位システムへ直接露出させず、意味のある共通インターフェースを提供することです。

たとえば、温度を30 ℃へ設定する処理を考えます。メーカーAはシリアルコマンド、メーカーBはWindows DLL、メーカーCはREST APIを提供しているかもしれません。上位ワークフローが三種類の実装を直接扱うと、装置交換のたびにソフトウェアを修正する必要があります。

SiLA 2またはLADSのServer／Gatewayが差異を吸収すれば、上位側は共通化された型、単位、操作、状態を使えます。ただし、標準を採用しただけで装置間の意味が自動的に一致するわけではありません。FeatureやFunctionの粒度、エラー、状態遷移、結果の構造まで合意して初めて、実用的な相互運用性が得られます。

最大の違いは「何を中心にモデル化するか」

SiLA 2：提供する機能をFeatureとして表す

SiLA 2は、Serverが提供する機能をFeatureにまとめます。Featureには、処理を実行するCommandと、値を取得・変更するPropertyを定義できます。Feature Definition LanguageはXML形式でインターフェース契約を表し、Mapping仕様によってgRPCのサービスへ変換されます［2］［3］。

たとえば恒温槽Serverなら、TemperatureControl Featureに次の要素を置く設計が考えられます。

• SetTargetTemperature：目標温度を設定するCommand
• StartControl：温調を開始するCommand
• CurrentTemperature：現在温度を返すProperty
• ControlState：待機、昇温、安定、異常などを返すProperty

この例は編集部による仮想設計です。実装では、単位、制約、Observable Command、実行エラー、Feature識別子を仕様に従って定義します。

LADS：装置の構造と機能を二つのViewで表す

LADSは、Hardware ViewとFunctional Viewを分けます。Hardware ViewではDeviceやComponent、銘板、校正、保守を扱います。Functional ViewではFunction、Functional Unit、Program Manager、状態、結果を扱います［5］。

同じ恒温槽なら、筐体、ヒーター、温度センサーをComponentとして表し、温度測定をSensor Function、温度制御をController Functionとして表す設計が考えられます。装置が複数の独立槽を持つなら、それぞれをFunctional Unitにできます。

つまり、SiLA 2は利用者が呼び出す機能の契約を作りやすく、LADSは装置を探索・監視・管理するための共通AddressSpaceを作りやすいという違いがあります。

通信とデータアクセスの違い

観点	SiLA 2	LADS
基本通信	gRPC／HTTP/2	OPC UA Client/Server
データ表現	Protocol Buffersへマッピング	OPC UA NodeとDataType
操作	Command	Method、書込み、状態機械
値の取得	Property	VariableのRead／Subscription
イベント	Command進捗やProperty購読など規定パターン	Event、Alarm & Condition、Subscription
探索	SiLA Discoveryと自己記述Feature	OPC UA DiscoveryとAddressSpaceのBrowse

SiLA 2のMapping仕様v1.1は、Feature Definition LanguageからProtocol Bufferファイルへの変換とgRPC上の表現を定めています［3］。LADSはOPC UAのDiscovery、Transport、Information Access、Securityを利用し、その上へ装置向け情報モデルを重ねます［6］。

ここでEthernet、USB、RS-232とSiLA 2／LADSを同列に比べないことが重要です。USBやRS-232は物理・通信経路の選択肢であり、その上でメーカー固有プロトコルをGatewayが読み、SiLA 2またはLADSとして公開することもできます。

長時間処理と状態管理はどう違うか

SiLA 2：Commandを中心に進捗と完了を追う

数分から数時間かかる測定では、要求を送って応答を待ち続けるだけでは不十分です。SiLA 2にはObservable Commandの考え方があり、Command開始後に実行情報、進捗、途中応答、最終応答を追跡できます。装置の操作を「一つのサービス呼出し」として扱う設計と相性があります［2］。

LADS：Functional UnitとProgramの状態機械を追う

LADSでは、Device、Functional Unit、Control Functionなどの状態機械と、Program Managerによる実行管理を組み合わせます。Program Templateを選び、実行中のActive Programを監視し、完了後にResultSetから結果を取得する流れが仕様に整理されています［5］。

両者とも長時間処理を扱えますが、視点が異なります。SiLA 2では「呼び出したCommandの進行」、LADSでは「装置内の処理単位・Programがどの状態にあるか」が中心になります。

結果・試料・トレーサビリティの違い

SiLA 2は、Featureごとに型を持つ応答やバイナリデータを返せます。画像や分析データについては、既存のオープンなデータ形式を活用することが推奨されています［7］。どのメタデータを結果へ含めるかは、採用するFeatureと組織の共通設計に依存します。

LADSは、Program Manager、Active Program、ResultSet、Result、ResultFile、SampleInfoなどを共通情報モデルとして持ちます。上位Job、Task、装置のProgram Run、試料を結び、プログラム実行から結果回収までを追跡する構造を作りやすい点が特徴です［5］。

ただし、LADSを使えば科学データの中身まで完全に標準化されるわけではありません。スペクトル、画像、クロマトグラムなどのファイル内容には、別のデータ標準や組織内スキーマが必要です。実験データをLIMSやデータベースへ接続する全体設計は、実験装置・LIMS・データベースを連携する設計で解説しています。

資産・保守管理ではLADSの共通モデルが生きる

LADSは、DeviceとComponentの銘板、設置情報、状態、校正、検証、保守タスクをHardware Viewで扱います［5］。すでにOPC UA Client、SCADA、MES、設備保全システムを利用している環境では、同じ技術基盤へ実験装置を統合しやすくなります。

SiLA 2でも保守用Featureを設計することは可能です。しかし、各Serverが独自にCalibration FeatureやMaintenance Featureを作るだけでは、組織横断の資産管理に必要な意味が揃わない可能性があります。共通Featureを採用・策定し、識別子や用語を統一する必要があります。

セキュリティは規格名ではなく運用まで比較する

SiLA 2はClient–Server通信の暗号化を要求し、TLSを利用します。認証・認可Featureの利用も案内されていますが、実際の証明書配布、秘密鍵保護、ユーザー管理は導入者の責任です［7］。

OPC UAは、通信セキュリティ、Application Instance Certificate、SecureChannel、Session、ユーザー認証、権限などの基盤を持ちます。LADSはその上に構築されます。ただし、SecurityPolicyを弱く設定したり、匿名接続を許したりすれば、安全性は確保できません。OPC UA Part 2の現行公開版は1.05.06で、脅威モデルとセキュリティモデルを定めています［8］。

どちらを採用しても、非常停止、過温・過圧、扉インターロックなどを上位ネットワーク通信だけに依存させてはいけません。安全機能は装置内制御や安全PLCで成立させ、SiLA 2／LADSは許可された操作と監視を担います。

SiLA 2とLADSの詳細比較

評価軸	SiLA 2が向きやすい	LADSが向きやすい
主目的	機能呼出しと研究ワークフロー	装置情報、状態、制御、結果、保守の統合
設計の起点	利用者が必要とするFeature	Device／ComponentとFunctional View
上位ソフトウェア	ラボオーケストレーター、Python／クラウドサービス	OPC UA Client、SCADA、MES、保全システム
個別操作	Commandとして明確に定義	Method、Variable、Functionで表現
長時間処理	Observable Command	Program／Functional Unitの状態機械
装置階層	Feature中心。必要なら独自に表現	Device／Componentを標準的に表現
保守・校正	Featureとして提供可能	Hardware ViewとMaintenance Facetを利用
結果追跡	Command応答とFeature設計で構成	Program Manager、ResultSet、SampleInfoを利用
OPC UA既存資産	別Gatewayや連携層が必要	同じOPC UA基盤を活用しやすい
実装範囲の確認	提供Featureと版を確認	Profile／Facet／Conformance Unitを確認

この表は、公式仕様の構造に基づく編集部の実務的な整理です。特定製品の優劣や、すべての実装へ当てはまる性能比較ではありません。

目的別の選択基準

SiLA 2を第一候補にしやすい場面

• 研究ワークフローから装置機能を明示的に呼び出したい
• 装置だけでなく、計算・データ処理サービスも同じ考え方でつなぎたい
• Featureを再利用し、ベンダーを越えて同じ機能契約を持たせたい
• gRPC／Protocol Buffersを使うソフトウェア開発体制と親和性が高い

LADSを第一候補にしやすい場面

• 装置の状態、構成部品、健康状態、校正、保守を共通化したい
• プログラム実行、試料、結果を標準モデルで追跡したい
• OPC UA、PLC、SCADA、MESなどのOT基盤がすでにある
• 装置調達でProfile／Facet単位の適合性を指定したい

両方を検討すべき場面

• 研究者向けワークフローと、全社設備監視・保守を両立したい
• サイトごとに既存基盤が異なり、一つの規格へ短期間で統一できない
• 装置ベンダーが一方、上位プラットフォームが他方へ対応している

規格選定を7段階で進める

1．ユースケースを操作・監視・結果・保守に分ける

「装置をつなぐ」では範囲が広すぎます。温度設定、測定開始、進捗監視、結果取得、校正期限監視など、必要な行為を分解します。

2．利用者と上位システムを決める

研究ワークフロー、LIMS、SCADA、設備保全、PythonアプリのどれがClientになるか整理します。既存Clientが対応する規格は重要な制約です。

3．装置側へ残す責任を決める

高速制御、安全、排他、実行順を装置内に残し、上位には安全なCommand／Methodと状態だけを公開します。

4．共通化したい意味を決める

機能契約を共通化するならFeature設計が中心です。装置構造・状態・結果・保守を横断利用するならLADS情報モデルを中心にします。

5．実装と運用の保有能力を確認する

gRPC、OPC UA SDK、証明書、Namespace、NodeSet、監視ツールなど、開発・保守できる技術を確認します。規格そのものより、継続運用できるかが重要です。

6．小さなPoCで相互運用性を試す

一台の実装だけで成功と判断せず、別ベンダーのClientまたはServerを組み合わせます。通信断、Busy、不正値、実行中の再命令、証明書更新も試験します。

7．選定理由と例外条件を文書化する

「今後はすべてSiLA 2」のような固定ルールより、目的、既存基盤、必要機能、例外、移行条件を記録します。

両規格を組み合わせる3つの構成

構成1：一つの装置アダプターから二つのServerを提供する

装置ドライバー／メーカーSDK
        ↓
共通ドメイン層・安全な装置API
        ├─ SiLA 2 Server → 研究ワークフロー
        └─ LADS Server   → OPC UA／設備・保守システム

低レベル通信、排他制御、実機状態の管理を一か所にまとめ、外部インターフェースだけを分けます。二つのServerが同時に矛盾する命令を送らないよう、単一の資源ロックと状態管理が必要です。

構成2：Gatewayで片方から片方へ変換する

既存SiLA 2装置をOPC UA環境へ公開したり、LADS装置をSiLA 2ワークフローから利用したりする構成です。導入は速い一方、完全な一対一変換はできません。

たとえば、SiLA 2のObservable CommandをLADSのProgram状態へ対応付けるには、進捗、取消し、エラー、結果、実行IDの規則を個別に決めます。LADSのDeviceHealthやComponent階層をSiLA 2へ出すには、それを表すFeatureが必要です。変換できない情報を黙って捨てず、対応表と制約を公開してください。

構成3：用途ごとに装置群を分け、上位で統合する

すべての装置を同じ規格へ変換せず、SiLA 2対応装置は研究ワークフロー、LADS対応装置はOPC UA基盤で扱い、上位オーケストレーターが両方のConnectorを持つ構成です。段階導入に向きますが、共通Job ID、試料ID、状態語彙、監査ログを上位で統一する必要があります。

併用時の実装例

編集部による仮想例として、分注装置、反応装置、分光装置を使うワークセルを考えます。

1. 上位ワークフローはSiLA 2 Featureを使い、分注、反応開始、測定開始を順に呼び出す。
2. 各装置のLADS ServerはDeviceHealth、校正期限、Component状態を中央監視へ公開する。
3. 共通Job IDとSample IDを、SiLA 2のCommand入力とLADSの結果コンテキストの両方へ渡す。
4. 安全インターロックと高速温調は装置PLCが担当する。
5. 通信断後は装置内の実行IDで状態を再照合し、同じ処理を二重実行しない。

これは両規格を必ず併用すべきという意味ではありません。一方だけで要件を満たせるなら、実装・保守の複雑さを抑えるため一方に絞る方が合理的です。自律実験へ発展させる場合の全体像は、自律実験・Self-driving Labとは？も参照してください。

よくある失敗と対策

失敗1：比較表だけで規格を決める

製品の対応状況、既存Client、証明書運用、保守担当を無視すると実装が止まります。実際のユースケースを一つ選び、エンドツーエンドで試験します。

失敗2：SiLA 2は制御、LADSは監視だけと固定する

LADSにもFunction-based／Program-based制御があり、SiLA 2でも状態・結果・保守Featureを設計できます。違いは可否ではなく、標準が中心に置くモデルと利用できる共通資産です。

失敗3：Gatewayなら自動変換できると考える

Command、状態機械、エラー、結果、装置階層は一対一になりません。意味の対応表、欠落情報、再試行規則、単位変換を設計します。

失敗4：二つのServerが別々に装置を制御する

別プロセスが同じシリアルポートやSDKを操作すると、命令競合や状態不一致が起こります。低レベルドライバーと排他制御を一か所へ集約します。

失敗5：「対応」の言葉だけで調達する

SiLA 2ならFeature名・版・Command・Property、LADSならNamespace版・Profile・Facet・任意Methodを確認します。相互接続試験と変更通知も契約に含めます。

技術的限界・不確かさ・責任範囲

• 規格は品質を保証しない：標準形式の値でも、校正不良、試料取り違え、単位設定ミスは起こります。
• 完全な意味統一ではない：共通Feature／Typeを使わず独自拡張が増えると、相互運用性は低下します。
• 実装差がある：規格対応の範囲、SDK、ベンダー製品、認証状況は変化します。導入時点で確認してください。
• リアルタイム制御の境界：ネットワーク越しの上位命令を、装置内部の高速制御ループや安全制御の代替にしません。
• 併用の複雑さ：二つの規格を採用すると、版管理、証明書、ログ、テスト、障害解析の対象も増えます。
• 責任分担：装置メーカー、Gateway開発者、プラットフォーム担当、ラボ運用者の責任を明示します。

選定・PoCチェックリスト

• 最初のユースケースを一文で説明できる
• 操作、監視、結果、保守の要件を分けた
• Clientとなる既存システムを特定した
• SiLA 2 FeatureまたはLADS Profile／Facetを一覧化した
• 長時間処理の進捗、取消し、完了、再接続を定義した
• Job、Task、Program Run、SampleのID対応を決めた
• 単位、許容範囲、データ型、エラーを定義した
• 証明書、認証、権限、監査ログの運用担当を決めた
• 通信断、Busy、二重実行、不正値を試験した
• 安全機能と高速制御を装置側へ残した
• 併用する場合は単一のドライバーと資源ロックを設けた
• 規格・Feature・Namespaceの版変更手順を決めた

FAQ

Q1．新規の実験自動化ならSiLA 2とLADSのどちらを選ぶべきですか？

研究ワークフローから機能を呼び出すことが中心ならSiLA 2、OPC UAを使った状態・結果・保守・設備統合が中心ならLADSを第一候補にします。既存システムとベンダー対応も含め、実機PoCで決めてください。

Q2．SiLA 2とLADSは競合規格ですか？

重なる領域はありますが、設計の中心とエコシステムが異なります。排他的に考えるより、必要な意味と利用者から選ぶのが実務的です。

Q3．一台の装置に両方実装できますか？

可能です。共通ドメイン層と低レベルドライバーを一つにし、その上へ二つのServerを設ける構成が考えられます。ただし排他制御、状態同期、証明書、試験の負担が増えます。

Q4．SiLA 2 Serverを自動的にLADS Serverへ変換できますか？

通信の中継は可能でも、意味の完全自動変換は困難です。FeatureとFunction、Observable Commandと状態機械、結果、Component階層の対応を個別に設計します。

Q5．既存のSCPI装置にはどちらも使えませんか？

使えます。Gatewayや装置PCがSCPIを処理し、上位へSiLA 2またはLADSを公開できます。装置固有エラー、タイムアウト、再接続、単位をラッパー内で管理します。

Q6．PLCがある場合はLADS一択ですか？

OPC UAとの親和性からLADSは有力ですが、一択ではありません。PLCが安全・高速制御を担当し、上位研究ワークフローにはSiLA 2を公開する構成も可能です。

まとめ

SiLA 2とLADSは、どちらも実験装置の相互運用性を高めますが、標準化の中心が異なります。

• SiLA 2はFeature、Command、Propertyによるサービス指向の機能契約が中心
• LADSはDevice、Component、Functional Unit、Program、ResultによるOPC UA情報モデルが中心
• 研究ワークフロー、装置・資産管理、既存OT基盤のどれを重視するかで選ぶ
• 両方を併用できるが、意味変換、排他制御、状態同期の設計が必要
• 規格名ではなく、実装Feature／Profileと異常系を実機で確認する

最初の一歩は、装置一覧を作ることではなく、代表ユースケースを一つ選び、操作、状態、結果、保守、安全の責任境界を書き出すことです。その要件へ最も自然に対応する規格を選び、小さな相互接続試験から始めてください。

参考文献

1. SiLA Association, “Standards,” 2026年10月11日確認. https://sila-standard.com/standards/
2. SiLA Association, SiLA 2 Part (A): Overview, Concepts and Core Specification, Release v1.1, 2022. 公式配布ページ
3. SiLA Association, SiLA 2 Part (B): Mapping Specification, Release v1.1, 2022. PDF
4. OPC Foundation, “LADS – Laboratory and Analytical Device Standard,” 2026年10月11日確認. https://opcfoundation.org/markets-collaboration/lads/
5. OPC Foundation, OPC UA for Laboratory & Analytical Device Standard (LADS) – Part 1: Basics, OPC 30500-1, Release 1.0.0, 2023-11-30. オンライン仕様
6. OPC Foundation, “UA Companion Specifications,” 2026年10月11日確認. 公式解説
7. SiLA Association, “FAQ: SiLA 2, Security and Other Standards,” 2026年10月11日確認. https://sila-standard.com/faq/
8. OPC Foundation, OPC Unified Architecture Part 2: Security Model, Version 1.05.06, 2025-10-22. オンライン仕様