Azure

Microsoftが2026年4月2日、自社開発AIモデル3種——MAI-Transcribe-1（音声認識）・MAI-Voice-1（音声合成）・MAI-Image-2（画像生成・解析）——をAzure AI Foundry経由でリリースした。外部パートナーへの依存を減らし、AIスタック全体を自社でコントロールしようとする戦略的転換として注目される。 3モデルの概要と用途 MAI-Transcribe-1 は高精度な音声テキスト変換に特化したモデル。Officeアプリのディクテーション機能やアクセシビリティ機能、企業の会議録自動化ワークフローへの組み込みが期待される。 MAI-Voice-1 は自然な発音のテキスト読み上げ・音声合成エンジン。Teams会議のリアルタイム翻訳や、Narratorのような支援技術、さらにはオーディオブック生成といった用途を視野に入れている。 MAI-Image-2 は画像生成・編集・解析をカバーするマルチモーダルモデル。Paintやフォトアプリ、EdgeブラウザのAIアシスト機能など、Windowsに組み込まれた形での提供が見込まれる。 いずれも「Microsoft Foundry」イニシアティブの一環として開発されており、Azure APIを通じてエンタープライズ顧客が利用できる形でリリースされる。 なぜこれが重要か これまでMicrosoftのAI機能の多くはOpenAIのモデルに依存していた。この構造はコスト・セキュリティ・カスタマイズの自由度という3つの観点でリスクをはらんでいた。 今回の内製化戦略が意味するのは、Microsoftが「AIを使うプラットフォーム」から「AIを作るプラットフォーム」へ軸足を移すという宣言だ。特に日本企業にとっては、データレジデンシー（データの国内保管）や監査ログの透明性といった規制要件を満たしやすくなる可能性があり、医療・金融・公共分野でのAI活用が加速するきっかけになりうる。 Azureをすでに使っている組織にとっては、「同じテナント内で完結するAIサービス」が増えることはガバナンス面で大きなメリットだ。外部APIへのデータ送信に関する社内承認フローを簡素化できる可能性がある。 実務での活用ポイント Azure AI Foundryをすでに使っている場合: 新モデルはFoundry経由で利用できる。既存のプロジェクトでモデルを差し替えるだけで音声・画像機能を試せる。まずは開発・テスト環境で評価サイクルを回したい。 Teamsや会議録の自動化を検討中の場合: MAI-Transcribe-1はPowerAutomateやAzure Logic Appsと組み合わせることで、会議の文字起こし→要約→Teamsチャンネル投稿のフローを構築できる可能性がある。コスト試算を含めて早めにPoC（概念実証）を計画したい。 セキュリティ担当者・IT管理者向け: 自社モデルになることでデータフローの透明性が上がる。利用するモデルのAPIエンドポイントとログ出力先を確認し、既存のゼロトラスト構成（Microsoft Entra IDベースの条件付きアクセスなど）と整合性を取ること。 筆者の見解 MicrosoftがAIの内製化に本腰を入れるこの動きは、率直に言って「遅かった」という気持ちと「ようやく来た」という気持ちが混ざる。 Azureというプラットフォームの信頼性は揺るがない。Entra IDを軸にしたアイデンティティ管理、Teamsを中心としたコラボレーション基盤、そしてFoundryという統合開発環境——これらを横断して動かすエコシステムは、他のクラウドベンダーが簡単に真似できるものではない。最も多くのエージェントが安全に動作するプラットフォームを提供する競争では、Microsoftには構造的な優位性がある。 一方で、モデルそのものの性能がどこまで仕上がっているかは、今の段階ではまだ見えていない。MAI-Image-2が既存の画像生成AIと比べて実際にどう違うのか、MAI-Transcribe-1が日本語音声にどれだけ対応できるのか——数字と事例が出てきてから判断したい。 Microsoftには、プラットフォームとしての強みを活かして、モデルの良し悪しに関わらず「Azureで動かすのが一番安心」と感じさせる環境を整える力がある。今回の発表がその方向に向かっているなら、大いに歓迎したい。内製モデルがFoundryの中で他のモデルと横並びで比較・選択できる状態になれば、それがいちばん健全な未来だと思っている。 出典: この記事は Microsoft Launches MAI-Transcribe-1, MAI-Voice-1, and MAI-Image-2: A Strategic Shift to In-House AI Models の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがAzure AI Foundryの新機能として「Microsoft Agent Framework」をパブリックプレビューで正式発表した。これまで研究プロジェクトとして独立していたAutoGenと、エンタープライズ向け基盤として発展してきたSemantic Kernelを一つのフレームワークに統合するという、長らく待望されていた動きだ。 AutoGenとSemantic Kernelが、ついに一本化 Microsoft Agent Frameworkの核心は「統合」にある。AutoGenはMicrosoft Researchが開発した実験的なマルチエージェントライブラリで、エージェント同士の会話ループや役割分担に強みがあった。一方のSemantic Kernelは.NET・Python・Java向けのエンタープライズ対応SDKとして、RAGやプラグイン管理を得意としていた。 この2つを並行して使いこなすことは、これまでのAIエージェント開発者にとって相当なコンテキストスイッチを要した。今回の統合により、開発者は一つのSDKで研究最前線のマルチエージェントパターンと商用グレードの信頼性・ガバナンスを同時に得られる。 実装の3本柱——MCP・A2A・OpenAPI Microsoft Agent Frameworkは以下の3つのインターフェース連携を中心に設計されている。 Model Context Protocol（MCP）対応 外部ツールやデータソースとの動的な接続をMCPで実現する。MCPはAnthropicが提案し業界全体で採用が広がるオープンプロトコルで、エージェントがリアルタイムにツールを「発見して使う」仕組みの標準となりつつある。MicrosoftがMCPをネイティブサポートしたことは、エコシステム互換性の観点から重要な判断だ。 Agent2Agent（A2A） Googleが主導するエージェント間通信プロトコルA2Aにも対応し、異なるランタイムやプラットフォームをまたいだエージェント協調が可能になる。自社システムだけでなく、外部パートナーのエージェントとも接続できる設計だ。 OpenAPIによるAPI統合 OpenAPI仕様に準拠したAPIであれば、追加のアダプター実装なしにエージェントのツールとして組み込める。既存のバックエンドAPIを即座にエージェント対応にできる点は、実務での移行コストを大きく下げる。 Azure AI Foundryとの統合——ガバナンスと可観測性 ローカルで実験したエージェントをAzure AI Foundryに持ち込むと、可観測性・耐久性・コンプライアンスが自動的に付いてくる設計になっている。さらに「マルチエージェントワークフロー（プライベートプレビュー）」では、永続的な状態管理・エラーリカバリー・ビジュアルデバッグが加わり、長時間稼働するビジネスプロセス自動化に耐える構成を組める。 KPMGはこのフレームワークをグローバル監査プラットフォーム「KPMG Clara AI」に採用しており、規制産業での実績としての重みは小さくない。 実務への影響——日本のエンジニアが今やるべきこと Azure AI Foundryを試せる環境があるなら今すぐ手を動かす パブリックプレビューは本番投入の前哨戦だ。ローカルでAutoGenをいじっていた開発者は、そのコードをベースにFoundryへの移行を試す絶好のタイミングになった。 ツール統合の入口としてMCPを覚える MCPはAIエージェントとツールを繋ぐ新しい標準として急速に普及している。REST APIの設計スキルがそのまま活かせるため、バックエンドエンジニアにとって参入障壁は低い。社内の既存APIをMCP対応ツールとして公開する設計を今のうちから考えておくと良い。 Semantic Kernelの学習コストが将来に繋がる 日本では.NETエンタープライズ案件でSemantic Kernelの採用が増えている。今回の統合で「Semantic Kernelを学ぶ＝Microsoft Agent Frameworkを学ぶ」という構図になったため、既存の学習投資がそのまま有効になった。 ガバナンス設計を後回しにしない エージェントが複数連携する構成では、どのエージェントが何をしたかのトレーサビリティが必須になる。Foundryのガバナンス機能はその回答の一つだが、設計段階からエージェントの権限範囲・ログ取得・人間によるチェックポイントを組み込む習慣を今から持つべきだ。 筆者の見解 正直に言えば、この発表を見て「やっと来た」という気持ちが強い。AutoGenとSemantic Kernelが別々に存在し続けていた状況は、Microsoftのエコシステムを愛する開発者にとってずっと気持ち悪かった。ユーザーを分断させる理由がなかったはずで、今回の統合はその意味で遅すぎたくらいだ。 とはいえ、やるべきことを正面から整理してきた点は評価したい。MCPへの対応、A2Aへの対応、OpenAPI統合——これらはどれも「自社だけで完結させない」という姿勢の表れであり、エコシステムを広げる正しい方向性だ。 私が今最も注目しているのは「ハーネスループ」の設計、つまりAIエージェントが自律的に判断・実行・検証を繰り返し回り続ける仕組みだ。Microsoft Agent Frameworkのマルチエージェントワークフローは、まさにそのループを企業システムの中で安全に回すためのインフラになりうる。 Microsoftの強みはAIモデルの性能競争ではなく、「最も多くのエージェントが安全に動作するプラットフォームを提供する競争」にある。Entra IDによるID管理、Foundryのガバナンス基盤、M365との連携——これらが本当に繋がり始めたとき、エンタープライズAIエージェントの管制塔としてのMicrosoftの地位は揺るぎないものになる。 今回の発表はその布石として、十分に意味がある一手だ。 出典: この記事は Introducing Microsoft Agent Framework の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIエージェントが「調べて考えてまとめる」を自動で回し続ける時代へ MicrosoftがAzure AI Foundry Agent Serviceに「Deep Research」機能をパブリックプレビューとして公開した。単発の質問応答でもなく、RAGの一回検索でもない。エージェントが自律的に「調査→推論→再調査」を繰り返し、最終的に根拠付きのレポートを生成する——そんなループ型の調査自動化を、API・SDKから直接呼び出せるサービスとして提供するのがこの機能の本質だ。 仕組みとアーキテクチャ Deep Researchの中核を担うのはo3-deep-researchモデル。このモデルが「調査マネージャー」として機能し、以下のようなマルチステップパイプラインを自動で組み立てる。 意図の明確化とスコープ設定 — GPT-4oやGPT-4.1が初期クエリを分析し、調査の範囲と目的を精緻化する Bing Searchによるウェブグラウンディング — スコープが固まったら、Grounding with Bing Searchツールを通じて信頼性の高い最新情報を収集する 合成と要約 — 複数の情報源を統合し、ソース付きの透明性の高いアウトプットを生成する アーキテクチャ上の特徴は「コンポーザビリティ」にある。Deep Research単体で完結するのではなく、Logic AppsやAzure Functionsと組み合わせて、レポート生成→通知→承認ワークフローといった一連の業務プロセス全体を自動化できる。 ChatGPT Deep ResearchとMicrosoft 365 Copilot Researcherとの違い 似たような名前の機能がすでに存在するので整理しておこう。 機能 対象 特徴 ChatGPT Deep Research 個人ユーザー チャットUIから利用 M365 Copilot Researcher ビジネスユーザー Officeワークフロー統合 Azure AI Foundry Deep Research 開発者・企業システム API/SDK経由で自社アプリに組み込み FoundryのDeep Researchは「チャット画面の外」に出ることを前提に設計されている。社内の基幹システム、データパイプライン、承認ワークフローに直接埋め込んで使うための部品だ。 実務への影響——日本のエンジニア・IT管理者にとっての意味 法務・コンプライアンス部門との連携: 規制動向の定期モニタリング、ガイドライン変更の影響分析、リスクレポートの自動生成。これまで人手で週次・月次でやっていた調査業務をエージェントに委ねられる現実的な選択肢になる。 競合・市場調査の自動化: 特定の業界・製品カテゴリに関する情報収集を定期ジョブとして設定し、差分レポートをTeams・メールに自動配信するような仕組みが、Azure Functions + Logic AppsとのコンポーズでNo/Low Code寄りに構築できる。 RAGの「一回検索」の限界を超える: 従来のRAGは「クエリ→検索→回答」の一往復が基本。Deep Researchは「クエリ→検索→中間結論→追加クエリ→再検索→最終回答」というループを自動で組み立てる。複雑な調査タスクに対して、従来RAGより精度の高いアウトプットが期待できる。 ガバナンスと監査: Azureの既存のセキュリティ・コンプライアンス基盤がそのまま適用される。どのソースを参照したか、どのような推論ステップを踏んだかがトレース可能なため、金融・医療・公共といったコンプライアンス要件の厳しい業種でも採用しやすい設計になっている。 ...

MicrosoftがAzure AI Foundry（旧称：Azure AI Studio）を通じて、自社開発の機械学習モデル3本をパブリックプレビューとして公開した。音声認識・音声生成・画像生成という、OpenAIが得意とするド真ん中の領域に自社モデルを投入したことで、両社の関係性に新たな局面が生まれている。 何が公開されたのか 今回発表されたモデルは以下の3つだ。 MAI-Transcribe-1：25言語に対応した音声認識モデル。エンタープライズグレードの精度を持ちながら、GPU コストを競合比約50%削減できるとされる MAI-Voice-1：音声合成モデル。シングルGPUで60秒の音声を1秒未満で生成できるというスピードが売り MAI-Image-2：テキストから画像を生成するモデル 注目すべきは、これらが「新たに作られた実験的モデル」ではなく、すでにCopilot・Bing・PowerPoint・Azure Speechを裏側で動かしている本番モデルと同一であるという点だ。Microsoft Azure AI Foundry ModelsプロダクトチームのNaomi Moneypenny氏がブログで明言している。 CopilotのAudio ExpressionはMAI-Voice-1上で動作し、Copilot Voice Modeの文字起こしにはMAI-Transcribe-1が使われている。つまりMicrosoftは、自社製品で実戦投入済みのモデルを今回初めて外部開発者向けに開放したわけだ。 OpenAIとの関係はどう変わる MicrosoftはOpenAIに約1,350億ドル相当（昨年10月時点）の出資を行っており、少なくとも2032年まで提携を継続する方針を示している。しかしOpenAIは今年140億ドルの赤字が見込まれるとも報じられており、Microsoft投資家からも懸念の声が上がっていた。 Microsoftが提携再交渉の際に「OpenAI抜きで単独あるいは第三者と共にAGI研究を追求できる」と明言したのは象徴的だ。今回の自社モデル公開は、その言葉を具体的な行動で裏付けるものと言える。パートナーシップを維持しつつも、技術的自律性を着実に高めている。 なぜこれが重要か Azureをプラットフォームとして採用している日本企業にとって、この動きが持つ意味は小さくない。 これまで音声・画像系のAI機能をAzure上で実装しようとすると、OpenAI APIを経由するケースが多かった。その場合、コスト・レイテンシ・データ主権（どこでデータが処理されるか）の3点が懸念材料になりやすかった。 自社モデルがFoundryから直接利用できるようになれば、Azure環境内でデータを完結させながら、GPU コストも抑えた音声・画像処理パイプラインを組める。コールセンターの会話解析、会議の自動議事録生成、多言語キャプション対応といった用途は、日本企業でも今すぐ検討に値する。 実務での活用ポイント 1. 音声系ユースケースから着手せよ MAI-Transcribe-1の25言語対応・低コストという特性は、グローバル対応が求められる日系多国籍企業のミーティング文字起こしや、コンタクトセンター品質監査への転用が現実的だ。既存のAzure Speechを使っているなら、まず開発者テナントでモデルを切り替えて精度・コストを比較するところから始めたい。 2. Foundryをエージェント基盤として捉え直す 今回の公開は「モデル単体」の話ではない。Foundryは音声・画像・テキスト処理をワンプラットフォームで統合できる場になりつつある。AIエージェントを構築する際、入力チャネルの一つとして音声を組み込む設計が、以前より格段に組みやすくなった。 3. データ主権の観点でOpenAI APIと比較検討する 金融・医療・公共分野など、データのリージョン外流出に敏感な業界では、Microsoftの自社モデルを選ぶことでデータガバナンス上の説明責任が果たしやすくなる。コンプライアンス要件との整合を確認した上で採用判断したい。 筆者の見解 MicrosoftがOpenAI依存を薄めながら技術的自律性を確立しようとしている方向性は、プラットフォーム企業として正しい戦略だと思う。「最も多くのエージェントが安全に動作する基盤を提供する」という競争において、自社モデルラインナップの充実は欠かせない一手だ。 一方で、正直なところを言えば「このくらいやれるはずだよね」という印象もある。Microsoftには世界最大規模のインフラと、OpenAIとの長年の共同研究で蓄積された知見がある。それだけのリソースを持つ企業が、自社製品に使っているモデルを開発者向けに開放するまでにここまで時間がかかったのは、もったいなかった。 Copilotが一部ユーザーから信頼を取り戻せていない現状も正直に見ている。だからこそ、今回のようにFoundryを開発者にとって本当に使いやすいプラットフォームとして育てていく姿勢を継続してほしい。Microsoftには正面から勝負できる力がある。その力を着実に形にしていくことが、長期的な信頼回復につながると思う。 Foundryを「AIモデルのマーケットプレイス」として進化させ、自社モデルも他社モデルも最適なものを選んで組み合わせられる環境を作ることで、Microsoft基盤を選ぶ理由はより強くなる。この方向は間違っていない。 出典: この記事は Microsoft shivs OpenAI with new AI models for speech, images の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは本当に「1兆ドル」を消し飛ばしたのか かつてAzure Coreの中枢を担ったシニアエンジニアが、衝撃的な告発記事を公開した。Axel Rietschinという人物だ。彼はWindowsカーネルエンジニアとして、DockerやAzure Kubernetes、Azure Container Instances、Windows Sandboxを支えるコンテナプラットフォームの発明・出荷に携わり、複数の特許も持つ。2010年からAzureを使い続け、2023年にAzure Coreに再入社した「日本で言えば生き字引」的な存在だ。 その彼が「21世紀で最もバカバカしく、最も防げたはずのミス」と断言する失敗の話を書き始めた。シリーズの第1回として公開されたこの記事が、Hacker Newsで1000ポイントを超えた。 初日から見えた組織の病巣 記事の冒頭は衝撃的だ。Rietschinが再入社初日——まだIDバッジも受け取っていない段階——に出席した月次計画会議での出来事から始まる。 会議室のスクリーンには、COM、WMI、パフォーマンスカウンター、VHDX、NTFS、ETWなど、Windowsの中核を担うコンポーネント群を示すアーキテクチャ図が映し出されていた。議題は「これらをOverlakeアクセラレーターカードに移植する計画」だという。 Overlakeとは、Azureのネットワーク処理を高速化するオフロードカード。FPGAが搭載されたそのチップは「爪の大きさ」で、Linuxが動く省電力設計だ。デュアルポートメモリはたった4KB。通常サーバーCPUのTDPのごく一部しか使えない。 そんなハードウェアに「Windowsの半分を移植しよう」と大真面目に議論していたのだ。しかも「ジュニアエンジニア数人に調べさせればいい」という発言まで飛び出した。 Rietschinはこの光景を「complacency（慢心）」と表現する。技術的な実現可能性を正しく評価できる人間が議論の中心にいない、あるいはいても声が届かない組織になっていた——それがこの話の本質だ。 Azureの根幹に潜む技術的負債 Rietschinが問題視しているのは単なる一会議ではない。Azure CoreというAzure全体のインフラ基盤を担うチームでこうした意思決定が行われていたという事実だ。 Azure Boostオフロードカードは、ネットワーク・ストレージ処理をホストCPUから分離し、テナントVMにリソースを最大限渡すための重要技術だ。AWSのNitroカードに相当する存在で、クラウドの競争力を決定づけるハードウェアレイヤーである。 そのチームが、ハードウェア制約を正しく理解しないまま、Windowsの複雑なユーザーモード・カーネルコンポーネントの移植を検討していた。これがシリーズ全体のテーマである「信頼の侵食」の出発点だ。 なぜこれが重要か 日本のエンタープライズIT界隈にとって、Azureはもはやインフラの基盤だ。多くの組織がMicrosoft 365、Azure AD（Entra ID）、Teams、そしてAzure上のワークロードを組み合わせて運用している。 その根幹部分——ハイパーバイザー、ネットワーク、ストレージI/O——の設計と実装に慢心があったとすれば、信頼性・セキュリティ・性能すべてに影響が及ぶ。 AzureがOpenAIの大規模トレーニングクラスターを支えているという事実は、今や広く知られている。そしてRietschinが示唆するのは、そのような最重要顧客との関係すら危うくなりかねない意思決定が組織の内部で起きていたという話だ。第1回の記事だけで全貌は明らかではないが、続報が非常に気になる。 実務への影響 アーキテクチャレビューの「技術力担保」を確認せよ Microsoftに限らず、大組織のクラウドサービスを使う際に重要なのは「そのサービスの技術的品質をどう検証するか」だ。SLAの文字面だけを信じるのではなく、可用性ゾーン設計、障害ドメインの分離、ネットワークパスの冗長性などを実際に問い合わせるクセをつけたい。 マルチクラウドの保険価値を再評価する Azureへの全乗りはリスクが高い。AWS、GCP、あるいはオンプレミスとのハイブリッドによる保険的な分散を、コストではなくリスク管理として再評価する価値がある。 内部告発的な情報ソースを監視する Rietschinのようなインサイダーによる告発記事はHacker Newsに集まりやすい。日本語の技術メディアに翻訳が出回る頃には対応が遅れる。英語の一次情報を定期的に確認する習慣が、IT戦略判断の質を高める。 筆者の見解 ぶっちゃけ、この記事を読んで「やっぱりな」という気持ちが強かった。 Azureのプラットフォームとしての基盤は今でも信頼している。Entra IDは正しい選択だし、Teamsや基盤サービスの総合力はまだ他に代替がない。しかし、Microsoftという会社が「最も賢いAIを作る競争」でどんどん後れを取っている一方で、その根幹のインフラ部分でもこういう意思決定が行われていたとすれば、話は深刻だ。 個人的に一番ヤバいと思うのは「ジュニアエンジニア数人に調べさせればいい」というセリフだ。技術的判断の重みを理解していない人間が会議を仕切っている。これは単なるAzureの問題じゃなく、大企業病の典型症状だ。日本のSIerと構造が変わらない。 Microsoftはいま光を失っている——そう感じていたが、この元エンジニアの告発はその感覚を数字と実体験で裏付けてくれた。OpenAIを危うく失いかけた話、米政府の信頼を損なった話は、このシリーズの続回で明かされるようだが、正直なところ続きが怖い。 それでも、Microsoftが最終的に勝つシナリオはまだあると思っている。ユーザーベースとブランド力は本物だ。Copilotがいつか最前線に並ぶ日が来ることを、心から期待している。この批判が「古い批評」になることを願いながら、しかし今は目を逸らさずに見続けるしかない。 出典: この記事は Decisions that eroded trust in Azure – by a former Azure Core engineer の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GitHub Actionsの2026年4月アップデートで、Azure Private Networkingを使うホステッドランナーにVNETフェールオーバー機能がパブリックプレビューとして追加された。地味なアップデートに見えて、エンタープライズのCI/CD可用性にとっては結構デカい話だ。 何が変わったのか Azure Private Networking に VNET フェールオーバーが来た これまでGitHub ActionsのAzureプライベートネットワーク接続は、プライマリのAzureサブネットに障害が発生すると、その時点でワークフローが止まる仕組みだった。今回のアップデートで、セカンダリサブネット（別リージョンも可）をあらかじめ設定しておくことができるようになり、プライマリが落ちたときに自動または手動でフェールオーバーできるようになった。 フェールオーバーのトリガーは2種類: 手動: ネットワーク設定UIまたはREST APIから明示的に切り替える 自動: GitHubがリージョン障害を検知した際に自動で切り替え フェールオーバーが発生すると、エンタープライズ・組織管理者に対して監査ログイベントとメールで通知が届く。手動フェールオーバーを実施した場合は、プライマリリージョンが復旧したあとの切り戻しも手動で行う必要がある点は覚えておきたい。 対象はAzureプライベートネットワークを使用しているエンタープライズ・組織アカウント。 OIDC トークンにリポジトリカスタムプロパティが正式対応（GA） パブリックプレビューだったGitHub Actions OIDCトークンのリポジトリカスタムプロパティ対応がGAになった。 これによって、クラウドプロバイダー側のOIDCトラストポリシーを、個別のリポジトリ名やIDではなく「環境タイプ」「チームオーナーシップ」「コンプライアンスティア」のようなカスタムプロパティの値で制御できるようになる。リポジトリが増えるたびにクラウド側のロール設定を更新する手間が減り、組織のガバナンスモデルとクラウドアクセス制御を一致させやすくなる。 サービスコンテナのエントリポイント・コマンドのオーバーライドも追加 サービスコンテナのエントリポイントとコマンドをワークフローYAML内から上書きできるようになった。entrypointとcommandキーを使い、記法はDocker Composeと同様なので、馴染みのある書き方でそのまま使える。地道だが、今まで無理やりな回避策を取っていたユーザーには嬉しいアップデートだろう。 実務への影響 エンタープライズCI/CDの可用性要件が現実的に満たせる Azureプライベートネットワーク経由でGitHub Actionsを動かしている環境は、セキュリティ要件上どうしてもパブリックランナーが使えない場面が多い。金融・官公庁・大手製造業などでは、このフェールオーバー機能があるかないかで、DR（ディザスタリカバリ）要件の充足度が変わってくる。 実務的には以下の点を押さえておきたい: セカンダリサブネットのリージョン選択: プライマリと同一リージョンに置くのか別リージョンにするかで、RTO（目標復旧時間）が大きく変わる。コスト増を許容してでも別リージョンを選ぶ判断が必要な場合がある 監査ログの設計: フェールオーバーイベントが監査ログに記録されるので、SIEMへの連携設計を事前にやっておく 切り戻し手順の文書化: 手動フェールオーバー時の切り戻しは自動ではない。手順書とRunbookを今のうちに用意する OIDC カスタムプロパティは今すぐ採用を検討すべき リポジトリ数が多い組織では、個別リポジトリをクラウドロールにマッピングする運用がそのうち破綻する。OIDCカスタムプロパティの仕組みを使えば、リポジトリのタグ付け（例: env=production, team=platform）をそのままアクセス制御ポリシーに反映できる。スケーラブルなアクセス管理の基盤として、早めに設計を見直す価値がある。 筆者の見解 VNETフェールオーバー機能そのものは技術的に特別新しい概念ではない。Azure Load BalancerやTraffic Managerで散々やってきたことをGitHub Actionsのランナー基盤に持ち込んだというだけだ。ただ、これが「ようやく来た」という感覚は正直ある。 エンタープライズ導入の文脈でGitHub Actionsを提案するとき、必ずCI/CDパイプラインの可用性を問われる。「Azureリージョンが落ちたらビルドも止まるんですか？」という質問に対して、今まではフェールオーバーの仕組みがなかったので、正直に「止まります」と言うしかなかった。それが今後は「セカンダリ設定しておけば継続します」と答えられる。地味だが導入のハードルを下げる効果は大きい。 OIDCカスタムプロパティのGA化については、これが本当に正しい方向性だと思っている。「禁止ではなく安全に使える仕組みを」という観点から言えば、個別リポジトリを列挙してアクセス制御するのはスケールしないし、結局管理できなくなって「全部禁止」に振れる組織が出てくる。組織のガバナンスモデルを軸にアクセス制御を設計できる仕組みが整うことで、GitHub Actionsをガンガン使い倒せる組織が増えるはずだ。 AzureとGitHubの統合がじわじわと深まっているのを感じるアップデートだった。Microsoftがプラットフォームとしての安全な基盤を着実に固めている、その一端として評価している。 出典: この記事は Azure private networking for GitHub Actions hosted runners: failover networks in public preview の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

何が起きているのか 2026年4月15日、MozillaとGoogle ChromeがDigiCert Global Root（G1ルート）の信頼を廃止する。これに合わせて、Azure Instance Metadata Service（IMDS）がパブリックイシュアをMicrosoft G2-XSへ切り替える予定だ。 「証明書の話なんて自分には関係ない」と思ったエンジニア、ちょっと待ってほしい。IMDSはAzure VM上で動くほぼあらゆるアプリケーションが、インスタンス情報の取得・マネージドID認証・アテスティッドデータの検証に利用している基盤APIだ。ここが壊れると、VM上のワークロードが静かに死ぬ。 Azure IMDSとは何か Azure Instance Metadata Service（IMDS）は、Azure VM内から169.254.169.254（リンクローカルアドレス）にHTTPリクエストを投げることで、VMのメタデータや認証トークンを取得できる仕組みだ。マネージドIDを使ったAzureリソースへのアクセス（Key Vault・Storage・Azure OpenAIなど）は内部的にこのエンドポイントを叩いている。 Attestedデータ（改ざん検知用の署名付きメタデータ）を使う場合、クライアント側でその署名を検証するためにルート証明書が必要になる。ここに今回の変更が直撃する。 影響を受けるシステムの条件 以下に該当するシステムは今すぐ確認が必要だ： Attesd Data APIを使っている: ?format=json&api-version=2021-01-01などでAttestedデータを取得し、署名を検証しているコード カスタム証明書ストアを持つ環境: OSのシステムストアを使わず、独自のバンドル証明書でTLS検証しているアプリ（Pythonのcertifi、Javaの独自トラストストアなど） エアギャップ環境・オフライン証明書検証: インターネットに出られないVMでルート証明書を静的にバンドルしているケース 古いOSイメージ: 長期間アップデートしていないLinuxやWindowsイメージはルート証明書ストアが古い可能性がある 逆に、最新のOSイメージを使っており、システムのルートストアに依存し、Attesd Dataを署名検証していない場合は影響を受けない可能性が高い。 対処法 ステップ1：IMDSの利用状況を棚卸しする まずコードベースを検索して、169.254.169.254へのリクエストやManagedIdentityCredentialの利用箇所を洗い出す。Azure SDK（Python・Java・.NET・Go等）を使っている場合、SDKが内部でIMDSを使っているので認識していなくても影響する可能性がある。 ステップ2：Microsoft G2-XSルート証明書を追加する カスタム証明書ストアを使っている環境では、Microsoft G2-XSルート証明書を事前に追加しておく必要がある。Microsoft PKIリポジトリから最新のルート証明書を取得し、各環境のトラストストアに追加する。 ステップ3：4月15日前にテスト環境で動作確認 ステージング環境で新しいルート証明書のみを使う設定でアプリを動かし、TLSエラーが出ないことを確認しておく。本番切り替えは段階的に。 実務への影響 この変更が日本のIT現場に与える影響は意外と大きい。特に以下のシナリオで問題が出やすい： SIer・受託開発案件: 納品後に顧客がメンテナンスしていないVMが大量にある場合、OSのルートストアが更新されていない可能性がある。4月15日以降に突然「認証が通らない」という問い合わせが来るパターンが容易に想像できる。 Pythonアプリ: certifiパッケージは独自のCA束を持っており、pipでアップデートしていない環境では古いルートセットのままだ。pip install --upgrade certifiを今すぐ実行すること。 Java・Spring Bootアプリ: JVMに埋め込まれたトラストストアを使っている場合、JDKのバージョンによってはG2-XSが含まれていない可能性がある。最新のJDK/JREへのアップデートを検討すること。 コンテナ環境: Dockerイメージのベースレイヤーが古い場合も同様。FROM ubuntu:22.04のまま何ヶ月もapt updateしていないイメージは要注意。 筆者の見解 率直に言う。この手のルート証明書ローテーションで毎回思うのは、証明書の有効期限やルートの廃止を「知らなかった」で済ませる日本のエンジニアが多すぎるということだ。 セキュリティの話は嫌いだ。細かい話が多いし、関わる人間もなんか面倒くさい人が多い。でも技術的な興味はめちゃくちゃある。特にこういうインフラレベルの変更は、知らないと本当に静かに死ぬのがタチが悪い。HTTPエラーが出るとかならまだいい。Attesd Data検証のエラーは、ログに出るかどうかもアプリの実装次第で、気づかずにセキュリティ検証をスキップしているケースもある。 Azureのプラットフォームとしての信頼性は揺るがない、と今でも思っている。ただMicrosoftが「重大な変更」をTech Communityのブログポストで告知して終わり、というコミュニケーションスタイルはもう少し改善できるんじゃないかとは思う。Azure Portalのバナーで当該サブスクリプションに直接通知するとか、Service Healthで影響リソースを特定するとか、やりようはいくらでもあるはずだ。 ...

Microsoft（マイクロソフト）は、旧称Azure AI FoundryをMicrosoft Foundryとしてリブランドし、GPT-5・GPT-5-mini・GPT-5-nanoを含む新世代モデルへの移行戦略を公式ブログで詳細に公開した。単なるモデル追加ではなく、既存デプロイの自動アップグレードポリシーやPTU（Provisioned Throughput Units）への移行パスまで踏み込んだガイドラインであり、実際にAzure OpenAIを本番運用している組織は内容を把握しておく必要がある。 モデル自動アップグレードとは何か Microsoft Foundryでは、デプロイ設定において「自動アップグレード」を有効にすると、マイクロソフトが指定したタイミングで基盤モデルが新バージョンに切り替わる。たとえばGPT-4oデプロイが自動的にGPT-4o-latestへ更新されるような仕組みだ。 これはコスト効率やパフォーマンス向上の恩恵を自動的に受けられる反面、出力の一貫性が失われるリスクがある。プロンプトとモデルの組み合わせで動作を保証している本番システムでは、意図しないモデル切り替えが品質劣化や動作変化として現れることがある。 今回の公式ガイドラインでは、GPT-5世代への移行に際しても同様のポリシーが適用されることが明示され、ピン留め（特定バージョン固定） とアップグレードのどちらを選ぶかを明確に意識して運用設計する必要があることが改めて強調されている。 PTUとは——消費課金との違いと移行パス PTU（Provisioned Throughput Units）は、一定のスループットをあらかじめ確保する予約型の課金モデルだ。消費量に応じた従量課金（Pay-as-you-go）とは異なり、レスポンス遅延のばらつきが小さく、大量リクエストを安定的に処理できる。 今回の移行戦略では、GPT-5系モデルへの移行にあたり既存のPTUデプロイをどう扱うかのパスが示されている。具体的には： 現行PTUデプロイは廃止スケジュールに従い段階的に終了 新モデルへの移行は事前通知期間を設けてガイド GPT-5-mini・GPT-5-nanoはコスト最適化向けの軽量オプションとして位置付け GPT-5本体はハイエンドタスク向け、miniとnanoはコストを抑えつつ大量処理したいユースケース向けという棲み分けが明確になっている。 実務への影響 日本のエンジニア・IT管理者へ 今すぐ確認すべきこと： 自社のデプロイが自動アップグレード設定になっているか確認する — Azure PortalまたはREST APIでデプロイ設定を確認し、意図せず自動アップグレードが有効になっていないか点検する モデルの非推奨（Retirement）スケジュールを把握する — Microsoft Foundryには各モデルのRetirementページがある。把握していないとある日突然APIが動かなくなる 本番とステージングでモデルバージョンを揃える — ピン留め運用にしているつもりでも環境間でバージョンがずれているケースがある PTU契約中の企業は移行パスを早めに確認する — 特に年間コミットメントで予約しているケースは、GPT-5世代へのPTU移行タイミングの見積もりが必要になる コスト観点での実務ヒント： GPT-5-nanoはトークン単価が大幅に安くなると予想される。分類・要約・フィルタリングなど「重い判断は不要だが大量処理したい」タスクをnanoに切り出す設計を検討する価値がある。 筆者の見解 正直に言う。GPT-5が出るのは間違いなく重要なマイルストーンだ。でも今回の発表で一番注目すべきは、モデルのスペックではなく「移行管理の複雑さが上がり続けている」という現実だと思っている。 モデルが半年〜1年周期で世代交代し、PTUの予約スキームも更新され、プロンプトの動作保証はモデルバージョンに依存する——これを全部自社でハンドリングしながら本番運用し続けるのは、正直かなりしんどい。 そして、ここが核心だが、マイクロソフトは「最も賢いAIを作る競争」では今のところ後れを取っている。GPT-5がどこまで他社の最新モデルに迫れるかはまだわからない。だから筆者が推している構成は変わらない——Microsoft Foundry基盤の上でタスクに最適なモデルを動かすというアーキテクチャだ。Foundry経由でAnthropicモデルも使えるようになっている今、Azureを捨てる必要はない。プラットフォームはMicrosoftのまま、頭脳を選ぶ自由を使えばいい。 PTU移行についてはコスト最適化の観点でガンガン活用すべきだが、特定モデルへの深い依存は避ける設計を心がけたほうがいい。今後も移行は繰り返される。モデルをすぐ交換できる疎結合なアーキテクチャが、長期的には正解だ。 がんばれマイクロソフト。GPT-5で巻き返してくれることを本当に期待している。この批評が「古い批評」になる日を待っている。 出典: この記事は Model Upgrade and Migration Strategy for Microsoft Foundry の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Entra IDに新たなGAアップデートが届いた。「External Multifactor Authentication（外部MFA）」が正式リリースとなり、組織が現在使っているサードパーティMFAプロバイダーをそのまま活かしながら、Entraの条件付きアクセスポリシーに準拠できるようになった。ゼロトラスト移行を検討している日本企業にとって、これは無視できない選択肢だ。 外部MFAとは何か Microsoft Entra IDの「外部MFA（External Multifactor Authentication）」は、Entra ID内蔵のMFA（Microsoft Authenticatorなど）ではなく、DuoやOkta、RSA SecurIDといったサードパーティのMFAソリューションを使いながら、Entraの多要素認証要件を満たせる仕組みだ。 従来は「外部認証方式（External Authentication Methods）」という名称だったが、今回のGA昇格にあわせて機能が拡充・整理された。 仕組みとしては、条件付きアクセスポリシーで「MFA必須」と設定した場合でも、外部プロバイダーによる認証が完了していれば要件を満たしたものとして扱われる。Entra IDが発行するトークンに対して、外部MFAの完了を示すクレームが付与される形だ。 同時に押さえておきたい2026年3月のアップデート群 今回のリリースノートには外部MFAのGA以外にも注目すべき動きがある。 パスキー同期がGA FIDO2ベースの同期パスキー（Synced Passkeys）がGAとなった。iCloudキーチェーンや1Passwordなどのサードパーティパスキープロバイダーに保存したパスキーを、複数デバイス間で同期しながらEntra IDの認証に使えるようになった。デバイス紐付けパスキーと同期パスキーは、管理者がポリシーで使い分けを制御できる。 Entraバックアップ＆リカバリーがPublic Preview 誤操作やセキュリティインシデントによるテナント設定の破損を自動復元する「Entra Backup and Recovery」がPublic Previewに入った。ユーザー・グループ・アプリ・条件付きアクセスポリシーなどの重要オブジェクトを日次バックアップ（P1/P2ライセンスで5日間保持）し、差分レポートと復元ジョブで元に戻せる。 Entra Kerberos によるハイブリッド参加がPublic Preview Entra Connectの同期やAD FSを待たずに、プロビジョニング時点でWindowsデバイスをすぐにHybrid Entra Joinできる新機能。レガシーなフェデレーション依存から脱却する道筋が見えてきた。 実務への影響 日本の大企業・官公庁では、RSAトークンやDuoをすでに全社展開しているケースが多い。これまでは「Entra IDに完全移行しないと条件付きアクセスのMFA要件を満たせない」というハードルが移行の足かせになっていた。外部MFAのGAにより、既存のMFA基盤を維持したまま段階的なゼロトラスト移行が現実的な選択肢になる。 エンジニア・IT管理者が今すぐ確認すべきこと： 現行MFAプロバイダーが外部MFAに対応しているか確認 — Microsoftの認定外部プロバイダーリストを確認し、現用製品がサポートされているか確認する 条件付きアクセスポリシーの見直し — 外部MFAを活用するには、ポリシー側で「認証強度（Authentication Strength）」の設定を正しく構成する必要がある パスキーの試験導入 — 同期パスキーGAを機に、パスワードレス認証のPoC開始を検討する好機だ Entraバックアップの有効化確認 — Public Previewだが即日オンにしておく価値はある。テナント設定を壊した後悔をする前に 筆者の見解 正直に言う。この外部MFA対応は、Microsoftが「現実を認めた」アップデートだ。 日本の大企業が「Entraに移行したいけどDuoの契約が3年残ってる」「RSAトークンを全社員に配り直す予算がない」という現実に直面しながらゼロトラスト移行を止めていた状況は、ずっとおかしかった。認証基盤の刷新を「一気にやらなければならない」という強迫観念が、むしろセキュリティ改善を遅らせてきた。 ゼロトラストの本質はネットワーク境界への依存をやめることだ。MFAプロバイダーがどこのベンダーかは本質じゃない。条件付きアクセスが正しく動いているか、Just-In-Timeで適切な認可が下りているか——そこが問われる。外部MFAはその実現を「今持っている資産で」始めるための現実解だ。 ただし、勘違いしてほしくないのは、これが「VPNとオンプレADを延命させるための言い訳」になってはダメだということ。外部MFAを使いながらも、中長期では認証基盤をEntra IDに集約していく方向性は変えるべきではない。移行の入口として使うのか、現状維持の口実にするのかで、3年後の姿が全然違ってくる。 Entraバックアップの話は別で純粋に嬉しい。テナント設定を管理コンソールで誰かが誤操作してぶっ壊す事故、一度でも経験した人なら分かるはず。「神頼みの手動復元」から「定期スナップショットからの差分復元」に変わるのは、運用品質の話として本当に重要だ。Public Previewとはいえ今すぐ有効化しておくべきだと思う。 Microsoftへの辛口コメントも続けるが、このEntraまわりのアップデートの着実さは評価している。エージェントの管制塔としてのEntra IDという方向性は正しい。がんばれマイクロソフト。 出典: この記事は External Multifactor Authentication (External MFA) Now Generally Available in Microsoft Entra の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

音声でAIと自然にやり取りするリアルタイムアプリ開発が、ついに「本番向け」のステージに入った。MicrosoftがAzure OpenAI GPT Realtime APIの正式GA（一般提供）を発表し、これまでプレビューで試してきた開発者には移行の期限が迫っている。2026年4月30日——それがプレビュー版の廃止日だ。 GPT Realtime API GAで何が変わるのか 今回のGA移行で変わるポイントは大きく4つある。 SDKの差し替え: MicrosoftがプレビューSDKとして独自にリリースしていたものはGAプロトコル非対応。OpenAI公式のSDK（openai-node、openai-python、openai-dotnet等）への移行が必須 エンドポイントURLの変更: /openai/v1/ 形式に統一。2025-04-01-preview のようなAPIバージョン指定はもう含めない WebRTCエンドポイントの更新: ブラウザベースのリアルタイム音声を使っている場合、エフェメラルキー発行エンドポイント（POST /openai/v1/realtime/client_secrets）と接続URL（/openai/v1/realtime/calls）が変わる session.updateイベントの統合: 音声会話（realtime）とリアルタイム文字起こし（transcription）が同一イベントに統合され、typeフィールドで区別するようになった 逆に変わらないことも把握しておきたい。コア機能・音声フォーマットのサポート・モデル能力は引き継がれる。移行コストは想定より小さく、Microsoftは「ほとんどのケースで30〜60分」と明言している。 移行の前提条件を確認する 移行前に以下を確認しておくこと。 プレビュー（Beta）プロトコルを使った既存のAzure OpenAIリソースとデプロイがあること Azureポータルへのアクセス権限（OpenAIリソース管理が可能なロール） SDK依存関係を更新できる開発環境 本番デプロイ前に検証できるテスト環境 現在の実装がWebSocketかWebRTCかの把握 特に注意したいのが**.NET SDK**だ。OpenAI .NET v2.9.0以降でないとGAプロトコルに対応していない。バージョンを固定していたプロジェクトでは要確認。 日本の実務への影響 リアルタイム音声AIは、コールセンター自動化・音声インタフェース付きの業務アプリ・議事録リアルタイム生成など、日本の現場でもニーズが高い領域だ。これがGAになったことで、PoC止まりだったプロジェクトが本番検討のテーブルに乗ってくる。 エンジニア・IT管理者が明日から使える実践ポイント： 既存プレビューアプリの棚卸しをすぐやれ: 4月30日まで時間がない。社内でRealtime APIを試験導入しているチームがあれば、今週中にリストアップして移行計画を立てる 新規開発はGAのクイックスタートから始める: 移行ガイドではなく公式のRealtime API Quickstartが起点。プレビューの癖を引きずらない WebRTCを使っているプロジェクトは特に注意: エンドポイントが2か所変わるので、ブラウザ側とサーバー側で漏れなくテストすること OpenAI公式SDKのバージョン管理を見直す: MicrosoftのプレビューSDKとOpenAI公式SDKが混在しているプロジェクトは、依存関係の整理から始める 筆者の見解 Realtime APIのGAそのものは素直に評価できる。音声AIが「本番で使える」フェーズに入ったのは意義があるし、Azure基盤の上でこれが動くというのは、セキュリティ・コンプライアンス要件の厳しい日本の大企業にとってはむしろ歓迎だろう。 ただ、今回の移行で一つ気になることがある。MicrosoftのプレビューSDKはGAプロトコル非対応、つまりOpenAI公式SDKを使えという話だ。これ、地味にMicrosoftの「自社SDKのリードを取れない」状況を象徴していないか。AzureでOpenAIモデルを使うのにOpenAIのSDKを使えという構造は、Microsoftがプラットフォームとして機能しているのかAPIプロキシとして機能しているのか、少し曖昧に見える。 個人的にはMicrosoft Foundry経由でモデルを選んで動かすという方向性が正しいと思っている。Azureの基盤・認証・ガバナンスはそのまま使いながら、動かすAIモデルは状況に応じて選ぶ。Realtime APIが重要なユースケースではGPT-4oを使えばいい。ただし他のユースケースで別のモデルが優れているなら、そちらを選べばいい。Azureを捨てる必要はない。その上で動くAIを選ぶ自由を使えばいいだけだ。 とにかく今すべきことは明確で、4月30日までに移行を完了させること。30〜60分で終わる作業をギリギリまで放置して障害を起こすのは笑えない。 出典: この記事は Azure OpenAI GPT Realtime API is Now Generally Available の内容をもとに、筆者の見解を加えて独自に執筆したものです。

クラウドが「外に出られない」組織の福音 Microsoftが2026年2月、政府機関・防衛組織・金融・医療などの規制産業向けに「Sovereign Private Cloud」スタックを正式発表した。従来のソブリンクラウド戦略をさらに一歩進め、インターネット接続を完全に断ち切ったエアギャップ（Air-gap）環境でも、大規模言語モデル（LLM）を含むAIワークロードを安全に稼働できる体制が整った。 Sovereign Private Cloudの3本柱 今回発表されたスタックは、3つのコンポーネントで構成される。 Azure Local（旧Azure Stack HCI）の完全非接続対応 オンプレミスに設置したAzure Localが、ネットワーク接続なしでフルに機能するよう強化された。管理プレーン・課金・更新のすべてがオフライン運用に対応し、物理的に隔離された施設でもAzureサービスのエクスペリエンスを維持できる。 Microsoft 365 Local Teams・Exchange・SharePointなどM365の主要ワークロードをオンプレミスで完結させる構成だ。データが施設外に一切出ないことを保証しながら、M365 Copilotによる生成AI支援も利用可能になる。特筆すべきは、Copilotのデータ処理を自国内で行える国が新たに11か国追加された点で、日本を含む各国の規制要件への対応が加速している。 Foundry Local（旧Azure AI Foundry Local） LLMをオンプレミスのGPUクラスター上で推論・ファインチューニングできるプラットフォーム。GPT-4クラスの大規模モデルも含め、モデルのウェイトは施設内に留まる。外部APIコールは一切発生しないため、機密性の高いドキュメント処理や情報分析にも適用できる。 なぜこれが重要か——日本のIT現場への影響 日本では防衛省・内閣サイバーセキュリティセンター（NISC）・金融庁・医療機関など、クラウドへの移行を検討しながらもデータの国外持ち出し規制や秘密保護法の壁に直面してきた組織が数多く存在する。これまではオンプレミスに独自システムを構築するか、高コストのプライベートクラウドを選択するしかなかった。 今回のSovereign Private Cloudは「Azureと同じUX・同じAPIで、データは外に出さない」という要求を正面から満たす解だ。特に以下の組織にとって意味は大きい。 防衛・安全保障関連: 秘密情報を扱うシステムへのAI導入が現実的な選択肢になる 金融機関: FISC安全対策基準やデータ主権への対応をMicrosoftスタックで一本化できる 医療・自治体: 次世代電子カルテや行政DXでCopilot活用の道が開ける 実務での活用ポイント 1. 既存Azure Stack HCI環境の評価から始める すでにAzure Stack HCIを導入済みの組織は、Azure Localへのブランド統合も含め、エアギャップ対応ファームウェアへのアップグレードパスを確認すること。Microsoftはサポートマトリクスを更新しており、既存ハードウェアが対象になる場合がある。 2. Foundry LocalのGPU要件を早期に見積もる LLMをオンプレで動かすにはNVIDIA H100/A100クラスのGPUが必要になるケースが多い。調達リードタイムが長期化している現状を踏まえると、概念実証（PoC）の段階で機材選定を並行して進めるべきだ。 3. M365 Copilotのデータ処理先を確認する テナント管理者はMicrosoft 365 管理センターで「データ保存場所」と「Copilotのデータ処理地域」を確認し、今回の11か国拡大に日本が含まれているかを検証すること（現時点では順次展開中）。 4. ガバナンスポリシーの整備を先行させる Azure Policyをエアギャップ環境に持ち込む際、ポリシー定義の更新がオフラインになることを考慮したオペレーション手順の設計が必要になる。 筆者の見解 Sovereign Private Cloudの発表を見て、Microsoftがクラウドの定義そのものを拡張しようとしていると感じた。「クラウド＝インターネット経由でリソースを借りる」という常識を覆し、「Azureのオペレーティングモデルを、接続形態に関わらず提供する」という方向性だ。 この戦略はAWSやGoogle Cloudとの差別化において非常に有効だと思う。AWSのOutpostsも同様の方向性を持つが、M365とAzure AIを一体のスタックとして提供できるのはMicrosoftだけだ。特にCopilotというキラーアプリを「完全オンプレで使える」ことのインパクトは、日本の政府・公共セクターにおけるMicrosoft選定の後押しになるだろう。 一方で課題もある。エアギャップ環境ではモデルの更新・脆弱性パッチの適用がすべて手動または計画的なオフライン作業になる。AI安全性の観点から、LLMのモデルウェイト自体に仕込まれたリスクをどう管理するかは、今後の重要な論点になるはずだ。セキュリティと利便性のトレードオフを適切に設計できる人材・体制の整備が、導入組織に求められる次の課題といえる。 出典: この記事は Microsoft Sovereign Cloud adds governance, productivity and support for large AI models securely running even when completely disconnected の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft Ignite 2025で発表されたAzure Copilotの大型アップデートが、クラウド運用の常識を塗り替えようとしている。単なる会話AIアシスタントの域を超え、クラウド管理ライフサイクル全体を自律的に調整する「エージェンティッククラウド運用（Agentic Cloud Ops）」という新しい運用モデルが正式に姿を現した。 Azure Copilotとは何か——6つの専門エージェント Azure Copilotは、クラウド管理の各フェーズに特化した6種類のAIエージェントを統合したアジェンティックインターフェースだ。現在ゲートドプレビューとして提供が始まっているこれらのエージェントは以下の通り： 移行エージェント（Migration Agent） — オンプレミスやマルチクラウド環境からAzureへの移行を自律的に支援。現時点でパブリックプレビューが開始済み デプロイエージェント（Deployment Agent） — アプリケーションやインフラのデプロイ作業を自動化 最適化エージェント（Optimization Agent） — コスト・パフォーマンス・リソース利用効率の継続的改善を担当 可観測性エージェント（Observability Agent） — ログ・メトリクス・トレースを横断した統合監視 レジリエンスエージェント（Resiliency Agent） — 障害への耐性評価と自動的な信頼性向上施策の実行 トラブルシューティングエージェント（Troubleshooting Agent） — インシデント発生時の根本原因分析と解決策の提示 重要なのは、これらが単発のコマンドに応答するだけでなく、複数のエージェントが連携して複合的な運用タスクを自律実行できる点だ。 ガバナンスとセキュリティ——現場が一番気にするポイント AIエージェントに自律的な操作権限を与えるとなると、真っ先に懸念されるのがガバナンスとセキュリティだ。Microsoftはこの点を明確に意識しており、Azure CopilotはRBAC（ロールベースアクセス制御）とAzure Policyの制約の範囲内でのみ動作する設計となっている。 さらに、エージェントの操作履歴は完全に記録され、コンプライアンス監査に対応できる。チャット履歴やアーティファクトデータをユーザー自身のストレージに保持できる「Bring Your Own Storage」オプションも提供され、データレジデンシーの要件にも柔軟に対応できる。 Azureインフラの進化——70リージョン体制とAIスケール対応 エージェント機能の基盤となるAzureインフラも大幅に強化されている。世界70以上のリージョン・数百のデータセンターを擁する体制に加え、2025年9月には大規模AIワークロード特化型データセンター「Fairwater」が稼働を開始。Atlanta拠点もこれに続く形で展開が進んでいる。 コンピュート面ではAzure Cobalt（独自Armプロセッサ）とAzure Boost（オフロードシステム）、コンテナ管理ではAKS Automatic、データベースではAzure HorizonDB for PostgreSQLがラインアップに加わり、AIスケールのワークロードに対応したスタックが整いつつある。 日本のIT現場への影響——なぜ今これが重要か 日本企業のAzure活用は急速に拡大しているが、多くの組織でクラウド運用人材の不足が深刻化している。特に中堅企業では、インフラエンジニアが監視・最適化・障害対応のすべてを少人数で回す構造が続いている。 Azure Copilotのエージェント群が本番稼働レベルに達した場合、これらのルーティン運用タスクの相当部分をAIに委任できるようになる。運用コスト削減という直接効果だけでなく、エンジニアがアーキテクチャ設計やビジネス価値創出に集中できる環境が整う点が大きい。 実務での活用ポイント 今すぐできること： 移行エージェントはパブリックプレビュー開始済み。オンプレミスからの移行プロジェクトを抱えている組織は早期評価の価値がある Azure Copilotプレビューへのサインアップページが公開されているため、利用申請を検討したい 準備しておくべきこと： Azure PolicyとRBACの整備が前提条件になる。エージェントはこれらの制約に従って動作するため、ポリシーが未整備だと効果が限定的になる エージェントの操作ログをどう監査プロセスに組み込むかを事前設計しておく 「AIが自律実行する範囲」と「人間が承認する範囲」の境界線を組織として決めておく 筆者の見解 エージェンティッククラウド運用というコンセプト自体は以前から語られていたが、今回のAzure Copilotはそれを具体的な製品として形にした点で一線を画す。6エージェントの役割分担は、従来のITSM（ITサービスマネジメント）プロセスと自然に対応しており、既存の運用フローへの統合を意識した設計だと感じる。 一方で、ゲートドプレビューという段階はまだ「選ばれた組織と一緒に作り込む」フェーズであり、全面的な本番利用までには少なくとも半年から1年の成熟期間が必要だろう。AIエージェントが誤った判断でリソースを削除したり、意図しないコスト増を引き起こすリスクも現実にあるため、慎重なロールアウト計画が不可欠だ。 ...

MicrosoftがAzure AI Foundry（旧Azure OpenAI Service）上で、コーディング特化モデル「GPT-5.2-Codex」を一般提供（GA）開始した。40万トークンという桁違いのコンテキストウィンドウ、50以上のプログラミング言語対応、マルチモーダルによるコーディング支援——この3点が揃ったモデルが、既存のAzureセキュリティ境界の内側でそのまま使えるようになった意義は極めて大きい。 40万トークンのコンテキストウィンドウが変えること 現在広く使われているGPT-4系モデルのコンテキスト上限は最大128Kトークン程度だが、GPT-5.2-Codexはその約3倍にあたる40万トークンを一度の推論に投入できる。これが実務上何を意味するかというと、大規模なモノリシックコードベース全体をプロンプトに含めながら、リファクタリング・脆弱性スキャン・ドキュメント生成を一気通貫で依頼できるということだ。 たとえば、数万行規模のJavaやC#のレガシーシステムであっても、複数ファイルにまたがる依存関係ごとモデルに渡してバグの根本原因を特定させることが現実的になる。これまでは「どのファイルを切り取ってプロンプトに貼るか」という職人技が必要だったが、その手間が大幅に削減される。 セキュアコーディングとインシデント対応への対応 今回のリリースで特筆すべきは、セキュアコーディングパターンの提示・脆弱性調査・インシデント対応という用途を明示的にターゲットにしている点だ。OWASP Top 10やCWE（Common Weakness Enumeration）への対応コードを自動的に提案したり、既存コードにおけるインジェクション脆弱性を検出したりといった用途が想定されている。 セキュリティ観点でさらに重要なのは、Azure OpenAI のVNet統合・プライベートエンドポイント・カスタマーマネージドキー（CMK）といった既存のガバナンス機能をそのまま流用できる点だ。ソースコードは企業の外には一切出ない。これは特に金融・医療・官公庁系の日本企業にとって、「ChatGPTは使えないがAzure経由なら使える」という調達ルールに適合する。 実務での活用ポイント 1. CIパイプラインへのセキュリティレビュー組み込み GitHub ActionsやAzure DevOpsのPRトリガーで、GPT-5.2-Codexを呼び出して差分コードの脆弱性チェックを自動化するアーキテクチャが現実的になった。ローカルSASTツール（Semgrepなど）と組み合わせれば、誤検知を絞り込みながら精度の高いセキュリティゲートを構築できる。 2. レガシーシステムの移行調査に使う 2025年以降、多くの日本企業でオンプレ→Azureへの移行プロジェクトが活発化している。40万トークンのウィンドウを活かして、古いCOBOLやVB6のコードをそのまま入力し「どの処理がAzure Functions化できるか」の分析を依頼することが可能だ。 3. マルチモーダル機能でアーキテクチャ図からコードを生成 画像入力に対応しているため、手書きのシーケンス図やER図をスキャンして「このアーキテクチャをAzure Bicepで記述して」という使い方も有効だ。設計→実装のギャップを縮める新しいワークフローが生まれつつある。 筆者の見解 OpenAIがCodexブランドを復活させた形でこのモデルが登場したことは、Microsoftの戦略を読む上で興味深い。GPT-4oやGPT-4.5のような汎用モデルとは別に、コーディング特化モデルを独立したSKUとして提供する方向性は、Copilot製品群との差別化という観点で理にかなっている。GitHub Copilotが「IDE補完」の文脈で使われる一方、GPT-5.2-Codexは「エージェント型の大規模コード処理」に特化する分業構造が見えてくる。 日本市場においては、AIガバナンス・情報漏洩対策の観点から「クラウドに出せないコード」を抱える企業がまだ多い。そこへAzureセキュリティ境界内での提供という形でMicrosoftが打ち込んだこの一手は、まさに「日本市場向けの現実解」として機能するだろう。2026年後半にかけて、Azure AIを核にしたセキュアなコード生成基盤の整備が日本企業の競争軸になると見ている。早期に評価検証を始めた組織が、次の開発生産性競争で頭一つ抜け出すことになる。 出典: この記事は Announcing GPT‑5.2‑Codex in Microsoft Foundry: Enterprise‑Grade AI for Secure Software Engineering の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AKSのセキュリティが2026年に大幅強化——nodes/proxy権限の悪用を自動ブロック Microsoftは2026年に入り、Azure Kubernetes Service（AKS）のセキュリティ機能を大幅に強化した。特に注目すべきは、AKS Automaticにおけるnodes/proxy権限保護の多層防御機構だ。 nodes/proxy権限とは何か、なぜ危険なのか Kubernetesのnodes/proxy権限は、ノードのKubeletに対してAPIサーバー経由でプロキシアクセスを可能にするサブリソースだ。この権限を悪用されると、攻撃者はノード上で任意コードをリモート実行（RCE: Remote Code Execution）できる。クラスター内でServiceAccountに過剰な権限が付与されている場合、この権限が攻撃の足がかりになるケースが実際のインシデントでも報告されている。 日本国内でもクラウドネイティブ化を進める企業が増えており、Kubernetes環境でのRBACミスコンフィグは依然として主要なセキュリティリスクの一つとして挙げられている。 AKS Automaticが実装した多層防御 AKS AutomaticはMicrosoftが管理するKubernetesのオペレーション自動化プラットフォームだが、今回のアップデートでは以下の防御機構が追加された。 ValidatingAdmissionPolicyによるアクセス制御 Kubernetes 1.30でGAとなったValidatingAdmissionPolicy（VAP）を活用し、「システムが承認したユーザー以外へのnodes/proxy権限付与」をAPIサーバーレベルでブロックする。これにより、開発者がうっかりRoleBindingで過剰権限を付与しようとしても、クラスターが自動的に拒否する仕組みだ。 デフォルト拒否ポリシーの適用 nodes/proxyへのアクセスはデフォルトで拒否される設定が組み込まれており、明示的に承認されたシステムコンポーネント以外はこの権限を持てない。K8sセキュリティのベストプラクティス（最小権限の原則）がマネージドサービス側で自動適用される形となった。 2026年のAKSアップデート全体像 nodes/proxy保護以外にも、2026年のAKSには注目すべきアップデートが相次いでいる。 Ubuntu 24.04 + containerd 2.0がGA：K8s v1.32以降でデフォルトノードOSとなり、起動時間短縮やカーネルハードニングが向上 NCv6 GPU VMのプレビュー：次世代NVIDIAを搭載したVM seriesがAKSで利用可能に。LLMのファインチューニングやエージェント型ワークロードに最適 Azure Monitor OpenTelemetry DistroがGA：高度なサンプリングと豊富なデータ収集で分散トレースの品質が向上 Azure SRE Agentの機能拡張：GitHub Copilotによる障害対応支援やServiceNow連携など、AIOpsへの傾倒が鮮明 まとめ AKSは単なるコンテナ実行基盤から、AIネイティブ・SREフレンドリー・エンタープライズグレードのコンピュート基盤へと進化しつつある。今回のセキュリティ強化は、プラットフォームエンジニアリングチームが個別に対策を講じなくても、クラウドベンダー側でK8sセキュリティのベストプラクティスが自動適用される時代の到来を示している。 nodes/proxy権限の取り扱いに不安を感じていたチームにとっては、AKS Automaticへの移行を検討する良い機会かもしれない。 元記事: AKS Automatic Security Enhancement: nodes/proxy Permission Protection

MySQL運用データを分析基盤へ、ETL不要で即時連携 Microsoftは、Azure Database for MySQL のデータを Microsoft Fabric にほぼリアルタイムでレプリケートできる新機能「Fabric Mirroring」のパブリックプレビューを開始した。 これまでMySQLの運用データを分析基盤へ取り込むには、ETL（Extract/Transform/Load）パイプラインを自前で設計・構築・運用するか、Azure Data FactoryなどのデータインテグレーションサービスをCI/CDと組み合わせる必要があった。データエンジニアリングのコストと複雑さが採用の壁となっていたが、Fabric Mirroringはその障壁を取り除く。 Fabric Mirroringとは Fabric Mirroringは、データベースの変更をキャプチャしてターゲット側に継続的に反映する CDC（Change Data Capture） 技術をベースとした機能だ。Azure Database for MySQLに蓄積された運用データを、ほぼリアルタイムでMicrosoft FabricのOneLakeへ自動同期する。 主な特徴は以下のとおり。 ETLパイプライン構築が不要：複雑なデータ変換・転送処理をノーコードで実現 ほぼリアルタイムの同期：本番DBへの負荷を最小化しつつ最新データを分析基盤へ反映 Fabric上でそのまま分析可能：同期されたデータはFabricのSQL分析エンドポイントやPower BIから直接クエリ可能 運用コストの削減：データパイプラインの監視・メンテナンス工数が不要になる 日本企業への影響 国内でもMySQLはECサイト・SaaSプロダクト・基幹システムのDBとして広く採用されている。従来はBIや機械学習向けにデータを活用しようとすると、専任のデータエンジニアによるパイプライン設計が必要だった。Fabric Mirroringにより、開発チームが直接・低コストでFabricの分析・AI機能を活用できるようになる点は、中小規模のチームにとって特にメリットが大きい。 Microsoft Fabricは2023年に一般提供が開始されたデータ分析統合プラットフォームで、データウェアハウス・データレイク・リアルタイム分析・Power BIを一体化した基盤だ。現在すでに Azure SQL Database や Azure Cosmos DB 向けのMirroringが提供されており、今回のMySQL対応によりサポートDBの幅がさらに広がった。 利用開始方法 パブリックプレビュー期間中はAzureポータルまたはFabricポータルから設定可能。対象はAzure Database for MySQL – Flexible Serverで、既存のMySQLインスタンスから数ステップでミラーリングを有効化できる。プレビュー期間中の追加料金については公式ドキュメントを参照のこと。 ETLレスのデータ連携はデータドリブン経営の加速を後押しする。本番運用中のMySQLをそのままFabricの分析パワーと組み合わせたい場合、今が試し時だ。 元記事: Fabric Mirroring for Azure Database for MySQL – Public Preview

Azure Arc対応AKSのWindows Server 2019、本日をもってサポート終了 Microsoftは2026年4月1日をもって、Azure Arc対応AKS（Kubernetes Service）におけるWindows Server 2019ノードのサポートを正式に終了した。これにより、Windows Server 2019ベースのノードイメージの新規提供およびセキュリティパッチの配信が停止される。 影響範囲と具体的なリスク 今回の変更で最も注意が必要なのは、Kubernetesバージョンのアップグレード可否に直結する点だ。Windows Server 2019のノードが残存しているクラスターでは、今後のKubernetesバージョンアップグレードが実行不可能になる。セキュリティパッチが適用されないノードを抱えたまま本番環境を運用し続けることは、コンプライアンス上のリスクはもちろん、実際の攻撃面の拡大にもつながる。 オンプレミスやエッジ環境にKubernetesクラスターを展開するためにAzure Arc対応AKSを活用している企業にとって、この変更は看過できない。特に、Windows向けコンテナワークロードを運用している環境では早急な対応が求められる。 移行先：Windows Server 2022 Microsoftが推奨する移行先はWindows Server 2022だ。Windows Server 2022はメインストリームサポートが2026年10月まで、延長サポートが2031年10月まで提供される予定であり、今後数年間の安定した運用基盤として選択できる。 移行の基本的な手順は以下の通りだ： 既存のWindows Server 2019ノードプールの棚卸し Windows Server 2022イメージを指定した新規ノードプールの作成 ワークロードの段階的な移行（drain & cordon） 旧ノードプールの削除 なお、LinuxノードのみのクラスターはKubernetesのバージョンアップグレードに影響を受けない点も確認しておきたい。 日本企業への影響 国内では製造業や流通業を中心に、Azure Arc対応AKSをオンプレミス・エッジ環境のコンテナ基盤として採用するケースが増加している。既にWindows Server 2019を使用中のクラスターを持つ組織は、本日以降のセキュリティパッチが提供されない状態にあることを認識した上で、速やかに移行計画を策定・実行する必要がある。 移行作業を先送りにするほど、脆弱性の累積とアップグレード対応の複雑化が進む。Microsoftの公式ドキュメントと移行ガイドを参照しながら、計画的な対応を進めてほしい。 元記事: Windows Server 2019 Retirement on AKS enabled by Azure Arc

MicrosoftとNVIDIAが原子力×AI協業——インフラのボトルネック解消へ Microsoftは、原子力エネルギー産業のデジタル変革を加速するため、NVIDIAとの戦略的協業「AI for Nuclear」を発表した。この取り組みは、業界が長年抱えてきたインフラのボトルネック——すなわち、原子力発電所の新設・刷新が「理想論」から「実行」へ移行できない構造的課題——の解消を狙ったものだ。 原子力産業が直面するボトルネック 原子力発電所の建設・運用にはきわめて複雑な許認可プロセスが伴う。各国の規制当局への申請書類は膨大で、審査期間も長期にわたる。加えて、次世代小型モジュール炉（SMR: Small Modular Reactor）をはじめとする新型炉の設計には高度なシミュレーション技術が必要であり、既存の計算インフラでは処理能力が不足しているケースも多い。 こうした課題に対して、MicrosoftとNVIDIAが提供するのは、Azure クラウドと NVIDIA の GPU コンピューティングを組み合わせたエンドツーエンドのAIツール群だ。 3つの主要領域でAIを活用 今回の協業では、主に以下の3領域でAIを適用する。 1. 許認可プロセスの効率化 規制申請に必要な膨大な文書作成・管理をAIが支援。過去の申請事例や規制要件を学習したモデルが、ドラフト生成やコンプライアンスチェックを自動化する。これにより、数年単位かかることもある許認可期間の大幅な短縮が期待される。 2. 設計・シミュレーションの加速 NVIDIA の高性能GPUを活用した物理シミュレーションにより、原子炉設計の反復サイクルを高速化する。熱流体解析や中性子輸送計算など、従来はスーパーコンピュータが必要だった処理をクラウド上で柔軟にスケールアウトできる。 3. 運用の最適化 稼働中のプラントでは、センサーデータや運転ログをリアルタイム解析するAIが、予知保全や異常検知を担う。設備の故障を事前に検知し、計画外停止を減らすことで、稼働率の向上とコスト削減を同時に実現する。 日本への示唆 日本においても、2011年の東京電力福島第一原発事故以降に停止した原発の再稼働審査や、次世代炉の導入議論が続いている。原子力規制委員会への許認可申請は世界でも屈指の複雑さを誇り、AIによる審査支援の需要は高い。MicrosoftのAzureはすでに国内データセンターを複数擁しており、今回のAI for Nuclearソリューションが国内電力会社にも展開される可能性がある。 Microsoftは近年、自社データセンターの電力需要増大を背景にスリーマイル島原発の電力購入契約を締結するなど、原子力への積極的な関与を見せている。AIとクラウドの普及が電力消費を押し上げる中、その電力源としての原子力と、原子力産業を支えるAI——という相互補完的な構図が鮮明になりつつある。 今後、具体的なツールの提供時期や対応する規制フレームワークの詳細については、MicrosoftおよびNVIDIAの追加発表が待たれる。 元記事: AI for nuclear energy: Powering an intelligent, resilient future

Azure DevOps MCPサーバーがMicrosoft Foundryに登場 Microsoftは、Azure DevOps向けのMCP（Model Context Protocol）サーバーをMicrosoft Foundryで正式に提供開始したと発表した。これにより、AIエージェントがAzure DevOpsのパイプライン・作業項目（Work Items）・リポジトリを自然言語で直接操作できるようになる。 MCPとは何か MCP（Model Context Protocol）は、AIモデルと外部ツール・データソースを標準的なインターフェースで接続するためのオープンプロトコルだ。Anthropicが提唱し、近年急速に採用が広がっている。MCPサーバーを経由することで、AIエージェントはアプリケーションのAPIを直接知らなくても、自然言語の指示だけで外部システムを操作できるようになる。 何ができるようになるのか Azure DevOps MCPサーバーを使うことで、開発者やAIエージェントは以下のような操作を自然言語で実行できるようになる。 パイプラインの管理: ビルドやリリースパイプラインの状態確認、トリガー実行 作業項目の操作: バックログの確認・更新、スプリント計画の調整 リポジトリへのアクセス: コードの参照やプルリクエストの状況確認 たとえば「先週マージされたPRの一覧を見せて」「今日のビルドが失敗した原因を調べて」といった指示を、AIエージェントが直接Azure DevOpsに問い合わせて答えられるようになる。 リモートMCPサーバープレビューも同時提供 今回の発表と合わせて、リモートMCPサーバーのプレビューも提供が開始された。従来のMCP接続はローカル環境でのプロセス起動が前提だったが、リモートMCPサーバーにより、クラウド上でホストされたMCPサーバーへのHTTPS接続が可能になる。これにより、エンタープライズ環境での大規模なエージェント活用がより現実的になる。 エージェント駆動のDevOpsへ この動きは「DevOpsのエージェント化」というトレンドの加速を示している。GitHub CopilotやAzure AI Foundryとの連携により、コードの記述から本番デプロイまでの一連のフローをAIエージェントが補佐・自動化する未来が近づいている。 日本でもAzure DevOpsを活用している企業は多く、CI/CDパイプラインや作業管理にAIエージェントを組み込む需要は高い。Microsoft Foundryのエコシステムを通じて、こうした機能が標準的に利用できるようになることは、DevOpsチームの生産性向上に大きく貢献するだろう。 利用開始方法 Azure DevOps MCPサーバーはMicrosoft Foundry経由で利用可能。Azure DevOpsのサービス接続とMicrosoft Foundryプロジェクトを組み合わせることで、既存のDevOps環境にAIエージェントを統合できる。 元記事: Azure DevOps MCP Server Now Available in Microsoft Foundry

Azure App Service証明書、業界標準変更で発行方式が刷新へ Microsoftは、CA/Browser Forum（CA/B Forum）が策定する業界全体の証明書基準変更に伴い、Azure App ServiceのマネージドTLS証明書に関する重要なアップデートを発表した。この変更は2026年内に適用が予定されており、Azureでウェブアプリを運用する開発者・運用担当者は内容を把握しておく必要がある。 何が変わるのか 影響を受けるのは以下の2種類の証明書だ。 無料マネージドTLS証明書（DigiCert発行） 有償App Service証明書（GoDaddy発行） CA/B Forumは、TLS証明書の最大有効期間を段階的に短縮する方向で議論を進めており、将来的には最大47日まで短縮される見通しだ（現行は最大397日）。これはフィッシングや証明書の不正利用リスクを低減するための業界全体の取り組みであり、Google、Apple、Mozillaなど主要ブラウザベンダーが推進している。 AzureのApp Service証明書においても、この基準変更に合わせて証明書の発行方式・有効期間・更新サイクルが変更される。具体的な新しい有効期間や移行タイムラインは順次公式ドキュメントに反映される予定だ。 自動更新ユーザーへの影響は最小限 Microsoftによれば、証明書の自動更新（Auto-renewal）を有効にしているユーザーは、Azureが更新処理を自動的に行うため影響を受けにくい。App Serviceのマネージド証明書はデフォルトで自動更新が設定されているケースが多く、該当ユーザーはAzureポータルで設定状況を確認するだけで済む場合がほとんどだ。 手動管理ユーザーは対応が必要 一方、以下のケースに該当する場合は能動的な対応が求められる。 有償App Service証明書を手動で更新・管理している場合 — 有効期間の変更に伴い、更新作業の頻度が増加する 証明書をKey Vaultと連携させている場合 — Key Vaultのシークレットローテーション設定も見直しが必要になる可能性がある 外部システムが証明書の有効期間に依存している場合 — 証明書の短縮に対応できるよう監視・アラート設定を更新する 日本の運用担当者へのポイント 日本では金融・医療・公共系のシステムでApp Serviceを活用するケースも増えており、証明書の有効期限切れによるサービス停止は深刻なインシデントにつながりかねない。今回の変更を機に、証明書管理の自動化状況を棚卸しし、手動フローが残っていれば自動化への移行を検討したい。 Azureポータルの「App Service証明書」ブレードでは、各証明書の自動更新ステータスを一覧で確認できる。まずは自動更新が有効かどうかを確認することが最初のアクションだ。 詳細はMicrosoftの公式ブログ「Apps on Azure Blog」で継続的に更新される予定となっている。 元記事: Industry-Wide Certificate Changes Impacting Azure App Service Certificates

Microsoft の Azure Developer CLI（azd）が2026年3月に7つのリリース（v1.23.7〜v1.23.13）を連続投入し、AIエージェント開発からインフラ管理まで幅広い強化が施された。 AIエージェントをターミナルからエンドツーエンドで操作 最大の目玉は azure.ai.agents 拡張によるAIエージェント対応コマンド群だ。 azd ai agent run — エージェントをローカルで起動 azd ai agent invoke — ローカルまたは Microsoft Foundry にデプロイ済みのエージェントにメッセージを送信 azd ai agent show — コンテナのステータスと健全性を表示 azd ai agent monitor — コンテナログをリアルタイムストリーミング これにより、AIエージェントの開発・テスト・本番デプロイまでの全工程をターミナル一つで完結できる。Microsoft Foundry との統合が前提となっており、Azure AI 基盤に乗る開発者には特に恩恵が大きい。 GitHub Copilot が azd init に統合（プレビュー） azd init 実行時に「GitHub Copilot でセットアップ（プレビュー）」オプションが追加された。Copilot エージェントがプロジェクトのスキャフォールディングを担い、Model Context Protocol（MCP）サーバーへの同意確認も事前に行う設計となっている。 さらに、コマンド失敗時にはAIによる多段階トラブルシューティングフローが起動。「説明」「ガイダンス」「自動修正」「スキップ」の4段階から選択でき、修正適用後にそのまま失敗コマンドを再実行できる。ターミナルを離れずに問題解決できる点は実務での生産性向上に直結する。 Container App Jobs の直接デプロイ対応 これまで Container Apps のみだったデプロイ対象に、Azure Container App Jobs（Microsoft.App/jobs）が加わった。azure.yaml の host: containerapp 設定はそのままで、Bicep テンプレートの内容に応じて自動判別される。追加設定不要で既存ワークフローへの組み込みが容易だ。 ...