Copilot Studio・Cowork・Scout・Work IQ、結局どれを使えばいいのか

記事内に広告が含まれています。

Copilot Studio、Copilot Cowork、Microsoft Scout、Work IQ。名前だけを見ると、どれも「Microsoft 365のデータを使って仕事を自動化するAI」に見えます。

しかし、実際には役割が異なります。Copilot Studioは組織向けエージェントを構築する基盤、Copilot Coworkは利用者が複数ステップの仕事を委任するクラウド型の実行体験、Microsoft ScoutはローカルPCとMicrosoft 365を横断するデスクトップ型エージェント、Work IQはそれらの一部を支える職場コンテキストとツールの基盤です。

この記事では、2026年9月10日時点のMicrosoft公式情報と、筆者環境で確認した運用上の知見を分けながら、それぞれの違いと使い分けを整理します。

最初に結論：4つは同じ種類の製品ではない

重要なのは、Work IQだけはCopilot Studio、Cowork、Scoutと同列の「利用画面」ではないことです。Work IQは、Copilotやエージェントがメール、ファイル、会議、チャット、人物、業務システムなどを関連付けて理解するための基盤です。

Copilot Studio内の用語を整理する

Copilot Studioを理解しにくくしている原因の一つが、「Standard harness」「Generative orchestration」「Classic orchestration」「Classic experience」という似た表現です。

Generative orchestrationとClassic orchestrationの違い

Classic orchestrationは、Generative orchestrationより必ず安全という意味ではありません。安全性や再現性は、Topicの選択方式だけでなく、ToolやFlowの内部で入力検証、権限確認、承認、排他制御、再読込検証をどこまで強制できるかで決まります。

Computer useとCloud PCの誤解しやすい点

Computer useは、Copilot StudioのエージェントがWindows上のWebサイトやデスクトップアプリケーションを仮想マウスとキーボードで操作するToolです。APIが用意されていないシステムでも、人間が画面上で行う操作を対象にできることが大きな利点です。

画面上のボタン選択、メニュー操作、入力欄への文字入力などを、Computer-Using Agentが視覚情報と推論を使って実行します。

Classic orchestrationからPC操作を行いたい場合

Classic orchestrationで質問順序や承認を固定したままPC操作を行いたい場合は、別経路として次のような構成を検討します。

Classic Topic
  → 入力内容を構造化
  → 質問順序と承認をTopic内で固定
  → Power Automate Flowを明示的に呼び出す
  → FlowからDesktop flowや対象の自動化経路を実行
  → 実行結果をTopicへ返す
  → Result codeに応じて分岐

この構成の利点は、Classic orchestrationがComputer useを自律選択することではありません。PC操作へ到達する前の質問、承認、検証、停止条件を明示的なTopicとFlowの中に固定できることです。

Cloud PC poolとは

Computer useでは、実行先としてCloud PC poolを構成できます。ただし、Cloud PC pool、通常のWindows 365 Cloud PC、Power AutomateのHosted machine、利用者のローカルPCを同じものとして扱うことはできません。

必要な接続方式、デバイス管理、参加状態、ライセンス、地域、利用可能なModelなどは変更される可能性があります。導入時には、Computer useとCloud PC poolの最新要件をMicrosoft Learnで個別に確認する必要があります。

Copilot Studioで規則を強制する方法

Copilot StudioのInstructionsには、エージェント全体の目的、Toolの使い分け、回答方針などを記述できます。しかし、ファイル上書き禁止、Path制限、Hash一致、承認必須などの重要な規則を、自然言語のInstructionsだけに依存させるべきではありません。

特にClassic orchestrationでは、CoworkやMicrosoft ScoutにあるSKILL.md形式の手順をRuntimeが自動発見して利用する仕組みを前提にできません。必ず守らせたい規則は、Topic、Power Automate Flow、Desktop flow、Connector、Dataverse、SharePointなどの決定論的な処理へ埋め込みます。

Classic Topic
  → 入力を構造化
  → Guard Flowを呼び出す
     1. AuthenticationとCallerを確認
     2. Path allowlistを確認
     3. Session、Claim、Lockを確認
     4. ETag、Version、Size、Hashを確認
     5. Schema validationを実行
     6. 許可された処理だけを実行
     7. 保存後に再読込して出力を検証
     8. System LinksやRegistryを更新
     9. Audit Eventを記録
  → Result codeでTopicを分岐
  → 不一致時はBlockedとして停止

重要なのは、「AIに忘れないよう依頼する」ことではなく、「Guardを通らない限り処理そのものを実行できない」構造へ変えることです。

大量データで確認したClassic系の運用知見

全件列挙よりSystem Linksを優先する理由

ファイル数が増えると、「ルートからすべてを列挙して目的のファイルを探す」方式は、取得上限、応答サイズ、Timeout、Pagination漏れの影響を受けやすくなります。

そのため、既知のPath、File ID、Node ID、親子関係、Canonical entity、関連RepositoryなどをSystem Linksとして保持し、必要な情報へ直接移動できる構成が有効です。

ただし、System Links自体が誤っていれば誤った対象へ到達します。リンク更新時には対象の存在確認、ID確認、Version確認、Link先の再読込が必要です。

SharePoint上のHTML表示とfetch()の失敗分類

SharePointへHTMLファイルを置いた場合、「HTMLファイルを開けること」と「HTML内部のJavaScriptからfetch()で別のデータを取得できること」は別の判定です。

HTMLが表示されたからといって、任意のAPIや別Siteのファイルを取得できるとは限りません。また、fetch()が失敗したからといって、直ちにSharePoint管理者権限が不足しているとも限りません。

CSP違反、Cross-Origin Block、TokenのAudience不一致などは、利用者へSite権限を追加するだけでは解決しません。BrowserのDeveloper ToolsでConsole、Network、Response header、Request originを分けて確認する必要があります。

HTML Projectionの推奨レベル

System LinksのHuman-readable ProjectionではLevel 0またはLevel 1をDefaultとし、常に最新データを必要とするInteractive viewだけをSPFxなどのGoverned Applicationとして実装する方が安定します。

Copilot Coworkとは

Copilot Coworkは、利用者が自然言語で望む成果を伝えると、Microsoft 365上の複数ステップの仕事を計画し、実行するクラウド型の体験です。

• Outlookのメール作成や送信
• 会議の作成やCalendarの管理
• Word、Excel、PowerPoint、PDFの作成
• Teamsへの投稿
• OneDriveやSharePoint上のFile検索、作成、整理
• 複数Sourceを使った調査とReport作成
• Daily briefingやMeeting intelligenceの作成
• Scheduled promptやEvent-driven taskの実行

CoworkはWork IQを利用し、利用者がアクセスできるメール、会議、ファイル、チャット、業務データなどを仕事の文脈として扱います。重要な操作や機密性の高い操作では、実行前に利用者へ承認を求めます。

Coworkが向いている用途

• 複数のMicrosoft 365資料を調査して成果物を作る
• 調査、文書作成、共有までを一つの委任Taskとして依頼する
• Inbox整理、Calendar調整、Briefing作成をまとめて任せる
• 個人や少人数で、長い作業をクラウド上で進める
• SKILL.md形式のCustom skillで作業手順を再利用する

Copilot Studioとの違い

Coworkは、利用者がその場で仕事を委任する体験です。一方、Copilot Studioは、Makerが業務Agent、Tool、Knowledge、Flow、認証、公開範囲を設計し、複数利用者へ提供するための基盤です。

Team全体で共通の入力Contract、承認、停止条件、監査、Connector、公開管理を持たせたい場合はCopilot Studioが適します。利用者ごとに異なる資料を使い、その場で成果物を完成させたい場合はCoworkが適します。

Coworkの提供状態

2026年9月10日時点のMicrosoft公式情報では、WorkまたはSchool account向けのCoworkは一般提供、Personal account向けはPreviewです。ただし、利用には対象License、管理者による有効化、Usage-based billingやCopilot Creditsの設定などが関係します。

Microsoft Scoutとは

Microsoft Scoutは、WindowsとmacOSで動作するデスクトップ型AIエージェントです。ローカルのWorkspace、Shell、Browser、開発ツール、Microsoft 365を横断して作業します。

• Workspace内のFileを読取、作成、編集、検索する
• Shell command、Build、Test、Scriptを実行する
• Codebaseを調査し、Patch適用やDebugを行う
• Browserを操作し、Page遷移、Form入力、Snapshot取得などを行う
• Outlook、Teams、OneDrive、SharePoint、Meeting等へ接続する
• HeartbeatやAutomationで定期的、継続的に処理する
• Sub-agentへ処理を委任する
• SKILL.md形式のCustom skillを利用する

Scoutが向いている用途

• Local workspaceにある大量Fileの調査
• Python、PowerShell、CLI等を使った解析や検証
• Hash計算、差分比較、Build、Test、Lint実行
• CAD Library、Source code、Local toolとMicrosoft 365を組み合わせる
• SharePointから作業Packageを取得し、Localで検証して結果を戻す
• 利用者のPC上で継続的なAgent運用を行う

ScoutとComputer useの違い

Computer useはCopilot Studioに追加するGUI操作用のToolです。Microsoft Scoutは、それ自体がLocal file、Shell、Browser、Microsoft 365を横断するデスクトップAgentです。

両者ともBrowser操作を行えますが、Computer useはCopilot Studio AgentのToolとして構成されるのに対し、ScoutはLocal workspaceとShellを含む独立したデスクトップ実行環境を持ちます。

Scoutの提供状態

2026年9月10日時点ではFrontier previewです。Microsoft LearnではPre-release documentationとして扱われ、機能、提供地域、利用条件、必要Licenseが変更される可能性が明記されています。

公式のGet startedでは、Frontier previewへの参加、対応OS、WorkまたはSchool account、Microsoft 365 Copilot access、Local Administrator権限、Windows環境ではVisual C++ Redistributable、GitHub Copilot BusinessまたはEnterprise License、管理者側の事前設定などが前提として記載されています。

したがって、Scoutを本番業務の唯一の実行基盤にする場合は、Previewであること、Client更新、権限管理、監査、Rollback、代替経路を含めて評価する必要があります。

Work IQとは

Work IQは、CopilotとAgentが組織の仕事を理解するための職場インテリジェンス層です。Microsoft 365と外部システムのデータ、コンテキスト、ツールを関連付け、権限を考慮した状態でAgentへ提供します。

Work IQは、単なる検索APIではありません。Microsoft公式情報では、主に次の要素で説明されています。

• Chat：会話、Agent間委任、継続性を支える
• Context：組織データからAgentが利用しやすいContextを組み立てる
• Tools：Microsoft 365のData取得や操作をAgent向けのToolとして提供する
• Workspaces：長時間Workflowの中間Dataや出力を保持する永続領域を提供する

「Work IQ」という言葉の3つの使われ方

このため、「Work IQはUsage-based APIである」という説明だけでは不十分です。Microsoft 365 Copilotの体験に組み込まれるWork IQと、Custom Agent向けに従量課金で提供されるWork IQ APIは分けて考える必要があります。

Work IQだけでは業務正本にならない

Work IQは組織内のContextを組み立て、関連情報をAgentへ提供するための基盤です。しかし、組織固有のCanonical entity、正式状態、承認状態、Correction、Version、排他Lock、System Linksの正本を自動的に設計してくれるわけではありません。

次のような情報は、SharePoint、Dataverse、Microsoft Lists、SQL、Atomic JSONなどで別途管理する必要があります。

• 正式なProject IDやEquipment ID
• 承認済みと下書きの区別
• FileのCanonical location
• Session、Claim、Lock、ETag、Hash
• Correction record
• Decision LogやLedger Journal
• System LinksとNode Registry

機能比較

要件別の方式選定

現在の実運用で現実的な構成

GitHub CopilotのSandboxで実行していたPython解析や成果物生成をClassicエージェント単体へ移すことはできません。一方、Copilot ChatにはPython解析やファイル生成に利用できる実行環境があり、ClassicエージェントはMicrosoft 365上のFile取得、Metadata確認、更新、公開、監査に向いています。

そのため、現時点では次のように役割を分ける構成が現実的です。

Copilot Chat
  → Python解析
  → 比較、変換、可視化
  → HTMLや成果物を実ファイルとして出力
  → 長文Instruction fileを作成

Human-controlled handoff
  → 2,000字以内の短縮起動文を転送
  → 書込みや切替の承認を管理

Classic Agent
  → Instruction fileを完全一致で取得
  → File ID、Size、ETag、Hash、本文末尾を検証
  → Microsoft 365上の許可された処理を実行
  → Result Packageを返却

Copilot Chat
  → Result Packageを再解析
  → 完了、Blocked、Failed、Inconclusiveを判定
  → 次工程を決定

この方式は完全自動ではありませんが、GitHub Copilotで行っていた解析能力と、ClassicエージェントのMicrosoft 365操作能力を、安全条件付きで組み合わせられます。

将来Microsoft Scoutが一般提供され、組織のLicense、Security、Intune、GitHub Copilot、監査要件を満たせる場合には、この手動Handoffの一部をScoutへ置き換えられる可能性があります。ただし、System Links、Lock、Result Package、検証手順などの永続的な業務Contractは、特定のHarnessへ依存させない方が移行しやすくなります。

よくある選定ミス

1. Work IQを新しい業務Agent製品だと考える

Work IQは主としてCopilotやAgentへ仕事のContextを提供する基盤です。業務Agentの画面やProcessそのものではありません。

2. Classic orchestrationならすべてが決定論的だと考える

Topicの選択や分岐を固定しても、呼び出すConnector、Flow、External API、生成AI処理が非決定的であれば、全体が完全に決定論的になるわけではありません。

3. Classic TopicからComputer use Toolを直接呼べると考える

現行のMicrosoft LearnではComputer useはGenerative orchestrationが有効なAgentに限定されています。ClassicではPower AutomateやDesktop flow等の別経路を検討します。

4. Coworkを組織共通Processの設計基盤として扱う

CoworkはEnd userが仕事を委任する体験です。全利用者共通の厳密な入力Contract、共有Guard、Connector管理、公開管理にはCopilot Studioが適します。

5. Scoutを正式な一般提供製品として本番前提にする

2026年9月10日時点ではFrontier previewです。機能や要件が変更される可能性を前提に、代替経路とRollbackを設計する必要があります。

6. Work IQが業務上の正本とCorrectionを自動管理すると考える

Work IQはContextを構築しますが、正式状態、承認済みVersion、Canonical entity、Correction recordなどの業務正本は別途設計が必要です。

こんな人におすすめ

• Copilot StudioでAgentを作ろうとしているが、CoworkやScoutとの違いが分からない
• Computer useとClassic orchestrationを組み合わせられると考えて設計していた
• Microsoft 365を跨ぐ個人Taskと、組織共通Processを分けて考えたい
• ローカルのPython、Shell、Browser処理とMicrosoft 365を連携したい
• 大量ファイルを扱うAgentでPagination、Timeout、Excel競合に困っている
• SharePoint上のHTML Dashboardでfetch()が失敗している
• GitHub CopilotからMicrosoft系Agentへ段階的に運用を移行したい

よくある質問

Q. まず1つだけ導入するなら、どれがよいですか？

A. 個人の日常業務をまとめて委任したい場合はCopilot Cowork、組織共通の反復業務を作成して複数利用者へ公開したい場合はCopilot Studioが出発点になりやすいです。

ローカルファイル、Shell、Code、Browser操作が中心の場合はMicrosoft Scoutが候補になりますが、2026年9月10日時点ではFrontier previewであることを考慮する必要があります。

Q. Work IQだけを導入すればAgentを作れますか？

A. Work IQはAgentへ組織Data、Context、Toolを提供する基盤です。利用者向けのAgent体験、業務Flow、Toolの入力Contract、承認、正本Dataなどは、Copilot Studio、Custom application、Cowork、Scout、Dataverse、SharePoint等と組み合わせて設計します。

Q. Classic orchestrationは今後使わない方がよいですか？

A. 一概には言えません。曖昧な依頼から複数のToolを動的に組み合わせる用途にはGenerative orchestrationが適します。一方、質問順序、承認、停止条件、結果Codeの分岐を明示的に設計する用途ではClassic orchestrationが有効です。

ただし、ClassicかGenerativeかにかかわらず、破壊的操作や正式Data更新の安全性はToolやFlowのGuardで確保する必要があります。

Q. Classic orchestrationでComputer useを使えますか？

A. 2026年9月10日時点のMicrosoft Learnでは、Computer use ToolはGenerative orchestrationが有効なAgentに限定されています。Classic orchestrationでは、TopicからPower Automate Flowを明示的に呼び出し、Flow側からDesktop flow等を実行する代替構成を検討します。

Q. Copilot CoworkとMicrosoft Scoutの最大の違いは何ですか？

A. CoworkはMicrosoft 365を中心にクラウド上で複数ステップの仕事を委任する体験です。Scoutはデスクトップ上でローカルファイル、Shell、Browser、開発ツール、Microsoft 365を横断するAgentです。

Q. Microsoft Scoutは今すぐ使えますか？

A. Frontier previewへの参加、管理者設定、対応OS、必要License、Local Administrator権限などの条件を満たす利用者が対象です。一般提供製品と同じ前提ではないため、導入前に最新のGet startedと管理者向け要件を確認してください。

Q. SharePointにHTMLを置けばDynamic Dashboardを作れますか？

A. 静的HTMLの表示と、JavaScriptによる認証付きData取得は別です。Snapshot用途ではDataを埋め込んだ静的HTMLが安定します。動的な認証付きApplicationが必要な場合は、SPFxや適切なAPI Clientを利用し、CSP、CORS、Token、Permissionを個別に設計する必要があります。

まとめ

• Copilot Studio：組織固有のAgentと反復業務を構築し、複数利用者へ公開する基盤
• Copilot Cowork：Microsoft 365上の複数ステップ業務をEnd userが委任するCloud型体験
• Microsoft Scout：Local file、Shell、Browser、Code、Microsoft 365を横断するDesktop Agent
• Work IQ：CopilotとAgentへ組織Data、Context、Toolを提供するIntelligence layer

どれか1つが他のすべてを置き換えるわけではありません。個人委任、組織共通Process、Local処理、Context基盤という役割を分け、必要に応じて組み合わせることが重要です。

また、AgentのInstructionsやMemoryだけに、正本、全件保証、排他制御、承認、監査を任せるべきではありません。重要な業務規則は、Flow、Storage、Version、Hash、System Links、Audit logなど、Agentの種類が変わっても残る決定論的な仕組みとして実装する必要があります。

参考資料

• Microsoft Learn：Generative orchestrationとClassic orchestration
• Microsoft Learn：Computer use
• Microsoft：Copilot Cowork
• Microsoft Learn：Microsoft Scout
• Microsoft Learn：Microsoft Scout Get started
• Microsoft Learn：Work IQ overview

本記事の製品情報と提供状態は2026年9月10日時点です。PreviewおよびFrontierの機能、License、対応地域、前提条件は変更される可能性があります。導入時には各Microsoft公式資料の最新版を確認してください。