STEP 1630 — 計測 MCP 三段安全 3 例比較 + 中規模計測基盤 3 例棲み分け
1. 三段安全設計 3 例比較 (計測 MCP 系)
計測装置に対して「危険な操作を止める」だけでなく「なぜ止めたかを人に見せる」ところまで作られた計測 MCP 実装が、これまでに 3 例確認された。三例に共通する構図と、各実装の差別点を整理する。
| 実装 | 安全境界の場所 | 判定単位 | 「なぜ」の返し方 | 掲載 |
|---|---|---|---|---|
| Keysight 公式 MCP | クライアント側 (LLM が preview → 人承認) | SCPI 平文 | preview_commands で SCPI 文字列を人に見せる | 既掲載 |
| KAME | サーバ側 (server-side rule で強制 block) | SCPI 平文 | サーバ側規則の説明文 | 既掲載 |
| Anai-Guo/LabAgent | サーバ側 (Pydantic 型 + YAML policy) | MeasurementPlan の field (semantic parameter) | LLM 助言と判定を層分離 | 掲載可 (条件付) |
LabAgent 一次資料 (fork agent 実測)
src/lab_harness/models/safety.py:11-15—Decision(str, Enum): ALLOW / REQUIRE_CONFIRM / BLOCKが Python 型として定義されているsrc/lab_harness/planning/boundary_checker.py:38-55のcheck_boundaries— docstring に "Three-tier check: 1. Absolute limits - hard block / 2. Warning thresholds - require operator confirmation / 3. Plan consistency" と明記、以降の分岐でviolations(BLOCK) とwarnings(REQUIRE_CONFIRM) を実際に populate。Tier 2 はif not violations:guard 付き (Tier 1 が優先、README 記述と整合)configs/default_safety.yaml— 絶対上限 5 種 + warn 閾値 4 種が数値で定義済 (abs_max_current_a: 10.0/warn_current_a: 0.1等)- 「上限が存在する理由を言葉で添える」=
src/lab_harness/planning/safety_advisor.pyのSYSTEM_SAFETYprompt (LLM 委譲)。ValidationResult.ai_adviceに保存され、docs/features/safety.md:149に「purely informational — it does not modify the plan or override safety decisions」と明文化。判定と助言の層分離が三例中もっとも明確
LabAgent の差別点 (Keysight/KAME に対して)
- MeasurementPlan の Pydantic field 単位で YAML policy と照合 — SCPI 文字列でなく semantic parameter を検査、抽象度が一段上
- Tier 3 (consistency: step=0 / >10000 points 等の無意味計画) が safety 判定に組み込まれている — Keysight/KAME にはない範囲拡張
- AI advice を判定と分離した layer に置き、
ai_advice is informational onlyを docs で明文化 — 三例中もっとも「LLM 汚染」を意識した層分け
- ★6 (前回誤報 84 → 実測 6 に訂正、下記 §3 参照)
Development Status :: 3 - Alpha、48 commits の大半が 2026-04-14 単日バースト (Anai-Guo 単独 + 1 外部コミッタ Tai An)、最終 push 2026-08-05 でその後停止- License MIT (前回懸念した「pip install git+https:// commit 固定なし」問題は license 面では消える。PyPI 未 publish なので commit pin 前提のみ残る)
- 比較 note 掲載時は「三例中もっとも実装が新しく、Pydantic + YAML policy 型化 approach を持つが、star / commit 分布から見て single-author alpha stage」と honest scope 併記推奨
2. 中規模計測基盤ライブラリ 3 例棲み分け
Nobuki-san の計測基盤ライブラリ選定において、既掲載の pymeasure (★754, MIT) と pyLabLib (★208, GPL-3.0) の間を埋める中規模帯として DavidLutton/LabToolkit を第 3 の選択肢として評価する。
| ライブラリ | ★ | License | 重心ドメイン | 抽象化 | 掲載 |
|---|---|---|---|---|---|
| pymeasure | 754 | MIT | 汎用計測 (Oscilloscope / DMM / DC 電源 中心) | Instrument 継承ツリー | 既掲載 |
| pyLabLib | 208 | GPL-3.0 | 顕微鏡 / カメラ / ステージ | デバイス class + backend 抽象 | 既掲載 |
| DavidLutton/LabToolkit | 28 | MIT | RF / microwave テストベンチ | 自前 3 層 (Instrument + SCPI + IEEE488) | 保留 (条件付) |
LabToolkit — 独立実装確認 (fork agent 実測)
- README・deps・code いずれにも pymeasure/pyLabLib 参照なし。抽象化は自前 3 層 (
Instrument.py+SCPI.py+IEEE488.py)、driver 継承ツリーは別系統 → 並列選択肢 (helper ではない) - PyPI 1.4.0 (2023-12-26)、MIT、Python ≥3.10、300 コミット、単独メンテナ (David Lutton)
- DataFrame ネイティブ返却 (pandas
df.attrsにメタ埋込) は pymeasure と異なる設計
カバレッジ 26 カテゴリ (RF 重心)
RF/microwave 重心が明確: SpectrumAnalyser / NetworkAnalyser / SignalGenerator / Oscilloscope / DigitalMultimeter / PowerSourceAC / PowerSourceDC / PowerMeter / PowerAnalyser / WaveformGenerator / FrequencyCounter / AudioAnalyser / ModulationMeter / FieldStrength / FilterRF / WirelessTestSet / Attenuator / Switch / Positioner / RangeFinder / PATester 他。
WirelessTestSet / FieldStrength / ModulationMeter / FilterRF は pymeasure でも希薄。この 4 カテゴリが LabToolkit を掲載する主な理由になる。
pyLabLib との棲み分け
成立。pyLabLib は顕微鏡 / カメラ / ステージ寄り、LabToolkit は RF テストベンチ寄り。重なりは Oscilloscope / DMM のみ。3 ライブラリはドメインで住み分けられており、Nobuki-san の選定は目的ドメインに応じた並列選択になる。
- RF テスト側の空白補完価値は確かにあるが、★28・Beta・単独メンテナ・直近リリース 2023-12 で以降 tag なし、release cadence が実質停止気味
- 「RF テストベンチ用途に限る補完ライブラリ」注記付きで並列選択肢欄に入れるのが妥当
- 取り込み条件 (MIT + 独立実装 + PyVISA 依存) は pymeasure と同じ、技術障壁なし
3. 前回報告の honest correction — LabAgent star 数
訂正: 第 3 回探索の要約で LabAgent の star 数を 「★6・48 コミットの個人リポジトリ」と書いた行に対して、直前の別行で 「Anai-Guo/LabAgent (要確認・84)」 と 84 という数字を併記していた。fork agent が GitHub リポジトリページで stargazers_count を直接確認したところ 実測 ★6。「84」の由来は今回の探索メモから追跡できず、別リポジトリの数字が混入したか、あるいは前回セッションの手元メモ上の書き間違いの可能性がある。
訂正後の正しい表記: Anai-Guo/LabAgent は ★6・48 commits・単独メンテナ・Development Status :: 3 - Alpha・最終 push 2026-08-05。掲載判定 (掲載可 条件付き) は star 数訂正後も変わらない (三例中もっとも実装が新しく Pydantic + YAML policy 型化 approach を持つという判定根拠は star 数と独立)。
4. Honest scope
- 本 note は fork agent 2 体が github.com リポジトリページ経由で読んだ内容の集約。raw.githubusercontent.com 経由の README fetch は今回の第 3 回探索で承認待ちで失敗しており、この制約は次回定期実行の default URL 修正で解消予定 (STEP 別 arc)
- LabAgent の三段判定は Python 型と YAML policy の対応まで確認したが、Nobuki-san の実機接続での end-to-end 動作は未検証。掲載時は「一次資料による静的確認済、実機挙動は未検証」を明示
- LabToolkit の RF カテゴリ 4 種 (WirelessTestSet / FieldStrength / ModulationMeter / FilterRF) が pymeasure に本当に無いかは pymeasure 側 driver 一覧との突合まで踏み込んでいない。fork agent の「pymeasure でも希薄」判定は README + driver directory の目視スキャンレベル
- 「三段安全設計 3 例」という枠自体が、今回の探索で目に入った範囲での標本。GitHub 全体・GitLab・企業内実装まで含めた網羅性は主張していない
5. Related
- STEP 1344 — Silent Visual Verifier v0.3 SCPI safety (Kikusui / Siglent SCPI 引数解釈 safety の D-FUMT₈ 視覚化、本 note の「三段安全」路線と直接接続)
- STEP 1582 — QCoDeS instrument primitive (計測抽象化 primitive の別枠)
- STEP 1587 — Scout instrumentation channels (計測チャネル探索)
- 全 tools ページ index