Microsoft Scoutとは|常時稼働Autopilotの実像とMicrosoft 365 Copilotとの違い【2026年最新】
Microsoft Scout(マイクロソフト・スカウト)は、Microsoftが2026年6月2日のBuild 2026で発表した同社初の「Autopilot」型AIエージェントです。ユーザーが指示しなくても常時バックグラウンドで動き、Teams・Outlook・OneDrive・SharePoint上の会議調整や期限管理を先回りで進める設計が特徴です。本記事では、Scoutの正体とできること、ファイルやシェルまで操作するデスクトップアプリとしての実体、Microsoft 365 Copilotとの違い、基盤技術のOpenClawとWork IQ、常時稼働ゆえのセキュリティリスク、そしてFrontierとGitHub Copilotライセンスを含む導入条件までを、2026年6月時点の公式情報で整理します。
目次
まとめ:Microsoft Scoutの位置づけと導入前に確認すべき前提
Microsoft Scoutは、呼ばれて答えるMicrosoft 365 Copilotとは別カテゴリの「Autopilot」として、呼ばれなくても動く常時稼働の実行レイヤーを担います。Teamsで対話しながら、デスクトップアプリ経由でローカルファイル・シェル・ブラウザ・MCPサーバーにまで手を伸ばせる点が、従来のCopilotと最も違う部分です。
導入のハードルは現状かなり高く、Frontierプログラムへの参加、Intuneによる端末許可、管理者のオプトイン同意に加えて、Microsoft 365 CopilotとGitHub Copilotの両方のライセンスが必要です。料金体系は未公表で、一般提供(GA)の時期も明らかにされていません。つまり「今すぐ全社展開する製品」ではなく、Frontierで小さく評価しながら、Autopilot前提のAIガバナンスを先回りで設計しておく段階と捉えるのが現実的な前提です。
Microsoft Scoutの正体|常時稼働Autopilotとデスクトップアプリの二面性
Microsoft Scoutを正しく理解する鍵は、「常時稼働のAutopilot」と「実際に手を動かすデスクトップアプリ」という二面性にあります。ニュースでは前者の”AI同僚”像が目立ちますが、公式ドキュメントが描くのはむしろ後者の実行エージェント像です。
Autopilotという新カテゴリと「always-on」設計が意味するもの
MicrosoftはBuild 2026で「Autopilots(オートパイロット)」という新カテゴリを定義し、その第1弾としてScoutを投入しました。Autopilotは、常時アクティブで自律的に動作し、独自のアイデンティティを持ち、毎回プロンプトを受けなくてもユーザーに代わって行動するエージェントを指します。
従来の生成AIが「困ったときに呼び出す相談相手」だったのに対し、Scoutは仕事の流れの中に常駐し、見落としがちな付随業務を自分から拾いに行きます。この「呼ばなくても動く」という設計思想こそが、Copilotとの最大の分岐点です。
Teams常駐とWindows・macOSデスクトップアプリの二面構造
Scoutへの指示や通知のやり取りはTeams上で行い、ユーザーから見れば既存のMicrosoft 365 UIの延長で利用できます。一方で実体は、Windows 11以降とmacOS 12 Monterey以降に対応したデスクトップAIアプリケーションです。
このデスクトップアプリを起点に、Scoutはクラウド(Teams・Outlook・OneDrive・SharePoint)だけでなく、ローカルのファイルやブラウザ、Model Context Protocol(MCP)サーバーにまで到達範囲を広げます。Teamsの中だけで完結するチャットボットではなく、PC上の作業全体に手を伸ばせる構造である点が、競合解説で見落とされがちなポイントです。
指示なしで進む会議調整・資料生成・期限ブロック・停滞検知の4動作
公式が代表例として挙げるScoutの動作は、次の4つに整理できます。いずれも「ユーザー本来の作業」ではなく「段取りや調整といった周辺業務」を取りに行く点が共通しています。
- 会議の調整・スケジューリング:複数拠点・タイムゾーンをまたぐ予定を読み、現実的な会議時間を提案・確保する
- 重要会議のフラグ立てと準備資料の生成:関連メール・ファイル・チャットを集約し、準備資料の下書きまで進める
- 納期に向けた作業時間の自動ブロック:今後の締切を検出し、集中時間をカレンダーに予定として確保する
- 停滞している意思決定のリスク検知:返信待ちやレビュー長期化などの停滞シグナルを表面化させる
Copilotが議事録要約やドラフト作成といった本業の精度を上げるのに対し、Scoutは本業に取りかかる前後の地ならしを担う役割分担になっています。
Scoutが実際に手を動かす範囲|ファイル・シェル・ブラウザ・MCPへの到達経路
Scoutの差別化要素は、調整業務だけでなく、ローカル環境で実際にファイルを書き換えコマンドを実行する点にあります。ここは「Teams常駐の調整役」という説明だけでは見えてこない、開発者エージェントとしての実体です。
ローカルのファイル操作・シェル実行を支える段階的権限設計
Scoutはワークスペース内のWord・Excel・PowerPoint・コードファイルを作成・編集・検索し、ビルドやテスト、スクリプトをシェルコマンドとして実行できます。実行できる範囲は段階的な権限システムで制御され、どのコマンドを自動承認し、どのコマンドに都度承認を求めるかを細かく定義できます。
機密ディレクトリには常に明示的な承認を要求するよう設定でき、ファイルシステム・シェル・ブラウザ・Microsoft 365という能力カテゴリ単位で有効/無効を切り替えられます。自律的に動くからこそ、「何をどこまで自動で許すか」を組織が設計できる構造になっている点が実務上の要です。
Playwrightによるブラウザ自動化とMCP経由の社内システム到達
ブラウザ操作には、Microsoftが開発するE2EテストフレームワークのPlaywrightが使われます。ScoutはWebページの遷移やフォーム入力、Webアプリ操作を自動化でき、その仕組みはAIエージェントとブラウザをつなぐPlaywright MCPの仕組みと同じ系譜にあります。
さらにScoutは、デスクトップアプリ経由でMCPサーバーに接続し、社内データベースやSaaSなど外部システムにも到達できます。標準化された接続プロトコルであるModel Context Protocol(MCP)の基本を押さえておくと、自社の独自システムをScoutの観察・操作対象につなぎ込む設計判断がしやすくなります。社内システムをどこまでMCPで露出させるかは、利便性と情報統制のトレードオフとして最初に決めるべき論点です。
サブエージェント委任・バンドルスキル・Heartbeat自律モードの実体
複雑な作業では、Scoutは専門サブエージェントを並列で起動し、調査やコードレビューを分担させて結果を集約します。標準で搭載されるスキルにはWord・Excel・PowerPoint編集、Microsoft Loop操作、対話型HTMLダッシュボードを生成するWeb Artifacts Builderなどがあり、SKILL.mdファイルを置けば独自スキルも追加できます。
自律モードは2種類です。15〜120分ごとに自動でチェックインして指定プロンプトを実行する「Heartbeat」と、スケジュールや条件をトリガーに独立実行する「Automations」があり、ユーザーが離席している間も処理を進めます。会話をまたいで好みや判断を記憶する点も含め、Scoutは単発の応答ではなく継続的なタスク遂行を前提に設計されています。
Microsoft 365 Copilotとの違い|Reactive層とProactive層の棲み分け
既にMicrosoft 365 Copilotを使う組織が最初に持つ疑問は「Copilotと何が違うのか、置き換えるのか」です。結論から言えば、両者は同じ仕事を別UIで行う関係ではなく、カバーするタイミングと役割そのものが異なります。
呼んで動くCopilotと呼ばずに動くScoutのインタラクション差
Microsoft 365 Copilotはユーザーの指示を起点に動くReactive(受動)型で、Scoutは指示がなくても常時バックグラウンドで動くProactive(能動)型です。Copilotはユーザーの代理として動きますが、Scoutはエージェント自身の独自アイデンティティで動作します。Microsoft 365 Copilotの全体像を踏まえると、両者の違いがより明確になります。
| 項目 | Microsoft 365 Copilot | Microsoft Scout |
|---|---|---|
| 動作モデル | Reactive(呼んだら答える) | Proactive(呼ばなくても動く) |
| 実行タイミング | ユーザーの指示時 | 常時バックグラウンド |
| アイデンティティ | ユーザーの代理として動作 | エージェント自身の独自ID |
| 主な用途 | 文書生成・要約・チャット応答 | 会議調整・期限管理・準備・停滞検知 |
| 動作場所 | M365アプリ内のCopilotペイン | デスクトップアプリ+接続先全体 |
Copilotが本業の精度とスピードを上げるレイヤーであるのに対し、Scoutは本業の前後にある調整を巻き取るレイヤーだと整理できます。
置き換えではなく追加レイヤー|Copilot Studioエージェントとの役割分担
Microsoftは、ScoutをCopilotの置き換えではなく、Copilotエコシステムに常時稼働の実行層を足す位置づけだと説明しています。Copilotが「会話で呼び出すインテリジェンス層」として残り、Scoutはその上で「裏でも動く実行層」として動きます。
Copilot Studioで構築する業務特化エージェントとも棲み分けが必要です。業務特化エージェントが「特定の業務フロー」を担うのに対し、Scoutは「ユーザー個人につくAutopilot」という別軸の存在です。同じユーザーに対して両者が並列で動く前提で、データ参照範囲と承認フローの基準を最初に統一しておくことが、運用設計の初手になります。
Scoutを支える技術基盤と常時稼働ゆえに生じる統制上のリスク
ScoutがAutopilotとして成立する裏には、実行を担うOpenClawと文脈を担うWork IQという二層構造があります。同時に、OSS基盤を採用したことと常時自律で動くことは、新しいリスク面も生みます。技術と統制をセットで把握しておくことが重要です。
OpenClaw|オープンソース基盤と上流貢献というMicrosoftの戦略転換
Scoutの中核は、オープンソースのエージェント基盤OpenClawの上に構築されています。OpenClawは2026年初頭にオープンソースとして公開され、特定のモデルプロバイダーに縛られない設計で、短期間にGitHubで世界的な支持を集めたエージェントフレームワークです。Microsoftはこれを自社で抱え込むのではなく、エンタープライズ向けのポリシー準拠機能をOpenClaw本体に上流貢献しながら活用する方針を打ち出しました。
自社製のランタイムを一から作らず、既に普及したOSS基盤に乗ったこの判断は、Copilotや自社モデルで囲い込んできたこれまでの路線からの転換点です。組織がOpenClawを自前運用する場合でも、自社環境がセキュリティ・コンプライアンス要件を満たしているかを監査可能な形で検証できるようにする、という点も公式に示されています。
Work IQ|M365シグナルから文脈を継続構築するコンテキスト層
Scoutが「次に何をすべきか」を判断する土台が、Microsoft 365のWork IQです。Work IQは、メール・ファイル・会議・チャットといったシグナルから、ユーザーの働き方・関心領域・優先事項を継続的に学習するコンテキスト層として設計されています。
OpenClawがアプリ操作やタスク実行を担う「手足」だとすれば、Work IQは優先事項や関係性を覚える「目と記憶」にあたります。Scoutは単独の巨大モデルというより、OpenClaw(実行層)+Work IQ(文脈層)をMicrosoftが製品として束ねたものと捉えると、構造を読み解きやすくなります。
自律エージェントの攻撃面|プロンプトインジェクションと統制設計
常時稼働で外部データに触れる自律エージェントは、悪意ある第三者が巧妙な指示を仕込むプロンプトインジェクションの標的になりやすいという固有のリスクを抱えます。基盤のOpenClaw自体も、初期の展開でセキュリティ上の指摘や挙動の不安定さが報じられてきた経緯があり、エンタープライズ採用では「便利さ」と同じ温度で「攻撃面」を見る必要があります。
Microsoftはこの懸念に対し、複数の統制を設計に組み込んでいます。各エージェントは共有の匿名アカウントではなく独自のEntra IDで動作し、誰が何をしたかを監査ログ上で個別に追跡できます。社内データを動かす場面ではMicrosoft Purviewの感度ラベルやデータ損失防止(DLP)が送信・書き込みの直前に適用され、違反になり得るアクションそのものを止めます。外部メール送信などの機密アクションには人間の承認を必須にでき、Scoutは外部から取り込んだメールやWebページを「指示」ではなく「データ」として扱う設計になっています。Windows上ではOpenClawを隔離環境で動かす実行コンテナ技術も用意され、PC本体への影響を抑えます。
Microsoft Scoutの導入条件・料金・GA前に企業が整える準備
セキュリティ設計が整っていても、入手経路と費用が読めなければ導入判断はできません。現時点のScoutは限定プレビュー段階であり、要件と費用、そして「待つ間にできる準備」を分けて理解しておくことが重要です。
利用に必要な5条件と対応OS|二重ライセンスというハードル
Scoutを使い始めるには、組織側とユーザー側で複数の条件を満たす必要があります。公式が示す主な要件は次のとおりです。
- Frontierプログラムへの登録(Microsoftの早期アクセス枠。Microsoft 365 Copilotライセンス保有が前提)
- Intuneポリシーの設定(対象デバイスへScout許可ポリシーを配布)
- 管理者のオプトイン同意(利用条件への明示的なアテステーション)
- GitHub Copilotライセンス(Business または Enterprise。利用ユーザーへの割り当てが必要)
- GitHubアカウント(サインインの前提であり、トークン課金の紐づけにも使われる)
注意すべきは、Microsoft 365 CopilotとGitHub Copilotの両方がそろって初めて使える点です。どちらか一方だけではアクセスできません。対応OSはWindows 11以降とmacOS 12 Monterey以降で、現状は両ライセンスを持つ大企業が主な対象になっていると読み取れます。
料金未公表というプレビュー段階の現状とGA前にできる準備
MicrosoftはScout単体のシート単価や使用量課金を公表していません。確定している費用は前提ライセンスのコストのみで、Microsoft 365 Copilot(Enterpriseで1ユーザー月額30ドルの公開価格)とGitHub Copilot(プランによる)が該当します。Scout自体が既存ライセンスに含まれるのか別課金になるのかは、今後の公式発表を待つ必要があります。
提供範囲は「選定顧客向けのプライベートプレビュー」と「Frontier対象組織向けの実験的リリース」の2系統で、一般提供(GA)の時期は未定です。だからこそGA前の今は、Work IQが自社のどのデータを参照しているかの棚卸し、Frontier参加可否を法務・情報セキュリティと判断する社内プロセスづくり、エージェント独自IDの命名・有効化・退職時停止フローの試作といった準備を進めておくと、評価機会が来たときに動きが速くなります。
Google・Anthropicの常駐型エージェントと比べた選定の軸
常駐・作業代行型のエージェントはMicrosoftだけの動きではありません。2026年にはGoogleがWorkspace向けの自律エージェントを、Anthropicが作業を代行するエージェントを相次いで投入しており、「個人につく常時稼働エージェント」がオフィススイートの新たな接点になりつつあります。
選定の軸は、UIの好みよりも自社の基盤との適合性です。Scoutの強みはMicrosoft 365・Entra ID・Purview・Intuneという既存ガバナンス基盤の上で動く点にあり、すでにこれらを運用する組織ほど統制を効かせやすくなります。逆に言えば、どのエージェントを選ぶ場合でも、「どのアクションを自動実行し、どこから人間承認を挟むか」の境界を組織として定義しておくことが、Autopilot時代に共通して問われる準備になります。
Microsoft Scoutに関するよくある質問
Microsoft Scoutについて、検索で多く見られる疑問とその回答を整理します。いずれも2026年6月時点の公式・公開情報に基づきます。
Microsoft Scoutは日本語環境や日本のテナントで使えますか?
Scoutは現在Frontierプログラム経由の限定プレビューで、対応OSはWindows 11以降とmacOS 12以降です。日本のテナントでも、Frontier登録・Intune設定・管理者オプトイン・両ライセンスという要件を満たせば対象になり得ますが、提供範囲は段階的で日本での一般提供時期は公表されていません。日本語対応の詳細を含め、最新の提供状況は公式情報での確認が必要です。
Microsoft Scoutは無料で使えますか?料金はどうなりますか?
Scout単体の料金は未公表です。無料で使える製品ではなく、前提としてMicrosoft 365 CopilotとGitHub Copilotのライセンスが必要なため、実質的にはこれらの契約コストが発生します。Scoutが既存ライセンスに含まれるのか追加課金になるのかは、今後の公式発表を待つ段階です。
Microsoft 365 Copilotがあれば追加契約なしでScoutを使えますか?
使えません。Microsoft 365 Copilotに加えて、GitHub Copilot(BusinessまたはEnterprise)のライセンスが別途必要です。さらにFrontierへの登録、Intuneでの端末許可、管理者のオプトイン同意という複数のゲートを通過して初めて利用できる構造になっています。
Microsoft ScoutとCopilot Studioのエージェントはどう使い分けますか?
Copilot Studioで作るエージェントは「特定の業務フローに特化した専用エージェント」、Scoutは「ユーザー個人につく常時稼働のAutopilot」という別軸の存在です。両者は競合ではなく併存させる前提で、同じユーザーに対する役割境界、データ参照範囲、承認フローの基準を最初に整理しておくと、運用が分断されません。
Microsoft Scoutの基盤であるOpenClawとは何ですか?安全なのですか?
OpenClawは、エージェントが業務アプリやローカルツールを操作するためのオープンソース基盤で、複数のLLMに対応する設計です。初期の展開ではセキュリティ上の指摘もありましたが、ScoutはそのOpenClawにEntra ID個別認証・Purviewによるデータ保護・人間承認・実行コンテナによる隔離といったエンタープライズ統制を重ねて提供されます。安全性は「基盤が安全か」だけでなく、組織がどこまで自動実行を許し、どこで人間承認を挟むかという運用設計に大きく依存します。
関連記事
- GitHub Copilot CLIの全体像と従来ツールからの進化ポイント:Scoutの利用前提となるGitHub Copilotの、ターミナル上で動くエージェント機能を理解できます。
- GitHub MCPサーバーの基本的な仕組みとその利用目的:ScoutがMCP経由で外部システムに到達する仕組みを、GitHub連携の具体例から押さえられます。