Quantum Sea

タグ: OCP APAC 2026

  • OCP APAC 2026 | AI通信の混雑に早く応えるSONiC、経路制御とパケットトリミング

    OCP APAC 2026 | AI通信の混雑に早く応えるSONiC、経路制御とパケットトリミング

    GPUの計算が速くても、通信の一部が遅れると、AIの処理全体を終えるまでの時間が延びます。大きなデータが短時間に集中する場面では、回線の速さに加えて、どの経路を通り、混雑をどれほど早く知れるかが大切になります。

    2026年8月のOCP APAC SummitでMicrosoftとBroadcomが紹介したのは、ネットワークスイッチを動かすソフトウェアSONiCを、AI向けの大規模な通信基盤へ対応させる取り組みです。経路情報を扱うBGPの拡張から、送信元が経路を指定するSRv6、混雑を早く伝えるパケットトリミング、細かな統計収集までをつなげて見ていきます。［1・2］

    少数の大きな通信が、同じ経路へ重なる

    発表が対象とするAIの学習通信には、少数の大きなフロー、短時間に通信が集中するバースト、遅い側の通信時間であるテールレイテンシーへの敏感さという特徴があります。経路の振り分けに使える通信の違いも少なく、大きなフローが同じリンクへ重なると、混雑しやすくなります。［2］

    等しいコストの経路へ通信を振り分けるECMPでも、このような条件では負荷がうまく分散しないと説明されています。経路が複数あることと、実際の通信が均等に流れることは別の問題です。資料の課題設定は、こうしたAI通信の性質を前提にしています。［2］

    接続が増えれば、BGPにも処理能力が要る

    資料では、1ポートあたり100Gbps、スイッチ全体で51.2Tbpsの構成を、複数のネットワーク面へ分けて導入したとしています。接続先が増えると、経路情報を交換するBGPの接続数も増えます。多数のポートを備えるハードウェアを用意すると同時に、それを制御するソフトウェアも拡張する必要があります。［2］

    そこで示されたのが、経路制御ソフトウェアFRRを10.0.1へ更新し、約20件のパッチを加えるSONiCの改善です。512のBGPセッション、約1,000の経路、次の転送先である512のネクストホップを扱う構成が紹介されています。単一ポートの切断・復帰に関する発表結果は、データ転送の停止が0.1秒未満、経路情報の収束が約5秒です。異なる二つの時間を、同じ「復旧時間」としてまとめないことが大切です。［2］

    SRv6で、送信元から通る経路を指定する

    通信の経路選択には、IPv6を使うセグメントルーティングのSRv6が挙げられています。資料の構成では、送信元のネットワークインターフェースカード（NIC）が、経路を表す短い識別子uSIDの列をパケットへ入れます。途中のスイッチが順に処理し、宛先のNICが受け取る仕組みです。［2］

    これにより、送信元が指定した経路をたどらせます。資料では、識別子の列が合わない場合はパケットを破棄する、厳密なソースルーティングを説明しています。経路を指定する仕組みそのものが混雑を自動で解決するわけではなく、どの経路を選ぶかと、途中で起きた混雑へどう応えるかを組み合わせる設計です。［2］

    パケットを短くして、混雑の知らせを先へ送る

    パケットトリミングは、混雑時に対象のパケットを短くし、宛先へ送る仕組みです。受信側のNICは、正常に受け取れなかったことを伝えるNACKを送信元へ返します。送信元は、その知らせを受けてパケットを再送し、送る速度を落とします。大きなデータを運び続ける代わりに、小さくしたパケットを早い通知につなげます。［2］

    資料の図では、通信の種類やヘッダー、サイズでトリミングの対象を選び、通常のデータ用とは別に、優先度の高い待ち行列と専用バッファーへ入れています。多数の送信元から一か所へ通信が集中するインキャストに対応するため、短くしたパケットをためる領域の容量も検討項目です。［2］

    発表では、優先度ごとに通信を一時停止するPFCや、パケットに混雑を知らせる印を付けるECNだけでは、このバースト性の高い通信に十分すばやく対応しにくいと説明しています。特にPFCの停止が周囲へ広がると、処理完了までの時間が延びる点を挙げています。PFCやECNがあらゆるネットワークで使えないという意味ではなく、ここで想定する通信に、より早いフィードバックを求める議論です。［2］

    ミリ秒単位の観測を、運用のデータへつなぐ

    短い混雑を調べるには、観測の間隔も細かくする必要があります。そこで紹介された高頻度ストリーミングテレメトリー（HFST）は、スイッチの統計をミリ秒単位で収集するための仕組みです。ASICがIPFIX形式で計測情報を送り、SONiC側のCounter Syncdが受け取って読み解きます。［2］

    受信した情報は、登録済みのIPFIXテンプレートに従って解析します。対応するテンプレートがなければ、そのメッセージは破棄されます。得られたカウンターは手元のデータベースへ保存でき、OpenTelemetry形式へ変換して収集・処理の仕組みへ渡すこともできます。細かく測るだけでなく、正しく解釈して保存するところまでを一つの経路として考えています。［2］

    実装の報告と、次に取り組む範囲を分けて読む

    発表は、BGPの拡張結果と、SRv6・トリミング・テレメトリーの設計を並べて紹介しています。設計資料へのリンクもありますが、これだけで、すべてのSONiC製品や導入先に同じ機能がそろっているとは判断できません。利用するASICやNIC、ソフトウェアの実装を合わせて見る必要があります。［2］

    今後の取り組みとしては、アクセラレーター同士を密に結ぶスケールアップ向けEthernetも挙げられています。今回の大規模なスケールアウト網を支える改善と、その先の検討範囲は分けて捉えたいところです。経路を制御し、混雑を早く伝え、その状態を細かく観測する。SONiCの役割は、この三つをハードウェアと運用の間でつなぐことにあります。［2］

    MicrosoftとBroadcomについて

    発表に登壇したMicrosoftとBroadcomの事業全体は、cyclewaveの企業解説で紹介しています。

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

    参考資料

    2026年8月の発表資料をもとに構成。性能値と課題は、資料で示された構成・通信条件に関する説明です。

    1. Open Compute Project「2026 OCP APAC Summit」 — 公式イベント・発表資料一覧。
    2. Microsoft・Broadcom「How SONiC Powers the World’s Largest AI Infrastructure」 — Guohan Lu、Mehak Mahajan。pp.4〜11：AI通信、BGP、SRv6、パケットトリミング、HFST。pp.12〜14：設計資料と今後の取り組み。
  • OCP APAC 2026 | GoogleとBroadcomのSONiC検証、AVSとTH6 BCMSIMをつなぐ

    OCP APAC 2026 | GoogleとBroadcomのSONiC検証、AVSとTH6 BCMSIMをつなぐ

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

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

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

    講演が挙げる課題は、スイッチが高価で、開発者と自動テストが同じ試験設備を共有しやすいことです。接続できる台数が限られれば、大きなネットワーク構成も試しにくくなります。新しいチップでは、そもそも実機がまだ用意できない段階から、ソフトウェアの開発が進みます。［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」。開催日・登壇者・公開資料の案内。記事は公開スライドをもとに構成しています。

  • OCP APAC 2026 | AIチップの電源を確かめる、試験用インターポーザーと負荷の自動掃引

    OCP APAC 2026 | AIチップの電源を確かめる、試験用インターポーザーと負荷の自動掃引

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

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

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

    まず確認するのは、チップの電源仕様です。資料は、電源系統である電源レールごとに、定常時と変動時の電圧条件、リップルと呼ばれる電圧の細かな揺れ、電流が変化する速さを確認するよう求めています。この変化の速さがスルーレートです。同じ最大電流でも、ゆっくり増える場合と急に増える場合では、試す条件が異なります。［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：共通化と仕様公開の計画。
  • OCP APAC 2026 | MicrosoftのDiablo 400、800V給電を負荷変動・停電まで検証

    OCP APAC 2026 | MicrosoftのDiablo 400、800V給電を負荷変動・停電まで検証

    AIラックの電源は、負荷が短時間で変わるときにも、交流入力が失われるときにも、必要な電力を届け続けることが求められます。複数の電源装置や蓄電装置を組み合わせるほど、装置同士が切り替わる瞬間や、故障から復帰する順序までが大切になります。

    2026年8月のOCP APAC SummitでMicrosoftが示したのは、高電圧直流（HVDC）を使うDiablo 400のシステム検証です。個々の部品から一つのラック、さらに複数ラックへと範囲を広げ、負荷変動・電源喪失・保護動作を確かめる考え方が紹介されています。［1・2］

    ±400V/800Vの電源構成を、ITラックと分けて考える

    発表の前提は、電源をITラックから切り離して配置する、±400V/800VのHVDC電源ラックです。目標として挙げられる電力密度は、ITラックあたり約1MW。これは資料が示す設計上の目標値であり、この発表で達成済みの運転性能を示す数値ではありません。［2］

    電源を分けると、電力の変換を担うPSU、蓄電と給電の切り替えに関わるCBU、電力を分配するPDU、電流を流す母線（バスバー）を、ラックをまたぐ一つのシステムとして扱う必要があります。資料は、電気的な乱れがこれらの装置やIT側の負荷へ伝わり得る点を、検証の出発点に置いています。［2］

    L10・L11・L12で、確かめる範囲を広げる

    Microsoftの検証フレームワークは、三つの段階に分かれています。資料中のL10・L11・L12は、今回の検証範囲を区別する呼び方です。［2］

    段階検証する範囲主な対象
    L10構成部品PSU、CBU、PDU、バスバーなどの個別の適合性
    L11単一ラック給電、電源異常時の運転継続、故障の切り離し
    L12複数ラックを含むシステム製品構成や実際のワークロードを踏まえた相互動作

    たとえば、PSU単体が試験に合格していても、それを複数台並べ、別のラックへ給電したときの応答まで同じとは限りません。部品の結果を土台にしながら、配線や蓄電装置、負荷を組み合わせた状態へ確認を進める。その順序が、この三段階の役割です。

    負荷の大きさに加え、変化の速さと繰り返しを試す

    電気的な検証では、入力電源の振る舞い、直流出力の安定性、効率などに加えて、急な負荷変動への応答を調べます。資料に挙がるのは、高い頻度で繰り返す負荷ステップ、大きな過渡変動、電圧のオーバーシュート・アンダーシュートです。目標値から一時的に上へ外れるか、下へ外れるかを含め、変化の最中を見ます。［2］

    ここで気を付けたいのが、複数の電源モジュールの電流分担（Ishare）です。発表は、急激な負荷変化の初期には制御の応答が追い付かず、分担が崩れるリスクを挙げています。試験設備を含む配線の電気的特性も応答へ影響し、負荷を変化させる周波数によっては共振が生じ得る、としています。［2］

    そのため、一定の負荷を一度かけるだけでは見えない振る舞いがあります。負荷の変え方や繰り返しの周波数をそろえ、電気計測とテレメトリーを突き合わせる。テレメトリーは装置から取得する状態情報ですが、資料はその測定誤差を抑えるため、事前の校正も重視しています。［2］

    交流入力の喪失から復帰まで、PSUとCBUの連携を見る

    電源が一時的に乱れたとき、給電を維持して運転を続ける能力はライドスルー（ride-through）と呼ばれます。今回のCBUの検証は、交流入力の喪失、復帰、給電の切り替えを、一連のシナリオとして扱います。［2］

    対象には、蓄電と電力の受け渡し、蓄電状態のバランス、負荷変動の平滑化、PSUとCBUの相互動作が含まれます。蓄電装置があることに加え、電源が失われたときにどう引き継ぎ、戻ったときにどう通常の状態へ移るかを確かめるわけです。資料はこうした検証項目を示していますが、運転を維持できる時間の保証値は示していません。［2］

    保護動作は、止める範囲と復帰の振る舞いまで確認する

    安全性の検証でも、構成部品、ラック、複数ラックという段階を使います。接地、絶縁、保護機能を調べ、故障を模擬的に与える故障注入試験によって、停止と復帰の振る舞いを確認する方針です。装置が残す状態情報やイベントの記録も、想定した応答との照合に使います。［2］

    資料は、高いインピーダンスを使う接地方式や、保護接地（PE）の接続を、複数ラック構成で注意する点に挙げています。ここから読み取れるのは、ラックの内側だけで安全を完結させず、接続先も含めて故障の影響を追う必要があるということです。特定の接地方式を、すべての設備へそのまま適用するための説明ではありません。［2］

    「100％」は、試験で扱う範囲を広げる目標

    発表はシステム統合検証の100％カバレッジを目標に掲げ、標準化された試験、設計固有の条件、実際の使い方を組み合わせています。この100％は、故障が起きない確率や、すでに達成した検証結果を表すものではありません。対象に選んだ構成とシナリオを、どこまで試験で扱うかという計画の話です。［2］

    800Vの電源構成を読み解くときは、容量や変換効率と一緒に、負荷変動、給電の切り替え、故障時の停止と復帰にも目を向ける。Microsoftの発表は、それらを部品からシステムへ順に積み上げて確かめる道筋を示しています。

    Microsoftの事業をもう少し知る

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

    Microsoftの企業解説を読む

    参考資料

    2026年8月11〜12日開催のOCP APAC Summitの公式掲載資料を使用し、2026年9月28日に保存済みスライドの全16頁を確認しました。検証の対象・方針と、性能の実測結果を分けて記述しています。

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

    ［2］Microsoft「Validating HVDC AI Rack Platforms with Complex Architecture: Diablo 400 System」公式掲載スライド。電源構成と目標はp.4、検証の段階と計画はpp.5–6、電気・ライドスルー・保護の検証はpp.9–11、リスクと校正はp.12、検証範囲を広げる提案はpp.13–15。公式一覧では「Validating High-Power AI Rack Platforms with complex architecture: Lessons from Mt. Diablo 400 System Qualification」として掲載されています。

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

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

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

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

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

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

  • OCP APAC 2026 | AI基盤を結ぶEthernet、ラック内・ラック間・拠点間で変わる役割

    OCP APAC 2026 | AI基盤を結ぶEthernet、ラック内・ラック間・拠点間で変わる役割

    AIの計算機をつなぐネットワークには、違う距離と役割の接続が重なっています。近くのアクセラレーター同士が細かなデータをやり取りする接続と、離れたデータセンターへ通信を運ぶ接続では、同じEthernetを使っていても、考えるべきことが変わります。

    2026年8月のOCP APAC Summitで、BroadcomのMohan Kalkunte氏は、こうしたAI基盤の接続を、スケールアップ、スケールアウト、スケールアクロスの三つに分けて説明しました。発表には、ラック内の通信規約から、多経路でデータを運ぶMRC、拠点間ネットワークまでが登場します。［1・2］

    近くの計算機と結ぶ、たくさんの計算機へ広げる

    この発表でのスケールアップは、アクセラレーター同士を密に結び、まとまった計算資源として使うための接続です。資料の出発点となる図では、ラック内の接続として描かれています。

    スケールアウトは、複数のラックにまたがる計算ノードをつなぎ、AIクラスターを広げる接続です。さらに、別のデータセンターにある計算資源へつなぐ領域を、スケールアクロスとして扱っています。［2］

    ただし、ラックの内か外かだけで、厳密に区切れるわけではありません。資料は光接続の取り組みとしてOCI（Optical Compute Interconnect）も紹介し、スケールアップを複数ラックや複数列へ広げる方向を示しています。物理的な距離に加えて、どのように計算資源を結びたいかを見るための分類です。

    共通のEthernetの上で、何をそろえるか

    スケールアップの説明では、ESUNとSUE-Tが並んで登場します。どちらもEthernetをAI計算向けに使うための取り組みですが、資料の構成図では受け持つ層が違います。［2］

    ESUNは、小さなメッセージを効率よく運び、複数のスイッチを経由する構成にも対応するための、Ethernet側の仕組みを扱います。信頼性の高い通信や、混雑時の制御が、その土台に置かれています。

    SUE-Tは、その上でアクセラレーター間のデータやメモリー操作を運ぶ、トランスポートの役割を担います。図では、共通のEthernetの物理層・データリンク層の上に、SUE-Tとほかのトランスポートが並んでいます。共通の配線やスイッチ基盤を使うことと、上位の通信方式まで同じであることは、分けて考える必要があります。

    運用するためのソフトウェアも関わります。資料は、スイッチOSのSONiCと、スイッチ機能をソフトウェアから扱うSAIについて、仕様、実装、検証を進める項目を紹介しています。オープンな仕様があるだけでなく、実際の機器でどこまで実装され、組み合わせて確かめられているかが重要になります。［2］

    多くの計算ノードへ広げるなら、経路の使い方も変える

    スケールアウトでは、通信量が増えるにつれて、一部の経路へ負荷が偏ることが問題になります。高速なスイッチを入れても、使われていない経路が多ければ、ネットワーク全体の余力を使い切れません。

    そこで紹介されているのが、MRC（Multipath Reliable Connection）です。資料ではRoCEv2を拡張する仕組みとして位置づけられています。RoCEv2は、Ethernet上のIPネットワークを通して、離れた計算機のメモリーへ効率よくデータを転送するRDMAを扱う方式です。［2］

    MRCは、パケット単位で通信を複数の経路へ振り分けます。経路が分かれると、送った順番と届く順番が入れ替わることがあります。そのため資料では、順不同のデータ配置と、届かなかった部分だけを送り直す選択的再送を、経路の制御や混雑の制御と組み合わせています。［2］

    道を増やすだけでなく、順序の違いや欠落を受け止められるようにする。スケールアウトの通信を考えるときには、ポート速度とあわせて、データが届くまでの振る舞いを見る必要があります。

    拠点をまたぐと、距離と保護も設計に入る

    スケールアクロスの領域では、拠点間を結ぶ通信の制御に加え、暗号化による保護も扱われています。資料はJericho4を使う構成を例に、広いネットワークの端から端までを対象とした混雑制御を挙げています。［2］

    拠点間では、通信が物理的な距離を移動する時間も必要です。資料にある大規模構成の説明を、遠くの計算機をラック内と同じ遅延で使える、という意味には読めません。どの処理を近くにまとめ、どの処理を拠点の外へ広げるかは、ワークロードと通信の特性をあわせて考えることになります。

    この発表から見えてくるのは、Ethernetという共通の土台の上にも、役割に応じた設計があることです。近い計算資源を密に結ぶこと、多くの計算ノードへ広げること、拠点間をつなぐこと。それぞれに必要な通信方式と運用の仕組みを確かめると、AIネットワークの構成を整理しやすくなります。

    発表企業の事業を知る

    Broadcomのネットワーク半導体と、そのほかの半導体・ソフトウェア事業については、cyclewaveの企業解説から読めます。

    Broadcomの企業解説を読む

    参考資料

    2026年9月27日確認。仕様や実装の状況は、2026年8月の講演資料に基づきます。

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

    ［2］Mohan Kalkunte／Broadcom「Open Ethernet Fabrics for AI Training and Inference」公式掲載スライド。接続の分類はp.3、ESUN・SUE-T・OCIとソフトウェアはpp.5–7、MRCはpp.11–12、拠点間の構成はp.14。

  • OCP APAC 2026 | Broadcomの3.5D実装、接続密度と熱設計の両立

    OCP APAC 2026 | Broadcomの3.5D実装、接続密度と熱設計の両立

    AI向けのチップは、計算する回路だけでなく、データを出し入れする回路やメモリーとの接続にも、大きな面積を使います。必要な機能を横へ広げていくと、チップやパッケージの大きさが制約になってきます。

    そこで、横に並べる構成へ、上下に重ねる構成を組み合わせる。2026年8月のOCP APAC SummitでBroadcomのHarish Bharadwaj氏が紹介した3.5D Heterogeneous Scale-Inは、そうした立体的な実装の考え方です。計算回路とキャッシュなどを別の半導体ダイに分け、積み重ねたうえで、HBMや入出力用のチップレットとつなぎます。［1・2］

    横に並べる2.5Dと、上下に重ねる3Dを組み合わせる

    半導体のダイは、ウエハーから切り出した回路の単位です。複数の機能を小さなダイに分け、組み合わせて使うものを、チップレットと呼びます。

    資料の3.5D構成では、計算用のダイを上段へ置き、下段へキャッシュとNoCを配置しています。NoC（Network-on-Chip）は、チップ内の回路同士を結ぶ通信網です。機能ごとに異なる製造プロセスを組み合わせることも、設計に含まれています。［2］

    この積層されたダイ群を、配線を仲介するインターポーザー上で、HBMや入出力用のチップレットと横につなぎます。HBMは高い帯域幅でデータをやり取りする積層メモリーです。計算ダイの下にすべてを重ねるのではなく、上下の接続と、隣り合うダイ間の接続を使い分けています。［2］

    ここでの「3.5D」は、資料がこの組み合わせを表すために用いている呼び方です。数字が大きいほど一律に高性能になる尺度ではありません。どの機能を積み、どの機能を横へ置くかを見ると、構成の意味がつかみやすくなります。

    回路面を向かい合わせると、接続の密度が変わる

    上下のダイをつなぐ方法として、資料はFace-to-BackとFace-to-Faceを比較しています。「Face」は回路のある面、「Back」はその裏面です。前者は回路面と裏面を、後者は二つの回路面を向かい合わせて接合します。［2］

    Face-to-Backの例では、TSV（シリコン貫通電極）を通して信号をつなぎます。資料は、その間隔による接続密度の制約と、電気的な負荷を課題として挙げています。細かな回路同士を上下へ分けても、その間を十分な本数で結べるかが重要になるわけです。

    一方、Face-to-Faceの例では、回路面同士のハイブリッド接合によって、より細かい間隔で信号を結んでいます。資料に示された信号接続密度は、Face-to-Backで約1,500本/mm²、Face-to-Faceで約14,000本/mm²です。これは二つの構成例における接続の密度であり、計算性能が同じ比率で高まるという数字ではありません。［2］

    接続を密にできれば、上下に分けた回路間でデータをやり取りしやすくなります。ただし、Face-to-FaceだからTSVを一切使わない、ということではありません。資料の断面図には、電力供給側などに貫通電極が残っています。

    近づけた回路の熱を、どう逃がすか

    回路を重ねると、データを近い場所でやり取りできる一方、熱の設計も立体的になります。上段と下段のどちらに発熱の大きい回路を置くかによって、温度分布が変わるためです。

    資料は、上下のダイに配置する回路ブロックの組み合わせを変え、熱モデルを使って検討する流れを示しています。設計の早い段階から試作と照合を進め、実際のシリコンでの結果をモデルへ反映していく考え方です。［2］

    電力の届け方も同時に考えます。回路の集積が進んでも、必要な電流を十分に供給できなければ動作は安定しません。資料では、貫通電極や電源配線の配置に加え、電圧降下と、電流密度に伴う信頼性の問題を扱っています。

    冷却を後から付け足すのではなく、回路の配置、電源の経路、熱の逃げ道を一緒に決める。その必要性が、積層の構成から見えてきます。

    二つのダイを、一つの時間軸で動かす

    上下に重ねても、ダイは別々につくられます。製造ばらつき、電圧、温度の違いによって、信号が届くタイミングも変わります。近くに置けば、それだけで同期の問題が解消するわけではありません。

    資料では、ダイ間で信号を同期させる方法や、条件の組み合わせごとのタイミング検証を、設計上の課題に挙げています。さらに、複数のダイと接合工程を組み合わせるため、全体として良品を得られる割合、つまり歩留まりも考慮する必要があります。［2］

    3.5Dの狙いは、限られたパッケージの中で、より多くの回路を効率よくつなぐことです。ただ、それを成立させる条件は、接続密度だけではありません。熱を逃がし、電力を届け、信号のタイミングをそろえ、製造できる構成へ落とし込む。上下に広がった設計では、これらを一緒に見ることが大切になります。

    発表企業の事業を知る

    Broadcomのカスタム半導体やネットワーク半導体を含む、会社全体の事業についてはcyclewaveで紹介しています。

    Broadcomの企業解説を読む

    参考資料

    2026年9月27日確認。接続密度などの数値は講演資料の構成例に基づき、製品全般の性能を表すものではありません。

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

    ［2］Harish Bharadwaj／Broadcom「3.5D Heterogeneous Scale-In」公式掲載スライド。全体構成はp.5、接合方式と接続密度はpp.6–7、実装・タイミング・熱と電源の課題はpp.8–10。

  • OCP APAC 2026 | Googleが示す2MW級CDU「Deschutes」、交換とポンプ試験の設計

    OCP APAC 2026 | Googleが示す2MW級CDU「Deschutes」、交換とポンプ試験の設計

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

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

    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」 — 発表者・演題・配布資料の掲載元。
  • OCP APAC 2026 | Microsoftの検証AI、テスト生成と不具合分類をつなぐ

    OCP APAC 2026 | Microsoftの検証AI、テスト生成と不具合分類をつなぐ

    サーバーの不具合は、ハードウェア、ファームウェア、ソフトウェアのどれか一つに、きれいに分かれて現れるとは限りません。温度の変化、装置側のログ、ソフトウェアのエラーを別々に見ていると、同じ問題を何度も調べたり、必要な試験へたどり着くまでに時間がかかったりします。

    MicrosoftがOCP APAC Summitで示したのは、テスト生成と不具合分類を、層をまたぐ計測情報でつなぐ検証AIです。試験項目を一度作って終えるのではなく、結果や過去の不具合を次の検証へ戻す仕組みとして、自律検証エージェントを位置付けています。［1・2］

    ログを並べるだけでなく、次の試験へつなぐ

    資料の検証ループは、ソフトウェアの不具合情報、ファームウェアのログ、ハードウェアのテレメトリーを入力にします。異常を見つけたら、その装置の条件に合う試験を起動し、過去の似た故障と関連付けて、原因を絞っていく流れです。［2］

    例として、ハードウェアとファームウェアの情報にメモリーエラーが現れた場合、ストレステストを実行し、過去の類似障害と照合する構成が描かれています。「エラーが出た」と記録するだけでなく、次に何を確かめるかまでつなぐ点が特徴です。［2］

    もちろん、同じようなログが出ていても、原因が同じとは限りません。似た事例は調査の手がかりであって、それだけで原因が確定するわけではないため、試験結果と人の判断を戻す経路も必要になります。

    TestGen.AIとBugEval.AIの役割

    資料では、検証シナリオを作るTestGen.AIと、不具合を評価・分類するBugEval.AIが示されています。意味の近い情報を探す検索や、過去の不具合のまとまりを使い、その時点で優先すべき試験や問題を選ぶ考え方です。［2］

    ここで大事なのは、過去に用意した試験だけを引き継ぐのではなく、前の世代で見逃した不具合も、次の世代の試験へ反映することです。資料は、過去世代の故障パターンを調べ、試験と変更提案を作る流れを示しています。［2］

    Microsoftの関連ブログも、こうしたエージェントを社内の検証・プラットフォーム開発で使う仕組みとして説明しています。公開資料に名前が出ていることと、そのまま利用できる一般向け製品であることは別です。［3］

    CPUの温度保護を、生成から再試験までたどる

    具体例は、CPUのサーマルトリップ点、つまり温度保護が作動する条件の検証です。まずTestGen.AIが試験を生成し、実行を統括するオーケストレーターが対象のハードウェアへ割り当てます。装置で負荷を動かし、温度の計測情報を集めます。［2］

    次にBugEval.AIが、集まった情報を判定条件と照合し、合否と診断に役立つ情報を返します。不合格なら、その結果を使って試験を調整し、再試験へ進みます。試験生成、実行、計測、評価を、ひと続きに扱う構成です。［2］

    この資料には、具体的な温度閾値や負荷条件までは示されていません。ここで示されているのは検証の組み立て方であり、個々のCPUで保護機能を試すための操作手順ではありません。

    試験を減らすときは、見逃しを増やしていないかを見る

    資料は、サンプルデータセットで重複する試験の実行を30％減らしたとしています。一方、検証サイクル全体を40％短くするという数字には、予測値と明記されています。評価対象の規模や詳細な比較条件も、このスライドだけでは分かりません。［2］

    試験の数や時間が減るだけでは、品質が良くなったとは判断できません。必要な不具合を引き続き見つけられるか、過去に見逃した条件を追加できたか、誤った分類が増えていないかも合わせて見る必要があります。これは、資料の効率改善を実際の検証へ持ち込むときの確認点です。

    変わりやすいハードウェア構成やファームウェアの条件を、試験結果と一緒に残すことも欠かせません。前の環境で役立った試験が、次の環境でも同じ意味を持つとは限らないからです。

    人の判断を残しながら、検証のつながりを短くする

    資料のループには、人が結果を確認し、学習へ戻す段階が含まれています。AIが情報を集め、似た不具合を整理し、試験の候補を用意する。その先の設計判断まで、根拠が追える状態にしておく構成です。［2］

    検証AIの価値は、試験を自動で増やすことだけではありません。過去に分かったことを、いま必要な試験へ結び直すことにあります。ハードウェアとソフトウェアを一緒に設計するなら、検証もまた、それぞれの情報をつないで進める必要があります。

    Microsoftの事業をもう少し知る

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

    Microsoftの企業解説を読む

    参考資料

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

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

    ［2］Microsoft：Embedding Intelligence into Hardware-Software Co Design Through Autonomous Validation Agents（講演スライド）

    ［3］Microsoft：Driving Efficiency in Modern System Engineering with AI Agents

  • OCP APAC 2026 | MicrosoftのAFPD、ディスク故障の予測を検証と保守につなぐ

    OCP APAC 2026 | MicrosoftのAFPD、ディスク故障の予測を検証と保守につなぐ

    データセンターで使うディスクは、同じように見えても、機種やファームウェア、使われ方が違います。故障の前に現れる兆候も一つではありません。すべてに同じ閾値を当てはめると、見逃す異常と、故障ではないのに拾ってしまう変化の両方が生まれます。

    Microsoftが紹介したAFPD（Azure Failure Prediction and Detection）のディスク向けの仕組みは、こうした違いを前提にしています。機種と故障種別に合わせた予測モデルを用意し、その予測を確かめてから、保守へつなぐ構成です。［1・2・3］

    ディスクの内側と、周囲の動きを合わせて読む

    手がかりは、ディスクが持つ健康状態の情報だけではありません。資料ではSMARTなどの内部テレメトリーに加え、システム側のI/Oやイベント、エラーログ、温度や湿度などの環境情報を合わせています。テレメトリーは、運用中の状態を継続して集めた計測情報です。［2］

    単発の値を見るだけでなく、前回からの差分や変化の傾向、一定期間をまとめた統計量を特徴量にします。たとえばエラーの増え方を扱うには、その時点の件数だけでは足りません。いつ、どのように変わってきたかを、モデルが比較できる形に整える必要があります。［2］

    さらに、ディスクが完全に利用不能になった後の記録だけで学習するのではなく、本番の故障検知やシステムログから、より早い段階の不具合をラベルに使います。故障を知らせる時点を、利用者への影響が出る前へ近づける考え方です。［2］

    機種と故障種別の組合せに、モデルを用意する

    この仕組みの軸は、ドライブの機種 × 故障種別ごとにモデルを持つことです。機種が変われば使える信号も変わり、故障の種類が変われば、重視する特徴や判定の閾値も変わります。［2］

    そのため、一つの大きなモデルの成績だけで運用を判断するのではなく、それぞれのモデルを学習し、検証し、更新できる構成にしています。ある故障を拾うルールが有効でも、それだけで別の故障まで見つかるとは限らないからです。

    正解率だけで、使える予測とは決めない

    故障がまれなデータでは、多くを「正常」と答えるだけでも、全体の正解率は高く見えます。運用で知りたいのは、故障と判断したものがどれだけ本当だったか、そして実際の故障をどれだけ拾えたかです。

    前者が適合率に当たる指標、後者が再現率（Recall）です。資料はHITを「検知したうち実際に正しかった割合」と定義し、HITと再現率が閾値を満たすかを、本番導入の判断に使っています。見逃しを減らすことと、不要な対応を増やさないことを、両方確かめるためです。［2］

    学習段階の受入基準として、正解率90％超、適合率75％超、再現率70％超、F1スコア70％超も示されています。これらはモデルを受け入れる基準であり、すべての機種で達成した実績値ではありません。［2］

    予測だけを動かしてから、保守へつなぐ

    本番へ広く展開する前には、予測を日次で評価しながら、実際の運用操作は起こさない検証段階を置きます。過去の故障結果と照らし合わせ、HITと再現率が基準を下回れば、学習や特徴量の見直しへ戻ります。［2］

    導入後も、少数の対象で先に動かすカナリア展開などを使い、段階的に適用します。誤検知や見逃しを追い、ハードウェアやファームウェアの変化によって予測が合わなくなれば再学習する。モデルは作って終わりではなく、運用に合わせて保つ対象です。［2］

    生成AIの説明と、設備を動かす判断を分ける

    発表の後半では、既知の故障を捉えるルール、機械学習モデル、原因分析を助けるAIエージェントを重ねる構成へ話が広がります。大規模言語モデル（LLM）は、証拠をまとめたり、原因の候補や対応案を整理したりする役割です。［2］

    ここで明示されているのは、LLMの出力だけを根拠に、設備群への操作を実行しないという境界です。不可逆な操作には、定めた方針による承認や人の確認を必要とし、実行の根拠、確信度、結果を残します。［2］

    新しい自動対応も、過去データによる評価、操作をしない観察運転、限定した本番適用という順に進めます。予測を当てる技術と、予測に基づいて安全に動く技術は、つながっていても同じではありません。［2］

    故障を早く知る価値を、運用で確かめる

    AFPDのディスク向け発表から見えてくるのは、予測モデルだけを高度化する設計ではありません。機種ごとの信号を整え、見逃しと誤検知を確かめ、影響の小さい範囲から保守へつなぐ。その連続した手順が、予測を使えるものにします。

    故障の兆候を早く知れれば、対応を選ぶ時間ができます。その時間を役立てるには、どの予測を、どの条件で、どの操作へつなぐかまで決めておくことが大切です。

    Microsoftの事業をもう少し知る

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

    Microsoftの企業解説を読む

    参考資料

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

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

    ［2］Microsoft：AFPD Disk Failure Prediction and Detection and AI Transformation（講演スライド）

    ［3］Microsoft：Azure Failure Prediction & Detection の概要（2025年11月4日）