Azure

Azure LocalのApril 2026リリース（バージョン12.2604.1003.209）が公開された。今回の更新は「新機能の追加」というより「現場で実際に使えるレベルへの引き上げ」という色合いが強い。エッジ・オンプレミス環境でAzureのクラウドサービスを動かしたいと考えている組織にとって、見逃せない内容が揃っている。 NVIDIA RTX PRO 6000 Blackwell GPU、ついにGA 最も注目すべきは、NVIDIA RTX PRO 6000 Blackwell Server EditionのGPUアクセラレーションがAzure Local VMおよびAKS on Azure Arcで正式にサポートされたことだ。これにより、エッジ環境でGPUを要する推論ワークロード——たとえばオンプレミスで完結させたい画像解析、音声認識、ローカルLLM推論など——をKubernetesクラスタ上で本番稼働させる道が正式に開けた。 データをクラウドに送れない製造現場や医療機関にとって、「エッジで動くGPUワークロード」は長年の悲願だった。Previewから一歩踏み出してGAになったことで、PoC止まりだったプロジェクトを本番へ移せるタイミングが来たと言える。 SAN分離展開（Disaggregated Deployment）の一般提供開始 従来のAzure Localはノード内蔵ディスクによるStorage Spaces Direct（S2D）が基本だったが、今回からSANストレージのみを使った「分離展開（Disaggregated Deployment）」が正式サポートされた。 このアーキテクチャの最大のメリットはストレージとコンピュートの独立スケーリングだ。従来は16ノードが上限だったクラスタが、この構成では16ノードを超えてスケールできる。すでに大規模なSANインフラを持つエンタープライズにとっては、既存資産を活かしながらAzure Localへ移行する現実的な経路になる。 あわせてSANストレージをS2Dと併用するハイブリッド構成もGAとなった。「どちらかを選べ」ではなく「両方使える」という柔軟性は、レガシー資産の多い日本のデータセンター環境では特に評価されるポイントだ。 運用・展開の実務改善が地味に重要 今回のリリースで見落とされがちだが実務に効く改善が複数ある。 検証（Validation）時間の最大50%短縮：これまでValidationが途中で失敗すると最初からやり直しだったが、3時間以内であれば失敗箇所から再開できるようになった。大規模クラスタの展開や更新作業での時間ロスが大幅に減る。 展開時間の最大40%短縮：8ノードまでのクラスタで展開時間が安定化・短縮された。週末の夜間作業枠でギリギリだったケースが改善される可能性がある。 ドメイン参加の事前実施サポート：展開前にドメイン参加を済ませておける構成が追加された。企業のIT統制上、ドメイン参加のタイミングに制約がある環境では作業フローが組みやすくなる。 更新設定の制御：いつ・どのように更新を適用するかをコントロールできる機能が追加された。メンテナンスウィンドウの厳格な管理が求められる本番環境では重要な追加だ。 AKSとKubernetesバージョンの注意点 AKS enabled by Azure Arcでサポートされるバージョンが更新された（1.31.12〜1.33.5系）。Kubernetes 1.30はサポート終了となるため、Azure Localをアップグレードする前にAKSクラスタのバージョンが対象外になっていないか確認が必要だ。 また、KMS v1が近く廃止予定となり、KMS v2への移行が求められる。既存クラスタはKMS v2を使って再展開する必要があるため、計画的な対応が必要になる。見落とすと後で痛い目を見る変更なので早めに把握しておきたい。 実務への影響 エッジAIの本番化を検討中の製造・医療・公共セクターにとって、GPU GAは「いよいよ本番へ」の号令になる。PoC環境をGAサポートの構成に揃え直す作業を今から着手しておくと良い。 大規模データセンター移行を計画している組織は、SAN分離展開によって16ノード上限という制約が消えたことを設計に織り込むタイミングだ。既存SAN資産の棚卸しを進めておこう。 AKSを本番運用中のチームは、Kubernetes 1.30のEOS対応とKMS v1廃止計画を必ずバックログに積むこと。Azureアップグレードと連動するため、優先度を上げて対処すべきだ。 筆者の見解 Azure Localは「オンプレミスにAzureを持ち込む」という当初のコンセプトから着実に成熟してきた。SAN分離展開のGAやGPUサポートの正式化は、これまで「面白そうだが使えない」と距離を置いていた大規模エンタープライズが、本格評価に踏み込める段階になったことを示している。 特に評価したいのは、検証時間の短縮や展開パフォーマンスの改善だ。新機能ばかりに注目が集まりがちだが、「再現性のある展開ができるか」「失敗したときに立て直しやすいか」という運用品質こそが現場での採用率を左右する。その地道な改善を積み重ねているのは、プラットフォームとして信頼できる方向性だと感じる。 一方で、エッジ×AI×Kubernetesの構成は絡み合う要素が多く、バージョン管理やKMS移行など「追いかけるコスト」も年々増している。情報を追い続けるよりも、標準的な構成で実際に動かしてみる経験を積む方が、長期的には組織の力になる。Azure Localの道のド真ん中——Microsoftの推奨構成に沿ったシンプルな展開——から始めることを改めて勧めたい。 出典: この記事は What’s new in Hyperconverged Deployments of Azure Local latest release の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Azure Application Gateway V1の廃止期限が今週2026年4月28日に迫っている。3年前に廃止アナウンスが出てから時間はあったはずだが、まだV2への移行が完了していない組織にとっては、今この瞬間が最後のチャンスだ。期限を超えると稼働中のV1ゲートウェイはAzureによって強制停止される。本番サービスへの直接的な影響が想定されるため、担当者は今すぐ状況を確認してほしい。 Application Gateway V1廃止の経緯と現在地 Microsoftは2023年4月28日にV1の廃止を正式アナウンス。段階的な廃止スケジュールは次の通りだ。 日付 内容 2023年4月28日 廃止アナウンス・V1購読の新規受付停止 2023年7月1日 V1未使用のサブスクリプションへのV1デプロイ禁止 2024年9月1日 全顧客向けV1の新規作成完全停止 2026年4月28日 稼働中のV1デプロイをすべて強制停止 廃止後（時期未定） V1リソースの削除 廃止後はパッチ提供・テクニカルサポート・SLAがすべて終了する。停止状態に置かれたV1ゲートウェイは、その後Microsoftによって削除されるスケジュールも別途通知される予定だ。 V2への移行で何が変わるか Application Gateway V2はV1と比べて多くの点で強化されている。 パフォーマンス面 自動スケーリング（Auto Scaling）により、トラフィック増減に自動で追従 ゾーン冗長性（Zone Redundancy）により、データセンター障害への耐性が向上 起動時間の大幅短縮（数分→数秒レベル） セキュリティ面 WAF（Web Application Firewall）ポリシーの柔軟な設定 マネージドルールセットの自動更新 Private Link統合によるバックエンド接続のセキュリティ強化 運用面 Key Vault統合による証明書管理の自動化 Azure MonitorおよびApplication Insightsとの統合強化 V2への移行は公式ドキュメントの「Migrate Azure Application Gateway and Web Application Firewall from V1 to V2」に手順が整理されている。MicrosoftはCSA（クラウドソリューションアーキテクト）やCSAM（カスタマーサクセスアカウントマネージャー）との連携も推奨しており、技術的な質問はMicrosoft Q&Aやメールサポートでも受け付けている。 実務への影響——日本のエンジニア・IT管理者が今すぐやること Step 1: V1の棚卸し（今日中） Azure Portalで「Application Gateway」を検索し、V1（SKU: Standard/WAF）が残っていないかすべてのサブスクリプションを横断的に確認する。複数サブスクリプションを持つ大企業では、見落としリスクが高い。2023年に送付されたMicrosoftからの廃止通知メールも合わせて確認したい。 Step 2: 移行計画の即時立案 V1が見つかった場合、まず「そのゲートウェイが何のために使われているか」を把握する。バックエンドプールの構成・リスナー設定・WAFポリシーをドキュメント化してからV2への移行作業に入る。 Step 3: 移行後の動作検証 V2はIPアドレスが変わるため、DNS設定の切り替えとTTLの設計が重要になる。ブルーグリーン方式で一時的にV1とV2を並走させながら検証期間を設けることが望ましい。 ...

Azure Databricksが2026年4月リリースノートのなかで静かに、しかし重要なアップデートを告知した。Mosaic AI Model ServingがAnthropicのClaude Opus 4.7をDatabricksホスト型モデルとしてサポートしたのだ。データエンジニアやMLエンジニアにとって、これは「どのモデルを使うか」の選択肢が広がったというだけの話ではない。エンタープライズデータ基盤のなかで最新の大規模言語モデルをどう安全に運用するかという、より本質的な問いへの回答が一つ増えた瞬間だ。 Databricksホスト型モデルとは何か Mosaic AI Model Servingのホスト型モデルとは、モデルの推論インフラをDatabricks側が管理し、ユーザーはAPIを叩くだけで利用できる仕組みだ。今回Claude Opus 4.7が追加されたことで、Foundation Model APIsのペイパートークン課金でこのモデルを呼び出せる。重要なのは、データがAzure Databricksの管理境界の外に出ない点だ。 通常、外部のAI APIをエンタープライズデータと組み合わせようとすると、データをAPIエンドポイントに送信することになる。これはセキュリティポリシー上の審査が必要になり、特に個人情報や機密情報を含む業務データでは大きなハードルになる。ホスト型モデルならこの問題を回避できる。 アクセス方法は三つ用意されている。 Foundation Model APIs（ペイパートークン） 推論（Reasoning）モデル向けのクエリ ビジョンモデル向けのクエリ Opus 4.7はAnthropicのフラッグシップクラスのモデルであり、複雑な推論タスクや長文ドキュメントの解析において高い精度を発揮する。Databricks上のUnity Catalogと組み合わせれば、データカタログに蓄積されたメタデータや実データに対して高度な自然言語クエリをかけることが現実的になる。 同時に注目すべき4月の他アップデート 今回のリリースノートはClaude Opus 4.7の追加だけにとどまらない。エンタープライズのデータ基盤という観点で注目すべきアップデートがいくつか重なっている。 Databricks Data ClassificationがGA（一般提供）になった。これはUnity Catalog内の機密データをエージェント型AIシステムで自動分類・タグ付けする機能だ。個人情報保護法対応やコンプライアンス管理のコストを大幅に下げられる可能性がある。 Lakeflow Designerがパブリックプレビューに入った。ドラッグ＆ドロップのキャンバスと自然言語でデータ変換ワークフローを視覚的に構築できる機能で、SQLやPythonを書かずにデータパイプラインを組める。 Supervisor API（Beta）も追加された。モデル、ツール、インストラクションを定義するだけで、ツール選択・実行・レスポンス合成をDatabricks側が処理するエージェント構築の仕組みだ。 これらを組み合わせると、「データの自動分類→パイプライン構築→AIエージェントによる分析」という流れを、比較的少ない工数でセキュアな環境に構築できるようになる。 実務への影響——日本のエンジニア・IT管理者にとっての意味 データガバナンスを維持したままAIを使いたい企業にとって、このアーキテクチャは現実解の一つになる。Microsoft Entra IDとAzureのロールベースアクセス制御（RBAC）を活かしつつ、Unity Catalog上でモデルへのアクセス権限を一元管理できる点は、エンタープライズ要件への適合性が高い。 コスト管理の面では、ペイパートークン課金は小規模な検証フェーズに向いている。本格運用に移行する際にプロビジョンドスループットを検討するという段階的な進め方が現実的だ。 Power BIとのBI互換モードが廃止されたことも見落とせない。4月17日のリリースでPower BIコネクタのBI互換モードが削除され、このオプションを使っていたレポートは機能しなくなった。Databricksを使っているチームは既存レポートの影響確認を早急に行う必要がある。 筆者の見解 Azure Databricksがモデルサービングのラインナップを継続的に拡張していることは、Azureのプラットフォーム戦略の正しさを示していると思う。「どのAIモデルが最も賢いか」という競争とは別の軸、つまり「エンタープライズデータと最良のモデルを安全に組み合わせられる場所はどこか」という競争では、Azureは着実に優位を積み上げている。 重要なのは、この枠組みがMicrosoftの独自モデルに閉じていないことだ。Unity CatalogというデータガバナンスレイヤーとMicrosoft Entra IDという認証・認可の仕組みを活かしながら、推論に使うモデルは用途に応じて選べる。これは「マイクロソフト基盤の上でどのAIを動かすかを選ぶ自由」という形で、エンタープライズにとって最も現実的なアーキテクチャに近づいている。 Data ClassificationのGAリリースも見逃せない。AIを業務に組み込む前の壁として「機密データをAIに食わせていいのか」という問いが必ず立ちはだかる。この問いに対してガバナンスの仕組みをプラットフォームレベルで提供し始めていることは、日本の大企業がAIを本番運用に踏み出す際の後押しになるはずだ。 ただし、Power BIのBI互換モード廃止のような「静かな破壊的変更」が混在しているのは正直なところ残念だ。リリースノートを細かく追わないと気づかないまま本番レポートが壊れるリスクがある。プラットフォームとしての信頼性を高めていくためにも、こうした変更はもう少し早期に、目立つ形で告知してほしいというのが率直な思いだ。ポテンシャルは十分あるだけに、運用面の丁寧さで応えてほしい。 出典: この記事は Anthropic Claude Opus 4.7 now available as a Databricks-hosted model (April 2026) の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AIカスタマイズの民主化が本格化する Microsoft Foundryが2026年4月、強化ファインチューニング（Reinforcement Fine-Tuning / RFT） に関する3つの重要アップデートを発表した。o4-miniのグローバルトレーニング対応、新世代グレーダーモデルの追加、そしてベストプラクティスガイドの公開だ。 「カスタムモデルを作る」というのはかつて一部の大手テック企業にしか許されない贅沢だったが、これらのアップデートによってその敷居が大きく下がる。エンタープライズのAI活用が「既製品をそのまま使う」フェーズから「自社業務に最適化されたモデルを育てる」フェーズへと移行する転換点になり得る。 3つのアップデートを整理する 1. o4-miniのグローバルトレーニング対応 ファインチューニングにおけるリージョン制約は、グローバルに展開する企業にとって長年のストレスポイントだった。今回のアップデートでo4-miniが13のAzureリージョンからトレーニングジョブを起動できるようになった（4月末までに全ファインチューニング対応リージョンへ拡大予定）。 現在対応しているリージョンにはEast US 2、Australia East、France Central、Germany West Central、Japan方面ではないものの欧州・北米・オセアニアに広く展開済みだ。日本リージョンの早期対応も期待したいところだが、まずはグローバル展開する日系企業が即恩恵を受けられる。 コスト面では、Standard trainingと比較してより低いトークン単価が適用される。o4-miniはもともと推論コストが抑えめなモデルだが、グローバルトレーニングでさらにスケーラブルになる。 REST APIでのジョブ作成は以下のように"trainingType": "globalstandard"を指定するだけだ： 出典: この記事は What’s New in Microsoft Foundry Fine-Tuning | April 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがAzure Foundryプラットフォーム上に、独自AIモデルファミリー「MAI（Microsoft AI）」の新作3種を投入した。音声認識のMAI-Transcribe-1、音声合成のMAI-Voice-1、画像生成のMAI-Image-2だ。OpenAIやMetaといったパートナーモデルへの依存を薄め、自社製モデルで一気通貫のエコシステムを築こうという意思表示として注目に値する。 3つのモデルが狙う「実用の穴」 MAI-Transcribe-1 ── 25言語対応の高精度文字起こし 音声をテキストへ変換するSTT（Speech-to-Text）モデル。25言語の書き起こしに対応し、バッチ処理速度は従来比2.5倍。GPUコストは約50%削減を実現したとされる。単純な精度追求だけでなく「コスト効率」を前面に出している点が特徴だ。価格は**$0.36/時間**から。大量の会議録・コールセンター音声を処理するシナリオで即戦力になれる水準を目指している。 MAI-Voice-1 ── リアルタイムに耐える感情表現つき音声合成 TTS（Text-to-Speech）モデル。感情のニュアンスを持った自然な音声を生成し、長い出力でも話者のアイデンティティを維持するという。最大60秒の音声を約1秒で生成できるため、音声エージェントや対話型アプリへのリアルタイム組み込みが現実的な選択肢になる。 MAI-Image-2 ── Arena.aiランキング3位の画像生成 画像生成モデルで、独立評価プラットフォーム「Arena.ai」のランキングで3位に位置づけられている。ライティング・テクスチャ・画像内テキスト描画の精度が向上したとされ、すでにCopilot・Bing・PowerPointへの統合が進んでいる。 Microsoft Foundryがハブになる 3モデルはいずれもMicrosoft Foundry経由で提供される。FoundryはOpenAI、Meta、Mistralといったサードパーティモデルと並列に自社MAIモデルを配置する「AIモデルの統合マーケットプレイス」だ。デプロイ・ガバナンス・スケーリングのツールが一体となっており、エンタープライズが複数モデルを一元管理するプラットフォームとして機能する。MAI Playgroundも同時提供され、本番前の動作確認が可能だ。 実務への影響——日本のエンジニア・IT管理者に伝えたいこと コスト構造の見直し機会：音声処理ワークロードに現在サードパーティSaaSを使っている場合、MAI-Transcribe-1の$0.36/時間という価格は比較検討に値する。特に大量バッチ処理をAzure上で完結させたい組織には「ベンダー集約によるコスト削減」の文脈で刺さりやすい。 Foundry一択でモデルを選ぶ時代：Foundryには今やOpenAI・Meta・Mistral・そして今回のMAIが並ぶ。「最良のモデルをAzureガバナンス下で使う」というアーキテクチャが現実的になっている。Entra IDによる認証・認可をそのまま活用しながら、タスクに応じてモデルを切り替える運用設計を今から考えておきたい。 音声エージェント開発者へ：MAI-Voice-1の「60秒音声を1秒で生成」は音声UIの応答性に直結する。カスタマーサポートや社内ヘルプデスクの音声エージェントを検討しているチームは、Playgroundで実際の発話品質を試してみる価値がある。 PowerPoint・Copilotに乗る画像生成：MAI-Image-2はすでにM365アプリへの統合が進んでいる。特別な設定なく、現在使っているCopilot機能が静かに強化されていく可能性があり、ユーザー企業は次のアップデートサイクルで変化を感じることになるだろう。 筆者の見解 今回の発表で筆者が注目したのは「競合への対抗」という表現ではなく、「実装の現実解」への寄せ方だ。 GPUコスト50%削減・バッチ速度2.5倍という数字は、ラボベースの精度比較ではなく、実際のエンタープライズワークロードで使える指標として提示されている。Microsoft Foundryが複数の外部モデルも束ねて提供する構図になっている以上、「自社モデルの性能で勝つ」よりも「最高のモデルが動くプラットフォームとして選ばれる」を目指している——そういう現実的な自己認識が透けて見える。それは正直なアプローチだと思う。 MAI-Image-2がArena.aiで3位というのは素直に評価したい。画像生成の品質競争は熾烈だが、PowerPointやBing、Copilotというリーチを持つプラットフォームに直接統合できる強みはMicrosoftにしかない。「最高モデルをどこでも届けられる仕組み」と「使われる場所への統合力」、この2軸が長期戦の鍵になる。 この延長線上に、Entra IDを軸としたエージェント管制塔という戦略がある。最も賢いモデルを作ることと、最も安全に多様なエージェントを動かせるプラットフォームを提供することは、必ずしも同じゲームではない。Microsoftが後者で本気を出し続けることを、引き続き期待している。 出典: この記事は Microsoft Launches 3 New MAI AI Models on Foundry to Take on OpenAI, Google の内容をもとに、筆者の見解を加えて独自に執筆したものです。

毎月定期リリースされるAzure SDKだが、2026年4月版は「見逃せないアップデート」が複数重なった月となった。セキュリティ修正、AIエージェント基盤の正式安定版化、そして広範なプロビジョニングライブラリの整備と、開発者・インフラ担当者の双方に影響するリリースだ。 CosmosDB Java SDK 4.79.0 — 重大なRCE脆弱性を修正 今回のリリースで最も緊急度が高いのが、Java向けCosmosDB SDK（4.79.0）に含まれるセキュリティ修正だ。対象の脆弱性はCWE-502（信頼できないデータのデシリアライゼーション）、つまり任意コード実行（RCE）につながりうるクラスの問題である。 修正の内容は根本的だ。CosmosClientMetadataCachesSnapshot、AsyncCache、DocumentCollection においてJavaのデシリアライゼーション機構を廃止し、JSON経由のシリアライゼーションに完全置換した。Javaのデシリアライゼーション攻撃は長年にわたって悪用されてきた経路であり、「クラスごと排除する」というアプローチは技術的に正しい判断だ。 このリリースにはセキュリティ修正にとどまらず、Nリージョン同期コミット対応、クエリの改善を支援するQuery Advisor機能、そしてハイブリッド検索におけるBM25スコア計算範囲を制御する CosmosFullTextScoreScope も追加されている。 AI Foundry 2.0.0 正式版 — 名前空間の整理と型名の統一 NuGetパッケージ Azure.AI.Projects がバージョン2.0.0として正式安定版（GA）に到達した。ただし、2.0.0への移行は破壊的変更を伴う。主な変更点を整理する。 名前空間の分離: 評価（Evaluations）とメモリ操作が Azure.AI.Projects.Evaluation、Azure.AI.Projects.Memory という独立した名前空間に移動 型名の見直し: Insights → ProjectInsights、Schedules → ProjectSchedules、Evaluators → ProjectEvaluators、Trigger → ScheduleTrigger と、プレフィックスを統一 命名規則の統一: ブール型プロパティが Is* 命名規則に揃えられた 内部型の隠蔽: 一部の型がinternalスコープに変更された 名前空間の分離は単なるリファクタリングではない。評価とメモリ管理を独立したパッケージとして扱えるようにすることで、本番システムへの組み込みが段階的・選択的に行えるようになる。 AI Agents 2.0.0 Java版 — GAと同時に破壊的変更 Java向けAzure AI Agentsライブラリも2.0.0でGA到達。API一貫性の改善のため、いくつかの破壊的変更が入っている。 一部のenum型が ExpandableStringEnum ベースのクラスに変換（将来の値追加への対応力向上） *Param クラスが *Parameter にリネーム MCPToolConnectorId が McpToolConnectorId に統一（大文字小文字の規則整理） beginUpdateMemories に新しい便利オーバーロードを追加 MCPToolConnectorId の名前が整理されている点は興味深い。MCPプロトコル（Model Context Protocol）との接続を正式に管理する仕組みが、GAレベルのAPIとして提供されたことを意味する。 ...

2026年5月1日、MicrosoftはWindows 365 Businessの提供価格を永続的に20%引き下げることを発表した。昨年中頃から続いていたプロモーション価格が実質的に「新定価」となる形で、中小企業（SMB）向けクラウドPCの普及に向けた明確なシグナルを打ち出した。 何が変わるのか 値下げの対象はWindows 365 Businessの全SKU。現時点では以下の3構成が128GBストレージとセットで提供されている。 プラン vCPU RAM Basic 2 4 GB Standard 2 8 GB Premium 4 16 GB 新価格は2026年5月1日以降に新規注文または更新したテナントから自動的に適用される。既存契約の場合は次回更新タイミングで反映されるため、現在利用中の組織は更新日を確認しておくとよい。なお、Windows 365 Businessはテナントあたり最大300台という上限があり、大規模展開が必要な場合はEnterprise版（上限なし）が引き続き選択肢となる。 オンデマンド起動（ハイバネーション）の導入 値下げと同時に、アイドル時のCloud PCが約1時間後に低消費電力状態へ移行する「オンデマンド起動」機能が追加される。ユーザーが再接続すると自動的に復帰するが、ウォームアップに若干の時間がかかる点には注意が必要だ。Microsoftは「完全起動後のパフォーマンスへの影響はない」としており、常時稼働が不要なユーザーにとっては合理的なトレードオフといえる。 これは「コスト削減と引き換えに起動速度を少し犠牲にする」構造であり、ターゲットがSMBであることを明確に示している。 実務への影響 物理PCとの比較検討が本格化 20%の値下げによって「Windows 365はちょっと高い」という印象が払拭されつつある。PC本体価格の上昇（円安含む）が続く中、3〜4年サイクルのデバイスリフレッシュと比較したTCO試算を改めて行う価値が出てきた。特に以下のシナリオでは優位性が高まる。 リモート・ハイブリッドワーカーが多い組織: ユーザーがどのデバイスからでも同じWindows環境にアクセスできる ITスタッフが少ない組織: エンドポイント管理の複雑さをMicrosoftに委ねられる 季節・プロジェクト単位で人員が増減する組織: ライセンスを柔軟に増減できる Azure Virtual Desktop（AVD）との棲み分け 複数セッション・高度なカスタマイズが必要なシナリオではAVDが依然として有力だが、設計・運用コストが高い。Windows 365 Businessは「マネージドで使い始められる手軽さ」が差別化ポイントであり、自社にAzure専任エンジニアがいない場合は積極的に検討すべき選択肢となった。 既存顧客へのアクションポイント 契約更新日を確認し、5月1日以降の更新タイミングを把握する ハイバネーション導入後の起動時間を実際にテストし、業務フローへの影響を評価する 次のデバイスリフレッシュサイクルまでに、物理PC vs Windows 365のTCO比較を実施する 筆者の見解 この値下げは、Microsoftが「SMBへのCloud PC普及」に本気で取り組んでいることを示す施策だと受け止めている。正直なところ、昨年のプロモーション価格の段階でも「期間限定では組織の意思決定に使いにくい」という声は多かった。今回それを永続的な定価に格上げしたことは、現場レベルの不満に応えた実務的な判断で評価できる。 ハイバネーション機能については、常時フルスペックで動かすことが前提のユーザーには少し気になるかもしれないが、多くのSMBユーザーにとっては十分なトレードオフだろう。「コスト最適化と引き換えに利便性を削る」ではなく、「使わない時間帯のコストを削る」設計は理にかなっている。 ただ、筆者が長く感じてきた課題は価格だけではなかった。クラウドPCというコンセプト自体は正しい方向性だし、Microsoft Entra IDを核にした統合管理の仕組みは長期的に見て正しい戦略だと今でも思っている。それだけに、今回のような価格・機能面の改善を継続して積み重ねてほしい。Windows 365にはまだ伸びしろがある。この値下げが「始まり」であってほしいと感じている。 出典: この記事は Microsoft Slashes Windows 365 Business Prices by 20%: What It Means for Cloud PCs in 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Azure Service Busの旧通信プロトコル「SBMP（Service Bus Messaging Protocol）」が、2026年9月30日をもって正式に廃止される。Microsoftは同日、BizTalk Server 2020向けのAMQP対応ホットフィックスも公開しており、レガシー統合基盤を抱える日本企業にとっても「今すぐ動く」必要がある局面に入った。 SBMPとは何か、なぜ廃止されるのか SBMP（Service Bus Messaging Protocol）は、Azure Service Busが初期から採用していた独自のTCP/IPベースのプロトコルだ。現在の主流はAMQP 1.0（Advanced Message Queuing Protocol）であり、SBMPはすでに数年前から「非推奨」のステータスに置かれていた。 AMQPはOASIS標準であり、マルチベンダー対応・TLS必須・接続管理の堅牢性といった点でSBMPより明らかに優れている。Microsoftが廃止期日を明確に示したことは、「いつかやる」を「今年中にやる」に変える意味で重要なアナウンスだ。 BizTalk Server 2020への影響と対処法 BizTalk Server 2020はSBMPを前提とした実装が含まれており、そのままでは2026年9月30日以降にAzure Service Bus連携が完全に停止する。Microsoftはこの問題に対処するホットフィックスを既にリリースしており、これを適用することでAMQPへの切り替えが可能になる。 対応ステップをまとめると以下の通りだ： ホットフィックスの適用: Microsoft公式ブログに掲載されたKB番号を確認し、BizTalk Server 2020環境に適用する 接続文字列・設定ファイルの更新: SBMPベースのエンドポイント設定をAMQPエンドポイントに書き換える テスト環境での動作検証: 本番適用前に、主要フローの送受信・エラーハンドリングを確認する 本番切り替えと監視強化: 切り替え後は一定期間、メッセージのロスト・遅延・デッドレターキュー積み上がりを重点監視する 旧SDKライブラリも同日廃止 もう一点見落とせないのが、旧SDKライブラリの廃止だ。WindowsAzure.ServiceBus（NuGetパッケージ）をはじめとする旧世代のクライアントライブラリも、SBMPと同じく2026年9月30日に退役する。 これは自社開発のアプリケーションにも直撃する。社内で「なんとなく動いている」古い.NETアプリや、長年手を入れていないバッチ処理が旧SDKを参照していないか、今すぐNuGetの依存関係を棚卸しすることを強く勧める。 移行先はAzure.Messaging.ServiceBus（現行の公式SDK）だ。名前空間・APIの設計が大きく変わっているため、単純な置き換えではなく一定のリライトが必要になるケースも多い。 実務への影響：日本のエンジニア・IT管理者に向けて 棚卸しから始めよ。 自社・顧客環境でAzure Service Busを利用しているシステムをすべてリストアップし、以下を確認する： BizTalk Server 2020を使っているか WindowsAzure.ServiceBus または関連する旧SDKを参照しているアプリはないか Logic Apps・Azure Functionsなど他のサービスでService Busを経由しているフローはないか BizTalk Server 2020はオンプレミスに残ったまま運用されているケースが日本では依然多い。クラウド連携部分だけがこっそりSBMPを使い続けていることに気づかず、2026年秋に突然メッセージが届かなくなる——という事態は十分ありうる。「今動いているから大丈夫」という判断は今回の件では通用しない。 また、この機会にAzure Service Busのトポロジー全体を見直し、プレミアム層への移行やプライベートエンドポイントの導入も検討する価値がある。ゼロトラスト観点から言えば、パブリックエンドポイント経由のメッセージング基盤をいつまでも放置しておくべきではない。 筆者の見解 Azure Service Busは非常に成熟したメッセージングサービスであり、Azureプラットフォームの信頼性を体現する存在のひとつだ。今回のSBMP廃止は、技術的に正しい判断だと思う。AMQPへの統一は長期的なメンテナンスコストを下げ、セキュリティ水準を引き上げる。Microsoftがきちんと移行パスとホットフィックスを用意してくれているのも、誠実な対応だ。 ただ、正直に言えば「もっと早く、もっとうるさく告知してほしかった」という思いもある。日本の大規模エンタープライズ環境では、BizTalkを中心とした統合基盤の変更は半年・一年単位の調整を要する。2026年9月という期限は、実態として決して長くない。Microsoftにはこうした移行案件において、グローバルTechコミュニティだけでなく、意思決定に時間がかかりやすい日本市場への丁寧なコミュニケーションを期待したい。 また、今回のような廃止アナウンスを機に、「BizTalk Server 2020をあと何年使うのか」という根本的な問いに向き合う企業も増えるはずだ。Azure Integration ServicesやAzure Logic Appsへの本格移行を検討し始めるタイミングとして、これ以上ない警鐘でもある。 ...

Azure DevOps MCPサーバーが4月21日に大型アップデートを公開した。新機能の中核はWIQLクエリ対応だが、より注目すべきは「ツールの安全性メタデータ化」と「ツール群の再設計」という設計思想の進化だ。AIエージェントとの統合を本格的に見据えた動きとして、開発現場への影響を詳しく見ていく。 WIQLクエリ対応：wit_query_by_wiql の追加 最も実用的な追加は、Work Item Query Language（WIQL）を実行できる wit_query_by_wiql ツールの登場だ。WIQLはAzure DevOpsのワークアイテムをSQLライクな構文で柔軟に検索できる仕組みで、これまでUI上での操作が主だったものをAIエージェント経由で動的に発行できるようになった。 リモートMCPでは現在、Insiders機能を有効にしたユーザー限定でのリリースとなっている。パフォーマンス検証とテレメトリ収集を経て順次一般提供に移行する予定だ。慎重な段階的ロールアウトはAzure DevOpsらしい堅実な姿勢で、本番プロジェクトへの影響を最小化しながら品質を担保する意図が読み取れる。 MCP Annotations：ツールの「意図」を明文化する MCP Annotationsは、AIがツールを呼び出す際の安全性・動作特性をメタデータとして明示する仕組みだ。今回のアップデートでは以下の3種類のアノテーションが実装された。 read-only：データを読み取るだけで変更を加えない destructive：不可逆な変更を伴う可能性がある openWorld：外部リソースへのアクセスを含む これは単なる「ラベル付け」ではない。AIエージェントがツールの組み合わせを自律的に選択する場面で、誤って破壊的な操作を実行するリスクを構造的に低減する設計だ。特にCI/CDパイプラインやワークアイテムの一括更新といった操作が絡むシナリオでは、このメタデータの存在が安全運用の要になる。 Wikiツール群の再設計：「数よりも質」へ MCPサーバー設計上の難題として公式が認めているのが、Azure DevOpsがカバーするサーフェス領域の広さだ。ツールが増えれば増えるほどLLMの性能が低下するというトレードオフがあり、今回はWikiツールを皮切りに関連ツールの統合が始まった。 新ツール名 種別 統合前のツール wiki 読み取り専用 wiki_get_page, wiki_list_pages, wiki_list_wikis など5ツール wiki_upsert_page 書き込み wiki_create_or_update_page search_wiki 検索 同名ツール このアプローチはAIエージェント設計の基本原則に沿っている。ツールの数が少なくコンテキストが明確なほど、LLMの推論精度と応答速度は向上する。今後他のツール群にも同様の整理が展開される見通しだ。 ローカルMCPサーバーへのPAT認証対応 ローカルMCPサーバーでは、個人アクセストークン（PAT）による認証がサポートされた。GitHub Copilotをはじめとする外部クライアントとの接続設定が大幅に簡略化される。特にオンプレミス環境やプロキシ環境下での開発が多い日本の大企業にとって、認証まわりの選択肢が増えることは運用の自由度向上に直結する。 Elicitationsと MCP Apps：まだ試験段階 Elicitations（操作実行時の対話的な情報収集）はプロジェクト選択などに対応したが、コミュニティからの需要が限定的として限定展開にとどまっている。フィードバックを求めている段階だ。 MCP Appsは実験的機能として、複数ツールの連鎖呼び出しを「ワークフロー」として定義する仕組みだ。mcp_app_my_work_item で自分のワークアイテム一覧を一気に操作できる。現時点では mcp-apps-poc ブランチ限定の検証フェーズだが、方向性は面白い。 実務への影響 今すぐ試せること PATを使ったローカルMCPサーバーとGitHub Copilotの連携設定 Insiders有効ユーザーはWIQLクエリの実験的利用 Wikiツール再設計後の構成変更（既存の mcp.json を要更新） 注意点 ツール統合に伴い、既存の設定ファイルや自動化スクリプトの修正が必要になる場合がある。特に wiki_get_page 系ツールを直接指定している設定は早めに棚卸しを リモートMCPはパブリックプレビュー中。本番プロジェクトへの本格導入は一般提供（GA）後が無難 中長期で注目すべきこと MCP Annotationsが浸透することで、AIエージェントによるAzure DevOps操作の「安全な自動化範囲」が明確になる。ここが整備されると、CI/CDの部分的な意思決定をエージェントに委ねるアーキテクチャが現実味を帯びてくる 筆者の見解 Azure DevOpsのMCP対応は、地味だが着実に「使えるもの」に近づいている。WIQLの対応とAnnotationsの整備は、単なる機能追加ではなくAIエージェントとの協調設計に向けた基盤整備だ。 ...

Azure Developer CLI（azd）にGitHub Copilotが統合された。バージョン1.23.11以降、azd initでのプロジェクト自動スキャフォールディングと、デプロイ失敗時のインテリジェントなエラー解決支援という2つの機能が追加されている。地味なアップデートに見えて、実際に使ってみると開発体験が大きく変わる。 azd × GitHub Copilot統合の概要 今回の統合は大きく2つの機能からなる。 ① Copilotによるプロジェクト初期化（azd init） azd initを実行すると「Set up with GitHub Copilot (Preview)」というオプションが表示される。これを選ぶと、Copilotがリポジトリのコードを解析し、言語・フレームワーク・依存ライブラリをもとにazure.yamlとBicepインフラテンプレートを自動生成してくれる。 たとえばExpress.jsとPostgreSQLを使ったNode.jsアプリなら、以下を自動で生成する： azure.yaml（ホストタイプや言語設定） Azure Container Apps用のBicepモジュール Azure Database for PostgreSQL用のBicepモジュール 従来は「Container AppにすべきかApp Serviceにすべきか」をドキュメントで調べ、Bicepを手書きする必要があった。この判断と実装をCopilotが引き受けてくれる形だ。 重要なのは変更前にpreflight checkが走る点。gitの作業ディレクトリがクリーンであることを確認し、MCP（Model Context Protocol）サーバーへのアクセス許可を事前に確認する。何が書き換わるかをユーザーが承認してから初めてファイルが更新される設計は、AIツールとして誠実なアプローチだ。 ② デプロイエラーの自動トラブルシューティング azd provisionやazd upが失敗したとき、従来は「エラーメッセージをコピー → Stack Overflow検索 → az CLIで修正 → 再実行」という手順を踏んでいた。この作業ループが、Copilot統合によってターミナル内で完結する。 エラー発生時は4つの選択肢が表示される： 選択肢 内容 Explain エラーの平易な解説 Guidance 修正手順のステップバイステップ案内 Diagnose and Guide 原因特定＋修正の自動適用（要承認）＋再実行 Skip 自分で対処 対応可能なエラーにはMissingSubscriptionRegistration（サブスクリプションにリソースプロバイダーが未登録）、SkuNotAvailable（該当リージョンにSKUが存在しない）、StorageAccountAlreadyTaken（ストレージアカウント名の重複）などが含まれる。これらはAzureデプロイ初心者がよく踏む落とし穴であり、対応方法を検索する時間を大幅に削減できる。 利用条件 azd 1.23.11以降（azd versionで確認、azd updateで更新） GitHub Copilotサブスクリプション（Individual / Business / Enterprise） GitHub CLI（gh）がインストール済みでログイン済みであること 実務への影響 日本のエンジニアが特に恩恵を受けるのはオンボーディング局面だ。 ...

Azure Virtual Desktop（AVD）のApp attach機能が、Windows Server 2022およびWindows Server 2025のセッションホストに正式対応した。これまでクライアントOS（Windows 10/11）限定だったこの機能が、サーバーOSにも開放されたことで、VDI基盤の設計自由度が大きく広がる。 App attachとは何か App attachは、アプリケーションをOSイメージに焼き込まずに、MSIXアプリパッケージとして動的にアタッチ・デタッチできる仕組みだ。従来のゴールデンイメージ管理の悩み——「アプリを追加するたびにイメージを再作成・再展開しなければならない」——を根本から解消できる。 具体的には以下のような構成が可能になる： ベースイメージは最小構成で管理し、アプリはパッケージとして別管理 ユーザーやグループに応じてアプリを動的に割り当て アプリの更新はパッケージの差し替えで完結し、イメージ再展開が不要 この仕組み自体は以前から存在していたが、Windows Server系のセッションホストでは使えなかった。 なぜ今回の対応が重要か 日本の大規模エンタープライズ環境では、Windows Server系のRDS（リモートデスクトップサービス）ベースのマルチセッション構成が依然として多い。Windows 10/11マルチセッション（Enterprise multi-session）が理想の移行先ではあるが、ライセンス形態や既存アプリの互換性、運用チームの習熟度などを理由に、Windows Serverセッションホストを維持しているケースは珍しくない。 そのような環境でもApp attachが使えるようになったことは、移行を急がずに運用改善を進められるという点で現場にとって大きな意味を持つ。「クライアントOSに全部移してからじゃないと使えない」という制約がなくなった。 実務での活用ポイント 1. イメージ管理の工数削減から手をつける まずはアプリ更新頻度が高いもの（ブラウザ、Officeアドイン、業務系クライアントツール等）をApp attachに移すだけでも、イメージ再作成・展開サイクルを大幅に減らせる。全部一度に移す必要はない。 2. Windows Server 2025への移行計画と組み合わせる Windows Server 2022のサポートは2026年10月まで。この機会にWindows Server 2025への移行計画と並行して、App attachの導入検討を進めると二重の投資効果が得られる。 3. Azure Files + App attach の組み合わせが鉄板 パッケージストレージにはAzure Filesが推奨される。SMBプロトコルでのアクセス、Entra ID（旧AAD）との統合、ゾーン冗長ストレージ（ZRS）によるHA構成まで、Azureで完結する構成が組める。 4. FSLogixとの棲み分けを明確に FSLogixはプロファイルの永続化、App attachはアプリの動的配布と役割が異なる。両方を適切に組み合わせることで、ステートレスなセッションホスト設計が実現できる。 実務への影響 AVDを既に導入している組織にとっては、追加コストなしで管理効率を上げられるアップデートだ。一方、まだオンプレRDS環境を維持している組織にとっては、クラウド移行の障壁がまた一つ下がったことを意味する。 Windows Server 2025対応という点は特に注目で、最新のサーバーOSでAVDを展開しようとしている組織が、最初からApp attachを設計に組み込める。「後から追加」ではなく「最初から正しい設計で始める」選択が取りやすくなった。 筆者の見解 AzureのVDI基盤としての完成度は着実に上がっている。App attachのサーバーOS対応は地味に見えるが、日本の現場事情を考えると相当に実用的な改善だ。 Windowsデスクトップ仮想化の歴史は長く、「アプリとOSを分離したい」という課題は20年前から変わっていない。技術的には正しい方向に進んでいるし、AVDという統合プラットフォームで這いずり回るように解決されてきた課題が、ようやくひとつずつ整理されてきた印象がある。 筆者が気になるのは、こういった地道な機能拡充が現場に届いているかどうかだ。「AVDって高くないですか」「設定が複雑で」という声は今でもよく聞く。機能が充実しても、それを使いこなせる人材と、正しい設計を描ける人材が現場にいなければ宝の持ち腐れになる。 Azureのプラットフォームとしての信頼性は揺るがない。あとは現場がそれをどう活かすか——情報を追いかけ続けるより、実際に手を動かして設計・運用の経験を積む方が、今の時代には圧倒的に価値がある。まずは検証環境でApp attachを触ってみることをお勧めしたい。 出典: この記事は App attach in Azure Virtual Desktop now supports Windows Server 2025 and Windows Server 2022 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftがソブリンクラウド戦略を大きく前進させた。Azure Local DisconnectedとMicrosoft 365 Local Disconnectedが正式GA（一般提供開始）となり、完全ネットワーク分離環境でもAzureのガバナンスと生産性スイートをフル活用できるようになった。さらにFoundry Localが大規模マルチモーダルLLMのオフライン実行に対応し、クラウドに繋がらない環境でもエンタープライズグレードのAI推論が可能になった。 Azure Local Disconnectedとは何か Azure Local Disconnectedは、インターネット接続がない完全エアギャップ（air-gapped）環境においても、Azureのポリシー管理・ガバナンス・コンプライアンス機能を維持しながら基幹インフラを運用できるソリューションだ。 Microsoft 365 Local Disconnectedを利用すれば、Exchange Server、SharePoint Server、Skype for Business Serverなどのコアワークロードを少なくとも2035年までサポートを受けながらオンプレミスで継続運用できる。データの管理・アクセス制御・コンプライアンスをすべて自組織の手元で完結させる、まさに「クラウドの恩恵を受けながら外には出さない」という構成が実現する。 Foundry LocalがNVIDIA・AMD GPUで大規模LLMをオフライン実行 今回の発表でもう一つ注目すべきは、Foundry Localの大幅な機能拡張だ。 Foundry Localはこれまでデスクトップ・ラップトップ・IoTデバイス上での小規模言語モデル（SLM）実行を主な用途としていたが、今回からNVIDIAおよびAMDチップを搭載した「ワークステーションクラス」以上のインフラ——エッジやエアギャップ環境を含む——にまで対応範囲を拡大した。これにより、マルチモーダルな大規模LLMをオンプレミスや閉域プライベートクラウド上でオフライン実行できるようになった。 なお、Microsoft独自のAIチップ「Maia 200」についてはFoundry Localでの対応は現時点では予定されていない。Maiaチップはデータセンター内のAzureワークロードに特化して最適化されており、「どこで動いているかを正確に把握できる」精度で制御できるためとのことだ。Foundry LocalはあくまでAMD・NVIDIAエコシステムを中心に展開する方針だ。 規制爆発時代のソブリン要件 MicrosoftのAIインフラ担当GM、アリスター・スピアーズ氏によれば、現在世界では4日に1本のペースでAI・サイバーセキュリティ・データプライバシーに関する新規制が導入されており、69カ国で1,000以上の政策イニシアティブが動いているという。 Satya Nadellaも「あらゆる地域・国でデータ主権の管理をどう確保するかが、今や誰にとっても最前線の課題だ」と明言した。Microsoftはソブリン要件を「パブリッククラウド型主権」「プライベートクラウド型主権」「ソブリンパートナーエコシステム」の3層ポートフォリオとして整理し、顧客がニーズに応じて組み合わせられる設計にしている。 実務への影響——日本のエンジニア・IT管理者が押さえるべきポイント 日本においても、政府・防衛・医療・金融などの分野では「クラウドを使いたいがデータを外に出せない」という制約は根強い。今回のGAはその制約を正面から解決する選択肢となる。 明日から動けるポイントを3つ挙げる： 既存オンプレミス環境の棚卸し: Exchange ServerやSharePoint Serverを「クラウド移行できない負債」として抱えている組織は、2035年サポート延長を前提にAzure Local DisconnectedでAzureガバナンスに統合する設計が現実的な道筋になる。 Foundry LocalをAI PoC環境として評価する: クラウドにデータを送れない機密性の高い業務でも、オンプレミスのGPUラックでLLMを動かせるようになった。まずは社内の検証環境でFoundry Localを試し、どのモデルがどの業務に使えるか感触をつかむのが早道だ。 ソブリン要件をコンプライアンス部門と共に整理する: 「4日に1本」の新規制という環境下では、設計段階からデータ主権・残存場所・アクセス制御の要件を文書化しておかないと後で詰む。Azureのポリシー管理機能を使って制御の証跡を自動で取れる構成にしておくことが、将来の監査対応コストを大幅に下げる。 筆者の見解 Microsoftのソブリンクラウド戦略は、方向性として正しいと思う。AIが実業務に入り込んでいくにつれ、データをクラウドの外に出せない用途は確実に増える。そこに対して「Azureの統合管理はそのまま維持しながら、物理的にはどこにでも置ける」という設計で応えようとしているのは、プラットフォームベンダーとしての強みを生かした正攻法だ。 ただし率直に言うと、AI推論の性能競争という観点ではFoundry Localが対応するモデルの「質」がどこまで上がるかが今後の肝になる。インフラが整うのは大前提として、そこで動くモデルが実際の業務に耐えうる精度を出せるかどうかが問われる。Microsoftには、プラットフォームの整備だけで満足するのではなく、そこで動かせるモデルの選択肢と性能についても手を抜かずに前進してほしい——それができる組織であることは間違いないのだから。 エージェントの管制塔としてのMicrosoft Entra IDと、Foundry Localによるオンプレミス推論の組み合わせは、長期的なアーキテクチャとして筋が良い。日本の大型エンタープライズこそ、この構成を早めに評価しておく価値がある。 出典: この記事は Azure Local Disconnected Generally Available; Foundry Local Supports Large AI Models Offline の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Azure Blob Storageを業務で使っている組織にとって、見逃せないアップデートが正式リリース（GA）された。Microsoft Defender for Storageの「自動マルウェア修復（Automated Malware Remediation）」機能だ。悪意あるファイルを検出した瞬間に自動でソフト削除し、手動対応なしにストレージを清潔に保てる。 何が起きたのか Defender for Storageのマルウェアスキャンは以前から存在していたが、「検出はする、対応は人間」という構図だった。今回GAになった自動修復機能では、アップロード時スキャン（On-Upload）とオンデマンドスキャンの両方で悪意あるBlobが検出されると、即座にソフト削除（Soft Delete）が実行される。 ソフト削除はAzure Blob Storage標準の機能で、削除したデータを一定期間（デフォルト7日、最大365日）保持する。つまり「アクセス遮断」と「証拠保全」が同時に達成できる。 主な仕様 有効化単位: サブスクリプション全体またはストレージアカウント単位で選択可能 Soft Delete未設定の場合: 機能有効化時にDefenderが自動でSoft Deleteを有効にする Blobインデックスタグ: 悪意ありと判定されたBlobには自動でタグが付与され、復元後も追跡可能 コスト: ソフト削除期間中のストレージコストはアクティブデータと同等 なぜこれが重要か 日本のエンタープライズでAzure Storageを使うシーンは多岐にわたる。社内ポータルへのファイルアップロード、Power Automateによる自動処理のステージングエリア、バックアップ先、そして生成AIのRAGデータソース。これらのシナリオではユーザーや外部システムからのBlobアップロードが常時発生し、マルウェア混入のリスクがある。 これまでは「Defenderがアラートを出す→SOCが確認する→削除する」というフローが必要だった。深夜・休日に悪意あるファイルがアップロードされても、翌朝まで誰も動けないというケースは珍しくない。自動修復はその窓を閉じる。 実務への活用ポイント 1. 既存のStorage Account設定を確認する Soft Deleteの保持期間はデフォルト7日だが、コンプライアンス要件やインシデント調査の実績を踏まえて変更を検討する。マルウェアの証跡を30日保持したいなら、Storage AccountのSoft Delete設定で変更しておく。 2. Blob Versioning との組み合わせに注意 Blobバージョン管理を有効にしているStorageアカウントでは、ソフト削除の復元手順が通常と異なる。公式ドキュメント「Manage and restore soft delete for blobs」を事前に確認しておくことを推奨する。 3. サブスクリプション全体 vs アカウント単位 組織内に開発・テスト・本番の複数環境がある場合、テスト環境で誤検知が発生すると全環境で無効化したくなる衝動に駆られる。アカウント単位で有効化できるため、本番環境を優先して適用し、テスト環境は段階的に展開する運用が現実的だ。 4. ログ・アラートパイプラインの見直し 自動修復が動いた場合でも、Defender for Cloudセキュリティアラート・Event Grid・Blobインデックスタグという3つのシグナルが残る。SIEMやAzure Monitor Alertsと連携させることで、「自動で処理されたが、何があったかは把握している」状態を維持できる。 筆者の見解 これは地味だが、実務的な価値が高いアップデートだと評価している。 セキュリティの理想は「人間が関与しなくても安全な状態が維持される仕組み」だ。検出と対応の間に人間のアクションが必要な設計は、その隙間がそのままリスクになる。今回の自動修復は「Non-Human Identityの管理」と同じ文脈で捉えられる——人間のボトルネックを取り除き、システムが自律的に安全を守る方向への一歩だ。 特に評価したいのは、ソフト削除という「後で見直せる」設計にしたことだ。自動的に完全削除してしまうと、誤検知のダメージが大きく、組織が機能を無効化してしまうリスクがある。隔離しつつ復元可能にするアプローチは、セキュリティと運用のバランスとして正しい。 Azure Storageを基盤として使っているのであれば、有効化を検討する理由はほぼない。コスト面でも「Soft Delete期間中のストレージ料金のみ」と明快だ。設定に10分かけるだけで、深夜の悪意あるアップロードに対する自動防衛線が張れる。これがプラットフォームとしてのAzureの強みだと思う。 ...

Azure Synapse Analyticsを本番運用している組織にとって、Microsoft Fabricへの移行はここ1〜2年の最大の課題の一つだ。その移行作業を自動化・アシストする「Migration Assistant for Fabric Data Warehouse」がパブリックプレビューとして公開された。FabCon Atlanta 2026に合わせたタイミングでの世界展開であり、Microsoftが本格的にSynapse→Fabric移行を後押しする姿勢を明確にした格好だ。 Migration Assistantとは何か Migration Assistantは、既存のAzure Synapse Analyticsワークロードを分析し、Microsoft Fabric Data Warehouseへの移行可能性を評価・実行を支援するツールだ。「アセスメントファースト」アプローチを採用しており、いきなり移行作業に入るのではなく、まず既存のスキーマ・クエリ・ストアドプロシージャの互換性を事前チェックする設計になっている。 具体的には以下のフローで動作する： 互換性スキャン — Synapseの既存オブジェクト（テーブル、ビュー、ストアドプロシージャ等）をスキャンし、Fabricで動作するか否かを判定 リスク分類 — 移行困難な箇所を「高リスク／中リスク／低リスク」に分類し、対処方針を提示 移行実行支援 — 互換性のあるオブジェクトから順次移行を進め、問題箇所は修正ガイダンスを提供 SynapseとFabricではT-SQLの実装に微妙な差異があり、これが移行の最大の落とし穴だった。Migration Assistantはその差異を事前に可視化することで、「移行してみたら動かなかった」という状況を減らすことを目的としている。 なぜいまFabricへの移行が重要か MicrosoftはAzure Synapse Analyticsの新機能開発を事実上フリーズし、投資の軸足をMicrosoft Fabricに移している。Synapseが消えるわけではないが、今後の機能強化・AI統合・パフォーマンス改善はFabricが主戦場だ。 Fabricは単なるDWHの後継ではなく、データレイク・データウェアハウス・リアルタイム分析・Power BIレポートを統合した「オールインワン分析プラットフォーム」として設計されている。OneLakeというストレージ統合レイヤーにより、これまでサイロ化していたデータを一元管理できる点が大きな価値だ。日本でもFabricのトライアルや導入が急増しており、Synapse利用組織にとって「いつ移行するか」は避けられない議題になっている。 日本のIT現場への影響 Synapse Analyticsは2019〜2022年頃にかけてデータ基盤刷新プロジェクトで多く採用された。当時のプロジェクトが本番稼働から3〜5年を経て「次の刷新」フェーズに入りつつある今、Migration Assistantの登場は非常にタイムリーだ。 IT管理者・データエンジニアが明日から取れる行動： まず現状把握から始める: Migration AssistantのAssessment機能だけでも先行実施し、自社のSynapse環境の「移行難易度スコア」を把握する。移行計画の根拠データになる ハイリスク箇所を優先的に調査: Assessment結果で高リスクに分類されたオブジェクトは、Fabric側でどう書き直すか早期に技術検証しておく 段階移行戦略の採用: 全ワークロードを一括移行するのではなく、低リスクのテーブルやシンプルなETLパイプラインから段階的に移行してチームのFabric経験値を積む OneLakeの設計を先に固める: 移行先のストレージ設計（ワークスペース分割・レイクハウスvs.ウェアハウスの使い分け）を先に決めておかないと、移行後の再設計コストが高くつく パブリックプレビュー段階であることを念頭に置き、本番移行は正式GA後のロードマップと品質を確認してから判断することを推奨する。 筆者の見解 率直に言えば、「Migration Assistantが必要になる状況」自体、本来は避けられたはずだという思いがある。SynapseからFabricへの移行は、Microsoftの製品戦略の転換に伴ってユーザーが強制される再移行であり、そのコストをユーザーが負担している構図は変わらない。 とはいえ、Microsoftがツールを用意して移行をアシストする姿勢は評価したい。過去にはオンプレSQLServer→クラウドでも似たような移行支援が整備されてきた歴史があり、Microsoftが大規模プラットフォーム移行においてツール整備を怠らない点は信頼できる。 Microsoft Fabricは統合プラットフォームとしての設計思想が明確で、「分析基盤のOneStop化」という方向性は正しい。データレイク・DWH・BIをバラバラのサービスで維持するコスト（金銭的にも運用的にも）は見た目より大きく、統合によって全体最適を得る発想は「道のど真ん中を歩く」選択だと思う。 Migration Assistantが成熟すれば、Synapse資産を持つ企業の意思決定を後押しする重要なピースになりうる。パブリックプレビューの今こそ、自社環境のAssessmentを回してフィードバックを積み重ねる好機だ。Fabricに本腰を入れるMicrosoftには、このツールをGA時にはさらに磨き上げた状態で届けてほしい。 出典: この記事は Public Preview: Migration Assistant for Fabric Data Warehouse (Synapse Analytics → Microsoft Fabric) の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Kubernetesクラスターのバックアップ設定に、これまで何ステップもかかっていた——そんな運用の煩わしさを、Azureが一気に解消しようとしている。2026年4月16日に公開されたAzureアップデートは、現場のエンジニアにとってすぐに役立つ改善が揃っている。 AKSバックアップがワンコマンドに 最大のトピックは、Azure BackupによるAKS（Azure Kubernetes Service）クラスターのワンコマンドセットアップだ。これまで、AKSクラスターのバックアップを有効化するには複数のリソース設定・権限付与・拡張機能のインストールを順番に実施する必要があり、手順の抜け漏れによる設定ドリフトがしばしば問題になっていた。 今回の更新により、クラスター状態・永続ボリューム・設定情報を一括でキャプチャするバックアップを、単一コマンドで有効化できるようになった。Azure Governmentを含む環境でも対応しており、規制業界や省庁系クラウドを利用している組織にとっても朗報だ。 SRE AgentとAzure Lighthouseで多テナント管理を効率化 マルチテナント環境を管理するMSPやエンタープライズSREチームには、SRE AgentとAzure Lighthouseの組み合わせが注目ポイントだ。テナントをまたいだアクセス委任と運用の一元可視化が可能になり、ポリシー適用の一貫性も向上する。複数の顧客環境を並行管理している運用チームにとっては、管理コストの削減に直結する機能だ。 Smart Tier GAと暗号化制御の独立化 BlobストレージおよびAzure Data Lake Storageのスマート階層化（Smart Tier）が一般提供（GA）に到達した。アクセスパターンを自動分析してデータを適切なストレージ層に移動させることで、コスト削減とレスポンス性の両立を自動で行う。手動ライフサイクルポリシーの管理から解放される効果は大きい。 また、Azure Filesが転送中暗号化設定をプロトコルごとに独立して管理できるようになった。これにより、特定のプロトコルだけ暗号化設定を強化したい場合に、サービス全体の設定を変更せずに対応できる。セキュリティ要件の厳しい環境での柔軟な運用に役立つ。 NVMeディスクのSite RecoveryとAKSネットワーク拡張 NVMeディスクを搭載した高パフォーマンスVMのSite Recovery対応が追加された。AI/MLワークロードや高スループットが求められるシステムのディザスタリカバリ計画を検討している組織には見逃せない対応だ。 AKSのネットワーク面では、StandardV2 NATゲートウェイのサポートとCNI オーバーレイCIDR拡張がプレビューで登場。大規模クラスターにおけるアウトバウンド通信のスケーラビリティ課題に対応するものだ。 実務への影響——日本のエンジニア・IT管理者へ AKSバックアップのワンコマンド化は、今日から使える改善だ。本番AKSクラスターにバックアップを設定できていない、あるいは設定手順が属人化している環境では、この機会に標準化を進めるべきだろう。CI/CDパイプラインにバックアップ有効化を組み込む際のハードルも大きく下がった。 Smart TierのGAについては、ストレージコストの最適化施策として改めて棚卸しの価値がある。アクセス頻度が不明確な大量データを抱えている場合、ライフサイクル設定を手動で維持するよりも自動化された方が長期的なコスト予測が立てやすい。 暗号化の独立設定は、コンプライアンス要件が細かく定義されている金融・医療・公共系の環境で特に重要だ。「全体の設定を変えるとリスクがある」という理由で後回しにされていたセキュリティ強化を、局所的に推進できるようになる。 筆者の見解 Azureはこのアップデートで、「使うのが大変」という運用上の摩擦を着実に減らしている。AKSバックアップのワンコマンド化ひとつとっても、現場のエンジニアが抱えていた手順の煩雑さを正面から解決しようとする姿勢が見える。 Kubernetesは「使いこなせれば強力だが、運用コストが高い」という認識が日本のIT現場ではまだ根強い。しかし今回のような改善が積み重なっていくことで、その認識は確実に変わっていく。AKSを本番に踏み切れていない組織の担当者が、「バックアップがこんなに簡単に設定できるなら」と判断する一押しになり得る。 Azureの強みはプラットフォームとしての総合力だ。Kubernetes管理、ストレージ最適化、ディザスタリカバリ、マルチテナント管理——それらを一貫した基盤の上で扱えることに、今回のアップデートは改めて意味を与えている。個別機能の充実が、全体最適につながる構造だ。 コスト最適化とセキュリティ強化は、どの組織でも永続的なテーマだ。Smart TierとFile Syncの暗号化独立設定はその両方に応えるもので、地味ながら現場インパクトは大きい。「知らなかった」ではなく、今すぐ設計に取り込む価値がある。 出典: この記事は Azure Backup single-command setup for AKS clusters (April 16 Update) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがAzure AI Fundamentals認定資格の中核である試験を、AI-900からAI-901へ刷新すると発表した。2026年6月30日にAI-900は廃止され、それ以降は新試験AI-901の合格が認定取得の要件となる。これは単なる試験更新ではなく、資格体系そのものの方向性を問い直す大きな転換点だ。 AI-900とAI-901、何が変わったのか 最も目を引く変更はPythonコーディング知識が必須になった点だ。AI-900は非技術者も含む「AIを概念として理解したい人」向けに設計されており、コーディングスキルは一切不要だった。新しいAI-901は「AIソリューションを実際に構築したい技術者の入門」へと対象を絞り込んでいる。 比較項目 AI-900（旧） AI-901（新） 対象者 非技術者・技術者初級 実装を目指す技術者初級 コーディング要件 不要 Python基礎構文・プログラミング概念 主な焦点 AIとは何か Foundryを使ってどうAIアプリを作るか 評価スキル Azure AIサービスの概念理解 Microsoft FoundryによるAIソリューション実装 AI-901では、Microsoft Foundryを軸にした生成AIアプリやエージェントの実装、テキスト・音声・コンピュータービジョン・情報抽出といったAIワークロードへの実践的な対応が問われる。Azureリソースのプロビジョニング経験も前提として求められる。 なぜこれが重要か 「AIについて説明できる人」は日本の職場にも急増している。しかし企業が本当に必要としているのは、AIを使って実際に何かを動かせる人だ。今回の資格刷新は、そのギャップを認定体系の側から埋めようとする動きと読める。 とりわけ注目すべきはMicrosoft Foundryへの集中だ。FoundryはAzure上でAIモデルのプロビジョニングからエージェント開発まで一気通貫で行えるプラットフォームで、Microsoftが「AIプラットフォームとしてのAzure」の核に据えた存在だ。この認定資格がFoundryを全面に押し出したことは、今後のAzure AI開発のメインルートがFoundryに集約されていくことを示唆している。 実務への影響——エンジニア・IT管理者が今押さえるべきこと 既存のAI-900保有者への影響はない。 認定資格そのものは継続するため、再取得や更新手続きは不要だ。ただし「より広いスキルセットをアピールしたい」場合はAI-901を任意で受験できる。 実務上の具体的なアクションとして以下を提案したい。 Foundry未経験なら今が学び時: AI-901に向けた学習コンテンツはMicrosoft Learnで整備が進んでいる。ベータ試験期間中は受験料が割引される場合が多く、コスト面でも取り組みやすい。 チームのAI人材育成基準を見直す: AI-900で「AIの概念を理解している」ことを証明していたエンジニアに、AI-901相当のFoundry実装スキルを追加習得させるロードマップを引くタイミングだ。 Python入門を後回しにしない: AI-901ではPython基礎が前提となる。Azure寄りのバックグラウンドを持つエンジニアでもPythonを避けられない時代になったと考えたほうがいい。 筆者の見解 正直なところ、この方向転換は歓迎したい。AI-900は「AIを怖がらせないための入り口」として機能していたが、資格を取っても実務では何もできないという状況が続いていた。そこへ「実装できることを証明する」試験を入門レベルでも要求するようにしたのは、資格の形骸化を防ぐ正しい判断だ。 Microsoft Foundryへの集中も戦略的に筋が通っている。企業がAzureを使い続ける理由のひとつは「Microsoftのプラットフォームに統合された形でAIを安全に動かせる」ことにある。AIモデルの選択肢は複数あれど、それを管理・運用するプラットフォームとしてFoundryが成熟すれば、Azure全体の価値は高まる。 一方で少し気になるのは難易度の急上昇だ。AI-900は「AIを概念として知りたいビジネス職」にも広く門戸を開いていた。AI-901は明確に技術者向けにシフトしたことで、非エンジニアが「Azureで認定を取る最初の一歩」として選べる試験が事実上なくなる。Microsoftがこの層向けに別途の入口を用意するかどうかは引き続き注目したい。 いずれにせよ、「概念を知っている」ではなく「実際に動かせる」を評価軸にしたこの変化は、日本のIT現場においても意味が大きい。資格体系がそこに追いついてきたことを、素直に前進と評価したい。 出典: この記事は Evolving the Microsoft Certified: Azure AI Fundamentals Certification の内容をもとに、筆者の見解を加えて独自に執筆したものです。

SOCの「情報過多問題」に、AIアシスタントが本格参戦 Microsoftが2026年4月のDefender XDR月次アップデートで、SOC（セキュリティオペレーションセンター）チームの業務を根本から変えうる機能群を一挙に投入した。単なる機能追加ではなく、「脅威分析の起点をどこに置くか」というアーキテクチャレベルの転換を示す内容だ。特に注目したいのは、Security Copilotの会話型インターフェースのDefenderポータルへの組み込みと、非人間アイデンティティ（NHI）管理の本格強化という2つの軸である。 Security Copilotがポータルに「住み込む」 これまでSecurity Copilotは、Defenderのサイドバーや独立したページから呼び出すスタイルだった。今回のアップデートでは、Defenderポータルに完全に埋め込まれたチャット体験が提供され、アナリストが調査コンテキストを保持したまま会話形式で脅威を追える設計になった。 具体的には、アラート・アイデンティティ・デバイス・IPアドレスといった調査対象に対して、会話の流れの中で「この挙動は正常範囲か？」「このIPは過去に悪用された実績があるか？」のように問いかけながら深掘りできる。CopilotはDefenderのテレメトリをグラウンドとして使うため、一般的なLLMへの問いかけと異なり、自社環境のデータと紐づいた回答が返ってくる。 あわせて、Security Alert Triage Agentという「エージェント型トリアージ」機能が拡張された。フィッシング・ID・クラウドのアラートを単一のエージェントが統合処理し、それが本物の脅威か誤検知かを自然言語で説明しながら判断を示す。ステップバイステップの根拠も提示されるため、アナリストが結果を鵜呑みにせず検証できる設計になっているのは好感が持てる。 IDセキュリティが「見えるもの」になる もう一つの大きな柱が、Identity Security Dashboard（パブリックプレビュー） の登場だ。これまで断片的だったIDリスクの全体像が、ひとつのダッシュボードに集約される。 主な内容： IDプロバイダー・オンプレID・SaaS ID・PAM/IGA統合・NHIの概要カード 特権アカウント・リスクユーザー・弱い設定のドメインのウィジェット 0〜100スコアのIDリスクスコア（侵害の可能性と影響度を複合評価） 成熟度マッピングページ：Connected → Protected → Fortified → Resilient の段階ごとのカバレッジスコアと優先タスク 特に目を引くのが、非人間アイデンティティ（NHI）専用タブの追加だ。Microsoft Entra IDのアプリ、ADサービスアカウント、Google WorkspaceアプリやSalesforceアプリまで対象に含まれ、リスクあり・過剰権限・未使用・外部公開といった分類で一覧表示できるようになった。 実務への影響：日本のIT管理者が今押さえるべき点 1. SOCがない組織でもトリアージの「補助輪」として使えるか試す価値あり Security Alert Triage AgentはSOCアナリスト向けと説明されているが、専任SOCを持たない中堅企業でも、アラートの一次判断にかかる工数削減の効果は期待できる。まずはパブリックプレビュー環境で動作を確認したい。 2. NHIの棚卸しを今すぐ始める 自動化・AI活用が進むほど、ワークロードIDやサービスアカウントの数は増え続ける。「誰が何にアクセスできるか」が把握できていない組織では、自動化の恩恵を受ける前にリスクが先に育つ。NHI専用タブはその棚卸しの起点として非常に使いやすい構成になっている。 3. Just-In-Timeアクセス検討のトリガーに 特権アカウントの可視化が進んだ今こそ、常時アクセス権を見直す機会だ。IDリスクスコアが高い特権アカウントを洗い出し、JITアクセスへの移行を段階的に進めることを推奨したい。 筆者の見解 Defender XDRがこの方向性に向かっていることは、正しいと思う。特にNHIの可視化強化は、業務自動化を本気で進めようとする組織が必ず直面する「IDのカオス」に正面から向き合う施策で、地味だが実質的に重要な前進だ。 Security Copilotの会話型統合については、「ツールを行き来しなくていい」というUXの改善は間違いなく価値があるし、テレメトリと紐づいた回答という設計思想は正しい。ただ、こういった機能の真価はデプロイしてから半年後に問われる。「使ってみたら結局アナリストが素通りする」にならないよう、UIの磨き込みと誤検知率の継続的な改善をしっかり続けてほしい。 Microsoftのセキュリティポートフォリオは、M365・Azure・Entra IDを統合的に使える環境にいる組織に対して、他では代替しづらいプラットフォームとしての強みを持っている。エージェントの管制塔としてEntra IDを中心に据え、NHIの安全な自動化基盤を作り込む方向は長期的に筋が通った戦略だ。この軸をぶらさずに磨き続けることを期待したい。 セキュリティを「禁止で守る」から「仕組みで守る」へ。そのシフトを加速するツールとして、今回のアップデートは評価に値する内容だ。 出典: この記事は Microsoft Defender XDR April 2026 Update Supercharges SOCs with Copilot Chat, Identity Risk Scoring, and New Threat Defenses の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Azureのストレージコストを「考えずに」最適化できる時代が来た。Microsoftは2026年4月、Azure Blob StorageおよびData Lake Storageのスマートティア（Smart Tier） を正式リリース（GA）した。2025年11月のIgniteで公開プレビューが始まってから約5ヶ月、早くも本番利用可能な状態に到達している。 ストレージコストは「気づいたら積み上がっている」コストの代表格だ。日本のクラウド利用現場でも、「とりあえずホット層に全部入れてある」「ライフサイクルポリシーを書いたけど誰もメンテしていない」という構成は珍しくない。スマートティアはそこへのひとつの回答になる。 スマートティアとは何か スマートティアは、オブジェクトごとの最終アクセス時刻を継続的に評価し、3つの層を自動で行き来させるフルマネージドの機能だ。 状態 移行先 条件 頻繁にアクセス ホット アクセスがあれば即座に昇格 30日間アクセスなし クール 自動降格 さらに60日間アクセスなし コールド 自動降格 重要なのは、データが再びアクセスされた瞬間にホットへ即昇格し、ティアリングサイクルがリセットされる点だ。GetBlobやPutBlobといった読み書き操作がトリガーとなる一方、GetBlobPropertiesのようなメタデータ操作はサイクルに影響しない——この設計の細かさが実務では効いてくる。 公開プレビュー段階のデータとして、スマートティアで管理された容量の50%以上が自動的にクール・コールド層へ移行したと報告されている。Azure Data Explorer（ADX）での採用事例でも、クエリのホットデータは即座にアクセス可能なまま、低頻度データはコスト効率の良い層へ自動移動するという動作が確認されている。 有効化の方法 設定はシンプルに設計されている。 新規ストレージアカウント作成時 ゾーン冗長構成（ZRS）のストレージアカウントを作成する際、デフォルトアクセス層として「スマート」を選択するだけ。Azure PortalとAPIの両方から設定可能だ。 既存アカウントへの適用 ゾーン冗長が有効になっている既存アカウントであれば、BlobアクセスTierを「default」から「smart」へ切り替えるだけで有効化できる。 現時点でほぼすべてのゾーン対応パブリッククラウドリージョンで利用可能だ。Azure JapanリージョンもZRSをサポートしているため、対象範囲に入る。 実務への影響 ライフサイクルポリシーとの使い分けを整理する スマートティアはライフサイクル管理ポリシーの「代替」ではなく「補完」として位置づけるのが現実的だ。「N日後に削除」「アーカイブへの移動」といった明示的なルールはライフサイクルポリシーが引き続き担う。「アクセス頻度に応じた動的なティア移動」はスマートティアに任せる——この役割分担を意識した設計が求められる。 ZRS（ゾーン冗長）が前提条件 スマートティアはゾーン冗長（ZRS）構成のストレージアカウントでのみ有効だ。LRS（ローカル冗長）のみのアカウントでは利用できない。既存アカウントへの適用を検討する場合は、まず冗長性設定の確認が必要になる。 トランザクションコストへの注意 ティア移行には読み出しコストが発生する。ホット→クールは書き込みコスト、クール→ホットは読み出しコストが加算される仕組みだ。アクセスが不規則なデータセットでは、自動昇降格が頻繁に起きてトランザクション費用がかさむ可能性がある。稼働後1〜2ヶ月はコストモニタリングを欠かさないようにしたい。 Data Lake Storageにも対応 Azure Data Lake Storage Gen2での利用も正式サポートされた。Databricks、Synapse Analytics、Azure Data Explorerなどのビッグデータワークロードでもスマートティアが機能するため、データ基盤全体でのコスト最適化が現実的になる。 筆者の見解 ストレージの自動最適化という機能単体で見れば、これは素直に良い仕事だと思う。「使った分だけ払う」というクラウドの本来の約束に、ようやくストレージが追いついてきた感覚だ。 ライフサイクルポリシーは「設計時に正しいルールを書く」ことを前提とした仕組みだったが、現実のデータアクセスパターンは設計者の想定を裏切り続ける。スマートティアはその前提を取り払い、「観察して動かす」アプローチに切り替えている。この発想の転換は、インフラ管理の方向性として正しい。 Azureが今後目指すべきは、こういった「仕組みを作れば自動で最適化が回り続ける」機能をどれだけ積み上げられるか、だと思っている。管理者がパラメータを手で調整し続けるのではなく、意図を定義したらあとはプラットフォームが動く——そういうプラットフォームとしての成熟度が問われている。 スマートティアはその方向の一歩として評価できる。まず検証環境で有効化し、実際のアクセスパターンとコスト変化を数週間観察するところから始めてほしい。「50%がクール層へ移行した」という数字が自分の環境でどう再現されるか、試してみる価値は十分ある。 出典: この記事は Optimize object storage costs automatically with smart tier—now generally available の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

「AIで一発解決」という幻想から目を覚ます MicrosoftのAzureチームが、エージェント型AIを活用したアプリケーションモダナイゼーション（近代化）の実情をまとめたドキュメントを公開した。AI全盛の2026年初頭においても、「クリックひとつでモダナイゼーション完了」という夢には程遠い——そんな現実が、数百件にわたる実案件の経験から浮かび上がってくる。 この記事は、技術的な詳細よりも「なぜモダナイゼーションは難しいのか」という根本的な問いに正面から向き合う内容だ。AIツールに飛びつく前に読むべき、実践的な知見が詰まっている。 なぜレガシーシステムは「触りにくい」のか 多くのレガシーアプリケーションは共通の問題を抱えている。 ドキュメントの欠如: 重要なビジネスロジックが、密結合・ハードウェア依存・何年も放置されたモノリシックなコードの奥深くに埋もれている 依存関係の脆弱性: 誰も覚えていない暗黙の前提が随所に潜む 周辺システムとの深い結合: この結合こそが「ミッションクリティカル」たる所以であり、同時に変更を極めてリスキーにしている ここで重要な整理がある。「モダナイゼーション」と一言で言っても、実態は2種類に分かれる。 マイグレーション（移行） は、ビジネスロジックだけでなく実装・インターフェース・運用モデルも含めて可能な限り保存するアプローチだ。一方、メインフレームやOT機器のようにハードウェアに縛られたシステムは、リアーキテクチャ（再設計・再実装） が正解になる。どちらを選ぶかを最初に明確にしないと、プロジェクトは途中で方向を見失う。 エージェント型AIの実力と限界 エージェント型AIは確かにモダナイゼーションにかかる時間を短縮できる。コードの静的解析、依存関係の可視化、テストケースの自動生成——これらの作業でAIは明らかに価値を発揮する。 しかしドキュメントが警告するのは、ベンダーの「80%精度」という主張を鵜呑みにするなという点だ。「2026年初頭でもまだジェネレーティブAIの時代だ」と明言されている。自社のコードベース、自社のリスクプロファイルで検証するまでは、すべての主張はマーケティングとして扱え——この姿勢は、現場のエンジニアが持つべき基本的な態度だろう。 実務への影響——日本のIT現場が意識すべきこと 日本の大企業では、SAP・ERPの刷新や基幹系マイグレーションが続々と動き出している。そこにAIエージェントを組み込もうという動きも出始めている。しかしこのドキュメントが示す教訓は、日本のIT現場に直接刺さる。 「ツールより先に組織設計」 モダナイゼーションが技術問題ではなく組織問題である以上、ベンダーのデモに感動する前に「誰がビジネスロジックの最終判断をするのか」を決めることが先決だ。AIがコードを解析しても、「このロジックに業務上の意味があるか」を判断できるのは人間しかいない（今のところ）。 「AIエージェントに任せていい部分と任せてはいけない部分を分ける」 コード変換・テスト生成・依存関係の可視化はAIが得意な領域。しかしビジネスルールの解釈、リスク判断、ステークホルダー調整は人間の仕事だ。この境界を曖昧にするとプロジェクトは迷走する。 「Azureプラットフォームの上でAIを選ぶ自由を使う」 Azure AI Foundryを通じてさまざまなモデルを活用できる現在、基盤としてのAzureを活かしつつ、特定の作業に最適なAIを選べる環境が整いつつある。Microsoft基盤を捨てる必要はない——その上で動かすAIを最適化する発想が現実的だ。 筆者の見解 「AIを使えばモダナイゼーションが楽になる」という空気が業界全体に漂っているが、このドキュメントはその幻想に冷水を浴びせる内容だ。率直に言って、こういう「実際はこれだけ大変なんですよ」という記事をMicrosoftが出すこと自体は評価したい。 ただ、日本のIT現場においては、そもそも「モダナイゼーションに着手できる状態」にすら到達していない組織が多い。ドキュメントが欠如し、担当者が退職し、システムの全体像を知っている人間が誰もいない——そういう状態で「AIエージェントを活用しましょう」と言っても、AIは解析する材料すら与えられない。 本質的な問題は、AIの使い方ではなく、長年にわたって技術的負債の可視化を怠ってきたことだ。レガシーシステムの価値と複雑さを正直に計測し、リアーキテクチャかマイグレーションかを判断する。そこにこそAIエージェントの本来の価値がある。「変換」ではなく「把握」のためにAIを使う、という順序を間違えないようにしたい。 標準的な構成を選び、ベンダー推奨の理由を理解し、自分の環境で検証してから判断する——この「道のド真ん中を歩く」姿勢が、AIの時代においても変わらず重要だと改めて感じさせられる内容だった。 出典: この記事は The Realities of Application Modernization with Agentic AI (Early 2026) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIがインフラの自律運用を担う時代が、コスト面でも現実的な選択肢になってきた。Microsoftは2026年4月15日、Azure SRE Agentの新しい課金モデルを正式に適用開始した。アクティブフロー100万トークンあたりのAAU（Azure Agent Unit）消費量をベースにした従量課金制で、企業がAIエージェントに自律的なサイト信頼性エンジニアリング（SRE）を任せる際のコスト予測が格段に立てやすくなった。 Azure SRE Agentとは何か Azure SRE Agentは、障害検知・根本原因分析・自動回復といったSREの定型業務をAIエージェントが自律的に実行するサービスだ。従来、オンコール担当者が深夜に対応していたような作業の一部を、人間の介入なしに処理できる。アラート→診断→修復のサイクルを24時間稼働のNHI（Non-Human Identity）として回し続けるイメージに近い。 新課金モデルの仕組み 今回の変更の核心は「予測可能性」だ。AAUという単位は、エージェントが処理する「アクティブフロー」のトークン量に比例して消費される。これにより： 使った分だけ払う明確な従量課金 トークン消費量からコストの事前試算が可能 月額固定モデルにありがちな「使い切れない枠」「超過請求」の両方を回避 企業のFinOps担当者にとって、AIエージェントのコストをAzure Cost Managementで他のリソースと同じ粒度で管理できる点は大きい。 実務への影響 IT運用チームへの直接的な影響として、まず考えるべきは「何を任せて何を人間が持つか」の線引きだ。Azure SRE Agentが得意とするのは、手順が明確に定義できる繰り返し対応タスク。具体的には以下のような領域が現実的な導入候補になる： 既知の障害パターンへの自動対応（再起動・スケールアウト・フェイルオーバー） 異常検知後の一次トリアージと担当者へのエスカレーション 定期的なヘルスチェックと結果のレポーティング AAUベースの課金であれば、まず低頻度の自動対応タスクから試験導入し、効果とコストを測定しながら段階的に範囲を広げる「道のド真ん中」アプローチが取りやすい。いきなり全自動化を狙わず、人間の承認ステップを残しながら徐々に委譲範囲を広げることで、リスクを最小化しながら実績を積める。 Microsoft Entra IDとの統合も見逃せない。SREエージェントはNHIとして動作するため、誰がどのリソースにアクセスできるかの管理はEntra IDで統一できる。Just-In-Timeアクセスや条件付きアクセスポリシーをそのままエージェントにも適用できる設計になっており、セキュリティポリシーの適用漏れが起きにくい。 筆者の見解 「仕組みを回すのはAI、作るのは人間」という流れが着実に加速している。Azure SRE Agentのような自律エージェントは、その象徴的な存在だ。今回の課金モデル変更は地味に見えて、実は本番導入における最後のハードルの一つを取り除く意味を持つ。コストが予測できなければ、企業のシステム部門は稟議を通せない。それが通るようになるということは、今後12〜18ヶ月で導入事例が急増することを意味する。 「でも結局、障害の80%はAIが処理して、残り20%の複雑な問題だけ人間が対応する」という世界が現実になりつつある。それは決して悪い話ではなく、SREエンジニアが本当に難しい問題だけに集中できる環境が整うということだ。NHIとしてのエージェント管理を今から設計しておくことが、来たるべき「人間が必要な局面だけに集中する運用モデル」への準備になる。 Azureのプラットフォームとしての強みは、こういうエージェント基盤の整備にある。ここは正直に評価できる部分だ。自律SREはまだ発展途上だが、コスト構造が整ったことで「試せる企業」の裾野が広がる。まずは小さく始めて、実際の効果を測定することをお勧めする。 出典: この記事は Announcing a flexible, predictable billing model for Azure SRE Agent の内容をもとに、筆者の見解を加えて独自に執筆したものです。