Windows Agent Framework入門｜既存版との違い

Microsoft Build 2026で、WindowsそのものをAIエージェントのプラットフォームに変える「Windows Agent Framework（WAF）」が発表された。ファイルマネージャー、タスクスケジューラ、ハードウェアセンサーまで、OSの内部機能にエージェントが直接アクセスできる宣言型APIが用意される。MIT License でオープンソース化される点も注目に値する。

既存のMicrosoft Agent Framework 1.0は.NETとPythonでマルチエージェントを構築するためのSDKだった。対してWAFは「Windows OS上でエージェントを動かす実行基盤」という位置づけで、守備範囲がまるで違う。両者は補完関係にあり、Agent Framework 1.0で書いたエージェントをWAFの実行環境にデプロイする、という使い方が想定されている。

Build 2026のセッション資料を一通り読み込み、WAFの全体像を整理した。

Windows Agent Frameworkとは何か

Windows Agent Framework（WAF）は、Windows OSの内部サブシステムにAIエージェントが直接アクセスするための宣言型APIセットとランタイム環境だ。2026年5月28日のMicrosoft Build 2026で正式発表された。

実際にWindows上でAIエージェントを動かした経験がある人ならわかると思うが、従来の方法は2つしかなかった。スクリーンショットを撮って画面上のボタン位置を推定する「computer use」方式と、PowerShellスクリプトをLLMに生成させる方式だ。筆者も両方試したが、computer useは解像度やスケール設定が変わるだけでクリック位置がずれる。PowerShell生成は権限エラーで止まることが10回に3回はあった。

WAFはこの苛立ちに正面から応える。エージェントがファイルシステム、通知センター、タスクスケジューラ、カメラやセンサーまで、構造化APIで直接操作する。画面を目視で探す必要がない。

Build 2026で発表された主な構成要素

ただし3つともPublic Preview段階だ。パッケージングのスキーマが変わるリスクは頭に入れておく必要がある。

WAFのアーキテクチャ：3層構造を理解する

WAFのアーキテクチャは3層に分かれている。上からアプリケーション層、ランタイム層、OS統合層だ。

┌─────────────────────────────────────────┐
│         Application Layer               │
│  (Agent Code / Semantic Kernel / etc.)  │
├─────────────────────────────────────────┤
│         Runtime Layer (WAR)             │
│  LifecycleManager │ MemoryManager       │
│  PermissionEngine │ RuleEngine          │
├─────────────────────────────────────────┤
│         OS Integration Layer            │
│  FileSystem │ TaskScheduler │ Sensors   │
│  Notification │ Registry │ Network      │
└─────────────────────────────────────────┘

アプリケーション層：エージェントコードが動く場所

開発者がエージェントのロジックを書く層。Semantic Kernel、AutoGen、LangGraphなど既存のオーケストレーションフレームワークがそのまま載る。WAF固有のSDKを新たに覚えなくていい。すでにAgent Framework 1.0で動いているコードを持ち込める設計だ。正直、ここが一番ありがたい。フレームワークが変わるたびに書き直すのはもう懲りている。

ランタイム層：WAR（Windows Agent Runtime）

WARはWinRTベースのバックグラウンドサービスとして走る。エージェントの起動・停止・メモリ管理・権限チェックを一手に引き受ける。

個人的に刺さったのはルールエンジンの設計だ。従来のプロセス単位のアクセス制御ではなく、「ユーザーの意図」に基づいた粒度の細かい権限制御を敷く。「メール送信エージェント」には送信APIだけを開放し、ファイルシステムへのアクセスは遮断する——こういう制御が宣言的に書ける。

OS統合層：Windowsの内部に直接アクセス

ファイルマネージャー、タスクスケジューラ、通知センター、ネットワークスタック、ハードウェアセンサーなど、OSの各サブシステムに構造化APIでアクセスする層。LangGraphにもOpenAI Agents SDKにもない、WAF固有のレイヤーがここだ。

Agent Framework 1.0との違い：比較表で整理

名前が似ているため混同しやすいが、Windows Agent FrameworkとMicrosoft Agent Framework 1.0は守備範囲が完全に異なる。両者の関係を一言で言えば「Agent Framework 1.0がエージェントの頭脳を作り、WAFがエージェントの手足を提供する」。

筆者がBuild 2026のセッション資料を読み込んだ限り、Microsoftは明確に「両方使え」というメッセージを出している。Agent Framework 1.0でマルチエージェントの思考チェーンを組み、WAFでWindowsへの操作権限を与える。

この棲み分けはAIエージェントの基本設計を理解していると飲み込みやすい。エージェントには「考える部分」と「動く部分」が必要で、MicrosoftはそれぞれにSDKと実行環境を分けて提供した形だ。

Windows Agent Runtimeの仕組み

Windows Agent Runtime（WAR）はWAFの心臓部だ。WinRT上に構築されたバックグラウンドサービスで、エージェントの生存管理からメモリ割り当て、権限チェックまでを担う。

ライフサイクル管理

WARがエージェントの起動・一時停止・再開・終了を統一的に管理する。従来はエージェントごとにプロセスを立ち上げ、終了処理も自前で書いていた。WARはエージェントをWindowsサービスとして登録し、OSレベルでライフサイクルを保証する。マシンがスリープから復帰したとき、エージェントが中断状態から自動的に再開する動作が組み込まれている。PCを閉じて翌朝開いたら、昨夜のタスクの続きをエージェントが拾っている——そういう世界観だ。

メモリとリソースの制御

エージェントがシステムリソースを食い尽くさないよう、WARはエージェントごとにメモリとCPUの上限を設定できる。

{
  "agent": "mail-assistant",
  "resources": {
    "memory_limit_mb": 512,
    "cpu_percent_max": 15,
    "gpu_allowed": false,
    "npu_allowed": true
  },
  "lifecycle": {
    "auto_start": true,
    "restart_on_failure": true,
    "max_restart_count": 3
  }
}

NPU（Neural Processing Unit）の使用許可もここで切り替える。Windows Copilot Runtimeと連携し、ローカルモデルの推論をNPUに投げるのが推奨構成だ。GPUをゲームや映像処理に残しつつ、エージェントの推論はNPUに逃がす——Copilot+ PCを持っている人には特にメリットが大きい。

ルールエンジンによる権限制御

WARの中核となるルールエンジンは、「プロセスID + ユーザー権限」という従来のWindowsセキュリティモデルを超え、「ユーザーの意図」単位で権限をスコープする。Build 2026の「Securing the agent mesh」セッションで詳細が公開されている。

# 権限マニフェストの例（YAML形式）
agent_name: mail-assistant
permissions:
  - scope: mail.send
    conditions:
      - recipient_domain: "company.com"
      - max_per_hour: 50
  - scope: file.read
    conditions:
      - path_prefix: "~/Documents/Reports/"
  - scope: notification.push
    conditions:
      - priority: "normal"
denied:
  - scope: file.write
  - scope: registry.modify
  - scope: network.raw_socket

メール送信エージェントなら「社内ドメインへの送信のみ、1時間50通まで」という粒度で制限できる。ファイルの読み取りは特定ディレクトリだけ、書き込みは全面禁止。このマニフェストがWindows Agent Storeでの審査基準にもなる。

Windows Agent Store：配布とガバナンス

Windows Agent Storeは、エージェントの発見・インストール・更新を一元管理するプラットフォームだ。Microsoft Storeのエージェント版と考えればいい。

個人開発者向けの配布フロー

企業向けのキュレーション機能

IT管理者はIntuneやMicrosoft 365管理センターからAgent Storeのカタログを制御できる。「社内で使用可能なエージェント」をホワイトリスト形式で管理し、権限マニフェストの上限を企業ポリシーで上書きする機能も用意される。Microsoft Agent 365のガバナンス機能と連携する形だ。

セキュリティモデル：意図ベースの権限制御

WAFのセキュリティモデルは、Build 2026の「Securing the agent mesh」セッションで独立したトピックとして扱われるほど重視されている。従来のWindowsのアクセス制御（ACL）はファイル・レジストリ・サービスへのユーザー/グループ単位の許可だった。WAFではこれに加え、「エージェントが何をしたいか」という意図レベルの制御が入る。

3段階のセキュリティ境界

3つの層が重なることで、個人利用でもエンタープライズでも粒度を変えられる。MCPエコシステムでは約66%のサーバーにセキュリティ上の問題が確認されている（OX Securityの調査）。WAFのような「実行環境側での権限強制」は、アプリ任せだったセキュリティをOS側で底上げする現実的な手段だ。

WAFの始め方：開発者向けクイックスタート

正式SDKドキュメントはGitHubのMITリポジトリで公開予定。以下はBuild資料ベースの構成で、パッケージ名はGA時に変わる可能性がある。

前提条件

• Windows 11 24H2 以降（Windows Insider Canary/Dev推奨）
• Visual Studio 2022 17.12+ または VS Code + C# Dev Kit
• .NET 9 SDK または Python 3.12+
• Windows App SDK 1.7+（WinUI 3対応アプリを作る場合）

Step 1: プロジェクトの作成

# .NET の場合
dotnet new console -n MyFirstAgent
cd MyFirstAgent
dotnet add package Microsoft.Windows.Agent.SDK --prerelease
dotnet add package Microsoft.SemanticKernel

# Python の場合
pip install windows-agent-sdk semantic-kernel
mkdir my_first_agent && cd my_first_agent

Step 2: エージェントの基本構造

# Python での最小構成例
from windows_agent import AgentBase, Permission, Manifest

class FileOrganizerAgent(AgentBase):
    """ダウンロードフォルダのファイルを整理するエージェント"""

    manifest = Manifest(
        name="file-organizer",
        permissions=[
            Permission("file.read", path="~/Downloads/"),
            Permission("file.move", path="~/Documents/Organized/"),
            Permission("notification.push", priority="low"),
        ]
    )

    async def on_trigger(self, event):
        # ダウンロード完了イベントで発火
        new_file = event.file_path
        category = await self.classify(new_file)
        dest = f"~/Documents/Organized/{category}/"
        await self.fs.move(new_file, dest)
        await self.notify(f"{new_file.name} を {category} に整理しました")

if __name__ == "__main__":
    FileOrganizerAgent.run()

on_triggerはポーリング不要の設計だ。WARがOSイベント（この例ではファイルダウンロード完了）を拾ってエージェントを起こす。while Trueループで監視する時代は終わる。

Step 3: マニフェストの作成と登録

# ローカルでエージェントを登録・テスト
waf register ./my_first_agent --dev-mode
waf start file-organizer
waf logs file-organizer --follow

--dev-modeフラグを付けるとAgent Store審査をスキップし、ローカル開発用に即座に登録される。本番デプロイ時にはこのフラグを外してStoreに提出する。

エコシステムとの接続：MCP・Copilot・Azure

WAFは単独で完結するツールではない。Microsoftが構築してきたAIエコシステム全体のOS統合レイヤーとして機能する。

MCPとの連携

Agent Framework 1.0はすでにMCP（Model Context Protocol）に対応している。WAF上で動くエージェントもMCPサーバーに接続でき、外部ツールやデータソースとの連携が開く。AWS MCP ServerでS3バケットを操作しつつ、ローカルファイルの整理はWAF APIで処理する——クラウドとローカルの境界をエージェントが自然にまたぐ構成が組める。

Windows Copilot Runtimeとの統合

Build 2026で同時に強化が発表されたWindows Copilot Runtimeは、ローカルNPUを使ったオンデバイス推論のAPIセットだ。WAFエージェントはCopilot Runtime経由でローカルモデルを呼び出せる。クラウドAPIの呼び出しコストを抑えたい処理——たとえばファイルの分類やテキスト要約——をNPUで処理し、複雑な推論だけAzure OpenAI Serviceに投げる構成が取れる。

このハイブリッド推論は、APIコストが月数万円に膨らんで困った経験がある人には切実な話だ。ファイル名の分類程度でGPT-4oを呼ぶ必要はない。NPUでローカル処理すればAPI料金はゼロになる。

Azure AI Foundryとの接続

Build 2026ではAzure AI FoundryにClaude（Anthropic）が正式追加された。エンタープライズSLAも付く。WAFエージェントのバックエンドLLMがOpenAI GPTに縛られなくなった点は地味だが影響が大きい。

Azure AI Foundryをハブにして、タスクごとにモデルを切り替える。ファイル操作の指示出しはGemini Flash Lite（安い）、コード生成はClaude Sonnet（精度が高い）、といった使い分けがWAFの権限マニフェスト1つで管理下に入る。

他のエージェントフレームワークとの比較

WAFのポジションを整理するため、主要なエージェント構築ツールと並べてみた。

自分なら「Agent Framework 1.0 + WAF」を選ぶ。Semantic Kernelのプラグインが既存プロジェクトに10本以上あれば、そのまま流用できるのが決め手になる。LangGraphのワークフロー型が好みなら、LangGraphをアプリ層に置いてWAFのAPIを叩く構成でも問題なく走る。

よくある質問

まとめ：WAFで変わる開発者の選択肢

Windows Agent Frameworkは「AIエージェントにOSレベルの手足を与える」という、これまでなかった層を埋めるツールだ。Agent Framework 1.0が思考を担い、WAFが操作を担い、Agent Storeが配布を担う。Microsoftが一気にスタックを縦に揃えた形になる。

開発者にとって実務的に重要なのは3点。

• 意図ベースの権限制御：エージェントの暴走リスクをOS側で抑え込める。企業導入のハードルが下がる
• NPUによるローカル推論：毎回クラウドAPIを叩かなくていい処理をNPUに逃がせる。コスト面で現実的になる
• MITライセンスのOSS：ベンダーロックインを気にせず採用できる。コミュニティ貢献も可能

現時点ではPublic Previewの段階で、本番投入にはWindows Insider Previewでの検証が必要だ。それでも、Windows上でエージェントを動かす予定があるなら、今のうちにWAFの権限モデルとランタイム構成を理解しておくのは合理的な先行投資になる。

まずはAgent Framework 1.0で小さなエージェントを作ってみるのが、WAF対応への最短ルートだ。