.NETやAzure・Microsoft製品で学んだことや気づいたことを共有しよう

@Tadataka_Takahashi

Microsoft Build 2026 の AI 発表を整理する：Microsoft AI は「モデル」より先にエージェント基盤を作りにきている

Posted at 2026-06-05

はじめに

Microsoft Build 2026 では、AI 関連の発表がかなり多くあったみたいです。

ぱっと見ると「Microsoft AI が新しいモデルを出した」というニュースが目立ちます。特に MAI-Thinking-1 や MAI-Image-2.5 は分かりやすいトピックです。

ただ、全体を眺めると、個人的にはモデル単体の発表よりも、エージェントを業務で動かすための基盤を Microsoft が縦にそろえにきている、という見方のほうがしっくりきました。

この記事では、Microsoft Build 2026 の AI 発表を次の観点で整理します。

モデル: Microsoft 独自の MAI ファミリー
コンテキスト: Microsoft IQ / Work IQ / Fabric IQ / Web IQ / Foundry IQ
実行基盤: Microsoft Foundry Agent Service
統制: Agent 365 と trust stack
開発者視点: 何を見ておくとよさそうか

なお、本記事は 2026年6月時点の公式発表をもとにした個人メモです。private preview / public preview / GA 予定の機能が混在しているため、実際に使う場合は最新の公式ドキュメントを確認してください。

まず全体像：モデル発表だけではない

Microsoft 公式ブログでは、Build 2026 の AI 発表について大きく次のような文脈で説明されています。

開発者はモデルやツールを自由に選びたい
一方で、企業システムではガバナンス、セキュリティ、信頼性が最初から必要
そのため、モデル、業務コンテキスト、実行環境、統制をひとつの開発体験に寄せていく

ここで重要なのは、Microsoft が「強いモデルを出しました」で終わっていないところです。

むしろ、次のようなスタックとして見ると理解しやすいです。

層	主な発表	何を担うか
モデル層	MAI-Thinking-1, MAI-Image-2.5, MAI-Code-1-Flash など	推論、画像生成、コード生成など
コンテキスト層	Microsoft IQ, Work IQ, Fabric IQ, Web IQ, Foundry IQ	業務文脈、構造化データ、Web、複数ソースの検索をエージェントへ渡す
実行・配布層	Foundry Agent Service, Toolboxes, Voice Live, Teams/M365 Copilot 連携	エージェントを作り、動かし、利用者の場所へ届ける
統制層	Agent 365, Entra, Defender, Purview, ASSERT, ACS	権限、監査、安全性、運用管理を担う

つまり、今回の発表は「AIモデルの追加」ではなく、業務エージェントを作って運用するための部品が一気に見えてきたものとして読むとよさそうです。

MAI-Thinking-1：Microsoft AI 初の reasoning model

今回の目玉のひとつが、Microsoft AI Superintelligence Team による新しい MAI ファミリーです。

公式発表では、7つの in-house model が紹介され、その中心として MAI-Thinking-1 が挙げられています。これは Microsoft AI 初の reasoning model と説明されています。

特徴としては、次の点が紹介されています。

35B active parameter のミッドサイズモデル
256K context window
複雑な multi-step instructions、long-context reasoning、code generation を意識
エンタープライズグレードの、商用ライセンスされたデータで学習したと説明

提供チャネルとしては Microsoft Foundry 経由での提供が説明されています。preview / GA などの提供形態は変わりやすいので、実際に試す場合は最新の公式ドキュメントやモデルカタログを確認するのがよさそうです。

ここで面白いのは、Microsoft が最上位の巨大モデル競争だけを狙っているというより、効率やコスト、業務利用時の扱いやすさも含めたモデル選択肢を増やしているように見える点です。

また、MAI-Code-1-Flash は GitHub 向けに調整された inference efficient coding model として、Copilot と VS Code で利用可能とされています。開発者体験の中に Microsoft 独自モデルが入ってくる流れも見えてきます。

7モデルの内訳としては、記事内で詳しく扱う MAI-Thinking-1、MAI-Code-1-Flash、MAI-Image-2.5 に加えて、MAI-Image-2.5 flash variant、43言語対応の音声認識モデル MAI-Transcribe-1.5、15言語対応として説明されている MAI-Voice-2 とその flash variant も含まれます。

MAI-Image-2.5：画像生成も Microsoft 独自モデルへ

画像生成系では、MAI-Image-2.5 と flash variant が発表されています。

公式ブログでは、Microsoft の MAI 画像モデルとして、text-to-image と image-to-image の両方に対応するモデルとして紹介されています。PowerPoint ではすでに動いており、OneDrive への展開や Foundry での提供も説明されています。

外部評価としては、Arena AI leaderboard で text-to-image が #3、image-to-image が #2 と紹介されています。もちろん leaderboard は評価軸のひとつにすぎませんが、最新の MAI 画像モデルの競争力を示す材料として見てよさそうです。

この点も、単に「画像生成モデルが増えた」というより、Microsoft 365 の作業体験と Foundry の開発体験の両方にモデルを配置している点がポイントだと思います。

業務アプリケーション視点では、画像生成が単独アプリではなく、ドキュメント、プレゼン、ファイル管理、業務エージェントの中に自然に入ってくる可能性があります。

Microsoft IQ：エージェントに文脈を渡す層

個人的に一番重要だと思ったのは、Microsoft IQ まわりです。

LLM を業務で使うと、すぐに「社内の文脈をどう渡すか」という問題にぶつかります。会議、メール、ファイル、組織、業務データ、Web の情報をどう取り込み、権限を守りながらエージェントに使わせるか、という話です。

ここでいう Microsoft IQ は、Work IQ、Fabric IQ、Foundry IQ、Web IQ などを含む、エージェント向けの知識・文脈レイヤーの総称として理解するとよさそうです。

Microsoft Build 2026 関連の発表を見ると、この文脈レイヤーは次のように整理できそうです。

Work IQ: Microsoft 365 や組織システム、外部ソースにまたがる働き方の文脈
Fabric IQ: 構造化された業務データに対する semantic foundation
Foundry IQ: Work IQ、Fabric IQ、Azure SQL、File Search、MCP sources などを束ねる SLA-backed retrieval endpoint
Web IQ: model-agnostic かつ MCP-native な Web grounding/search stack

Work IQ については、2026年6月16日に API endpoints が GA 予定とされています。A2A、redesigned remote MCP server、REST API が含まれ、Microsoft 365 Copilot ライセンスとは独立した consumption basis の利用も説明されています。

ここで少し注意したいのは、Work IQ / Fabric IQ / Web IQ / Foundry IQ は完全な横並びというより、Foundry IQ が Work IQ や Fabric IQ を含む複数の知識ソースをまとめて、エージェントから使いやすい retrieval endpoint として扱う位置づけに近い点です。記事冒頭では理解しやすさのために同じ「コンテキスト層」に置きましたが、実装時には Foundry IQ を上位の検索・知識プレーンとして見ると整理しやすそうです。

ここは開発者にとって大きいです。

これまでは、社内データを使うAIを作ろうとすると、RAG のためにチャンク分割、インデックス、検索、権限、監査などを自前で組む必要がありました。もちろん今後も自前実装が必要なケースはありますが、Microsoft 365 や Fabric を使っている組織では、Microsoft IQ 系の機能が「まず検討する土台」になっていく可能性があります。

Foundry：エージェントを作り、動かし、届ける場所

Microsoft Foundry 側の発表も、エージェント基盤として見ると重要です。

Build 2026 の Foundry 関連発表では、次のような機能が紹介されています。

Foundry Agent Service
Toolboxes in Foundry
Voice Live
Memory
Teams / Microsoft 365 Copilot への公開
Foundry IQ による知識・grounding

特に、Foundry Agent Service は、クラウド側でエージェントをホストするための基盤として説明されています。公式発表では、起動の速さ、セッションごとに分離された sandbox、isolated execution、persistent memory、elastic scale といった特徴が挙げられています。

関連して、hosted agents は 2026年7月上旬までに GA になる見込みと説明されています。Build 2026 時点の記事としては、かなり近いマイルストーンなので、実際に採用を検討する場合は GA 状況を追っておきたいところです。

Memory についても、単に「記憶機能がある」というより、次の3種類が整理されています。

Procedural memory: タスクの進め方や手順の記憶。Build 2026 で新しく出た要素として重要
User memory: 利用者ごとの嗜好や文脈
Session memory: セッション内の会話や作業文脈

また、Voice Live は prompt agents 向けには GA として紹介されており、speech recognition、text-to-speech、turn detection、interruption handling、avatars などをひとつの API にまとめるものです。一方で、hosted agents と Voice Live の統合は public preview とされているため、音声エージェントを作る場合は利用形態ごとのステータスを分けて見る必要があります。

さらに、Foundry agent を Teams や Microsoft 365 Copilot に公開する流れも示されています。これは「エージェントを作ったが、利用者にどう届けるか」という問題に対する Microsoft らしい答えです。

利用者が毎日いる場所が Teams や Microsoft 365 Copilot なら、そこへ出せることはかなり大きいです。

Agent 365：作ったあとの管理が主役になる

エージェントは作るだけでは終わりません。

むしろ、社内で増えていくと次の問題が出ます。

どのエージェントが存在しているのか
誰が作ったのか
どのデータにアクセスできるのか
どんな操作をしたのか
問題が起きたときに止められるのか
監査やポリシーに乗せられるのか

Agent 365 自体は、Build 2026 より前に GA している、エージェントを観測、統制、保護するための control plane です。Build 2026 ではその拡張として、ローカルエージェントも含めた discovery や管理の方向性が示されています。

そのため、ここは「Build 2026 で Agent 365 が新登場した」というより、GA 済みの Agent 365 が、ローカルや複数フレームワークのエージェントまで管理対象を広げていると見るほうが正確です。Entra、Defender、Purview といった既存の統制基盤を、エージェント管理にも拡張していく流れです。

加えて、open-source trust stack として ASSERT と Agent Control Specification も紹介されています。

ASSERT: Adaptive Spec-driven Scoring for Evaluation and Regression Testing。自然言語の要件やポリシーを、AIモデルやエージェントに対する実行可能な評価へ変換する open-source framework
Agent Control Specification (ACS): agent loop のどこでどのように control を適用するかを標準化する、portable runtime control standard

このあたりを見ると、Microsoft は「エージェントを大量に作れるようにする」だけでなく、大量に作られたエージェントを企業としてどう管理するかをかなり重視しているように見えます。

開発者として見ておきたいポイント

今回の発表を、開発者視点でざっくり置き換えるとこうなります。

1. モデル選定は「性能」だけではなくなる

MAI-Thinking-1 のような reasoning model、MAI-Code-1-Flash のような coding model、外部モデル、OpenAI 系モデルなど、選択肢は増えています。

これからは「一番強いモデルはどれか」だけではなく、次のような観点がより重要になりそうです。

タスクに合うか
コストは見合うか
レイテンシは許容できるか
データ境界やライセンス要件に合うか
Foundry や Copilot など既存基盤とどうつながるか

2. RAG を毎回自作する前に、知識層を確認する

社内文書検索や業務データ連携を作るとき、これまでは RAG パイプラインを自前で設計することが多かったと思います。

ただ、Microsoft 365、SharePoint、Teams、Fabric、Azure SQL、既存の検索基盤などにデータがある組織では、Work IQ / Fabric IQ / Web IQ を直接見るだけでなく、それらを束ねる Foundry IQ を使えるかを先に確認する価値が出てきそうです。

特に権限、監査、ポリシーまで含めると、単純なベクトル検索だけでは足りません。ここをプラットフォーム側がどこまで面倒を見るのかは、今後の実装判断に効いてきそうです。

3. エージェントは「作る」より「運用する」が難しい

PoC でエージェントを作るのは比較的簡単になりました。

一方で、本番運用では次のような論点が出ます。

ログと監査
権限とデータ境界
ガードレール
評価と回帰テスト
コスト管理
利用者への配布
既存業務ツールとの接続

Foundry、Agent 365、ASSERT、Agent Control Specification (ACS) の発表は、この「作ったあとの現実」を意識したものとして見ると理解しやすいです。

まとめ

Microsoft Build 2026 の AI 発表は、単に「Microsoft AI が新モデルを出した」という話ではなく、もう少し大きく見ると次のような流れだと感じました。

Microsoft 独自の MAI モデル群が増えてきた
Microsoft IQ によって、エージェントに業務コンテキストを渡す層が整理され、Foundry IQ が複数の知識ソースを束ねる役割を持ってきた
Foundry が、エージェントを作る・動かす・届ける場所として強化されている
Agent 365 や trust stack によって、エージェントの統制が前面に出てきた
開発者にとっては、モデル選定、知識層、運用設計をセットで考える必要が増えそう

個人的には、今回の発表で一番大事なのは「Microsoft も reasoning model を出した」ことだけではなく、エージェントを企業システムとして扱うための足場を作りにきていることだと思います。

このあたりはまだ preview の機能も多いですが、Microsoft 365、Azure、GitHub、Windows を使う開発者にとっては、今後の設計判断に影響してくるテーマになりそうです。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up