エージェント実行基盤が主戦場に、Microsoft Buildで見えたAI開発の次段階｜2026年6月4日版

2026年6月4日

エージェント実行基盤が主戦場に、Microsoft Buildで見えたAI開発の次段階｜2026年6月4日版

日本時間2026年6月4日時点で押さえるべき流れは、AIの競争軸が「賢いモデル単体」から「エージェントを安全に動かす実行基盤」へ移っていることです。

Microsoft Build 2026では、GitHub、Foundry、Windows、Microsoft 365、Securityをまたぐエージェント関連の発表が集中しました。ポイントは、チャット画面で答えを得る段階ではなく、AIがコードを書き、アプリを操作し、社内データを参照し、実行ログを残すところまでを企業システムとして扱い始めた点にあります。

今日の見方はシンプルです。AIエージェントを本番業務に入れるには、モデル選びより先に「隔離」「権限」「監査」「評価」の設計が必要になる、ということです。

MicrosoftはBuild 2026で、Foundry、GitHub Copilot app、Windows 365 for Agents、Agent 365を一つのエージェント基盤として打ち出した
GitHub Copilot appは、複数のエージェント作業をworktreeやブランチで分離し、人間が差分と検証結果を見ながら進める方向へ広がっている
Foundryは、ホスト型エージェント、ツール、記憶、検索、評価、ガバナンスをまとめ、プロトタイプ後の運用課題を狙っている
日本企業が見るべきなのは「どのAIが一番賢いか」だけでなく、社内ID、端末管理、ログ、データ境界に接続できるかどうか

今日の重要ニュース早見表

重要度	分野	要点	日本の読者への影響
高	エージェント基盤	MicrosoftがBuild 2026で、Foundry、GitHub、Windows、Securityを横断するエージェント基盤を提示	企業導入では、PoCの次に実行環境と統制設計が問われる
高	開発ツール	GitHub Copilot appの技術プレビュー対象が拡大し、複数セッション、worktree、検証UIが前面に	開発者は「AIに書かせる」より、差分を検証して統合する役割が増える
高	クラウド実行	Foundryがホスト型エージェント、Toolboxes、Memory、評価、Teams公開などを整備	社内ツール連携やRAG実装を自前で組む範囲が変わる可能性
中	端末・セキュリティ	Windows 365 for AgentsとAgent 365が、エージェント用Cloud PC、ID、Intune、Defender管理を前面に	情シス部門は、ローカルAIエージェントを「未管理アプリ」として扱う準備が必要

Microsoft Build 2026の核心は「エージェントの運用基盤」

Microsoft Build 2026は6月2日から3日にかけて開催され、公式ライブブログにはAIモデル、Foundry、GitHub Copilot app、Windows 365 for Agents、OpenClaw on Windowsなどが並びました。

ただし、個別発表をばらばらに見るより、今回は一つの流れで見る方が分かりやすいです。Microsoftは、AIエージェントを次のような層に分けて扱っています。

Build: GitHubでエージェントやアプリを作る
Contextualize: Microsoft IQやFoundry IQで社内データやWeb情報に接続する
Run: FoundryやWindows 365 for Agentsで実行する
Govern: Agent 365、Entra、Defender、Purview、Intuneで監視・制御する
Improve: 評価、トレース、フィードバックで改善する

何が起きたか

Microsoftは、AIエージェントを「会話ボット」ではなく、長時間動き、複数ツールを呼び、ブラウザやアプリを操作し、業務システムの中で結果を出す存在として位置づけました。

Microsoftの公式ブログでは、企業向けエージェントにはモデルや計算資源だけでなく、ID、文脈、ポリシー、人間の監督が必要だと説明されています。これは、日本企業のAI導入でもそのまま課題になります。社内規程、個人情報、業務システム、委託先データが絡む現場では、便利なAIツールを入れるだけでは済みません。

なぜ重要か

生成AIの導入は、これまで「どのモデルを使うか」「どの業務にチャットを入れるか」が中心でした。エージェント化が進むと、問題は変わります。

AIがファイルを読み、チケットを更新し、ブラウザを操作し、コードを変更するなら、次の問いが避けられません。

そのエージェントは誰の権限で動くのか
実行中にどのファイルやAPIへアクセスしたのか
失敗したとき、誰が差分とログを確認できるのか
社外サービスやMCPサーバーに何を渡しているのか
本番環境に近い操作を、どこまで自動化してよいのか

ここがポイント: AIエージェントの導入は、モデル比較だけでは判断できません。実行環境、ID、ログ、評価、停止手段まで含めて「業務システム」として見る必要があります。

GitHub Copilot appは、AI開発を「複数セッション管理」に寄せる

GitHubは6月2日、GitHub Copilot appの技術プレビュー対象を既存のCopilot Pro、Pro+、Business、Enterprise顧客に拡大したと発表しました。

このアプリは、AIにコードを書かせるだけの画面ではありません。既存のIssueやPull Request、過去セッションを起点にし、複数のエージェント作業を並行して進め、差分や検証を人間が確認するための作業台に近づいています。

何が起きたか

GitHubの発表では、Copilot appは次のような機能を持つと説明されています。

Issue、Pull Request、プロンプト、過去セッションから作業を開始
複数のエージェントセッションを並列実行
各セッションをgit worktreeとブランチで分離
統合ターミナルやブラウザで挙動を検証
PR作成、レビュー対応、CI、マージ条件まで既存のGitHubフローに接続
MCPサーバーや再利用可能なスキル、スケジュール実行に対応

今回の追加では、Canvasesという作業面も強調されています。これは、チャットのやり取りだけでなく、計画、PR、ブラウザ操作、ターミナル、チェックリストなどを人間とエージェントが同じ対象として見ながら進める考え方です。

日本の開発現場への影響

日本の開発チームにとって重要なのは、AIコーディングが「補完」から「作業単位の委任」に移りつつある点です。

ただし、これは開発者の確認が不要になるという意味ではありません。むしろ、レビューすべき対象は増えます。コード差分だけでなく、AIが参照した文脈、実行したテスト、ブラウザでの確認結果、CIで落ちた理由まで見る必要があります。

現場で先に整えるべきことは、次の3つです。

IssueやPRの粒度を、AIが迷わず扱える大きさにする
テスト、Lint、型チェック、セキュリティ検査をCIで必ず通す
AIが変更できるリポジトリ、ブランチ、秘密情報の境界を決める

Foundryは「プロトタイプ後」の面倒を取りに行く

Microsoft FoundryのBuild Editionでは、ホスト型エージェント、Toolboxes、Memory、Foundry IQ、評価、ガバナンスがまとめて示されました。

ここで見える狙いは、デモを作る段階ではなく、社内で長く動かす段階の負担を下げることです。

何が起きたか

Microsoft Foundryの公式ブログによると、Build 2026での主な更新は次の通りです。

Microsoft Agent Frameworkに、スキル、メモリ、ミドルウェアなどの安定した構成要素を追加
ホスト型エージェントは、2026年7月初旬までの一般提供予定として案内
Toolboxes in Foundryは、MCPクライアント、ツール、スキル、企業データへの接続を一つの管理エンドポイントに寄せる
Memoryは、手順を覚えるprocedural memory、ユーザー記憶、セッション記憶を扱う
Foundry IQは、Work IQ、Fabric IQ、Azure SQL、File Search、MCPなどを検索・知識レイヤーとしてまとめる
トレース、評価、Agent Control Specification、ASSERTなどで、エージェントの振る舞いをテスト・制御する

なぜ重要か

多くの企業AIプロジェクトは、最初のデモではうまく見えます。問題はその後です。

社内FAQ、経費精算、営業支援、問い合わせ対応、開発支援などに広げると、データソースが増え、権限が複雑になり、ログの保管や誤動作時の責任範囲も曖昧になります。Foundryの更新は、この「プロトタイプ後の面倒」をクラウド基盤側で吸収しようとするものです。

日本企業がすぐ確認すべきなのは、機能名よりも接続先です。Microsoft 365、Azure SQL、Fabric、GitHub、Teamsをすでに使っている組織では、既存のIDと権限設計にどこまで自然に乗るかが導入判断に直結します。

Windows 365 for AgentsとAgent 365は、エージェントを管理対象にする

AIエージェントがブラウザやアプリを操作するなら、実行場所も管理対象にする必要があります。Microsoftはこの部分で、Windows 365 for AgentsとAgent 365を組み合わせています。

何が起きたか

Microsoft Learnの説明では、Windows 365 for Agentsは、AIエージェントに安全なオンデマンドCloud PCを提供するための仕組みです。管理されたID、デバイス状態、ガバナンスされたセッションライフサイクルを持つCloud PC上で、エージェントを動かす考え方です。

Microsoft Security Blogでは、Agent 365がローカル、SaaS、クラウドのエージェントを検出・監視・制御する方向も示されています。2026年6月には、Defenderがエージェントの実行端末、MCPサーバー、関連ID、到達可能なクラウドリソースをマッピングする機能を提供予定とされています。

日本の読者への影響

ここは情シス部門に直結します。

開発者が個別にAIエージェントやMCPサーバーを入れると、社内からは見えない自動処理が増えます。コードを書くだけならまだしも、ファイルを開く、ネットワークへ接続する、ブラウザで社内SaaSを操作するとなると、従来のSaaS管理や端末管理では足りません。

確認すべき項目は明確です。

社内で使われているAIエージェントを棚卸しできるか
MCPサーバーや外部ツール連携を把握できるか
エージェントごとにIDと権限を分けられるか
実行ログ、ファイルアクセス、ネットワーク接続を追えるか
問題が起きたときに停止・遮断できるか

日本の読者が見るべきポイント

今回の発表はMicrosoft中心ですが、論点はMicrosoft利用企業だけに閉じません。Claude Code、OpenAI Codex、Gemini系の開発支援、社内RAG、MCPツール連携を使うチームにも同じ問題が出ます。

開発者

AIに任せる単位が大きくなるほど、テストとレビューの価値が上がります。エージェントが複数セッションで並行作業するなら、worktree、ブランチ、CI、差分確認、依存関係の更新履歴をきれいに残す設計が必要です。

企業利用者

問い合わせ、営業、経理、人事などの業務にAIエージェントを入れる場合、便利さだけでなく、社内データの境界を決める必要があります。誰のメール、どの契約書、どの顧客データを参照できるのか。そこが曖昧なままでは、本番導入に進みにくくなります。

情シス・セキュリティ担当者

今後は「生成AIサービスを許可するか」だけでは足りません。ローカル端末で動くエージェント、クラウドで動くエージェント、MCPサーバー、ブラウザ操作、Cloud PC実行環境までを管理対象に含める必要があります。

継続ウォッチ

次に見るべき点は、発表の大きさではなく、実際に使える条件です。

Foundryのホスト型エージェントが、2026年7月初旬までにどの範囲で一般提供されるか
GitHub Copilot appの技術プレビューが、無料ユーザーや未契約組織にどこまで広がるか
Windows 365 for Agentsの提供地域、料金、実行制限が日本企業に合う形になるか
Agent 365が、Microsoft外のAIエージェントやMCP利用をどこまで可視化できるか
エージェントの評価・監査ログが、社内監査や委託先管理に使える粒度で残るか

今日のまとめ

2026年6月4日時点のAI・ITニュースで最も重要なのは、エージェントが「便利なAI機能」から「管理すべき実行主体」になり始めたことです。

Microsoft Build 2026の発表は、モデル性能だけを競う話ではありません。GitHubで作り、Foundryで動かし、WindowsやCloud PCで隔離し、Agent 365やDefenderで監視する。そうした全体像が見えました。

日本の企業や開発チームにとっての次の判断材料は、どのAIを選ぶかだけではなく、エージェントにどの権限を渡し、どこで実行し、どう止めるかです。PoCを進めるチームほど、早い段階でID、ログ、CI、端末管理、外部ツール連携を同じ設計図に入れておく必要があります。

参照リンク

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！