サーバーの基板を交換するとき、コネクターが合うだけでは十分ではありません。管理用のソフトウェアが、新しい基板の構成や制御方法を知らなければ、状態を読み取ったり、正しい順番で起動したりするための作り込みが残ります。
M-PNP（Modular Plug-and-Play）は、この機種ごとの情報をハードウェア側から渡し、共通のファームウェアで扱える範囲を広げようとする取り組みです。2026年8月のOCP APAC Summitでは、JabilのTodd Rosedahl、HPEのDavid Heinrich、IntelのDirk Blevinsが、自己記述型のJSONファイルと、それを利用する仕様群を説明しました。［1］
簡単にまとめると？
- M-PNPは、サーバーの機種ごとの構成や制御情報をJSONで伝え、共通ファームウェアの再利用を目指します。
- 機器の発見・起動、FPGAの制御、相互運用の条件を、役割の異なる仕様でつなぎます。
- JSONを用意するだけで互換性が完成するわけではなく、筐体全体の動作や適合条件までそろえる必要があります。
- 2026年10月8日に確認した公式一覧は0.5のパッケージを掲載しています。講演で示された後続版の目標時期とは区別します。
機種ごとの知識を、コードの外へ渡す
サーバーをモジュールに分けるDC-MHS（Data Center Modular Hardware System）では、計算を担うHPM（Host Processor Module）と、管理・セキュリティ・制御を担うDC-SCMを組み合わせます。DC-SCM側には、サーバーの状態監視や制御を行うBMC（Baseboard Management Controller）があります。
発表が指摘するのは、ハードウェアの接続条件をそろえても、BMCのファームウェアに機種固有の知識が必要になることです。HPMや筐体の違いをあらかじめコードへ組み込む方式は、資料中で「Plug-and-Code」と呼ばれています。新しい構成を扱うたびに、対応するコードを用意する仕事が生じます。［1］
M-PNPの方向性は、ハードウェアを説明するファイルを用意し、共通のファームウェアに読み込ませることです。JSONは、項目名と値を組み合わせて情報を記述する形式です。ここでは、機器の情報を発見し、構成し、利用するためのデータを渡す役割を持ちます。ハードウェア供給側が共通のひな型や変換ツールを使ってファイルを作る想定です。
ただし、JSONという形式を選べば、すべての動作が自動的に決まるわけではありません。どの項目が必要で、値をどう解釈し、どの制御先へ結び付けるかを共有して初めて、共通のコードが利用できます。形式をそろえることと、意味や動作をそろえることは別の仕事です。
機器を見つける仕様と、制御する仕様
発表では、M-PNPの仕様群を三つの役割で説明しています。
一つ目のFRU Discovery & Bootは、BMCが構成部品を発見し、起動に必要な情報を扱うための仕様です。FRU（Field Replaceable Unit）は現場で交換可能な単位を指します。この仕様は、FRUの識別情報、構成部品を説明するJSONのスキーマ、プラグアンドプレイに必要な起動要件を扱います。スキーマは、ファイルにどんな項目をどの形式で記すかという約束です。［1］
二つ目のHPM FPGAは、BMCがFPGAを扱う際のインターフェースや、内部の機能を表す方法をそろえる仕様です。FPGA（Field-Programmable Gate Array）は、書き込む構成によって論理回路を組み替えられるデバイスです。資料は、機能単位であるIPブロック、レジスターの配置、仮想配線などをJSONで説明する枠組みを挙げています。バスや通信手順に加え、セキュリティ上の考慮や版管理も対象です。
三つ目のInteroperabilityは、何をもって相互運用できるとするかを定義する上位の仕様です。共通の用語や要求、適合の考え方を置き、発見・起動やFPGAなどの設計仕様につなげます。各社の部品が同じファイル形式を出せるだけでなく、組み合わせたときの条件まで一致しているかが論点になります。
三つの仕様は、一方向に積み重なるだけではない
原資料の図は、発見・起動とFPGAの仕様を双方向の矢印でつなぎ、その両方を相互運用仕様へ結んでいます。ここには、ファイルを上から順に読むだけでは説明できない依存関係があります。
図の説明では、FRU Discovery & Boot側が、FPGAの電源状態や、発見・IPブロック設定に使うCSRを参照します。CSR（Control and Status Register）は、制御や状態を読み書きするレジスターです。一方、FPGA側の仕様も、機器の発見手順とJSONの使い方についてFRU Discovery & Bootを参照します。［1］
つまり、「どんな部品が付いているか」を知る仕組みと、「その部品をどう制御するか」という約束を別々に完成させても、接点が食い違えば動作はそろいません。さらに下段の相互運用仕様が、共通の定義や要求を両方へ与えます。図は、部品情報、制御インターフェース、組み合わせの条件を一緒に設計する必要を示しています。
まずは一部をファイル化し、残る機種差を見つける
講演は、従来方式から完全なプラグアンドプレイへ一度に移ると説明していません。中間段階として「Plug & Play Lite」を置き、一部のJSONは事前に組み込むか、実行時に動的に読み込み、ほかの定義はまだコードへ組み込む状態を示しています。最終的な構想では、定義ファイルを実行時に読み込み、基本的な機能を共通のファームウェアで提供する方向です。［1］
残る課題には、プラットフォームや筐体全体を説明するJSON、LEDの動作方針、筐体の熱に関する要求、情報の作成・読込み・保存方法が挙げられています。個々の部品の情報だけでは、サーバー全体の振る舞いを決め切れないためです。
採用を検討するときは、どの情報が共通のファイルに移せて、どこに機種固有の処理が残るかを分けると、評価の対象が見えます。たとえば、部品を発見できること、制御対象の情報を解釈できること、筐体の動作条件に従えることは、それぞれ確かめる必要があります。これは仕様の要点から考えられる確認の順序であり、製品の適合性を判定済みという意味ではありません。
公開されている道具と、まだ目標である段階
具体的な道具として、OCPの公式GitHubではFRU Packaging Toolが公開されています。READMEは、M-PNP.FRU_Discovery_Boot 0.5に従い、EEPROMなどへ書き込むFRUイメージを生成するツールと説明しています。IPMI形式とDMTF形式のFRU情報を組み合わせたイメージを作るもので、サーバー全体のプラグアンドプレイ動作を単独で保証するものではありません。［3］
2026年10月8日に確認したOCP公式の仕様一覧は、M-PnP v0.5 Release Packageを掲載しています。パッケージ内の文書には個別の版があり、FRU Discovery & BootとHPM FPGAは0.5.0 RC2、Interoperability Design Specは0.3.0と案内されています。束の版と、収録文書の版を分けて確認することが大切です。［2］
一方、8月の講演資料は0.7を2026年9月の目標、0.9をGlobal Summit後の目標として示し、さらに1.0へ進む計画を述べています。目標の月を過ぎたことだけでは、公開や完成を確認したことにはなりません。本稿では、今回確認できた公式一覧の掲載内容と、講演中の開発計画を区別しています。［1］
M-PNPが取り組むのは、機種ごとの知識を共通の仕組みに渡すための境界です。JSON、発見手順、FPGAの制御、筐体全体の要求がどこでつながるのかを見ると、「差し替えられるハードウェア」を「管理して動かせるシステム」へ近づけるための作業が見えてきます。
参考資料
2026年10月8日確認。講演資料と公式の公開案内を対象とし、仕様適合試験や実機の相互運用試験は行っていません。
［1］Todd Rosedahl、David Heinrich、Dirk Blevins「MHS Modular Plug-and-Play (M-PNP) Workstream Update and Guidelines for Adoption」、OCP APAC Summit 2026、全17ページ。自己記述と段階は4〜7ページ、仕様群は8〜12ページ、計画・課題・ツールは13〜15ページ。公式発表一覧。
［2］Open Compute Project「DC-MHS Specs and Designs」。M-PnP v0.5 Release Packageと収録文書の版、FRU Packaging Toolの案内。
［3］Open Compute Project「OCP-SVR-MHS-M-PNP_FRUTool」、README。FRUイメージ生成ツールの対象と対応仕様。