Quantum Sea

タグ: OCP

  • Microsoftの液空HRU、冷却液の熱を空気へ渡す装置の流量診断

    Microsoftの液空HRU、冷却液の熱を空気へ渡す装置の流量診断

    液冷の装置を設置しても、冷却液が予定どおり流れなければ、期待した熱を運べません。ポンプの能力だけでなく、ホースの曲がり方、弁の状態、フィルターや気泡までが、実際の流れを変えます。

    2026年8月のOCP APAC SummitでMicrosoftが紹介したのは、液体から空気へ熱を渡すHRU（Heat Reduction Unit）を、大規模に導入・保守するための考え方です。焦点は、運転が始まってから故障を探すだけでなく、初期設定の段階で流れの異常を見つけ、装置自身が状態を知らせる設計にあります。［1・2］

    簡単にまとめると？

    • 液空HRUは、サーバーから冷却液が運んだ熱を空気へ渡す装置です。
    • 流量はポンプと流路の釣り合いで決まり、弁やホースの状態も影響します。
    • 導入時の診断と原因別の通知を重視しますが、資料の改善数値は実測の保証値ではありません。

    冷却液で集めた熱を、空気へ渡す

    資料の液空HRUは、サーバーのコールドプレートから戻った冷却液を、液空熱交換器のコイルへ通します。ファンウォールで空気を流し、液体が運んだ熱をホットアイル側へ渡す構成です。ポンプ、リザーバーや膨張タンク、マニホールド、温度・圧力・流量の計測点も含まれます。［2］

    ここでHRUは、熱を消しているわけではありません。チップから冷却液へ移った熱を、今度は空気へ受け渡しています。したがって、液体側の流れと、空気側の熱の受け入れが、どちらも成立する必要があります。

    流量は、ポンプと流路の両方で決まる

    流れにくさを表すのが、流量に対する圧力損失です。資料では液体系のインピーダンスとして説明されています。マニホールド、弁、ホース、QD、コールドプレート、フィルターなど、流路に入る部品がそれぞれ抵抗を加えます。［2］

    実際の動作点は、ポンプが生み出せる圧力と、流路が必要とする圧力の釣り合いで決まります。同じポンプでも、弁が十分に開いていなかったり、ホースが折れ曲がっていたりすれば、設計時とは違う流量になります。「ポンプが動いている」と「必要な量が流れている」を分けて確かめる理由です。

    そのため発表では、最初の充填時から流れにくさと圧力を確認することを重視しています。初期の組立てや設定の問題を見逃すと、運用後の温度異常や、原因を絞れない警報として現れかねません。［2］

    一つの警報に、違う原因を押し込めない

    たとえば流量が少ないとき、ポンプの異常、弁の閉止、フィルターの詰まり、充填不足や気泡では、調べる場所も対処も違います。すべてが一つの「冷却異常」という警報になれば、正しい部品を選んで交換することも難しくなります。

    Microsoftの資料は、ポンプ保護、流量と流体系、漏れと液位、温度、設定と操作を分けた検知階層を示しています。過熱や過圧、空運転、極端な低流量、フィルター詰まり、リザーバー液位などを、条件に対応したコードで知らせる考え方です。［2］

    何かが悪いと知らせるだけでなく、何を先に確かめればよいかまで絞れることが、保守を支えます。同時に、閾値は機器の世代や構成に合わせて調整する必要があります。

    工場から本稼働まで、確認を段階に分ける

    発表では、故障モード影響解析（FMEA）を、設計側と作業工程側の両方へ適用する方針が示されています。部品が壊れる場面だけでなく、作業で弁を閉じたままにするような誤操作も想定して、検知と自己保護を確かめます。［2］

    資料の導入フローは、工場での状態確認から、現地での流体系の診断、設定値の自動適用、IT機器への給電、最終確認を経て本稼働へ進む構成です。センサー、弁、フィルター、液位、流量を初期段階で調べ、冷却液の状態に合わせて制御を整えます。［2］

    自動化の価値は、単に作業を速くすることだけではありません。同じ確認を毎回行い、手順の抜けを本稼働へ持ち込まないことにもあります。写真を用いた作業手順や、条件ごとの案内は、その確認を現場で再現しやすくする手段です。

    改善率より、改善につながる仕組みを読む

    資料には、導入時間や誤った部品交換、耐久性などの改善を示す数字もあります。ただし、該当ページには、説明のための概数であり、正確な運用データではないと明記されています。この発表から実測の改善率や、導入後の効果を保証することはできません。［2］

    それでも、設計の方向は明確です。流量不足を早く見つけること、原因ごとに知らせること、点検までの間に自己保護できること。液冷を使い続けるためには、熱交換器の性能と同じくらい、導入時に正しく整え、その状態を読み取れる仕組みが重要になります。

    Microsoftの事業をもう少し知る

    Azureを含むクラウド、業務ソフト、Windowsなど、Microsoft全体の事業についてはcyclewaveの企業解説にまとめています。

    Microsoftの企業解説を読む

    参考資料

    2026年9月27日確認。HRUの名称と構成は今回の講演資料に沿っています。

    ［1］Open Compute Project「2026 OCP APAC Summit」発表一覧

    ［2］Microsoft「Liquid-to-Air HRU Cooling at Scale: Serviceability and Fleet-Safe Maintenance Practices」公式掲載スライド。構成と圧力損失はpp.4–5、導入・保守の課題はpp.6–7、FMEAと検知・導入工程はpp.8–10、数値の留意事項はpp.6・11。

  • 直流配電と液冷の安全設計、Googleが示すHBSEと保護手段

    直流配電と液冷の安全設計、Googleが示すHBSEと保護手段

    液冷の話では、まず「どれだけ熱を運べるか」に目が向きます。けれども、高い電力を扱うラックでは、冷却液の通り道と電源の近さも設計の一部です。冷却がよく効く配置でも、漏れや故障、保守の場面まで考えなければ、安全な配置とは言えません。

    2026年のOCP APAC Summitで、Googleの安全設計エンジニアは、この組み合わせをHBSE（Hazard-Based Safety Engineering、ハザードベースの安全設計）から考える発表をしました。新しい製品の安全性を実証した報告ではなく、危険源と保護手段をどう結びつけて評価するかという提案です。［1・2］

    簡単にまとめると？

    • HBSEは、危険なエネルギー源と人へ届く経路を捉え、その間の保護手段を評価する考え方です。
    • 液冷と高電力を組み合わせる際は、漏れが起きた後や保守中にも保護が働くかを確認します。
    • 発表は安全評価の提案であり、特定製品の安全性の実証や、必要な絶縁距離を一律に決めるものではありません。

    危険源から、届く経路まで見る

    HBSEでは、電気や熱、動く部品などのエネルギー源を見つけ、そこから人や可燃物へエネルギーがどう届くかを考えます。そして、その間に置く絶縁、覆い、隔離などの保護手段（safeguard）を確かめます。IEC 62368-1:2023も、情報通信機器などについてエネルギー源を分類し、保護手段を定める製品安全規格です。考え方だけで細かな要求事項の代わりになるわけではありません。［2・3］

    たとえば高電力の直流配電では、電圧の数字だけを見ても、触れ得る場所や故障時の電流、アークが起こる条件までは分かりません。アークフラッシュは電気的な放電が熱や光を一気に放つ現象です。発表資料は、作業者が近づく保守の場面も含めて、電気エネルギーがどこへ届き得るかを評価するよう促しています。［2］

    冷却液が加わると、何を見直すのか

    冷却液は、それ自体を電気の危険源と同一視するものではありません。ただ、液体が漏れれば、絶縁物や通電部との関係が変わります。発表資料は、液体が電気的な異常につながる故障の連鎖を想定し、電源部の近くに置くコールドプレートの配置と絶縁の境界を一緒に考えています。漏れれば必ずアークが起きる、という意味ではありません。［2］

    もう一つは、液が触れる部材との相性です。配管やシールなどの接液材（wetted materials）は、冷却液と組み合わせて評価する必要があります。UL SolutionsのCDU（冷却液分配装置）向け資料も、液体を使う部品や絶縁液の適合性を安全評価の項目に挙げています。冷却性能だけよくても、長く使う間に部材が傷み、漏れを招いては設計が成り立ちません。［2・4］

    電気の側では、空間距離（clearance）と沿面距離（creepage distance）も論点になります。前者は導電部の間などの空気中の距離、後者は絶縁物の表面に沿う距離です。Googleの資料は、冷却液が近くにある電源部で、こうした絶縁の条件と機械的な隔壁を併せて考えるよう示しています。ただし、必要な距離をこの記事から一律に決めることはできません。［2・5］

    故障が一つ起きたあとも、守れるか

    安全設計を日常の正常な状態だけで終わらせないことも、発表の要点です。たとえば、液体の漏れが起きたとき、電気的な異常へ進む経路をどこで遮れるか。さらに保守で覆いを開けるとき、作業者とエネルギー源の間に何が残るか。漏れ、電気、作業の三つを別々に確認するだけでは、このつながりが見えにくくなります。［2・3］

    資料は±400V DCや800V DCを例に挙げていますが、その数字だけで装置全体に適用する規格や試験方法は決まりません。IEC 62368-1は製品安全の規格であり、CDUについても冷媒を含むかなどの構成によって評価する規格が変わるとUL Solutionsは説明しています。ラック全体、冷却装置、保守作業を一つの規格名だけで片づけず、対象を分けて確かめる必要があります。［2・3・4］

    液冷と高電力を両立させる鍵は、冷却液と電気を単に遠ざけることではなく、何が危険源になり、どの経路を通り、どの保護手段で止めるかを設備の境界ごとに描くことです。性能を伸ばす設計と、故障後も守る設計を、最初から同じ図面に載せる。今回の発表は、その順序を思い出させてくれます。

    UL Solutionsの事業を知る

    CDUの安全評価資料を公開しているUL Solutionsは、試験・検査・認証と関連ソフトウェアを提供する企業です。事業の構成や、認証後も続くサービスの仕組みは、cyclewaveでまとめています。

    UL Solutionsの企業解説へ

    Googleを含むAlphabetの事業を知る

    Googleは、検索やYouTube、企業向けクラウドなどを手がけるAlphabet傘下の企業です。cyclewaveでは、広告が生む収益と、クラウドや計算基盤への投資を、会社全体の数字から整理しています。

    Alphabetの企業解説へ

    参考資料

    2026年9月26日確認。本文は公開スライドと規格・認証機関の公開説明に基づきます。発表動画の発言・質疑は確認対象に含めていません。

    ［1］Open Compute Project「2026 OCP APAC Summit」発表一覧。イベントと資料の掲載元。

    ［2］Yulianti (Dessy) Darmanto「Hazard Based Safety Engineering (HBSE) Concept with Coolant and High Power」公式掲載スライド。全12頁。HBSEはpp.3–5、直流と保守はpp.6–7、冷却液と電源の統合はpp.8–9。

    ［3］IEC「IEC 62368-1:2023」公開説明。対象分野、エネルギー源と保護手段の考え方。

    ［4］UL Solutions「Certification of Coolant Distribution Units」。CDUの構成、液体・接液材と適用規格の説明。

    ［5］UL Solutions「How Insulation Is Coordinated: Clearances, Creepages and Distances Through Insulation」。空間距離・沿面距離の用語定義。

  • GoogleのeRoT提案、制御機器の起動を外部の信頼基点で確かめる

    GoogleのeRoT提案、制御機器の起動を外部の信頼基点で確かめる

    データセンターの電源や冷却を制御する機器は、表示が正常でも、起動に使ったファームウェアまで正しいとは限りません。長く使われる設備ほど、機器の設計や更新方法もそろっていないことがあります。では、制御機器が信頼できる状態で起動したかを、どこで確かめればよいのでしょう。

    2026年8月のOCP APAC Summitで、GoogleのMiguel Osorio氏は、電源・冷却・建物制御などのOT（Operational Technology）機器に外付けの信頼の起点を加える設計案を示しました。ポイントは、起動する機器自身に確認を任せきりにせず、別の部品が起動コードを測定し、その結果を運用側でも照合できるようにすることです。［1・2］

    簡単にまとめると？

    • GoogleのeRoT案は、CPUとは別の信頼基点で、CPUを動かす前に最初の起動コードを測定します。
    • 起動状態を遠隔で照合できても、その後の設定変更や動作中の侵害まで安全と証明するものではありません。
    • 更新は未使用の記憶領域へ準備して切り替える提案で、無停止や必ず復旧できることを保証していません。

    CPUが動き出す前に、最初のコードを測る

    講演が提案するのは、CPUとは別に置くeRoT（external Root of Trust）です。Root of Trustは、鍵や測定値をより信頼できる場所に置き、ほかの確認を始めるための基点を指します。スライドの構成例では、eRoTが起動用のA/B二つのEEPROM、切り替え回路、CPUのリセット信号につながります。これはすべてのOT機器が同じ配線になるという意味ではなく、外付け部品を使う一つの設計です。［2］

    この構成では、まずeRoTが使うEEPROMを選び、CPUの最初に書き換え可能なコード（First Mutable Code）を測定します。その値をTPMのPCR（Platform Configuration Register）へ取り込んでから、CPUのリセットを解除します。CPU自身が動いたあとで初めて測る方式と比べ、最初の書き換え可能な段階を測定に含めやすいのが狙いです。スライドはこの順序を示していますが、機器に実装した際の測定範囲は構成ごとに確かめる必要があります。［2］

    ここで二つの働きを分けておくと、話が追いやすくなります。検証起動（verified boot）は、署名や許可された鍵・版を調べ、認められないコードを起動させないための仕組み。測定起動（measured boot）は、起動時に使ったコードの測定値を後から照合できるように残す仕組みです。Googleの資料は、鍵や許容するファームウェア版を記したプラットフォーム・マニフェストと、この二つの働きを組み合わせる案を示しています。［2］

    測定値は、離れた運用側でも照合する

    起動時に値を記録するだけでは、その値が期待どおりか分かりません。講演は、OpenConfigのAttestZを遠隔証明の例に挙げます。機器がTPM内の鍵で署名したquoteとPCRの値を送り、運用側のサービスが証明書と署名を検査し、あらかじめ登録した期待値と比べる流れです。OpenConfigの公開文書はネットワークスイッチの管理を対象にしています。講演が示したOT機器への適用案そのものが、すべての設備で実装済みというわけではありません。［2・3］

    証明できる範囲にも線があります。講演スライドには「ランタイムの完全性」を示唆する記述がありますが、AttestZの公開文書が勧める測定範囲は、最初の命令から静的なルートファイルシステムまでの起動状態で、動作中の変化は対象外です。したがって、起動状態の照合に成功しても、その後の設定変更や実行中の侵害まで安全だと証明されたことにはなりません。［2・3］

    更新は、使っていないEEPROMに先に書く

    起動を測れても、ファームウェアの更新で動いている領域を直接書き換えると、途中で失敗したときに戻しにくくなります。発表資料の更新案では、ホスト側から専用のUSB経路でeRoTへ新しいデータを送り、使用中ではないEEPROMに新しい内容を準備します。暗号学的な検証を経て、次の起動でA/Bの選択を切り替え、起動が成功した後に新しい側を確定する手順です。使用中の領域を保ったまま準備する考え方ですが、更新中も停止が一切ないことや、失敗から必ず復旧できることを保証するものではありません。［2］

    共通の接続口は、提案を使いやすくするために

    eRoTをさまざまな制御機器へ広げるには、チップだけでなく接続の仕方も大切です。スライドは、DC-SCM基板とRoT Add-In Moduleをつなぐ公開済み設計に触れ、複数のRoT実装を受け入れられる接続を目指すと説明しています。機器のたびに基板を設計し直す負担を減らす、という方向です。ただし、この講演は個々のOT機器での互換性試験や運用実績を示したものではありません。［2］

    OpenPRoTのコードは公開されていますが、講演が掲げる参照スタックの提供時期は、2026年第4四半期の初期版と2027年第2四半期の広い利用を目指す予定です。すでに完成した製品や、すべてのOT機器で使える確定仕様として読むのは早いでしょう。実際の導入では、どの起動段階を測り、誰が期待値を管理し、更新失敗時にどこへ戻るかを、対象機器ごとに確認することになります。［2・4］

    今回の提案が見せるのは、「安全なチップを追加する」だけではない設計の順序です。起動前に測る。測った結果を離れた場所で確かめる。更新は別の領域に準備してから切り替える。この三つをつなぐことで、長く使う制御機器の信頼を、運用の中で確かめ続ける道が開けます。

    Googleを含むAlphabetの事業を知る

    Googleは、検索やYouTube、企業向けクラウドなどを手がけるAlphabet傘下の企業です。cyclewaveでは、広告が生む収益と、クラウドや計算基盤への投資を、会社全体の数字から整理しています。

    Alphabetの企業解説へ

    参考資料

    2026年9月26日確認。講演スライド全26ページと公開文書を照合しました。講演動画の音声・質疑は確認対象に含めていません。

    ［1］Open Compute Project「2026 OCP APAC Summit」発表一覧。演題、登壇者、資料掲載。

    ［2］Google「Composable Security Architecture: Raising the Security Bar for Datacenter Operational Technology Appliances」公式掲載スライド。OTの対象はpp.3–6、eRoT・起動測定はpp.11–20、更新はpp.21–23、接続案と予定はpp.24–25。

    ［3］OpenConfig「AttestZ」公開文書。ネットワーク機器のTPM登録・遠隔証明と、静的な起動状態を中心とする測定範囲。

    ［4］CHIPS Alliance OpenPRoT 公開リポジトリ。プロジェクトの公開状況を参照。講演中の将来提供日程とは区別しています。

  • OpenStack・Kubernetes・Cephの役割分担、計算資源・コンテナ・保存先をつなぐ

    OpenStack・Kubernetes・Cephの役割分担、計算資源・コンテナ・保存先をつなぐ

    たとえば、すでにOpenStackでサーバーやストレージを運用しているところへ、AI推論用のコンテナを増やしたいとします。そのとき、基盤を丸ごとKubernetesに置き換える必要はあるのでしょうか。答えを考える鍵は、二つに同じ仕事をさせないことです。

    2026年8月のOCP Korea Tech Dayで、AWS Koreaの講演はOpenStack、Ceph、Kubernetesが共存する三つの接点を示しました。発表の中心は、GPUを載せる計算資源、データを置くストレージ、コンテナの運用をどう組み合わせるか。個々の構成要素は公開されていますが、スライドは三つを組み合わせた特定環境の性能試験ではありません。［1・2］

    簡単にまとめると？

    • OpenStackは計算・通信・保存の資源を用意し、Kubernetesはコンテナの配置や更新を担います。
    • 両方でCephを使っても、同じデータへ自動でアクセスできるわけではありません。
    • EKS Hybrid Nodesは管理プレーンがAWS側にあり、オンプレミスとの安定した接続が必要です。

    OpenStackは資源を用意し、Kubernetesは仕事を配置する

    OpenStackは仮想マシン、ネットワーク、ストレージを払い出す基盤です。必要ならIronicでベアメタルのマシンも扱えます。その上にKubernetesのクラスタを置けば、Kubernetesはコンテナ化したサービスをどのノードで動かし、どう更新するかを管理します。発表は、この上下関係を「OpenStack上のKubernetes」として示しています。［2］

    クラスタを作る接点の一つがCluster API Provider OpenStackです。Cluster APIはKubernetesのクラスタ作成と更新を宣言的に扱う仕組みで、このプロバイダーがOpenStackの資源を使ったクラスタ管理を担います。発表にはMagnumも別の選択肢として並びます。どちらを選ぶかで作成・更新の手順は変わりますが、KubernetesがOpenStackの役割をそのまま引き受けるわけではありません。［2・3］

    保存先はCSI、外への入口は別の接続でつなぐ

    コンテナの中身を作り直しても、学習データや設定を残したい。その保存先をKubernetesから使えるようにするのがCSI（Container Storage Interface）という接続方式です。OpenStackのCinder CSIはブロックストレージを永続ボリュームとして渡し、Manila CSIは共有ファイルシステムを扱います。一方、外部にサービスを公開する負荷分散には、OpenStackのクラウドコントローラーとOctaviaを使う経路があります。保存先と通信の入口は、別々の接続点です。［2・4］

    Cephを保存基盤に選ぶ構成なら、ここにも分かれ道があります。RookはKubernetes上でCephクラスタの配置や運用を助けるオペレーターです。ceph-csiは、CephのRBD（ブロック）やCephFS（共有ファイルシステム）をKubernetesのボリュームとして渡します。CephをOpenStack側でも利用できますが、「両方でCephを使う」だけで同じデータへ自動的にアクセスできるわけではありません。接続先、権限、ネットワーク、データの扱いは構成ごとに決めます。［2・5・6］

    EKS Hybrid Nodesは、管理する場所が異なる

    発表は、既存のオンプレミス資源を使う別の選択肢としてAmazon EKS Hybrid Nodesも挙げています。OpenStack上の仮想マシンやベアメタルをノードに使えますが、Kubernetesの管理プレーンはAWSリージョンにあります。オンプレミスだけで完結するクラスタではなく、AWS側の管理プレーンとノードを結ぶ安定したネットワークが必要です。OpenStack上に自分たちでKubernetesクラスタを管理する構成とは、運用責任と接続の前提が違います。［2・7］

    三つの技術を重ねるとき、まず決めたいのは「何をどこが管理するか」です。サーバーとネットワークを用意する層、コンテナを動かす層、データを残す層。その接点に必要なドライバーと運用主体が見えていれば、既存の基盤を生かしたままAI用の仕事を増やす道筋を描けます。

    AWSを支えるAmazonの事業を知る

    AWSは、Amazon.comの企業向けクラウド事業です。Amazon全体には通販、出店者向けサービス、広告などもあり、それぞれ収益の仕組みが異なります。cyclewaveでは、AWSの位置づけを全社の売上と利益からたどっています。

    Amazon.comの企業解説へ

    参考資料

    2026年9月26日確認。講演スライドと各プロジェクトの公式資料を照合しました。個別構成の性能・費用を測定した記事ではありません。講演動画の質疑は確認対象に含めていません。

    ［1］Open Compute Project「2026 OCP Korea Tech Day」発表一覧。演題、登壇者、資料掲載。

    ［2］AWS Korea「The New Normal of Infrastructure in the AI Era: Accelerating Innovation with Kubernetes」公式掲載スライド。全31頁。基盤の役割はpp.8–11、EKSの配置はp.22。市場予測や導入率、個別企業の節約率は本文に転用していません。

    ［3］Kubernetes Cluster API Provider OpenStack 公式文書。OpenStack上のKubernetesクラスタ作成・管理。

    ［4］Kubernetes Cloud Provider OpenStack。Cinder CSI、Manila CSI、OpenStack Cloud Controller Managerなどの役割。

    ［5］Rook Ceph 公式文書。RookオペレーターによるCephの配置・運用。

    ［6］Ceph「Container Storage Interface」。RBDとCephFSをKubernetesボリュームへ接続するCeph-CSIの役割。

    ［7］AWS「Deploy Amazon EKS clusters across cloud and on-premises environments」。EKS Hybrid Nodesの管理プレーン、ノード配置、接続要件。

  • PhisonのΔPBAエントロピー提案、SSDのデータ配置をアドレスの差から読む

    PhisonのΔPBAエントロピー提案、SSDのデータ配置をアドレスの差から読む

    SSDでは、パソコンやサーバーから見えるデータの並びと、実際に記録された場所の並びは同じとは限りません。書き換えを重ねたあと、その違いを一つの数値で見られるでしょうか。

    2026年のOCP APAC Summitに公式掲載された資料で、Phison Electronics（群聯電子）のAndrew Lin氏は、SSD内部の配置を読む「ΔPBAエントロピー」を提案しました。SSDのデータそのものの乱雑さを測る話ではありません。論理アドレスが隣り合うデータについて、物理的な保存先がどのように変わるかを調べる方法です。［1・2・5］

    簡単にまとめると？

    • PhisonのΔPBAエントロピーは、隣り合う論理アドレスの物理的な保存先の差から、配置の特徴を読む提案です。
    • TRIM後に値が下がる例には数え方の変更が含まれ、物理配置が整理された証拠とは限りません。
    • この値だけでSSDの速度や寿命は判断できず、書き込み増幅率への単純な換算にも使えません。

    隣のデータは、SSDの中でも隣にある？

    ホストが指定するLBA（Logical Block Address、論理ブロックアドレス）は、読み書きする場所を表す番号です。一方、発表資料のPBA（Physical Block Address、物理アドレス）は、SSD内の保存先を表します。両者の対応はFTL（Flash Translation Layer）という変換の仕組みが管理します。データを書き直すと、同じLBAでも別の物理位置を指すことがあります。［2・3］

    Lin氏の指標は、隣り合うLBAの物理アドレスの差をΔPBA＝PBA(i+1)−PBA(i)として記録します。たとえばLBAを順にたどったとき、PBAも毎回1ずつ増えれば、差はすべて「＋1」。保存先の飛び方が不規則になれば、差として現れる値もさまざまになります。［2］

    飛び先の「種類」がどれほど散らばるか

    次に、ΔPBAの各値が何回出たかを数えます。その出現割合にShannonの情報エントロピーを適用したものが、今回のHです。式で書けば H＝−Σp(k)log₂p(k)。Hは、差の種類だけでなく、その出現割合の偏りも表します。一種類だけなら0で、同じ種類数なら均等に現れるときに最も大きくなります。単位は情報量のbitで、熱や消費電力の単位ではありません。［2］

    資料にある小さな例では、五つのLBAの間にある四つの差がすべて「＋1」ならHは0。四つがそれぞれ異なる値ならHは2bitになります。Boltzmannの式は「配置の候補が増えるほど散らばる」という発想の入口ですが、SSDの評価値として実際に計算しているのは、この差分の頻度分布から求める情報量です。［2］

    ここには大切な限界があります。Hは差の大きさをそのまま足す値ではありません。仮に差がいつも「＋100」でも、一種類しか現れなければHは0です。低いHだけで「データが必ず隣接している」とは言えず、高いHだけで読み取りの遅さや製品寿命を決めることもできません。これは発表資料の式から分かる、指標の読み方です。［2］

    TRIMで値が下がるのは、数え方にもよる

    TRIMは、不要になった論理ブロックをSSDに知らせる操作です。NVMeではdeallocate（割り当て解除）として扱われます。通知した瞬間にデータの物理配置がきれいに並び直る、という意味ではありません。［2・3］

    発表資料の例は、TRIMされたLBAをまたぐ二組の差を計算せず、両方を同じ「TRIM」という分類に入れます。先ほどの四組を数える枠はそのままにすると、Hは2bitから1.5bitへ下がります。ここで起きたのは数える対象と分類の変更です。この例だけを、SSDが物理的に整理された証拠として読まないほうが正確です。

    一方、資料の別ページは「隣り合う有効なLBA」を測ると説明しています。TRIMをまたぐ組を飛ばすのか、「TRIM」分類として数えるのか。その方法と分母をそろえなければ、二つのHを比べることはできません。［2］

    書き込みの負担を、この数値だけでは決められない

    SSDは、使わなくなった領域を再利用するためにガベージコレクション（GC）を行います。その過程で、ホストが書いた量よりも多くのデータが記録媒体へ書かれることがあります。WAF（Write Amplification Factor、書き込み増幅率）は、記録媒体への総書き込み量をホストからの書き込み量で割った比です。［3・4］

    Lin氏はHを、先のGC負担を見積もるファームウェア向けの手がかりにしたいと考えています。ただし、資料のシミュレーションでも、SSDの構成や余剰領域を変えるとHがほぼ同じでもWAFは変わります。資料ではGCによる再配置をHに対して中立と扱うモデルも示しますが、実際のPBA対応が変わる装置でどう見えるかは、測定時点や実装をそろえて検証する必要があります。HをWAFの換算表のようには使えません。［2・4］

    ドライブ全体の数値より、乱れが集まる場所を見る

    資料の後半では、ドライブ全体の差分分布から求めたHが小さくても、一部の領域にばらつきが集まる例を示しています。全域の集約値だけでは、GCを先に行いたい場所を見逃すかもしれません。そこで提案されるのが、論理アドレスの範囲を区切って計算する領域別のHです。どの範囲を切り出すか、実際のファームウェアが何を動かしたかも一緒に見ることが大切になります。［2］

    発表は「GetEntropy」という値をコントローラーから取得し、実機トレースで共同検証することも呼びかけています。2026年9月時点で、この発表資料だけからOCPやNVMeが採択した共通の標準指標だとは言えません。もし将来、SSDの状態表示にこうした数値が現れたら、差分の定義、TRIMの数え方、領域の切り方、WAFとの実測関係を一緒に確かめる。その読み方まで含めて、今回の提案は興味深いと思います。［2］

    Phisonの事業を知る

    この発表を行ったPhison Electronics（群聯電子）は、NANDフラッシュを制御するコントローラーを設計し、SSDやモジュールも手がけています。cyclewaveでは、製品構成と在庫、利益と現金の動きから会社全体を見ています。

    Phisonの企業解説へ

    参考資料

    2026年9月26日確認。本文は公開スライドを中心に構成しました。講演動画の発言や質疑は確認していません。資料のシミュレーションは、特定条件での発表者の結果として扱っています。

    ［1］Open Compute Project「2026 OCP APAC Summit」発表一覧。演題、登壇者、資料への導線。

    ［2］Andrew Lin「Applying Thermodynamics to Storage: Defining Entropy Metrics for Next-Gen SSDs」公式掲載スライド。全18頁。指標の定義はpp.3–7、モデルとシミュレーションはpp.9–15、提案はp.16。

    ［3］NVM Express「NVMe Namespaces」。ホストから見えるLBA、deallocateとTRIM、GCの説明。

    ［4］NVM Express「Overcoming the Write Amplification Problem with NVM Express Flexible Data Placement」。WAFの定義と物理配置・GCの関係。

    ［5］群聯電子「公司概況」。Phison Electronicsの正式名称を確認。

  • Microsoftの電力テレメトリー活用、CPU利用率の分布からラックのサーバー搭載数を見積もる

    Microsoftの電力テレメトリー活用、CPU利用率の分布からラックのサーバー搭載数を見積もる

    たとえば、ラックにまだ空きがあるのに、電力の上限が気になってサーバーを追加できない場面を考えてみます。一台ずつの最大消費電力を足せば慎重に見積もれますが、実際には全台が同じ強さで動き続けるとは限りません。反対に、平均値だけで台数を決めると、負荷が重なったときの余裕を見落とします。

    2026年8月のOCP APAC SummitでMicrosoftが示したのは、実際に動くサーバー群の利用率と消費電力の分布から、ラックへの搭載台数を見積もる考え方です。最大性能を測る試験から少し視点を変え、「普段はどんな負荷で動き、ときどきどこまで電力が増えるのか」を計画に持ち込みます。［1・2］

    簡単にまとめると？

    • ラックの台数を見積もるには、CPUの平均利用率だけでなく、負荷の偏りや実運用の電力分布も読みます。
    • 搭載台数の増加例は、負荷の分布と許容する電力超過確率を使った計算で、ラックの供給電力を増やした結果ではありません。
    • 電力予測や負荷の再現は対象フリートでの検証であり、すべてのサーバーに通用する完成済みベンチマークではありません。

    一台分の電力を、どの負荷で決めるか

    講演では、ラックや電力区画に収めるノード数を elevation と呼んでいます。ここでいうノードは、電力を見積もる単位となるサーバーです。台数を少なく抑えすぎれば、同じサーバー数により多くのラックや床面積が必要になります。多く詰め込みすぎれば、電力を抑えるための性能制限が働き、利用者の仮想マシンに影響するおそれがあります。［2］

    その間を探る手がかりが、利用率に対して電力がどう変わるかを表すロードラインです。ただし、試験用の負荷で描いた曲線が、実際のクラウドと同じ形になるとは限りません。資料の比較例では、従来のベンチマークは低い利用率では実フリートより電力が小さく、高い利用率では逆に大きくなっていました。曲線上の一点だけを選ぶと、選んだ負荷によって余裕を大きく見積もったり、小さく見積もったりします。［2］

    CPUの平均利用率が同じでも、中の動きは違う

    フリートとは、運用中のサーバー群のことです。資料にある複数のフリートでは、CPU利用率の分布も、利用率に対する電力の曲線も異なります。立ち上がり途中のフリートと、運用が進んだフリートでは、よく現れる利用率の範囲さえ変わります。CPUだけでなく、メモリーやその他の部品が使う電力も、ノード全体の見積もりに含める必要があります。［2］

    もう一つの違いは、CPU内部の負荷の偏りです。論理プロセッサー（LP）は、この資料ではハードウェアスレッドを指します。たとえば、少数のLPが忙しく残りが休んでいる状態と、全LPがほどほどに動く状態では、平均利用率が同じでも内訳は違います。資料の実測例も、LPごとの利用率が均一ではないことを示しています。平均を一つ読むだけでは、この違いが消えてしまいます。［2］

    平均と偏りを、電力予測の入力にする

    Microsoftは対象の「Fleet A」で、LP全体の平均利用率、利用率の偏りを示すジニ係数、平均動作周波数、周波数のばらつきを示す変動係数の四つを使い、ブレードの電力を予測しました。報告された決定係数R²は約0.97、平均絶対誤差（MAE）は約18Wです。［2］

    R²は、観測された電力のばらつきをモデルがどれだけ説明できたかを見る指標です。MAEは、予測と実測の差の絶対値を平均したもの。したがって、この結果を「すべての予測が18W以内に収まる」「どのサーバーでも97％の精度が出る」と読むことはできません。対象フリートで、平均に加えて負荷の偏りを持ち込む意味があった、と受け止めるのが自然です。

    実際のフリートに近い負荷を、試験でも作る

    モデルで傾向をつかんだら、試験用の負荷も現実に近づけます。発表の最初の試作は、整数演算とメモリー負荷を組み合わせ、LPごとに動く時間と休む時間を変えるものでした。ディスクとネットワークにも軽い負荷を加え、CPUだけを一様に動かす試験から一歩進めています。［2］

    二つ目の試作では、圧縮、暗号処理、キーバリュー処理、グラフ処理、メモリーアクセスを混ぜました。資料の比較図では、三つのフリートに対する電力曲線が初回の試作からさらに近づいています。ただし、二つ目にはその時点でI/O負荷がなく、発表者も完全な一致とはしていません。これは公開クラウドの負荷を再現するための概念実証であり、完成した汎用ベンチマークの紹介ではありません。［2］

    台数の増加例には、電力超過の条件が付く

    搭載台数の図では、Fleet Aの利用率分布とノード間の違いを使い、利用率50％のベンチマーク値を基準にする従来の方法と比べています。たとえばラックの電力枠が20kWの場合、電力が枠を超える確率の目標を1％とした例では、22台から28台へ増える計算です。同じ20kWでも、超過確率の目標を0.01％にすると26台になります。［2］

    ここで変わったのは、ラックが供給できる電力ではなく、負荷の分布と許容する超過確率を踏まえた台数の見積もりです。図は単純化した例で、28台ならどの環境でも安全という設置指針ではありません。また、この確率を、そのまま年間の停止時間やサービスの障害率へ換算することもできません。

    ラックの外側と、これからの負荷も含めて考える

    実際の計画には、曜日や季節、地域、特定顧客の使い方が関わります。ラック単体に余裕があっても、列やデータセンター全体の電力枠が先に制約になることもあります。AI処理が増えれば、これまで観測した分布がそのまま続くとも限りません。資料は、こうした複雑さと、性能制限をどこまで許容できるかを未解決の条件として挙げています。［2］

    発表の呼びかけは、事業者の運用データをそのまま公開せずに、共通の用語、検証手順、匿名化した根拠の示し方をOCPコミュニティで作ろう、というものでした。電力計画を平均一つで済ませず、普段の負荷とまれな大きな負荷を一緒に読む。そのために、テレメトリーと試験をつなごうとする提案です。［2］

    Microsoftの事業をもう少し知る

    今回の発表を行ったMicrosoftは、Azureだけでなく、業務ソフトやWindowsなども展開しています。会社全体の事業と設備投資については、cyclewaveの企業解説にまとめています。

    Microsoftの企業解説を読む

    参考資料

    2026年9月26日確認。公式スライド全24ページと、グラフ・試作条件を照合しました。講演動画の音声・質疑は確認対象に含めていません。

    ［1］Open Compute Project「2026 OCP APAC Summit」発表一覧。演題・登壇者・公式資料への導線。

    ［2］Microsoft「Telemetry-Driven Power Estimation for Rack-Level Provisioning in Public Cloud Data Centers」公式掲載スライド。課題とロードラインはpp.2–6、実フリートはpp.7–11、モデルはpp.12–13、試作はpp.14–19、搭載台数例と条件はpp.20–22。

  • FactryzeのOCRP案、GPUクラスタを計算・通信・熱・ストレージで点検する

    FactryzeのOCRP案、GPUクラスタを計算・通信・熱・ストレージで点検する

    GPUクラスタがベンチマークで速く動いても、長い学習ジョブを安定して走らせられるかは別の問いです。GPUの演算性能が高くても、通信が途切れたり、冷却に余裕がなくなったり、途中の状態を保存するストレージが遅れたりすれば、仕事全体に影響します。速さと、動かし続けられる状態は、分けて確かめたいところです。

    2026年8月のOCP APAC Summitで、Factryzeの創業者Akash Borate氏は、GPUクラスタの健全性（cluster health）を共通の方法で測る案を紹介しました。発表資料は、その構想を「Open Cluster Reliability – OCRP」と呼びます。これは発表者による提案で、OCPが批准した規格や、導入済みの認証制度として紹介されたものではありません。［1・2］

    簡単にまとめると？

    • OCRPはGPUクラスタの継続運用を測る提案で、批准済みの規格や認証制度ではありません。
    • 計算・ネットワーク・熱・ストレージの信号を、原因を絞る手がかりとして見ます。
    • 測定する値だけでなく、試験方法、測るタイミング、結果の残し方までそろえる構想です。

    速さを測ることと、運用を続けられるかは別

    MLPerfなどの性能ベンチマークは、決められた条件で計算をどれだけ速く進められるかを示します。発表者が別の軸として挙げるのは、長い運転の間もクラスタが仕事を続けられる状態か、というreadiness（継続運用に向けた準備状況）です。性能試験を置き換えるのではなく、その結果だけでは見えにくい運用中の変化を補う考え方です。［2］

    GPUやサーバーが出す温度、エラー、通信状態の記録は、すでにさまざまな道具で読めます。ただ、どの信号を、どんな負荷の下で、いつ測れば「健全」と言えるのか。そこが運用者ごとに違うと、別のクラスタの結果をそのまま比べられません。同氏は、測定値だけでなく試験方法と結果の書き方までそろえる必要があると提案します。［2］

    一つの通信エラーから、四つの領域を見る

    資料では、複数GPUの集団通信に使うNCCLでタイムアウトが出る場面を例にします。画面に見えるのは通信のエラーでも、それだけで故障した場所は決まりません。資料の図は、原因を調べる候補を次の四領域に分けています。［2・3］

    • 計算：同じ負荷でのGPU間の活動量のばらつきや、ECC（誤り訂正）で訂正されたメモリーエラーの推移。
    • ネットワーク：通信リンクのビット誤り率（BER）や、リンク断・復帰の回数。
    • 熱：GPUと高帯域メモリー（HBM）の温度、冷却液の供給側と戻り側の温度差。
    • ストレージ：計算の途中状態を保存するチェックポイントの書き込み時間や、I/Oの遅れ。

    これらは故障箇所を自動で特定する答えではなく、どこを調べるかを絞る手がかりです。たとえば温度や通信エラーの変化を見るときも、負荷や装置構成が違えば同じ値を単純には比べられません。［2］

    何を測るかに加え、方法とタイミングをそろえる

    OCRP案は、信号・試験方法・測定の頻度や契機・結果票を一続きで定めようとします。カウンターや温度を読み取る受動的な観測と、基準となる負荷をかける能動的な試験は役割が違います。資料はGPUの状態監視・診断に使うNVIDIA DCGMや、NCCLの集団通信試験などを例に挙げます。ただし、これらは発表資料に挙がる候補であり、共通の試験一式として採用済みではありません。［2・4］

    いつ測るかも大切です。運用中に継続して読む信号、予定を決めて行う能動試験、部品交換やファームウェア更新の後の再確認、運用開始前の受入試験を分ける。資料に載る試験周期は構想を示す例で、すべてのGPUクラスタに適用する推奨周期ではありません。［2］

    結果票は、まだ採点基準が決まった規格ではない

    発表資料の結果票には、対象ノード、測定時刻、試験名、四領域それぞれの状態、全体の判定が並びます。例では計算と熱がBASELINE、ネットワークがWARNING、ストレージがALERTで、全体がAMBERです。ただし、スライド自身が試案の見本（strawman example）と記し、「測定であって認証ではない」と区別しています。この色や語を、確定した合否基準として使うことはできません。［2］

    実際に注意や異常の境界を決めるには、機器、負荷、観測期間をそろえた故障記録が要ります。登壇者も、運用者が匿名化した故障データを持ち寄り、試験や閾値を共同で整えるよう呼びかけています。資料に載る故障率曲線や個別の数値を、別の現場の共通基準へそのまま移す段階ではありません。［2］

    「このクラスタは健全です」という一語より、何を、どんな負荷で、いつ測り、四領域の結果をどう残したか。その条件が見えれば、引き渡し前と運用中の状態も読み比べやすくなります。速さの数字に、続けて使うための測定を重ねる。OCRP案は、その共通の読み方をつくろうとする提案です。

    参考資料

    2026年9月24日確認。本文は公開スライドと公式技術文書をもとにしています。発表動画の発言・質疑は確認対象に含めていません。スライドの故障率・割合・閾値は原データや条件を別途照合できていないため、一般的な統計や推奨値として引用していません。

    ［1］Open Compute Project「2026 OCP APAC Summit」発表一覧。演題、登壇者、資料掲載。

    ［2］Akash Borate「Benchmarking GPU Cluster Health: Towards an Open Standard for AI Infra Readiness」公式掲載スライド。全16頁。評価の軸はpp.3–7、OCRP案はpp.8–12、追加信号表はpp.15–16。

    ［3］NVIDIA「Overview of NCCL」。GPU間の集団通信に使うライブラリの説明。

    ［4］NVIDIA「Data Center GPU Manager Documentation」。GPUの状態監視・診断に使うDCGMの説明。

  • MicrosoftのPCIeカセット案、アクセラレータ交換後もホストを使い続けるための条件

    MicrosoftのPCIeカセット案、アクセラレータ交換後もホストを使い続けるための条件

    GPUを新しい世代に替えるたび、サーバーの筐体や電源、冷却まで設計し直すのでは、更新の負担が大きくなります。そんな負担を減らすには、交換する部分の形だけでなく、どこまでを交換し、どこからを使い続けるかを決めておく必要があります。

    2026年8月のOCP APAC Summitで、Microsoftはアクセラレータを「PCIeカセット」という交換単位にまとめる設計案を示しました。狙いは、GPUなどの種類が変わっても、ホスト側の再設計をできるだけ抑えること。現時点では、発表資料で示された構想です。［1・2］

    簡単にまとめると？

    • MicrosoftのPCIeカセット案は、アクセラレータ側を交換単位にまとめ、ホストの再設計を抑える構想です。
    • 交換性を成立させるには、形状だけでなく電力・冷却・制御・保守の接点をそろえる必要があります。
    • 発表図だけで仕様の批准や他社製品との互換性が確認されたとは言えません。

    カセットとホストの間に、境界を引く

    この案では、アクセラレータごとに変わりやすい形状、固定方法、熱の逃がし方、制御信号をカセット側の設計範囲に置きます。一方のホスト側には、筐体、ホストプロセッサーモジュール（HPM）、管理・制御を担うDC-SCM、電力供給や保守の仕組みを残し、可能な範囲で使い続けます。DC-SCMは、OCPが仕様を定めるサーバーの管理・セキュリティ・制御用モジュールです。［2・3］

    カセットは、単なる「GPUを入れる箱」ではありません。発表資料は、現場交換可能ユニット（Field Replaceable Unit、FRU）として捉え、差し込む経路、重さ、固定具まで検討対象に挙げています。PCIeの接続に加えて、電源コネクターの電流容量、冷却、サイドバンドの制御信号、状態を伝えるテレメトリーも境界をまたぎます。ホットプラグや出力制御を扱うなら、その対応範囲も合わせて決めなければなりません。［2］

    冷却と電力は、境界をまたいで決まる

    液冷なら、カセット内のコールドプレートだけを決めても足りません。接続先のCDU（冷却液分配装置）と合わせて、流量、圧力、冷却液の種類、漏れの検知を考える必要があります。空冷なら、ヒートシンクやファンだけでなく、筐体内で使える風量や音響条件が関わります。電力も同様です。新しいアクセラレータが要求する電流や瞬間的な電力変動を、ホストの配線と電源が受け止められるかを確認します。［2］

    つまり、カセットを交換できる形にしても、ホストの冷却能力や給電の余裕を超えれば、ホスト側の変更は避けられません。資料も、インターフェースの選び方がホストへ複雑さを持ち込み、電力と冷却の境界調整を後回しにすると再利用が難しくなると振り返っています。［2］

    「差し替え可能」を実現するために残る仕事

    資料の次の課題は、カセットの寸法や重量だけではありません。熱・電力の許容範囲、制御インターフェース、侵入検知、ホットプラグ、保守の手順まで含めた共通の接点を、早い段階で定義することです。新しいカセットを差し込むたびに何を再評価するかも、そこで明らかになります。［2］

    発表の図には「OCP Cassette Specificationに準拠」と書かれていますが、末尾はカセットの形状や電力範囲をこれから検討する呼びかけです。この一枚の図だけで、批准済みの仕様や、異なるメーカーの製品をそのまま挿し替えられる互換性があるとは言えません。市場投入までの時間を短くするという狙いも、発表内で削減率が実測されたわけではありません。［2］

    この提案が教えてくれるのは、交換性を部品の形だけで判断しないことです。機械、電力、冷却、制御、保守の接点を一緒に決め、ホストが使い続けられる条件を明確にする。その境界が見えて初めて、新しいアクセラレータを迎える準備ができます。

    Microsoftの事業や収益の仕組みは、cyclewaveの企業解説にまとめています。

    Microsoftの企業解説を読む

    参考資料

    2026年9月26日確認。本文は公開スライドを中心に構成しています。発表動画の発言・質疑は確認対象に含めていません。

    ［1］Open Compute Project「2026 OCP APAC Summit」発表一覧。演題、登壇者、資料と動画の掲載。

    ［2］George Asirvatharaj、Hardik Shah、Niharica Sohal「Modular PCIe Cassette Architecture for Scalable AI Systems」公式掲載スライド。全13頁。課題と構成はpp.5–6、カセットとホストの条件はpp.7–9、残る課題と提案はpp.10–11。

    ［3］Open Compute Project「DC-SCM 2.2 Specification」。DC-SCMとHPMの用語と役割の確認。

  • Everpureが示すメモリーエラー診断、DIMM以外の原因も記録から調べる

    Everpureが示すメモリーエラー診断、DIMM以外の原因も記録から調べる

    サーバーに「メモリーエラー」と表示されると、DIMMを交換したくなります。でも、その表示が教えてくれるのは、まずメモリーを通る処理で異常が見えたということです。原因までDIMMにあると決まったわけではありません。

    2026年8月のOCP APAC Summitで、EverpureのMeeta Saggi氏は、メモリーエラーを装置全体の状態を知る手がかりとして読む方法を示しました。エラーが記録された場所と、壊れた場所を分けて考える。単純ですが、不要な交換を避け、原因に合った対応を選ぶための大切な一歩です。［1・2］

    簡単にまとめると？

    • メモリーエラーは異常を見つけた場所の情報であり、DIMM自体が原因と決まったわけではありません。
    • エラーの件数だけでなく、発生箇所・時刻・繰り返し方を、周辺機器や設定の記録と合わせて調べます。
    • 共通形式で記録と対応案を渡しても、部品交換などを決める前には運用側の検証が必要です。

    エラーを報告した場所と、原因の場所

    DIMMは、サーバーで使うメモリーモジュールです。訂正できたエラーはCE（Correctable Error）、訂正できなかったエラーはUE（Uncorrectable Error）として記録されます。これらは対処の重要な信号ですが、件数だけでDIMMの故障を確定できません。［2］

    信号はCPUのメモリーコントローラー、パッケージ内の接続、基板上の配線やコネクター、DIMMのスロットを通ります。また、PCIe機器で生じたpoison（不正なデータ）がDMA経由でシステムメモリーに伝わり、後から観測される例もあります。見えているエラーを追うには、この経路全体を候補として残す必要があります。もちろん、DIMM自体が故障している場合もあります。［2］

    エラーの回数だけでは、原因を絞れない

    発表資料は、訂正可能エラーが多い場面でも、弱いメモリーセル、信号線の異常、接続部の不安定さなど、異なる原因を考えられると示します。同じ件数でも、起きた場所や時間の並び方が違えば、必要な点検も変わります。資料の故障割合を描いた図は説明用と明記され、実測の発生率ではありません。［2］

    具体例には、DQデータ線の異常、BIOS/RASの設定不備でシステム管理モード（SMM）の処理負荷が増えて遅延が大きくなるケース、PCIe機器から伝わった不正なデータがメモリー上で観測されるケースが挙げられます。これらは「DIMMを替えれば直る」と早合点しないための診断例であり、どの機器でも同じ原因の割合で起きるという統計ではありません。［2］

    記録、分析、対応を別の段階にする

    発表では、OCPのHardware Fault ManagementとRAS APIの枠組みを使い、流れを四つに分けます。まずCPU、メモリー、周辺機器がエラーを報告し、収集側が履歴を残す。分析器は新しい記録だけでなく、同じ報告元の過去の記録も合わせて見て、考えられる故障と対応を提案する。最後に、運用側のポリシーがその提案を受け入れるか決めます。［2・3］

    共通のエラー記録はCPER（Common Platform Error Record）、提案する対応を表す記述子はCPAD（Common Platform Action Descriptor）です。CPADは「自動的にDIMMを交換せよ」という命令ではありません。資料の図でも、分析器の出した提案をポリシー層が検証してから、部品交換、修復、設定変更などの対応につなげます。［2・3］

    共通の記録形式があっても、診断は続く

    OCPが公開したRAS API v0.9は、CPERとCPADを扱うためのインターフェースやデータ構造を示す中間版です。通信に使う下位の仕組みを一つに固定せず、部品ごとの実装や分析方法に余地を残しています。この仕様があることと、すべてのサーバーで高精度な原因推定が実現済みであることは別です。［3］

    メモリーエラーを見たら、まずCE/UEの種類、発生箇所、時刻、繰り返し方を確認し、ほかの機器や設定の記録と合わせて見る。DIMMは重要な候補の一つとして残しながら、交換だけを最初の答えにしない。発表が伝えるのは、メモリーを「犯人」ではなく、原因を探すための信号源として使う考え方です。［2］

    Everpure（旧Pure Storage）の事業や収益の仕組みは、cyclewaveの企業解説にまとめています。

    Everpureの企業解説を読む

    参考資料

    2026年9月24日確認。本文は公開スライドとOCPのRAS API文書を照合しています。発表動画の発言・質疑は確認対象に含めていません。

    ［1］Open Compute Project「2026 OCP APAC Summit」発表一覧。演題、登壇者、資料掲載。

    ［2］Meeta Saggi「Memory Errors as System Signals – Don’t shoot the messenger」公式掲載スライド。全13頁。原因候補と説明用の割合図はpp.4–7、CPER/CPADの流れはpp.8–9。

    ［3］Open Compute Project「RAS API Specification Version 0.9」。2025年12月の中間版。対象範囲はpp.8–10、CPER/CPADの構造はpp.16–23。

  • UL Solutionsの単相浸漬冷却試験、樹脂の変形と冷却液の絶縁性

    UL Solutionsの単相浸漬冷却試験、樹脂の変形と冷却液の絶縁性

    サーバーを液体に浸して冷やすとき、冷却液が触れるのは発熱する部品だけではありません。ケーブルの被覆、樹脂の部品、基板の材料も、同じ液体の中で長く過ごします。よく冷える液体を選んでも、周囲の材料が変形したり、液体の電気的な性質が変わったりすれば、運用は難しくなります。

    2026年8月のOCP APAC Summitで、UL SolutionsのJulie Shih氏は単相浸漬冷却（single-phase immersion cooling）に使う材料と冷却液の適合性を調べた試験を紹介しました。「単相」は、ここでは冷却液を沸騰させて熱を運ぶ方式ではなく、液体のまま使うことを指します。コールドプレートの内部だけに液体を通す直接液冷とも、触れる部材の範囲が違います。［1・2］

    簡単にまとめると？

    • 単相浸漬冷却では、冷却液と樹脂・基板材料を組み合わせた適合性の評価が必要です。
    • 部材の外観や強度に加え、部材を浸した後の冷却液の絶縁性も調べます。
    • 今回の静置浸漬試験だけで、液体が流れる実機の長期寿命や安全性は証明できません。

    液体を一つ選んでも、相性は決まらない

    発表では、ポリカーボネート（PC）、PA66、PBT、EPDMといった樹脂・エラストマー、エポキシとPPOの基板材料を、炭化水素系、合成エステル系、配合油の三種類の冷却液と組み合わせました。80℃と105℃で4、8、12週間、液体を流さない静置浸漬で変化を調べています。これは材料と液体の組み合わせを比べる試験で、すべての樹脂や市販冷却液を順位づけする試験ではありません。［2］

    樹脂やゴムなら外観、寸法、引張強さなど。基板の積層材なら、それに電気的な特性も加えます。液体自体についても、浸す前後で絶縁に関わる性質を確かめます。冷却液だけのカタログ値を読んでも、実際の組み合わせの変化は分からないためです。［2］

    目に見える変化と、強さの変化は同じではない

    試験では、PCは合成エステルでひび割れが、エステル油では変色と端の剥がれが見られました。PA66は色の変化に加えて、高温・長い浸漬で引張強さが落ちました。EPDMは炭化水素系の液体では膨らみ、合成エステルでは縮んで硬くなる傾向を示します。同じ「液体に浸す」でも、材料と液体の組み合わせによって変化の仕方が違います。［2］

    変色は気づきやすい一方、色だけで機能を判定することはできません。寸法が変われば接続部の位置や密着にも影響し得ますし、引張強さの低下は部材の耐久性を考える手がかりになります。ただし、今回の試験片で見られた変化から、すべての完成機器の寿命を計算することはできません。

    冷却液の絶縁性も、部材を浸した後に測る

    基板の積層材では、105℃での試験では、PPO系の絶縁破壊に対する強さが、エポキシ系より大きく低下しました。冷却液側でも、材料を浸した後の絶縁破壊電圧（BDV）を測っています。BDVは、一定の試験条件で液体が電気的に破れるまでの電圧を示す値です。炭化水素系の液体では、比較対象のエステル系より低下が大きい組み合わせが示されました。［2］

    もう一つの誘電正接（Df）は、交流信号に対する損失の目安です。発表では、エポキシやPPOの積層材を浸した後の冷却液のDfが、液種と測定周波数によって異なる変化を示しました。高周波の信号品質を考えるときの注意点ですが、測定は室温で行われています。80℃や105℃の浸漬条件と、電気特性を測った温度を同一視しないことも大切です。［2］

    実機の判断には、液体の流れも含む評価が要る

    この研究は材料の相性を考える入口になりますが、発表者自身が静置浸漬という限界を示しています。実際の装置では液体が流れ、温度も変動し、部品には力がかかります。長期の実機運転や、すべての製品の安全性を、この12週間の試験だけで証明したものではありません。［2］

    発表資料はUL 62368-1に材料適合性に関わる要求がある一方、今回のような適合性を調べる詳細な試験方法をそこだけで指定しているわけではない、と説明します。材料、冷却液、温度、期間、流れをどうそろえて評価するか。発表者は評価基準のさらなる整備を課題に挙げています。OCPは2026年6月に部品と冷却液の適合性を調べるガイダンスを公開していますが、それ自体が合否の閾値や認証を定める文書ではありません。［2・3］

    単相浸漬冷却を選ぶ際に見たいのは、液体単体の性能だけではありません。どの部材を、どの液体に、どの条件で浸すかを組み合わせて確かめる。冷却の設計と材料の試験を、一つの表に並べて考える必要があります。

    UL Solutionsの事業を知る

    今回登壇したUL Solutionsは、試験・検査・認証と関連ソフトウェアを提供する企業です。事業の構成や、認証後も続くサービスの仕組みは、cyclewaveでまとめています。

    UL Solutionsの企業解説へ

    参考資料

    2026年9月24日確認。本文は公開スライドの試験条件と発表者が示した限界に沿ってまとめています。発表動画の発言・質疑は確認対象に含めていません。

    ［1］Open Compute Project「2026 OCP APAC Summit」発表一覧。演題、登壇者、資料掲載。

    ［2］Julie Shih「Material Compatibility, Reliability, and Safety Risks in Single-Phase Immersion Cooling」公式掲載スライド。全13頁。試験条件はpp.3–4、材料・冷却液の結果はpp.5–9、限界はpp.10–11。

    ［3］Open Compute Project「Server Component Immersion Material Compatibility Testing, v1.5」。2026年6月公開。評価ガイダンスの対象と、合否・認証を定めない範囲はpp.6–8。