エラーが出た。設定を変えて、もう一度やってみる。

アプリの不具合を直すときなら、よくある一手だ。ところが実験室でこれをやったAIは、状況を悪くしてしまった。相手にしていたのは、画面の中のファイルではなく、泡立った液体だったからだ。

Anthropicが2026年8月27日に紹介したModel Hardware Standard、略してMHS。AIエージェントを実験装置につなぐ仕組みの話なのだが、私がいちばん面白いと思ったのは、この小さな失敗だった。AIに手がつくと、何ができるようになり、どこでつまずくのか。泡の行方を追うと、それが見えてくる。

水も、粘り気のある液も、同じ速さで扱ってしまった

製薬企業Genentechの試験では、タンパク質の濃度を測るため、液体を吸って移す装置、容器を運ぶアーム、光の吸収を読む測定器をClaudeが連携させた。

同じ速さの扱いが泡を生み原因特定を経て速度調整で安定した出来事の流れと、それを支えるMHSという入口を分けて示す図 水のような液体と粘性の高い液体を同じ流量で扱ったことで泡が増え、人が原因(速すぎる扱い)を特定し、混合速度を落としたところ、その後は安定した扱いを保てたと報告された、という5段階の出来事の流れを上段に示す。MHSは装置に接続するための共通の入口であり、この出来事の一段階ではなく、各段階を支える基盤として下段に別枠で示している。 液体ごとに、扱う速さを探し直した 水と粘性試料では、適した流量が違う ① ② ③ ④ ⑤ 同じ速さ 泡が増加 試行・測定 結果を比較 流量を調整 MHS:機器を操作し、測定値を受け取る共通の入口
水と粘性試料に同じ流量を使うと、泡が生じて移送が不正確になった。研究者が試行範囲と比較用の熟練者データを用意し、Claudeは移送と測定を繰り返して、液体ごとの流量を探した(Genentechの公開報告)。本誌の実測ではありません。混合中の泡への対処では、別途、人が「新しいウェルへ移す」「混合回数を減らす」と伝えた事例も本文で扱っています。MHSは研究プレビューです。

最初につまずいたのは、液体ごとの違いだ。水のような液と、粘り気があって泡立ちやすいタンパク質の試料を、同じ流量で扱ってしまった。泡ができると、移す液量や測定に影響し、センサーもエラーを返す。

Claudeは同じ容器の中で設定を変えて再試行した。それが、さらに液体をかき混ぜ、泡を増やした。人が「原因は物理的な泡だ」と説明し、きれいな容器へ移って混合回数を減らすよう導くと、その後はその条件を保てたという。学んだ扱い方は、再利用できる手順にも残された。Anthropic掲載のGenentechによる実施報告

台所で、泡立った飲み物をさらにかき混ぜたらどうなるか。実験用の液体と同じではないけれど、「もう一回」が元へ戻す操作ではないことは、想像できると思う。

ソフトウェアでも、再試行してよいとは限らない。決済やメール送信を二重に実行したら困る。だから重複を防ぐ仕組みを設ける。物理の世界では、それに加えて、温度が上がった、試料が減った、泡が増えたという変化が残る。失敗した手順をやり直す前に、いま目の前の状態がどう変わったかを見なければならない。

「機械をつなぐ」と「実験を進める」の間

では、MHSは何をするのだろう。

実験の意図を、機器の操作へつなぐ。研究室を描いた生成イメージで、MHS対応製品や安全な操作手順の実演ではありません。

実験室には違うメーカーの装置が並ぶ。それぞれ操作方法も、データの返し方も違う。人なら画面や説明書を読んで行き来できるが、プログラムでまとめて動かすには、間をつなぐソフトが要る。

MHSは、装置を見つけ、状態を読み、操作する入口を揃える研究プレビューだ。装置の特徴や制限もエージェントへ伝え、MCPやAPIなどを通じて扱う。2026年9月時点では参加を募る段階で、完成した万能規格が普及済みという話ではない。MHS研究プレビュー

仕組みのイメージなら、こう考えると分かりやすい。AIが「試料を移して測って」と考えても、アームは、液体を扱う装置が動いている最中に突っ込んではいけない。装置側の完了信号を待ち、置く場所が空いたら運ぶ。こうした順序や停止条件を、毎回AIの文章判断だけに任せるのではなく、機器と制御ソフトで守る。

その上で、結果を読んで次の条件を考えるところへAIを入れる。決まった順序を繰り返す自動化と、結果に応じて次を選ぶ働きが、組み合わさるわけだ。

すでにある実験自動化とは、何が違うのか

実験装置をつなぐ努力は以前からある。例えばSiLA 2は、装置の機能を共通の形で記述し、ソフトウェアから扱うための標準だ。つなぐ規格がなかったから、突然MHSがすべてを発明したのではない。SiLAの公式解説

違いを考えるなら、同じ実験を一万回繰り返す場面と、今日の結果を見て明日の条件を変える場面を分けるとよい。前者なら、安定した専用プログラムが強い。後者では、変更のたびに装置間の制御を組み直す手間が重くなる。

AIが役立つ余地は、その変更を考え、コードへ落とし、結果を読んで次へつなぐところにある。研究者が「なぜこうなったのだろう」と思ったときに、もう一本試すまでの距離が短くなる。装置をただ自動で動かすことより、こちらのほうが研究には効くのではないかと思う。

失敗を教えることも、研究になっている

実験室のロボットを調べるLabRobFailという研究は、操作がうまくいった映像だけでなく、失敗を見つけ、どこで起きたかを捉えるためのデータを用意している。2026年7月公開の査読前研究で、制御の間違い、物理的な異常、作業の意味の食い違いなどを扱う。LabRobFail原論文

これを読んでも、Genentechで使われたClaudeに何の学習データが不足していたかまでは分からない。ただ、「成功手順を覚えるだけでは足りない」という研究上の課題は、泡の一件とよくつながる。

例えば、容器を置く場所がずれているなら位置を直す。中身が変質したなら、位置を直しても回復しない。何が失敗したかによって、次の一手はまったく違う。装置に触れるAIには、この見分け方も必要になる。

試せなかった一回が、試せるようになる

私には、この話はAIの不得意を笑う材料というより、協働が具体的になってきた証拠に見える。

人間は、研究の狙いと、現場で起きたことの意味を伝える。AIは、たくさんの候補を整理し、操作を組み、結果を並べる。間違いを指摘した後に、その教訓を次の試行へ残していける。そうなれば、同じ失敗のたびに人が最初から説明し直す負担も減らせる。

もちろん試料や装置を守る仕組みは要る。でも、その目的はAIを実験室へ入れないことではない。安心して任せられる範囲を広げ、研究者の「これも試してみたい」を実行へ近づけるためだ。

泡を増やしてしまったAIに、人が泡の意味を教えた。その先に、まだ試せていなかった実験が一本増える。機械に手が届くというのは、そういう可能性の広がりなのだと思う。

MHSの実施例は開発元と協力先の報告に基づき、本誌による実機検証ではありません。具体的な薬剤操作や機器の安全判断は、各施設の専門家・手順に従う必要があります。