Azure

Microsoftは2026年5月開催のMicrosoft Build 2026において、エンタープライズAI競争の主戦場はモデルの性能ではなくデータコンテキストにあると宣言し、Microsoft Fabric Data WarehouseへのNVIDIA GPUアクセラレーション統合を発表した。 Microsoft Fabric Data Warehouseに何が起きているか Fabric Data WarehouseにNVIDIA GPUアクセラレーションが統合される。最大の特徴は既存のクエリを書き換える必要がない点だ。従来のSQL資産をそのままに、最大7倍のデータ分析高速化が実現できるという。 この機能は2026年7月に早期アクセスプレビューとして提供開始予定。また、このアーキテクチャを支える研究成果はデータベース分野の権威ある国際会議「ACM SIGMOD 2026」でBest Industry Paper賞を受賞しており、学術的な裏付けも得ている。 「モデルより文脈」戦略の意味 MicrosoftがBuildで繰り返し強調したメッセージは「AIエージェントの価値はモデルの賢さより、どれだけ正確なデータにアクセスできるかで決まる」というものだ。 この主張は自社の強みを最大限に活かす戦略として読み解ける。Microsoftはすでに企業の基幹データに深く入り込んでいる。SharePoint、Exchange、Teams、Azure SQL——これらのデータを「コンテキスト」としてAIエージェントに渡せる仕組みを整えることで、モデル性能競争とは別軸で優位性を確立しようとしている。 Buildで公開された主な技術要素： HorizonDB: AIエージェントが企業の分散データを横断的に参照するための新しいデータファブリック層 Fabric Data Warehouse + NVIDIA GPU: 既存ワークロードを変更せずにGPUアクセラレーションを享受 データコンテキストパイプライン: エージェントが最新かつ正確なデータをリアルタイム参照できる連携基盤 日本のIT現場への影響 日本の多くのエンタープライズはすでにMicrosoft 365とAzureを軸にデータ基盤を構築している。この発表が実務に与えるインパクトは小さくない。 エンジニア・データエンジニアへのヒント： 既存のFabric Data Warehouseを使っているなら、7月の早期アクセスプレビューを今から申請して検証環境を先に用意しておく GPU統合はクエリ変更不要とされているが、実際のワークロードでのパフォーマンスプロファイルは必ず独自計測する。「最大7倍」は条件次第 HorizonDBのアーキテクチャ詳細はACM SIGMOD論文として公開されており、技術的な深掘りが可能 IT管理者・アーキテクトへのヒント： 「AIエージェントにどのデータを見せるか」の設計が、今後の企業AI戦略の核になる。データガバナンス整備が先決 Microsoft Entra IDを使ったデータアクセス制御の整備が、エージェント導入前の必須ステップ Fabric未導入の場合、このタイミングでの移行検討価値が一段と高まった 筆者の見解 Build 2026を通じて見えてきたMicrosoftの戦略は、AIモデル競争から「データプラットフォーム競争」への明確なシフトだ。この方向性は、正直なところ「正しい賭け方」に見える。 Azureの強みは常にインフラとしての信頼性と、企業データへの深い統合にあった。エンタープライズの現場では、最強のモデルより「自社のデータを正確に理解してくれるAI」の方が価値を生む場面が圧倒的に多い。その意味で「データコンテキストがモデル性能を凌駕する」という主張は、現場感覚に合っている。 Microsoft Foundry経由で外部モデルを活用しつつ、データ基盤はFabricで管理する——という組み合わせが現実的な選択肢として浮かんでくる。Azureのプラットフォームとしての役割を活かすなら、最強のモデルを自前で作る必要はない。最良のモデルが安全に動作できるエコシステムを提供する側に回ればいい。Microsoftにはその力がある。 GPU統合でのクエリ高速化とACM SIGMODでの受賞は実力の裏付けとして受け止めている。2026年7月のプレビューで実際の現場ワークロードがどこまで恩恵を受けられるか、アーキテクチャの美しさを結果で証明してほしい。 出典: この記事は Microsoft bets the enterprise AI race will be won on data context, not model power の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft の Azure Container Registry（ACR）チームが、外部レジストリのコンテナイメージを ACR 経由でキャッシュする「ACR Artifact Cache」の内部アーキテクチャを公式ブログで詳細に公開した。1日1億件を超えるイメージプルを支えるプルスルーキャッシュの設計思想と、実際の動作フローが明らかになった。 なぜ上流レジストリに直接依存してはいけないのか コンテナを本番運用しているチームなら、一度は遭遇したことがあるはずだ——Docker Hub のレートリミットに引っかかり、Kubernetes ノードが突然イメージを取得できなくなるアレだ。 Docker Hub は認証なしユーザーや個人プランユーザーに対してプル数を制限しており、CI/CD の共有エージェントや大規模な Kubernetes クラスターでは、あっという間に上限に達する。しかしこれは Docker Hub 固有の話ではない。本質的な問題は「上流レジストリへの直接依存が、本番システムに許容できないリスクをもたらす」という点にある。 具体的な失敗パターンはこうだ： 上流の一時的な障害や低速化がそのままサービス停止に直結する レートリミット・バースト制限で大規模スケールアウト時にイメージ取得が詰まる 認証情報の管理が各チームに分散し、セキュリティ統制が効かなくなる ネットワークポリシー（承認済みの境界内のみ通信を許可）が上流への直接アクセスを許可しないケースがある ACR Artifact Cache はこの問題を「上流の内容を ACR 経由で透過的にキャッシュする」ことで解決する。クライアントは通常の ACR プルと同じ操作をするだけでよく、裏側の複雑さは隠蔽される。 キャッシュルールとクレデンシャル管理 設定はコントロールプレーンで行う。チームはまず「キャッシュルール」を作成し、ACR 内の下流パスと上流ソースのマッピングを定義する。 出典: この記事は Inside ACR Artifact Cache: Pull-Through Caching at Scale の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftのクラウドAI開発プラットフォーム「Microsoft Foundry」のポータルが正式にGA（一般提供）へ移行し、パイロット用途から本番環境向けのエンタープライズグレードAI基盤としての利用が可能になった。 Microsoft Foundryとは何か Microsoft Foundryは、AIモデルの展開・エージェント開発・本番運用をひとつのプラットフォームで完結させるMicrosoftのAI開発基盤だ。「Discover（探索）」「Build（構築）」「Operate（運用）」というエンドツーエンドのライフサイクルを統合することで、開発チームが信頼性・コンプライアンス・運用品質を犠牲にせずに迅速に動けることを目指している。 今回のGA移行により、以下の機能が本番利用可能となった： RBAC（ロールベースアクセス制御）: チームごとの権限管理を細粒度で実現 監査ログとコンプライアンスコントロール: 企業のガバナンス要件に対応 監視・アラート機能: 本番AIワークロードの安定運用を支援 仮想ネットワーク統合: セキュアなネットワーク環境でのAI実行 ポータル・API・SDK・CLIおよび開発者ツールにわたって、GAスコープの一貫したライフサイクル管理が提供される。 注意点：すべてが移行されたわけではない GAのスコープは「Foundryプロジェクト」に限定されており、既存ユーザーは注意が必要だ。 新ポータルでサポートされないもの： スタンドアロンのAzure OpenAIリソース（クラシックポータルの継続利用、またはFoundryプロジェクトへのアップグレードが必要） ハブベースのクラシックプロジェクト（Foundryプロジェクトへの移行が必要） 認証についても整理が必要だ。多くの機能はAPIキー認証に対応しているが、評価（Evaluations）・データセット・Content Understanding・エージェント・ワークフローはMicrosoft Entra ID認証が必須となっている。ガバナンス重視の本番環境では、Entra IDとRBACの組み合わせが推奨される。APIキー認証はロールベースの権限粒度を提供しないため、企業用途では原則としてEntra IDを選ぶべきだ。 本番移行前に確認すべき事項 Microsoftは移行前に以下の確認を求めている： モデル展開・エージェント開発・運用の必要シナリオを整理する プレビュー専用機能やクラシックポータル依存箇所を洗い出す 本番環境でGA機能のみを使用する組織ポリシーを定義する 既存Azure OpenAI・クラシックFoundryワークロードの移行ガイダンスを確認する チームとサービスアイデンティティに必要なロール割り当てを確認する 実務への影響 エンジニア・アーキテクト向け： 新規のAIエージェント開発プロジェクトは、Foundryプロジェクトをベースに設計するのが今後の標準になる。特にエージェント・ワークフロー系の機能はEntra ID認証が必須のため、セキュリティ設計の段階からID管理を組み込む必要がある。「とりあえずAPIキーで動かす」アプローチは開発初期には便利だが、本番移行時に設計の見直しを迫られる可能性がある。 IT管理者・セキュリティ担当向け： GAになったことで、監査ログとRBACが本番レベルでサポートされる。ゼロトラスト設計との親和性が高く、サービスアイデンティティ（Non-Human Identities）の管理も含めてEntra ID中心に統合できる体制が整いつつある。エージェントが自律的に動く環境では、人間のアカウントと同様にNHIへのJust-In-Timeアクセス制御を検討することを推奨する。 既存Azure OpenAIユーザー向け： 今すぐ移行が必須なわけではないが、新機能はFoundryプロジェクト側に集約されていく方向性は明確だ。移行タイミングを組織の開発ロードマップに組み込んでおくことを推奨する。 筆者の見解 Microsoft FoundryがGA到達によってエンタープライズAI基盤として形になってきたことは、正しい方向性だと思う。 特に注目しているのは、Foundryが特定のモデルに縛られない設計になっている点だ。Microsoftはモデル開発の競争で先頭を走っているわけではないが、「どのモデルでも安全に動かせるプラットフォーム」という立ち位置は長期的に見て非常に有利だ。Entra IDがAIエージェントの管制塔になるシナリオは、すでにMicrosoft基盤を持つ企業にとって現実的な最善手といえる。 一方で、クラシックポータルとの分断や移行パスの複雑さは、既存ユーザーにとって頭の痛い問題だ。「まずFoundryプロジェクトへ」という方針は理解できるが、既存資産の移行コストを丁寧にケアする姿勢を見せ続けてほしい。それだけのポテンシャルを持つ基盤だけに、移行の摩擦で採用が鈍ることがないよう期待したい。RBACや監査ログが揃ったいま、あとはユーザーがスムーズに乗り換えられる体験を磨くフェーズだ。 出典: この記事は New Microsoft Foundry portal general availability overview の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはNVIDIA RTX PRO 6000 Blackwell GPUを搭載したAzure NCv6仮想マシンの一般提供（GA）移行を発表した。AI推論とビジュアルコンピューティングを単一基盤に統合したこの新シリーズは、East US・West Europeをはじめとする主要リージョンへの順次展開が始まっている。 Azure NCv6 VMとは何か NCv6シリーズはAzureのGPUコンピューティングラインナップの中でも、プロフェッショナルグレードのAI処理とグラフィックス処理を両立させることを目的とした新世代VMシリーズだ。搭載されるNVIDIA RTX PRO 6000は、Blackwellアーキテクチャをベースとした最新世代のプロフェッショナルGPUであり、前世代のAda Lovelaceアーキテクチャから大幅なパフォーマンス向上を実現している。 NVIDIA Blackwellアーキテクチャの特徴 Blackwellアーキテクチャは、Tensor Coreの最新世代実装によりAI推論ワークロードの処理効率を大幅に高めている。同時にRT Coreの強化によってリアルタイムレイトレーシングも強力にサポートされており、エンタープライズ向けの認定ドライバーと組み合わせることで安定した長期運用が可能だ。 AI推論とビジュアルコンピューティングの統合 従来はAI処理に特化したNCシリーズと、グラフィックスワークロード向けのNVシリーズが分かれていたが、NCv6はこの境界を統合する設計となっている。1台のVM内でAIモデルの推論処理と高精度な3Dレンダリングを並行して実行できる点は、CAD・BIM・映像制作・医療画像解析といった業務において大きなメリットをもたらす。 リモートワークステーションとしての活用 Azure Virtual Desktop（AVD）やWindows 365とのシームレスな統合により、強力なGPUパワーをリモートワークステーション環境から活用できる。物理的なGPUワークステーションの代替として、社外・自宅を問わずプロフェッショナルグレードの作業環境にアクセスできる点は、ハイブリッドワーク推進の観点でも注目に値する。 リージョン展開状況 現在はEast USとWest Europeでの提供が先行しており、他のAzureリージョンへは順次展開予定となっている。日本リージョン（Japan East / Japan West）への展開時期については公式アナウンスを待つ必要があるが、主要リージョン展開後に追随するのがMicrosoftの通例だ。 実務への影響 コスト最適化の観点 GPU搭載の物理ワークステーションはハイエンドモデルで1台あたり数百万円のコストがかかる。NCv6 VMをAVDと組み合わせることで、初期投資を抑えながら複数ユーザーが高性能GPU環境を共用するモデルを構築できる。特に使用頻度が均一でないデザイン部門や研究開発部門では、オンデマンドのGPUクラウドが経済合理性を持ちやすい。 AIエンジニア向けのポイント Blackwellアーキテクチャはトランスフォーマーモデルの推論に最適化されており、大規模言語モデル（LLM）のファインチューニングやRAGパイプラインの本番稼働に直接活用できる。Azure AI Foundryとの統合を活用することで、モデルの開発からデプロイまでをシームレスに進める環境が整っている。 段階的な移行戦略 既存のNCv3やNCasT4_v3シリーズを使っている環境からのリフトは、Azure Migrationガイドを参照して計画的に実施することを推奨する。GA移行によりSLAが正式に適用されるため、本番ワークロードへの採用を安心して進められる環境が整った点は重要なポイントだ。 筆者の見解 Azure NCv6のGA移行は、Azureのコンピューティング基盤としての厚みをあらためて実感させるリリースだ。NVIDIAの最新Blackwellアーキテクチャをいち早くクラウドで提供できるのは、MicrosoftとNVIDIAの深いパートナーシップあってこそであり、このあたりはAzureの揺るぎない強みだと感じている。 特に注目したいのは、AI推論とビジュアルコンピューティングを統合するという方向性だ。これまで「AI用クラウド」と「グラフィックスクラウド」を使い分けなければならなかった組織にとって、単一のVM系列で両方を賄えるのは運用の簡素化につながる。Microsoft Foundry経由でAIモデルを動かす場合も、この基盤は選択肢として十分に検討に値する。 一方で、実際に日本の現場でGPU VMを使いこなすには、コスト感覚と適切なユースケース選定が不可欠だ。「Blackwellだから」という理由でむやみに移行するのではなく、ワークロードの特性をきちんと評価した上で判断してほしい。物理ワークステーションの方が経済合理性の高いシナリオも依然として存在する。 日本リージョンでの提供開始が待ち遠しいところだが、それまでの間はEast US等を使った検証環境構築から始めるのが現実的な準備だろう。Azureはエンタープライズ要件を満たすプラットフォームとしての信頼性を持っており、このシリーズも長期運用に耐えうる選択肢になると見ている。 出典: この記事は Azure NCv6 Virtual Machines: Enhancements and GA Transition の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft は Build 2026 において、独自開発のマルチモーダル AI モデル群「MAI（Microsoft AI）」シリーズの最新版として、MAI-Image 2.5・MAI-Voice 2・MAI-Transcribe 1.5 の3モデルを一挙に発表した。画像生成・音声合成・音声認識という異なる3領域でモデルを揃え、AI インフラとしての自社プラットフォームを強化する姿勢を明確に打ち出した形だ。 MAI-Image 2.5：Arena 画像生成リーダーボードで3位に入る実力 MAI-Image 2.5 は、クラウドソーシング型の評価プラットフォーム「Arena」が公開する画像生成リーダーボードで 3位 を獲得したことが大きな注目を集めている。1位・2位は OpenAI の gpt-image-2 が占めているが、それに次ぐ位置に独自モデルが入ってきたことは、Microsoft の画像生成技術が一定の競争水準に達したことを示す。 エンタープライズ向けの用途——マーケティング素材の自動生成、ドキュメントのビジュアル補強、プロダクトモックアップ生成など——において、Azure AI Foundry 経由でそのまま利用できる点は実用上のメリットが大きい。データレジデンシーやコンプライアンスの観点から、外部 API を経由したくない企業にとっては特に魅力的な選択肢になりうる。 MAI-Voice 2：多言語対応と感情表現の強化 MAI-Voice 2 では多言語サポートの拡張と感情表現の精度向上が主な改善点として挙げられている。テキスト読み上げ（TTS）の品質向上により、コールセンター向け AI エージェントや、Copilot スタジオで構築する音声応答ボット、アクセシビリティ機能への応用が想定される。 日本語話者にとっては、多言語対応の質が実務適用の可否を左右する。日本語での感情表現——イントネーションの自然さ、文脈に応じた抑揚——は引き続き注視が必要だが、エンタープライズ向け音声 AI を社内基盤に統合する観点からは、Microsoft 製エコシステム内で完結できることのメリットは小さくない。 MAI-Transcribe 1.5：会議要約と音声エージェントに照準 MAI-Transcribe 1.5 は音声認識（STT）の精度向上に特化したモデルで、会議の文字起こしと要約、そして音声エージェントのバックエンドとしての活用を主なターゲットとしている。 Teams Premium に組み込まれているインテリジェント要約機能の裏側を支える技術的基盤としての位置づけも考えられ、精度向上はエンドユーザー体験に直結する。また、Azure AI Foundry でカスタムエージェントを構築する際に音声入力を取り込む用途でも、精度の底上げは設計の幅を広げる。 実務への影響——日本のエンジニア・IT管理者の視点から Azure AI Foundry 経由の統合活用 これら3モデルは Azure AI Foundry から利用可能になる見込みだ。すでに Azure 基盤を使っているチームであれば、追加のベンダー契約なしにマルチモーダル機能を取り込める可能性がある。まずはプロトタイプ段階で精度や応答速度を自社ユースケースで検証することを勧める。 音声エージェント構築の現実解 MAI-Voice 2 + MAI-Transcribe 1.5 の組み合わせは、Copilot スタジオや Azure Bot Service と組み合わせた音声エージェント構築の選択肢を広げる。特に社内ヘルプデスクの自動化や、製造現場でのハンズフリー作業支援など、音声インタフェースが有効なシナリオで実証実験を始める価値がある。 ...

Microsoft Build 2026が2026年6月2日、サンフランシスコのFort Mason Centerで開幕し、Azure AI Foundryを核とした大規模なAIエージェント基盤の刷新を発表した。外部データ連携レイヤー「Foundry IQ」、AIネイティブデータベース「Azure HorizonDB」（ベクトルインデックス内蔵）の提供開始と、AnthropicのClaude（クロード）のファーストパーティモデル統合が主なハイライトだ。 AIエージェントは「新しいアプリ」——Microsoftの戦略転換 Satya Nadella（サティア・ナデラ）CEOの基調講演が象徴するように、今年のBuildは「AIエージェントは新しいアプリである」という宣言を核心に据えている。単にプロンプトへ応答するチャットボットとは一線を画し、エージェントは自律的に計画を立て、ツールを使い、複数ステップのタスクを独立して実行できる。 これまでCopilotとして展開されてきた各種アシスタントが、エージェントアーキテクチャへと進化する転換点を迎えている。たとえば、WordのCopilotがリサーチタスクをエージェントに委譲し、そのエージェントが社内文書とWebを横断して情報を収集し、構造化されたブリーフを返す——ユーザーはドキュメントを離れることなくこれを完結できる、といった活用シナリオが具体的に示される予定だ。 Foundry IQ：外部データ連携を標準化する新レイヤー Azure AI Foundryに新たに追加されたFoundry IQは、AIエージェントが企業の外部データソースへアクセスするための統合レイヤーだ。RAG（Retrieval Augmented Generation）を企業環境で実用的に展開する際の最大の課題は「どこのデータをどう引っ張るか」であり、Foundry IQはその部分を標準化・抽象化することを目指す。 従来はSharePoint・Salesforce・基幹システムそれぞれに個別コネクタを実装する必要があったが、Foundry IQによってデータグラウンディングを共通インターフェースで扱えるようになる。エージェントの信頼性向上と開発工数削減に直結する機能追加だ。 Azure HorizonDB：ベクトルインデックス内蔵のAIネイティブDB Azure HorizonDBは、AIワークロードを前提として設計されたデータベースサービスで、ベクトルインデックスを標準機能として内蔵している。従来のリレーショナルDBにベクトル機能を後付けするアプローチとは異なり、セマンティック検索とキーワード検索を統一されたクエリで扱えるよう設計されている点が差別化ポイントだ。 RAGシステム構築時に必要だった別途ベクトルストアの用意が不要になるため、アーキテクチャの複雑さを大幅に削減できる可能性がある。Azure CosmosDBやAzure SQL DatabaseのベクトルDB拡張と比較して、AIネイティブという設計思想がどこまで実務で差別化できるかが今後の注目点だ。 Claude統合：モデル選択の自由度が実用レベルに 今回の発表で特に注目すべきは、AnthropicのClaudeがAzure AI Foundryのファーストパーティモデルとして利用可能になった点だ。OpenAIモデル（GPT-4oシリーズ）に加え、Meta・Mistral・Anthropicのモデルが同一プラットフォーム上で選択・切り替えできる環境が整った。 「Agent Blueprints」と呼ばれる新機能では、カスタマーサポートのトリアージ、サプライチェーンのリスク分析、医療記録の要約など、典型的なエンタープライズシナリオ向けの事前構築済みテンプレートが提供される。ゼロから設計するのではなく、ブループリントを起点に自社環境へ最適化したエージェントを迅速に展開できる。 エージェントの本番運用監視、ハルシネーション検出、コンプライアンス境界の強制といったガバナンスツールも合わせて強化されており、企業導入の信頼性向上が意識されている。 Windows Local AI：クラウドとエッジをまたぐ実行環境 クラウドだけでなく、Windows Local AIとして端末側でのAI推論も本格的に整備されつつある。NPU搭載のCopilot+ PCが普及期を迎えた今、Microsoftは「Local Agent Runtime」を通じてクラウドとエッジをシームレスにまたぐエージェント実行環境を提供する。 Phi-4などのSLM（Small Language Model）をNPU向けに量子化し、オフラインでも動作するエージェントを構築できるWindows AI Studioも発表された。データ機密性が高いユースケースや低遅延が求められる場面では、ローカル実行の選択肢は現実的な差別化要素となる。 実務への影響 日本のエンジニア・IT管理者向けの実践的ポイントをまとめる。 短期（3ヶ月以内）で着手すべきこと Azure AI Foundry上でのモデル切り替え評価: OpenAI一択だった構成から、タスクに応じてモデルを選ぶアーキテクチャへの移行を検討する。長文処理・複雑な推論タスクは特に比較評価の余地が大きい Agent Blueprintsの確認: 既存のCopilot実装をエージェントアーキテクチャに移行できるか、ブループリントを参照して影響範囲を把握する 中期（6ヶ月以内）で進めたいこと Foundry IQによるRAGアーキテクチャの統合: 現在バラバラに管理しているデータコネクタをFoundry IQに集約できるか調査・PoC実施 HorizonDBの評価: 新規プロジェクトのデータストア選定でHorizonDBを候補に加え、ベクトル検索要件のある案件で評価する ガバナンス面の先行準備 ...

Microsoftは2026年6月1日、Microsoft Defender for Cloud のオープンソースリレーショナルデータベース向け保護機能（Defender for Open-Source Relational Databases）をAWS RDS環境に対して正式GA（一般提供）化した。プレビュー期間中に有効化済みの環境は自動移行され、2026年7月の請求から課金が開始される。 何が変わったのか これまでプレビューとして提供されていたAWS RDS向けの脅威検知機能が、本番運用に耐えるGAステータスへ昇格した。対応するデータベースは以下の5種類だ： Aurora PostgreSQL Aurora MySQL PostgreSQL MySQL MariaDB この機能を有効化すると、Defender for Cloudは2つの主要な保護を提供する： データベース脅威検知（Database Threat Protection） — 不審なログインパターン、SQLインジェクション試行、異常なデータアクセスなどをリアルタイムで検知し、セキュリティアラートを発行する 機密データ検出（Sensitive Data Discovery） — AWS RDSインスタンス内の機密データを自動で発見し、セキュリティインサイトに反映する。この機能はDefender CSPM（Cloud Security Posture Management）とも連携し、クラウドセキュリティ態勢の向上に寄与する 有効化の手順 設定はAzureポータルから行う： Azure PortalでMicrosoft Defender for Cloudを開く Environment settings から対象のAWSアカウントを選択 Databasesプランの設定を開き、Open-source relational databasesをオンにする Configure accessからCloudFormationテンプレートをダウンロードし、AWSスタックを更新する 内部的にはDefenderForCloud-DataThreatProtectionDBロールが作成または更新され、RDSのパラメーターグループ・オプショングループの管理権限やログ収集権限がDefender for Cloudに付与される仕組みだ。なお、利用可能なAWSリージョンはテルアビブ・ミラノ・ジャカルタ・スペイン・バーレーン以外のすべてのパブリックリージョン。東京・大阪リージョンは対応済みのため、日本企業の環境で問題なく使える。 注意点：7月から課金が始まる プレビュー中に有効化していた環境では自動的にGAへ移行される。特に何もしなければ保護は継続されるが、2026年7月の請求から課金が開始される点は見落とさないようにしたい。 コスト削減を望む場合は、移行前にプランを明示的に無効化する必要がある。AWSマルチクラウド環境でDefender for Cloudを有効にしているチームは、今すぐ対象インスタンス数とコスト影響を確認することを強く推奨する。 実務への影響 マルチクラウド構成の日本企業に直結する話 日本のエンタープライズでは「コアシステムはAzure、既存のPostgreSQLはAWS RDS」という混在構成は珍しくない。従来はAzureとAWSのセキュリティ監視を別々のツールで管理せざるを得ず、インシデント対応時にコンテキストが分断されるという課題があった。 Defender for Cloudがこの橋渡し役を担うことで、Microsoft SentinelやDefenderのダッシュボードでマルチクラウドDBの脅威を一元的に可視化できる体制が整う。運用チームの負担軽減という観点でも、統合管理が進むのは実務にとってプラスだ。 IT管理者がすぐやるべきこと 課金確認: Defender for CloudのEnvironment settingsでAWSアカウントのDatabasesプランの状態を確認する 対象DB棚卸し: Aurora含むRDSインスタンスの台数と規模をコスト試算に活用する 既存ツールとの重複チェック: AWS GuardDutyやAWS Security Hubとの機能重複を評価し、二重投資になっていないか確認する CloudFormationテンプレートの更新確認: プレビューから自動移行されている場合も、権限設定が最新になっているかを改めて確認する 筆者の見解 マルチクラウドが当たり前になった今、「クラウドをまたいで統一されたセキュリティ管理を行う」という課題はどの企業も抱えている。Defender for CloudがAWS RDSのOSSデータベースを正式サポートしたことは、その課題への実用的な回答のひとつだ。 ...

Microsoft は 2026年6月1日（本日）より、Entra Connect Sync および Cloud Sync において、Entra ID の特権ロールを持つクラウドユーザーへの「ハードマッチ」操作をブロックする施策を段階的に有効化した。オンプレミスの Active Directory（AD）を経由してクラウド特権アカウントを乗っ取る「SyncJacking」攻撃を封じるセキュリティ強化で、ハイブリッドID環境を運用するすべての組織が影響を受ける可能性がある。 ハードマッチとは何か ハードマッチとは、Entra ID 上にすでに存在するクラウド専用ユーザーと、オンプレミス AD のオブジェクトを紐付けるための仕組みだ。 典型的なシナリオは次のとおり。最初はクラウドファーストで組織を立ち上げ、Entra ID 上にユーザーを直接作成して M365 ライセンスや管理ロールを割り当てた。その後オンプレミス AD を導入し、既存のクラウドユーザーをハイブリッドIDとして統合したい——という場面だ。 このとき Entra Connect は AD 側のオブジェクトとクラウド側のオブジェクトを自動的に結びつけることができない。そこで管理者が AD ユーザーの sourceAnchor 属性にクラウドユーザーの onPremisesImmutableId と同じ値を書き込むことで、次回の同期サイクル時に「ハードマッチ」が成立し、AD がそのアカウントのソースオブソリティ（権限の源泉）となる。 SyncJacking——攻撃者が悪用した仕組み このハードマッチの仕組みが攻撃に転用されたのが「SyncJacking」だ。セキュリティ企業 Semperis が 2022 年に開示し、Microsoft のセキュリティ対応センター（MSRC）が 2025年5月に「重要な特権昇格の脆弱性」として公式認定した。 攻撃の流れはシンプルだ。 攻撃者がオンプレミス AD のオブジェクトへの書き込み権限を取得する 標的となるクラウド特権ユーザー（グローバル管理者など）の onPremisesImmutableId を調べる AD オブジェクトの sourceAnchor にその値を書き込む 次の同期サイクルで正規のハードマッチが発生し、AD がそのグローバル管理者アカウントを掌握する 攻撃者は Entra ID に直接触れることなく、AD 経由でクラウド特権を完全掌握する オンプレミス AD への侵入を足がかりにクラウドの最高権限を奪取できる、ハイブリッド環境特有の危険な攻撃ベクターだ。 2段階の強化内容と影響範囲 今回の対策は 2 段階で適用される。 ...

AIエージェントが業務プロセスを自律的に処理する時代が到来しつつある中、Microsoftは2026年3月のRSAカンファレンス直前、Microsoft Defender・Entra・PurviewにAIエージェント専用のセキュリティ機能群を追加発表した。エージェントのID管理・可視化・データ保護を統合する「AIエージェントセキュリティ層」として、組織がAIエージェントを安全にデプロイするための基盤整備が本格化する。 AIエージェントに「専用のセキュリティ層」が必要な理由 従来のアプリケーションと異なり、AIエージェントは「自律的に判断し、外部サービスにアクセスし、データを移動させる」。通常のアプリケーションのアクセス制御モデルが想定していない動作だ。 Microsoftは「AIエージェントは普通のアプリケーションとして扱うべきではなく、専用のセキュリティ層が必要」と明言している。この方針のもと、3つの領域で新機能が投入された。 Agent 365：AIエージェントの管制塔 今回の発表の中核となるのが Agent 365 だ。2026年5月1日に正式提供（GA）が予定されているこのプラットフォームは、組織内に展開されているすべてのAIエージェントを一元的に把握・管理するコントロールプレーンとして機能する。 IT部門・セキュリティチーム・事業部門が同一ビューを共有できる点が重要だ。「どのエージェントが何に、誰の権限でアクセスしているか」を横断的に把握できなければ、ガバナンスは絵に描いた餅になる。Agent 365はMicrosoft 365 E7ライセンスにバンドルされる。 可視化と統制：Shadow AI検知からIntune連携まで AIセキュリティダッシュボード（GA済み） CISOやセキュリティチームが組織全体のAI関連リスクを一覧できるダッシュボードが正式提供された。AIリスクの「見える化」はあらゆる対策の出発点だ。 Entra Internet Access Shadow AI Detection（3月31日より） 管理外のAIサービス利用をネットワーク層で検知する機能。ChatGPTや各種AIツールを頭ごなしに「禁止」するのではなく、利用状況を把握した上で適切なポリシーを当てるアプローチだ。「禁止よりも可視化から」という考え方は、ゼロトラストの文脈でも正しい方向性といえる。 Intune AIアプリインベントリ（5月予定） エンドポイントにインストール済みのAIアプリを深掘り把握する機能。ネットワーク層とエンドポイント層を組み合わせた多層的な可視化が整ってくる。 IDとデータの保護 Entraの新機能 Entra Backup and Recovery（プレビュー）：Entraの設定・データのバックアップと復旧。Entraへの依存度が高まる中、地味ながら実は非常に重要な機能だ Entra Tenant Governance：マルチテナント環境での管理強化 Windows Hello パスキー連携：ネイティブ統合によりパスキー対応を拡張 Purviewによるプロンプトデータ保護 AIプロンプトに個人情報やクレジットカード番号等の機密データが含まれる場合にブロックできる機能が追加された。Microsoftのセキュリティブログは「機密データはポリシーが追いつく速度よりも速くAIワークフローを流れる」と指摘しており、現場の実感とも合致する課題への直接的な対処だ。 Security CopilotとSentinelの新機能 Security CopilotがMicrosoft 365 E5・E7にデフォルト統合された。以下のエージェント型機能が追加されている： Security Analyst Agent in Defender（3月26日よりプレビュー）：繰り返し発生するセキュリティ作業を自動化するアナリスト支援エージェント Security Alert Triage Agent：クラウドおよびID関連アラートのトリアージを自動化 Microsoft Sentinelは「エージェントレス防衛プラットフォーム」として位置づけられ、Microsoft Fabricとのデータ組み合わせ機能が強化された。 日本のIT現場への影響 AIエージェントのガバナンス体制構築が急務になる。 来年・再来年にAIエージェントを本格導入しようとしている企業は、今のうちにIDとアクセス権の棚卸しを進めておく必要がある。エージェントは「動くだけ」では危険であり、「管理された上で動く」が必須条件になっていく。 M365 E7ライセンスの評価が現実的な検討事項になってきた。 Agent 365のバンドル先がE7というのは重要なシグナルだ。AIエージェント活用を本格化させるなら、ライセンス体系の見直しは避けて通れない。 Shadow AI対策には「禁止より把握」のアプローチを。 Entra Internet Access Shadow AI Detectionのような検知・可視化ツールを使い、社員が使っているAIツールの実態を把握した上でポリシーを整備する方が現実的だ。頭ごなしの禁止は利用が地下に潜るだけで逆効果になることが多い。 ...

2026年5月29日（UTC 09:39〜17:05）、Azure OpenAI Serviceが約7.5時間にわたる大規模障害を発生させた。原因は雷雨による電源・熱障害であり、複数のリージョンが影響を受け、AIワークロードに依存する多くのシステムが機能不全に陥った。 何が起きたのか マイクロソフトが公開したPost Incident Review（PIR）によると、障害の根本原因は雷雨による電源サージおよびデータセンター内の熱管理システムへの連鎖的な影響だ。 UTC 09:39に最初の障害が検出され、複数リージョンでAzure OpenAI Serviceへのリクエストが失敗し始めた。影響を受けたリージョンでは、APIリクエストのエラーレートが急上昇し、モデル推論が事実上停止。UTC 17:05に完全復旧が確認されるまでの約7時間26分、AIワークロードが多くの現場で止まった。 影響範囲はAzure OpenAI Serviceにとどまらず、Azure AI ServicesやAzure Machine Learningの一部機能にも波及した可能性がある。 シングルリージョン依存が露わにしたリスク 今回の障害が改めて浮き彫りにしたのは、大規模AIサービスにおけるシングルリージョン設計の危うさだ。 従来のWebアプリやデータベースであれば、複数リージョンへのフェールオーバー設計はすでに常識だ。しかしAzure OpenAI Serviceのような大規模言語モデル（LLM）APIは、マルチリージョン化が難しい現実がある。 モデルのデプロイ先が限定的: GPT-4oやo1シリーズなどのモデルは、すべてのリージョンで等しく利用できるわけではない エンドポイントのリージョン固定: デフォルトのAzure OpenAI Serviceエンドポイントはリージョン固有のURLを使用する コスト: 複数リージョンにプロビジョニング容量（PTU）を確保するのは費用負担が大きい 実務への影響と今すぐできる対策 1. マルチリージョンフェールオーバーを設計する Azure API Management（APIM）やAzure Front Doorと組み合わせることで、マルチリージョンフェールオーバーを実現できる。プライマリリージョン（例：Japan East）とセカンダリリージョン（例：East US 2）の両方にAzure OpenAI Serviceをデプロイし、APIMのバックエンドプールで健全性プローブと自動フェールオーバーを設定するのが王道の構成だ。 2. リトライとサーキットブレーカーをアプリ層に実装する Azure OpenAI Serviceの一時的な障害に対して、指数バックオフ付きのリトライ処理とサーキットブレーカーパターンを実装する。Semantic KernelやPromptFlowを使っている場合は、組み込みのリトライ設定を確認しておくこと。 3. Azure Service Healthのアラートを設定する Azure Service HealthでAzure OpenAI Serviceのサービス正常性アラートを設定し、障害発生時に即座に通知を受け取れるようにしておく。早期に代替手段へ切り替える判断ができるかどうかが、復旧速度を大きく左右する。 4. AIワークロードのSLA設計を根本から見直す Azure OpenAI Serviceの標準SLAは99.9%だが、これは月間約44分のダウンタイムを許容する数字だ。今回の7.5時間はその10倍以上にあたる。ビジネスクリティカルなAIワークロードには、それに見合った冗長設計を要求すること。 筆者の見解 今回の障害で最も気になったのは、技術的な問題そのものではなく、多くの企業がAzure OpenAI Serviceをシングルリージョンで本番稼働させているという現実だ。 ...

2026年5月29日、MicrosoftはAzure Resource Manager MCP ServerのPublic Previewを発表した。AIエージェントがAzure Resource Graph（ARG）クエリを通じてAzureインフラを直接操作・参照できる仕組みが、一般開発者向けに開放される。同週には Azure Files のマネージドID専用認証GA、Azure NetApp Files 64TiBファイルサイズ対応GA、Microsoft Foundry の Vercel AI SDK 対応など複数の重要アップデートが重なった。 Azure Resource Manager MCPサーバーとは MCPとはModel Context Protocol（モデルコンテキストプロトコル）のことで、AIエージェントが外部システムと標準化された方法でやり取りするための仕組みだ。今回公開されたAzure Resource Manager MCP Serverを使うと、Azure AI Foundryで動くAIエージェントが、ARGクエリを通じてAzureリソースの状態を問い合わせたり、リソース管理操作を実行したりできるようになる。 従来であれば「エンジニアがPortalを開き、PowerShellを実行する」という手順が、AIエージェントへの指示一つで完了する可能性が出てきた。「今どのリソースが起動していて、コストはいくらか」「セキュリティルールに違反しているリソースはないか」——そうした問いをエージェントに自然言語で投げられる環境が整ってきている。 今週の主要アップデート Microsoft Foundry + Vercel AI SDK 対応 Microsoft FoundryがTypeScriptのVercel AI SDKに対応した。TypeScriptで書かれたAIアプリケーションからFoundry経由でモデルを呼び出す際の実装コストが下がる。 AKS Application Insights 自動インスツルメンテーション Azure Kubernetes Service（AKS）でApplication Insightsの自動インスツルメンテーションがサポートされた。コンテナワークロードのトレーシングやメトリクス収集の手動設定が不要になり、セットアップ工数が大幅に削減される。 Azure Files Entra ID専用認証のGA Azure FilesのSMBアクセスをEntra IDのマネージドIDのみに制限するモードが一般提供（GA）となった。ストレージアカウントキーへの依存を排除し、ゼロトラスト型のアクセス制御を徹底できる。 ネットワーク強化 NSGとUDRの制限値が引き上げられた。Azure Front Door のWebSocket対応、Network Watcher のルール影響アナライザー追加、VPNのS2S証明書認証とP2Sユーザーグループ別IPプールなども利用可能になった。 Azure NetApp Files 64TiB対応GA 1ファイルあたり最大64TiBのサイズをサポート。大規模データベースやHPCワークロードへの適用範囲が拡大した。 ...

MicrosoftのAzure SRE Agentチームが、インタラクティブCLIよりも先にMCPサーバーをリリースする設計判断の背景と、人間とAIエージェントの両方を同時に相手にするインターフェース設計の原則を公開した。 なぜMCPサーバーが最初なのか Azure SRE Agentには、設計当初から3種類のインターフェースが想定されている。 インタラクティブCLI — 深夜2時のインシデント対応中にターミナルを叩く人間向け。簡潔で障害対応に最適化 エージェントモード — Copilot CLIのようなコーディングエージェントがサブプロセスとして起動するモード MCPサーバー — コーディングエージェントの中にいる人間、および他のエコシステムで動くリモートエージェント向け CLIとエージェントモードには共通点がある。呼び出し側が「Azure SRE Agentの存在を知っていて、意図的に呼び出す」必要がある点だ。人間がコマンドを打つ、あるいはエージェントがサブプロセスを起動する——いずれも能動的な呼び出しだ。 MCPサーバーはまったく異なる動作原理を持つ。ツールとして呼び出し側がすでにいる環境の中に自分を露出する。SREエンジニアがCopilot CLI上で「APIゲートウェイの何が問題か」と尋ねると、モデルがツール説明を読んで適切なツールを発火させる。別のターミナルを開く必要はない。PagerDutyのSREエージェントがトリアージループを回す際も、サブプロセスを起動せずプロトコルで直接応答を得る。 この違いを一言でまとめると：CLIは意図を要求し、MCPサーバーは呼び出し側の居場所に出向く。 MCPサーバーが相手にする2種類の呼び出し元 MCPサーフェスには、同じプロトコルを使いながらまったく異なる文脈の2種類の呼び出し元がいる。 コーディングエージェントの中にいる人間：VS Code CopilotやClaude Desktop、Cursor上でデプロイスクリプトを書いたりRunbookを読んでいるSREエンジニアだ。コンテキストスイッチを望まず、今やっている作業の傍らにSREの能力が自然に存在してほしい。MCPサーバーを一度接続すれば、それは常にそこにある。 他のエコシステムのリモートエージェント：クロスクラウドインシデントを処理するAWS DevOpsエージェント、トリアージループを回すPagerDutyのSREエージェント、あるいは別のAzure SRE Agentインスタンスがサブタスクを委譲する場合などだ。カスタム統合なしに、プロトコルで合意するだけで相互運用できる。 呼び出し元 文脈 必要なもの Copilot CLI / VS Code Copilot上の人間 コーディングセッション中 読みやすい要約、最小限のオーバーヘッド Claude Desktop / Cursor上の人間 エージェンティックセッション 会話内でSREツールが使える状態 AWS DevOpsエージェント 自動インシデントループ 定義されたスキーマ、安定したフィールド PagerDuty SREエージェント トリアージパイプライン パーサブル、疎、ナラティブ不要 別のAzure SRE Agentインスタンス 委譲されたサブタスク エージェント間コントラクト ツール説明文はプロダクト意思決定そのもの MCPツールには名前、自然言語の説明、JSONスキーマが付く。この説明文がモデルのツール選択を直接左右するという点は、見落とされがちながら極めて重要だ。 「Azureリソースのヘルス状態を返す」と書かれたツールと、「VMやゲートウェイ、データベース、コンテナが正常・劣化・到達不能のいずれかを確認する。アクティブな障害の診断やデプロイ後の状態確認に使う」と書かれたツールでは、モデルの呼び出し精度が大きく変わる。 後者は「何をするか」だけでなく「いつ使うか」を伝える。チームはツール説明をシステムプロンプトと同様にイテレーションした——テスト中に誤った呼び出しが発生したとき、修正箇所はほぼ常にスキーマではなく説明文だったという。 人間とエージェント、なぜ同じ出力形式を使うのか 人間は読みやすいレスポンスを求め、リモートエージェントはパース可能な構造を求める。「呼び出し元に応じて出力形式を切り替えるべきでは？」という発想は自然だが、チームはあえて単一の出力形式を選んだ。 すべてのツールレスポンスは、定義されたフィールドと安定したセマンティクス、そして1つの summary フィールド（平文の1文）で構成される。人間は summary を読み、リモートエージェントはそれを無視して構造化フィールドをパースする。オーバーヘッドはどちらの方向でも無視できる程度だ。 ...

Microsoftは2026年5月28日、Microsoft Marketplaceの最新アップデートとして、AI推論サービス「Fireworks AI」のMicrosoft Foundryパブリックプレビュー開始と、DeepSeek V4 Flash・DeepSeek V4 ProのFoundry提供を発表した。エンタープライズ向けAIモデルの選択肢が一気に拡充され、Azure基盤上で多様なオープンモデルを高速に運用できる環境が整いつつある。 Fireworks AI、Microsoft Foundryでパブリックプレビュー開始 Fireworks AIは、オープンソースAIモデルの高速推論に特化したプラットフォームを提供するスタートアップ企業だ。同社独自の最適化技術により、Llama系やMistral系のオープンモデルを標準的な推論エンジンと比較して大幅な低レイテンシで運用できる点が強みとなっている。 このサービスがMicrosoft Foundryのパブリックプレビューとして利用可能になったことで、Azure利用企業はFireworks AIの最適化された推論エンジンをエンタープライズグレードのセキュリティ・コンプライアンス環境のまま活用できるようになる。チャットボット等のリアルタイムインタラクションが求められるユースケースでは、推論速度の差がそのままユーザー体験の差になるため、このオプションの追加は実務的な意味が大きい。 DeepSeek V4 Flash・ProがFoundryに追加 今回のアップデートで合わせて注目すべきは、DeepSeek V4 FlashとDeepSeek V4 ProのMicrosoft Foundryへの追加だ。DeepSeekはオープンウェイトモデルを公開している企業で、V4世代では特に数学・論理推論・コーディング支援タスクでの精度向上が報告されている。 Microsoft Foundry経由での提供により、自社データをDeepSeekの外部クラウドに直接送信することに抵抗感がある組織でも、Azure基盤上での管理・運用という形であれば導入を検討しやすくなる。組織のリスクポリシーに応じて「使う・使わない」を判断できる選択肢が揃うことが、プラットフォームとしての役割だ。 実務への影響 今回の追加により、Azure AI Foundry上で選択可能なモデルのラインナップが大きく広がった。GPT-4o・Claude・Geminiといったクローズドモデルに加え、各種オープンモデルを同一プラットフォーム上で比較・評価・本番運用できる環境が整いつつある。 実務での活用として、以下のシナリオが考えられる： コスト最適化: 高精度が必要なタスクにはプレミアムモデル、バッチ処理や社内ドキュメント分類には高速・低コストなオープンモデルを使い分ける ベンダーロックイン分散: 特定プロバイダーへの依存を分散させることで、価格交渉力を維持しつつリスクを低減する レイテンシ重視のユースケース: インタラクティブなチャットアプリやリアルタイム補助機能ではFireworks AIの高速推論が有効な選択肢になる IT管理者の観点では、Microsoft Foundry経由のモデル利用はMicrosoft Entra IDによるアクセス制御・Azure Policyによるガバナンス・既存コンプライアンスフレームワークとの統合がそのまま使える。「AIを導入したいが、外部クラウドへのデータ送信のリスク管理をどうするか」という日本企業特有の懸念も、Foundryプラットフォームであれば対処しやすい。 筆者の見解 Microsoft Foundryにオープンモデルの選択肢が増えることは、正しい方向性だと評価している。 筆者はかねてから「Microsoft基盤の強みを最大限に生かしながら、推論に使うモデルは最善のものを選ぶ自由を使えばいい」というスタンスをとっている。Microsoft Entra IDによる統合認証・コンプライアンス管理・既存インフラとの接続性——これらはMicrosoft基盤が本当に優れている領域だ。そのプラットフォームの上で動かすAIモデルについては、ユースケースに応じた最善の選択ができる状態を作ることが、エンタープライズにとって合理的な戦略になる。 Fireworks AIの高速推論がFoundryに統合されることも歓迎したい。AIの実用化において「レイテンシ」は見落とされがちだが、ユーザーが実際に触れる体験に直結する要素だ。コスト・精度・速度の三軸で選択肢を持てることが、現場でのAI展開を加速させる。 Foundryが「最良のAIを安全に動かすプラットフォーム」として機能し続けることで、Microsoftの競争力は一層高まる。そのロードマップを着実に実行し続けてほしい。 出典: この記事は New in Microsoft Marketplace: May 28, 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月のPatch Tuesdayで計130件の脆弱性を修正した。中でもAzure DevOpsの情報漏洩（CVE-2026-42826）とAzure Cloud ShellのSSRFによる権限昇格（CVE-2026-32169）はいずれもCVSS 10.0という最高スコアを記録しており、Azure環境を運用するすべての組織で即時対応が求められる。 修正された主要Azure脆弱性 今月のPatch TuesdayにおけるAzure関連の修正は16件。特に注目すべき3件を解説する。 CVE-2026-42826：Azure DevOps 情報漏洩（CVSS 10.0） CVSS満点10.0を記録したAzure DevOpsの情報漏洩脆弱性。CI/CDパイプラインやソースコードリポジトリを管理するAzure DevOpsは多くの企業の開発インフラ中枢を担っており、この脆弱性が悪用されると機密コードやシークレット情報が流出しうる。サプライチェーン攻撃の入口になりかねない点が特に深刻だ。 CVE-2026-32169：Azure Cloud Shell SSRF → 権限昇格（CVSS 10.0） Azure Cloud ShellにおけるSSRF（Server-Side Request Forgery）を利用した権限昇格の脆弱性。こちらもCVSS 10.0。SSRF攻撃は本来アクセスできないはずの内部リソースへの到達を可能にする。Cloud Shellはブラウザから直接Azureリソースを操作できる便利なツールだが、悪用された場合はテナント全体に影響が及ぶリスクがある。 CVE-2026-35435：Azure AI Foundry アクセスコントロール EoP Azure AI Foundryにおけるアクセスコントロールの不備による権限昇格（Elevation of Privilege）脆弱性。AI開発・運用基盤として企業導入が進むAI Foundryへの攻撃経路であり、AI関連ワークロードのセキュリティ設計を改めて見直す契機となる。 なぜこれが重要か CVSS 10.0は脆弱性スコアの最高値であり「理論上考えられる最悪の影響範囲」を意味する。それが今月は2件同時に報告されたという事実は、軽く受け流せるものではない。 特にAzure DevOpsは現代のソフトウェア開発サプライチェーンの核心部分だ。ここが攻撃されると、ソースコード流出にとどまらず、ビルドパイプラインへの不正コード挿入という連鎖攻撃につながりうる。加えてAzure Cloud ShellはAzure管理者が日常的に使うツールであり、権限昇格の被害を受けた場合はテナント全体への波及が現実的なリスクとなる。 実務での対応ポイント 今すぐやること Azure DevOpsおよびAzure Cloud Shellを利用している環境では、Microsoftが提供するパッチを即時適用する Microsoft Defender for Cloud のアラートを確認し、既に不審なアクセスやSSRFの痕跡がないかを調査する Azure AI Foundryを利用している場合は、アクセス権限の棚卸しを今週中に実施する 中長期的な対応 Azure DevOpsのサービスプリンシパルに付与された権限を最小特権の原則で見直す Cloud Shellの使用ログをAzure MonitorまたはMicrosoft Sentinelで継続監視する設定を入れる CI/CDパイプラインで使われるNon-Human Identity（マネージドID・サービスプリンシパル）の権限を定期監査する仕組みを整備する NHI（Non-Human Identity）の過剰権限は今回のような権限昇格攻撃が刺さりやすい条件を作り出す。サービスプリンシパルに「とりあえずOwner」を付けたまま放置しているケースは依然多い。今回を機に棚卸しを実施してほしい。 ...

Azure DatabricksはvLLMエンジンによるカスタム・ファインチューニングLLMのサービング（Beta）、Lakeflow Spark宣言的パイプラインのリアルタイムモード（パブリックプレビュー）、Anthropic Claude Opus 4.8のホスティング対応など、2026年5月に大型アップデートを一斉公開した。 vLLMカスタムモデルサービング（Beta） vLLM（高効率LLM推論エンジン）を使ったカスタムLLMのサービングがBeta公開された。自社でファインチューニングしたモデルや独自の量子化済みモデルをAzure Databricks上で直接ホストし、APIエンドポイントとして提供できるようになる。 従来はManagedサービスのモデルか、自前のKubernetesクラスター上でのサービングが主流だったが、vLLMをDatabricksのModel Servingに統合することで、データとモデルの距離を縮め、レイテンシを最小化しながらセキュアな推論環境を構築できる。ファインチューニング済みモデルを扱う組織にとって、推論インフラの管理コスト削減は直接的なメリットだ。 Lakeflow Sparkリアルタイムパイプライン（パブリックプレビュー）：5ms以下の世界 Lakeflow Spark宣言的パイプラインにリアルタイムモードが追加され、エンドツーエンドのレイテンシが5ms以下を実現するとのことだ。同時にupdate_flow APIもパブリックプレビューに入った。 金融取引のリアルタイム不正検知、IoTセンサーデータの即時分析、ライブダッシュボード更新など、これまでKafka＋専用ストリーミング基盤が必要だったユースケースをLakeflowに統合できる可能性がある。update_flow APIの追加により、パイプラインの一部フローのみを選択的に更新・再実行するオペレーションも可能になり、本番環境での部分修正コストが大幅に下がることが期待される。 Anthropic Claude Opus 4.8がDatabricks-hostedモデルとして利用可能に Databricks Model ServingにAnthropic Claude Opus 4.8が追加された。Foundation Model APIのpay-per-tokenとして利用でき、推論（Reasoning）モデルやビジョンモデルのクエリも対応している。 Databricksの統合環境内でClaude Opus 4.8を呼び出せることで、データパイプラインの結果をそのままLLMに渡す処理フローを、外部APIへのデータ転送なしに構築できる。データガバナンスの観点でも、データがDatabricks/Azure環境外に出ないという点は企業にとって重要な選択肢になる。 その他の主要アップデート Databricks Appsの水平スケーリング（Beta）: 単一のアプリURLの背後で複数インスタンスを起動可能に。ゼロダウンタイムデプロイとセッションアフィニティを実現する。 クロスエンジンABAC（Beta）: 外部エンジンがUnity CatalogのDelta・IcebergテーブルへABACを適用した状態でアクセスできるようになった。行フィルター・列マスクのポリシーをUnity Catalogに一元化できる点が大きい。 Lakeflow Designerの強化: AI生成説明文の双方向編集、N-way Combine演算子、カスタムJOIN条件、マルチモーダル出力プレビューなど、データエンジニアリングUIが大幅に改善された。 実務への影響 ファインチューニング運用チームへ: vLLMサービングのBeta開始により、学習基盤と推論基盤をDatabricks上に統一するアーキテクチャが現実的になった。今のうちにPoC評価を始めておくことを推奨する。 データエンジニアへ: リアルタイムパイプラインの5ms以下レイテンシは、Kafkaベースの既存アーキテクチャの再評価トリガーになりうる。ただしBeta/PPの段階では、本番SLA要件との照合を慎重に行うこと。 セキュリティ・ガバナンス担当者へ: クロスエンジンABACとUnity Catalogの組み合わせは、マルチエンジン環境でのデータアクセス制御の標準化につながる。Databricksを中心にしたガバナンス設計の検討価値が上がった。 筆者の見解 今回のアップデートで最も注目したいのは、vLLMカスタムサービングとリアルタイムパイプラインの組み合わせが示す方向性だ。「データがある場所でAI推論も動かす」という思想が、着実にプラットフォームに実装されている。これはAzure全体のアーキテクチャ哲学とも一致する。データをどこか別の場所に送ってAIで処理するのではなく、データが存在するプラットフォームの上でAIも動かす——この考え方は、セキュリティとレイテンシの両面で理にかなっている。 Claude Opus 4.8がDatabricks-hostedで使えるようになったことも評価したい。Microsoft Foundry経由で各種モデルを選べる環境が広がることは、Azure基盤を維持しながら推論エンジンを柔軟に選択できるという現実的な解に近づく動きだ。 リアルタイムパイプラインの5ms以下レイテンシには正直驚いた。ストリーミング処理の文脈でDatabricksを語ることへの抵抗感が筆者にはあったが、この数字が本番環境でも安定するならば、専用ストリーミング基盤の存在意義を問い直す必要があるかもしれない。BetaからGAへの成熟を注視したい。 出典: この記事は Azure Databricks May 2026 Release Notes: vLLM Custom Serving & Real-Time Pipelines の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftはAzure Container Apps上で動作するAzure Functionsに対し、カスタムKEDAスケールルールのオーバーライド機能を正式サポートした。allowScalingRuleOverride プロパティを true に設定するだけで、Service Bus・Kafka・Cronをはじめとする60以上のKEDAスケーラーを自由に組み合わせられる。プラットフォームが自動生成していたスケールルールを超え、きめ細かなスケール制御が現実のものとなった。 KEDAとAzure Container Apps——基礎の整理 KEDA（Kubernetes Event-driven Autoscaling）は、Kubernetes上でイベント駆動型のオートスケールを実現するOSSプロジェクトで、現在はCloud Native Computing Foundation（CNCF）のインキュベーションプロジェクトとして管理されている。Azure Container AppsはこのKEDAを基盤に持っており、キューの深さ・メッセージ数・HTTPリクエスト数などのメトリクスに応じてコンテナのレプリカ数を0から自動的にスケールアウト・スケールインする仕組みを提供してきた。 これまでAzure Container Apps上のAzure Functionsは、Functionsランタイムが自動的に適切なKEDAスケールルールを生成していた。この自動化は便利な反面、「もっと複雑なスケーリング条件を設定したい」「複数のトリガーを組み合わせたい」というニーズに応えられなかった。 何が変わったのか——allowScalingRuleOverride の効果 今回の新機能の核心は allowScalingRuleOverride プロパティだ。このプロパティを true に設定すると、Functionsランタイムが自動生成するスケールルールへの依存をやめ、ユーザー自身が定義したカスタムKEDAスケールルールが適用されるようになる。 具体的には以下のことが可能になる： Service Bus スケーラー: キュー内の未処理メッセージ数に基づいてワーカー数を制御 Kafkaスケーラー: コンシューマーグループのラグ（遅延）に応じてスケール Cronスケーラー: 時間帯や曜日ベースでのスケジュール制御 複合スケールルール: 複数のスケーラーを AND/OR 条件で組み合わせるカスタム構成 60以上のKEDAスケーラーが利用可能であり、MySQLやPostgreSQLのクエリ結果、Prometheusメトリクス、外部HTTPエンドポイントの値などを基準にスケールさせることもできる。 設定方法の概要 azure.yaml または Bicep/ARM テンプレートでの設定例は以下のようなイメージだ（実際のスキーマはドキュメントを参照）： 出典: この記事は Custom KEDA Scale Rules for Azure Functions on Azure Container Apps の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはBuild 2026（6月2日、サンフランシスコ）において、WindowsをAIエージェントのネイティブ実行プラットフォームとして正式に位置づけ、オンプレミス・クラウド・エッジを横断する分散エージェント管理基盤「Azure Agent Mesh」を発表した。Windows Agent Runtime（WAR）の導入により、エージェントはOSの構成要素として動作するようになり、これまでのCopilotのような付加機能とは一線を画す。 Windows Agent Runtime（WAR）：エージェントをOS構成要素として扱う WARはバックグラウンドサービスとして動作し、エージェントのライフサイクル・メモリ・パーミッションを一元管理する。基盤はモダンアプリが依存するWinRTと同じレイヤーであり、その上にルールエンジンを追加することで細粒度のアクセス制御を実現している。 注目すべきはAgentPolicy APIだ。IT管理者はエージェントがアクセスできるフォルダ、ネットワーク、クリップボードまで宣言的に定義できる。「センシティブデータをスキャンするエージェントは特定フォルダのみ参照可能、ネットワークアクセスは禁止」といった設定を、開発者がサンドボックスを自前実装することなく実現できる点は企業にとって大きな意味を持つ。 Microsoftはアーキテクチャの第一原則を「セキュリティ」と定義しており、エンタープライズが懸念する「AIエージェントのガバナンス不在問題」に正面から応えようとする設計になっている。 開発者向けツールチェーン：YAMLマニフェストでポータブルなエージェント定義 Visual Studio 2026には「Agent Designer」が搭載される。低コードのコンパニオンUIからエージェントの意図・アクション・安全制約を記述したYAMLマニフェストを生成でき、Gitによるバージョン管理にも対応する。新CLIツールwagentはマニフェストと依存ファイルをシングル実行バイナリにパッケージングする。 実演ではWindows Server 2026・Windows IoT・Windows 365 Cloud PCの3環境で同一マニフェストを無修正で動作させており、コンテナワークロードに近いポータビリティを実現している。 Windows 365がエージェント実行ノードに Windows 11 バージョン26H2から、Windows 365でプロビジョニングされたCloud PCがAIエージェントのセキュアな実行ノードとして機能するようになる。企業はCloud PCインスタンスをまたがるエージェントプールを定義し、数千の並列ドキュメント処理ボットをVMを直接管理することなくスケールさせることが可能だ。 新クライアント「Windows 365 Link」を使えば、低スペックノートPCからでもGPUアクセラレーション済みCloud PC上でエージェントを実行し、結果をローカルで受け取れる。デモではSharePointライブラリを監視し、契約書から重要条項を抽出してDynamics 365レコードに書き込むワークフローがWindows 365 Agent Node上で動作し、数秒でローカルに結果が反映されていた。 Azure Agent Mesh：オンプレ・クラウド・エッジを横断する制御プレーン Azure Agent Meshは今回最も注目すべき発表だ。オンプレミスWindowsサーバー、Windows 365 Cloud PC、Azure Arc対応エッジデバイスを一つのエージェント実行制御プレーンとして統合する。開発者はローカル開発と同一のAPIでこのMeshをターゲットにでき、Meshがレイテンシ・GPU可用性に基づいてタスクを最適な実行環境へ自動ルーティングする。GA（一般提供）は2026年Q4を予定。 実務への影響 IT管理者・セキュリティ担当者にとって、AgentPolicy APIは「まずエージェントを禁止する」アプローチを取らなくて済む設計だ。最小権限の原則に基づいた許可リストをYAMLで定義・バージョン管理できるため、エージェントの野良導入を防ぎながら業務自動化を安全に進められる。Microsoft Entra IDとの統合による認証・認可の一元管理も想定されており、Non-Human Identities（NHI）の管理基盤として機能する可能性がある。 エンジニアにとっては、YAMLマニフェストでエージェントを定義しGit管理するワークフローは、既存のIaC（Infrastructure as Code）運用と同じ感覚で扱える点が大きい。wagentによるパッケージングでCI/CDパイプラインへの組み込みも容易になるだろう。Azure Agent Meshにより、社内の物理サーバーリソースとAzureのスケーラビリティを状況に応じて使い分ける柔軟な設計が現実的になる。 アーキテクトにとって、Azure Agent Meshは「どこでエージェントを動かすか」という配置判断をアプリ層から切り離せることを意味する。データレジデンシーの制約でオンプレミス必須のワークロードとクラウドスケールが必要なバースト処理を、同一の開発・運用フローで扱えるようになる。 筆者の見解 Build 2026の発表を通じて、Microsoftがエージェント時代の基盤プレイヤーとしての戦略を明確にしてきたと感じる。特にAgentPolicy APIとAzure Agent MeshはMicrosoftが得意とする「エンタープライズのガバナンスをどう守るか」という問いへの回答として筋が通っている。 ...

MicrosoftはAzure Monitorパイプラインの新機能3種類──セキュアインジェスション、ポッド配置ルール、データ変換機能──をパブリックプレビューとして公開した。Kubernetes環境における観測性（オブザーバビリティ）基盤の強化を目的とした機能群であり、エージェントレスアーキテクチャへの移行をさらに後押しする内容となっている。 Azure Monitorパイプラインとは Azure Monitorパイプラインは、ログ・メトリクス・トレースなどの観測データをAzureネイティブに収集・加工・転送するためのインフラだ。従来のエージェントベースの収集から脱却し、プラットフォーム側でデータフローを制御する方向性を着実に進めてきた。今回のパブリックプレビューでは、特にKubernetes環境に向けた機能拡張が中心となっている。 新機能の概要 セキュアインジェスション データ収集経路にセキュリティレイヤーを追加する機能だ。収集エンドポイントへの通信を暗号化・認証付きで行えるようになり、テレメトリデータの改ざんや盗聴リスクを低減する。マネージドIDや証明書ベースの認証と組み合わせることで、ゼロトラスト原則に沿った観測基盤を構築できる。 ポッド配置ルール Kubernetesクラスター内のどのノード・ポッドからデータを収集するかを、ルールベースで細かく制御できる機能だ。ラベルセレクタや名前空間フィルタを用いて、特定のワークロードだけを監視対象に絞り込める。不要なデータ収集を排除することで、取り込みコストの最適化と監視ノイズの削減が両立できる。 データ変換機能 収集したテレメトリデータをパイプライン内でフィルタリング・加工・正規化してから格納する機能だ。Kusto Query Language（KQL）ライクな変換ロジックを使って、フィールドの追加・削除・マスキングや条件付きルーティングが可能になる。PII（個人識別情報）の除去やコスト最適化のためのサンプリングもここで実装できる。 実務への影響 Kubernetes運用チームにとって Kubernetesクラスターの運用では「監視はしたいが、コストとノイズが爆発する」という悩みを持つ現場が多い。ポッド配置ルールとデータ変換機能の組み合わせにより、「本当に必要なデータだけを取り込む」という設計が現実的になってきた。 特にAzure Kubernetes Service（AKS）を使っている環境では、Azure Monitor managed service for PrometheusやContainer Insightsと組み合わせることで、フルマネージドな観測基盤が完成する。 セキュリティ・コンプライアンス担当者にとって セキュアインジェスションとデータ変換（PII除去）の組み合わせは、コンプライアンス要件を満たしながら観測性を確保したい組織にとって有効な手段だ。個人情報保護法やGDPRへの対応として、ログの中から個人情報を自動除去してから格納する運用がパイプライン内で完結する。後処理に頼らずデータ収集の入口で対処できるのは設計として堅牢だ。 コスト意識の高い組織にとって Azure Monitorの取り込みコストは、大規模クラスターでは無視できない金額になる。ポッド配置ルールによる収集対象の絞り込みと、変換機能によるサンプリング・フィルタリングを組み合わせれば、観測品質を維持しながら費用を抑制する余地が生まれる。パブリックプレビュー期間中にコスト試算を行っておくと、GA後の移行判断がスムーズになる。 筆者の見解 Azureのオブザーバビリティスタックは、この数年で「エージェントを入れれば動く」という状態から「プラットフォームとして設計する」段階へと着実に成熟してきた。今回の機能追加はその延長線上にある。 特に評価したいのは、データ変換をパイプライン内で完結させる方向性だ。これまでデータが格納されてからKQLで後処理するアプローチが主流だったが、取り込み前の段階で不要データを捨て、必要な形に整えてから格納する設計は、コストとセキュリティの両面で理にかなっている。 ゼロトラストの観点でも、観測データの収集経路そのものを保護するという発想は遅すぎるくらいだった。テレメトリデータが改ざんされれば、インシデント対応の根拠が崩れる。セキュアインジェスションは地味に見えるが、長期的にはインフラの信頼性に直結する機能だ。 Azureプラットフォームとしての強みは、こういった「インフラ側でちゃんと考えている」積み重ねにある。パブリックプレビューの段階で積極的に検証し、GA移行後にスムーズに本番適用できる体制を整えておくことを勧めたい。 出典: この記事は Announcing new public preview capabilities in Azure Monitor pipeline の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Azure API Centerのウェブポータルを正式リリース（General Availability、GA）した。これにより、組織内に散在するあらゆるAPIをポータルUIから一元的に管理・検索・文書化できる機能が、本番環境での利用に正式対応した。 Azure API Center ポータルとは何か Azure API Centerは、組織が保有するすべてのAPI（REST、GraphQL、gRPC、SOAPなど）を単一のカタログとして管理するためのAzureサービスだ。今回GAとなった「ポータル」は、このカタログをエンジニアやAPI利用者がブラウザから直感的に操作できるウェブUIとして提供するもので、これまでCLIやAPIベースの操作が中心だった部分を大幅に使いやすくする。 ポータルで主に実現できることは以下の通りだ。 APIカタログの横断検索 — 組織内の全APIを横断的に検索し、利用可能なAPIをすばやく発見できる APIドキュメントの参照 — OpenAPI仕様書などのAPI定義を視覚的に確認できる メタデータ・ライフサイクル管理 — APIの開発状況（開発中/プレビュー/本番/非推奨）、オーナー、コンプライアンス状態などを一元的に管理できる Azure API Managementとの統合 — 既存のAPIゲートウェイと連携し、ガバナンスを強化できる なぜこれが重要か 日本のエンタープライズ企業では「APIが組織内に乱立しているが全容を把握できていない」という状況が非常に多い。マイクロサービス化が進んだ組織では、部門ごとに独自のAPIが生まれ、類似機能のAPIが重複して作られるケースも珍しくない。結果として、セキュリティリスクの見落としや開発コストの増大につながる。 Azure API Centerポータルのは、プラットフォームエンジニアリングの文脈でAPIガバナンスを標準化するうえで意味のある一歩だ。「APIをまず台帳に登録する」という文化が根付けば、開発効率の向上とコスト削減、そしてセキュリティリスクの低減が期待できる。 また、近年注目されるNon-Human Identities（NHI）の管理という観点からも見逃せない。APIはまさにNHIの集合体であり、どのAPIが何の権限で何にアクセスしているかを可視化することは、ゼロトラストセキュリティ推進において直接的な意味を持つ。管理されていないAPIは、単なる技術的負債ではなくセキュリティ上の盲点になり得る。 実務での活用ポイント 1. まず社内APIの「棚卸し」から始める ポータルを導入する前に、組織内の主要APIをカタログに登録する作業から入ろう。Azure API ManagementやAzure Functionsで公開中のAPIは自動インポートできる場合もあるため、既存資産の棚卸しから始めると効果的だ。 2. ライフサイクルステージを明示して廃止計画を立てる 「開発中」「プレビュー」「本番」「非推奨」のステージを明示することで、古いAPIへの依存を防ぎ、段階的な廃止計画を立てやすくなる。 3. 内部APIも「開発者ポータル」として活用する 外部公開APIだけでなく、社内向けAPIもポータルで管理することで、「既存APIを再利用する文化」を醸成できる。同じ機能のAPIを複数チームが重複開発するムダが減る。 4. OpenAPIリンティングをCIパイプラインに組み込む Azure API CenterはAPIのコンプライアンス状態を追跡できる。CI/CDパイプラインでOpenAPI仕様書の検証を自動化し、その結果をポータルで可視化することで、APIレビュープロセス全体を標準化できる。 筆者の見解 APIガバナンスは地味に見えるが、プラットフォームエンジニアリングの中核をなす重要な取り組みだ。Azure API Centerポータルのこの節目は、この地道な領域に対するMicrosoftのコミットメントとして評価したい。 「禁止ではなく安全に使える仕組みを」という観点で言えば、APIの一元管理は理にかなったアプローチだ。APIの利用を制限するのではなく、標準化されたカタログを通じて「公式ルートが一番便利」という状況を作り出す。この方向性は正しい。 ただし、ツールが整っても文化が変わらなければ意味がない。ポータルを入れただけで満足する組織と、APIファーストの設計思想をチーム全体に浸透させる組織との差は、今後さらに広がるだろう。AIエージェントがAPIを介してシステムを操作する時代が加速する今、API管理の整備に着手するなら早いほどよい。Microsoftにはこの機能をより使いやすく・より深く機能させるアップデートを続けてほしいと、率直に期待している。 出典: この記事は Azure API Center portal is now generally available の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはAzure SQL Database、Azure SQL Managed Instance（always-up-to-dateポリシー適用済み環境）、およびFabric SQLに対して、インデックス自動圧縮機能「Auto Index Compaction」をパブリックプレビューとして公開した。従来DBAが手動で組んでいた夜間インデックス再構築ジョブを、プラットフォーム側が自律的に代替する機能だ。 インデックス断片化との長い戦いに終止符 RDBMSを長く運用していると必ず向き合うのがインデックス断片化の問題だ。データの挿入・更新・削除を繰り返すうちにB-Treeのページが断片化し、クエリパフォーマンスが徐々に低下する。これを解消するために多くの現場では深夜に ALTER INDEX ... REBUILD や REORGANIZE を走らせるジョブを組んでいる。 しかしこのアプローチには根本的な課題がある。REBUILD処理はテーブル全体を対象とするため、I/Oとメモリを大量消費する。クラウド環境では「深夜帯だからコストを気にしなくていい」という理屈は通らず、スロットリングや予期しないコスト増につながるリスクがある。また、REBUILDのオンラインモードは一部の旧エディションでは非対応だった歴史もあり、メンテナンスウィンドウの設計が複雑になりがちだった。 Auto Index Compactionの仕組み Auto Index Compactionが従来のREBUILD/REORGANIZEと根本的に異なるのは、処理済みページのみを対象にするという設計思想だ。テーブル全体をスキャンして再構築するのではなく、実際にDMLが発生して断片化したページだけを継続的に圧縮・整理する。 これにより以下のメリットが生まれる： リソース消費が大幅に少ない: 全件スキャンではないため、CPU・I/O・メモリへの影響が局所的に留まる バックグラウンドで継続稼働: 特定の時間帯に集中させる必要がなく、アイドル時間を活用して常時最適化が進む 設定が1コマンド: ALTER DATABASE [database_name] SET AUTOMATIC_INDEX_COMPACTION = ON のみで有効化完了 現時点でパブリックプレビューが適用されるのはAzure SQL Database、Azure SQL Managed Instance（always-up-to-dateポリシー）、Fabric SQLの3環境。オンプレミスのSQL Serverは対象外であることに注意が必要だ。 実務への影響：日本のDBAが今すぐ見直すべきこと 1. 既存のインデックスメンテナンスジョブの棚卸し SQL Server AgentやAzure Automationで組んでいる夜間REBUILDジョブを一覧化しよう。Auto Index Compactionが有効な環境では、それらジョブを無効化または削除できる可能性が高い。ジョブの削除はメンテナンスコストの削減に直結する。 2. コスト試算の見直し Azure SQL Database（サーバーレスモデル）を使っている場合、夜間の大規模REBUILDによるvCoreスパイクがコストに響いていたケースがある。Auto Index Compactionへの移行で、このスパイクを平準化できるかモニタリングしてみる価値がある。 3. Fabric SQL利用者にとっての意義 Fabric SQLはまだ採用初期の組織が多いが、インフラ管理の手間を最小化したいという需要に応える形でこの機能が提供されたことは注目に値する。Fabricの「フルマネージドで運用負荷ゼロ」というコンセプトと一貫している。 4. プレビュー中の動作検証を早めに ...