Azure

クラウドが「使えない」現場がある パブリッククラウドは便利だ。しかし現実には、インターネットに常時つながることができない場所で動く重要システムが世界中に存在する。軍・防衛、エネルギーインフラ、公共安全機関、遠隔地の研究施設——こうした環境ではデータをクラウドに送ること自体が規制や安全保障上の要件と衝突する。 MicrosoftとArmadaはこの「ラストマイル問題」に正面から取り組む協業を発表した。Azure Local を Armada の Galleon モジュラーデータセンター（MDC）上に展開し、切断・制限・移動環境でも Azure のクラウド運用モデルをそのまま持ち込める「主権エッジ（Sovereign Edge）」基盤を実現する。 何が新しいのか Azure Local × Galleon MDC の組み合わせ Azure Local は Microsoft のオンプレミスクラウドプラットフォームで、Azure の管理モデルやセキュリティを自前環境に持ち込める製品だ。今回はこれを Armada の Galleon MDC という物理的に展開可能なモジュール型データセンター上で動かす。 Galleon MDC は「運べるデータセンター」として設計されており、衛星・LTE/5G・RF・SD-WAN などの多様な回線に対応した回復性の高いネットワーク接続、ハイパーコンバージドおよび SAN バックストレージ、政府・規制準拠のセキュリティハードニングをパッケージで提供する。完全切断状態でも動作し続ける設計になっている点が最大の特徴だ。 Foundry Local によるオンプレ AI 推論 インフラだけでなく、AI ワークロードもこの環境で完結させられる。Microsoft Sovereign Private Cloud の一部として提供される Foundry Local を使えば、AI 推論・分析処理をパブリッククラウドへの接続なしに自分たちのトラストバウンダリ内だけで完結させることができる。 この構成が対応するユースケースは具体的だ： データ主権要件への対応 — データを自国・自組織のインフラ外に出さない 低遅延のリアルタイム判断 — 分析結果をその場で意思決定に使う 帯域制約・断絶環境での AI 運用 — 接続が不安定な現場でも AI が止まらない 日本のIT現場への影響 「これは海外の防衛案件の話」と思うかもしれないが、日本にとっても無関係ではない。 まず経済安全保障・データ主権の観点。日本の経済安全保障推進法により、重要インフラ事業者（電力・通信・金融・交通等）は外部依存を最小化しながらデジタル化を進めることが求められている。「国産クラウド」という選択肢が現実的でない中、この種の「主権プライベートクラウド」は現実的な落としどころになりえる。 次に地方・離島・災害時の継続性。日本は離島が多く、災害時に回線が切断されるリスクが高い環境だ。このアーキテクチャは「平常時はクラウド接続、断絶時でも AI/データ処理を継続」という運用を可能にする。官公庁・自治体・公共インフラ事業者にとって検討価値は高い。 ...

「障害が起きたとき、どう振る舞うか」から設計する時代 AzureのIaaSチームが、耐障害性設計に関するベストプラクティスシリーズの第2弾を公開した。今回のテーマは「ビルトイン・レジリエンシー」、つまりAzureプラットフォームが標準で提供する可用性・継続性・リカバリーの仕組みを、実際の業務システムにどう組み込むかという実践的な話だ。 技術的な内容に入る前に、一点だけ強調しておきたい。このシリーズが繰り返し述べている「障害はエッジケースではなく現実だ」という一文は、インフラ設計の哲学として非常に本質を突いている。日本のエンタープライズIT現場では、まだ「落ちないようにする」思想が支配的だが、クラウド時代に求められるのは「落ちたときにどう振る舞うか」の設計である。 可用性ゾーンとVM Scale Setsの組み合わせが鍵 物理配置から始まるコンピュート耐障害性 Azureのコンピュート耐障害性は「配置」と「分離」がベースになる。仮想マシン（VM）を一カ所に集中させると、局所的な障害がワークロード全体に波及するリスクが高まる。 Virtual Machine Scale Sets（VMSS） は、スケールと可用性を同時に確保するための機能だ。インスタンスを可用性ゾーンや障害ドメイン（Fault Domain）をまたいで自動的に分散配置し、フロントエンド層・アプリケーション層などの分散サービスを安定稼働させる。スケールアウト/インの自動化だけでなく、障害発生時の影響範囲（ブラストラジウス）を最小化できる点が重要だ。 可用性ゾーン（Availability Zones） はデータセンター単位の分離を提供する。各ゾーンは独立した電源・冷却・ネットワークを持ち、1つのゾーンが影響を受けても他のゾーンが稼働し続ける設計になっている。ゾーンをまたいだアーキテクチャを組むことで、単一拠点障害によるサービス停止を防ぎやすくなる。 ストレージとネットワーク層も同様の考え方で コンピュートだけ冗長化しても、ストレージやネットワークが単一障害点になれば意味がない。IaaSの耐障害性設計は、この3層を一体として考えることが大前提だ。AzureはZone-Redundant Storage（ZRS）やAzure Load Balancerなど、各層で対応する機能を提供している。 実務への影響 — 日本のエンジニア・IT管理者が意識すべきこと 「設計一回きり」では通用しない ブログ内でも触れられているが、「耐障害性設計は一回決めたら終わり」ではない。アーキテクチャが分散・複雑化するにつれ、設計の見直しは継続的に必要になる。MicrosoftはAzure IaaS Resource Centerとして、チュートリアルとベストプラクティスを集約しているので、参照先として押さえておくとよい。 Well-Architectedフレームワークとの接続 Azure Well-Architected Framework（WAF）の信頼性（Reliability）柱と今回の内容は直結している。WAFのレビューを定期的に実施している組織は、今回のシリーズをそのアップデートインプットとして活用できる。未実施であれば、まずWAFレビューから着手するのが「道のド真ん中」だ。 段階的な移行が現実的 既存のオンプレミスワークロードをAzureにリフト&シフトしただけでは、耐障害性の恩恵は限定的だ。VMSSへの移行や可用性ゾーンをまたいだ構成への再設計は、一度に全部やる必要はない。優先度の高いミッションクリティカルなワークロードから順に「クラウドネイティブな耐障害性」を組み込んでいくアプローチが現実的だ。 筆者の見解 AzureのIaaS基盤そのものに対する信頼は揺るがないと私は思っている。可用性ゾーン、VMSSといった機能群は成熟しており、エンタープライズの要件に十分応えられる水準にある。今回のブログシリーズが「基盤から丁寧に語り直す」形式を取っていることも、地に足のついた良い発信だと感じる。 一方で、率直に言えば日本のエンタープライズIT現場との温度差はまだある。「落ちないようにする」から「落ちることを前提に設計する」への思想転換が、まだ浸透しきっていない組織は多い。Azureが正しい設計思想を提供しているのだから、あとはそれを使いこなす側の問題だ。 もう一点加えると、こうした基盤の詳細を追い続けることの意味は、以前と少し変わってきている。AIエージェントが管理タスクを担うようになる未来では、「どの機能をどう組み合わせるか」を人間がすべて把握しなくてよくなる。エンジニアが本当に意識すべきは、「Azureが何を保証し、何を自分たちで設計すべきか」という責任分界点の理解だ。この「共有責任モデル」の本質は、どれだけAIが進化しても変わらない。そこを正しく理解した上で、Azureの耐障害性機能を使い倒してほしい。 出典: この記事は Azure IaaS: Keep critical applications running with built-in resiliency at scale の内容をもとに、筆者の見解を加えて独自に執筆したものです。

音声AIの実用化フェーズが、いよいよ本格的に始まりつつある。Microsoft Foundryに、gpt-realtime-1.5 と gpt-audio-1.5 という2つの新しい音声特化モデルが追加された。低遅延・多言語対応・命令追従性の向上という3点セットで、これまで「技術デモ」の域を出なかったリアルタイム音声AIアプリケーションの実用展開を、一段と現実的な選択肢に押し上げている。 何が変わったのか：2モデルの役割分担 今回追加された2モデルはそれぞれ異なる用途に最適化されている。 gpt-realtime-1.5 は、名前の通りリアルタイム性を最優先した設計だ。音声入力から応答までの遅延を極限まで削ることを目指しており、コールセンターの自動応答、会議中のリアルタイム通訳補助、インタラクティブな音声アシスタントなど、「会話のテンポ」が体験品質を左右するシナリオ向けに作られている。 gpt-audio-1.5 は、音声の豊かな表現力と多言語対応にフォーカスしたモデルだ。命令追従性（instruction following）が向上しており、システムプロンプトで指示したキャラクター・トーン・話し方のスタイルをより忠実に再現できる。日本語をはじめとする多言語の自然さも改善されており、ナレーション生成、音声コンテンツ制作、教育系アプリへの応用が見込まれる。 両モデルに共通する強化点として、ツール呼び出し（Function Calling）との統合精度向上が挙げられる。音声で「明日の東京の天気を調べて」と言えば、外部APIを呼び出して回答するような音声エージェントの構築が、これまでより安定して動作するようになった。 なぜMicrosoft Foundryが重要か これらのモデルが「Azure OpenAI」ではなく「Microsoft Foundry」というプラットフォームで提供されている点は見逃せない。Microsoft Foundryは、複数のAIモデルを統一的なインターフェースで扱い、エージェントとして組み合わせるための基盤だ。単にAPIを叩くだけでなく、プロンプト管理・評価・デプロイまでを一元管理できる。 Entra ID経由のアクセス制御、Azure Private Endpointによるネットワーク分離、コンプライアンス要件への対応――こうした「エンタープライズが安心して使うための環境」がすでに整っているのがAzure基盤の強みだ。音声AIという新しいモダリティを、ゼロから新しいセキュリティアーキテクチャを設計することなく既存の統制の傘の下で試せる。これは日本の大規模エンタープライズにとって、実は相当大きなアドバンテージである。 実務への影響：日本のエンジニア・IT管理者はどう動くか すぐに試せること： Microsoft Foundry のプレイグラウンドで gpt-realtime-1.5 の遅延感を体感する。音声AIのUX評価は「触って感じる」が最速の判断軸だ。 既存のTeamsや社内ポータルへの音声アシスタント統合を検討しているチームは、Function Callingとの連携デモをPoC対象に加えると良い。既存のAPI資産をそのまま流用できる可能性が高い。 多言語コールセンター（日英・日中など）の自動化を検討中の組織は、gpt-audio-1.5 の多言語性能を評価リストに入れるタイミングだ。 設計上の注意点： リアルタイム音声はテキストと比べてレイテンシ要件が厳しく、ネットワーク品質が体験に直結する。Azure Regionsの選択（Japan East推奨）と、WebSocket接続の安定性確保は設計段階から織り込んでおく必要がある。また、音声データはプライバシーリスクが高いため、データ保持ポリシー（Zero Data Retention対応の確認）は必ず事前に確認すること。 筆者の見解 リアルタイム音声AIが「動くデモ」から「使えるプロダクト」に移行するためのハードルは、モデル性能だけではなかった。遅延、多言語品質、外部システムとの連携精度、そしてエンタープライズ水準のガバナンス――これらが同時に揃わないと、現場への導入判断が出ない。今回の2モデルは、その「同時に揃える」部分をかなり真剣に詰めてきた印象がある。 Microsoft Foundryというプラットフォームの方向性は、個人的に正しいと思っている。「どのAIモデルを使うか」という選択を抽象化し、エンタープライズが安全に動かせるインフラを提供する――この戦略は長期的に見て堅い。AIモデルそのものの最先端争いとは別の軸で、Microsoftが強みを発揮できる土俵だ。 一方で、音声AIの体験品質はまだ「すごいね」で終わりやすい段階にある。日本語の自然さ、感情表現の細かさ、長い文脈での一貫性――使い込むと気になる部分は依然として出てくる。それでも、コールセンター自動化や社内ヘルプデスクの音声対応など、「90点の品質でも十分価値がある」ユースケースは確実に存在する。そこを狙って実績を積み上げることが、今のエンジニアにとっての現実的な正解だろう。 情報を追い続けることよりも、自分の手で動かして成果を出す経験を積む――そのための素材として、今回のアップデートは十分に価値がある。まずは触ってみることをすすめたい。 出典: この記事は New Azure OpenAI models bring fast, expressive, and real-time AI experiences in Microsoft Foundry の内容をもとに、筆者の見解を加えて独自に執筆したものです。

クラウド移行プロジェクトが失速する原因のひとつは、技術的な難しさよりもむしろ、移行前の調査・計画フェーズの膨大な手間だと言われてきた。Microsoftはこの課題に正面から向き合う形で、Azureポータルに統合されたAI搭載の「Azure Copilot Migration Agent」をパブリックプレビューとして公開した。 Migration Agentが解決しようとしていること Flexeraの「State of the Cloud Report」によれば、企業のクラウド予算は平均17%超過しており、84%の組織がコスト管理を最大の課題として挙げている。その多くは、移行計画が甘いまま実行フェーズに入ることが原因だ。 Migration Agentは、この「移行前の計画・評価フェーズ」に特化したAIアシスタントとして位置づけられており、既存のAzure Migrateデータの上で動作する。主な機能は3つだ。 1. エージェントレスVMware検出 Azureへの直接接続や既存ネットワーク構成の変更なしに、VMware環境のインベントリ作成・依存関係マッピング・6R（Rehost/Refactor/Rearchitect/Rebuild/Replace/Retire）分類を自動生成できる。オフライン環境向けには「Azure Migrate Collector」が新たにパブリックプレビューで提供され、Azure接続が未確立な環境でもインベントリ収集が可能になった。 2. ランディングゾーンの自動構成 MicrosoftのCloud Adoption Frameworkに準拠したランディングゾーンを自動生成し、TerraformまたはBicepのテンプレートを出力する。ネットワーク・IDポリシーの設定から、ワークロード移行の順序を整理した「ウェーブプラン」の作成まで一括で行える。 3. GitHub Copilotとの連携 .NETやJavaアプリケーションのモダナイゼーション作業をGitHub Copilot経由で開発チームに引き渡す機能も備える。CAST Highlightなど第三者ツールとの連携による詳細なリファクタリング分析にも対応している。 「計画専門」という現実——実行は従来どおり 「パブリック利用可能」という発表にもかかわらず、実態は依然パブリックプレビューであり、重要な制約がある。 Migration Agentにできないこと: VMのレプリケーション テスト移行 カットオーバーの実行 これらはすべて従来どおりAzure Migrateポータル上で行う必要がある。つまり、このエージェントは既存ワークフローの「置き換え」ではなく、計画フェーズに特化した「知的なアシスタント層」として捉えるべき存在だ。 さらに、ランディングゾーンテンプレート生成を含む完全なエンドツーエンド計画サポートは現時点ではVMwareワークロードのみに限定されており、Hyper-VやベアメタルはAnalysisと戦略ガイダンスにとどまる。また、Copilotの会話履歴にBring Your Own Storageを利用しているテナントでは利用不可、かつテナントレベルでプレビューの明示的な有効化が必要という制約もある。 実務への影響——日本のIT現場で使えるか BroadcomによるVMware買収後のライセンス変更を受けて、多くの日本企業がVMware基盤の今後を見直している。そのタイミングでこのエージェントが登場したことは、移行検討の入り口として意味がある。 IT管理者・インフラエンジニアへの実践的なヒント： まず棚卸しから始める: エージェントレス検出機能を活用し、現状のVMwareインベントリと依存関係を可視化するだけでも価値がある。移行しない場合でも、現行環境の把握に使える Terraformを使っていないなら好機: ランディングゾーンのBicepテンプレート自動生成は、Azure構成のベストプラクティスを学ぶ教材としても活用できる 「計画ツール」として評価する: 移行の実行自体を期待すると失望する。あくまでアセスメントと計画の工数削減ツールとして評価軸を合わせるべき テナント設定の確認を忘れずに: プレビュー機能はテナントレベルで有効化が必要。IT部門の管理者は事前に確認しておくこと 筆者の見解 MicrosoftがAzure Migrateの計画フェーズにAIを組み込んできたこと自体は、正しい方向性だと思う。移行プロジェクトの失速要因の多くが「人手による調査・計画の重さ」にあることは現場でも実感しているし、そこをAIで自動化しようというアプローチは道のど真ん中を歩いている。 ただ、「計画は自動化できるが、実行はまだ従来どおり」という現時点のスコープは、率直に言えばやや物足りない。VMware以外への対応が限定的な点も、日本の大企業に多いHyper-V環境を考えると、すぐに恩恵を受けられる組織は限られる。 Microsoftにはプラットフォームとしての総合力がある。AzureのID基盤・ネットワーク・ガバナンスの体制は業界でも屈指の完成度だ。だからこそ、この「計画専用」の制約を早期に乗り越えて、実行フェーズまで一気通貫でカバーできる形に進化させてほしい。今のMicrosoftならそれができる力を十分に持っているはずだ。 クラウド移行を検討している組織にとっては、プレビューの今から触っておくことで、GA（一般提供）時にスムーズに活用できる下地を作れる。まずは手元のVMware環境の棚卸しツールとして使い始め、機能の進化を追っていくのが現実的なアプローチだろう。 出典: この記事は Microsoft Launches Azure Copilot Migration Agent to Accelerate Cloud Migration Planning の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Azureが2026年4月3日付けで大量のアップデートを公開した。なかでも目を引くのが Azure SQL Managed Instance（SQL MI）のAI搭載PaaS化と、インフラのドリフト検出・修復提案ツールの追加だ。地味に見えて、実はDBとインフラ運用の現場を根本から変えるポテンシャルを持つ変更である。 Azure SQL MI：「AIが入ったマネージドDB」へ 今回のアップデートで、SQL MIは単なる「サーバーレスなSQL Server」から一歩踏み込み、以下の機能がサービスに組み込まれた。 自動チューニング（Automated Tuning）: クエリの実行計画をAIが継続監視し、パフォーマンスが劣化する前に自動で最適化を提案・適用する 異常検知（Anomaly Detection）: 通常のワークロードパターンから逸脱した動作をリアルタイムで検出。障害の予兆を早期に捉えられる モデル駆動インサイト（Model-Driven Insights）: AIが蓄積されたメトリクスを解析し、インデックス設計やリソース配分に関する具体的な改善提案を出す 重要なのは、これらが「外部ツールを組み合わせた拡張機能」ではなく、SQL MIサービスそのものに内包された点だ。アンダーレイのサーバー管理が不要なPaaSの強みと、AIによるインテリジェントな運用支援が一体化した。 インフラのドリフト検出：構成ずれを自動で発見・修復提案 もうひとつの大きな変更が、AIによるインフラ構成ドリフト検出ツールだ。 デプロイしたAzureリソースが「あるべき構成（desired state）」からいつの間にかずれてしまう「ドリフト」は、エンタープライズ環境では慢性的な悩みだ。誰かが緊急対応でポータルから手動変更した、古いスクリプトが残っていた——そういった蓄積が気づかないうちにコンプライアンス違反やセキュリティホールを生む。 新ツールはデプロイ済みリソースと定義済み構成を自動比較し、差異を検出した上で修復提案まで提示する。Infrastructure as Codeを活用していれば特に効果が高く、Bicep・Terraform等との組み合わせで「構成の真実の情報源」を常に守る仕組みが整う。 注意すべき廃止スケジュール 今回のアップデートには、運用担当者が見落としてはいけないサービス廃止通知も含まれている。 App Service / Azure Functions における Python on Windows のサポート終了: 移行期限は2027年まで。既存ワークロードがある場合は早めにLinuxコンテナへの移行計画を立てること Storage向け Azure DNS Endpoints の廃止: こちらも2027年タイムラインで移行が必要。ストレージ関連の接続構成を持つシステムは影響範囲の確認が急務 SRE Agentの課金モデル変更: アクティブフロー単位の従量課金に変更される。利用量の多い環境では想定外のコスト増にならないよう、利用状況の確認を推奨 実務への影響 DBエンジニア・DBA向け: SQL MIの自動チューニングとインサイト機能は、慢性的な人手不足が続く日本のDB運用現場に直結する恩恵だ。「クエリが遅い原因を深夜に調査する」「定期的なインデックス見直しをスケジューリングする」といった作業の多くをAIがカバーしてくれるようになる。ただし、AIの提案をレビューする能力は引き続き必要なので、スキルアップの方向性を「提案を正しく評価できる人材」に転換していくことが求められる。 インフラ担当・クラウドアーキテクト向け: ドリフト検出ツールは、ガバナンスを手動のチェックリストで維持してきた組織に特に刺さる。まずプレビュー環境で試し、自社のIaCリポジトリとの連携フローを設計しておくと本番展開がスムーズになる。Azure PolicyやDefender for Cloudとの組み合わせも検討したい。 廃止対応: 2027年という期限は「まだ先」に見えるが、大企業の移行プロジェクトは承認・設計・テストで1〜2年かかることが珍しくない。今すぐ影響範囲の棚卸しだけでも着手しておくことを強く勧める。 筆者の見解 Azureが今回打ち出した方向性——コアサービスの中にAIを埋め込む——は、プラットフォームとしての正しい進化だと思う。AIを「使うかどうかオプトイン」ではなく「使わないことが選択肢にならない」レベルで基盤に溶け込ませる。この戦略は長期的に見て競争優位になりうる。 SQL MIの自動チューニングやドリフト検出は、技術者が「実行ではなく判断と設計」に集中できる環境を着実に整えてくれている。「仕組みを作れる人だけが価値を出す」という世界が、Azureのマネージドサービスの中でも現実になりつつある。 ひとつ気になるのは、こうした機能が「プレビューで使えます」「ポータルから有効化してください」という案内で終わってしまうケースが多いことだ。せっかく良いものを作っているなら、標準有効・自動展開まで踏み込んでほしいと感じる。Azureの基盤としての力はある。あとはその力を現場が迷わず使いきれるUXへの磨き込みを期待したい。 廃止スケジュールについては、余裕があるうちに動くことが鉄則。「今動いているから大丈夫」という判断が後手に回る最大の原因だ。四半期に一度はAzureのRoadmapとRetirement noticesをチェックする習慣を、チームの文化として根づかせてほしい。 ...

AIエージェントが開発ワークフローの中に「入り込む」時代が静かに始まっている。Microsoft Foundryに新たに統合されたAzure DevOps Remote MCPサーバーは、その象徴的な一歩だ。 MCPとは何か、なぜ今これが重要なのか MCP（Model Context Protocol）は、AIモデルが外部システムのデータやツールに標準化された方法でアクセスするためのプロトコルだ。簡単に言えば、「AIエージェントが使えるAPIの共通規格」と考えてよい。 これまでAIをDevOpsツールと連携させるには、ローカルへのサーバーインストールや複雑な設定が必要だった。今回のアップデートでは、Streamable HTTP方式のリモートMCPサーバーがMicrosoft Foundryに直接統合されたことで、その障壁が大幅に下がった。 何ができるようになるのか 今回の統合により、AIエージェントはAzure DevOps上の以下のデータに直接アクセスできる： ワークアイテム（バックログ・スプリントボード・バグ等） プルリクエスト（PR）（差分・レビューコメント・承認状態等） テスト計画（テストケース・実行結果等） ローカルへのインストールは不要で、Microsoft Foundry上でのセットアップだけで動作する。エージェントがBacklogを読んで次の実装タスクを提案したり、PRの内容を理解してレビューコメントを生成したりするシナリオが、現実的なものになってきた。 Streamable HTTPが意味すること 従来のMCP実装はローカルプロセスとの標準入出力（stdio）通信が主流だった。Streamable HTTPへの移行は、MCPを「クラウドネイティブなプロトコル」へと昇格させる動きだ。認証・スケーリング・監査ログといった企業要件との親和性も高く、エンタープライズ利用に向けた実装として評価できる。 実務への影響——日本のエンジニア・IT管理者へ エンジニア視点：AIエージェントに「今スプリントのバックログを確認して、実装優先度を提案して」と指示するような使い方が近い将来に実用域に入る。今のうちにMCPの概念と、Azure DevOps上のデータ構造（ワークアイテムのフィールド定義等）を整理しておくと、エージェント活用の立ち上がりが速くなる。 IT管理者・アーキテクト視点：重要なのは認証・認可の設計だ。エージェントがDevOpsデータにアクセスする以上、どのエージェントが・どのプロジェクトの・どのスコープにアクセスできるかを明示的に管理する必要がある。Microsoft Entra IDによるアクセス管理が鍵を握る。「とりあえず全部アクセスできる」設定のまま運用するのは、人間のアカウントで同じことをするのと同様にリスクがある。 筆者の見解 MCP対応のRemoteサーバーがFoundryに統合されたことは、方向性として正しいと思う。「AIエージェントが自律的に判断・実行・検証を繰り返すループ」を設計する上で、DevOpsデータへのアクセスは不可欠なピースだ。バックログを読んでコードを書き、PRを作成し、テスト結果を確認して次のアクションを決める——こうしたループをプラットフォームが支えてくれるなら、開発の自動化は一段と現実味を帯びる。 Microsoft Foundryというエコシステムの中でこれが実現されている点も重要だ。エージェントの認証・認可をMicrosoft Entra IDで一元管理できる構造は、エンタープライズ利用において長期的に正しい戦略だと評価している。個々のエージェントが勝手に動き回るのではなく、プラットフォームが「管制塔」として機能する設計思想だ。 あとは、エージェントが「どこまで自律的に動いて良いか」のガバナンス設計が追いつくかどうかが問われる。ツールだけ先行して、運用ルールが空白のまま使い始める組織が出てこないよう、実装と並行してポリシー整備も進めてほしい。 Microsoftはエージェント時代のプラットフォームとして本気で動いている。今後の展開に注目したい。 出典: この記事は Azure DevOps Remote MCP Server Lands in Microsoft Foundry, Giving AI Agents Direct Access to Your DevOps Data の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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