Microsoft Scoutとは？特徴や使い方、Copilotとの違いを徹底解説

Microsoft Scout（マイクロソフト・スカウト）は、Microsoftが2026年6月2日のBuild 2026で発表した、同社初の「Autopilot」型AIエージェントです。
常時稼働でTeams・Outlook・OneDrive・SharePointの仕事を追いかけ、会議調整・期限ブロック・準備資料生成・停滞リスクの検知まで、ユーザーが指示しなくても自律的に進める設計が特徴です。
OpenClawオープンソース基盤とWork IQコンテキスト層を組み合わせ、Entra ID個別アイデンティティとMicrosoft Purviewによる統制を備えています。

本記事では、Microsoft ScoutのAutopilotとしての位置づけ、できること、Microsoft 365 Copilotとの違い、OpenClawとWork IQの技術基盤、セキュリティ・ガバナンス設計、Frontier programとGitHub Copilotライセンスを含む提供形態、企業が備えるべきアクションまでを、2026年6月時点の公式情報で体系的に整理します。

既にMicrosoft 365 Copilotを使っている組織と、これからAIエージェントを検討する組織のそれぞれが、自社のフェーズに合った備え方を判断できる構成です。

Microsoft Scoutとは？Build 2026で発表されたMicrosoft初の「Autopilot」エージェント

Microsoft Scout（マイクロソフト・スカウト）は、Microsoftが2026年6月2日のBuild 2026で発表した、同社初の「Autopilot」型AIエージェントです。

公式の位置づけは「always-on personal agent」で、ユーザーが指示しなくてもバックグラウンドで動き、自分の代わりに業務を進めるエージェントとして設計されています。

従来のMicrosoft 365 Copilotが「呼ばれたら答えるアシスタント」であるのに対し、Scoutは「呼ばれなくても動く同僚」に近い性格を持ちます。

Microsoftはこの新カテゴリを「Autopilots」と命名し、その第1弾としてScoutを投入したというのが、Build 2026発表の中核メッセージです。

https://youtu.be/3ff6UtpPQv8?si=T_I1Ee_LwVbF2Ajh

Autopilotという新カテゴリの定義

Microsoftの公式発表では、Autopilotを以下のように定義しています。

• 常時アクティブで自律的に動作する
• 独自のアイデンティティを持ち、ユーザーに代わって行動する
• バックグラウンドに留まり、毎回プロンプトを受けなくても行動を起こす
• 仕事の流れをアプリ・システム横断で理解し続ける

つまり、ユーザーとの対話に立ち上がる「Copilot」とは別に、職場の作業を見続ける常駐型のレイヤーをMicrosoftが新設したと理解するのが正確です。

AIエージェント・自律型AIエージェントという概念自体はIT業界で広く議論されてきましたが、Windowsだけでも14億台超の月間アクティブデバイスを抱えるMicrosoftが、Microsoft 365利用者を含めた巨大な業務PC基盤を前提に「Autopilots」という名前で標準カテゴリ化した点に、今回の発表の戦略的意味があります。

Build 2026での発表ハイライトとScoutの位置づけ

ScoutはBuild 2026の中でも基調的な発表として扱われ、Microsoftが進めるエージェント戦略全体の見通しを示す存在でした。Scout本体と、Build 2026で同時発表された周辺技術の関係を以下に整理します。

発表	内容	Scoutとの関係
Microsoft Scout	Autopilot第1弾。Microsoft 365に統合	本記事の主題
Work IQ APIの一般提供発表（2026年6月16日GA予定）	M365シグナルからユーザー文脈を構築する基盤	Scoutが公式に利用を明示しているコンテキストエンジン
Frontier Tuning	Frontier対象組織向けの個別チューニング	Scoutを含むAutopilot群への将来的な適用が見込まれる周辺技術
Teams Platform協調エージェント	複数エージェントの協調実行	Scoutを含むエージェント群との連携余地が想定される周辺技術

表からわかるように、Scoutが公式に基盤として使うのはOpenClawとWork IQで、Frontier TuningやTeams Platformの協調エージェントはBuild 2026で同時発表された周辺技術という関係です。

Microsoftがエージェント戦略を「単発のプロダクト」ではなく「足場づくり」として進めている点は変わりませんが、各要素とScoutの結び付き方には濃淡があります。

「Scout」という名称の意味

「Scout（スカウト）」は「先回りして偵察し、有用な情報を持ち帰る存在」を指す英語です。

Microsoftは命名の理由を明示的には説明していませんが、「ユーザーが目を向けていない時間帯に、業務の前線を先回りで把握しに行く存在」という製品コンセプトと整合する命名と読み取れます。

事実、Microsoft公式ブログは、Scoutの第一の役割を「stay active in the background, understanding how work gets done across your apps and systems（バックグラウンドで稼働し続け、アプリやシステム横断で仕事がどう進んでいるかを理解する）」と説明しています。

---

Microsoft Scoutでできること——常時稼働で進む業務サポート

Microsoft Scoutの最大の特徴は、ユーザーがプロンプトを送らなくても自分から業務に介入する点です。具体的に何をするかが見えないと「便利そう」で止まってしまうため、本セクションでは公式が明示している4つの基本動作と、Scoutが到達できる範囲を順に整理します。

Scoutが日常的に実行する4つの動作

Microsoft公式ブログが明示している、Scoutの代表的な動作は以下の4つです。

• タイムゾーンを跨いだ会議の調整・スケジューリング
  複数の参加者・複数地域の予定を読み取り、現実的な会議時間を提案・確保する。海外拠点との会議調整に消えていた時間が、ユーザーが介入する前に1段階終わっている状態をつくる。
  
  

• 重要な会議のフラグ立てと準備資料の自動生成
  カレンダー上の重要会議をScout側で識別し、関連メール・ファイル・チャットを集めて準備資料の下書きまで進める。「会議直前に資料を漁る」というよくある時間ロスを後退させる。
  
  

• 納期と作業時間の自動カレンダーブロック
  今後の納期をメール・チャット・プロジェクト情報から検出し、作業に必要な集中時間を予定として確保する。手動の「ブロックタイム入れ」が、Scoutの提案として最初から並ぶ。
  
  

• 停滞している意思決定のリスク検知
  スレッドが止まっている、回答が来ていない、レビュー待ちが長期化している、といった停滞シグナルを浮き彫りにする。マネージャー視点の「気付けば停滞していた」を、停滞中の段階で表面化させる。

4つの動作に共通するのは、いずれも「ユーザーが本来やる作業」ではなく「ユーザーが見落としがちな付随業務」を取りに行く点です。Copilotが本業のドラフトや要約を高速化するのに対し、Scoutは段取りや調整といった周辺業務の地ならしを担う設計になっています。

接続するMicrosoft 365アプリと到達範囲

Scoutが上記の動作を実現できるのは、Microsoft 365の主要アプリケーションに常時接続しているからです。公式が言及している接続先は以下のとおりです。

接続先	利用するデータ
Teams	チャット、チャネル、会議
Outlook	メール、カレンダー、連絡先
OneDrive	個人ファイル、共有フォルダ
SharePoint	チーム・組織のドキュメントとサイト

ここまでは、いわゆる「Microsoft 365 Copilotが既に見ているデータ」と重なります。ScoutがCopilotと異なるのは、これらをユーザー操作のたびに参照するのではなく、バックグラウンドで継続的に観察し続ける点です。

加えて、デスクトップアプリ経由ではローカルリソースやMCP（Model Context Protocol）サーバーまで到達範囲を拡張できます。

• ブラウザ
  ローカルのChromiumベースのブラウザを操作し、Web上の業務ツールに到達する経路を持つ
  
  

• ローカルリソース
  ユーザーPC上のファイル・アプリの状態を読み取れる範囲で参照する
  
  

• MCPサーバー
  Model Context Protocolで接続された外部システム（社内データベース・SaaS等）にも到達できる

つまりScoutは、Microsoft 365内で完結するエージェントではなく、デスクトップアプリを起点にユーザーの作業全体に手を伸ばせる構造です。社内独自のシステムを使う組織でも、MCPで接続すればScoutの観察対象にできる、というのが現時点の到達範囲設計です。

Microsoft社内での先行運用

公式ブログによれば、ScoutはまずMicrosoftの社内従業員が早期体験版を使う形で運用が始まりました。

社内で確認された成果としては、会議調整・リスク検知・「仕事を前に進めるための継続的なナッジ」が挙げられています。Microsoft自身が、自社の組織を「Scoutを業務に組み込んだ場合の動作検証フィールド」として使ったという経緯です。

これは、外部企業が同じようにScoutを評価する際の参考になる評価パターンです。新カテゴリの製品を入れるとき、まず社内のごく限定範囲で会議調整やレビュー停滞検知のような低リスク業務に当てて、組織の反応を観察する段取りは、Scout評価を進めるうえで有効な進め方の一例として捉えるとよいでしょう。

---

Microsoft 365 CopilotとMicrosoft Scoutの違い

Scoutを評価するとき、既にMicrosoft 365 Copilotを使っている組織が最初に持つ疑問は「Copilotと何が違うのか／Copilotを置き換えるのか」です。本セクションでは、両者のインタラクションモデル・実行モード・統制設計の違いを順に整理します。

CopilotとScoutのインタラクションモデルの違い

両者の最大の違いは、ユーザーとの関わり方そのものにあります。以下の表で、Microsoft 365 CopilotとScoutを並べて整理しました。

項目	Microsoft 365 Copilot	Microsoft Scout
インタラクションモデル	Reactive（呼んだら答える）	Proactive（呼ばなくても動く）
実行タイミング	ユーザーの指示時	常時バックグラウンド
アイデンティティ	ユーザーの代理として動く	エージェント自身の独自ID
主な用途	文書生成・要約・チャット応答	会議調整・期限管理・準備・リスク検知
動作場所	M365アプリ内のCopilotペイン	デスクトップアプリ＋接続先アプリ全体

表から読み取れるのは、両者が「同じ仕事を別UIでやる」関係ではなく、「カバーするタイミングと役割そのものが違う」関係にあるということです。Copilotが本業の精度・スピードを上げるレイヤーであるのに対し、Scoutは本業に取りかかる前後の段取りを巻き取るレイヤーになります。

既存Copilot資産との関係——置き換えではなく追加レイヤー

Microsoftが強調しているのは、ScoutがCopilotを置き換えるものではなく、Copilotエコシステムに新しいレイヤーを足す位置づけだという点です。

Microsoft 365 Copilotは引き続き「会話で呼び出すインテリジェンス層」として機能し、Scoutはその上で「常時動く実行層」として動きます。

実際、Scoutはユーザーに通知や提案を投げる際にTeams上で対話を行う設計になっており、ユーザーとの接点という意味ではCopilotと同じM365 UIを使います。違いは「裏でも動いている」ことそのものです。

Microsoft 365 CopilotエージェントやCopilot Studioで構築する業務エージェントとも棲み分けが必要です。前者は「特定の業務フローに沿った専用エージェント」を指すのに対し、Scoutは「ユーザー個人につくAutopilot」という別の軸の存在です。

以下の表で、Microsoft 365 Copilot周辺の主要なエージェント種別を整理しました。

種別	カテゴリ	主な用途	動作モデル
Microsoft 365 Copilot	Copilot（汎用）	文書生成・要約・チャット応答	Reactive
Copilot Studioで作る業務エージェント	Agent	業務プロセス特化（ITサポート/HR等）	Reactive中心
Microsoft 365 Copilot Chat	Copilot（チャット）	部門横断のチャット応答	Reactive
Microsoft Scout	Autopilot	個人の常時稼働サポート	Proactive

同じ「エージェント」でも、Reactiveか Proactiveか、業務プロセス特化か個人サポートか、で棲み分けがあります。Scoutを導入する際は、既存のCopilot Studio製エージェントとの役割境界を最初に整理しておくことが、運用設計の初手になります。

CEO発言で示されたMicrosoftの戦略的位置づけ

Build 2026のキーノートで、CEOのサティア・ナデラ氏はScoutを含むAutopilotを「企業向けのClaw」と表現しました（Impress Watch 2026/06/03）。

ここでの「Claw」はオープンソースのエージェント基盤OpenClawを指していますが、ナデラ氏の発言の趣旨は「個人向けに広がっているOpenClaw的なエージェント体験を、エンタープライズの統制要件に合わせて再構築する」という宣言です。

Copilotとの違いは、技術差以上に「Microsoftが何を獲りに行っているか」の差です。ScoutはCopilotの拡張という枠を超え、個人のAI体験を職場の文脈に持ち込むための起点として位置づけられています。

---

Microsoft Scoutを支える技術——OpenClawとWork IQ

ScoutがAutopilotとして成立するためには、「常時動かす実行基盤」と「文脈を理解するコンテキスト層」の両方が必要です。本セクションでは、それぞれの役割を担うOpenClawとWork IQを順に整理します。

OpenClaw——複数モデルプロバイダー対応のオープンソースエージェント基盤

OpenClawは前身プロジェクトが2025年末に登場し、2026年1月にOpenClawの名称へ移行したオープンソースのエージェントフレームワークです。短期間で世界中の開発者から大きな支持を集め、エージェントが業務アプリやローカルツールを操作するための共通基盤を提供します。特定のモデルプロバイダーに縛られず、複数のLLMバックエンドに対応する設計が特徴です。

MicrosoftはOpenClawを「自社で抱え込む」のではなく「上流に貢献しながら使う」アプローチを取りました。Microsoft公式ブログでは、以下の方針が明示されています。

• ScoutのコアはOpenClawオープンソースの上に構築する
• エンタープライズグレードのポリシー準拠機能をOpenClaw上流に直接貢献する
• 組織は「環境がセキュリティ・コンプライアンス要件を満たしているか」をオープンに検証できる

つまり、Scoutの中核ロジックをブラックボックスにしない方針がここで打ち出されています。これは、エンタープライズが「自分たちが採用するエージェントの動作モデルを監査できる」という運用上の要件に直結する判断です。

Computerworldはこの動きを「OpenClawを乗っ取るのではなく、その上に乗る戦略」と論評しています。OpenClawを中心とするオープンソースエコシステムを、Microsoftがエンタープライズ要件で補完しながら活用する形になっており、過去の「自社製造して囲い込む」スタイルからの転換点でもあります。

Work IQ——ユーザー文脈を継続的に構築するレイヤー

Scoutが「次に何が必要か」を判断するために使うのが、Microsoft 365のWork IQです。

Work IQの公式発表内容はAnnouncing the new Work IQ APIs（Microsoft 365 Blog）で公開されています。

Work IQは、メール・ファイル・会議・チャットのシグナルから、ユーザーの働き方・関心領域・関係性・優先事項を継続的に学習する基盤として設計されています。Microsoft公式は「Work IQ carries work forward, becoming more useful, relevant, and aligned to your priorities」と説明しています。

OpenClawがエージェントの「手足」だとすると、Work IQはエージェントの「目と記憶」の役割を担います。両者の関係を整理すると以下のようになります。

層	役割	担う部分
OpenClaw	実行・アクション層	アプリ操作・ファイル参照・タスク実行
Work IQ	コンテキスト・記憶層	ユーザーの優先事項・関係性・関心領域
Microsoft Scout	Autopilot（ユーザー視点のまとまり）	上記2層を1つの「常時稼働エージェント」として束ねる

このように、Scoutは単独のモデルというより、「OpenClaw＋Work IQの組み合わせをMicrosoftが製品化したもの」と捉えると構造が読み解きやすくなります。

Web IQ・Fabric IQとの関係性（周辺発表）

Build 2026では、Work IQに加えてMicrosoft Fabricを起点とするFabric IQと、Web上の情報をエージェントに与えるWeb IQも併せて発表されました。ただし現時点でMicrosoft公式がScoutの基盤として明示しているのはWork IQまでで、Fabric IQ・Web IQは「Scout周辺で同時発表された関連技術」という位置づけが正確です。

IQ	カバーする情報源	Scoutとの関係
Work IQ	M365内のメール・会議・ファイル等のシグナル	Scoutが公式に利用を明示しているコンテキスト基盤
Fabric IQ	Microsoft Fabric上の構造化ビジネスデータ	Build 2026で同時発表された周辺技術
Web IQ	Web上の最新情報	Build 2026で同時発表された周辺技術

つまり、いまScoutが実際に文脈構築に使うのはWork IQ単独であり、Fabric IQ・Web IQはエージェント時代のデータ層の拡張可能性を示す発表として並んでいる関係です。

「Autopilotがどこまで業務を見にいけるか」がIQ層の広がりに依存することは間違いありませんが、Web IQ・Fabric IQをScoutで使えるかは今後の公式アナウンスで確かめる必要があります。読者の判断としては、まずWork IQの範囲でScoutの動作を理解しておくのが安全です。

---

Microsoft Scoutのセキュリティ・ガバナンス

Autopilot型エージェントを企業導入する際、IT部門が最初に確認するのは「勝手に動くなら、どう統制するのか」です。Microsoftはこの懸念を見越して、Scoutに対するセキュリティ・ガバナンス機構を最初から設計に組み込んでいます。本セクションでは、4つの主要な統制要素を順に整理します。

Entra IDによる独自アイデンティティ

Scoutは、ユーザーアカウントの権限を借りるのではなく、エージェント自身が持つMicrosoft Entra IDのアイデンティティで動作します。これは、共有の匿名サービスアカウントを使う旧来のボット運用とは明確に異なる設計です。

独自アイデンティティを持つことで得られる利点は以下のとおりです。

• どのエージェントが何をしたかが監査ログ上で個別に追跡できる
• ユーザー個人のフル権限ではなく、エージェント用に絞った権限セットを割り当てられる
• エージェントを停止する際に、ユーザーセッションに影響を与えずに切り離せる

つまり、IT管理者は「ユーザーAのScout」を独立した管理対象として扱えるようになります。組織内で複数のAutopilotが稼働するようになっても、操作ログの突合が「人ではなくエージェント単位」で可能になる構造です。

Microsoft Purviewによるデータ保護ポリシーの即時適用

Scoutが社内データを動かす場面では、Microsoft Purviewの感度ラベル・データ損失防止（DLP）ポリシーが送信や書き込みの直前に適用される設計になっています。

Microsoft公式は「data protection policies from Microsoft Purview, including sensitivity labels and loss prevention, are enforced in the moment, before anything is sent or written」と明記しています。これは「事後的にログを取って違反を検出する」運用ではなく、違反になり得るアクションそのものを止める運用設計です。

具体例で言えば、社内機密ラベルの付いたファイルを外部メール宛に添付しようとしたScoutのアクションは、Purviewのルールによって送信前に止められます。Autopilotが自律的に動くとはいえ、データ越境のコントロールはあくまで既存のM365ガバナンス基盤の上に置かれているという理解で問題ありません。

Human sign-off（人間承認）の組み込み

すべてのアクションをScoutが勝手に進めるわけではなく、機密アクションには人間の承認を必須にできる設計が組み込まれています。

ヒューマン・イン・ザ・ループ（HITL）の考え方をAutopilotに落とし込んだ形で、IT管理者がポリシー側で「どのアクション類型は人間承認を求めるか」を定義できます。

実務で押さえるべきポイントは2点です。

• 全アクションを人間承認にするとAutopilotの効率価値が消える
• 一切人間承認を求めないと、行動責任の所在が曖昧になる

つまり、現実的な設計は「どのカテゴリのアクションは即時実行可、どこからは人間承認必須か」の閾値を組織として決めることです。例えば「社内資料の要約はScoutに任せる／外部宛メール送信は必ず人間が確認する」のように、リスクと業務効率の両立点を運用ルール側で持つ形になります。

Intuneでの管理とFrontier access設定

Scoutの有効化・無効化は、IT管理者がMicrosoft Intuneのポリシーを通じて行います（公式: Set up Microsoft Scout with Intune）。

Windows向けにはADMXテンプレート、macOS向けには .mobileconfig のカスタム構成プロファイルが提供されており、両OSをまたいで同じテナント設定を配布できます。

Windowsポリシーの中核は「Allow Clawpilot Frontier access」設定（内部名 AllowScoutFrontierAccess）で、これを有効化したデバイスでのみユーザーがScoutにサインインできます。これが無効または未構成の場合、Frontierユーザーであっても待機画面でブロックされます。
　

Intuneでの Allow Clawpilot Frontier access 設定画面（出典：Microsoft Learn: Set up Microsoft Scout with Intune）

つまり、Scoutを使えるか使えないかは、最終的にIT管理者がIntune側で個別に許可した端末グループに依存します。組織全体に一気に展開する前に、まずパイロットグループだけに権限を絞って試す、というロールアウト設計が標準的な進め方になります。

---

Microsoft Scoutの提供形態と入手方法

セキュリティ設計が整っていても、入手経路と料金がクリアでなければ導入判断はできません。本セクションでは、現時点のScoutの提供チャネル・必要要件・料金状況を整理します。

Frontier programでの限定プレビュー提供

ScoutはMicrosoft 365のFrontier programを通じて提供されています。

Frontier programは、Microsoft 365 Copilotライセンスを持つ組織が「Microsoft最新のAI機能をGA前に評価できる」枠組みで、テナント単位での申し込み制です。

Frontierは早期評価の枠組みであり、対象機能は「preview and subject to change」と明記されています。Scoutも同じ条件下にあり、現時点はあくまで限定プレビューです。

利用に必要な条件

実際にScoutを使い始めるには、組織側とユーザー側でそれぞれ複数の条件を満たす必要があります。Microsoft Learn: Admin access overview for Microsoft Scoutで示されている要件を整理すると以下のとおりです。

要件	概要
Microsoft 365 Copilotライセンス	Frontier program加入の前提条件
Frontier programへの登録	Microsoft 365 admin centerでテナントを登録
Intuneポリシー設定	対象デバイスへのScout許可ポリシー配布
管理者のオプトイン・アテステーション	テナント管理者が利用条件への明示的同意を表明
GitHub Copilotライセンス	Scoutを利用する対象ユーザーへの割り当てが必要
GitHubアカウント	ユーザーがScoutにサインインする前提条件であり、Scoutのtoken billingにも使用される

注目すべきは、Microsoft 365 CopilotとGitHub Copilotの両方のライセンスが必要なうえに、管理者のアテステーション（明示的な利用同意）も別ゲートとして用意されている点です。Microsoft 365 Copilotだけでも、GitHub Copilotだけでも、Scoutにはアクセスできない構造になっています。

これは、Scoutが「Microsoft 365領域の業務支援」と「GitHub Copilot由来の開発者向けAI体験」の延長線上に置かれていることを示唆しており、現時点では両方の契約がある大企業が主な対象になっていると読み取れます。さらに、Scoutのトークン課金はユーザー個々のGitHubアカウントに紐づくため、組織としてはGitHubアカウントの管理ポリシーも合わせて見直しておく必要があります。

Intuneでのセットアップの流れ

IT管理者が実施する手順は、公式ドキュメントSet up Microsoft Scout with Intuneに整理されています。要点は以下のとおりです。

Microsoft Scout ADMX/ADMLテンプレートのIntuneインポート画面（出典：Microsoft Learn: Set up Microsoft Scout with Intune）

• ADMXとADMLのインポート
  microsoft-scout.admx と microsoft-scout.adml をIntune管理センターからImported Administrative Templatesとしてインポート
  
  

• Windows構成ポリシーの作成
  「Microsoft Scout - Frontier access」のような名称でWindows 11以降向けポリシーを作成し、「Allow Clawpilot Frontier access」を有効化
  
  

• macOS用カスタムプロファイルの配布
  microsoft-scout.mobileconfig をDevice channelとしてmacOS Custom profileに登録
  
  

• 対象デバイスへの割り当て
  全デバイス／パイロットグループの単位で割り当て、Intune同期完了後にユーザーがScoutにサインインできることを確認

テンプレートファイルはGitHub上のscout-resourcesリポジトリで公開されており、組織のIT管理者が自分で入手して配布できます。

公開リポジトリで管理用テンプレートを提供する形は、エンタープライズIT管理者にとっては馴染みのあるディストリビューション方式です。Microsoftは新カテゴリのエージェントであっても、配布・管理は既存のIntune運用フローに乗せられるよう設計したことになります。

料金体系は未公表——プレビュー段階の事実

Microsoftは現時点で、Scout単体の料金や追加課金体系を公表していません。公式ブログ・Microsoft Learn・関連報道のいずれにも、Scoutのシート単価や使用量課金の情報は記載されていません。

Computerworldも、Scoutが「Microsoft 365 Copilotサブスクリプションに含まれるのか、別課金になるのか」が現時点で不明であることを指摘しています。

現時点で確定している費用要素は、前述の前提ライセンスのみです。

要素	既存契約コスト
Microsoft 365 Copilot Enterprise	1ユーザーあたり月額$30（参考: Microsoft 365 Copilot Enterprise pricing）。Business・Frontline等の別プランは価格帯が異なる
GitHub Copilot	プランによる（参考: GitHub Copilot料金）
Frontier program	Microsoft 365 Copilotライセンス保有組織がテナント単位でオプトインする早期評価枠。Scout単体の追加課金有無は未公表

つまり現状は、「既にM365 Copilot＋GitHub Copilotの両方を導入している大企業が、Frontier経由でScoutを試す」フェーズです。前述のとおりMicrosoft Learnはトークン課金にユーザーのGitHubアカウントを使う運用にも言及しており、現行ライセンスの範囲ですべてが賄えるかは公式の追加発表を待つ必要があります。Scout自体の追加課金有無も、今後の公式発表を待つ必要があります。

提供範囲とロードマップの現在地

公式ブログによれば、現時点での提供範囲は以下の2系統です。

• 選定された顧客向けのプライベートプレビュー
• Frontier対象組織向けのexperimental release

一般提供（GA）の時期は公表されていません。Microsoftは「今後数カ月のうちにCopilot内にAutopilotによるデジタルチームを構築していく」と説明しており、Scoutはその第1弾として段階的に対象を広げる方針です。

導入を検討している組織にとっては、今すぐ全社展開する話ではなく、Frontierで小さく試して評価する段階だと理解しておくのが現実的です。

---

Microsoft Scout時代に企業が備えること

Scoutが企業に直接届くのはまだ先ですが、「Autopilotが業務に常駐する時代」が見えてきたこと自体は、IT部門・経営層の判断を変える材料になります。本セクションでは、フェーズ別にいま着手できる打ち手を整理します。

フェーズ別の備え方マップ

組織のAI活用フェーズに応じて、Scout時代に向けた優先度高めのアクションは異なります。以下の表で、3タイプに整理しました。

組織タイプ	いますぐやること	Scout世代の判断基準
Microsoft 365 Copilot利用済み組織	Work IQ APIで取得できる文脈情報を整理。Frontier programへの参加可否を法務・情報セキュリティ部門と検討	エージェントの独自IDをEntra ID上でどう設計するかが描けているか
Copilot Studioでエージェントを運用中	既存エージェントとScoutの役割境界を定義（業務特化 vs 個人付き）。Purviewラベル設計を見直す	Autopilotと既存業務エージェントを「同じユーザーに対して」どう並列運用するかを決められているか
AI未導入・検討中組織	M365 Copilot単独からの導入を進める。AIエージェントの基本概念と業務インパクトを部門ごとに共有	Scout相当のAutopilotが標準化した際に「人間が承認するアクション境界」を組織として持てるか

共通しているのは、「Scoutを使うかどうか」よりも、自社のAI統制設計・データ統制設計をAutopilot前提に書き直せるかが問われる、という点です。

既存Microsoft 365 Copilot利用組織がやること

最も手前にいるのは、既にMicrosoft 365 Copilotを契約している組織です。

ここで取るべき手は3つあります。

Work IQで何が見えているかを棚卸しする

Scoutが使う文脈基盤はWork IQです。
自社のWork IQが、どのアプリ・どのファイル・どのチャットを参照しているかをIT管理者が把握しておくことで、Scoutが入ったときに「想定外の情報がエージェントに見られる」事態を避けられます。

Frontier program参加の組織判断を早めに固める

Frontierは特性上、「IT部門の判断だけ」では完結しません。法務・情報セキュリティ・情報システム部門の合意形成が必要になるため、Scout参加の可否を判断する社内プロセスを先に作っておくと、いざ評価機会が来たときに動きが速くなります。

エージェント独自IDの運用ルールを試作する

Scoutが独自Entra IDで動くという設計は、組織内のID管理プロセスに新しい型を持ち込みます。
ユーザーごとのAutopilot ID命名規則・有効化フロー・退職時の停止フローを、まずパイロットグループ向けに試作しておくと、本格展開時の混乱を抑えられます。

これらは、Scoutそのものを使えるかとは別軸で、組織側が今のうちに整理しておける打ち手です。

Copilot Studioで業務エージェントを運用中の組織がやること

Copilot Studioで部門専用エージェントを既に運用している組織は、Scout導入時にエージェント間の役割衝突を整理する必要があります。

具体的には、以下の論点を社内で明文化することが現実的な打ち手です。

• 同じユーザーに対して、業務特化エージェントとAutopilotが並列で動く前提を作る
  業務特化エージェント（例: 営業支援・ITサポート）は「特定の業務」を担当し、ScoutはScout側で「ユーザー個人の段取り」を担当する役割分担を、最初に定義しておく
  
  

• エージェント間のデータ参照ルールを設計する
  業務特化エージェントが扱う社内ナレッジへのアクセス権を、ScoutにもMirroringするのか、あえて分けるのかを決める
  
  

• 承認フローを統一する
  業務特化エージェントとScoutで承認ポリシーが食い違うと、ユーザー体験が分断される。Purview・承認ワークフローの基準を1つにまとめる

「すでにエージェントがいるからScoutは要らない」と判断するのではなく、「業務特化型と個人付きAutopilotは別レイヤーで併存する」という前提で運用設計を準備しておくのが、AI総研の支援現場でも有効だった整理軸です。

AI未導入・検討中組織がやること

Scout時代をいきなり追いかける必要はありません。むしろ未導入の組織にとっては、「Autopilotが標準化される前に、現行のCopilotで業務AIの定着パターンを作っておく」ほうが現実的です。

具体的な打ち手は以下のとおりです。

• M365 Copilotの個別部門導入から始め、業務影響を小さく評価する
• 議事録・要約・メール下書きのような低リスク業務でAIの活用パターンを社内に定着させる
• Autopilotが入る前に、人間が「どのアクションは承認制にするか」のラインを部門ごとに合意しておく

Scoutが一般提供される時期は未公表ですが、AI総研の支援観察として、Autopilot時代に組織が詰まる論点はほぼ「現行Copilot段階で詰まる論点と同じ」です。今のうちに小さく転んでおくほうが、Autopilot本格化後の意思決定スピードを上げられます。

IT管理者が先回りで検討すべき3つの論点

Scoutを「いざ評価したい」となったときに、IT管理者の判断が遅れる典型的な論点は3つあります。

誰がScoutを有効化できるか

Frontier programとIntuneポリシーの両方を扱える権限を持つ管理者は、組織によっては片手で数えられる人数です。
IT管理者の権限分掌をAutopilot前提で見直しておくと、評価サイクルが詰まりません。

どの範囲のメール・ファイルをScoutに見せるか

公式ブログによれば、Scoutは承認済みのリソースや宛先にアクセスを限定する設計が可能とされています。
ただし、これを「機能ベース」ではなく「組織方針」として最初に決めておかないと、現場で「ここは見せたくない」という個別運用が乱立します。粒度（サイト単位かフォルダ単位か等）の詳細は公式の追加情報を確認したうえで運用ルールに落とす必要があります。

どのアクションをHuman sign-off対象にするか

外部メール送信・外部ドキュメント共有・カレンダー上の重要会議の編集など、「Scoutの自動実行を許すか／必ず人間承認にするか」のラインを組織として定義しておくと、ユーザーごとのバラツキを避けられます。

これらの論点は、技術選定の話というよりAIガバナンスの組織設計の話です。Scoutが手元に届いてから決めるのでは遅く、現行のCopilot利用と並行で先回りで議論しておくことが、Autopilot時代に詰まらない組織の条件になります。

---

AIエージェントを業務に定着させるために

Microsoft ScoutのようなAutopilot型エージェントが本格化する前に、企業が取るべき備えは「Scoutを待つ」ことではなく、現行のMicrosoft 365 Copilot・Copilot Studio・GitHub Copilotを業務プロセスに定着させることです。

Autopilot時代に詰まる論点（IDの設計・承認フローの境界・部門間ガバナンス）は、現行のCopilot活用段階で詰まる論点とほとんど重なります。Copilot段階で運用ルールが固まっていれば、Scoutが届いたときの評価サイクルは大幅に短縮できます。

AI総合研究所では、Microsoft環境を起点に業務プロセス全体へAIを定着させるための手順を、220ページのガイドにまとめています。PoCから全社展開までの設計、部門別ユースケース、AI運用における統制・セキュリティのチェックポイントを整理した実装手順書として、Autopilot時代を見据えた自社のAI活用戦略の土台に活用ください。

---

まとめ

本記事では、Build 2026で発表されたMicrosoft Scoutについて、Autopilotとしての位置づけ・できること・Microsoft 365 Copilotとの違い・OpenClawとWork IQの技術基盤・セキュリティ統制・提供形態・企業の備え方までを、2026年6月時点の公式情報で解説しました。要点を改めて整理します。

• Microsoft Scoutは、Microsoftが2026年6月2日に発表した同社初のAutopilot型エージェントで、ユーザーが指示しなくても常時稼働で業務を進めることをCopilotと区別する設計思想に置いている
  
  

• 会議調整・準備資料生成・期限カレンダーブロック・停滞リスク検知の4動作を中心に、Teams・Outlook・OneDrive・SharePointと接続。デスクトップアプリ経由でブラウザ・ローカルリソース・MCPサーバーまで到達範囲を持つ
  
  

• **Microsoft 365 Copilotは「Reactiveな指示対応」、ScoutはAutopilotとして「Proactiveな常時稼働」**という別レイヤーとして併存し、置き換えではなく追加レイヤーとして設計されている
  
  

• 技術基盤はOpenClawオープンソース＋Microsoft 365のWork IQの組み合わせで、Microsoftが自社で抱え込まず、ポリシー準拠機能をOpenClaw上流に直接貢献するアプローチを取っている
  
  

• セキュリティはEntra ID個別アイデンティティ・Microsoft Purviewのリアルタイム適用・Human sign-off・Intuneポリシーの4本柱で構成され、IT管理者が許可範囲・承認ラインを細かく設計できる
  
  

• 入手にはMicrosoft 365 CopilotライセンスとGitHub Copilotライセンスの両方に加え、Frontier program登録・Intuneポリシー配布・管理者のオプトイン/アテステーション・GitHubアカウントが必要で、現時点はプライベートプレビュー／Frontier experimental release段階。Scout単独の料金体系は未公表
  
  

• 企業の備え方は、Copilot既導入組織はWork IQ把握とエージェント独自ID運用の試作、Copilot Studio運用組織は業務特化エージェントとScoutの役割境界の明文化、未導入組織は現行Copilotでの業務定着を先に進めるのが、AI総研の支援観察から見た現実的なルート

Microsoft Scoutは、企業のAI活用が「指示するAI（Copilot）」から「先回りで動くAI（Autopilot）」へと一段進むことを示す象徴的な発表です。実際にScoutを業務に組み込めるかは別として、Autopilot前提でAIガバナンスを書き直す動きを、いまから準備しておくことが、組織のAI競争力を左右する時期に入りました。