AnthropicがModel Hardware Standardのresearch previewを公開｜MCPとの違いと、一般企業がいま学べる設計原則

Anthropicが2026年8月27日、Model Hardware Standard(MHS)のresearch previewを公開しました。AIエージェントが顕微鏡・分注機(liquid handler)・ロボットアームといった物理デバイスを、ベンダーごとの個別インタフェースではなく共通のドライバ仕様経由で発見し、操作するための仕様です。名前も発想もMCP(Model Context Protocol)と似ていますが、扱う対象が違います。この記事では、公式発表に書かれている事実を整理したうえで、実験室も製造ラインも持たない一般企業にとって「いま関係があるのか、ないのか」を正直に切り分け、それでも設計として持ち帰れるものを取り出します。

何が公開されたのか#

Anthropicの発表によれば、MHSは「AIエージェントが物理デバイスを安全に操作するための共有仕様」で、まずは科学研究ラボと先端製造業の第一陣に対してresearch previewが開かれました。想定されている装置は顕微鏡・分注機・ロボットアームなどで、用途としては創薬実験の定型作業から、量子コンピュータのレーザー校正までが挙げられています。開発はAnthropicとHHMI Janelia Research Campusの共同作業として始まったと明記されています。

前提として置かれている課題は素朴なものです。ラボや製造現場がハードウェアをセットアップして統合するには、通常で数週間から数か月かかる。装置同士は基本的に会話せず、専門家が個別の統合を作り込む必要がある。そして、装置がつながったあとも、AIエージェントとデータを共有する共通の方法も、エージェントに安全に操作させる共通の方法も存在しない。MHSはこの統合作業を「数時間から数分」に縮めるものだと説明されています。

出自も公式に書かれています。MHSは、AnthropicのBeneficial Deploymentsチームの担当者と、HHMI Janelia Research Campusのポスドク研究者の共同作業として始まりました。後者は、レーザー・電動フォーカサー・異なるベンダーの専用カメラが共通インタフェースなしに同居するリグで脳イメージング実験を回しており、実験を速めるために、装置同士がメモリ速度で通信できる共有メモリ上の辞書を作りました。リグ全体の状態を1つの標準化された辞書に置くというこの発想が起点になり、そこへAIモデルを統合する形で標準へ育っています。仕様が先にあって現場に降りてきたのではなく、現場の回避策が標準化された、という順序です。

仕組み:標準ドライバと、自動生成される参照ファイル#

readとwriteという最小のプリミティブ#

MHSが導入するのは標準化されたドライバです。ドライバはOSとハードウェアの間を翻訳するソフトウェアで、MHSのドライバは「read(例:温度を取得する)」「write(例:温度を設定する)」という単純なプリミティブの集合を使います。どんなハードウェアでも理解して実行できる粒度まで語彙を落とす、という設計です。あわせて、各デバイスを標準形式で発見可能にし、間に専用の翻訳プログラムを挟まなくてもデバイスとエージェントがネットワーク越しに互いを見つけて通信できるようにします。

装置の特性と安全上限をドライバに持たせる#

もう1つの柱が、装置の特性の記述です。エージェントが初めて見る装置を扱えるようにするには、コードだけからは読み取れない情報が要ります。公式が例として挙げているのは、ロボットアームの重量です。安全に動かすために必要な情報でありながら、これまでは紙のマニュアルや個人のPC、あるいは担当者の暗黙知として散らばっていました。

MHSのドライバには、こうした情報を自然言語で直接書き込めるタグがあります。利用者が自分で書いてもよいですし、エージェントに設備構成をヒアリングさせる形でも構いません。そのタグの情報をもとに、ドライバは装置の一般的な特性を記した参照ファイルを自動生成します。含まれるのは「何を測れるか」「何を変更できるか」「どんな安全上限が強制されるか」です。この参照ファイルが、エージェントがその装置を操作するために必要な情報一式になる、という組み立てです。

操作経路はMCP・CLI・コードファイルの3つ#

装置がつながり、エージェントが使い方を把握したあとの制御経路は3つ用意されています。MCP、コマンドラインインタフェース、そしてコードファイル(API)です。公式は、これらが組み合わさることで、1行のコードから複数装置をまたいだオーケストレーションが可能になると説明しています。

この3経路の使い分けにも理由があります。エージェントが長時間のタスクを実行する場合や、オンラインの推論では追いつかない速度で装置を動かす必要がある場合、複数装置のドライバコマンドをコードファイル側で連結できます。これにより、エージェントが1ステップごとに推論しなくても、装置側が処理を実行できます。公式には、Claudeがレーザーを調整してはカメラで結果を観察するという探索を繰り返し、学んだことをコードファイルにまとめて決定論的なスクリプトを書き、以降は単一コマンドでレーザーのアライメントを実行できるようにした例が記載されています。推論で探索し、確定した手順は決定論的なコードへ落とす、という順序です。

標準が吸収するのは「制御方式の寄せ集め」#

抽象論だと分かりにくいので、公式に載っているCarnegie Mellonの構成を借ります。同ラボの装置は3台のPCに分かれていて、制御方式がそれぞれ違いました。1台目はロボットアームで、通常のAPIではなく、投入用ディレクトリに置かれたジョブファイルを読むスケジューリングソフト経由。2台目は分注機で、古いWindowsのActiveX/COMスクリプティングインタフェース、加えてUSB接続の監視カメラ。3台目はプレートリーダーで、プログラム的なインタフェースが一切なく、画面上のGUIしかありません。

MHSはこの3つを、状態(その系が取りうる条件。たとえば「プレートが位置3にある」「試料が25度」「ウェルが満たされている」)と手順(吸引する、振とうするなど実行できる操作)という1つのマニフェストに変換します。下でどの制御方式が動いていようと、モデルから見えるインタフェースは1つに揃う、という説明です。

現場の統合が重いのは、装置の性能差ではなく、この「制御方式の寄せ集め」を毎回人手で吸収しているからです。ソフトウェアの世界でレガシーAPI・CSV連携・画面操作の自動化が同居している状況と、構造としては同じ問題を扱っています。

MCPとの関係と違い#

MHSはMCPを置き換えるものではありません。役割の階層が違い、MHSはMCP経由でも触れます。整理すると次の通りです。

MCPが「AIと外部ツールをつなぐ共通コネクタ」を担うのに対し、MHSは「その先にある物理装置を、どう記述し、どこまで動かしてよいかを含めて標準化する」層だと捉えると整理しやすくなります。MCPそのものの基礎は

早期の事例で確認されたこと#

公式発表には、パートナー各社が自ら書いた事例が併載されています。数字はいずれもパートナー自身の報告であり、第三者による再現検証ではない点に注意して読む必要があります。

• Genentech: 分注機・ロボットアーム・マイクロプレートリーダーの3台を協調させるBCAタンパク質定量アッセイの自動化を、概念実証として実施。Claudeが試行転送と吸光度測定を繰り返し、水では約140µL/s、粘性のあるBSA溶液では10µL/sという流量に収束させた
• Carnegie Mellon University: 分注機・プレートリーダー・ロボットアーム・監視カメラを組み合わせた用量反応曲線の測定を、約3倍高速化。生の非自動化状態から曲線完成までの所要時間は約8時間で、ベンダーによる自動化構築が通常数週間かかるのと対比されている
• QuEra Computing: 量子コンピュータのレーザーの「ロック」復帰を自動化。専門家4名が数か月かけて作った既存スクリプトは成功率約58%・1回あたり約150秒だったのに対し、エージェントが一晩の反復で書き換えたスクリプトは開発時の計測で約6秒・96%、後日のブラインドテストで99.3%と報告されている
• HHMI Janelia: 7つのベンダープログラムが共通インタフェースなしに同居していた顕微鏡リグをMHSで統一。別チームでは、半日かかっていた手作業のセットアップが単一の手順になったとされる
• Tetsuwan Scientific: 自社の自動生物実験プラットフォームResearchOSにMHSを統合し、カリフォルニア州San Pedro Creekの汚染源を調べるqPCRワークフローを実行
• University of Washington(Baker/Pinglay labs): 装置を遠隔監視するダッシュボード、増幅曲線を見て適切な時点で停止するエージェント監督付きのqPCR、LeRobotベースのロボットアームと分注機の衝突しないプレート受け渡しを構築

このうち、業務目線でいちばん見るべきなのはCarnegie Mellonの安全検証です。MHSが人間のオペレーターと同じように安全に動作し、自己修正するかを確かめるため、プレート欠落・プレートの回転・リーダーがビジー・カメラ切断・デバイス到達不可・非常停止が作動中、という6つの条件を人為的に発生させたところ、システムは6件すべてを「いずれの装置も動く前に」ブロックしたと報告されています。動かしてから異常を検知するのではなく、動かす前に不可能・不安全な要求を弾いた、という順序が要点です。

推論で探索し、確定したら決定論的な処理へ落とす#

QuEraの事例は、エージェントの使い方として参考になります。従来のスクリプトは、人間が現場でやる手順をそのまま順番に写したものでした。ロックを保持している機能を解除し、チューニング制御を順に動かし、都度周波数を確認し、外れていればやり直し、正しくなったらロックをかけ直す。この直線的な手順は、途中の変化を吸収できません。誰かがラボのドアを開けて温度や気圧が動いただけで、成功していた手順が巻き戻り、最初からやり直しになります。

QuEraはこの問題をMHS経由でClaudeに渡しました。エージェントのループは4つの役割に分かれ、それぞれが別インスタンスとして動きます。1つが復帰を速く確実にする仮説を出し、1つがその変更をスクリプトへ書き、1つが実機に対して実行して全ステップを記録し、1つが記録を読んで次に何を変えるかを決める。これを無人で一晩、数百回繰り返した結果、収束したスクリプトは直線的な手順ではなく決定木の形になっていたと報告されています。各計器を読み、その値からif-thenの条件を組み立てて調整する構造です。

ここで注目したいのは、最終成果物がエージェントではなくスクリプトである点です。運用時に毎回モデルへ推論させるのではなく、探索の段階だけモデルを使い、確定した手順は決定論的なコードとして固定する。前述のレーザーアライメントの例と同じ形で、レイテンシもコストも再現性も、この切り分けで大きく変わります。

一般企業にいま関係あるか:正直なところ薄い#

結論から言えば、実験装置も製造ラインも持たない企業にとって、MHSはいま直接手を動かす対象ではありません。理由は3つあります。

1つ目は、対象が明確に絞られていることです。research previewの提供先は科学研究ラボと先端製造業の第一陣であり、参加は申請制です。2つ目は、仕様がまだ公開されていないことです。Anthropicは「オープンソース化する前に、標準についてやるべき作業がまだある」と述べており、公開時点で仕様書もリファレンス実装も一般公開されていません。3つ目は、適用条件です。MHSはプログラム可能なインタフェースを持つデバイスで動作し、プログラミングインタフェースを持たないハードウェアにはまだ対応していないと明記されています。

関係が出てくるとすれば、自社が装置メーカーである場合、ラボや製造現場を持つ場合、あるいはロボティクス製品を扱う場合です。公式発表にはAWS(Strands Robots)、Automata、Danaher、Doosan Robotics、MBF Bioscience、QIAGEN、Tecan、Universal Robotsといったハードウェアベンダー・支援企業が対応を進めていることや、Hugging FaceがLeRobotに、Raspberry Piが自社製品にMHS対応を追加する早期採用者として挙げられています。オープンなロボット学習基盤の流れは

もう1つ、間接的な影響として見ておきたいのが、社内で「AIに物理的な操作をさせたい」という話が出たときの判断材料です。オフィスの入退室、什器の制御、倉庫の搬送機器といった相談は、生成AIの導入が進んだ組織では自然に出てきます。MHSとその事例が示しているのは、そうした要望に対して必要になるのが賢いモデルではなく、装置の能力と上限の機械可読な記述、そして動かす前に弾く検査だという点です。この構図を知っていると、「まずPoCで動かしてみる」以外の答えを持てます。

それでも学べる3つの設計原則#

MHSが物理装置向けに採った設計は、そのままソフトウェアのエージェント設計に読み替えられます。ここが本記事でいちばん持ち帰りやすい部分です。

1. 能力の記述を、呼び出し側ではなくリソース側に持たせる#

MHSは、装置の特性・測定できる項目・変更できる項目・安全上限を、装置側のドライバに書かせています。エージェント側のプロンプトに書き足していく設計だと、対象が増えるほど指示が肥大化し、装置の入れ替えのたびに更新漏れが起きます。社内システム連携でも同じことが起こります。「このAPIは月末は使えない」「この項目は更新すると請求に影響する」といった知識が、特定のプロンプトの中だけに書かれていないか。ツール定義やスキーマの側に寄せられないか。この問いは、装置を1台も持っていないチームにも効きます。

2. 安全上限は、指示ではなく実行層で強制する#

参照ファイルに書かれるのは「どんな安全上限が強制されるか(what safety limits will be enforced)」です。エージェントに守ってほしい上限ではなく、実行層が強制する上限として表現されている点が重要です。ソフトウェア側でも、「本番DBは更新しないでください」とシステムプロンプトに書くのと、読み取り専用の資格情報しか渡さないのとでは、安全性の質がまったく違います。入力・出力・挙動の3層で境界を作る考え方は

3. 物理的に不可能な操作は、エージェントに渡す前に弾く#

Carnegie Mellonの6条件の検証は、この原則の実例です。プレートが無い・回転している・カメラが切れている・非常停止中といった前提条件は、エージェントの判断力に委ねるべき事柄ではありません。実行の直前に機械的にチェックし、条件を満たさなければ装置を動かさない。ソフトウェアに置き換えれば、「対象レコードが存在するか」「権限があるか」「同一処理が実行中でないか」を、エージェントの推論ではなく事前条件のチェックとして持つ、ということです。人の承認をどこに置くかという判断とは別レイヤーの話で、承認の設計は

現時点で分かっていないこと#

固有事実として確定していない点を、確定しているように書かないために整理しておきます。

• オープンソース化の時期: 「オープンソース化する前にやるべき作業がある」とされるのみで、具体的な時期は示されていません
• ライセンス: 公開時にどのライセンスで提供されるかは述べられていません
• 対応デバイスの範囲: プログラム可能なインタフェースを持つデバイスが対象で、それを持たないハードウェアは未対応です。ただしCarnegie Mellonの事例では、APIを持たないプレートリーダーのGUIをMHS側から人と同じように操作した例も報告されており、境界は実装依存の面があります
• 安全評価の中身: research previewの目的の1つとして、パートナーとともに追加の安全評価を作ることと、物理世界でのAI利用に対する保護を強化することが挙げられています。評価項目そのものは今後の公開待ちです
• 一般提供の条件: 現時点では申請制のウェイトリストです

本記事の記述は、Anthropicの公式発表「Previewing the Model Hardware Standard」(2026年8月27日)に書かれている内容を根拠にしています。事例中の数値は、同ページに掲載された各パートナー自身の報告です。QuEraとTetsuwan Scientificについては、各社のブログにも詳細が公開されています。

FAQ#

まとめ#

MHSは、AIエージェントの守備範囲がソフトウェアから物理装置へ広がるときに何が必要かを、Anthropicが具体的な仕様として提示したものです。read/writeという最小のプリミティブ、そして装置側に置かれた特性と安全上限の記述。ここに、Carnegie Mellonの検証で確認された「装置が動く前に弾く事前検査」という運用を重ねると、研究ラボや製造現場の話としてだけでなく、エージェント設計の一般的な作法として読めます。

同時に、いまの適用範囲は限定的です。research previewであり、仕様は非公開で、対象はプログラム可能なインタフェースを持つ装置に限られ、モデル自身の物理推論には明確な限界が残っています。装置を持たない企業が急いで対応する必要はありません。仕様がオープンソースとして公開された段階で、あらためて自社の装置・製品との接点を確認する。それまでは、設計原則だけを自分たちのエージェントに移植しておく。この距離の取り方が、現時点では妥当だと考えています。