Azure

英国財務省（HM Treasury）は2026年7月10日、Microsoft Azureの運営法人であるMicrosoft Ireland Operations、AWS EMEA SARL、Google Cloud EMEA、Oracle Corporation UKの4社を、英国金融システムを下支えする「Critical Third Party（CTP、重要な第三者事業者）」として初めて正式指定したと発表した。これを受けてイングランド銀行（BoE）、健全性規制機構（PRA）、金融行為規制機構（FCA）の3当局は現地時間7月13日、共同でこれら4社への直接監督を開始した。英国の金融機関が利用するクラウドサービスの約7割強を、この4社が占めているとされる。 「集中リスク」への対応としてのCTP監督 CTP制度は2023年の金融サービス市場法に基づき新設された枠組みで、個別の金融機関ではなく「多くの金融機関が同じ事業者に依存している」こと自体が生むシステミックリスクへの対応が狙いだ。イングランド銀行のSarah Breeden副総裁は「重要な第三者事業者が金融機関の業務に組み込まれるほど、新たな種類のシステミックリスクが生じうる」と述べ、FCAのNikhil Rathi長官も「同一の事業者が数千社にサービスを提供する以上、単一の障害が金融システム全体に波及しうる」とコメントしている。 CTPに指定された事業者は、提供する重要サービスのリスクを自ら特定・管理する義務を負い、特に大規模インシデント発生時には規制当局および利用金融機関との迅速な情報共有が求められる。指定・解除の権限はHMTが持ち、3当局は指定基準を満たし続けているかを定期的にレビューする。 既存の外部委託規制を置き換えるものではない 重要なのは、このCTP制度が金融機関自身に課される既存の外部委託・オペレーショナルレジリエンス規制を「置き換えるものではない」と明記されている点だ。各金融機関は引き続き、デューデリジェンスやコンティンジェンシープランなど自らのサードパーティ管理責任を負う。CTP監督は、規制当局がハイパースケーラー側に直接働きかける「もう一段上のレイヤー」として追加された仕組みという位置づけになる。なお同様の発想は、EUの「DORA」（Digital Operational Resilience Act）がすでに2025年1月から施行しており、Microsoft・AWS・Google等をEU域内で「重要ICTサードパーティ」として直接監督する枠組みを持つ。英国の今回の制度はBrexit後の独自規制として、これに追随する形となる。 実務への影響 日本ではこのニュースはまだほとんど報じられていないが、他人事ではない。金融庁も従来から「システムリスク管理態勢」やFISC安全対策基準を通じてクラウド集中リスクへの注意喚起を行ってきたが、ハイパースケーラーを直接監督する枠組みには踏み込んでいない。EU・英国という主要金融市場が相次いでクラウド事業者への直接監督に踏み出したことは、Microsoft・AWS・Google・Oracle側のガバナンスやインシデント対応プロセスが底上げされることを意味し、その恩恵はグローバル契約を通じて日本の金融機関にも波及する可能性が高い。 日本のIT管理者にとっての実務ポイントは2つある。ひとつは、CTP指定があっても「自社の第三者リスク管理責任がなくなるわけではない」という原則の確認だ。クラウド事業者が監督下に入ったからと安心せず、自組織のBCP・DR設計や単一リージョン依存の洗い出しは引き続き自分たちの仕事だと再認識したい。もうひとつは、各社が今後公表するレジリエンス関連の情報やSLA変更に注意を払うことだ。英国・EUの規制対応で強化されたインシデント通知プロセスや可用性基準は、グローバル契約を通じて日本の顧客にも展開されるケースが多い。 筆者の見解 今回の指定で興味深いのは、Azureが「最先端のAI機能」ではなく「金融システムを支えるインフラとしての信頼性」という文脈で規制当局から名指しされた点だ。AI機能の派手な競争ばかりが話題になりがちだが、実際に金融機関が数十年単位で預けるのは、こうした地味な可用性・ガバナンス対応の積み重ねである。この領域でMicrosoftが持つエンタープライズとの長年の関係と実績は、AI単体の性能競争とは別の軸で効いてくる強みだと考えている。 一方でCTP指定は「お墨付き」ではなく「踏み絵」でもある。直接監督下に入るということは、インシデント発生時の説明責任のハードルが今まで以上に上がるということだ。ここで真摯に対応し切れるかどうかが、AIエージェントが金融機関の業務にまで入り込んでくるこれからの時代に「安心して基盤を預けられる会社」としての評価を左右する。Azure・Entra IDを中心とした統合プラットフォームを長年推してきた身としては、今回の規制対応を単なるコンプライアンス業務として片付けず、信頼を積み増す機会として活かしてほしいと素直に思う。 出典: この記事は UK financial regulators to begin overseeing Critical Third Parties announced by HMT の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが「Azure Arc」のマルチクラウド管理機能を拡張し、これまでAWSのみに対応していたマルチクラウドコネクタに、Google Cloud Platform（GCP）対応をパブリックプレビューとして追加した。これによりAWS・GCP・Azureの3大パブリッククラウドを横断する単一の管理画面が実現し、資格情報を保存せずに済むOIDCフェデレーション認証も新たに導入された。さらに、物理拠点単位でリソースをグルーピングして管理する新機能「Azure Arc site manager」もプレビュー公開されている。 Azure Arcとは何か Azure Arcは、Azure外にあるリソース——オンプレミスのサーバー、他クラウド上の仮想マシン、Kubernetesクラスタなど——をAzure Resource Managerの管理境界に取り込む仕組みだ。Arc化したリソースには、Azure Policyによるガバナンス、Microsoft Defender for Cloudによるセキュリティ監視、Azure Monitorによる可観測性など、Azureネイティブの機能をそのまま適用できる。「Azureの外にあるものを、Azureの中にあるかのように扱う」というのがArcの一貫したコンセプトだ。 今回のアップデートの中身 最大の変更点は、マルチクラウドコネクタのGCP対応だ。これまでAWS上のEC2インスタンスを自動検出してArc対応サーバーとしてオンボードする機能はあったが、今回GCPのVMインスタンスにも対応した（パブリックプレビュー）。これにより、AWS・GCP・Azureという主要3クラウドの仮想マシンを、同一のAzureポータル・同一のAPI・同一のPolicy/RBACモデルで統合管理できるようになる。 もう一つの重要な変更が、認証方式の刷新だ。従来のマルチクラウド接続では、AWSやGCP側で発行したサービスアカウントキーやアクセスキーをAzure側に保存する必要があった。長期間有効な資格情報を他クラウドの管理画面に保存する構成は、漏洩・悪用のリスクを常に抱え込むことになる。今回導入されたOIDC（OpenID Connect）フェデレーション認証では、資格情報を一切保存せず、都度短命なトークンを発行してアクセスする方式に切り替わった。 あわせて「Azure Arc site manager」もプレビュー公開された。工場・支店・データセンターといった物理拠点単位でArcリソースをグルーピングし、拠点ごとに設定やヘルス状態をまとめて把握・管理できる機能だ。 実務への影響 複数クラウドを併用する日本企業——特に子会社や事業部ごとにAWS・GCP・Azureが乱立しているような大企業——にとって、ガバナンスの一元化が進む意味は大きい。Policy準拠状況やセキュリティ体制をクラウドごとにバラバラに追いかけるのではなく、Azure Policy・Defender for Cloud・Azure Monitorという単一のレイヤーで横断的に把握できるようになる。 IT管理者にとって特に注目すべきはOIDCフェデレーション認証への移行だ。長期間有効なアクセスキーをどこかに保存する構成は、棚卸しが追いつかず放置されがちで、インシデントの温床になりやすい。既存のマルチクラウドコネクタをAWSやGCPで使っている場合は、今回のOIDC対応への切り替えを優先的に検討する価値がある。多拠点展開している製造業・小売業などでは、Azure Arc site managerによる拠点単位の管理も、現場のオペレーション負荷軽減に直結するはずだ。 筆者の見解 ゼロトラストを推進する立場から見て、今回のOIDCフェデレーション認証の追加は素直に評価したい。常時有効な資格情報をあちこちに保存する構成は、特権アカウント管理における最大級のリスクであり、Just-In-Timeでの一時的なアクセスに寄せていく今回の方向性は正しい。 AzureがAWS・GCPまで管理範囲に取り込みにいく姿勢も一貫している。マイクロソフトは最先端のAIモデルを作る競争では必ずしも先頭に立てていないが、「あらゆるエージェント・あらゆるクラウドが安全に動作するための管制塔」としての立ち位置では強みを発揮できるはずだ。Entra IDやAzure Policyを軸にしたガバナンス基盤は、AIエージェントが自律的に動く時代においてこそ価値が増す。Azure Arcのマルチクラウド対応拡大は、その土台を着実に固める動きとして評価したい。プラットフォームとしての信頼を積み上げ続け、正面から勝負できる力を見せてほしいところだ。 出典: この記事は Expanding Azure Arc for Hybrid and Multicloud Management の内容をもとに、筆者の見解を加えて独自に執筆したものです。

セキュリティベンダーBeyondTrustが公開した年次レポート「Microsoft Vulnerabilities Report」第13版により、AzureとDynamics 365における重大（Critical）脆弱性の件数が、2024年のわずか4件から2025年には37件へと急増し、約9倍に達したことが明らかになった。象徴的な事例として、Microsoft Entra IDのトークン偽造に関する脆弱性（CVSSスコア10.0、深刻度最高）も報告されている。全体としては権限昇格（Elevation of Privilege、EoP）がMicrosoft製品を狙う脅威の中心を占めている。 重大脆弱性9倍増の中身 BeyondTrustのレポートは、Microsoftが年間で公表するセキュリティ更新プログラム（CVE）を集計・分析したもので、13年続くシリーズとして業界の指標のひとつになっている。今回とりわけ目を引くのが、AzureとDynamics 365における「Critical」評価の脆弱性の急増だ。1年で4件から37件という伸び方は、単なる誤差では説明がつかない規模であり、クラウド基盤とビジネスアプリケーション層の両方で攻撃対象領域（アタックサーフェス）が拡大していることを示している。 象徴的に取り上げられているEntra IDのトークン偽造脆弱性は、認証基盤そのものを標的にした問題だ。CVSS 10.0は「攻撃条件がほぼなく、影響が最大」という組み合わせを意味し、悪用されれば正規ユーザーになりすまして広範囲のリソースにアクセスされるおそれがある。 なぜAzureが焦点になるのか レポートが強調するのは、AzureがCopilotやAIエージェントなどの「マシンアイデンティティ」を支える基盤層になっているという点だ。AIエージェントは人間よりも多くのサービス間通信・トークン発行・権限委譲を行うため、認証基盤に脆弱性があると、被害が一つのアカウントにとどまらず、エージェントが持つ権限の連鎖を通じて増幅されるリスクがある。EoP（権限昇格）が脅威の中心にあるという指摘も、この文脈で読むと理解しやすい。低い権限で侵入されても、昇格の穴があれば最終的に管理者権限まで到達し得るということだ。 実務への影響 日本企業の多くはMicrosoft Entra IDを認証基盤に、Dynamics 365を基幹業務システムに使っている。今回の急増は「うちはAzureとM365だから安心」という前提を一度見直す材料になる。具体的には次の点をチェックしたい。 常時アクセス権を洗い出す: 特権ロールが恒常的に付与されたままのアカウントがないか確認し、Just-In-Time（PIM等）でのタイムボックス化に切り替える Entra IDの条件付きアクセスとトークン保護: トークン窃取・偽造への対策（Continuous Access Evaluationやトークンバインディング）が有効になっているか点検する AIエージェント・サービスプリンシパルの棚卸し: Copilotや業務自動化で作られたマシンアイデンティティが増えている企業ほど、権限の可視化と定期棚卸しを怠らない パッチ適用の優先順位: Critical評価かつEoP系のCVEは、公開後すぐに適用できる体制を整えておく 筆者の見解 筆者はゼロトラスト推進派で、常時アクセス権の放置こそが特権アカウント管理における最大のリスクだと考えている立場から見ると、今回の数字は「やはりそこが甘くなりがちだ」という警鐘に聞こえる。EoPが脅威の中心にあるという結果は、ネットワーク層・認証層・認可層のうち認可層の設計が後手に回っている企業が多いことの裏返しでもあるだろう。 AzureとEntra IDをエージェントの管制塔として使う戦略自体は、長期的に見て正しい方向性だと考えている。ただ、その管制塔の足元でCritical脆弱性が1年で9倍に増えたという事実は、応援する立場として率直に苦言を呈したいところだ。プラットフォームとしての信頼を積み上げてきたからこそ、認証基盤の堅牢性は他社以上に厳しく問われる。ここで足を止めてもらっては困る、というのが正直な感想だ。 幸い、対策の方向性ははっきりしている。Just-In-Timeアクセス、条件付きアクセス、そしてマシンアイデンティティを含むNon-Human Identities（NHI）の管理を徹底することだ。特にNHIの管理が甘いと、結局は人間がボトルネックとなって自動化が進まない。AIエージェント活用が本格化するこれからこそ、Microsoftには認証基盤の足元をきっちり固めた上で、正面から評価される製品であってほしいと期待している。 出典: この記事は 2026 Microsoft Vulnerabilities Report: Critical Flaws Double as Elevation of Privilege Dominates the Cyber Threats の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Entra IDは2026年6月より、Entra Connect SyncまたはCloud SyncによるオンプレミスADからEntra IDへの「ハードマッチング」を、Entraロールを保持するクラウド管理ユーザーオブジェクトに対してブロックする運用に変更した。特権昇格攻撃への対策として実施されたこのセキュリティ強化は、ハイブリッドID環境を運用する多くの日本企業に直接影響する。 ハードマッチングとは何か Entra Connect Syncを使ってオンプレミスのActive Directory（AD）とEntra IDを同期する場合、ディレクトリ間でオブジェクトを紐付ける方法が2つある。 ソフトマッチング（Soft Matching）: UPNやSMTPアドレスなどの属性を使って自動的に一致させる方法 ハードマッチング（Hard Matching）: ImmutableId（sourceAnchor）を直接書き込み、オブジェクトを強制的に紐付ける方法 ハードマッチングは移行シナリオや既存オブジェクトの引き継ぎで便利な反面、「攻撃者がオンプレミスADを侵害した際に、クラウド側の特権ユーザーアカウントに自由に紐付けて乗っ取る」という権限昇格攻撃の経路になり得る。今回のブロックはこの穴を塞ぐ措置だ。 何が変わるのか ロール保持ユーザーへのハードマッチングがブロック 2026年6月1日以降、Entra IDロール（グローバル管理者、特権ロール管理者など）を保持しているクラウドユーザーオブジェクトに対して、オンプレミスからのハードマッチングが拒否されるようになった。 影響を受けるシナリオは主に以下の通り： Entra Connect Syncを使った既存構成のメンテナンス中に特権ユーザーを再マッチングしようとするケース Cloud Sync経由でADからオブジェクトを取り込む際に管理者アカウントと紐付けようとするケース ディザスタリカバリやテナント移行でImmutableIdを操作するケース Connect Syncの設定変更に管理者認証が必須に（近日対応予定） あわせて予告されている変更として、Entra Connect Syncの設定変更（機能の有効化・無効化など）に際して、クラウド管理者のインタラクティブ認証が必須になる。ウィザードからの操作でもPowerShellからの操作でも、変更を確定するために認証済み管理者のサインインが求められる。 これにより、万が一Connect Syncサーバー自体が侵害されても、設定を勝手に変更することが格段に難しくなる。 NetBIOS名解決テストが「情報提供のみ」に格下げ Entra ConnectのAD DSヘルス監視エージェントにある「NetBIOS Name Sysvol Connectivity」テストが、アラート生成対象から情報提供のみに変更された。NetBIOSは現代のAD環境では必須でなくなっているケースが多く、アラートノイズを減らす実用的な変更といえる。 実務への影響——日本のIT管理者が今すぐ確認すべきこと 影響を受ける可能性のある構成の確認 まず現在の環境でハードマッチングを使っているかどうかを確認する。Entra Connect SyncでImmutableIdを手動設定しているオブジェクトが対象になる。 ImmutableIdが設定されているユーザーを確認 Get-MgUser -All -Property DisplayName,UserPrincipalName,OnPremisesImmutableId | Where-Object { $_.OnPremisesImmutableId -ne $null } | Select-Object DisplayName, UserPrincipalName, OnPremisesImmutableId 特権ロールの棚卸し 次に、Entraロールを保持しているクラウドユーザーを棚卸しする。特に「クラウドオンリーで作成した管理者アカウント」に対して、何らかの同期設定が絡んでいないかを確認したい。 Entraロールを保持しているユーザー一覧 Get-MgRoleManagementDirectoryRoleAssignment -All | Where-Object { $_.PrincipalType -eq ‘User’ } | Select-Object -ExpandProperty Principal ...

検証やお客様対応などで複数のMicrosoft Entra ID（旧Azure AD）テナントを行き来している方、毎回 az login していませんか？「またログインか…」続きをみる note.com で続きを読む →

Model Context Protocol（MCP）の最新仕様「2026-07-28リリース候補」が、プロトコルレベルでの完全なステートレス化を実現した。Microsoftの公式ブログ「Apps on Azure」でその詳細と移行ガイドが公開され、Azure App Service上でMCPサーバーをスケールアウトする際の複雑さが根本的に解消されることになる。 MCPがステートレスになるとは何か これまでのMCP仕様（2025-11-25）では、クライアントが最初にinitializeリクエストを送り、サーバーからMcp-Session-Idを受け取る「ハンドシェイク」が必須だった。このセッションIDはその後のすべてのリクエストに付与され、事実上「どのインスタンスが応答したか」を固定する役割を果たしていた。 水平スケーリング環境では、このセッションの「スティッキー性」が障害になる。インスタンスをまたいでセッション状態を共有するにはAzure Cache for Redisのような外部ストアが必要で、ARRアフィニティの無効化と合わせて手順が増えていた。 2026-07-28仕様では、この構造そのものが削除された。 削除されたもの 仕様変更の中心は2つのSEP（Spec Enhancement Proposal）だ。 SEP-2575: initialize/initializedハンドシェイクの廃止。プロトコルバージョンやクライアント情報は_metaフィールドでリクエストごとに送る SEP-2567: Mcp-Session-Idヘッダーとプロトコルレベルのセッション管理の廃止 結果として、すべてのMCPリクエストはどのインスタンスでも処理できる自己完結型のメッセージになった。 // 2026年仕様でのtool call（セッションID不要） { “jsonrpc”: “2.0”, “id”: 1, “method”: “tools/call”, “params”: { “name”: “search”, “arguments”: {“q”: “otters”}, “_meta”: { “io.modelcontextprotocol/clientInfo”: {“name”: “my-app”, “version”: “1.0”} } } } 追加されたもの ステートレス化と同時に、インフラ層との親和性を高める3つの改善も加わった。 ルーティング可能なヘッダー（SEP-2243）: Mcp-MethodとMcp-Nameヘッダーの必須化。ロードバランサーやAPIゲートウェイがリクエストボディを解析せずに操作単位でルーティング・レート制限できる キャッシュ可能なリスト（SEP-2549）: tools/listの結果にttlMsとcacheScopeが付与され、HTTP Cache-Controlと同様のキャッシュ制御が可能に 分散トレーシング（SEP-414）: W3C Trace Context（traceparent等）が_meta内で標準化。Application InsightsなどOpenTelemetry対応バックエンドで、クライアントSDKからMCPサーバー、その下流まで一本のスパンツリーとして可視化できる App Serviceでの変化：何がどう楽になったか App Serviceのビルトインロードバランサーはもともとラウンドロビンで動作させたいが、これまでのMCPはプロトコル自身がセッションアフィニティを持っていたため干渉していた。2026仕様でその干渉がなくなった。 項目 2025年仕様 2026年仕様 ARRアフィニティ無効化 必須 + Redisでセッション共有が必要 必須（プロトコルとの競合はない） Redis の用途 プロトコルセッション状態の共有 アプリ固有の状態管理のみ インスタンス追加時 セッション共有の設定変更が必要 スケールアウトするだけ 「普通のステートレスWebアプリをスケールアウトする」感覚でMCPサーバーを運用できるようになる、というのが今回の変化の本質だ。 ...

MicrosoftがAzure公式ブログで、Model Context Protocol（MCP）サーバーをAzure App Service上に安全にホストするためのリファレンスアーキテクチャを公開した。背景にあるのは、MCPサーバーの大多数が認証を実装していないという衝撃的な調査結果だ。 MCPサーバーのセキュリティ実態：数字が示す危機 Astrix Researchが発表した「State of MCP Server Security 2025」によると、OAuthを実装しているMCPサーバーはわずか8.5%。残りの91.5%は静的なAPIキーのみか、認証自体が存在しない状態でインターネットに公開されている。 これは机上の話ではない。すでにCVEが複数発行されている。 CVE-2025-6514（CVSS 9.6）：mcp-remoteにおけるOSコマンドインジェクション。悪意あるMCPサーバーに接続したクライアントのマシン上でリモートコード実行（RCE）が可能。約50万ダウンロードが影響を受けた CVE-2025-49596：MCP Inspectorの開発ツールが認証なしのローカルWebUIを公開しており、細工されたWebページからRCEが可能 問題の根本はMCPプロトコル仕様が認証をオプションとして定義している点にある。仕様書には「認可は実装依存」と明記されており、セキュリティの責任は開発者側にある。「簡単に立ち上げられる」というMCPの魅力が、そのままセキュリティリスクに直結している。 Azure App Serviceによる5層防御アーキテクチャ Microsoftが公開したサンプルリポジトリ（seligj95/app-service-secure-mcp）は、azd up一発でセキュアなMCPサーバーを展開できる構成になっている。5つの防御層を見ていこう。 1. Easy Auth——自前実装不要のOAuth App Serviceの組み込み認証（Easy Auth）をMicrosoft Entra IDと連携させることで、アプリケーションコードが動き出す前にプラットフォームレベルでトークン検証が完了する。 重要なのがProtected Resource Metadata（PRM）の公開だ。WEBSITE_AUTH_PRM_DEFAULT_WITH_SCOPESという1つのアプリ設定を追加するだけで、MCPクライアントが認可サーバーを自動検出してOAuthフローを完結できるようになる。8.5%しか実装できていないOAuth準拠を、コードを書かずに達成できる。 globalValidation: { requireAuthentication: true unauthenticatedClientAction: ‘Return401’ } また、App ServiceがX-MS-CLIENT-PRINCIPALヘッダーにクライアントのクレームを注入し、クライアントが偽装しようとした場合は上書きして除去するため、ツール側で「誰が呼んでいるか」を安全に確認できる。 2. マネージドID——秘密情報を一切保存しない システム割り当てマネージドIDにより、App ServiceはAzureが管理するEntra IDのIDを取得する。Key VaultやAzure OpenAIへの認証に格納された認証情報が一切不要になる。 重要な原則：クライアントが提示したトークンはあくまで「このMCPサーバーへのアクセス権」であり、Key Vaultへのアクセス権ではない。そのトークンをそのままダウンストリームに転送するのは脆弱性だ。マネージドIDによる委譲が正しい実装パターンになる。 3. Key Vaultシークレット参照——そして「返してはいけない」設計 アプリ設定にKey VaultのURIを参照させることで、平文のシークレットがリポジトリにも設定画面にも現れない。 ただし見落としがちな点がある。シークレットを読めるツールが、その値を返してはいけない。サンプルコードのread_secret_metadataツールは、マネージドIDによるアクセスが機能することを確認しつつ、返すのはバージョン情報と値の文字数のみ。値本体は意図的に除外されている。 シークレットを返すget_secretツールは、見かけが親切でも実態は「資格情報流出API」だ。 4. プライベートエンドポイント＋API Management——インターネットから姿を消す App ServiceとKey Vaultにプライベートエンドポイントを設定し、パブリックネットワークアクセスを無効化する。インターネットから唯一見えるのはAPI Management（APIM）のゲートウェイのみ。 APIMがトラフィックの入口でEntra JWT検証とレートリミットを実行し、その先のプライベートエンドポイントでもEasy Authが再度トークン検証を行う。攻撃者はパブリックゲートウェイのJWT検証とレートリミットを突破した上で、さらに認証が要求されるプライベートエンドポイントに到達しなければならない。 5. Application Insights——インシデント前に検知する Azure Monitor OpenTelemetryによる自動計装に加え、ツール呼び出しごとに構造化イベントを記録する。5分間の呼び出し数が閾値（サンプルは100回）を超えたらアラートを発火させる設定で、エージェントのループや不審なプロービングを事後のフォレンジックではなくリアルタイムで検知できる。 ...

MicrosoftがAzure上でArm64ベースの自社設計CPUチップ「Cobalt 200」を搭載したVMのプレビュー提供を開始した。同時に、AI学習向け自社設計アクセラレータ「Maia 200」がすでにMicrosoftのデータセンターで本番稼働（production）に入っていることが明らかになった。汎用コンピュート向けとAI学習向け、自社シリコンの「両輪」が出揃った形だ。 Cobalt 200とMaia 200—2つの自社チップが担う役割 Cobalt 200（汎用コンピュート向け） Cobalt 200はArm64アーキテクチャをベースにMicrosoftが独自設計したCPUチップだ。前世代のCobalt 100はAzure内部サービス向けに限定利用されていたが、Cobalt 200では外部顧客向けVMとしてプレビュー提供が始まった。 Arm64アーキテクチャの特性として、Intel/AMD系のx86 CPUと比べて電力効率が高く、スケールアウト型ワークロード——Webサーバー、API、マイクロサービス、コンテナワークロードなど——との相性が良い。コスト最適化の観点でも、同等パフォーマンスをより低い単価で実現できるケースが出てきている。 Maia 200（AI学習向け） Maia 200はAI・機械学習モデルの学習処理に特化した自社設計のアクセラレータチップだ。現時点では顧客が直接選択して使えるVMとして提供されているわけではなく、Microsoftが自社のAIサービス基盤——Azure OpenAI ServiceやMicrosoft Copilotの推論・学習基盤——を動かすためにデータセンター内部で稼働している。 今回のポイントは、Maia 200がプレビューや実証実験ではなく本番稼働（production）に移行済みであることだ。デモレベルのチップではなく、実際のサービストラフィックを支える基盤として機能している。 なぜこれが重要か—Nvidia依存という巨大リスクへの回答 AIインフラ競争において、クラウド大手が直面してきた最大の課題の一つが「Nvidia GPU依存」だ。H100やB200といったNvidia製GPUは需給がひっ迫し、調達コストも膨大。さらに、Nvidiaのロードマップに自社のAI事業が縛られるという戦略的リスクが常に付きまとう。 GoogleはTPU（Tensor Processing Unit）、AWSはTrainium/Inferentia、そしてMicrosoftはMaia——主要クラウドが独自AIチップを持つのは、まさにこのリスクヘッジであり、長期的なコスト構造の改善を狙った動きだ。 Maia 200が本番稼働に入ったということは、Microsoftの自社シリコン戦略が「研究開発フェーズ」から「実運用フェーズ」へ確実に移行したことを意味する。 実務への影響—日本のエンジニア・IT管理者が知っておくべきこと Cobalt 200 VMのプレビュー参加を検討する Linux系ワークロード——コンテナ、マイクロサービス、Webバックエンド——を抱えているエンジニアにとって、Cobalt 200 VMは試す価値がある選択肢だ。Docker multi-arch（マルチアーキテクチャ）対応のコンテナイメージを使っていれば、多くのケースでほぼシームレスに移行できる。コスト最適化の一手として検討に値する。 Arm64移行前の互換性チェックを忘れずに .NET（特に.NET 6以降）、Python、Node.js、GoはArm64対応が十分に進んでいる。一方で、古いネイティブライブラリや一部のWindows依存コンポーネントはx86エミュレーションが必要になる場合がある。本番移行前にCI/CDパイプラインでのビルドターゲット追加と動作確認を行うことを強く推奨する。 AIサービスコスト構造の長期的変化を見据える Maia 200の内部展開が進むにつれ、Azure OpenAI ServiceやAzure AI Foundryのコスト構造が中長期的に変化する可能性がある。自社シリコンの普及はクラウド事業者のマージン改善要因となるため、AIサービスの価格競争力向上につながる展開も考えられる。発注先のコスト動向として注視しておく価値はある。 筆者の見解 MicrosoftのCobalt 200・Maia 200による自社シリコン戦略は、プラットフォームとして正しい方向性だと評価している。クラウド基盤として顧客に安定したサービスを届けるには、ハードウェア層から独自に最適化できる能力が必要で、AWSやGoogleが先行していた領域だった。 Maia 200が本番稼働に入ったことは「デモができる」ではなく「本物のトラフィックで動かせる」を証明した点で意味が大きい。自社AIサービスの品質と応答速度を自社チップで支えられる体制が整いつつある。 次の関心は、Maia 200がいつ顧客向けオプションとして解放されるかだ。現状ではAzure内部のワークロードに閉じており、顧客がMaia 200の恩恵を受けるのはAzure OpenAI等のサービス経由に限られる。NvidiaのGPUを直接指定して使いたい高度な学習ワークロードを持つ顧客にとって、Maia 200を「選択できる」日が来ればプラットフォームとしての差別化はさらに強まるはずだ。 Azureがエージェント・AI基盤として長期的に信頼できる舞台であることは変わらない。その足元を支えるハードウェア投資として、今回の発表は着実な前進だ。 出典: この記事は Microsoft launches VMs based on Cobalt 200 chip in preview, Maia 200 already in production の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftはBuild 2026にて、Azure Functionsのサーバーレスエージェントランタイムをパブリックプレビューとして発表した。これにより、これまでイベント駆動の関数実行基盤として知られていたAzure Functionsが、AIエージェントのホスティング・実行プラットフォームとしての役割を担うことになる。 .agent.mdという新しいプログラミングモデル 今回の最大の特徴は、エージェントの定義を .agent.md というMarkdownファイル一枚で完結させる点だ。従来のエージェントフレームワークではPythonやTypeScriptで複数ファイルにまたがってエージェントを記述するのが一般的だったが、Azure Functionsのアプローチはこれを覆す。 YAMLフロントマターでトリガー種別やメタデータを宣言し、Markdownの本文がそのままエージェントへの指示（システムプロンプト）になる。MCPサーバーの接続設定や追加ツールの定義は mcp.json と agents.config.yaml という補助ファイルに分離されており、構成管理の観点でも整理しやすい。 たとえば「毎日15時にWeb上の技術ニュースを収集してメールで要約を送る」エージェントは、以下のような .agent.md 一枚で実現できる： name: Daily Tech News Email trigger: type: timer_trigger args: schedule: “0 0 15 * * *” You are a news assistant. When triggered, fetch today’s top tech news and email a summary to $TO_EMAIL. Pythonプロジェクトとその依存関係の管理が不要になる。この簡潔さはDevOpsコストの削減に直結する。 対応トリガーとコネクタの広さ エージェントを起動できるトリガーは既存のHTTP・Timer・Service Bus・Event Hubs・SQL・Cosmos DBに加え、TeamsメッセージやOutlookメール・カレンダーイベント・SharePointアイテムへの接続バックトリガーが新たに追加された。つまり、誰かがTeamsにメッセージを投稿したことをきっかけにエージェントが動き出す、といった業務自動化シナリオが標準で実現できる。 さらに、エージェントからアクセスできるコネクタは 1,400以上。Microsoft 365・Teams・Outlook・SharePoint・Salesforce・ServiceNowなど、企業の主要SaaSが一通りカバーされている。これはPower Automateのコネクタカタログと共通の資産を活用したものだ。 コールドスタートとコスト 実務者が真っ先に気にするであろう2点について、Azure Functionsプロダクトチームは明確に回答している。 コールドスタートについては「エージェントランタイム固有の追加遅延はない。インフラがボトルネックになるのではなく、LLMの推論時間がボトルネックになる」とのことだ。Flex Consumptionプランのスケールtoゼロ特性はそのまま維持される。 コストについては「エージェント税（追加料金）は存在しない」と明言。通常のFunctions実行と同一の秒単位課金モデルが適用される。 実務への影響——日本のエンジニア・IT管理者に向けて 既存のAzure Functions運用スキルがそのまま活きる Managed Identity認証・Application Insightsによるトレース・Flex Consumptionのスケーリング設定——これらは既存のFunctions開発者がすでに知っているオペレーションモデルだ。エージェント化しても「関数が起動したらエージェントが動く」という概念モデルで理解できる。学習コストを低く抑えながらエージェント運用に踏み込めるのは、実際のシステム移行を担うエンジニアにとって大きなメリットだ。 ...

Microsoftは2026年6月、Azure FunctionsにLogic AppsおよびPower Platformで長年使われてきた1,400以上のマネージドコネクタをファーストクラスのトリガーとして利用できるプレビュー機能を発表した。ローコードツール専用だったコネクタのエコシステムが、コードファーストな開発者にも開かれた形だ。 マネージドコネクタとは Azure Logic AppsやPower Automateには、Microsoft 365・Salesforce・Slack・ServiceNowといった外部サービスと連携するための「マネージドコネクタ」が1,400種類以上用意されている。接続先の認証情報や通信処理をMicrosoft側が管理（マネージド）してくれるため、開発者は外部サービスの細かい接続仕様を自前で実装せずに済む。これまでこのコネクタ群はローコード・ノーコードの世界での利用が中心で、コードで書くAzure Functionsからは直接活用する仕組みが存在しなかった。 何が変わったか 今回のアップデートにより、Azure Functionsのトリガーとして1,400以上のマネージドコネクタを直接バインドできるようになった。「Office 365のメールを受信したときにFunctionを起動する」「SharePointにアイテムが作成されたらFunctionを呼び出す」「SalesforceのレコードがアップデートされたらFunctionをトリガーする」といった処理が、Logic Appsを中継せずにコードだけで実現できる。 これまで必要だったLogic Apps → Azure Functionsという2段構成を、Azure Functions単体に集約できるシナリオが生まれた。 対応トリガーの例 現在プレビューで利用できる代表的なトリガーは以下の通り： Office 365メール受信 — 特定条件のメールが届いたときにFunctionを起動 Microsoft Teamsへのメッセージ投稿 — チャネルへの投稿をトリガーに処理を実行 SharePointアイテム作成 — ドキュメントライブラリへのファイル追加などをトリガーに Salesforceレコード更新 — CRMのデータ変更をAzure側でリアルタイムに処理 現状のサポート範囲と今後 現在プレビューとして提供されているのはC#（.NET 10 Isolated Worker）のみ。PythonおよびNode.jsは「近日対応予定」とされている。Azure Functionsの実務利用でPythonやNode.jsを選んでいるチームも多いため、これら言語のサポートが出揃った時点が実質的な評価開始のタイミングになるだろう。 実務への影響 アーキテクチャの設計選択肢が広がる 「ちょっとしたイベント処理はコードで書きたいが、コネクタはLogic Appsのものを使いたい」というジレンマは、Azure開発の現場でよく耳にする話だ。今回の対応により、単純なイベント起動型の処理はAzure Functionsに集約し、複数コネクタ間の複雑なフロー制御や承認ワークフローはLogic Appsに任せる、という明確な役割分担が設計しやすくなる。 コスト面の検討ポイント Logic AppsとAzure Functionsでは課金モデルが異なる。Logic Appsはコネクタの種類と実行回数に応じた従量課金が発生するケースがある。Azure Functionsでのマネージドコネクタ利用時の課金体系はプレビュー中に詳細が変わる可能性もあるため、本番移行前に必ず確認しておきたい。 M365連携の自動化がコードで書ける 日本のエンタープライズでもMicrosoft 365は標準プラットフォームとなっている。TeamsのメッセージングやSharePointのドキュメント管理、Exchange Online経由のメール処理を、C#のコードで直接イベントドリブンに書けるようになることは、Azure開発者にとって実用的な選択肢が一つ確実に増えることを意味する。 コネクタ品質のばらつきに注意 1,400以上のコネクタすべてが等しく信頼できるわけではない。Logic Appsでも一部のコネクタはサードパーティ提供であり、品質・更新頻度・エラー時の挙動にばらつきがある。Functionsで使う場合も同様で、本番運用に投入する前には接続先サービスのレート制限・認証フロー・障害時の挙動を必ずステージング環境で検証してほしい。 筆者の見解 このアップデートは地味に見えるが、実は「アーキテクチャの設計判断を変えうる」変更だと感じている。 Logic AppsとAzure Functionsは「ローコード vs コードファースト」という軸で住み分けてきたが、今回のマネージドコネクタ対応でその境界線が意図的に曖昧にされた。両者をより柔軟に組み合わせられる環境に向かっている方向性は正しいと思う。 ...

MicrosoftはAzure FunctionsにおけるGoの第一級言語サポートをパブリックプレビューとして公開した。Flex Consumptionプランで利用可能になり、Goエンジニアが慣れ親しんだ標準パッケージをそのままサーバーレス関数の記述に使えるようになった。 Goが「第一級市民」になるとは何か これまでAzure FunctionsでGoを動かすには、カスタムハンドラーという迂回路を使う必要があった。独自プロセスとしてGoバイナリを起動し、Functions Workerとのやり取りを自分で実装する形だ。便利とは言えない。 今回のアップデートで、この制約が取り払われた。HTTPハンドラーは標準のhttp.HandlerFuncをそのまま使って記述できる。 func HttpHandler(w http.ResponseWriter, r *http.Request) { fmt.Fprintln(w, “Hello from Azure Functions!”) } Goを書いたことがある人ならすぐに理解できる、いつも通りの書き方だ。非HTTPトリガー（タイマー、メッセージキュー等）もcontext.Contextと型付きペイロードで処理でき、Goらしい型安全なコードが書ける。 サポートされるトリガー一覧 パブリックプレビュー時点で以下のトリガーが利用可能だ。 トリガー種別 用途の例 HTTP REST APIエンドポイント、Webhookの受信 Timer 定期バッチ処理 Service Bus 非同期メッセージ処理 Event Hubs ストリームデータの取り込み Event Grid イベント駆動アーキテクチャ Cosmos DB データ変更の検知・連鎖処理 Blob Storage ファイルアップロード後の処理 実務でよく使うトリガーは一通り揃っている。プロトタイプから本格的なプロダクション用途まで対応できる水準だ。 なぜこれが重要か——Goとサーバーレスの相性 Goはコンパイル後のバイナリが小さく、起動が速い。サーバーレス関数において最大の課題の一つがコールドスタートの遅延であることを考えると、この組み合わせは理にかなっている。 AzureのFlex ConsumptionプランはコールドスタートとスケーリングをAzureがマネージドで制御するプランだ。ここにGoの軽量さが加わることで、従来のC#やNodeよりも低レイテンシなサーバーレス関数を実現できる可能性がある。 また、GoはクラウドネイティブなOSS（KubernetesやTerraform等）の実装言語として事実上の標準に近い地位にある。こうしたエコシステムに慣れた開発者がAzureに参入しやすくなるという意味もある。 日本のIT現場への影響 Goチームを抱える組織にとっては、バックエンドコードをAzure FunctionsにそのままデプロイできるためCI/CDパイプラインの統一が容易になる。言語ごとに別のデプロイ方法を使い分けるコストが下がる。 マイクロサービス移行中のチームにとっては、既存のGoサービスの一部をFunctions化してFlex Consumptionの従量課金メリットを得るという選択肢が現実的になった。 スタートアップや少人数チームでは、GoのシンプルさとAzure Functionsのインフラ管理不要という特性を組み合わせることで、少ない人手で高い可用性を実現しやすくなる。 実務での第一歩としては、まずHTTPトリガーの関数から始めるのが無難だ。Goの標準ライブラリだけで動くシンプルなAPIエンドポイントをFlex Consumptionに乗せ、コールドスタート時間と実行コストを計測してから適用範囲を広げていくアプローチを推奨する。 筆者の見解 Goサポートのアナウンスは、Azure Functionsのエコシステムとして正しい方向の一手だと思う。 これまで「AzureでGoを使いたければApp ServiceかAKSを選べ」という暗黙のメッセージがあった。それが変わる。Goを書く開発者にとってAzureの選択肢が広がるのは歓迎すべきことで、Azureのプラットフォームとしての懐の深さにもつながる。 標準パッケージをそのまま使えるという設計方針も評価できる。独自フレームワークや特殊なSDKを覚えさせるのではなく、「Go開発者がGoを書けばいい」という姿勢は、道のド真ん中を歩くアプローチとして正しい。 一方で、プレビュー段階での成熟度については慎重に見ていく必要がある。Flex Consumptionプランは比較的新しく、本番導入にあたってはSLAや運用ノウハウの蓄積状況を自分たちで確認することが重要だ。 Azureはインフラプラットフォームとしての信頼性は揺るがない。あとはこういった地道な言語サポートの拡充が、実際に開発者体験の改善として積み重なっていくかどうか。Goチームを抱えている組織は、まずFlex Consumptionプランのプレビューで試してみる価値は十分にある。 出典: この記事は Announcing Go support in Azure Functions (Preview) の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft は Azure SQL Database の長期保存（LTR）バックアップに対する WORM（Write Once, Read Many）不変保護機能を一般提供（GA）として公開した。グローバル管理者を含む最高権限のアカウントでもバックアップの変更・削除が一切できなくなる仕組みで、金融・医療・公共機関など規制要件の厳しい業種向けにデータ保護を大幅に強化する。 Azure SQL LTR バックアップ不変保護とは Azure SQL Database には標準の PITR（Point-in-Time Restore）とは別に、数ヶ月〜最大 10 年単位でバックアップを保持する LTR（Long-Term Retention）機能がある。今回 GA になったのは、この LTR バックアップに対する immutability（不変性）保護だ。 主な特性は以下の通り： WORM 保護: バックアップが作成されると、設定された保持期間中は一切の変更・削除が不可能 管理者も例外なし: サブスクリプション所有者・グローバル管理者を含むいかなるアカウントもバックアップを変更できない Microsoft Entra ID 認証との統合: Entra ID ログインを利用する SQL Database インスタンスではセキュリティ体制がさらに強化 コンプライアンス監査対応: SOC 2、ISO 27001、PCI DSS、HIPAA 等の監査証跡として機能する変更不可能なバックアップを証明できる 技術的な実装の背景 従来の Azure SQL バックアップは、技術的には管理者権限で削除・変更が可能な状態だった。これは「内部脅威（インサイダー脅威）」や「管理者アカウントの乗っ取り」シナリオでデータが失われるリスクを意味していた。 今回の機能は Azure Blob Storage 側の Immutable Storage ポリシーを活用し、バックアップデータを WORM 状態にロックする。一度コミットされた immutability ポリシーは Azure インフラレベルで保護されるため、アプリケーション層や IAM 層の操作では迂回できない構造になっている。 ...

Microsoftは2026年6月12日、Microsoft Build 2026の流れを受けてAzureの大規模アップデートを発表した。コンピュート・ストレージ・データベース・AI・セキュリティ・開発ツールと幅広い領域で多数の機能がGA（一般提供）に到達しており、運用チームは今すぐ対応が必要なアクションアイテムも複数存在する。 Azure Cobalt 200 VM：エージェントAI時代のコンピュート基盤 今回のアップデートで最も注目すべきは Azure Cobalt 200 VM の登場だ。従来比50%のパフォーマンス向上を実現し、エージェント型AIワークロードへの最適化が施されている。 AIエージェントが複数タスクを並列処理しながら継続的に推論を行う「エージェント型ワークロード」は、従来の単発API呼び出しとは根本的に異なる負荷特性を持つ。Cobalt 200はこうした新しい計算パターンに対応するために設計されており、長期的なAIインフラの主力になると見ている。 コンピュート面ではほかにも以下がGA到達している： NCv6（GPUコンピュートシリーズ最新世代） Premium SSD v2 の非ゾーンVM対応 また、GuestRDMAとLinux NVMeのAzure Site Recovery（ASR）サポートがプレビュー入りした。ハイパフォーマンスコンピューティング環境の災害対策を検討しているチームには見逃せない動きだ。 ストレージ：Azure FilesのGAと注意すべき課金変更 Azure Files が正式GAとなった。エンタープライズ向けフルマネージドファイル共有として安定フェーズに入ったと評価できる。 ただし、同時に 課金ポリシーの変更 が発表されており注意が必要だ： cool・cold・archiveティアの 最小請求オブジェクトサイズ が明確化（2026年7月1日より適用） GPv1アカウントおよびレガシーBlobアカウント の新規作成が2026年6月1日より制限開始（すでに適用済み） GPv1アカウントをまだ利用しているケースは、マイグレーション計画を早急に立てる必要がある。「今動いているから大丈夫」は通用しない。 データベース：PostgreSQLとAzure SQLの強化 データベース領域では複数の重要なGA到達がある。 PostgreSQL では、メンテナンスコントロール機能と開発者向け PostgreSQL Hub がGA。Azure SQL では Microsoft Entra IDログイン のサポートと イミュータブル（不変）バックアップ保護 が追加された。EntraログインサポートによってAzure SQLがID管理の一元化エコシステムに深く組み込まれ、イミュータブルバックアップはランサムウェア対策の観点で実質必須の機能だ。 Cosmos DB ではパーティション単位の自動フェイルオーバー、チェンジフィードの強化、AIアプリ向けベクターデータ同期用の埋め込み機能が追加された。なお、Cosmos DB Synapse Linkは2029年3月31日に廃止 が決定しているため、利用中の組織はマイグレーション計画のスケジューリングを始めてほしい。 AI・開発者ツール：Fable 5がFoundryに統合 AI・開発者ツール領域では見逃せない動きがある。 Anthropic Fable 5がAzure AI Foundryに統合 され、Copilotとのインテグレーションも確認されている。Microsoft Azure AI Foundryを通じて外部の最先端モデルを活用できるエコシステムが着実に広がっている。 ...

Microsoftは、Azure Container Appsの新リソースタイプ「Sandboxes」を発表した。AIエージェントが外部コードやツールを安全に実行するためのエフェメラルなセキュアコンピュート環境で、GitHub Copilot Cloud SandboxesおよびAzure AI Foundry Hosted Agentsの基盤インフラとしてすでに採用されている。 Azure Container Apps Sandboxesとは AIエージェントが実際に役立つ仕事をするには、コードを書くだけでなく「実行する」必要がある。問題は、外部から渡されたコードや動的に生成されたスクリプトの実行が、本質的にセキュリティリスクを伴う点だ。 Azure Container Apps Sandboxesは、このリスクに正面から向き合うために設計されたリソースタイプだ。一言で言えば「使い捨てのセキュアな実行箱」——エージェントがコードを走らせるたびに新しい隔離環境を起動し、タスクが終われば破棄する。 3つの技術的特徴 1. サブ秒起動 従来のコンテナは、起動に数秒〜数十秒かかることが多い。AIエージェントがコードを実行するたびにこれだけ待たされていたら、対話的な開発体験は成立しない。Sandboxesはサブ秒（1秒未満）での起動を実現し、エージェントとのやりとりを自然なテンポで維持できる。 2. スナップショットベースの一時停止・再開 実行状態をスナップショットとして保存し、必要なときに即座に再開できる。長時間の計算タスクや、人間の確認を挟む対話型エージェントフローでも、状態を失わずに作業を継続できる。これはステートレスが前提だった従来のサーバーレスモデルとは一線を画す設計だ。 3. マイクロVM単位の分離 最も重要な特徴がここだ。各Sandboxはマイクロレベルの仮想マシン境界で分離されている。たとえ悪意あるコード（または単純なバグ）が実行されても、影響はそのマイクロVMの内側に封じ込められる。プロセス分離レベルのコンテナと比べて、格段に強固なセキュリティ境界を提供する。 このアプローチはFirecrackerやgVisorなど、クラウドサンドボックスの先駆的技術から影響を受けており、「高速 + 安全」という相反する要件を両立させる設計パターンとして業界に定着しつつある。 GitHub CopilotとAzure AI Foundryへの統合 Sandboxesが単なる新機能発表にとどまらない理由は、すでに主要製品の基盤インフラとして採用されている点にある。 GitHub Copilot Cloud Sandboxes: CopilotのコーディングエージェントがPR作成やコード修正を行う際、コードの実行・テストはSandboxes上で行われる。開発者のローカル環境や本番環境に一切干渉しない。 Azure AI Foundry Hosted Agents: Foundry上でホストされるAIエージェントが外部ツールやAPIを呼び出す際の実行環境としても活用される。エージェントが自律的に動作する際のセキュリティ基盤を担う。 MicrosoftはSandboxesをAIエージェント時代のインフラ基盤として位置づけており、上位製品がこれを透過的に活用する構造を整えている。 実務への影響——日本のエンジニアへの示唆 自社エージェント開発に活用できる GitHub CopilotやFoundryだけでなく、自社でAIエージェントを開発している組織も、Azure Container Apps Sandboxesを直接利用できる。ユーザーが送信したコードを安全に実行するコードインタープリター機能、動的に生成されたスクリプトのテスト実行、マルチエージェントシステムにおける隔離されたツール実行——これらのユースケースで自前のサンドボックス環境を構築する手間が大幅に削減できる。 セキュリティ設計の発想が変わる 従来、「AIが生成したコードを実行する」という要件には「それは危険なので禁止」という結論が出がちだった。Sandboxesは「禁止ではなく、安全に実行できる仕組みを提供する」という設計思想の転換を技術的に支える。セキュリティを担保しながらAIエージェントの能力を最大限に引き出すアーキテクチャが、Azureのマネージドサービスとして利用可能になった。 Foundryとのセット活用を検討する 現在Azure AI Foundryを評価中・運用中の組織は、エージェントのツール実行部分にSandboxesを組み合わせることで、セキュリティアーキテクチャを強化できる。特に外部APIの呼び出しや動的コード実行を含むワークフローでは、設計の早い段階から組み込むことを推奨する。 筆者の見解 AIエージェントが「コードを読む」から「コードを実行する」フェーズに移行したとき、インフラ側にも相応の進化が必要になる。Sandboxesはその変化に対するMicrosoftの明確な回答だ。 特に評価したいのは、GitHub CopilotとFoundryという自社の主力製品での実績ある採用だ。「発表だけで使われていない」ではなく、自社製品のバックエンドに実際に使っている——これは技術的な成熟度を示す根拠として重要だ。マイクロVM分離という設計の選択も堅実で、「コンテナだから大丈夫」という楽観論より、エンタープライズ採用において信頼を得やすいアプローチだと思う。 一方で、サブ秒起動やスナップショット再開が実際の業務ワークロードでどれだけのスケールに耐えられるか、コストモデルがどうなるかは、現時点ではまだ見極めが必要な部分だ。Microsoftのインフラ基盤の地力は申し分ない。あとは実際に使い込んだときの運用知見をいかに早く積み上げられるかが鍵になる。 Non-Human Identity（NHI）の管理と業務自動化の観点からも、「安全なコード実行環境」の重要性はエージェント普及とともに増す一方だ。Sandboxesはその需要に対して一歩先に手を打った取り組みとして、Azure基盤を採用する組織には注目する価値がある。 出典: この記事は Introducing Azure Container Apps Sandboxes: Secure Infrastructure for Agentic Workloads の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftはFabricの2026年6月機能アップデートを公開し、プライベートネットワーク環境でAzure SQL Database・SAP・SQL Server 2016〜2022・SharePointへのミラーリングが利用可能になったと発表した。データエージェントの可観測性強化とOneLakeのストレージライフサイクル管理の簡素化も含まれており、エンタープライズ向けの実用性が一段と高まった内容だ。 プライベートネットワーク対応がゲームチェンジャーになる理由 Fabricのミラーリング機能は、既存のデータソースをリアルタイムに近い形でOneLakeに複製するアーキテクチャだ。これまでパブリックエンドポイント経由のみという制約があったが、今回のアップデートでその壁が取り除かれた。 今月から対応したソースは以下の通りだ： Azure SQL Database（プライベートエンドポイント経由） SAP（オンプレミスデータゲートウェイ経由） SQL Server 2016〜2022（オンプレミスデータゲートウェイ経由） SharePoint（プライベートネットワーク内） 日本の大企業・金融機関・医療機関の多くは「インターネット非経由が原則」という情報セキュリティポリシーを持つ。これまではそのポリシーがFabric活用範囲を事実上狭めていた。今回の対応により、クローズドな企業ネットワーク内でもFabricのデータ統合能力をフルに活かせる環境が整った。 データエージェントの可観測性強化 今月のアップデートには、データエージェント（Data Agent）の可観測性（Observability）と信頼性向上も含まれている。エージェントの実行ログとトレーシング情報の可視化が強化され、エラー発生時の原因追跡が容易になった。 AIエージェントを業務プロセスに組み込もうとしている企業にとって、「動いているはずなのに結果がおかしい」「なぜ失敗したかわからない」という状況はアジャイルな改善を阻害する最大の壁だ。可観測性の強化は地味に見えて、実運用における信頼のクリティカルパスを埋める重要な改善といえる。 OneLakeのストレージライフサイクル管理の簡素化 OneLakeのストレージライフサイクル管理機能が簡素化された。データの「ホット→クール→コールド」層間の移動ルールをシンプルな設定で管理できるようになり、長期保管データのコスト最適化が扱いやすくなった。 大量の分析データを保有する企業では「とりあえず全部ホットストレージ」という選択をしがちだが、アクセス頻度の低いデータをコールド層に自動移動させるだけでストレージコストを大幅に削減できる。今回の簡素化により、アーキテクトだけでなくデータエンジニアレベルでこの設定を扱えるようになる。 実務への影響 閉域網環境でのFabric採用検討を再開すべきタイミング 「ネットワーク要件が合わない」「セキュリティ審査を通過できない」という理由でFabricの導入を諦めた、または保留にしている日本企業は少なくないはずだ。今回のプライベートネットワーク対応を機に、要件整理を再度行う価値がある。 特に以下のシナリオでは検討の優先度を上げるべきだ： オンプレSQL Serverのレガシーデータをリアルタイム分析したい：SQL Server 2016〜2022というバージョン範囲はまさに「現役で動いているオンプレDB」のど真ん中。ゲートウェイ経由でミラーリングできるなら、大規模なデータ移行プロジェクトなしに分析基盤を構築できる。 SAP連携がボトルネックになっている製造業・大手流通：SAP×プライベートネットワーク対応は直撃の改善だ。SAPのデータをFabric/OneLakeに流せるなら、BIレポートの集計ラグを大幅に縮小できる。 SharePointデータを含む社内情報の横断分析：Teams/SharePointのコンテンツをOneLakeに統合してAIで検索・分析するシナリオが、閉域網でも現実的になる。 アーキテクト向けアクションアイテム オンプレミスデータゲートウェイの設計を早めに固める（SQL Server・SAP経由のミラーリングに必須） Azure Private Linkの構成を先にレビューしておく（Azure SQL DB向け） ストレージライフサイクルポリシーの初期設定を設計フェーズで決めておく（後付けより設計段階での決定が効果的） 筆者の見解 Fabricのプライベートネットワーク対応は、日本市場の現実に対するMicrosoftの真摯な応答だと評価したい。 日本の大企業が「閉域網原則」を持つのは、単なる保守性ではなく業法・規制・実際の脅威環境を踏まえた判断だ。その現実に対して「パブリックエンドポイントで繋いでください」という立場を取り続けることは、Fabricの普及を自ら妨げていた側面がある。今回の対応でその壁が一つ取り除かれたことは素直に歓迎したい。 Fabricが目指す「あらゆるデータをOneLakeに集約して、その上でAI・BIを動かす」というビジョンは正しい方向性だ。部分最適を積み重ねて後から高コストに気づくのではなく、統合プラットフォームで全体最適を図るという思想は、今の日本企業に最も必要なアーキテクチャ哲学でもある。 データエージェントの可観測性強化も同様だ。AIエージェントを業務に組み込むなら、ブラックボックスのまま動かすわけにはいかない。ログ・トレーシング・信頼性という基盤を固めてから機能を広げる——これは正攻法だ。 毎月着実にアップデートを重ね、エンタープライズの現実的な要件に応えていく継続的な改善姿勢こそが、Fabricの長期的な競争力になってきている。「今月何が変わったか」を追うことが実務上の意思決定に直結する、数少ないプラットフォームの一つとして、Fabricは着実にその地位を固めつつある。 出典: この記事は Fabric June 2026 Feature Summary の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、科学・工学分野のR&Dワークフローに自律AIエージェントチームを展開するAzureベースのプラットフォーム「Microsoft Discovery」を正式提供（GA）開始した。同時に発表された次世代トポロジカル量子チップ「Majorana 2」は前世代比で信頼性が1,000倍向上しており、その実現にDiscoveryのエージェント機能が大きく貢献している。 Microsoft Discoveryとは何か Microsoft Discoveryは、組織が専門化されたAIエージェントのチームをデプロイできるプラットフォームだ。各エージェントは大規模な知識ベースを推論し、仮説を生成し、実験を最適化し、結果を検証し、継続的なループで学習する。 アーキテクチャの核心は以下の4要素で構成される： Discovery Engine：マルチエージェントの研究ワークフロー全体を統合管理 Azure HPC連携：計算負荷の高いシミュレーションを処理 信頼スコアリングと引用機能：エージェントの出力を追跡可能・レビュー可能にする エンタープライズセキュリティ・ガバナンス：知的財産の保護と規制準拠を担保 Microsoftが設計上の4要件として掲げているのは、ワークフローの再現性、出力のレビュー可能性、独自知識のガバナンス、既存R&D組織への適合性だ。「ブラックボックスではなく説明可能なエージェント」という姿勢は、企業での実採用に向けた現実的な解答といえる。 Majorana 2——AIエージェントが実現した量子チップの飛躍 今回の最大のハイライトは、Discoveryの実績として同時発表されたMajorana 2だ。量子チームはDiscoveryのエージェントを活用して以下を実現した： 製造ワークフローの管理自動化 測定作業の自動化 材料スタックの最適化 キュービット製造における未発見の欠陥の特定 約20年分の異なるフォーマットの実験データにわたるパターン相関分析 技術面では、アルミニウムから鉛の超伝導体への転換により、宇宙線由来のノイズからキュービットを遮蔽することに成功。平均量子ビット寿命20秒（最長1分）を達成した。他のアプローチで典型的なマイクロ秒単位の寿命と比べると、桁違いの改善だ。演算時間は1マイクロ秒、量子ビットサイズは0.1ミリメートルの100分の1という高集積度を実現している。 Microsoftはこれにより、スケーラブルな量子コンピュータの実現を2029年と見込んでおり、当初計画から半分のタイムラインに前倒しとなる。 個人研究者・小規模チームへの間口も開放 エンタープライズ向けのAzure GAと並行して、無料のデスクトップアプリがEarly Previewで公開された。GitHub Copilotアカウントがあればローカル実行が可能で、大学研究者や小規模チームも敷居低くDiscoveryを試せる。 早期顧客には、エネルギー貯蔵・バイオシステム工学でセルフドライブ型科学ワークフローを構築するPacific Northwest National Laboratory（PNNL）や、半導体向け次世代流体の開発を進めるSyensqoなどが含まれる。 日本のIT現場への影響 日本の製造業・素材産業・医薬品分野の企業にとって、Microsoft Discoveryは今後注目すべきプラットフォームだ。 R&Dチームへの示唆： 既存のAzure環境を持つ企業は、追加インフラなしにアクセスできる 「20年分のデータを横断分析」というユースケースは、製造業の品質管理や失敗事例の学習に直結する GitHub Copilotの法人契約があれば、まずデスクトップアプリで小規模実験が可能 IT管理者・アーキテクトへの示唆： エージェントの出力に信頼スコアと引用が付くことで、コンプライアンス対応がしやすくなる Azure HPC連携は既存のAzureガバナンスポリシーが適用されるため、セキュリティチームの負担が比較的小さい Non-Human Identity（NHI）管理の観点から、エージェントに対してもMicrosoft Entra IDの条件付きアクセスをどう適用するかを早期に設計しておく価値がある 筆者の見解 Microsoft Discoveryの正式提供が持つ意味は、単に「もう一つのAIサービスが増えた」ではない。これはMicrosoftが「最も賢いAIを作る競争」ではなく、「最も多くのエージェントが安全かつ追跡可能に動作するプラットフォームを提供する競争」に軸足を置いていることの表れだ。 Majorana 2の開発でAIエージェントが「20年分の実験データを横断的に相関分析し、未発見の欠陥を特定した」という事実は、単なる業務効率化の話ではない。「AIが研究の主要なプレイヤーになった」という現実を示している。 エージェントの管制塔としてのAzure基盤——Entra IDによる認証・認可、HPC連携、ガバナンスコントロール——という構成は、長期的に見て筋が通っている。信頼スコアリングと引用機能を標準装備にしている点も評価できる。「エージェントが何をしたか説明できない」という問題は企業導入の最大の障壁の一つであり、ここに正面から答えを出していることは意味が大きい。 日本の製造業・研究機関にとって、自社の10年・20年分の実験データや製造ログがAIエージェントによって体系的に活用される日は、想像より近いかもしれない。Azure上でのエージェント基盤構築を今から設計し始めるのが、現実的な次の一手だろう。 出典: この記事は Microsoft Discovery Reaches GA on Azure, Powering the Agentic AI behind Majorana 2 Quantum Chip の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftはAKS（Azure Kubernetes Service）の2026年5月29日付リリースノートを公開し、AKS AutomaticのマネージドシステムノードプールがGA（一般提供）に昇格した。LocalDNSが新クラスターでデフォルト必須となるなど運用自動化が前進した一方、Flatcar Container Linuxの廃止期限が目前に迫っており、既存利用者には早急な移行対応が求められる。 マネージドシステムノードプール GA化の何が変わるか AKS AutomaticにおけるマネージドシステムノードプールがGAとなり、システムコンポーネント（kube-system 等）が動作するノードプールをAzureが完全管理する形が標準化された。 セキュリティ観点での変更点は大きい。GAとともに以下の制限が自動適用される： 新クラスターでは顧客提供のSSHキーをブロック（既存クラスターは保持するが追加不可） 複数レイヤーのセキュリティ制限が自動的に有効化 ノードへの直接アクセス経路が制限される 重要な注意点：マネージドシステムノードプールを持たない既存のAKS Automaticクラスターは、インプレースアップグレードで対応できない。クラスターを再作成してワークロードを移行する必要があるため、移行計画の立案が必須だ。 LocalDNS が新クラスターで必須化 新規作成するAKS Automaticクラスター、および既存クラスターへ追加する新ノードプールでは、LocalDNSモードが Required にデフォルト設定される。 LocalDNSはノードローカルのDNSキャッシュを利用して名前解決を行う。kube-dnsやCoreDNSのPodへの依存を削減し、クラスター内DNS応答速度と信頼性が向上する。マイクロサービス環境でDNS解決がボトルネックになるケースへの現実的な対処だ。 既存ノードプールへの変更はなく、新クラスター・新ノードプール追加時から有効となる。 Microsoft Defender for Containers にマルウェアスキャンが追加 Microsoft Defender for Containersにマルウェアスキャン機能が追加された。コンテナイメージや実行中ワークロードへの悪意あるコード混入を検知する。 サプライチェーン攻撃がKubernetes環境でも現実的な脅威となっている今、コンテナレイヤーでのスキャンは多層防御の重要な一手だ。Defender for Containersを既に有効化している環境では、ポリシーへの組み込みを検討したい。 廃止タイムライン：今すぐ対応が必要なもの ノードOS / 機能 廃止開始 完全削除 移行先 Flatcar Container Linux 2026年6月8日 2026年9月8日 Azure Container Linux for AKS Windows Server Annual Channel 2026年5月15日 2027年5月15日 LTSC（Long Term Servicing Channel） Windows Server 2019 2026年3月1日 2027年4月1日 Windows Server 2022以降 ...

Microsoftは、AIエージェント向け統合プラットフォーム「Microsoft Foundry」を正式提供（GA）開始し、Build 2026においてFireworks AIとの連携強化を発表した。「最も賢いモデル」を作る競争ではなく、「最も信頼できるプラットフォーム」を構築することで、エンタープライズAI市場の主導権を握ろうという大きな戦略転換だ。 Microsoft Foundryとは何か Microsoft Foundryは、Azure上でAIエージェントを構築・管理・監視するための統合基盤だ。単一のAzureエンドポイントから複数のAIモデル（オープンモデルを含む）にアクセスでき、モデルの選定・切り替え・コスト管理をひとまとめに行える。 今回のGAに合わせて特に注目されるのが、Fireworks AIとの統合だ。Fireworks AIは高性能な推論特化インフラを提供するスタートアップで、Foundryとの連携によりエンタープライズグレードのSLA（サービス品質保証）とSOC 2コンプライアンス対応のオープンモデル推論が、単一のAzureエンドポイントから利用できるようになった。 「能力競争」ではなく「信頼性競争」 Microsoftのこの戦略を端的に示すのが、「AIの能力よりも、AIを安全・確実・低コストで運用できる仕組みこそが企業採用の決め手になる」という読みだ。 現在のAI市場はGPT-4o、Claude、Geminiなど各社が最高性能を競い合う状況にある。しかしMicrosoftは、大企業が実際にAIを本番導入する際の課題は「どのモデルが賢いか」ではなく、次の3点だと見切っている。 コンプライアンスと監査対応 — 金融・医療・官公庁では、SOC 2やISO 27001、GDPRへの対応が必須条件 コスト可視化と管理 — 開発・検証環境のAIコストが予算超過するリスクへの対応 ガバナンスとアクセス制御 — 誰が何のエージェントを何に使ったかを追跡・制御する仕組み Foundryはこの3つを一元的に解決するプラットフォームとして設計されている。 Fireworks AI統合が実務にもたらすもの Fireworks AIの推論インフラは、LlamaやMixtralなどオープンソースLLMを商用グレードで動かすことに特化している。今回のFoundry統合により、以下が実現する。 Azure環境を離れることなく、最新のオープンモデルを本番グレードのSLAで利用できる コスト効率の高いオープンモデルと高性能なクローズドモデルを、同一のAPIで柔軟に切り替えられる セキュリティ監査・ログ記録もAzure標準のツールチェーンで完結する 「AIモデルの選択肢を広げながら、運用基盤はAzureに統一できる」という実践的なメリットは、特にマルチモデル戦略を検討している組織に刺さる提案だ。 日本のIT現場への影響 日本の金融・製造・公共セクターでは、クラウドやAIの採用においてコンプライアンス要件が非常に厳しい。「オープンモデルを使いたいがSOC 2対応ができないためプライベートモデルに限定せざるを得ない」という状況は、IT部門からよく聞く話だ。 Microsoft Foundryの正式提供により、この制約が一部緩和される可能性がある。Fireworks AI経由のオープンモデル推論がAzureのコンプライアンス傘下に入ることで、IT部門が経営層や法務部門へ説明しやすくなる。 また、Azure OpenAI Serviceで管理基盤を標準化している組織にとっては、追加の学習コストなしに利用可能モデルの幅を広げられる点も評価ポイントになるだろう。エージェント管理においてMicrosoft Entra IDを中心に据えている構成とも親和性が高い。 筆者の見解 Microsoftのこの戦略には、一定の説得力がある。「最強のモデルを作る競争」では厳しい場面があっても、「エンタープライズが安心してエージェントを大量に動かせるプラットフォーム」という土俵なら、長年の実績と信頼を武器に戦える。 Foundry経由で他社AIモデルを統一基盤で使えるようにした判断は賢明だと思う。「Azureを使いながら最適なモデルを選べる自由度」を提供することで、プラットフォームの価値を高め、Azure離れを防ぐ有力な手段になりうる。エージェントの管制塔としてMicrosoft Entra IDが機能し、実行モデルは状況に応じて最適なものを選ぶ——この構成は、筆者が実務で推奨しているアーキテクチャと合致している。 一方、「信頼性で勝負」という戦略が「能力競争から降りた」と受け取られるリスクも否定できない。プラットフォームとしての強みは本物であり、Microsoftが勝てる土俵だ。そこに加えて、Copilotをはじめとした自社AIサービスの品質も地道に磨き続けてほしい。強固なプラットフォームと優れた自社モデルが揃ったとき、Microsoftの本当の強みが発揮される。その日が来ることを楽しみにしている。 出典: この記事は With Foundry, Microsoft bets the enterprise AI battle is about reliability, not capability の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft は2026年6月のBuild 2026（サンフランシスコ）において、Microsoft Foundryに対してエンタープライズ向けAIエージェントの本番運用を支える大規模な機能拡張を発表した。単なる「新しいモデルエンドポイントの追加」ではなく、ランタイム・ツール管理・メモリ・知識検索・ガバナンスまでを一体で提供する「AIエージェント工場」へと進化した形だ。 Foundryとは何か——改めて整理する Microsoft Foundryは、Azureを基盤とした統合AIアプリ・エージェント開発プラットフォームだ。Azure サービスとのネイティブ連携、Microsoft 365データソースへのアクセス、そしてフレームワーク間の相互運用を特徴とする。今回のアップデートは、2025年にGA（一般提供）となったAzure AI Foundry Agent Serviceをさらに拡張するものとなっている。 今回追加された主要機能 ホスト型エージェントインフラ（Foundry Agent Service） マネージドなサンドボックスセッションが提供され、エージェントは状態・ファイルシステムアクセス・複数フレームワーク対応を持ったまま動作できる。APIはステートフルな「Responses API」と軽量な「Invocations Protocol」の2種類が用意され、用途に応じて使い分けが可能だ。 注目すべきはルーティン（Routines）機能がパブリックプレビューに入ったことだ。エージェントをスケジュール実行できるようになり、「夜間のチケットトリアージ」「日次レポート生成」といったバッチ的な自動化がFoundry上で完結する。OpenClawやHermesといった長時間稼働エージェントも、永続的な状態とファイルを持ったまま動作できる。 Toolbox——ツール管理の一元化 ツール・スキル・MCPクライアント・エンタープライズデータ統合を一本のマネージドエンドポイントに集約する「Toolbox」がパブリックプレビューになった。これまでは各エージェントにツールをハードコードする必要があったが、Toolboxでは登録したツールをランタイムに動的に検索・呼び出せる。 特に重要なのがTool Search機能だ。モデルに全ツールを渡すのではなく、タスクに関連する少数のツールだけを選択してモデルに提示する。これはコストとレイテンシの両方に効く実用的な設計だ。 また、Microsoft TeamsおよびMicrosoft 365 Copilotへの直接パブリッシュが2026年6月にGA予定となった。Foundryで構築したエージェントを、IDやポリシーが自動適用された状態で従業員の日常作業環境に展開できる。 メモリ機能——「何を話したか」から「どうやるか」へ Foundry Agent Serviceのメモリは、手続き記憶（Procedural Memory）・ユーザー記憶・セッション記憶の3種類に体系化された。 中でも手続き記憶はBuild 2026での新機能だ。従来のメモリが「何を話したか」を記録するものだったのに対し、手続き記憶は「どうやって仕事をこなすか」をエージェントが学習し次回以降に活かす機能だ。初期ベンチマーク（Tau bench）では、タスク成功率が7〜14ポイント改善したと報告されている。コストはほぼ変わらない水準での改善だという点も評価できる。 メモリストアはMicrosoft Entra IDをスコープ識別子として使い、保持期間や内容の検査も制御できる。 Foundry IQ——知識レイヤーの統一 Work IQ・Fabric IQ・Azure SQL・ファイル検索など複数の情報源を単一のSLA付きナレッジレイヤー「Foundry IQ」として統合した。グラウンディング（文脈付与）と検索を一元化することで、エージェントが参照すべき情報源を個別に実装する手間をなくす設計だ。 日本のエンジニア・IT管理者への影響 AIエージェント導入の「本番稼働」ハードルが下がる これまで日本企業がAIエージェントの本番導入を躊躇する理由の一つは、「ガバナンスや監査対応をどうするか」という問題だった。今回のFoundry強化により、Entra IDと統合した権限管理・ポリシー適用・オブザーバビリティがプラットフォームレベルで提供される。セキュリティポリシーの実装をエージェントごとにゼロから作る必要がなくなる。 Toolboxは「AIエージェントのマイクロサービス化」 Toolboxの思想は、エンタープライズ内の業務機能をMCPスキルとして登録し、複数エージェントから再利用するアーキテクチャを促進する。日本企業で多い「部署ごとに似たようなツールを個別実装」という状況を、組織横断で共有するツールカタログへと変えていく布石になり得る。 ルーティン機能で既存の自動化ニーズを取り込む 「夜間バッチで稼働するAgentにする」という需要は日本のSI現場でも強い。Foundry上でスケジュール実行が完結するようになれば、既存の定時ジョブをAIエージェントとして再設計する際の移行コストが下がる。 筆者の見解 Microsoft Foundryの今回の発表を見て、「ここにいた」と感じた。モデルをAPIで呼ぶだけなら誰でもできる。難しいのは、エンタープライズがAIエージェントを安全に、監査可能な形で、既存のIDインフラと統合して動かすことだ。その「難しい部分」をプラットフォームが引き受けるという方向性は、正しいと思う。 Entra IDをエージェントの管制塔として使う設計は長期的に見ても筋が良い。ゼロトラストの観点からも、エージェントのアイデンティティ管理は人間と同じ仕組みに統合されるべきであり、Foundryはその方向に向かっている。 一方で、手続き記憶の「7〜14ポイント改善」という数字はベンチマーク環境での話だ。実運用での再現性はこれから問われる。日本企業が本番導入を進めるには、ガバナンス設定の複雑さや既存システムとの統合コストをどう下げるか、ドキュメントとサポート体制がカギになるだろう。 ツールチェーン全体を統合し、エージェントが安全に動ける場所を作るというのはMicrosoftが最も強みを持てる勝負だ。その力を存分に発揮できるよう、実装の細部まで丁寧に仕上げてほしいと思う。 出典: この記事は Microsoft Foundry Adds Runtime, Tooling, and Governance for Production Agents の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft は「MSBuild 2026」にて、Azure App Service に「Easy AI」と呼ばれる新機能群を追加し、既存の Web アプリケーションを Model Context Protocol（MCP）エンドポイントとして公開できる仕組みを発表した。コードのリアーキテクチャなしに既存の Web API を AI エージェントの「道具」として接続できるようになる、エンタープライズにとって実用性の高いアップデートだ。 Easy AI とは何か Easy AI は、Azure App Service 上で稼働する既存 Web アプリを、最小限のコード変更で AI エージェントから呼び出し可能なサービスに変換するための機能セットだ。 中核にあるのが MCP エンドポイント化の仕組みだ。MCP（Model Context Protocol）は Anthropic が提唱し、各社が採用を進めているオープンなプロトコルで、AI エージェントが外部ツールやデータソースと標準的な方法でやり取りするための仕様だ。Azure AI Foundry・各種 IDE プラグイン・サードパーティ製エージェントフレームワークなど、あらゆる AI エコシステムが対応を進めており、事実上の業界標準になりつつある。 今回の発表により、Azure App Service 上の Web API は既存のコードベースを大きく変えることなく MCP サーバーとして機能するようになる。 リアーキテクチャ不要の意味 従来、AI エージェントから業務システムを呼び出そうとすると、以下の課題があった。 既存 API を MCP 形式に対応させるための書き直し 認証・認可の仕組みを再設計する必要性 エージェントランタイムとのセッション管理の複雑さ Easy AI はこれらを App Service のプラットフォームレイヤーで吸収し、アプリケーション開発者が意識しなくてよい部分を自動化する。裏側では Microsoft Entra ID による認証フローと統合されており、エージェントが安全にエンドポイントを呼び出せる仕組みが整っている。 ...