Microsoft Agent 365入門｜料金・使い方・GA新機能2026

Microsoft Agent 365とは｜Agent Frameworkと混同しないために

結論から書く。Microsoft Agent 365 は「企業内で動いている AI エージェントを、ID・セキュリティ・コンプライアンスの統一フレームに乗せる管理プラットフォーム」だ。エージェントを作るためのSDKではない。ここを最初に固定しないと、社内稟議書を書く時点で議論が空転する。

名前が似ている Microsoft Agent Framework 1.0（2026年4月GA）は、開発者が .NET / Python でエージェントを書くためのSDK。Semantic Kernel と AutoGen を統合した実装ライブラリにすぎない。一方の Agent 365 は、社内で動いているそのエージェントたちを「誰が、どのデバイスで、どの権限で」使っているかを可視化・統制する側だ。

役割の違いを表で押さえる

役割が逆方向であることが伝わるはず。両者は競合ではなく、Microsoft Agent Framework で作ったエージェントを、Agent 365 で運用するという縦の関係になる。

なぜ今これが必要なのか

2026年に入ってから、社内のあちこちで非公式にエージェントが動き始めている。OpenClaw（GitHub史上最多Star 347k達成）、GitHub Copilot CLI、Claude Code、Codex などをエンジニアが各自インストールし、業務データを食わせて使う。情シスからすると「誰が、どこで、何のAPIキーで動かしているか」が見えない。これが2026年版のシャドーITだ。

Microsoft はこの状況に対し、Defender と Intune を窓口にしたエージェント管理を打ち出した。Agent 365 はその受け皿として、ID（Entra）・端末（Intune）・脅威検知（Defender）・ライセンス（Microsoft 365）の4軸を一本化する。Slack や Salesforce が「ログを集めて統治する」のと同じ構造を、AIエージェントレイヤーで先取りした形と言える。

GAで何が変わったか｜2026年5月の中身

プレビュー版（2025年）は、機能は限定的だった。GAで初めて一般提供となり、企業導入の前提が整った形になる。Microsoft Security Blog（2026-05-01）の発表に基づき、変更点を5つに絞る。

プレビューからGAへの差分を時系列で見る

2025年12月のIgniteで初公開された当初は、Frontier program 限定で配られていた。当時カバーしていたのは Microsoft 純正エージェント（Copilot Studio製）のみで、サードパーティ製は対象外だった。GAでこの制限が外れ、AWS / GCP / OSS まで一気に守備範囲が広がった。

筆者が公開資料を追った範囲では、今回のGAで「マルチクラウド対応」が最大の差分だ。Microsoft が自社プラットフォームに閉じない方針を取ったのは、エンタープライズの現実（社内に複数クラウドが混在）を認めた結果と読める。一方で、Context mapping のような踏み込んだ統制機能は preview にとどまり、本番運用は2026年後半以降になる見込み。

料金とSKU｜E7・E5・単体の3パターン

Agent 365 の入手経路は3つしかない。価格を整理してから選び方を書く。

E5 の本体価格は2026-07-01から $57 → $60/user/月に値上げされる。E3 も $36 → $39 へ。Microsoft Agent 365 のリリースに合わせた包括的な値上げで、円換算だと約9,000円/user/月（E5）になる計算だ。

Security Copilot との関係

2025-11-18から、Microsoft 365 E5 を契約している既存の Security Copilot 顧客には、AI セキュリティエージェントが追加で提供されている。これは Agent 365 とは別のラインで、Defender 内のフィッシング解析や脅威ハンティングを自動化する用途だ。Agent 365 は「エージェントを管理する」側、Security Copilot のセキュリティエージェントは「Agent 365 が管理する対象になりうるエージェント」と捉えると整理がつく。

主要機能を5つに絞って解説

Microsoft 公式の機能一覧は20項目以上に膨らむが、現場で実際に効くのは下記5つに集約される。優先順位をつけて回した結果、運用の8割が回るのはこのスコープだった。

1. Agent Inventory（エージェント棚卸し）

Defender / Intune の管理コンソールに、組織内で動いているエージェントの一覧が表示される。Microsoft 純正だけでなく、OpenClaw、GitHub Copilot CLI、Claude Code といった OSS エージェントも検出対象に入った。デバイスID、起動ユーザー、最終起動時刻、API呼び出し先が紐づくので、「誰が、いつ、何のために」が初めて見える。

筆者がプレビュー資料の画面例を確認した限り、UI は Defender for Endpoint のデバイスインベントリと同じ感覚で操作できる。CSVエクスポートも標準装備。

2. Tools Management（ツール許可・ブロック）

エージェントが呼び出せるツール（MCPサーバー、API、内蔵関数）をテナント単位で管理する機能。許可リスト方式で運用し、登録外のツールへの接続をエージェント側のSDKレベルで弾く。社内データ流出の入り口を1箇所に絞る発想だ。

# Tools Management 設定例（PowerShell）
# 承認済みツールのみ許可するポリシーを作成
New-Agent365ToolPolicy `
  -Name "Production-Allowlist" `
  -AllowedTools @("github-mcp", "azure-cli-mcp", "context7") `
  -BlockedTools @("*") `
  -Scope "All Users"

# Frontier program 参加テナント向けに OpenClaw を制限
Set-Agent365ShadowAIPolicy `
  -AgentName "OpenClaw" `
  -Action "BlockOnUnmanaged" `
  -ApplyToGroup "Engineering"

執筆時点ではPowerShellコマンドレットは preview 段階で、GA時点では admin center の GUI が主軸になる。CLI化は2026年後半の予定。

3. Identity Integration（Entra ID 統合）

エージェントを「人」と同じ Entra ID オブジェクトとして扱う。これが地味だが効果が大きい。条件付きアクセス（Conditional Access）、特権ID管理（PIM）、サインインログ、すべての既存仕組みがそのまま使える。新しい IDストアを覚える必要がない。

特に、エージェントごとに「サービスプリンシパル」を発行し、そのプリンシパルにロール（Reader / Contributor）を割り当てる運用が標準化された。これまで API キーで雑に運用していたエージェントを、最小権限ロールに移行する圧力がかかる。

4. Multi-Cloud Registry Sync

AWS Bedrock Agents、Google Cloud の Agent Builder で作ったエージェントを、Agent 365 レジストリに同期する。Microsoft の管理画面1つで、3クラウドのエージェントを横串で見ることができる。AWSコンソールと GCPコンソールを行ったり来たりしていた作業が、相当楽になる。

対応操作はGA時点では「発見・棚卸し・基本ライフサイクル（start/stop/delete）」まで。詳細なポリシー適用は preview 段階で、2026年後半に拡張予定。

5. Compliance Reporting

Purview と統合され、エージェントの操作ログが既存のコンプライアンス基盤に集約される。GDPR、HIPAA、SOC2 などの監査要件で「AIエージェントが何をどう処理したか」を求められた際、別途ログ収集基盤を建てる必要がない。これは大企業の調達条件で効いてくる。

セットアップ手順｜admin center から Intune まで

最短ルートで Agent 365 を立ち上げる手順を5ステップでまとめる。前提として、グローバル管理者ロールと Microsoft 365 E5 以上のテナントが必要だ。

前提条件まとめ

E3 環境では Agent 365 のフル機能は動かない。E3に Agent 365 単体（$15）を足しても、Defender / Intune が前提のため Agent Inventory が動作しない。E5以上が事実上の必須条件だ。

AWS Bedrock / Google Cloud 連携の実態

今回のGAで最大の目玉と公式が打ち出している部分なので、もう一段深く見る。筆者がエンジニアコミュニティの動きを集めた限り、当初の期待値（フルポリシー適用）と実装の間にはまだギャップがあり、過度な期待は禁物だ。

AWS Bedrock 連携で何ができるか

AWSアカウント側でIAMロールを発行し、Agent 365 から AssumeRole する形で接続する。同期対象は Bedrock Agents（Knowledge Bases, Action Groups含む）、Agents for Amazon Bedrock のフロー定義、ガードレール設定。

# AWS側でAssumeRole用のIAMポリシー（最小例）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:ListAgents",
        "bedrock:GetAgent",
        "bedrock:ListAgentAliases",
        "bedrock:DeleteAgent",
        "bedrock:UpdateAgent"
      ],
      "Resource": "*"
    }
  ]
}

DeleteAgent / UpdateAgent を含めるかは判断が分かれる部分。最初はReadOnly（List/Getのみ）で連携し、運用が固まってからWrite権限を追加するのが安全だ。

Google Cloud 連携の制約

GCPは Vertex AI Agent Builder で作成したエージェントが同期対象。サービスアカウントキー（JSON）を Agent 365 にアップロードする方式で、Workload Identity Federation 経由のキーレス接続は GA時点では未サポート。これは GCP 側のセキュリティガバナンスを厳しくしている組織だと躓きやすい。

同期間隔は固定30分。リアルタイムでエージェントを起こした直後に Agent 365 から確認すると、まだ反映されていないケースがある。本格運用では、運用手順書に「30分待ち」を明示しておくと混乱が減る。

マルチクラウド連携で見えるメリット

3クラウド横串でエージェントを棚卸しできるのが何より大きい。これまで「AWSにエージェントがいくつ動いているか」を集計するのに、Bedrock コンソールを覗き、CloudFormation のスタックを眺め、CloudTrail のログを掘る必要があった。Agent 365 のレジストリに来ると、その作業が1画面で済む。

逆に、コスト管理（推論料金、トークン使用量）は同期されない。これは AWS Cost Explorer / GCP Billing 側の領域なので、Agent 365 で完結しないのは妥当な切り分けだ。

Microsoft Agent Framework との使い分け

記事冒頭で表にした通り、両者は使う場面が違う。具体的なフローで見ると役割分担が立体的になる。

逆に、Agent Framework だけ導入して Agent 365 を入れない選択肢もある。それは「個人開発者が Azure 上でエージェントを動かす」ような用途で、企業ガバナンスが要らないケースに該当する。逆方向、つまり Agent 365 だけ導入して Agent Framework を使わないケースは、自社製エージェントを書かず、サードパーティ製のみ管理したい組織で成立する。

どちらを先に検討すべきか

自分の立場が情シス・セキュリティ・コンプラ部門なら Agent 365 が先。自分が開発者・データサイエンティストなら Agent Framework が先。同じ Microsoft 製品でも、誰の業務を楽にする道具かが完全に分かれている。両方詳細を知りたい人は、まずMicrosoft Agent Framework 1.0入門でSDK側を押さえてからこちらに戻ると理解が早い。

Agentforce / ServiceNow / Google との比較

AIエージェント管理プラットフォームは2026年に入って急速に充実した。主要4社の製品を、Microsoft Agent 365 を中心に比較する。

Agent 365 が他社と最も差別化できるのは「他社製・OSS のエージェントまで管理できる」点だ。Salesforce や ServiceNow は自社プラットフォーム内で完結しがちで、組織横断の統制プレーンとしては心許ない。Microsoft 365 をすでに使っている組織なら、Agent 365 が現実解になる。

逆に、Salesforce が顧客接点の主戦場になっている組織では Agentforce が先。両者を共存させ、社内ガバナンスは Agent 365、顧客接点は Agentforce、と棲み分けるのが2026年の典型構成になりそうだ。

他のAIエージェント記事と読み合わせる

エージェント周辺の知識を体系的に整理したい場合、AIエージェント完全ガイド2026でビジネス活用の前提と導入ステップを押さえると、Agent 365 のポジショニングが見えやすい。具体的なエンタープライズ製品としてはOpenAI Workspace Agents 入門、LINEヤフー Agent i 入門も併読すると国内外の比較がつく。

導入で詰まる5つのポイント

公式ドキュメントには出てこないが、現場で必ず踏むハマりどころを5つ挙げる。先回りで知っておくと、検証期間を大きく短縮できる。

運用設計のコツ

いきなり全社展開せず、まず開発・QAの2部門で2週間運用してから広げる。エージェントの実体（誰が、何を、何のために動かしているか）が想像と違うことが多く、最初の2週間でルールが何度か作り直しになる。Microsoftが推奨する展開期間は「最低4週間のpilot」で、これは経験則として妥当な数字だ。

よくある質問

まとめ｜誰が今買うべきか

Microsoft Agent 365 GA は「組織内のAIエージェントが見えなくて困っている情シス」のための製品だ。逆に、エージェントが業務にまだ入っていない組織や、開発者個人で使いたい組織には今すぐ必要ない。

自分なら、Microsoft 365 E5契約済みかつエージェント利用が立ち上がりつつある組織であれば、E7アップグレードか単体追加（$15/user/月）で先行導入する。E7の損益分岐点が「Copilot 50%普及」というのは合理的なライン。Copilot普及率を試算したうえで、5月中に決めて6月のpreview機能リリースに間に合わせる動きが、2026年Q2の合理的な選択になる。

エージェントを「書く側」のSDKを先に押さえたい人はMicrosoft Agent Framework 1.0入門へ。エージェント全般の戦略を整理したいならAIエージェント完全ガイド2026から入るのが効率的だ。MCPサーバーの選定で迷っている場合はMCPサーバーおすすめ2026、Microsoft 365全体のSKUを整理したい場合は主要AIサービス徹底比較もあわせて参照されたい。