生成日時: 2026年04月25日 対象期間: 過去 24 時間以内 処理モード: 詳細モード 更新件数: 7 件
公開日時: 2026年04月24日 18:30:50 UTC リンク: Public Preview: Azure Backup for Elastic SAN
アップデートID: 560904 情報源: Azure Updates API
カテゴリ: In preview, Storage, Azure Elastic SAN, Features
要約:
何が更新されたか
Azure BackupがElastic SANをサポートし、Elastic SANボリュームのバックアップおよびリストア機能がパブリックプレビューとして提供開始されました。
主な変更点や新機能
Elastic SANのデータをAzure Backupでフルマネージドにバックアップ・リストアできるようになりました。これにより、誤削除やランサムウェア攻撃、アプリケーションアップデートなどによるデータ損失からElastic SANボリュームを保護できます。
影響を受ける対象
Azure Elastic SANを利用しているユーザーおよび、Elastic SAN上のデータ保護が必要なシステムやアプリケーションが対象です。
注意点があれば記載
本機能はパブリックプレビュー段階のため、本番環境での利用には注意が必要です。また、サポート範囲や制限事項については公式ドキュメントを確認してください。
詳細:
本アップデートは、「Azure Backup for Elastic SAN」のパブリックプレビュー提供開始に関するものです。これにより、Azure BackupがElastic SAN（Elastic Storage Area Network）をサポートし、Elastic SANボリュームのバックアップおよびリストアをフルマネージドで実行できるようになりました。アップデートの目的は、Elastic SAN上のデータを偶発的な削除、ランサムウェア攻撃、アプリケーションのアップデートなどによるデータ損失から保護することです。
具体的な機能としては、Azure BackupとElastic SANの統合により、Elastic SANボリュームのバックアップデータをエクスポートし、必要に応じてリストアできる点が挙げられます。これにより、従来は手動で行っていたバックアップ・リストア作業をAzure Backupの管理機能を通じて自動化・効率化することが可能となります。バックアップはフルマネージドで提供されるため、インフラ管理者はバックアップのスケジューリングや保持ポリシーの設定、リストアポイントの管理などをAzureポータルやAPIを通じて一元的に実施できます。
技術的な仕組みとしては、Azure BackupサービスがElastic SANのボリュームデータをエクスポートし、バックアップストレージに安全に保存します。リストア時には、バックアップデータから指定したボリュームを復元することができます。これにより、データの整合性や可用性を確保しつつ、迅速な障害対応やデータリカバリが実現できます。
活用シナリオとしては、ミッションクリティカルなデータをElastic SAN上で運用している場合の定期バックアップ、アプリケーションのバージョンアップ前の事前バックアップ、誤操作によるデータ削除からの迅速な復旧、ランサムウェア等のセキュリティインシデント発生時のリカバリなどが想定されます。これにより、企業のBCP（事業継続計画）やDR（ディザスタリカバリ）対策の強化にも寄与します。
注意点や制限事項については、本アップデートがパブリックプレビュー段階であるため、本番環境での利用は慎重に検討する必要があります。また、Elastic SANのバックアップ対象やリストアの粒度、サポートされるリージョンやバックアップ保持期間など、詳細な制限事項については公式ドキュメントを参照することが推奨されます。
関連するAzureサービスとの連携としては、Azure Backupの他のストレージサービス（例：Azure Disk BackupやAzure Files Backup）と同様に、統合的なバックアップ管理が可能です。これにより、複数のストレージサービスを横断したデータ保護戦略をAzure上で一元的に実装することができます。
公開日時: 2026年04月24日 18:15:17 UTC リンク: Public Preview: Hosted Agents in Foundry Agent Service
アップデートID: 560997 情報源: Azure Updates API
カテゴリ: In preview, AI + machine learning, Microsoft Foundry, Features
要約:
何が更新されたか
「Foundry Agent Service」において、Hosted Agentsがパブリックプレビューとして提供開始されました。
主な変更点や新機能
Hosted Agentsは、各エージェントセッションごとに専用の実行サンドボックス上で動作します。これにより、セッションごとにクリーンな環境が提供され、セッション間での状態共有やデータ漏洩が発生しません。また、強固なコンピュート境界が確保されています。
影響を受ける対象
Foundry Agent Serviceを利用している開発者や運用担当者が対象です。特に、セキュアな実行環境やセッションごとの分離が求められるワークロードに関わる技術者にとって重要なアップデートです。
注意点があれば記載
本機能はパブリックプレビュー段階のため、本番環境での利用には注意が必要です。正式リリース前のため、機能や仕様が変更される可能性があります。
詳細:
「Public Preview: Hosted Agents in Foundry Agent Service」は、Foundry Agent Serviceにおいてホスト型エージェントのパブリックプレビューを開始したことを示すアップデートです。本アップデートの背景には、エージェント実行環境のセキュリティと分離性の向上、およびより柔軟な運用ニーズへの対応があります。従来のエージェント実行環境では、複数のセッション間で環境が共有されることによるデータリークやセキュリティリスクが懸念されていましたが、本機能によりこれらの課題を解決することが目的です。
具体的な機能として、Hosted Agentsは各エージェントセッションごとに専用の実行サンドボックス内で動作します。このサンドボックスは完全に分離されたクリーンな環境であり、セッション開始時には一切の共有状態が存在しません。これにより、セッション間でのデータ漏洩や状態の持ち越しが発生せず、強固なコンピュート境界が維持されます。各セッションは独立しており、他のセッションの影響を受けることなく安全に処理が実行されます。
技術的な仕組みとしては、Azureが提供する分離型の実行基盤上でエージェントがデプロイされ、各セッションごとに新規のサンドボックス環境がプロビジョニングされます。この環境はセッション終了時に破棄されるため、永続的なデータや状態が残ることはありません。これにより、セキュアなマルチテナント運用や、機密性の高いワークロードの実行が可能となります。
活用シナリオとしては、CI/CDパイプラインのビルド・デプロイ作業や、セキュリティ要件が厳しい業務プロセスの自動化、複数のプロジェクトやチームでのエージェント共有運用などが挙げられます。特に、セッションごとに完全な分離が求められる環境や、エージェント実行時のクリーンな状態が必要なケースで有効です。
注意点としては、パブリックプレビュー段階であるため、サービスの安定性や機能面で一部制限が存在する可能性があります。また、既存のFoundry Agent Serviceとの互換性や、サンドボックス環境におけるリソース制限などについては、公式ドキュメントやサポート情報を参照する必要があります。
関連するAzureサービスとの連携については、Foundry Agent Service自体がAzure上で動作するため、Azure DevOpsやAzure Pipelinesなどの自動化・CI/CDサービスとの統合が想定されます。これにより、Azureエコシステム内でセキュアかつ効率的なエージェント運用が実現できます。
詳細は公式アップデートページ（https://azure.microsoft.com/updates?id=560997）を参照してください。
公開日時: 2026年04月24日 18:15:17 UTC リンク: Generally Available: Foundry Toolkit for Visual Studio Code (formerly AI Toolkit for VS Code)
アップデートID: 560987 情報源: Azure Updates API
カテゴリ: Launched, AI + machine learning, Microsoft Foundry, Features
要約:
何が更新されたか
Foundry Toolkit for Visual Studio Code（旧称：AI Toolkit for VS Code）が一般提供（GA）となりました。
主な変更点や新機能
本ツールキットは、Microsoft Agent Framework向けのVS Code拡張機能を提供します。テンプレートやGitHub Copilotを利用したエージェントの作成、ローカルでのテスト・デバッグ、可視化やトレース機能、Foundryへの直接デプロイが可能です。
影響を受ける対象
Visual Studio Codeを利用してMicrosoft Agent Framework上でエージェント開発を行う開発者や技術者が対象です。
注意点があれば記載
本ツールキットの利用には、対応するVS Code環境およびMicrosoft Agent Frameworkの知識が必要です。既存のAI Toolkit for VS Codeを利用している場合は、名称変更にご注意ください。
詳細:
Foundry Toolkit for Visual Studio Code（旧称：AI Toolkit for VS Code）が一般提供（GA）となりました。本ツールキットは、Microsoft Agent Frameworkの開発を支援するためのVS Code拡張機能を提供します。主な目的は、エージェント開発の生産性向上と開発サイクルの効率化にあります。これにより、開発者はVisual Studio Code上でエージェントの作成、テスト、デバッグ、デプロイまでをシームレスに実施できるようになります。
具体的な機能としては、まずエージェントの作成をテンプレートから迅速に行う機能が搭載されています。これにより、標準的な構成を持つエージェントを即座に生成し、開発を開始することが可能です。また、GitHub Copilotとの連携により、AIによるコード補完や自動生成を活用したエージェント作成もサポートされています。これにより、開発者はより効率的にコードを記述でき、品質の高いエージェントを短期間で開発することができます。
ローカル環境でのテストおよびデバッグ機能も強化されています。エージェントの挙動を可視化するビジュアライゼーションやトレース機能が提供されており、動作の流れや問題箇所を直感的に把握することができます。これにより、開発中のエージェントの品質向上とトラブルシューティングが容易になります。
さらに、開発したエージェントはFoundry環境へ直接デプロイすることが可能です。VS Codeからの一貫した操作でデプロイメントが完結するため、開発から運用までのワークフローが大幅に簡素化されます。
技術的には、VS Code拡張機能として動作し、Microsoft Agent FrameworkのAPIやFoundryのデプロイメント機能と連携しています。これにより、ローカル開発環境とクラウド環境の連携がシームレスに行える設計となっています。
活用シナリオとしては、AIエージェントやボットの開発、カスタム業務プロセスの自動化、対話型アプリケーションの構築などが挙げられます。特に、迅速なプロトタイピングや反復的な開発が求められる現場で有効です。
注意点としては、本ツールキットはFoundryおよびMicrosoft Agent Frameworkに依存しているため、これらのサービスの利用環境が必要です。また、利用するテンプレートやGitHub Copilotの機能は、VS Codeおよび拡張機能のバージョンや設定に依存する場合があります。
関連するAzureサービスとの連携については、FoundryおよびMicrosoft Agent Frameworkを中心に、今後Azureの他のAIサービスやデプロイメント基盤との統合が期待されます。詳細は公式ドキュメントやアップデート情報を参照してください。
詳細情報は公式アップデートページ（https://azure.microsoft.com/updates?id=560987）をご確認ください。
公開日時: 2026年04月24日 18:15:17 UTC リンク: Generally Available: WireGuard In‑Transit Encryption for Azure Kubernetes Service (AKS)
アップデートID: 560015 情報源: Azure Updates API
カテゴリ: Launched, Compute, Containers, Azure Kubernetes Service (AKS), Features, Security
要約:
何が更新されたか
Azure Kubernetes Service（AKS）において、WireGuardによるインフライト（転送中）暗号化機能が一般提供（GA）されました。
主な変更点や新機能
Azure CNI（Ciliumベース）およびAdvanced Container Networking Services（ACNS）を利用しているAKSクラスターで、WireGuardを用いたノード間通信の自動暗号化が可能になりました。これにより、クラスターノード間のトラフィックを透過的に暗号化し、セキュリティを強化できます。
影響を受ける対象
Azure CNI（Cilium）およびACNSを利用しているAKSクラスターが対象です。既存または新規の該当構成のクラスターで利用できます。
注意点があれば記載
WireGuard暗号化を利用するには、AKSクラスターがAzure CNI（Cilium）またはACNSを使用している必要があります。その他のネットワークプラグインや構成では利用できません。導入前に、既存のネットワーク設定やパフォーマンスへの影響を十分に確認することを推奨します。
詳細:
本アップデートは、Azure Kubernetes Service（AKS）において、WireGuardによるインフライト暗号化が一般提供（GA）となったことを示しています。対象となるのは、Azure CNI（Container Networking Interface）をCiliumおよびAdvanced Container Networking Services（ACNS）と組み合わせて利用しているAKSクラスターです。この機能の導入背景には、Kubernetesクラスター内のノード間通信におけるセキュリティ強化の要請があります。従来、AKSのネットワーク通信は暗号化されていない状態で転送されることが多く、特にマルチテナント環境や厳格なコンプライアンス要件を持つシナリオにおいては、通信経路の暗号化が求められていました。
WireGuardは、高速かつシンプルなVPNプロトコルであり、Linuxカーネルにネイティブ統合されている点が特徴です。今回のアップデートにより、AKSクラスター内のノード間通信がWireGuardを用いて自動的かつ透過的に暗号化されるようになります。これにより、アプリケーションやワークロードの変更を伴うことなく、ネットワークレベルでのセキュリティ向上を実現できます。具体的には、Azure CNIをCiliumおよびACNSと併用している環境でWireGuardが有効化されることで、ノード間のパケットがWireGuardトンネルを通じて暗号化され、外部からの盗聴や改ざんリスクを低減します。
技術的な実装としては、Ciliumが提供するネットワークポリシーおよびデータプレーン機能と、WireGuardのカーネルモジュールを組み合わせることで、ノード間の通信を自動的に暗号化します。これにより、Kubernetesクラスターの管理者は、追加の構成や複雑な証明書管理を行うことなく、セキュアな通信経路を確保できます。
活用シナリオとしては、機密性の高いデータを扱う業務システムや、複数のテナントが共存するマルチテナント環境、あるいは厳格なセキュリティ基準を満たす必要がある金融・医療分野のシステムなどが挙げられます。これらのシナリオでは、ノード間通信の暗号化が必須要件となる場合が多く、本アップデートによりAzure上での要件充足が容易になります。
注意点としては、WireGuardによる暗号化はAzure CNIをCiliumおよびACNSと組み合わせて利用しているAKSクラスターに限定される点です。また、既存のネットワーク構成やパフォーマンス要件に影響を与える可能性があるため、導入前には十分な検証が推奨されます。
本機能は、Azure Kubernetes Serviceのセキュリティ強化に寄与し、Azure CNI、Cilium、ACNSといった関連サービスとの連携によって、より堅牢なクラウドネイティブ環境の構築を支援します。
公開日時: 2026年04月24日 17:45:05 UTC リンク: Retirement: Support for .NET 8 (LTS) ends on November 10, 2026—upgrade your apps to .NET 10 (LTS)
アップデートID: 558033 情報源: Azure Updates API
カテゴリ: Compute, Mobile, Web, App Service, Retirements
要約:
何が更新されたか
Azure App Service上でサポートされている.NET 8 (LTS)のサポート終了日が2026年11月10日と発表されました。
主な変更点や新機能
.NET 8 (LTS)のサポート終了に伴い、セキュリティアップデートやカスタマーサポートの提供が終了します。今後は.NET 10 (LTS)へのアップグレードが推奨されています。
影響を受ける対象
Azure App Service上で.NET 8 (LTS)を利用しているアプリケーションが対象となります。サポート終了後もアプリケーション自体は動作しますが、脆弱性対応や技術サポートは受けられなくなります。
注意点があれば記載
2026年11月10日以降、.NET 8 (LTS)を利用したままではセキュリティリスクが高まるため、早めに.NET 10 (LTS)への移行計画を立てることを推奨します。サポート終了前に十分な動作検証とアップグレード対応を行ってください。
詳細:
2026年11月10日をもって、.NET 8（LTS）のサポートが終了します。Azure App Service上でホストされているアプリケーションは引き続き稼働しますが、サポート終了後はセキュリティアップデートの提供が停止され、.NET 8（LTS）に関するカスタマーサービスも受けられなくなります。これは、Microsoftが長期サポート（LTS）バージョンのライフサイクル管理方針に基づき、最新の技術とセキュリティを維持する目的で行われるものです。
今回のアップデートの主な目的は、開発者や運用担当者に対して、サポート終了前に.NET 10（LTS）へのアップグレードを促すことです。サポートが終了したバージョンを使い続けると、脆弱性への対応ができなくなり、セキュリティリスクが高まります。また、障害発生時や技術的な問題が生じた際のサポートも受けられなくなるため、安定した運用を継続するためには早期の移行が推奨されます。
具体的な変更内容としては、.NET 8（LTS）に対するセキュリティパッチやバグフィックスの提供が終了し、公式サポート窓口での問い合わせ対応も停止されます。アプリケーション自体はApp Service上で動作し続けますが、サポート終了後は新たな問題が発生した場合、自己責任で対応する必要があります。
技術的な仕組みとして、Azure App Serviceは複数の.NETバージョンをサポートしており、アプリケーションの設定やデプロイ時に使用する.NETバージョンを指定できます。アップグレードの際は、アプリケーションのコードや依存ライブラリが.NET 10（LTS）に対応しているかを事前に確認し、必要に応じてリファクタリングやテストを行うことが重要です。App Serviceの構成変更やCI/CDパイプラインの更新も必要になる場合があります。
活用シナリオとしては、企業の業務システムやWeb API、SaaSアプリケーションなどがApp Service上で.NET 8（LTS）を利用している場合、サポート終了前に.NET 10（LTS）への移行を計画し、段階的なテストとリリースを実施することが推奨されます。これにより、セキュリティやパフォーマンスの向上、最新機能の活用が可能になります。
注意点として、サポート終了後もアプリケーションが動作するため、移行作業を怠りがちですが、セキュリティリスクや障害対応の負担増加を避けるため、計画的なアップグレードが必須です。また、移行時には依存ライブラリや外部サービスとの互換性も十分に検証する必要があります。
関連するAzureサービスとしては、App Serviceの他にもAzure DevOpsやGitHub Actionsを利用したCI/CDパイプライン、Application Insightsによる監視、Azure Key Vaultによるシークレット管理などがあります。これらのサービスと連携しながら、.NETバージョンのアップグレードと運用管理を行うことで、より安全かつ効率的なシステム運用が可能です。
詳細は公式アップデートページ（https://azure.microsoft.com/updates?id=558033）をご参照ください。
公開日時: 2026年04月24日 16:45:30 UTC リンク: Generally Available: Cascading read replicas in Azure Database for PostgreSQL
アップデートID: 560939 情報源: Azure Updates API
カテゴリ: Launched, Databases, Hybrid + multicloud, Azure Database for PostgreSQL, Features
要約:
何が更新されたか
Azure Database for PostgreSQLで「カスケーディングリードレプリカ（Cascading read replicas）」機能が一般提供（GA）されました。
主な変更点や新機能
既存のリードレプリカからさらに新しいリードレプリカを作成できるようになりました。これにより、2段階のレプリケーション階層で最大30台までリードレプリカを構成できます。これまでよりも柔軟にリード負荷分散やスケーラビリティの向上が可能です。
影響を受ける対象
Azure Database for PostgreSQLを利用している技術者や、リード負荷の高いワークロードを運用しているシステムが対象です。特に、読み取り性能の拡張や高可用性構成を求める環境で有用です。
注意点があれば記載
リードレプリカの階層は2段階まで、最大30台までの制限があります。設計時にはこの制限を考慮する必要があります。また、レプリケーション遅延やコスト増加にも注意が必要です。
詳細は公式ドキュメントをご確認ください。
詳細:
Azure Database for PostgreSQLにおいて、カスケード型リードレプリカ機能が一般提供（GA）されました。本アップデートの背景には、リード中心のワークロードに対するスケーラビリティ向上のニーズがあります。従来はプライマリインスタンスから直接リードレプリカを作成する方式のみがサポートされていましたが、今回のアップデートにより既存のリードレプリカからさらにリードレプリカを作成することが可能となりました。これにより、二階層のレプリケーション構成を組むことができ、最大30台までのリードレプリカを展開できます。
具体的な機能としては、プライマリインスタンスから直接リードレプリカを作成するだけでなく、既存のリードレプリカを親として新たなリードレプリカを生成することができます。これにより、レプリカの階層構造が形成され、リードクエリの負荷分散や地理的分散に柔軟に対応できます。実装方法としては、Azure PortalやCLI、APIを通じてレプリカ作成操作を行うことで、カスケード型レプリカチェーンを構築できます。各レプリカは非同期レプリケーション方式でデータを受け取るため、整合性要件に応じて設計する必要があります。
活用シナリオとしては、グローバルに分散したアプリケーションで地域ごとにリードレプリカを配置し、ユーザーのアクセス遅延を低減するケースや、分析処理などリード負荷が高いワークロードで多数のレプリカを用いてスケールアウトするケースが挙げられます。また、障害時のフェイルオーバーやバックアップ用途にも有効です。
注意点として、レプリカチェーンは最大二階層までしか構築できず、レプリカの総数は30台までに制限されています。また、カスケード型レプリカは非同期レプリケーションであるため、レプリカ間のデータ整合性にはラグが生じる可能性があります。書き込み処理はプライマリインスタンスに限定されるため、レプリカはリード専用となります。レプリカの管理や監視には、Azure Monitorなどのサービスを活用することが推奨されます。
関連するAzureサービスとしては、Azure Database for PostgreSQLの他、Azure Monitorによる監視、Azure Backupによるバックアップ、Azure Resource Managerによるリソース管理などが挙げられます。これらのサービスと組み合わせることで、より堅牢かつスケーラブルなデータベース運用が可能となります。
公開日時: 2026年04月24日 16:45:30 UTC リンク: Generally Available: CRC Protection
アップデートID: 560889 情報源: Azure Updates API
カテゴリ: Launched, Storage, Azure Elastic SAN, Features
要約:
【何が更新されたか】
Azure Elastic SANでCRC-32Cチェックサム検証機能が一般提供（GA）されました。
【主な変更点や新機能】
Elastic SANボリュームへの接続時、クライアント側でCRC-32Cによるデータ整合性検証を有効化できるようになりました。新規作成時だけでなく、既存のElastic SANにもCRC保護を適用することが可能です。
【影響を受ける対象】
Elastic SANを利用しているAzureユーザーや、SANストレージ上で高いデータ整合性を求めるシステムを運用している技術者が対象です。特に、データの破損や転送エラーを検出したい場合に有効です。
【注意点】
CRC保護はクライアント側で有効化する必要があります。既存のElastic SANに対しても設定変更が可能ですが、運用環境での適用時はパフォーマンスや互換性への影響を事前に確認してください。
このアップデートにより、Elastic SAN利用時のデータ整合性向上と障害検出能力が強化されます。
詳細:
Azure Elastic SANにおいて、CRC-32Cチェックサム検証機能が一般提供（Generally Available）となりました。このアップデートの背景には、ストレージデータの整合性と信頼性向上へのニーズがあります。特に大規模な分散ストレージ環境では、データ転送時の誤り検出が重要であり、CRC（Cyclic Redundancy Check）による保護は、データ破損や通信エラーの早期発見に寄与します。
今回の変更点として、Elastic SANボリュームへの接続時に、クライアント側でCRC-32Cチェックサム検証を有効化できるようになりました。CRC保護はElastic SANの新規作成時だけでなく、既存のElastic SANにも適用可能です。これにより、ストレージ利用者は運用中の環境に対しても柔軟にデータ整合性保護を追加することができます。
技術的な仕組みとしては、クライアントがElastic SANボリュームにアクセスする際、データ転送時にCRC-32Cアルゴリズムを用いてチェックサムを生成・検証します。これにより、転送中のデータが意図しない変更や破損を受けていないかを検証でき、エラー検出率が向上します。CRC-32Cは高速かつ広く利用されているアルゴリズムであり、ストレージI/Oのパフォーマンスへの影響を最小限に抑えつつ、信頼性を高めることが可能です。
活用シナリオとしては、ミッションクリティカルなアプリケーションや金融、医療など高いデータ整合性が求められる業界でのElastic SAN利用時に、CRC保護を有効化することで、データ破損リスクの低減が期待できます。また、バックアップやアーカイブ用途でも、転送データの検証を通じて安全性を担保することができます。
注意点としては、CRC保護はクライアント側で有効化する必要があり、全てのクライアントが対応しているとは限りません。また、CRCチェックサムの計算には一定の処理負荷が発生するため、パフォーマンス要件と整合性要件のバランスを考慮して導入する必要があります。既存のElastic SAN環境に対しても設定変更が可能ですが、運用中のシステムへの影響を事前に評価することが推奨されます。
関連するAzureサービスとしては、Elastic SANはAzure Virtual MachinesやAzure Kubernetes Serviceなどのコンピュートリソースと連携して利用されることが多く、これらのサービスと組み合わせることで、高信頼性のストレージ基盤を構築できます。今回のCRC保護機能追加により、Azure Elastic SANのデータ整合性がさらに強化され、幅広いシナリオでの利用価値が向上しています。
このレポートは自動生成されました - 2026-04-25 12:01:53 JST