Microsoft Build 2026～生成AIは「答えるAI」から「働くAI」へ～
fukayayuji
目次
はじめに
2026年6月2日から3日にかけて、Microsoftの年次開発者向けカンファレンスである「Microsoft Build 2026」が開催されました。
Go deep on real code and real systems with the teams building and scaling AI at Microsoft Build, June 2–3, 2026, in San Francisco and online.
Microsoft Buildは、開発者、IT部門、システム企画担当者、ソリューション開発に関わる企業に向けて、Microsoftの最新技術や今後の方向性が発表される重要なイベントです。Azure、Windows、Microsoft 365、GitHub、Microsoft Copilot、Microsoft Foundry、セキュリティ、開発ツールなど、Microsoftの主要な技術領域が幅広く扱われます。
Microsoft Build 2026は、米国サンフランシスコでの現地開催に加えて、オンラインでも配信されました。今回のBuildでは、特にAIエージェント、Microsoft 365 Copilot、GitHub Copilot、Microsoft Foundry、Windows上のローカルAI、AI時代のセキュリティとガバナンスなど、企業の生成AI活用に直結するテーマが数多く取り上げられました。
本記事では、その中でも「Microsoft Build 2026 | Opening Keynote」の内容をもとに、AIに関連する発表にフォーカスして整理します。すべての発表を網羅するのではなく、企業がこれから生成AIやAIエージェントを本格的に活用するうえで、何を考えるべきかという観点から読み解いていきます。
Opening Keynoteを見て、私が最も強く感じたことがあります。
それは、生成AIの主戦場が、いよいよ「AIに質問する」段階から、「AIエージェントに業務を任せる」段階へ移り始めているということです。
これまで生成AIは、文章作成、要約、翻訳、アイデア出し、コード生成など、人間の作業を支援する存在として語られることが多くありました。もちろん、それだけでも大きな価値があります。しかし今回のBuildで示されたのは、単にチャット画面の中でAIが賢く答えるという話ではありません。
AIがツールを使い、ファイルにアクセスし、コードを生成・実行し、業務データを参照し、TeamsやOutlookなどの業務環境の中で動き続ける。そうしたAIエージェントを、企業の中で安全に、継続的に、管理しながら使っていくための基盤が本格的に整い始めている、というメッセージでした。 これは、企業の生成AI活用にとって非常に重要な変化です。
生成AIは「モデル導入」から「一連の環境設計」へ
これまで企業の生成AI活用では、「どのモデルを使うか」「どのチャットツールを導入するか」が大きな論点でした。GPTを使うのか、Claudeを使うのか、Geminiを使うのか。社内向けチャットボットを作るのか、議事録要約や文書作成に使うのか。そうした議論が中心でした。
しかし、AIエージェントの活用が進むと、論点は大きく変わります。
AIエージェントは、単に文章を生成するだけではありません。業務の目的を理解し、必要な情報を探し、ツールを呼び出し、複数の手順を実行し、場合によっては長時間にわたってタスクを進めます。
そのため企業には、モデルだけでなく、次のような要素を一体で考える必要が出てきます。
社内データや業務文書をAIにどう渡すのか。
AIにどの業務ツールを使わせるのか。
AIが実行してよい操作と、実行してはいけない操作をどう分けるのか。
AIエージェントごとのIDや権限をどう管理するのか。
AIの実行ログをどう監査するのか。
AIの成果をどう評価し、改善していくのか。
つまり、生成AI活用は「AIツールを入れる」話から、「AIエージェントが安全に働ける業務基盤を設計する」話に変わりつつあります。 Microsoft Build 2026では、このAIエージェント時代の基盤として、エッジからクラウドまでのコンピュート、モデル、コンテキスト、ツール、ランタイム、開発環境、セキュリティ、ガバナンスが一体で語られていました。これは、企業のAI活用が、個別のPoCや部門ごとの便利ツールから、組織全体の業務基盤へ進む段階に入っていることを示しています。
AIエージェントは、チャット画面の外に出ていく
今回のBuildでは、AIエージェントが動く場所も大きく広がっていました。
ひとつは、PCやエッジデバイスです。Windows上でローカルにAIモデルを動かし、クラウドに毎回問い合わせなくても、端末上で要約、音声認識、計画、ツール呼び出しなどを実行する構想が示されました。これは、AIがクラウド上のAPIだけで動くものではなく、ユーザーの手元の環境にも広がっていくことを意味します。
もちろん、すべてのAI処理がローカルに移るわけではありません。高負荷な処理や大規模な推論は引き続きクラウドが重要です。しかし、PCやエッジ側で一定のAI処理が可能になることで、クラウドとローカルを組み合わせた新しいAI活用が進んでいくと考えられます。
もうひとつは、業務の現場に置かれる新しいデバイスです。Project Solaraでは、デスク上の常設デバイスやバッジ型のウェアラブルデバイスのように、AIエージェントが現場の文脈に近い場所で動く未来が示されました。
Composing a new platform for agent-first devices - Command Line
New interaction technology enables new types of computers. Learn more about Microsoft’s Project Solara.
Command Line 
ここで重要なのは、Project Solaraが単なる新デバイスの発表ではなく、「エージェントがどこに存在するのか」を問い直す構想であるという点です。Microsoftは、AIエージェントが特定のアプリケーションの中に閉じるのではなく、PC、クラウド、現場端末、ウェアラブルなど、さまざまな形で業務の中に入り込む世界を描いています。
AIエージェントは、もはや「チャット画面を開いたときだけ使うもの」ではなくなっていきます。PC、クラウド、Teams、Outlook、業務アプリ、現場端末、ウェアラブルなど、業務が発生する場所に入り込んでいく存在になります。
企業にとっては、AIの利用範囲が広がるほど、管理すべき範囲も広がるということです。
どこでAIが動くのか。
どの業務システムに接続するのか。
どのデータを参照できるのか。
どの操作を許可するのか。
ログや監査証跡をどう残すのか。
AIエージェントが現場に近づくほど、こうした設計が重要になります。
AIエージェントの品質は「コンテキスト」で決まる
今回の発表で、改めて強調されたのがMicrosoft IQの考え方です。
AIエージェントは、モデルだけでは業務に使える存在にはなりません。どれだけ高性能なモデルであっても、自社の業務ルール、社内文書、システム上のデータ、担当者、過去の判断、現在の状況を知らなければ、実務に即した判断はできません。
Microsoft IQでは、Work IQ、Fabric IQ、Foundry IQ、Web IQといった形で、社内外の情報をAIエージェントに接続する考え方が示されています。
Work IQは、Microsoft 365上の文書、メール、会議、チャット、人や組織の関係性など、日々の仕事の流れをAIが理解するための知能基盤です。
Fabric IQは、構造化された業務データに意味を与え、AIが業務データを理解できるようにするための基盤です。
Foundry IQは、AIエージェントが参照する知識を統合し、エージェントが必要な情報を取得できるようにするための基盤です。
Web IQは、AIエージェントが外部の最新情報を根拠として利用するための仕組みです。
ここで重要なのは、AIの性能を上げるために必要なのは、単に大きなプロンプトを渡すことではないという点です。
企業にとって本当に重要なのは、自社の業務知識をAIが使いやすい形で整理し、必要なタイミングで、必要な権限の範囲で、正しく参照できるようにすることです。
たとえば、社内の業務手順書、過去のプロジェクト資料、顧客対応履歴、業務システム上のデータ、担当者の知見が別々の場所に散在している状態では、AIエージェントは十分な判断ができません。逆に、それらが適切に整理され、権限管理された形でAIエージェントに接続されていれば、AIは単なる一般論ではなく、その企業の業務に即した支援ができるようになります。 生成AI活用の本丸は、最新モデルを選ぶことだけではありません。自社の知識、データ、業務プロセスを、AIエージェントが活用できる状態にすることです。
AIエージェントには、組織としてのハーネス管理が必要になる
AIエージェントが業務を実行するようになると、便利さと同時にリスクも増えます。
AIエージェントは、ファイルを読むかもしれません。
コードを実行するかもしれません。
データベースにアクセスするかもしれません。
メールやTeamsで通知するかもしれません。
業務システムを操作するかもしれません。
このとき、個人の注意やプロンプトの工夫だけで安全を担保することはできません。
必要になるのは、組織としてのハーネス管理です。
ハーネス管理に関しては、以下のコラムで説明させて頂いていますが、AI活用におけるハーネス管理とは、AIに「何を考えさせるか」だけでなく、AIに 何をさせてよいか、どこまで任せるか、どう監視するか を会社側で管理できることです。
組織としてハーネス管理できるAIエージェントが、企業の生成AI活用を次の段階へ進める
目次はじめに「ハーネス管理できる」とは何か個人の工夫だけでは、AIエージェント活用は広がらない野良AI時代に必要なのは、禁止ではなく組織AI基盤AIエージェント活用で…
AITC | AI TRANSFORMATION CENTER 
今回のBuildで紹介されたMicrosoft Execution Containers、Agent 365、Foundryのガードレール、評価機能、Agent Optimizerなどは、まさにこの方向性を示しています。
Microsoft Execution Containers、略称MXCは、Windows上でAIエージェントの実行をOSレベルで隔離・制御するための仕組みです。
GitHub - microsoft/mxc: Policy-driven, layered isolation and containment · GitHub
Policy-driven, layered isolation and containment . Contribute to microsoft/mxc development by creating an account on GitHub.
またAgent 365では、AIエージェントにもID、権限、監視、コンプライアンスが必要であることが示されています。これは非常に重要な視点です。
これからの企業では、人、アプリ、デバイスと同じように、AIエージェントも管理対象になります。誰が作ったエージェントなのか。誰の代理で動いているのか。どのデータにアクセスできるのか。どの操作を実行できるのか。どのようなログが残っているのか。これらを組織として把握できなければ、AIエージェントを本格的に業務へ展開することは難しくなります。
ここで大切なのは、AIエージェントを「危ないから禁止する」という発想だけでは不十分だということです。禁止すれば、現場は使いやすい外部ツールや個人利用に流れ、かえって見えないリスクが増える可能性があります。 必要なのは、AIエージェントを安心して自由に使える環境を用意し、その上で、組織として必要なハーネスをかけることです。
開発現場では、AIが「コードを書く」から「開発プロセスを進める」へ
GitHub Copilot appでは、GitHub IssueやPull Requestを起点に、複数のAIエージェントセッションを並列に動かし、それぞれの作業を分離しながら進める方向性が示されました。コード補完やチャットによる相談ではなく、Issue対応、修正、検証、レビュー、CI、マージ支援まで含めて、開発プロセス全体をAIが支援する方向です。
これは、ソフトウェア開発の生産性を大きく変える可能性があります。
ただし、ここでも重要なのは、AIがコードを生成できることだけではありません。AIが作ったものを、どうレビューするのか。どうテストするのか。どうマージするのか。どう本番環境に接続するのか。どう権限やデータを管理するのか。
AIによってコード生成の速度が上がるほど、設計、統合、品質保証、セキュリティ、運用管理の重要性はむしろ高まります。
RayfinはというAIエージェントや開発者が作ったアプリを、企業で使える本番レベルのバックエンドにつなげるためのオープンソースSDKが紹介されましたが、AIが生成したアプリケーションを、認証、データベース、ストレージ、アクセス制御、ガバナンスを備えた企業の管理環境に接続する考え方も、この流れの中で非常に重要です。
AIが速く作れるようになるほど、企業側には「速く作られたものを、安全に業務で使える状態にする力」が求められます。
これは、従来のシステム開発でも重要だったテーマですが、AIエージェント時代にはさらに重要になります。なぜなら、AIによってコードやアプリケーションの生成速度が上がるほど、未整理のまま業務に入り込むシステムや、管理されない小規模アプリケーションが増える可能性があるからです。 生成AI時代の開発基盤は、AIがコードを書けることだけでは不十分です。AIが作ったものを、企業として安全に受け止め、管理し、運用できる仕組みが必要になります。
Copilotは、対話型AIから「デジタルな同僚」を目指して
Microsoft 365 Copilotの説明も、今回のBuildで印象的でした。
これまでCopilotは、チャットを通じて質問に答えたり、文書を作成したり、会議を要約したりする存在として使われてきました。しかし、今回示された方向性は、それにとどまりません。
新しく示された、Microsoft Scoutに代表されるAutopilotは、常時動作し、独自のIDを持ち、ユーザーや組織のポリシーの範囲内でタスクを進めるAIエージェントです。Teams、Outlook、OneDrive、SharePointなどの業務環境とつながり、会議調整、準備資料の作成、成果物の確認、リスクの検知など、仕事の流れの中で継続的に動くことが想定されています。
これは、AIが「聞かれたら答える存在」から、「仕事の流れを理解し、必要なときに動く存在」へ近づいていることを意味します。
ただし、ここでも前提になるのはハーネス管理です。AIエージェントが自律的に動くほど、誰の権限で動くのか、どこまで実行してよいのか、どの操作には人間の承認が必要なのかを明確にする必要があります。 企業におけるAIエージェント活用は、自由に使わせるだけでも、禁止するだけでもうまくいきません。安全に自由に使える環境を、組織として設計することが重要です。
企業の競争力は、汎用モデルではなく、自社固有の学習ループへ
モデル選択に加えて、組織固有の業務に合わせてAIを改善する仕組みとして「Frontier Tuning」も発表されました。
Frontier Tuning: Teaching AI to work the way you do - Microsoft 365 Developer Blog
We're announcing the private preview of Frontier Tuning, a new approach to making AI work the way your business does by applying reinforcement learning in…
Microsoft 365 Developer Blog 
汎用モデルは自社の業務用語、自社の判断基準、自社の業務手順、自社の暗黙知を最初から理解しているわけではありません。 企業にとって本当に価値があるのは、自社の業務に合わせてAIを継続的に改善していく仕組みです。
Microsoftはこれを、企業ごとの評価基準、業務ログ、成功事例、判断結果、ワークフローを使って、AIを自社の目的に向けて継続的に改善していく考え方として示していました。
これは、AI時代における企業競争力の源泉がどこに移るのかを示しています。
既に、多くの企業が同じような高性能モデルを使えるようになっています。そうなると、差がつくのはモデルそのものではありません。
差がつくのは、自社の業務知識をどれだけAIに接続できているか。
自社の評価基準をどれだけ明確にできているか。
AIの実行結果をどれだけ継続的に改善できるか。
そして、その改善ループをどれだけ組織として回せるかです。
つまり、企業のAI活用は、「AIを使う」から「AIを自社の業務に合わせて育てる」段階に入っていきます。
ここで重要なのは、企業ごとの業務手順、評価基準、成功パターン、失敗パターン、承認フロー、品質基準を、AIが継続的に学習・改善できる形にしていくことです。 このような仕組みを持てる企業と、汎用AIをそのまま使うだけの企業では、AI活用の深さに差が出ていくと考えられます。
セキュリティも、AIエージェント時代に合わせて変わる
AIエージェントが業務の中で動くようになると、セキュリティの考え方も変わります。
従来のセキュリティは、人間、アプリケーション、端末、ネットワーク、データを中心に設計されてきました。しかしAIエージェントは、そのいずれとも少し異なる存在です。
AIエージェントは、人間の代理で動きます。
アプリケーションのように実行されます。
端末やクラウド上で処理を行います。
複数のツールやデータにアクセスします。
場合によっては、コードを生成し、実行します。
つまり、AIエージェントは、ユーザーでもあり、アプリケーションでもあり、実行環境でもあり、業務プロセスの一部でもあります。
そのため、AIエージェント時代のセキュリティでは、次のような観点が重要になります。
エージェントごとのID管理。
ユーザー代理実行時の権限制御。
アクセスできるデータ範囲の制限。
実行環境のサンドボックス化。
ログと監査証跡の取得。
人間の承認が必要な操作の定義。
異常な動作の検知と停止。
これは、AI活用をセキュリティ部門だけに任せる話ではありません。業務部門、IT部門、セキュリティ部門、法務・コンプライアンス部門、経営層が一体となって設計すべきテーマです。 AIエージェントを本格的に活用する企業ほど、セキュリティとガバナンスを最初から組み込んだAI活用基盤が必要になります。
本Buildを踏まえて考えるべきこと
今回のMicrosoft Build 2026は、Microsoft製品の発表イベントではあります。しかし、ここから得られる示唆は、Microsoft製品を使うかどうかに限られません。
企業として、以下のようなことを考えるきっかけになったのではないでしょうか？
第一に、AIエージェントに任せたい業務を明確にすることです。
単に「AIを使う」のではなく、どの業務のどの手順をAIに任せるのか、人間はどこで判断するのかを設計する必要があります。
第二に、AIが参照すべき社内知識を整備することです。
文書、データ、業務ルール、過去の判断、担当者情報などが散在したままでは、AIエージェントは十分に力を発揮できません。
第三に、権限と実行範囲を管理することです。
AIエージェントが何を読めるのか、何を実行できるのか、どこまで自律的に動いてよいのかを、組織として定義する必要があります。
第四に、評価と改善の仕組みを持つことです。
AIエージェントは一度作って終わりではありません。業務で使いながら、ログを取り、評価し、改善し、バージョン管理していく対象です。
第五に、AI活用を個人任せにしないことです。
一部の詳しい人だけが工夫して使う状態では、組織全体の生産性向上にはつながりません。必要なのは、安心して自由に使える環境と、組織としてハーネス管理できる基盤です。
第六に、AIエージェントを前提とした業務設計に踏み出すことです。
これまでの業務プロセスにAIを後付けするだけでは、AIエージェントの価値は限定的です。AIが調査し、人が判断し、AIが実行し、人が承認する。あるいは、AIが日常的な調整や確認を進め、人間はより重要な判断に集中する。そうした新しい業務分担を設計することが重要です。
最後に
Microsoft Build 2026が示したのは、生成AIが「答えるAI」から「働くAI」へ進化してくというビジョンです。
AIエージェントは、業務を理解し、ツールを使い、データを参照し、長時間タスクを進める存在になっていきます。そして、そのAIエージェントは、PC、クラウド、業務アプリ、現場デバイス、チームのコミュニケーション空間の中に広がっていきます。
だからこそ、企業に必要なのは、最新のAIモデルを試すことだけではありません。
AIエージェントが安全に働ける環境を整えること。
自社の業務知識をAIが活用できる状態にすること。
AIの実行範囲を管理すること。
AIの成果を評価し、継続的に改善すること。
そして、それを個人の工夫ではなく、組織の基盤として実現することです。
生成AI活用の次の段階は、AIエージェントを組織としてどう活かすかにあります。
AIトランスフォーメーションセンターとしても、企業がAIエージェントを安全に、実用的に、そして継続的に活用できるようにするための仕組みづくりが、これからますます重要になると考えています。
筆者
AITC センター長
深谷 勇次
