Quantum Sea

タグ: OCP

  • MicrosoftのAIエージェントによるサーバー検証、試験生成から不具合分類へ

    MicrosoftのAIエージェントによるサーバー検証、試験生成から不具合分類へ

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

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

    簡単にまとめると？

    • Microsoftの検証AIは、装置の計測情報やログを、試験の生成・実行・不具合分類へつなぐ仕組みです。
    • 過去の不具合と人の確認を次の試験へ戻しますが、似たログだけで原因を確定するわけではありません。
    • 重複試験の削減はサンプルデータでの結果で、検証全体の短縮は予測値として区別されています。

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

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

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

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

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

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

    簡単にまとめると？

    • AFPDは、ディスクの機種と故障種別ごとに予測モデルを用意します。
    • 予測を先に評価し、誤検知や見逃しを確かめながら段階的に保守へつなぎます。
    • LLMの出力だけで設備を動かさず、不可逆な操作には方針に基づく承認や人の確認を置きます。

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

    手がかりは、ディスクが持つ健康状態の情報だけではありません。資料では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日）

  • 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」 — 発表者・演題・配布資料の掲載元。
  • AIクラスターのリファレンス設計、400G空冷と開発中の800G液冷を比べる

    AIクラスターのリファレンス設計、400G空冷と開発中の800G液冷を比べる

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

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

    簡単にまとめると？

    • OCPの公開設計は、AI計算機だけでなく、通信・ストレージ・配線・管理までを一つの構成として扱います。
    • 計算用と管理用の通信には違う役割があり、統合する場合も復旧や運用の経路を考える必要があります。
    • 発表時点で400G・空冷構成は公開済みですが、800G・液冷構成は変更を見込む開発中の案です。

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

    ここでいうリファレンスアーキテクチャーは、構成を検討する際の参照設計です。資料では、計算、ネットワーク、ストレージ、接続トポロジー、管理基盤を、その対象に挙げています。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。

  • 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」 — 発表者・演題・配布資料の掲載元。
  • Microsoftの液冷バスバー案、大電流を運ぶ導体の小型化と漏れ対策

    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（講演スライド）

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

    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」。英語からドイツ語へのニューラル機械翻訳。

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

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

    公開仕様から製品選びへ、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

  • MicrosoftとBroadcomが示すMRC、通信を複数経路へ分け不足分だけ再送する

    MicrosoftとBroadcomが示す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の概要とセグメントの定義。