Quantum Sea

投稿者: SB

  • OCP APAC 2026 | Googleの大容量HDD検証、HSMR・HAMR・ヘッド無効化

    OCP APAC 2026 | Googleの大容量HDD検証、HSMR・HAMR・ヘッド無効化

    HDDの容量が増えると、同じ設置スペースに多くのデータを置けます。その一方で、全領域に書き込み、読み出して確かめる時間も長くなります。新しい記録方式を使いこなすには、容量だけでなく、導入前の検証にも目を向ける必要があります。

    GoogleのJim Hsu氏とJerome Tzeng氏の資料は、HSMR、HAMR、Head Depopulationという三つの技術を取り上げ、検証項目と時間のかかる工程を整理しています。容量を増やす方法と、故障した一部を切り離して使い続ける方法。それぞれに、確かめるべきことが違います。［1］

    簡単にまとめると？

    • HSMRは一台のHDD内で記録方式の異なる領域を組み合わせ、容量と性能を調整します。
    • HAMRは記録部分を一時的に加熱して書き込む技術で、HSMRとは別の軸です。
    • ヘッド無効化は容量を減らして使い続ける方法で、残った部分の安定性も検証します。
    • 検証時間の短縮案は示されていますが、一定の短縮率が実証されたわけではありません。

    三つの技術は、HDDのどこを変えるのか

    HSMR（Hybrid Shingled Magnetic Recording）は、従来型磁気記録のCMR領域と、トラックの一部を重ねて記録するSMR領域を、一台のドライブ内で組み合わせる方式です。資料では、領域の割り当てを変え、性能と容量のバランスを取る技術として説明されています。［1］

    HAMR（熱アシスト磁気記録）は、レーザーと近接場光トランスデューサーを使い、記録媒体のごく小さな部分を一時的に加熱して書き込む技術です。記録密度を高めるための方式であり、CMRとSMRの使い分けとは別の軸です。今回の資料でも、HAMRの検証をCMRモードとSMRモードに分けています。［1］

    Head Depopulationは、不具合のあるヘッドを使用対象から外し、残ったヘッドと容量でドライブを使い続けるための仕組みです。容量をそのまま保つ修理ではなく、使える容量が減る代わりに、ドライブ全体を早期に退役させずに済む可能性があります。残った部分が仕事を続けられるかを、別途確かめる必要があります。［1］

    HSMRは、領域の切り替えと同時動作を確かめる

    HSMRの試験では、コマンドの適合性、CMRからSMRへの変換時のデータ整合性、データ転送を伴わないコマンドの応答時間を確認します。正しい命令に応じるだけでなく、不正な命令を適切に中止できるかも評価対象です。［1］

    さらに、CMR領域で通常の処理に相当する負荷を動かしながら、SMR領域では読み書きを継続する構成を示しています。一方の領域だけを測って良好でも、同時に使うと待ち時間が変わるかもしれません。一台の中で二つの領域が共存するときの性能まで見ることが、この検証の要点です。［1］

    HAMRは全面の読み書き、ヘッド無効化は前後の比較へ

    HAMRのCMRモードでは、初期の状態と性能を記録したうえで、全領域の連続書き込み・読み出し、ランダムアクセス、再度の全面確認へ進みます。データパターンの照合や状態ログの監視を行い、負荷をかけた後の性能と初期値を比較します。SMRモードには、ゾーンの状態を変えて繰り返し確認する工程も含まれます。［1］

    Head Depopulationでは、対応コマンドやヘッドなどの状態情報をドライブ単位で調べます。ラック規模の試験では、まず性能の基準値を取り、数十日間の負荷試験を実施。その後にヘッドを無効化し、再び入出力性能と状態ログを確認します。「無効化の命令が成功した」ことと、「残る容量で安定して使える」ことを分けて評価する流れです。［1］

    28TBの全面検証に約3日。その時間をどう扱うか

    資料は、28TB HDDで全LBAの読み書きに約3日かかる例を挙げています。LBAは論理ブロックアドレスのこと。ホストから見える記憶領域を端から端まで確かめる試験です。HSMRのSMR領域を埋める処理には約2日、ヘッド無効化後の再フォーマットにも時間がかかるとしています。いずれも発表資料の例で、どのHDDでも同じ日数になるわけではありません。［1］

    短縮案には、盤面の外周・中間・内周など対象を絞って読む方法、CMR部分を先に評価する順序への変更、台数を増やした並列試験、ファームウェアの最適化があります。ここは改善のアイデアとして示された部分で、一定の短縮率が実証された結果ではありません。［1］

    試験の対象を絞れば、全領域を読む場合とは確認できる範囲が変わります。並列化には追加の機器が必要です。容量が増えるほど、何日で終わるかだけでなく、何を確かめた結果として導入するのかが大切になります。三つの技術を同じ容量競争としてまとめず、変わる仕組みに合わせて検証を組み立てる。その視点が、次世代HDDを運用へつなぐ手がかりになります。

    Googleの事業と親会社Alphabetの収益構造は、cyclewaveでまとめています。

    Alphabetの企業解説へ

    参考資料

    2026年9月27日確認。

    1. Google「The Future of Next-Gen HDD Qualification: HSMR, HAMR, and Head Depopulation」 — 2026 OCP APAC Summit公開スライド。技術の区別p.3–4、HSMR p.5、HAMR p.6–7、ヘッド無効化p.8、性能評価p.9、試験時間と改善案p.10。
    2. Open Compute Project「2026 OCP APAC Summit」 — 発表者・演題・配布資料の掲載元。
  • OCP APAC 2026 | Microsoftの液冷バスバー案、流量配分と漏れ対策の設計

    OCP APAC 2026 | Microsoftの液冷バスバー案、流量配分と漏れ対策の設計

    AIサーバーへ大きな電力を届けるとき、熱くなるのはチップだけではありません。電流を運ぶ経路にも抵抗があり、そこで生じた熱を逃がす必要があります。給電する量が増えるほど、その経路の大きさや重さも、ラック設計の課題になってきます。

    MicrosoftがOCP APAC Summitで取り上げたのは、バスバーを液体で冷やす設計です。バスバーは、大きな電流をまとめて運ぶ棒状・板状の導体。空気で冷やすだけでは寸法や気流の制約が厳しくなるため、冷却液を使って電力経路そのものを小さくする考え方です。［1・2］

    簡単にまとめると？

    • 液冷バスバーは、大電流を運ぶ導体を液体で冷やし、給電経路の小型化を目指す設計です。
    • 重量や占有面積の比較は特定条件のシミュレーションで、量産運用の実績や全ラック共通の効果ではありません。
    • 小型化と引き換えに、回路全体の流量配分や充填、清浄度、漏れへの対応が必要になります。

    電源ラックからITラックまで、冷やす場所を分けて考える

    資料の構成例では、電源ラックから±400V DC／800V DCの高電圧直流で電力を送り、ITラック側で低電圧直流へ変換します。高電圧側と低電圧側の両方にバスバーがあり、それぞれの場所で冷却方法を選びます。［2］

    選択肢は、空冷バスバー（ACBB）と液冷バスバー（LCBB）です。電源ラックとITラックがどちらも空冷なら両側で空冷を使う構成が考えられます。一方だけが液冷なら、その側のバスバーを液冷にする組み合わせも示されています。［2］

    つまり、ラックのどこかに液冷を入れたら、給電経路も一律に液冷へ変わるわけではありません。そこで利用できる気流と液冷回路を見ながら、区間ごとに決める設計です。

    5,000Aの比較では、重さと占有面積に差が出る

    空冷バスバーは、冷却液の配管を持たない単純さが強みです。ただ、大電流に対応するためにヒートシンクや気流を整える板を加えると、重さや占有面積が増え、電源ユニットの保守もしにくくなります。液冷は、こうした空気側の制約を減らす方向に働きます。［2］

    資料には、目標電流を両方式とも5,000Aにそろえたシミュレーション比較があります。空冷を1としたとき、液冷は重量が0.68、占有面積が0.67。電流密度は空冷の2倍超とされ、コネクター周囲の温度余裕も、5℃未満から約10℃へ広がる例が示されています。［2］

    この数字は、資料中の設計条件を比較したものです。すべてのラックで同じ比率まで小型化できるという意味ではなく、実機の量産運用で得た結果でもありません。それでも、冷却方法を変えることで、導体を太くする以外の設計余地が生まれることは読み取れます。

    流れやすくするだけでは、必要な場所へ届かない

    液冷バスバーは、ラック内の既存の液冷回路へ組み込む案です。ここで重要になるのが流量配分です。バスバー側の流路抵抗が低すぎると、冷却液がそちらへ多く流れ、同じ回路につながるほかの部品とのバランスが変わります。［2］

    流路抵抗は、ある流量を通すためにどれだけの圧力差が必要か、という関係で捉えられます。冷却したい部品ごとに必要な流量が違うため、バスバー単体の流れやすさだけでなく、回路全体の圧力損失と合わせて設計する必要があります。

    長い配管には、導入や保守の難しさもあります。資料では、マニホールドからの充填が難しく、専用の治具が必要になる可能性や、途中で分割しにくい配管の洗浄が課題に挙がっています。［2］

    冷却の故障を、給電の故障へ広げない

    バスバーは、止まればその先へ電力を届けられなくなる部分です。発表では、漏れがラック運転へ直接影響すること、冗長性を持たない構成では単一障害点（SPOF）になり得ることを、主要なリスクとして挙げています。［2］

    そのため、冷却性能と並んで、漏れをどこで検知し、検知後に何を保護するかを決めておく必要があります。資料は、接合部を減らすこと、漏れ検知線の配置、既存ラックの漏れ対応への統合や、ファームウェア側の変更も検討項目にしています。［2］

    確認する側にも設備が要ります。大電流を流して冷却能力を確かめるには、十分な電源と電子負荷が必要です。形が収まること、計算上は冷えること、実際の負荷で安全に使えることは、別々に確かめなければなりません。［2］

    液冷は、チップの外側へ広がっていく

    液冷バスバーの狙いは、電流を運ぶ経路を小さくし、ラック内の空間と温度の余裕を取り戻すことです。その代わり、流量配分、充填、清浄度、漏れへの対応までが、配電の設計に加わります。

    AIサーバーの高密度化を支えるのは、冷却能力だけではありません。電力を届ける部分と、そこで生まれた熱を運び出す部分を、一緒に成立させること。液冷バスバーは、そのつながりがよく見える設計例です。

    Microsoftの事業をもう少し知る

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

    Microsoftの企業解説を読む

    参考資料

    2026年9月27日確認。講演の公開スライドをもとに構成しています。

    ［1］Open Compute Project：2026 OCP APAC Summit 公式セッション一覧

    ［2］Microsoft：Busbar Cooling Challenges and Emerging Opportunities for Next-Generation AI Platforms（講演スライド）

  • OCP APAC 2026 | SPEC CPU 2026、52のベンチマークで「速さ」と「処理量」を分ける

    OCP APAC 2026 | SPEC CPU 2026、52のベンチマークで「速さ」と「処理量」を分ける

    サーバーの性能表で、CPUの横に大きなスコアが並んでいます。その数字が高いほど、一つの仕事が早く終わるのでしょうか。それとも、たくさんの仕事を同時に処理できるのでしょうか。

    SPEC CPU 2026は、その二つを分けて比較するベンチマークです。計算性能を測る試験プログラムを52本収録し、速さを見るSPECspeedと、単位時間あたりの処理量を見るSPECrateを用意しています。整数と浮動小数点の分類を組み合わせ、四つの測定系に分かれます。［3］

    2026年のOCP APAC Summitでは、非営利の性能評価団体SPEC（Standard Performance Evaluation Corporation）のDavid Reiner氏が、新版の変更点を紹介しました。2026年5月に公開されたこの新版から、CPUの数字を読むときに押さえたい点を見ていきます。［1・2・6］

    簡単にまとめると？

    • SPEC CPU 2026は、一つの仕事を終える速さと、複数の仕事を同時に処理する量を分けて測ります。
    • スコアはメモリーやコンパイラーにも左右され、同じ版・測定系と構成条件を確かめて比較します。
    • 任意のエネルギー測定はシステム全体が仕事に使ったエネルギーを見るもので、CPU単体のTDPではありません。

    CPUだけでなく、メモリーとコンパイラーも測る

    SPEC CPUという名前ですが、結果はCPUチップだけでは決まりません。キャッシュや主記憶の構成、プログラムを実行できる形に変換するコンパイラーと、その最適化も測定対象に含まれます。実際のアプリケーションに由来する計算を、こうした組み合わせで動かした結果です。［2・3］

    たとえば同じCPUを積んだサーバーでも、メモリーの構成やコンパイラーの設定が違えば、結果をそのまま「CPUの差」とは読めません。性能表の構成欄まで見ることで、どのような条件で出た値なのかが分かります。

    SPECspeedは一つの仕事、SPECrateは同時に進める仕事

    SPECspeedでは、各ベンチマークを一つずつ実行し、仕事を終えるまでの時間を測ります。SPECrateでは、同じベンチマークの複数のコピーを同時に動かし、単位時間あたりにどれほど仕事を進められるかを見ます。［3・4］

    測定系ベンチマーク数スコアが高いときの意味
    SPECspeed 2026 Integer13整数系の仕事を、より短い時間で終える
    SPECspeed 2026 Floating Point13浮動小数点系の仕事を、より短い時間で終える
    SPECrate 2026 Integer14整数系の仕事を、単位時間あたりにより多く処理する
    SPECrate 2026 Floating Point12浮動小数点系の仕事を、単位時間あたりにより多く処理する

    整数系にはコンパイラーやデータ圧縮、浮動小数点系には流体や大気のシミュレーションなどが入っています。表の本数は、四つのスイート（試験プログラムの組）を合計して52本です。［4］

    ここで気をつけたいのが、SPECspeedの「一つ」は、1コアや1スレッドという意味ではないことです。一つの仕事を複数のスレッドに分けて進められるベンチマークもあります。Reiner氏の資料では、整数系SPECspeedで並列処理を使えるものが、前版の10本中1本から、新版では13本中9本へ増えたと説明しています。［2］

    SPECrateは各コピーを1スレッドで動かします。見るときは「何コピーを同時に実行したか」、SPECspeedなら「何スレッドを使ったか」も一緒に確かめると、サーバーの使い方を想像しやすくなります。［4・5］

    52本に増え、暗号化検索やグラフ探索も加わった

    前版のSPEC CPU 2017は43本、新版は52本です。ただ増やしただけでなく、扱うアプリケーションの分野も広がりました。LLVMコンパイラーやPythonインタープリター、機械翻訳など、いまのソフトウェアを支える処理が加わっています。［2・6］

    新しいセキュリティ分野の例が750.sealcrypto_rです。これは、データを復号せずに計算できる「準同型暗号」を使う検索です。データベースと検索条件を暗号化したまま照合する処理が含まれています。［2・7］

    854.graph500_sでは、点と線でつながりを表すグラフをたどります。ある点から近い順に探す幅優先探索や、点どうしの最短経路を求める処理を使います。また、772.marian_rには英語をドイツ語へ訳すニューラル機械翻訳が含まれます。「CPUが速い」の中に、異なる種類の仕事があることが見えてきます。［8・9］

    52という数は、入力条件の数ではありません。各ベンチマークには、入力データや処理内容を定めたワークロードがあります。発表では、このワークロードの種類も増やしたと説明しています。同じプログラムを違う入力で動かすことで、特定の処理だけに偏らず、CPU内部のさまざまな動きを調べる狙いです。［2］

    baseとpeakでは、最適化の条件が違う

    結果の名前の末尾には、baseやpeakが付きます。baseは、同じスイートの同じ言語に共通するコンパイラー設定を使うなど、最適化の条件をそろえた測定です。peakは、ベンチマークごとに設定を選ぶ余地が広くなります。baseも最適化を行うため、「何も調整していない状態」という意味ではありません。［5］

    比較するときは、まずSPECspeedかSPECrateか、IntegerかFloating Pointか、baseかpeakかを合わせます。そのうえで、CPUの個数と有効なコア数、メモリー構成、OS、コンパイラー、コピー数やスレッド数を読みます。条件が異なる構成を比べる場合は、何が違うのかも含めて判断することになります。［5］

    たとえばサーバー全体の処理能力を知りたいなら、コア数の異なる機種どうしを比べる意味があります。一方で、その差を「1コアあたりの速さ」と呼ぶには、別の切り分けが必要です。何を選ぶための比較なのかを先に決めると、スコアの使い道がはっきりします。

    CPU 2017の点数から、CPU 2026へは換算できない

    旧版と新版のスコアを並べて、その増減を性能向上率として読むことはできません。SPECは、CPU 2017とCPU 2026の結果を相互に換算する式はないと説明しています。プログラム、入力データ、実行規則に加え、スコアの基準となる参照機も変わっているためです。［4］

    同じサーバーで新版の点数が小さくなっていても、それだけで性能が落ちたとは言えません。世代の異なるCPUを比較したいときも、両方を同じ版・同じ測定系で測った結果から出発するのが基本です。

    電力を測るなら、仕事を終えるまでのエネルギーも見る

    SPEC CPU 2026には、電力を測定してエネルギー指標を出すオプションがあります。これは全ての結果に自動で付くものではありません。規則に対応した電力計と温度センサーを使い、対象システムとは別の制御用システムで測定データを集めます。［3・5］

    電力計を置くのは、AC電源と測定対象システムの間です。CPU単体の消費電力や、仕様表のTDPを示す数値ではありません。エネルギー指標は、実行時間の代わりに仕事に要したエネルギーを使い、参照機との比から計算します。［4・5］

    電力とエネルギーは、見ているものも異なります。たとえば、ある処理中の平均電力が小さくても、終了までに長い時間がかかれば、その仕事で使うエネルギーは増える場合があります。性能とエネルギーの結果を並べることで、処理量を増やしたいのか、仕事あたりのエネルギーを抑えたいのか、目的に沿って考えやすくなります。

    自分の仕事に近い測定から読む

    SPEC CPU 2026は、計算を中心とする仕事を比べるための共通の基準です。ネットワークやストレージの性能を主に測るものではなく、機械翻訳が含まれるからといって、AIサービス全体の応答時間を表すわけでもありません。自分が使うアプリケーションの性能を、そのまま代わりに測れるものではないとSPECも説明しています。［4］

    性能表に出会ったら、最初に点数の大きさを見る前に、名前を最後まで読んでみる。版、speedかrateか、整数か浮動小数点か、baseかpeakか。そして構成と実行条件へ進む。その順番で読むと、一つの数字が、自分の仕事に合うサーバーを考えるための手がかりになります。

    参考資料

    2026年9月26日確認。OCP公式掲載スライドとSPECの公開文書をもとに構成しました。講演動画の発言や質疑は未確認です。

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

    ［2］David Reiner「SPEC CPU 2026 — What’s New, What’s Improved and Why it Matters」公式掲載スライド。全17頁。測定対象はp.8、世代差とワークロードはpp.10–12、分野別の例はpp.13–14。

    ［3］SPEC「SPEC CPU 2026」。四つの測定系、52ベンチマークと任意のエネルギー測定。

    ［4］SPEC「CPU 2026 Overview / What’s New?」。測定範囲、各スイートの本数、コピー・スレッド、指標の計算と旧版からの移行。

    ［5］SPEC「CPU 2026 Run and Reporting Rules」。base・peak、実行条件、測定機器、構成情報の開示。

    ［6］SPEC「SPEC Releases the SPEC CPU 2026 Benchmark Suites」。2026年5月5日の公開発表と変更点。

    ［7］SPEC「750.sealcrypto_r」。暗号化したデータベースと検索条件を使う準同型暗号のベンチマーク。

    ［8］SPEC「854.graph500_s」。幅優先探索と全点対最短経路を使うベンチマーク。

    ［9］SPEC「772.marian_r」。英語からドイツ語へのニューラル機械翻訳。

  • OCP APAC 2026 | Caliptraの製造時プロビジョニング、UDSと証明書の役割

    OCP APAC 2026 | Caliptraの製造時プロビジョニング、UDSと証明書の役割

    サーバーの起動時にファームウェアの署名を確かめるには、最初に信頼する情報が必要です。その鍵は誰が設定したのか。このチップは、製造時に登録された個体と同じなのか。確認をさかのぼると、データセンターへ届く前の工程に行き着きます。

    2026年8月のOCP APAC Summitで、GoogleのZachary Halvorsen氏とTimothy Trippel氏は、Caliptra Subsystemのプロビジョニングを説明しました。プロビジョニングはここでは、チップ固有の情報や起動時の検証に使う情報を設定し、試験・製造の状態から運用できる状態へ進める作業を指します。［1・2］

    簡単にまとめると？

    • Caliptraの製造時設定は、チップ固有の情報と検証の仕組みを整え、本番へ引き渡す工程です。
    • 個体識別の秘密をチップ内に保ち、証明書を求める情報を外へ出す役割を分けます。
    • 参照コードの公開と、各製品の製造工程が完成・検証済みであることは別です。

    信頼の起点にも、最初の設定がある

    Caliptraは、SoCに組み込むオープンソースのRoot of Trust（信頼の基点）です。機器の識別、起動するファームウェアの測定、その状態を暗号学的に示す証明などを支えます。今回の発表は、Caliptraのコアに制御用のMCUなどを組み合わせたSubsystemを、製造工程でどう準備するかが主題です。［2・4］

    設定する情報には、役割の違うものが含まれます。チップ固有の秘密、ファームウェアの検証に使う公開鍵に対応したハッシュ値、工程を進めるためのトークン、証明書を作るための属性などです。これらは、OTP（One-Time Programmable）と呼ばれる一度の書き込みを前提にしたヒューズ領域などへ、定められた状態で設定します。秘密鍵をすべて外から書き込む、という仕組みではありません。［2・3］

    UDSは、外へ渡す証明書とは役割が違う

    UDS（Unique Device Secret）は、その個体を暗号学的に識別するための秘密の起点です。Caliptraでは、ヒューズに保持するUDSのシードをもとに、デバイスの識別鍵を導出します。起動時の測定と識別情報を結びつけるDICE（Device Identifier Composition Engine）の仕組みも、この起点につながります。［2・4］

    一方、IDevID（Initial Device Identifier）は、製造時に確立するデバイス識別情報です。CaliptraのROMが識別鍵を導出し、その公開側の情報を含むCSR（Certificate Signing Request、証明書署名要求）を作ります。外へ取り出すのはこの要求であり、IDevIDの秘密鍵そのものではありません。公式仕様では、その秘密鍵を外部へ公開しない設計が求められています。［4］

    この区別は製造工程を読むうえで大切です。チップの中に保つ秘密と、相手へ示せる証明書は、同じ「識別に使う情報」でも扱いが違います。

    試験、製造、本番へ、状態を進める

    発表は製造の流れを、大きくRaw、Test、Manufacturing、Productionの四段階で説明しています。Rawはまだ設定されていない状態。Testではチップの試験と工程用トークンの設定を行い、ManufacturingでUDSや証明書に関わる準備を進めます。Productionは本番運用へ引き渡す段階です。［2］

    単に作業者が工程名を書き換えるわけではありません。ライフサイクル状態によって、デバッグで触れる範囲や、書き込めるヒューズが変わります。資料は、いくつかの状態遷移でパスワードに似たトークンを要求する流れを示しています。公式ガイドによれば、状態はヒューズに記録され、チップをリセットしても前の状態には戻りません。四段階の説明の内側には複数の試験状態があり、返却解析などの別経路も用意されています。［2・3］

    つまり、製造時には試験に必要なアクセスを確保し、そのまま本番へ持ち越さないようにする設計です。「本番状態になったから、あらゆる検査用の経路が永久になくなる」とも言い切れず、許可されたデバッグや返却時の扱いは、状態と権限を分けて読む必要があります。

    証明書の発行は、チップの外にもつながる

    製造工程の図では、チップがIDevIDのCSRと、その真正性を確かめるためのHMAC（鍵付きのメッセージ認証コード）を出力します。製造側のHSM（Hardware Security Module）がHMACを検証し、証明書の発行を支えます。HSMは、こうした処理で使う鍵を保護する専用の装置です。発行した証明書は、個体情報のデータベースへ登録する流れになっています。［2・3］

    ここで目指しているのは、受け取った要求に無条件で署名することではありません。正しい製造経路から来た要求かを確かめ、どの個体の証明書なのかを記録し、その後の運用へ渡せるようにすることです。チップの内部の保護に加え、証明書を発行する側の鍵と記録も、信頼をつなぐ役割を持ちます。

    工場で決める情報と、運用者が加える情報

    発表資料は、設定を製造時と運用段階に分けています。製造時にはUDS、ベンダーのファームウェア検証に関わる情報、工程やデバッグのトークン、IDevID証明書の属性などを準備します。運用側には、追加の乱数材料であるField Entropy、古い版への巻き戻しを防ぐための情報、鍵の管理、所有権移転などに関わる設定があります。［2］

    Productionへ進んだ後も、所有者が認可されたコマンドで必要な設定を行う、というのが発表の流れです。ただし、ヒューズを通常の設定ファイルのように何度でも書き直せるわけではありません。公式ガイドは、運用中に変更できる領域とロック条件を区別しています。どの情報を工場で確定し、どれを所有者に残すかは、製造と運用をつなぐ設計事項です。［2・3］

    参照コードの公開と、製品への組み込みは分けて見る

    講演が提供予定として挙げたのは、状態遷移を行うJTAGスクリプト、UDS設定やCSR取得を担う製造用ファームウェア、運用中の設定変更を認可するMCUファームウェアです。スライドの最終説明では、これらの成果物は開発中と明記されています。［2］

    その後、公式リポジトリでは2026年8月24日にMCU Runtime SDKの2.0と2.1向け初回リリースが公開され、2.1の説明には製造用のヒューズ設定ファームウェアも含まれています。一方、9月26日に確認したプロビジョニングガイドには、共通の参照フローや支援ツールを開発中とする記述が残っています。公開されたコードがあることと、各製品の製造工程が完成・検証済みであることは分けて考えたいところです。［3・5］

    今回の発表が示すのは、信頼の基点を載せるだけでなく、その個体を登録し、検証に使う情報を設定し、権限を切り替えて引き渡すまでのつながりです。製造者と運用者がこの境目を共有できれば、サーバーが届いた後に「何を根拠に信頼するのか」を、より具体的に確かめられます。

    Googleを含むAlphabetの事業を知る

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

    Alphabetの企業解説へ

    参考資料

    2026年9月26日確認。公式スライド全17ページ、製造フロー図、Caliptraの公開仕様・ガイド・リリース記録を照合しました。講演動画の音声・質疑は確認対象に含めていません。

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

    ［2］Google「Caliptra Subsystem Provisioning」公式掲載スライド。設定対象はpp.2–4、状態と製造フローはpp.5–12、参照コードと開発段階はpp.13–15。

    ［3］CHIPS Alliance「Caliptra Subsystem Provisioning Guide」。ヒューズ、ライフサイクル、CSRの認証、製造後の設定制約。製造インフラの個別認証を保証する文書ではありません。

    ［4］CHIPS Alliance「Caliptra」公開仕様。UDS、IDevID、DICE、秘密鍵の扱い。閲覧時点のmainブランチを参照しています。

    ［5］CHIPS Alliance「caliptra-mcu-sw」リリース一覧。2026年8月24日公開のrt-sdk-2.0.0／rt-sdk-2.1.0と、製品ごとの組み込みが必要な参照SDKとしての位置づけ。

  • OCP Korea 2026 | 公開仕様から製品選びへ、OCPの貢献データベースとMarketplaceの使い分け

    OCP Korea 2026 | 公開仕様から製品選びへ、OCPの貢献データベースとMarketplaceの使い分け

    OCPの記事には、公開仕様、ワークストリーム、認定製品、Marketplaceといった言葉が出てきます。どれも同じ場所を指しているようで、役割は少しずつ違います。

    2026年8月のOCP Korea Tech DayでMichael Schill氏が紹介した「OCP 101」は、そのつながりを見渡すための講演です。議論に参加する場所、設計の根拠を読む場所、実際の製品を探す場所を分けると、OCPの技術を追いやすくなります。［1・2］

    簡単にまとめると？

    • OCPは、技術を議論するプロジェクトと、公開された成果物、製品を探す場を分けて読むと追いやすくなります。
    • 貢献データベースは共有された設計や仕様、Marketplaceはそれを使った製品・サービスを探す入口です。
    • 講演の提案を正式仕様や認定製品と混同せず、公開資料の版・対象範囲・利用条件を確かめます。

    OCPは、一つの完成品を売る場所ではない

    Open Compute Projectは、データセンターに関わる技術を共有し、共同で発展させるコミュニティです。対象はサーバーやラックだけでなく、電力供給、冷却、ネットワーク、ストレージ、管理、セキュリティー、さらにチップレットやフォトニクスにも広がっています。［2・3］

    同じ「OCPの取り組み」でも、すでに公開された仕様を読む段階と、新しい要求を議論する段階は違います。講演で提案された内容が、その時点で正式な仕様や認定製品になっているとは限りません。まず、資料がどの段階の成果物なのかを見ることが出発点になります。

    プロジェクトから、公開された成果物へ

    講演資料では、トップレベルのプロジェクト、その下のサブプロジェクトやワークストリームから、成果物がOCP Contribution Database（貢献データベース）へつながる構造が示されています。ワークストリームは、特定のテーマを継続的に検討する作業のまとまりです。［2］

    成果物は仕様書だけではありません。参照アーキテクチャー、ソースコード、試験済みの構成、ホワイトペーパーなども含まれます。それぞれが答える疑問も異なります。寸法や接続条件を確かめるなら仕様書、全体の組み方を知るなら参照アーキテクチャー、試験の前提を読むなら構成と結果を扱う文書、というように使い分けられます。

    ただし、成果物が公開されていることと、自分の設備でそのまま使えることは同じではありません。対象範囲、版、前提となる条件を読み、手元の構成との対応を確かめる必要があります。

    Marketplaceは、設計を採用する入口になる

    公開された技術や設計は、製品、チップレット、統合ソリューション、施設やサービスとして提供されます。OCP Marketplaceは、そうした認定製品やサービスと、その提供者を探すための場所です。［2・4］

    貢献データベースが「何が共有されているか」を読む入口なら、Marketplaceは「その技術を使った何が提供されているか」を探す入口です。資料と製品の間にどんな対応があるかを追えると、仕様書の名前だけで候補を選ばずに済みます。

    施設を扱うOCP Readyや、製品を扱う認定表示などは、対象とする範囲が違います。講演資料も、体験センター、施設、製品・サービスの紹介を分けています。個別の製品を比較するときには、その掲載ページと関連する成果物、適用されるプログラムを一緒に確認したいところです。［2・4］

    AI向けには、建物とクラスタの両側で設計が進む

    講演は、AI向けの取り組みを「Open Systems for AI」という大きな枠の下で説明しています。その中には、建物や物理設備を主に扱うOpen DC for AIと、計算機群の組み合わせを扱うOpen Cluster Designs for AIがあります。［2］

    前者は、電力供給やバックアップ、送配電網との接続、水の供給と冷却、建物や機械設備、物理インフラのテレメトリーなどが対象です。後者は、列・ラック・ネットワークを含むクラスタやポッドの構成を扱います。液冷にも空冷にも、それぞれの設計の検討があります。［2］

    たとえば高密度のAIラックを導入するとき、サーバーの仕様だけを読んでも、建物側の電力や熱の受け渡しは決まりません。逆に施設の容量だけでは、計算機間の通信の組み方までは決まりません。二つの取り組みを分けて読むと、どこまでを一つの資料で確かめられるかが見えやすくなります。

    参加は、資料を読むところから始められる

    講演の最後では、プロジェクトのメーリングリストや会議への参加、仕様などへの貢献、イベントやワークショップへの参加という、複数の関わり方が挙げられています。役職を担うことだけが参加ではなく、公開情報を学び、議論を知り、経験や要求を共有するところにも入口があります。［2・3］

    OCP Academyには技術とコミュニティの入門講座があります。関心のあるプロジェクトを見つけたら、まず資料と会議の案内を読み、扱う課題と参加条件を確認する。そのうえで、仕様の読み手としてなのか、設計や運用の経験を持ち込む側なのかを考えると、次の行動を選びやすくなります。［2・5］

    OCPを追うときは、発表だけで完結させず、プロジェクト、成果物、製品へとつながりをたどる。逆に製品から入ったときには、対応する仕様と議論へ戻る。この往復が、名前の近い技術や、提案と完成した仕様を混同しないための助けになります。

    参考資料

    2026年9月27日確認。組織図・件数・将来の市場予測ではなく、講演が示した参加と採用の仕組みを中心に整理しています。

    ［1］Open Compute Project「2026 OCP Korea Tech Day」発表一覧

    ［2］Michael Schill「OCP 101: How to Engage with the OCP Community」公式掲載スライド。技術範囲はpp.3–5、貢献と市場のつながりはpp.10–12、AIの取り組みはpp.16–17、学習と参加はpp.24–28。

    ［3］Open Compute Project「Community」

    ［4］Open Compute Project「Marketplace」

    ［5］OCP Academy

  • OCP APAC 2026 | MRCが組み合わせる、パケット単位の多経路化と選択的再送

    OCP APAC 2026 | MRCが組み合わせる、パケット単位の多経路化と選択的再送

    AIの処理を分担する計算機が増えると、通信の一部に混雑が集まるだけで、ほかの計算機も待たされます。回線の速度を上げるだけでなく、空いている経路を使い、届かなかったデータを効率よく送り直すことが重要になります。

    2026年8月のOCP APAC SummitでMicrosoftとBroadcomが説明したMRC（Multipath Reliable Connection）は、パケット単位で通信を複数の経路へ分け、順番が前後した到着と選択的な再送を扱う仕組みです。一本の経路に通信を固定する考え方から、ネットワーク全体の使い方を見直しています。［1・2］

    簡単にまとめると？

    • MRCはパケットを複数の経路へ分け、届く順序の違いを受信側で扱う仕組みです。
    • 不足分だけを再送し、経路選択や混雑の検知と組み合わせてネットワークの余力を使います。
    • 障害試験は特定構成での結果であり、損失の影響がなくなることや、すべてのAI処理の性能を保証しません。

    複数の経路を使うなら、到着順の違いも受け止める

    RDMAは、離れた計算機のメモリーへ効率よくデータを転送するための仕組みです。今回の資料では、従来のRDMA運用での課題として、多経路化、順序が入れ替わったパケットの処理、再送の効率、輻輳制御の調整を挙げています。ここでの比較を、あらゆるRDMA実装が同じ制約を持つという意味には広げられません。［2］

    MRCで使うパケットスプレーは、一つの通信のパケットを複数の経路へ振り分ける方法です。同じ宛先でも通る道が違えば、後から送ったパケットが先に着くことがあります。

    そこで必要になるのが、Out-of-Order Packet Delivery（OOPD）、つまり送信順と異なる順番での到着を扱う機能です。資料の図では、異なる経路を通ったパケットを受信側がメモリー内の対応する位置へ受け入れています。経路を増やすことと、順序の違いを扱うことを組み合わせて初めて、複数の道を使いやすくなります。［2］

    届いたものを全部送り直さず、不足分を再送する

    パケットが欠けたときの処理も重要です。資料は、途中から後ろをまとめて送り直すGo-Back-N型の課題に対し、選択的再送を示しています。［2］

    受信側が、どの範囲を受け取り、どこが欠けたかをSACK（Selective Acknowledgment）とビットマップで知らせ、送信側は必要なパケットを送り直します。資料の例では、先に届いたデータを残し、欠けた番号を埋める流れが描かれています。［2］

    これは、届かなかったデータを無視して処理を進めるという話ではありません。正しくそろえるための信頼性を保ちながら、すでに届いたデータの再送を減らす考え方です。多経路による順序の変化と、実際の欠落を区別して扱うことが、その前提になります。

    経路の選択を、通信の端から考える

    MRCの説明には、SRv6を用いたソースルーティングも登場します。SRv6は、IPv6ネットワーク上でセグメントの指定を使って通信の経路や処理を表す仕組みです。［3］資料では、各スイッチだけで判断する従来の構成と、コントローラーを用いてワークロードに応じた端から端までの経路を扱う構成を対比しています。［2］

    ここで重要なのは、単に経路の本数が多いことではありません。計算の通信パターンに合わせて、どの経路へ負荷を分けるかを考えられることです。複数の独立したネットワーク面を使うマルチプレーン構成も、この説明の一部になっています。

    混雑の手がかりを、データが消える前に返す

    資料のパケットトリミングの例では、混雑した箇所でパケットのペイロードを取り除き、ヘッダーを受信側へ渡します。到着したヘッダーを、混雑に関する手がかりとして使う構成です。［2］

    すべてが消えて何も届かない場合と比べると、どのパケットが混雑の影響を受けたかを知る材料が残ります。MRCの発表では、この仕組みを誤った混雑判断を減らすための要素として位置づけています。具体的な制御条件は実装に依存し、図に描かれたバッファー使用率を、あらゆる機器の共通設定値と読むものではありません。

    障害試験から、何が分かるか

    発表では、Thor Ultraを搭載したPCIe Gen 5サーバーで、リンクを取り外す試験や、ランダムな損失を加える試験が示されました。後者は、16台のサーバー、リーフ・スパイン構成、ib_write_bwによる全対全の通信で、特定のリンク群の損失率を変えています。［2］

    結果の図は、損失が増えるにつれて再送が増え、スループットも低下する様子を示しています。MRCが損失や故障の影響をなくすのではなく、残る経路と再送処理を使って通信を続ける、という読み方が適切です。この試験だけから、あらゆるAIモデルの学習時間や、すべての障害時の性能を決めることはできません。

    MRCの要点は、経路を分ける、順序の違いを扱う、不足分を送り直す、混雑を知るという機能を一緒に考えることです。AIネットワークの余力を使うには、速いリンクを並べるだけでなく、データが届くまでの振る舞いをつないで設計する必要があります。

    発表企業の事業を知る

    MicrosoftとBroadcomの会社全体の事業については、cyclewaveの企業解説から読めます。

    Microsoftの企業解説を読む
    Broadcomの企業解説を読む

    参考資料

    2026年9月27日確認。試験結果は講演資料に記された構成と条件に限ります。

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

    ［2］Microsoft・Broadcom「Enabling AI Networking @ Scale with Multi-path Reliable Connections（MRC）」公式掲載スライド。機能と経路はpp.3–8・16、順不同受信と選択的再送はpp.9–15、パケットトリミングはpp.17–20、障害・損失試験はpp.21–22。

    ［3］IETF RFC 8986「Segment Routing over IPv6（SRv6）Network Programming」。SRv6の概要とセグメントの定義。

  • OCP APAC 2026 | 液空HRUの流量不足を、圧力損失と導入時の診断から防ぐ

    OCP APAC 2026 | 液空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。

  • OCP APAC 2026 | Microsoftのラック台数の見積もり、CPU利用率の分布から電力を読む

    OCP APAC 2026 | 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。

  • OCP APAC 2026 | GPUクラスタの健全性を計算・通信・熱・ストレージで測るOCRP案

    OCP APAC 2026 | GPUクラスタの健全性を計算・通信・熱・ストレージで測るOCRP案

    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の説明。

  • OCP APAC 2026 | メモリーエラーが出ても、原因はDIMMとは限らない

    OCP APAC 2026 | メモリーエラーが出ても、原因は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。