Azure

Microsoftは、AIエージェントのファイル・ネットワークアクセスをOSカーネルレベルで強制制御する新技術「MXC（Microsoft Execution Containers）」を発表した。OpenAIとNVIDIAがすでにパートナーとして参画しており、Microsoft Entra ID・Defender・Intuneとの統合プレビューは2026年7月を予定している。 MXCとは——「アプリ層の設定」では守れない時代のOS組み込みサンドボックス AIエージェントの権限管理は、これまでアプリケーション層での対処が主流だった。どのAPIを呼べるか、どのファイルを読めるか——それはコードと設定ファイルが決めていた。だがこの方式には根本的な弱点がある。プロンプトインジェクション攻撃や設定ミスがあれば、エージェントは意図しない操作を実行できてしまう。 MXCはこの問題をOSのカーネルレベルで解決する。エージェントが「事前に宣言されたポリシー以外のリソースへアクセスしようとした瞬間に、OS側が強制的にブロックする」設計だ。アプリケーションコードの品質や設定の正確さに依存せず、カーネルがポリシーを強制する点で従来のコンテナ技術とは一線を画す。 OpenAI・NVIDIAの参画が示すエコシステム戦略 MXCが単なるWindowsセキュリティ機能にとどまらないことを示すのが、OpenAIとNVIDIAの早期参画だ。 OpenAIのエージェントフレームワークがMXCサンドボックス上で動作するということは、OpenAI Agents SDKを使って構築されたエージェントもMicrosoftのポリシー管理下に置けることを意味する。NVIDIAの参画はGPU実行コンテキストへの拡張を示唆しており、ローカルLLM推論やCUDA計算を伴うエージェントワークロードにも安全な実行環境が提供される可能性がある。 Microsoftのエコシステム戦略が「自社モデルのみ」ではなく「他社のエージェントも安全に動かせるプラットフォーム」を目指していることが、このパートナー構成から読み取れる。 Entra/Defender/Intune統合——NHI管理が実行層まで届く 7月予定のプレビューで最も注目すべきは、Microsoft Entra IDとの統合だ。 これは実質的に、AIエージェントに対するNon-Human Identity（NHI）管理の実装を意味する。Entraでエージェントの「誰が」を管理し、MXCコンテナで「何ができるか」を強制する2層構造——これはゼロトラストの原則をAIエージェントにまで一貫して適用するアーキテクチャだ。 Defenderとの統合はエージェントの行動をリアルタイム監視・異常検知し、Intuneとの統合はポリシーの一元管理を可能にする。IT管理者が使い慣れたMicrosoft管理コンソールでAIエージェントの権限を制御できる体制が整う。 実務への影響 エージェント本番導入の心理的障壁が下がる 日本の多くの企業がAIエージェントの本番導入に慎重な理由の一つは「権限設計の難しさ」だ。広すぎれば情報漏洩のリスク、狭すぎれば機能しない。MXCのポリシー管理が普及すれば、エージェントへの権限付与に対する恐れを技術的な担保で軽減できる。 今から準備できること 現時点ではプレビュー段階のため、実運用への採用は2026年後半以降になるだろう。今すべきことは「自組織のAIエージェント利用の棚卸し」だ。どのエージェントがどのリソースにアクセスしているかを把握し、EntraのサービスプリンシパルやマネージドIDの整理を進めておくと、MXCポリシー設計に移行しやすくなる。 ゼロトラスト適用範囲がNHIまで拡大 「常時アクセス権の付与は特権アカウント管理における最大のリスク」という原則は、人間のIDと同様にAIエージェントにも当てはまる。MXCとEntraの組み合わせにより、Just-In-Time型のアクセス制御をエージェントに適用する道が開ける。 筆者の見解 AIエージェントのセキュリティ課題に対して、MicrosoftがOS層から解決策を提示してきたことは正しい方向性だと評価している。 「エージェントの管制塔としてのMicrosoft Entra ID」という戦略を以前から支持してきたが、MXCはその戦略に実行層の裏付けを追加するものだ。IDで認証・認可を管理し、コンテナで実行境界を強制する——この構造は、AI時代のゼロトラストアーキテクチャとして筋が通っている。 NHI管理は多くの組織でいまだにボトルネックになっており、「エージェントに何をどこまで任せていいかわからない」という現場の不安は根強い。OS側での強制機構があれば、「設定を間違えたら何をするかわからない」という恐れに技術的な答えを返せる。これは「禁止ではなく安全に使える仕組みを」という観点から、業務効率化を前進させる取り組みだ。 Microsoftが持つ「最も多くのエージェントが安全に動作できるプラットフォーム」としての競争優位性を、今回の発表はさらに強固なものにする。OpenAIやNVIDIAのエコシステムとも協調できる設計になっているのは、プラットフォームとしての強みを活かした正しい戦略だ。7月のプレビューを実際に検証し、改めて報告したい。 出典: この記事は Microsoft launches MXC, an OS-level sandbox for AI agents, with OpenAI and Nvidia already on board の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはBuild 2026において、自社設計のARM系プロセッサを搭載した「Azure Cobalt 200」VMシリーズのパブリックプレビューを発表した。前世代のCobalt 100比で最大50%のパフォーマンス向上を実現しており、現代のエージェントAIワークロードへの最適化を前面に押し出した新世代インフラだ。 Azure Cobalt 200の技術的特徴 TSMC 3nmプロセスとデュアルチップレット構成 Cobalt 200の核心は、TSMCの3nmプロセスノードで製造されたデュアルチップレット構成にある。合計132コアを搭載し、前世代比で大幅な演算密度の向上を実現している。 チップレット（Chiplet）設計とは、複数の小さなダイを一つのパッケージに統合するアーキテクチャだ。製造歩留まりの向上とスケーラビリティの確保が同時に実現できるため、大規模データセンター向けプロセッサでは主流のアプローチになっている。AMDのEPYCシリーズが先行して採用してきた手法をMicrosoftが自社設計チップに適用したかたちだ。 ARMアーキテクチャが選ばれる理由 AzureがARM系の独自プロセッサを採用し続ける背景には、x86に対する電力効率の優位性がある。同じワット数あたりのスループットでARM系は優位に立つことが多く、データセンターの運用コストと冷却コストの削減につながる。 特にエージェントAIワークロードは、大量のリクエストを並列処理する性質を持つ。コア数の多さと電力効率の良さは、コスト効率の高いエージェント実行環境の構築に直結する要素だ。 提供リージョン パブリックプレビュー開始時点でWest US3やEast US2を含む複数リージョンで即時利用可能となっている。日本リージョンでの提供時期は現時点では明示されていないが、プレビュー段階での検証は米国リージョンを使えば今すぐ着手できる。 実務への影響 エージェントAI基盤の選定に直結 2026年現在、AzureでAIエージェントを構築する際の選択肢は急速に広がっている。Cobalt 200 VMは、多数のエージェントが並列動作する環境においてコスト対効果が高い選択肢となりうる。特に効果が期待できるワークロードは以下の通りだ。 マルチエージェントオーケストレーション: 多数の軽量エージェントが並列実行されるシナリオ 推論パイプラインのCPUオフロード: GPUリソースを節約しつつ前処理・後処理をCPUで担う構成 RAGパイプライン: 大量の検索・集約処理が絡むリトリーバルワークフロー コスト試算の観点 ARM系VMは一般的にx86 VMより単価が低く設定される傾向がある。50%の性能向上が同価格帯で実現されるなら、実質的なコストパフォーマンスは大幅に改善する計算になる。エージェント基盤の構築を検討中のチームは、プレビュー期間中にベンチマークを取得しておくと、GA（一般提供）リリース時の意思決定が速くなる。 日本リージョン展開を待つ場合の現実的な対処 West US3やEast US2での検証を先行させ、日本リージョンへの展開を待つアプローチが現実的だ。レイテンシが許容範囲内であれば、プレビュー段階から開発環境や非本番ワークロードを移行して知見を積んでおくことも選択肢に入る。GAリリース時に「すでに検証済み」の状態で臨めるかどうかは、競合優位に直結する。 筆者の見解 Azure Cobalt 200の発表は、Microsoftが「AIの頭脳」競争とは別の軸——「AIが安全かつ効率的に動くインフラ」競争——で着実に前進していることを示している。 エージェント時代において、「どのモデルを使うか」と「どのインフラで動かすか」は分離して考えるべき問題になってきた。Cobalt 200はその後者——インフラ側の競争力——を着実に高める投資だ。Microsoft Entra IDをエージェントの管制塔として、高効率なARM系インフラの上で多様なAIを動かすエコシステムは、長期的に見て合理的なアーキテクチャだと思う。 Microsoftが持つ強みはモデルの性能だけではない。エンタープライズの信頼、セキュリティ基盤、そして世界中に展開するデータセンターのネットワークだ。Cobalt 200のようなインフラ投資はその根幹を強化する。正面から勝負できる力がある会社なのだから、この方向性を着実に伸ばしてほしい。 あとは、この高効率インフラの恩恵が日本リージョンにも早く届くことを期待している。日本のエンタープライズがエージェント基盤の設計判断をする際に、Cobalt 200が選択肢として現実的に見えるリージョン展開の加速に期待したい。 出典: この記事は New Azure Cobalt 200 VMs deliver 50% performance improvement, fully optimized for modern agentic AI workloads の内容をもとに、筆者の見解を加えて独自に執筆したものです。

NVIDIAとMicrosoftは、2026年6月2日に開催されたMicrosoft Buildにおいて、エージェンティックAIをWindowsデバイスからAzureクラウド、ローカル環境まで一貫して展開できる統合アクセラレーテッドコンピューティングスタックの拡張パートナーシップを発表した。NVIDIAのJensen Huang CEOがSatya Nadella CEOの基調講演に台北からライブ参加するかたちで、両社の本気度を印象づけた。 AIエージェント時代のWindowsを再定義——RTX SparkとDGX Station 今回の発表の目玉のひとつが、NVIDIAの新しいハードウェアラインアップだ。 RTX Sparkは、パーソナルAIエージェント専用として設計されたWindowsPC向けの新プラットフォームだ。1ペタフロップのAI演算性能と最大128GBのユニファイドメモリを搭載しながら、終日バッテリー駆動を実現。電源を抜いてもフルパフォーマンスを維持できる点が特徴で、CUDA、RTX、DLSS、TensorRTといったNVIDIAの30年以上の技術資産をそのまま活用できる。Microsoft Surface、ASUS、Dell、HP、Lenovo、MSIから今秋登場予定だ。 より上位の選択肢としてDGX Station for Windowsも発表された。NVIDIA GB300 Grace Blackwell Ultraデスクトップスーパーチップを搭載し、最大748GBのコヒーレントメモリと20ペタフロップス（FP4）の演算性能を持つ。1兆パラメータ規模のフロンティアモデルをオンプレミス環境で常時稼働させることが可能で、ASUS、Dell、GIGABYTE、HP、MSI、Supermicroから第4四半期に出荷予定とされている。 Microsoft Foundryでオープンモデルのエコシステムを拡大 エンタープライズ向けのエージェンティックAI基盤として、Microsoft Foundry上でのNVIDIAオープンモデルの展開が大幅に拡張された。 注目は新たに公開されたNemotron 3 Ultraだ。長時間推論が必要なコーディング・研究・エンタープライズワークフロー向けに設計されたオープンフロンティア推論モデルで、今月よりFoundry管理コンピュート上で利用可能となる。音声認識向けのNemotron 3.5 ASR、コンテンツ安全性のためのNemotron 3.5 Content Safetyも合わせて提供される。 また、物理AIのためのオムニモデルNVIDIA Cosmos 3（視覚推論・世界シミュレーション・行動生成を統合）や、企業向け気象予測・リスク分析に使えるNVIDIA Earth-2 AIウェザーモデルもMicrosoft Planetary Computer ProおよびFoundry経由で利用可能になる。 さらに、AnthropicのClaudeモデルがNVIDIA GB300 Blackwell UltraシステムのAzure上でネイティブ稼働するようになったことも発表された。数週間以内に顧客向けに提供開始予定とされており、OpenAIやAnthropicのモデルに加え、Hermes特殊エージェントも含めた複数モデルが、Foundry Agent Serviceのホスト型エージェントとして統合アイデンティティ・ガバナンス付きで利用できるようになる。 セキュリティバイデザインのエージェントランタイム「OpenShell」 見落とせないのがNVIDIA OpenShellの存在だ。自律型エージェントのための「セキュリティバイデザイン」なランタイムとして設計されており、GitHub CopilotおよびRTX Spark・DGX Station for Windowsの両方に組み込まれる。エージェントが長時間稼働・自律判断するようになった場合のセキュリティ境界をランタイムレベルで担保しようとする試みで、エンタープライズ展開における信頼基盤として機能することが期待されている。 実務への影響 日本のエンジニア・IT管理者にとって、この発表にはいくつかの実務的な示唆がある。 クラウド一択からの脱却が現実的に: RTX SparkやDGX Stationの登場により、AIエージェントのオンプレミス・エッジ実行が現実的な選択肢になってきた。クラウドレイテンシやデータ主権の観点からハイブリッド構成を検討している組織には、具体的な検討材料が生まれた。 Foundryをハブにしたモデル選択の自由: Microsoft Foundryは、NVIDIAのオープンモデル、Anthropicのモデル、OpenAIのモデルを同一プラットフォームで選択・組み合わせて使えるマーケットプレイスとして機能し始めている。特定モデルへのロックインを避けながら、Azure基盤のセキュリティとガバナンスを活用できる構成が現実的になった。 エージェント向けハードウェア選定の時代へ: AIモデルを「どこで動かすか」の議論が本格化している。1ペタフロップ級（RTX Spark）か20ペタフロップ級（DGX Station）か——ワークロードの規模とコストに応じたハードウェア選定が必要になってくる局面が来ている。 筆者の見解 今回のNVIDIA・Microsoft連携発表を見て感じるのは、「プラットフォームとしてのAzureが、AI時代の全体設計を本気で描き始めた」という印象だ。 ...

Microsoftは2026年6月、Fedoraをベースとした汎用サーバーLinuxディストリビューション「Azure Linux 4.0」のパブリックプレビュー提供を開始した。Azure VM・VMスケールセット・コンテナイメージで利用可能となり、AKSおよびWSLへの対応も今後予定されている。 Azure Linux 4.0 とは何者か Azure Linux（旧称：CBL-Mariner）はもともとAzure内部のインフラ用途やコンテナワークロードに特化して開発されたMicrosoft製Linuxである。これまでのバージョンはコンテナ・AKSノードプールでの利用が主体だったが、4.0ではFedoraをアップストリームベースとして採用し、汎用サーバーOSとしての利用を初めて公式サポートした点が最大のブレイクスルーだ。 Fedoraを選んだ理由として、最新のカーネルとパッケージへの追従が速く、Azure最適化コンポーネント（ハイパーバイザー統合・ネットワークドライバ・観測可能性エージェント等）との相性が良い点が挙げられる。Red Hat Enterprise Linux（RHEL）の上流ディストリビューションであるFedoraを採用することで、エンタープライズ用途での信頼性担保も意識している。 対応環境と利用シナリオ 現時点でのパブリックプレビューでは以下が利用可能だ： Azure VM（第1世代・第2世代）：Standard_D系・Standard_E系など主要SKUで動作確認済み VMスケールセット（VMSS）：自動スケールが必要なWebアプリ・バックエンド処理基盤に対応 コンテナベースイメージ：既存のAzure Linux 3.x系コンテナイメージの後継として利用可能 今後のロードマップとしてAKSノードプールおよびWSLディストリビューションへの対応が予告されており、開発者がローカル環境でAzure Linux 4.0をWSL上で動かしながらそのままAKSにデプロイする、という「ローカルとクラウドの環境一致」ワークフローが実現できる見通しだ。 なぜこれが重要か これまでAzure上でLinuxワークロードを動かす場合、Ubuntu・RHEL・CentOS Stream・SUSE等のサードパーティディストリビューションを選ぶのが一般的だった。それぞれに長所があるが、「Azureに最適化されているか」「サポートライフサイクルがAzureのリリースサイクルと一致しているか」という点で常に齟齬が生じていた。 Azure Linux 4.0はMicrosoftが責任をもってAzureサービスと同期してメンテナンスするため、カーネルパッチやAzureエージェントのアップデートが一体的に提供される。これはパッチ管理の簡素化という観点で、IT運用チームにとって無視できないメリットだ。 実務での活用ポイント 新規ワークロードには積極的に評価を：Greenfield構築であれば、Azure Linux 4.0をベースに選ぶことでAzureとの統合レイヤーが薄くなり、トラブルシューティングの複雑さが減る。まずはステージング環境でのパイロットから始めると低リスクだ。 AKS移行を考えているなら先行評価を：コンテナとVM両方でAzure Linux 4.0を使えば、同一OSスタックでアプリケーションをテストしてからAKSに乗せるパスが確立できる。環境差分によるデバッグコストを削減できる。 WSL対応後の開発者体験に注目：WSLでAzure Linux 4.0が動くようになれば、Windowsマシン上でAzureと同じOSでコードを書いてそのままデプロイできる。CI/CDの「ローカルでは動く問題」が構造的に減らせる可能性がある。 既存のAzure Linux 3.x環境は引き続き動作：4.0への移行は強制ではなく段階的に進められるため、本番環境の急な変更は不要。ただしEOLスケジュールは事前に確認しておくこと。 筆者の見解 Azure Linux 4.0は、Microsoftが「Azure専用OS」を本気で育てる意志を示した動きとして評価している。Azureというプラットフォームの信頼性は揺るがないが、その上で動くOSレイヤーまでMicrosoftが一元管理するという発想は、AWSのAmazon Linux・GoogleのContainer-Optimized OSと肩を並べる方向性だ。 長年Azureを扱ってきた身からすると、「UbuntuをAzureに最適化してきた手間」は決して小さくなかった。カーネルバージョンとAzureエージェントの相性問題、ディストリビューションのEOL管理——これらの運用コストをMicrosoft側に引き取ってもらえることで、インフラチームが本来集中すべきアーキテクチャ設計に時間を使えるようになる。 一方で、Fedoraベースという選択はロールリングリリース的な性格も持つため、エンタープライズ運用で求められる「変化の少なさ」とトレードオフになる面もある。GAに向けてどこまでの安定性保証を打ち出せるか、サポートライフサイクルの詳細をMicrosoftには明確に示してほしい。プラットフォームとしての実力は十分あるのだから、その点の整備こそが普及の鍵になるはずだ。 出典: この記事は Announcing Azure Linux 4.0: Purpose-Built for Azure, Now in Public Preview の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月開催のMicrosoft Build 2026において、エンタープライズAI競争の主戦場はモデルの性能ではなくデータコンテキストにあると宣言し、Microsoft Fabric Data WarehouseへのNVIDIA GPUアクセラレーション統合を発表した。 Microsoft Fabric Data Warehouseに何が起きているか Fabric Data WarehouseにNVIDIA GPUアクセラレーションが統合される。最大の特徴は既存のクエリを書き換える必要がない点だ。従来のSQL資産をそのままに、最大7倍のデータ分析高速化が実現できるという。 この機能は2026年7月に早期アクセスプレビューとして提供開始予定。また、このアーキテクチャを支える研究成果はデータベース分野の権威ある国際会議「ACM SIGMOD 2026」でBest Industry Paper賞を受賞しており、学術的な裏付けも得ている。 「モデルより文脈」戦略の意味 MicrosoftがBuildで繰り返し強調したメッセージは「AIエージェントの価値はモデルの賢さより、どれだけ正確なデータにアクセスできるかで決まる」というものだ。 この主張は自社の強みを最大限に活かす戦略として読み解ける。Microsoftはすでに企業の基幹データに深く入り込んでいる。SharePoint、Exchange、Teams、Azure SQL——これらのデータを「コンテキスト」としてAIエージェントに渡せる仕組みを整えることで、モデル性能競争とは別軸で優位性を確立しようとしている。 Buildで公開された主な技術要素： HorizonDB: AIエージェントが企業の分散データを横断的に参照するための新しいデータファブリック層 Fabric Data Warehouse + NVIDIA GPU: 既存ワークロードを変更せずにGPUアクセラレーションを享受 データコンテキストパイプライン: エージェントが最新かつ正確なデータをリアルタイム参照できる連携基盤 日本のIT現場への影響 日本の多くのエンタープライズはすでにMicrosoft 365とAzureを軸にデータ基盤を構築している。この発表が実務に与えるインパクトは小さくない。 エンジニア・データエンジニアへのヒント： 既存のFabric Data Warehouseを使っているなら、7月の早期アクセスプレビューを今から申請して検証環境を先に用意しておく GPU統合はクエリ変更不要とされているが、実際のワークロードでのパフォーマンスプロファイルは必ず独自計測する。「最大7倍」は条件次第 HorizonDBのアーキテクチャ詳細はACM SIGMOD論文として公開されており、技術的な深掘りが可能 IT管理者・アーキテクトへのヒント： 「AIエージェントにどのデータを見せるか」の設計が、今後の企業AI戦略の核になる。データガバナンス整備が先決 Microsoft Entra IDを使ったデータアクセス制御の整備が、エージェント導入前の必須ステップ Fabric未導入の場合、このタイミングでの移行検討価値が一段と高まった 筆者の見解 Build 2026を通じて見えてきたMicrosoftの戦略は、AIモデル競争から「データプラットフォーム競争」への明確なシフトだ。この方向性は、正直なところ「正しい賭け方」に見える。 Azureの強みは常にインフラとしての信頼性と、企業データへの深い統合にあった。エンタープライズの現場では、最強のモデルより「自社のデータを正確に理解してくれるAI」の方が価値を生む場面が圧倒的に多い。その意味で「データコンテキストがモデル性能を凌駕する」という主張は、現場感覚に合っている。 Microsoft Foundry経由で外部モデルを活用しつつ、データ基盤はFabricで管理する——という組み合わせが現実的な選択肢として浮かんでくる。Azureのプラットフォームとしての役割を活かすなら、最強のモデルを自前で作る必要はない。最良のモデルが安全に動作できるエコシステムを提供する側に回ればいい。Microsoftにはその力がある。 GPU統合でのクエリ高速化とACM SIGMODでの受賞は実力の裏付けとして受け止めている。2026年7月のプレビューで実際の現場ワークロードがどこまで恩恵を受けられるか、アーキテクチャの美しさを結果で証明してほしい。 出典: この記事は Microsoft bets the enterprise AI race will be won on data context, not model power の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft の Azure Container Registry（ACR）チームが、外部レジストリのコンテナイメージを ACR 経由でキャッシュする「ACR Artifact Cache」の内部アーキテクチャを公式ブログで詳細に公開した。1日1億件を超えるイメージプルを支えるプルスルーキャッシュの設計思想と、実際の動作フローが明らかになった。 なぜ上流レジストリに直接依存してはいけないのか コンテナを本番運用しているチームなら、一度は遭遇したことがあるはずだ——Docker Hub のレートリミットに引っかかり、Kubernetes ノードが突然イメージを取得できなくなるアレだ。 Docker Hub は認証なしユーザーや個人プランユーザーに対してプル数を制限しており、CI/CD の共有エージェントや大規模な Kubernetes クラスターでは、あっという間に上限に達する。しかしこれは Docker Hub 固有の話ではない。本質的な問題は「上流レジストリへの直接依存が、本番システムに許容できないリスクをもたらす」という点にある。 具体的な失敗パターンはこうだ： 上流の一時的な障害や低速化がそのままサービス停止に直結する レートリミット・バースト制限で大規模スケールアウト時にイメージ取得が詰まる 認証情報の管理が各チームに分散し、セキュリティ統制が効かなくなる ネットワークポリシー（承認済みの境界内のみ通信を許可）が上流への直接アクセスを許可しないケースがある ACR Artifact Cache はこの問題を「上流の内容を ACR 経由で透過的にキャッシュする」ことで解決する。クライアントは通常の ACR プルと同じ操作をするだけでよく、裏側の複雑さは隠蔽される。 キャッシュルールとクレデンシャル管理 設定はコントロールプレーンで行う。チームはまず「キャッシュルール」を作成し、ACR 内の下流パスと上流ソースのマッピングを定義する。 出典: この記事は Inside ACR Artifact Cache: Pull-Through Caching at Scale の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftのクラウドAI開発プラットフォーム「Microsoft Foundry」のポータルが正式にGA（一般提供）へ移行し、パイロット用途から本番環境向けのエンタープライズグレードAI基盤としての利用が可能になった。 Microsoft Foundryとは何か Microsoft Foundryは、AIモデルの展開・エージェント開発・本番運用をひとつのプラットフォームで完結させるMicrosoftのAI開発基盤だ。「Discover（探索）」「Build（構築）」「Operate（運用）」というエンドツーエンドのライフサイクルを統合することで、開発チームが信頼性・コンプライアンス・運用品質を犠牲にせずに迅速に動けることを目指している。 今回のGA移行により、以下の機能が本番利用可能となった： RBAC（ロールベースアクセス制御）: チームごとの権限管理を細粒度で実現 監査ログとコンプライアンスコントロール: 企業のガバナンス要件に対応 監視・アラート機能: 本番AIワークロードの安定運用を支援 仮想ネットワーク統合: セキュアなネットワーク環境でのAI実行 ポータル・API・SDK・CLIおよび開発者ツールにわたって、GAスコープの一貫したライフサイクル管理が提供される。 注意点：すべてが移行されたわけではない GAのスコープは「Foundryプロジェクト」に限定されており、既存ユーザーは注意が必要だ。 新ポータルでサポートされないもの： スタンドアロンのAzure OpenAIリソース（クラシックポータルの継続利用、またはFoundryプロジェクトへのアップグレードが必要） ハブベースのクラシックプロジェクト（Foundryプロジェクトへの移行が必要） 認証についても整理が必要だ。多くの機能はAPIキー認証に対応しているが、評価（Evaluations）・データセット・Content Understanding・エージェント・ワークフローはMicrosoft Entra ID認証が必須となっている。ガバナンス重視の本番環境では、Entra IDとRBACの組み合わせが推奨される。APIキー認証はロールベースの権限粒度を提供しないため、企業用途では原則としてEntra IDを選ぶべきだ。 本番移行前に確認すべき事項 Microsoftは移行前に以下の確認を求めている： モデル展開・エージェント開発・運用の必要シナリオを整理する プレビュー専用機能やクラシックポータル依存箇所を洗い出す 本番環境でGA機能のみを使用する組織ポリシーを定義する 既存Azure OpenAI・クラシックFoundryワークロードの移行ガイダンスを確認する チームとサービスアイデンティティに必要なロール割り当てを確認する 実務への影響 エンジニア・アーキテクト向け： 新規のAIエージェント開発プロジェクトは、Foundryプロジェクトをベースに設計するのが今後の標準になる。特にエージェント・ワークフロー系の機能はEntra ID認証が必須のため、セキュリティ設計の段階からID管理を組み込む必要がある。「とりあえずAPIキーで動かす」アプローチは開発初期には便利だが、本番移行時に設計の見直しを迫られる可能性がある。 IT管理者・セキュリティ担当向け： GAになったことで、監査ログとRBACが本番レベルでサポートされる。ゼロトラスト設計との親和性が高く、サービスアイデンティティ（Non-Human Identities）の管理も含めてEntra ID中心に統合できる体制が整いつつある。エージェントが自律的に動く環境では、人間のアカウントと同様にNHIへのJust-In-Timeアクセス制御を検討することを推奨する。 既存Azure OpenAIユーザー向け： 今すぐ移行が必須なわけではないが、新機能はFoundryプロジェクト側に集約されていく方向性は明確だ。移行タイミングを組織の開発ロードマップに組み込んでおくことを推奨する。 筆者の見解 Microsoft FoundryがGA到達によってエンタープライズAI基盤として形になってきたことは、正しい方向性だと思う。 特に注目しているのは、Foundryが特定のモデルに縛られない設計になっている点だ。Microsoftはモデル開発の競争で先頭を走っているわけではないが、「どのモデルでも安全に動かせるプラットフォーム」という立ち位置は長期的に見て非常に有利だ。Entra IDがAIエージェントの管制塔になるシナリオは、すでにMicrosoft基盤を持つ企業にとって現実的な最善手といえる。 一方で、クラシックポータルとの分断や移行パスの複雑さは、既存ユーザーにとって頭の痛い問題だ。「まずFoundryプロジェクトへ」という方針は理解できるが、既存資産の移行コストを丁寧にケアする姿勢を見せ続けてほしい。それだけのポテンシャルを持つ基盤だけに、移行の摩擦で採用が鈍ることがないよう期待したい。RBACや監査ログが揃ったいま、あとはユーザーがスムーズに乗り換えられる体験を磨くフェーズだ。 出典: この記事は New Microsoft Foundry portal general availability overview の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはOpenAIの最新フラッグシップモデル「GPT-5」を、エンタープライズ向けAI開発基盤「Azure AI Foundry」で正式提供開始した。単なるモデル追加ではなく、コスト最適化機能やエージェント基盤の整備など、本番運用を見据えた大型アップデートとなっている。 GPT-5ファミリーの構成 Azure AI FoundryでのGPT-5シリーズは、用途に応じた4つのモデルで構成される。 モデル 特徴 GPT-5 272kトークンコンテキスト、複雑な分析・コード生成向けの深い推論 GPT-5 mini リアルタイムアプリ・エージェント向け、ツール呼び出し対応 GPT-5 nano 超低レイテンシー特化、Q&A用途向け GPT-5 chat 128kトークン、マルチモーダル・マルチターン会話対応 各モデルはAzure AI Foundryの同一エンドポイントからアクセス可能で、後述の「モデルルーター」によって最適なモデルが自動選択される。 モデルルーターで推論コストを最大60%削減 今回のアップデートで特に注目すべきは「モデルルーター」機能だ。GPT-5ファミリー（およびFoundry Models内の他モデル）を対象に、受け取ったプロンプトの複雑さや要件を分析し、最適なモデルを自動的に選択する。 この仕組みにより、精度を落とさずに推論コストを最大60%削減できるとMicrosoftは説明している。「重い処理はGPT-5、シンプルな問い合わせはGPT-5 nano」という判断をモデル自身が行うため、開発者はモデル選択のロジックを自前で実装する必要がなくなる。 エージェント基盤との統合 GPT-5は近日中にFoundry Agent Serviceとの統合も予定されている。注目ポイントは以下のとおり。 ブラウザ自動化：WebアプリへのAIによるアクセス・操作 MCP（Model Context Protocol）統合：外部ツールとの標準的な接続インターフェース Foundryテレメトリ：エージェントの動作を可視化・監査可能に Responsible AI準拠：ポリシーベースのガバナンス また、reasoning_effortパラメータなど開発者向けの制御機能も強化されており、推論の深さ・速度・詳細度をチューニングできる。フリーフォームのツール呼び出し機能により、厳格なスキーマなしに広範なツールと連携できるようになった点も実用上大きい。 実務への影響 PTU対応でエンタープライズ本番稼働が現実的に GPT-5はProvisioned Throughput Unit（PTU）に対応しており、スループットを事前確保することで安定したレスポンスタイムが保証される。コスト予測可能性を重視する企業にとって、パイロットから本番移行を判断する大きな後押しになるだろう。 コスト管理の自動化 モデルルーターを活用すれば、「どのAPIをどのモデルで叩くか」という設計上の判断をプラットフォームに委譲できる。コスト最適化のための複雑なルーティングロジックを自前実装する工数を削減でき、アプリケーション本体の開発に集中できる。 Realtime 2.0（音声・翻訳）の拡充 今回のアップデートではRealtime 2.0（GPT Realtime Whisper / Translate）も同時に強化されている。リアルタイム音声入力や多言語翻訳を組み込んだアプリケーション開発が、Azureのエンタープライズ基盤上でより現実的な選択肢になってきた。コールセンター自動化や多言語対応サービスを検討している組織は要注目だ。 筆者の見解 GPT-5のAzure AI Foundry対応は、Microsoftのプラットフォーム戦略の方向性がよく表れた発表だと感じている。 「最も賢いモデルを自分で作る」競争と、「最良のモデルを安全に使えるプラットフォームを提供する」競争——Microsoftが今注力しているのは明らかに後者だ。モデルルーターはその象徴で、エンタープライズが本番環境でAIを使うときに本当に必要なもの（コスト予測可能性、ガバナンス、監査可能性）を着実に整備している。この点は率直に評価したい。 一方で、PTUやモデルルーターのような機能が日本のIT現場に浸透するには、まだ相当な学習コストがかかる。「Azureを使っているが、AI活用はまだ個人アカウントのChatGPT」という状況も少なくない。Azure AI Foundryというプラットフォームの実力は本物だが、組織として使いこなせる体制を先に整えることが前提となる。 使いこなす準備が整った企業にとっては、GPT-5のAzure対応は「パイロットから本番へ」の背中を押してくれる発表になるはずだ。Azureを基盤としながら最前線のモデルを活用できる環境は、Microsoft Foundryが持つ最大の強みであり、その価値は今後さらに高まっていくと見ている。 出典: この記事は GPT-5 in Azure AI Foundry: The future of AI apps and agents starts here の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftはNVIDIA RTX PRO 6000 Blackwell GPUを搭載したAzure NCv6仮想マシンの一般提供（GA）移行を発表した。AI推論とビジュアルコンピューティングを単一基盤に統合したこの新シリーズは、East US・West Europeをはじめとする主要リージョンへの順次展開が始まっている。 Azure NCv6 VMとは何か NCv6シリーズはAzureのGPUコンピューティングラインナップの中でも、プロフェッショナルグレードのAI処理とグラフィックス処理を両立させることを目的とした新世代VMシリーズだ。搭載されるNVIDIA RTX PRO 6000は、Blackwellアーキテクチャをベースとした最新世代のプロフェッショナルGPUであり、前世代のAda Lovelaceアーキテクチャから大幅なパフォーマンス向上を実現している。 NVIDIA Blackwellアーキテクチャの特徴 Blackwellアーキテクチャは、Tensor Coreの最新世代実装によりAI推論ワークロードの処理効率を大幅に高めている。同時にRT Coreの強化によってリアルタイムレイトレーシングも強力にサポートされており、エンタープライズ向けの認定ドライバーと組み合わせることで安定した長期運用が可能だ。 AI推論とビジュアルコンピューティングの統合 従来はAI処理に特化したNCシリーズと、グラフィックスワークロード向けのNVシリーズが分かれていたが、NCv6はこの境界を統合する設計となっている。1台のVM内でAIモデルの推論処理と高精度な3Dレンダリングを並行して実行できる点は、CAD・BIM・映像制作・医療画像解析といった業務において大きなメリットをもたらす。 リモートワークステーションとしての活用 Azure Virtual Desktop（AVD）やWindows 365とのシームレスな統合により、強力なGPUパワーをリモートワークステーション環境から活用できる。物理的なGPUワークステーションの代替として、社外・自宅を問わずプロフェッショナルグレードの作業環境にアクセスできる点は、ハイブリッドワーク推進の観点でも注目に値する。 リージョン展開状況 現在はEast USとWest Europeでの提供が先行しており、他のAzureリージョンへは順次展開予定となっている。日本リージョン（Japan East / Japan West）への展開時期については公式アナウンスを待つ必要があるが、主要リージョン展開後に追随するのがMicrosoftの通例だ。 実務への影響 コスト最適化の観点 GPU搭載の物理ワークステーションはハイエンドモデルで1台あたり数百万円のコストがかかる。NCv6 VMをAVDと組み合わせることで、初期投資を抑えながら複数ユーザーが高性能GPU環境を共用するモデルを構築できる。特に使用頻度が均一でないデザイン部門や研究開発部門では、オンデマンドのGPUクラウドが経済合理性を持ちやすい。 AIエンジニア向けのポイント Blackwellアーキテクチャはトランスフォーマーモデルの推論に最適化されており、大規模言語モデル（LLM）のファインチューニングやRAGパイプラインの本番稼働に直接活用できる。Azure AI Foundryとの統合を活用することで、モデルの開発からデプロイまでをシームレスに進める環境が整っている。 段階的な移行戦略 既存のNCv3やNCasT4_v3シリーズを使っている環境からのリフトは、Azure Migrationガイドを参照して計画的に実施することを推奨する。GA移行によりSLAが正式に適用されるため、本番ワークロードへの採用を安心して進められる環境が整った点は重要なポイントだ。 筆者の見解 Azure NCv6のGA移行は、Azureのコンピューティング基盤としての厚みをあらためて実感させるリリースだ。NVIDIAの最新Blackwellアーキテクチャをいち早くクラウドで提供できるのは、MicrosoftとNVIDIAの深いパートナーシップあってこそであり、このあたりはAzureの揺るぎない強みだと感じている。 特に注目したいのは、AI推論とビジュアルコンピューティングを統合するという方向性だ。これまで「AI用クラウド」と「グラフィックスクラウド」を使い分けなければならなかった組織にとって、単一のVM系列で両方を賄えるのは運用の簡素化につながる。Microsoft Foundry経由でAIモデルを動かす場合も、この基盤は選択肢として十分に検討に値する。 一方で、実際に日本の現場でGPU VMを使いこなすには、コスト感覚と適切なユースケース選定が不可欠だ。「Blackwellだから」という理由でむやみに移行するのではなく、ワークロードの特性をきちんと評価した上で判断してほしい。物理ワークステーションの方が経済合理性の高いシナリオも依然として存在する。 日本リージョンでの提供開始が待ち遠しいところだが、それまでの間はEast US等を使った検証環境構築から始めるのが現実的な準備だろう。Azureはエンタープライズ要件を満たすプラットフォームとしての信頼性を持っており、このシリーズも長期運用に耐えうる選択肢になると見ている。 出典: この記事は Azure NCv6 Virtual Machines: Enhancements and GA Transition の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft は Build 2026 において、独自開発のマルチモーダル AI モデル群「MAI（Microsoft AI）」シリーズの最新版として、MAI-Image 2.5・MAI-Voice 2・MAI-Transcribe 1.5 の3モデルを一挙に発表した。画像生成・音声合成・音声認識という異なる3領域でモデルを揃え、AI インフラとしての自社プラットフォームを強化する姿勢を明確に打ち出した形だ。 MAI-Image 2.5：Arena 画像生成リーダーボードで3位に入る実力 MAI-Image 2.5 は、クラウドソーシング型の評価プラットフォーム「Arena」が公開する画像生成リーダーボードで 3位 を獲得したことが大きな注目を集めている。1位・2位は OpenAI の gpt-image-2 が占めているが、それに次ぐ位置に独自モデルが入ってきたことは、Microsoft の画像生成技術が一定の競争水準に達したことを示す。 エンタープライズ向けの用途——マーケティング素材の自動生成、ドキュメントのビジュアル補強、プロダクトモックアップ生成など——において、Azure AI Foundry 経由でそのまま利用できる点は実用上のメリットが大きい。データレジデンシーやコンプライアンスの観点から、外部 API を経由したくない企業にとっては特に魅力的な選択肢になりうる。 MAI-Voice 2：多言語対応と感情表現の強化 MAI-Voice 2 では多言語サポートの拡張と感情表現の精度向上が主な改善点として挙げられている。テキスト読み上げ（TTS）の品質向上により、コールセンター向け AI エージェントや、Copilot スタジオで構築する音声応答ボット、アクセシビリティ機能への応用が想定される。 日本語話者にとっては、多言語対応の質が実務適用の可否を左右する。日本語での感情表現——イントネーションの自然さ、文脈に応じた抑揚——は引き続き注視が必要だが、エンタープライズ向け音声 AI を社内基盤に統合する観点からは、Microsoft 製エコシステム内で完結できることのメリットは小さくない。 MAI-Transcribe 1.5：会議要約と音声エージェントに照準 MAI-Transcribe 1.5 は音声認識（STT）の精度向上に特化したモデルで、会議の文字起こしと要約、そして音声エージェントのバックエンドとしての活用を主なターゲットとしている。 Teams Premium に組み込まれているインテリジェント要約機能の裏側を支える技術的基盤としての位置づけも考えられ、精度向上はエンドユーザー体験に直結する。また、Azure AI Foundry でカスタムエージェントを構築する際に音声入力を取り込む用途でも、精度の底上げは設計の幅を広げる。 実務への影響——日本のエンジニア・IT管理者の視点から Azure AI Foundry 経由の統合活用 これら3モデルは Azure AI Foundry から利用可能になる見込みだ。すでに Azure 基盤を使っているチームであれば、追加のベンダー契約なしにマルチモーダル機能を取り込める可能性がある。まずはプロトタイプ段階で精度や応答速度を自社ユースケースで検証することを勧める。 音声エージェント構築の現実解 MAI-Voice 2 + MAI-Transcribe 1.5 の組み合わせは、Copilot スタジオや Azure Bot Service と組み合わせた音声エージェント構築の選択肢を広げる。特に社内ヘルプデスクの自動化や、製造現場でのハンズフリー作業支援など、音声インタフェースが有効なシナリオで実証実験を始める価値がある。 ...

Microsoft Build 2026が2026年6月2日、サンフランシスコのFort Mason Centerで開幕し、Azure AI Foundryを核とした大規模なAIエージェント基盤の刷新を発表した。外部データ連携レイヤー「Foundry IQ」、AIネイティブデータベース「Azure HorizonDB」（ベクトルインデックス内蔵）の提供開始と、AnthropicのClaude（クロード）のファーストパーティモデル統合が主なハイライトだ。 AIエージェントは「新しいアプリ」——Microsoftの戦略転換 Satya Nadella（サティア・ナデラ）CEOの基調講演が象徴するように、今年のBuildは「AIエージェントは新しいアプリである」という宣言を核心に据えている。単にプロンプトへ応答するチャットボットとは一線を画し、エージェントは自律的に計画を立て、ツールを使い、複数ステップのタスクを独立して実行できる。 これまでCopilotとして展開されてきた各種アシスタントが、エージェントアーキテクチャへと進化する転換点を迎えている。たとえば、WordのCopilotがリサーチタスクをエージェントに委譲し、そのエージェントが社内文書とWebを横断して情報を収集し、構造化されたブリーフを返す——ユーザーはドキュメントを離れることなくこれを完結できる、といった活用シナリオが具体的に示される予定だ。 Foundry IQ：外部データ連携を標準化する新レイヤー Azure AI Foundryに新たに追加されたFoundry IQは、AIエージェントが企業の外部データソースへアクセスするための統合レイヤーだ。RAG（Retrieval Augmented Generation）を企業環境で実用的に展開する際の最大の課題は「どこのデータをどう引っ張るか」であり、Foundry IQはその部分を標準化・抽象化することを目指す。 従来はSharePoint・Salesforce・基幹システムそれぞれに個別コネクタを実装する必要があったが、Foundry IQによってデータグラウンディングを共通インターフェースで扱えるようになる。エージェントの信頼性向上と開発工数削減に直結する機能追加だ。 Azure HorizonDB：ベクトルインデックス内蔵のAIネイティブDB Azure HorizonDBは、AIワークロードを前提として設計されたデータベースサービスで、ベクトルインデックスを標準機能として内蔵している。従来のリレーショナルDBにベクトル機能を後付けするアプローチとは異なり、セマンティック検索とキーワード検索を統一されたクエリで扱えるよう設計されている点が差別化ポイントだ。 RAGシステム構築時に必要だった別途ベクトルストアの用意が不要になるため、アーキテクチャの複雑さを大幅に削減できる可能性がある。Azure CosmosDBやAzure SQL DatabaseのベクトルDB拡張と比較して、AIネイティブという設計思想がどこまで実務で差別化できるかが今後の注目点だ。 Claude統合：モデル選択の自由度が実用レベルに 今回の発表で特に注目すべきは、AnthropicのClaudeがAzure AI Foundryのファーストパーティモデルとして利用可能になった点だ。OpenAIモデル（GPT-4oシリーズ）に加え、Meta・Mistral・Anthropicのモデルが同一プラットフォーム上で選択・切り替えできる環境が整った。 「Agent Blueprints」と呼ばれる新機能では、カスタマーサポートのトリアージ、サプライチェーンのリスク分析、医療記録の要約など、典型的なエンタープライズシナリオ向けの事前構築済みテンプレートが提供される。ゼロから設計するのではなく、ブループリントを起点に自社環境へ最適化したエージェントを迅速に展開できる。 エージェントの本番運用監視、ハルシネーション検出、コンプライアンス境界の強制といったガバナンスツールも合わせて強化されており、企業導入の信頼性向上が意識されている。 Windows Local AI：クラウドとエッジをまたぐ実行環境 クラウドだけでなく、Windows Local AIとして端末側でのAI推論も本格的に整備されつつある。NPU搭載のCopilot+ PCが普及期を迎えた今、Microsoftは「Local Agent Runtime」を通じてクラウドとエッジをシームレスにまたぐエージェント実行環境を提供する。 Phi-4などのSLM（Small Language Model）をNPU向けに量子化し、オフラインでも動作するエージェントを構築できるWindows AI Studioも発表された。データ機密性が高いユースケースや低遅延が求められる場面では、ローカル実行の選択肢は現実的な差別化要素となる。 実務への影響 日本のエンジニア・IT管理者向けの実践的ポイントをまとめる。 短期（3ヶ月以内）で着手すべきこと Azure AI Foundry上でのモデル切り替え評価: OpenAI一択だった構成から、タスクに応じてモデルを選ぶアーキテクチャへの移行を検討する。長文処理・複雑な推論タスクは特に比較評価の余地が大きい Agent Blueprintsの確認: 既存のCopilot実装をエージェントアーキテクチャに移行できるか、ブループリントを参照して影響範囲を把握する 中期（6ヶ月以内）で進めたいこと Foundry IQによるRAGアーキテクチャの統合: 現在バラバラに管理しているデータコネクタをFoundry IQに集約できるか調査・PoC実施 HorizonDBの評価: 新規プロジェクトのデータストア選定でHorizonDBを候補に加え、ベクトル検索要件のある案件で評価する ガバナンス面の先行準備 ...

Microsoftは2026年6月1日、Microsoft Defender for Cloud のオープンソースリレーショナルデータベース向け保護機能（Defender for Open-Source Relational Databases）をAWS RDS環境に対して正式GA（一般提供）化した。プレビュー期間中に有効化済みの環境は自動移行され、2026年7月の請求から課金が開始される。 何が変わったのか これまでプレビューとして提供されていたAWS RDS向けの脅威検知機能が、本番運用に耐えるGAステータスへ昇格した。対応するデータベースは以下の5種類だ： Aurora PostgreSQL Aurora MySQL PostgreSQL MySQL MariaDB この機能を有効化すると、Defender for Cloudは2つの主要な保護を提供する： データベース脅威検知（Database Threat Protection） — 不審なログインパターン、SQLインジェクション試行、異常なデータアクセスなどをリアルタイムで検知し、セキュリティアラートを発行する 機密データ検出（Sensitive Data Discovery） — AWS RDSインスタンス内の機密データを自動で発見し、セキュリティインサイトに反映する。この機能はDefender CSPM（Cloud Security Posture Management）とも連携し、クラウドセキュリティ態勢の向上に寄与する 有効化の手順 設定はAzureポータルから行う： Azure PortalでMicrosoft Defender for Cloudを開く Environment settings から対象のAWSアカウントを選択 Databasesプランの設定を開き、Open-source relational databasesをオンにする Configure accessからCloudFormationテンプレートをダウンロードし、AWSスタックを更新する 内部的にはDefenderForCloud-DataThreatProtectionDBロールが作成または更新され、RDSのパラメーターグループ・オプショングループの管理権限やログ収集権限がDefender for Cloudに付与される仕組みだ。なお、利用可能なAWSリージョンはテルアビブ・ミラノ・ジャカルタ・スペイン・バーレーン以外のすべてのパブリックリージョン。東京・大阪リージョンは対応済みのため、日本企業の環境で問題なく使える。 注意点：7月から課金が始まる プレビュー中に有効化していた環境では自動的にGAへ移行される。特に何もしなければ保護は継続されるが、2026年7月の請求から課金が開始される点は見落とさないようにしたい。 コスト削減を望む場合は、移行前にプランを明示的に無効化する必要がある。AWSマルチクラウド環境でDefender for Cloudを有効にしているチームは、今すぐ対象インスタンス数とコスト影響を確認することを強く推奨する。 実務への影響 マルチクラウド構成の日本企業に直結する話 日本のエンタープライズでは「コアシステムはAzure、既存のPostgreSQLはAWS RDS」という混在構成は珍しくない。従来はAzureとAWSのセキュリティ監視を別々のツールで管理せざるを得ず、インシデント対応時にコンテキストが分断されるという課題があった。 Defender for Cloudがこの橋渡し役を担うことで、Microsoft SentinelやDefenderのダッシュボードでマルチクラウドDBの脅威を一元的に可視化できる体制が整う。運用チームの負担軽減という観点でも、統合管理が進むのは実務にとってプラスだ。 IT管理者がすぐやるべきこと 課金確認: Defender for CloudのEnvironment settingsでAWSアカウントのDatabasesプランの状態を確認する 対象DB棚卸し: Aurora含むRDSインスタンスの台数と規模をコスト試算に活用する 既存ツールとの重複チェック: AWS GuardDutyやAWS Security Hubとの機能重複を評価し、二重投資になっていないか確認する CloudFormationテンプレートの更新確認: プレビューから自動移行されている場合も、権限設定が最新になっているかを改めて確認する 筆者の見解 マルチクラウドが当たり前になった今、「クラウドをまたいで統一されたセキュリティ管理を行う」という課題はどの企業も抱えている。Defender for CloudがAWS RDSのOSSデータベースを正式サポートしたことは、その課題への実用的な回答のひとつだ。 ...

Microsoft は 2026年6月1日（本日）より、Entra Connect Sync および Cloud Sync において、Entra ID の特権ロールを持つクラウドユーザーへの「ハードマッチ」操作をブロックする施策を段階的に有効化した。オンプレミスの Active Directory（AD）を経由してクラウド特権アカウントを乗っ取る「SyncJacking」攻撃を封じるセキュリティ強化で、ハイブリッドID環境を運用するすべての組織が影響を受ける可能性がある。 ハードマッチとは何か ハードマッチとは、Entra ID 上にすでに存在するクラウド専用ユーザーと、オンプレミス AD のオブジェクトを紐付けるための仕組みだ。 典型的なシナリオは次のとおり。最初はクラウドファーストで組織を立ち上げ、Entra ID 上にユーザーを直接作成して M365 ライセンスや管理ロールを割り当てた。その後オンプレミス AD を導入し、既存のクラウドユーザーをハイブリッドIDとして統合したい——という場面だ。 このとき Entra Connect は AD 側のオブジェクトとクラウド側のオブジェクトを自動的に結びつけることができない。そこで管理者が AD ユーザーの sourceAnchor 属性にクラウドユーザーの onPremisesImmutableId と同じ値を書き込むことで、次回の同期サイクル時に「ハードマッチ」が成立し、AD がそのアカウントのソースオブソリティ（権限の源泉）となる。 SyncJacking——攻撃者が悪用した仕組み このハードマッチの仕組みが攻撃に転用されたのが「SyncJacking」だ。セキュリティ企業 Semperis が 2022 年に開示し、Microsoft のセキュリティ対応センター（MSRC）が 2025年5月に「重要な特権昇格の脆弱性」として公式認定した。 攻撃の流れはシンプルだ。 攻撃者がオンプレミス AD のオブジェクトへの書き込み権限を取得する 標的となるクラウド特権ユーザー（グローバル管理者など）の onPremisesImmutableId を調べる AD オブジェクトの sourceAnchor にその値を書き込む 次の同期サイクルで正規のハードマッチが発生し、AD がそのグローバル管理者アカウントを掌握する 攻撃者は Entra ID に直接触れることなく、AD 経由でクラウド特権を完全掌握する オンプレミス AD への侵入を足がかりにクラウドの最高権限を奪取できる、ハイブリッド環境特有の危険な攻撃ベクターだ。 2段階の強化内容と影響範囲 今回の対策は 2 段階で適用される。 ...

Microsoft Entra IDが、「全クラウドアプリ対象＋一部リソース除外」という構成のConditional Access（条件付きアクセス）ポリシーを特定の認証フローで回避できていたセキュリティ上の抜け穴を修正し、2026年3月27日から段階的な展開を開始した。OIDC（OpenID Connect）スコープのみを使用する認証リクエストも含め、ポリシーが正しく評価されるようになる。 何が問題だったのか Conditional Accessポリシーを「すべてのクラウドアプリ（All cloud apps）」を対象にしつつ、特定アプリを除外（Exclude）する設定にしている場合、アプリケーションが openid、profile、email などのOIDCスコープや、Microsoft Graphの User.Read のような限定的なスコープのみをリクエストするケースでは、これまでConditional Accessが適用されていなかった。 認証リクエストが「特定のリソース」を明示的にターゲットしない形式であるため、ポリシーエンジンが評価をスキップしていたのが原因だ。結果として、MFAや端末コンプライアンスの要件を満たさないままサインインが成立してしまう状況が生じていた。 修正後の挙動 改修後は、OIDCスコープや限定的なGraphスコープのみを使うリクエストに対しても、「全クラウドアプリ対象」ポリシーが漏れなく評価されるようになる。除外設定の有無にかかわらず、該当ポリシーに設定されたMFA要件・端末コンプライアンス・承認済みアプリ条件などが強制適用される。 Microsoftはこの変更を「Secure Future Initiative（SFI）」の一環として位置付けており、テナント管理者にはMicrosoft 365メッセージセンターおよびEntra管理センター経由で事前通知が送られる。 影響を受けるテナントの確認方法 影響が出るのは、以下の条件を満たすConditional Accessポリシーを持つテナントに限られる： ターゲットリソースに「すべてのクラウドアプリ（All cloud apps）」を選択している かつ「除外 > 対象外クラウドアプリを選択」で1つ以上のアプリを除外している 確認手順は Microsoft Entra管理センター > 保護 > 条件付きアクセス > ポリシー から各ポリシーのターゲット設定を開くだけだ。この組み合わせに該当しないポリシーしか持たないテナントには影響がない。 すでにすべてのサインインにMFAまたは端末コンプライアンスを要求しているポリシー構成であれば、実質的な変化は起きない。問題になるのは、OIDCスコープのみで認証するカスタムアプリケーションが「除外なしでMFAを要求される」ようになるケースだ。開発環境・ステージング環境でテストを先行させることを強く推奨する。 実務への影響 すぐに確認すべきこと： Conditional Accessポリシーの棚卸し — 「全クラウドアプリ＋除外」構成のポリシーを洗い出す。M365管理者なら今週中に終わらせたい作業だ カスタムアプリの認証フロー確認 — 自社開発アプリやサードパーティSaaSがOIDCスコープのみで認証していないか確認。該当する場合はステージング環境で事前に動作検証を行う 通知の受信確認 — Entra管理センターのメッセージセンターにMicrosoftからの事前通知が届いているはずなので確認する ヘルプデスクへの周知 — 変更後にMFA画面が突然表示されてサポート問い合わせが増える可能性がある。エンドユーザーへの事前告知も検討を 筆者の見解 Conditional Accessは「ゼロトラスト戦略の要」だと考えている。ネットワーク境界でブロックするVPN型の発想とは根本的に異なり、「誰が、どのデバイスから、どのアプリに、どんな条件でアクセスするか」をきめ細かく制御できる点が強みだ。 今回修正されたOIDCスコープの抜け穴は、ポリシーを正しく設定しているつもりの管理者が気づかないまま放置していたケースが相当数あったはずで、今回の修正は歓迎すべきことだ。「設定した＝適用されている」は甘い認識で、実際の認証フローに即した検証が不可欠だということを改めて示している。 ただし、修正の展開が3月開始〜6月完了という長い期間をかけている点は気になる。影響範囲の広さへの慎重さは理解できるが、セキュリティ修正をここまでゆっくり展開するのは、攻撃者にとって都合のよい窓口期間ができるという側面もある。エンタープライズIT部門は「自分のテナントにはまだ適用されていない」と楽観しないよう注意してほしい。 Microsoft Entra IDは引き続きゼロトラスト戦略の中核として使い続けていい基盤だ。今回のような修正が迅速に届き、管理者がきちんと対応できる仕組みになっているなら、その信頼は揺るがない。 出典: この記事は Microsoft Entra ID Fixes Conditional Access Policy Bypass, Enforces MFA for OIDC-Only Requests の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft が Microsoft Entra Global Secure Access（GSA） を更新し、Entra 登録済みデバイス（Entra Registered Devices） を使った BYOD（Bring Your Own Device）シナリオへの正式対応を発表した。これにより、社員の個人デバイスを組織が完全管理しなくても、条件付きアクセスポリシーを適用した上で企業リソースへの安全なアクセスが可能になる。 「登録済み」と「参加済み」——デバイス管理の重要な違い Entra のデバイス管理には大きく分けて 2 種類がある。 種別 概要 組織の管理権限 Entra Registered（登録済み） デバイスに信頼 ID を付与するが、組織はフル管理権限を持たない 限定的 Entra Joined（参加済み） 組織が完全管理。MDM ポリシーや構成プロファイルを適用可能 フル Hybrid Joined（ハイブリッド参加済み） オンプレミス AD と Entra ID の両方に参加 フル 今回の BYOD 対応は「登録済み」デバイスを活用するもので、社員のプライバシーを守りながら企業セキュリティを担保するアプローチだ。個人のスマートフォンや私物 PC に MDM を全適用するのは現実的ではなく、これまで BYOD 対応が難しかった組織にとって選択肢が広がる。 仕組みのポイント：アイデンティティベースのアクセス制御 BYOD アクセスの実現フローは以下の通りだ。 デバイス登録 — Microsoft Authenticator や Intune Company Portal を使って個人デバイスを Entra ID に登録。この時点でデバイスに「信頼できる ID」が付与される 条件付きアクセスポリシーの適用 — デバイスが登録済みであることを条件にアクセスを制御。未登録デバイスはブロック Global Secure Access 経由でのトラフィック保護 — Private Access プロファイルを通じ、企業内部リソースへのアクセスを暗号化・保護 重要なのは、ネットワーク層ではなくアイデンティティ層で制御している点だ。従来の VPN のように「社内ネットワークに入れば何でもできる」という発想ではなく、「誰が・どのデバイスで・何にアクセスするか」を細かく制御する。 ...

AIエージェントが業務プロセスを自律的に処理する時代が到来しつつある中、Microsoftは2026年3月のRSAカンファレンス直前、Microsoft Defender・Entra・PurviewにAIエージェント専用のセキュリティ機能群を追加発表した。エージェントのID管理・可視化・データ保護を統合する「AIエージェントセキュリティ層」として、組織がAIエージェントを安全にデプロイするための基盤整備が本格化する。 AIエージェントに「専用のセキュリティ層」が必要な理由 従来のアプリケーションと異なり、AIエージェントは「自律的に判断し、外部サービスにアクセスし、データを移動させる」。通常のアプリケーションのアクセス制御モデルが想定していない動作だ。 Microsoftは「AIエージェントは普通のアプリケーションとして扱うべきではなく、専用のセキュリティ層が必要」と明言している。この方針のもと、3つの領域で新機能が投入された。 Agent 365：AIエージェントの管制塔 今回の発表の中核となるのが Agent 365 だ。2026年5月1日に正式提供（GA）が予定されているこのプラットフォームは、組織内に展開されているすべてのAIエージェントを一元的に把握・管理するコントロールプレーンとして機能する。 IT部門・セキュリティチーム・事業部門が同一ビューを共有できる点が重要だ。「どのエージェントが何に、誰の権限でアクセスしているか」を横断的に把握できなければ、ガバナンスは絵に描いた餅になる。Agent 365はMicrosoft 365 E7ライセンスにバンドルされる。 可視化と統制：Shadow AI検知からIntune連携まで AIセキュリティダッシュボード（GA済み） CISOやセキュリティチームが組織全体のAI関連リスクを一覧できるダッシュボードが正式提供された。AIリスクの「見える化」はあらゆる対策の出発点だ。 Entra Internet Access Shadow AI Detection（3月31日より） 管理外のAIサービス利用をネットワーク層で検知する機能。ChatGPTや各種AIツールを頭ごなしに「禁止」するのではなく、利用状況を把握した上で適切なポリシーを当てるアプローチだ。「禁止よりも可視化から」という考え方は、ゼロトラストの文脈でも正しい方向性といえる。 Intune AIアプリインベントリ（5月予定） エンドポイントにインストール済みのAIアプリを深掘り把握する機能。ネットワーク層とエンドポイント層を組み合わせた多層的な可視化が整ってくる。 IDとデータの保護 Entraの新機能 Entra Backup and Recovery（プレビュー）：Entraの設定・データのバックアップと復旧。Entraへの依存度が高まる中、地味ながら実は非常に重要な機能だ Entra Tenant Governance：マルチテナント環境での管理強化 Windows Hello パスキー連携：ネイティブ統合によりパスキー対応を拡張 Purviewによるプロンプトデータ保護 AIプロンプトに個人情報やクレジットカード番号等の機密データが含まれる場合にブロックできる機能が追加された。Microsoftのセキュリティブログは「機密データはポリシーが追いつく速度よりも速くAIワークフローを流れる」と指摘しており、現場の実感とも合致する課題への直接的な対処だ。 Security CopilotとSentinelの新機能 Security CopilotがMicrosoft 365 E5・E7にデフォルト統合された。以下のエージェント型機能が追加されている： Security Analyst Agent in Defender（3月26日よりプレビュー）：繰り返し発生するセキュリティ作業を自動化するアナリスト支援エージェント Security Alert Triage Agent：クラウドおよびID関連アラートのトリアージを自動化 Microsoft Sentinelは「エージェントレス防衛プラットフォーム」として位置づけられ、Microsoft Fabricとのデータ組み合わせ機能が強化された。 日本のIT現場への影響 AIエージェントのガバナンス体制構築が急務になる。 来年・再来年にAIエージェントを本格導入しようとしている企業は、今のうちにIDとアクセス権の棚卸しを進めておく必要がある。エージェントは「動くだけ」では危険であり、「管理された上で動く」が必須条件になっていく。 M365 E7ライセンスの評価が現実的な検討事項になってきた。 Agent 365のバンドル先がE7というのは重要なシグナルだ。AIエージェント活用を本格化させるなら、ライセンス体系の見直しは避けて通れない。 Shadow AI対策には「禁止より把握」のアプローチを。 Entra Internet Access Shadow AI Detectionのような検知・可視化ツールを使い、社員が使っているAIツールの実態を把握した上でポリシーを整備する方が現実的だ。頭ごなしの禁止は利用が地下に潜るだけで逆効果になることが多い。 ...

Microsoftは2026年5月にシアトルで開催されたOpen Source Summit North America 2026において、AIエージェントのガバナンスをオープンに標準化するフレームワーク「Open Agent Governance Framework（OAGF）」を発表した。エージェント間通信・ポリシー適用・監査可能性の仕様をオープンソースとして策定し、ベンダーを超えた相互運用性の実現を目指す取り組みだ。 Open Agent Governance Frameworkとは何か OAGFは、複数のAIエージェントが連携して動作する「マルチエージェント」環境における統制基盤を定義するオープン標準だ。主な仕様は3つの柱で構成される。 エージェント間通信（Agent-to-Agent Communication） 異なるベンダーや異なるプラットフォームで動作するエージェント同士が、安全かつ標準的な方法でメッセージをやり取りできるプロトコルを定義する。現状、エージェント間通信はベンダー独自実装が乱立しており、互換性の問題が実運用の大きな障壁となっている。 ポリシー適用（Policy Enforcement） 組織のセキュリティポリシーやコンプライアンス要件を、エージェントの動作に自動的に反映させる仕組みだ。どのエージェントが何のデータにアクセスできるか、どの操作を許可・拒否するかを一元的に制御できる。 監査可能性（Auditability） エージェントがいつ、何を、誰の指示で実行したかを追跡・記録する仕様だ。AI活用が進む組織でコンプライアンス担当者が最も懸念するのが「AIが何をしたかわからない」問題であり、OAGFはここに直接答える形となっている。 Azure Linux 4.0も同時発表 同イベントではAzure Linux 4.0も発表された。MicrosoftがAzureインフラ向けに開発・メンテナンスしているLinuxディストリビューションの最新版で、コンテナホストやエッジ環境での利用を主眼に置く。CBL-Marinerから改称されたAzure Linuxは、Azureの基盤インフラで実際に使われている実績から、信頼性・セキュリティ・パフォーマンスのバランスに優れた選択肢として評価されている。 なぜこれが重要か——AIエージェントの「野良化」問題 AIエージェントの企業導入が加速する中、最大の課題のひとつが「誰がエージェントを管理するか」という問題だ。部門ごとに異なるエージェントを導入し、それぞれが独自のアクセス権限を持つ状況が生まれれば、従来のITガバナンスは機能しなくなる。 OAGFのようなオープン標準が普及すれば、組織のIT部門は一元的なポリシー管理のもとで複数のエージェントを安全に運用できるようになる。これはゼロトラストの文脈でも重要で、エージェントのアイデンティティ（NHI: Non-Human Identity）管理と組み合わせることで、人間ユーザーと同等のアクセス制御を自動化エージェントにも適用できる。 実務への影響——日本のエンジニア・IT管理者へ NHI管理の設計を今すぐ始める エージェントを導入する前に、そのエージェントのアイデンティティをどう管理するかを設計することが不可欠だ。Microsoft Entra IDを使ったサービスプリンシパルやマネージドIDの仕組みを活用し、エージェントごとに最小権限を割り当てる「Just-In-Time（JIT）アクセス」の設計を早い段階から組み込むべきだ。 監査ログの設計を後回しにしない 「とりあえず動けばいい」でエージェントを本番導入すると、後からガバナンス要件を満たすための改修コストが跳ね上がる。OAGFの監査可能性仕様を参考に、ログの設計は実装と並行して進めよう。 ベンダー標準よりオープン標準を優先する 複数のエージェントを組み合わせる環境では、特定ベンダーのプロプライエタリな通信方式に依存するとロックインリスクが高まる。OAGFのようなオープン標準への対応状況を、エージェント製品選定の評価軸に加えることを推奨する。 筆者の見解 MicrosoftがAIエージェントのガバナンスをオープン標準として推進するこの動きは、長期的に見て正しい方向だと思う。 AIエージェントの時代において、最も賢いモデルを作る競争とは別軸で、最も多くのエージェントが安全に動作するプラットフォームを提供する競争がある。Microsoft Entra IDとAzureという実績あるインフラを持つMicrosoftは、後者の競争で有利な立場にある。OAGFはその強みをさらに活かせる方向への投資だ。 特にNHI管理の標準化は、エンタープライズの自動化推進において本質的なボトルネック解消につながる可能性がある。エージェントのガバナンスが整備されないうちは、IT部門がエージェント導入にブレーキをかけるのは合理的な判断であり、OAGFはそのブレーキを安全に外すための鍵となり得る。 ひとつ注目したいのは、この標準がどこまで「本当にオープン」になれるかだ。Microsoftが主導して策定した標準が業界標準として定着するには、競合他社を含む幅広いエコシステムの参加が欠かせない。「道のド真ん中を歩く」選択肢として多くの組織が採用できる標準になるかどうか、コミュニティの広がりを今後も注視したい。 出典: この記事は From open source to agentic systems: Microsoft at Open Source Summit North America 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年5月29日（UTC 09:39〜17:05）、Azure OpenAI Serviceが約7.5時間にわたる大規模障害を発生させた。原因は雷雨による電源・熱障害であり、複数のリージョンが影響を受け、AIワークロードに依存する多くのシステムが機能不全に陥った。 何が起きたのか マイクロソフトが公開したPost Incident Review（PIR）によると、障害の根本原因は雷雨による電源サージおよびデータセンター内の熱管理システムへの連鎖的な影響だ。 UTC 09:39に最初の障害が検出され、複数リージョンでAzure OpenAI Serviceへのリクエストが失敗し始めた。影響を受けたリージョンでは、APIリクエストのエラーレートが急上昇し、モデル推論が事実上停止。UTC 17:05に完全復旧が確認されるまでの約7時間26分、AIワークロードが多くの現場で止まった。 影響範囲はAzure OpenAI Serviceにとどまらず、Azure AI ServicesやAzure Machine Learningの一部機能にも波及した可能性がある。 シングルリージョン依存が露わにしたリスク 今回の障害が改めて浮き彫りにしたのは、大規模AIサービスにおけるシングルリージョン設計の危うさだ。 従来のWebアプリやデータベースであれば、複数リージョンへのフェールオーバー設計はすでに常識だ。しかしAzure OpenAI Serviceのような大規模言語モデル（LLM）APIは、マルチリージョン化が難しい現実がある。 モデルのデプロイ先が限定的: GPT-4oやo1シリーズなどのモデルは、すべてのリージョンで等しく利用できるわけではない エンドポイントのリージョン固定: デフォルトのAzure OpenAI Serviceエンドポイントはリージョン固有のURLを使用する コスト: 複数リージョンにプロビジョニング容量（PTU）を確保するのは費用負担が大きい 実務への影響と今すぐできる対策 1. マルチリージョンフェールオーバーを設計する Azure API Management（APIM）やAzure Front Doorと組み合わせることで、マルチリージョンフェールオーバーを実現できる。プライマリリージョン（例：Japan East）とセカンダリリージョン（例：East US 2）の両方にAzure OpenAI Serviceをデプロイし、APIMのバックエンドプールで健全性プローブと自動フェールオーバーを設定するのが王道の構成だ。 2. リトライとサーキットブレーカーをアプリ層に実装する Azure OpenAI Serviceの一時的な障害に対して、指数バックオフ付きのリトライ処理とサーキットブレーカーパターンを実装する。Semantic KernelやPromptFlowを使っている場合は、組み込みのリトライ設定を確認しておくこと。 3. Azure Service Healthのアラートを設定する Azure Service HealthでAzure OpenAI Serviceのサービス正常性アラートを設定し、障害発生時に即座に通知を受け取れるようにしておく。早期に代替手段へ切り替える判断ができるかどうかが、復旧速度を大きく左右する。 4. AIワークロードのSLA設計を根本から見直す Azure OpenAI Serviceの標準SLAは99.9%だが、これは月間約44分のダウンタイムを許容する数字だ。今回の7.5時間はその10倍以上にあたる。ビジネスクリティカルなAIワークロードには、それに見合った冗長設計を要求すること。 筆者の見解 今回の障害で最も気になったのは、技術的な問題そのものではなく、多くの企業がAzure OpenAI Serviceをシングルリージョンで本番稼働させているという現実だ。 ...

2026年5月29日、MicrosoftはAzure Resource Manager MCP ServerのPublic Previewを発表した。AIエージェントがAzure Resource Graph（ARG）クエリを通じてAzureインフラを直接操作・参照できる仕組みが、一般開発者向けに開放される。同週には Azure Files のマネージドID専用認証GA、Azure NetApp Files 64TiBファイルサイズ対応GA、Microsoft Foundry の Vercel AI SDK 対応など複数の重要アップデートが重なった。 Azure Resource Manager MCPサーバーとは MCPとはModel Context Protocol（モデルコンテキストプロトコル）のことで、AIエージェントが外部システムと標準化された方法でやり取りするための仕組みだ。今回公開されたAzure Resource Manager MCP Serverを使うと、Azure AI Foundryで動くAIエージェントが、ARGクエリを通じてAzureリソースの状態を問い合わせたり、リソース管理操作を実行したりできるようになる。 従来であれば「エンジニアがPortalを開き、PowerShellを実行する」という手順が、AIエージェントへの指示一つで完了する可能性が出てきた。「今どのリソースが起動していて、コストはいくらか」「セキュリティルールに違反しているリソースはないか」——そうした問いをエージェントに自然言語で投げられる環境が整ってきている。 今週の主要アップデート Microsoft Foundry + Vercel AI SDK 対応 Microsoft FoundryがTypeScriptのVercel AI SDKに対応した。TypeScriptで書かれたAIアプリケーションからFoundry経由でモデルを呼び出す際の実装コストが下がる。 AKS Application Insights 自動インスツルメンテーション Azure Kubernetes Service（AKS）でApplication Insightsの自動インスツルメンテーションがサポートされた。コンテナワークロードのトレーシングやメトリクス収集の手動設定が不要になり、セットアップ工数が大幅に削減される。 Azure Files Entra ID専用認証のGA Azure FilesのSMBアクセスをEntra IDのマネージドIDのみに制限するモードが一般提供（GA）となった。ストレージアカウントキーへの依存を排除し、ゼロトラスト型のアクセス制御を徹底できる。 ネットワーク強化 NSGとUDRの制限値が引き上げられた。Azure Front Door のWebSocket対応、Network Watcher のルール影響アナライザー追加、VPNのS2S証明書認証とP2Sユーザーグループ別IPプールなども利用可能になった。 Azure NetApp Files 64TiB対応GA 1ファイルあたり最大64TiBのサイズをサポート。大規模データベースやHPCワークロードへの適用範囲が拡大した。 ...

MicrosoftのAzure SRE Agentチームが、インタラクティブCLIよりも先にMCPサーバーをリリースする設計判断の背景と、人間とAIエージェントの両方を同時に相手にするインターフェース設計の原則を公開した。 なぜMCPサーバーが最初なのか Azure SRE Agentには、設計当初から3種類のインターフェースが想定されている。 インタラクティブCLI — 深夜2時のインシデント対応中にターミナルを叩く人間向け。簡潔で障害対応に最適化 エージェントモード — Copilot CLIのようなコーディングエージェントがサブプロセスとして起動するモード MCPサーバー — コーディングエージェントの中にいる人間、および他のエコシステムで動くリモートエージェント向け CLIとエージェントモードには共通点がある。呼び出し側が「Azure SRE Agentの存在を知っていて、意図的に呼び出す」必要がある点だ。人間がコマンドを打つ、あるいはエージェントがサブプロセスを起動する——いずれも能動的な呼び出しだ。 MCPサーバーはまったく異なる動作原理を持つ。ツールとして呼び出し側がすでにいる環境の中に自分を露出する。SREエンジニアがCopilot CLI上で「APIゲートウェイの何が問題か」と尋ねると、モデルがツール説明を読んで適切なツールを発火させる。別のターミナルを開く必要はない。PagerDutyのSREエージェントがトリアージループを回す際も、サブプロセスを起動せずプロトコルで直接応答を得る。 この違いを一言でまとめると：CLIは意図を要求し、MCPサーバーは呼び出し側の居場所に出向く。 MCPサーバーが相手にする2種類の呼び出し元 MCPサーフェスには、同じプロトコルを使いながらまったく異なる文脈の2種類の呼び出し元がいる。 コーディングエージェントの中にいる人間：VS Code CopilotやClaude Desktop、Cursor上でデプロイスクリプトを書いたりRunbookを読んでいるSREエンジニアだ。コンテキストスイッチを望まず、今やっている作業の傍らにSREの能力が自然に存在してほしい。MCPサーバーを一度接続すれば、それは常にそこにある。 他のエコシステムのリモートエージェント：クロスクラウドインシデントを処理するAWS DevOpsエージェント、トリアージループを回すPagerDutyのSREエージェント、あるいは別のAzure SRE Agentインスタンスがサブタスクを委譲する場合などだ。カスタム統合なしに、プロトコルで合意するだけで相互運用できる。 呼び出し元 文脈 必要なもの Copilot CLI / VS Code Copilot上の人間 コーディングセッション中 読みやすい要約、最小限のオーバーヘッド Claude Desktop / Cursor上の人間 エージェンティックセッション 会話内でSREツールが使える状態 AWS DevOpsエージェント 自動インシデントループ 定義されたスキーマ、安定したフィールド PagerDuty SREエージェント トリアージパイプライン パーサブル、疎、ナラティブ不要 別のAzure SRE Agentインスタンス 委譲されたサブタスク エージェント間コントラクト ツール説明文はプロダクト意思決定そのもの MCPツールには名前、自然言語の説明、JSONスキーマが付く。この説明文がモデルのツール選択を直接左右するという点は、見落とされがちながら極めて重要だ。 「Azureリソースのヘルス状態を返す」と書かれたツールと、「VMやゲートウェイ、データベース、コンテナが正常・劣化・到達不能のいずれかを確認する。アクティブな障害の診断やデプロイ後の状態確認に使う」と書かれたツールでは、モデルの呼び出し精度が大きく変わる。 後者は「何をするか」だけでなく「いつ使うか」を伝える。チームはツール説明をシステムプロンプトと同様にイテレーションした——テスト中に誤った呼び出しが発生したとき、修正箇所はほぼ常にスキーマではなく説明文だったという。 人間とエージェント、なぜ同じ出力形式を使うのか 人間は読みやすいレスポンスを求め、リモートエージェントはパース可能な構造を求める。「呼び出し元に応じて出力形式を切り替えるべきでは？」という発想は自然だが、チームはあえて単一の出力形式を選んだ。 すべてのツールレスポンスは、定義されたフィールドと安定したセマンティクス、そして1つの summary フィールド（平文の1文）で構成される。人間は summary を読み、リモートエージェントはそれを無視して構造化フィールドをパースする。オーバーヘッドはどちらの方向でも無視できる程度だ。 ...