Azure

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

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

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

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

Microsoftは2026年5月15日、第7世代の汎用（D）・メモリ最適化（E）・ストレージ最適化（Lsv）仮想マシンシリーズをAzureで正式提供開始（GA）したと発表した。同時に、Azure Virtual Network Managerへのルール影響アナライザー追加、Service Bus PremiumのKoreaリージョン向け機密コンピューティング対応など、インフラ関連の複数アップデートが一斉に展開されている。 第7世代VM（D/E/Lsv7）：何が変わったか VMシリーズの整理 Azureの仮想マシンにはCPUアーキテクチャの世代更新に合わせて定期的に新シリーズが登場する。今回GAとなったv7世代の位置付けは次のとおりだ。 Dシリーズv7（汎用）: CPUとメモリのバランスが良く、Webサーバーや一般的なアプリケーションサーバーに適する Eシリーズv7（メモリ最適化）: 大量RAMが必要なDBサーバーやSAP、インメモリキャッシュ用途に最適 Lsvシリーズv7（ストレージ最適化）: NVMe SSDを大量に搭載し、高I/OのNoSQLや分析ワークロードに対応 世代が上がると同一コスト帯でのパフォーマンスが向上することが多い。v5やv6系を利用中の場合は、移行コストと効果を試算する価値がある。 移行時の注意点 新世代VMへの移行は基本的にリサイズ操作で完結するが、以下の点を事前に確認したい。 一部のレガシーエージェントや拡張機能がv7に未対応の場合がある Availability Setを使用中の場合はAvailability Zoneへの移行を検討する好機でもある 世代が上がっても同一SKU名で価格が変わるケースがあるため、価格/パフォーマンス比の再計算を必ず実施する Azure Virtual Network Manager：ルール影響アナライザーGA 「変更前にシミュレートする」価値 ネットワーク設定の変更は、エンタープライズ環境における最大のリスクイベントのひとつだ。NSGルールを変更したら本番トラフィックが遮断された、というインシデントは日本でも枚挙にいとまがない。 Azure Virtual Network Manager（AVNM）のルール影響アナライザーは、変更を適用する前に「何が影響を受けるか」を可視化する機能だ。具体的には次の情報を確認できる。 影響を受けるVNetおよびサブネットの一覧 既存のトラフィックフローへの影響範囲 ポリシーロールアウト前の変更検証レポート 日本のエンタープライズへの実務インパクト 日本の大規模エンタープライズでは、オンプレミス時代のネットワーク設計がそのままAzureに移植されているケースが多く、複雑なNSGルールやUser Defined Route（UDR）が積み重なった環境も珍しくない。AVNMのアナライザーは、そうした複雑な環境での変更管理（Change Management）の安全網として機能する。 Service Bus Premium：機密コンピューティングと拡張SLA Service Bus PremiumがKorea（韓国）リージョンで機密コンピューティングに対応したことに加え、可用性ゾーン対応リージョンでのSLAが4ナイン（99.99%）に拡大した。 日本リージョン（Japan East/Japan West）での機密コンピューティング対応については今回のアップデートに含まれていないが、SLA拡張はJapan Eastを利用するユーザーにも適用される可能性がある。最新のSLAドキュメントで確認しておきたい。 App Service & FastAPI：開発者体験の改善 SSHヘルパーエイリアス: Azure App Service for Linux上のPythonアプリへのSSH接続がエイリアスで簡略化。デバッグ時の接続手順が減り、診断速度が向上する FastAPIデプロイ簡略化: FastAPIアプリのApp Service for Linuxへのデプロイに必要な設定が削減。PythonモダンAPIフレームワークをAzureで本格活用したいチームには朗報だ Azure Monitor + Grafana：可視化統合の強化 AzureメトリクスをGrafanaで可視化するインテグレーションが強化されたほか、「MDASH」というコードネームの新しいダッシュボードツールが導入された。チーム横断での運用ビューの作成・共有が容易になる見込みだ。 ...

AnthropicのClaude Sonnet 4.6が、Microsoft Foundry（旧Azure AI Foundry）で正式に利用可能になった。最大100万トークンのコンテキストウィンドウと128Kトークンの最大出力を備え、Azure課金体系に統合されてMicrosoft Marketplaceから直接調達できる。 100万トークン・コンテキストが実務で意味すること コンテキストウィンドウ100万トークンは、単に「長い文章が入る」という話ではない。実務で具体的に変わるのは次のような場面だ。 大規模コードベースの一括解析: リポジトリ全体をコンテキストに載せ、リファクタリング方針やバグの根本原因を一度に問い合わせられる 大量ドキュメントの同時参照: 数百ページの仕様書・契約書・ログを分割せずに一括解析できる 複数APIドキュメントを参照しながらのコード生成: 連携先システムのドキュメントを全部読ませた上でコードを生成できる 128Kの最大出力も重要だ。エージェントが複数ステップのワークフローを一度の推論でまとめて出力できるため、細かく刻む必要がなくなり、エラーの連鎖も減る。 Microsoft Foundryとの統合が日本企業に刺さる理由 Azure課金統合とMarketplace経由の調達は、日本の大企業環境では特に効いてくる。 多くの日本企業では、外部SaaSの新規契約には購買部門の承認フローが必要で、外部APIの直接利用がセキュリティポリシーで制限されているケースも多い。Microsoft Marketplaceであれば既存のAzure Enterprise Agreementの枠内で処理できることが多く、調達の障壁が大幅に下がる。 さらに、Microsoft Entra IDによる認証・認可、Azure Private Linkによるネットワーク分離、Azure Monitorによるログ収集——これらの既存ガバナンス基盤がそのまま使える。「新しいAIを使いたいが、セキュリティレビューが通らない」という壁が一段低くなる。 エージェント・ワークフロー設計への影響 Claude Sonnet 4.6はコーディングとエージェント処理に特化した設計とされており、Microsoft FoundryのオーケストレーションサービスであるPrompt FlowやAzure AI Agent Serviceと組み合わせることで、実用的な自律エージェント構築が現実味を帯びてくる。 実務で想定されるユースケース： コードレビューエージェント: リポジトリ全体をコンテキストに載せてPRの品質評価と修正提案を自動化 ドキュメント分析エージェント: 大量の社内文書・契約書を解析してリスク検出や要約を実行 システム統合エージェント: 複数のAPIドキュメントを同時参照しながら連携コードを自動生成 実務への影響——明日から動けるポイント 既存のAzureサブスクリプションで検証可能: 新規契約不要でMicrosoft Marketplaceから有効化できる セキュリティ設定はAzureの標準資産を流用: Private Endpoint、Managed Identity、RBACをそのまま適用できる コスト管理はAzure Cost Managementで一元化: 他のAzureリソースと同じ画面で使用量を把握できる モデル切り替えの自由度: 用途に応じてGPT-4oやその他のFoundryモデルと使い分けられる 筆者の見解 Claude Sonnet 4.6のMicrosoft Foundry対応は、私がずっと主張してきた方向性の具体化だ。「Microsoft基盤はそのままに、その上で動かすAIを用途別に選ぶ」——この考え方が製品として形になってきた。 Microsoft Entra IDをエージェントの管制塔として使い、その上でAnthropicやOpenAIのモデルを状況に応じて使い分ける。これが企業市場でのMicrosoftの本当の強みだと思っている。AIの性能競争でどのベンダーが勝つかは誰にもわからない。しかし、AIを安全にガバナンスを保ちながら動かすプラットフォームを提供するという競争では、Microsoftには明確な地の利がある。 この方向性をもっと積極的に押し出してほしいというのが正直な期待だ。Azure AI Foundry自体の使い勝手——特にモデル切り替え時の設定引き継ぎやエージェントのデバッグ環境——はまだ磨き込みの余地がある。良い素材が揃ってきた今だからこそ、プラットフォームとしての完成度を上げることに力を入れる段階だろう。実力は十分にあるのだから、あとは仕上げ次第だ。 ...

Microsoftは、Azure Virtual Desktop（AVD）のハイブリッド展開オプションを大幅に強化し、Azure Arcを介してオンプレミスの既存インフラ——Nutanix AHV、VMware vSphere、物理Windowsサーバー——上でAVDセッションホストを稼働させる「Azure Virtual Desktop Hybrid」の技術詳細を公開した。これまでAzure VMまたはAzure Localが前提だったAVD展開の選択肢が、企業の既存資産を活かした構成にまで広がる。 Azure Virtual Desktop Hybridとは何か Azure Virtual Desktop（AVD）はMicrosoftのクラウドベースVDI（仮想デスクトップ基盤）サービスだが、これまでセッションホストはAzure VMかAzure Local（旧Azure Stack HCI）に限られていた。今回のAVD Hybridはこの前提を崩し、Azure Arcを管理プレーンとして使うことで、オンプレミスの任意のインフラ上にAVDセッションホストを配置しつつAzureから一元管理できる構成を実現する。 対応プラットフォームは以下の4種類: Azure Local（旧Azure Stack HCI） Nutanix AHV VMware vSphere 物理Windowsサーバー NutanixとVMwareへの対応は特に注目に値する。日本の大手企業や金融機関ではこれらのハイパーバイザーが広く採用されており、既存資産の有効活用につながる。 Azure Arcが果たす役割 AVD Hybridの核心はAzure Arcだ。Azure Arcはオンプレミスやマルチクラウド環境をAzureの管理プレーンに接続するサービスで、今回の構成ではオンプレミスのAVDセッションホストに対して以下を可能にする: Azure portalからの一元管理 Azure MonitorおよびLog Analyticsによる監視 Microsoft Entra IDとの統合認証の維持 Intuneによるポリシー管理の適用 物理的にはオンプレミスに存在するセッションホストが、管理体験としてはフルクラウドAVDと同等になる点が最大の特徴だ。 なぜこれが重要か AVD Hybridが日本のIT現場で意味を持つ理由は主に2点ある。 規制対応とコスト効率の両立: 金融・医療・公共セクターではデータを国内オンプレミスに置くことが求められる場面がある。一方でVDIの管理コストをクラウド活用で削減したいニーズも強い。AVD Hybridはこの二律背反を解消するアーキテクチャだ。 脱VPNへの近道: 従来のオンプレVDIは社内VPN接続が前提だったが、AVDはReverse Connection方式を採用しユーザー側からの受信接続を不要とする。ゼロトラスト原則に自然に適合するアクセスモデルだ。 実務での活用ポイント 既存Nutanix/VMware環境の段階活用 ハードウェア更改タイミングを待たずに導入できる。まずAzure Arcエージェントを既存VM上に展開してAVD Hybridセッションホストとして登録し、管理をAzureに寄せていくアプローチが現実的だ。 段階的クラウド移行設計 オンプレ資産を維持しながら新規ワークロードはAzure側AVDで受ける構成にすることで、フルクラウド移行への段階的ロードマップを描きやすくなる。 コスト試算の注意点 セッションホスト自体はオンプレのためVM分のAzureコストは発生しないが、Azure ArcのライセンスとAVDアクセスライセンス（SAL）は別途必要になる。導入前にTCOを丁寧に計算することが欠かせない。 ...

Microsoftは2026年5月1日より、Azure Service Bus PremiumをAvailability Zone（AZ）対応の全リージョンで99.99%のSLAを提供開始した。従来の99.9%から一段階上の信頼性保証へ格上げされ、金融・医療・EC系など厳格なSLA要件を持つシステムへの採用ハードルが大幅に下がる。 99.9% と 99.99% ——たった0.09%が意味する現実 数字だけ見ると微差に見えるが、年間ダウンタイムの許容時間に換算すると話は変わる。 SLA 年間許容ダウンタイム 99.9% 約8時間44分 99.99% 約52分 実に10倍近い差だ。金融機関の決済処理や製造ラインのリアルタイムイベント処理では、1分単位のダウンが直接的な損失につながる。「Service Busは99.9%だから社内規定上採用できない」という判断が覆るケースが出てくるだろう。 Availability Zone冗長化が支える高可用性 Azure Availability Zoneとは、同一リージョン内に存在する物理的に独立したデータセンター群だ。電源・冷却・ネットワークがそれぞれ分離されており、1ゾーンで障害が起きても他のゾーンには影響しない設計になっている。 Service Bus Premiumはこの複数ゾーンにまたがる冗長化を活用し、単一障害点を排除した構成を取る。今回の99.99% SLAはAZ機能が有効なすべてのリージョンで適用される。 Azure Service Bus Premium の主な特徴 StandardとPremiumの2ティアを持つService Busのうち、Premiumが選ばれる理由は可用性だけではない。 専用メッセージングユニット: マルチテナント環境ではなく専用リソースを使用。予測可能なスループットを確保 大規模メッセージ対応: 最大100MBまでのペイロードをサポート VNet統合: プライベートエンドポイントやVNetサービスエンドポイントに対応し、ネットワーク分離を実現 Geo-Disaster Recovery: 別リージョンへのフェイルオーバーをサポート 高スループット: 本番ワークロード向けのパフォーマンス保証 今回のSLA向上は、これらの機能に加えてもう1つの選定理由が追加されたことを意味する。 実務への影響と活用ポイント 既存ユーザーは追加設定不要 見落としてはならない点として、既存のPremiumユーザーはAZ対応リージョンで稼働していれば、追加設定なしで99.99% SLAが自動適用される。移行作業もコスト増もなく信頼性が上がるのは素直にありがたい。 採用を見直す価値があるシステム 以下のようなユースケースでは、今回の変更を機に評価を再検討してほしい。 金融機関の決済・振込メッセージング基盤 ヘルスケア系のアラート・通知パイプライン ECサイトの注文処理・在庫連携フロー 工場・製造現場のリアルタイムイベント処理 StandardからPremiumへの移行ROIを再計算する StandardはPremiumに比べてコストが低いが、99.99% SLAで守られるビジネス価値を加味したROI試算を行う価値がある。特に「障害時の損失コスト × 年間期待ダウンタイム差」で計算すると、多くのミッションクリティカル系システムでPremiumが正当化される。 筆者の見解 SLAの数字を「どうせ大差ない」と流してしまうエンジニアもいるが、エンタープライズ調達の現場では話が違う。要件定義書やベンダー評価シートにSLAの閾値が明記されている案件では、99.9%と99.99%の差が採用の可否を左右することが実際にある。その壁を取り除いたことの意義は小さくない。 Azureのインフラ基盤としての信頼性は引き続き高い。Service Busのような基盤コンポーネントを地道に強化するのは、プラットフォームとしての完成度を高める正しいアプローチだ。華やかなAI系の発表が続く中で、こういった堅実な改善こそが日本の大規模エンタープライズ案件での競争力を支えているという側面もある。 疎結合アーキテクチャへの移行を検討している組織にとって、「メッセージングの土台が99.99%で守られる」という事実は、その設計判断を後押しする材料になる。Event GridやEvent Hubsとの使い分けを再整理しながら、Service Bus Premiumをアーキテクチャの中核に据えるシナリオを検討してみてほしい。 ...

Microsoftは、Azure上の旧世代VM（仮想マシン）系列を対象としたReserved VM Instances（リザーブドインスタンス）の新規購入および更新を、2026年7月1日をもって終了すると発表した。Av2・Bv1・Dv2・Fsv2・Gシリーズなどのレガシー系列を予約割引で利用している企業は、移行計画を早急に立てる必要がある。 廃止されるVM系列と影響範囲 今回の廃止対象となる主なVM系列は以下の通りだ。 Av2シリーズ（汎用、旧世代） Bv1シリーズ（バースト可能） Dv2 / Dsv2シリーズ（汎用） Dv3 / Dsv3シリーズ（汎用） Fsv2シリーズ（コンピューティング最適化） Gシリーズ（メモリ・ストレージ最適化） 2026年7月1日以降、これらの系列に対するReserved VM Instancesの新規購入と既存予約の更新が停止される。ただし、すでに購入済みの予約は契約期間終了まで継続して有効となるため、即座にすべての割引が失われるわけではない。 移行先として推奨される最新VM系列 Microsoftが推奨する移行先は、最新世代のVM系列だ。 旧系列 推奨移行先 Dv2 / Dv3 Dv5 / Dsv5シリーズ Bv1 Bsv2シリーズ Fsv2 Fasv6 / Falsv6シリーズ Gシリーズ Mv3シリーズ 最新世代のVMは旧世代と比較してコストパフォーマンスが大幅に向上しており、同等またはそれ以上のスペックをより低いコストで提供できるケースも多い。特にDv5・Ev5系列はIntelの第3世代もしくはAMD EPYCプロセッサを採用し、ネットワーク帯域やストレージスループットでも世代間の差は顕著だ。 実務への影響：日本のエンジニア・IT管理者が今やるべきこと 1. 現在のリザーブドインスタンス棚卸し Azureポータルの「予約」ブレード、またはAzure Cost Management + Billingから、対象VM系列のReserved Instancesを確認しよう。有効期限と系列名を一覧化し、7月1日以前に期限切れを迎えるものを優先的に対応する。 2. 更新前に移行を完了させる 既存の予約が2026年7月1日以降に満了する場合、更新が不可能になるため、期限到来前に新世代VMへのリソース移行と新規予約の購入を完了させる計画が必要だ。 3. Azure Migrate・Azure Advisorを活用する Azure Advisorは旧世代VMに対して自動的に移行提案を出すことがある。Azure Migrateを使えば、依存関係のマッピングや移行後のコスト見積もりも自動化できる。これらを活用して影響範囲と工数を早めに把握しよう。 4. Savings Planとの使い分けを検討 Reserved VM Instancesは特定のVM系列・リージョンに縛られるが、Azure Savings Planはより柔軟に適用できる。今後も頻繁にVMサイズを変更する予定があるなら、Savings Planへの切り替えも選択肢の一つだ。 筆者の見解 Azureを長く使っていると、こうしたVM世代交代のアナウンスは定期的に届く。2026年7月という期日は一見余裕があるように見えるが、本番環境のVM移行は検証・承認・メンテナンスウィンドウの確保など多くのステップが必要で、実際に動き出してみると時間はあっという間に過ぎる。 正直なところ、レガシーVM系列を今も使い続けている企業の中には、「動いているから触らない」という判断でここまで来たケースも少なくないだろう。だが今回のようなReserved Instancesの廃止は、コスト最適化の恩恵が受けられなくなるだけでなく、将来的なVM系列廃止の予告でもある。Azureはこういったアナウンスを段階的に行う傾向があり、今動いている計算機が突然使えなくなるわけではないが、「標準的で再現性のある構成」を維持するためにも、推奨世代のVMに揃えておくのが正しい道だ。 ...

MicrosoftがAI特化型バイオテクスタートアップを対象に、Azure基盤上で創薬・ゲノム解析・臨床試験データ管理を一元化する「2026 Operating Model Blueprint」を公開した。Microsoft for Startups プログラムを通じて提供されるこのリファレンスアーキテクチャは、ウェットラボ中心だった従来の創薬プロセスをコンピュータ主導のパラダイムへ転換する具体的な青写真として注目されている。 計算資源の制約を崩す「クラウドファースト創薬」 タンパク質折り畳みや分子ドッキングシミュレーションには、数百台のGPUを数週間稼働させるのが当たり前になりつつある。オンプレミスのHPCクラスターを持てないスタートアップにとって、クラウドの弾力的なスケーリングは「あれば便利」ではなく「なければ始まらない」インフラだ。 今回のブループリントでは、NVIDIA H100 および AMD Instinct クラスターと、Azure Machine Learning・Azure AI Foundry を組み合わせた参照構成が示されている。分散学習最適化フレームワーク DeepSpeed や、パートナーシップ経由でエコシステムに組み込まれる BioNeMo プラットフォームとの統合も明示されており、大規模バイオインフォマティクスモデルの構築コストを現実的な水準に引き下げることを目指している。 マルチモーダルデータと「ポリシー・アズ・コード」ガバナンス バイオテックデータの難しさは、その多様性と規制の厳しさにある。クライオ電子顕微鏡（cryo-EM）の画像スタック、全ゲノム配列、電子カルテ、ウェアラブルからのリアルワールドデータ――これらを一つのプロジェクトに統合しながら、GDPR・HIPAA・新興AIガバナンス規制に同時準拠するのは長年の難題だった。 ブループリントは Microsoft Purview を中心としたデータ分類・系譜追跡の自動化と、AIワークロード向け「ポリシー・アズ・コード」の概念を組み合わせる。たとえば「欧州患者データで学習したモデルを、明示的な同意なしに米国クラスターでファインチューニングしない」というルールをコードとして定義・強制できる設計だ。ロールベースアクセス制御と顧客管理暗号化キーを前提として、その上位レイヤーでAI固有のコンプライアンスを実現する構造は、バイオテック以外の規制産業にも応用が利く。 自律エージェントが「実験設計」まで担う未来 ブループリントが最も野心的なのはエージェンティックワークフローの部分だ。AutoGen と Semantic Kernel で構成された自律エージェント群が、データアクセスの交渉・エフェメラルコンピュートのプロビジョニング・実験設計の提案まで自律的に実行する構想が示されている。タンパク質-リガンドドッキングシミュレーションの収束が遅い場合にエージェントが自動でGPUを追加するシナリオは、研究者が手動でETLジョブを操作する時代からの明確な決別を示している。 実務への影響――日本のバイオテック・IT担当者へ バイオテックスタートアップ・研究機関向け このブループリントは「Azure構成を決める際のチェックリスト」として直接活用できる。データガバナンス周りはどの組織も悩みどころのため参照価値が高く、AMED（日本医療研究開発機構）助成を受けた研究プロジェクトでも適用を検討する価値がある。Azure AI FoundryとPurviewの組み合わせは、論文再現性（Reproducibility Crisis）の対策としても機能する点も見逃せない。 エンタープライズIT・Azureアーキテクト向け 「ポリシー・アズ・コード」の考え方はバイオテック専用ではない。金融・製造・医療など、データ規制が複雑な業界全般に応用できるアーキテクチャパターンだ。セキュリティガバナンスの自動化を検討中のアーキテクトは、このブループリントを自業種向けに読み替える価値がある。 筆者の見解 バイオテック×AIという組み合わせは「大きな夢を語りやすいが実用化は遠い」カテゴリに見られがちだ。しかし今回のブループリントが示しているのは夢物語ではなく、NVIDIA H100の実際の可用性、DeepSpeedとの具体的な統合、Microsoft Purviewによるデータ系譜管理など、すでに動いている技術を組み合わせた実践的な設計図だ。 Azureが本来得意とする「規制対応×エンタープライズガバナンス×ハイブリッド構成」の組み合わせが、ここでは正面から活きている。Microsoft Foundry経由で最適なAIモデルを選んで使いながら、基盤としてのAzureが持つ認証・コンプライアンス・スケーリングの強みを最大限に引き出す設計思想は、この領域でMicrosoftが発揮できる本来の強みだと思う。 日本での普及には時間がかかるだろう。ライフサイエンス系のスタートアップエコシステム自体が米国・欧州に比べて薄く、このブループリントが日本語圏でほとんど報じられていないことがその証左だ。ただ、AMEDや大学発ベンチャーがこういった参照アーキテクチャを使いこなせるようになれば、計算創薬での国際競争力という文脈でAzureが自然な選択肢になる道筋が見えてくる。情報を追うだけでなく、実際に試して成果を出す組織が最終的に勝つ。 出典: この記事は Microsoft Azure Targets AI-Native Biotech Startups with 2026 Operating Model Blueprint の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftとSAPは、年次カンファレンス「SAP Sapphire 2026」において、エージェントAIを中核とした協業強化を発表した。SAP独自のAIエージェント「SAP Joule」がAzure AIと深く統合されることで、長年「記録のシステム（System of Record）」として機能してきたERPが、自律的に業務を実行する「行動のシステム（System of Action）」へと進化する——。この転換点が今年のSapphireの最大のテーマだった。 ERPが「考えて動く」ようになるとはどういうことか 従来のERP（Enterprise Resource Planning）は、発注・受注・在庫・会計といった企業活動を「記録する」ことが主な役割だった。ユーザーがデータを入力し、レポートを参照し、意思決定は人間が行う——という流れが前提だ。 エージェントAIはこの構造を根本から変える。SAP JouleはSAPの各業務アプリケーションに組み込まれたAIエージェントであり、今回Azure AIとの連携が強化された。 具体的には、Jouleが在庫状況を検知し、発注候補先を自律的に評価し、承認ルールに沿って発注を実行する——という一連のプロセスを、人間の介在なしに処理するシナリオが想定される。「AIに聞いたら答えが返ってくる」という従来のCopilot的な使い方ではなく、「AIが業務をやりきる」という段階への移行だ。 AzureがRISE with SAPの最大ホスティング基盤として確立 今回改めて強調されたのは、AzureがRISE with SAP（SAPのクラウド移行プログラム）における最大のホスティング基盤であるという位置づけだ。 RISE with SAPはS/4HANAへの移行を支援するパッケージ型のクラウドプログラムで、日本の大手製造業・商社・金融機関でもAzure上への移行が急増している。そのインフラにAzureを選び、頭脳にJoule（Azure AI連携済み）を組み込む構成は、今後のエンタープライズAIの標準的なアーキテクチャの一つとなっていくだろう。 実務への影響——今すぐ考えるべきこと RISE with SAP on Azureを推進中の組織へ すでにAzure上でSAP環境を運用しているなら、SAP Jouleの評価を早期に開始することを勧める。Jouleはすでにサプライチェーン・調達・人事・財務領域でエージェント機能を提供しており、特定業務プロセスでのPoC（概念実証）はすぐに着手できる状況にある。 エージェントのID管理にEntra IDを活用する エージェントが業務を自律実行するということは、「エージェント自身のID管理」が重要課題になることを意味する。Microsoft Entra IDのワークロードID機能でSAP Jouleエージェントのアクセス範囲を精密に制御し、Just-In-Time（JIT）の権限付与を組み合わせることが、セキュアなエージェント運用の基本になる。 S/4HANA移行プロジェクトにエージェント設計を組み込む 現在S/4HANA移行を計画中であれば、移行後のアーキテクチャにエージェントAIの導入余地を最初から組み込んでおくことを推奨する。後から「エージェントを足す」設計変更は想像以上にコストがかかる。 筆者の見解 この発表が示す方向性は、Microsoftの本質的な強み——「最強のAIを作る競争ではなく、最も多くのエージェントが安全に動けるプラットフォームを作る競争」——に直結している。 SAP JouleがAzure AIと連携し、Entra IDがエージェントの身元を管理し、AzureがRISE with SAPの基盤として機能する。このスタックが整うと、企業は「どのAIモデルが賢いか」という選択の前に「どのプラットフォームでエージェントを安全に動かせるか」という問いを解かなければならなくなる。その答えとしてAzureが選ばれ続けているのは、地道な戦略の積み重ねの結果だと評価している。 一方で、ERPのエージェント化が本当に業務価値を生むかは、プロセス設計次第だ。「自動化できる」と「自動化すべき」は別の問いであり、特に例外処理や多段階承認が複雑な日本の商習慣では、エージェントに委ねる範囲の設計が実装の成否を分ける。日本の大手SAPユーザー企業がこの枠組みをどう使いこなしていくか、実際のユースケースの蓄積を注目している。 出典: この記事は Microsoft and SAP Sapphire 2026: Agentic AI Turns ERP Into a System of Action の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはAzure FoundryとAIを組み合わせた製造業向け機能「Copilot for Factories」を2026年5月13日に発表した。工場現場における希少な専門知識の枯渇や、生産ラインのボトルネックといった長年の課題を、ソフトウェアとAIの力で解決することを狙った取り組みだ。 Copilot for Factoriesとは何か 「Copilot for Factories」は、Microsoft Azure Foundry（旧Azure AI Foundry）を基盤として動作する製造業特化型AIソリューションだ。単なるチャットボットではなく、工場の生産データ・設備ログ・品質記録といった現場データと連携し、以下のようなシナリオをAIが支援する。 主なユースケース 予知保全の高度化 PLC（プログラマブル・ロジック・コントローラ）や各種センサーから収集したデータをAzure IoT Hub経由でリアルタイム分析し、設備の異常兆候を事前に検知する。従来は熟練エンジニアが「音」や「振動の感覚」で判断していた領域をAIが肩代わりすることで、ベテラン技術者への依存度を下げる。 品質管理の自動化 製造ラインのカメラ映像や検査ログをAIが分析し、不良品の検出精度を向上させる。Azure Digital Twinsと連携することで、仮想モデル上で「どの工程で不良が発生しやすいか」を事前シミュレーションすることも可能だ。 ボトルネックの特定と工程最適化 生産ラインの各工程のサイクルタイムや在庫データをAIが横断分析し、どこがスループットの足を引っ張っているかを可視化する。現場の「なんとなく遅い気がする」という感覚的な判断をデータドリブンに置き換える。 暗黙知のデジタル化 熟練作業員の手順書・マニュアル・過去のトラブル対応ログをAIに学習させ、新人や別工場のスタッフが同等レベルのガイダンスを受けられる環境を構築する。「属人化した職人技」をソフトウェアとして組織資産に変える、というコンセプトだ。 なぜ今、製造業にAIなのか 製造業は長年、「デジタル化が最も遅れた産業」の一つとして語られてきた。しかしその状況が急速に変わりつつある背景には、2つの構造的な危機がある。 熟練技術者の大量退職 団塊の世代の退職が進む日本の製造現場では、「30年のキャリアを持つベテランが持っている知識」が組織から失われるリスクが現実化している。後継者育成には10年単位の時間がかかるが、AIを使えばその知識の「エッセンス」を比較的短期間でシステムに組み込むことができる。 競争力の維持と自動化の加速 ドイツ・中国・韓国の製造業がスマートファクトリー化を急ピッチで進める中、日本の製造業が従来の方法論に固執し続けることは競争力の観点から限界に近づいている。Copilot for Factoriesは、既存の製造設備（レガシーシステムを含む）にAIを「後付け」で追加できる設計になっており、全面刷新なしにDXを進められる点が現実的だ。 実務への影響——日本のエンジニア・IT管理者が知っておくべきこと Azure環境を持っている企業はすぐに評価を Azure IoT HubやAzure Digital Twinsをすでに活用している企業であれば、Copilot for Factoriesとの統合障壁は低い。まずAzure Foundry上のプレビュー機能として確認し、自社の製造ラインのどのユースケースに適用できるかを評価することを勧める。 データ基盤の整備が先決 AIは良いデータなしには機能しない。「センサーは付いているが、データがサイロ化している」「紙の記録しかない」という工場では、まずデータ収集・統合基盤の整備が優先課題となる。Azure Data FactoryやMicrosoft Fabricを組み合わせたデータパイプラインの構築を検討する価値がある。 SAP・Siemens・Rockwellとの連携確認を Microsoftは主要な製造業ERPおよびOT（Operational Technology）ベンダーとのコネクタを継続的に拡充している。自社の基幹システムが対応リストに含まれているかを確認することが、導入検討の最初のステップとなる。 セキュリティ設計を初期から組み込む OT環境とIT環境をつなぐことは利便性を高める一方、セキュリティリスクも拡大する。Microsoft Entra IDを活用したゼロトラスト設計を前提とし、工場ネットワークへのアクセス制御をJust-In-Time（JIT）方式で実装することを強く推奨する。「とりあえずつないでみる」は工場では許されないリスクだ。 筆者の見解 Microsoftが製造業にフォーカスするのは、理にかなっている。エンタープライズ顧客の多くが製造業であり、Azure・M365・Teams・Dynamics 365のフルスタックを活用できる領域だからだ。Copilot for Factoriesはその統合プラットフォーム戦略の延長線上にある。 とりわけ「暗黙知のデジタル化」というコンセプトは、日本の製造業が抱える深刻な課題に直撃する提案だと感じる。熟練技術者の退職問題は、どの現場でも頭を抱えているテーマだ。ここに具体的なソリューションを提示できるなら、Microsoftにとって大きな差別化要素になりえる。 一方で、Azure Foundryというプラットフォームの力を最大限に活かすには、AIモデルの選択肢の充実が不可欠だ。Microsoftはプラットフォームとしての強さを持っているのだから、その上で動作するAIの質についても、妥協せずに追求してほしい。インダストリアルAIは汎用的なアシスタントとは異なり、専門ドメインの精度が問われる世界。ここは「最良のAIをプラットフォーム上で動かす」という戦略を、ぜひ本気で実行してほしいと思う。 製造業のDXはまだ道半ばだが、AIがこの分野に本格参入してきたことで、次の5年間で現場の景色は大きく変わるはずだ。Copilot for Factoriesがその変化を加速する鍵の一つになれるか、今後の展開を注視したい。 出典: この記事は Microsoft May 13 2026 Industrial AI: Azure Foundry Copilot for Factories の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft の Azure Kubernetes Service（AKS）が Kubernetes v1.35 の一般提供（GA）を開始し、Ubuntu 24.04 LTS をデフォルトのノード OS として採用。あわせて Containerd 2.0 が標準搭載され、コンテナ基盤の根幹が刷新された。 何が変わったのか Ubuntu 24.04 LTS がデフォルトに昇格 これまで AKS のノード OS として広く使われてきた Ubuntu 22.04 LTS に代わり、Ubuntu 24.04 LTS（Noble Numbat） がデフォルトになった。Ubuntu 24.04 はカーネル 6.8 系を採用しており、以下の点が強化されている。 カーネルハードニングの強化: Seccomp プロファイルや namespace 分離の改善が含まれ、コンテナ逃げ出し攻撃に対する防御層が厚くなった より長いサポートライフサイクル: LTS 版として 2029 年 4 月まで標準サポート、さらに ESM（Extended Security Maintenance）で 2034 年まで延長可能 最新ハードウェア対応: GPU ノードや ARM ベースの Ampere インスタンスとの親和性が向上 Containerd 2.0 の標準搭載 コンテナランタイムが Containerd 1.x 系から Containerd 2.0 に更新された。主な恩恵は次のとおり。 ...

Microsoft Azure AI Foundryは、Fireworks AIとの統合をパブリックプレビュー段階に引き上げた。これにより、Kimi K2.6やDeepSeek V4 Proなどの最新オープンモデルが、Azureのエンタープライズグレードのセキュリティ・ガバナンス環境の中で利用可能となった。Microsoft Build 2026での実機デモも予告されており、今後の機能拡充が期待される。 Fireworks AIとは Fireworks AIは、高速・低コストなオープンモデルの推論サービスで実績を積んできたAIインフラ企業だ。スタートアップ向けのAPI提供からスタートし、今回Azure AI Foundryへの統合によってエンタープライズ市場への本格参入を果たした形となる。 利用可能なモデルと料金 今回のパブリックプレビューで登場した主要モデルは以下の通り。 Kimi K2.6（複雑推論・エージェントワークロード向け） 価格：$0.95/1Mトークン（インプット） 複雑な多段階推論やエージェント型AIの基盤モデルとして設計 企業のワークフロー自動化タスクへの適性が高い DeepSeek V4 Pro コスト効率の高さで注目されている大規模言語モデル コーディング・データ分析・多段階推論に強みを持つ これらのモデルはAzure AI Foundryの管理画面から直接呼び出せるため、既存のAzure環境を維持しながらモデルの選択肢を大幅に拡張できる。 なぜこれが重要か 従来、エンタープライズ企業がオープンモデルを本番環境で使おうとすると、「セキュリティ・コンプライアンスの担保」「SLAの確保」「スケーラビリティの検証」という三重の壁が立ちはだかっていた。 Azure AI Foundry経由でFireworks AIのモデルを呼び出せるということは、MicrosoftのSLA・セキュリティポリシー・請求管理の傘の下で、多様なモデルを使い分けられることを意味する。 特に日本の大手企業・金融・官公庁系では、クラウド上のAIモデル利用に対するコンプライアンス審査が厳しい。「Azure上で動いているから」という文脈は、社内稟議を通す上で依然として強力な説得材料になる。 実務での活用ポイント エンジニア・アーキテクト向け タスクの性質に応じてモデルを使い分ける設計が現実的になった。Kimi K2.6を推論エージェントのバックエンドに配置し、より単純なタスクには安価なモデルをルーティングする構成などが考えられる。Azure AI Foundryのモデルルーティング・フォールバック機能と組み合わせることで、コストと品質のバランスをコード変更なしに調整できる点も実用的だ。 IT管理者・調達担当向け 既存のAzureエンタープライズ契約の範囲内で精算できる可能性が高く（詳細は契約担当に要確認）、新たなベンダー審査が不要になるケースが多い。Azure Portalから一元管理できる点も運用負荷の軽減につながる。 筆者の見解 Azure AI Foundryがオープンモデルのマーケットプレイスとして機能し始めているこの流れは、Microsoftの戦略として正しい方向性だと思う。 「最も賢いモデルを自社で作り続ける競争」だけでなく、「最も多くのモデルが安全に動作するプラットフォームを提供する競争」でも戦うという二正面作戦は、Azureというインフラ、Microsoft Entra IDという認証基盤、エンタープライズとの長年の信頼関係を強みとするMicrosoftにとって理にかなっている。 現実的に考えると、多くの日本企業は「どのモデルが最も賢いか」よりも「どのモデルがAzureで使えるか」で意思決定をしている。その意味で、Foundryへの外部モデル統合は地味に見えて、実はかなり実効性のある施策だ。 あとはユーザーとしてシンプルに「使いやすいか」を問いたい。モデルの選択肢が増えることは歓迎だが、選択肢が多すぎると現場が混乱する。Microsoft Build 2026でのデモが、どこまでエンタープライズの実ユースケースを具体的に示せるか——そこで本当の手応えを確認したいと思っている。 出典: この記事は Open Model Inference at Scale on Foundry: What’s New with Fireworks AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Azure SDK チームが、Azure Functions の Service Bus トリガーにおける指数バックオフ（Exponential Backoff）とサーキットブレーカー（Circuit Breaker）の実装パターンを公式サンプルとして公開した。分散システムにおけるリトライストームを制御し、依存サービスの保護と障害時の段階的縮退（Graceful Degradation）を実現する。 なぜ今これが必要か Azure Functions は受信メッセージに対してスケールアウトを自動的に行う。これは高スループットを実現する強みだが、裏を返せばダウンストリームの依存サービスへ大量の同時リクエストを一気に集中させるリスクでもある。 たとえば、データベースが応答遅延を起こしているとき、Functions の全インスタンスが即座にリトライを繰り返すとどうなるか。Service Bus のキューは溜まり続け、再試行で消費されるコンピュートリソースは無駄になり、最終的には一時的な障害がシステム全体の障害に発展する。これがリトライストームだ。 2つのパターンの役割分担 指数バックオフ――「次はいつリトライするか」を制御する 指数バックオフは、リトライのたびに待機時間を指数関数的に増やすパターンだ。1回目の失敗後は5秒後、2回目は15秒後、3回目は45秒後……というように、依存サービスが回復する時間的余裕を与える。 Azure Functions + Service Bus の実装では、メッセージのアプリケーションプロパティにリトライカウントを持たせ、次回実行用のメッセージを指定時刻にスケジュールして現在のメッセージを完了（Complete）する。最大リトライ数を超えたメッセージはデッドレタキューへ退避する。 出典: この記事は Exponential backoff and circuit breaker for Service Bus-triggered Azure Functions の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月7日、次世代Azure Boostをベースとした新VMシリーズ「Esv7」「Dsv7」「Dlsv7」の一般提供（GA）を開始した。カスタムASIC/FPGAハイブリッドとMANA（Microsoft Azure Network Adapter）を1枚のPCIeカードに集約した設計により、最大400Gbpsのネットワーク帯域と最大100万IOPSのリモートストレージ性能を実現している。 Azure Boostとは何か Azure Boostは、従来はホストCPUが担っていたストレージ処理・ネットワーク処理・仮想化オフロードをカスタムシリコンに移管するためのMicrosoft独自アーキテクチャだ。初代Azure BoostはEbsv5などのVMシリーズで採用済みだったが、今回の次世代版では設計を根本から刷新している。 初代との主な違い： カスタムASICとFPGAをハイブリッド統合（前世代はFPGA単体） MANA（Microsoftカスタムネットワークアダプター）を同一カードに統合 専用SoCを搭載したオールインワン設計 1枚のPCIeカードでネットワーク・ストレージ・仮想化の全機能をカバー 要するに「クラウドの縁の下」で動くカスタムシリコンが、よりコンパクトに・より高性能に進化したと理解してよい。 新世代の数字：400Gbps・100万IOPS 項目 性能 最大ネットワーク帯域 400 Gbps リモートストレージ最大IOPS 100万IOPS Dsv7のDsv6比コンピュート改善 最大25% Dsv7のDsv6比DBワークロード改善 最大30% 特にDBワークロードでの30%向上は実務的な意味が大きい。同じ予算で約1.3倍の処理能力を得られるということは、スケールアップ不要のままコスト削減できる可能性を意味する。 3シリーズの使い分け Dsv7（汎用・Dシリーズ後継） Webアプリケーション、中規模データベース、開発/テスト環境に適する最もバランスの取れた汎用VMシリーズ。既存のDsv5・Dsv6ユーザーの移行先として最初に検討すべき選択肢だ。 Esv7（メモリ最適化・Eシリーズ後継） SAP HANA、大規模インメモリデータベース、分析ワークロードなど、メモリ集約型の処理に向く。100万IOPSのストレージ性能はインメモリ型SAPのログI/Oにも恩恵をもたらす。 Dlsv7（コスト最適化） ネットワーク性能を確保しつつコストを抑えたい場面向け。マイクロサービス、キャッシュサーバー、軽量なWebバックエンドなどに適する。 日本のIT現場への影響 既存VM移行の好機 Dsv5・Dsv6、Esv5・Esv6を使用している環境では、新シリーズへの移行を検討する価値がある。DBワークロードを抱える環境では、VMサイズを据え置いたまま性能が上がるか、あるいは1サイズ下げてコスト削減できるかを試算してみることを勧める。 SAP on Azure環境 ESv7がSAP認定VMとして公式認定される見通しで、インメモリ型SAP環境のリフレッシュ計画に組み込む価値がある。ストレージIOPSの向上はBW/4HANAなどの大規模ジョブに直接効いてくる。 AI・MLのCPU前処理フェーズ GPU VMと組み合わせたデータ準備・前処理フェーズには汎用高性能VMが必要になる。Dsv7はそのフィット感が高い。 実務での活用ポイント Azure Migrate・SKU推薦ツールで事前試算する: 既存VMのリソース使用率データをもとに、新シリーズ移行前後のコスト/性能を自動試算できる。まずここから始める 開発・テスト環境で先行検証: 本番前にDsv7でベンチマークを取り、実際の改善率を確認してから本番移行のGoを判断する Ultra Disk / Premium SSD v2との組み合わせを確認: 100万IOPSの性能を引き出すにはストレージ側も対応が必要。Ultra DiskかPremium SSD v2を使う構成が前提になる Accelerated Networkingの設定確認: 400Gbpsの恩恵を受けるにはAccelerated Networkingが有効である必要がある。既存VMからの移行時に設定が正しく引き継がれているか確認を 筆者の見解 Azureの強みは常に「プラットフォームとしての総合力」にある。次世代Azure Boostはその総合力を下から支えるインフラ投資の代表例だ。カスタムシリコンの設計・製造・クラウドサービスへの統合というサイクルをMicrosoftが内製化できていることは、長期的なコスト競争力と性能ロードマップの観点から非常に重要な意味を持つ。 ...

Microsoftは、組織内で無秩序に増殖するAIエージェントを統制するための「マルチリージョン AIエージェント・ランディングゾーン」参照アーキテクチャを、Azure公式ブログで公開した。エージェント登録・ガバナンス・マルチリージョン制御を統合した設計パターンが示されており、AIエージェント活用が本格化する今、多くの組織にとって見逃せない内容だ。 AIエージェント・スプロールとは何か 「スプロール（Sprawl）」とは本来、都市が無計画に郊外へ広がっていく現象を指す言葉だ。AIエージェント領域では、各部門や開発チームが独立してエージェントを立ち上げ、ガバナンスなしに組織内へ無秩序に増殖していく状態を指す。 具体的には次のような問題が発生する。 同じ機能を持つエージェントが複数乱立し、コストが膨らむ セキュリティポリシーが統一されず、データ漏洩リスクが高まる Non-Human Identity（NHI）管理が追いつかなくなり、権限の棚卸しが不可能になる 誰がどのエージェントを動かしているかの可視性が失われる コンテナ黎明期に「とりあえずDockerで動かす」フェーズがあり、やがてKubernetesという統制層が必要になったのと本質的に同じ現象が、今まさにAIエージェントの世界で起きている。 参照アーキテクチャの主要コンポーネント 今回公開された参照アーキテクチャは、スプロール問題を技術的に解決する設計パターンを提示している。 エージェント・レジストリ（Agent Registry） 全てのAIエージェントを一元登録し、目的・所有者・アクセス権・依存関係を管理する。新規エージェントのデプロイには必ずレジストリへの登録が必要となる仕組みで、「野良エージェント」の発生を構造的に防ぐ。 Microsoft Entra IDによるNHI管理 各エージェントにはManaged Identityが割り当てられ、Azure RBACで必要最小限の権限のみが付与される。Just-In-Time（JIT）アクセスを採用することで、常時特権を持つエージェントを排除し、権限の最小化原則を徹底できる。 Azure Policyによるガードレール デプロイ先リージョン・使用可能なAIモデル・ネットワーク設定・暗号化要件などをポリシーとして定義し、準拠していないリソースは自動的にブロックされる。開発者が意識しなくてもガードレールの内側にとどまれる設計だ。 マルチリージョン制御とフェイルオーバー Azure API Managementをフロントエンドに配置し、複数リージョンのAzure AI Servicesへのルーティングを一元管理する。特定リージョンが高負荷または障害時には自動的にバックアップリージョンへ切り替わり、可用性を確保する。 統合的な可観測性（Observability） Azure MonitorとApplication Insightsを組み合わせ、エージェントの呼び出し回数・レイテンシ・コスト・エラー率を統合的に可視化する。異常なトークン消費を早期検知するアラートルールも含まれており、コスト爆発を未然に防ぐ仕組みになっている。 日本の現場での実践ポイント まず棚卸しから始める 自組織内に存在するAIエージェントを全て把握することが出発点だ。シャドーAIとして個人や部門が独自に立ち上げているケースは想定以上に多い。Azure Cost Managementでのコスト分析が実態把握の糸口になる。 NHI管理体制を今すぐ整備する AIエージェントの数は今後確実に増加する。人間のアカウント管理と同じ厳密さでNHIを管理する体制を今から構築しておかないと、後から追うのは困難になる。Managed Identityを積極的に採用し、サービスプリンシパルの乱用を防ぐ習慣を組織に根付かせることが重要だ。 参照アーキテクチャを自社仕様にカスタマイズする 今回の参照アーキテクチャはBicepテンプレートで提供されている。そのまま使うのではなく、自社のコンプライアンス要件に合わせてカスタマイズし、社内のエージェント開発チームが迷わず使える「ゴールデンパス」として整備することが定着への近道だ。 筆者の見解 Microsoftがこのタイミングでランディングゾーンの参照アーキテクチャを公開したのは、プラットフォームベンダーとして理にかなった判断だ。「最も多くのエージェントが安全に動作する場所」としてのAzureを確立するという方向性は、Microsoftが持つ最大の競争優位に直結する。 特に評価したいのは、NHI管理とJITアクセスへの設計上の言及だ。エージェント・スプロールの本質的なリスクは「誰がどのエージェントに何を許可しているか」が見えなくなることにある。その問題意識が設計思想の根幹に置かれている点は、実務目線で見ても正しい優先度だと感じる。自動化を進めるためには結局NHIを制御できるかどうかが鍵になるからだ。 一方で、実際の現場定着には課題もある。参照アーキテクチャは「あるべき姿」を明確に示してくれるが、それを使いこなすにはAzureの基盤知識が相応に求められる。このアーキテクチャを活用できる組織とそうでない組織の差が、そのままAIエージェント活用力の差になっていく時代がもうそこに来ている。アーキテクチャの整備と並行して、それを扱える人材の育成にも同じ重さで取り組んでいただきたい。 出典: この記事は Governing Agent Sprawl: A Multi-Region AI Agent Landing Zone on Azure (Reference Architecture) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月のPatch Tuesdayにて、Azure Managed Instance for Apache Cassandraに存在する2件の重大なリモートコード実行（RCE）脆弱性（CVE-2026-33109、CVE-2026-33844）を公開・修正した。CVSS スコアはそれぞれ9.9と9.0と極めて深刻であり、マネージドCassandraを利用している組織は即座の対応が求められる。 脆弱性の概要 今回発見された2件の脆弱性は、いずれもリモートコード実行（RCE）を可能にするものだ。 CVE番号 CVSSスコア 深刻度 CVE-2026-33109 9.9（Critical） 重大 CVE-2026-33844 9.0（Critical） 重大 特に注意すべきは、攻撃の前提条件の低さにある。低権限のアカウントを持つ攻撃者が、被害者のユーザー操作を一切必要とせずに任意コードを実行できるという組み合わせは、実際の攻撃シナリオにおいて非常に悪用されやすいパターンだ。 Apache Cassandraはオープンソースの分散NoSQLデータベースであり、大規模データの高可用性処理に広く使われている。AzureのマネージドサービスとしてCassandraを利用することで、インフラ管理の手間を省けるが、今回のようにプラットフォーム側の脆弱性が直接利用者に影響する点は留意が必要だ。 修正の適用状況 MicrosoftはPatch Tuesdayの一環としてこの脆弱性に対応済みであることを発表している。マネージドサービスの性質上、インフラ層のパッチはMicrosoftが管理するが、利用者側でも自分たちのワークロードが適切に更新されているか確認することが重要だ。Azureポータルからサービスの状態とメンテナンスウィンドウを確認しておきたい。 実務での確認ポイント Azure Managed Instance for Apache Cassandraを利用している場合の即時アクション： Azureポータルで稼働インスタンスを確認: 「Azure Managed Instance for Apache Cassandra」として登録されているリソースを棚卸しする ネットワークアクセス制御の見直し: パブリックエンドポイントを無効化し、プライベートエンドポイント経由のアクセスのみに絞る サービスプリンシパル・マネージドIDの権限確認: データベースに接続するNon-Human Identity（NHI）に過剰な権限が付与されていないか確認する アクセスログの確認: 不審な操作がなかったか、Azure Monitorのログを遡って確認する Microsoft Security Response Center（MSRC）のアドバイザリを追跡: 追加情報が公開された場合に備えて定期確認する また、今回のような「低権限で攻撃可能」なRCE脆弱性は、最小権限の原則（Principle of Least Privilege）の徹底がいかに重要かを改めて示している。接続アカウントに管理者権限を与えていた場合、被害の範囲が大幅に広がることになる。 筆者の見解 セキュリティ案件は正直、追うのが得意なジャンルではない。だが今回のケースは純粋に技術的な興味を引く話だ。CVSS 9.9というスコアは、攻撃の容易さと影響範囲の広さを同時に示しており、数字の重みをちゃんと受け止めてほしい。 問題の本質は「マネージドサービスだから安全」という誤解にある。マネージドサービスはインフラ管理の手間を省いてくれるが、脆弱性がなくなるわけではない。むしろ、プラットフォーム側の問題は利用者が自力でパッチを当てることもできないため、Microsoftのパッチ適用タイミングに依存するという側面もある。 この構造を踏まえると、設計段階で「侵害を前提とした防御」を組み込むことが不可欠だ。具体的には、データベースへのアクセス権を最小化し、接続するNon-Human Identityに必要最低限の権限のみを与え、定期的に棚卸しする仕組みを整えること。NHI管理を怠ると、こうした脆弱性が発覚したとき「どのサービスプリンシパルがどのデータベースに何の権限で繋がっているか」がわからなくなり、影響範囲の特定すらできなくなる。 マネージドサービスを積極的に使うのは正しい選択だ。ただし、「管理をMicrosoftに任せる部分」と「自分たちで管理すべき部分」の境界線を明確に引いたうえで運用してほしい。その境界を曖昧にしたまま使い続けることのリスクが、今回の件で見えてきたと思う。 出典: この記事は Azure Managed Instance for Apache Cassandra: Critical RCE Vulnerabilities (CVE-2026-33109, CVE-2026-33844) の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftが、Linuxカーネルの権限昇格脆弱性「Copy Fail（CVE-2026-31431）」および「DirtyFrag（CVE-2026-43284/CVE-2026-43500）」に対する緩和策を、Azure Kubernetes Fleet Managerを使って複数のAKSクラスターへ安全に一括展開する手順を公開した。 なぜこの脆弱性が危険なのか 今回対象となるCVE群は、コンテナからホストノードへのroot権限昇格（Local Privilege Escalation / LPE）を可能にする深刻な脆弱性だ。AKSのLinuxノードが対象で、緩和策を適用するまでの間、悪意のあるコンテナがノード全体を乗っ取るリスクがある。 Kubernetesのマルチテナント環境では、ひとつのノードに複数の名前空間・複数のチームのワークロードが同居している。ノードへのroot昇格が成功した場合、そのノード上のすべてのPodのデータ、シークレット、通信が危険にさらされる。コンテナ隔離の前提が根底から崩れるという意味で、影響範囲は想像以上に広い。 2段階の緩和アプローチ Azure Kubernetes Fleet Managerを使った緩和策は、即時対応と恒久対応の2段階に分かれている。 即時対応：DaemonSetによるカーネルモジュール無効化 ノードイメージのアップグレードがすぐに適用できない環境向けの暫定策だ。algif_aead（Copy Fail関連）、esp4、esp6、rxrpc（DirtyFrag関連）という4つの脆弱なカーネルモジュールをブロックするDaemonSetを、Fleet ManagerのClusterResourcePlacementを使って複数クラスターへ一括展開する。 DaemonSetはkube-systemではなく専用の名前空間kernel-lpe-cve-mitigate-nsに配置される。意図の明確化と管理のしやすさを両立した設計だ。 展開はClusterStagedUpdateRunによりステージ管理される。canaryグループから段階的に適用できるため、問題が生じた場合の影響範囲を最小化できる。 出典: この記事は Apply Copy Fail and DirtyFrag CVE mitigations at-scale using Azure Kubernetes Fleet Manager の内容をもとに、筆者の見解を加えて独自に執筆したものです。

xAI（イーロン・マスク率いる AI 企業）の最新フラッグシップモデル「Grok 4.3」が、Microsoft Azure AI Foundry 上で正式に利用可能となった。エージェント型 AI 機能として本番環境に即投入でき、GPT 系モデルに加わる新たな選択肢として注目を集めている。 Grok 4.3 の核心——「エージェント知能」とは何か Grok 4.3 は「最新世代のエージェント知能（Next-Generation Agentic Intelligence）」を標榜するモデルだ。単純な質問応答に留まらず、複数ステップのタスクを自律的に計画・実行する能力を持つ。 具体的には以下のようなシナリオで真価を発揮する： ツールの連携使用: Web 検索、コード実行、ファイル操作などを組み合わせ、目標達成まで自律的に進める 長期タスクの分解と実行: 複雑な要件をサブタスクに自動分解し、順序立てて処理する 状態を維持した継続的作業: 長いセッションを通じてコンテキストを保ちながら業務を完遂する これらはいずれも、人間の介在なしに「仕事の流れをまるごと自動化する」ためのエージェント設計の基本要件であり、今後の AI 活用の主流となる方向性と一致している。 Microsoft Foundry 経由で使う意味 Azure AI Foundry（旧 Azure AI Studio）は、様々な AI モデルを統一された管理基盤のもとで利用できるプラットフォームだ。OpenAI の GPT-4o 系、Meta の Llama 系 OSS モデルに続き、今回 xAI の Grok 系が加わった。 Foundry 経由で利用することの主なメリットは以下のとおりだ： 観点 内容 認証・認可 Microsoft Entra ID による既存 ID 管理基盤との統合 コンプライアンス Azure Policy・リージョン制御で規制業界にも対応 コスト管理 Azure Cost Management でモデル使用料を一括把握 ...