Microsoft Build 2026まとめ ~コンテキストの海をAIが泳ぐ時代に、業務基盤屋は何を考えるか~

すかんく
すかんく

クラウドセキュリティアーキテクト

はじめに

どうも、すかんくです。

2026年6月2~3日、サンフランシスコで開催された Microsoft Build 2026 を追っていました。
キーノートはいつもどおりAI一色……なんですが、今年のそれは「AIをどう使うか」ではなく「AIが前提になった世界で、開発も業務もどう組み替わるか」という話になっていて、個人的にけっこう刺さるものがありました。

例によって発表は山ほどあるんですが、本記事では情報システム屋の視点から「これは押さえておきたい」というものに絞ってまとめつつ、正直な感想を残しておきたいと思います。

技術的な深掘りというより、「で、現場的にどう受け止めるの?」というレイヤーの話だと思って読んでもらえれば。では始めましょう。


全体テーマ:「Be yourself at work」と3つの軸

今年のBuildを貫くメッセージは「職場で自分らしく働く(Be yourself at work)」でした。Microsoftが整理していたアンカーは大きく3つ。

  1. 本当の意味で“あなたのもの”であるインテリジェンス … Microsoft Agent Platform + Microsoft IQ
  2. フルスタックを自分流に … Silicon→OS→開発ツール→クラウド、その起点としてのWindows
  3. その次に来るもの … エージェントが科学・研究の領域へ

開発者向けの祭典なので当然なんですが、裏を返すと「エージェントを前提にした業務基盤を、ガバナンスとセキュリティ込みでどう成立させるか」が全部のテーマに絡んでくる構図です。我々のような職務領域も追従が必要な話題になっているなと感じました。

ちなみに自前のMAIモデル群(推論の MAI-Thinking-1、コーディングの MAI-Code-1MAI-Image-2.5MAI-Transcribe-1.5)の発表もあって、「Microsoftといえば実質OpenAI」だった構図が変わりつつあるのも今年のトピックでした。ここは本筋から外れるので、また別の機会に。


注目ポイント:Microsoft IQ ~コンテキストの海をAIが泳ぐ~

今回の発表の肝であり、自分自身も「うわ、これは世界観が変わるやつだ」と感じたのが Microsoft IQ です。

Microsoft Agent Platformの土台として、エージェントに“知能の源泉”を供給するレイヤー群、というのがざっくりした位置づけ。整理すると、概念的には次の層で構成されています。

レイヤーざっくり何を司るか
Work IQユーザーの仕事の文脈(ワークフロー/業務の文脈)。API GAは6/16予定
Foundry IQナレッジの文脈(社内外の知識を束ねる中間層)
Fabric IQデータの文脈(データ基盤としての土台)
Web IQ世界の知識(MCPネイティブで外の世界とつながる層)

注意点として、これらは「個別の製品」というより「AIの振る舞いを豊かにするために組織が到達したい状態(アウトカム)」として説明されているのが面白いところ。

GitHubでエージェントを作り、Foundryにデプロイし、最適なモデルで自動最適化して、Teams・M365・どこからでも呼び出す——その全工程に、IQが文脈を供給し続けるわけです。

従来の「ユーザーがコンテキストを与えてAIを活用する」世界から、「コンテキストの海をAIが自分で泳ぐ」イメージに世界観が変わってきたなぁ

という感触を持ちました。これ、地味なようでパラダイムが完全に裏返ってるんですよね。

これまでのAI活用は、極論すると「人間がプロンプトという名のバケツで、必要なコンテキストをAIに手渡す」作業でした。RAGにしたって、結局「どの情報を、どう渡すか」を人間(か、人間が組んだパイプライン)が設計していた。

ところがMicrosoft IQの世界観は、Work / Foundry / Fabric / Webという形でコンテキストが最初から海として存在していて、エージェントがそこを能動的に泳ぐ(学んでいる)
人間がバケツで水を運ぶんじゃなくて、AIが海に飛び込んで必要な水を自分で見つけてくる。発想の主語がひっくり返っているのが本質だと思います。

正確にはWork IQの時点からMicrosoftのAI戦略としてはこの傾向が顕著でしたが、今回のBuildを経てワークロードがMicrosoft Scoutによってエンドポイントまで拡張されたことにより、この世界観の中にいるイメージがより鮮明に描けるようになりました。


これ、マルチベンダー戦略が“不利”になる世界では?

ここからが情シスとしては悩ましいポイント。

こうなってくると、業務基盤で下手にマルチベンダー戦略を採るほうがデメリットに見えてくる。ベンダーロックインが事業リスク、なんて言っていられるんだろうか……?

長年「特定ベンダーに寄せすぎるとロックインで身動きが取れなくなる」というのが基盤設計において語られてきたと思います。調達の交渉力、可搬性、リスク分散——どれも正論です。

でもMicrosoft IQの世界観だと、価値の源泉が「個々のツールの良し悪し」から「コンテキストが、どれだけ深く・滑らかにつながっているか」に移る。
Work IQがM365の業務文脈を、Fabric IQがデータ基盤を、Foundry IQがナレッジを、シームレスに束ねてエージェントに供給する。この “つながりの深さ” は、同一スタックに寄せているほど効いてくるわけです。

ここでマルチベンダーを採ると、ベンダー間の境界ごとにコンテキストの “継ぎ目” ができる。その継ぎ目こそがエージェントの泳ぎを止める。つまり「分散させたこと自体が、コンテキストの分断=競争力の低下」として跳ね返ってくる構図になりかねない。

この世界観で働く環境と、これまでの業務環境とでは、生産性のベースラインが違いすぎるのではないか。

正直、これは煽りではなく本気でそう思っています。もちろん「だから全部Microsoftに寄せろ」という単純な話にする気はない(後述のセキュリティの “工夫の余地” がまさにそこ)。ただ、ロックインのリスク評価そのものを、コンテキスト時代の物差しで測り直す必要があるのは間違いない。「ロックインは悪」という前提を思考停止で握りしめていると、足元をすくわれる気がしました。


AIガバナンス・セキュリティは“手堅い”の一言

ここはわたしの本丸なので、しっかり見ました。結論から言うと、エージェント時代のガバナンス/セキュリティは手堅く揃ってきたという印象です。

エージェントのID・統制:Entra Agent ID / Agent 365

  • Agent 365 が、エージェントの可観測性・アクセス制御・コンプライアンスを束ねる統制基盤として前進。Agent 365 SDK がGAし、開発の段階から統制を“組み込み”で入れられるように。
  • Agent 365 Agent Registry が、Microsoft Defender・Entra・Intuneが連携して見つけ出した未管理のローカルエージェントまで可視化。コーディングエージェントやMCPサーバーなど20種類以上に対応。シャドーAI対策の本命ですね。
  • ランタイム保護も Defender / Entra / Intune の三位一体。エージェントの活動をDefenderのadvanced huntingで追えるらしい。

エージェントに Entra Agent ID で “身元” を与え、人間と同じ統制の土俵に乗せる——という方向性が、今年でだいぶ具体化しました。ID領域の業務に携わる身としては、ここがいちばん腹落ちする設計思想です。

コード・モデルの保護

  • MDASH(コードネーム):100以上の専門AIエージェントをアンサンブルで動かす、マルチモデルのagentic脆弱性スキャン基盤。CyberGymベンチで96.55%まで来たとのこと。
  • Microsoft Defender × GitHub Code Security 連携がGA。実行時の本番シグナル(インターネット露出・データ機微度)で脆弱性の優先度づけ→Copilot Autofixで修正、まで一気通貫。
  • Defender AI model scanning(プレビュー):デプロイ前にモデルアーティファクトの完全性を検証。

実行環境の隔離(Windows)

  • Windows 365 for Agents がGA。完全に隔離されたポリシー統制下のCloud PCでエージェントを動かせる。
  • Microsoft Execution Container(MXC)SDK:OSレベルでエージェント実行をプロセス/セッション隔離。

データ保護:Purview

  • Foundry Control Plane に Purview のデータリスクシグナルを埋め込み(GD)。開発・テスト中に機微データの露出をリアルタイムで警告。
  • エージェントプロンプト向けのランタイムDLP(Foundry、Agent 365連携プレビュー)。機微情報がモデルに渡る前に検知・ブロック・監査。

で、ユーザー(私個人)の感想

Entra Agent IDやエンドポイントの保護はもちろん、Entra Suite(Private Access / Internet Access)でトラフィックを抑え、PurviewやMCAS(Defender for Cloud Apps)でデータと振る舞いを統制する——という多層防御の絵姿は、全体としてよく描けている。

エージェントという“新しいプリンシパルタイプ”を、ID(Entra)/ネットワーク(Entra Suite)/データ(Purview)/アプリ振る舞い(MCAS)の各レイヤーで包む、という構図。守りの絵としては、ちゃんと多層になっている。ここはいつも通りのMicrosoftオールインワンを評価したいところです。


……とはいえ、現場目線での“工夫の余地”

ベタ褒めで終わるとらしくないので、率直なところを。

個人的には、Entra Private Access / Internet Accessはまだエンタープライズで通用する水準に達しきっていないと感じている。加えて、MCASやPurviewも“全部入り(全対応)”というわけではないので、この辺はアーキテクチャ的に工夫の余地がありそうですな。

絵姿はキレイなんですが、構成要素を一つずつ現場の要求水準で見ていくと、まだ詰めが要ります。

  • Entra Private Access / Internet Access:SSE/SASE文脈の本命候補ではあるものの、既存の成熟したプロキシ/ZTNA製品と並べたとき、機能網羅性・運用の作り込み・例外ハンドリングの面でまだ“伸びしろ”が大きい。「Entraで全部まかなえます」と言い切れるかというと、エンプラ要件だと現状はまだ慎重に見たい。というか、自分がアーキテクトでPoCをやったりしたら絶対に採用しないと言い切れる。
  • Purview / MCAS のカバレッジ:対象アプリ・操作・データ経路のすべてに均一に効くわけではない。「対応している前提」で設計図を引くと、いざ蓋を開けたときに保護の“穴”が残る。特にエージェント経由の非定型なデータアクセスは、まさにこれから埋まっていく領域ですし、Purview Endpointみたいな一見強力そうなソリューションも、実際に使ってみると痒い所に手が届かないどころか、痒い所しかないのが現状。

なので実務的には、「Microsoftの絵姿をそのまま敷くのではなく、効くところ・効かないところを見極めて、足りない部分を別解で補うアーキテクチャ設計」が当面の腕の見せどころになりそうです。多層防御の“層”のうち、どこが実戦投入レベルで、どこがまだプレビュー品質なのかを冷静に仕分けする——ここを雑にやると、紙の上だけ堅牢な統制になってしまう。

そして話が冒頭の「マルチベンダー問題」に戻ってくるのが面白いところで。コンテキストの観点では同一スタックに寄せる引力が強い一方、セキュリティの観点では “まだ全部はMicrosoftで賄いきれない” 現実がある。この引力と現実のあいだで、どうバランスを取るか。情シス・基盤屋の次の数年の仕事は、けっこうここに集約される気がしています。


まとめ

  • Microsoft IQは「人がコンテキストを渡す」から「AIがコンテキストの海を泳ぐ」へのパラダイム反転。地味だけど本質的。
  • その世界観では、マルチベンダー=コンテキストの分断として競争力に跳ね返る可能性があり、「ロックイン=悪」の前提を測り直す必要がある。
  • ガバナンス/セキュリティ(Entra Agent ID / Agent 365 / MDASH / Purview / 各種隔離)は手堅く前進。エージェントを “身元あるプリンシパル” として統制に乗せる思想は腹落ちする。
  • ただしEntra Private/Internet AccessやPurview・MCASは、まだ全要件をカバーしきれていない。絵姿を鵜呑みにせず、効く/効かないを仕分けして補完するアーキテクチャ設計が現場の勝負どころ。

新しい世界観にワクワクしつつ、足元の“工夫の余地”もちゃんと見る。このバランス感覚が、これからのアーキテクトには求められそうだなぁ、と思ったBuild 2026でした。ではまた!

この記事をシェア