Quantum Sea

タグ: Google

  • GoogleとBroadcomのSONiC仮想検証、実機が届く前に不具合を探す

    GoogleとBroadcomのSONiC仮想検証、実機が届く前に不具合を探す

    新しいネットワークスイッチを使うには、チップだけでなく、それを動かすソフトウェアも準備する必要があります。ところが実機が届くまで検証を始められないと、不具合の発見も後ろへずれてしまいます。

    この待ち時間を減らすために、GoogleとBroadcomが紹介したのが、Alpine Virtual Switch（AVS）とTH6向けBCMSIMを組み合わせる検証環境です。ネットワークOSのSONiCと、スイッチチップの動作モデルをつなぎ、実機の到着前からソフトウェアの組み合わせを確かめます。講演では、Googleが最初のTH6実機サンプルを受け取る前に、約40件の異なる問題を特定して解決したと報告しています。［1］

    簡単にまとめると？

    • AVSとTH6 BCMSIMをつなぎ、実機が届く前からSONiCとスイッチのソフトウェアを検証します。
    • 動作モデルの細かさと設定を検証目的に合わせ、ソフトウェア間の不整合を早く見つける設計です。
    • 仮想環境での検証は、実機の発熱・電力・信号品質まで再現した証拠ではありません。

    実機の数に、検証の数を縛られないようにする

    講演が挙げる課題は、スイッチが高価で、開発者と自動テストが同じ試験設備を共有しやすいことです。接続できる台数が限られれば、大きなネットワーク構成も試しにくくなります。新しいチップでは、そもそも実機がまだ用意できない段階から、ソフトウェアの開発が進みます。［1］

    AVSは、SONiCのソフトウェア群をコンテナ化し、パケットを転送するデータプレーンの実装を差し替えられる仮想スイッチです。複数のAVSをつなぐ際には、Kubernetes上でネットワークを再現するKNE（Kubernetes Network Emulation）を使う「Aktive」が配置を受け持ちます。1台の動作と、複数台を結んだ構成を、段階を分けて検証できる形です。［1］

    何を再現するかで、モデルを選ぶ

    仮想スイッチといっても、実機のどこまでをソフトウェアで表すかは同じではありません。資料は、AVSに組み合わせる選択肢を三つの層に分けています。［1］

    • VPPは、高速なソフトウェアのパケット処理エンジンです。チップや、その制御用SDKのモデルは持ちません。
    • Luciusは、SAI（Switch Abstraction Interface）の層でスイッチの動作を表します。SAIは、SONiC側からスイッチを制御するための共通インターフェースで、LuciusはSONiCの機能を素早く確かめる用途に位置づけられています。
    • BCMSIMは、チップ内部の制御情報を読み書きするレジスターの動作まで扱うデバイスモデルです。その上で、実機向けのBroadcom SDKとSAIを動かします。

    SDKは、ソフトウェアからチップを扱うためのライブラリーなどをまとめたものです。BCMSIMを使うと、SONiCの機能だけでなく、SAI、SDK、チップの動作モデルへと続く組み合わせを確認できます。検証したい層に応じて、処理の速さや規模と、モデルが扱う詳細さを選ぶ考え方です。資料には、この三方式を同じ条件で測った性能比較は示されていません。［1］

    仮想ポートをつなぎ、実機と設定をそろえる

    今回の構成では、TH6の動作モデルと仮想ネットワークインターフェースの間に「BCMSIM vBridge」を置きます。モデル側と外側で使うメッセージを橋渡しし、パケットの送受信や、リンクが切れて戻る変化をやり取りします。CPU向けのパケットには別の仲介層があり、ポートごとの統計も観測します。［1］

    もう一つ大切なのが、AVSと実機側の設定をそろえることです。資料では、SONiCのconfig_db.jsonやBroadcomのbcmsim-config.ymlを例に挙げています。同じ問題を仮想環境で追いたくても、設定が違えば、動作の違いがどこから来たのか切り分けにくくなります。モデルを用意するだけでなく、再現に必要な条件を合わせるところまでが検証環境の設計です。［1］

    約40件の問題を、最初の実機より前に解決

    講演で報告された約40件は、SAI・SDKとネットワークOSの設定に関する問題です。Googleが最初のTH6実機サンプルを受け取る前に特定・解決した件数であり、チップの物理的な欠陥を40件見つけた、という意味ではありません。［1］

    こうした検証は、コードを取り込む前の自動テストにも組み込めます。資料では、クラウド上で数時間ごと、または重要度に応じて毎晩、AVSとTH6 BCMSIMを使う自動処理を走らせる取り組みを説明しています。変更のたびに実機の順番を待たず、ソフトウェアの不整合を早めに見つける狙いです。［1］

    GoogleのAVS環境をBroadcom側の仮想マシンで立ち上げる試みも、単発の実験として報告されています。同じ環境を共有し続けられれば、問題を説明し直す往復を減らせる可能性があります。ただし、継続運用による短縮効果は、今回の資料では測定結果として示されていません。［1］

    仮想環境で前倒しできる範囲を、はっきりさせる

    BCMSIMは、資料ではASICの「デジタルツイン」と呼ばれています。ここで示されているのは、チップの動作モデルを使い、設計からSDK、SAI、SONiCへと検証をつなぐ仕組みです。実機の発熱、電力、信号品質、実効的な転送性能まで、すべて同じように再現できることを示すものではありません。［1］

    検証のうち、実機を待たずに進められる部分を増やす。実機が届いたら、物理環境でしか確かめられない部分に向き合う。AVSとBCMSIMの組み合わせは、その順序を組み直し、ソフトウェアの問題を早い段階で減らしておくための取り組みです。

    発表に登場する企業を知る

    Broadcomの半導体・基盤ソフト事業と、Googleの親会社Alphabetの事業全体は、cyclewaveの企業解説にまとめています。

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

    参考資料

    ［1］Google・Broadcom「Accelerate fabric validation with Alpine VS and BCMSIM」。2026 OCP APAC Summitの公開スライド。3–5ページ：検証設備の課題とAVS・Aktive、7–11ページ：モデルの層と接続・設定、12–14ページ：適用例と報告結果。公式一覧では「Accelerate cloud scale validation with AVS and TH6 BCMSIM」として掲載。

    ［2］Open Compute Project「2026 OCP APAC Summit」。開催日・登壇者・公開資料の案内。記事は公開スライドをもとに構成しています。

  • GoogleのAIチップ電源検証案、インターポーザーと負荷変動の自動試験

    GoogleのAIチップ電源検証案、インターポーザーと負荷変動の自動試験

    AIチップへ電気を届ける回路は、必要な電流が急に変わっても、電圧を許容範囲に保たなければなりません。その確かめ方も、一定の電流を流すだけでは足りません。電流の変化をどれほど速く、どの周期で繰り返すかまで、試験の条件になります。

    2026年8月のOCP APAC SummitでGoogleが示したのは、専用の処理を担うASICなどの電源を検証するために、試験用インターポーザーの設計から、負荷を自動で変える試験までをつなぐ手順です。装置のつまみを自動で回す前に、何を再現し、どこで測るかをそろえる。そこが、この提案の出発点です。［1・2］

    簡単にまとめると？

    • AIチップの電源試験では、最大電流だけでなく、電流が変わる速さや繰り返し方もそろえます。
    • Googleの提案は、試験用基板の配線・測定点から、負荷を順に変えて波形を記録する自動化までをつなぎます。
    • 仕様公開やAIによる波形判定は発表時点の計画で、短縮率や判定精度の実測値は示されていません。

    電流の大きさと、変わる速さを分けて見る

    まず確認するのは、チップの電源仕様です。資料は、電源系統である電源レールごとに、定常時と変動時の電圧条件、リップルと呼ばれる電圧の細かな揺れ、電流が変化する速さを確認するよう求めています。この変化の速さがスルーレートです。同じ最大電流でも、ゆっくり増える場合と急に増える場合では、試す条件が異なります。［2］

    続いて、その条件を作れる負荷ツールを選びます。必要な最低電圧とピーク電流に対応するか、電流を正確に読めるか、立ち上がり・立ち下がりの速さを調整できるかを確認します。発熱への冷却や、過熱・逆挿しへの保護も選定項目です。ノイズの許容範囲が厳しいレールには、静的な負荷を備えたインターポーザーで試験する案も示されています。［2］

    試験用の接続基板も、測定結果を左右する

    ここでのインターポーザーは、電源の試験対象と負荷ツールをつなぐ接続基板です。資料では、高密度に配線できるHDI基板を使い、電源、グラウンド、制御信号、電流測定用のシャント信号の接続を確認します。電源を試すための基板として、配線と測定点を設計します。［2］

    負荷ツールは、電源レールの出力の近くに置きます。接続経路の抵抗による電圧低下、IRドロップを小さくするためです。測定点へは専用の配線対を引き、どこの電圧を読み取るかも設計段階で決めます。負荷をかける位置と電圧を測る位置の両方を整えて、試験したい電源の状態を捉えます。［2］

    さらに、基板の層をつなぐビアに電流が偏らないか、配線の抵抗が最大負荷時の動作を妨げないかを、直流のシミュレーションで確認します。電圧の測定にはMMCX同軸コネクターや適切なアクティブプローブを使う案もあります。試験を自動化しても、その入口となる配線や測定方法が不適切なら、欲しい波形は得られません。［2］

    負荷を変えながら、電圧と電流を一緒に記録する

    試験の構成では、直流電源が負荷ツールと電圧レギュレーター（VR）へ給電し、信号発生器が負荷の変動を作ります。オシロスコープは出力電圧と、電流を知るためのシャント信号を記録します。操作画面であるGUIが、条件の変更と波形の取り込みをまとめて制御します。［2］

    資料の「3D Automation」は、この条件をプログラムで順に変える自動掃引の構想です。GUIでは負荷電流の最大値と増減の速さを設定し、周波数とデューティー比の開始・終了値を指定します。周波数は負荷変動を繰り返す速さ、デューティー比は一周期のうち負荷パルスがオンになっている時間の割合です。［2］

    掲載された3Dグラフは、周波数とデューティー比に対して、出力電圧の最大値がどう変わるかを立体的に表しています。この発表の3Dは、試験条件の自動掃引と応答の立体表示に関する表現で、半導体の積層構造を指してはいません。［2］

    たとえば、最大電流だけを合わせて一度測る試験では、繰り返し方を変えたときの電圧応答まではわかりません。周波数とデューティー比を順に変えれば、どの組み合わせで電圧が大きく変動するのかを探れます。自動化の狙いは、測定回数を増やすだけでなく、条件と波形を対応づけて比較しやすくすることにあります。

    基板・負荷ツール・操作画面を、共通の手順でつなぐ

    発表が目指しているのは、ASICの設計者、基板の設計者、負荷ツールの提供者が、同じ試験手順を共有できる環境です。仕様の読み取り、負荷ツールの選定、インターポーザー設計、測定系の構築、自動掃引を一続きにすることで、どこまで確かめたかを共有しやすくしようとしています。［2］

    発表時点では、負荷ツール、インターポーザー、GUIの設計プロセスを扱うOCP仕様を公開する計画が示されています。発表資料を、確定済みの仕様書として読むことはできません。AIで波形を識別して調整案を出すことも今後の可能性として述べられており、この資料には、試験時間の短縮率やAIによる判定精度の実測値は示されていません。［2］

    この提案から見えるのは、電源試験の自動化を支える基板と計測の大切さです。必要な負荷を作れること、そのときの電圧を正しい位置で測れること、条件を変えて同じ手順を繰り返せること。その三つをそろえるところから、AIチップの電源を確かめる仕組みは始まります。

    Googleの親会社Alphabetについて

    Googleを傘下に持つAlphabetの事業と収益構造は、cyclewaveの企業解説にまとめています。

    cyclewaveでAlphabetの企業解説を読む

    参考資料

    2026年8月11〜12日開催の発表資料をもとに構成。仕様公開とAI活用に関する記述は、発表時点の計画・提案です。

    1. Open Compute Project「2026 OCP APAC Summit」 — 公式イベント・発表資料一覧。
    2. Google「Interposer design flow with 3D Automation loading Slammer for ASIC/xPU.」 — Li-Chung（Leo）Chen、Jimmy Chen。公式一覧からリンクされたスライド。pp.3〜8：設計・試験手順と自動掃引、pp.9〜11：共通化と仕様公開の計画。
  • 電力・冷却・建物の接続条件をそろえる、Googleのデータセンター構想

    電力・冷却・建物の接続条件をそろえる、Googleのデータセンター構想

    新しいAIサーバーを導入するとき、機器がラックに収まれば準備が終わるわけではありません。必要な電力を届けられるか、熱を施設の外へ運べるか、保守のための場所が残るか。サーバーの世代交代は、建物側の設計にもつながっています。

    GoogleのGregory Moore氏が示したのは、こうした関係をまとめて考える「Fungible & Sustainable Data Center」という構想です。ここでのfungibleは、異なる機器や将来の構成へ対応しやすいこと。GPUを自由に差し替えられるという意味ではなく、設備の接続条件をそろえ、変更を受け入れられる施設を目指す考え方です。［1］

    簡単にまとめると？

    • Googleは電力・冷却・建物の接続条件をそろえ、将来の機器変更に対応しやすい施設を構想しています。
    • 蓄電は容量だけでなく、変動する時間幅と影響範囲に応じて役割を分けます。
    • CDUの公開仕様があっても、流量や接続条件、配置と保守の空間を施設ごとに合わせる必要があります。

    設備ごとの最適化から、つながりを決める設計へ

    発表の軸は、モジュール化、相互運用性、標準化を、電力・冷却・建物まで横断して進めることです。高性能なサーバー、効率のよい電源、大きな冷却能力があっても、それぞれの接続条件が合わなければ、一つの施設としては使えません。［1］

    OCPが進めるOpen Data Centerの取り組みも、電力、冷却、機械的な構造、計測情報を共有できる設計へ広げています。特定の機器だけに施設を合わせ込む度合いを減らし、次の構成を選べる余地を残す方向です。［2］

    電力は「何MWか」に加え、変化への応答を考える

    AIの処理では、消費電力が時間とともに変わります。その変動が、サーバー内部の問題で収まるのか、ラック列や施設、電力系統まで伝わるのかによって、備える設備も変わります。資料は、最大電力の容量だけでなく、負荷の急変や系統との相互作用を設計上の課題にしています。［1］

    そこで示されるのが、蓄電を三つの階層へ分ける考え方です。チップやラックの近くでは、コンデンサーやラック内のバッテリーバックアップで短い変動に応答する。ラック列では、列の端や側方に置く蓄電設備で電力をつなぎ、ピークを抑える。施設では、大きな蓄電システムを長時間のバックアップや系統への対応に使います。［1］

    これは、どのデータセンターにも同じ三段構成を必須にする説明ではありません。変動の時間幅と影響する範囲を分け、どこで受け止めるかを選ぶための整理です。容量の大きさだけで蓄電設備を選ぶと、その役割の違いが見えにくくなります。

    電源装置の標準化には、過渡応答と寸法も含まれる

    電力変換では、半導体による変換回路を用いるSST（Solid-State Transformer）が取り上げられています。資料が標準化の対象にしているのは、入力と出力の接続、配電構成だけではありません。定常時と過渡時の性能、機械寸法、物理的な接続部も含まれます。［1］

    同じ出力容量でも、負荷が変わった瞬間の応答や、設備との取り合いが違えば、そのまま置き換えられるとは限りません。「つながる」の中身を、電圧や容量だけでなく、動作条件と設置条件まで具体的にする必要があります。

    発表はv0.3のSST仕様を標準化の出発点として紹介しています。これは、すべてのSST製品が共通仕様へ統一済みという話ではなく、相互運用に必要な条件を固めていく段階です。［1］

    液冷設備は、公開仕様と建物内の配置を合わせて読む

    冷却では、CDU（Coolant Distribution Unit）のProject Deschutesが紹介されています。CDUは、サーバー側の冷却液の循環や、施設側との熱の受け渡しを担う装置です。Deschutesのv1.0は、OCPのCDUプロジェクトでも公開資料として扱われています。［1・3］

    CDUの仕様が共有されても、それだけで建物の冷却設計が決まるわけではありません。サーバーホールの検討図には、CDUやUPS（無停電電源装置）をラック列の中に置く案と、列の外へ分ける案が示されています。機器を置く場所が変われば、IT機器に使える空間や配管・配電の経路も変わります。［1］

    まず必要な熱負荷を見積もり、その流量と接続条件を受けられる設備を選び、保守のための空間まで配置へ戻す。公開仕様は、そのやりとりを具体的にするための共通の土台になります。

    環境負荷も、稼働中の電力だけで終わらせない

    持続可能性の章では、エネルギー、水、熱に加え、設備や建材のライフサイクルも扱っています。非常用電源については、燃料電池や長時間蓄電などを、特定の方式に固定せず性能で評価する方向が示されています。これは試験や評価の取り組みであり、全施設への導入実績を示すものではありません。［1］

    機器を更新しやすいことと、環境負荷が小さいことは同じではありません。更新の頻度、利用できる電力や水、バックアップに求める時間など、施設ごとの条件を合わせて評価する必要があります。

    世代交代の前に、変えられる範囲を決めておく

    この構想の要点は、次のサーバーのために大きな電源と冷却装置を用意することだけではありません。電力の変動を受け止める場所、熱を受け渡す接続、装置を置き換える寸法と動線を、共通の条件として整理することです。

    そうした条件が共有できれば、機器を変えるたびに、どこまで建物側を見直す必要があるかを判断しやすくなります。サーバーを選べる自由度は、その手前にある電源、冷却、空間の設計から生まれる。Googleの提案は、その範囲をデータセンター全体へ広げています。

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

    Alphabetの企業解説を読む

    参考資料

    2026年9月27日確認。

    ［1］Google：The Fungible & Sustainable Data Center: A Blueprint for the AI Era — 2026 OCP APAC Summit公開スライド。構想p.10、電力p.12–18、冷却・配置p.20–24、環境負荷p.30–31。

    ［2］Open Compute Project：Realizing the Open Data Center Ecosystem Vision — 2025年10月13日。Open Data Centerの背景。

    ［3］Open Compute Project：Coolant Distribution Unit — CDUプロジェクトとProject Deschutes v1.0資料。

  • GoogleのCDU「Deschutes」、冷却液を循環させる2MW級装置の保守と試験計画

    GoogleのCDU「Deschutes」、冷却液を循環させる2MW級装置の保守と試験計画

    液冷設備を選ぶとき、まず気になるのは「何kWの熱を扱えるか」でしょう。ただ、データセンターで長く使うには、冷却能力と同じくらい、ポンプを確かめる方法や部品を取り外すための空間も大切になります。

    GoogleのEdward Kung氏が紹介したProject Deschutesは、2MWの熱負荷を仕様表に掲げる液冷用CDUです。2026年2月公開のv1.0では、機械図面や寸法に加え、駆動装置と膨張タンクの整備性、ポンプの信頼性試験が整理されています。冷やせる設備を、保守しながら使い続けられる設備へ近づける設計です。［1］

    簡単にまとめると？

    • Deschutesは2MWを仕様に掲げるCDUですが、冷却能力は流量や配管条件と合わせて読む必要があります。
    • 駆動装置や膨張タンクの交換を想定し、取り外す方向と作業空間まで設計しています。
    • ポンプは運転条件の変化と長期運転を試す計画で、資料は全試験の完了結果を示したものではありません。

    2MWのCDUを、流量と圧力から読む

    CDU（Coolant Distribution Unit）は、サーバー側と施設側の冷却回路の間に置かれ、熱交換や冷却液の循環を担う装置です。Deschutesの構成図には、2台のポンプと3台の熱交換器、フィルター、膨張タンクなどが示されています。サーバー側の液をただ冷たくするのではなく、必要な流れをつくる部品が一つにまとまっています。［1］

    仕様表の熱負荷は2,000kW、IT側と施設側の流量はそれぞれ500GPM、アプローチ温度は3°Cです。GPMは1分あたりのガロン数を表す流量の単位。アプローチ温度は熱交換する二つの回路の温度差を見る指標です。これらはDeschutesの仕様値であり、配管条件や流量が変わっても常に2MWを処理できるという意味ではありません。［1］

    その違いが見えるのが、流量に対する圧力のグラフです。ポンプの回転条件ごとに曲線が分かれ、流量が増えると確保できる圧力も変わります。ラックや配管で生じる圧力損失と、CDUから供給できる流量・圧力を合わせて見る必要があります。熱交換側の表も、一次側と二次側の流量を分けて評価しています。［1］

    交換作業に必要な空間も、設計に含める

    今回の更新では、VFD（可変周波数駆動装置）の取り外しが具体的に描かれています。VFDはモーターの回転を制御する装置です。資料の整備図には、取り外す方向と36インチの作業空間が示されています。寸法上はCDUを置けても、その前を別の機器がふさいでいれば、この作業は難しくなります。［1］

    膨張タンクの図も印象的です。タンクを後方または側方へ振り出せるよう、二つのヒンジ位置を用意しています。タンク単体の収まりだけでなく、設置後にどちら側から手を入れられるかまで考える。こうした整備のしやすさは、冷却能力の数字だけでは見えない部分です。［1］

    仕様には、CDUやリアドア熱交換器と組み合わせる「Redmond」のホットアイル・コンテインメントも含まれます。これはラックからの暖かい排気を通路内に区画する構造です。CDUを単独で置く話から、ラック列や通路との取り合いまで視野が広がっています。［1］

    1年間の連続試験だけでなく、運転条件の変化も見る

    ポンプの試験計画では、入口液温25°Cと55°C、水系冷却液とPG25など、使用条件の幅を扱います。そのうえで、短い起動・減速の繰り返し、二つの運転点の往復、1年間の連続運転という異なる負荷を設けています。［1］

    二つの運転点を使う試験では、110psiの条件で250GPMを5分、500GPMを5分とし、これを500サイクル繰り返します。1年間の試験では500GPM・110psiで運転し、電力、回転速度、圧力などを記録。終了後には分解して摩耗や腐食を調べます。これは資料に記載された試験手順で、すべての試験を完了した結果の報告ではありません。［1］

    同じ2MW級のCDUでも、接続する設備や整備に使える場所、想定する運転の変動は違います。Deschutesの公開資料からは、能力表を出発点に、配管との適合、交換時の動線、長期試験の条件へと確認を進める流れが見えてきます。

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

    Alphabetの企業解説へ

    参考資料

    2026年9月27日確認。

    1. Google「Project Deschutes Update V1.0」 — 2026 OCP APAC Summit公開スライド。仕様p.5、構成p.6、性能p.8–9、整備p.10–12、試験p.13–14、公開時期p.15。
    2. Open Compute Project「2026 OCP APAC Summit」 — 発表者・演題・配布資料の掲載元。
  • Googleが示すPCIe Gen6接続検証、部品のばらつきと他社ケーブルの相性を調べる

    Googleが示すPCIe Gen6接続検証、部品のばらつきと他社ケーブルの相性を調べる

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

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

    簡単にまとめると？

    • 高速PCIe接続は、部品単体の挿入損失だけでなく、ケーブルとコネクターを組み合わせて検証します。
    • 寸法公差の組み合わせを分析し、製造中の測定と他社部品との試験を設計へつなげます。
    • 発表は設計・製造・評価を結ぶ方法の提案で、採用済みの認証制度とは区別する必要があります。

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

    発表の背景には、基板への実装後に分かったコネクターのばらつきと、異なるメーカーのケーブル・コネクターを組み合わせた際の相互運用性の問題があります。ここでいう「非標準」は、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」 — 発表者・演題・配布資料の掲載元。
  • Googleの大容量HDD検証、HSMR・HAMRの記録方式と故障ヘッドの扱い

    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」 — 発表者・演題・配布資料の掲載元。
  • Googleが示すCaliptraのプロビジョニング、製造時に整える識別情報と証明書

    Googleが示すCaliptraのプロビジョニング、製造時に整える識別情報と証明書

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

    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としての位置づけ。

  • 直流配電と液冷の安全設計、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 公開リポジトリ。プロジェクトの公開状況を参照。講演中の将来提供日程とは区別しています。

  • Googleの±400V DC配電案、電源をラック外へ移す狙いと課題

    Googleの±400V DC配電案、電源をラック外へ移す狙いと課題

    はじめに

    Googleの技術チームが提案した次世代の+/-400Vdcラック電源システムは、AIや機械学習（ML）の進化による電力需要増加に対応するための画期的なソリューションです。本記事では、この電源システムの必要性やメリット、課題について、詳細に解説します。

    簡単にまとめると？

    • Googleの提案は、ラック外の整流器と高電圧直流配電を使い、ラック内の空間や配電損失の改善を目指します。
    • 高電圧化には、安全保護、初期費用、関連技術の整備という課題があります。
    • 既存48Vラックと共存するサイドカー設計など、段階的な移行も検討されています。

    電力需要の急増と従来システムの限界

    AI/MLの進化と電力需要

    AIモデルの規模が拡大し、より多くのGPUやASICチップが一つのラックに搭載されるようになっています。その結果、1ラックあたりの消費電力は、数年前の20kWから現在では140kWへと急増しています。

    これに伴い、従来の48V電源システムでは以下の問題が顕在化しています：

    • スペースの競合: 電源システムがラック内のスペースを多く占有し、コンピューティング性能が制限される。
    • 電力密度の限界: 電力密度の成長が追いつかず、次世代システムのニーズに対応できない。
    • 熱と機械的制約: コネクタやバスバーの機械的・熱的限界が電力供給のボトルネックに。

    +-400Vdcシステムの提案

    Googleはこれらの課題を解決するために、以下の特徴を持つ+/-400Vdc電源システムを提案しました。

    高電圧化の利点

    1. 損失の削減: 電圧を上げることで、配電時の電力損失を抑制。
    2. スペース効率の向上: ラック外への電源システムの移設により、内部スペースを最大限活用。
    3. 既存エコシステムの活用: 電気自動車（EV）産業で成熟した400V技術（半導体、コンデンサなど）を流用可能。

    システム構成

    • AC-DC変換を行う整流器をラック外に設置。
    • バッテリーは直流電源に直接接続し、UPS（無停電電源装置）機能を統合。
    • 高効率かつ高密度な400Vdc to 48Vや400Vdc to 12Vのコンバータを使用して負荷に電力供給。

    従来のアーキテクチャとの比較

    以下の表は、従来の48Vシステムと新しい+/-400Vdcシステムを比較したものです。

    項目48Vシステム+/-400Vdcシステム
    電力損失高い低い
    スペース効率制限あり最適化可能
    エコシステムの成熟度高い（既存技術）中程度（EV技術活用）
    導入コスト安価高コスト
    将来性限界が近い高い柔軟性と拡張性

    課題と解決策

    課題

    1. 安全性の確保:
      • 直流（DC）は交流（AC）と比べてアークフラッシュや地絡検出が難しい。
      • 高電圧でのシステム設計には慎重なアプローチが必要。
    2. コスト増加:
      • 初期導入コストや変換モジュールの設計費用が高い。
    3. エコシステムの未成熟:
      • 特に800Vdc以上の電圧システムの構築には、技術革新が必要。

    解決策

    • 商用技術の標準化:
      • ソリッドステートトランスフォーマー（SST）の開発・普及を加速。
      • ラック外の整流器やバッテリーを標準化し、スケールメリットを活用。
    • 安全性向上の設計:
      • ゼロクロッシングのないDC特有の問題を解決するための保護回路を開発。
    • 段階的移行:
      • 現行の48Vラックと新システムを共存させる中間的な「サイドカー」設計の採用。

    データセンターの未来：マイクログリッドとの統合

    マイクログリッドは、次世代データセンター設計において重要な役割を果たします。分散型エネルギー（太陽光、風力、バッテリー）と直流バスを直接接続することで、以下を実現可能です：

    • エネルギー効率の向上: インバータを排除することで変換損失を削減。
    • 信頼性の向上: グリッドの外乱に対する耐性を強化。
    • 持続可能性の確保: 再生可能エネルギーの活用を最大化。

    まとめと今後の展望

    次世代のAI/MLアプリケーションに対応するためには、電力インフラの大幅な見直しが必要です。Googleが提案する+/-400Vdcシステムは、その具体的な一歩として期待されます。

    協業を通じて、次世代データセンターに適したエコシステムを構築することが、業界全体の課題解決と進化に寄与するでしょう。

    企業の事業もあわせて読む

    Googleと親会社Alphabetの事業については、cyclewaveの企業解説で紹介しています。

    cyclewaveでAlphabetの企業解説を読む