Quantum Sea

タグ: OCP

  • Microsoftの電力テレメトリー提案、単位と測定範囲をそろえる

    Microsoftの電力テレメトリー提案、単位と測定範囲をそろえる

    同じ「100」という電力値でも、二つのサーバーで意味が同じとは限りません。片方は100ワット、もう片方は100ミリワットかもしれません。CPUだけを測った値と、装置全体を測った値かもしれません。数値を並べる前に、何を、どの単位で、どの範囲から測ったかをそろえる必要があります。

    2026年8月のOCP APAC Summitで、MicrosoftのSmitha Kashyap C氏らは、異なる機器から集める電力テレメトリーに共通の意味を持たせる案を発表しました。センサーを一種類に統一する話ではありません。機器ごとの値を、あとから比べて使える形へ写すための設計です。［1・2］

    簡単にまとめると？

    • Microsoftの案は、機器ごとの電力測定値に共通の項目名・単位・対象範囲を与える仕組みです。
    • 電力とエネルギーを区別し、値を比べる際は測定時刻や平均化期間も確かめます。
    • 示された共通スキーマや対応表は提案であり、OCPの批准済み仕様や全社の実装済み対応表ではありません。

    名前が似ていても、測っている量を確かめる

    電力テレメトリーは、CPU、メモリー、SSD、電源装置などから運用中に得る測定値です。原資料は、メーカーごとに項目名や単位、電力上限の定義が異なるため、機種を増やすたびに集計用の変換が必要になると説明します。［2］

    ここでは名称だけをそろえても足りません。電力はある時点や短い区間の消費の速さで、単位はワット（W）。エネルギーは時間を通じて使った量で、単位はジュール（J）です。資料の例にある「cpu_power」と「package_energy」は、名前だけで同じ指標とはみなせません。測定範囲もCPUのコア、パッケージ、サーバー全体で違います。［2］

    元データ、意味づけ、使う側の三層

    発表は仕組みを三層に分けます。第一層はCPU内部のカウンター、ファームウェアのセンサー、NVMeのログなど、機器が実際に出す値。第二層は、その値に共通の項目名、単位、対象範囲、閾値、版を与える意味づけのスキーマ。第三層は、監視画面、分析、ジョブ配置など、値を使う側です。［2］

    たとえば「pkg_energy_j」なら、パッケージのエネルギーをジュールで表す項目だと分かります。資料のSSD例は1秒間の平均電力です。単位と測定対象の範囲をそろえることは比較の土台ですが、実測値を読み比べるなら時刻や平均化期間も要ります。発表の第二層の要素表には、その時間条件を表す独立項目は示されていません。また、異機種の写像表は提案の見本です。対応する各社の元データが同じ範囲を測り、同じセンサーとして実装されていることまで証明するものではありません。［2］

    集める経路と、値の意味は別

    機器の中からOSが読むインバンドの値もあれば、管理用の経路を通るサイドバンドの値もあります。発表はRedfishやPLDM/MCTPなど既存の管理・伝送の仕組みとの接続を示します。しかし、値を運べることと、その値が同じ測定対象・単位を指すことは別です。どの経路で受け取っても、第二層で意味を確かめる必要があります。［2］

    同じ定義で値を集められれば、異機種をまたぐ監視や、電力の余裕を見たジョブ配置を考えやすくなります。資料は仕事ごとの消費エネルギー推定や炭素排出の集計も将来の利用先に挙げています。ただし、共通スキーマの提案だけで、個々の仕事の消費量が正確に測れると実証したわけではありません。計測の時間間隔、共用部の電力、推定方法は別に検証が要ります。［2］

    提案の図と、承認された仕様を分ける

    スライドは第二層を「OCP Semantic Schema」と呼び、共通のフィールドへ写す考えを示しています。これは今回の発表で示された構想として読むのが正確です。例示された版名や異機種の対応表を、そのままOCPが批准した仕様や全メーカーの実装済み対応表として扱うことはできません。［2］

    電力の見える化は、センサーを増やすだけでは進みません。どこから来た値で、何を測り、いつの値なのか。その意味に加えて時刻や平均化期間も確かめられれば、異なるサーバーの値を継続して読み比べやすくなります。

    Microsoftの事業や収益の仕組みは、cyclewaveの企業解説にまとめています。

    Microsoftの企業解説を読む

    参考資料

    2026年9月24日確認。本文は公開スライドの三層案と例示をもとにしています。発表動画の発言・質疑は確認対象に含めていません。

    ［1］Open Compute Project「2026 OCP APAC Summit」発表一覧。演題、登壇者、資料掲載。

    ［2］Smitha Kashyap C、Chockalingam A、Prateek Gupta「Standardizing Power Telemetry Semantics for Energy Efficient, Hyperscale Datacenter Operations」公式掲載スライド。全15頁。課題はpp.3–4、三層案と写像例はpp.5–11、想定用途はpp.12–13。

  • MegazoneSoftが示すGitAIOps、AIへ渡す運用ルール・現状・決定理由の分け方

    MegazoneSoftが示すGitAIOps、AIへ渡す運用ルール・現状・決定理由の分け方

    担当が入れ替わった朝、AIに『なぜ、この警報の設定なの？』と尋ねる場面を想像してみます。現在の設定ファイルは読めても、ほかに検討した選択肢や、採用した理由が残っていなければ、答えは推測になりかねません。AIに運用を手伝ってもらうほど、何を守り、いま何が動き、なぜそう決めたかを分けて残すことが大切になります。

    2026年8月のOCP Korea Tech Dayで、MegazoneSoftのHoon Jo氏は、この三つをGit上の記録として整理する「GitAIOps」を紹介しました。資料に登場するのはGKE上の通知サービスを使った実習例です。AIが本番環境の変更を自律的に判断し、成功させた実績を報告するものではありません。［1・2］

    簡単にまとめると？

    • GitAIOpsは、守るルール・現在の構成・決定の理由を分け、必要な場面で参照できるようにする方法です。
    • 運用を変えたら、決定理由と構成の記録を一緒に更新し、次の変更前には実環境とも照合します。
    • 紹介されたのは実習の設計例であり、AIの回答精度や本番運用での効果を実証した報告ではありません。

    三つの層は、作業の順番ではなく、情報の役割

    一つ目は、毎回守る作業ルールです。発表例のCLAUDE.mdには『変更前に現在の状態を確認する』『kubectlを使うなら接続先を表すcontextを明示する』といった約束が入ります。長い設計書を毎回読ませる代わりに、作業の入口で外せない条件を短く持つ層です。ファイル名は利用するAIツールごとに変わります。［1］

    二つ目は、必要なときに開く現在の構成です。例ではクラスタやノードプール、Gateway API、Workload Identityなどの関係を一枚の要約にします。これは設計時の理想図ではなく、『いま、何がどこで動いているか』をつかむための文書です。ただし、文書は更新が遅れることがあります。変更の直前には実際の環境と照らし合わせる必要があります。［1］

    三つ目は、決定とその理由を積む記録、ADR（Architecture Decision Record）です。資料の例では警報の条件をPrometheusRuleで管理する選択と、Grafana Alertingを使う選択を比べ、PromQLによる条件指定、Gitでの版管理、Alertmanagerへの経路づけを理由に残しています。『何を使うか』だけでなく『なぜ別案を選ばなかったか』が読めれば、次の担当者も前提を点検できます。［1］

    発表者自身が、この三層は実行手順を上から順に並べたものではなく、役割と読み込むタイミングの違いだと説明しています。ルールは入口で、構成は必要になった時点で、ADRは理由を問う場面で使う。全部を一度に詰め込むより、問いに合う記録へたどり着ける形です。公開された実習リポジトリにも、ツールの入口ファイルと共通の作業ガイドを分ける構成が見られます。［1・3］

    記録が役立つのは、次の変更まで手入れしたとき

    資料は『作業する→新しい判断が生まれる→ADRに残す→現在の構成を更新する』という習慣を示します。たとえば警報の条件を変えたのにADRだけが古いままなら、AIは過去の理由を現在の理由として説明してしまいます。逆に現在の構成だけを書き換えれば、変更を戻すときに何を守ろうとしたのかが分かりません。両方を同じ変更の中で見直すところに、この方法の価値があります。［1］

    登壇資料には、記録をもとに質問へ答えたり、新しい担当者向けの案内文を作ったりするデモの進行が載っています。ただ、資料だけでは回答の正確さや再現性、実運用での効果は測れません。『Gitへ置けばAIがいつも正しい』という結論ではなく、根拠に戻って確かめられるようにする設計例として読むのがよさそうです。［1］

    AIへ渡す前に、人が決めておく境界

    Git上の文書は共有しやすい反面、秘密鍵や顧客情報をそのまま置く場所ではありません。AIが読める範囲と、実行できる操作も別に考えます。たとえば構成の説明や変更案の作成までは任せても、本番への適用には人の承認と別の権限を求める。記録の更新をレビューする人、古い記述を直す人も決めておきたいところです。これらは発表の三層を実務へ持ち込む際の編集上の補足であり、デモで安全性が検証されたという意味ではありません。

    AIに覚えていてほしいのは、単なる会話の続きではありません。守る約束と現状、選択の理由が次の仕事でも読めること。まず一つの運用判断について、代案と採用理由を短く残すところから始めれば、AIにも人にも、迷ったとき戻れる道ができます。

    登壇企業について

    MegazoneSoftの事業や、Google Cloudの導入・運用を支える役割は、cyclewaveの企業解説でまとめています。

    MegazoneSoftの企業解説へ

    参考資料

    2026年9月23日確認。登壇スライドのデモ説明を参照し、講演動画や回答精度の独立検証は根拠に含めていません。OCPの暫定スケジュールは講演名・登壇者表記がスライドおよび資料一覧と異なるため、本記事では資料一覧とスライドを優先しました。

    ［1］MegazoneSoft / Hoon Jo『GitAIOps: A Three-Tier Memory Structure for AI Agents』OCP掲載スライド（19頁。三層はpp.7–10、更新習慣はp.11、デモの説明はpp.13–15、導入の考え方はp.16）。

    ［2］Open Compute Project『2026 OCP Korea Tech Day』発表一覧（開催日、資料名、登壇者の掲載）。

    ［3］発表者のGitAIOps実習リポジトリ（学習用の構成例。実運用性能の証明としては用いていません）。

  • Open Source ConsultingのOpenStack SLURP更新、中間版を飛ばす6ノード検証

    Open Source ConsultingのOpenStack SLURP更新、中間版を飛ばす6ノード検証

    クラウド基盤の更新は、ボタンを押して終わりにはできません。仮想マシンが動き続けていても、管理画面や新しい仮想マシンの作成まで同じように使えるとは限らないからです。「更新できた」と「利用者に影響がなかった」の間には、いくつもの確認があります。

    2026年8月のOCP Korea Tech Dayで、Open Source ConsultingのShin Hocheol氏は、OpenStackを2025.1 Epoxyから2026.1 Gazpachoへ更新した6ノード環境の検証を紹介しました。発表の価値は「無停止」の一語より、更新前後の状態をどこで確かめたかにあります。［1・2］

    簡単にまとめると？

    • SLURPは隣り合う対象版の間で中間版を飛ばす更新経路で、任意の版を飛ばせる制度ではありません。
    • 発表の6ノード検証では、更新中に監視した仮想マシンのPingとHTTPの切断は0回でした。
    • 通信が続いたことは、管理画面や全API、すべての利用者操作が無影響だった証明ではありません。

    半年ごとの公開、1年ごとの飛び越し

    OpenStackの主要版はおおむね半年ごとに出ます。そのうち一つおきに「SLURP（Skip Level Upgrade Release Process）」と呼ぶ版があり、隣り合うSLURP版の間は中間の版を飛ばす更新経路が支えられています。EpoxyとGazpachoはその組み合わせです。どの版からでも何版でも飛ばせる制度ではありません。古い版から一気に移す場合や、配布ツールごとの制約は別に確かめます。［2：pp.12、17、20］［3］

    発表で使ったKolla-Ansibleは、OpenStackの各サービスをコンテナにまとめ、Ansibleで配置や更新を進める公式プロジェクトです。命令が短いことと、作業全体が単純なことは違います。設定、秘密情報、コンテナ画像、データベース、メッセージキュー基盤のRabbitMQなど、更新の前提は複数の場所に分かれています。［2：pp.18、21］［4］

    まず、戻れる材料をそろえる

    発表資料とKolla-Ansibleの2026.1版の手順を重ねると、準備は四つに分けられます。対象版のリリースノートを読み、設定とデータベースをバックアップする。インベントリと設定・パスワードの差分を合わせる。対象版のコンテナ画像を用意し、prechecks（事前検査）を通す。最後に、更新中と更新後に何を監視するかを決める、という順です。［2：pp.21–26］［4］

    特にRabbitMQの更新経路は、版を見ずに決められません。発表では、EpoxyのRabbitMQ 4.0からGazpacho側へ進む前に4.1を経由する案を示します。一方、2026.1版の公式文書は、条件に合う4.0から4.2への経路も許可例に載せています。「必ず中間版が要る」と固定せず、現在の実装、許可された経路、利用中のキューの状態を照合するのが正確です。［2：p.24］［5］

    「切れなかった」の測り方

    発表者の検証環境は、制御を担うコントローラーノード3台と仮想マシンを動かすコンピュートノード3台の計6台です。2025.1から2026.1への更新中、仮想マシンへのPingとHTTPを連続監視し、この測定では切断を0回と報告しました。更新処理の失敗も0件でした。これは、発表者が示した構成と測定方法に限る良い検証結果です。［2：pp.27–32］

    同じ資料には、管理画面Horizonは完了まで利用が制限され、更新中に仮想マシンを新しく作ったり消したりする操作は勧めない、とあります。PingとHTTPが途切れなかったことは、全API、全アプリケーション、全利用者操作が無影響だった証明ではありません。OpenStackのSLURP方針も、版を飛ばす更新のサポートと、あらゆる環境でのローリング・無停止更新を同一視していません。［2：p.32］［3］

    実運用で目指すのは、宣伝文句としての「無停止」ではなく、どの機能を守り、どこに保守時間を設け、何をもって完了とするかを決めることです。今動いている仮想マシンの通信だけでなく、認証、API、管理画面、新規配置、データベースの状態まで、利用者の動線に沿って測る。そうして初めて、更新の成否を自分たちの環境で言葉にできます。

    登壇企業について

    Open Source Consultingがどんな事業を手がけているかは、cyclewaveの企業解説で紹介しています。

    Open Source Consultingの企業解説へ

    参考資料

    2026年9月23日確認。6ノードの測定結果は発表者の検証環境の結果として扱い、ほかの構成に一般化していません。実際の更新手順は対象版の公式文書と現行設定で再確認が必要です。

    1. OCP「2026 OCP Korea Tech Day」 — 発表一覧。
    2. Shin Hocheol（Open Source Consulting）「Evolution of OpenStack Releases and Kolla-Ansible SLURP Upgrade Strategy」 — pp.17–33に更新案と6ノードの検証。
    3. OpenStack Technical Committee「Release Cadence Adjustment」 — SLURPの支援範囲とローリング更新の限界。
    4. Kolla-Ansible 2026.1「Operating Kolla」 — 事前準備と更新手順。
    5. Kolla-Ansible 2026.1「RabbitMQ」 — 許可経路と事前確認。
  • OOTTUMのアンダーリフト搬送案、ラックを下から支える低床ロボットの設計

    OOTTUMのアンダーリフト搬送案、ラックを下から支える低床ロボットの設計

    サーバーラックを交換するとき、運ぶのは「大きな箱」ではありません。機器や電源を載せた重い構造物を、床や周囲の設備を傷めずに、狭い通路の先まで動かします。AI向けの高密度ラックでは、その作業自体が設備設計の一部になります。

    2026年8月のOCP Korea Tech Dayで、OOTTUMのHwang Yongsuk氏は、ラック搬送ロボットの動き・持ち上げ方・荷重の伝わり方を一つの仕組みとして考える案を示しました。完成品の性能発表というより、何を設計し、どう確かめるべきかを整理した資料です。［1・2］

    簡単にまとめると？

    • OOTTUMは、ラック下へ入る低さと、駆動・操舵・短いリフトを両立させる搬送ロボットを構想しています。
    • ラックの重さが支持部・車輪・床へ伝わる経路を追い、総重量と床の一点にかかる力を分けて考えます。
    • 資料は設計と検証の計画であり、実際の床・通路・ラックを使った安全確認が必要です。

    車輪が強いだけでは、運べない

    ラックの下にロボットを入れるには、まず床とラック底面の隙間に収まる高さが要ります。入った後は、重さを支えながら少し持ち上げ、通路へ引き出し、向きを変えて置き直す。ラックの幅や支持点、通路の幅、床の段差が変われば、必要な車輪配置や旋回の余地も変わります。［2：pp.5–8、15–17］

    OOTTUMの資料が繰り返すのは、ラックの総重量と、床の一か所にかかる力は別という点です。車輪を増やしたり大きくしたりするだけでは、床の許容荷重、接触点の位置、狭い場所での操舵を同時に満たせません。OCPの施設向け指針も、床の「均等荷重」だけでなく、転がる荷重や一点に集中する荷重を分けて扱っています。数値は床の種類と現場条件で確かめる必要があります。［2：pp.8、12、15］［3］

    持ち上げた重さは、どこを通るのか

    資料が「Underlift Integration」と呼ぶのは、ラック下に進入し、下から持ち上げるアンダーリフト構成です。発表された構想では、薄い搬送部の中に駆動、操舵、短い距離のリフトを収めます。ラックの重さは受け板からリフト機構、支持フレーム、車輪へと伝わり、最後に床が受け止めます。この荷重経路を持ち上げ中、走行中、下ろす間で大きく変えないことが設計の狙いです。持ち上げ用のフォーク全体をせり上げたまま運ぶ構成を避けられるなら、ラック下に入るための低さと通路での動きやすさを両立しやすくなります。［2：pp.9–14］

    ただ、薄く作るほど車輪、リフト、骨格、配線、センサーを入れる場所が厳しくなります。強度を上げるために厚くすれば、今度はラックの下へ入れなくなる。発表はこの両立を「部品の選択」ではなく、機械全体の配置問題として描いています。ここに載る図は提案する構造であり、量産機の定格荷重や現場での稼働実績を示すものではありません。［2：pp.10–13、19］

    「動いた」より先に、安全な止まり方を考える

    資料の例示シーケンスは、接近、横からの進入、ラック下への位置合わせ、短いリフト、引き出し、方向転換という順番です。各段階で確認点が違います。持ち上げる前には支持位置と荷重の偏り、走行中には加減速と制動、曲がるときには転倒の安定性と障害物との距離を見ます。停電時に荷重を保持し、安全に止まれるかも、全工程にまたがる要件です。［2：pp.16–18］

    現場へ入れる判断には、実際のラック底面、重さ、床、通路を使った検証が欠かせません。発表者自身も、ロボット側の試験と、施設側の条件を一緒に照合する段階を提案しています。資料にあるのは検証の計画と設計の方向であって、あらゆるデータセンターで安全に運べたという結果ではありません。［2：pp.18–20］

    ラックの移動を考えると、設置場所の入口から床、ラックの足元までが、一続きの設備に見えてきます。重いものを運ぶ技術は、速さだけでは測れません。「入れる」「支える」「曲がる」「止まる」を、同じ現場条件で確かめられることが次の一歩です。

    参考資料

    2026年9月23日確認。OOTTUMの構造図と搬送順序は発表者の提案として扱い、実機の安全認証や導入実績とは区別しました。

    1. OCP「2026 OCP Korea Tech Day」 — 開催日と発表一覧。
    2. Hwang Yongsuk（OOTTUM）「Motion Architecture for Heavy-Load Server Rack Handling Robots in AI Data Centers」 — 20ページの発表資料。pp.8–19に設計要件と検証案。
    3. OCP「Colo Facility Guidelines for OCP Racks v2.0」 — 床の転がり荷重、集中荷重と搬入条件の参考。個別施設の許容量ではありません。
  • ETRIのNPUaaS設計、異なるAI半導体をクラウドで共有する

    ETRIのNPUaaS設計、異なるAI半導体をクラウドで共有する

    AI用の半導体を手に入れても、利用者がすぐ使えるとは限りません。モデルに合う装置を探し、ソフトウェアをそろえ、空いている資源を割り当てる。種類の違うNPU（Neural Processing Unit）が混ざれば、その段取りはさらに増えます。2026年のOCP Korea Tech Dayで、韓国の研究機関ETRIは、NPUをクラウドのサービスとして届けるための基盤を示しました。［1・2］

    簡単にまとめると？

    • ETRIは、異なるメーカーのNPUを共通の管理基盤で見つけ、利用者の仕事へ割り当てる設計を示しています。
    • NPUの分割利用や対応モデルは装置・実装ごとに条件があり、掲載された全製品の互換性を保証するものではありません。
    • 段階的な更新と切り戻しを設計しますが、「無停止」は目標であり、すべての構成での実証結果ではありません。

    「装置がある」から「使える」まで

    NPUは、AIの計算を効率よく進めるための専用プロセッサーです。同じNPUという名前でも、メーカーごとにドライバーや開発環境、使えるモデル、メモリーの扱いが違います。研究者や開発者にとって必要なのはチップの一覧だけでなく、仕事を投げたら適切な装置に届き、実行状態を見られる入口です。

    ETRIの資料は、その入口をコンテナと仮想マシンの両方へ広げる構成を描きます。Kubernetesはコンテナの配置を、OpenStackは仮想マシンなどの基盤を受け持ち、その間にサービスの受付、装置の発見と割当て、ストレージやネットワークをつなぐ層を置いています。これは発表資料の設計例であり、すべてのNPUクラウドが同じ構成という意味ではありません。［1］

    メーカーが違っても、運用の入口をそろえる

    資料の図には、異なるメーカーのNPUを見つけ、必要なソフトウェアを入れ、装置の情報を利用者へ渡す部品が並びます。アプリケーションが直接すべての機種差を引き受けるより、基盤側に共通の管理面を置く考え方です。画面に複数の企業名があるからといって、各社のすべての製品やモデルの動作が保証されたわけではありません。［1］

    使える量も一枚岩ではありません。NPUを一つの仕事に丸ごと割り当てる場合と、対応する装置を分割して複数の仕事で使う場合では、隔離や性能の確認方法が変わります。資料には分割・再配置の案が示されていますが、分けられる数や性能は装置と実装の条件付きです。［1］

    更新中も使い続けるには、戻り道が要る

    クラウドではドライバーや装置用の部品を更新し続けます。ETRIは、複数の実行先を段階的に切り替え、問題が出たら元へ戻す流れを図にしています。「Zero-Downtime」という見出しは、この更新設計の目標として読むのが妥当です。すべての構成で停止ゼロを実証した数値は、資料には示されていません。［1］

    さらに資料は、NPUを含むKubernetesの作成画面と、LLMの性能試験ツールの画面を載せています。運用の入口に加え、性能を測る手段も示しています。一方、機種間の優劣やサービス全体の可用性を判断するには、モデル、入力長、バッチ、消費電力、測定回数などをそろえた別の検証が必要です。掲載画面だけで比較順位は付けられません。［1］

    資料の末尾には、openKcloudの公開リポジトリも示されています。ただ、コードが公開されていることと、全機能が実環境で安定して動くことは別です。［1・3］

    この発表の面白さは、NPUを「GPUの代わりの部品」として終わらせない点です。開発者が使い始められるか、更新を戻せるか、分割しても性能を説明できるか。半導体をサービスに変える仕事は、チップの外側にもあります。

    参考資料

    2026年9月23日確認。発表資料は画像主体の17頁で、構成図と画面を原寸で確認しました。講演動画・質疑応答は根拠に含めません。資料の「無停止」は設計図の表現で、全環境の運用実績として扱いません。

    ［1］ETRI / Hyunhwa Choi「NPUaaS: A Redesign of the AI Semiconductor Cloud Service Platform」OCP掲載スライド（17頁。統合基盤p.8、異種装置管理pp.9–10、更新p.11、分割p.12、操作・測定画面pp.13–14）。

    ［2］Open Compute Project「2026 OCP Korea Tech Day」（開催日、登壇者、資料の掲載）。

    ［3］openKcloud公開リポジトリ（発表資料p.16の公開開発先。記事本文の性能・互換性の証拠としては用いていません）。

  • AIエージェントの処理中データを守るTEEとアテステーション

    AIエージェントの処理中データを守るTEEとアテステーション

    社外の計算基盤でAIエージェントを動かすとき、入力した資料はどこまで見えないのでしょう。保存時と通信中を暗号化しても、処理の瞬間には計算する装置がデータを使います。2026年のOCP Korea Tech Dayで、LablupのJoongi Kim氏は、この処理中のデータに目を向けました。［1・2］

    簡単にまとめると？

    • TEEは処理中のデータを保護する仕組みで、コンテナによる隔離とは守る範囲が異なります。
    • アテステーションで実行環境を確かめ、条件に合うときだけ鍵や秘密情報を渡します。
    • TEEの外のAPIやログには別の保護が必要で、エージェントの判断の正しさも保証しません。

    守る相手が違えば、仕組みも違う

    同氏は、AIエージェントの実行環境に二つの守り方を挙げています。一つは、不正なプログラムを含む利用者の仕事から、基盤側のサーバーを守ること。権限を絞ったコンテナや小さな仮想マシンがこちらに向きます。もう一つは、利用者の仕事を、基盤を管理する側から守ること。ここで機密コンピューティングが登場します。前者を入れただけで、後者も満たすわけではありません。［1］

    機密コンピューティングでは、CPUなどが提供する信頼実行環境（TEE: Trusted Execution Environment）の内側で計算します。クラウドの管理者や通常の仮想化基盤から、実行中のメモリーと処理を分ける設計です。どこを守るかはCPU・GPU・接続機器の組み合わせで変わり、「コンテナに入れたから機密」という意味ではありません。［1・3］

    鍵を渡す前に、動く場所を確かめる

    仕事をTEEで起動するだけでは、期待したプログラムが、期待した環境で動いているかは分かりません。その確認に使うのがアテステーションです。ハードウェアや起動状態から得られる証拠を外部で検証し、条件に合う場合だけ、暗号鍵や秘密情報を渡します。Confidential Containersの実装も、検証と鍵の受け渡しを別の役割として扱っています。［3・4］

    AIエージェントなら、処理する資料や認証情報を渡す前に、この確認を置く考え方です。ただし確認が教えてくれるのは、選んだ信頼境界と構成が条件に合うかどうか。エージェントの判断が正しいか、呼び出した外部ツールまで安全かを証明するものではありません。

    GPUや外部サービスへ出るとき、境界を描き直す

    Kim氏の資料は、クラウド・CPU・GPUの対応状況を並べていますが、対応する機種や地域、提供段階は変わります。GPUで計算するなら、CPU内で守ったデータをGPUへどう渡し、GPU側でもどこまで保護するかを、使う構成で確かめる必要があります。資料が挙げる転送性能の差も特定条件を示していないため、一般的な速度低下率とは読みません。［1］

    同じことは、ツール呼び出しやログにも言えます。TEEの外へ送った入力、外部APIの応答、運用者が読める記録は、別の保護と権限設計が要ります。機密コンピューティングは、AIエージェント全体を一枚の盾で包む技術というより、処理する場所の信頼を確かめる一層です。［3・4］

    この発表を読みながら、最初に決めたいのは製品名よりも境界だと感じます。誰から何を守るのか。資料はいつ復号するのか。どの処理が外へ出るのか。その線を引けば、必要なTEE、アテステーション、鍵の条件を具体的に選べます。

    登壇企業について

    Lablupは、GPUやNPUを複数の利用者・仕事に割り当てるソフトウェア「Backend.AI」を展開する企業です。会社の事業や収益の仕組み、上場準備の動きは、cyclewaveでまとめています。［5］

    Lablupの企業解説へ

    参考資料

    2026年9月23日確認。講演動画や質疑応答は根拠に含めていません。クラウド・半導体の提供状況、性能値は発表資料の時点の記載であり、現行の全環境へ一般化していません。

    ［1］Lablup / Joongi Kim「Secure and private AI agents with confidential computing」OCP掲載スライド（10頁。二つの保護方向p.5、処理中データp.6、クラウド・チップp.7–8、限界p.10）。

    ［2］Open Compute Project「2026 OCP Korea Tech Day」（開催日、登壇者、資料の掲載）。

    ［3］Confidential Computing Consortium「Common Terminology for Confidential Computing」（TEEとアテステーションの定義、保護範囲）。

    ［4］Confidential Containers「Attestation with Trustee」（検証と条件付きの秘密情報提供）。

    ［5］Lablup「Company」（企業と製品の概要）。

  • AIアクセラレータをつなぐUALink 2.0、4仕様の役割と対応範囲

    AIアクセラレータをつなぐUALink 2.0、4仕様の役割と対応範囲

    AI向けのアクセラレータを増やすと、チップ同士がやり取りする量も増えます。速い計算機を並べるだけでは足りず、同じ仕事に参加するチップをどうつなぎ、どう管理するかが問われます。

    2026年8月のOCP APAC Summitで、UALink ConsortiumのKurtis Bowman氏は、アクセラレータ間をつなぐUltra Accelerator Link（UALink）の更新を紹介しました。発表の中心は「2.0」という一つの数字よりも、通信の共通部分、信号の通り道、運用管理、チップレットへの組み込みを分けて定めたことにあります。［1・2］

    簡単にまとめると？

    • UALinkは、AIアクセラレータ同士を近い範囲で結ぶ接続規格で、PCIeやEthernetをすべて置き換えるものではありません。
    • 更新では、通信の共通部分、データリンク・物理層、運用管理、チップレットを四つの仕様に分けています。
    • 仕様の公開と製品の量産・相互運用実証は別で、対応する版と実測条件を確認する必要があります。

    UALinkが受け持つ範囲

    UALinkは、AI計算に使うアクセラレータ同士を近い範囲で結ぶスケールアップ接続の規格です。発表資料は、PCIe、CXL、Ethernetを置き換える万能な配線とは位置づけず、それぞれを補うものとしています。ラック間のネットワークや、CPUと周辺機器の接続まで、すべてをUALinkに読み替えることはできません。［2］

    今回紹介されたのはCommon 2.0、200G Data Link and Physical Layers（DL/PL）2.0、Manageability 1.0、Chiplet仕様の四つです。共通部分、信号の通り道、運用管理、チップレットを別の仕様として見ると、製品発表で「UALink対応」と書かれたときにも意味を確かめやすくなります。［2・3］

    Common 2.0は、アクセラレータ間の通信と計算

    Common 2.0は、アクセラレータ間の通信に共通する部分を扱います。新たに示されたIn-Network Computeは、計算の一部を接続網の中で進め、やり取りの待ち時間や転送量を減らすことを狙うものです。複数のアクセラレータが分担して学習・推論を進める際に、データの受け渡しだけでなく、その途中でできる処理にも目を向けています。［2・3］

    ただし、公開スライドは狙いと仕様の位置づけを説明する資料です。どの演算を、どの装置で、どれだけ速くしたかという実測結果まで、この発表だけで確定できるわけではありません。性能の比較は、実装と測定条件が示された資料で確かめる必要があります。［2］

    DL/PL 2.0は、信号を運ぶ部分を独立させる

    Data Link Layer（データリンク層）とPhysical Layer（物理層）は、隣り合う装置間でデータを渡す手順と、そのための信号・接続を扱います。UALinkの200G DL/PL 2.0は、この部分をCommon仕様から切り分けました。発表側は、将来、信号方式や速度を変えるときに、ほかの仕様まで同時に作り直さずに進めやすくなると説明します。［2・3］

    ここでの「200G」は仕様の名称と対象速度を示す言葉です。装置全体の実効速度や、異なるメーカーの機器を混ぜたときの性能を、その数字だけからは判断できません。

    Manageability 1.0は、つながった装置を見渡すために

    多くのアクセラレータとスイッチを一緒に動かすには、通信路の定義だけでなく、状態を知り、設定を変える方法も要ります。Manageability 1.0は、UALinkシステムの制御面・管理面を扱い、gNMI、YANG、SAI、Redfishなどの既存の仕組みを使う方向を示しています。［2・3］

    管理用の仕様が公開されたことと、製品同士がすでに問題なく相互運用できることは別です。製品を比べる際は、使える管理機能の範囲と、組み合わせ試験の結果を分けて見るのがよさそうです。

    Chiplet仕様は、チップの内側へ接続を持ち込む

    Chiplet仕様は、複数の小さな半導体ダイを一つのSoCとして組み合わせる際に、UALinkをどう組み込むかを定めます。インターフェース、形状、フロー制御、管理が対象です。発表スライドでは「Chiplet 1.0」と記されていますが、2026年9月24日に確認したConsortiumの公開一覧ではChiplet 1.01が掲載されています。資料を読むときは、発表時の版と現在配布される版を区別したいところです。［2・3］

    同一覧はUCIe 3.0への準拠も説明しています。ただし、チップ内で規格を組み込めることから、完成したサーバーやクラスタ全体の採用状況までは読み取れません。［3］

    仕様の公開と、使える製品は別の段階

    発表資料のロードマップは、適合性・相互運用の取り組み「Compliance 1.0」を2026年第4四半期に示しています。実験室での評価は2027年初頭、本番導入は同年後半に進める計画です。これは2026年9月時点では将来の予定です。仕様が公開・批准されたという話を、製品が量産され、相互運用が実証済みだという話へ置き換えないようにします。［2］

    これから「UALink 2.0対応」の製品を見るなら、四つのうちどの仕様のどの版に対応するか、実際に試した機器の組み合わせは何か、性能はどの条件で測ったかを確認したいところです。通信、管理、チップへの組み込みを分けて読むことが、この発表のいちばん役立つ入口になります。

    参考資料

    2026年9月24日確認。本文は公開スライドとConsortiumの公開仕様一覧をもとにしています。発表動画の発言・質疑は確認対象に含めていません。

    ［1］Open Compute Project「2026 OCP APAC Summit」発表一覧。演題、登壇者、資料掲載。

    ［2］Kurtis Bowman「UALink 2.0 Specification Update: Advancing Accelerator Interconnect Technology for AI Workloads」公式掲載スライド。全15頁。仕様の役割はpp.4・7–11、ロードマップと評価計画はpp.12–13。

    ［3］UALink Consortium「Specifications」。Common 2.0、200G DL/PL 2.0、Manageability 1.0、Chiplet 1.01の公開一覧。

  • Point2のe-Tube、プラスチック導波路でつなぐラック内接続

    Point2のe-Tube、プラスチック導波路でつなぐラック内接続

    AIサーバーの中では、GPU同士やスイッチへ向かう短いケーブルが何本も走ります。遠くへ送る光ファイバーほどの距離は要らない。それでも通信速度が上がると、太い銅線を短い範囲に押し込むのも難しくなります。

    2026年8月のOCP Korea Tech Dayで、Point2 TechnologyのThomas Cho氏は、銅線と光の間にプラスチックの導波路へRF信号を通す選択肢を示しました。「e-Tube」と呼ぶこの方式が、どこを置き換えようとしているのか。通信の通り道から見てみます。［1・2］

    簡単にまとめると？

    • Point2のe-Tubeは、高周波信号をプラスチック導波路へ通す接続方式で、空中へ電波を飛ばすものではありません。
    • 銅線や光との比較値は条件付きの推定であり、ケーブル両端には電力を使う送受信回路が必要です。
    • 実演・信号評価と、量産採用や長期信頼性は別で、パッケージ近くへの展開にも将来の計画が含まれます。

    銅線が厳しくなるのは、短い距離でも

    銅ケーブルは安く、構造が分かりやすく、交換もしやすい。一方、高速の電気信号を通すほど損失が増え、太い線を選んだり、信号を補正する回路を足したりする必要が出ます。ラック内なら数メートルで足りても、速度、密度、曲げやすさ、風の通り道を一緒に満たすのは簡単ではありません。［2］

    光ファイバーは長い距離を得意としますが、電気信号から光への変換と、その逆の変換に部品と電力が要ります。どちらが有利かは距離だけで決まりません。発表資料が示すDAC、補正回路付き銅ケーブル、光ケーブルの到達距離は2026年時点の代表例であり、線径、コネクター、送受信回路によって変わります。［2］

    信号を「空中」ではなく、プラスチックの中へ導く

    e-Tubeでは、両端の送受信チップが電気信号を高周波のRF信号へ変え、アンテナからプラスチック製の導波路へ入れます。導波路は電波が進む道筋を作る部材です。反対側でRF信号を受け、また電気信号として装置へ渡します。無線の仕組みを使いますが、ラックへ向けて空中に電波を放つ方式ではありません。［2・3］

    資料にある1.6TbpsのOSFPケーブル案では、OSFPという差し込み式の端子、RF送受信チップ、導波路、接続部を一体として描いています。ケーブルの中を通る媒体は銅導体でも光ファイバーでもない一方、両端は能動回路を使います。資料で「バックプレーンの通り道は受動的」と書かれる部分と、ケーブル全体が電源不要であることを混同しないようにしたいところです。［2］

    比較の数字は、同じ条件で確かめてから

    Point2は、銅に比べた到達距離や重さ、光に比べた消費電力や遅延の利点を提示します。ただし、資料の1.6T比較図には「相対比較のための推定」と明記されています。ケーブルの構造、送受信回路、コネクター、システム側の余裕によって結果は動きます。宣伝文句をそのまま製品間の保証値にはできません。［2］

    計測と製品化の段階も分けて見る必要があります。Point2は2026年にe-Tubeの実演を告知し、Keysightとは1.6Tbps級の信号を評価する協業を発表しました。これらは技術が検証段階を進んでいる根拠ですが、ラック全体での量産採用や長期故障率の証明ではありません。なお、従来型の銅線用AECについての生産拡大発表を、新方式e-Tubeの量産実績に読み替えることもできません。［4・5・6］

    まずはケーブル、その先にパッケージの近く

    発表は、差し込み式のケーブルから、半導体のパッケージに近い場所へRFの入口を移すNPE、さらに一体化を進めるCPEまで描きます。途中のバックプレーン接続では、基板へ信号を長く引き回さず、装置を交換しやすい接続にしたいという狙いがあります。ただし、この後半は展開案やロードマップを含みます。現在購入できる同一仕様の完成品を並べた表ではありません。［2］

    銅、光、プラスチック導波路は一つの勝者に決まる話ではありません。必要な距離と速度、端子の数、消費電力、交換のしやすさが違えば、選ぶ媒体も変わります。e-Tubeの面白さは、ラック内で銅が苦しくなり、光では構成が重い場面に、別の信号の通り道を差し出す点にあります。実装例を読むときは、どこまでが試験済みで、どこからが設計目標かを確かめたいところです。

    Point2 Technologyの事業全体と開発段階は、cyclewaveの企業記事で整理しています。

    Point2 Technologyの事業をcyclewaveで読む

    参考資料

    2026年9月23日確認。本文は公開スライドと両社の一次資料をもとにしています。講演動画の発言・質疑は確認対象に含めていません。数値比較はPoint2の推定条件を超えて一般化していません。

    ［1］Open Compute Project「2026 OCP Korea Tech Day」発表一覧。開催日、登壇者、資料掲載。

    ［2］Thomas Cho「e-Tube RF Transmission over Plastic Waveguides」公式掲載スライド。16頁。銅・光の比較はpp.3–6、信号経路はpp.7–9、条件付き比較はp.10、展開案はpp.11–15。

    ［3］Point2 Technology「e-Tube Technology」。RF送受信チップとプラスチック導波路の説明。

    ［4］Keysight・Point2 Technology「次世代AIスケールアップ用相互接続技術の推進に向け提携」。2026年1月29日。1.6Tbps級の信号評価に向けた協業。

    ［5］Point2 Technology「DesignCon 2026でe-Tubeを実演」。2026年の実演告知。

    ［6］Point2 Technology・FIT「従来型400G AECの生産拡大」。2021年の発表。

  • Echionの負極材料XNO、AIデータセンターの停電対策と電力変動への備え

    Echionの負極材料XNO、AIデータセンターの停電対策と電力変動への備え

    停電に備える電池と、電力の揺れをならす電池。どちらも同じ蓄電池でできそうですが、求められる働き方はかなり違います。前者は出番まで待ち、数分間を支える。後者は設備が動く間、充電と放電を何度も往復します。

    2026年8月のOCP Korea Tech Dayで、Echion TechnologiesのDerek Laan氏は、AIデータセンターのUPSやサーバーラックのBBUに、この二つの仕事が重なり始めていると説明しました。発表の中心は同社の負極材料XNOですが、まずは電池に必要な出力と、蓄えておく電力量を分けると話が見えやすくなります。［1・2］

    簡単にまとめると？

    • AI設備の電池には、停電への備えと、日々の電力変動を吸収する二つの役割があります。
    • EchionのXNOは、速い充放電の繰り返しを特徴とするリチウムイオン電池の負極材料です。
    • 材料の商用供給と、開発中のUPSラックが広く稼働していることは別です。

    停電を待つだけでは、電力の揺れに追いつかない

    従来のUPSは、外からの給電が途切れたとき、発電機などが立ち上がるまで電力を支える役目です。停電が毎日続くわけではないため、放電後の充電には比較的時間を取れます。

    AIの学習設備では、複数のGPUが同じ処理に合わせて動き、データの受け渡しでいったん計算を止めます。発表は、そこで設備の消費電力が短い間隔で上下する例を示しました。系統から見える電力をなだらかにするなら、消費が増えたときに電池から出し、減ったときには電池へ戻す必要があります。放電だけ速くても、次の揺れまでに充電できなければ続きません。［2］

    ここでUPSは「停電への備え」と「日々の変動を吸収する装置」を兼ねることになります。ただし、電池にすべてを任せる設計が唯一の答えではありません。計算負荷の制御や施設側の電力設備と役割を分け、非常時に使う残量を確保することも欠かせません。

    同じMWでも、必要なMWhは違う

    電池の出力を示すMWは、一度にどれだけ電力を出し入れできるか。電力量のMWhは、どれだけの時間それを続けられるかを示します。たとえば100MWを約1分間出し続けるなら、単純計算では約1.7MWhが必要です。実際には波形、変換損失、使える充電率の範囲で変わります。

    資料は、平均約270MWの設備を想定し、短い変動を打ち消すための対称な充放電能力を約105MW、最も深い変動で動く電力量を約2.6MWhと置いています。これは電力の出し入れは大きくても、1回に動く電力量は比較的小さいという例です。運用中の特定施設がこの数字で動いていると確認したものではなく、メーカーのモデル試算として読みます。［2］

    電池の充電速度を表すCレートも関係します。概念上、1Cなら1時間で定格容量に相当する電力、10Cならその10倍の電力です。約105MWを1Cで充電できるようにするには、単純計算で約105MWhの容量が要ります。容量そのものよりも充電できる速さが設備の大きさを決めてしまう場面です。ただし、実際の許容Cレートはセル、温度、劣化、残量で変わります。［2］

    Echionが提案するのは、速く出して速く戻せる負極

    XNOは、リチウムイオン電池の負極に使うニオブ系材料です。Echionは、急速充電時に起こりうるリチウム析出を抑えながら、速い充放電を繰り返せることを特徴とします。発表は商用セルの値として、充電・放電とも10～30C、5万回超のサイクル寿命を示します。ただし、これは特定セルの条件による会社公表値で、どの温度・放電深度・システムでも同じ寿命になるという意味ではありません。［2・3］

    資料にあるピーク1.5MW・連続充放電1MWのUPSラックは、既存のXNOセルを用いた開発中の構想です。一方、XNO負極粉末とそれを使うセル・モジュールの供給は別の成熟段階にあります。材料が商用供給されていることと、発表のUPSラックが既に広く稼働していることは同じではありません。［2・3］

    設備へ入れるなら、電池だけの性能では決まらない

    発表の費用比較では、約270MWの仮想設備に対し、LFP電池とXNO電池で設置面積や10年間の所有費用に差が出ると試算しています。しかし、計算方法は資料だけでは再現できず、価格、温度、充放電の深さ、更新時期にも左右されます。10年間の所有費用を約80％減らせるというのは、同社の条件付き試算です。一般的な導入効果とは扱えません。［2］

    実際の設計では、どの時間幅の変動を電池に受け持たせるか、停電用の残量をどこまで残すか、電力変換器と冷却装置が往復運転に耐えるかをそろえて考えます。材料に高いCレートがあっても、ラック全体の出力、保護、熱、保守の条件が追いつかなければ使い切れません。

    この発表から持ち帰りたいのは、電池を「何分もつか」だけで選ばない視点です。バックアップ用のエネルギーと、絶えず揺れる電力を受け止める力。二つを分けて設計すると、必要なセルとシステムの姿が見えてきます。

    Echion Technologiesの電池材料事業と会社の輪郭は、cyclewaveの企業記事で整理しています。

    Echion Technologiesの事業をcyclewaveで読む

    参考資料

    2026年9月23日確認。本文は公開スライドと企業一次資料をもとにしています。講演動画の発言・質疑は確認対象に含めていません。Echionの数値と経済比較は会社の提示条件に限ります。

    ［1］Open Compute Project「2026 OCP Korea Tech Day」発表一覧。開催日、登壇者、資料掲載。

    ［2］Derek Laan「High-power energy storage and solving the AI data centre power problem」公式掲載スライド。22頁。役割はpp.5–7、材料と充放電比較はpp.9–13、UPS構想はpp.15–16、モデル試算はpp.18–19。

    ［3］Echion Technologies「XNO技術と商用供給」。負極材料の位置づけ、産業規模の粉末供給。

  • SK Broadbandのデータセンター運用案、テレメトリーで電力と冷却をつなぐ

    SK Broadbandのデータセンター運用案、テレメトリーで電力と冷却をつなぐ

    たとえば、稼働中のデータセンターで、ラックの消費電力と冷却液の温度が近い時間帯に上がったとします。記録の時計がずれていると、どちらが先に変わったかも分かりません。AIデータセンターの運用では、設備を増やす前に、判断に使えるデータをそろえることが欠かせなくなっています。［1］

    2026年8月のOCP Korea Tech Dayで、SK BroadbandのPark Jaewook氏は、運用を四つの仕事に分けました。①データの品質、②手順と知識、③電力と冷却の連携、④運用者の役割です。発表は構想と例を交えた提案で、示された時間や精度の目標が、すべての施設で達成済みという意味ではありません。［1・2］

    簡単にまとめると？

    • 電力と冷却を一緒に見るには、測定値の単位・周期・欠損の扱いと時刻をそろえる必要があります。
    • 電力の変化を冷却の先行信号に使う案ですが、制御条件は自施設の遅れや安全装置と合わせて確かめます。
    • AIは検証しやすい作業から段階的に使い、専門家の判断を残す提案で、自律制御の完成報告ではありません。

    まず、同じ出来事を同じ時刻で見る

    センサーの値は、届くだけでは十分ではありません。記録が抜けていないか、測定器のずれはないか、同じ「流量」が機器ごとに別の単位や周期で届いていないか。さらに、設備の時計がずれていれば、障害の前後関係まで曖昧になります。発表資料は、この四つをデータ品質の問題として並べています。［1］

    そこで必要なのが、集める項目と単位、収集周期、欠損の扱いを先に決め、計測網と時刻同期を設計することです。時刻をそろえれば「電力の変化が冷却の異常より先だったか」は確かめやすくなります。ただし、順番が分かっても、それだけで因果関係は決まりません。現場の構成や他の記録と突き合わせる工程は残ります。［1］

    次に、経験を点検できる手順へ移す

    運用者の頭の中にだけある判断を、設備図、過去の事例、手順書、警報の条件と結びつける。資料は、その最初の題材にイベントログを選びます。たとえば冷却液の流量が下がり、フィルターの前後で圧力差が増えたとき、システムが「詰まりの可能性」を示し、運用者が値と条件を確かめる形です。発表スライドの数値入り事例は説明用の例であり、導入施設の実績とは読みません。［1］

    AIエージェントを使うとしても、まずはログの要約や候補の提示から始め、誤りを測れるようにする。資料も、専門家が最終判断する形と、簡単で検証しやすい作業から段階的に広げる考え方を示しています。液冷装置や電源の自動制御まで完成した、という発表ではありません。［1］

    電力を、冷却の少し先にある手がかりにする

    GPUの仕事量が変わると電力が先に動き、その熱が冷却液の計測点に届くまでには時間差が生じます。温度が上がってからポンプを動かすだけでは、対応が遅れる場合があります。発表は、まずラックの電力変化を先行する信号として使い、将来は仕事量の情報まで組み合わせる案を示しました。［1］

    ここで大事なのは、資料にある秒数をそのまま制御設定へ写さないことです。熱が伝わる時間は、チップ、配管、流量、センサーの位置で変わります。自施設で遅れを測り、冷却の能力や安全装置との関係を確かめてから、予測や制御の条件にします。電力と冷却をつなぐ発想は有用ですが、早く反応させれば必ず安全、とは言えません。［1］

    運用する人を、設計の初めから入れる

    計測点や配線が固まった後で運用者が参加しても、必要なデータを後から取りにくくなります。資料は、名称や単位、判断条件を設計段階から合わせ、試運転で実際に読めるか確かめる役割を運用者に求めています。複数の施設を一画面にまとめるときも、画面を作る前に共通の項目と時刻の基準が必要です。［1］

    OCPにも、施設の電力・温度などのテレメトリーを扱う取り組みと、IT機器と施設側の管理を近づける「Open Data Centers for AI」があります。ただし、発表スライドに並ぶすべての文書や数値が、そのまま確定した統一規格ではありません。今回の資料は、既存の公開資料を確かめつつ、現場で足りない定義を探す入口として読むのがよさそうです。［1・3・4］

    AIデータセンターを安定して動かす道筋は、派手な自律制御から始まるわけではありません。欠損のない計測、同じ時刻、説明できる判断条件、そして運用者が止められる手順。その土台があって初めて、電力と冷却を一緒に見守れるようになります。

    SK Broadbandの通信・メディア事業とデータセンター事業は、cyclewaveの企業記事で整理しています。

    SK Broadbandの企業分析をcyclewaveで読む

    参考資料

    2026年9月23日確認。発表資料に含まれる対応時間・損害額・精度目標は、一般施設の実測値やOCPの一律要件として用いていません。講演動画・質疑応答は根拠に含めていません。

    ［1］SK Broadband / Park Jaewook「F1-Style AI DC Operations: 4 Core Pillars」OCP掲載スライド（27頁。四つの仕事はp.7、データ品質はpp.8–9、運用知識はpp.11–12、電力と冷却はpp.14–15、運用者はpp.17–18）。

    ［2］Open Compute Project「2026 OCP Korea Tech Day」発表一覧（開催日・登壇者・資料の掲載）。

    ［3］Open Compute Project「Data Center Telemetry」（施設の電力・熱・機械系データを扱う取り組み）。

    ［4］Open Compute Project「Open Data Centers for AI」（施設側とIT側のテレメトリーおよび管理の方向）。