Azure

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 ベースのノードプールに移行する。 ...

Azure Event Grid MQTTブローカーがエンタープライズ向けに正式提供開始 Microsoftは、Azure Event GridにエンタープライズグレードのMQTTブローカー機能を正式統合したと発表した。数百万台規模のデバイスに対応するスケーラビリティと、ゼロトラストセキュリティをデフォルトで実装している点が最大の特徴だ。 MQTTとは——IoTの「共通言語」 MQTT（Message Queuing Telemetry Transport）は、IoTデバイス間の軽量メッセージングプロトコルとして国際標準化されており、センサー、工場設備、スマートビルディングシステムなど、処理能力やネットワーク帯域が限られた環境でも安定した通信を実現する。製造業からスマートシティまで、IoT基盤の「共通言語」として日本国内でも広く採用が進んでいる。 エンタープライズが求める3つの要件を満たす 今回発表されたAzure Event Grid MQTTブローカーは、企業がIoT基盤に求める以下の要件を一つのマネージドサービスで提供する。 1. 大規模スケーラビリティ 数百万台のデバイスから同時に送信されるメッセージを処理できる水平スケーリングを実現。ピーク時のトラフィック増加にも自動対応し、インフラ管理の工数を削減する。 2. ゼロトラストセキュリティの標準実装 デバイス認証、転送中のデータ暗号化（TLS）、きめ細かいアクセス制御ポリシーがデフォルトで有効化されている。「信頼せず、常に検証する」ゼロトラスト原則をインフラレベルで実装することで、接続デバイス数が増加しても一貫したセキュリティ態勢を維持できる。 3. Azure全サービスとのネイティブ統合 Azure IoT Hub、Azure Functions、Azure Stream Analytics、Azure Digital Twinsなど、既存のAzureサービス群とシームレスに連携する。MQTTブローカーを起点に受信したデータをリアルタイムで変換・分析・可視化するパイプラインを、追加のミドルウェアなしに構築できる。 日本の製造業・スマートシティへの影響 日本では製造現場のスマートファクトリー化やインフラのIoT化が加速しており、信頼性の高いMQTTブローカーをクラウドネイティブに利用できる環境へのニーズは高い。これまでは自前でMosquitto等のオープンソースブローカーを運用するか、専用IoTプラットフォームを採用するケースが多かったが、Azure Event Gridへの統合によってフルマネージドかつエンタープライズSLAを持つ選択肢が加わった形だ。 既存のAzureユーザーにとっては、IAM（Identity and Access Management）やモニタリングを統一基盤で管理できるメリットも大きく、運用コストの削減につながる可能性がある。 今後の展望 MicrosoftはEvent Gridを単なるイベントルーターから、リアルタイムイベント処理の統合ハブへと進化させる戦略を明確にしている。MQTTブローカーの追加はその重要なマイルストーンであり、AMQP・Kafkaプロトコルとの相互運用性拡張など、さらなる機能強化が期待される。 IoT基盤の刷新やクラウド移行を検討している組織は、Azure Event Grid MQTTブローカーをアーキテクチャ選定の有力候補として評価する価値があるだろう。 元記事: Azure Event Grid MQTT Broker: Enterprise-Grade Messaging for the Connected World

MicrosoftがNVIDIA Rubin世代のAIデータセンター展開に向けた戦略を公開 Microsoftは、NVIDIA次世代アクセラレーテッドコンピューティングプラットフォーム「Vera Rubin NVL72」を大規模展開する初のハイパースケールクラウドプロバイダーになることを発表した。CES 2026においてNVIDIA Rubinプラットフォームの登場とともに、Azureがすでに受け入れ準備を整えていることが明らかになった。 数年先を見越したデータセンター設計 Azureのデータセンター戦略は、次世代GPUの電力・冷却・メモリ・ネットワーク要件を業界の数年先を見越して設計されている点が大きな特徴だ。ウィスコンシン州およびアトランタの「Fairwater」サイトをはじめとする次世代AI超大型ファクトリー（AIスーパーファクトリー）において、Vera Rubin NVL72ラックをシームレスに統合できる体制が整っている。 NVIDIA Rubin世代のAIインフラは電力・冷却・性能最適化の面で大幅なアップグレードを必要とするが、MicrosoftはFairwaterサイトでの運用実績と複数世代にわたる刷新経験を通じて、技術進化に柔軟に対応できる能力を証明してきた。 GPT-3.5を支えたインフラが次のステージへ MicrosoftはNVIDIA Ampere・Hopperの大規模初期導入においても先行しており、NVIDIA Quantum-2 InfiniBandネットワークで接続されたクラスターがGPT-3.5などの大規模言語モデルの実現を支えた。さらにスーパーコンピューティング性能記録の更新にも貢献しており、次世代システムをより速く、より高い実世界性能で稼働させる能力を示している。 また、NVIDIA GB200 NVL72およびGB300 NVL72プラットフォームについても、業界初かつ最大規模の実装を公開済み。これらは単一のスーパーコンピューターとしてラックに統合され、AIモデルの学習を飛躍的に高速化する。 システム全体最適化がAzureの競争優位 Azureの強みは単なるGPUの追加にとどまらない。コンピュート・ネットワーキング・ストレージ・ソフトウェア・インフラすべてを統合プラットフォームとして設計する「システムズアプローチ」が根幹にある。 具体的には以下の要素が連携して動作する： Azure Boost：IO・ネットワーク・ストレージのボトルネックを解消するオフロードエンジン 高スループットBlobストレージ：大規模クラスターへのデータ供給を安定化 CycleCloud / AKS：大規模クラスタースケールでの低オーバーヘッドスケジューリング 液冷式熱交換ユニット（HEU）：精密な温度管理を実現 Azure HSMシリコン：セキュリティ処理をオフロード Azure Cobalt：汎用コンピュートおよびAI周辺タスクの高効率処理 推論ワークロードで50ペタFLOPSへ NVIDIA Vera RubinスーパーチップはNVFP4精度で50ペタFLOPSの推論性能を提供する見込みで、推論ヘビーなワークロードに最適化されたインフラとしてAzureが提供する。 日本企業においても大規模言語モデルの推論コスト削減は急務であり、Azure上でのRubinプラットフォーム活用は、AIサービスの経済性を大きく変える可能性がある。MicrosoftとNVIDIAの長期的な協業関係が、クラウドAIインフラの次世代標準を築きつつある。 元記事: Microsoft’s strategic AI datacenter planning enables seamless, large-scale NVIDIA Rubin deployments

Azure仮想ネットワークのアウトバウンドアクセスに重大な変更 Microsoftは、Azure仮想ネットワーク（VNET）上の仮想マシン（VM）がインターネットへ接続する際の基本動作を根本的に変更する。2026年3月31日以降、新規に作成される仮想ネットワーク・サブネットはデフォルトで「プライベート」設定となり、明示的にアウトバウンド接続を構成しない限り、VMはインターネットへアクセスできなくなる。 これまでの動作と何が変わるのか これまでAzureでは、明示的な出口経路（egress path）を設定していないVMに対して、「デフォルトアウトバウンドアクセス」と呼ばれる暗黙的なインターネット接続が提供されていた。この機能により、追加設定なしでOSアップデートの取得、ライセンス認証、外部APIとの連携などが可能だった。 Microsoftは今回、この暗黙的な接続を廃止し、明示的かつ監査可能なネットワーク設計を義務付ける方針へと転換する。ゼロトラスト（Zero Trust）ネットワーク原則に基づき、「セキュア・バイ・デフォルト」の実現を目指すためだ。 既存の仮想ネットワークへの影響は？ この変更は既存の仮想ネットワークには適用されない。 2026年3月31日以前に作成済みのVNETおよびそのサブネット内にデプロイされたVMは、引き続き従来通りの動作を維持する。ただしMicrosoftは、将来的な安定性のためにも明示的なアウトバウンド方法へ移行することを強く推奨している。 主な理由は以下の通りだ。 デフォルトアウトバウンドが使用するパブリックIPアドレスは予告なく変更される可能性がある 自前でトレーサブルなIPリソースを管理することで、セキュリティ・コンプライアンス要件を満たしやすくなる VMから公開エンドポイントへの接続経路を組織側でコントロールできる 推奨される移行先アーキテクチャ Microsoftはワークロードの要件に応じて、以下4つのアウトバウンド方法を推奨している。 方法 特徴 Azure NAT Gateway スケーラブルで予測可能な送信アクセス。大規模環境に最適 Load Balancerのアウトバウンドルール 既存のロードバランサー構成を活用できる パブリックIPアドレス 個別ワークロード向けのシンプルな構成 Azure FirewallまたはNVA（ネットワーク仮想アプライアンス） ポリシーの一元管理が必要なエンタープライズ環境に適する 放置するとどうなるか プライベートサブネットにデプロイされたVMに明示的なアウトバウンド設定がない場合、以下のような障害が発生しうる。 OSアップデートやパッケージリポジトリへのアクセス失敗 Windows認証（Azure AD / Entra ID）の接続エラー Microsoft Intuneとの同期失敗 監視エージェントやテレメトリの送信停止 外部API・サードパーティサービスとの連携断絶 開発・テスト環境やレガシー構成で、暗黙のインターネットアクセスに依存しているケースは特に注意が必要だ。 今すぐ確認すべきこと 自社のAzure環境がデフォルトアウトバウンドアクセスに依存しているかどうかを今すぐ確認することを強く推奨する。Azure Portalのネットワーク設定やNSG（ネットワークセキュリティグループ）フローログを活用して、明示的な出口設定のないVMをリストアップし、計画的に移行を進めることが障害回避の近道となる。 期限は2026年3月31日。残り時間は少ない。 元記事: Azure VNET Outbound Access – Important Changes March 2026

Microsoft、Azure Sphereの終了を正式発表 Microsoftは、IoTデバイス向けセキュリティプラットフォーム「Azure Sphere」を2031年7月31日をもって終了すると正式に発表した。同日をもってすべてのサービスが停止される。 終了するサービスの範囲 今回の終了（リタイアメント）によって停止するのは以下のとおり： OSおよびセキュリティアップデートの配信停止 DAA（Device Authentication and Attestation）シリコン証明書の新規発行停止 MT3620 MCUの延長サポート終了 クラウドサービス全般（デバイス管理ポータル、テレメトリ収集など） 2031年7月31日以降、既存デバイスはセキュリティパッチを受け取れなくなるため、IoTデバイスの性質上、長期稼働を前提とした製品では特に早期の対応計画が求められる。 Azure Sphereとは Azure Sphereは2018年にMicrosoftが発表したIoTセキュリティプラットフォームで、独自設計のMCU（MT3620）、Linuxベースの専用OS、クラウドベースのセキュリティサービスの3層構造で構成される。組み込み機器にエンタープライズレベルのセキュリティをもたらすというコンセプトで、製造業や産業用途を中心に採用が進んでいた。 日本でも製造業のDX推進の文脈でAzure Sphereを採用した事例があり、影響を受けるユーザーは少なくないとみられる。 移行に向けた対応 Microsoftは移行先の案内とQ&Aを公式ブログで公開している。終了まで約5年の猶予があるものの、IoT機器は製品サイクルが長く、設計・認証・量産のリードタイムも考慮すると、今から移行計画を立てることが強く推奨される。 代替候補としては、Microsoft Azure IoT HubやAzure IoT Centralといった既存のAzure IoTサービス群への移行、あるいはArmのPSA Certified対応チップやNXP・STMicroelectronicsなどのセキュアエレメント搭載MCUへの切り替えが考えられる。 まとめ 2031年という期限は一見遠く感じるが、組み込み製品の開発・保守サイクルを考えると実質的な猶予は長くない。Azure Sphereを採用している開発者・製品担当者は、公式Q&Aを確認しつつ、早期に移行ロードマップの策定に着手することを検討すべきだろう。 元記事: Azure Sphere is Retiring in 2031 - What you need to know

Azure Container Apps Dynamic Sessions とは Microsoftは、Azure Container AppsのDynamic Sessions機能にビルトインのMCP（Model Context Protocol）エンドポイントを追加した。これにより、AIエージェントがPython・Node.js・シェルスクリプトなどのコードを、Hyper-V隔離されたサンドボックス環境でミリ秒単位に起動して安全に実行できるようになる。 LLM（大規模言語モデル）がコードを生成し、そのコードを即座に実行して結果を返すパイプラインの構築が、これまで以上に容易になった。 主な特徴 Hyper-V による強固な分離 各セッションはHyper-Vによる仮想化で互いに完全に隔離されており、ホスト環境にも影響を与えない。信頼できないユーザー提出コードや、AIが生成したスクリプトを本番システムのリスクなしに実行できるエンタープライズグレードのセキュリティを備える。 プリウォームによるミリ秒起動 セッションプールと呼ばれる仕組みで、あらかじめウォームアップされた未割り当てセッションを大量に待機させておく。リクエストが来た時点でプールから割り当てるため、コンテナをゼロから起動するコストが不要となり、サブ秒（ミリ秒オーダー）での起動が実現する。 自動スケールと自動クリーンアップ 同時に数百〜数千セッションを手動介入なしにスケール可能。セッションはタスク完了後またはアイドルタイムアウト後に自動で破棄され、リソースが解放される。 想定ユースケース AI/LLMワークフロー: ChatGPTやClaude等が生成したコードを本番環境に触れさせることなく検証・実行 インタラクティブ開発: スクリプトやプロトタイプを使い捨て環境で素早くテスト セキュアなコード実行: ユーザー提出の任意コードを隔離環境で安全に処理 バーストワークロード: 予測困難なアクセス急増に対してセッションを自動スケールで対応 セッションプールの種類 Dynamic Sessionsには2種類のプールが用意されている。 コードインタープリタープール: Python・Node.js・シェルなどの実行環境がプリインストールされたマネージドコンテナ。LLM駆動のワークフローや安全なコード実行に最適。 カスタムコンテナープール: 独自の依存関係や実行環境が必要なケース向けに、任意のコンテナイメージを使用できる。 MCPエンドポイントとの統合で広がるAIエージェント活用 今回追加されたMCPエンドポイントにより、Claude・GPT-4・Geminiなどのモデルを組み込んだAIエージェントフレームワークから、Dynamic Sessionsのサンドボックスを標準プロトコルで呼び出せるようになった。「コード生成 → 安全な実行 → 結果のフィードバック」というループをエージェント内で完結できる点が大きな強みだ。 Azureを活用した開発者やエンタープライズシステム担当者にとって、LLMベースのコーティングエージェントや社内自動化ツールへの応用が期待される機能追加といえる。 元記事: Dynamic sessions in Azure Container Apps | Microsoft Learn

AIエージェントのコード実行に新たな選択肢 Microsoftは「Azure Container Apps Dynamic Sessions」に、ビルトインのMCP（Model Context Protocol）エンドポイントを追加したと発表した。これにより、AIエージェントがPython・Node.js・シェルスクリプトなどのコードを、Hyper-V隔離サンドボックス内でミリ秒単位に起動して安全に実行できるようになる。 これまでの課題と今回の改善 LLM（大規模言語モデル）駆動のワークフローでは、AIが生成したコードをそのまま実行する「コードインタープリター」的なユースケースが増えている。しかし、任意コードの実行はセキュリティリスクと隣り合わせであり、適切な隔離環境の構築には相応の手間がかかっていた。 Dynamic Sessionsは以前からHyper-Vベースの強固なサンドボックスを提供していたが、今回のアップデートでMCPエンドポイントがビルトインで利用可能となり、エージェントとの統合に必要な設定量が大幅に削減された。開発者はインフラ構築の複雑さを意識せず、コードインタープリター機能を自分のエージェントに組み込める。 MCP統合のポイント MCPは、LLMとツール・外部サービスをつなぐためのオープンプロトコルとして急速に普及しつつある。今回のDynamic SessionsへのMCPエンドポイント追加は、このエコシステムへの公式対応であり、AnthropicのClaudeやその他のMCP対応エージェントからも直接呼び出せるようになる。 主な特徴は以下のとおりだ。 Hyper-V隔離: 各セッションはVM単位で隔離されており、他のセッションや基盤インフラへの影響を防ぐ 高速起動: ミリ秒単位のコールドスタートにより、インタラクティブなユースケースにも対応 マルチランタイム対応: Python・Node.js・シェルをサポート Microsoft Agent Frameworkとの統合: 公式サンプルが公開されており、すぐに試せる 日本の開発者への示唆 国内でも生成AIを活用したデータ分析ツールや社内エージェントの開発が活発化しており、「AIにコードを書かせて即実行」という要件はますます一般的になっている。Azure上でこのユースケースを実装する際、Dynamic Sessions + MCPの組み合わせは有力な選択肢となるだろう。 Microsoft Agent Frameworkとの統合サンプルはTech Communityブログ上で公開されており、既存のAzureサブスクリプションがあればすぐに検証を始められる。 元記事: Even simpler to Safely Execute AI-generated Code with Azure Container Apps Dynamic Sessions