「測定装置のログ取りと条件出しを、AIに任せられませんか」という相談は、製造業と研究部門の両方から届きます。そして多くの場合、装置1台ごとの接続開発を積み上げた見積もりを見た時点で止まります。
止まる理由は技術的な難しさではありません。装置が5台あれば接続の作り込みも5回発生し、しかもそれは装置メーカーが変われば流用できない。「やりたいこと」より「つなぐこと」のほうが高いという構造が、この種の案件をずっと足止めしてきました。
つなぐ作業が毎回作り直しになる理由
産業用・研究用の機器は、それぞれ固有の制御方法を持っています。シリアル通信で独自のコマンド体系を叩くもの、メーカー製SDKを経由するもの、専用PCのアプリケーションしか窓口がないもの。同じ「読み取る」「動かす」でも、装置ごとに語彙が違います。
そこにAIエージェントを載せようとすると、装置の語彙とエージェントが扱える語彙の間を埋める層を、毎回書くことになります。この層は装置固有なので、次の案件では捨てることになる。専門家の工数が要り、数週間から数ヶ月かかり、そして再利用できない。見積もりが膨らむのはここです。
Model Hardware Standardが標準化したもの
Anthropicは2026年8月27日、AIエージェントが物理デバイスを安全に操作するための共有仕様「Model Hardware Standard（MHS）」を、科学研究ラボと先進的な製造業の第一陣に向けてリサーチプレビューとして公開しました。
中核にあるのは標準化されたドライバです。コンピュータのOSと物理デバイスの間に入るソフトウェアとして機能し、read と write を含む基本的なコマンド（プリミティブ）の集合を通じてデバイスを扱います。対象はプログラマブルなインターフェースを持つあらゆるデバイスとされており、顕微鏡、液体ハンドラ、ロボットアームなどが挙げられています。エージェントはこれらを並列に動かすことができ、創薬から量子コンピュータのレーザー校正までが用途として示されています。
Anthropicによれば、通常なら専門家によるカスタム開発で数週間から数ヶ月かかる統合が、数時間から数分で済むようになります。加えて、仕様はモデル非依存で、Claude系のモデルに縛られません。将来的なオープンソース化も表明されています。
MCPがAIエージェントとソフトウェア側のツールをつなぐ共通仕様として広がったのと、狙いの立て付けはよく似ています。違うのは、書き込み先が画面の向こうではなく、実際に動く装置だという点です。
「数時間」に含まれていない工程
ここを読み違えると、社内の期待値がずれます。短縮されるのは接続の作り込みであって、案件全体ではありません。
| 短くなる工程 | そのまま残る工程 |
|---|---|
| 装置ごとの接続層の実装 | 何をどこまで自動化するかの合意 |
| 制御コマンドの調査と実装 | 異常時の停止条件と手動介入の設計 |
| 装置追加時の横展開 | 安全確認・受け入れ試験・記録の保全 |
物理デバイスを動かす以上、間違った書き込みは元に戻せません。 画面上のツールなら操作を取り消せますが、試薬を吐出した液体ハンドラや、動いたロボットアームは取り消せない。したがって、どの操作をエージェントに委ね、どこから人間の確認を挟むかという線引きが、接続よりも重い設計対象になります。
エージェントに渡す権限の切り方そのものは、ソフトウェア側で議論されてきた話とつながります。信頼境界をどこに置くかという整理はAIエージェントの権限設計で扱った考え方が、そのまま応用できます。装置が相手になると、境界を越えた場合の被害が物理的になるだけです。
手持ちの装置が対象外だったとき
現場でよくあるのは、動かしたい装置がいちばん古い、という状況です。外部から制御する口を持たず、専用PCの専用アプリからしか操作できない。この場合、共通仕様が普及しても対象になりません。
打ち手が無いわけではありませんが、性質が変わります。装置を直接動かす方向を諦め、装置が吐き出す結果のほうを自動化するという切り替えです。測定値がCSVやログとして出るなら、その回収と集計、異常値の検知までは自動化できます。操作は人が行い、判断の材料づくりを機械に寄せる形です。
地味に見えますが、投資対効果はしばしばこちらが上回ります。操作の自動化は装置ごとに作り込みが要るのに対し、結果の自動化は装置が変わっても仕組みを流用できるからです。 装置の更新時期が数年先なら、まずこちらを固め、更新のタイミングで制御インターフェースを持つ機種を選ぶ、という順番が現実的です。
今の位置づけを踏まえた現実的な構え
リサーチプレビューであり、提供先は限定されています。この段階でできる意思決定は、導入の可否ではなく準備の可否です。
具体的には2つあります。1つは、自社の装置がプログラマブルなインターフェースを持っているかどうかの確認。専用アプリからしか操作できない装置は、標準仕様が普及しても対象になりません。ここは今日から調べられます。
もう1つは、自動化したい作業の粒度を言語化しておくことです。「装置をAIで動かす」は要件になりません。「条件を変えながら20回測定してログを1つの表にまとめる」なら要件になります。この粒度を詰めないまま接続だけ用意すると、作ったものが使われずに終わります。スコープを広げすぎて止まる典型的なパターンは作りすぎを避ける要件設計にまとめました。
次にやること
まず、自動化候補の作業を1つだけ選び、手順を紙に書き出してください。 誰が、どの装置を、どの順で操作し、どこで判断しているか。この判断の部分が、後でエージェントに渡すか人が持つかを決める境界になります。
そのうえで、その装置の外部制御手段を、メーカーの資料で確認してください。 プログラマブルなインターフェースの有無が、この先の選択肢をほぼ決めます。無い場合は、仕様が普及しても打ち手は変わらないため、別の方法を検討したほうが早い。
装置やシステムとAIエージェントを接続する構成の検討、自動化範囲の切り分けと要件整理については、グリームハブの開発・AI・自動化のご相談で承っています。装置構成と目的によって進め方が変わるため、個別にご相談ください。お問い合わせからどうぞ。
