Cloud

概要 ドイツのセキュリティ企業QUIRSOの調査により、中国語圏の攻撃者とみられるハッカー集団がVMware vCenterの重大な脆弱性を悪用し、世界47カ国361件のIPアドレスでroot権限を奪取したうえ、一部の環境でBabuk派生のランサムウェアを展開していたことが明らかになった。悪用対象となったのは、ディレクトリトラバーサルの脆弱性であるCVE-2026-59310(CVSSスコア9.8)で、Broadcomは2026年7月29日にパッチをリリースしていた。しかし公開開示からわずか5日後には実際の攻撃キャンペーンが始まっており、パッチ適用前の環境が広範囲で悪用された形だ。あわせて認証回避の脆弱性CVE-2026-59309の悪用も8月1日時点で確認されている。 攻撃の手口 攻撃者はvCenterの脆弱性を突くことで、rootコンテキストでの即座の非対話的コード実行を獲得した。侵害は段階的に進み、まず「zz-poc59310-syslog.log」という名の不正なcronファイルを介して初期アクセスを確立し、続いてcurlやwgetで外部サーバー(5.34.177[.]38:9861)から「linuxFile」というバックドアインプラントを取得、systemdやcronを使って永続化させている。このlinuxFileインプラントはWebSocketチャネル(ws://intel.se9ly9upbhay.shop:8080/ws)を通じてC2サーバーと通信し、C2アドレスはXOR難読化された状態で保持されていた。 このほかにも、攻撃者はSSH公開鍵を追加して遠隔アクセスを確立したり、「vmware-perf-update.jsp」というJSP形式のWebシェルを設置したうえでvSphere SSO管理者グループへ不正アカウントを追加するなど、複数の手法を組み合わせて侵害を拡大させていた。最終段階では、ファイルを".babyk"拡張子で暗号化するBabuk派生のランサムウェアが展開されたケースも確認されている。QUIRSOは、このランサムウェア展開が防御側の目を本来の侵入活動からそらす「煙幕」として機能した可能性を指摘しており、単なる金銭目的の攻撃ではなく、より深い偵察や情報窃取が並行して行われていた可能性を示唆している。 攻撃者の特定と被害範囲 QUIRSOは、攻撃者作成スクリプト内に残された中国語のアーティファクトや、中国のセキュリティ研究成果の再利用とみられる痕跡、UTC+08:00タイムゾーンでの活動パターンなどを根拠に、「中程度の確信度」で中国語話者の脅威行為者による関与と評価している。被害は47カ国361件のIPアドレスに及び、国別ではドイツ(55件)、米国(41件)、トルコ(38件)、イラン(26件)、フランス(25件)の順に多かった。また8月14日には、侵害の痕跡を系統的に消去する目的とみられるツールを含むGitHubリポジトリ「pikpak0066/tmpclean」も発見されており、攻撃者が痕跡隠蔽にも注力していたことがうかがえる。 対策と今後の展望 Broadcomは7月29日の時点でCVE-2026-59310に対するパッチを既にリリースしており、未適用の環境では早急な適用が強く推奨される。パッチ公開からわずか5日で実際の悪用が始まった事実は、公開されたパッチ情報から攻撃者が脆弱性の詳細を迅速に解析し武器化する能力を持つことを改めて示している。vCenterを運用する組織は、パッチ適用だけでなく、不審なcronジョブやSSH鍵の追加、未知のWebシェルの有無など、侵害の兆候を個別に確認することが求められる。

概要 マクドナルドやVodafone、Kyndrylなど大手企業9社が、侵害されたAzure認証情報を悪用した大規模なデータ窃取キャンペーンの被害を受けたことが判明した。攻撃者は「TheHatman」というハンドルネームでダークウェブフォーラムに出没しており、侵害した認証情報を使ってAzure/Entraポータルから直接従業員データをダウンロードしたと主張している。被害企業と流出件数は、マクドナルドが約170万件、Tata Consultancy Services(TCS)が約80万件、Vodafoneが約42万5,000件、HCL Technologiesが約25万件、IHGが約18万5,000件、Kyndrylが約17万件、Gap Inc.が約8万件、Hexawareが約2万件、Wyndham Hotelsが約9,000件と、合計で数百万件規模の企業内部データが対象になったとされる。 窃取されたデータと悪用リスク 流出したデータには、従業員の氏名、企業メールアドレス、電話番号、物理住所に加え、従業員ID、職務、所属部門、マネージャー情報といった組織構造を示す情報が含まれる。特に懸念されているのは、サービスアカウントやグローバル管理者アカウントに関する情報が含まれている点で、これが悪用されれば単なる個人情報漏えいにとどまらず、企業システムへの不正アクセスや権限昇格につながる可能性がある。セキュリティ企業Hudson Rockの調査によれば、今回の侵害は情報窃取型マルウェア(インフォスティーラー)によるセッショントークンの窃取と関連している可能性が指摘されているほか、フィッシングキャンペーン、多要素認証(MFA)の未導入、APIの悪用といった侵入経路の可能性も挙げられているが、具体的な侵入手法は依然として特定されていない。 想定される影響 窃取された組織構造データや従業員の連絡先情報は、ビジネスメール詐欺(BEC)やスピアフィッシングキャンペーンの実行に直接利用される恐れがある。攻撃者が従業員の役職やマネージャー関係を把握していることで、なりすましメールの説得力が増し、標的型攻撃の成功率が高まる可能性がある。またサービスアカウントやグローバル管理者情報の流出は、クラウド環境における権限昇格攻撃の足がかりとなりうるため、影響を受けた各社は認証情報のローテーションやアクセス権限の見直しといった追加的な対応を迫られている。 今後の対策 Hudson Rockは、インフォスティーラー感染によって侵害された認証情報を早期に検出する仕組みや、サイバー犯罪インテリジェンスの活用を組織に推奨している。今回の事案は、クラウド管理ポータルへのアクセスにおいて多要素認証を徹底することや、エンドポイントでのマルウェア感染対策、セッショントークンの適切な管理がいかに重要かを改めて示す事例となった。攻撃者による具体的な侵入経路の特定と、被害企業側の詳細な調査結果の公表が今後注目される。

概要 Google Cloudは8月11日、耐量子計算機暗号(Post-Quantum Cryptography, PQC)への移行に関する詳細なロードマップを公開した。ブログ記事はJai Haridas氏(VP/GM, Regulated and Sovereign Cloud)とMichael Bachman氏(VP/GM, Cloud Foundations)が執筆し、2029年までの完全対応を目標に、「Store Now, Decrypt Later(SNDL)対策」「完全性・否認防止」「暗号的敏捷性を備えた基盤・鍵管理」という3つの領域に分けた段階的な移行計画を示している。背景にあるのは「Harvest Now, Decrypt Later(HNDL)」と呼ばれる脅威で、攻撃者が現在のうちに暗号化通信を記録・保存しておき、将来量子コンピュータが実用化された時点でまとめて復号するリスクへの対応が急務となっている。 すでに実装済みの機能も多い。google.comおよび*.googleapis.comのAPIエンドポイントはFIPS 203として標準化されたML-KEMのハイブリッドモードに対応し、Application/Proxy Load BalancerではX25519MLKEM768によるTLS 1.3の量子安全な鍵交換をオプトインで提供している。またCloud KMSでは鍵カプセル化のML-KEM、署名用のML-DSA(FIPS 204)・SLH-DSA(FIPS 205)が一般提供(GA)済みで、Google内部のサービス間通信を暗号化するALTS(Application Layer Transport Security)についても2025年にPQC対応を完了したという。 技術的な詳細 Google CloudはPQCアルゴリズムとして、NISTが標準化した鍵カプセル化メカニズムのML-KEM(FIPS 203)、デジタル署名のML-DSA(FIPS 204)とSLH-DSA(FIPS 205)を採用する。現行のX25519と組み合わせるハイブリッドモード(X25519MLKEM768)を採用することで、既存システムとの互換性を保ちながら段階的にPQCを導入できる設計になっている。またPQC署名はサイズが大きく証明書チェーンの検証に影響を与えるため、ChromeやCloudflareと連携してMerkle Tree Certificatesの実験に取り組んでおり、IETFのPLANTSワーキンググループでの標準化にも関与しているという。 ハードウェア面では、チップレベルの検証を行うCaliptra v2.1、オープンソースのRoot of TrustであるOpenTitan(量子安全ブートは2025年に対応完了)、TPM 2.0 v185などを組み合わせ、2028年までにConfidential ComputingやFIPS 140-3 Level 3準拠のQuantum-Safe Cloud HSMを整備する計画としている。 ロードマップと責任分担 3つの領域それぞれに達成目標年が設定されている。SNDL対策(顧客ワークロード、管理者・開発者フロー、データパイプラインの保護)は2027年完了を目標に、Cloud VPNやCloud Interconnect、GKE Service Mesh、Tinkなどが2026〜2027年にかけて順次対応する。完全性・否認防止(ソフトウェアサプライチェーン保護、証明書発行、Cloud IAM)と、基盤・鍵管理(EKM、Google Workspace Client-Side Encryptionなど)はいずれも2028年完了を目標としている。 移行にあたってはGoogleと顧客の責任分担が明確化されており、Googleはネットワークの量子安全化や転送中暗号化、ハードウェアの完全性保証を担う一方、顧客側はアプリケーションのPQCハンドシェイク対応や鍵のライフサイクル管理、サービス設定の更新を担う「責任共有モデル」となる。この動きは、2030〜2035年に従来型アルゴリズムの段階的廃止を求めるNSAのCNSA 2.0や、移行パスを定めるNIST IR 8547といった規制動向とも歩調を合わせたものだ。 顧客への推奨事項 Google Cloudは顧客に対し、(1) Cloud Asset InventoryやWizの暗号資産評価ツールを用いた暗号資源のインベントリ把握、(2) BoringSSLやChrome、各種SDKなどPQC対応ソフトウェアへの更新、(3) 量子安全なAPIやロードバランサーを用いた検証、という3段階での準備を推奨している。今後数年で主要クラウドサービスの量子安全化が段階的に進む見通しであり、企業側も自社システムの暗号資産棚卸しを早期に始めることが求められそうだ。

概要 AWSは2026年8月13日、AWS Client VPN用クライアントソフトウェア「AWS VPN Client」のv6.0.xを公開した。今回のアップデートでは、コマンドラインインターフェース(CLI)のサポートに加え、企業向けの管理機能強化、そしてOpenVPN3をベースとした再構築による接続確立の高速化が図られている。既存のAWS Client VPNエンドポイントとの互換性は維持されており、エンドポイント側の変更は不要で、追加料金なしに標準のAWS Client VPN料金の範囲内で利用できる。 技術的な詳細 新たに追加されたCLIは、GUI(グラフィカルインターフェース)と機能的に同等であり、スクリプトによるVPN接続の自動化やInfrastructure as Code(IaC)ワークフローへの組み込みが可能になった。AWSは「AWS VPN Client CLIはGUIと完全な機能パリティを提供し、自動化ワークフローにVPN接続をスクリプト化できるようになった」としている。GUIとCLIは同時に起動して独立したVPN接続を維持できるため、運用担当者の手作業と自動化スクリプトを併用する環境でも支障なく利用できる。対応プラットフォームはWindows(x64/ARM)、macOS(x64/ARM)、Linux(x64)。 管理機能面では、特定ユーザーに限定したプロファイルや、デバイス単位で適用されるグローバルプロファイルの設定など、組織全体でポリシーを一元的に適用できる仕組みが加わった。従来、組織内でのVPNプロファイル配布はきめ細かなアクセス制御に乏しかったが、今回のアップデートによりエンタープライズ規模での管理がしやすくなる。 背景と今後の展望 これまでVPN接続の自動化には、サードパーティ製ツールの利用や手動での操作が必要だった。今回のCLI対応とOpenVPN3ベースへの刷新により、CI/CDパイプラインや構成管理ツールとの連携、多数の拠点・デバイスを抱える企業でのVPN運用効率化が期待される。既存環境からの移行に伴う設定変更が不要な点も、導入のハードルを下げる要素といえる。

概要 Node.jsおよびDenoの生みの親であるRyan Dahl氏が、Cloudflare WorkersのDurable Objectsおよび関連JavaScript APIと互換性を持つ、自己ホスト型・分散型の実装「celld」を公開した。Dahl氏自身はこれを「セルフホスト可能な分散Durable ObjectsおよびWorkers実装」と説明しており、Cloudflareのインフラに縛られずに同様のアーキテクチャを独自のバックエンド上で運用できる点が最大の特徴となっている。celldはApache 2ライセンスで公開されており、JavaScriptおよびTypeScriptで書かれたコードを実行できる。 技術的な詳細 celldはRustとJavaScriptで実装されており、非同期ランタイムにはTokio Rustを採用している。ストレージバックエンドにはAmazon S3互換のオブジェクトストレージを利用する設計で、各celldオブジェクトはそれぞれ独自のSQLiteコピーを保持する。オブジェクトごとに単一スレッドで処理を行うことで、複雑な同時実行制御の問題を回避しているという。API面ではCloudflare WorkersおよびDurable ObjectsのJavaScript APIと互換性があり、理論上はWebAssemblyを介してRust、C/C++、Go、Zigで書かれたコードも実行可能とされる。 Durable Objectsのアーキテクチャは、Cloudflareのエンジニアであるケントン・ヴァーダ氏が考案したもので、celldの開発チームはこれを「分散システムに近年もたらされた最良のプリミティブの一つ」と高く評価し、自らの実装を同アーキテクチャへの「ラブレター」と表現している。従来のAWS Lambdaのようなサーバーレスモデルとは異なり、Durable Objectsのモデルは計算とデータを同じ場所に共存させることで、WebSocket APIを活用した低遅延の分散Webアプリケーションを可能にする。リアルタイムの共同編集やマルチプレイヤーゲーム、AIエージェントの構築といった用途に適しているとされる。 コストを巡る主張の対立 Dahl氏の試算によれば、Cloudflare上で100個のアクティブなDurable Objectセルを稼働させると月額415ドルかかるのに対し、celldをDigitalOceanのS3互換バケットと8GBの仮想マシンで運用した場合は月額49ドルで実現できるという。これに対してCloudflareは異論を唱えており、オブジェクトが休止状態であれば月額コストは20.65ドルまで下がると反論している。 開発方針と今後の展望 celldのGitHubリポジトリでは、AI生成コードによるコントリビューションが禁止されている点も特徴的だ。開発チームは「コーディングエージェントは、大規模かつコンテキストの乏しい変更を送りやすくしてしまう」ことを理由に挙げている。記事では、Neonをはじめとする他のデータベースサービスプロバイダーも計算とデータを同じ場所に配置する同様のアプローチを進めていることに触れており、celldの登場はこうした実行環境の次の潮流を象徴する動きとも位置づけられている。

概要 サムスン電子の次世代HBM4メモリーの歩留まりが、業界で「黄金水準(golden yield)」とされる80%に到達したと報じられた。2月の量産開始時点では60%未満だった歩留まりを、わずか半年ほどでここまで引き上げたことになる。当初は2026年末までに80%達成を目標としていたが、プロセス改善が予想を上回るペースで進んだことで、数カ月前倒しでの達成となった。NVIDIAの次世代AIアクセラレータ「Vera Rubin」向けの供給競争が激化するなか、これまでHBM市場で先行してきたSKハイニックスに対する競争力を大きく高める材料として注目されている。 技術的な詳細 歩留まり改善を支えたのは、TC-NCF(熱圧縮非導電膜)プロセスの進展と、HBM4の基盤となる1c DRAMの歩留まりが年初の時点ですでに80%を超えていたことの2点とされる。一方のSKハイニックスもHBM4の歩留まりを「80%程度」まで引き上げているとみられ、MR-MUF(先進型モールドアンダーフィル)技術を用いて下半期に順調な量産拡大を見込んでいるという。両社とも同水準の歩留まりに達しつつあることで、HBM4世代における技術的な差は縮まりつつある。 ビジネスへの影響 サムスンは2026年下半期のHBM4売上を前四半期から3倍以上に拡大させる計画で、2026年下半期にはHBM販売全体の60%以上をHBM4が占める見通しだ。年末までにはHBM市場でのシェアを約38%まで高めることを目標としており、これは同社のDRAM全体の市場シェアと同水準になる。歩留まり改善はNVIDIAの次世代GPU「Vera Rubin」の生産加速を後押しする可能性があり、複数サプライヤーからの調達を望む顧客にとっても有利に働くとみられる。 背景と今後の見通し SKハイニックス社内では、歩留まり競争と並行して労使交渉も動いている。経営陣と労働組合は、給与上限の撤廃と年間営業利益の10%を配分する利益配分スキームでは合意したものの、「利益配分の半分以上を財務諸表株で支払い、売却にロック期間を設ける」とする経営側の提案について労働側が反発しており、交渉は複雑化している。市場調査会社TrendForceは、供給制約が続くなかでHBM4の価格決定力は2027年まで維持されると予測する一方、2027年のHBM出荷量は前年比50~60%増加する見通しであっても需要増には追いつかず、市場の逼迫状態はしばらく続くとみている。なお業界の構造変化を示す動きとして、Appleがサプライチェーン多様化のため中国CXMTのメモリー採用を検討しているとの報道もある。

概要 欧州最大級の格安航空会社ライアンエアーは、Google Cloudと5年間のデータ・AIパートナーシップ契約を締結したと発表した。契約金額は両社とも非公開としている。ライアンエアーはこれに先立つ7月27日にもAWSとの契約を5年間更新しており、今回のGoogle Cloud契約と合わせることで、複数のクラウドプロバイダーを併用する「デュアルクラウド」体制を構築する。ライアンエアーのCEOであるエディ・ウィルソン氏は「優れたインフラの回復力を確保する必要があり、新たなデュアルクラウド戦略はそれを実現するものだ」と述べている。 役割分担とAIサービスの活用 新体制では、AWSとGoogle Cloudがそれぞれ異なる役割を担う。AWSは引き続き公式サイトの運用や647機の保有機材にまたがる運航計画を支え、Amazon Quick、Amazon Bedrock、Bedrock AgentCoreといったサービスが利用される。一方、Google Cloud側では従業員3万5000人を対象にGoogle Workspaceを全社導入するほか、エージェント型AIプラットフォームのGemini Enterpriseを意思決定の自動化や乗務員のスケジューリング最適化、従業員の生産性向上に活用する。さらにGoogle DeepMindのアルゴリズム改善技術「AlphaEvolve」や、気象予測・保守計画に用いる「WeatherNext」も導入される予定だ。 デュアルクラウド化の狙いと今後の展望 今回の体制構築の主眼は、片方のクラウドで障害が発生した際にもう一方へ自動的に切り替えることで、フライト運航や顧客対応を止めずに継続できるインフラの回復力を高めることにある。航空会社にとって予約システムや運航計画の停止は直接的な事業損失につながるため、単一プロバイダーへの依存を避ける動きは業界的にも合理性が高い。Google Cloudのバイスプレジデントであるマウリーン・コステロ氏は、今回のパートナーシップについて「業界のリーダー企業が安全に規模を拡大し、運用コストを削減する助けとなる」と語った。ライアンエアーは2034年までに年間旅客数3億人を目指しており、今回のインフラ強化はその成長戦略を支える基盤整備の一環と位置づけられる。

概要 CNCF（Cloud Native Computing Foundation）は8月11日、オープンソースツールキット「Cloud Native Buildpacks」をGraduated（卒業）プロジェクトに認定したと発表した。Graduatedは、CNCFホスト下のプロジェクトが到達できる最高段階のステータスであり、広範な本番環境での採用実績、ベンダー中立的なガバナンス体制、成熟したセキュリティ慣行を満たしたプロジェクトにのみ与えられる。Cloud Native Buildpacksはアプリケーションのソースコードから直接OCI準拠のコンテナイメージを構築する仕組みを提供しており、コンテナビルドの標準として確固たる地位を築いたことが今回の認定で裏付けられた形だ。 技術的な詳細 Cloud Native Buildpacksの中核的な価値は、開発者がDockerfileを手書きする手間を省き、Java、Python、Go、Node.js、Rubyといった主要言語を自動検出したうえで、依存関係のインストールやイメージレイヤーの構築までを自動化する点にある。手動での設定ファイル管理を排除することで運用の複雑性を大きく削減し、ある大規模導入事例では脆弱性への対応時間が数週間単位から数時間単位へと短縮されたという実績も報告されている。セキュリティ面では、Quarkslabによる第三者セキュリティレビューを経て、OpenSSF Best Practicesバッジも取得しており、CNCF Code of Conductも採用するなど、ガバナンスと品質保証の両面で成熟した運営体制が評価されたとみられる。 コミュニティと採用状況 プロジェクトには164組織から535人の貢献者が参加しており、Bloomberg、Heroku by Salesforceなどが積極的にコード貢献を行う主要な貢献者として名を連ねる一方、DigitalOcean、GitLab、Google、HashiCorp、Spring、VMware by Broadcomなどは実運用で採用するアダプターとして名を連ねる。プロジェクトを実運用で採用する企業（アダプター）は20社以上にのぼり、単なる技術検証にとどまらない広範な本番導入が進んでいることがうかがえる。こうした多様なエコシステムからの継続的な貢献と、特定ベンダーに依存しないガバナンス構造が、CNCFの卒業基準を満たす重要な要素になったと考えられる。 今後の展望 CNCFの発表によれば、プロジェクトの今後のロードマップはOCI Artifactsサポートの拡大、ソフトウェア部品表（SBOM）ワークフローの強化、そしてWebAssemblyを含む次世代ワークロード形式への対応に重点が置かれるという。サプライチェーンセキュリティへの関心が高まるなか、SBOM対応の強化はコンテナビルドの透明性向上に直結する取り組みであり、WebAssemblyへの対応拡大はコンテナ技術の適用範囲がさらに広がっていることを示している。Cloud Native Buildpacksの卒業は、クラウドネイティブなソフトウェア供給網全体の信頼性と標準化を進めるうえで、一つの節目になりそうだ。

概要 Google Cloudは8月11日、Database Migration Service（DMS）にGeminiを統合したAIコード変換機能を発表した。OracleやSQL ServerからPostgreSQL（AlloyDB for PostgreSQLおよびCloud SQL for PostgreSQL）へのデータベース移行において、これまで数ヶ月を要していたストアドプロシージャ・トリガー・カスタム関数などの手続き型ロジックの変換作業を、数日単位に短縮できるとしている。 「最後の1マイル」問題 Google Cloudによれば、データベース移行はスキーマ変換やデータ移行そのものは比較的スムーズに進む一方、数百個に及ぶストアドプロシージャやトリガー、カスタム関数を専有のSQL方言（PL/SQLやT-SQLなど）からPostgreSQLのPL/pgSQLへ手作業で書き換える工程がボトルネックとなってきた。数千行規模の手続き型コードを人手で翻訳するには長い期間がかかるうえ、変換ミスによるリスクも高い。この「最後の1マイル」を解消することが、今回の機能追加の主眼だという。 技術的な詳細 新機能は、ソースデータベースのテーブル関係やデータ型、外部キー制約、プロシージャ間の依存関係といったスキーマ全体のコンテキストを自動的に読み込んだ上で、Geminiが変換対象のコードを生成する仕組みを採る。標準的なDDLやスカラ関数の変換には決定論的なコンパイラルールによる1対1マッピングを用い、条件分岐やNULLハンドリングなど複雑な手続きブロックの変換にGeminiのコンテキスト理解を組み合わせることで精度を担保する。生成後は構文・依存関係の自動検証を経て、変換前後のコードをサイドバイサイドで表示し、変換理由をインラインで説明する評価画面が提示される。開発者はここで内容を確認・編集した上で、Cloud SQLやAlloyDB上のステージング環境にデプロイして機能・性能を検証できる。処理はすべて利用組織のGoogle CloudプロジェクトIAMガバナンス配下で完結するため、複数ファイルの手作業コピー&ペーストや、コードの外部持ち出しを避けられる点もセキュリティ面での特徴として挙げられている。 利用方法と今後 機能はGoogle Cloudコンソールのmigration assessmentウィザードから呼び出す形で提供される。記事では料金体系やプレビュー・GA(一般提供)の区分については明記されておらず、詳細はデータベース移行および料金の公式ドキュメントを参照する必要がある。あわせて公開された動画シリーズ「Gemini taught me PostgreSQL」では、OracleやSQL Serverからの典型的な変換シナリオが紹介されている。Google Cloudは関連するデータベース運用エージェントや、複数結果セットの変換自動化といった取り組みも進めており、AIを活用したデータベース移行・運用の自動化を今後も拡張していく方針とみられる。

概要 Kubernetes上でMLワークフローを構築・運用するためのプラットフォームであるKubeflowが、CNCF（Cloud Native Computing Foundation）の卒業（Graduation）に向けて急速に前進していることが明らかになった。卒業はCNCFホスティングプロジェクトの中でも最も成熟した段階に位置づけられるステータスであり、Kubeflowが本番環境で広く使われる、安定したMLエコシステムへと進化したことを示す節目となる。これに合わせて、Kale 2.0、Kubeflow Trainer、新設計のNotebooks v2、そしてKubernetes 1.34以降に正式対応したKubeflow Community Distribution 26.03など、複数の新機能・新コンポーネントがまとめて発表された。 Kale 2.0とKubeflow Trainer Kale 2.0は、注釈を付けたJupyterノートブックを本番運用可能なパイプラインへと自動変換するツールで、KFP（Kubeflow Pipelines）SDKのコードを一切書かずに変換できる点が特徴だ。Kubeflow Pipelines v2アーキテクチャにも対応しており、データサイエンティストが実験段階のノートブックから本番運用への移行をスムーズに進められるよう設計されている。 一方のKubeflow Trainerは、MPI（Message Passing Interface）サポートを通じて分散AIトレーニングとHPC（高性能コンピューティング）ワークロードを統一的に扱えるコンポーネントとして刷新された。特にFlux Frameworkとの正式統合により、単一のKubernetes環境上で大規模なHPCシミュレーションとAIトレーニングを並行して実行できるようになった点が注目されている。LinkedIn上の投稿では、この統合は「HPC技術のクラウドネイティブインフラ採用に向けた重要な一歩」であり、「現代的なGenAIワークロードに不可欠」だと評価されている。 Notebooks v2とKubernetesエコシステムへの統合 完全に再設計されたNotebooks v2は、宣言型のCRD（Custom Resource Definition）駆動アーキテクチャを採用した点が大きな変更点だ。これによりプラットフォームチームは、JupyterLabやVS Codeといったインタラクティブな開発環境に対して、テンプレート化された形で制御・管理を行えるようになる。現在はalpha版として利用可能だが、Kubeflowプロジェクト全体が宣言的でKubernetesネイティブな設計思想へと寄せていく方向性を示すものといえる。 さらに、Kubeflow Community Distribution 26.03ではKubernetes 1.34以降への正式な検証が完了した。マルチテナント対応の強化やPod Security Standards Restrictedポリシーへの互換性実装が盛り込まれ、組織規模での運用における信頼性とセキュリティの向上が図られている。 背景と今後の見通し Kubernetesは今やプロダクション環境におけるAI基盤の中核レイヤーになりつつあり、実運用の事例も蓄積されてきている。記事ではSubaru Corporationの事例が紹介されており、KubernetesとArgo CDを活用することで30GB以上に及ぶAIコンテナイメージのプル時間を3時間から3分にまで短縮したという。 コミュニティ面では、新たなアウトリーチプログラムやML Experienceワーキンググループの発足により、Kubeflowへの参加障壁を下げる取り組みも進んでいる。8月19日には実世界のMLOpsユースケースを紹介する仮想ショーケースイベントの開催も予定されており、今回発表された各コンポーネントの実運用への浸透が今後の焦点となりそうだ。