Microsoft FoundryにFireworks AIとDeepSeek V4が追加——エンタープライズ向けAIモデル選択肢が大幅拡充

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

May 30, 2026 · 1 min · 胡田昌彦

Azure DevOpsとCloud ShellにCVSS 10.0の致命的脆弱性——2026年5月Patch TuesdayでAzure関連16件を含む130脆弱性を修正

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」を付けたまま放置しているケースは依然多い。今回を機に棚卸しを実施してほしい。 ...

May 30, 2026 · 1 min · 胡田昌彦

Azure Databricks 2026年5月アップデート:vLLMカスタムモデルサービング・5msリアルタイムパイプライン・Claude Opus 4.8対応が同時解禁

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

May 30, 2026 · 1 min · 胡田昌彦

Microsoft、画像生成モデル「MAI-Image-2-Efficient」をFoundryで公開 — GPU効率4倍・速度22%向上でバッチ生成コストを大幅削減

Microsoftは2026年5月、新しい画像生成モデル「MAI-Image-2-Efficient(Image-2e)」をMicrosoft Foundryで公開した。前世代の「MAI-Image-2」と同じアーキテクチャを基盤としながら、GPU効率を最大4倍、処理速度を最大22%向上させており、Eコマース・メディア・マーケティング分野での大規模本番利用を強く意識した設計となっている。 MAI-Image-2-Efficientとは Image-2eは、Arena.aiの画像モデルファミリーランキングで3位を記録した「MAI-Image-2」の効率化版だ。同じモデルアーキテクチャを維持しながら、レイテンシとGPU使用量で正規化した比較において最大4倍の効率化を実現している。 具体的な数字を並べると: 処理速度:MAI-Image-2比で最大22%向上 GPU効率:レイテンシ正規化で最大4倍 競合比較:主要な画像生成モデルと比べて平均40%高速 「同じ品質の画像を、より少ないGPUリソース・より短い時間で生成できる」という点がImage-2eの核心だ。これは1枚あたりの生成コストに直結する話であり、大量生成が必要な業務現場では非常に重要な改善となる。 対象とするユースケース Image-2eはとくに以下のシナリオを念頭に設計されている。 Eコマース・商品画像の大量生成 商品カテゴリごとに何千枚もの商品画像や背景違いバリエーションを日々生成するようなプラットフォームでは、GPU時間のコストが直接事業コストに乗ってくる。Image-2eの4倍効率化は、スループット向上か、または同じスループットを大幅に低いコストで実現するか、という選択肢を与えてくれる。 メディア・マーケティングのコンセプト生成 ムードボードやコンセプトアートを迅速に反復するクリエイティブチームでは、速度が体験の品質に直結する。22%の速度向上は、単なる待ち時間の削減というより、ワークフロー全体の快適さを変える可能性がある。 リアルタイムインタラクション プロンプトを入力してすぐ結果を得るようなリアルタイム用途にも対応しており、バッチ専用モデルではない点も実用的だ。 今月のMicrosoft Foundry Labsはそれだけじゃない 同月(2026年5月)のFoundry Labsアップデートでは、Image-2e以外にも注目リリースが3つある。 SocialReasoning-Bench 「AIエージェントはユーザーの利益のために行動できているか」を測定するオープンソースのベンチマークだ。カレンダー調整とマーケットプレイス交渉の2シナリオで、エージェントがユーザーの代理として「どれだけ価値を引き出せたか」(Outcome Optimality)と「どれだけ適切なプロセスを使ったか」(Due Diligence)を評価する。エージェントが他のエージェントと交渉する時代における「信頼性の指標」として興味深い取り組みだ。 MagenticLite / MagenticBrain / Fara1.5 Microsoft Researchが発表したオープンソースのエンドツーエンドエージェントスタックだ。 MagenticLite:チャットとブラウザが統合されたUIレイヤー。QEMU ベースのサンドボックス(Quicksand)でブラウザセッションとコード実行を分離しつつ、エージェントの推論過程を可視化し、重要なアクションには明示的な承認を求める設計 MagenticBrain:Qwen 3 8Bをファインチューニングしたオーケストレーターモデル。推論・コーディング・委任を担う Fara1.5:コンピューター操作モデルの新世代(4B/9B/27B)。Online-Mind2WeBベンチマークで前世代比ほぼ2倍のパフォーマンスを記録 実務への影響 — 日本のエンジニア・IT管理者にとっての意味 Azure環境での画像生成パイプラインの見直し 現在Azure上で画像生成パイプラインを構築・運用している場合、Image-2eへの移行を検討する価値がある。とくに月間の画像生成枚数が多い場合ほど、4倍効率化の恩恵はコスト削減に直結する。まずはFoundryのプレイグラウンドでMAI-Image-2と出力品質・速度・コストを比較してみるのが現実的な第一歩だ。 MagenticスタックのOSSとしての活用 MagenticLite/MagenticBrainはオープンソースとして公開されており、自社インフラ上に展開することができる。「AIエージェントを会社のインフラ上でコントロールしたい」というニーズが強い日本の大企業にとっては、特にFara1.5の「重要アクションは人間の承認を求める」設計が刺さるかもしれない。 SocialReasoning-Benchはエージェント品質評価の議論に使える 社内でAIエージェント導入を推進する際、「エージェントが本当にユーザーの利益を守って動くのか」という懸念は必ずあがる。SocialReasoning-Benchはその懸念に答えるための評価フレームワークとして、ベンダー比較や内製評価に応用できる。 筆者の見解 Image-2eが示すのは、「品質で勝つ」だけでなく「効率で勝つ」という開発の成熟だと思っている。モデルの品質スコアを競うフェーズから、本番環境で持続可能に動かすための効率最適化に移行しつつある流れは、エンタープライズ採用の加速という観点からも正しい方向性だ。 Microsoft Foundryというプラットフォームの強みは、こういった多様なモデル(画像生成、エージェント制御、コンピューター操作)を一つのエコシステムで統合して提供できる点にある。個々のモデルが絶対的な最強かどうかより、「使いたいモデルを安全・効率的に本番で動かせる基盤」としてのFoundryの価値は着実に積み上がっている。 Magenticスタックのオープンソース化も評価したい。エージェントの動作を透明化し、人間の介入ポイントを設計に組み込んでいる姿勢は、エンタープライズが安心してエージェントを導入するための条件として本質的に正しいアプローチだ。Microsoftが「最も多くのエージェントが安全に動作するプラットフォームを提供する競争では有利」という文脈で考えると、今月のFoundry Labsリリース群はその方向を着実に具体化したものと言えるだろう。 出典: この記事は MAI-Image-2-Efficient: New Faster Image Generation Model in Microsoft Foundry の内容をもとに、筆者の見解を加えて独自に執筆したものです。

May 29, 2026 · 1 min · 胡田昌彦

Azure Container Apps上のAzure FunctionsでカスタムKEDAスケールルールが利用可能に——60以上のスケーラーを自在に組み合わせ

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

May 29, 2026 · 1 min · 胡田昌彦

Microsoft Build 2026:WindowsがAIエージェント実行基盤に進化、Azure Agent Meshでオンプレ・クラウド横断の分散エージェント管理を実現

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が得意とする「エンタープライズのガバナンスをどう守るか」という問いへの回答として筋が通っている。 ...

May 29, 2026 · 1 min · 胡田昌彦

Azure Monitorパイプラインが3機能をパブリックプレビュー公開──Kubernetes環境のオブザーバビリティが本格強化

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

May 28, 2026 · 1 min · 胡田昌彦

Azure API Center ポータルが正式リリース(GA)——組織内APIカタログの一元管理・検索・文書化が本番運用可能に

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

May 28, 2026 · 1 min · 胡田昌彦

Azure SQL DatabaseとFabric SQLに「自動インデックス圧縮」がパブリックプレビュー入り:夜間メンテナンスジョブがついに不要になる

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. プレビュー中の動作検証を早めに ...

May 28, 2026 · 1 min · 胡田昌彦

MicrosoftがAzure Linux 4.0プレビューとAzure Container Linux GAを発表——AKSノードのディスク使用量を40%削減・5秒起動を実現

Microsoftは2026年のOpen Source Summit North Americaにて、クラウド最適化Linuxディストリビューション「Azure Linux 4.0」のパブリックプレビュー開始と、コンテナ特化OS「Azure Container Linux」の一般提供(GA)開始を発表した。 Azure Linux 4.0とは——CBL-Marinerの後継として大幅進化 Azure Linux(旧称: CBL-Mariner)は、MicrosoftがAzureインフラ・Xbox・エッジサービスで長年内部利用してきたLinuxディストリビューションだ。今回の4.0プレビューは、初めて顧客向けAzure VMに4.0ブランチを提供するものであり、節目となるリリースといえる。 カーネルのメジャーアップグレード Azure Linux 4.0はLinux 6.6 LTSカーネルを採用。前世代(3.0系)が使用していた5.15 LTSから大幅にジャンプしており、以下のメリットをもたらす: AMD EPYC / Intel Xeon最新世代のネイティブサポート Intel TDX / AMD SEV-SNPによる機密コンピューティング(コンフィデンシャルコンピューティング)対応 NVIDIAオープンソースカーネルモジュールのサポート強化でGPU接続が容易に AIワークロード向けには、リアルタイム推論に特化した「低レイテンシカーネル設定プロファイル」がVM作成時に選択可能となった。内部テストでは推論のテールレイテンシを最大30%削減できるとしている。 セキュリティ強化が標準搭載 Azure Linux 4.0のセキュリティ設計は注目に値する: SELinux強制モード(Enforcing Mode) デフォルト有効 不変ルートファイルシステム(Immutable Root Filesystem) オプション搭載 署名済みリポジトリによるソフトウェアサプライチェーンの保護 SBOM(ソフトウェア部品表) を全イメージに付与 Azure Security Centerとの統合による自動脆弱性スキャン 不要なパッケージを含まない最小構成と、ロックダウンされたカーネル設定により、攻撃対象領域を大幅に削減している。 パッケージ管理と開発者体験 パッケージマネージャはdnfに移行(スクリプト環境向けにtdnfも維持)。Microsoftが検証した3,000以上のパッケージが利用可能で、Python 3.12・Node.js 22・.NET 9などの最新ランタイムが含まれる。 新ツール「azl-shell」は、Azure Linuxのファイルシステムとカーネルインターフェースを再現するコンテナ化された開発環境を提供し、デプロイ前のローカルテストが可能になった。 Azure Container Linux GA——AKSに特化した不変OS AKSノード用の専用OS「Azure Container Linux」がGAとなった。コンテナワークロード以外のすべてを排除した、極限まで絞り込んだ設計が特徴だ。 主要スペック 項目 数値 ...

May 27, 2026 · 1 min · 胡田昌彦

Microsoft Foundry Labs 5月アップデート:AIエージェントの交渉能力を測るベンチマーク「SocialReasoning-Bench」など4機能を公開

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

May 27, 2026 · 1 min · 胡田昌彦

Azure週次アップデート#137:Microsoft SentinelとDefender for Endpointがランサムウェアへの予防的防御を実現、TLS 1.0/1.1廃止も本格化

Microsoftが2026年5月16日付けでAzureの週次アップデート第137号を公開した。今回はMicrosoft Sentinel、Defender for Endpoint、Copilot for Security、Purviewを中心に、セキュリティ運用と企業ガバナンスの実務に直結する変更が複数含まれる。 Defender for Endpoint:ランサムウェアへの「予防的防御」が登場 今回のアップデートで最も注目すべきは、Microsoft Defenderがランサムウェア攻撃を予防的(Predictive Shielding)に遮断した事例の公開だ。従来の検知・対応モデル(Detect & Respond)から、攻撃が実行される前にパターンを予測して先手を打つアプローチへのシフトを示している。 さらに、高価値資産(High-Value Assets)への選択的対応アクションも導入された。ドメインコントローラや重要業務サーバーなど、停止させると業務全体に波及する資産に対して、通常の検知とは異なる慎重かつ的確な対応を選択できる仕組みだ。「誤対応によるサービス停止」と「攻撃の放置」という従来のトレードオフに悩むSOCアナリストには、実運用を変える可能性のある実装だ。 Microsoft Sentinel:Azure Blob StorageでCCFコネクタのデータ統合を拡張 Microsoft SentinelでAzure Blob StorageをCCF(Common Control Framework)コネクタ経由で活用できる新機能がパブリックプレビューとなった。大量のログデータをコスト効率よく取り込む手段として、ストレージ経由の統合は現場での需要が高く、特にデータ保持コストを意識する環境では有効な選択肢になる。 また、Sentinel → Defender へのポータル移行が「アーキテクチャ上の判断」であることを明示したガイドラインも公開された。単なるUI変更ではなく、セキュリティ設計の見直しを伴う決断として捉えるべき内容だ。現在Sentinelで本番運用中のチームは、このガイドを参照した上でロードマップを組み直すことを強く推奨する。 Copilot for Security & Purview:M365 Copilotのデータを電子証拠保全の対象に 企業ガバナンスの観点で見逃せないのが、Microsoft 365 CopilotのインタラクションデータをPurview eDiscoveryで収集・保全できるようになったアップデートだ。訴訟対応・コンプライアンス調査においてCopilotの利用ログを開示する必要が生じるケースに備え、保全の仕組みを事前に整えておく体制が求められる。 CISOを対象としたAIセキュリティダッシュボードの活用ガイドも公開された。AI導入に伴うリスクをどう可視化し、経営層・セキュリティ管理者に提示するかの具体的な実装例として参考になる。 Defender for Cloud:WAF・Storage・Azure SQLの統合防御が整理 Azure WAFとDefender for Storage、Defender for Azure SQL Databasesを組み合わせた「Better Together」構成が整理・公開された。個別サービスをバラバラに運用するのではなく、Web層・ストレージ層・データベース層を連携した統合防御ラインとして設計するアプローチへの方向性が明確になっている。 Azure インフラ:SAP・PostgreSQL・Red Hatの動向 インフラ面では以下の更新も注目される。 SAP Sapphire 2026でのSAP on Azure新発表(エンタープライズAIとのSAP統合が焦点) PostgreSQLのAzure上での継続強化(コミットからクラウドデプロイまでの自動化) Red Hat Summit 2026でのAzure Red Hat OpenShiftにおけるAI対応強化 欧州のデジタル未来へのコミットメントとして、Azureインフラ拡張投資を明言 実務への影響 SOC・セキュリティ担当者へ: ...

May 26, 2026 · 1 min · 胡田昌彦

Azure Arc経由のWindows Server 2025ホットパッチが無償化——再起動なしでセキュリティパッチを適用できる運用が加速

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

May 26, 2026 · 1 min · 胡田昌彦

MicrosoftがAzure SQL Managed InstanceのFabricミラーリングをGA公開——ETLなしでリアルタイム分析が可能に

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

May 25, 2026 · 1 min · 胡田昌彦

Microsoft OneLakeがFabCon/SQLCon 2026で大幅強化——OracleとSAP DatasphereのミラーリングがGAに、SharePointやAzure Monitorも対象拡大

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開発が必要で、工数・保守コストが膨大だった。 ...

May 25, 2026 · 1 min · 胡田昌彦

AzureのAKS Fleet ManagerがマネージドCiliumクロスクラスターネットワーキングをプレビュー公開——複数AKSクラスター間の統合管理が現実的な選択肢に

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

May 25, 2026 · 1 min · 胡田昌彦

Microsoft Entra ID、外部MFAがGA(一般提供開始)——サードパーティMFAをConditional Accessに統合、2026年9月のCustom Controls廃止前に移行を

Microsoftは2026年3月、Microsoft Entra IDにおいてOpenID Connect(OIDC)標準に基づく外部MFA(External MFA)を一般提供(GA)として正式リリースした。これにより、組織が使用するサードパーティのMFAソリューションをConditional Access(条件付きアクセス)ポリシーと統合できるようになった。 外部MFAとは何か 従来のMicrosoft Entra IDでは、「Custom Controls」という機能でサードパーティ連携は可能だったものの、Conditional Accessポリシーとの統合が限定的で、細かなポリシー制御に制約があった。 外部MFAはこの制約を解消する。OIDCを通じてサードパーティのMFAプロバイダーと認証フローを統合し、Entra IDが認証要求を評価したうえでユーザーを外部プロバイダーに誘導する。検証後はEntra ID側で最終的なアクセス判断を下す——つまりポリシー制御の中枢はあくまでEntra IDに集約される設計だ。 設定と運用の仕組み 設定後、外部MFAはテナントの認証メソッドポリシーに「外部認証メソッド設定」として追加される。管理者は特定のユーザーグループへの適用・除外を柔軟に制御でき、組み込みの認証オプションと並べて管理できる。 外部プロバイダーが認証中にユーザー情報にアクセスするには、管理者の同意(Admin Consent)の付与が必要だ。この点はセキュリティ上の重要なポイントであり、実装前に社内ポリシーのレビューを行っておきたい。 MicrosoftのPrincipal Product Lead、Swaroop Krishnamurthy氏は「サインイン頻度とセッション制御を適切に調整すれば、再認証とユーザー生産性のバランスを取れる」とコメントしている。一方で「過剰な再認証はフィッシングリスクを高める可能性がある」とも警告しており、ポリシーの適切なチューニングが不可欠だ。 主なユースケース 外部MFAが特に力を発揮するのは以下のシナリオだ: M&A(合併・買収)シナリオ: 買収先企業が既存のMFAインフラを持っている場合、完全移行前の過渡期でもシームレスな認証統合が実現できる 規制・コンプライアンス要件: 特定のMFAソリューション使用を義務付けるセクター規制(金融・医療等)への対応 既存MFAインフラの維持: オンプレミスやSaaSで稼働中のMFAソリューションをEntra IDに統合し、ユーザー体験を統一する 【重要】2026年9月30日 Custom Controls廃止——移行は今すぐ着手を 既存のCustom Controls機能は2026年9月30日に廃止予定。現在使用中の設定は移行期間中は動作し続けるが、移行ガイダンスは廃止日前にMicrosoftが公開予定だ。 Custom Controlsを利用中の組織は早急に移行計画を立てることを強く推奨する。特に規模の大きい組織ではテスト・パイロット運用に相応の時間が必要になるため、「そのうちやる」は危険な先送りになる。 日本のエンジニア・IT管理者への実務インパクト 移行チェックリスト(Custom Controls利用中の場合) 現状把握: Entra IDの認証メソッドポリシーからCustom Controls設定を洗い出す 外部プロバイダーの対応確認: 利用中のサードパーティMFAベンダーが外部MFA(OIDC)に対応しているか確認 テスト環境での検証: パイロットグループを設定して動作検証を実施 ポリシーチューニング: サインイン頻度・セッション制御の再調整 本番移行と監視: ログ・サインインレポートで異常を早期検知 ゼロトラスト戦略との整合性 外部MFAはConditional Accessによる中央集権的なポリシー管理を維持したまま外部ソリューションと統合できる点で、ゼロトラストアーキテクチャとの相性が非常に良い。「認証はどのプロバイダーでも、ポリシー判断はEntra IDで一元化」という分離は、ネットワーク境界に依存しないIDベースのアクセス制御原則と自然に整合する。 筆者の見解 外部MFAのGA化は、Entra IDが企業のIDプラットフォームとして成熟していることを示す好例だと感じている。MFAの選択肢を外部に開きながらもポリシー制御をEntra IDに集約する設計は、M&Aや業界規制が絡む現実の企業IT環境をよく理解した実装だ。 ゼロトラスト推進の観点から言えば、「どのMFAを使うか」よりも「ポリシー評価と認可判断がどこで行われるか」のほうが本質的に重要だ。その中枢をEntra IDに置いたまま選択肢を広げられるのは理にかなっている。 ひとつ実務的な注意点を加えると、Admin Consentの管理とConditional Accessポリシーの再設計には相応の工数が伴う。Custom Controls廃止まで6ヶ月を切っているいま、日本の大規模エンタープライズが先送りするリスクは小さくない。廃止日という明確な締め切りがある以上、今月中に着手計画を立てることを強くすすめたい。Entra IDには正面から勝負できる実力が備わっている。その力を使いこなせるかどうかは、運用側の準備次第だ。 ...

May 25, 2026 · 1 min · 胡田昌彦

Microsoft Build 2026がサンフランシスコに移転——AIエージェント・信頼性・開発者プラットフォーム刷新を6月2〜3日に発表

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 各社とのポジションを差別化しようとしている。 ...

May 25, 2026 · 1 min · 胡田昌彦

MicrosoftがPostgreSQL 18に上流コントリビューション——DiskANNベクター検索統合とAzure HorizonDB発表で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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

May 25, 2026 · 1 min · 胡田昌彦

Azure Cosmos DBとLangChainが統合——「langchain-azure-cosmosdb」でRAG・エージェントAIのスタックを1本化

MicrosoftはAzure Cosmos DB for NoSQLをLangChain/LangGraphの単一永続化レイヤーとして活用できるPythonパッケージ「langchain-azure-cosmosdb」をリリースした。ベクターストア・セマンティックキャッシュ・チャット履歴・LangGraphチェックポインターを1つのデータベースで完結させ、RAGとエージェントAIアプリの構築を大幅に簡素化する。 AIエージェント開発者が抱える「スタック分散」問題 LangChainやLangGraphでAIエージェント・RAGアプリを構築する際、多くの開発者は次のような「スタック分散」に悩まされている。 ベクター検索:PineconeやQdrantなど専用のベクターデータベース チャット履歴:別のストレージバックエンド エージェント状態のチェックポイント:さらに別のシステム セマンティックキャッシュ:追加のインフラ 長期メモリ:もうひとつのボルトオン この「分散スタック」はコストだけでなく、セキュリティ境界の拡大・グローバル展開の困難さ・運用負荷の増大を招く。langchain-azure-cosmosdbはこの問題を一気に解消することを狙いとしている。 パッケージが提供する6つのインテグレーション 新パッケージは以下の6つのインテグレーションをすべてAzure Cosmos DB for NoSQL上で提供する。すべて同期・非同期の両バリアントが揃っている。 インテグレーション 主要クラス 機能概要 ベクターストア AzureCosmosDBNoSqlVectorSearch ベクター・全文・ハイブリッド検索 セマンティックキャッシュ AzureCosmosDBNoSqlSemanticCache LLMレスポンスのキャッシュによるコスト削減 チャット履歴 CosmosDBChatMessageHistory TTL付き会話履歴の永続化 LangGraphチェックポインター CosmosDBSaver マルチターンエージェントの状態保存 LangGraphキャッシュ CosmosDBCache グラフワークフローのノードレベルキャッシュ LangGraphストア CosmosDBStore 名前空間管理付き長期メモリ 認証はアクセスキーとMicrosoft Entra ID(Managed Identity)の両方をネイティブサポートする。 インストールはシンプルだ: 出典: この記事は Introducing langchain-azure-cosmosdb: Build Agentic Apps and RAG with One Database の内容をもとに、筆者の見解を加えて独自に執筆したものです。

May 25, 2026 · 1 min · 胡田昌彦

AI・テクノロジーの情報を発信しています

YouTube

AI・テクノロジーの最新トレンドを動画で配信中

note

技術コラム・深掘り記事を公開中