Cloud

概要 Microsoftは、アラブ首長国連邦・サウジアラビア・カタール・クウェートの湾岸4カ国において、2030年までにクラウドおよびAIインフラの整備に100億ドル超を投資すると発表した。副会長兼社長のBrad Smith氏が明らかにしたもので、既存の投資計画に約20億ドルを積み増す形となる。この100億ドルという数字は設備投資(capex)と運用費用(opex)の両方を含んでおり、各国でのソブリンクラウド・アーキテクチャの構築とAI向けコンピュート施設の増強に充てられる。世界的にクラウド大手各社が生成AI需要を見込んで湾岸地域でのインフラ拡張を競う中、Microsoftも自社の存在感をさらに強める姿勢を鮮明にした。 通信インフラとデジタルレジリエンスへの投資 今回の発表には、クラウド・AI施設の拡張にとどまらず、地域の通信基盤とセキュリティ対応力を底上げする施策も含まれている。Microsoftは2030年までに中東全域の陸上光ファイバー網および大容量海底ケーブルに4億ドル超を追加投資する計画で、すでにカタール・サウジアラビア・UAEに陸揚げ地点を持つ海底ケーブルシステム「SeaMeWe-6」に関与しているほか、総延長27万5000マイルを超える自社のグローバル光ファイバー網の拡充も進める。あわせて、湾岸4カ国の企業・公共部門向けに、デジタル対応力の監査、事業継続計画、データ保護プログラムなど「デジタルレジリエンス」を支援するサービスも提供するとしている。この背景には、バーレーンやUAEで第三者運営のクラウドデータセンターがドローン攻撃による被害を受けた事例があり、地域の緊張が高まる中でもインフラ投資を継続・拡大する姿勢を打ち出した形だ。 地域パートナーシップの拡大 Microsoftは各国の主要AI関連組織との連携も強化している。UAEでは2024年にAbu Dhabi拠点のG42に15億ドルを出資してマイノリティ株主となっており、Brad Smith氏自らがG42の取締役会に名を連ねる。サウジアラビアでは同国の公的投資ファンド(PIF)が支援するHUMAIN、カタールではQAIとそれぞれ直接出資は伴わないものの技術面での協業を進めているほか、クウェート政府とも連携を拡大する方針だ。こうした各国固有のAI推進主体と足並みをそろえることで、単なるインフラ提供にとどまらない、政府・産業界を巻き込んだ包括的なAIエコシステムの構築を狙っているとみられる。 今後の見通し 湾岸諸国は潤沢な資金力を背景に国家戦略としてAI投資を加速させており、Microsoftに限らず主要クラウド事業者にとって同地域は今後のAIインフラ需要を左右する重要市場になりつつある。一方で、地政学的リスクの高まりを踏まえたデジタルレジリエンス需要の拡大は、単なるデータセンター誘致競争から一歩進み、通信網の冗長性や事業継続性といった「守り」の側面を含む投資競争へと戦線が広がりつつあることを示している。今回の増額表明が実際のインフラ稼働やソブリンクラウドの具体的なサービス提供にどう結びついていくか、今後の進捗が注目される。

概要 Google Cloudは9月24日、AWS EKSからGKEへのクラスター移行を支援するオープンソースのAIエージェントプラグイン「GKE agentic migration」を発表した。手動でのKubernetesマニフェスト書き換えは時間がかかる一方、汎用LLMによる自動変換は廃止済みAPIフィールドの見落としやセキュリティ設定の欠落といったハルシネーションを起こしやすい。GKE agentic migrationは、LLMによる複雑な変換作業と決定論的な検証エンジンを組み合わせることで、この速度と正確性のトレードオフを解消することを狙っている。さらに、生成した変更をライブクラスタへ直接適用するのではなく、GitリポジトリをソースオブトゥルースとしたGitOpsベースのプルリクエストとして提出する仕組みを採用し、既存のCI/CDレビュープロセスの中で安全に移行を進められるようにしている。 移行フローとハイブリッド検証の仕組み 移行はまず、ソースGitリポジトリのクローンやEKSクラスタのスキャンによる深い発見(discovery)から始まり、マニフェストの索引化と依存関係のマッピングを経て、アーキテクチャ上の非互換性を洗い出した評価レポートが生成される。各ブロッカーには解決責任者と目標解決日が割り当てられ、プラットフォームエンジニアが移行範囲を承認したうえで、VPCやサブネット、GKEクラスターなどを定義するTerraformベースのランディングゾーン設計に進む。 続くクラウド翻訳のステップでは、AWS IRSAをWorkload Identityへ、ALBをGateway APIへ、KarpenterのノードクレームをGKEのNode Auto Provisioning(NAP)やCustom Compute Classesへ変換するなど、AWS固有の設定をGKEの対応機能へLLMが変換する。生成された結果はterraform validateやKubernetesマニフェストのスキーマチェックといった決定論的な検証にかけられ、ここで機械的に誤りを排除してからプルリクエストとして提出される仕組みだ。データベースやストレージのデータ転送そのものはプラグインの対象外とし、Google Cloud Database Migration ServiceやStorage Transfer Serviceを使う運用チーム向けのランブック生成に留めている点も特徴で、翻訳作業とデータ転送作業を明確に分離することでリスクを限定している。 マルチペルソナ設計と評価 同ツールはプラットフォームエンジニアとアプリケーション開発者という異なる役割を想定した状態管理も備える。プラットフォームエンジニアがランディングゾーンの設計と移行境界の承認を担い、その状態を永続化した移行状態グラフを介して、アプリ開発者が権限分離されたフォルダの中で個々のワークロードの翻訳を非同期に進められる。専用のCLIバイナリや中央コントロールプレーンを必要とせず、既存の開発環境からGit経由で協調作業できるオープンソース構成になっている点も、大規模かつ複数チームにまたがる移行を想定した設計といえる。 コンサルティング企業Persistentのシュリバスタバ氏(EVP)は、企業のクラウド刷新における最大の障壁は実行リスクと予測不可能性であるとしたうえで、生のチャットプロンプトとは異なり、構造化された状態永続化、プラットフォームとアプリチーム間のペルソナ境界、そして交渉の余地のない人間承認ゲートを組み合わせている点を評価するコメントを寄せている。Google CloudはGKE agentic migrationをGitHub上で公開しており、オンボーディングガイドに沿ってサンプルのEKSリポジトリで試すことができるとしている。

概要 Ubuntu搭載のLinuxカーネルに存在するAF_UNIXソケット関連のuse-after-free脆弱性(CVE-2026-80521、CVSS 7.8)を悪用し、DockerやKubernetesのコンテナからホストのroot権限を奪取できる公開エクスプロイトが登場した。セキュリティ研究グループDepthFirstが9月22日にエクスプロイトコードを公開したが、Ubuntu側のパッチはまだ提供されておらず、AWS・Azure・GCPなど主要クラウド上で稼働するワークロードにも影響が及ぶ可能性がある。 技術的な詳細 脆弱性は、ローカルプロセス間通信を管理するAF_UNIXソケットのカーネル側ガベージコレクション機構に存在する。レースコンディションにより、ガベージコレクターがソケット参照を解放した後もそのポインタがカーネル内部の永続リストに残ってしまうことがあり、後続の回収処理がこの解放済みメモリを指す古いポインタをたどることで、悪用可能な状態(use-after-free)が生じる。影響を受けるのはUbuntu 26.04、24.04、22.04の各LTSで、カーネル6.1系、6.6系、および6.10以降のバージョンが対象となる。DockerやKubernetesの既定のseccompプロファイルはAF_UNIXソケットへのアクセスを許可しているため、通常の権限のコンテナ内からでも攻撃コードを実行できる点が問題を深刻にしている。 修正状況と対応 上流のLinuxカーネルでは8月6日にすでに修正が取り込まれ、カーネル7.1.10および7.2で対応済みとなっている。一方でUbuntuのセキュリティトラッカー上のステータスは「vulnerable, work in progress」のままで、9月27日時点でも公式パッチは未提供の状態が続く。現時点でCISAの既知の悪用済み脆弱性(KEV)カタログには掲載されておらず、実際の攻撃への悪用が確認された報告もないが、公開エクスプロイトが出回ったことで悪用のハードルは大きく下がったといえる。 なお、この脆弱性はAI支援による脆弱性検出によって発見された経緯があり、OpenAIの研究者による独立した発見とも重なっていたという。機械学習を活用した脆弱性研究の進展が、コンテナエスケープのリスク発見を加速させている一例として注目される。 影響と対策 パッチが未提供の間、クラウド上でマルチテナントのコンテナワークロードを運用する事業者にとっては、ホストroot権限を奪われるリスクが現実的な脅威となる。対策としては、影響を受けるカーネルに上流の修正パッチを直接適用すること、または信頼できないワークロードをFirecrackerやKata ContainersなどのマイクロVM分離に移行することが挙げられる。DepthFirstとUbuntuのいずれも暫定的な回避策は公開していない。Ubuntu側の修正版が提供されるまでは、コンテナの信頼境界を過度に信用しない運用が求められる。

概要 Cloudflareは、同社のコンテナ実行環境「Containers」（および未信頼コードやAIエージェントを実行する「Sandboxes」）において、削除済みコンテナが使用していたディスクブロックが別テナントのコンテナから読み取れる脆弱性を修正したと発表した。原因は、ストレージ層で採用しているLinuxのdm-thin（device mapper thin provisioning）のプール設定に含まれていた「skip_block_zeroing」オプションで、これが有効になっていたため新規に割り当てられる64KiB単位のディスクブロックが消去されず、前の利用者のデータがそのまま残存する状態になっていた。セキュリティ企業Accomplishの研究者Oren Yomtovが9月4日にバグバウンティ経由で報告し、Cloudflareは同日中に修正をマージ、9月19日までに全ホストでの是正作業を完了させたとしている。 脆弱性の技術的詳細 dm-thinはブロックを64KiB単位で割り当てるが、コンテナが実際に書き込むデータはそれより小さいことが多い。研究者のPoC（概念実証）は、この差分を突く形で成立した。ext4ファイルシステムの空き領域のうち64KiB境界に対応する箇所を特定し、そこにわずか4KiBのファイルを書き込むと、新規ブロック割り当てがトリガーされる。しかしskip_block_zeroing設定下では、書き込んだ4KiB分だけが上書きされ、残りの60KiBには直前の所有者のデータがそのまま残る。これをraw-device（生デバイス）レベルで読み取ることで、他テナントの残存データを回収できた。 研究者はext4のメタデータチェックサムを利用して、自分のファイルシステムに属さないディレクトリブロックを識別する手法を確立し、実環境での影響を検証した。その結果、6つの本番環境で2,700個の外部ディレクトリiノードを検出し、24回の試行のうち18回、また4大陸に分散する22の基盤ノードのうち20ノードで残存データの観測に成功した。回収されたデータには、ディレクトリ構造だけでなく、構造的に完全なSQLiteデータベースのページも含まれていたという。 対応と影響評価 Cloudflareの対応は段階的に行われた。まずskip_block_zeroing設定をフリート全体（全サーバー群）から削除し、新規に割り当てられるストレージブロックのゼロクリアを有効化した。続いて、既存の稼働中コンテナディスクと、事前キャッシュされていたOCIイメージレイヤーを廃棄し、オフピーク時間帯にホストVMを再起動してイメージキャッシュを一掃した。9月4日15:26 UTCの報告からランタイム修正のマージまでは6時間程度、全ホストでのキャッシュスナップショット削除完了までは9月19日15:03 UTCまでを要した。研究者による独立した再検証でも、修正後はPoCが機能しなくなったことが確認されている。 Cloudflareはディスクi/oのテレメトリを精査した結果、この攻撃経路を通じた活動としては研究者自身とCloudflareエンジニアによる認可済みテストのみが検出され、第三者による悪用の痕跡は見つかっていないとしている。ただし、影響範囲にはAIエージェントなど未信頼コードを実行する用途で使われるSandboxesも含まれており、マルチテナント環境でのストレージ再利用が持つリスクの大きさを改めて示す事例となった。ゼロクリアを前提としないthin provisioning設定は性能上のメリットがある一方、テナント分離が要求される環境では見落としやすい落とし穴であり、他のクラウドプロバイダーやコンテナ基盤の運用者にとっても設定点検の教訓となりそうだ。

概要 Anthropicは9月24日から25日にかけて、Akamai Technologiesとの間で7年間・116億ドル規模のクラウドインフラ契約を結んだと発表した。今年5月時点で報じられていた契約規模は18億ドルとされており、わずか数か月で6倍以上に膨れ上がった格好だ。契約の特徴は、AI企業のインフラ調達では一般的なGPUではなく、Akamai Cloudが持つ世界数千拠点のポイント・オブ・プレゼンスを活用した分散型のCPU(汎用プロセッサ)インフラに焦点を当てている点にある。AIエージェントが処理するタスクが多様化する中で、推論以外の汎用コンピューティング需要が増していることが背景にあるとみられる。用途の詳細は両社とも明らかにしていない。契約は条件付きで、Akamai側が配信・可用性の要件を満たすことが前提となっており、一定の条件下ではいずれの当事者も解約できる。発表を受けてAkamai株は時間外取引で一時17〜22%上昇し、同社史上最大の契約となった。 新株予約権を組み込んだ契約構造 今回の契約で目を引くのが、AkamaiがAnthropicに付与する新株予約権(ワラント)だ。ワラントは非議決権の転換優先株式で、行使価格は1株111.33ドル、最大でAkamaiの発行済み普通株式の5%(約770万株)に相当する。まず116億ドルの契約締結時点で約2%分がベストし、その後はAnthropicの追加支出に連動して段階的にベストが進む仕組みで、契約には最大90億ドルの拡張条項が盛り込まれている。この拡張が実行された場合、30億ドルごとに約1%ずつワラントが積み増され、拡張分と合わせた契約総額は最大約200億ドルに達する可能性がある。通常、AI企業のインフラ調達では調達先企業(Amazon、Google、Microsoft、AMDなど)がAnthropicに出資し、代わりにチップやクラウド容量を提供する形が一般的だが、今回のAkamaiとの契約はその逆で、供給企業であるAkamai側がAnthropicに新株予約権を付与するという異例の構造となっている。 Akamaiの収益見通しと株式市場の反応 Akamaiは今回の契約に伴い、総額約55億ドルの設備投資を見込んでいるほか、サプライチェーン部材やメモリの先行調達のため2026年中に追加で17億ドルの資本支出を計画しているとしている。一方で、この契約による収益貢献は2026年通期のガイダンスには影響しないとしており、実際の収益計上は2027年後半以降に1億5000万〜3億ドル規模で始まり、2028年末までに年間換算で約17億ドルのペースに達する見通しだ。Akamaiのトム・レイトンCEOは「Anthropicは AI革命を推進しており、大規模なAIインフラの構築・運用にあたってAkamaiの能力を選んでくれたことを大変嬉しく思う」と述べており、大規模言語モデル企業向けの新たな収益源としてAkamai Cloudの立ち位置を強調している。 Anthropicの膨張する調達額と財務リスク 今回の契約は、Anthropicがこの11か月間で積み上げてきたコンピュート調達契約の総額を5170億ドル超に押し上げた。先月にはAI向けクラウド企業Nscaleとの間で450億ドル規模の契約も締結しており、Anthropicは主要クラウド事業者に加え、幅広いパートナーとの間で巨額のインフラ調達を続けている。こうした急拡大するコミットメントについて、Dario Amodei CEO自身が「将来の収益見通しがわずかでも外れれば、会社が破産する可能性がある」との趣旨の警告を発しており、需要予測に基づいて先行投資を積み上げるAI業界特有のリスクを認めている。OpenAIのSam Altman CEOも同様に、コンピュートインフラへの支出が持続可能な水準を超えつつあることに懸念を示しており、AI企業各社が競って結ぶ巨大インフラ契約が業界全体の財務リスクとして意識され始めている状況がうかがえる。

概要 Microsoftは2026年9月23日、Azure Container Apps(ACA)の新しい実行基盤である「ACA Sandboxes」と、サーバーレスデプロイの新モデル「ACA Express」の一般提供(GA)を発表した。両者はプレビュー期間を経て正式版となり、エージェントワークロードと高速なWebアプリ配信という異なる要求に応える形で設計されている。ACA Expressはコンテナイメージから本番稼働までを最速で実現するデプロイモデルであり、その高速な起動とスケーリングを支える計算基盤として、ACA Sandboxesのマイクロ VM分離技術を採用している。ACA SandboxesはExpressだけでなく、GitHub Copilotのクラウドサンドボックスや Foundry Hosted Agentsなど、Microsoft社内の複数の製品がすでに基盤として利用しているという。 マイクロVM分離とサンドボックスの管理機能 ACA Sandboxesは、Azure Resource Manager(ARM)上のリソースである「サンドボックスグループ」として管理され、1グループに数千単位のサンドボックスをオンデマンドで含められる。各サンドボックスはディスクイメージから起動し、独自のカーネルと仮想ハードウェアを持つ「ハードウェア隔離されたマイクロVM」として実行され、CPU仮想化によってメモリ分離を強制する。これにより、信頼できないコードやマルチテナントのタスクを、強い分離境界の中で安全に実行できる。 ネットワーク制御は組み込みのエグレスプロキシが担う。ポリシーを設定しない場合、サンドボックスは無制限のアウトバウンドアクセスを持つため、既定拒否のポリシー、パスやメソッドによるマッチング、リクエスト変換、ルールの順序評価といった機能はすべてオプトインで有効化する設計になっている。状態管理も柔軟で、ディスク状態のみを保持する「停止」状態、ディスクとメモリの両方を保存するスナップショット、サンドボックス削除後も存続する永続ボリュームなど、複数の永続化オプションから選択できる。監査・テレメトリ機能(コンソール出力、OpenTelemetry信号、運用メトリクス、エグレス決定ログ)も作成時に明示的な設定が必要なオプトイン方式であり、ログ記録自体はポリシーの強制とは別機能である点に注意が必要だとされる。 ACA Expressによる高速デプロイ ACA Expressは、環境のプロビジョニングを待たずにコンテナアプリを直接作成できる、開発者およびエージェント向けの高速デプロイモデルだ。消費ベースのコンピュートで動作し、リクエストに応じてゼロからハイパースケールまで自動的にスケールし、アイドル時はゼロまでスケールダウンするため使用した分だけ課金される。環境プロビジョニング費用は発生せず、毎月最初の180,000 vCPU秒、360,000 GiB秒、200万リクエストは無料枠として提供される。コールドスタートからの起動はサブセカンドまで最適化されており、SaaSアプリケーションやAIアプリのフロントエンド、開発者向けツール、社内ダッシュボード、スタートアップの迅速なプロトタイピングといった用途に適する。 一方でExpressはHTTP中心のワークロードに特化しており、GPUワークロード、TCPサービス、ジョブ/バッチ処理、サービスディスカバリを伴うマイクロサービスといった用途には非対応で、それぞれ既存のサーバーレスGPUやワークロードプロファイル環境、Container Apps Jobsが代替手段として案内されている。HTTP/2やDapr、カスタムドメイン、OpenTelemetryといった機能も現時点ではサポート対象外だ。提供リージョンは日本(East/West)を含む40以上のAzureリージョンに及ぶ。 展望 ACA SandboxesはすでにGitHub CopilotのクラウドサンドボックスやFoundry Hosted Agentsの基盤として採用されており、Expressと合わせて一般提供されたことで、エージェント実行基盤としての実運用への採用が本格化するとみられる。マイクロVMによる強い分離と、サブセカンドの起動・スケーリングという両立が難しかった要件を単一の基盤で満たす設計は、今後増加が見込まれる自律型AIエージェントのマルチテナント実行や、信頼できないコードを大量に処理するサービスにとって、有力な選択肢になりそうだ。

概要 Googleは9月23日、Google Kubernetes Engine(GKE) 1.37にワークロードのレプリカ数をゼロまでスケールダウンできるネイティブなスケールツーゼロ機能を追加したと発表した。バッチ処理やイベント駆動型ワーカー、開発環境など、需要が断続的でアイドル期間の長いワークロードを対象に、使っていない時間帯のリソース消費とコストをゼロに抑えつつ、需要発生時には即座に再起動できる点が特徴だ。 技術的な仕組み 中核となるのはHorizontalPodAutoscaler(HPA)のminReplicas: 0設定と、Google Cloud Managed Service for Prometheusを経由した外部メトリクスの組み合わせだ。新設のAutoscalingMetricというカスタムリソースでPub/SubやCloud Monitoring、ロードバランサーのシグナルなどをPromQLクエリとして定義し、HPAのExternalメトリクスとして参照することで、アダプターを介さない統合されたメトリクスパイプラインを実現している。メトリクスが閾値を下回ればすべてのポッドを停止し、未処理タスクの発生などメトリクスが仕事の保留を示すと即座にデプロイメントを再起動する仕組みだ。 最大の課題であるコールドスタート(ノード起動に通常60〜90秒かかる)への対策として、GKEが管理する「キャパシティバッファ」が導入された。複数のゼロスケール対象ワークロードに即座に容量を提供する「アクティブバッファ」と、アクティブバッファよりも低コストで容量を補充する「スタンバイバッファ」を組み合わせることで、需要発生時の再スケールをほぼ瞬時に行えるとしている。 既存ソリューションとの違い GKEはこの機能をKEDA(Kubernetes Event-Driven Autoscaling)と比較し、優位性を強調している。KEDAではScaledObjectカスタムリソースと専用オペレーターの運用が必要で、大規模なフリートでは1万行を超えるYAML設定が発生しうるほか、ポーリング間隔やシグナル経路のホップ数によってコールドスタートの検知に遅延が生じやすいという。一方GKEのネイティブ機能は標準のHPAを拡張する形で提供され、追加コンポーネントの運用が不要な上、シグナルパスが内部化されているため反応速度も向上するとしている。 利用方法と今後の展望 導入は、(1)需要変動やアイドル期間のあるワークロードを特定し、(2)AutoscalingMetricとminReplicas: 0を設定したHPAを適用し、(3)必要に応じてキャパシティバッファを追加する、という3ステップで進められる。この機能の利用にはGKE 1.37以上が必要で、最適なパフォーマンスを得るにはキャパシティバッファの適切な設定も欠かせない。Googleは今後、開発環境を毎晩20時にゼロスケールし翌朝7時に復帰させるといった、スケジュールベースのスケーリング機能も追加していく方針を示しており、コスト最適化に向けたきめ細かな制御が今後さらに強化される見通しだ。

概要 Cloudflareは9月22日、Gitのブランチごとに本番環境に近い隔離されたプレビュー環境を自動生成する新機能「Worker Previews」を発表した。開発者はnpx wrangler previewコマンドを実行するだけで、各ブランチに専用のURL、環境変数、シークレット、バインディングを持つ環境をデプロイでき、本番環境のDurable ObjectsやContainerとは完全に分離された状態で動作する。記事はまず「ステージング環境で機能するコードが本番環境で異なる動作をするのは最悪だ」という開発者に馴染み深い課題を提起しており、AIコーディングエージェントが生成するコード量の増加に伴って、より包括的かつ高頻度なテストの必要性が高まっている背景を強調している。 技術的な仕組みと可観測性 Worker Previewsでは、Wrangler設定ファイルに「ベース設定」を一度定義しておき、個々のプレビュー環境ではその設定を部分的に上書きできる。これにより、環境変数やストレージバケットの構成をプレビューごとに柔軟にカスタマイズすることが可能だ。観測面ではWorkers Observabilityツールと統合されており、ログ、エラー、メトリクス、トレースをプレビュー単位で確認できるほか、各リクエストのライフサイクルをウォーターフォール形式で追跡できる。ブラウザ自動化を伴うテストの場合は、スクリーンショットやDOMイベントの録画機能も利用可能だ。またプレビューURLを独自ドメインで公開することもでき、OAuthやCORSといった本番環境同様の挙動を再現しつつ、Cloudflare Accessによる保護も設定できる。 AIエージェントとの親和性、顧客の評価 Worker Previewsは人間の開発者だけでなく、AIコーディングエージェントが自律的にテストループを回すことを念頭に設計されている点が特徴だ。Cloudflare自身も、オープンソースのエージェント統合プラットフォーム「CloudflareOS」の開発において社内検証に利用しており、複数のコンポーネントが実際に連携して動作して初めて明らかになるセキュリティ上の課題を早期に発見する目的で活用しているという。顧客からの評価も紹介されており、Supermemoryの創業者はHTTPフローやDurable Objectsを含むWorkerの変更をプレビュー環境で確認でき、問題を早期に検出できると述べている。またRampのシニアスタッフエンジニアは、Inspect AIエージェントのPRをスマートフォン上でもレビュー・テストできるようになった点を評価するコメントを寄せている。 今後の展開 Cloudflareは今後、複数のWorkerアプリケーションにまたがるプレビュー対応や、Queue ConsumersおよびWorkflowsの完全な隔離、さらに長期運用を前提としたステージング・QA環境向けサポートの拡充を計画している。Worker Previewsは現時点ですでに利用可能となっており、CloudflareはGitHubやDiscordコミュニティを通じて開発者からのフィードバックを募っている。AIエージェントによる開発が一般化するなかで、本番相当の環境で安全に検証できる仕組みは、今後の開発ワークフローの標準的な要素になっていく可能性がある。

概要 Kubernetesプロジェクトはコードネーム「Garhwal」を冠したバージョン1.37を正式リリースした。今回のリリースは安定性、セキュリティ、そしてAI/MLワークロードの最適化を重点テーマに据えており、合計67件のエンハンスメントが盛り込まれている。内訳はアルファ機能が27件、ベータへの昇格が23件、GA(一般提供)に到達したものが16件、非推奨・削除が1件となっており、クラスタ運用の基盤機能から先進的な機能まで幅広く手が入った形だ。次期バージョンの1.38は2026年12月にリリースされる予定である。 Metrics APIの安定化とAPIサーバーの堅牢化 今回のリリースで特に注目されるのが、metrics.k8s.ioとして提供されるMetrics APIが正式に安定版(Stable)へ到達したことだ。このAPIはノードやPodのヘルス監視の基盤であり、Horizontal Pod Autoscaler(HPA)やVertical Pod Autoscaler(VPA)、kubectl topコマンドなど、リソース監視・自動スケーリングに関わる主要機能が依存している。安定版化により、これらの機能を支えるインターフェースの互換性が長期的に保証されることになる。 あわせてGAに到達した「Resilient Watchcache Initialization」は、kube-apiserverの再起動時にetcdへリクエストが殺到して負荷が集中する問題を防ぐ機能で、再起動直後は限定的なリクエストのみを安全に処理し、それ以外はHTTP 429を返して制御する仕組みを備える。大規模クラスタにおけるコントロールプレーンの回復性を高める改善といえる。また、外部のmTLSブートストラップツールなしにPod間の安全な通信を実現する「Pod Certificates」もGAに到達し、サービスメッシュ導入のハードルを下げるものとして位置づけられている。 セキュリティとAI/MLワークロード向けの新機能 セキュリティ面では、Linuxのユーザー名前空間を活用してコアのノードコンポーネントを非rootで実行する「Rootless Kubelet」(フィーチャーゲートKubeletInUserNamespace)がベータに昇格した。コンテナエスケープが発生した際の影響範囲を縮小する狙いがあり、マルチテナント環境でのセキュリティ強化に直結する。 AI/MLワークロードの効率化という観点では、GPUに依存するワークロードのクラウドコストを削減する「HPA Scale to Zero」がベータへ進んだ。需要がない時間帯にPodのレプリカ数をゼロまで縮退させることで、高価なGPUリソースの遊休コストを抑制できる。このほかアルファ機能として、InPlacePodVerticalScalingSchedulerPreemptionによるワークロード認識型スケジューリング、デバッグやセキュリティ分析向けのPodチェックポイント・リストア機能、StatefulSetのローリング更新における「Recreate」戦略も導入されており、今後のベータ・GA昇格が注目される。 ストレージ管理の改善:未使用PVCの自動検出 ストレージ分野では、PersistentVolumeClaim(PVC)がどのPodからも参照されていない状態を自動検出するPersistentVolumeClaimUnusedSinceTime機能がベータに昇格し、デフォルトで有効化された。PVC保護コントローラーがPVCにUnusedという条件(Condition)を自動的に付与する仕組みで、そのPVCが現在いずれかの稼働中Podから参照されているかどうかを、手動でのトラッキングやカスタムツールを用意することなく可視化できる。 これまで大規模クラスタでは、孤立した(orphaned)ストレージリソースを特定するためにPodとPVCを手作業で突き合わせたり、独自のスクリプトを運用したりする必要があった。標準のCondition機構を通じてこの情報が提供されることで、未使用ストレージの削除によるコスト最適化や、利用状況に基づくキャパシティプランニング、さらにはこの条件を利用した自動削除ポリシーの構築が容易になる。運用コストの削減に直結する地味ながら実用的な改善であり、ストレージリソースが肥大化しがちな大規模環境ほど恩恵が大きいといえるだろう。

概要 Cloudflareは9月21日、サーバーレスプラットフォームWorkers上でPythonを実行する「Python Workers」を一般提供(GA)段階に進めたと発表した。2年前にベータ機能として導入されて以来、多くの開発者がすでにPython Workers上でアプリケーションを構築してきたが、今回のGA化により、PythonはJavaScriptと並んでCloudflareデベロッパープラットフォームの第一級言語として正式に位置づけられる。FastAPI、Django、FlaskといったWSGI/ASGI対応の主要Webフレームワークを、JavaScriptのグルーコードを書くことなく、そのままエッジランタイム上で直接実行できるようになった点が最大のポイントだ。 技術的な仕組み Python WorkersはWebAssembly(Wasm)を基盤としており、Cloudflareは2018年からWasmをサポートしてきた実績を土台に、Pyodide(PythonインタプリタをWasmにコンパイルしたプロジェクト)を用いてPythonコードをエッジ上で実行している。さらにCloudflareは、この仕組みを標準化する提案として「PEP 783」を通じて「PyEmscripten」プラットフォームの策定にも関与しており、単なる自社実装にとどまらずPythonエコシステム全体への貢献を図っている。データベース接続についてはカスタムのsocket syscall実装によりTCPソケットを扱えるようにし、PostgreSQLやMySQLの標準的なドライバもそのまま利用可能にした。 開発者への影響 今回のGA化で特に強化されたのが、Workers AI、R2、D1、Hyperdrive、Durable Objects、Queues、Workflowsといった既存のCloudflareサービスとのネイティブ統合だ。型変換の仕組みをランタイムとPython SDKの両方に統合したことで、たとえばキューへのメッセージ送信はself.env.QUEUE.send({"key": "value"})のようにPythonのデータ型をそのまま渡すだけで済むようになり、これまで必要だった複雑なJavaScript相互運用コードを書く必要がなくなった。OpenAIやLangChainなど主要なAI関連ライブラリにも対応しており、Pythonの豊富なエコシステムに慣れた開発者が、使い慣れたパターンとライブラリを活かしながらグローバルに自動スケーリングするアプリケーションをそのまま構築できる点が実務上の大きなメリットとなる。 制限事項と今後の展望 一方で、ネイティブにC/C++/Rustなどの拡張モジュールを含むパッケージについては、Wasm対応が別途必要であり、パッケージエコシステム全体としてはまだ移行途上にある点には留意が必要だ。Cloudflareは今後、パフォーマンスとメモリ効率のさらなる向上、対応パッケージの拡充、そして開発者フィードバックに基づく継続的な改善を進める方針を示しており、PyEmscriptenエコシステムの普及を後押ししていく構えだ。JavaScript以外の言語でサーバーレスエッジ開発を行いたいPython開発者にとって、今回のGA化は本番導入の判断材料となる重要な節目と言えるだろう。