Azure

MySQL運用データを分析基盤へ、ETL不要で即時連携 Microsoftは、Azure Database for MySQL のデータを Microsoft Fabric にほぼリアルタイムでレプリケートできる新機能「Fabric Mirroring」のパブリックプレビューを開始した。 これまでMySQLの運用データを分析基盤へ取り込むには、ETL（Extract/Transform/Load）パイプラインを自前で設計・構築・運用するか、Azure Data FactoryなどのデータインテグレーションサービスをCI/CDと組み合わせる必要があった。データエンジニアリングのコストと複雑さが採用の壁となっていたが、Fabric Mirroringはその障壁を取り除く。 Fabric Mirroringとは Fabric Mirroringは、データベースの変更をキャプチャしてターゲット側に継続的に反映する CDC（Change Data Capture） 技術をベースとした機能だ。Azure Database for MySQLに蓄積された運用データを、ほぼリアルタイムでMicrosoft FabricのOneLakeへ自動同期する。 主な特徴は以下のとおり。 ETLパイプライン構築が不要：複雑なデータ変換・転送処理をノーコードで実現 ほぼリアルタイムの同期：本番DBへの負荷を最小化しつつ最新データを分析基盤へ反映 Fabric上でそのまま分析可能：同期されたデータはFabricのSQL分析エンドポイントやPower BIから直接クエリ可能 運用コストの削減：データパイプラインの監視・メンテナンス工数が不要になる 日本企業への影響 国内でもMySQLはECサイト・SaaSプロダクト・基幹システムのDBとして広く採用されている。従来はBIや機械学習向けにデータを活用しようとすると、専任のデータエンジニアによるパイプライン設計が必要だった。Fabric Mirroringにより、開発チームが直接・低コストでFabricの分析・AI機能を活用できるようになる点は、中小規模のチームにとって特にメリットが大きい。 Microsoft Fabricは2023年に一般提供が開始されたデータ分析統合プラットフォームで、データウェアハウス・データレイク・リアルタイム分析・Power BIを一体化した基盤だ。現在すでに Azure SQL Database や Azure Cosmos DB 向けのMirroringが提供されており、今回のMySQL対応によりサポートDBの幅がさらに広がった。 利用開始方法 パブリックプレビュー期間中はAzureポータルまたはFabricポータルから設定可能。対象はAzure Database for MySQL – Flexible Serverで、既存のMySQLインスタンスから数ステップでミラーリングを有効化できる。プレビュー期間中の追加料金については公式ドキュメントを参照のこと。 ETLレスのデータ連携はデータドリブン経営の加速を後押しする。本番運用中のMySQLをそのままFabricの分析パワーと組み合わせたい場合、今が試し時だ。 元記事: Fabric Mirroring for Azure Database for MySQL – Public Preview

Azure Arc対応AKSのWindows Server 2019、本日をもってサポート終了 Microsoftは2026年4月1日をもって、Azure Arc対応AKS（Kubernetes Service）におけるWindows Server 2019ノードのサポートを正式に終了した。これにより、Windows Server 2019ベースのノードイメージの新規提供およびセキュリティパッチの配信が停止される。 影響範囲と具体的なリスク 今回の変更で最も注意が必要なのは、Kubernetesバージョンのアップグレード可否に直結する点だ。Windows Server 2019のノードが残存しているクラスターでは、今後のKubernetesバージョンアップグレードが実行不可能になる。セキュリティパッチが適用されないノードを抱えたまま本番環境を運用し続けることは、コンプライアンス上のリスクはもちろん、実際の攻撃面の拡大にもつながる。 オンプレミスやエッジ環境にKubernetesクラスターを展開するためにAzure Arc対応AKSを活用している企業にとって、この変更は看過できない。特に、Windows向けコンテナワークロードを運用している環境では早急な対応が求められる。 移行先：Windows Server 2022 Microsoftが推奨する移行先はWindows Server 2022だ。Windows Server 2022はメインストリームサポートが2026年10月まで、延長サポートが2031年10月まで提供される予定であり、今後数年間の安定した運用基盤として選択できる。 移行の基本的な手順は以下の通りだ： 既存のWindows Server 2019ノードプールの棚卸し Windows Server 2022イメージを指定した新規ノードプールの作成 ワークロードの段階的な移行（drain & cordon） 旧ノードプールの削除 なお、LinuxノードのみのクラスターはKubernetesのバージョンアップグレードに影響を受けない点も確認しておきたい。 日本企業への影響 国内では製造業や流通業を中心に、Azure Arc対応AKSをオンプレミス・エッジ環境のコンテナ基盤として採用するケースが増加している。既にWindows Server 2019を使用中のクラスターを持つ組織は、本日以降のセキュリティパッチが提供されない状態にあることを認識した上で、速やかに移行計画を策定・実行する必要がある。 移行作業を先送りにするほど、脆弱性の累積とアップグレード対応の複雑化が進む。Microsoftの公式ドキュメントと移行ガイドを参照しながら、計画的な対応を進めてほしい。 元記事: Windows Server 2019 Retirement on AKS enabled by Azure Arc

MicrosoftとNVIDIAが原子力×AI協業——インフラのボトルネック解消へ Microsoftは、原子力エネルギー産業のデジタル変革を加速するため、NVIDIAとの戦略的協業「AI for Nuclear」を発表した。この取り組みは、業界が長年抱えてきたインフラのボトルネック——すなわち、原子力発電所の新設・刷新が「理想論」から「実行」へ移行できない構造的課題——の解消を狙ったものだ。 原子力産業が直面するボトルネック 原子力発電所の建設・運用にはきわめて複雑な許認可プロセスが伴う。各国の規制当局への申請書類は膨大で、審査期間も長期にわたる。加えて、次世代小型モジュール炉（SMR: Small Modular Reactor）をはじめとする新型炉の設計には高度なシミュレーション技術が必要であり、既存の計算インフラでは処理能力が不足しているケースも多い。 こうした課題に対して、MicrosoftとNVIDIAが提供するのは、Azure クラウドと NVIDIA の GPU コンピューティングを組み合わせたエンドツーエンドのAIツール群だ。 3つの主要領域でAIを活用 今回の協業では、主に以下の3領域でAIを適用する。 1. 許認可プロセスの効率化 規制申請に必要な膨大な文書作成・管理をAIが支援。過去の申請事例や規制要件を学習したモデルが、ドラフト生成やコンプライアンスチェックを自動化する。これにより、数年単位かかることもある許認可期間の大幅な短縮が期待される。 2. 設計・シミュレーションの加速 NVIDIA の高性能GPUを活用した物理シミュレーションにより、原子炉設計の反復サイクルを高速化する。熱流体解析や中性子輸送計算など、従来はスーパーコンピュータが必要だった処理をクラウド上で柔軟にスケールアウトできる。 3. 運用の最適化 稼働中のプラントでは、センサーデータや運転ログをリアルタイム解析するAIが、予知保全や異常検知を担う。設備の故障を事前に検知し、計画外停止を減らすことで、稼働率の向上とコスト削減を同時に実現する。 日本への示唆 日本においても、2011年の東京電力福島第一原発事故以降に停止した原発の再稼働審査や、次世代炉の導入議論が続いている。原子力規制委員会への許認可申請は世界でも屈指の複雑さを誇り、AIによる審査支援の需要は高い。MicrosoftのAzureはすでに国内データセンターを複数擁しており、今回のAI for Nuclearソリューションが国内電力会社にも展開される可能性がある。 Microsoftは近年、自社データセンターの電力需要増大を背景にスリーマイル島原発の電力購入契約を締結するなど、原子力への積極的な関与を見せている。AIとクラウドの普及が電力消費を押し上げる中、その電力源としての原子力と、原子力産業を支えるAI——という相互補完的な構図が鮮明になりつつある。 今後、具体的なツールの提供時期や対応する規制フレームワークの詳細については、MicrosoftおよびNVIDIAの追加発表が待たれる。 元記事: AI for nuclear energy: Powering an intelligent, resilient future

Azure DevOps MCPサーバーがMicrosoft Foundryに登場 Microsoftは、Azure DevOps向けのMCP（Model Context Protocol）サーバーをMicrosoft Foundryで正式に提供開始したと発表した。これにより、AIエージェントがAzure DevOpsのパイプライン・作業項目（Work Items）・リポジトリを自然言語で直接操作できるようになる。 MCPとは何か MCP（Model Context Protocol）は、AIモデルと外部ツール・データソースを標準的なインターフェースで接続するためのオープンプロトコルだ。Anthropicが提唱し、近年急速に採用が広がっている。MCPサーバーを経由することで、AIエージェントはアプリケーションのAPIを直接知らなくても、自然言語の指示だけで外部システムを操作できるようになる。 何ができるようになるのか Azure DevOps MCPサーバーを使うことで、開発者やAIエージェントは以下のような操作を自然言語で実行できるようになる。 パイプラインの管理: ビルドやリリースパイプラインの状態確認、トリガー実行 作業項目の操作: バックログの確認・更新、スプリント計画の調整 リポジトリへのアクセス: コードの参照やプルリクエストの状況確認 たとえば「先週マージされたPRの一覧を見せて」「今日のビルドが失敗した原因を調べて」といった指示を、AIエージェントが直接Azure DevOpsに問い合わせて答えられるようになる。 リモートMCPサーバープレビューも同時提供 今回の発表と合わせて、リモートMCPサーバーのプレビューも提供が開始された。従来のMCP接続はローカル環境でのプロセス起動が前提だったが、リモートMCPサーバーにより、クラウド上でホストされたMCPサーバーへのHTTPS接続が可能になる。これにより、エンタープライズ環境での大規模なエージェント活用がより現実的になる。 エージェント駆動のDevOpsへ この動きは「DevOpsのエージェント化」というトレンドの加速を示している。GitHub CopilotやAzure AI Foundryとの連携により、コードの記述から本番デプロイまでの一連のフローをAIエージェントが補佐・自動化する未来が近づいている。 日本でもAzure DevOpsを活用している企業は多く、CI/CDパイプラインや作業管理にAIエージェントを組み込む需要は高い。Microsoft Foundryのエコシステムを通じて、こうした機能が標準的に利用できるようになることは、DevOpsチームの生産性向上に大きく貢献するだろう。 利用開始方法 Azure DevOps MCPサーバーはMicrosoft Foundry経由で利用可能。Azure DevOpsのサービス接続とMicrosoft Foundryプロジェクトを組み合わせることで、既存のDevOps環境にAIエージェントを統合できる。 元記事: Azure DevOps MCP Server Now Available in Microsoft Foundry

Azure App Service証明書、業界標準変更で発行方式が刷新へ Microsoftは、CA/Browser Forum（CA/B Forum）が策定する業界全体の証明書基準変更に伴い、Azure App ServiceのマネージドTLS証明書に関する重要なアップデートを発表した。この変更は2026年内に適用が予定されており、Azureでウェブアプリを運用する開発者・運用担当者は内容を把握しておく必要がある。 何が変わるのか 影響を受けるのは以下の2種類の証明書だ。 無料マネージドTLS証明書（DigiCert発行） 有償App Service証明書（GoDaddy発行） CA/B Forumは、TLS証明書の最大有効期間を段階的に短縮する方向で議論を進めており、将来的には最大47日まで短縮される見通しだ（現行は最大397日）。これはフィッシングや証明書の不正利用リスクを低減するための業界全体の取り組みであり、Google、Apple、Mozillaなど主要ブラウザベンダーが推進している。 AzureのApp Service証明書においても、この基準変更に合わせて証明書の発行方式・有効期間・更新サイクルが変更される。具体的な新しい有効期間や移行タイムラインは順次公式ドキュメントに反映される予定だ。 自動更新ユーザーへの影響は最小限 Microsoftによれば、証明書の自動更新（Auto-renewal）を有効にしているユーザーは、Azureが更新処理を自動的に行うため影響を受けにくい。App Serviceのマネージド証明書はデフォルトで自動更新が設定されているケースが多く、該当ユーザーはAzureポータルで設定状況を確認するだけで済む場合がほとんどだ。 手動管理ユーザーは対応が必要 一方、以下のケースに該当する場合は能動的な対応が求められる。 有償App Service証明書を手動で更新・管理している場合 — 有効期間の変更に伴い、更新作業の頻度が増加する 証明書をKey Vaultと連携させている場合 — Key Vaultのシークレットローテーション設定も見直しが必要になる可能性がある 外部システムが証明書の有効期間に依存している場合 — 証明書の短縮に対応できるよう監視・アラート設定を更新する 日本の運用担当者へのポイント 日本では金融・医療・公共系のシステムでApp Serviceを活用するケースも増えており、証明書の有効期限切れによるサービス停止は深刻なインシデントにつながりかねない。今回の変更を機に、証明書管理の自動化状況を棚卸しし、手動フローが残っていれば自動化への移行を検討したい。 Azureポータルの「App Service証明書」ブレードでは、各証明書の自動更新ステータスを一覧で確認できる。まずは自動更新が有効かどうかを確認することが最初のアクションだ。 詳細はMicrosoftの公式ブログ「Apps on Azure Blog」で継続的に更新される予定となっている。 元記事: Industry-Wide Certificate Changes Impacting Azure App Service Certificates

Microsoft の Azure Developer CLI（azd）が2026年3月に7つのリリース（v1.23.7〜v1.23.13）を連続投入し、AIエージェント開発からインフラ管理まで幅広い強化が施された。 AIエージェントをターミナルからエンドツーエンドで操作 最大の目玉は azure.ai.agents 拡張によるAIエージェント対応コマンド群だ。 azd ai agent run — エージェントをローカルで起動 azd ai agent invoke — ローカルまたは Microsoft Foundry にデプロイ済みのエージェントにメッセージを送信 azd ai agent show — コンテナのステータスと健全性を表示 azd ai agent monitor — コンテナログをリアルタイムストリーミング これにより、AIエージェントの開発・テスト・本番デプロイまでの全工程をターミナル一つで完結できる。Microsoft Foundry との統合が前提となっており、Azure AI 基盤に乗る開発者には特に恩恵が大きい。 GitHub Copilot が azd init に統合（プレビュー） azd init 実行時に「GitHub Copilot でセットアップ（プレビュー）」オプションが追加された。Copilot エージェントがプロジェクトのスキャフォールディングを担い、Model Context Protocol（MCP）サーバーへの同意確認も事前に行う設計となっている。 さらに、コマンド失敗時にはAIによる多段階トラブルシューティングフローが起動。「説明」「ガイダンス」「自動修正」「スキップ」の4段階から選択でき、修正適用後にそのまま失敗コマンドを再実行できる。ターミナルを離れずに問題解決できる点は実務での生産性向上に直結する。 Container App Jobs の直接デプロイ対応 これまで Container Apps のみだったデプロイ対象に、Azure Container App Jobs（Microsoft.App/jobs）が加わった。azure.yaml の host: containerapp 設定はそのままで、Bicep テンプレートの内容に応じて自動判別される。追加設定不要で既存ワークフローへの組み込みが容易だ。 ...

Azure Cosmos DB の Fabric ミラーリング、プライベートエンドポイント対応が一般提供開始 Microsoftは、Azure Cosmos DB の Microsoft Fabric ミラーリング機能において、プライベートエンドポイント（Private Endpoint）サポートの一般提供（GA: Generally Available） を発表した。これにより、インターネットを経由せずに企業のプライベートネットワーク内でデータを安全にレプリケーションできるようになった。 Fabric ミラーリングとは Microsoft Fabric のミラーリング機能は、Azure Cosmos DB などの運用データベースのデータをリアルタイムで Fabric の OneLake へ自動的に複製する仕組みだ。アプリケーション側の運用データベースに手を加えることなく、分析・BI・AI ワークロード向けのデータ基盤を構築できる点が特長で、ETL パイプラインの開発・運用コストを大幅に削減できる。 プライベートエンドポイント対応で何が変わるか これまでのミラーリングは、パブリックネットワーク経由での接続が前提だったため、金融・医療・官公庁など厳格なネットワーク分離を求める業界での採用に課題があった。今回のGA対応により、以下のような構成が本番環境で利用可能になった。 Cosmos DB アカウントをパブリックアクセス無効に設定したまま Fabric へミラーリング Azure Virtual Network（VNet）内に閉じた通信経路でデータを転送 コンプライアンス要件（ISMS、PCI DSS 等）を満たしたデータ統合パイプラインの構築 日本国内でも金融機関やヘルスケア企業を中心に、ネットワーク分離要件のためクラウドサービスの利用範囲が制限されるケースが多い。この対応により、そうした組織でも Fabric による統合データ分析基盤を検討しやすくなるだろう。 MySQL の Fabric ミラーリングもプレビュー開始 あわせて、MySQL から Microsoft Fabric へのリアルタイムミラーリングがプレビューとして提供開始された。Cosmos DB（NoSQL）に加え、広く普及しているリレーショナルDBである MySQL もサポート対象となったことで、Fabric を中心としたデータ統合の選択肢がさらに広がっている。 まとめ 機能 ステータス Cosmos DB ミラーリング（プライベートエンドポイント） GA（一般提供） MySQL → Fabric ミラーリング プレビュー ...

Azure Cosmos DB Rust SDK、パブリックプレビューに登場 Microsoftは、Azure Cosmos DB for NoSQL向けのネイティブRust SDK「Azure Cosmos DB SDK for Rust」のパブリックプレビュー開始を発表した。これにより、RustアプリケーションからAzure Cosmos DBを直接操作できるようになった。 今回のリリースは、昨年ベータ公開された「Azure SDK for Rust」の流れを受けたもの。データベース・コンテナ・アイテムに対するCRUD操作をイディオマティックなRust APIで実行でき、CosmosClientBuilderを通じた直感的なクライアント構築が特徴だ。 なぜRustとCosmosDBの組み合わせが注目されるのか Rustは近年、クラウドネイティブ・高性能システム開発において急速に存在感を高めている。所有権モデルによるメモリ安全性、強力な型システムによるスレッド安全性、そしてWebAssembly対応など、分散システムやクラウドサービスとの親和性が高い。 日本でも、Rustは2023年頃からバックエンド開発や組み込みシステムへの採用が広がっており、パフォーマンスが要求される場面でGoやC++の代替として検討されるケースが増えている。そのRustから、スケーラブルなNoSQLデータベースとして定評あるCosmosDBを扱えるようになったことは、エンタープライズ開発者にとって朗報だ。 主な機能 CosmosClientBuilderによる新APIデザイン: DefaultAzureCredential（Microsoft Entra ID経由）またはアカウントキーによる認証をサポート マルチリージョン書き込み: 地理的分散を活用した高可用性アーキテクチャに対応 トランザクションバッチ: 複数操作をアトミックに実行可能 障害注入テスト（Fault Injection Testing）: 分散システムの耐障害性検証を容易にする機能 非同期対応: tokioランタイムによる完全な非同期I/O クイックスタート SDKの利用には Rust 1.70以上が推奨される。Cargo.tomlに以下の依存関係を追加するだけで始められる。 元記事: Announcing the Public Preview of the Azure Cosmos DB SDK for Rust!

Azure Speech Neural HD TTSが大幅値下げ、新リージョンにも展開 Microsoftは、Azure Speechが提供する高品質音声合成サービス「Neural HD Text to Speech（TTS）」について、価格の引き下げと提供リージョンの拡大を発表した。 価格が約27%値下げ 従来、Neural HD TTSの利用料金は100万文字あたり30ドルだったが、今回のアップデートにより22ドルへと引き下げられた。削減率は約27%で、音声AIアプリケーションを大規模に運用している開発者や企業にとって、ランニングコストの大幅な削減につながる。 日本語でも高品質な音声合成が求められる場面——コールセンター向けのIVR（自動音声応答）、ナレーション生成、アクセシビリティ機能など——での活用コストが下がることは、国内の開発者にとっても朗報といえる。 新リージョンへの展開開始 Neural HD TTSが利用可能なリージョンとして、新たに以下が追加された。 West US 2 East US 2 Canada Central リージョンの拡大により、データレジデンシー（データ保管場所）の要件が厳しいエンタープライズ利用や、レイテンシを重視するリアルタイム音声アプリケーションにおいても、より柔軟な構成が取れるようになる。 Neural HD TTSとは Neural HD TTSは、Azure Speechが提供する音声合成エンジンの中でも特に高品質なラインで、自然なイントネーション・感情表現・滑らかな発話を実現する。従来のニューラルTTSと比べ、より人間らしい音声出力が得られるとされており、音声アシスタント、ポッドキャスト自動生成、教育コンテンツ読み上げなど幅広いユースケースで採用が進んでいる。 音声AI開発のハードルが下がる 生成AIブームに伴い、テキスト生成と組み合わせたエンドツーエンドの音声AIサービスへの需要が急増している。今回の値下げとリージョン拡大は、Azure AI Foundryエコシステム全体としてのコスト競争力強化の一環とも読めり、AWSのPollyやGoogle CloudのText-to-Speechとの競合に向けた動きとも言えるだろう。 Azure Speech Neural HD TTSの詳細や利用開始手順は、Azure公式ドキュメントおよびAzure AI Foundry Blogで確認できる。 元記事: Azure Speech – Neural HD Text to Speech: Recent Voice Updates

Azureサービスのテストが「ローカルだけ」で完結する時代へ Azureを使ったSpring Bootアプリケーションの開発において、ユニットテストは長年の課題だった。実際のAzureリソースをプロビジョニングしなければテストできないとなると、コストも時間もかかる。そこで注目されるのが、Spring Cloud AzureとDockerを組み合わせたテスト手法だ。 MicrosoftのAzure SDK Blogが公式に解説したこのアプローチでは、本物のAzure環境を一切使わずに、ローカルのDockerコンテナ上でAzureサービスをエミュレートしてテストが実行できる。 Spring Cloud Azureとは Spring Cloud Azureは、SpringアプリケーションからAzureサービスを簡単に利用できるようにするOSSプロジェクトだ。Azure Storage、Service Bus、Event Hubsなど主要なAzureサービスとのシームレスな統合を提供しており、Springの自動設定（Auto Configuration）の仕組みに乗っかった形で動作する。 DockerをユニットテストのAzure代替として使う 今回紹介されているアプローチのポイントは、Azurite（Azureストレージエミュレーター）などのDockerイメージを使うことにある。spring-cloud-azure-docker-compose という依存ライブラリを追加するだけで、テスト実行時にDockerコンテナが自動起動し、テスト完了後に自動停止する。 Azure Blob Storageのテスト例 Maven（pom.xml）への依存追加は以下の3点が基本となる： 元記事: Writing Azure service-related unit tests with Docker using Spring Cloud Azure

Microsoftは、Azure Container Appsに新機能「Dynamic Sessions（ダイナミック セッション）」を追加したと発表した。AIタスクに特化したエフェメラル（一時的）なサンドボックスコンピューティング環境を迅速にスピンアップできる仕組みで、アイドル時のコスト削減と推論レスポンスの向上を同時に実現する。 Dynamic Sessionsとは何か Dynamic Sessionsは、AIエージェントや生成AIアプリケーションがコードを安全に実行したり、外部ツールを呼び出したりするための使い捨てサンドボックスを動的に生成する機能だ。セッションは必要なときにだけ起動し、タスク完了後は自動的に破棄される。従来のコンテナアプリと異なり、常時稼働のプロセスを維持する必要がなく、アイドル状態でのコンピューティングコストを大幅に削減できる。 解決する課題 LLM（大規模言語モデル）ベースのAIエージェントが急速に普及するにつれ、推論処理の中でPythonコードの実行・外部API呼び出し・ファイル操作といった「ツール使用」のニーズが急増している。こうした処理を既存の本番コンテナ内で直接実行すると、セキュリティリスクやリソース競合が問題になりやすい。Dynamic Sessionsはこの課題を根本から解決するアーキテクチャを提供する。 主な特徴は以下の通りだ。 即時起動: リクエストのたびにサンドボックスを高速生成し、推論レスポンスのレイテンシを最小化 完全な隔離: 各セッションは独立した環境で実行されるため、セッション間のデータ漏洩リスクがない スケーラビリティ: 並列AIワークロードに対して自動的にセッションをスケールアウト コスト最適化: 使った分だけの課金で、アイドルコストをゼロに近づける 日本市場への影響 CopilotやカスタムAIエージェントを企業向けシステムに組み込む動きが国内でも加速している。特に製造・金融・小売分野でのAIエージェント導入が進む中、安全なコード実行環境のニーズは高まる一方だ。Azure上でAIエージェントを構築している日本の開発チームにとって、Dynamic Sessionsはインフラ管理の複雑さを減らしながらセキュリティ要件を満たす現実的な選択肢となりうる。 利用開始 Dynamic Sessionsは現在、一部顧客向けのプレビュー段階にある。Azure Container Appsを利用中のユーザーはAzureポータルまたはAzure CLIから機能を有効化できる。GA（一般提供）のタイムラインはMicrosoftから追って発表される予定だ。 AIエージェント基盤をクラウドに構築する際の「実行環境の安全な分離」という課題に、Azureが本格的な解答を示した形となる。今後のGA展開と料金体系の詳細に注目したい。 元記事: Azure Container Apps Dynamic Sessions: Ephemeral Compute for AI Inference

AKS Azure Linux 2.0、3月31日でサポート完全終了 Microsoftは、Azure Kubernetes Service（AKS）で使用されているノードイメージ「Azure Linux 2.0」のサポートを2026年3月31日をもって完全終了すると発表した。この期限を過ぎると、Azure Linux 2.0を使用しているノードプールのスケールアウト・スケールインが一切できなくなるため、運用中のクラスターを持つエンジニアは早急な対応が求められる。 何が起きるのか タイムラインを整理すると以下のとおりだ。 2025年11月30日: AKSによるAzure Linux 2.0へのセキュリティアップデート提供終了。ノードイメージは202512.06.0リリースで凍結 2026年3月31日: ノードイメージを削除。以降はノードプールのスケール操作が不可能に セキュリティパッチが止まった状態でイメージが凍結されているため、すでに新規構築での利用は推奨されない状況だ。3月31日以降はスケール操作自体ができなくなるため、実質的にクラスターの運用継続が困難になる。 移行方法 Microsoftが推奨する移行方法は2つある。 方法1: Kubernetesバージョンのアップグレード ノードプールをサポート対象のKubernetesバージョンにアップグレードする。この過程でノードイメージも新しいものに更新される。 方法2: osSku を AzureLinux3 に変更 ノードプールのosSkuパラメーターをAzureLinux3に変更して移行する。Azure Linux 3（旧称: Mariner）はRed Hat系のパッケージ管理を採用しており、Azure Linux 2.0との互換性も高い。 同日に廃止されるもう一つの機能 Azure Linux 2.0のEOLと同日、ノードプールに設定できるタグ aks-disable-kubelet-serving-certificate-rotation=true もサポート対象外となる。このタグでkubeletの証明書ローテーションを無効化していた環境では、合わせて設定の見直しが必要だ。 AKSのKubernetesバージョンサポートポリシー AKSはGA（一般提供）バージョンに対して12ヶ月のサポートポリシーを採用している。長期サポート（LTS）を有効化した場合はさらに延長されるが、Azure Linux 2.0はLTS期間中（v1.28〜v1.31）においても今回のEOLが適用されるため注意が必要だ。 現在サポート対象のバージョンは以下のとおり（標準サポート）。 バージョン AKS GA サポート終了 1.32 2025年4月 2026年3月 1.33 2025年6月 2026年6月 1.34 2025年11月 2026年11月 1.35 2026年3月 2027年3月 対応期限は今日 本記事の執筆時点で、期限の2026年3月31日は本日だ。まだ移行が完了していない場合は、直ちにAzureポータルまたはAzure CLIでノードプールのアップグレードに着手することを強く推奨する。移行の詳細手順はMicrosoft公式ドキュメントおよびRetirement GitHub Issueを参照のこと。 元記事: AKS Azure Linux 2.0 End of Life on March 31, 2026 – Migration Required ...

Azure SQL Managed Instance に SQL Server 2025 更新ポリシーが正式提供開始 Microsoft は、Azure SQL Managed Instance（SQL MI）における SQL Server 2025 更新ポリシー（Update Policy） の一般提供（General Availability / GA）を発表した。これにより、企業はエンジンバージョンの更新サイクルをより柔軟にコントロールできるようになる。 更新ポリシーとは何か SQL MI の更新ポリシーは、マネージドインスタンスが追従するエンジンバージョンのトラックを定義する設定だ。従来の SQL Server 2022 ポリシー では、最新の SQL Server 2022 互換アップデートが自動適用されていたが、新しい SQL Server 2025 ポリシー では、SQL Server 2025 相当の機能アップデートをいち早く受け取ることが可能になる。 変更の影響範囲 今回の GA にともない、以下の管理インターフェースで新ポリシーの設定変更が可能になった。 Azure Portal — インスタンス設定画面の UI が更新され、ドロップダウンから新ポリシーを選択できる REST API — updatePolicy プロパティ経由でプログラム設定に対応 PowerShell — Set-AzSqlInstance コマンドレットにパラメーターが追加 Azure CLI — az sql mi update コマンドでも同様に設定可能 IaC（Infrastructure as Code）でインスタンスを管理しているチームは、Bicep や Terraform のテンプレートに updatePolicy の明示指定を追加しておくことで、意図しないポリシー変更を防げる。 ...

KubeCon Europe 2026でAKSが大幅強化——コンテナ運用チームが押さえるべき5つのポイント 2026年4月にオランダ・アムステルダムで開催された KubeCon + CloudNativeCon Europe 2026 にて、MicrosoftはAzure Kubernetes Service（AKS）の一連のアップデートを発表した。観測性（Observability）、マルチクラスター運用、ストレージ、AIを活用したトラブルシューティングにまたがる内容で、コンテナ基盤を担う運用チームにとって実務直結の改善が揃っている。 1. コンテナネットワークメトリクスのフィルタリング——監視コストを制御する Advanced Container Networking Services（ACNS）はすでにeBPFテクノロジーを使ったノード・Pod単位の深い可視性を提供してきたが、今回プレビューとして追加されたコンテナネットワークメトリクスフィルタリングでは、収集・保存前にメトリクスをソースでフィルタリングできる。 Kubernetesのカスタムリソースを使ってネームスペース単位、Pod・ラベル単位、メトリクス種別単位でフィルタリング条件を定義可能。大規模クラスターで問題になりがちなAzure Monitorのコスト増大とダッシュボードの低速化を抑えながら、必要な箇所での深い可視性を維持できる。 要件はCiliumデータプレーン（Kubernetes 1.29以上）で、Azure managed Prometheus・Azure Managed Grafanaと統合される。 2. GPUメトリクスのAzure Monitor統合——AI・MLワークロードの死角を解消 Kubernetes上でAI・機械学習ワークロードを運用する場合、GPUの利用状況監視は従来「手動でエクスポーターを設定し、カスタム統合が必要」という煩雑な作業を伴っていた。 今回のアップデートで、AKSはGPUのパフォーマンスと利用率メトリクスをマネージドPrometheus・Grafanaへ直接統合する。CPU・メモリ・ネットワークと同一の監視スタックにGPUテレメトリが乗るため、統一的なキャパシティプランニング・アラート・コスト配賦が実現する。 推論ワークロードやバッチ処理を走らせているチームにとって、GPUノードプールの稼働率をGrafanaダッシュボードで可視化し、インフラ投資対効果を示せることは大きな意義がある。 3. Fleet Managerのクロスクラスターネットワーキング——マルチクラスター接続を統一 環境分離・リージョン冗長・コンプライアンス境界分離などの理由から複数のAKSクラスターを運用するケースは珍しくない。しかし従来はクラスター間のサービス接続にカスタムの仕組みが必要で、サービスディスカバリも不統一だった。 Azure Kubernetes Fleet ManagerがマネージドCiliumクラスターメッシュによるクロスクラスターネットワーキングを提供開始した。これにより複数クラスター間の統一的な接続性を確保でき、独自実装なしに一貫したサービスディスカバリとクラスター間可視性が得られる。 マルチクラスター・マルチリージョン構成を取る組織にとって、運用の複雑さを大幅に削減するアップデートだ。 運用チームへの示唆 今回の5大発表に共通するテーマは「スケールしてもオペレーションを維持可能にする」という点だ。特に注目すべきは以下の組み合わせ効果： メトリクスフィルタリング × GPUメトリクス統合 → 「見るべき場所だけを深く見る」観測戦略の実現 Fleet Managerのクラスターメッシュ → マルチクラスター運用の標準化 Cilium依存の機能が多いため、データプレーンをCiliumに移行済みか評価することが前提となる。Kubernetes 1.29以上へのバージョン管理計画とあわせて確認したい。 各機能の詳細はAzure公式ドキュメントおよびKubeCon Europe 2026のセッション録画で確認できる。 元記事: AKS Platform Updates: What Container Teams Need to Know from KubeCon Europe 2026 ...

Azure Database Migration Service、Google AlloyDB・EDB対応でPostgreSQL移行の選択肢が拡大 Microsoftは2026年3月27日のAzureアップデートで、Azure Database Migration ServiceがGoogle AlloyDBおよびEDB（EnterpriseDB）のPostgreSQL互換データベースからのオンライン移行を正式にサポートしたと発表した。移行には標準的なPostgreSQLのレプリケーションプロトコルであるpgoutputプラグインを使用する。 pgoutputによるオンライン移行とは pgoutputは、PostgreSQL 10以降に組み込まれた論理レプリケーション用の出力プラグインだ。従来の移行手法ではデータベースを一時的に停止する必要があったが、pgoutputを使ったオンライン移行ではソースDBを稼働させたまま差分データをAzure側に継続的に同期できる。カットオーバー（切り替え）時のダウンタイムを数分程度に抑えられるため、24時間稼働が求められる本番環境の移行に特に有効だ。 Google AlloyDBはGoogleが提供するPostgreSQL互換のフルマネージドデータベースサービスで、分析ワークロードにも対応した高性能な選択肢として注目されている。EDB（EnterpriseDB）はPostgreSQLのエンタープライズ向けディストリビューションで、Oracle互換機能を持つ「EDB Postgres Advanced Server」などを提供している。これら2製品からAzure Database for PostgreSQL Flexible Serverへの移行パスが整備されたことで、マルチクラウド環境やオンプレミスからのAzure集約がより現実的になった。 PostgreSQL Flexible Serverにカスタムタイムゾーン対応も追加 同アップデートでは、Azure Database for PostgreSQL Flexible Serverのスケジュール済みcronジョブにカスタムタイムゾーンを設定できる機能も追加された。これまではUTC固定だったため、日本時間（JST）で特定の時刻にバッチ処理を実行したい場合に計算が必要だった。今後はタイムゾーンを直接指定することで、運用ミスのリスクが低下する。 今回のAzureアップデートの主なポイント（PostgreSQL関連以外） 今回の3月27日アップデートはPostgreSQL移行以外にも多岐にわたる。主なトピックは以下のとおりだ。 AKS（Azure Kubernetes Service）: アプリレベルのルーティングやメッシュレスIstioサポート、ネットワークAI診断エージェントの追加 Azure SQL / Microsoft Fabric: Fabric SQLへの顧客管理キー対応、SQL Databaseの自動インデックス圧縮、Hyperscale SKUの新規追加 Azure Monitor: OLTPインジェストによるテレメトリ処理の高速化、DiskANNのベクトル検索精度・スループット改善 Entra ID: テナントガバナンスの強化と外部MFAオプションの追加。API・管理フローへのMFA強制が段階的に厳格化される予定 移行を検討している組織への影響 日本国内でもGoogle AlloyDBやEDB PostgreSQLを採用している企業は増えており、Azureへの統合・移行を検討しているチームにとって今回の対応は朗報と言える。pgoutputベースのオンライン移行はネイティブPostgreSQLだけでなく互換DBにも広がりつつあり、クラウド間・オンプレとクラウド間のデータ移行における標準的アプローチとして定着しつつある。 元記事: PostgreSQL migration now supports Google AlloyDB and EDB via pgoutput plugin

Azureのデフォルトアウトバウンドアクセスが廃止へ——Azure Virtual Desktop利用者は要対応 Microsoftは2026年3月31日以降、新規作成されるAzure仮想ネットワーク（VNet）において、デフォルトアウトバウンドアクセス（Default Outbound Access / DOA） を無効化する重大なポリシー変更を実施する。この変更はAzure Virtual Desktop（AVD）を利用している組織に特に大きな影響を与えるため、早急な対応が求められている。 デフォルトアウトバウンドアクセスとは これまでAzureでは、VNet内のリソースが明示的な設定なしにインターネットへのアウトバウンド通信を行える「デフォルトアウトバウンドアクセス」が暗黙的に提供されてきた。しかしMicrosoftはゼロトラストネットワーク（Zero Trust Network）の原則に基づき、この暗黙的な接続を廃止する方向へ舵を切った。 ゼロトラストとは「信頼しない、常に検証する」を基本原則とするセキュリティモデルで、クラウド環境では特に重要視されている。デフォルトで外部通信を許可するという従来の設計は、このモデルと相容れないものだった。 AVD利用者への具体的な影響 2026年3月31日以降に新規作成するVNetでは、DOAが自動的に無効となる。既存のVNetへの影響は現時点では対象外だが、新規環境の構築や既存環境のVNet再作成時には対応が必要になる。 Azure Virtual Desktopはセッションホスト（仮想デスクトップVM）がインターネットやMicrosoftのサービスエンドポイントへ接続する必要があるため、アウトバウンド接続が確保されていない場合、仮想デスクトップの起動や認証、更新処理が正常に動作しなくなるリスクがある。 推奨される代替接続方式 Microsoftは以下の明示的なアウトバウンド接続方式への移行を推奨している： NAT Gateway：シンプルかつスケーラブルなアウトバウンドNATソリューション。新規環境には最も推奨される選択肢 Azure Firewall / NVA（ネットワーク仮想アプライアンス）：トラフィックの制御・監視が必要なエンタープライズ環境に適合 ロードバランサー（アウトバウンドルール付き）：既存のロードバランサー構成と統合する場合に有効 今すぐ確認すべきこと 日本国内でAVD環境を運用・設計している担当者は、以下の点を確認することを強く推奨する： 現在利用中のVNetがDOAに依存していないか棚卸しを行う 今後新規構築するAVD環境では、設計段階からNAT GatewayやAzure Firewallを組み込む テスト環境で接続方式の切り替えを事前に検証する この変更はセキュリティ強化の観点から歓迎すべき方向性だが、準備なく新規VNetを作成すると接続障害につながる可能性がある。期限の2026年3月31日まで時間的余裕は少なく、早急な対応計画の策定が望まれる。 元記事: Azure’s Default Outbound Access Changes: Guidance for Azure Virtual Desktop Customers

Azure Database for PostgreSQL、2026年2月の主要アップデートを発表 Microsoftは、Azure Database for PostgreSQLにおける2026年2月分のアップデート内容をまとめて公開した。今回のアップデートでは、インフラのコード化（IaC）環境の強化やUI改善、モニタリング機能の充実など、開発・運用両面での機能追加が目立つ。 PostgreSQL 18のTerraformサポートが追加 最大のトピックは、PostgreSQL 18に対するTerraformサポートの追加だ。新規サーバーの作成だけでなく、既存サーバーからPostgreSQL 18へのメジャーバージョンアップグレードも、Terraformのコードから実行できるようになった。 Terraformを活用してAzureインフラを管理しているチームにとっては、データベースのバージョン管理もIaCに統一できる大きなメリットとなる。GitOpsやCI/CDパイプラインとの親和性も高まり、データベース運用の自動化がより容易になる。 PostgreSQL 18は現在プレビュー段階のメジャーバージョンで、クエリ最適化やJSON処理の改善、論理レプリケーションの強化など多くの新機能が含まれている。本番環境への採用を検討している組織にとって、Terraformからの管理対応は重要なステップとなる。 Elastic ClusterもTerraformで管理可能に スケールアウト型の分散PostgreSQL構成であるElastic Cluster（旧称：Hyperscale/Citus）についても、Terraformサポートが追加された。大規模データを扱うワークロードで利用されるElastic Clusterの構成管理を、コードで一元管理できる環境が整いつつある。 ポータルのVM SKU選択UIを刷新 Azureポータル上でのサーバー作成・変更時に使用するVM SKU（仮想マシンのサイズ選択）の画面が刷新された。従来のUI では選択肢が見づらく、必要なスペックを見つけるのに手間がかかるケースがあったが、新UIではコア数・メモリ・ストレージなどのスペック比較がより直感的に行えるよう改善されている。 Grafanaダッシュボードとのネイティブ統合 モニタリング面では、Grafanaダッシュボードとの統合が追加された。Azure Managed Grafanaを利用することで、PostgreSQLの各種メトリクス（接続数、クエリレイテンシ、ストレージ使用量など）を可視化・監視するダッシュボードをすぐに活用できる。 Observabilityを重視する運用チームにとって、別途カスタムダッシュボードを構築する手間を省けるのは実用的なメリットだ。 まとめ 今回のアップデートは、Terraformによる管理範囲の拡大、ポータルUXの改善、そしてGrafana統合と、クラウドネイティブな開発・運用ワークフローへの対応を着実に進めている印象だ。Azure Database for PostgreSQLを利用中のチームは、特にIaC管理の強化ポイントを中心に変更内容を確認しておくとよいだろう。 元記事: February 2026 Recap: Azure Database for PostgreSQL

Azure Event Grid MQTTブローカーが正式一般提供（GA）に Microsoftは、Azure Event Grid MQTTブローカーの正式な一般提供（GA: General Availability）を発表した。製造現場の機器から車両、エッジデバイス、金融システムまで、数百万台規模のIoTデバイスをエンタープライズグレードのセキュリティで接続・管理できる基盤として提供される。 MQTTとは——IoT通信の業界標準プロトコル MQTT（Message Queuing Telemetry Transport）は、低帯域・高遅延環境での利用を前提に設計された軽量なパブリッシュ/サブスクライブ型メッセージングプロトコルだ。センサーや組み込みデバイスなど制約の多い環境での通信に広く採用されており、スマートファクトリーや自動車のコネクテッドサービス、スマートシティ基盤などで事実上の標準となっている。 ゼロトラストセキュリティによるデバイス管理 今回のGAで特に注目されるのが、ゼロトラスト（Zero Trust）セキュリティモデルの採用だ。従来のIoT環境では、デバイス認証の複雑さがセキュリティ上の弱点になりやすかった。Azure Event Grid MQTTブローカーは、デバイスごとに厳密な認証・認可を適用し、接続元を問わず信頼しない原則で通信を保護する。 日本でも製造業のスマートファクトリー化や、自動車メーカーによるコネクテッドカー開発が加速している。こうした大規模IoT環境でのセキュリティ担保は長年の課題であり、本サービスはその解決策の一つとして注目される。 Azureエコシステムとのシームレスな統合 収集したIoTデータはリアルタイムでAzureの各サービスへルーティングできる。具体的には以下のような連携が可能だ。 Azure Stream Analytics — リアルタイムでのデータ分析・異常検知 Azure Functions / Logic Apps — イベント駆動の自動化処理 Azure Digital Twins — 物理世界のデジタルツイン構築 Microsoft Fabric / Synapse Analytics — 大規模データの蓄積と分析 この統合により、デバイスからクラウドまでのデータパイプラインをAzureで一元管理できる。 主なユースケース スマートファクトリー: 生産ライン上の機器状態をリアルタイム監視し、予知保全や品質管理に活用 コネクテッドビークル: 車両から収集した走行データの集約・解析 スマートグリッド・エネルギー管理: 電力消費のリアルタイム最適化 金融システム: 高頻度・低遅延が求められるトランザクション系イベント処理 今後の展望 国内でもIoT活用による製造業のDX（デジタルトランスフォーメーション）推進は政府が重点施策として掲げており、信頼性の高いIoTメッセージング基盤へのニーズは高まる一方だ。Azure Event Grid MQTTブローカーのGAは、そうした需要に応える選択肢として企業の注目を集めそうだ。 料金や詳細なSLA（サービスレベルアグリーメント）についてはAzure公式ドキュメントを参照されたい。 元記事: Azure Event Grid MQTT Broker: Enterprise-Grade Messaging for the Connected World ...

Microsoftがソブリンクラウドを大幅強化——政府・規制産業向けに完全オフライン運用も実現 Microsoftは、政府機関や規制産業向けのクラウド戦略「Microsoft Sovereign Cloud（ソブリンクラウド）」について、新たな機能群の提供開始を発表した。データ主権（Data Sovereignty）と規制遵守を重視する組織に向け、パブリッククラウドとプライベートクラウドの両面で機能を拡充する。 主な新機能・強化点 1. EU内でのエンドツーエンドAIデータ処理 EUデータ境界（EU Data Boundary）の一環として、EUの顧客向けAIサービスで処理されるデータが、すべてEU域内に留まることを保証する。静止データ・転送中データのいずれも、EUの外に出ることなく処理・保管される。GDPRをはじめとするEU規制への対応を強化したい企業にとって重要な進展だ。 2. Microsoft 365 CopilotのEU内処理を15カ国に拡大 Copilotのインタラクションデータに関して、自国内処理（In-country Processing）の対応国を15カ国に拡大する。企業のAI活用を推進しながら、データが国外に出ないことを担保する。 3. Azure Localの切断運用（Disconnected Operations）対応 注目すべきはAzure Localにおける「切断運用」機能だ。インターネットに接続しない完全なオンプレミス環境でも、クラウドと同等の管理・制御プレーンを利用できるようになる。防衛・公共インフラ・金融機関など、インターネット接続自体が制限される環境でのクラウド技術活用が現実的になる。 4. Microsoft 365 Localの一般提供開始（GA） Microsoft 365のオンプレミス展開版が一般提供を開始。ライセンス管理や認証処理を含めてローカル完結できる構成が可能になる。 5. Azure Localのスケールアップ・ハードウェア対応強化 最大スケールの拡大 外部SAN（Storage Area Network）ストレージのサポート追加 最新NVIDIA GPUへの対応 AI推論やHPC（高性能計算）ワークロードをオンプレミスで処理したいユーザーには朗報となる。 欧州でのインフラ・組織体制も整備 Microsoftは技術面だけでなく、ガバナンス体制の強化も進めている。欧州法に準拠した形でデータセンター運営を監督する「欧州取締役会」を設立し、構成員はすべてEU国籍保有者とした。インフラ面ではオーストリアに新データセンターを開設し、ベルギーへの展開も今月中に予定している。 日本企業への示唆 ソブリンクラウドの議論は欧州が先行しているが、日本でも経済安全保障推進法の施行やサイバーセキュリティ規制の強化を背景に、政府・重要インフラ企業のクラウド調達要件は厳格化が続いている。Azure Localの切断運用機能やMicrosoft 365 Localは、日本の防衛・公共機関・金融機関でも活用が検討されるものだ。Microsoftの動向は日本のクラウド戦略にも直接影響を与えうる。 今回の発表はMicrosoftが2025年6月にCEOのSatya Nadella氏が表明したソブリンクラウド方針の具体化であり、規制対応と技術革新の両立を目指す同社の姿勢が改めて示された形だ。 元記事: Microsoft Strengthens Sovereign Cloud Capabilities with New Services

AKS Arc の Windows Server 2019 サポート終了——段階的廃止スケジュールを確認 Microsoftは、Azure Arc 対応の Azure Kubernetes Service（AKS Arc）における Windows Server 2019 ノードプールを 2026年3月末をもって廃止すると発表した。この日以降、Windows Server 2019 ノードプールの新規作成はできなくなり、既存のノードプールもセキュリティアップデートや品質更新プログラムの提供が停止される。 段階的廃止スケジュール AKS Arc における Windows Server の廃止は、以下のスケジュールで段階的に進められる。 廃止対象 廃止時期 Windows Server 2019 ノードプール 2026年3月 Windows Server 2022 ノードプール 2027年3月 ホストOSとしての Windows Server 2019/2022/2025 2028年3月 なお、AKS Arc on Windows Server 自体は 2028年3月まで引き続きサポートされており、今回の廃止はあくまで Kubernetes ワーカーノードに使用する Windows OS が対象。AKS Arc のクラスターアーキテクチャそのものへの影響はない。 今すぐ対応が必要なこと 現在 Windows Server 2019 ノードプールを利用中の場合、以下の対応を検討する必要がある。 1. Windows Server 2022 ノードプールへのワークロード移行 最も直接的な対応策。既存ワークロードを Windows Server 2022 ベースのノードプールに移行する。 ...