Microsoft Build 2025 キーノートまとめ
今年も始まりました。Microsoft Build 2025、シアトル会場からお送りしてます。今回もキーノートのセッションを日本語でまとめました。
はじめに
Satya NadellaはBuildの開幕挨拶で、現在を新たなプラットフォームシフト（open agentic web）中盤の「スケールが一気に起きる局面」と位置づけ、縦割りスタックの少数アプリからオープンでスケーラブルなエージェント基盤へ移行しつつあると述べ、開発者がスタックのあらゆる層でアプリとエージェントを構築し全ての人と組織をエンパワーできる機会を拡大するのが本カンファレンスの狙いだと強調したうえで、「物語は常にツールから始まる」とし、ソフトウェアエンジニアリングはアイデアを形にし複雑さを制御するための適切なツールを磨き続ける営みであり、Microsoftはそのツール群を絶えず進化させていると語たりました。
開発者ツール
まずはすべての原点である開発ツールについてですが、ソフトウェアエンジニアリングは常にアイデアを形にし複雑さを制御するための最適なツールが要となり、私たちはそれらを継続的に進化させており、その成果としてVisual Studioファミリーは現在1億5000万ユーザーを超え、GitHub Copilotは1500万人以上の開発者に利用されるなど採用と普及が驚異的な勢いで拡大しているところです。
Build ではまず Visual Studio の大規模アップデートを展開し、.NET 10 対応、デザイン時ライブプレビュー、Git ツールの改良、クロスプラットフォーム向け新デバッガーなどを追加したうえで安定版を毎月リリースする体制へ移行し、さらに VS Code は 100 回目のリリースを達成しました。マルチウィンドウ強化やエディター内ステージ表示を容易にし、GitHub は開発者のホームとして GitHub Enterprise がエンタープライズ市場で高い勢いを示す中、信頼性・セキュリティ・コンプライアンス・監査性・データレジデンシーをより重視した取り組みを強化していく方針です。
IT ツールからデプロイ先インフラまで信頼を軸に据える中、オープンソースを中核とする GitHub は次の大きな一歩として VS Code 内で進化してきた GitHub Copilot を本日からオープンソース化し、AI を活用したコーディング機能を世界で最も愛される開発ツールのコアレポジトリに直接統合することで、開発者が求める信頼性と透明性を一段と高めます。
GitHub Copilot は引き続き進化を続け、コード補完からチャット、マルチファイル編集、エージェントへと発展してきた流れを踏まえ、開発者は質問を投げれば AI が回答し、タスクをエージェントに割り当てて実行させたり AI と協働しながらプロジェクトを完了させたりと自由に組み合わせられるようになり、
さらにエージェントモードでは Java 8→20／21 や .NET 6→9 へのフレームワーク更新、オンプレミス アプリのクラウド移行まで自動で計画を立て依存関係を整理し、修正案を提示しつつ学習してプロセス全体をシームレスに最適化します。
次に紹介されたのは Site Reliability Engineering 向けの自律型 SRE エージェントで、深夜に PagerDuty で呼び出されるメモリリークなどのライブサイト障害を自動でトリアージし根本原因を特定して緩和策を実行したうえで修復項目を含むインシデントレポートを GitHub Issue として記録し、その修復タスクを GitHub Copilot に割り当てられます。
GitHub に組み込まれたフルコーディングエージェントは、Copilot をペアプログラマーから真の同僚（peer programmer）へと進化させ、Issue を割り当てればバグ修正・新機能開発・コード保守などを自律的に完了できるようになり、本日から皆さまにご利用いただけます。
サティア氏は「もはやバグを報告するだけの時代ではなく、自ら修正を任されることこそエンパワーメントだ」と述べ、実際に手元の GitHub 画面で多数の Issue を確認したうえで、最初の課題として「コミュニティページにユーザーグループサイズのフィルターを追加する」Issue を開いて内容を詳しく確認しました。
サティア氏は「ユーザーグループサイズのフィルター追加」という Issue を開き、必要な範囲やキャッシュ構成をざっと確認したうえでそのタスクを新しい相棒である Copilot に割り当てると、
Copilot が即座に認識してブランチを作成し PR を生成し、進行状況を示す“目”の絵文字まで表示して作業を継続する様子を示し、まるでメール振り分けを自動化する感覚で Issue を処理できることを楽しげにデモンストレーションしました。
Copilot はタスクを受け取ると専用ブランチを作成し、GitHub Actions で必要な計算リソース（仮想マシン）を自動生成してドラフト PR をセッションログにコミットし、開発者はそのログで進捗を随時確認できるうえ、エージェントは指定された MCP サーバーのみを利用してセキュリティ要件を順守しながら動作し、さらに他のエージェントにコードレビューを依頼して CI/CD やマージ前に人と連携できる仕組みを備え、SRE エージェントなどを含むオープンかつセキュアなエコシステムをパートナーにも提供できるよう、これらの内部機能を公開していきます。
OpenAI社 Sam Altman氏との対談
コードレビューを含む多数のエージェントを開発者が構築できるよう内部機能を公開しつつ、個々の開発者とIT部門が十分に制御できるよう配慮しており、エージェントのシステム化の文脈で金曜日にリリースされた OpenAI の Codex エージェントに大いに期待していることから、Satya Nadella はSam Altman 氏をMicrosoft Build にバーチャル招待し歓迎しました。
Sam Altman 氏は、CLI から最新のコーディングエージェントへ至る開発形態の進化を振り返り、開発者が仮想の同僚となるエージェントにバグ修正・新機能実装・コード解説など複数タスクを並行委任し、数日単位の大規模アイデアまで任せられる「真のエージェンティックなコーディング体験」が遂に実現したことはプログラミング史上最大級の変革であり、GitHub リポジトリや実行環境と深く統合することで高度な成果を得られ、今後さらに進化すると述べました。
Satya 氏は、開発者がエージェントや同僚と協働しながらフローを維持し、開発ライフサイクル全体を加速できる点を強調したうえで、OpenAI のモデルロードマップについて質問し、Sam Altman 氏は、既に高性能なモデルが今後さらに賢くなるだけでなく、選択肢を意識せず自動で最適な動作を行うほどシンプルかつ信頼性が高くなり、マルチモーダル対応やツール統合も進んで「It just works」と呼べる使い勝手に近づくなど、想像以上のスピードで進歩すると述べました。
Satya 氏は、ChatGPT をはじめとする状態管理型エージェントアプリのスケールや Codex の事例を引き合いに、開発者がモデルを活用しマルチエージェントオーケストレーションまで実装できるようになることが Build の主題であると説明し、プロダクション規模のステートフルなエージェントアプリを構築する際の助言を求めました。
その問いに対しSam Altman 氏は、最大の課題はモデル性能の進化スピードに対応することであり、2年前・1年前・現在・そして1〜2年後で可能なことが劇的に変わるため、近未来を見据えて新しいツールとワークフローを積極的に取り入れ、技術シフトの初期段階から深く関与する姿勢が大きな成果につながると助言しました。
Satya 氏は、開発者が最新モデルのアップデートを継続的に取り込みつつ同じ速度でアプリを進化させる「アプリケーションサーバー」の重要性を説明し、Sam Altman 氏は Codex の社内利用で早期導入者がワークフローを大幅に変革し生産性を飛躍的に向上させた実例を紹介し、両者はパートナーシップへの感謝を述べて対談を締めくくりました。
Satya 氏は、開発者にとって前例のない好機が訪れており、重要なのは特定のツールやエージェント、フォームファクターそのものではなく、それらが結集することで個々のエンジニアやチームが自らの技術と創造性を存分に発揮できるようになる点だと強調しました。
アプリとエージェント
Satya 氏は次のテーマとしてスタックを上位に進め、Microsoft 365 が提供するプラットフォーム機会について語り始めました。
Microsoft 365 Copilot
Satya 氏は、Microsoft 365 Copilot の最新アップデートが一般提供（GA）となったことに強い興奮を示し、これは同サービス史上最大の更新であると述べました。
Satya 氏は、今回の Microsoft 365 Copilot のアップデートが Teams 以来最大規模であり、Chat・Search・Notebooks・Create・Agents を直感的なひとつの枠組みに統合した「AI のための UI」だと説明しました。Chat は Web データと社内データの双方に基づいて応答し、Search は Confluence、Google Drive、JIRA、ServiceNow などすべてのアプリを横断して機能します。Notebooks ではチャット、ページ、ドキュメント、メールなど異種データをコレクション化し、音声レビューやポッドキャストも生成でき、Create は PowerPoint を説明動画に変換したり画像を生成したりします。さらに Researcher エージェントは Web と企業データを横断して深い連想推論を行い、Analyst エージェントは複数の Excel ファイルから洞察・予測・可視化を自動生成し、これらのエージェントが「専門知識を指先に置く」という同氏の長年のビジョンを実現していると強調しました。
Teams はこれらすべての機能をマルチプレイヤー化し、開発したエージェントを Teams や Copilot 上に表示して @メンションだけで質問・アクション指示・ワークフロー開始が可能になり、Teams AI Library によりマルチプレイヤーエージェントの構築はこれまでになく容易で、MCP 対応に加えてたった 1 行のコードで 2A を有効化でき、さらに Azure Search でエピソード記憶やセマンティック記憶を追加できる新しいリトリーバルシステムも後述されると説明しました。
開発者は作成したエージェントを Agent Store に公開できるようになり、Copilot と Teams の双方で発見・配布され、数億規模のユーザーに一挙にリーチして新たなビジネス機会を開放できます。
Satya 氏は、過去 1 年間であらゆる業界のマイクロソフトパートナーが Copilot と Teams に接続するエージェントを多数構築したと述べ、具体例として、Workday エージェントが学習項目・承認・ワークフローを要約して利用者に注意を促す機能、ServiceNow エージェントがインシデントの解決指標をリアルタイムで提示し結果を即座に PowerPoint 資料へまとめる機能、そして金融プロフェッショナル向けエージェントが取引所提供の財務データを Excel や PowerPoint 上で発見・分析・共有できる機能を紹介しました。
Copilot Studio
Copilot Studio を使えば開発者自身がエージェントを作成でき、同スタジオには多数の新機能が追加されており、最近ではフルコード エージェントを統合したほか、MCP エージェント フローによって大規模言語モデル（LLM）と決定論的ワークフローを自在に組み合わせられるようになっています。
本日から Copilot Studio ではマルチエージェントオーケストレーション機能により、たとえば新入社員オンボーディングのように施設・財務・法務など各分野のエージェントを連携させる複雑なマルチエージェント ワークフローを簡単に構築でき、全体の処理速度が向上して関係者すべてにとって利便性が高まります。
Copilot Tuning
Satya 氏は、過去 1 年で Copilot と Teams に接続するエージェントが 100 万件以上構築されたと述べたうえで、企業データ・ワークフロー・文体に合わせてモデルをファインチューニングできる新機能 Copilot Tuning を発表しました。同機能では、少量の社内リファレンスを用意して学習ジョブを開始するだけで、Copilot が各社固有の語調や用語を習得し、将来的には組織特有の専門知識まで理解できるようになります。チューニング済みモデルは元データの権限を継承し、指定グループへ安全に配布可能です。例えば法律事務所なら過去の訴訟資料を踏まえて文書を生成し、業界別にサービスを提供するコンサルティング企業なら各業種向けに最適化されたモデルを用意できるため、社内外の製品・サービスに組織の専門性を拡大反映できると強調しました。
Miti 氏のデモでは、開発者が Microsoft 365 Copilot アプリ、Copilot Studio、そして Copilot Tuning を組み合わせて生産性ソリューションを容易にスケールできる様子が紹介されました。
まず新しい M365 Copilot アプリでは、Researcher エージェントが GitHub バックログと Web データを統合推論し、パフォーマンス課題の分析と次のタスク優先度付けを対話形式で支援する様子を実演しました。
Visual Studio の Agents SDK を用いることで、数ステップで GitHub 連携コネクターを生成し、Issue を Microsoft Graph にインデックスして Copilot が参照できるようになる過程も示されました。
続いて Copilot Studio では、メールで届く RFP に自動応答するエージェントを低コードで構築し、Teams チャネル上に提案書を投稿させるデモを実施しました。
設定画面で目的・指示を入力し、Dynamics MCP サーバーや DocuSign、SAP など外部 MCP サーバーをワンクリックで接続し、
さらにマルチエージェント オーケストレーションを用いてコンプライアンスチェック専用エージェントと連携させることで、複雑なワークフローを自動化できることを示しました。
最後に Copilot Tuning を用いて、契約書作成専用モデルをローコードでファインチューニングする手順を紹介しました。
SharePoint 上の契約データベースを知識ソースとして指定し、契約チームと購買チームにアクセス権を限定したうえでデータラベリングとトレーニングを行い、完成したモデルを M365 Copilot アプリから「契約書ビルダー」エージェントとして公開し、実際に自社の文体・条項・構成に沿ったドラフト契約書を自動生成するところまでを披露しました。
Miti 氏は、これらの機能を活用することで開発者自身のアウトプットを大幅に拡張し、ビジネス現場の担当者が AI を活用して業務プロセスを再構築できると強調し、デモを Satya 氏へ引き継ぎました。
デモのまとめとしてSatya 氏は、Copilot Studio が推論モデルや Copilot Tuning、決定論的ワークフローにアクセスできることで、あらゆる業務アプリケーションを MCP サーバーとして扱い、マルチエージェント フレームワークが役割やビジネスプロセス単位でワークフローを自律的に編成できるようになり、SaaS と生産性ソフトが一体化した次世代のオートメーションを開発者が実現できる「ゲームチェンジャー」だと強調しました。
Azure AI Foundry
Copilot と Copilot Studio の下層にあるすべての機能を開発者向けの第一級プラットフォームとして公開し、モデルが数か月ごとに進化していく時代に対応できる「マルチモーダルかつマルチエージェントのステートフルアプリ」を誰もが構築できるようにする方針を示しました。従来の単純なリクエスト／レスポンス API ではなく、評価基盤・オーケストレーション層・RAG などモデル周辺の仕組み全体が重要になるため、それらを一体で提供する Azure AI Foundry を「インテリジェンスの生産ライン」と位置付け、AI 時代の完全なアプリプラットフォームとして開発者に提供することが動機であると説明しました。
Satya 氏によれば、Azure AI Foundry は既に BMW、Carvana、Coca-Cola、NASDAQ などを含む 7 万以上の組織や Gainsight など多数の ISV に採用されており、企業は PoC 段階から全社規模の導入へ移行して AI の ROI を本格的に引き出し始めているそうです。過去 3 か月で処理したトークンは 100 兆を超え、前年比 5 倍に達しており、同氏が最近日本へ訪日した際には、Azure AI Foundry を用いて聴覚情報処理障害（APD）のある人々が音声を理解しやすくするアプリが開発されている事例を目にし、大きな感銘を受けたと述べました。
株式会社アイシンの事例
私は2歳の時に耳が聞こえなくなりました。わたしは全く聞こえなかったので、この世の中には声というものがあると教えられました。
加藤さんとの出会いですが、加藤さんがワイワイシステムを使い始めて感動して、我々に手紙を書いてくれました。
その手紙の内容は、生活が変わり始めている（という内容でした）
一番困ることは、会話ができないことです。
日本の中でもいろんな方言がありますので、いろんな地域性の喋り方、特有の言い回しっていうものに対応、自分の声で話して、それを文字にして伝えたいという要望が結構たくさん出てきたというところがええありまして。まあ、エンジンの開発を行うことにしました。ええ、私たちはAzure AI Foundryをたくさん使わせていただいてます。主な使いかたとしては、ええ発言を修正するためのロジックを検証したり、あと翻訳をええ適切な翻訳になるための検証するための検証ツールとして使っています。私たちは、Azure Speech Serviceをリアルタイムの文字起こしに共に使っています。それ以外にも、ええ。当社の方の声の学習をして、その方専用のモデルを作るカスタムスピーチモデルというものに使っています。おかげさまで私たちのワイワイシステムがアプリケーションは日本国内で145万ダウンロードとか致します。
私は子供の声が話かわからなかった。それが分かる会社でも加藤さん今までわからなかった。加藤さん何分かる？私分かるから、そして、教えてあげられる。
私はただのエンジニアでした。ですが、ええアプリを出したことによって、ええ、本当にユーザーさんの声が僕を支えてくれて、本当にそういう感覚です。それが自分のこうエネルギーというか、モチベーションにつながっていると思います。
Satya 氏は、開発事例を共有した加藤様やアイシン様をはじめとする開発者に深い謝意を示し、その取り組みが非常に刺激的であると称賛しました。
Azure AI Foundry のモデル
Foundry では既に応答モデル・推論モデル・タスク特化モデル・マルチモーダルモデルなど 1,900 種類以上を選択でき、OpenAI を含む最新モデルも網羅していると述べ、モデル選択の幅をさらに拡大すると表明しました。
Satya 氏は、今年だけで OpenAI のモデル 15 種を Azure 上に同時出荷（SIM ship）し、新モデル公開当日に利用可能にしており、来週には Sora も追加されると述べました。開発者が重視するコスト・信頼性・レイテンシ・品質の面で Azure OpenAI は最上級のサービスを提供し、バッチ処理やスピルオーバーによるコスト管理、業界最高水準のセキュリティ／コンプライアンス／セーフティをエンタープライズ保証として備えています。
しかしモデル選択とルーティングは依然手間がかかるため、Foundry でクエリを最適なモデルへ迅速に振り分けられる仕組みを導入し、開発者の負担を軽減すると説明しました。 新たに導入される Model Router は、要求内容に最適な OpenAI モデルを自動で選択するため、開発者が手動でモデルを切り替える必要がなくなります。この仕組みにより、アプリを単一モデルに固定する従来のアプローチから、柔軟に複数モデルを活用できるマルチモデル体制へと移行できます。
xAI社のGrokをAzureで公開
これによりアプリやエージェントを単一モデルに縛り付ける時代から真のマルチモデル活用へ移行できるため、Satya 氏は本日、xAI の Grok が Azure に提供開始されると発表し、Grok 3 が推論・ディープサーチ・応答を単一モデルで実現する点を強調しつつ、週末に Elon 氏と直接対話できたことを語りました。
Elon Musk氏との対談
まず、Satya 氏は Build への参加に感謝を述べつつ、Elon 氏がマイクロソフトでインターンとしてキャリアを始め Windows 開発や PC ゲームに携わっていた経歴に触れ、その初期の体験について語ってほしいと依頼しました。これに対し Elon 氏は、Windows 以前に MS-DOS 時代の IBM PC（当初 128 KB、後に 256 KB へ拡張）でゲームをプログラミングしていたことや、Windows 3.1 の時代にも開発を続けていた思い出を振り返りました。
Elon 氏は、近日リリース予定の Grok 3.5 について、物理学の第一原理を用いて最小限の誤差で真理に近づく推論モデルであると説明しました。
まず、正しい結論を導くために公理的要素へ問題を分解し、そこから推論を積み上げ、最終的にエネルギー保存則や運動量保存則といった物理学の基本法則に照らして検証する手法を採用していると述べました。
こうしたアプローチにより、完全に誤りをなくすことは難しくても、誤差を時間とともに最小化し続けることが AI セーフティ上極めて重要であり、「正直こそ最良の方策」という格言が安全性の核心であると強調しています。
さらに、開発者コミュニティからのフィードバックを積極的に受け入れ、誤りを迅速に修正しモデルを改善していく姿勢を示し、「どんな要望や指摘でも遠慮なく伝えてほしい」と呼びかけました。
Satya 氏は、Grok 3.5 の公開を機に開発者からのフィードバックを積極的に取り入れながら導入を加速させたいと述べ、Elon 氏に感謝の意を表するとともに「開発者の皆さまからの声を心待ちにしている」と強調しました。これに対し Elon 氏は「要望を知らせていただければ必ず実現する」と応え、協力姿勢を示し、Elon 氏と再度対話する機会を得たことに触れ、Grok 3.5 に関する取り組みやロードマップについて議論しつつ、まずは API へのフィードバックを開発者から集めて連携を深めたいと述べました。
Azure AI Foundry のモデル
Satya 氏は、複数モデルを扱う際に求められる新機能として Foundry の一括スループットプロビジョニングについて話し、開発者は一度確保したスループットを Grok を含む複数モデル間で共有できるため、モデル選択とリソース管理が一変すると説明しました。さらに、EU 域内ソブリンデプロイメントに対応した Mistral、そして Mark 氏がLlama Herdを近日Azure へ公開予定のMistralやLlama など、OSS 系モデルも同じ枠で提供されることを紹介しました。
また、 Black Forest Labs をはじめ多数のオープンソースモデルが同一スループットの背後で利用でき、API 仕様も共通化されているためモデル切替が容易になり、開発者は自由に組み合わせてアプリを構築できると強調し、Hugging Face とのパートナーシップを拡大し、Foundry から 11,000 以上の最先端およびオープンソースモデルにアクセスできるようになると発表しました。
エージェント開発においてモデルは要素の一部に過ぎず、リアルタイム Web と企業内ナレッジグラフの両方へ高度にアクセスできる洗練されたリトリーバルシステムが不可欠であり、単なるベクトル検索と埋め込みだけでは不十分で、複雑なクエリを分解・並列実行し統合結果を返せるエージェント専用のデータベース兼クエリエンジン――すなわちユーザー意図を理解する最新のナレッジリトリーバルスタック――が必要だと述べました。
リトリーバル層の次に位置づけられる オーケストレーション層 の重要性を説き、Foundry Agent Service を用いればポータル上で数行の宣言的コードだけで複雑なワークフローを担うエージェントを構築でき、マルチエージェントの協調実行をサポートしつつ Semantic Kernel や Autogen ともシームレスに統合され、実行環境としてマネージドサービスのように利用できると説明しました。すでに 1 万社以上が採用しており、本日 一般提供（GA） となったことを発表しました。
Foundry をコンテナーアプリや Azure Functions に容易に接続し、クラウドでも ARC を用いたハイブリッド環境でも、さらにはエッジへも OSS モデルを AKS にデプロイできるようにすることで、あらゆるエージェンティック シナリオで最適なコストパフォーマンスを実現できると述べました。
Foundry と Copilot Studio の連携をさらに強化し、開発者が Foundry でファインチューニングまたはポストトレーニングしたモデルをそのまま Copilot Studio に取り込んでワークフロー自動化やエージェント構築に即利用できるようになったと説明しました。
Foundry と Copilot Studio 連携の好例として Stanford Medicine の事例を紹介しました。同院は複数のエージェントをオーケストレーションし、患者履歴・放射線画像・PubMed／臨床試験データなど多岐にわたる情報源を一元化し、がん治療で最重要となる腫瘍ボード会議を AI で支援する仕組みを実装しており、その革新性を示すビデオを紹介しました。
Stanford Medicineの事例
Stanford Medicine では、がん治療の要である腫瘍ボード会議を対象に、Azure AI Foundry 上で複数エージェントを連携させる Healthcare Agent Orchestrator を構築し、患者履歴・投薬・検査結果・放射線画像・医学文献・臨床試験など断片化した情報を統合し、年間 4,000 回開催される会議を AI で効率化しています。
オーケストレーション層が各エージェントを調停して総合レポートを作成し、Word で要約や PowerPoint スライドを自動生成するほか、わずか数行のコードで Teams へ展開して医師が直接対話できるようにしており、機械的作業を削減して臨床判断に集中できる環境を実現しています。
このプラットフォームは他院でも再利用可能な形で提供され、地域病院でもアカデミックセンターと同等の能力を利用できるようにすることで、より迅速かつ情報に基づいた治療決定を可能にし、世界中の医師を支援する変革的な取り組みとなっています。
Healthcare agent orchestratorの発表
Satya 氏は、Stanford Medicine が活用した Healthcare Agent Orchestrator が Foundry で一般利用可能になったと発表し、複数モデルとマルチエージェントを Foundry・Copilot・Teams で統合し現場ワークフローを自律的に編成する実例が示されたことで、単一アプリの域を超え全社規模へスケールできる段階に到達したと強調しました。
Foundryにおける監視機能
エンタープライズ規模へスケールする際に欠かせない要素としてオブザーバビリティを挙げ、Foundry に新たな監視機能を追加し、AI の本番運用においてインパクト・品質・安全性・コストを一元的に可視化・管理できるようにしたと説明しました。
Entra Agent ID
また将来は、あらゆる組織で人とエージェントが協働する体制が当たり前になると述べ、Entra ID Agents の導入により、エージェントが独自の ID・権限・ポリシー・アクセス制御を持ち、Foundry や Copilot Studio で作成したエージェントが自動的に Entra のエージェントディレクトリに登録されるようになったと説明しました。
ServiceNow と Workday と連携し、Entra を通じてそれぞれのエージェントを自動プロビジョニング・管理できるようにすると述べました。
また、データガバナンスの観点では Microsoft Purview が Foundry と統合され、開発者がエージェントを作成すると同時にエンドツーエンドのデータ保護が自動で適用されるため、安全性が一段と高まると説明しました。
さらにセキュリティ面では Microsoft Defender が Foundry と統合され、ウォレット悪用や認証情報窃取といった脅威からエージェントをエンドポイントと同等レベルで保護できるようになりました。これらの機能により、Foundry はまさに「エージェントファクトリー」として開発・運用・保護を一体的に提供する基盤となっています。
Azure AI Foundry と GitHub Copilot のデモ
デモ担当者は、チャット型旅行アプリ Vibe Travel に Azure AI Foundry と GitHub Copilot を組み合わせる開発フローを紹介しました。ユーザーが 8 か月後（南半球の夏季となる 2026年1月）にニュージーランドでスキー場を尋ねると、アプリが誤った前提で回答したため、適切な季節情報を与えて修正する必要が示されました。
Foundry のダッシュボードを開き、GPT-4o を用いる Vibe Travel エージェントのプロンプトに追加の知識を付与して回答をより確実にする手順を示しました。具体的には、参照用ファイルや Microsoft Fabric、TripAdvisor など外部サービスと接続する方法も選べますが、今回は最も手軽な Bing Search でのグラウンディング を追加するオプションを選択し、数クリックで設定を完了させました。
Bing Search でのグラウンディングに加え、オープンなフライト予約 API へのアクセス権を付与し、Vibe Travel エージェントを強化しました。これによりアプリは「南半球の夏季はスキー不可」という正しい回答を返すようになり、さらにユーザーの代理で航空券を予約するアクションまで実行できる自律型エージェントへ進化しました。
予約後にカレンダー登録やホテル手配、社内休暇申請といった追加アクションも容易に組み込めることを示しましたが、コードベースには引き続き改良の余地があると説明しました。
GitHub Copilot の新機能 Agent Mode を起動し、主要 LLM プロバイダーの中から最適なモデルを選択したうえで、Model Context Protocol（MCP）を通じてリポジトリに割り当てられた Issue 一覧を取得する操作を実演しました。これによりブラウザーを開かずとも GitHub MCP サーバー経由で状況を取得でき、開発者は Copilot を単なるコード補完ツールから実作業を支援するエージェントへと拡張できることを示しました。
リセットボタンを押すと警告なしにチャットが消える問題（Issue #1）の解決に取り組むため、GitHub Copilot Agent Mode に対して Issue の詳細取得と実装支援を依頼し、さらに上司から急遽受け取った画面デザインのスクリーンショットをコンテキストウィンドウに追加してプロンプトを送信しました。
Copilot は GitHub MCP サーバーを利用するための権限を求め、許可すると Issue の詳細を取得し、Agent Mode の新しいビジョン機能によって提示されたスケッチも理解したうえで、必要な変更点を分析しコード修正を自動で進め始めました。
デモ担当者は、事前に Copilot に割り当てておいた別の Issue を確認しました。Copilot はすでに実装方針とコード変更を含む PR を自動作成しており、 「View session」ボタンからセッションログを辿ることで、修正過程を詳細に追跡できる様子を紹介しました。
コード内容を確認した後、コメント欄にフィードバックを入力すれば Copilot が即座に対応を開始し、絵文字で進捗が表示されるため、二つの Issue を並行して効率良く処理できることを実感していました。
エディターに戻って Issue #1 の進捗を確認すると、Copilot Agent Mode が提案内容を検証したうえで関連ファイルを特定し、規定のコーディング規約とスタイルを遵守しつつ修正を完了していました。アプリ側でも上司の要望どおり UI 変更が反映され、ライブ環境で素早く動作を確認できました。結果として、わずか数分で 2 件の Issue を同時に解決するデモを実現した形です。
ついでに Satya 氏が先ほど Copilot に割り当てた「グループサイズフィルター追加」の Issue も確認し、Copilot がすでに変更に着手するプルリクエストを自動生成していることを示しました。PR にはフィルタープロパティの追加、Redis キャッシュの実装、テスト手順など具体的な修正内容が記載されており、エージェントが迅速に作業を進めている様子がわかります。
Copilot はグループサイズ フィルター用のプロパティ追加に加え、Redis キャッシュ処理とテスト手順まで実装しており、その変更を含むアプリをステージング環境へ自動デプロイしていました。デプロイ状況を確認し、エージェントが短時間でコード更新から環境反映まで完遂したことを示しました。
Satyaは複数のタスクを並行して処理できる状況を「ハードに並列作業している」と述べつつ、プラットフォームシフトを本格的にスケールさせるには “アプリサーバーの完全性” が不可欠であり、その構築が順調に進んでいる点に興奮を示しました。ここまででクラウド側の取り組みを一通り紹介したと締めくくりました。
Foundry Local
Satya 氏は、クラウドで構築したアプリサーバーの能力をエッジやクライアントにも拡張するため、本日 Foundry Local を発表しました。Foundry Local には高速ランタイム、ローカル推論モデル、Agents as a Service、そしてローカル開発用 CLI が含まれ、Windows と macOS の両方を完全サポートします。
開発者向けに Windows の重要性を再確認し、10 億を超えるユーザーとデバイスへ到達できる最もオープンかつ大規模なプラットフォームであると説明しました。Windows はクラウドでもローカルでも同一イメージで動作し、セキュリティ・信頼性・アプリ互換性を継続的に強化しており、過去 1 年間には Adobe や Zoom などがオンデバイス AI 機能を活用した優れた Windows アプリをリリースしていることを紹介しました。また Microsoft Store の AI Hub では、これら新機能を採用したアプリが続々と公開されていると述べました。
Windows AI Foundry
Windows を AI に最適なプラットフォームへと進化させる新施策として Windows AI Foundry を発表しました。同社が Copilot Plus PC の “Recall” や “Click to Do” など社内機能を開発する際に用いたランタイムと SDK を一般開発者向けに開放し、開発ライフサイクル全体を支援する基盤へ拡張するという位置づけです。
Windows AI Foundry では、モデルに加えて豊富なセマンティック API が提供され、ローカルデータをプライバシーを保持したままベクトルストアに埋め込み・インデックス化できるため、ハイブリッド RAG アプリケーションを構築し、検索時にローカルデータへも直接アクセスして高精度な回答を得られるようになります。
さらに、開発者が独自モデルを利用する場合でも Windows ML を通じて多様なシリコン上へ高性能な AI をデプロイでき、デバイスごとの細かな最適化を意識せずに済むため、実装負荷を大幅に軽減できます。
MCPのネイティブ対応
Satya 氏はエージェンティック Web 時代に合わせて Windows を刷新し、MCP（Model Context Protocol）のネイティブ対応 を発表しました。Windows にはファイルシステム、設定、アプリアクション、ウィンドウ操作など複数の 組み込み MCP サーバー が含まれ、さらに MCP レジストリ を標準搭載することで、セキュリティと性能を検証済みの MCP サーバーをクライアントが安全かつ容易に発見できる仕組みを提供し、ユーザーの制御性を保持したままエージェントと連携できるようにします。
MCP on Windows と GitHub Copilot のデモ
Divya氏はWindows上のVS CodeでGitHub CopilotとMCPを利用し、「①新しいLinuxディストリビューション（WSL）をセットアップし、②Node.jsでWebサイトを構築し、③FigmaのSigmaデザインを適用する」という一連の作業を、たった3文の指示だけで自動化できることを実演しました。
実演に先立ち、エージェントがMCP Serverへ接続するにはユーザーの明示的な許可が必要であるため、Windowsの設定でWSLとFigmaのMCP Serverを有効化し、他のアプリは既定で無効のままにしてユーザーが制御権を保持できる状態にしました。
この手順により、Copilot Agent Modeは安全な権限管理の下でWSL環境やFigmaデザインファイルへアクセスし、3文のプロンプトだけで環境構築からUI適用までを自動的に完了できることを示しました。
VS Code を開いた Divya 氏は GitHub Copilot の Agent Mode に対し、「WSL で最新の Fedora を検索してインストールし、その後 Node.js でシンプルな Web サイト プロジェクトを構築してほしい」という2文の指示を送信しました。
Copilot は MCP Server との安全な接続を確立し、ユーザー承認プロンプトを表示したため、Divya氏は許可を与えて処理を継続させました。
バックグラウンドでは利用可能なオンラインディストリビューションを検索し、最新バージョンである Fedora 42 を特定してインストールを開始しました。
セットアップ完了後、Divya氏は別デバイスでログを確認し、同一プロンプトから Copilot がマルチステップ要求をシームレスに分解・実行した手順を詳細に追跡できることを示しました。
Copilot はオンラインの WSL ディストリビューションを検索して Fedora 42 を選択し、DNF パッケージマネージャー経由で Node.js と npm を Fedora 内にインストールしたうえで、WSL と直接対話するコマンドも自動実行し、結果として簡易 Web サイト プロジェクトを構築しました。
Web サイトをさらにデザイン調整するため、Figma デスクトップ アプリで選択した「Penguin Pen Pots」という Sigma デザインを提示し、VS Code に戻って 3 つ目の指示文を準備し、GitHub Copilot に対して「選択した Figma デザインを取得してサイトに適用してほしい」と依頼するステップへ移行しました。
CopilotはMCPレジストリを検索して最適なサーバーとしてFigma MCPサーバーを特定し、安全な接続を確立する際にユーザー許可を求めたため、Divya氏は承認しました。
接続後、エージェントはFigmaからデザイン詳細を取得してプロジェクトに統合し、サイトのレイアウト・スタイル・コンテンツを選択した「Penguin Pen Pots」デザインに合わせて自動更新しました。
これら三文のやり取りだけで、Fedora 環境構築から Node.js サイト生成、Figma デザインの適用までを完了できたことを示し、MCP による安全な権限管理とエージェント主導のワークフローが開発生産性を大幅に向上させる例として紹介しました。最後に Divya 氏は「Secure、Agent-driven、Developer-first を実現する MCP on Windows の力」を強調し、プレゼンを Satya 氏へ引き継ぎました。
WSLのオープンソース化
Satya 氏は、10 年前に発表した “Bash on Ubuntu on Windows” が現在の WSL へ発展した経緯を振り返り、最初の GitHub Issue が「WSL をオープンソース化してほしい」という要望だったことを紹介しました。当時は Windows イメージと密結合で難しかったものの、WSL 2 以降のアーキテクチャ分離によりスタンドアロン化が進んだ結果、本日その最初の Issue を「Fixed」としてクローズできるとして、WSL を完全にオープンソース化すると発表しました。
Kevin Scott氏が語る「エージェント」の世界
Kevin Scott 氏は、今回で９回目となる Build 基調講演に CTO として登壇し、年１回この場で開発者と直接対話できることを大変嬉しく思うと述べました。内向的な性格ながらも、過去１年間にテクノロジー界で起こった数多くのエキサイティングな出来事、そして今後１年間で登場する多くの新しい技術を共有したいという思いから、この 15〜20 分間はその内向性を忘れるほど興奮していると語りました。自身の興奮の源泉は “agentic web” という、ここ数年マイクロソフトだけでなく業界全体が取り組んできたコンポーネント・プロトコル・サービスが結集して生まれつつある新しい潮流であり、しかもそれが オープンな形 で進行している点だと語りました。これは今後の方向性を踏まえると開発者コミュニティ全体が強く望むべき姿であり、同氏はその進展に大きな期待を寄せていると述べました。
「Open agentic web」を語るうえで、まず “エージェント” の定義を整理しました。マイクロソフトが目指すエージェントとは、人間がタスクを委任できる存在であり、その委任内容は年々複雑化していると説明しました。
この1年でエージェントそのものが爆発的に増加し、Microsoft・パートナー・コミュニティが構築する多様なエージェントがスタックの最上層に豊かなエコシステムを形成しつつあると説明しました。さらに、可視化できる範囲のエージェントでは日次アクティブユーザーが前年比で2倍以上に伸びており、利用頻度が加速度的に高まっていると述べました。また、ここ1年で登場した新しい reasoning models によりエージェントが極めて複雑なタスクを遂行できるようになっており、特にソフトウェアエンジニアリング領域で驚くべき成果が現れていると強調し、Build 期間中にさらに多くの事例を紹介すると予告しました。
エージェントの世界における、ラインタイムとは
Agentic Web スタックのエージェント層の上位に位置する runtime について説明し、過去1年でとくに reasoning layer が大きく進化したと述べました。
現在のモデルは実利用を上回る “能力オーバーハング” 状態にあり、今後12か月で性能向上とコスト低減がさらに加速するため、開発者は「いまは実現がぎりぎりに思える」高度な推論タスクを目標に掲げ、野心的に活用領域を拡大すべきだと呼びかけました。 さらに reasoning 以外にも基本的なソフトウェアエンジニアリング要素として エージェンティックなメモリーの本格実装が不可欠であり、現在は RAG や長大コンテキストで近似しているものの、エージェントが広範かつ高精度に記憶を想起し、問題解決やユーザーの好みを持続的に学習できる仕組みが必要だと指摘しました。
その解決策の一つとして、Microsoft はオープンソースの TypeAgent を公開しており、Build 会期中に詳細を紹介すると述べ、エージェントをトランザクション的な存在から持続的・個別化された協働パートナーへ進化させる重要性を強調し、Runtime 層の各コンポーネントは Azure Foundry に段階的に組み込まれ、今後さらに充実すると述べました。
エージェントの世界における、プロトコルとは？
エージェントがユーザーの代理でアクションを実行するには外部世界と接続するプロトコルが不可欠であり、MCP や H2A などのオープンで信頼性の高い相互運用プロトコルが、数億規模で利用されるエージェントと開発者が作成するエージェントをつなぐ基盤になると強調しました。
MCPへのサポート
Build で特に強調したいのは Microsoft が MCP (Model Context Protocol) に本格コミットする姿勢であり、ここ数か月で MCP が飛躍的に普及した理由は、HTTP のようにシンプルでペイロードに干渉しない設計ゆえに、オープンな Agentic Web に不可欠な相互運用レイヤーを担えるからだと説明しました。
Microsoft は Windows の MCP Registry や自社サービスを MCP 対応へ順次アップリフトしており、エージェント間およびエージェント↔サービス間通信の標準プロトコルとして採用しています。さらに、Anthropic と協力してエージェントの自己識別・権限制御などエンタープライズ課題を解決する拡張仕様を数か月内に進め、オープンコミュニティ全体を強力に支援すると述べました。
このレイヤーで最も重要なのは“どこでも使える標準プロトコル”の普及であり、個々の技術優劣を議論するよりも全員が上にスタックを積める共通土台を確立することが価値を生むと述べ、Microsoft はその標準を MCP と位置づけ普及を推進すると強調しました。
階層化の観点から、HTTP 上に HTML が乗る構造を引き合いに出し、既存の Web サイトや API を簡単にエージェンティック アプリ化できる新プロトコル NL Web を発表しました。
NL Web で公開されたエンドポイントはデフォルトで MCP Server として振る舞うため、MCP に対応した任意のエージェントからアクセス可能であり、Large Language Model の能力を活用して既存サービスやプロダクトを容易に拡張できます。NL Web を「Agentic Web のための HTML」と位置付け、GitHub で公開されたコードを確認するよう開発者に呼びかけました。
Microsoft は TripAdvisor や O’Reilly Media などの主要パートナーと協力し、NL Web を用いて短期間で実装・プロトタイプを作成し、自社サイトに直接 Agentic な体験を組み込む事例をすでに多数実現しています。
NL Web の具体的な活用方法を示すため、任意の GitHub リポジトリにエージェンティック UI を簡単に追加できるデモを紹介しました。公開リポジトリから取得できる Python スクリプトを実行すると GitHub API からメタデータとコード内容を抽出し、ベクトル化してローカルのベクトルストアへ取り込みます。デモでは CTO オフィスの Jennifer Marsman 氏のリポジトリを対象にデータを取り込み、NL Web エンドポイントとして公開したうえで、MCP 対応エージェントからリポジトリ全体を対話的に検索・質問できる UI を生成する流れを示しました。
この例により、開発者は NL Web のコードを取得するだけで既存サイトや API をエージェンティック Web の一員として拡張できることが実証され、MCP を標準プロトコルとしたオープンなエージェント連携が容易に実現できる点が強調されました。
次のステップでは、取得したリポジトリデータに対してスクリプトを実行し、選択したモデルと埋め込み手法でベクトルを生成し、開発者が任意に選べるローカルまたはクラウドのベクトルストアへ格納します。今回はノート PC 上で動作するローカルベクトルストアにインポートし、NL Web サーバーがそのストアへアクセスできるように設定しました。
Kevin 氏は「私たち１社がすべてを担うより、オープンソース化して皆さんのフィードバックと想像力を結集することこそ、Agentic Webを本質的に面白くする唯一の道だ」と強調しました。
Kevin 氏はSatya 氏にマイクを戻す前に、Open が不可欠である理由を 2 点に絞って強調しました。
まず第一に、シンプルで相互補完的なコンポーネントやプロトコルを世界中の開発者に公開することで、無限の創造性と厳密な検証が注ぎ込まれ、想像を超えるイノベーションが生まれると述べます。
第二に、もし初期の Web がブラウザメーカーのような一企業に垂直統合されていたなら、Web 全体がその企業の想像力の範囲内に閉じ込められ、現在のような豊かでダイナミックな姿には決して到達しなかったと指摘しました。
この歴史的教訓を踏まえ、エージェンティックなウェブも同様に多くの開発者が自由に「リフ」し、想像力を存分に発揮できるオープンな環境であるべきだと呼び掛けました。
Satya Nadella 氏は、まず Kevin 氏への謝意を述べたうえで、agentic web のビジョンは「Web 本来の精神」に一層近づくものだと強調しました。従来は一部に集中していた content と intelligence が、今後はより分散され、Web 全体で発見しやすくなると述べ、NL Web が持つ二つの「民主化」効果に言及しました。第一に、どのアプリや Web サイトでも高度な知能を簡単に創出できる点です。第二に、開発者なら誰でもその知能を横断的に集約し、活用できる点です。これにより、開発者は reasoning model と NL Web を組み合わせ、ユーザーのインテントを起点に分散したインテリジェンスを合成・再構築できます。Satya 氏は「検索(Search) やフィード(Feed) の概念自体が再定義される」と述べ、開発手法が大きく変わることを示唆し、このプラットフォームをコミュニティと共に築き上げたいと呼びかけ、今後大きな変革が起こるだろう。これは過去 10〜15 年の力を繰り返すものだと締めくくりました。
データの世界
次のレイヤーは データです。AI app にとって data tier は極めて重要であり、私たちはフルデータスタックを構築しています。実際に成果も出ており、たとえば Lumen 社は Fabric を活用してデータアクセスを高速化し、10,000 時間以上の工数を削減しました。また Site 社は当社のデータスタックを用いて処理速度を 10 倍に向上させています。なかでも印象的なのは NFL の事例で、同リーグは最近の選手評価タスクを データ上で運用し、高度な分析を実現しました。
NFL における勝敗は、一つのプレーや一秒、そして相手よりわずかに優れた行動で決まります。その鍵を握るのが データ です。上位 3% のドラフト候補選手が集う NFL Scouting Combine では、従来も同量のデータを収集していましたが、複数のシステムに分散していたため、チームは統一的な方法でフィルター・検索・比較を行えず、複数のレポートを横断しながら分析せざるを得ませんでした。
短期間で選手の全体像を把握するために AI を活用するのが最適解でした。キックオフまでの猶予が限られる中、Azure Foundry が必要なツール一式を提供し、すぐに開発を開始できました。まず、追加のファインチューニングを行わずに使える Azure OpenAI GPT モデルを採用しました。さらに、データの高速な保存と取得には Azure Cosmos DB を利用し、ワークロードのシームレスなデプロイには Azure Container Apps を用いました。こうして当初は大きな課題と思われた取り組みを、短時間で解決できました。
チームは現在、自然言語で「ディフェンスラインの選手で最速の40ヤード走タイムは？」といった質問を投げかけるだけで、瞬時に比較分析用データを取得できます。従来は数時間を要していた絞り込みが数秒で完了し、選手が目の前にいる間にリアルタイムで詳細を深掘りできるため、評価者は以前よりも高い確信をもって意思決定できるようになりました。
Satya 氏は、Build では SQL Server 2025 の提供開始を皮切りに、データ関連のニュースを多数発表していると述べました。
データ層とインテリジェンスをこれまで以上に緊密に結び付けるため、Cosmos DB を Foundry に直接統合しました。これにより、あらゆるエージェントが会話履歴などを即座に保存・取得できるほか、近い将来には RAG アプリケーションでも Cosmos DB を活用できるようになります。
加えて、Azure Databricks から Genie spaces や AI functions のデータを Foundry と接続する機能を提供します。さらに PostgresSQL クエリ内で言語モデルの応答を直接統合できるようになり、自然言語と SQL を混在させたクエリを実行すると、従来とは異なる形でクエリプランがオーケストレーションされます。これにより、開発者はデータ操作と生成 AI を組み合わせ、これまでにない方法でインサイトを得られるようになります。
Microsoft Fabric
Fabric は 2 年前の Build で発表された当社データ／アナリティクススタックの中核サービスで、あらゆるデータとワークロードを 1 つの統合されたエクスペリエンスに集約します。昨秋に SQL を Fabric に統合しましたが、本日さらに大きな次の一歩を踏み出します。
Fabric には Cosmos DB も統合され、SQL と並んでテキストや画像、音声といった半構造化データを即座に扱えるようになります。これにより、あらゆるデータベースを統合し AI 向けに最適化できます。さらに Fabric には Digital Twin Builder を組み込み、ノーコード／ローコードで物理資産のデータを高速にマッピングできるようにしました。
データ取り込み時の処理を支援する機能として、OneLake で Shortcut Transformations を発表しました。これは AI-driven ETL で、音声→テキスト変換や感情分析、要約などの AI 変換を Foundry 経由で数クリックで適用できます。
最後に Copilot in Power BI を紹介します。チャット形式で複数の Power BI レポートやセマンティックモデルを横断的に質問・可視化・分析でき、作成済みのダッシュボードやモデルの上に推論モデルを重ねて活用できます。
このエージェントは Microsoft 365 Copilot でも利用可能となり、データ活用の体験を大きく変革します。
インフラストラクチャー
スタック最下層の インフラストラクチャ層 は、性能・レイテンシとコスト低減を同時に最適化する開発者のクラシックな課題に対応します。そのために私たちは、データセンター用シリコンからシステムソフトウェア、GPU に至るまで業界全体で システム全体最適化 を進め、一体化したプラットフォームとしてソフトウェアの力で徹底的に効率化します。
目標は、クラウドと次世代 AI ワークロード向けに 最低コストで最大スケール のインフラを提供することです。究極の評価指標は「tokens per Watt per dollar」であり、この比率を最大化することが私たちのゴールです。
私たちは、シリコンの進化（Mooreʼs Law）、システムソフトウェア最適化、モデル最適化という 3 つの S カーブ を同時に走らせ、その複合効果を速いペースで実現しています。準備が整い次第すぐに運用へ組み込む方針です。
実際 Azure は業界で初めて NVIDIA GB200（NVLink 72 ラック構成）を大規模に提供し始めました。これにより、単一 GB200 から 毎秒約 865,000 トークン という驚異的な生成性能を達成しています。
Nvidia Jenson氏との対談
Satya 氏は Build 開発者会議に再び参加した Jensen 氏に感謝を述べ、世界へさらなるインテリジェンスを届ける共同目標を強調しました。その指標として「tokens per dollar per Watt」を提示し、まず Moore’s Law から話を始めてほしいと求めました。
Jensen 氏は参加への興奮を示し、2 年前に Azure 上で世界最大級の AI スーパーコンピューターを共同で立ち上げたことを振り返りました。現在は新しい CUDA アルゴリズムとモデル技術、Azure の最新 AI インフラが組み合わさり、Hopper 世代比で 40 倍の高速化を実現していると述べ、その進化速度を「異常な速さ」と表現しました。
Satya 氏は、ハードウェアとソフトウェアの最適化が相乗効果（compounding effects）を生み出す点に言及しました。
Jensen 氏は、アーキテクチャ互換性とエコシステムの安定を保つことで、ソフトウェア開発者・AI 開発者・インフラ利用企業の投資を全フリートにわたって償却できると説明しました。CUDA はインストールベースが大きく、アクセラレータとして汎用性も高いため、データ処理を 20〜50 倍に高速化し、動画トランスコーディングや画像処理など多様なワークロードを一斉に加速できると強調しました。目標は、データセンターの 全ワークロードをフリートの寿命全体で最大限利用し、tokens per dollar per Watt を高めることです。
Satya 氏は、あらゆるワークロードを同指標で加速できるかを問いかけ、Jensen 氏は両社のパートナーシップによって「世界最高の AI ファクトリー」を構築し、今後さらなる進化が続くと述べました。
データセンター
Azure では NVidia GB200 をベースにした世界最大規模のスーパーコンピューターを稼働させる予定で、開発者の皆さまに向けて大規模に提供できるよう拡張を進めています。現在 Azure は 70 以上のデータセンターリージョンを擁し、過去 3 か月だけで 10 個のデータセンターを各国・各大陸に新設しました。
完全な AI システムを構築するため、冷却面も強化しています。たとえば Maya で導入した Sidekick 液体冷却ユニットをクローズドループ方式で運用し、GB 200 の需要を満たしつつネットワーク側の水消費をゼロに抑えます。最新のデータセンターは AI 向けに設計され、昨年までの Azure 全体を上回る量の光ファイバーを敷設しています。こうした設計は従来のデータセンターを塗り替える革新的なものであり、施設を訪れるたびに圧倒されると述べています。
Azure では 400 テラバイト規模の AI 専用バックボーンでデータセンター間を接続し、推論や学習などあらゆるワークロードを分散して処理できるようにしています。AI アプリケーションには GPU などのアクセラレータだけでなく、演算リソースとストレージも不可欠であり、この領域でも S カーブ型の効率向上を進めています。
昨年 10 月に発表した Azure CobaltのARM ベースの仮想マシンは、すでに Microsoft Teams や Defender など社内の大規模ワークロードを支えています。外部でも Adobe、Databricks、Snowflake など主要パートナーが Cobalt を活用してスケールアウトしています。さらに、英国気象庁 (Met Office) は Azure 上で最先端のスーパーコンピューターを稼働させ、気象・気候予測の精度と迅速性を大幅に向上させています。このシステムは気象科学向けとして世界最高レベルの性能を備えています。
英国気象庁（Met Office）の事例
Met Office は 170 年以上にわたり信頼性の高い気象・気候インテリジェンスを提供しており、毎日 500 億件超の観測と 200〜300 テラバイトの運用データを取り込んでいます。この膨大なデータを高解像度モデルで処理するにはスーパーコンピューターが不可欠で、演算能力が高いほど予報精度が向上し、人々の意思決定に貢献します。
Azure に完全統合された科学用スーパーコンピューター計画により、世界初の気象予報専用クラウドベーススーパーコンピューターが実現し、より複雑なモデルを高解像度で実行して迅速かつ正確な予測を提供できます。これにより顧客は予報精度の向上を体感し、厳しい気象状況でも信頼して行動できるようになります。今後は予報期間の拡大やさらなる高解像度モデリングも視野に入り、Met Office のサービス全体が強化され、生活の質が一層向上します。
デジタルレジリエンス
パフォーマンスと効率性だけでなく、デジタルレジリエンスも重視しています。Microsoft Cloud では、クラウドで最も包括的なコンプライアンス機能を提供し、データの地域やコンフィデンシャルコンピューティングなどの主権的コントロールを用意しています。これらは AI accelerators や GPU を含むクラウドインフラストラクチャや PaaS ワークロードにも適用され、システムのガバナンスとアクセス権を完全に管理できます。ただし、極端に低いレイテンシーやアプリ・データの保管場所を厳密に制御する必要があるクリティカルなユースケースも依然として存在します。
Azure Local
極端に低レイテンシーで、ネットワークから切り離された状態でもアプリやデータを実行できるようにするため、Microsoft は Azure Local を提供しています。これにより、これまで AI プラットフォーム上で扱ってきた開発者やナレッジワーカー向けワークフローを、接続の制約がある環境でも利用可能にできます。
Microsoft Discovery
最後に取り上げたい領域は 科学 です。今後数年間で科学的プロセスそのものにブレークスルーが起こり、新素材や新しい化合物・分子の創出が一段と加速すると予想しています。そのため、これまで紹介してきたスタック全体を科学のワークフローに適用しようとしています。これが本日発表する Microsoft Discovery の目標です。 Microsoft Discovery は、GitHub が開発者、Microsoft 365 と Copilot／Copilot Studio がナレッジワークやビジネスプロセスを支えるのと同様に、科学分野を対象としたプラットフォームです。Graph RAG というグラフベースのナレッジエンジン上に構築されており、単なる事実検索ではなく、公開データと自社データの両方から科学領域のニュアンスを理解します。Foundry を基盤に、R&D に特化した高度なエージェントを提供し、推論だけでなく研究そのものを遂行します。静的なパイプラインではなく、エージェントが連続的かつ反復的に協調して候補を生成・シミュレートし、結果から学習する仕組みで、いわば Copilot や Coding Agent の「科学版」と言えます。
Microsoft Discoveryのデモ
John 氏（Chemistry Product Lead）は、科学プラットフォーム上で複数のエージェントを指揮し、データセンター冷却用のイマージョンクーラントに関する新発見へと導くプロセスを紹介します。現在主流のクーラントの多くは PFAS 由来で環境負荷が高いため、より優れた代替物質を探索する必要があります。John 氏は 「知識の推論」「仮説の生成」「実験の実行」という三つのステップを連続的かつ反復的に循環させることで、最適なクーラントの発見を目指すデモを行います
最初のステップとして、John 氏は最新の知見を把握するため、クーラントとその特性について質問し、候補物質を洗い出そうとします。プラットフォームは公開情報と社内の信頼できる研究データを扱う複数のエージェントが連携し、ナレッジグラフを用いて推論します。これにより、単独の LLM では難しい関連付けを行い、より深い洞察と高精度な回答を提供します。この処理には数分かかります。
画面には、左側に要約、右側に最新のクーラント研究を網羅した詳細レポートが表示され、各所に信頼できる研究への引用リンクが付いています。これらの知見を検証・反復することもできますが、今回は知識の推論に留まらず実際のクーラント発見を目指すため、Step 2「仮説生成」に進みます。そこで私は、本研究で求められる沸点や電子機器を損傷させない誘電率などを踏まえた、調査専用のプランを作成するようエージェントに依頼します。
エージェントが最適なワークフローを自動生成し、手法やコードを指定しなくても Microsoft Discovery が一括で管理します。
これらのエージェントは Microsoft 製ツールやモデルに加え、オープンソース、サードパーティ、自社ソリューションも統合できます。
ユーザーは手順を追加したり評価基準を変更したりして、常にプロセスを制御できます。 返されたプランは、まず generative chemistry ステップで数百万の新規候補分子を生成し、AI モデルで高速に絞り込み、最後に HPC シミュレーションで検証する流れです。提案内容を確認して妥当と判断したため、このプランを実行します。
Microsoft Discovery を用いた最終プロセスの結果、PFAS を含まない冷却液の候補群が提示されました。研究者は各候補の沸点が目標範囲に収まり、誘電率も電子機器に適していることを確認し、次のステップとして実験室での検証に進む準備が整ったかを判断しました。有望な候補の一つは実際に合成され、実験映像では標準的な PC を液中に沈めて Forza Motorsport を実行し、ファン無しでも温度を安定保持できることが示されました。この成果により、永久化学物質に依存しない新しいクーラント材料の発見が現実となり、Microsoft Discovery を活用すれば創薬や半導体、新素材設計など他分野でも同様のブレークスルーが期待できると締めくくられました。
Microsoft Discovery がすでに幅広い業界の企業で R&D を加速していることは非常に素晴らしく、今後さらに多くの研究開発ラボに広がり、どのような成果が生み出されるのか楽しみにしています。
最後に
本セッションは、Microsoft が “agentic web” 全体にわたり開発者へ新たな機会を提供していることを総括的に説明するものでした。Microsoft はシステム全体を貫くプラットフォーム戦略を採り、スタックの各層でオープンなエコシステムを実現しています。具体的には、GitHub と GitHub Copilot がソフトウェア開発ライフサイクルを支え、Microsoft 365、Copilot、Teams、Copilot Studio があらゆる役割と業務プロセス向けのエージェントを可能にします。さらに Foundry は “agent factory” として、どのようなデータでも活用できる AI アプリやエージェントを世界水準のインフラ上で展開し、管理・ID・セキュリティを統合的に提供します。これらの取り組みは開発者の野心を後押しし、新しい価値創出の機会を広げることが目的です。
Satya 氏は、この1年で出会った開発者の実例を振り返り、技術が実社会にもたらす価値を強調しました。スペインでは Foundry を活用して息子が罹患する希少疾患の診断を迅速化した父親がいます。南米ではウェルネスをゲーム化するアプリを開発するスタートアップが登場しています。日本の航空会社は Phi を用いて客室乗務員が高度 3 万フィートでも報告書を作成できるようにしました。こうした事例は、プラットフォームを作る側ではなく、それを使ってアプリケーションを構築する開発者こそが真の勝者であることを示しています。
勝者は経済のあらゆる分野、世界中のあらゆる地域に広がるべきであり、Microsoft の使命は技術そのものではなく、「人々が技術で何を成し遂げるか」にあります。締めくくりに世界銀行がナイジェリアの学生を対象に Copilot を活用した調査を実施した結果、統計的に最も効果的な教育介入となったと報告されました。この成功を受け、同プログラムはペルーにも拡大され、数百人の公立学校教師が Copilot で授業計画を強化し、学習成果を向上させ、自身のキャリア成長にも役立てています。
コメントを残す