Anthropic Model Hardware Standard（MHS）とは？AIが顕微鏡・ロボットアームを動かす新標準とMCPとの違い・研究プレビュー参加条件【2026年8月最新】

Model Hardware Standard（MHS／モデル・ハードウェア・スタンダード）は、AIエージェントが顕微鏡・ロボットアーム・液体分注機といった物理機器を安全に操作するための共有仕様です。 Anthropicが2026年8月27日（米国時間）に研究プレビュー（リサーチプレビュー）の第1フェーズを発表しました。同社がMCPで「AI ↔ ソフトウェア」の接続を標準化したのに続き、今回は「AI ↔ 物理ハードウェア」の接続を標準化しようとしています。

ただし現時点（2026年8月29日）で、MHSは申込・選考制の限定研究プレビュー段階です。仕様書・SDK・GitHubリポジトリは一般公開されておらず、一般の開発者が今日から触れる状態ではありません。この記事では、公開されている一次情報の範囲で「何ができて、何がまだできないのか」を整理します。

この記事でわかること:

• MHSの定義と、Anthropicがこの規格を出した狙い
• 標準ドライバ・デバイス発見・自然言語タグなど、アーキテクチャの中身
• MCPとの関係（置き換えなのか、共存なのか）を表で整理
• 公式が公開した実証データ（QuEra・カーネギーメロン大・Genentechなど）
• Anthropic自身が認めている「できないこと」と限界
• 安全性の担保方法と、EU機械規則2027年適用という規制論点
• 研究プレビューの対象組織・申し込み方法・実質的な参加条件

想定読者: 研究ラボ・先端製造業でラボ自動化を検討している方、ハードウェアメーカーで制御ソフトの標準対応を判断する立場の方、MCPの次に来る標準規格の動向を正確に押さえたいエンジニア・企画担当者。

Model Hardware Standard（MHS）とは — 概要と基本情報

出典: Anthropic公式サイト

MHSは、プログラマブルインターフェースを持つあらゆる機器を、AIエージェントから共通のコマンド体系で操作できるようにする仕様です。Anthropicの公式表現では「a shared specification for AI agents to safely operate physical devices（AIエージェントが物理デバイスを安全に操作するための共有仕様）」とされています。

起源は、Anthropicのアレク・ケメニー（Alek Kemeny）氏と、Janeliaのポスドク研究者アルコ・バスト（Arco Bast）氏が開発した「shared memory dictionary（共有メモリ辞書）」です。複数のプログラムが同一のメモリ領域を参照して機器の状態をやり取りできる仕組みで、これがMHSの原型になりました。ゼブラフィッシュのイメージングを伴う顕微鏡研究が最初の実験場です。

Anthropicのケメニー氏はMHSの位置づけをこう表現しています。

What MCP did for software, MHS will do for the hardware world.
（MCPがソフトウェアに対して果たしたことを、MHSはハードウェアの世界で果たす）

ここで重要なのは、MHSは基盤モデルでもロボット制御モデルでもなく「接続規格」だという点です。Gemini Robotics 2やNVIDIA Cosmos 3のような物理AIのモデルが「どう動かすか」を担うのに対し、MHSは「どうつなぐか」を担います。担当するレイヤーがそもそも違います。

なぜMHSが必要になったのか — ラボ機器は「翻訳プログラムの山」だった

出典: Howard Hughes Medical Institute（HHMI）公式サイト

MHSが解こうとしているのは、機器ごとに制御方法がバラバラで、統合に数週間から数カ月かかるという現場の課題です。

研究ラボや製造ラインの機器は、メーカーごとに独自のドライバ・独自のコマンド体系・独自のファイル形式を持っています。液体ハンドラーはWindows PCの専用ソフトから、プレートリーダーは別のPCから、ロボットアームはさらに別のコントローラから動かす、という構成が珍しくありません。機器をまたいだ自動化をしようとすると、そのたびに機器ごとの「翻訳プログラム」を書く必要がありました。

Anthropicによれば、MHSはこの統合作業を数時間〜数分の単位に短縮することを狙っています。実際、カーネギーメロン大学の事例では、箱から出したばかりの機器からワークフロー完成までが8時間だったと公式が記載しています（従来は数週間）。

この構図は、AIエージェントとソフトウェアの接続でMCP（Model Context Protocol）が解決した問題とよく似ています。MCP以前は、AIに社内ツールを触らせるたびに個別のインテグレーションを書く必要がありました。MHSはその発想を物理機器に持ち込んだものだと理解すると、位置づけが掴みやすくなります。

MHSの仕組み — アーキテクチャを構成する4つの要素

公式発表から読み取れるMHSの構成要素は、大きく4つです。「read／writeという極端に単純なコマンド」と「自然言語で書く安全上限」の組み合わせが設計の中核になっています。

1. 標準ドライバ（standardized driver）

OSとハードウェアデバイスの間を翻訳する層です。プリミティブは驚くほど単純で、基本は次の2つだけです。

• read — 状態を取得する（例: 現在の温度を読む）
• write — 状態を設定する（例: 温度を設定する）

顕微鏡でも遠心分離機でもロボットアームでも、この共通のコマンド体系で扱えるようにするのがドライバの役割です。プリミティブを絞り込んだことで、機器ごとの差異をドライバ側に閉じ込められます。

2. デバイスディスカバリ（標準フォーマットでの発見）

MHSに対応した機器は、標準フォーマットで「発見可能」な状態になります。デバイスとエージェントがネットワーク越しに互いを見つけて通信できるため、機器ごとの接続コードを毎回書く必要がなくなるのがポイントです。

エージェント同士が互いを発見する仕組みとしてはA2AプロトコルやAgentic Resource Discovery（ARD）がありますが、MHSのディスカバリはその物理デバイス版に相当します。

3. 自然言語タグとリファレンスファイルの自動生成

MHSドライバには、機器の情報を自然言語で書き込めるタグが用意されています。ユーザーが自分で書いてもよいですし、エージェントが担当者に聞き取り（インタビュー）をしながら書かせることもできます。

このタグ情報から、ドライバが自動的に「リファレンスファイル」を生成します。含まれるのは次の3点です。

• その機器が何を測定できるか
• 何を調整できるか
• どの安全上限（safety limits）が強制されるか

つまり、機器の取扱説明書に相当する情報を、エージェントが読める形式で機器自身が持つ構造になっています。安全上限をこのファイルに書き込むことで、エージェント側の判断に頼らずデバイス側で逸脱を止められます。

4. 3つの制御メカニズム（併用可能）

エージェントから機器を操作する経路は3種類が用意されており、用途に応じて併用できます。

MHSはMCPを置き換える規格ではなく、MCPを通信手段の1つとして内包しています。

MHSとMCPの違い — 「置き換え」ではなく「レイヤーの追加」

出典: Model Context Protocol 公式サイト

MHSはMCPの後継でも代替でもありません。 MCPが「AI ↔ ソフトウェア／データ」を担うのに対し、MHSは「AI ↔ 物理デバイス」を担い、その通信手段の1つとしてMCPを使います。

決定的に違うのは失敗時のコストです。MCPで事故が起きた場合、影響はデータやアカウントの範囲に収まります（それでも重大ですが、原状回復の余地はあります）。実際にAIエージェントがデータを全削除した事故のように、ソフトウェア領域でも深刻な事例は起きています。しかしMHSの領域では、誤ったコマンドがサンプルを焼く・機器を衝突させる・危険な薬品を分注するといった不可逆な物理的損害に直結します。だからこそMHSは、プロトコルの上に「安全上限の強制」という層を持たせています。

乱立する新標準の住み分け

2026年に入り、エージェント関連の標準は複数並走しています。混同しやすいので整理します。

それぞれ競合ではなく、担当レイヤーが違います。MCP側の今後の方向性はMCP新ロードマップの解説で、パッケージング層の議論はAgent Plugins 1.0.0の解説で扱っています。

公式が公開した実証結果 — 数字で見るMHSの効果

出典: QuEra Computing 公式サイト

Anthropicは研究プレビューの発表と同時に、ローンチパートナーによる実証結果を公開しています。これらはすべて公式ブログ由来の数値であり、第三者による再現検証はまだ公開されていません。

注目すべきは「学習内容をコードに固める」動き

QuEraとGenentechの事例に共通するのは、エージェントが試行錯誤して得た知見を、最終的に決定論的スクリプトへ落とし込んでいる点です。

流れとしてはこうです。Claudeがレーザーやポンプのパラメータを調整する → カメラやセンサーで結果を観察する → 反復して事象の順序を理解する → 学んだ手順をコードファイルに固定する。以降は毎回LLMに推論させる必要がなくなり、再現性とコスト効率の両方を確保できます。

QuEraでは複数のClaudeインスタンスが夜間に最適化ループを走らせたとされており、これはマルチエージェントの構成が物理機器の制御に持ち込まれた事例と言えます。Anthropicが科学研究向けに展開しているClaude Scienceと組み合わせると、「仮説を立てる層」と「機器を動かす層」が接続される構図になります。

MHSでできないこと・現時点の限界

MHSの評価で見落とされがちですが、Anthropic自身が公式発表の中で複数の限界を明記しています。 導入判断ではこちらのほうが重要です。

1. プログラマブルインターフェースを持たない機器では使えない

公式は「MHS doesn't yet work with hardware that lacks a programming interface」と明記しています。手動ノブ式の機器や、外部から制御APIが出ていないクローズドな旧型機器はそのままでは対象外です。メーカー側のドライバ提供やレトロフィットが前提になります。

古い機器が多いラボ・工場では、MHS対応以前に「そもそも制御可能な機器か」の棚卸しが必要です。

2. 物理・化学・生物的な制約の理解が弱い

公式の表現を引用します。

As a large language model, Claude learns about the physical world through text and images, meaning its spatial and physical reasoning have limitations.
（大規模言語モデルであるClaudeは、テキストと画像を通じて物理世界を学ぶため、空間的・物理的な推論には限界がある）

特に苦手なのが、実世界の物理的直観を要するトラブルシューティングです。Genentechの事例では、タンパク質サンプルの泡（foaming）に由来するエラーをClaudeがソフトウェアのバグと誤認し、研究者が「そのエラーコードは物理的な気泡が原因である」と教える必要がありました。

公式も「Claudeの装置理解は物理的というよりプログラム的だった」と記しています。ハードウェア故障の切り分けは、依然として人間の領域です。

3. 完全無人化ではなく、専門家の伴走が前提

現時点のMHSは「研究者を置き換えるもの」ではなく「研究者が伴走する自動化」です。リスクの高い操作の前にエージェントが人間の承認を待って夜間に停止する、というケースも公式に記載されています。24時間動くこと自体は可能でも、朝に人間が判断する運用は残ります。

4. 対応機器カテゴリがまだ狭い

遠心分離機、自動インキュベーター、各種分析機器、センサー類など、今後追加のハードウェア対応が必要だと公式が明記しています。現時点でカバーされているのは限られたカテゴリです。

5. 仕様が未公開・未確定

公式は「We have more work to do on the standard before we open-source it.」としています。つまり仕様は今後変わりうるということです。現時点で自社製品にMHS対応を作り込むと、仕様変更で手戻りが発生するリスクがあります。

6. 一般ユーザーは今すぐ使えない

研究プレビューは申込・選考制です。対象は科学研究ラボ／先端製造業／ハードウェアメーカーで、個人開発者が今日からインストールして試せる状態ではありません。

安全性はどう担保されるのか — デバイスレベルの上限と規制の論点

MHSの安全設計の核は、「エージェントが暴走しても、機器が動く前にデバイス側で止める」という考え方です。ソフトウェア側の判断だけに依存しない構造になっています。

デバイスレベルの安全上限の強制

自然言語タグで記述した安全境界がドライバに埋め込まれ、エージェントが逸脱した指示を出しても機器が動作する前にブロックされます。公式によれば、カーネギーメロン大学の検証では人為的に発生させた6件の障害をすべて「デバイスが動く前に」ブロックしたとされています。

報道で具体例として挙がっているのは次のようなケースです。

• プレート搬送時の機器同士の衝突防止
• サンプルを焼くレベルの過大なレーザー出力の遮断
• プレートの欠落・回転（誤セット）の検知
• 異常検知時の緊急停止

安全性評価の共同構築が研究プレビューの目的

Anthropicは、研究プレビューの主目的自体を「ローンチパートナーとともに安全性評価（safety evaluations）を構築すること」だとしています。加えて、physical safety roadmap（物理安全ロードマップ）を策定中であることも明言しており、オープンソース化の際にはプレビューで得られた知見を安全な導入ガイダンスとして併せて公開する方針です。

つまり現段階のMHSは、「完成した安全機構を配る」フェーズではなく「安全機構を一緒に作る」フェーズにあります。

見落とされがちな規制論点：EU機械規則2027年適用

日本語圏でほとんど触れられていませんが、製造業にとって無視できない論点があります。EUの機械規則（Machinery Regulation (EU) 2023/1230）が2027年1月20日に適用開始され、従来の機械指令を全面的に置き換えます。この新規則は、AIベースの安全機能や自己進化する機械の挙動を初めて明示的に規制対象に含めています。

海外メディア（The Next Web）が指摘しているのは、ハードウェアの動作を制約するMHSのリファレンスファイルや安全上限の定義が、「規制対象の安全コンポーネント」に該当する可能性です。該当するなら、簡易な自己適合宣言では足りず、notified body（第三者認証機関）による正式な評価が必要になり得ます。オープンソース化後にドライバや安全定義を書く人が、自覚のないまま規制対象の安全部品の作者になっている、という構図になりかねません。

※ これは報道による法的解釈であり、EU当局やAnthropicの公式見解ではありません。 EU市場向けの機器を扱う企業は、自社の法務・認証部門への確認を推奨します。

なお、エージェント運用全般のリスク整理はAIエージェントのセキュリティ対策にまとめています。MHSの文脈では、そこに「物理的損害」「化学的・生物学的リスク」という次元が追加されると考えるとよいでしょう。

ROS 2との関係はまだ議論段階

ロボティクス実務者からは「MHSとROS 2はどう関係するのか」という疑問が出ています。Open Robotics のコミュニティフォーラムでは、MHSをURDF／SDFに近い「基盤的なドライバ記述標準」として位置づけ、その上に意図検証（intent validation）層を置くという多層防御の整理案が議論されています。URDFのジョイント制限、ros2_controlのインターフェース、sensor_msgsのフィールド標準をMHSのリファレンスファイルにどうマッピングするか、という具体的な論点も出ています。

※ これらはコミュニティの提案段階であり、Anthropic公式のROS 2対応方針ではありません。

研究プレビューの参加条件と申し込み方法

出典: Claude Platform Docs（Anthropic公式）

研究プレビューは第1フェーズが2026年8月27日に開始されました。申込制かつ選考制で、誰でも参加できるものではありません。

対象となる組織

公式サイトおよび発表内容から読み取れる対象は、次の3類型です。

申し込みの流れ

1. 公式サイト（https://modelhardwarestandard.com）にアクセスする
2. サイト上の申込フォーム（Google フォーム）から必要事項を送信する
3. Anthropic側の選考を経て、採択された組織にアクセスが提供される

実質的な参加条件は「共同開発へのコミットメント」

ここが最も重要です。研究プレビューの目的が安全性評価の構築である以上、採択された組織は「先に使わせてもらう」だけでなく、オープンソース化前の安全性評価づくりをAnthropicと共同で行う立場になります。フィードバックの提供、ベストプラクティスの策定、テスト環境の提供といった実務コミットが前提です。

「とりあえず試したい」という温度感の組織より、自社の機器・ワークフローで具体的に検証したいテーマがあり、担当エンジニアを割ける組織のほうが通りやすいと考えるのが自然です。

未確認の項目

以下は現時点で公式に示されていません。断定できないため、未確認のまま記載します。

• 選考基準・採択数・プレビュー期間
• 第2フェーズ以降のスケジュール（公式は「first phase」とのみ表現）
• 日本国内からの申込可否・日本語サポートの有無
• 参加費用の有無

対応パートナー・エコシステムの現状

MHSの現実味を測るうえで、どのベンダーが対応を表明しているかは重要な指標です。発表時点で、ユーザー側とベンダー側の両方に名前が並んでいます。

研究・実証パートナー（使う側）

HHMI Janelia Research Campus／Genentech／カーネギーメロン大学／ワシントン大学（Baker Lab・Pinglay Lab）／QuEra Computing／Tetsuwan Scientific

対応を実装・計画するベンダー（作る側）

特に注目したいのはMBF Bioscienceです。ScanImageは世界の数百の神経科学ラボで使われている顕微鏡制御ソフトで、ここにMHSドライバが載ると、既存の研究資産を持つラボが比較的低コストでAIエージェント制御に移行できる可能性があります。

またRaspberry PiとLeRobotが入っていることで、大型のラボ機器だけでなく小規模な自作リグにも降りてくる導線が用意されています。

※ 日本企業のMHS対応は、現時点で確認できていません（Doosan Roboticsは韓国、Tecanはスイス、QIAGENは独・蘭を拠点とする企業です）。

他社のフィジカルAIとの違い — レイヤーが違う

「MHSはGemini RoboticsやNVIDIA Cosmosの競合なのか」という疑問がありますが、基本的にレイヤーが異なります。

MHSは「どう動かすか」を決めるモデルではなく、「どうつなぐか」を決める規格です。理屈のうえでは、Gemini Robotics系のモデルがMHS経由で機器を叩く構成もあり得ます（実際にClaude以外での公開実証はまだありません）。

各モデル側の詳細は、Gemini Robotics 2、NVIDIA Cosmos 3、Figure AI Helix-02でそれぞれ整理しています。国内の動向としては国産フィジカルAI基盤モデルのNoetraもあり、標準化の主導権争いという意味ではMetaによる Assured Robot Intelligence 買収の動きも同じ文脈で読めます。

なお、AnthropicにとってMHSはフィジカルAI領域への実質的な初参入です。これまでのClaudeは基本的に画面の中で完結していました（Claude Opus 5などのモデル自体はソフトウェア領域の製品です）。ライフサイエンス領域ではOpenAIのGPT-Rosalindのような動きもあり、「AI × 科学」の競争は基盤モデル層と実行環境層の両方で進んでいます。

こんな組織におすすめ

MHSの研究プレビューへの参加、あるいは対応準備の着手が現実的に意味を持つのは、次のような組織です。

• プログラマブルな機器を複数台運用しているラボ・製造ライン — 機器間の統合コストが実際に発生している組織ほど効果が見えやすい
• 機器統合に数週間かけている組織 — 短縮効果が最も大きい層。カーネギーメロン大の「8時間」が示す通り
• 夜間・週末の無人稼働で得られる価値が大きい実験・製造 — 最適化ループや長時間モニタリングを回したいケース
• ハードウェアメーカーで、AIエージェント対応が製品差別化になる企業 — 早期にドライバを提供すれば標準側に影響を与えられる
• 安全性評価の共同構築に人員を割ける組織 — プレビューの趣旨に合致する
• 社内にエージェント運用の知見がすでにある組織 — MCPを実運用している組織は移行の理解が早い

今は見送るべき組織

一方、現時点では待ったほうが合理的なケースも明確にあります。

• 旧型・手動操作中心の機器しかない現場 — プログラマブルインターフェースがない機器はそもそも対象外
• すぐに本番導入したい組織 — 仕様が未確定で、変更による手戻りリスクがある
• 専門家の監督体制を用意できない組織 — 物理的な誤動作の切り分けには人間の知見が必須
• 個人開発者・小規模な趣味用途 — 現在の対象は組織単位。オープンソース化を待つほうが現実的
• EU市場向け機器を扱い、認証プロセスが固まっていない企業 — 2027年1月の機械規則適用との関係を整理してからのほうが安全
• 失敗が許されないクリティカルな工程 — 研究プレビュー段階の規格を本番のクリティカルパスに置くべきではない

日本の組織が今できること・できないこと

現時点で日本の読者が取れる現実的なアクションを整理します。

共通して言えるのは、「MHSが来る前提で、機器側の準備を進める」ことには今から意味があるという点です。制御APIの有無、ネットワーク接続性、安全上限を誰がどう定義するかという整理は、MHSが最終的にどの形で公開されても無駄になりません。

よくある質問（FAQ）

Q. MHSはMCPの後継ですか？
いいえ。MHSはMCPを置き換えるものではなく、MCPを3つの制御手段のうち1つとして内包します。MCPは引き続きAIとソフトウェア・データの接続を担い、MHSがその外側に物理デバイス層を追加する構造です。

Q. MHSは無料で使えますか？
現時点でMHS自体の料金体系は公表されていません。規格（specification）でありSaaS製品ではないため、「月額いくら」という概念は今のところ存在しません。ただし実運用では、LLMのAPI／サブスクリプション費用、ドライバ実装の工数、安全検証のコストが別途発生します。これらの具体額もAnthropicは公表していません。

Q. いつオープンソース化されますか？
Anthropicはオープンソース化を明言していますが、時期は未発表です。公式は「オープンソース化の前に、標準についてやるべき作業がまだある」としています。ライセンス種別も未公表です。

Q. Claude以外のモデルでも使えますか？
公式はmodel-agnostic（モデル非依存）と明記しており、他社モデルやオープンソースモデルからの利用も想定されています。担当者は「科学者をベンダーロックインさせたくない」と述べています。ただし、現時点で公開されている実証事例はすべてClaudeによるものです。

Q. 手持ちの顕微鏡や分析装置でも使えますか？
プログラマブルインターフェース（外部から制御できるAPI）を持つ機器であれば対象になり得ます。手動ノブ式や外部制御を受け付けないクローズドな機器は、現時点では対象外です。まずは機器メーカーに制御APIの有無を確認するのが第一歩です。

Q. AIが機器を暴走させる危険はありませんか？
MHSはデバイスレベルで安全上限を強制し、逸脱した指示は機器が動作する前にブロックする設計です。公式はカーネギーメロン大の検証で6件の人為的障害をすべてブロックしたとしています。ただし安全性評価そのものが研究プレビューで構築中の段階であり、専門家の監督を前提とした運用が必要です。

Q. 日本から申し込めますか？
公式に国・地域の制限は明記されていませんが、日本からの申込可否や日本語サポートの有無は未確認です。申込フォームは英語で提供されています。

Q. ROS 2を使っている場合、どう関係しますか？
Anthropicから公式のROS 2対応方針は示されていません。コミュニティでは、MHSをURDF／SDFに近いドライバ記述標準として位置づけ、その上に意図検証層を重ねる案が議論されている段階です。

まとめ — 「MCPの物理版」をどう受け止めるか

MHSは、AIエージェントが顕微鏡やロボットアームを操作するための共通仕様であり、2026年8月27日に限定研究プレビューが始まったばかりの規格です。要点を整理します。

• MCPの置き換えではない。 MCPを通信手段の1つとして内包し、その外側に物理デバイス層と安全上限の強制を追加する
• 効果は数字で示されている。 QuEraの成功率58%→99.3%、カーネギーメロン大の統合8時間など、公式が具体的な実証データを公開している
• 限界も公式が認めている。 プログラマブルIF必須、物理的直観の弱さ、専門家の監督が前提、仕様は未確定
• 参加は選考制で、共同開発へのコミットが実質条件。 単なる先行利用の枠ではない
• 規制の論点がある。 EU機械規則2023/1230の2027年1月適用との関係は、製造業にとって早めに整理すべきテーマ

現時点で最も現実的なアクションは、MHSそのものを追いかけることより、自社機器の制御APIの有無と安全境界の定義を先に整理しておくことです。仕様が確定してオープンソース化されたときに、準備ができている組織とそうでない組織の差は大きく開きます。

規格が動く速度は速いため、オープンソース化・仕様公開・第2フェーズ開始が次の確認ポイントになります。エージェント側の標準動向はMCPとは、運用上のリスク整理はAIエージェントのセキュリティ対策を併せて確認してください。

参考・出典

• Anthropic 公式ニュース「Previewing the Model Hardware Standard」
• Model Hardware Standard 公式サイト
• Fortune / CNBC / SiliconANGLE / The Next Web / IoT Tech News による報道（2026年8月27〜28日）
• Open Robotics Discourse（ROS 2との関係に関するコミュニティ議論）