Quantum Sea

タグ: OCP APAC 2026

  • OCP APAC 2026 | Googleが示すPCIe Gen6接続検証、公差と他社ケーブルの組み合わせ

    OCP APAC 2026 | Googleが示すPCIe Gen6接続検証、公差と他社ケーブルの組み合わせ

    同じサーバーで、ケーブルを別のメーカーのものに替えると通信品質が変わる。高速な接続では、部品を一つずつ確かめるだけでは見つけにくい問題があります。コネクターとケーブルが、実際にかみ合ったときの状態まで見る必要があるためです。

    GoogleのScott Lee氏らは、PCIe Gen6／Gen7の接続を見据え、標準的なコネクターやケーブル構成から外れるシステムの設計・検証方法を提案しました。寸法公差の分析、製造中の測定、メーカーをまたぐ組み合わせ試験をつなぎ、接続全体の余裕を確かめる考え方です。［1］

    挿入損失が合格でも、組み合わせ全体は合格とは限らない

    発表の背景には、基板への実装後に分かったコネクターのばらつきと、異なるメーカーのケーブル・コネクターを組み合わせた際の相互運用性の問題があります。ここでいう「非標準」は、PCIeの標準的な接続部品や構成に、そのまま当てはめられないという意味です。独自の形状を使うだけで、直ちに通信できないと決まるわけではありません。［1］

    資料の試験表では、信号がどれだけ弱まるかを見る挿入損失（IL）は、掲載された全組み合わせで合格しています。一方、iRLなど別の評価項目には不合格が混じっています。同じシステムでケーブルを替えた際のRaw BER、つまり誤り訂正前のビット誤り率にも差が示されています。一つの指標が良好でも、接続全体の品質は決められません。［1］

    寸法の「許容範囲」を組み合わせて考える

    コネクターは、図面どおりの一つの形だけで量産されるものではありません。接続する基板の厚さ、接点の位置、ピンの幅やめっきの厚さなどに、製造上許される範囲、すなわち公差があります。この小さな差が重なると、高速信号から見たインピーダンスにも違いが生まれます。［1］

    提案の中心は、DOE（実験計画法）によって、公差の組み合わせと電気特性の関係を調べることです。基板側とコネクター側の寸法条件を組み合わせ、インピーダンスの変化に効く要因を探します。代表的な一個だけでなく、許容範囲の端に寄った条件も設計段階で扱うわけです。［1］

    掲載例では、製造パラメーターの最適化前後で、インピーダンス曲線の最大値と最小値の差が11.88Ωから8.72Ωへ縮まっています。これはその図に示されたコネクターの比較例であり、すべての部品に同じ改善幅が出るという値ではありません。重要なのは、ばらつきを分析し、その要因へ設計変更を戻す手順です。［1］

    製造中の変化と、他社部品との相性を分けて測る

    完成後に基板へ実装して測る検査は、詳しい特性を調べられる反面、問題が見つかる時点が遅くなります。Googleの提案では、コネクターを製造工程の途中で測定し、特性が変化していないかを追います。インライン検証と呼ばれる方法です。［1］

    ただし、製造中の測定で確認できるのは特性の一部です。資料もこの制約を明記しており、完成品やシステムの評価を丸ごと置き換える案ではありません。早い段階で変化を捉える検査と、組み上がった状態を詳しく確かめる検査には、それぞれ役割があります。［1］

    ケーブルの相互運用性では、メーカーXのコネクターを使った治具に、別のメーカーYのケーブルを接続して測る構成を示しています。評価場所も特定メーカーに依存しない試験所とし、知的財産や測定環境の差をめぐる懸念を減らす考えです。自社同士でうまくつながることと、他社製品ともつながることを、別々に確かめます。［1］

    最後はホストから受信側まで、一本の経路として見る

    システム設計者は、各メーカーから公差の厳しい側を含む部品モデルを受け取り、ホストから受信側までの伝送路を評価します。提案は、個々の独自部品を標準品と呼び替えることではなく、組み合わせた経路がPCIe Base仕様のチャネル要件を満たすかを確かめるものです。［1］

    発表時点では、GoogleはPCI-SIGとの合意のもとで、この方法をOCPを通じて公開する計画を示しています。採用済みの認証制度というより、設計・製造・評価をつなぐ方法の提案です。高速化する接続で、メーカーの違いを越えて品質をそろえるには何を共有すべきか。その答えを、部品の形状だけでなく、測り方にも求めています。［1］

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

    Alphabetの企業解説へ

    参考資料

    2026年9月27日確認。

    1. Google「PCIe Design and Validation Strategy with Non-Standard Connector and Cable Linkage」 — 2026 OCP APAC Summit公開スライド。背景・相互運用性p.3–9、公差とDOE p.10–13、製造・組み合わせ・システム検証p.14–16、公開計画p.17。
    2. Open Compute Project「2026 OCP APAC Summit」 — 発表者・演題・配布資料の掲載元。
  • OCP APAC 2026 | AIクラスターの公開設計、400Gの構成から800G液冷への拡張

    OCP APAC 2026 | AIクラスターの公開設計、400Gの構成から800G液冷への拡張

    AIの計算基盤をつくるとき、アクセラレーターの型番が決まっても、まだ設計は終わりません。計算機同士の接続、データを置くストレージ、ジョブを動かす管理サーバー。それぞれを、実際に配線して運用できる一つの構成へまとめる必要があります。

    その手がかりになるのが、OCPのOpen Cluster Designs for AIです。2026年8月のOCP APAC Summitでは、BroadcomのBhaskar Chinni氏が、公開済みの400G・空冷構成と、開発中の800G・液冷構成を紹介しました。部品の組み合わせだけでなく、ラックへの配置や管理系まで含めて、AIクラスターをどう組み立てるかを示す取り組みです。［1・2］

    計算機の一覧を、組み立てられる設計へ

    ここでいうリファレンスアーキテクチャーは、構成を検討する際の参照設計です。資料では、計算、ネットワーク、ストレージ、接続トポロジー、管理基盤を、その対象に挙げています。XPUはAIアクセラレーターを広く指す呼び名で、特定の製品名ではありません。［2］

    設計図には、どのラックに機器を収め、どのポートを結び、どのケーブルや光部品を使うかという情報が登場します。部品表に加えて、電力、設置面積、重量の見積もりも扱います。調達する側と設置する側が、同じ構成を見ながら話を進められる粒度です。［2］

    AIの学習では、計算機を増やすほど、その間を行き来するデータや、保存するチェックポイントも増えます。計算の量に対して通信やストレージが足りなければ、速いアクセラレーターも待つことになります。資料が目指しているのは、こうした比率をそろえた、バランスのよいクラスターです。機器を2倍にすれば必ず処理が2倍速くなる、という性能保証ではありません。

    五つのネットワークには、違う役割がある

    公開済みの400G設計を読むうえで分かりやすいのが、ネットワークを役割ごとに分けている点です。資料には、XPU同士のスケールアウト、CPU側のスケールアウト、ストレージ、インバンド管理、アウトオブバンド管理という五つのネットワークが描かれています。［2］

    XPU側は分散したAI計算の通信を、ストレージ側は学習データや計算結果の出し入れを受け持ちます。CPU側にも、前処理などの仕事と、それに応じた通信があります。同じクラスターの中でも、流れるデータと、求められる性能が少しずつ違います。

    管理用の接続も一種類ではありません。インバンド管理は通常のシステム接続を通して運用するための経路で、アウトオブバンド管理は、機器の専用管理ポートなどを使う別系統の経路です。後者には、サーバーだけでなく、スイッチや電源分配装置の管理も含まれています。計算を行う経路が不調なときにも、状態を調べたり復旧したりする手段を考えておくわけです。［2］

    これは、すべてのAI基盤で必ず五つを物理的に分離しなければならない、という決まりではありません。資料でも機器を共用する構成に触れ、次の800G設計では一部を統合する方向を示しています。大切なのは、統合する場合も、それぞれの通信が担う役割を見失わないことです。

    ジョブを動かすまでの準備も、設計に含める

    計算ノードの外側には、ヘッドエンドと呼ばれる管理・制御側の機器群があります。監視、ジョブのスケジューラー、一時的なデータ置き場に加え、OSイメージ、コード、コンテナーを用意する仕組みも配置されています。［2］

    利用者がコードを用意し、実行環境を整え、ジョブを投入して、結果を取り出す。この流れを支える機器も必要です。アクセラレーターだけを並べた図では見えにくい部分ですが、実際に使える計算基盤にするには欠かせません。

    公開設計を読むときも、計算ノードの台数と同じくらい、管理サーバーや一時領域がどこにあり、どのネットワークへつながるのかを見ると、運用時の姿を想像しやすくなります。

    800Gへの拡張では、冷却と運用も変わる

    発表時点で、400G・空冷のOPG-128は2026年1月に公開済みでした。OPGはOpen Pod Groupの略で、末尾の数字は含まれるXPU数を表します。一方、800G・液冷のOPG-576は、同年2月に開発を始めた構成として紹介されています。［2］

    800G案では、576基のXPUを含むグループに対して、計算機とネットワークの液冷ラック、列の端に置くCDUが描かれています。CDUは冷却液の循環や熱交換を担う装置です。接続速度を上げるだけでなく、高密度になった機器の熱を、施設側へどう渡すかも構成の一部になっています。［2］

    管理側の構成も広がっています。資料は推論やエージェント型AIの利用を挙げ、障害が起きた際に、性能が予測可能な形で段階的に低下することを目標にしています。故障しないことだけでなく、一部が止まったときに何を続けられるかまで、設計の視野に入っています。

    ただし、ここで示された800G構成は開発中のプレビューです。図にも変更を見込む旨が添えられており、完成版の仕様や、そのまま導入できる確定済みの部品表として読む段階ではありません。

    公開設計のよさは、速い機器を見つけるだけでなく、その周囲に必要なものまで一緒に考えられることです。計算、通信、保存、冷却、運用をつなげて見ると、AIクラスターを動かし続けるための条件が見えてきます。

    発表企業の事業を知る

    Broadcomが手がける半導体とインフラソフトウェアの事業については、cyclewaveにまとめています。

    Broadcomの企業解説を読む

    参考資料

    2026年9月27日確認。800G構成の開発状況は、2026年8月の講演資料に基づきます。

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

    ［2］Bhaskar Chinni／Broadcom「Open cluster designs for AI: Blueprints for open-source AI infrastructure」公式掲載スライド。設計の範囲と用語はpp.3–6、公開・開発状況はpp.7–8、400G構成はpp.11–19、800G構成と今後の方向はpp.21–24。

  • 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］

    三つの技術は、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］

    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は、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 APAC 2026 | MRCが組み合わせる、パケット単位の多経路化と選択的再送

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

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

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

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

    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は、サーバーのコールドプレートから戻った冷却液を、液空熱交換器のコイルへ通します。ファンウォールで空気を流し、液体が運んだ熱をホットアイル側へ渡す構成です。ポンプ、リザーバーや膨張タンク、マニホールド、温度・圧力・流量の計測点も含まれます。［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 | 高電力DCと液冷の安全設計、危険源と保護手段を結ぶHBSE

    OCP APAC 2026 | 高電力DCと液冷の安全設計、危険源と保護手段を結ぶHBSE

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

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

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

    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」。空間距離・沿面距離の用語定義。

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

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

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

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

    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 公開リポジトリ。プロジェクトの公開状況を参照。講演中の将来提供日程とは区別しています。