AnthropicがAIエージェントに実験装置を操作させる規格MHSを限定公開
目次
Anthropicは8月27日、AIエージェントが物理機器を操作するための共通仕様Model Hardware Standard（MHS）のリサーチプレビューを開始したと発表した。
対象は顕微鏡、分注ロボット（決まった量の液体を正確に移し替える装置）、ロボットアームといった研究・製造の現場機器で、エージェントはこれを複数台まとめて動かす。
仕様はモデル非依存で、MCPのような標準プロトコル経由ならエージェント基盤を選ばない。
開発はもともと、Anthropicと神経科学の研究拠点であるHHMI Janelia Research Campusの共同作業として始まっている。
ただ、いまのところは申し込み制のリサーチプレビューで、仕様書もドライバーの実装も公開されていない。
オープンソース化はそのあと、パートナーと安全性評価を作り込んでからになる。
MHSは何を標準化するか
そもそも機器ごとに制御用のプログラミングインターフェースがばらばらで、これまで標準化された繋ぎ方がなかった。
仮に接続できたとしても、機器同士でデータをやり取りする共通の形式は決まっていない。エージェントに安全に操作させる仕組みとなると、さらに標準がない。
MHSはそこを標準ドライバーで統一する。OSと機器の間を翻訳するソフトウェアで、命令はreadやwriteのような単純なプリミティブにまとめてある。要するに温度を取得するのがread、設定するのがwriteにあたる。
ドライバーが機器の情報を標準の形式で公開する。エージェントと機器はネットワーク越しに互いを見つけられて、間に個別の翻訳プログラムはいらない。
Anthropicが挙げている例はロボットアームの重量で、安全に動かすには必要な情報だが、コードだけからは判別できないことがある。というよりこの種の情報は、これまで紙のマニュアルか担当者の頭の中にあった。
そこでMHSドライバーは、この手の情報を自然言語のタグとして受け取る。タグの中身はユーザーが自分で書いてもいいし、エージェントに機器構成を聞き取りさせて書かせてもいい。
あとはタグの情報から、ドライバーが参照ファイルを自動生成する。何を測れるか、何を調整できるか、どの安全上限を強制するかがそこに書かれる。
実際にエージェントが機器を動かすときは、MCP、コマンドラインインターフェース、コードファイル（API）を使う。3つを組み合わせれば、エージェントは複数機器のオーケストレーションを1行のコードから呼べる。
graph TD
A[AIエージェント] --> B[MCP]
A --> C[コマンドライン]
A --> D[コードファイル/API]
B --> E[MHSドライバー]
C --> E
D --> E
E --> F[分注ロボット]
E --> G[ロボットアーム]
E --> H[プレートリーダー]
E --> I[顕微鏡]機器ごとの安全上限はドライバーが強制する。
共同開発元のHHMI Janeliaは、これを二光子顕微鏡で使っている。エージェントがレーザー出力を上げすぎて蛍光分子を退色させ、試料を痛めることがない。
MCPとの役割分担
| MCP | MHS | |
|---|---|---|
| 接続先 | ソフトウェアのツールやデータ | プログラミングインターフェースを持つ物理機器 |
| 基本命令 | サーバーが提供するツールやリソース | read や write といったプリミティブ |
| 機器の情報 | サーバー側の実装が返す | 自然言語タグから参照ファイルを自動生成 |
| 安全側の制御 | プロトコルでは強制せず実装者に委ねる | ドライバーが機器ごとの上限を強制 |
| 呼び出し方 | クライアントとサーバーがJSON-RPCで往復 | MCP・コマンドライン・コードの3通り |
つまりMCPはMHSに至る3つの方法のうちの1つで、機器の発見、安全上限、参照ファイルの生成はその先のMHSドライバーが担う。
ちなみにMCPの仕様2026-07-28は基本プロトコルを「ステートレスで自己完結したリクエスト」と定めており、安全面はプロトコルで強制せず実装者の責任としている。この改訂の中身はMCP仕様2026-07-28でプロトコルがステートレス化に書いた。
エージェントの探索をスクリプトに固定する
AnthropicはMHSのテスト中、Claudeが科学者のように探索的に機器を扱ったと書いている。
レーザーを少し動かし、カメラでビームの移動を確かめ、その結果を踏まえて次の調整を決める。そのうえで学んだ内容をコードファイルに固め、毎回推論しなくてもレーザーを整列できる決定論的なスクリプトを書いて、最後は全体を1コマンドで走らせた。
中性原子方式の量子計算機を作っているQuEra Computingが、レーザーの再ロックでこれをやっている。
この方式では、レーザーの周波数を1兆分の1という精度で保つ必要がある。温度、振動、気圧の変化でこの「ロック」が外れると、それだけで計算が狂う。
QuEraにはMHS以前から自動復帰スクリプトがあった。レーザーシステム技術者、ソフトウェア技術者、アルゴリズム担当、テスト担当の4人が数か月かけて作ったもので、人間の手順をそのまま順番に実行する。ただ成功率は約58%で、1回の試行に約150秒かかっていた。
一方、同じ問題をMHS経由でClaudeに任せたときは、エージェントのループが4つの役割に分かれた。
仮説を出す担当が復帰を速く確実にする案を挙げ、実装担当がそれをスクリプトに書き、実行担当が実機のレーザーで走らせて全手順を記録し、判断担当が記録を確かめて次に何を変えるか決める。役割ごとに別のClaudeインスタンスを立てている。
このサイクルが無人で一晩に数百回まわって、朝には復帰が約6秒、成功率96%になっていた。
Anthropicの説明では、Claudeがスクリプトを多段の条件分岐に組み替えたことでここまで速くなった。
元のスクリプトは、どんな乱れが来ても同じ手順を頭から順になぞるだけだった。Claudeが書いたほうは、まず各計器を読み、その値から条件を積み上げて、乱れの中身に合わせて動かす箇所を選ぶ。
周波数がほとんどずれていなければ大半の制御は何も変えないので、スクリプトは1つか2つだけ変えて残りは放置する。人間の操作者だと、正しいと確認するために結局全部を確かめるしかない。
仕上がったスクリプトをエージェント抜きで、同じ乱れを人為的に起こして試した。700回中695回で正しいロックに復帰した。成功率99.3%で、周波数が大きく飛んだケースで10〜14秒、簡単なものは0.9〜5.4秒。人間が手でやると5〜10分かかる。
続けてQuEraは、ロックの質そのものにもエージェントを使っている。
レーザーのふらつきをどこまで抑え込めるか、というつまみ調整の作業になる。目標周波数に追従させる制御ループには相互に依存する12個のPIDパラメータ（比例・積分・微分の3項の係数）があり、これを回してふらつきを詰めていく。ふらつきが小さいほど量子演算が正確になり、ロックも外れにくくなる。
そのふらつきを正確に測るには、オシロスコープで波形を取ってフーリエ変換にかけないといけない。12個を1回いじるたびにそれをやるのは人間には現実的でないので、専門家はサーボが返す概算値を見ながら詰める。
その専門家が調整した状態で、ふらつきは15.7 mV。Claudeは変更のたびに波形を取ってふらつきを実測し、363回の実験と16時間の無人稼働で1.55 mVまで下げた。
検証のため専門家が同じレーザーをゼロから調整し直し、両方の設定を位相雑音アナライザー（信号のふらつきを周波数ごとに測る計測器）にかけた。帯域全体ではほぼ同じだったが、約220 kHzの共振だけは手動調整側のふらつきがClaudeの約1000倍多かった。
19時間の連続運転でも、Claudeの設定は一度もロックが外れなかった。一方の専門家の設定は毎時約1.6回外れていた。
ただしこの調整ワークフローは、再ロックのスクリプトと違ってエージェントが都度介在する。条件が変われば、その場でパラメータを動かし直す。
パートナー実装で出た数字
| 実施者 | 対象 | 結果 |
|---|---|---|
| QuEra Computing | 量子計算機のレーザー再ロック | エージェント抜きで700回中695回成功（99.3%）。従来スクリプトは58%・約150秒 |
| Carnegie Mellon University | 段階希釈による用量反応曲線 | 3台の非互換な制御PCをまたいでドライバーを新規作成。統合に約8時間（業者なら数週間）、実験は約3倍速 |
| Genentech（創薬） | BCAタンパク質定量の自動化 | 流速を自分で探索し、水で約140 µL/s、粘性のあるタンパク質溶液（BSA）で10 µL/sに収束（ずれの指標RMSEはそれぞれ0.016と0.181） |
| HHMI Janelia | 二光子顕微鏡まわりの装置統合 | 7本のベンダーソフトの状態を共有メモリ上の1つの表に集約。カメラ追加が数分、実験開始が7手順から1クリック |
| University of Washington（タンパク質の新規設計） | 遠隔監視とqPCRの停止判断、アーム連携 | ドライバー作成込みで6台の機器を1週間以内に接続 |
| Tetsuwan Scientific（ラボ自動化） | qPCRワークフローとコンパイラ改良 | 9,143回の分注を試し、多重分注の精度予測がメーカー仕様比で約12%改善（45回中31回で上回る、符号検定 p ≈ 0.001） |
CMUのロボットアームは、決まったフォルダにジョブファイルを入れると動く。分注ロボットは古いWindowsのスクリプトから動かす。プレートリーダーに至ってはプログラムから操作する手段がなく、画面のボタンを押すしかない。制御用のPCも3台に分かれている。
ここにMHSのドライバーを1本ずつ書くと、機器の状態（プレートが位置3にある、試料が25 °C）とできる操作（吸引する、振とうする）が並んで出てくる。
Claudeから見ると、3台とも同じreadとwriteで動く。ドライバーとその上のオーケストレーション層まで含めて約8時間で、業者に組んでもらうと数週間かかる工程だった。
薬をどの濃さで効かせるかは、濃い液を同じ比率で薄めながら濃度ごとの反応を測っていくと分かる。効きはじめから頭打ちまでの曲線がそこで取れる。
1回目は上限が濃すぎて上が頭打ちになり、当てはまりが基準のR² 0.9に届かなかった。Claudeはそれを自分で判断してプレートを捨て、上限を200 µg/mLから100 µg/mLに下げて測り直している。
2回目はR²が0.98を超えた。人間は一度も手を出していない。
ついでに、プレートがない、プレートの向きが違う、リーダーが使用中、カメラが切れている、機器に届かない、非常停止中の6つをわざと起こしている。6回とも機器が動く前に止まった。
Tetsuwan Scientificは自動化した生物実験ラボをAPI越しに貸し出している。
qPCR（DNAを増やして量を測る反応）の試薬は石鹸のように粘る液で、ピペットで吸うと泡立つ。泡が入るとその分だけ量がずれて、最後の測定値まで狂う。
カメラと画像処理で泡を見張っていたら、ロボットアームが持っていたチューブに泡が出た。ただアームには泡を消す手がない。
そこでResearchOSがネットワークを探し、MHSで繋がっている機器の中から遠心機を見つけた。Claudeは低速で短時間回す案をSlackで出し、そのまま遠心機へ命令している。
プロトコル側に書いてあるのは必要な遠心力だけで、回転数しか受け付けない機器なら回転半径で割る変換はClaudeがやる。どの遠心機を使ったかはプロトコルに残らない。
機器メーカー側の対応
| メーカー | 製品・基盤 | 内容 |
|---|---|---|
| Amazon Web Services | Strands Robots | リサーチプレビュー参加者に非公開の先行版パッケージを提供 |
| Automata | LINQ | 自律ラボでの機器エラー処理にMHS対応を追加 |
| Danaher | スマート計測機器、自律ラボ | Anthropicと適用範囲を検討中 |
| Doosan Robotics | ロボットアーム | 自動品質検査と複数ロボットの協調をMHSで検証 |
| MBF Bioscience | ScanImage | レーザー走査顕微鏡向けソフトのMHSドライバーを開発中 |
| QIAGEN | QIAsymphony Connect | 核酸精製プラットフォームで概念実証を実施 |
| Tecan | Fluent | 分注プラットフォームをエージェントから直接操作できるように対応中 |
| Universal Robots | ロボティクスプラットフォーム | 先行アクセスを受け、対応を予定 |
Danaherは計測機器を束ねる会社、Automataはラボ自動化、MBF Bioscienceは顕微鏡のソフトを作っている。家庭向けの機器を手がける会社は入っていない。
現時点の制約
Genentechでは、液体を動かす途中で泡が出るとエラーコードが返る。Claudeは同じウェル（試料を入れる窪み）でパラメータを変えて再試行し、液体をさらに撹拌して泡を増やした。
泡が物理的な原因だという説明と、きれいなウェルへ移して混合回数を減らす手を教えてからは、Claudeも同じやり方を続けた。Genentechはこれを再利用できるスキルにまとめ、液体の性質に応じた既定値をClaudeが選べるようにした。
QuEraでは、装置そのものに物理的な不具合が出るとClaudeが対処できなかった。装置をプログラムとしてしか知らないので、物理的に何が起きているかまでは分からない。
少しでもリスクがあると判断した操作の前には人間の確認を待って止まるため、夜間の実験が承認待ちのまま朝になっていたこともある。もっとも慎重すぎるエージェントの方が慎重でないよりましだ、とQuEraは書いている。
実験の意図とやり方について、大量の文脈を与える必要があったことも報告している。
Claudeが判断に使えるのはテキストと画像までで、機械の重さや手応えが入ってくるわけではない。空間や物理の判断はそこで頭打ちになる。専門家の監督なしには運用できないとAnthropicは書いている。
規格の側の制約もある。プログラミングインターフェースを持たない機器はまだ対象外で、Anthropicはそうした機器のメーカーとドライバーを作り込んでいる最中だという。
ただしCMUのプレートリーダーにはAPIがなく、MHSが人間と同じように画面のGUIを操作していた。動作の確認は、画面に出ている値が頼りになる。
手元の機材で使えるか
Hugging Faceがロボティクスライブラリ LeRobot にMHS対応を追加し、Raspberry PiはCamera MHS Driverでのテストを経て複数製品への統合を進めている。開発者が普段作っている機器まで規格を広げたい、というのが次の段階になる。
タンパク質を新規設計しているUniversity of Washingtonのデモでも、LeRobotベースのオープンソースのロボットアームにMHSを載せ、分注ロボットとのプレート受け渡しを衝突なく通した。
家庭向けのIoT機器は、リサーチプレビューの対象に挙がっていない。
そもそもSwitchBotのようにクラウドAPIと公式のMCPサーバーが用意されている製品なら、SwitchBot公式CLI @switchbot/openapi-cli が登場で扱ったとおりMCPだけで動く。MHSはその手前、機器ごとに違うドライバーを標準化するところを引き受ける。重量のような物理的な特性もエージェントに伝える。
参加はmodelhardwarestandard.comのフォームからの申請制で、そのページには概要と申し込みリンク、Anthropicの告知へのリンクしか載っていない。
オープンソース化のタイミングで、リサーチプレビューで分かったことと安全な使い方の方針も併せて出すと予告している。とはいえ公式サイトとAnthropicの告知のどちらにも、いまはMHS自体の仕様書、ドライバーの形式、コード例、リポジトリへのリンクがない。