Azure

Microsoftは2026年5月、Azure AIの研究開発部門「Microsoft Foundry Labs」の最新アップデートとして、AIエージェントの代理交渉能力を評価するオープンソースベンチマーク「SocialReasoning-Bench」、テキストから画像を生成する新モデル「MAI-Image-2-Efficient」、衛星・航空画像向けオブジェクト検出エンドポイント「EO/OS Object Detection」を含む4つの新機能を公開した。 SocialReasoning-Bench：AIエージェントの「交渉力」を可視化する 今回のアップデートの中でとりわけ注目したいのが「SocialReasoning-Bench」だ。AIエージェントが人間を代表して価格交渉・条件調整・合意形成をどれだけうまくこなせるかを測るオープンソースベンチマークである。 AIエージェントがビジネス現場に本格導入されてきた今、「タスクをこなせるか」だけでなく「関係者間の複雑な利害をどれだけ理解して動けるか」という評価軸が現実味を帯びてきた。SocialReasoning-Benchはまさにその問いに答えようとするものだ。 オープンソースとして公開することで、Microsoftのエコシステム外のエージェント開発者も同じ物差しでモデルを比較評価できる。ベンチマークの標準化は業界全体の成熟度を押し上げる重要な動きであり、単なる機能追加とは一線を画す。 MAI-Image-2-Efficient：画像生成の「効率化競争」を体現 「MAI-Image-2-Efficient」はテキストから画像を生成するモデルの新バージョンで、前世代比で22%の高速化と4倍の効率改善を実現しているという。 「4倍の効率改善」とは、同品質の画像を生成するのに必要なコンピューティングリソースが4分の1になるということだ。エンタープライズ向けの大規模コンテンツ生成ワークフローに組み込む場合、この差は月次のクラウドコストに直接響く。品質の向上よりも「速く・安く」を追求する方向性は、本番運用を見据えた実用的な進化といえる。 EO/OS Object Detection：GeoAIカテゴリが新設 「EO/OS Object Detection」は、衛星画像や航空写真（Earth Observation / Overhead Sensing）から物体を自動検出するエンドポイントだ。今回のアップデートで「GeoAI」という新カテゴリがFoundry Labs内に追加され、地理空間データを扱うAI機能群がまとめられた形になった。 インフラ管理・農業・防災・都市計画など、地理空間データの活用は産業分野を問わない。Azure基盤上でこうした機能が標準APIとして利用できるようになれば、専門的なGISツールなしでも高度な空間解析ワークフローを構築しやすくなる可能性がある。 実務への影響 エージェント開発者へ：SocialReasoning-Benchは自社開発エージェントの評価に活用できる。単一モデルのテストとしてではなく、マルチエージェントシステム全体の交渉ロジックを検証する仕組みとして取り込む価値がある。 画像生成ワークフローの担当者へ：MAI-Image-2-Efficientへの移行を検討する際は、単純な速度比較ではなくトークンあたりのコスト削減効果を試算してほしい。大量生成ユースケースほど効果が大きく、Azure AI Foundryのコンソールで既存プロンプトをそのまま使って比較評価できる。 インフラ・建設・防災DX担当者へ：GeoAI機能群の追加は、衛星データ解析を内製化したい企業にとって重要な選択肢になりうる。従来はArcGISやGoogle Earth Engineなど専用プラットフォームが必要だったユースケースを、Azure基盤内で完結させられる可能性がある。 筆者の見解 Foundry Labsからの今回のアップデートで特に評価したいのは、SocialReasoning-Benchをオープンソースで公開した判断だ。評価指標をオープンにすることは業界の信頼を獲得する正攻法であり、Microsoft以外のプレイヤーも巻き込んで「標準」を作る戦略としても理にかなっている。 MAI-Image-2-Efficientの効率化も、地に足のついた進歩だ。「より賢く」よりも「より速く・安く」を追求するラボの姿勢は実用的で歓迎できる。Foundry Labsという研究開発の場で技術を磨き、それを製品に還元していく流れは、Microsoftが強みとする「研究から製品への橋渡し」の本来の姿に近い。 GeoAIカテゴリの新設も、Azureをドメイン特化型ユースケースのプラットフォームとして育てていく方向性の表れだと受け取っている。汎用AIの競争では差別化が難しくなる中、こうした垂直領域への投資はAzureならではの戦略として筋が通っている。正面から強みを活かした勝負ができる領域に投資してほしいという期待に応えてくれている。 Foundry Labsで育った技術が数ヶ月後にAzure AI Foundryの正式機能として降りてくるのが通常のパターンだ。今回の4機能は、そのGAに向けた先行評価として今すぐ触っておく価値がある。 出典: この記事は What’s New in Microsoft Foundry Labs – May 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月15日付けで、Azure Arc経由でオンプレミスおよびマルチクラウド環境のWindows Server 2025に適用できるホットパッチ（Hotpatch）機能のアクセス簡素化を発表した。既存の登録済みマシンへの課金が停止され、より広い範囲への展開が現実的な選択肢となった。 ホットパッチとは何か ホットパッチ（Hotpatch）とは、OSを再起動することなくカーネルレベルのセキュリティパッチを適用できる技術だ。従来のWindowsパッチ適用では月例更新（Patch Tuesday）のたびにサーバーの再起動が必要で、業務システムのダウンタイムや夜間メンテナンス作業が避けられなかった。 ホットパッチはプロセスの実行状態を維持したまま、メモリ上でパッチを適用する。WindowsカーネルにはAzure Virtual Machines向けにすでに提供されていたが、Azure Arc経由でオンプレミスのWindows Server 2025にも展開できるようになったことが今回の大きなポイントだ。 今回の変更内容 今回の発表の核心は「アクセスの簡素化」と「課金の見直し」の2点に集約される。 課金停止の範囲: 2026年5月15日以降、Azure Arcにすでに登録済みのWindows Server 2025マシンに対しては、ホットパッチ機能への追加課金が停止された。以前はAzure Arc対応サーバー向けのホットパッチは有償オプションとして提供されていたが、この変更により既存環境への展開コストの計算が変わる。 展開の容易化: ホットパッチを利用するための前提条件や設定手順が整理され、既存のAzure Arc接続環境であれば追加の複雑な設定なしに機能を有効化しやすくなっている。 対象環境: Windows Server 2025が対象。Azure上の仮想マシンだけでなく、Azure Arcに接続されたオンプレミスサーバーやAWS・GCPなど他クラウド上のWindows Server 2025にも適用される点がポイントだ。 なぜこれが重要か セキュリティパッチの適用遅延は、日本の多くの企業が抱える現実的なリスクだ。「再起動を伴うメンテナンスの調整が大変だから」という理由でパッチ適用が後回しになるケースは珍しくない。業務システムの可用性を維持しながら脆弱性を放置するというジレンマを、ホットパッチは技術的に解決する。 Azure Arcが重要な役割を担うのは、現実の企業環境がハイブリッドだからだ。オンプレミスのサーバーをすべてAzureに移行するのは現実的ではなく、多くの企業がオンプレ・Azure・AWS・GCPの混在環境を運用している。その管理を一元化するためにAzure Arcがある。今回の変更は、Arcの価値をパッチ管理の領域でも強化するものだ。 実務への影響 既存のAzure Arc環境を持つ企業はまず確認を: すでにAzure Arcに接続済みのWindows Server 2025マシンがあれば、追加課金なしでホットパッチを有効化できる状況になっている。まずはAzure PortalまたはAzure Arc管理コンソールで対象マシンのステータスを確認したい。 パッチ適用の頻度と再起動サイクルが変わる: ホットパッチ適用時は、四半期に1回の「ベースライン月」にのみ再起動が必要になる設計になっている。毎月の再起動を四半期1回に削減できれば、運用負荷は大幅に下がる。夜間メンテナンスの件数を減らせるのは、SRE・インフラ担当にとって実質的なメリットだ。 ゼロトラスト観点でも重要: 脆弱性の露出期間（Exposure Window）を短縮できることは、ゼロトラストアーキテクチャの実践において直接的に効いてくる。特権アカウントやサービスアカウントが動くサーバーについては、パッチ適用の迅速化が侵害リスクの低減に繋がる。 マルチクラウドへの展開を計画しているなら: AWS・GCP上のWindows Server 2025にAzure Arcエージェントを導入することで、オンプレと同一の運用体制に組み込める。マルチクラウド運用を標準化するうえで、Arc経由のパッチ管理は有力な選択肢になる。 筆者の見解 ホットパッチは地味に見えて、実は運用の本質を突いた機能だ。日本のエンタープライズ現場で「パッチが当てられない理由」として最もよく聞くのが「再起動の調整がつかない」である。技術的な問題ではなく、スケジュール調整という人間系の問題がセキュリティのボトルネックになっているのが実態だ。ホットパッチはそのボトルネックを物理的に消す。 Azure Arcを軸に、オンプレ・クラウド混在環境を一元管理するアプローチはプラットフォームとして正しい方向だと思っている。特定のクラウドベンダーに縛られず、管理面だけMicrosoftの傘に入るというモデルは、現実の企業事情にフィットしている。今回の課金見直しはその普及を後押しするもので、方向感としては歓迎したい。 あとはWindowsにおけるパッチ品質の問題を地道に解決し続けることが条件だが——そこへの投資はMicrosoftには続けてほしい。実力があるのは間違いないのだから、運用負荷を減らす地味な改善を積み重ねることが、長期的な信頼に繋がる。 出典: この記事は Simplified access to Hotpatching enabled by Azure Arc for Windows Server 2025 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftはAzure SQL Managed InstanceのMicrosoft Fabricへのミラーリング機能を正式GA（一般提供）として公開した。運用中のSQL Managed InstanceのデータをリアルタイムでOneLakeに複製し、ETLパイプラインを一切構築することなく分析ワークロードを実行できる。同時に、Cosmos DBのプライベートエンドポイント経由ミラーリングも同日GAとなり、エンタープライズのデータ分析基盤がさらに強化された。 ミラーリングとは何か Microsoft Fabricのミラーリングは、変更データキャプチャ（CDC）技術をベースに、運用データベースへの影響を最小限に抑えながらOneLakeへ継続同期する機能だ。OneLakeに複製されたデータはParquet形式で自動保存され、FabricのSQL Analytics Endpoint経由で即座にT-SQLやSparkから参照できる。 従来のアーキテクチャでは、Azure Data FactoryやdbtなどでETLパイプラインを設計・構築・維持するコストが避けられなかった。ミラーリングはこの構造を根本から変える。本番データベースを一切変更せずに、分析専用のデータ層を追加できる。 今回のGA内容 Azure SQL Managed InstanceのFabricミラーリング（GA） 運用中のSQL MIのデータをOneLakeにリアルタイム複製 Fabric上のSpark／T-SQLから直接分析可能 既存のSQL MI環境を変更せずに分析基盤を追加 Cosmos DBのプライベートエンドポイント経由ミラーリング（GA） VNet内のCosmos DBを安全にFabricと接続 セキュリティ要件の厳しいエンタープライズ環境に対応 マルチモデルデータとリレーショナルデータの横断分析が実現 OneLakeに集約されたデータは、Power BI・Synapse Analytics・Data Science・Data Engineeringなど、Fabricエコシステム全体から共通して参照できる。「One copy of data, many uses」という設計思想が具体的な形になった。 実務への影響 ETL廃止への現実的なパス 多くの企業で分析基盤のボトルネックはETLパイプラインの複雑さにある。SQL Managed Instanceをすでに運用中であれば、ミラーリングを有効化するだけでデータ複製が始まる。Data Factoryや自作スクリプトで維持してきたデータ抽出ロジックを、段階的に廃止・簡素化できる可能性がある。 本番負荷ゼロの分析専用レプリカ OneLakeへの複製は本番SQL MIにほぼ負荷をかけない。月次集計や重いレポーティングクエリをFabric側で実行することで、本番のパフォーマンスを守りながら分析の自由度を高められる。 異種データソースの統合分析 Cosmos DBとSQL MIの両方をミラーリングすれば、マイクロサービスアーキテクチャで分散したデータをOneLakeに集約し、Fabricで横断分析できる。これまでは困難だった「NoSQLとRDBを結合して分析する」構成が現実的なコストで実現する。 移行前に試算すべきコスト ミラーリングはOneLakeにデータのコピーを保持するためストレージコストが増加する。特に書き込み頻度の高いCosmos DBは複製コストとFabricキャパシティコストを事前に見積もること。なお、OneLakeからSQL MIへの逆方向書き戻しはサポートされないため、双方向同期が必要な用途には使えない点を注意されたい。 筆者の見解 ミラーリングのGAで、Microsoft Fabricの「データプラットフォーム統合」という戦略がかなり具体的な形になってきた。 評価しているのは「既存資産を壊さずに分析能力を追加できる」という設計思想だ。SQL Managed Instanceはエンタープライズ環境で広く採用されており、そこへの既存投資を活かしたまま分析基盤を拡張できる点は、現実の企業ニーズに即している。 「分析のためだけにSynapse Analyticsを別途契約する」構成より、Fabric一本に統合していく流れはアーキテクチャとして正しい方向だ。部分最適のツールを組み合わせて保守に苦労するより、OneLakeを中心に据えてシンプルに保つ構成の方が、長期的な運用コストは間違いなく下がる。 Fabricはまだ発展途上で、パフォーマンスや機能の成熟度に課題が残る部分もある。だが統合プラットフォームとしての方向性は正しく、ミラーリングのGAはその実現に向けた着実な一歩だ。SQL MIを運用中のチームは、まずDev／Staging環境でミラーリングを試してみる価値がある。 出典: この記事は Announcing General Availability of Mirroring for Azure SQL Managed Instance in Microsoft Fabric の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft は FabCon/SQLCon 2026 において、Microsoft Fabric の中核データレイク基盤である OneLake の大規模アップデートを発表した。Oracle および SAP Datasphere のミラーリングが正式GA（一般提供開始）となり、SharePoint リスト・Azure Monitor・Dremio がプレビュー対象として追加されたことで、異種データベースからの分析統合が現実的な選択肢として整いつつある。 OneLakeミラーリングとは何か OneLakeミラーリングは、外部データソースのデータをコピー・移動させることなく、OneLake上に論理的なビューとして統合する仕組みだ。ETLパイプラインを都度構築する従来のアプローチとは異なり、元データベースとの同期を維持しながらFabricの分析・AI機能をそのまま適用できる。 これまでも Azure SQL Database や Snowflake などへの対応は進んでいたが、今回のアップデートでエンタープライズ現場で根強いシェアを持つ Oracle と SAP Datasphere がGAに昇格したことは、実用性の面で大きな転換点となる。 今回のアップデート詳細 GAとなったミラーリング対象 Oracle Database — 長年エンタープライズDBの王座に君臨してきたOracle。日本の大規模システムでの採用率を考えれば、このGAの意義は大きい SAP Datasphere — SAP ERP環境との連携需要が高い製造・流通業界に直結する対応 プレビューに追加されたミラーリング対象 SharePoint リスト — Microsoft 365 上の業務データを分析に活かせる経路が開く Azure Monitor — インフラ・アプリのログ・メトリクスをFabricのデータ基盤と統合可能に Dremio — データレイクハウス系プラットフォームとの接続性が強化 Database Hub と Fabric IQ Database Hub は複数の異種DBを一元的に管理・ナビゲートするインターフェース。Fabric IQ はデータ統合の推奨・最適化を支援するインテリジェント機能で、どのソースをどうつなぐべきかの指針を提示する。 日本のIT現場への影響 日本の大手企業・官公庁では Oracle や SAP がまだ現役稼働しているケースが珍しくない。従来、これらのシステムからBIや機械学習用にデータを取り出すには独自のETL開発が必要で、工数・保守コストが膨大だった。 ...

MicrosoftがAzure Kubernetes Service（AKS）Fleet Managerに、Ciliumベースのクロスクラスターネットワーキング機能をパブリックプレビューとして公開した（2026年5月22日）。複数のAKSクラスターにまたがるサービスディスカバリー、ネットワークポリシー管理、オブザーバビリティを、Azureのマネージドサービスとして一元的に提供する。 AKS Fleet Managerとは AKS Fleet Managerは、複数のAKSクラスターを「フリート（艦隊）」として束ね、統一的に管理するためのAzureサービスだ。企業がKubernetesを本番運用するフェーズに移行すると、開発用・ステージング用・本番用・リージョン別・チーム別と、あっという間にクラスター数が増大する。それぞれを個別に管理するのは現実的でなく、フリート管理という概念が生まれた背景はここにある。 今回のプレビューでは、このフリート上でCiliumベースのネットワーク機能が「マネージド」として提供される。これまで各クラスターに個別インストール・個別設定が必要だったCiliumのコントロールプレーンを、Azureが管理してくれるという意味だ。 Ciliumが果たす役割 Ciliumは、Linuxカーネルの拡張機能であるeBPF（extended Berkeley Packet Filter）をベースとしたCNCFのオープンソースプロジェクトで、Kubernetesのネットワーキングとセキュリティを担う事実上の標準ソリューションになりつつある。iptablesに依存する従来のネットワークプラグインと比較して、高いパフォーマンスと可視性を持つのが特徴だ。 今回のマネージドCiliumによるクロスクラスターネットワーキングが提供する主な機能は次の3つだ。 サービスディスカバリー クラスターAで動くサービスがクラスターBのサービスを名前で探して呼び出せる。通常、クラスター間通信ではIPアドレスやエンドポイントの手動管理が必要になるが、これをCiliumが自動化する。 ネットワークポリシーの統合管理 各クラスターにバラバラに定義していたKubernetesネットワークポリシーを、フリートレベルで一元管理できる。「このネームスペースのPodはフリート内のどのクラスターからも通信できる」といった宣言的な設定が可能になる。 オブザーバビリティ Ciliumの可視化ツール「Hubble」との統合により、クラスター間を流れるトラフィックの全体像をリアルタイムで把握できる。障害時の原因究明が格段に速くなることが期待される。 実務への影響 マルチクラスター構成の採用障壁が下がる これまでマルチクラスター構成は「必要性はわかっているが、運用が複雑になりすぎる」という理由で敬遠されてきた。今回のマネージドCiliumにより、その複雑さの大半をAzureに委ねられるようになる。リージョン分散やマルチテナント構成を検討している中堅以上の組織には、現実的な選択肢として浮上してくる。 ゼロトラストネットワーキングへの布石 Ciliumのネットワークポリシーは「許可されていない通信はデフォルトで拒否」という思想に基づいており、ゼロトラストアーキテクチャと親和性が高い。クラスター間通信にも同じ原則を適用できるようになる点は、セキュリティ要件の厳しい金融・医療系のシステムにとっても注目に値する。 現時点ではパブリックプレビュー 本番環境への採用は、GAリリースを待ってからが現実的だ。ただし今のうちに検証環境で試しておくことで、GA時に即座に本番適用できる準備が整う。プレビュー参加には Azure CLI または Azure Portal からフリートリソースのCiliumオプションを有効化するだけで始められる。 筆者の見解 AzureのKubernetesまわりの機能強化は、地道ながらも確実に積み上がっている。AKS Fleet Managerのような「多数のクラスターを束ねる」レイヤーは、エンタープライズの本番Kubernetes運用において長らく欠けていたピースの一つだった。 マネージドCiliumという方向性は理にかなっている。CNCFの事実上の標準ツールをAzureが管理してくれるなら、ユーザーはCiliumの運用ノウハウよりもアーキテクチャ設計に集中できる。eBPFベースのネットワーキングはもはや先端技術ではなく標準になりつつあり、「道のド真ん中を歩く」選択として採用しやすい段階に来ている。 一方で気になるのは、エコシステムの複雑さだ。AKS、Fleet Manager、Cilium、Hubble、Azure CNI Overlayとの関係など、理解すべき概念が積み重なっている。Azureがこれらをうまく抽象化して「難しいことを考えなくていい体験」を提供できるかどうかが、実際の普及を左右するだろう。 「最も多くのワークロードが安全に動作するプラットフォーム」を本気で目指すなら、このネットワーキングレイヤーの成熟は欠かせない。プレビューの動向を引き続き注視したい。 出典: この記事は Microsoft Azure AKS Fleet Manager Cross-Cluster Networking Preview (Managed Cilium) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは開発者向け年次カンファレンス「Microsoft Build 2026」を2026年6月2〜3日にサンフランシスコのFort Mason Centerで開催すると発表した。シアトルでの10年間の歴史に幕を下ろし、AIエージェント・信頼性・開発者プラットフォームの再定義を前面に押し出した集中型イベントへと生まれ変わる。 10年ぶりのサンフランシスコ回帰——規模縮小は「集中」のサイン Build 2017年以降、シアトルのコンベンションホールで5,000名超を集めてきた同カンファレンスが、今年はFort Mason Center（収容定員約3,000名）という文化施設での開催に転換する。会場規模の縮小は後退ではなく、広範な製品発表から脱却し、実践的なワークショップとディープな技術セッション中心の体験に絞り込んだ意図的な選択だ。 サンフランシスコはAIスタートアップ・ベンチャーキャピタル・トップエンジニアリング人材が集積するAIの震源地。Microsoftがこの地を選んだことは、開発者向けナラティブ全体をAIに集約するという強いシグナルだ。CEOのSatya Nadella、CTOのKevin Scottらが登壇し、AIを「機能」ではなく「開発体験のコア」と位置づけるビジョンを打ち出す見通しだ。 AIエージェントが主役——自律実行の時代へ 今回のメインテーマは「AIエージェント」だ。チャットボットやCopilotのような受け身の応答型から、複数ステップのタスクを自律的に実行するエージェント型へのシフトを開発ツールとして支援する発表が相次ぐ見込みだ。 具体的には以下が期待される： Copilot Studio の自律エージェント機能の拡張 AutoGen フレームワークの新バージョン Microsoft 365・Dynamics 365・Azure とのエージェント統合 API AI Foundry for Windows SDK（ONNX Runtime・DirectML・Copilot Runtime を統合した NuGet パッケージ） Agents はワークフロー管理・複数データソースをまたぐ推論・マルチステップタスク実行を自律的に担うよう設計される。セッショントラックではオーケストレーションパターン・メモリ管理・各サービスとの統合手法が深く掘り下げられる予定だ。 Windows 開発者にとって注目すべきは、NPU（Neural Processing Unit）搭載デバイス向けのネイティブエージェント API の可能性だ。ローカル AI 推論を OS レベルで統合し、デスクトップアプリが自律アシスタントをスポーンできるアーキテクチャが現実味を帯びてくる。 「信頼性」を競争差別化の軸に 急速な AI 展開が進む中、Microsoftが競合との差別化として前面に押し出すのが「Trust（信頼性）」だ。Build 2026 では以下の発表が予想される： Responsible AI Toolbox のアップデート Azure AI Content Safety の新機能 プライバシー保護型機械学習・説明可能 AI・敵対的堅牢性テストのツール群 エンタープライズ向け「Trustworthy AI 認証プログラム」（予定） AI エージェントが業務システムに組み込まれるためには、監査可能性・透明性・操作耐性が不可欠だ。Microsoftはこの「エンタープライズ安心感」を軸に、コンシューマー志向の AI 各社とのポジションを差別化しようとしている。 ...

MicrosoftがPostgreSQL 18に対する上流コントリビューションを本格化させ、マネージドサービス「Azure HorizonDB」の発表と組み合わせ、PostgreSQLをAI時代の中核データベースとして位置づける戦略を鮮明にした。 PostgreSQL 18への上流コントリビューションとは Microsoftは単にPostgreSQLをホストするだけでなく、PostgreSQL本体（上流）への貢献を加速している。今回の動きで特に注目されるのは、DiskANNベクター検索の「述語プッシュダウン（Predicate Pushdown）」機能をPostgreSQL 18本体に統合しようとしている点だ。 DiskANNは、Microsoftが開発したグラフベースの近似最近傍探索（ANN: Approximate Nearest Neighbor）アルゴリズムで、大規模なベクターインデックスを高速に検索できる技術だ。従来の実装ではベクター検索と通常のWHERE句フィルタリングが別々に処理されていたが、述語プッシュダウンによりこれらを統合処理することで、RAG（Retrieval Augmented Generation）などAIアプリケーションのクエリパフォーマンスが大幅に向上する。 たとえば「特定のカテゴリ（WHERE category = ’tech’）に属する文書の中から、質問文に意味的に近いものを検索する」といったクエリを、1回のインデックス走査で完結できるようになる。フィルタリング後にベクター検索をかける方式に比べ、処理コストが劇的に下がる。 Azure HorizonDB — 何が新しいのか Azure HorizonDBは、MicrosoftがPostgreSQLベースで展開するマネージドデータベースサービスの新たな方向性を示すものだ。PostgreSQLとAzureのAIスタック（Azure AI Foundry、Azure OpenAI Service）との深い統合が特徴とされており、既存のPostgreSQL資産との互換性を維持しながらクラウドネイティブなスケーラビリティを提供するという方針だ。 Amazon AuroraやGoogle AlloyDBが同様のアプローチを取るなか、HorizonDBはMicrosoftのAIプラットフォームとの一体化という点で独自の差別化を図っている。 なぜこれが重要か MicrosoftがPostgreSQLのコミュニティそのものに貢献しているという点が重要だ。AWSのAuroraはPostgreSQLを独自拡張する方向性が強く、コミュニティとの距離感を感じるユーザーも多かった。上流本体にコントリビューションするスタンスは、長期的にコミュニティ内での信頼と発言力を高める。 AIアプリケーションにおいてベクター検索はもはや必須の機能だ。pgvectorなどの拡張として提供されていた機能がコア近くに統合されることで、安定性と最適化の両面で恩恵が期待できる。日本企業でPostgreSQLを利用しているシステムは多く、Azure Database for PostgreSQLを使っているチームにはこれらの改善が透過的に届く可能性がある。 実務への影響 — 日本のエンジニア・IT管理者にとって 今すぐ確認すべきこと: RAGシステムを構築・検討中のチーム: PostgreSQLベースのベクター検索（pgvector等）を使っている場合、DiskANNの述語プッシュダウン統合はクエリ速度に直結する改善だ。PostgreSQL 18のベータ版でのベンチマーク動向を注視したい Azure Database for PostgreSQL利用者: HorizonDBへの移行パスや互換性について、プレビュー期間中に検証環境で確認しておくことを推奨する。既存の接続文字列やORMがそのまま使えるかどうかが鍵になる オンプレPostgreSQLからの移行検討組: Aurora / AlloyDB / HorizonDBの三択が今後の主要な検討軸になる。TCOとAIスタックとの統合容易性、そしてサポート体制で比較してほしい pgvector利用者: 現時点でpgvectorを本番運用しているなら、DiskANNとの性能比較情報を収集しておくと、将来の移行判断がスムーズになる 筆者の見解 Microsoftのこの動きは、評価したい方向性だ。 クラウドベンダーがOSSの上流本体に本気で貢献するのは、技術的にも誠実なアプローチである。AWSがAuroraで独自拡張路線を進めたのとは対照的であり、「利用するだけでなく返す」というスタンスはPostgreSQLコミュニティとの関係において長期的な資産になる。 DiskANNの性能は技術的に実績がある。それをPostgreSQL本体に統合しようとする判断は筋が通っており、AIワークロードをPostgreSQLで処理したいユーザーにとって実用的な価値がある。 Azure基盤の上でAIを動かすという文脈では、HorizonDBの位置づけは理にかなっている。Azure AI FoundryやAzure OpenAI Serviceとの接続をデータベース層から最適化できるなら、Azureスタックで統一しているチームにとっては自然な選択肢になるはずだ。 あとは実際のベンチマーク数値と、Aurora・AlloyDBとの現実的な性能比較を見てから判断したい。良い数字が出れば、これは「Azureを使い続ける理由」をもう一つ増やしてくれる取り組みだ。 出典: この記事は Microsoft’s PostgreSQL Push: Upstream AI Vector Search and Azure HorizonDB の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

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は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は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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。