8月27日、Anthropic が Model Hardware Standard（MHS）の研究プレビューを始めた。AI エージェントが顕微鏡や分注機やロボットアームといった実物の機器を操作するための、共通の仕様だ。対象はまず研究室と先端製造の一部で、広く公開する前に安全評価と運用の作法を一緒に作る段階にある。
これは「AI がロボットを動かせるようになった」というニュースではない。動かすこと自体は前からできた。今回変わったのは、機器ごとに毎回ゼロから作っていた「つなぎ込み」の側だ。そして発表本文でいちばん具体的に書かれているのは、成果ではなく、うまくいかなかった場面のほうだった。
手を動かす人の道具立てが変わるとき、変化は性能の数字より先に、段取りのほうに出る。今回はそこを読む。
まず、確かめられることから
公開されている数字を先に置く。
カーネギーメロン大学の用量反応の実験では、機器を動かすためのドライバを用意するのに8時間かかった。ベンダーに作ってもらう構成なら通常は数週間かかるところだ。ワシントン大学では6台の機器をつなぐのに、ドライバを書く時間を含めて1週間を切った。Anthropic 自身は、統合にかかる時間が「数週間から数か月」から「数時間または数分」になると書いている。
QuEra の量子計算機のレーザー安定化では、数字の性質が少し違う。もともとのスクリプトでは1回の復旧に150秒かかり、成功率は58%だった。エージェントに一晩かけてパラメータを調整させた後は6秒・96%になり、最終的な盲検では700回の試行で99.3%が成功している。難しい擾乱でも10〜14秒だった。
ここは分けて読んでおきたい。前者は「つなぎ込みが速くなった」話で、後者は「調整そのものをやらせたら速くなった」話だ。同じ発表の中に、性質の違う二種類の改善が入っている。
規格の中身は、思ったより素朴だ
MHS がやっていることは、機器ごとにばらばらだった操作を、共通の語彙に落とすことだ。
使うのは read と write という単純な命令の組み合わせで、たとえば「温度を取得する」が read にあたる。機器ごとに標準化されたドライバが置かれ、そのドライバが、この機器は何を測れるか、何を調整できるか、どの安全上限が課されるかを書いた参照ファイルを自動で作る。機器の特徴は自然言語のタグとして書ける。
操作の経路は3つある。Model Context Protocol、コマンドライン、コードファイル。これらを組み合わせて、複数の機器を一行で束ねて動かせる、というのが売りだ。Anthropic 側はこの関係を USB になぞらえて説明している。
発想としては、機械に「あなたは何ができるのか」を自分で申告させる、ということだ。推測させるのをやめる。
速くなったのは作業ではなく、段取りだった
「AI が実験をやってくれる」と読むと、話の中心を外す。
これまで研究室や工場で時間を食っていたのは、実験そのものより手前の工程だった。機器同士が互いに口をきかず、その都度、専門の人が一対一のつなぎを書く。装置を1台足すたびに、その作業がまた発生する。MHS が削ったのは主にここだ。
だから恩恵が大きいのは、新しいことをやる場所ではなく、機器の数が多く入れ替わりも多い場所になる。逆に、既に完成した一式でずっと同じ手順を回している現場では、変わるものは少ない。
道具の規格化は、たいてい派手な場所より、面倒な場所から効く。
安全は、モデルの判断ではなく機器の側に置かれた
設計として目を引くのは、安全の置き場所だ。
MHS は機器レベルの安全上限を強制する。研究者の言葉として発表本文に出てくるのは、エージェントが誤ってレーザーの出力を上げすぎる心配をしなくてよい、という趣旨の説明だった。上限はモデルの判断ではなく、ドライバに書かれた設定として効く。
この置き方は、AI に「危ないことをしないよう」お願いする方式とは違う。賢さの側ではなく、配線の側に線を引いている。
ただし、副作用も一緒に書かれている。Claude は少しでもリスクがあると判断した操作の前で人間の確認を待って止まり、そのせいで実験が一晩止まることもあったという。安全側に倒すと、止まる。止まると、時間を失う。この二つは同じ設計の表と裏だ。
できなかったことのほうが、正確に書かれている
発表本文には、失敗の記述が具体的に残っている。
ジェネンテックのタンパク質定量の実験では、混合中に泡ができて実行時エラーが出た。このとき Claude が最初に取った行動は、同じウェルでパラメータを変えて再試行することだった。結果として液はさらに撹拌され、泡が増えた。泡がなぜできるのかという物理を理解していなかったからで、人が液の扱いを穏やかにする方向へ誘導する必要があった。
Anthropic 自身の整理も同じ方向を向いている。大規模言語モデルは物理世界をテキストと画像から学んでいるため、空間的・物理的な推論に限界がある。物理・化学・生物の制約が絡む場面、特に不具合の原因を切り分ける場面で苦手が出る。装置の理解がプログラム的であって物理的ではないので、ハードウェア側で何かが起きると手が止まる。
制約はほかにもある。プログラミング可能なインターフェースを持たない機器は、そもそも対象外だ。エージェントを長時間動かし続ける計算コストは、節約できた人の時間と天秤にかける必要がある。込み入った手順ほど、安定して動かすには相応の作り込みが要る。
つまり、機械に触れる部分の共通語はできたが、触った先で起きることの直感はまだない。
Raspberry Pi と LeRobot が入っている意味
参加している顔ぶれの中に、研究室でも工場でもない名前が混じっている。
Hugging Face は自社のロボティクス向けライブラリ LeRobot に MHS の対応を加えるとされ、Raspberry Pi はカメラ用のドライバでの試験を経て、複数の製品で MHS を使えるようにする方向だと書かれている。ほかに AWS、Automata、Danaher、Doosan Robotics、MBF Bioscience、QIAGEN、Tecan、Universal Robots といった機器側の名前が並ぶ。
Raspberry Pi と LeRobot は、個人の机の上にいちばん近いところにある。ここに対応が入るということは、将来的に、家庭や個人の工作の側でも同じ作法で機器をつなげる可能性がある、という話になる。
ただし現時点はそこではない。MHS は研究プレビューで、対象は限られた研究室と製造業者だ。公開の仕様として開かれるのはこの先で、Anthropic はそのときに研究プレビューで得た知見も一緒に出すとしている。今日から自宅の機械につなげる規格ではない。
私たちは、どう向き合うか
個人の側から見ると、この発表は「今すぐ使えるもの」ではなく「来たときの判断材料」として置いておくのが妥当だと思う。
判断の軸は、たぶん三つになる。
ひとつは、上限をどこに書くか。MHS の設計思想を家庭に持ち込むなら、「AI に気をつけてもらう」のではなく、機器の側に越えられない線を書く、という順番になる。温度、出力、可動範囲、動かせる時間帯。賢さに頼らない部分をどれだけ確保できるかで、任せられる範囲が決まる。
ふたつめは、止まることを許すかどうか。安全側に倒した AI は、迷ったら確認を待って止まる。研究室では一晩止まっただけで済んだが、家の中で止まって困るものと、止まっても構わないものは違う。暖房や給水のように止まると生活が痛むものと、記録や整理のように翌朝でよいものを、先に分けておく必要がある。
みっつめは、プログラム的にしか分かっていない相手に何を任せるか。泡の話はそのまま家庭でも起きる。何かが引っかかったとき、原因を物理として理解していない相手は、同じ操作を繰り返す方向に倒れやすい。人が見に行くまでの時間が、そのまま被害の幅になる。
コストも正直に見ておきたい。対応した機器を揃え直す出費、常時動かす場合の電気と計算の費用、そして設定を書いて確かめる時間。研究室の事例ですら、望む結果を得るには実験の文脈を大量に与える必要があったと書かれている。つまり「つないだら勝手にやってくれる」ところまでは、まだ距離がある。
見ておきたい点
次に何が起きたら景色が変わるのか、を並べておく。
一つは、仕様が公開の形で開かれる時期と、そのときに一緒に出るとされている安全評価の中身。二つめは、Raspberry Pi と LeRobot での実装が実際にどこまで降りてくるか。三つめは、プログラミング可能なインターフェースを持たない機器——つまり家庭にある大半のもの——がどう扱われるか。四つめは、物理的な不具合の切り分けが、モデル側の改善で埋まるのか、それとも機器側のセンサーと報告の作り込みで埋まるのか。
最後の一つは、たぶん一番重要だ。前者なら待っていれば来る。後者なら、買う機械を選ぶときの基準が変わる。
機械が自分の「できること」を申告するようになったとき、あなたは自分の家の機械に、何を申告させたいだろうか？
