元Azureコアエンジニアが暴露:Microsoftが「1兆ドル」を消し飛ばした意思決定の内幕

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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

April 3, 2026 · 1 min · 胡田昌彦

【緊急対応】Azure IMDSのTLS証明書が4月15日に変わる——DigiCert G1廃止が引き起こすクラウド障害リスク

何が起きているのか 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で影響リソースを特定するとか、やりようはいくらでもあるはずだ。 ...

April 3, 2026 · 1 min · 胡田昌彦

Microsoft FoundryのGPT-5移行戦略を読み解く——PTU移行と自動アップグレードの落とし穴

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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

April 3, 2026 · 1 min · 胡田昌彦

Microsoft Entra ID「外部MFA」がGAに — 既存の多要素認証を捨てずにゼロトラスト移行できる現実解

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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

April 3, 2026 · 1 min · 胡田昌彦

Azure OpenAI GPT Realtime API が正式GA——プレビュー版は4月30日で廃止、今すぐ移行せよ

音声で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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

April 3, 2026 · 1 min · 胡田昌彦

Microsoft Sovereign Cloud、完全エアギャップ環境でLLM実行に対応——政府・防衛向け「Sovereign Private Cloud」スタック発表

クラウドが「外に出られない」組織の福音 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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

April 3, 2026 · 1 min · 胡田昌彦

GPT-5.2-Codex がMicrosoft Foundryで正式GA — 40万トークン×エンタープライズセキュリティで変わるソフトウェア開発の現場

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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

April 3, 2026 · 1 min · 胡田昌彦

Azure Database for MySQLのデータをMicrosoft Fabricへリアルタイム連携——「Fabric Mirroring」がパブリックプレビュー開始

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

April 1, 2026 · 1 min · 胡田昌彦

【移行急務】Azure Arc対応AKSでWindows Server 2019サポートが本日終了——2022への移行を急げ

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

April 1, 2026 · 1 min · 胡田昌彦

MicrosoftとNVIDIAが原子力エネルギー向けAI協業を発表——許認可から設計・運用まで一貫支援

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

April 1, 2026 · 1 min · 胡田昌彦

Azure DevOps MCPサーバーがMicrosoft Foundryで提供開始——AIエージェントが自然言語でパイプラインを操作

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

April 1, 2026 · 1 min · 胡田昌彦

Azure App Service証明書に影響する業界全体のCA/B Forum変更——自動更新が鍵

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

April 1, 2026 · 1 min · 胡田昌彦

Azure Developer CLI(azd)2026年3月アップデート:AIエージェントのローカル実行・デバッグ、GitHub Copilot統合など7リリースを一挙解説

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 テンプレートの内容に応じて自動判別される。追加設定不要で既存ワークフローへの組み込みが容易だ。 ...

March 31, 2026 · 1 min · 胡田昌彦

Azure Cosmos DB の Fabric ミラーリングがプライベートエンドポイント対応でGA——セキュアなデータ統合が本番利用可能に

Azure Cosmos DB の Fabric ミラーリング、プライベートエンドポイント対応が一般提供開始 Microsoftは、Azure Cosmos DB の Microsoft Fabric ミラーリング機能において、プライベートエンドポイント(Private Endpoint)サポートの一般提供(GA: Generally Available) を発表した。これにより、インターネットを経由せずに企業のプライベートネットワーク内でデータを安全にレプリケーションできるようになった。 Fabric ミラーリングとは Microsoft Fabric のミラーリング機能は、Azure Cosmos DB などの運用データベースのデータをリアルタイムで Fabric の OneLake へ自動的に複製する仕組みだ。アプリケーション側の運用データベースに手を加えることなく、分析・BI・AI ワークロード向けのデータ基盤を構築できる点が特長で、ETL パイプラインの開発・運用コストを大幅に削減できる。 プライベートエンドポイント対応で何が変わるか これまでのミラーリングは、パブリックネットワーク経由での接続が前提だったため、金融・医療・官公庁など厳格なネットワーク分離を求める業界での採用に課題があった。今回のGA対応により、以下のような構成が本番環境で利用可能になった。 Cosmos DB アカウントをパブリックアクセス無効に設定したまま Fabric へミラーリング Azure Virtual Network(VNet)内に閉じた通信経路でデータを転送 コンプライアンス要件(ISMS、PCI DSS 等)を満たしたデータ統合パイプラインの構築 日本国内でも金融機関やヘルスケア企業を中心に、ネットワーク分離要件のためクラウドサービスの利用範囲が制限されるケースが多い。この対応により、そうした組織でも Fabric による統合データ分析基盤を検討しやすくなるだろう。 MySQL の Fabric ミラーリングもプレビュー開始 あわせて、MySQL から Microsoft Fabric へのリアルタイムミラーリングがプレビューとして提供開始された。Cosmos DB(NoSQL)に加え、広く普及しているリレーショナルDBである MySQL もサポート対象となったことで、Fabric を中心としたデータ統合の選択肢がさらに広がっている。 まとめ 機能 ステータス Cosmos DB ミラーリング(プライベートエンドポイント) GA(一般提供) MySQL → Fabric ミラーリング プレビュー ...

March 31, 2026 · 1 min · 胡田昌彦

Azure Speech Neural HD音声が値下げ&新リージョン展開——音声AI開発のコストが27%削減

Azure Speech Neural HD TTSが大幅値下げ、新リージョンにも展開 Microsoftは、Azure Speechが提供する高品質音声合成サービス「Neural HD Text to Speech(TTS)」について、価格の引き下げと提供リージョンの拡大を発表した。 価格が約27%値下げ 従来、Neural HD TTSの利用料金は100万文字あたり30ドルだったが、今回のアップデートにより22ドルへと引き下げられた。削減率は約27%で、音声AIアプリケーションを大規模に運用している開発者や企業にとって、ランニングコストの大幅な削減につながる。 日本語でも高品質な音声合成が求められる場面——コールセンター向けのIVR(自動音声応答)、ナレーション生成、アクセシビリティ機能など——での活用コストが下がることは、国内の開発者にとっても朗報といえる。 新リージョンへの展開開始 Neural HD TTSが利用可能なリージョンとして、新たに以下が追加された。 West US 2 East US 2 Canada Central リージョンの拡大により、データレジデンシー(データ保管場所)の要件が厳しいエンタープライズ利用や、レイテンシを重視するリアルタイム音声アプリケーションにおいても、より柔軟な構成が取れるようになる。 Neural HD TTSとは Neural HD TTSは、Azure Speechが提供する音声合成エンジンの中でも特に高品質なラインで、自然なイントネーション・感情表現・滑らかな発話を実現する。従来のニューラルTTSと比べ、より人間らしい音声出力が得られるとされており、音声アシスタント、ポッドキャスト自動生成、教育コンテンツ読み上げなど幅広いユースケースで採用が進んでいる。 音声AI開発のハードルが下がる 生成AIブームに伴い、テキスト生成と組み合わせたエンドツーエンドの音声AIサービスへの需要が急増している。今回の値下げとリージョン拡大は、Azure AI Foundryエコシステム全体としてのコスト競争力強化の一環とも読めり、AWSのPollyやGoogle CloudのText-to-Speechとの競合に向けた動きとも言えるだろう。 Azure Speech Neural HD TTSの詳細や利用開始手順は、Azure公式ドキュメントおよびAzure AI Foundry Blogで確認できる。 元記事: Azure Speech – Neural HD Text to Speech: Recent Voice Updates

March 31, 2026 · 1 min · 胡田昌彦

DockerでAzureサービスのユニットテストを実現——Spring Cloud Azure活用ガイド

Azureサービスのテストが「ローカルだけ」で完結する時代へ Azureを使ったSpring Bootアプリケーションの開発において、ユニットテストは長年の課題だった。実際のAzureリソースをプロビジョニングしなければテストできないとなると、コストも時間もかかる。そこで注目されるのが、Spring Cloud AzureとDockerを組み合わせたテスト手法だ。 MicrosoftのAzure SDK Blogが公式に解説したこのアプローチでは、本物のAzure環境を一切使わずに、ローカルのDockerコンテナ上でAzureサービスをエミュレートしてテストが実行できる。 Spring Cloud Azureとは Spring Cloud Azureは、SpringアプリケーションからAzureサービスを簡単に利用できるようにするOSSプロジェクトだ。Azure Storage、Service Bus、Event Hubsなど主要なAzureサービスとのシームレスな統合を提供しており、Springの自動設定(Auto Configuration)の仕組みに乗っかった形で動作する。 DockerをユニットテストのAzure代替として使う 今回紹介されているアプローチのポイントは、Azurite(Azureストレージエミュレーター)などのDockerイメージを使うことにある。spring-cloud-azure-docker-compose という依存ライブラリを追加するだけで、テスト実行時にDockerコンテナが自動起動し、テスト完了後に自動停止する。 Azure Blob Storageのテスト例 Maven(pom.xml)への依存追加は以下の3点が基本となる: 元記事: Writing Azure service-related unit tests with Docker using Spring Cloud Azure

March 30, 2026 · 1 min · 胡田昌彦

Azure Container Apps「Dynamic Sessions」登場——AIワークロードのコスト削減とレイテンシ改善を両立するエフェメラル実行環境

Microsoftは、Azure Container Appsに新機能「Dynamic Sessions(ダイナミック セッション)」を追加したと発表した。AIタスクに特化したエフェメラル(一時的)なサンドボックスコンピューティング環境を迅速にスピンアップできる仕組みで、アイドル時のコスト削減と推論レスポンスの向上を同時に実現する。 Dynamic Sessionsとは何か Dynamic Sessionsは、AIエージェントや生成AIアプリケーションがコードを安全に実行したり、外部ツールを呼び出したりするための使い捨てサンドボックスを動的に生成する機能だ。セッションは必要なときにだけ起動し、タスク完了後は自動的に破棄される。従来のコンテナアプリと異なり、常時稼働のプロセスを維持する必要がなく、アイドル状態でのコンピューティングコストを大幅に削減できる。 解決する課題 LLM(大規模言語モデル)ベースのAIエージェントが急速に普及するにつれ、推論処理の中でPythonコードの実行・外部API呼び出し・ファイル操作といった「ツール使用」のニーズが急増している。こうした処理を既存の本番コンテナ内で直接実行すると、セキュリティリスクやリソース競合が問題になりやすい。Dynamic Sessionsはこの課題を根本から解決するアーキテクチャを提供する。 主な特徴は以下の通りだ。 即時起動: リクエストのたびにサンドボックスを高速生成し、推論レスポンスのレイテンシを最小化 完全な隔離: 各セッションは独立した環境で実行されるため、セッション間のデータ漏洩リスクがない スケーラビリティ: 並列AIワークロードに対して自動的にセッションをスケールアウト コスト最適化: 使った分だけの課金で、アイドルコストをゼロに近づける 日本市場への影響 CopilotやカスタムAIエージェントを企業向けシステムに組み込む動きが国内でも加速している。特に製造・金融・小売分野でのAIエージェント導入が進む中、安全なコード実行環境のニーズは高まる一方だ。Azure上でAIエージェントを構築している日本の開発チームにとって、Dynamic Sessionsはインフラ管理の複雑さを減らしながらセキュリティ要件を満たす現実的な選択肢となりうる。 利用開始 Dynamic Sessionsは現在、一部顧客向けのプレビュー段階にある。Azure Container Appsを利用中のユーザーはAzureポータルまたはAzure CLIから機能を有効化できる。GA(一般提供)のタイムラインはMicrosoftから追って発表される予定だ。 AIエージェント基盤をクラウドに構築する際の「実行環境の安全な分離」という課題に、Azureが本格的な解答を示した形となる。今後のGA展開と料金体系の詳細に注目したい。 元記事: Azure Container Apps Dynamic Sessions: Ephemeral Compute for AI Inference

March 30, 2026 · 1 min · 胡田昌彦

【緊急】AKS Azure Linux 2.0が3月31日でサポート終了——今すぐAzure Linux 3への移行を

AKS Azure Linux 2.0、3月31日でサポート完全終了 Microsoftは、Azure Kubernetes Service(AKS)で使用されているノードイメージ「Azure Linux 2.0」のサポートを2026年3月31日をもって完全終了すると発表した。この期限を過ぎると、Azure Linux 2.0を使用しているノードプールのスケールアウト・スケールインが一切できなくなるため、運用中のクラスターを持つエンジニアは早急な対応が求められる。 何が起きるのか タイムラインを整理すると以下のとおりだ。 2025年11月30日: AKSによるAzure Linux 2.0へのセキュリティアップデート提供終了。ノードイメージは202512.06.0リリースで凍結 2026年3月31日: ノードイメージを削除。以降はノードプールのスケール操作が不可能に セキュリティパッチが止まった状態でイメージが凍結されているため、すでに新規構築での利用は推奨されない状況だ。3月31日以降はスケール操作自体ができなくなるため、実質的にクラスターの運用継続が困難になる。 移行方法 Microsoftが推奨する移行方法は2つある。 方法1: Kubernetesバージョンのアップグレード ノードプールをサポート対象のKubernetesバージョンにアップグレードする。この過程でノードイメージも新しいものに更新される。 方法2: osSku を AzureLinux3 に変更 ノードプールのosSkuパラメーターをAzureLinux3に変更して移行する。Azure Linux 3(旧称: Mariner)はRed Hat系のパッケージ管理を採用しており、Azure Linux 2.0との互換性も高い。 同日に廃止されるもう一つの機能 Azure Linux 2.0のEOLと同日、ノードプールに設定できるタグ aks-disable-kubelet-serving-certificate-rotation=true もサポート対象外となる。このタグでkubeletの証明書ローテーションを無効化していた環境では、合わせて設定の見直しが必要だ。 AKSのKubernetesバージョンサポートポリシー AKSはGA(一般提供)バージョンに対して12ヶ月のサポートポリシーを採用している。長期サポート(LTS)を有効化した場合はさらに延長されるが、Azure Linux 2.0はLTS期間中(v1.28〜v1.31)においても今回のEOLが適用されるため注意が必要だ。 現在サポート対象のバージョンは以下のとおり(標準サポート)。 バージョン AKS GA サポート終了 1.32 2025年4月 2026年3月 1.33 2025年6月 2026年6月 1.34 2025年11月 2026年11月 1.35 2026年3月 2027年3月 対応期限は今日 本記事の執筆時点で、期限の2026年3月31日は本日だ。まだ移行が完了していない場合は、直ちにAzureポータルまたはAzure CLIでノードプールのアップグレードに着手することを強く推奨する。移行の詳細手順はMicrosoft公式ドキュメントおよびRetirement GitHub Issueを参照のこと。 元記事: AKS Azure Linux 2.0 End of Life on March 31, 2026 – Migration Required ...

March 30, 2026 · 1 min · 胡田昌彦

Azure SQL Managed Instance、SQL Server 2025 更新ポリシーが一般提供(GA)開始——旧ポリシー廃止スケジュールも明らかに

Azure SQL Managed Instance に SQL Server 2025 更新ポリシーが正式提供開始 Microsoft は、Azure SQL Managed Instance(SQL MI)における SQL Server 2025 更新ポリシー(Update Policy) の一般提供(General Availability / GA)を発表した。これにより、企業はエンジンバージョンの更新サイクルをより柔軟にコントロールできるようになる。 更新ポリシーとは何か SQL MI の更新ポリシーは、マネージドインスタンスが追従するエンジンバージョンのトラックを定義する設定だ。従来の SQL Server 2022 ポリシー では、最新の SQL Server 2022 互換アップデートが自動適用されていたが、新しい SQL Server 2025 ポリシー では、SQL Server 2025 相当の機能アップデートをいち早く受け取ることが可能になる。 変更の影響範囲 今回の GA にともない、以下の管理インターフェースで新ポリシーの設定変更が可能になった。 Azure Portal — インスタンス設定画面の UI が更新され、ドロップダウンから新ポリシーを選択できる REST API — updatePolicy プロパティ経由でプログラム設定に対応 PowerShell — Set-AzSqlInstance コマンドレットにパラメーターが追加 Azure CLI — az sql mi update コマンドでも同様に設定可能 IaC(Infrastructure as Code)でインスタンスを管理しているチームは、Bicep や Terraform のテンプレートに updatePolicy の明示指定を追加しておくことで、意図しないポリシー変更を防げる。 ...

March 30, 2026 · 1 min · 胡田昌彦

【重要】Azure デフォルトアウトバウンドアクセス廃止:Azure Virtual Desktop利用者が今すぐ確認すべき移行対応

Azureのデフォルトアウトバウンドアクセスが廃止へ——Azure Virtual Desktop利用者は要対応 Microsoftは2026年3月31日以降、新規作成されるAzure仮想ネットワーク(VNet)において、デフォルトアウトバウンドアクセス(Default Outbound Access / DOA) を無効化する重大なポリシー変更を実施する。この変更はAzure Virtual Desktop(AVD)を利用している組織に特に大きな影響を与えるため、早急な対応が求められている。 デフォルトアウトバウンドアクセスとは これまでAzureでは、VNet内のリソースが明示的な設定なしにインターネットへのアウトバウンド通信を行える「デフォルトアウトバウンドアクセス」が暗黙的に提供されてきた。しかしMicrosoftはゼロトラストネットワーク(Zero Trust Network)の原則に基づき、この暗黙的な接続を廃止する方向へ舵を切った。 ゼロトラストとは「信頼しない、常に検証する」を基本原則とするセキュリティモデルで、クラウド環境では特に重要視されている。デフォルトで外部通信を許可するという従来の設計は、このモデルと相容れないものだった。 AVD利用者への具体的な影響 2026年3月31日以降に新規作成するVNetでは、DOAが自動的に無効となる。既存のVNetへの影響は現時点では対象外だが、新規環境の構築や既存環境のVNet再作成時には対応が必要になる。 Azure Virtual Desktopはセッションホスト(仮想デスクトップVM)がインターネットやMicrosoftのサービスエンドポイントへ接続する必要があるため、アウトバウンド接続が確保されていない場合、仮想デスクトップの起動や認証、更新処理が正常に動作しなくなるリスクがある。 推奨される代替接続方式 Microsoftは以下の明示的なアウトバウンド接続方式への移行を推奨している: NAT Gateway:シンプルかつスケーラブルなアウトバウンドNATソリューション。新規環境には最も推奨される選択肢 Azure Firewall / NVA(ネットワーク仮想アプライアンス):トラフィックの制御・監視が必要なエンタープライズ環境に適合 ロードバランサー(アウトバウンドルール付き):既存のロードバランサー構成と統合する場合に有効 今すぐ確認すべきこと 日本国内でAVD環境を運用・設計している担当者は、以下の点を確認することを強く推奨する: 現在利用中のVNetがDOAに依存していないか棚卸しを行う 今後新規構築するAVD環境では、設計段階からNAT GatewayやAzure Firewallを組み込む テスト環境で接続方式の切り替えを事前に検証する この変更はセキュリティ強化の観点から歓迎すべき方向性だが、準備なく新規VNetを作成すると接続障害につながる可能性がある。期限の2026年3月31日まで時間的余裕は少なく、早急な対応計画の策定が望まれる。 元記事: Azure’s Default Outbound Access Changes: Guidance for Azure Virtual Desktop Customers

March 28, 2026 · 1 min · 胡田昌彦