Copilot Studio、Copilot Cowork、Microsoft Scout、Work IQ――名前が似ていて、結局何が違うのか分かりづらいと感じたことはありませんか。この記事では、それぞれの位置づけと使い分けを整理します。
この記事でわかること
- 4つの用語の正確な定義と位置づけ
- Computer useとClassic orchestrationの誤解されやすい関係
- 大量データで実際に確認されたClassic系の運用上の落とし穴
- SharePoint上のHTML表示とfetch()失敗の分類
- 要件別の推奨構成
4つの用語を整理する
| 用語 | 位置づけ |
|---|---|
| Copilot Studio Standard harness | Topic、Tool、Knowledge、Agent flow等を組み合わせる業務Agent基盤 |
| Classic orchestration | Trigger phraseでTopicを選択し、Topic内でToolを明示的に呼ぶ決定論寄りの方式 |
| Generative orchestration | ModelがTopicやToolを説明に基づいて選択する方式 |
| Classic experience | Copilot Studioの従来Authoring画面を指す表現。Classic orchestrationとは同義ではない |
| Copilot Cowork | Microsoft 365上で利用者から委任された多段階業務を実行するCloud型体験 |
| Microsoft Scout | Local PCのFile・Shell・BrowserとMicrosoft 365を横断するDesktop Agent（Frontier preview） |
| Work IQ | AgentがMicrosoft 365や外部Systemの組織Data・Context・ToolへPermission-awareにアクセスするIntelligence layer |
機能比較
| 観点 | Copilot Studio Standard | Copilot Cowork | Microsoft Scout | Work IQ |
|---|---|---|---|---|
| 主利用者 | Makerが構築し複数利用者へ公開 | End userが成果を委任 | End userが自分の端末で委任 | Developer/Agent runtime |
| 実行場所 | Cloud。ToolによりCloud PC/Machine | Microsoft 365 Cloud | Windows/macOS Desktop+Cloud | Microsoft 365 service layer |
| 得意な対象 | 反復可能な業務Process、Conversation | Microsoft 365を横断する長いTask | Local file、Shell、Browser、Code | Context構築、M365操作 |
| PC GUI操作 | Computer use Tool経由 | 利用機能に依存 | Browserを制御しLocal Shell/Fileへ直接作用 | GUI Operatorではない |
| 定期実行 | Trigger、Agent flow、Power Automate | Scheduled prompt、Event-driven | Heartbeat/Automation | Long-running workflow向けWorkspaceを提供 |
| 提供状態 | Harness/機能ごとに異なる | Work/School向けは一般提供 | Frontier preview | Usage-based API |
Computer useとCloud PCの誤解しやすい点
Computer useはWeb SiteやWindows ApplicationをVirtual mouse/Keyboardで操作するToolです。APIがないSystemもGUI経由で対象化できるのが大きな利点です。実行MachineとしてCloud PC pool（Entra joinedかEntra hybrid joinedかEntra registeredのいずれかでIntune enrolledされたWindows VM群）を使えます。
重要な訂正
Microsoft Learnの現行文書ではComputer useはStandard harness向けですが、利用条件としてGenerative orchestrationが有効なAgentのみと明記されています。そのため「Classic orchestrationがComputer useを直接選択する」とは言えません。Classic orchestrationは別経路として、TopicからPower Automate Flowを明示呼出しし、Flow側がPC操作を行う構成になります。
Classic orchestrationの利点は、Computer useを自律選択することではなく、PC操作を行うFlowを明示的なTopicと条件の中へ固定できることです。どの入力・承認・Error分岐を通ってPC操作に至ったかを設計しやすくなります。
Classic orchestrationで規則を強制する方法
Classic orchestrationは、GitHub CopilotハーネスやCoworkにある「SKILL.md型の再利用手順をRuntimeが必ず発見・遵守する仕組み」を前提にできません。そのため、守らせたい規則はInstructionsだけではなく、Power Automate Flow内の決定論的処理へ埋め込みます。
Classic Topic
→ 入力を構造化
→ Guard Flowを呼出し
1. Authentication/caller確認
2. Path allowlist確認
3. ETag/Hash/Version確認
4. Schema validation
5. 実処理
6. 再読込と出力検証
7. System Links/Registry更新
8. Audit Event記録
→ 結果CodeでTopic分岐「AIへ忘れないよう依頼する」のではなく、「Guardを通らない限り処理できない」構造に変えることが重要です。
大量データで確認されたClassic系の運用知見
以下は全環境共通の公式Limitではなく、特定のAgent/Connector/Flow/権限/File構造で得られた運用上の観測です。
| 知見 | 症状 | 対策 |
|---|---|---|
| 大量Fileを含むFolder一覧取得 | First pageだけを全件と誤認、Response size超過、Timeout | 全件列挙を通常経路にしない、Page size/CursorをRun Stateへ保存 |
| 1つのExcelへ全台帳集約 | 必要Table取得失敗、同時更新で重複・欠落 | Excelは小規模Queue/Configurationに限定、大量RecordはFolder shardやJSONへ分割 |
| 大きなMarkdownの更新で内容毀損 | 部分Contentを全文として上書き、Concurrent updateで一方の変更が消える | Metadata取得→Size/Hash確認→Full content取得→保存後の再読込検証を必須化 |
SharePoint上のHTML表示とfetch()の失敗分類
「HTMLが開けること」と「HTML内のfetch()が成功すること」は別の判定です。「管理者権限が必要」と一括りするのではなく、次のように分離して確認します。
| 区分 | 確認対象 |
|---|---|
| User access | 閲覧UserがSource fileやSiteへAccessできるか |
| Site permission | HTMLを置いたSiteと取得先Siteで必要Permissionを持つか |
| API delegated permission | User Contextで対象APIを呼ぶScopeがあるか |
| SharePoint admin role | Admin API自体がRoleを要求していないか |
| Tenant policy | Custom Script、CSPでBlockされていないか |
| Browser policy | CORS、Cookie等でBlockされていないか |
CSP違反、Cross-Origin Block、Access token不備などは権限付与だけでは解決しません。
HTML Projectionの推奨レベル
| Level | 方式 | 安定性 | 用途 |
|---|---|---|---|
| 0 | HTMLへ表示Dataを埋め込む | 高 | Snapshot Report |
| 1 | Build時にJSON/Markdownを統合し静的HTML生成 | 高 | 日次Report、設備View |
| 2 | 同一権限境界の静的DataをClient取得 | 中 | 軽量なFilter/Drill-down |
| 3 | SPFx+SPHttpClient等 | 中から高 | 認証付き動的Application |
| 4 | 任意HTML+素のfetch()+外部API | 低 | Productionでは非推奨 |
System LinksのHuman-readable Projectionでは、Level 0またはLevel 1をDefaultとし、最新Dataが必要なInteractive viewだけをSPFx等のGoverned Applicationとして実装します。
Cowork・Scout・Work IQの位置づけ
Copilot Cowork
- 個人単位で複数のMicrosoft 365資料を調査し成果物を作る用途に適する
- Folder作成・File整理・Communication・Briefingを一つの委任Taskとして扱える
- 共有業務Processの厳密なContractや全利用者共通GuardにはCopilot Studio側が適する
Microsoft Scout
- Local workspaceの大量File調査、Script実行、Hash計算、CAD Library等と組み合わせやすい
- SharePointから必要な作業PackageだけをLocalへ取得し、検証後にResultを戻す方式に適する
- Frontier previewであり提供条件はSubject to Change
Work IQ
- Data accessとContext assemblyを簡素化する
- 組織固有のCanonical EntityやCorrection、Approval stateは別途設計が必要
方式選定表
| 要件 | 優先候補 |
|---|---|
| APIがないWindows/Web画面を共有Agentから操作 | Standard harness+Generative orchestration+Computer use+Cloud PC pool |
| PC操作前の質問順序・Approvalを固定 | Classic Topic+Power Automate/Desktop flow |
| Microsoft 365を跨ぐ個人委任Task | Copilot Cowork |
| Local File、Shell、Browser、Codeを横断 | Microsoft Scout |
| 組織DataをAgentへPermission-awareに提供 | Work IQ |
| 組織共通の反復業務を複数利用者へ公開 | Copilot Studio |
| 大量Fileの永続Knowledge Graph | SharePoint+Atomic Record+System Links |
こんな人におすすめ
- Copilot Studioでエージェントを作ろうとしていて、他のCopilot系製品との違いが分からない
- Computer useやClassic orchestrationを誤解したまま設計してしまった経験がある
- SharePoint上のHTMLダッシュボードが思ったように動かず困っている
よくある質問
Q. まず何か、1つだけ導入するなら？
A. 個人の日常業務を楽にしたいならCopilot Cowork、組織共通の反復業務を自動化したいならCopilot Studioが出発点になりやすいです。
Q. Microsoft Scoutは今すぐ使えますか？
A. Frontier previewの位置づけで、Local Administrator権限や対応OS等の前提が公式Get startedに記載されています。導入前に公式要件を確認することをおすすめします。
コメント