同じ「100」という電力値でも、二つのサーバーで意味が同じとは限りません。片方は100ワット、もう片方は100ミリワットかもしれません。CPUだけを測った値と、装置全体を測った値かもしれません。数値を並べる前に、何を、どの単位で、どの範囲から測ったかをそろえる必要があります。
2026年8月のOCP APAC Summitで、MicrosoftのSmitha Kashyap C氏らは、異なる機器から集める電力テレメトリーに共通の意味を持たせる案を発表しました。センサーを一種類に統一する話ではありません。機器ごとの値を、あとから比べて使える形へ写すための設計です。[1・2]
名前が似ていても、測っている量を確かめる
電力テレメトリーは、CPU、メモリー、SSD、電源装置などから運用中に得る測定値です。原資料は、メーカーごとに項目名や単位、電力上限の定義が異なるため、機種を増やすたびに集計用の変換が必要になると説明します。[2]
ここでは名称だけをそろえても足りません。電力はある時点や短い区間の消費の速さで、単位はワット(W)。エネルギーは時間を通じて使った量で、単位はジュール(J)です。資料の例にある「cpu_power」と「package_energy」は、名前だけで同じ指標とはみなせません。測定範囲もCPUのコア、パッケージ、サーバー全体で違います。[2]
元データ、意味づけ、使う側の三層
発表は仕組みを三層に分けます。第一層はCPU内部のカウンター、ファームウェアのセンサー、NVMeのログなど、機器が実際に出す値。第二層は、その値に共通の項目名、単位、対象範囲、閾値、版を与える意味づけのスキーマ。第三層は、監視画面、分析、ジョブ配置など、値を使う側です。[2]
たとえば「pkg_energy_j」なら、パッケージのエネルギーをジュールで表す項目だと分かります。資料のSSD例は1秒間の平均電力です。単位と測定対象の範囲をそろえることは比較の土台ですが、実測値を読み比べるなら時刻や平均化期間も要ります。発表の第二層の要素表には、その時間条件を表す独立項目は示されていません。また、異機種の写像表は提案の見本です。対応する各社の元データが同じ範囲を測り、同じセンサーとして実装されていることまで証明するものではありません。[2]
集める経路と、値の意味は別
機器の中からOSが読むインバンドの値もあれば、管理用の経路を通るサイドバンドの値もあります。発表はRedfishやPLDM/MCTPなど既存の管理・伝送の仕組みとの接続を示します。しかし、値を運べることと、その値が同じ測定対象・単位を指すことは別です。どの経路で受け取っても、第二層で意味を確かめる必要があります。[2]
同じ定義で値を集められれば、異機種をまたぐ監視や、電力の余裕を見たジョブ配置を考えやすくなります。資料は仕事ごとの消費エネルギー推定や炭素排出の集計も将来の利用先に挙げています。ただし、共通スキーマの提案だけで、個々の仕事の消費量が正確に測れると実証したわけではありません。計測の時間間隔、共用部の電力、推定方法は別に検証が要ります。[2]
提案の図と、承認された仕様を分ける
スライドは第二層を「OCP Semantic Schema」と呼び、共通のフィールドへ写す考えを示しています。これは今回の発表で示された構想として読むのが正確です。例示された版名や異機種の対応表を、そのままOCPが批准した仕様や全メーカーの実装済み対応表として扱うことはできません。[2]
電力の見える化は、センサーを増やすだけでは進みません。どこから来た値で、何を測り、いつの値なのか。その意味に加えて時刻や平均化期間も確かめられれば、異なるサーバーの値を継続して読み比べやすくなります。
Microsoftの事業や収益の仕組みは、cyclewaveの企業解説にまとめています。
参考資料
2026年9月24日確認。本文は公開スライドの三層案と例示をもとにしています。発表動画の発言・質疑は確認対象に含めていません。
[1]Open Compute Project「2026 OCP APAC Summit」発表一覧。演題、登壇者、資料掲載。
[2]Smitha Kashyap C、Chockalingam A、Prateek Gupta「Standardizing Power Telemetry Semantics for Energy Efficient, Hyperscale Datacenter Operations」公式掲載スライド。全15頁。課題はpp.3–4、三層案と写像例はpp.5–11、想定用途はpp.12–13。

コメントを残す