実験装置を自動化しようとすると、装置ごとに異なる通信コマンド、専用SDK、返却形式へ対応する必要があります。SiLA 2は、この違いを装置の機能を表す共通インターフェースで包み、ワークフロー側から一貫した形で操作するためのオープンな通信標準です。
この記事で学べること
- SiLA 2が解決しようとしている問題と、SCPI・メーカーSDKとの役割の違い
- Client、Server、Feature、Command、Propertyの関係
- 短時間の処理と長時間の実験をどう表現するか
- 既存装置をSiLA 2対応にする際の基本構成
- Feature設計、エラー、安全制御、証明書管理で失敗しない判断基準
結論から言うと、SiLA 2を導入する価値は「通信方式を新しくすること」ではありません。装置固有の命令を、測定する、温度を設定する、現在値を読むといった意味のある機能として定義し、上位の実験ソフトウェアから再利用できるようにすることです。SiLA 2は安全回路やリアルタイム制御を置き換える規格ではないため、PLCや装置内コントローラーとの責任分担が重要です。
SiLA 2とは何か
SiLAはStandardization in Lab Automationの略称で、SiLA 2は実験・分析装置とソフトウェアを接続するためのオープンな通信標準です。SiLA Associationは、SiLA 2をHTTP/2、Protocol Buffers、gRPCのワイヤ形式を利用する標準として説明しています。また、装置の種類よりも「装置が提供する機能」に重点を置くことを設計思想に掲げています［1］。
たとえば、分光光度計Aと分光光度計Bが異なるメーカーコマンドを使っていても、SiLA Serverがその違いを吸収し、上位ソフトウェアには「測定開始」「波長設定」「測定結果取得」といった機能を提示します。ただし、同じFeature名を付けるだけで相互運用できるわけではありません。意味、単位、前提条件、エラー、バージョンまでそろって初めて、置換可能性が高まります。
実験自動化全体におけるSiLA 2、OPC UA LADS、SCPI、PLCの位置づけは、先に実験自動化の通信・制御・標準を整理するで確認すると理解しやすくなります。
SiLA 2が必要になる理由
装置を追加するたびに個別実装が増える
装置AはRS-232の文字列、装置BはWindows専用SDK、装置CはREST APIという環境では、実験ワークフローが各装置の実装詳細に強く依存します。装置更新のたびに上位コードまで修正すると、保守範囲が広がり、試験項目も増えます。
SiLA 2では、装置固有通信をSiLA Serverの内部に閉じ込めます。ワークフローはSiLA ClientとしてServerのFeatureを呼び出します。この境界が安定すれば、装置ドライバーと実験手順を別々に保守できます。
「接続できる」と「実験を任せられる」は違う
ポートが開き、値を読み書きできても、実験自動化に必要な情報が足りない場合があります。処理の完了をどう判断するか、途中経過を取得できるか、装置が使用中か、設定値が許容範囲外ならどのエラーになるか、といった運用上の契約が必要です。
SiLA 2のFeatureは、Command、Property、データ型、制約、エラーなどを機械可読な形で記述する枠組みを提供します。つまり、単なる通信変換器ではなく、装置機能の契約を定義する層として使うのが本質です。
基本構成：Client、Server、Feature
| 要素 | 役割 | 実験室での例 |
|---|---|---|
| SiLA Client | 機能を呼び出す側 | ワークフロー管理ソフト、Pythonアプリ、LIMS連携サービス |
| SiLA Server | 機能を提供し、装置固有通信へ変換する側 | 装置PC上のサービス、エッジPC、装置内ソフトウェア |
| Feature | 関連するCommand、Property、Metadataをまとめた機能単位 | 温度制御、測定、サンプル搬送、装置情報 |
公式Python実装の説明では、ClientがServerへ接続すると、Serverが実装するFeatureがClientから利用可能になり、その配下にCommand、Property、Metadataが現れます［2］。概念としては、次の流れです。
- ワークフローがSiLA Clientから「測定」Featureを探す
- Clientが「測定開始」Commandを呼ぶ
- SiLA ServerがメーカーSDKやSCPIへ変換する
- 装置が測定を実行する
- Serverが進捗、完了、結果、エラーをSiLAの形式で返す
Serverは必ずしも装置本体に組み込む必要はありません。既存装置では、装置に接続されたPCや小型エッジPCにServerを置く「ラッパー構成」が現実的です。一方、物理的なインターロックやミリ秒以下の制御は、装置内コントローラーやPLCへ残します。
Featureは「装置名」ではなく「機能」で分ける
Feature設計で最初に迷うのは粒度です。「分光光度計Feature」のように装置名で大きくまとめると、別機種へ移行したときに再利用しにくくなります。一方、ボタン一つごとにFeatureを作ると、数が増えて意味のまとまりが失われます。
実務では、独立して理解・試験・再利用できる責務で分けます。たとえば仮想的な吸光度測定装置なら、次のように整理できます。
| Feature候補 | 主な責務 | 含める例 |
|---|---|---|
| DeviceInformation | 装置識別と能力確認 | 機種、シリアル番号、ファームウェア版 |
| Measurement | 測定の開始と結果取得 | Measure、測定ID、測定結果 |
| WavelengthControl | 波長条件の設定・確認 | SetWavelength、CurrentWavelength |
| DeviceStatus | 稼働状態と異常の監視 | OperationalState、CurrentError |
ここで示した名称は説明用の仮想例であり、公式Featureとして実在すると主張するものではありません。実装前にはSiLAのFeatureリポジトリや組織内カタログを確認し、既存定義を再利用できないか検討します。
CommandとPropertyをどう使い分けるか
Commandは「実行させる操作」
Commandは、Server側で処理を実行させるための呼び出しです。入力はParameter、出力はResponseとして表します。たとえば、測定開始なら試料IDや測定条件をParameterとし、測定IDや結果参照先をResponseにできます。
Commandは、短時間で応答が返るUnobservable Commandと、進捗や残り時間などを追跡できるObservable Commandに分けて考えます。公式Python実装の資料では、Observable Commandは呼び出し直後にコマンドインスタンスを返し、実行状態、進捗、推定残り時間、途中応答を扱えると説明されています［2］。
| 処理 | 向く表現 | 理由 |
|---|---|---|
| 装置名を設定する | Unobservable Command | 短時間で完了し、最終応答だけでよい |
| 30分の温度プログラムを実行する | Observable Command | 状態、進捗、残り時間、失敗を追跡したい |
| 測定を開始し、スペクトルを順次得る | Observable Command＋Intermediate Response | 完了前のデータや進行状況が必要 |
長時間処理を同期的な一回の呼び出しにすると、ネットワーク切断と装置停止を区別しにくくなります。逆に、数十ミリ秒で終わる設定変更を複雑なObservable Commandにすると、実装と監視が過剰になります。
Propertyは「現在の情報」
Propertyは、現在値や状態を表します。現在温度、装置状態、設定波長などが候補です。公式資料では、Propertyは現在値を取得でき、Observable Propertyでは値の変化を購読できます［2］。
判断の目安は、「これは動作を起こす依頼か、それとも現在の事実か」です。温度を変更させるならCommand、現在温度を知るならPropertyです。ただし、設定値の変更をPropertyへの書き込みとして表すのではなく、規格の定義に従ってCommandとして設計する考え方が基本です。
データ型と制約は、単位まで設計する
SiLA 2では整数、実数、真偽値、文字列、バイナリ、日時に加え、List、Structure、Constrained型などを扱えます。公式Python実装では、制約付き型に違反する値を受け取るとValidationErrorを返す動作が示されています［3］。
しかし、Real型で数値を送れるだけでは十分ではありません。次を明示しないと、通信は成功しても実験条件が誤ります。
- 単位：℃、K、s、min、mL、µLなど
- 有効範囲：0〜100 ℃など
- 分解能・桁数：0.1 ℃単位か、0.01 ℃単位か
- 欠損・未測定・範囲外の表現
- 時刻のタイムゾーン
- 大容量画像やスペクトルを本文で送るか、参照先を返すか
Protocol Buffersは言語やプラットフォームに依存しない構造化データのシリアライズ機構で、複数言語のコード生成に対応します［4］。ただし、Protobuf自体が物理単位や測定の意味を保証するわけではありません。意味の一貫性はFeature Definitionの設計と運用ルールで担保します。
SiLA 2の通信技術を必要以上に怖がらない
SiLA 2はHTTP/2上で動作し、Protocol Buffersでペイロードを直列化し、gRPCのワイヤ形式を利用します［1］。gRPCではサービス、呼び出せるメソッド、Parameter、戻り値の型を定義し、ClientとServerのコードを生成できます［5］。HTTP/2は同一接続上で複数の交換を並行して扱えるため、効率的な通信基盤になります［6］。
ただし、SiLA利用者全員がHTTP/2フレームやProtobufのバイナリ形式を手作業で実装する必要はありません。通常はSDKやコード生成を利用し、Feature定義と装置ロジックへ集中します。一方、ネットワーク障害、証明書、タイムアウト、再接続を理解せずに済むわけではありません。
実装選定の注意：SiLA 2の旧Python実装「sila2 0.14.0」の公式ドキュメントは、現在そのプロジェクトをUnmaintainedと明記しています［7］。この記事では仕様概念の確認に利用していますが、新規導入時は現行仕様、保守状況、ライセンス、対応Featureを確認し、保守停止中のSDKを無条件に採用しないでください。
既存装置をSiLA 2対応にする構成
既存装置には、すでにSCPI、シリアル通信、REST API、メーカーSDKなどの制御手段があります。それを捨てる必要はありません。SiLA Serverをアダプターとして置き、装置固有通信を内側に閉じ込めます。
| 層 | 担当 | 変更時の影響 |
|---|---|---|
| 実験ワークフロー | 複数装置の順序、条件分岐、記録 | 実験手順の変更 |
| SiLA Client | Featureの発見・呼び出し・監視 | Feature契約の変更 |
| SiLA Server | Featureを装置固有命令へ変換 | ドライバーや装置機種の変更 |
| 既存ドライバー | SCPI、シリアル、SDK、REST | メーカー仕様の変更 |
| 装置内制御 | モーター、温度、インターロック | 制御盤・ファームウェア変更 |
装置が出力したデータをLIMSやデータベースへ登録する処理は、実験装置・LIMS・データベースを連携する設計で扱っています。SiLA 2で制御できても、試料ID、条件、結果、監査情報を結び付けるデータ設計は別途必要です。
導入手順：最初の1台をどう設計するか
1．自動化する利用場面を一つに絞る
「装置をSiLA対応にする」ではなく、「測定条件を送り、測定完了を検知し、結果ファイルと試料IDを保存する」のように、開始条件と完了条件を定めます。最初から全機能を覆うと、UI用機能や保守機能まで混ざり、境界が曖昧になります。
2．装置の機能と固有コマンドを分離する
利用者が必要とする機能を先に列挙し、その後で各機能をメーカーSDKやSCPIへ対応付けます。上位Feature名にメーカー独自コマンド名をそのまま使うと、装置交換時の抽象化が失われます。
3．Command、Property、データ型を決める
操作か状態か、短時間か長時間か、入力と出力は何かを決めます。単位、範囲、列挙値、タイムゾーン、大容量データの受け渡しも定義します。Commandを再送した場合に二重実行されるかも確認します。
4．正常系より先に異常系を列挙する
扉が開いている、試料がない、装置が使用中、測定範囲外、通信切断、ディスク容量不足などを洗い出します。利用者が対処できるエラーはDefined Execution Errorとして区別し、ログだけに埋め込まない設計が望まれます。公式資料でも、Validation Error、Framework Error、定義済み・未定義のExecution Errorが区別されています［2］。
5．エミュレーターで契約試験を行う
実機を常時占有せず、正常応答、遅延、既知エラー、通信切断を返す模擬Serverを作ります。Client側が進捗、タイムアウト、再接続を正しく扱えるか確認してから実機へ接続します。
6．運用責任を決める
Feature Definition、Server実装、証明書、装置ドライバー、ワークフロー、データ保存先を誰が保守するかを決めます。装置メーカー、情報システム部門、研究部門の境界を文書化しないと、障害時に原因切り分けが止まります。
SiLA 2が向く場面・向かない場面
| 状況 | 適合度 | 判断理由 |
|---|---|---|
| 異なるメーカーの装置を共通ワークフローから操作したい | 高い | 機能契約と装置固有通信を分離しやすい |
| 装置追加や交換を繰り返す研究基盤 | 高い | Server境界を安定させる価値が大きい |
| 1台だけを短いスクリプトで一度制御する | 要検討 | SCPIやSDKの直接利用の方が小さく作れる場合がある |
| 安全PLCのインターロックを置き換えたい | 不適 | 安全・決定論的制御は装置内・PLC側の責務 |
| サブミリ秒のリアルタイム制御ループ | 不適 | ネットワーク越しの上位通信層に置くべきでない |
| 工場全体の設備モデルや長期資産管理が中心 | 比較検討 | OPC UAやLADSを含め要件から選ぶ |
自動化の範囲、投資効果、段階導入の考え方は実験自動化とは？導入手順・装置連携・データ基盤・費用対効果も参考になります。
よくある失敗
失敗1：メーカーAPIを名前だけ変えて公開する
装置固有のメソッドをそのままFeatureへ写すと、Clientが結局メーカー仕様へ依存します。利用者の目的から機能を定義し、固有パラメーターはServer内部で変換します。
失敗2：長時間処理を完了まで待つ一回の呼び出しにする
通信切断時に、装置が動作中なのか停止したのか分からなくなります。Observable Command、実行ID、進捗、最終状態、再接続後の照会を設計します。
失敗3：停止Commandがあれば安全だと考える
ネットワークが切れれば停止Commandは届きません。非常停止、扉インターロック、上限温度などは装置内やPLCで成立させ、SiLA 2は通常運転の調整と監視に使います。
失敗4：単位と時刻を暗黙にする
25という値が℃かKか、タイムスタンプがUTCか現地時刻か分からなければ、型が正しくても再現性はありません。単位、タイムゾーン、校正情報、試料IDを契約とデータ記録へ含めます。
失敗5：SDKと標準仕様を同一視する
SDKの便利機能、未実装機能、保守状況は製品ごとに異なります。規格で保証される部分、SDK固有の挙動、自組織の運用ルールを分けて記録します。
技術的限界・不確かさ・責任範囲
- 相互運用性：SiLA 2準拠だけで、異なるServerが同じ意味・単位・エラーを持つとは限りません。共通Featureと適合試験が必要です。
- 可用性：Client、Server、ネットワーク、装置ドライバーのどこでも障害が起こります。再接続と状態照会を設計します。
- セキュリティ：証明書、鍵、ネットワーク分離、認証・認可、ログ保存を組織要件に合わせます。旧Python実装の資料でも暗号化通信と証明書を扱い、暗号化しない起動は開発用途に限定すべきとされています［8］。
- 安全：SiLA 2は機械安全規格そのものではありません。人身・設備保護は装置設計、PLC、安全回路、手順で担保します。
- データ完全性：通信成功は結果の妥当性を保証しません。校正、試料追跡、監査証跡、原データ保存が別途必要です。
複数装置を閉ループで結び、次の実験条件を自動決定する場合は、装置接続に加えて最適化、品質判定、停止条件が必要です。全体像は自律実験・Self-driving Labとは？で整理しています。
導入前チェックリスト
- 自動化したい利用場面と完了条件を一文で説明できる
- 装置固有通信と、上位へ公開する機能を分離した
- Featureの責務が大きすぎず、細かすぎない
- CommandとPropertyを操作・状態で区別した
- 長時間処理に進捗、最終状態、実行寿命を設計した
- 単位、範囲、時刻、欠損、大容量データの扱いを決めた
- 既知エラーと利用者の対処方法を定義した
- 通信切断後の状態確認と二重実行防止を決めた
- 非常停止とインターロックをSiLA 2へ依存させていない
- SDKの保守状況と規格バージョンを確認した
- 模擬Server、実機、統合環境で試験計画を作った
- Feature、証明書、ドライバーの保守責任者を決めた
FAQ
Q1．SiLA 2を使えば、どの装置も同じコードで動かせますか？
自動的には同じになりません。同じ意味のFeature、Command、Property、データ型、単位を実装し、適合試験に合格して初めてコードを共通化しやすくなります。SiLA 2は共通化の枠組みを提供します。
Q2．既存装置のファームウェア改修は必要ですか？
必須ではありません。外部PC上のSiLA Serverから、既存のSCPI、シリアル通信、メーカーSDKを呼ぶラッパー方式が使えます。ただし、外部制御APIがなければ自動化できる範囲は限定されます。
Q3．REST APIがあればSiLA 2は不要ですか？
単一装置を接続するだけならREST APIで十分な場合があります。複数装置間で機能、型、長時間処理、状態、エラーをそろえたい場合は、SiLA 2の契約が価値を持ちます。
Q4．SiLA 2とOPC UA LADSはどちらを選ぶべきですか？
用途、既存基盤、装置ベンダー、情報モデル、運用体制によります。SiLA 2は機能ベースの実験装置連携に適した選択肢です。LADSはOPC UAの情報モデルとして装置情報や機能を標準化します。次回以降の記事で、LADSの構造と両者の使い分けを詳しく扱います。
Q5．最初から全装置をSiLA 2対応にすべきですか？
推奨しません。価値が明確な1台・1ユースケースから始め、Feature設計、試験、運用の型を作って横展開する方が安全です。
まとめ
SiLA 2は、実験装置ごとに異なる通信方式を、機能ベースの共通インターフェースで扱うためのオープン標準です。ClientはServerが公開するFeatureを利用し、操作はCommand、現在の情報はPropertyとして扱います。長時間実験ではObservable Commandにより進捗や完了を追跡できます。
導入の要点は、規格を採用すること自体ではなく、Featureの意味、単位、エラー、実行状態を実務に耐える契約として設計することです。既存のSCPIやSDKはSiLA Serverの内側で活用し、安全制御は装置内やPLCに残します。小さなユースケースと模擬Serverから始めることで、装置追加や交換に強い実験基盤へ段階的に近づけます。
参考文献
- SiLA Association, “Standards – Introducing SiLA 2,” SiLA 2 Version 1.1および技術概念（2026年10月11日確認）. https://sila-standard.com/standards/
- SiLA2, “Interact with a SiLA Server,” sila2 0.14.0 documentation, 2022（2026年10月11日確認）. https://sila2.gitlab.io/sila_python/content/client/usage.html
- SiLA2, “SiLA Data Types,” sila2 0.14.0 documentation, 2022（2026年10月11日確認）. https://sila2.gitlab.io/sila_python/content/data_types/index.html
- Google, “Overview,” Protocol Buffers Documentation（2026年10月11日確認）. https://protobuf.dev/overview/
- gRPC Authors, “Introduction to gRPC,” last modified 2024-11-12（2026年10月11日確認）. https://grpc.io/docs/what-is-grpc/introduction/
- M. Thomson, C. Benfield (Eds.), “HTTP/2,” RFC 9113, IETF, 2022. DOI: 10.17487/RFC9113
- SiLA2, “Python implementation of the SiLA 2 standard,” sila2 0.14.0 documentation, project status notice（2026年10月11日確認）. https://sila2.gitlab.io/sila_python/
- SiLA2, “Start the generated SiLA Server,” sila2 0.14.0 documentation, 2022（2026年10月11日確認）. https://sila2.gitlab.io/sila_python/content/server/start_server.html
