生成日時: 2026年04月08日 対象期間: 過去 24 時間以内 処理モード: 詳細モード 更新件数: 4 件
公開日時: 2026年04月07日 19:30:53 UTC リンク: Generally Available: Azure Red Hat OpenShift adds NVIDIA H100 and H200 GPU support
アップデートID: 559547 情報源: Azure Updates API
カテゴリ: Launched, Containers, Azure Red Hat OpenShift, Open Source, Regions & Datacenters
要約:
何が更新されたか
Azure Red Hat OpenShift（ARO）が、NVIDIA H100およびH200 GPUを搭載したAzure仮想マシンSKUのサポートを一般提供開始しました。
主な変更点や新機能
これにより、ARO上でNVIDIA H100およびH200 GPUを活用した大規模なAI、機械学習、ハイパフォーマンスコンピューティング（HPC）ワークロードの実行が可能となります。完全マネージドなOpenShift環境で最新世代のGPUリソースを利用できる点が主な強化ポイントです。
影響を受ける対象
AIや機械学習、HPCワークロードをAzure Red Hat OpenShift上で運用している、または今後運用を検討している技術者や開発者が対象となります。
注意点があれば記載
NVIDIA H100およびH200 GPU対応のAzure仮想マシンSKUの利用には、対応リージョンや利用可能なSKUに関する制約がある場合があります。詳細は公式ドキュメントを確認してください。
詳細:
Azure Red Hat OpenShift（ARO）は、NVIDIA H100およびH200 GPUを搭載したAzure Virtual Machine SKUのサポートを新たに一般提供開始しました。本アップデートの背景には、AI、機械学習（ML）、およびハイパフォーマンスコンピューティング（HPC）領域における大規模かつ高性能な計算リソースへの需要の高まりがあります。これにより、ユーザーはフルマネージドなOpenShift環境上で、最新のNVIDIA GPUを活用した大規模なAIモデルのトレーニングや推論、データ解析、シミュレーションなどのワークロードを実行できるようになります。
具体的には、AROクラスターのノードプールとしてNVIDIA H100およびH200 GPUを搭載したAzure VM SKUを選択可能となり、これらのGPUを必要とするPodやワークロードをOpenShift上でシームレスにデプロイ・管理できます。これにより、Kubernetesベースのワークロードに対しても、GPUリソースの割り当てやスケジューリングを効率的に行うことが可能です。
技術的な仕組みとしては、AROのマネージドサービス基盤上でGPU対応のAzure VMをノードとして組み込むことで、OpenShiftのスケジューラやリソース管理機能と連携し、GPUリソースの割り当てや利用状況の監視が実現されています。NVIDIA GPUドライバやCUDAなどの必要なソフトウェアスタックは、OpenShiftのノードイメージやOperatorを通じて適切に管理されます。
活用シナリオとしては、生成AIモデルの大規模トレーニング、ディープラーニング推論、科学技術計算、金融リスク解析など、高度な計算能力を要するユースケースが想定されます。これらのワークロードを、Azureのセキュアかつスケーラブルなインフラストラクチャ上で、OpenShiftのエンタープライズ向け機能とともに運用できます。
注意点としては、GPU搭載VMの利用には追加コストが発生すること、またGPUリソースの利用には対応するコンテナイメージやライブラリの準備が必要となる点が挙げられます。さらに、GPUノードの可用性やスケール要件については、Azureの各リージョンで提供されるSKUや在庫状況に依存します。
関連するAzureサービスとしては、Azure Machine LearningやAzure Kubernetes Service（AKS）などが挙げられますが、AROはRed Hat OpenShiftのフルマネージドサービスとして、これらと連携しつつ、エンタープライズ向けのKubernetes基盤を提供します。今回のアップデートにより、ARO環境で最新GPUリソースを活用した先進的なAI・HPCワークロードの展開がより容易になりました。
公開日時: 2026年04月07日 17:45:41 UTC リンク: Generally Available: Disable HTTP proxy in AKS
アップデートID: 557857 情報源: Azure Updates API
カテゴリ: Launched, Compute, Containers, Azure Kubernetes Service (AKS), Features
要約:
何が更新されたか
Azure Kubernetes Service（AKS）で、HTTPプロキシの無効化機能が一般提供（GA）されました。
主な変更点や新機能
これまでAKSクラスターで設定されたHTTPプロキシは、ネットワーク要件の変更時に設定変更や削除が困難で、運用中のクラスターに影響を与えることがありました。今回のアップデートにより、管理者はAKSクラスター上でHTTPプロキシ設定を無効化できるようになりました。
影響を受ける対象
AKSクラスターを運用しており、アウトバウンド通信の制御にHTTPプロキシを利用している組織や管理者が対象です。ネットワーク構成変更時の柔軟性が向上します。
注意点があれば記載
HTTPプロキシの無効化は、クラスターの外部通信経路やセキュリティポリシーに影響する可能性があります。無効化前にネットワーク要件やセキュリティ設定を十分に確認し、必要に応じて関係者と調整を行うことを推奨します。
詳細:
本アップデートは、Azure Kubernetes Service（AKS）においてHTTPプロキシの無効化機能が一般提供（Generally Available）となったことを示しています。従来、組織がアウトバウンドトラフィックを制御するためにHTTPプロキシを利用している場合、ネットワーク要件の変更に応じてプロキシ設定を変更または削除する必要が生じていました。しかし、これらの変更は稼働中のクラスターに対して影響を及ぼす可能性があり、運用上の課題となっていました。
今回のアップデートにより、AKSの管理者はHTTPプロキシ設定を明示的に無効化できるようになりました。これにより、ネットワーク要件の変更時にプロキシ設定の削除や変更を柔軟かつ安全に実施でき、クラスターの安定運用が支援されます。具体的には、AKSクラスターの構成においてHTTPプロキシの利用を停止するオプションが提供され、これを用いることでクラスター全体のアウトバウンド通信がプロキシを経由しないように設定できます。
技術的な実装方法としては、AKSのクラスター設定においてHTTPプロキシの無効化オプションを選択することで適用されます。これにより、クラスター内のノードやPodが外部と通信する際にプロキシ設定が参照されなくなります。これらの設定変更はAzure CLIやAzure Portalなど、既存の管理ツールを通じて実施可能です。
この機能の活用シナリオとしては、ネットワーク構成の変更やセキュリティポリシーの見直しに伴い、プロキシ経由の通信を廃止したい場合や、プロキシ障害時の迅速な切り替えが求められる場合などが挙げられます。また、プロキシ設定が不要となった環境への移行時にも有効です。
注意点としては、HTTPプロキシを無効化することで、これまでプロキシを経由していた通信が直接インターネットに接続されるため、ネットワークセキュリティグループ（NSG）やファイアウォール設定など、他のセキュリティ対策との整合性を十分に確認する必要があります。また、プロキシを利用した監査やトラフィック制御が不要となる場合でも、組織のセキュリティポリシーに従った運用が求められます。
関連するAzureサービスとの連携については、AKSクラスターが他のAzureサービス（例：Azure Monitor、Azure Policyなど）と連携している場合、HTTPプロキシ設定の変更がそれらの通信に影響を与える可能性があるため、事前に影響範囲を確認し、必要に応じて設定の見直しを行うことが推奨されます。
以上のように、本アップデートはAKSクラスターのネットワーク構成管理を柔軟かつ安全に行うための重要な機能追加となります。
公開日時: 2026年04月07日 17:15:12 UTC リンク: Generally Available: Azure Functions now supports MCP resource triggers
アップデートID: 559981 情報源: Azure Updates API
カテゴリ: Launched, Compute, Containers, Internet of Things, Azure Functions, Features, Services
要約:
何が更新されたか
Azure FunctionsがMCP（Model Context Protocol）リソーストリガーを正式にサポートするようになりました。
主な変更点や新機能
これまでAzure Functions上で構築したMCPサーバーではツールのみを公開できましたが、今回のアップデートにより、MCPリソーストリガーを利用して、Azure FunctionsホストのMCPサーバーからリソースを直接公開できるようになりました。
影響を受ける対象
MCPサーバーをAzure Functions上で構築・運用している開発者や、MCPプロトコルを利用したアプリケーションの開発者が主な対象となります。
注意点があれば記載
本機能を利用することで、リソースの公開範囲やアクセス管理に注意が必要です。既存のMCPサーバー構成に変更を加える場合は、動作確認やセキュリティ設定の見直しを推奨します。
詳細:
本アップデートは、Azure FunctionsにおいてMCP（Model Context Protocol）リソーストリガーのサポートが一般提供（GA）となったことを示しています。従来、Azure Functions上でMCPサーバーを構築する際、開発者はツールの公開は可能でしたが、リソース自体を直接公開することはできませんでした。今回のアップデートにより、Azure Functionsをホスト環境としたMCPサーバーから、MCPリソースを直接エクスポーズ（公開）することが可能となりました。
この機能強化の主な目的は、MCPを利用したアプリケーション開発において、リソースの管理や連携をより柔軟かつ効率的に行えるようにする点にあります。具体的には、MCPリソーストリガーをAzure Functionsで利用可能とすることで、MCPプロトコルに準拠したリソースイベントの検知や処理をサーバーレスアーキテクチャ上で実現できます。これにより、MCPサーバーが管理するリソースの状態変化やイベント発生時に、Azure Functionsが自動的にトリガーされ、必要な処理を実行できるようになります。
技術的な仕組みとしては、Azure Functionsのトリガー機構にMCPリソーストリガーが追加された形となります。開発者は、Azure FunctionsのトリガーとしてMCPリソースイベントを指定し、イベントドリブンな関数実装を行うことができます。これにより、MCPサーバーがリソースの変更や操作を検知した際に、該当するAzure Functionsが呼び出される仕組みとなります。
活用シナリオとしては、MCPリソースの作成・更新・削除といったイベントに応じて自動的に処理を実行したい場合や、MCPリソースを中心としたワークフロー自動化、監査ログの記録、外部システムとの連携処理などが挙げられます。たとえば、MCPリソースの状態が変更された際に、Azure Functionsを用いて通知を送信したり、追加のデータ処理を行うことが可能です。
注意点や制限事項については、本アップデートの情報では詳細は明記されていませんが、MCPリソーストリガーの利用にあたっては、対応するMCPサーバーのバージョンやAzure Functionsの設定要件など、事前に公式ドキュメントで確認することが推奨されます。
また、Azure Functionsは他のAzureサービスと連携しやすい特徴を持っているため、MCPリソーストリガーを活用したイベント駆動型アーキテクチャを、Azure Logic AppsやAzure Event Grid、Azure Storageなどと組み合わせて拡張することも可能です。これにより、MCPリソースを中心とした高度な自動化や統合シナリオを実現できます。
詳細は公式アップデートページ（https://azure.microsoft.com/updates?id=559981）を参照してください。
公開日時: 2026年04月07日 17:00:23 UTC リンク: Generally Available: Pod CIDR expansion in AKS
アップデートID: 557907 情報源: Azure Updates API
カテゴリ: Launched, Compute, Containers, Azure Kubernetes Service (AKS), Features
要約:
何が更新されたか
Azure Kubernetes Service（AKS）において、Pod CIDR拡張機能が一般提供（GA）となりました。
主な変更点や新機能
これまでAKSクラスターでPod用IPアドレス（Pod CIDR）が枯渇した場合、環境を再構築する必要がありました。今回のアップデートにより、オーバーレイネットワークを利用しているAKSクラスターでは、既存クラスターのPod CIDR範囲をインプレースで拡張できるようになりました。これにより、運用中のクラスターでPod IPアドレスの不足を解消し、サービスの中断や再構築の手間を削減できます。
影響を受ける対象
オーバーレイネットワークを利用しているAKSクラスターが対象です。Pod数の増加やスケーラビリティ向上を求める運用現場に特に有用です。
注意点があれば記載
Pod CIDR拡張はオーバーレイネットワークを利用している場合のみ利用可能です。既存のクラスター設定やネットワーク構成によっては追加の検証が必要となる場合があります。詳細は公式ドキュメントをご確認ください。
詳細:
本アップデートは、Azure Kubernetes Service（AKS）におけるPod CIDR拡張機能の一般提供（GA）を発表するものです。従来、AKSクラスタに割り当てられたPod IPアドレス範囲（Pod CIDR）が枯渇した場合、運用チームは新たなIPアドレス空間を割り当てるためにクラスタ全体を再構築する必要がありました。これにより、システムのダウンタイムや運用上の混乱が発生し、サービス継続性に影響を及ぼしていました。
今回のアップデートにより、オーバーレイネットワークを利用しているAKSクラスタにおいて、既存のPod CIDR範囲をインプレースで拡張できるようになりました。これにより、クラスタの再構築を伴わずにPodのIPアドレス空間を増やすことが可能となり、運用効率が大幅に向上します。具体的には、クラスタのPod CIDRが枯渇しそうな場合や、ワークロードの増加に伴いPod数を拡張したい場合に、追加のIPレンジを割り当てることで、既存の環境を維持しつつリソース拡張が実現できます。
技術的には、オーバーレイベースのネットワークプラグインを利用しているAKSクラスタが対象となります。Pod CIDR拡張は、AKSの管理プレーンから設定を変更することで実施され、既存のPodやノードに影響を与えることなく、追加のIPアドレス範囲がクラスタ全体に適用されます。この機能により、IPアドレスの枯渇によるサービス停止リスクを低減し、より柔軟なスケーリングが可能となります。
活用シナリオとしては、急激なワークロード増加やマルチテナント環境でのPod数拡張、または長期運用中のクラスタにおけるIPアドレス空間の見直しなどが挙げられます。これまでのようにクラスタ再構築や大規模な移行作業を伴うことなく、既存環境のままIPレンジを拡張できるため、運用コストやリスクの削減に寄与します。
注意点としては、本機能はオーバーレイネットワークを利用しているAKSクラスタに限定されている点が挙げられます。Azure CNI（クラウドネイティブインターフェース）ベースのクラスタなど、他のネットワーク構成では利用できない場合があります。また、Pod CIDR拡張の操作は慎重に行う必要があり、事前に十分な検証とバックアップを推奨します。
本機能は、AKSの他の管理機能やAzure Monitor、Azure Policyなどの運用管理サービスとも連携可能であり、運用自動化や監視体制の強化にも活用できます。詳細は公式ドキュメントやアップデート情報を参照してください。
このレポートは自動生成されました - 2026-04-08 12:02:17 JST