Azure

Microsoftは2026年5月22日、Azureの週次アップデートを公開した。データベースの運用自動化、外部コラボレーションのセキュリティ強化、ネットワーク管理改善に重点が置かれており、エンタープライズ環境の実運用に直結する変更が多数含まれている。 データベース：運用負荷を減らす自動化と移行の柔軟性向上 今回最も注目すべき変更がSQL自動インデックス圧縮（プレビュー）だ。データベースを長期運用していると、インデックスが断片化・肥大化してクエリパフォーマンスが低下する問題は多くのエンジニアが経験している。これまで手動での定期メンテナンスが必要だったが、Azureが自動的に圧縮を実行してくれるようになる。 SQL Managed Instanceの変更イベントストリーミングも追加された。近リアルタイムでの変更データキャプチャ（CDC）をEvent Hubsへ送信できる機能で、イベント駆動型アーキテクチャへの移行を検討している組織に有用だ。また、新しいHyperscale SKUとソフトデリートの追加も発表された。 Azure Database for PostgreSQLは移行元ソースとして、EDB（EnterpriseDB）とGoogle AlloyDBを新たにサポートした。最小ダウンタイムでの移行を実現するPGアウトプット機能と組み合わせることで、他クラウドやオンプレミスのPostgreSQL互換環境からの移行選択肢が大幅に広がった。 ベクター検索エンジンDiskANNの改善も含まれており、Azure上でのAI/RAG（検索拡張生成）ワークロードの高速化が期待できる。 Microsoft Fabric：データ統合の摩擦を減らす Microsoft Fabricにおいて、MySQLミラーリングをOneLakeへ取り込む機能が追加された。さらに、Cosmos DBのプライベートエンドポイントミラーリングがGA（一般提供）となり、カスタムパイプラインなしで運用データをFabricへ流し込めるようになった。分析とオペレーショナルデータをリアルタイムで連携させたいシナリオで活用できる。 ネットワーク：制限拡張とトラブルシューティング支援 NSG（ネットワークセキュリティグループ）とUDR（ユーザー定義ルーティング）の制限値が更新された。大規模ネットワーク構成を組む環境では制限値に悩まされることがあるため、実務への影響は小さくない。 Azure Front DoorにWebSocketサポートが追加され、リアルタイム通信が必要なアプリケーションをFront Door経由でより手軽に配信できるようになった。Network Watcherのルール影響アナライザーでは、ルール変更が実際のトラフィックにどう影響するかを事前に予測できる。誤った設定変更による予期しない通信断の防止に役立つ機能だ。 VPN強化としてS2S証明書認証とP2S接続のユーザーグループ別IPプール割り当てにも対応した。 ID・セキュリティ：外部コラボレーション管理の強化 Entra IDの外部MFAとテナントガバナンス機能が強化された。ゲストアカウントやB2Bコラボレーションのセキュリティポリシーをより細かく管理できるようになり、外部コラボレーションにおける認証制御が向上する。 Azure FilesにおいてEntra専用ID（Entra-only identity）でのアクセス制御がサポートされた。従来のパスワードベース認証を廃止しEntra IDに一元化できるため、ゼロトラスト推進の観点から歓迎できる変更だ。 AI統合：Cosmos DBとLangChain/LangGraphの連携 Cosmos DBにLangChain/LangGraphとの統合が発表された。RAGやLLMエージェントシナリオでのベクターデータ管理がシームレスになる。Azure AI Foundryのロール更新やモデルルーター改善と合わせると、Azureプラットフォーム上でのAIエージェント構築が実用的な段階に進んでいることがわかる。 日本のエンジニア・IT管理者への影響 データベース担当者にとって、SQLインデックス自動圧縮の検討が優先事項になりそうだ。プレビュー段階なので本番環境への適用は慎重に行うべきだが、定期メンテナンス作業の自動化は運用コスト削減に直結する。 移行プロジェクトを抱えているチームには、PostgreSQLの新移行ソース対応が朗報だ。EDBやGoogle AlloyDBを使っている環境からの移行障壁が下がった。 セキュリティ担当者は、Entra外部MFA強化とAzure FilesのEntra専用ID対応に注目。外部コラボレーションが多い組織では、ゲスト管理ポリシーを見直す良い機会だ。 AI・データ分析チームは、Cosmos DBのLangChain統合とDiskANN改善が実務レベルで使えるか評価する価値がある。 筆者の見解 今回のアップデートで特に評価したいのは、SQLインデックス自動圧縮とEntra外部MFA強化の2点だ。 インデックス肥大化への対処は、専任DBAがいない中小規模の組織では長年の悩みだった。クラウドの真の強みは「難しい運用をプラットフォームに任せ、エンジニアがより価値の高い仕事に集中できること」だと考えている。こういった運用自動化の積み重ねこそ、Azureが力を発揮する場面だ。 Entra IDの外部コラボレーション制御強化については、ゼロトラスト推進の観点から正しい方向性だと感じる。日本企業では外部ベンダーや業務委託先とのコラボレーションが増えているが、セキュリティポリシーの一貫性が保てていないケースも多い。常時アクセス権の付与は特権アカウント管理における最大のリスクであり、Entra IDを中心に据えた認証・認可の統一は、複雑化する組織のアクセス管理を整理するうえで有効な手段だ。 一方、今回のアップデートで少し惜しいと感じるのは、AI統合まわりの分散感だ。Cosmos DB、DiskANN、Azure AI Foundryとそれぞれに個別改善が入っているが、「Azureでエンドツーエンドのエージェントを構築するならこう使え」という統一されたストーリーが見えにくい。個々の機能は確実に良くなっているだけに、エンジニアが全体像を把握しやすい形での情報発信があるとなおよいと思う。 Azureには統合プラットフォームとしての強みを活かせる余地がまだ十分にある。積み上がっている機能群を実務レベルでの全体最適につなげていくことに期待したい。 出典: この記事は Azure Update 22nd May 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月、Azure SQL Managed Instance（SQL MI）のデータ変更をAzure Event HubsまたはFabric Evenstreamへニアリアルタイムで配信する「Change Event Streaming」機能をパブリックプレビューとして公開した。INSERT・UPDATE・DELETEの行レベル変更を、CDCやカスタムポーリングなしにSQLレイヤーだけで管理できる新しいアーキテクチャだ。 Change Event Streamingとは 従来、RDBMSの変更データをリアルタイムに別システムへ連携するには、Change Data Capture（CDC）の設定やカスタムポーリングスクリプトの実装が必要だった。CDCは強力だが設定が複雑で、ポーリングはレイテンシとリソースのトレードオフが常に課題となる。 Change Event Streamingはこの課題を解決する。SQLのトランザクションログと連携し、行レベルの変更イベントをCloudEvents形式のJSONとしてAzure Event Hubsに配信する。リトライや配信ログの協調管理はSQL側が担うため、アプリケーション側の実装を大幅に簡略化できる。 技術的なポイント CloudEvents準拠: 業界標準のイベントフォーマット（CNCF CloudEvents）でデータを配信。Kafka互換のEvent Hubs Consumer APIやFabric Evenstreamのコンシューマーからそのまま消費できる SQLレイヤーで完結: CDCのような外部エージェントやポーリングサービスが不要。設定はSQL MI側で一度行うだけ Fabric Eventstream対応: Microsoft Fabric（次世代データ統合プラットフォーム）のEvenstreamにも直接配信可能。リアルタイム分析パイプラインの構築が容易になる ニアリアルタイム: ミリ秒オーダーではないが、従来のポーリング方式と比較して大幅な低レイテンシ化が期待できる アーキテクチャの変化 従来のCDCベース構成と今回の変化を比較すると、中間レイヤーの排除による恩恵がよくわかる。 従来（CDCベース）: 出典: この記事は Stream data in near real time from SQL MI to Azure Event Hubs – Public Preview の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはAzure Resource Manager（ARM）をMCPサーバー経由でAIエージェントから操作できる「Azure Resource Manager MCP Server」のパブリックプレビューを開始した。同時に、Intel Xeon 6搭載の新世代VMシリーズ「Dl/D/E v7」の正式提供も始まり、2026年5月第19〜20週のAzureアップデートはインフラ自動化と高性能化の両面で見逃せない動きが揃った。 Azure Resource Manager MCP Server：AIエージェントがAzureを「しゃべって操作」する 今回最もインパクトが大きいのが、ARM MCPサーバーのパブリックプレビューだ。 Model Context Protocol（MCP）とは、AIエージェントが外部ツールやAPIを呼び出すための標準インターフェース仕様。このMCPサーバーを通じて、AIエージェントがARMを経由してAzureインフラを直接操作できるようになる。 具体的には以下が可能になる： 自然言語でARGクエリを生成・実行：「マネージドディスクを使っていないVMを一覧して」という問いに対し、AIがAzure Resource Graph（ARG）向けのKusto Query Language（KQL）クエリを自動生成して実行し、結果をリアルタイムで返す ARMテンプレートのデプロイ管理：リソースグループスコープでのデプロイ開始・進捗監視・問題検出・キャンセルまでをAIエージェントが担当できる KQLやARMテンプレートの記述はこれまでAzure運用の「専門家の壁」として機能してきた。この仕組みが整備されることで、自然言語ベースのインフラ操作が現実的な選択肢になる。 Azure Dl/D/E v7 VM：Intel Xeon 6で最大20%の性能向上 汎用・メモリ最適化VMの新世代として、Dl/D/E v7シリーズが正式提供（GA）された。Intel® Xeon® 6（開発コード名：Granite Rapids）を搭載し、前世代v6比で最大20%の汎用コンピュートパフォーマンス向上を実現する。 メモリ対vCPU比は3種類： シリーズ メモリ/vCPU 用途 Dlsv7 2 GiB コンピュートヘビー Dsv7 4 GiB 汎用 Esv7 8 GiB メモリヘビー 最大192 vCPUs（248・372 vCPUsは近日GA予定）。ローカルNVMe一時ディスクも選択可能で、低レイテンシーストレージが必要なシナリオにも対応する。現時点はCentral USのみで提供中、追加リージョンは順次展開予定。 Virtual Network Manager ルール影響分析：本番適用前にシミュレーション Azure Virtual Network Managerのルール影響分析機能がGAとなった。セキュリティ管理者ルールを本番ネットワークへ適用する前に、影響をシミュレートできる機能だ。 ネットワーク変更の誤設定は最悪の場合サービス断につながる。「やってみてから気づく」ではなく「事前に確認してから適用する」運用が標準化できる。ゼロトラスト移行中の組織にとっては特に重要な機能追加だ。 Application Gateway for ContainersがAKS Automaticに対応（プレビュー） これまでAKS Automaticクラスターではプロビジョニングできなかった制限が解除され、Application Gateway for ContainersをAKS Automaticのアドオンとして使用できるようになった（パブリックプレビュー）。Gateway API ベースのアプリケーション配信をAKS Automaticの簡略化された運用モデルの中に統合でき、手動インフラ管理の手間が削減される。 ...

Microsoftは2026年5月19日、Azure Files SMBにおける「Entra-Only ID認証（Entra-Only identities）」の一般提供（GA）を発表した。Microsoft Entra IDをKerberos認証の主体として直接利用する仕組みで、オンプレミスのActive Directory（AD）、ハイブリッドID同期、マネージドドメインコントローラーのいずれも不要となる。追加費用は発生せず、HDD・SSD全シェア・全課金モデルで利用できる。 これまでの課題：ADが「クラウド化の壁」だった Azure Filesへの移行を検討した企業がよく口にするのが「認証をどうするか」という問題だ。SMBプロトコルを使うファイル共有では、従来からWindowsのKerberos認証が前提となっており、その鍵配布センター（KDC）としてADが必須だった。 クラウドに移行しても、ADをオンプレミスに残すか、Azure AD Domain Services（現Microsoft Entra Domain Services）を立ち上げるか、いずれかのハイブリッド構成が必要だった。インフラチームが「ほぼクラウド化できたのに、ADだけ残っている」という状況は珍しくない。今回のGA発表は、その最後のブロッカーを正面から取り除くものだ。 何が変わったのか Microsoft Entra IDがKDCになる Entra-Only IDの核心は、Microsoft Entra IDがKerberos KDCの役割を直接担う点にある。クライアントはEntra IDに対して認証要求を出し、KerberosチケットをAzure Filesへのアクセスに使う。ADドメインへの参加は不要で、Entra参加済みのデバイスがあれば動作する。 ポータルからNTFSアクセス許可を設定できるように 従来、NTFS権限の設定にはドメイン参加済みクライアントからicaclsコマンドを叩く必要があった。今回のGAでは、Azureポータルから直接、ファイル・ディレクトリのACLをEntra-Onlyユーザー・グループに対して設定できるようになった。全リージョンで利用可能だ。 RBAC対応の拡充（限定リージョン） 共有レベルのRBAC（ロールベースアクセス制御）がEntra-Onlyユーザー・グループに対しても適用できるようになった。こちらは現時点では限定リージョンのみとなっており、対象リージョンは公式ドキュメントで確認が必要だ。 macOSクライアントへの拡張（限定プレビュー） Platform SSOでEntra参加したmacOSクライアントからも、Entra-Only認証でAzure Filesにアクセスできる。クリエイティブ職や混在環境での運用を想定した機能で、現在は限定プレビューの位置づけだ。 Azure Virtual Desktop（AVD）とFSLogixへの影響 Entra-Only IDが最も直接的な価値を発揮するのがAzure Virtual Desktop（AVD）＋FSLogixの構成だ。 FSLogixはユーザーのプロファイルをAzure Filesのファイル共有に置いてセッションホストにマウントする。従来はこのマウントにAD認証が必要だったため、AVDをフルクラウド化したくても「FSLogixのためだけにADを維持する」という矛盾した構成を取らざるを得なかった。 Entra-Only IDによってこの制約が解消される。さらにB2B（ビジネス間連携）サポートが組み込まれており、外部パートナーが自社のEntraアカウントでFSLogixプロファイルを利用できる。ゲストアカウントを別途作る必要がなく、ID管理の二重化を防げる。 実務への影響：日本のIT現場で何が変わるか ADのリタイア計画を具体化できる オンプレミスADを段階的に廃止したい企業にとって、「Azure FilesがADなしで動く」という事実は計画の実現性を大きく高める。ハイブリッドID（AD + Entra ID同期）との共存もサポートされているため、移行期間中に両方を並行運用することも可能だ。 VPNを減らす正当な根拠が生まれる Entra参加済みデバイスがあれば、VPNなしでAzure Filesへのリモートアクセスが成立する。「ファイルサーバーにアクセスするためにVPNを張らなければならない」という理由がひとつ消える。VPN廃止・縮小を検討している管理者には追い風だ。 IntuneとのID ライフサイクル統合 クライアント側のInture連携が組み込まれており、デバイスのコンプライアンス状態とファイルアクセス権を統合管理できる。退職者のアカウント失効・デバイス登録解除とファイル共有アクセスの無効化を一元的に扱えるのは、ID管理の工数削減に直結する。 追加コスト不要・既存シェアに適用可能 HDD・SSD共に、トランザクション最適化・ホット・クールのすべての課金モデルで追加費用なしに利用できる。既存のAzure Filesシェアに対して機能を有効化するだけで使えるため、新規リソースの作成も不要だ。 筆者の見解 ゼロトラスト推進の観点から言えば、このGAは「正しい方向への一歩」だ。ネットワーク境界を前提とした認証モデルの残滓であるオンプレミスADへの依存を、クラウドネイティブなID基盤で置き換えること——これはアーキテクチャとして筋が通っている。 Microsoft Entra IDがKDCを担うという設計は、エージェントやサービス間のID管理を将来的にEntraで一元化していく流れとも一致する。人間のアカウントだけでなく、Non-Human Identity（NHI）——サービスプリンシパル、マネージドID、ワークロードID——を含めたすべてのIDをEntraで管理できる世界に向けて、ファイル共有というレガシーなレイヤーをクラウドネイティブ化した意義は小さくない。 ...

Microsoftは、Azureセキュリティエンジニア向けの主力認定資格「AZ-500（Azure Security Engineer Associate）」を2026年8月31日に廃止し、後継資格「SC-500: Microsoft Certified: Cloud and AI Security Engineer Associate」を導入する。ベータ試験は2026年5月に開始済みで、正式試験および公式トレーニングは2026年7月提供開始予定だ。 なぜ今、資格体系が変わるのか AZ-500はAzureのセキュリティ機能を広くカバーしてきた実績ある資格だ。しかし、クラウドセキュリティの守備範囲はここ数年で急速に拡大している。生成AIワークロードの保護、AIを悪用した攻撃手法への対策、マルチクラウド環境への対応——これらを既存カリキュラムに継ぎ足していくには限界があると判断したのだろう。 名称に「AI」が明示的に入ったことは象徴的だ。Azureセキュリティの問題が、インフラ保護だけでなくAIそのものをどう安全に動かすかという次元に移行したことを、Microsoftが資格体系として公式に認めた形になる。 SC-500が問われる主要領域 正式な出題範囲は7月の正式公開まで確定しないが、名称と業界トレンドから以下が主軸になると見られる。 AIワークロードのセキュリティ設計: Azure OpenAI ServiceやAzure AI Foundryを使ったワークロードの権限分離・データ保護 Non-Human Identities（NHI）の管理: サービスプリンシパル・マネージドIDなど、人間以外のアイデンティティへのJust-In-Timeアクセス制御 ゼロトラストアーキテクチャの適用: Microsoft Entra IDを基点としたハイブリッド・マルチクラウド環境の認証・認可設計 脅威検知・対応: Microsoft Defender for Cloud、Microsoft Sentinelを活用した継続的監視とインシデント対応 移行スケジュールと受験戦略 時期 イベント 2026年5月 SC-500ベータ試験開始 2026年7月 正式試験・公式トレーニング提供開始 2026年8月31日 AZ-500廃止 現在AZ-500を学習中の人は、カリキュラムが旧来の形で残っているうちにAZ-500を取るか、SC-500に切り替えるかを判断する必要がある。ベータ試験は通常より低い受験料で受けられる場合が多く、アーリーアダプターとして実績を積む意味でも検討に値する。 すでにAZ-500を保有しているエンジニアは、更新期限を確認した上で、SC-500へのアップグレードパスがどう整備されるかMicrosoft Learnの公式アナウンスを追いたい。 日本のAzureエンジニア・IT管理者への実務的示唆 AZ-500の廃止はただの試験リニューアルではなく、現場スキルの再定義を意味する。 AIエージェントが業務プロセスに入り込んでくる今、従来のセキュリティ設計の盲点として浮上しているのがNHI（Non-Human Identities）の権限管理だ。エージェントやバッチジョブが持つサービスプリンシパルが過剰権限のまま運用されているケースは多く、攻撃者にとっては格好の侵入経路になる。SC-500がここを問う内容になるなら、資格学習が直接インシデント防止につながる可能性がある。 また、ゼロトラストへの移行途上にある日本の大規模企業は、VPN依存の旧来モデルとEntra IDベースの新モデルが混在した状態になっていることが多い。SC-500の学習を通じてゼロトラストの設計原則を体系的に整理することは、資格取得の副産物として現場に還元できる価値が大きい。 筆者の見解 セキュリティ系の資格は、細かい規制フレームワークのマッピングや番号暗記が多く、個人的には得意分野とは言えない領域だ。それでも今回の刷新については「良い方向に踏み出した」と感じている。 理由はシンプルで、資格名にAIが入ったこと自体より、AIワークロードのセキュリティ設計という実務課題が試験の対象になることの方が重要だからだ。Copilotやエージェントが組織のシステムに接続し、メールを読み、ファイルを操作し、外部APIを叩く——そのような権限を持つ存在のIDライフサイクル管理を、きちんと問える試験になるなら価値がある。 Microsoftには、SC-500が「名前だけ刷新した資格」にならないよう期待したい。ベータ試験の出題傾向が出そろえば、カリキュラムの本気度が見えてくる。Just-In-Timeアクセスとゼロトラストが試験のコアに据えられているなら、現場で即戦力になる証明として機能する資格になり得る。 Entraを基点としたアイデンティティ管理という方向性はMicrosoftの強みそのものだ。それをAIの時代に合わせて定義し直そうとしているこの動きは、正面から評価していい。 出典: この記事は New Microsoft Certified: Cloud and AI Security Engineer Associate Certification の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは2026年5月、Azure Virtual Desktop（AVD）向けRDP Multipathに冗長TCP経路（Redundant TCP Transport）サポートを追加し、一般提供（GA）ロールアウトを開始した。企業ネットワークの20〜30%を占めるとされるUDP制限環境での「Multipathが機能しない」という盲点が、今回のアップデートで解消される。 RDP Multipathとは何か RDP Multipathは2025年7月にGAを迎えた機能で、ICE（Interactive Connectivity Establishment）プロトコルを使って複数のネットワークパスを発見・管理し、プライマリパスが劣化した際に自動切り替えを行う。WebRTCでも広く用いられる手法で、セッションをネットワーク品質の変動から守る仕組みだ。 ただし初期設計はUDP専用だった。厳格なファイアウォールポリシーや集中型セキュリティアプライアンスを持つ環境——日本では金融・医療・官公庁系を中心に珍しくない構成——では、UDPが制限されておりMultipathの恩恵を受けられなかった。 今回の変更点 今回GAとなったのは、このICEフレームワークにTCP冗長パスを組み込む機能だ。技術的なポイントは以下の通り。 UDPと同様に複数のアクティブ・スタンバイTCPパスを候補プールとして管理 ネットワーク劣化を検知すると自動でパスを切り替え 設定変更不要——環境に導入後は透過的に動作 段階的ロールアウトのため、すべてのホストプールが同時に有効化されるわけではない クライアント要件: Windows App 2.0.1069.0以降 なぜこれが重要か UDPの壁は現実問題 ゼロトラスト移行が進む企業であっても、歴史的なネットワーク制約は一朝一夕では取り除けない。レガシー機器、MPLS回線のルーティング設計、コンプライアンス要件による通信制御——これらが重なると、UDP開放は「やりたくてもできない」状態になりやすい。AVD導入を検討しつつ「接続安定性」を懸念材料に挙げていた組織にとって、TCP冗長化は実質的なブロッカー解消だ。 恩恵が大きいシナリオ テレワーク・在宅勤務環境: 家庭用ルーターやISPの制約でUDPが不安定になるケース 拠点オフィス（支店・営業所）: SD-WANやMPLS回線での非対称ルーティング モバイルユーザー: ホテルWi-Fi、空港Wi-Fi、モバイルホットスポット 実務への影響 動作前提の確認が最初の一手 RDP Shortpathが前提インフラとなるため、まだ導入していない環境では事前整備が必要だ。Microsoftの公式ドキュメントに沿ってRDP Shortpathを有効化し、その上でWindows Appを2.0.1069.0以降に更新する。Intuneを使った一括更新配布が効率的だ。 ヘルプデスクコスト削減の定量評価を AVD環境での「接続が切れた」系チケットは管理工数の大きな消費源だ。自動フェイルオーバーが機能することでセッション切断の頻度が下がり、ヘルプデスクへの問い合わせ数を直接削減できる。セッション安定性をKPIとして測定している組織は、ロールアウト前後の数値を比較しておくと経営層への説明材料になる。 実務チェックリスト RDP Shortpathが実装済みかどうかを確認する Windows Appバージョンを2.0.1069.0以降に更新する（Intuneで配布管理） ファイアウォールポリシーを見直し、TCPとUDP双方が最適化されているか確認する 段階的ロールアウトの適用タイミングをAzureポータルで監視する 筆者の見解 RDP MultipathのUDP専用設計は「理想を追った最初の一手」として理解できるが、現実のエンタープライズ環境には歴史的な制約がある。それを認め、TCP冗長化を追加したこの判断は現実的で、評価に値する。 Azure Virtual DesktopはAzure基盤の信頼性に乗っかった価値ある選択肢であり、こうしたネットワーク耐障害性の継続改善はその価値を着実に高める。「設定変更不要で透過的に動作する」という設計思想も正しい。エンタープライズグレードのサービスに求められるのは、ユーザーに意識させない透明性だ。 日本のIT現場では、ゼロトラスト移行の道半ばで「UDP制限環境では最新機能が使えない」というギャップに悩む組織が一定数いる。今回の機能追加はそのギャップを埋めるものとして、AzureのクラウドVDI採用を後押しする意味を持つ。地道な改善の積み重ねこそがプラットフォームへの長期的な信頼を築く——そのことをこのアップデートは改めて示してくれた。 出典: この記事は RDP Multipath with Redundant TCP Transport – GA Rollout Begins for Azure Virtual Desktop の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftはVS Code向け拡張機能「Microsoft Foundry Toolkit」を正式版（GA）としてリリースした。これにより開発者は、Azure AI Foundryのモデルカタログ参照・デプロイ・プロンプト管理・評価といった一連の作業をVS Codeを離れることなく完結できるようになる。 Microsoft Foundry Toolkitとは何か Microsoft Foundry Toolkit（旧称: Azure AI Foundry Extension for VS Code）は、Azure AI FoundryとVS Codeを直接橋渡しするIDE拡張機能だ。プレビュー期間を経て今回GAとなったことで、企業の開発標準ツールチェーンへの正式採用がしやすい状況になった。 GA版で提供される主な機能は以下のとおり： モデルカタログの参照: Azure AI Foundryが提供するGPT-4o、Claude、Mistral、Llama等の多様なモデルをIDE内でブラウズできる モデルのデプロイ: 選択したモデルをAzure上にデプロイする操作をVS Codeから直接実行可能 プロンプト管理: プロンプトのバージョン管理や編集がIDE内で行える 評価（Evaluation）: モデルの出力品質をIDE内で評価・比較する機能 プレビューからGAへ——何が実際に変わるのか プレビューとGAの違いは単なる「ラベル変更」ではない。GAになることで以下の点が変わる： SLAと安定性の保証が付く。プレビュー機能は予告なく変更・廃止されるリスクがあるため、企業の本番ワークフローには組み込みにくい。GA化によってこの障壁が取り除かれる。 エンタープライズIT部門の承認が通りやすくなる。社内のソフトウェア管理ポリシーにおいて「プレビュー版」と「GA版」を明確に区別している組織は多い。開発チームがFoundry Toolkitの導入稟議を上げる際に、GAであることは重要な根拠になる。 ドキュメントとサポートが充実する。プレビュー期間中はドキュメントが追いついていないケースもあるが、GA後はMicrosoftの公式サポート対象として整備が進む。 日本のエンジニア・IT管理者への影響 VS Codeはすでに多くの日本企業で標準的なIDEとして採用されている。そこにAIモデル管理の機能が直接統合されることは、AIアプリケーション開発の現場にとって具体的なメリットがある。 実務での活用ポイントを整理しておこう： モデル比較検討の効率化: ChatGPTやClaude等、複数モデルをブラウザやAPIクライアントを行き来して比較していた作業がIDE内で完結する。コンテキストスイッチが減り、開発フローが途切れない プロンプトエンジニアリングの標準化: プロンプトをコードと同じリポジトリで管理できるため、チームでのレビューやバージョン管理がしやすくなる。「誰かのローカルにしかない最強プロンプト」問題の解消につながる 評価の自動化: モデルの出力品質評価をCIパイプラインに組み込む第一歩として活用できる。「なんとなく使ってみて良さそうだった」から「定量的に評価して選定した」への移行を助ける 企業内AI利用の統制: Azure AI Foundry経由でモデルを管理することで、どのモデルを誰がどの規模でデプロイしているかをAzureのロールベースアクセス制御（RBAC）やコスト管理ツールで把握できる。野良AI利用の抑制にも効く IT管理者の視点では、開発者が勝手に外部のAIサービスを使い始めることへの対策として、「公式に使いやすい選択肢を提供する」アプローチが有効だ。Foundry Toolkit＋Azure AI Foundryはその文脈で評価に値する。 筆者の見解 MicrosoftのAzureプラットフォームが、AIモデルを「選んで使う場所」として機能する方向に進んでいることは、長期的に見て正しい戦略だと思っている。特定のモデルを自社で作り勝つ競争ではなく、あらゆるモデルが最も安全に動作する基盤を提供する競争——この土俵ではMicrosoftには強みがある。 Foundry Toolkitが今回GAになったことは、その戦略を開発者の日常的なワークフローにまで着地させようとする取り組みの一つだ。IDE統合というアプローチは理にかなっている。開発者は基本的にIDEから離れたくない生き物であり、そこにモデル管理を持ち込むのは摩擦を下げる正しい方向だ。 ただし、機能が揃うことと実際に使われることは別の話だ。プロンプト管理や評価の機能は、チームの開発文化として根付いて初めて価値を発揮する。ツールを導入して終わりではなく、「なぜこの評価指標を使うのか」「プロンプトのレビューをどう回すか」という運用設計がセットで必要になる。ツールを導入した後のプロセス設計まで、Microsoftのドキュメントやコミュニティがどこまで支援できるか、今後の展開を注目したい。 Azure AI FoundryとVS Codeという、いずれも現場に定着したプロダクトを組み合わせた拡張機能がGAになった。これは地味に見えて、企業でのAI開発標準化に向けた着実な一歩だ。 出典: この記事は Microsoft Foundry Toolkit for VS Code is Now Generally Available の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft Azure AI Foundryに、画像生成AIの新たな選択肢としてTongyi-MAI Z-Image-Turbo（阿里巴巴）、FLUX.1-schnell（Black Forest Labs）、Stable Diffusion XL Base 1.0（Stability AI）の3モデルがHugging Faceコレクション経由で追加され、即日利用可能になった。 追加された3モデルの概要 Tongyi-MAI Z-Image-Turbo 阿里巴巴（Alibaba Cloud）が開発した高速画像生成モデル。「Turbo」の名が示す通り、高品質な画像を短い推論時間で生成することに最適化されている。中国発の主要AIモデルがAzureのエンタープライズ基盤上で提供される意義は大きく、グローバルなAIモデルポートフォリオの充実を示している。 FLUX.1-schnell Stability AIの元コアメンバーが設立したBlack Forest Labsによる画像生成モデル。FLUXシリーズは高い画像品質と多様なスタイル対応で注目を集めており、schnell（ドイツ語で「速い」）バリアントは推論速度を重視したバージョンだ。オープンウェイトモデルとして公開されており、コミュニティでの採用実績も豊富なため、既存の社内ワークフローへの組み込みもしやすい。 Stable Diffusion XL Base 1.0 画像生成AIの代名詞とも言えるStable Diffusionの上位版。1024×1024ピクセルの高解像度出力に対応し、プロンプトへの忠実度が向上している。すでに多くの企業が社内ツールや製品に組み込んでいる実績のあるモデルが、Azure基盤のエンタープライズSLAとともに利用できるようになった。 HuggingFaceコレクション経由での提供 今回の追加はAzure AI FoundryのHugging Faceコレクション機能を通じて提供される。Hugging Face上のモデルをAzureのマネージドエンドポイントとして展開できるこの仕組みは、オープンソースモデルのデプロイに伴う運用負荷を大幅に削減できる点が魅力だ。 開発者はHugging Faceで慣れ親しんだモデルを、Azureのセキュリティ・コンプライアンス・監視の仕組みの上でそのまま動かせる。APIの形式もAzure AI Foundryの標準に統一されるため、既存のAzure SDKや認証基盤との統合も容易だ。 実務への影響 画像生成ユースケースの多様化 これまでAzure AI Foundryで画像生成というと主にDALL-E系モデルが中心だったが、今回の追加で選択肢が大幅に広がった。具体的なユースケースとして以下が考えられる： マーケティング素材の自動生成: 商品画像のバリエーション生成、SNS向けビジュアルの量産 社内ドキュメントの図解補完: 技術ドキュメントや提案書への挿絵をAIで自動生成 eコマース: 商品の着用イメージや背景差し替えの自動化パイプライン ゲーム・コンテンツ開発: アセット生成をAzure基盤に統合してCI/CDと連携 エンタープライズ統制との両立 個人利用ではMidJourneyやAdobe Fireflyを使うエンジニアも多いが、企業のセキュリティポリシー上、外部SaaSへのデータ送信が制限されるケースは日本企業では特に多い。Azure AI Foundryを使えば、プロンプトや生成画像がAzureテナント内に留まるため、情報漏洩リスクを管理しやすい。 Microsoft Entra IDベースのアクセス制御、Azure Monitorによるログ収集、Azure Policyによるガバナンスといった既存のエンタープライズ管理インフラとの連携も自然に行える点は、大企業の情報システム部門には響く訴求ポイントになる。 筆者の見解 Azure AI Foundryが「使いたいモデルを安全に動かせるプラットフォーム」として着実に成熟してきていることを、今回の3モデル追加は改めて示している。自社でフロンティアモデルを開発する競争とは別の軸、すなわち「どのAIモデルでも受け入れる管制塔」としての戦略が形になってきている。 日本のエンタープライズ環境では、どんなに優れた技術でも「セキュリティとコンプライアンスをクリアできるか」が導入の最初のハードルになる。情報システム部門に「AzureのAIサービスとして使う」と説明できれば、個別SaaSを申請するよりも圧倒的に話が通りやすいはずだ。その意味で、FLUXやStable DiffusionをAzure基盤で動かせる選択肢は実務的な価値が高い。 ...

Microsoftは2026年5月のPatch Tuesday（月例セキュリティ更新）で、Azure Cloud Shellに存在するCVSSスコア最高値10.0の権限昇格脆弱性（CVE-2026-32169）を含む138件の新規CVEに対応した。いずれも公開時点での野良悪用は未確認だが、スコアの深刻さと攻撃対象の広さから、即時対応が求められる内容だ。 Azure Cloud Shellの最高危険度脆弱性（CVE-2026-32169） CVSS 10.0は現行の評価体系で取り得る最大値であり、事実上「考え得る最悪の条件が揃っている」を意味する。Azure Cloud Shellはブラウザ経由でBashやPowerShellを直接操作できるマネージドサービスで、インフラ管理者やDevOpsエンジニアが日常的に利用する。この脆弱性は権限昇格（Elevation of Privilege）に分類される。 技術的な詳細は現時点で限定的な公開にとどまるが、CVSSの最大値が付与される条件としては「認証不要・ユーザー操作不要・ネットワーク越しに攻撃可能」の組み合わせが典型的だ。 実務対応: Azure Cloud Shellはマネージドサービスのため、ユーザー側での手動パッチ適用は不要。Microsoftがバックエンドを自動更新する。ただし、Azure Monitorを使って5月以前のCloud Shell利用ログを確認し、不審なコマンド実行がないか確認しておくことを推奨する。 特に注意すべき脆弱性 CVE-2026-41089：Windows Netlogon リモートコード実行（CVSS 9.8）—最優先パッチ スタックベースのバッファオーバーフローを悪用し、ドメインコントローラーに特定のネットワークリクエストを送信するだけで認証不要・ユーザー操作不要のRCEが成立する。ZDIは本脆弱性を明示的に「ワーム化可能（wormable）」と評価しており、ドメインコントローラーが侵害された場合はドメイン全体の陥落を意味する。 Active Directoryを軸に動いている日本のエンタープライズにとって、これは最悪シナリオに直結する。テスト環境での確認を最短化してでも、展開を急ぐ価値がある。 CVE-2026-41096：Windows DNS Client リモートコード実行 ヒープベースのバッファオーバーフローを悪用し、悪意のあるDNSレスポンスによってWindowsマシン上でコードを実行できる。認証不要・ユーザー操作不要で、実質すべてのWindowsマシンが攻撃対象となりうる点が脅威だ。MitM（中間者攻撃）ポジション、または偽DNSサーバーを用意できる攻撃者が、企業内ネットワーク全体を標的にできる可能性がある。 Microsoft Dynamics 365（CVE-2026-42898） ERP・CRM環境を運用している組織は個別にMicrosoftのセキュリティ情報を確認し、オンプレミス版の場合は特に手動適用が必要かを確認されたい。 今月の全体像：138件のCVE、30件がCritical 今月は138件の新規CVEを対象とし、30件がCritical、3件がModerate、1件がLow、残りがImportant評価だ。なお今月はちょうどPwn2Own Berlinの直前にあたり、ベンダーがイベント前にできる限り脆弱性を修正する慣行も件数増の一因と見られる。件数の多さはAIを活用した脆弱性発見の増加を反映している部分もある、と今回の調査を執筆したZDIは指摘している。 AdobeのMay 2026パッチ Adobeは10件のセキュリティ情報で52件のCVEに対応した。優先度が高いのは以下の2件だ： Adobe Commerce（APSB26-49）：15件のCVE、最高CVSS 8.7、デプロイ優先度「2」（早急対応推奨） Adobe Connect（APSB26-50）：2件のCVEがいずれもCVSS 9台 その他After Effects、Illustrator、Premiere Pro等の主要クリエイティブツールも対象だが、いずれも野良悪用は未確認。 日本のエンジニア・IT管理者への実務ポイント Netlogonパッチ（CVE-2026-41089）を最優先に：ADドメインを運用している組織はこのパッチを即時展開する。「ワーム化可能」という評価を軽視しない Azure Cloud Shellのログ確認：マネージドサービスだが、Azure Monitorで5月以前の利用ログを確認し不審なアクティビティがないかを横展開で調査する DNS通信の監視強化：CVE-2026-41096対応として、EDR・NDRでDNSレスポンスへの異常検知設定を見直す WUFBやWSUSの配布スケジュール確認：今月は大規模リリースのため、配布遅延が生じていないか確認し必要に応じて即日展開設定に変更する Adobe製品の更新：デザイン・マーケティング部門が使用するAdobe製品も忘れずに更新する 筆者の見解 Azure Cloud ShellのCVSS 10.0という数字を見たとき、率直に驚いた。Azureポータルのあんなに身近な場所にそれほどの危険度の穴があったのか、という感覚だ。一方で、マネージドサービスであることはこういう場合にはっきりメリットが出る。自分でパッチを当てなくていい。Microsoftが迅速に対応してくれた点は素直に評価したい。 より気になるのはNetlogon（CVE-2026-41089）のほうだ。「ワーム化可能」とZDIが明言した脆弱性はそう多くない。日本のエンタープライズの多くはAD依存が強く、ドメインコントローラーへの無認証RCEは事業継続そのものを脅かす。パッチを当てれば解決するが、パッチ適用を後回しにする組織が必ず出てくる。それが心配なのだ。 DNS ClientとNetlogonの脆弱性はどちらも「内部ネットワークにいればそれだけで信頼される」という旧来の前提が崩れる類のものだ。VPN境界に頼ったセキュリティモデルでは一点突破で全滅しかねない。ネットワーク・認証・認可の3層防御とJust-In-Timeアクセスの実践を、この機会に組織内で改めて見直してほしい。月例パッチは毎月くる。それに対応し続けられる仕組みを持っているかどうか、今一度確認する価値がある。 出典: この記事は Critical Azure Cloud Shell Elevation-of-Privilege Vulnerability (CVE-2026-32169, CVSS 10.0) Fixed in May 2026 Patch Tuesday の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは2026年5月21日、Microsoft Securityの月次大規模アップデートを発表した。エージェント管理基盤「Agent 365」の一般提供（GA）開始、組織内で管理外運用されている「シャドウAIエージェント」の検出・管理機能のプレビュー提供（Claude Codeなどローカルエージェントも対象）、そしてDefender for Storageの自動マルウェア修復GA化が主な内容だ。 Agent 365がGAへ——エージェント管理の「管制塔」が正式稼働 Agent 365は、組織内で稼働するAIエージェントを一元的に可視化・管理するためのプラットフォームだ。2026年5月のアップデートでGAとなり、本番運用が正式に可能になった。 AIエージェントの利用が急拡大する中、「どのエージェントが何にアクセスできるか」「エージェント同士がどう連携しているか」を把握できない状況は、セキュリティ上の重大なリスクとなる。Agent 365はMicrosoft Entra IDと統合し、エージェントのIDライフサイクル管理を実現する基盤として設計されている。 シャドウAIエージェントの検出機能がプレビュー提供開始 今回のアップデートで特に注目されるのが、「シャドウAIエージェント」の検出・管理機能だ。シャドウAIエージェントとは、IT部門の管理外で個人が導入・運用しているAIエージェントのことを指す。Claude Codeのようなローカル環境で動作するコーディングエージェントも検出対象として明示されている点が重要だ。 AIエージェントの普及は、かつてのSaaS普及期における「シャドウIT」問題と酷似した構造を持つ。個人や小チームが業務効率化のために導入したエージェントが、気づかぬうちに機密データにアクセスしたり、外部サービスと通信したりするケースはすでに現実として起きている。 この機能はプレビュー段階だが、エージェントの動作を観測し、ポリシー違反を検出・アラートする仕組みを提供する。 Defender for Storage：悪意あるBlobの自動ソフト削除がGA Azure Blob Storageにマルウェアがアップロードされた際、自動的にソフト削除（論理削除）する機能がGAとなった。これにより、悪意あるファイルを即座に隔離しつつ、誤検知の場合でも一定期間内に復元できる。ランサムウェアの侵入経路としてストレージは標的になりやすく、アップロードされた時点で自動的にブロック・隔離できることは実務上の価値が高い。 実務への影響 AIエージェントの「野良運用」は今すぐ把握すべき 組織内で何人のエンジニアがローカルのAIエージェントを使っているか、正確に把握できている管理者は現状ほとんどいないだろう。この状況は、AIエージェントが「実際にコードを書き、APIを叩き、外部サービスと連携する」現代においては深刻なリスクだ。 シャドウAIエージェント検出機能はIT管理者にとって今後不可欠なツールになると見られる。プレビュー期間中に評価環境でテストし、GA時にスムーズに展開できる準備を今から始めるべきだ。 NHI（Non-Human Identity）管理の観点で捉える AIエージェントもIDを持ち、リソースにアクセスする。このNon-Human Identity（NHI）の管理は、人間のIDと同様にライフサイクル管理が必要だ。「エージェントに過剰な権限を与えたまま放置」は特権アカウント管理における古典的な失敗パターンそのものであり、Just-In-Time（JIT）アクセス制御の考え方をエージェントにも適用し、「必要なときだけ、必要な権限だけ」を原則とすることが重要だ。 Defender for Storageの自動修復は今日から有効化を Blobストレージを利用しているAzure環境であれば、Defender for Storageの自動マルウェア修復はすぐに有効化を検討してほしい。設定の複雑さは低く、得られる防御効果は大きい。ソフト削除であるため、万が一の誤検知にも対応できる設計になっている。 筆者の見解 今回のアップデートを見て感じるのは、Microsoftが「現場で実際に起きていること」に正面から向き合い始めているということだ。 シャドウAIエージェントの問題は、セキュリティベンダーが声高に叫ぶ「高度な攻撃」よりも、むしろ多くの現場で今まさに進行しているリアルな課題だ。エンジニアが各自で使い始めたコーディングエージェントがどんな権限で動いているかを把握していない——この状況を「禁止」で解決しようとすると必ず失敗する。「禁止ではなく、安全に使える仕組みを用意する」という方向性は正しい。 Agent 365とMicrosoft Entra IDの統合という方向性も、AIエージェントの管制塔として機能させるという長期戦略として筋が通っている。AIが普及すれば普及するほど、「どのエージェントに何の権限を与えるか」を安全に管理できるプラットフォームの価値は増す。Microsoftにはこの分野での優位性がある。 もったいないのは、こうした実質的な取り組みが、機能のてんこ盛りや複雑な製品ブランドによって見えにくくなりがちな点だ。現場の課題を直接解決する機能を継続的に積み上げていくこの姿勢を、もっと前面に出してほしい。それができる力が、Microsoftには間違いなくある。 出典: この記事は What’s new in Microsoft Security: May 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftのAzure Database for PostgreSQLチームが、OracleデータベースからAzure Database for PostgreSQLへの移行をAIで自動化するVS Code拡張機能を公開した。スキーマ変換・PL/SQLコード翻訳・マルチエージェント検証を一気通貫で処理し、長年移行プロジェクトの最大の障壁だった工数とリスクの問題に正面から切り込む。 Oracleからの脱却を阻む「最後の難所」 Oracleから別のDBMSへの移行を検討した経験のあるエンジニアであれば、テーブル定義の変換よりもPL/SQLストアドプロシージャやトリガーの書き換えが工数の大半を占めることを肌で知っているはずだ。Oracle固有の組み込みパッケージ（DBMS_OUTPUT、UTL_FILEなど）、カーソル処理、例外ハンドリングの構文差異は機械的な置換では対応できず、業務ロジックを熟知したエンジニアが1行1行確認する必要があった。 今回公開されたVS Code拡張機能は、この「最後の難所」にAIで踏み込む。 ツールの主な機能 スキーマ自動変換（DDL変換） OracleのCREATE TABLEや制約定義をPostgreSQL互換のDDLに変換する。NUMBER→NUMERICなどのデータ型マッピングや、両者で挙動が異なるシーケンス・インデックス定義の差異も自動検出して対応する。 PL/SQL → PL/pgSQL 翻訳 ストアドプロシージャ、ファンクション、トリガーに埋め込まれたPL/SQLコードをPostgreSQL向けのPL/pgSQLに翻訳する。Oracle固有パッケージの代替実装も提案するため、翻訳後のコードがPostgreSQL上でそのまま動作することを目指している。 GitHub Copilotによるマルチエージェント検証 GitHub Copilotを活用したマルチエージェントが翻訳後のコードを自動検証する。変換後コードに潜む論理エラーや互換性の問題を検出し、「翻訳はできたが動かない」という状況を防ぐ仕組みだ。 VS Codeネイティブな体験 既存の開発環境であるVS Codeの拡張として動作するため、別途ツールの導入や学習コストが発生しない。エンジニアは普段の作業フローの延長線上で移行作業を進められる。 実務への影響 日本の大規模エンタープライズには、20〜30年以上稼働するOracleシステムを今も多数抱える企業が少なくない。Oracleのライセンスコストは近年さらに上昇しており、PostgreSQLへの移行は「コスト削減」と「クラウドネイティブ化」を同時に達成できる有力な選択肢だ。 これまで移行プロジェクトを躊躇させてきた最大の理由は工数とリスクだった。数万行規模のPL/SQLコードを持つシステムでは、翻訳・テスト・検証にかかる人月コストが移行コスト全体の大半を占めることもある。AIによる自動翻訳とマルチエージェント検証の組み合わせは、このボトルネックを大きく緩和する可能性がある。 エンジニア・IT管理者への実践的なアドバイス: まず小規模なサブシステムで精度を見極める: PL/SQL依存度の低い周辺システムから試し、変換品質と残工数を定量的に把握してから全社展開を判断する 自動変換後の業務ロジックレビューは必須: 翻訳精度が高くなっていても、業務ロジックの正確性は最終的に人間が確認する。特に複雑なカーソル処理や例外ハンドリングは重点的にレビューする Azure Database Migration Serviceとの組み合わせを検討: スキーマ・コード変換はこのVS Code拡張で、実データのETLはAzure Database Migration Serviceで——三位一体の移行計画を立てると抜け漏れが減る GitHub Copilotのライセンスが前提: マルチエージェント検証にCopilotが必要なため、組織のライセンス状況を事前に確認しておく 筆者の見解 データベース移行、特にOracleからの移行は「分かっているけど手が付けられない」案件の代表格だった。費用対効果は明確でも、移行リスクと工数が意思決定を阻み続けてきた。 今回のアプローチ——VS Codeに統合されたAIが変換・翻訳・検証を一気通貫でこなす——は、その構造的な障壁を崩す可能性がある。人間が1行1行確認していたPL/SQL翻訳をAIが担い、マルチエージェントが品質を担保する。「仕組みを作れる人間が少数いれば、あとはAIが回す」という流れが、データ基盤の移行領域にも着実に波及してきた。 Azureのインフラとしての信頼性は揺るがない。その上に乗るデータベース層をオープンソースのPostgreSQLに寄せていく方向性は、ベンダーロックインのリスク分散という観点でも理にかなっている。Entra ID統合によるセキュリティ向上やマネージドサービスとしての運用負荷軽減も、移行先としてAzure Database for PostgreSQLを選ぶ積極的な理由になる。 一点付け加えるなら、公開されたばかりの拡張機能を全社規模のOracleシステムにいきなり適用するのは早計だ。まず実際の本番コードベースの一部で変換精度を検証し、残工数を見積もった上で判断する——その慎重さがあってこそ、このツールの恩恵を最大限に引き出せる。検証の結果が良好であれば、長年先送りにしてきたOracle脱却のプロジェクトを動かす絶好の契機になるはずだ。 出典: この記事は No code left behind: How AI streamlines Oracle-to-PostgreSQL migration の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftはAzure DevOpsのSprint 273アップデートをリリースし、大規模リポジトリ運用を妨げていたGitオブジェクト数の上限撤廃をはじめ、プルリクエスト（PR）レビューフローの改善や新しいWindows ARM64エージェントのパブリックプレビュー提供など、開発チームの生産性に直結する機能強化を一括して展開した。 Gitオブジェクト数上限の撤廃：モノレポ時代への対応 今回のアップデートの中で最もインパクトが大きいのが、Azure ReposにおけるGitオブジェクト数上限の完全撤廃だ。 従来、Azure DevOpsのリポジトリにはGitオブジェクト（コミット、ツリー、ブロブなど）の総数に制限が設けられており、長年にわたる開発履歴を持つ大規模リポジトリや、複数プロジェクトを一元管理するモノレポ構成では上限に引っかかるケースがあった。今回この制限が撤廃されたことで、リポジトリの成長を気にせず設計できるようになる。 フロントエンド・バックエンド・インフラのコードを単一リポジトリで管理するモノレポ戦略を取る組織や、CI/CDの履歴が膨大になったレガシーリポジトリを抱える企業にとって、この変更は実質的な制約から解放されることを意味する。 PRリストへの未解決コメント表示：レビュー漏れを防ぐ これまでAzure DevOpsのPRリストでは、各PRの未解決コメントスレッドの状況がひと目では把握できず、レビューが完了しているのか、まだコメントが残っているのかを個別に開いて確認する必要があった。 Sprint 273ではPRリスト上に未解決コメントスレッドが直接ハイライト表示されるようになり、複数のPRを並行してレビューしているシニアエンジニアや、チームのPRステータスを管理するリーダーが一覧から状況を素早く把握できるようになった。 External バッジ：サードパーティステータスポリシーを明確に区別 PRのステータスチェックに関しても重要な改善が入った。これまで、Azure DevOps標準のブランチポリシー（ビルド検証や必須レビュアーなど）と、SonarQubeやSnykといったサードパーティ製の外部ステータスポリシーが視覚的に区別できず、PRがブロックされた際にどちらの原因かがわかりにくかった。 今回追加された「External」バッジにより、外部ツールによるステータスチェックが明示されるようになった。トラブルシューティングの時間短縮と、開発者の「なぜブロックされているのか」というフラストレーション解消に寄与する、小さいが確実に効く改善だ。 Windows ARM64エージェントのパブリックプレビュー Azure PipelinesのセルフホステッドエージェントとしてWindows ARM64対応がパブリックプレビュー（Windows 11向け） として提供開始された。 Qualcomm Snapdragon搭載のSurface ProシリーズやCopilot+ PCが普及する中、ARM64ネイティブでビルドとテストを実行できる環境を整えたい組織にとって、待望の機能追加となる。特に、x64エミュレーション経由で発生するパフォーマンスロスを排除したい開発チームには試す価値がある。 その他の改善点 GitHub Advanced Security for Azure DevOpsでは、削除済みまたはAdvanced Securityが無効化されたリポジトリがセキュリティ概要ビューに表示されなくなった。無効なエントリが残り続けてリスクスコアが歪む問題が解消され、実際にスキャンされているリポジトリのみが対象として表示される。 Azure BoardsではWork Itemのコピー機能が改善され、親リンクと子リンクを個別に選択してコピーできるようになった。「親は同じにしたいが子は引き継がない」といったユースケースに柔軟に対応できる。 GitHub統合REST APIのセキュリティも強化され、旧来のOAuthトークンからGitHub App OAuthトークンへ移行。自動トークン更新が可能になり、手動での再認証が不要になった。 日本のエンジニア・IT管理者への実務的影響 Gitオブジェクト上限の撤廃は、特に長期間運用しているエンタープライズ向けリポジトリを持つ組織に恩恵が大きい。従来、上限回避のためにリポジトリを分割したり、historyを刈り込む運用をしていたチームは、その制約を前提とした設計を見直せる可能性がある。 PRレビューの可視化改善は、コードレビューをDevOpsプロセスの中核に置いているチームにとってすぐに活用できる変更だ。Externalバッジと組み合わせることで、「誰がなぜブロックしているのか」の説明コストが下がり、開発テンポが上がる。 Windows ARM64エージェントについては、現時点でパブリックプレビューのため本番環境への即時適用よりも検証環境での評価から始めるのが現実的だ。Copilot+ PCをエンジニアに支給している組織では、ビルド性能の比較検証を行っておく価値がある。 筆者の見解 Gitオブジェクト上限の撤廃は、地味に見えて実は大事な決断だと思う。スケーラビリティ上限というのはいつか必ず踏む地雷であり、「今はまだ大丈夫」と放置していると移行コストが膨らむ。これを先んじて取り除いたことは評価したい。 PRレビューの可視化改善や Externalバッジの追加も、現場の開発者の声をちゃんと聞いた改善に見える。GitHubのUXに慣れたエンジニアが「Azure DevOpsはわかりにくい」と感じがちだった部分を地道に削っている姿勢は正しい方向だ。 Windows ARM64エージェントについては、今後ARM64デバイスが開発機として本格普及した時に「対応済み」である重要性が増してくる。先手を打っていることは間違いなく、あとは正式リリースまでどれだけ丁寧にフィードバックループを回せるかが問われる。 Azure DevOpsはGitHubとの統合深化という大きな流れの中で、自分の立ち位置を再定義している最中にある。エンタープライズ向けの堅牢なデプロイ管理・ガバナンス機能という軸で磨き続ければ、必ず光る領域がある。Sprint 273のような地に足のついた改善の積み重ねが、その土台になると筆者は見ている。 出典: この記事は Azure DevOps Sprint 273 Update – Repository Git Object Limit Removal の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは、AMD EPYC第5世代プロセッサ「Turin（Zen 5アーキテクチャ）」を搭載したAzure仮想マシンの新3シリーズ「Dav7」「Eav7」「Fasv7」の一般提供（GA）を発表した。汎用・メモリ最適化・コンピュート最適化の主要カテゴリを一括でカバーする今回のリリースは、価格性能比とI/O帯域幅の両面で前世代から大幅な引き上げを実現している。 AMD EPYC「Turin」とは何か AMD EPYC Turinは、Zen 5マイクロアーキテクチャに基づく第5世代のEPYCサーバープロセッサだ。前世代の「Genoa（Zen 4）」から引き続き多数のコアと広帯域メモリを特徴とするが、IPC（クロックあたりの命令実行数）が向上しており、同一コア数でのスループットが改善されている。エネルギー効率も改善されているため、コストあたりの計算能力という観点で競争力が増している。 3シリーズの概要 Dav7シリーズ（汎用） Webサーバー、小〜中規模データベース、開発・テスト環境など幅広いワークロード向け。vCPUとメモリのバランスが取れた構成で、多くの一般的な業務システムの移行先として適している。 Eav7シリーズ（メモリ最適化） SAP HANAやインメモリデータベース、大規模な分析ワークロードなど、高メモリを必要とするシステム向け。メモリ対vCPU比が高く設定されており、データをオンメモリで保持し続けるシステムに向いている。 Fasv7シリーズ（コンピュート最適化） 高クロック周波数を活かしたバッチ処理、ゲームサーバー、高スループットなWebアプリケーション向け。シングルスレッド性能が重要なワークロードに適している。 Azure Boost統合によるI/O性能の向上 今回の3シリーズはすべてAzure Boostに対応している。Azure Boostとは、ネットワークおよびストレージの処理をホストCPUからMicrosoftの専用オフロードハードウェアへ移すMicrosoftの独自技術だ。これにより、購入したvCPUリソースの大部分を実際のワークロードに使えるようになる。従来はハイパーバイザーの管理処理に消費されていた分のCPUサイクルが節約され、特にI/O集中型ワークロードでの実効性能が前世代から引き上げられている。 実務への影響 — 日本のエンジニア・IT管理者が知るべきこと 既存VMの移行候補として評価する価値がある 特にDsv5やEasv5シリーズを使用中の環境では、同一スペックで月額コストが下がるか、同一コストでスペックアップできる可能性がある。移行前にAzure Price Calculatorで比較検証をしておきたい。 SAP・Oracle等のライセンス課題に注意 メモリ最適化のEav7はSAP HANAのユースケースに適しているが、SAP製品のAzure認定VMリスト（SAP Certified IaaS Platforms）に掲載されているかどうかを必ず事前確認すること。新シリーズのSAP認定は正式リリースから数ヶ月遅れで取得されるケースがある。 リージョン展開状況の確認を忘れずに 新VMシリーズは全リージョンで同時提供開始になるわけではない。東日本・西日本リージョンでの提供有無とクォータ申請の要否は、Azureポータルの「Virtual Machines」→「サイズ」フィルターで確認できる。 コンピュート集約型のAI推論ワークロードへの転用 GPU VMほどではないが、CPU推論（ONNX Runtime等）を使う軽量なAIワークロードでは、Fasv7のような高クロック構成が費用対効果の高い選択肢になることがある。 筆者の見解 Azureのコンピュートプラットフォームとしての地力は、こういったアップデートを見るたびに改めて確認できる。AMD EPYCとの連携深化は着実で、ハードウェア側の進化をクラウドユーザーがタイムリーに享受できる仕組みは整っている。 ただ正直なところ、「どのVMシリーズを選ぶか」という判断の重要性は、AIワークロードの台頭とともに相対的に変わりつつある。Azureを活用する上で今本当に重要なのは、GPU/NPUリソースの調達とAzure AI Foundry上でのモデル選択の戦略であり、CPU VMの細かいチューニングはその次の話になってきている。 とはいえ、既存の業務システムやデータ基盤はCPU VMで動き続ける。コスト最適化の観点でDav7・Eav7・Fasv7への移行を定期的に見直すのは地味だが確実なアプローチだ。Azureのインフラ基盤への信頼は揺るがない。その上でどのサービスとどのAIを組み合わせるかを考えるのが、今の正しいAzure活用の姿だと思っている。 出典: この記事は Announcing General Availability of Azure Da/Ea/Fasv7-series VMs based on AMD ‘Turin’ processors の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、クラウドメッセージングサービス「Azure Service Bus Premium」向けに、ハードウェアベースのTrusted Execution Environment（TEE）を活用したコンフィデンシャルコンピューティングの一般提供（GA）を発表した。韓国中部およびUAE北部リージョンから提供が開始され、既存のアプリケーションコードを変更することなく有効化できる。 コンフィデンシャルコンピューティングとは何か データのセキュリティには従来、「保存時の暗号化」（encryption at rest）と「転送時の暗号化」（encryption in transit）が2本柱だった。しかしデータが実際に処理・演算される「使用中」（in use）の状態は、これまで保護が難しい領域とされてきた。 コンフィデンシャルコンピューティングはこの第三の課題を解決するアプローチだ。ハードウェアレベルで隔離された信頼された実行環境（TEE）内でデータを処理することにより、クラウドプロバイダーや基盤インフラの管理者であっても処理中のデータにアクセスできない状態を実現する。AzureではIntel TDX（Trust Domain Extensions）などのプロセッサ機能を活用してTEEを実装している。 Azure Service Bus Premiumでの実装：アプリ変更ゼロが最大の特徴 今回のGA発表で特筆すべきは、導入のシンプルさだ。名前空間単位で有効化するだけで、その名前空間配下のすべてのキュー、トピック、サブスクリプションにコンフィデンシャルコンピューティングが自動適用される。接続文字列の変更も、アプリケーションコードの修正も不要だ。 なおこの機能はPremiumティア限定となっている。TEEの特性上、専用ハードウェアリソースの割り当てが前提となるため、共有リソースモデルのStandardティアでは技術的に実装できない。 対応リージョン（2026年5月時点） リージョン 状況 韓国中部（Korea Central） GA済み UAE北部（UAE North） GA済み 日本東部・西部 未対応（ロードマップ要確認） 現時点で日本リージョンは対象外となっている。国内の金融・医療・公共機関での本格採用を検討する場合、日本リージョンへの対応時期を公式ロードマップで確認してから設計を進める必要がある。 実務への影響 金融・医療・公共分野のエンジニアへ メッセージングの処理中に個人情報・医療情報・金融取引データが流れるアーキテクチャでは、この機能が強力な追加防御層になる。ゼロトラストの「常に検証する」原則をメッセージング層にも貫きたいシステム設計において、処理中データの保護は見落とされがちなポイントだった。 ただし繰り返しになるが、現時点では日本リージョン非対応だ。データレジデンシー要件がある場合は対応を待つか、韓国中部リージョンでの代替構成の可否を法務・コンプライアンスチームと協議する必要がある。 Non-Human Identity（NHI）管理の観点から マイクロサービスやイベント駆動アーキテクチャでは、アプリケーション間のメッセージングにService Busを使う構成が多い。これらのワークフローはサービスプリンシパルやマネージドIDといったNHIが実行する自動化処理だ。 NHIが送受信するメッセージにセンシティブなデータが含まれる場合、コンフィデンシャルコンピューティングにより処理中の保護も担保できる。「セキュリティ要件を理由に自動化を制限せざるを得なかった」ユースケースへの突破口になる可能性がある。 実装時のチェックポイント ティア確認: StandardからPremiumへの移行が必要か確認し、コスト評価を先に行う 必要な権限: 名前空間の設定変更には所有者または共同作成者ロールが必要 リージョン選択: 現時点では韓国中部・UAE北部のみ。日本リージョン対応まで待つか否かを設計段階で決める 監査ログ: TEEの利用状況はAzure Monitor・診断ログで追跡可能 筆者の見解 コンフィデンシャルコンピューティングは「データ保護の第三の柱」として位置づけられる技術であり、保存時・転送時の暗号化が標準化された次のフロンティアとして注目されてきた。それをメッセージングサービスに展開してきたことは、エンタープライズ向けのセキュリティ設計としての方向性は正しいと思う。 「アプリ変更不要」という設計判断も評価できる。セキュリティ強化策を現場に展開する際、「アプリの修正が必要」となった瞬間にプロジェクトは複雑化しコストが跳ね上がる。名前空間単位でON/OFFできるシンプルな有効化フローは、現場での採用障壁を下げるという意味で重要な設計判断だ。 一方で、日本リージョン非対応は率直に惜しい。金融・医療・公共分野での採用拡大を本気で狙うなら、日本のデータレジデンシー要件に対応したリージョン展開を早期に進めてほしいところだ。Azureはエンタープライズ基盤としての実績とブランドがある。その土台があるだけに、リージョン対応の速度が採用のボトルネックになるのはもったいない。 日本のIT現場では、「クラウドにデータを置くこと自体への懸念」を持つステークホルダーがまだ多い。コンフィデンシャルコンピューティングは、その懸念に対する技術的な回答の一つになり得る。「処理中でもクラウド事業者はデータの中身を見られない」という説明は、重要なコンプライアンス要件を持つ組織の意思決定を後押しする力がある。日本リージョンでの対応を待ちながら、アーキテクチャ設計に組み込む準備を今から進めておく価値のある発表だ。 出典: この記事は Announcing general availability of confidential computing for Azure Service Bus Premium の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftはAI推論プラットフォームのFireworks AIをMicrosoft Foundryに統合すると発表した。高速推論に強みを持つFireworks AIのモデル群がFoundry経由で利用可能になり、リアルタイム性が求められるエンタープライズAIアプリケーション開発の選択肢が大きく広がる。 Fireworks AIとは何者か Fireworks AIは「推論速度」に特化したAIプラットフォームとして知られる。自社でAIモデルの研究開発を競うのではなく、Llama系やMistral系といったオープンソースモデルを独自の最適化技術で高速化し、業界トップクラスの低レイテンシで提供することを強みとしている。 同社が打ち出す数値はインパクトが大きく、汎用クラウドのAI APIと比較して数倍から十数倍のトークン生成速度を実現するケースも報告されている。コスト効率も高く、特定のユースケースでは他のマネージドサービスより大幅に低いコストで同等の性能を得られる点が評価されてきた。 Microsoft Foundryへの統合で何が変わるか Microsoft Foundryは、Azure上でAIモデルの選定・デプロイ・管理・監視を一元化するプラットフォームだ。OpenAI、Meta、Mistral AIなど複数のモデルプロバイダーをすでに収録しており、今回のFireworks AI統合はその拡充にあたる。 統合によって得られる最大のメリットは、Azureの既存インフラとのシームレスな接続だ。Microsoft Entra IDによる認証・認可、Azure Policy によるガバナンス、既存のAzure課金体系への統一——これらをFireworks AIのモデルにもそのまま適用できる。 つまり、エンタープライズがFireworks AIの高速推論を採用する際に「別のクラウドアカウントを開設し、新たなセキュリティレビューを通し、コスト管理の仕組みを作り直す」といった導入コストが不要になる。既存のAzure環境に対してAPIエンドポイントを向け直すだけで利用が始まる構造だ。 低レイテンシが重要なユースケースに直撃 Fireworks AIが特に輝くのは、推論速度がユーザー体験や業務効率に直結する場面だ。 リアルタイム音声AI・会話エージェント: 音声入力から応答生成までのRound-Trip Timeが体験品質を決める。100msを超えると違和感が生まれ、300msを超えると実用に耐えない。Fireworks AIの低レイテンシはこのユースケースと相性がよい。 コード補完・開発支援ツール: GitHub Copilotのような補完体験を自社環境で内製する場合、キーストロークに追従する速度が求められる。 大量同時リクエストへのスループット: 数千人が同時に使う社内チャットボットや、ECサイトのレコメンデーションエンジンなど、スループットが重要な場面でのコスト最適化に有効だ。 実務への影響——日本のエンジニア・IT管理者に向けて モデル選定の自由度がFoundry内でさらに広がった。日本企業がAzureを使いながらOpenAI GPT-4系の速度や価格に課題を感じているなら、同じFoundryのUI・APIから代替モデルを試す選択肢が増えたことを意味する。A/Bテストや段階的移行もFoundryのオーケストレーション機能を使って管理しやすくなる。 コンプライアンス面でも導入が現実的になった。日本のエンタープライズでよく問題になる「新しいAIサービスのセキュリティ審査」「データの所在確認」「契約手続き」のハードルが、Azure経由の統合によって大幅に低くなる。情報システム部門とセキュリティチームへの説明コストも減る。 価格感度の高い用途での活用を検討したい。推論コストが積み重なる大規模バッチ処理や、無制限に近い社内APIとして展開する場合、Fireworks AIのコスト効率は財務的なインパクトを持ちうる。Foundry上でのコスト可視化と合わせて試算してみる価値がある。 筆者の見解 この発表を見て思ったのは、「Microsoftはプラットフォームとして正しい戦略を着実に実行している」ということだ。 自社でモデル開発競争の最前線を走ることに苦戦しているとしても、「あらゆるAIが安全・安定して動くプラットフォーム」を構築するという戦略は本質的に正しい。Fireworks AIのような高速推論に特化した専業プロバイダーをFoundryに取り込むことで、エンタープライズはMicrosoftのガバナンス・セキュリティ基盤を保ちながら、最適なモデルを選んで組み合わせられる。 このアプローチは「Azureの上で動かすAIを選ぶ自由を使えばいい」という考え方と完全に一致している。Microsoft Foundryが「AIの管制塔」として機能し始めているのは歓迎すべき方向だ。 ただ一点、今後に期待したいのはドキュメントと料金体系の分かりやすさだ。Foundryに統合されるモデルプロバイダーが増えれば増えるほど、どのモデルをどのユースケースに選ぶべきかの判断が複雑になる。「比較しやすく、試しやすく、切り替えやすい」体験を磨き続けることが、このプラットフォーム戦略を成功させる鍵になると思う。その力はMicrosoftには十分ある。 出典: この記事は Announcing Fireworks AI on Microsoft Foundry の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月、Azureのネットワーク基盤に関する包括的なアップデートを発表した。AIワークロードへの対応強化、ゾーン冗長アーキテクチャの全面展開、そしてDNS脅威インテリジェンス保護の正式提供（GA）が主な柱で、エンタープライズが直面するスケール・セキュリティ・可用性の3課題に同時に踏み込む内容となっている。 AIを軸に再設計されたネットワーク基盤 Azureのグローバルネットワークは、AIワークロードの急増に対応するために設計の前提そのものが変わりつつある。現時点でAzureは60以上のAIリージョン、80万キロメートル超の光ファイバー網、そして4 Pbps以上のWAN帯域を持つ。さらに、FY24年末比で全体容量が3倍に拡張され、現在は18 Pbpsに達した。 AIモデルのトレーニングは、長時間にわたる大帯域フローと、GPU間の超低レイテンシ通信という、従来のクラウドワークロードとは質的に異なる要件を持つ。Azureはこれに対し、InfiniBandと高速Ethernetを組み合わせたロスレスデータ転送アーキテクチャで対応している。分散GPUクラスターはリージョン間を専用AIワイドエリアネットワーク（AI WAN）で接続し、Azure Private Linkとハードウェアベースの仮想ネットワークアプライアンス（DPU搭載）によって安全かつ高パフォーマンスな通信を実現する。 この構成は、GPUをただ並べてスケールさせるだけでなく、ネットワーク層からAIに最適化するという思想の具現化だ。クラウドプロバイダーの競争軸が「コンピュート量」から「ネットワーク品質」へとシフトしていることを示している。 高可用性の標準化──ゾーン冗長NAT Gateway V2がGA AzureはIgnite 2025で発表したStandard NAT Gateway V2を正式提供（GA）に引き上げた。これはExpressRoute、VPN Gateway、Application Gatewayに続くゾーン冗長対応の追加で、アウトバウンド通信の可用性が一段と向上する。 主な仕様は以下のとおり： ゾーン冗長: 1ゾーン障害時に自動でトラフィックを他ゾーンへ分散 スループット: 最大100 Gbps 処理能力: 毎秒1,000万パケット IPv6: 標準対応 追加コストなし: ゾーン冗長化に追加料金は発生しない 「ゾーン冗長をデフォルトに」というAzureの方針が、ゲートウェイ系サービス全体に浸透してきたことが明確に見て取れる。マルチゾーン構成をわざわざ手設計する手間が不要になり、インフラチームの運用負荷は下がる。 セキュリティの深化──DNS脅威インテリジェンス保護がGA DNS Security Policy with Threat Intelが正式提供に移行した。これは継続的な脅威インテリジェンスフィードと連携し、悪意あるドメインへの名前解決をリアルタイムでブロックする機能だ。 DNSはゼロトラスト設計においてしばしば見落とされる攻撃面の一つだ。VPNを排除してゼロトラストを進めても、DNS経由の脅威が残存していれば意味がない。この機能のGAは、Azureがネットワーク層・認証層・認可層の多層防御を実装するうえでの重要なピースを埋めるものだ。 日本のエンタープライズへの影響と実務ポイント 日本のIT現場でこのアップデートが直接関係するのは、以下のシナリオだ。 AIワークロードをAzure上で動かすチームへ GPUクラスターを複数リージョンにまたがって配置する場合、AI WANと専用Private Link構成の活用を検討する InfiniBandベースのHigh-Performance Compute（HPC）SKUと、今回強化された通常Ethernetベースのルートが何を対象とするか整理しておく ゾーン冗長設計を進めているインフラチームへ NAT GatewayがSKU追加料金なしでゾーン冗長化できるようになった。既存のV1を使っている環境はV2への移行計画を立てるタイミングだ ExpressRoute・VPN・App Gateway・NAT Gatewayと主要ゲートウェイが揃ったことで、アウトバウンド・インバウンド双方のゾーン冗長が設計しやすくなった ゼロトラスト移行を推進するセキュリティチームへ DNS Security PolicyのGAにより、プライベートDNSゾーンへの脅威インテリジェンス統合が本番利用可能になった。既存のAzure Firewallと組み合わせた多層防御の設計を見直す価値がある ゼロトラスト移行の際に「VPN廃止後のDNS制御はどうするか」は必ず議論になる。このタイミングでDNS Security Policyを設計に組み込みたい Non-Human Identity（NHI）と自動化の観点 サービス間通信の自動化を進めると、NHIがAzureネットワークリソースにアクセスするシナリオが増える。Private LinkとDPUベースのアプライアンスは、こうしたNHI通信の安全な経路として機能する ゾーン冗長化によりネットワーク可用性が上がると、自動化パイプラインの安定性も向上する。インフラの堅牢化は自動化推進の前提条件だ 筆者の見解 Azureのネットワーク基盤は、正直に言って地味に見えがちな領域だ。しかし今回のアップデートはその評価を変えるに足る内容だと思う。18 Pbps到達というスケール、ゾーン冗長の標準化、DNS脅威インテリジェンスのGA、どれを取っても「やるべきことをやっている」という印象を受ける。 ...

MicrosoftとSAPは、2026年5月開催の年次カンファレンス「SAP Sapphire 2026」において、Azure上でのSAP連携に関する複数の重要アップデートを発表した。RISE with SAPにおけるAzureの採用比率が60%を超えたことが明らかになったほか、SAP Datasphere MirroringとMicrosoft Fabricの統合がGA（一般提供）に達するなど、エンタープライズ向けクラウド・データ基盤の両社協業が新たなフェーズに入った。 RISE with SAPのAzure採用率が60%超に RISE with SAPは、SAPのオンプレミスERPをクラウドへ移行するための包括的サービスプログラムだ。SAP S/4HANAへのアップグレードから運用保守まで一括で請け負うモデルとして多くの大企業に採用されており、今回の発表でそのAzure採用比率が60%を超えたことが確認された。 この数字は単なるシェアではない。ERPのコア部分がAzure上に乗っているということは、Microsoft EntraによるID管理、Microsoft Sentinelによるセキュリティ監視、Teamsとの業務フロー連携など、Microsoft 365エコシステム全体との統合が自然な形で可能になることを意味する。SAPを使い続けながらMicrosoftスタックで全体最適を図るという設計が、エンタープライズ市場で着実に支持を集めている。 SAP Datasphere MirroringとMicrosoft Fabric統合がGA 今回の発表の中でエンジニアに最も影響が大きいのが、SAP Datasphere MirroringとMicrosoft Fabricの統合のGA化だ。 SAP Datasphere Mirroringを使うと、SAP S/4HANA上のビジネスデータをリアルタイムに近い形でFabricへ複製できる。これまでSAPデータをBIやAI分析に活用するには、ETL処理や複雑なデータパイプラインの構築が必要で、データエンジニアの工数が相当かかっていた。GAによってこのフローが標準化・安定化することで、Power BIやFabric上のAI機能とSAPの業務データをより簡単に接続できるようになる。 具体的には以下のようなユースケースが現実的になる： SAP S/4HANAの在庫・受注データをFabricへ連携し、需要予測モデルをAzure AI上で動かす SAPの財務データとSalesforceや外部データを同一のFabricワークスペースで横断分析する Power BIレポートをSAPデータの最新状態で自動更新し、経営ダッシュボードを維持する SAP Data Sovereignty CloudをAzure Governmentで提供 もう一つの注目発表が、SAP Data Sovereignty CloudをAzure Government環境で提供するという内容だ。官公庁・防衛・金融など高度なデータ主権要件を持つ業種・業態向けに、SAPワークロードを物理的・論理的に分離されたAzure Government環境で稼働させることが可能になる。 日本では直接Azure Governmentリージョンの利用は限定的だが、このアーキテクチャ設計の方向性は参考になる。日本の省庁や重要インフラを担う企業が「SAP × クラウド」を検討する際のリファレンスモデルになり得る。 実務への影響：日本のSAPユーザー企業が注目すべき点 データ活用の民主化が加速する Fabric統合のGAは、SAPデータ活用のハードルを大きく下げる。これまでSAPとBIをつなぐには専門的なSAP BASIS知識やBW/BEX設計スキルが必要だったが、Mirroring経由であればFabricのUIから設定できるケースが増える。データエンジニアやBI開発者が独立して動けるようになることで、SAPチームの負荷分散にもつながる。 SAPのEOL（2027年問題）対応との組み合わせ SAP ECC 6.0の標準保守期限（2027年）が迫る中、RISE with SAPへの移行を検討している企業は多い。その際の移行先としてAzureを選択すると、上述のFabric統合やEntraとのID連携がすぐに活用できる状態になる。移行と同時にデータ活用基盤を刷新できるのは大きなメリットだ。 Microsoft Entraによる統合ID管理 RISE with SAPをAzureで動かすと、Microsoft Entra IDによるシングルサインオン・条件付きアクセス・Just-In-Timeアクセス管理がSAPにも適用できる。SAPのロール・認可管理は複雑で運用負荷が高い傾向があるが、Entraと連携させることでガバナンスの一元化が図れる。 ...

MicrosoftはMicrosoft Build 2026の開幕に先立ち、完全マネージド型Redisサービス「Azure Managed Redis」の新機能プレビューを公式ブログで発表した。エンタープライズ向けのキャッシュ強化と、AIワークロードへの最適化が今回の中心テーマとなっており、AIシステムの「速さの要」となるキャッシュ層に大きな変化が訪れようとしている。 Azure Managed Redisとは何か Azure Managed Redisは、Microsoftが提供する完全マネージド型のインメモリデータストアサービスだ。従来の「Azure Cache for Redis」に続く形で登場し、Redis Enterprise技術をベースにしている。Redis Stackのモジュール群（RedisSearch、RedisJSON、RedisTimeSeriesなど）をネイティブに統合しており、単純なキャッシュ用途を大きく超えた活用が可能な点が特徴だ。 Build 2026での注目機能：AIワークロードへの本格対応 今回のプレビュー発表でとりわけ注目されるのが、AIワークロードへの最適化だ。具体的には以下の方向性が示されている。 ベクター検索とRAGへの対応強化 生成AIシステムで広く採用されているRAG（Retrieval-Augmented Generation）アーキテクチャにおいて、キャッシュ層は重要なボトルネックになりやすい。Azure Managed Redisはベクター検索機能を備えており、埋め込みベクターを高速に検索・格納する用途での活用が期待されている。 セマンティックキャッシュ LLM（大規模言語モデル）への同一または類似クエリは、毎回推論を実行するとトークンコストが積み上がる。セマンティックキャッシュは意味的に近い質問に対してキャッシュ済み回答を返す仕組みで、コスト削減とレスポンス高速化の両立を実現する。Azure Managed Redisではこの用途に向けた最適化が進んでいる。 エンタープライズ向けキャッシュの信頼性強化 アクティブ・ジオレプリケーション、99.99%のSLA、Flashストレージ層の活用によるコスト最適化など、大規模エンタープライズ環境での運用を想定した機能群もBuild 2026で詳細が明らかになる見込みだ。 実務への影響：日本のエンジニアが今すぐ考えるべきこと AIシステム設計でのキャッシュ戦略を見直す Azure OpenAIやAzure AI Foundryを使ってLLMアプリを構築している場合、キャッシュ層の設計は後回しにされがちだ。しかし、運用フェーズに入るとトークン費用とレイテンシが想定外に膨らむケースが多い。今がキャッシュ戦略を組み込む設計を見直す好機だ。 Azure Cache for RedisからのパスをBuildで確認せよ 既存の「Azure Cache for Redis」ユーザーは、Azure Managed Redisへの移行パスや機能差異をBuild 2026のセッションで確認することを強く勧める。特にRedis Stackモジュールを使っている場合、移行による恩恵は大きい可能性がある。 RAGアーキテクチャ設計時のキャッシュ配置 RAGシステムでは「埋め込み生成→ベクター検索→LLM回答生成」という流れのどこにキャッシュを置くかで、コストと応答速度が劇的に変わる。Azure Managed Redisのベクター検索とセマンティックキャッシュを組み合わせることで、ベクター検索コストとLLMトークンコストの双方を削減できる設計が現実的になる。 筆者の見解 Azure Managed Redisが「AIワークロード最適化」を正面に掲げてきた点は、素直に評価したい。AIシステムを実際に運用するエンジニアにとって、キャッシュ層はコスト管理と応答品質の両方に直結する重要インフラだ。ここにMicrosoftが本気で投資してくるのであれば、Azure上でのAIシステム構築の完成度は着実に上がる。 ただ、一点気になるのは「プレビュー発表」というタイミング設計の問題だ。Build直前にプレビューを告知して、本番GAはまだ先、というパターンはMicrosoft製品では繰り返し見られる。エンタープライズ現場では「使える」と「使えるかもしれない」の差は大きい。今回の発表を追いかけて設計に織り込むのは、GAのタイミングを見極めてからにするのが現場の賢い判断だろう。 とはいえ、Azureのプラットフォームとしての方向感は正しい。AIワークロードが急増する中で、インフラ層からAI統合を設計し直そうとしているのは、ちゃんとやるべきことをやっている姿勢だと思う。Microsoft Build 2026のセッション詳細が出揃った段階で、改めて踏み込んで評価したい。 出典: この記事は Know before you go: Azure Managed Redis at Microsoft Build 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

クラウドデプロイプラットフォームのRailwayが、2026年5月19日（UTC）、Google Cloudによる誤ったアカウント停止を起因とする約8時間の全面障害を経験した。GCPの制御プレーン停止が引き金となり、AWSや自社インフラ「Railway Metal」にまで障害が波及するカスケード障害が発生し、全リージョンのワークロードが到達不能となった。 何が起きたか 日本時間2026年5月20日早朝（UTC 22:20頃）、RailwayのダッシュボードおよびAPIが突如として503エラーを返し始め、ユーザーはログインすら不可能な状態に陥った。 原因はGoogle Cloudがプロダクション環境のRailwayアカウントを誤って停止状態に設定したことだった。Railwayは即座にGCPのP0チケットを起票し、アカウントマネージャーを直接呼び出した。GCPのアクセス権自体は約9分後（22:29 UTC）に回復したものの、本当の混乱はそこから始まった。 カスケード障害の連鎖 RailwayはGCPにホストされた制御プレーンAPIを、エッジプロキシのルーティングテーブル更新に使用していた。GCPへのアクセスが一時的に失われた間、この制御プレーンが停止し、ルーティングテーブルへの書き込みができなくなった。 問題はGCPアクセス回復後も既存のキャッシュが徐々に失効したことだ。キャッシュが切れるにつれ、GCPとは無関係のAWS環境や自社インフラ（Railway Metal）のワークロードも404エラーを返し始めた。制御プレーンがルーティングを解決できないため、稼働中のインスタンスへの経路が消えてしまったのだ。ピーク時には全リージョンの全ワークロードが到達不能になった。 障害タイムライン（UTC） 時刻 出来事 22:10 自動監視がAPIヘルスチェック失敗を検知、オンコール調査開始 22:11 ダッシュボード503エラー、ユーザーログイン不可 22:19 根本原因特定：GCPがRailwayアカウントを停止 22:22 GCPにP0チケット起票、アカウントマネージャーと直接連絡 22:29 GCPアクセス権回復（コンピュートインスタンスは停止継続） 22:35 キャッシュ失効開始、Railway Metal・AWSも404エラーへ 23:54 全永続ディスクが準備完了状態に 01:38（翌日） エッジトラフィック再開、ネットワーク復旧 06:14 全面復旧 復旧後にはGitHubがOAuthとWebhook連携でRailwayをレート制限するという二次障害も発生した。GCP障害によりキャッシュが全クリアされた影響で、GitHub APIへのコール数が急増したためだ。また、利用規約の同意レコードもリセットされ、ユーザーが次回ログイン時に再同意を求められるという問題も生じた。 実務への影響 マルチクラウドの「見せかけ」に注意 今回の事例が示すのは、物理的にマルチクラウドであっても、制御プレーンが一カ所に集中していれば単一障害点になり得るという事実だ。Railwayは実際にAWS・GCP・自社インフラという複数環境を持っていたにもかかわらず全体が機能不全に陥った。 設計段階で確認すべき重要な問いは次の3つだ。 制御プレーン（ルーティング・DNS・認証基盤）は分散化されているか？ 特定クラウドのAPIへの依存がどこに存在するか？ 障害時のフォールバックはあるか？ キャッシュのTTLは適切か？ 長すぎれば変更が反映されず、短すぎれば障害時の猶予がなくなる アカウント停止リスクへの備え 今回はGCPによる誤停止だったが、クラウドプロバイダーによるアカウント停止は請求問題・ポリシー違反の誤検知など様々な理由で発生し得る。これはGCPに限らずAzure・AWSでも起こりうるリスクだ。 重要なサービスは複数のプロジェクト・サブスクリプションへの分散を検討する クラウドプロバイダーとのサポート契約・エスカレーションパスを事前に確認しておく アカウント停止を想定した緊急フェイルオーバー手順書を整備し、定期的に訓練する 筆者の見解 今回のRailway障害が突きつけたのは、マルチクラウド戦略は「存在する」だけでは意味がないという厳しい現実だ。制御プレーンという神経系が一点に依存していれば、どれだけワークロードを分散させても、その一点の障害で全体が止まる。 RailwayがP0チケット起票から9分でGCPのアクセス権を回復させたことは評価に値する。エンタープライズレベルのサポート体制の効果は確かにある。一方で、アクセス権回復からフル復旧まで約8時間を要したことは、「回復への準備」がいかに重要かを改めて示している。回復できることと、素早く回復できることは全く別の話だ。 自社システムを設計・運用するすべてのエンジニアに問いたい。あなたのシステムの「制御プレーン」はどこにあるか？ そしてそれが突然消えたとき、どう振る舞うかを実際に検証したことがあるか？ 「今動いているから大丈夫」は通用しない。障害の想定と実際の訓練こそが、本物の耐障害性を生む。 出典: この記事は Incident Report: Railway Blocked by Google Cloud (Resolved) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftのAzure DevOpsチームは2026年2月、GitHubリポジトリをAzure DevOpsプロジェクトに接続できる上限を従来の500件から2,000件へと4倍に拡張した。同時に、接続管理を自動化するREST APIエンドポイントも新たに追加され、大規模組織でのGitHub連携管理が大幅に改善された。 なぜ500件では足りなかったのか Azure DevOpsとGitHubの連携は、Azure Boardsのワークアイテムとプルリクエストを紐づけたり、Azure Pipelinesのトリガーにしたりと、多くの組織で基幹的なDevOpsワークフローの一部になっている。 しかし、従来の500リポジトリという制限は、マイクロサービスを積極的に採用している組織や、複数のプロダクトラインを持つ大規模開発チームにとって現実的な壁となっていた。1サービス1リポジトリの構成で100以上のマイクロサービスを複数チームで管理すると、あっという間に500件の壁に近づく。GitHub Organizationsを複数に分けるなどの回避策を強いられていた組織も少なくない。 今回の2,000件への引き上げにより、こうした大規模環境での連携管理が現実的なものになった。 REST APIで「人手なし」の自動管理が可能に 上限拡張と同時に追加されたREST APIは、より本質的な改善といえる。 従来はAzure DevOpsのプロジェクト設定画面から手動でリポジトリを追加・削除する必要があった。新しいAPIエンドポイントを使えば、TerraformやBicep、あるいは自社製のプロビジョニングスクリプトから自動的に接続を管理できる。 実際のユースケースとしては以下が考えられる： 新規マイクロサービス作成時の自動接続: CI/CDパイプラインの一部としてGitHubリポジトリ作成と同時にAzure DevOps連携を設定 IaCによるDevOps環境の再現性確保: 開発・ステージング・本番の各プロジェクトに対して、同一のリポジトリセットを宣言的に管理 オフボーディング自動化: プロジェクト終了時にリポジトリの接続を自動的に解除し、不要なアクセス権を残さない 同時期の関連アップデート 今回のリポジトリ上限拡張は、2026年2月〜5月にかけて連続的に投入されたAzure DevOpsの一連の強化策と連動している。 リリース 機能 意義 2026年5月 Git objectカウント制限の撤廃 大規模モノレポ対応 2026年4月 組み込みコード検索（拡張機能不要） 環境依存の解消 2026年3月 Remote MCPサーバーのパブリックプレビュー AIエージェントとのDevOps連携 2026年2月 GitHubリポジトリ上限2,000件＋REST API 本記事の対象 Remote MCPサーバーのプレビューが同時期に始まっている点は注目に値する。Azure DevOpsをAIエージェントの操作対象として扱えるインフラが整いつつあることを示している。 日本の現場への影響 日本のエンタープライズIT部門では、GitHub EnterpriseとAzure DevOpsを「両方使っている」環境が一定数存在する。コード管理はGitHub、プロジェクト管理（Boards）やパイプラインはAzure DevOpsという分業体制だ。 この構成を採用している組織では、今回の制限緩和と自動化APIの恩恵を直接受けられる。特に、年度替わりの大規模プロジェクト立ち上げや、SIer各社が顧客ごとに複数の開発リポジトリを管理するシナリオで効果が大きい。 明日から試せること： 現在の接続リポジトリ数を確認（プロジェクト設定 → GitHub connections） 新REST APIのドキュメントを確認し、既存のプロビジョニングフローに組み込めるか検討 Terraform Azure DevOps Providerの対応状況を確認 筆者の見解 2,000件という数字は単なる上限緩和ではなく、「エンタープライズ規模での本格運用」を明示的に意識した判断だ。GitHubとAzure DevOpsという2つの強力なプラットフォームを擁するMicrosoftならではの、統合投資の成果が見え始めている。 ...