Azure

Azure Synapse AnalyticsおよびAzure Data Factory（ADF）で構築したパイプラインを、Microsoft Fabricへ安全に移行するための組み込みマイグレーション体験（プレビュー）が公開された。「とにかく試してみて、動かなかったら戻す」式の移行ではなく、事前に互換性を確認してから移行するアプローチを採用している点が最大のポイントだ。 マイグレーションの3ステップ 新しいツールはSynapseワークスペースに直接組み込まれており、「Integrate」メニューから「Migrate to Fabric (Preview)」を選択するだけで開始できる。フローは以下の3段階で構成される。 ステップ1: アセスメント（事前評価） 対象のSynapseワークスペースで評価を実行すると、各パイプラインとアクティビティの移行準備状況が診断される。評価結果はCSVでエクスポートも可能なため、オフラインでの検討や部門間での共有にも対応できる。 ステップ2: 評価結果の確認とパイプライン選択 各パイプラインは4つのステータスに分類される。 Ready — そのまま移行可能 Needs review — 一部変更が必要 Coming soon — 対応予定（現時点では未サポート） Unsupported — 非対応 Readyなものから優先的に移行し、Needs reviewのものは修正しながら順次対応するという段階的移行が設計上の前提になっている。 ステップ3: 接続先マッピングと移行実行 移行先のFabricワークスペースを選択し、Synapseのリンクサービス（Linked Services）をFabric接続にマッピングする。マッピングが未完了のアクティビティは無効化された状態で移行されるため、意図せず本番データに触れることがない。さらに移行後はトリガーが無効化された状態で作成され、エンジニアが明示的に有効化するまで実行されない。 実務への影響 Azure Synapseで数十本・数百本のパイプラインを運用している日本企業にとって、「既存資産をどう扱うか」はFabric移行を検討する際の最大の壁になっていた。今回のツールはその壁に対するMicrosoftの回答だ。 特に注目したいのが段階的移行を前提とした設計だ。すべてを一度に移行する必要はなく、ReadyなパイプラインからFabricへ移行しながら、Needs reviewのものを並行して修正できる。データ基盤の移行でありがちな「全か無か」のリスクを回避しやすくなっている。 また、移行は無償で提供される点も見逃せない。Fabricのキャパシティライセンスのコスト検討とは別に、移行作業自体に追加費用がかからないことは、社内稟議のハードルを下げる実用的なポイントだ。 移行後の手順としては以下が推奨されている。 接続情報と認証情報の検証 エンド・ツー・エンドテストの実施 トリガーの再設定と有効化 筆者の見解 Microsoft FabricがSynapse・ADF・Power BI・Sparkといった分散していたサービスを一つのプラットフォームに統合しようとしている方向性は、筆者も正しいと思っている。データエンジニア・アナリスト・BIエンジニアがバラバラのサービスで作業する状況は、ライセンス管理・権限管理・コスト管理のいずれの観点からも非効率だ。「部分最適を積み重ねると全体として高コストになる」という現実に対する、まっとうな答えがFabricの統合戦略だ。 ただ、どれだけ優れたプラットフォームを作っても、既存資産からの移行コストが高すぎれば誰も来ない。今回のマイグレーションツールは、その「移行の壁」を下げるための重要な一手だ。この種のツールをきちんと整備してきたことは素直に評価したい。 一方で、CSVレポートの「Unsupported」や「Needs review」に分類されるパイプラインが多い環境では、移行判断はこういった細部で時間がかかる。プレビュー期間中に積極的にフィードバックを送り、GAまでに対応範囲を広げてもらうよう働きかけることが重要だ。Fabricがデータ基盤のデファクトスタンダードになっていくためにも、移行ツールの完成度を高め続けてほしい。Fabricにはそれだけのポテンシャルがある。 出典: この記事は Upgrade your Synapse pipelines to Microsoft Fabric with confidence (Preview) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIの最新フロンティアモデル GPT-5.5 が、Microsoft Foundry にて一般提供（GA）を開始した。単なるモデルアップデートにとどまらず、エンタープライズグレードのガバナンス・セキュリティ・コンプライアンスと一体化した「本番で運用できるAI」として提供される点が今回の核心だ。 GPT-5.5シリーズの進化 GPT-5シリーズは着実に積み上げを続けている。GPT-5で統合推論と速度が一本化され、GPT-5.4でエンタープライズ向けのマルチステップ推論と初期エージェント機能が追加された。今回のGPT-5.5では以下の点が強化されている。 エージェントコーディング・コンピューター操作の精度向上 大規模コードベースをまたぐ多段階タスクを自律的にこなす能力が向上した。曖昧な障害の根本原因をアーキテクチャレベルで診断し、「この修正が他の箇所に何を引き起こすか」を先読みして対処する。テストやレビューの必要性も自律的に判断するため、人間の関与が必要な箇所を絞り込める。 自律実行とリサーチ深度の向上 コード生成だけでなく、ドキュメント・スプレッドシート・プレゼンテーションといった成果物の作成も対象になった。問いから結果まで、ドラフトの複数回リファイン、論理の検証、データと文書をまたいだ合成まで「能動的な協働者」として機能する設計だ。 長文脈推論とトークン効率 巨大なコードベースや大量ドキュメント、複数セッションにまたがる処理でも文脈を保持し続ける。さらに、より少ないトークン・少ないリトライで高品質な出力を実現し、大規模本番環境でのコスト・レイテンシ削減に直接貢献する。 また GPT-5.5 Pro というプレミアム版も提供される。推論深度と複雑タスクへの対応をさらに強化したもので、法律・ヘルスサイエンス・DevOps・ソフトウェアエンジニアリングなど「不正確さのコストが特に高い領域」での活用を主眼としている。 Microsoft Foundryが担う役割 「フロンティアモデルへのアクセス」は出発点にすぎない。現実の課題は「数千のエージェントを本番環境で、適切な分離・アイデンティティ管理・ガバナンスとともに動かし続けること」だ。Microsoft Foundryはこの課題に特化したプラットフォームとして設計されている。 幅広いモデル選択肢：特定モデルへの依存ではなく、最良モデルを選び続けられる構造 オープンなエージェントフレームワーク：既存システムとの統合に柔軟対応 Microsoft 365・Azureとのネイティブ連携：既存のエンタープライズ資産を活かせる セキュリティ・コンプライアンス・ガバナンス：企業ポリシーをプラットフォームレベルで適用 新モデルが登場しても、評価・本番化・スケールアップを摩擦なく行えるのがFoundryの設計思想だ。 実務への影響 「AIの品質」と「エンタープライズ管理」を切り離す必要がなくなる これまで最先端AIを使うには、ガバナンスや監査ログを自前で構築する必要があった。FoundryはAIの品質と管理基盤をセットで提供し、Azureを使っている組織はMicrosoft Entra IDによる既存の認証・認可基盤とそのまま接続できる。 エージェント自動化の実用フェーズが本格化 GPT-5.5のコンピューター操作精度の向上は、定型業務の自動化からコードレビュー・インフラ変更検証・調達ドキュメント作成まで、幅広い業務自動化の実用化を後押しする。「試してみたが使い物にならなかった」という評価が過去のものになりつつある。 マルチエージェント構成への備えを今から Foundry Agent Serviceは「数千のエージェントを本番で並行運用する」ことを前提にした設計だ。単体チャットボットではなく、役割分担した複数エージェントが協調するアーキテクチャを今から検討しておく価値がある。Non-Human Identity（NHI）の管理と合わせて、エージェントの「身元と権限」設計をどう組むかが次の実務課題になる。 筆者の見解 Microsoft Foundryが「モデル選択の自由」を基盤設計の中核に置いたことは、長期的に正しい判断だと評価している。自社モデルの出来に関わらず、最良のフロンティアモデルをエンタープライズ基盤の上で動かし続けられる構造——これはAzureをプラットフォームとして選び続ける理由として、十分な説得力を持つ。 「最も賢いAIを作る競争」とは別に、「最も多くのエージェントが安全に動作するプラットフォームを提供する競争」という戦場でMicrosoftは明確に有利だ。GPT-5.5のFoundry統合は、まさにその戦略を実証する動きである。 一方で、率直に言えばナビゲーション機能の充実を期待したい。モデルの選択肢が増えれば増えるほど、「どのモデルをどのユースケースに使うべきか」の判断コストが組織に積み重なる。それを整理するガイダンスとツールをFoundryに組み込む力は、Microsoftには十分あるはずだ。その点でまだ伸びしろがある。 日本のIT現場では、エージェントAIが「試験運用フェーズ」の企業がまだ多い。しかしこのペースで実用化が進めば、「本番適用できていない」こと自体が競争力の差になる時代はすぐそこまで来ている。今こそFoundryとGPT-5.5を組み合わせた具体的なユースケースを探索し始めるタイミングだ。 出典: この記事は OpenAI’s GPT-5.5 in Microsoft Foundry: Frontier intelligence on an enterprise ready platform の内容をもとに、筆者の見解を加えて独自に執筆したものです。

医療業務の中でも最も高コストな行政負担のひとつとされる「事前承認（Prior Authorization）」のフローを、AIエージェントが丸ごと処理するソリューションが Microsoft Azure AI Foundry のテンプレートとして正式公開された。米国の医療保険ペイヤー向けに設計されたものだが、その設計思想は日本のあらゆる業種に直接転用できる普遍性を持っている。 「事前承認」とは何か——そして何が難しかったか 事前承認（Prior Authorization、PA）とは、米国の医療保険制度において、保険会社（ペイヤー）が特定の治療・薬剤・検査に対してあらかじめ承認を与えるプロセスを指す。患者にとっては治療の遅延を招き、医療機関には膨大な事務作業を強いる仕組みとして長年問題視されてきた。米国医師会の調査では、医師の9割以上がこのプロセスが患者ケアを遅らせていると報告している。 日本では国民皆保険制度の構造上、同一の制度は存在しない。しかし「申請 → 審査 → 承認/却下 → 通知」という処理の骨格は、購買稟議・契約審査・与信チェック・補助金申請など、国内企業の業務フローと完全に一致する。今回のテンプレートを「US医療専用」として見過ごすのはもったいない。 4エージェント構成の全体設計 公開されたソリューションは4つのAIエージェントが協調動作するマルチエージェント設計を採用している。 インテークエージェント — 申請内容の受け取りと構造化データへの変換 ポリシー照合エージェント — 保険プランのカバレッジポリシーとの照合・適用可否の判定 臨床レビューエージェント — 医療的必要性の評価と根拠資料の収集 意思決定・通知エージェント — 最終判断の生成と申請者への通知 「単一の万能エージェントに全責任を負わせない」この設計思想が重要だ。各エージェントは独立したロールと責任範囲を持ちながらオーケストレーションで連携する。一つのエージェントの判断に誤りがあっても、後続エージェントがチェックポイントとして機能する構造は、エンタープライズ向けの信頼性設計として現時点でのベストプラクティスといえる。 Azure Developer CLI で即展開 特筆すべきはデプロイの手軽さだ。Azure Developer CLI（azd up）の1コマンドでAzure環境へ展開できる設計になっており、PoC（概念実証）から実運用への移行障壁を大幅に下げている。基盤となるのは Azure AI Foundry・Azure OpenAI Service・Azure Health Data Services 等のマネージドサービスで、インフラ管理の複雑さをプラットフォーム側に吸収させながら業務ロジックに集中できる構成となっている。 実務への影響 パターンの移植可能性: 今回のテンプレートから業界固有のロジックを剥がして骨格だけ取り出せば、日本企業の多くの承認系業務に転用できる。最初から作り直す必要はなく、このテンプレートをベースに業務特化ロジックを上乗せするアプローチが最も現実的だ。 Non-Human Identities（NHI）の活用: このソリューションの各エージェントは「ノンヒューマンな処理担当者」として機能する。Microsoft Entra ID を通じた NHI 管理と組み合わせることで、「どのエージェントがどの権限で何を処理しているか」のガバナンスを確立できる。エージェントを「便利な自動化スクリプト」ではなく「アイデンティティを持つ処理主体」として管理する発想の転換が、長期的な運用安定性につながる。 コンプライアンス設計の参照先として: 医療データを前提とした設計ゆえ、データ境界・監査ログ・PII保護のパターンがテンプレートに組み込まれている。金融・医療・公共系など規制の厳しい日本の業界でも、このガバナンス設計は参考になる。 筆者の見解 マルチエージェントのソリューションを「テンプレート1本で試せる時代」になったことは、Azure AI Foundry の方向性として評価したい。 Microsoftがこのテンプレートで示しているのは「AIの活用例」だけではない。Entra ID によるアイデンティティ管理、Azure 上のデータガバナンス、監査証跡——Microsoftが長年エンタープライズ向けに磨いてきた基盤の強みが、マルチエージェントの時代になっても変わらず機能することを示している点が本質だと思う。「最も多くのエージェントが安全に動作するプラットフォームを提供する」という戦略は、着実に具体化されつつある。 ...

Azure Virtual Network TAP（VTAP）がパブリックプレビューとして一部リージョンで展開を開始した。クラウド上の仮想マシン間を流れるネットワークトラフィックをリアルタイムでコピーし、セキュリティ分析ツールやパケットキャプチャソリューションへ転送できるこの機能は、長年「見えない」とされてきたクラウド内部の東西通信（East-West Traffic）を可視化する。ゼロトラスト移行を進める組織にとって、一つの重要なピースが揃い始めた。 Azure Virtual Network TAPとは何か TAPとは「Traffic Access Point」の略であり、ネットワーク機器の世界では昔からある概念だ。物理環境では、スイッチやルーターにタップデバイスを接続して通過するパケットをコピーする手法が使われてきた。Azure VTAPはこれをクラウドのvSwitch（仮想スイッチ）レベルで実現する。特定の仮想マシン（NIC）を流れるインバウンド・アウトバウンド・双方向のトラフィックを、ネットワーク仮想アプライアンス（NVA）として動作するコレクターへミラーリングする仕組みだ。 従来手法との違い これまでAzure上でパケットレベルの監視を実現しようとすると、主に以下の方法に頼るしかなかった。 Network Watcher のパケットキャプチャ: VM内のエージェントを使った手動・オンデマンドのキャプチャ。常時監視には不向き NSG フローログ: IPアドレス・ポート・バイト数などのメタデータのみ。ペイロードは取得不可 VM内のログ転送: OSレベルのログをSIEMに送る手法。NIC以下のレイヤーは見えない VTAPはvSwitchレベルで動作するため、VMのOSやアプリケーションに一切手を加えることなく、ネットワーク層のトラフィックそのものをキャプチャできる。侵害を受けたVMがキャプチャを妨害できないという意味でも、セキュリティ上の優位点となる。 動作の仕組み 構成要素は3つだ。 TAP対象リソース — 監視したいVMのNIC VTAPリソース — AzureポータルまたはAPIで設定するミラーリング設定 コレクター — IDS/IPS、パケットアナライザー、SIEMエージェントとして動作するNVA トラフィックはGREトンネルなどでカプセル化されコレクターに転送される。既存のサードパーティ製セキュリティアプライアンス（Palo Alto、Fortinet等）とも連携しやすい設計であり、既存投資を活かしながら導入できる点が現実的だ。 実務への影響 東西通信の可視化がゼロトラストを補完する オンプレミスではスパインスイッチのSPAN/MIRRORポートでキャプチャできた東西通信が、クラウドでは仮想スイッチの内部で完結するため、従来の手法では取得が困難だった。VTAPにより、同一VNet内のVM間通信も含めた全トラフィックを分析ツールへ流せるようになる。 ゼロトラストの原則「Never Trust, Always Verify」を語る現場は増えたが、実態として「認証・認可が通った後の通信」はブラックボックスになりがちだ。VTAPはそのギャップを埋める具体的な手段となる。 具体的なユースケース IDS/IPSの導入: Microsoft Defender for Cloudだけでなく、オンプレミス運用で使い慣れたIDS製品をクラウドにも適用できる PCI DSS・金融系コンプライアンス対応: カード情報や金融データを扱うシステムでの全パケット記録要件に対応しやすくなる インシデントレスポンス: 侵害発生時の事後分析に加え、侵害進行中のリアルタイム検知が可能になる マルチベンダーSIEM統合: Splunk、Microsoft Sentinel、SumoLogicなど既存のSIEM環境にVNetトラフィックを流す 日本企業へのメッセージ 日本の大企業に多い「Lift & Shift」型クラウド移行では、オンプレミスのセキュリティ監視の仕組みをそのままに、仮想マシンだけクラウドへ移すパターンが見られる。このとき「クラウドだとパケットが見えない」という問題がセキュリティ監査の障壁になるケースがある。VTAPによって、オンプレミスで長年使ってきたNDR（Network Detection and Response）ソリューションをAzure VMに対しても適用できる道が開かれる。既存投資を活かしながらクラウドの可視性を高められるのは、移行コストを重視する日本企業にとって現実的な選択肢だ。 筆者の見解 筆者はセキュリティ分野を専門とは言えないが、VTAPのようなインフラ監視技術には純粋な技術的興味を覚える。 ゼロトラストの「掛け声」と「実装」のギャップは、日本の現場で何度も目撃してきた。「VPN廃止」「Identity-basedアクセス」を謳いながら、実際には認証後のラテラルムーブメントを全く検知できていないケースが驚くほど多い。VTAPはその穴を塞ぐための具体的な道具だ。 ...

Microsoftはセルフホスト型の Azure DevOps Server 向けに2026年4月のセキュリティパッチを公開した。今回のパッチには、セキュリティ上の懸念を含む3件の修正が盛り込まれており、特に自社データセンターやプライベートクラウドで Azure DevOps Server を運用している組織にとって、早急な適用が求められる内容となっている。 今回のパッチに含まれる修正内容 1. PRマージ時のnull参照例外（安定性） プルリクエストのマージ完了時、ワークアイテムの自動クローズ処理においてnull参照例外が発生しマージが失敗するケースがあった。特定の条件下でのみ再現する問題だが、CI/CDパイプラインに組み込まれたレビューフローでは致命的なブロッカーになりえる。今回のパッチでこの問題が解消された。 2. サインアウト時の悪意あるリダイレクト防止（セキュリティ） 今回の修正の中で最も注意が必要なのがこれだ。いわゆる「オープンリダイレクト（Open Redirect）」の脆弱性に近い問題で、サインアウト時のリダイレクト先URLの検証が不十分だったため、攻撃者が細工したURLを介してユーザーをフィッシングサイト等に誘導できる可能性があった。 社内のオンプレミス環境だから大丈夫、と油断している組織こそ要注意だ。内部ネットワーク内のマシンで動作していても、メール等で送られてくる細工されたリンクを社内ユーザーがクリックすれば脆弱性は成立しうる。今回のパッチでリダイレクト先のバリデーションが強化された。 3. GitHub Enterprise Server へのPAT接続修正（連携） GitHub Enterprise Server（GHES）との連携に使用するPersonal Access Token（PAT）接続が正常に作成できない不具合も修正されている。GitHubとAzure DevOpsを組み合わせたハイブリッドなDevOps構成を取っている組織では影響が直接出ていたはずだ。 適用対象と確認方法 今回のパッチは最新バージョンの Azure DevOps Server を対象としている。適用後の確認は、ダウンロードしたパッチインストーラーを使って以下のコマンドを実行することで行える。 出典: この記事は April Patches for Azure DevOps Server - Azure DevOps Blog の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AI基盤の整備が急速に進む中、プラットフォームチームが直面する現実的な課題がある。「AIを誰もが使えるようにしたいが、1つのアプリがクォータを食い尽くして全体が止まる」という問題だ。その解決策として、Azure Kubernetes Service（AKS）のApplication Network（AppNet、現在パブリックプレビュー）とオープンソースのagentgatewayを組み合わせた、アプリケーション単位のトークンレート制限機能が公開された。シークレットの配布なしにAIコストを一元管理するというプラットフォーム設計の考え方は、今後のAI基盤運用の標準的なアーキテクチャになり得る。 従来のAI API管理の限界 AI推論ワークフローの典型的な構成はシンプルだ。AIプロバイダーのアカウントを作成し、APIキーを配布して、アプリケーションからAPIを呼ぶ。しかし利用規模が拡大すると、避けられない問題が発生する——403: Insufficient Quota。クォータが枯渇した瞬間、全アプリケーションが同時に停止し、どのワークロードが原因かすら特定できない。 一対一でAPIキーを発行する対策も一般的だが、これはこれで問題がある。キーのプロビジョニング・ローテーション・配布といった運用負担が積み重なり、新しいアプリケーションのオンボーディングが遅くなる。「AIを使いたい」という開発チームの要求に対して、プラットフォームそのものが障害になるという本末転倒な状況だ。 プラットフォーム層でのレート制限という考え方 AppNetとagentgatewayが解決するのは、まさにこの構造的問題だ。 キーアイデアは「アプリケーションをシークレットではなくIDで識別する」こと。 Azure Kubernetes Application NetworkはIstioのztunnelプロキシを通じて、クラスター内の全トラフィックにmTLS（相互TLS）による自動ワークロードID認証を確立する。このIDをベースに、agentgatewayがCEL（Common Expression Language）式を使ってアプリケーションごとのトークンバジェットを定義・適用できる。 具体的な構成要素は以下のとおりだ： AppNet: 全トラフィックにmTLSを自動適用し、アプリケーションのID情報をワイヤー上で伝搬する agentgateway: mTLSを終端し、IstioウェイポイントとしてネットワークへTLSIDを直接読み取りトークンレート制限を適用する Azure Foundry APIキー: agentgatewayのみがアクセス。アプリケーションチームはシークレットを一切扱わない この構成の最大の利点は、アプリケーション側のコードを変更することなく、プラットフォーム層でAIコストを一元管理できることだ。 実務への影響 コスト管理の民主化とガバナンスの両立 AI利用を「使いたい人に使わせる」ながら「特定のチームがコストを独占しない」という、一見矛盾した要件を同時に満たせる。予算管理部門が求める可視性と、開発チームが求める利便性を同時に実現できる。 オンボーディングの高速化 新しいアプリケーションがAI機能を使い始めるとき、APIキーの発行申請・承認・配布というプロセスが不要になる。ワークロードIDが自動的に認証基盤となるため、セキュリティレビューが完了していれば即日利用開始できる。 インシデント対応の改善 クォータ超過時に「誰が使ったか」を正確に特定できる。AIコストのFinOps的な分析が現実的なレベルで可能になる。 明日から試せる具体的アクション AKSクラスターにApplication Networkを有効化（パブリックプレビュー） agentgatewayをデプロイし、AppNetのIstio準拠コントロールプレーンと連携設定 CEL式でアプリケーションごとのトークンバジェットポリシーを定義 Azure Foundry（Azure AI Services）のAPIキーはagentgatewayにのみ設定し、アプリケーションチームへのシークレット配布をゼロにする 筆者の見解 このアーキテクチャを見て率直に感じるのは、「これはAIの問題ではなく、アイデンティティの問題だ」という点だ。 シークレットを配布してアクセス制御するというモデルは、VPNと同じ発想の延長線上にある。静的な認証情報を配布して管理する構造は、どこかで必ず運用コストと漏洩リスクに転化する。それに対してmTLSとワークロードIDによる動的な認証は、ゼロトラストのアーキテクチャ原則に合致した正しい方向性だ。 NHI（Non-Human Identity＝非人間アイデンティティ）の管理という観点でも重要な意味を持つ。AI活用を本気でスケールさせるなら、AIワークロード自体のIDをどう管理するかが業務効率のボトルネックになる。「人間が手動でAPIキーを発行・ローテーションする」構造のままでは、AI活用の速度がその運用作業に律速されてしまう。 Azureが描くプラットフォームの方向性——エージェントの管制塔としてEntra IDを活用し、AI利用を安全かつ自律的に許可していく——は長期的に正しいと考える。AppNetとagentgatewayの組み合わせはその具体的な実装例であり、「どのAIモデルを使うか」よりも「どうガバナンスするか」を先に固めるという、プラットフォームエンジニアリングの本来の仕事に戻ってきた感がある。 AI利用のゲートを閉じるのではなく、安全に使える仕組みを作って開放する。その正しい実装を今のうちに整えておくことが、今後のAI活用競争で組織が後れを取らないための基盤になる。プラットフォームが価値を生む時代は、まだ始まったばかりだ。 出典: この記事は Control AI spend with per-application token rate limiting using Application Network and agentgateway の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが2026年から2029年にかけて、日本のAIインフラ・サイバーセキュリティ・IT人材育成に総額100億ドル（約1.5兆円）を投資すると正式に発表した。国内データセンターの拡張とパートナーエコシステムの強化を両輪に据えたこの計画は、Azure Japanのリージョン能力を大幅に引き上げるものであり、日本のクラウド市場の勢力図にも影響を与えうる規模感だ。 投資の3本柱——AI・サイバーセキュリティ・人材 今回の投資は大きく3つの領域に分類できる。 1. AIインフラの拡充 国内のAzureリージョンに大規模なGPUクラスターおよびAIワークロード向けの計算基盤が追加される。Azure OpenAI ServiceをはじめとするAIサービスの処理をより低レイテンシで日本国内から利用できるようになるとみられる。データレジデンシー（データ国内保持）の要件が厳しい金融・医療・公共セクターにとって、これは実質的な障壁が一つ取り除かれることを意味する。 2. サイバーセキュリティ強化 Microsoft Security製品の国内展開支援とともに、セキュリティ人材育成プログラムの拡充が含まれる。Microsoft Defender、Microsoft Sentinel、Entra IDを軸としたゼロトラストアーキテクチャの国内普及加速が期待される。 3. IT人材育成 Azure・AIスキルの認定資格プログラムや学習コンテンツを国内のパートナー・教育機関と連携して提供し、DX推進に必要な技術者の育成を支援する。 日本のIT現場への影響 データセンター拡張が解決する実務課題 日本のエンタープライズ企業が公共クラウドへの移行をためらう大きな理由の一つが「データを国外に出せない」という制約だ。今回のデータセンター増強は、国内リージョンの冗長性と処理能力をともに底上げする。特に東京・大阪のマルチリージョン構成が強化されることで、ディザスタリカバリ（DR）構成の選択肢も広がるはずだ。 Azure AI Foundryを起点にした活用戦略 1.5兆円規模の投資で整備されるインフラを最大限活用するには、Azure AI Foundry（旧Azure AI Studio）を中心に据えたアーキテクチャが現実解になる。Foundryを通じてさまざまなAIモデルを組み合わせ、Azureのセキュリティ・コンプライアンス基盤の上で動かすアプローチは、Microsoft基盤を継続利用しながらも最良のAI体験を確保できる方向性として注目に値する。 IT管理者が今すぐ確認すべきこと Microsoft Entra External IDおよびEntra IDのライセンス計画を見直す: AI・自動化エージェントの増加に伴い、Non-Human Identity（NHI）の管理需要が急拡大する。今のうちから体制を整えておくことが業務自動化のボトルネック解消に直結する Azure Regionのロードマップを再確認する: 今回の投資によりサービス提供開始時期が変わる可能性がある Microsoft Security製品のPoC計画を前倒しする: Sentinelや Defenderのインフラが国内で強化されるタイミングは、導入コスト・レイテンシ両面での好機になりうる 筆者の見解 これほどの規模の投資を日本に向けてくれることは、素直に歓迎したい。Azureプラットフォームの信頼性と、Entra IDを軸としたセキュリティ・ID基盤の方向性は今も正しいと考えているし、今回の投資はその路線の強化として一貫している。 ただ一点、率直に言いたいことがある。インフラが世界最高水準になっても、それを使いこなせるエンジニアが国内にいなければ意味をなさない。日本のIT業界は今、かつてないほどの構造転換の只中にある。AIがコーディングし、AIが設計し、AIがテストする時代に、「人材を増やす」ことそのものへの投資効果は以前とは根本的に異なる。人材育成プログラムの中身が「AIを使いこなす少数の設計者を育てる」方向に本気でシフトしているかどうか——そこが今回の投資の真価を決めると思う。 1.5兆円という数字のインパクトに目を奪われるのではなく、「この投資が3年後に何を変えたか」を問い続けることが、IT現場で働く私たちに課せられた宿題だ。Azureの正しい力が、日本の現場できちんと使われる未来を期待している。 出典: この記事は Microsoft deepens its commitment to Japan with $10 billion investment in AI infrastructure の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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の強みだと思う。 ...