本稿では、2026年5月6日に確認対象となったMicrosoft Learnの「Copilot Cowork common questions (Frontier)」をもとに、Microsoft 365 Copilot Coworkで何が変わるのかを整理します。結論から言うと、Coworkは「質問に答えるCopilot」ではなく、メール送信、会議調整、文書作成、Teams投稿、組織内検索などの複数ステップ業務をユーザーの代わりに進めるエージェント型機能です。公式情報ではプレビュー機能であり、早期アクセスにはFrontier preview programへの参加が必要とされています。(Microsoft Learn)
特に管理者は、全社展開の前に「誰に見せるか」「どのプラグインを許可するか」「Anthropicモデルを利用できる状態か」「DLPや監査ログで追跡できるか」を確認する必要があります。開発者は、SKILL.mdによるカスタムスキルやMicrosoft 365アプリパッケージとしてのプラグイン開発を見据えつつ、まずは限定ユーザーで検証するのが安全です。
MicrosoftのAI/Copilot更新で何が変わるのか、利用者と管理者向けに整理
Copilot Cowork common questions (Frontier)で最も重要なのは、CoworkがCopilot Chatとは役割の異なる「作業実行型」のCopilotとして位置づけられている点です。Copilot Chatは下書き、要約、質問回答などの単発支援に向いています。一方、CoworkはMicrosoft 365環境をまたいで複数ステップの作業を進めるため、導入時のリスク管理も変わります。(Microsoft Learn)
| 比較項目 | Copilot Chat | Microsoft 365 Copilot Cowork |
|---|---|---|
| 主な役割 | 下書き、要約、Q&A、アイデア出し | メール送信、会議設定、文書作成、Teams投稿などの業務実行 |
| 得意な作業 | 1回の会話で完結する単発タスク | 複数アプリ・複数データをまたぐ作業 |
| 所要時間の目安 | 数秒〜数分 | 数分〜数時間の自律実行 |
| 管理上の観点 | 情報アクセス、生成内容の確認 | 権限、承認、プラグイン、外部接続、監査、DLPの確認 |
| 向いている利用例 | 会議要約、メール文案、資料のたたき台 | 受信箱整理、会議準備、プロジェクト立ち上げ、定例レポート作成 |
実務上は、「Copilotに文章を作ってもらう」段階から、「Copilotに作業プロセスの一部を任せる」段階に進むと考えると分かりやすいです。たとえば、会議メモを渡して「関係者へのフォローアップメールを作成し、次回会議を調整し、議事録をWord文書にまとめる」といった依頼が想定されます。ただし、送信や投稿など影響の大きい操作では承認が求められるため、利用者側の確認フローを省略してよい機能ではありません。(Microsoft Learn)
まず確認すべき前提条件
CoworkはMicrosoft 365 Copilotで利用する機能ですが、通常の一般提供機能として扱うのではなく、Frontierのプレビュー機能として理解する必要があります。Microsoftは、Frontierを一般公開前の実験段階のAI機能を早期に利用するためのプログラムとして説明しており、組織ではテナントレベルで有効化やアクセス管理を行う形になります。(Microsoft Adoption)
利用前に確認すべき前提は次のとおりです。
| 確認項目 | 確認内容 | 実務上の注意点 |
|---|---|---|
| Frontier参加 | 対象ユーザーまたは管理者がFrontier preview programに参加しているか | 管理者アカウント自体がFrontierに参加していないと、管理画面でCoworkが見えない場合があります |
| Microsoft 365 Copilotライセンス | 対象ユーザーに有効なMicrosoft 365 Copilotライセンスが割り当てられているか | パイロット対象者を先に決め、ライセンス割り当てを整理してから展開します |
| Coworkの可用性 | Microsoft 365 Copilot環境でCoworkが有効か | Microsoft 365 admin centerのAgent管理で確認します |
| Anthropicモデル | テナントでAnthropicモデルの利用が許可されているか | CoworkはAnthropicモデルをサブプロセッサとして利用するため、地域・テナント設定の確認が必要です |
| 利用環境 | ブラウザ、デスクトップアプリ、モバイルアプリで利用できるか | 利用者向けの手順書では、実際に使わせる入口を1つに絞ると混乱を減らせます |
公式FAQでは、Coworkが見えない場合は管理者アカウントもFrontierに登録されているかを確認するよう案内されています。管理センターで設定が見つからない場合、機能が存在しないと判断する前に、ライセンス、Frontier参加、管理者アカウントの状態を順番に確認しましょう。(Microsoft Learn)
管理者への影響範囲
Coworkの導入で管理者に求められる作業は、単なる機能オン・オフではありません。エージェントがMicrosoft 365内の作業を進めるため、ユーザー範囲、プラグイン、外部接続、監査、DLP、データ所在地まで含めて確認する必要があります。
Coworkの公開範囲を制御する
Microsoftの管理者向け情報では、Coworkは既定でライセンスを持つユーザーがAgent Storeから見つけてインストールできる状態とされています。管理者はMicrosoft 365 admin centerの「Copilot > Agents > All agents」からCoworkを管理し、全ユーザー、特定ユーザーまたはグループ、ブロックのいずれかを選択できます。(Microsoft Learn)
全社展開よりも、まずはセキュリティグループを使った段階展開が現実的です。特に日本企業でよくある「部署単位」「拠点単位」「役職単位」の展開では、地理的な条件指定ではなく、Microsoft Entra IDのセキュリティグループで対象者を表現する設計が重要です。公式情報でも、国または地域ベースのスコープ設定はサポートされず、地理的または組織的なセグメントはセキュリティグループで表すよう説明されています。(Microsoft Learn)
事前インストールとピン留めは分けて考える
Coworkは、ユーザーが自分で追加するだけでなく、管理者が対象ユーザーに事前展開できます。さらに、Copilotのレールにピン留めして常時表示させることもできます。ただし、展開とピン留めは別の操作です。公式情報では、ピン留めするには先にエージェントが展開されている必要があるとされています。(Microsoft Learn)
おすすめの進め方は次の順序です。
| フェーズ | 管理者の操作 | 目的 |
|---|---|---|
| 検証 | 特定グループだけにCoworkを利用可能にする | 業務影響、承認フロー、ログ取得を確認する |
| パイロット | 対象グループに事前展開する | 利用者がAgent Storeで探す手間を減らす |
| 定着化 | 必要なユーザーにピン留めする | 日常業務の入口として使いやすくする |
| 拡大 | 利用ログ、問い合わせ、失敗例を見て対象範囲を広げる | 無秩序な全社展開を避ける |
展開時に注意したいのは、「見えるようにする」と「使いこなせるようにする」は別だという点です。Coworkは複数ステップの業務を実行するため、利用者には承認画面の読み方、送信前確認、ファイルの扱い、プラグイン接続の意味を説明する必要があります。
セキュリティとコンプライアンスで確認すべきポイント
Coworkは、Microsoft 365アカウントで許可された範囲のデータやサービスにアクセスします。公式FAQでは、Coworkの各アクションはMicrosoft 365アカウントを通じて認可され、ユーザーがすでに権限を持つサービスやデータだけにアクセスすると説明されています。(Microsoft Learn)
送信・投稿・会議設定は承認前レビューを徹底する
Coworkは、メール送信、Teams投稿、会議設定などの機密性が高い操作の前に承認プロンプトを表示します。中リスク・高リスクの操作ではリスクレベルも表示され、必要に応じてパラメータを確認できます。(Microsoft Learn)
利用者に伝えるべきポイントは次の3つです。
| 確認項目 | 見るべき内容 | 失敗しやすい例 |
|---|---|---|
| 宛先 | メール、Teams投稿、会議招待の対象者 | 同姓同名や外部ユーザーを誤って含める |
| 内容 | 送信文、投稿文、会議説明、添付資料 | 未確定情報や社外秘情報が含まれる |
| 操作範囲 | 今回だけ承認するのか、同様の操作で確認を省くのか | 「Don’t ask again」を安易に選び、以後の確認が甘くなる |
特に「承認を求められたから安全」ではなく、「承認画面で何を確認すべきか」を教育することが重要です。送信前のレビュー責任は、最終的には利用者に残ると考えて運用ルールを作りましょう。
ファイル制限と保存場所を理解する
CoworkはWord、Excel、PowerPoint、PDF、Markdown、画像、コード、音声、動画、アーカイブなど幅広いファイル形式を扱えます。一方で、ローカル端末上のファイルにはアクセスまたは編集できず、OneDriveやSharePoint上のファイルを中心に扱います。添付ファイルは200MB未満である必要があり、暗号化されたファイルはユーザーに権限があっても読み取れないとされています。(Microsoft Learn)
管理者は、利用者向けガイドに次のような基準を入れておくと混乱を防げます。
| 業務シーン | 推奨する扱い | 理由 |
|---|---|---|
| 会議資料の要約 | SharePointまたはOneDrive上の対象ファイルを指定する | 権限管理と履歴管理を既存のMicrosoft 365に寄せられる |
| 顧客情報を含む資料 | 秘密度ラベルとDLPポリシーを確認してから利用する | 意図しない処理や共有を避ける |
| ローカルに保存された資料 | そのまま扱わせず、組織のルールに沿ってクラウドに配置する | Coworkはローカルファイルの編集には対応しません |
| 暗号化ファイル | 必要なら別の安全なレビュー手順を用意する | Coworkでは読み取れない可能性があります |
DLP、監査ログ、データ所在地を確認する
管理者向け情報では、Microsoft Purview DLPポリシーがCoworkを含むCopilotエージェントのやり取りに適用され、機密情報の処理をブロックできるとされています。また、Microsoft Purview監査ログにはCoworkとのやり取りがCopilotアクティビティとして記録され、エージェント名、エージェントID、バージョンが含まれると説明されています。(Microsoft Learn)
さらに、Coworkの会話コンテンツは既定でテナントのローカルリージョン地理内に保存され、Advanced Data ResidencyやMulti-Geo構成もサポートされるとされています。(Microsoft Learn)
導入前に最低限確認したい項目は、次のとおりです。
| 項目 | 確認すること |
|---|---|
| Purview DLP | 機密情報タイプ、秘密度ラベル、Copilot関連のDLP適用範囲 |
| 監査ログ | Cowork利用時のログが取得できるか、SOCや監査担当が確認できるか |
| データ所在地 | 自社のデータ所在地要件とCoworkの保存仕様が矛盾しないか |
| 情報分類 | Coworkに扱わせてよい情報、扱わせない情報を明文化しているか |
| インシデント対応 | 誤送信、誤投稿、不要な外部接続が起きた場合の連絡先と手順 |
Anthropicモデル設定は見落としやすい
Copilot Cowork common questions (Frontier)では、CoworkがAnthropicモデルをサブプロセッサとして利用することが明記されています。関連するMicrosoft Learnの説明では、AnthropicがMicrosoftのサブプロセッサとしてオンボードされ、Microsoft Product TermsやDPAなどの枠組みの下で扱われるとされています。(Microsoft Learn)
ここで重要なのは、地域やクラウド種別によって既定値や利用可否が異なることです。Microsoftは、多くの商用クラウドではAnthropicモデルを既定で有効化する一方、EU/EFTAおよび英国では既定で無効、政府クラウドやソブリンクラウドでは利用できないと説明しています。(Microsoft Learn)
管理者は、次の判断を先に済ませておきましょう。
| 判断ポイント | 確認内容 |
|---|---|
| 自社テナントでAnthropicモデルを使うか | 法務、セキュリティ、プライバシー担当と確認する |
| 対象ユーザーを制限するか | Microsoft 365 admin centerでユーザーまたはセキュリティグループ単位のアクセスを検討する |
| 無効化時の影響 | Anthropicモデルを無効にすると、一部機能が利用できなくなる可能性を利用部門へ説明する |
| 既存設定からの移行 | 以前のAnthropic関連トグルを利用していた場合、新しいサブプロセッサ設定を確認する |
特にグローバル企業では、日本のテナントだけでなく、欧州、英国、政府系環境、子会社テナントの条件が異なる可能性があります。「本社で使えるから全拠点で使える」と判断しないことが重要です。
利用者向けに伝えるべき使い方
Coworkを有効化しても、利用者が「何を頼めばよいか」を理解していなければ効果は出ません。公式のGet started情報では、依頼内容は具体的なほうがよいとされ、「メールを送って」ではなく、宛先、目的、要約対象、出力形式などを含めた指示が推奨されています。(Microsoft Learn)
実務で使いやすい依頼例は次のとおりです。
| 業務 | 良い依頼例 | 確認すべき点 |
|---|---|---|
| 会議後のフォロー | 「今日の会議メモをもとに、参加者向けのフォローアップメールを作成し、未決事項を箇条書きにしてください」 | 宛先、未決事項、期限 |
| 週次報告 | 「今週のメールと会議内容をもとに、プロジェクト別の週次報告をWord文書で作成してください」 | 参照範囲、事実と推測の区別 |
| 会議準備 | 「明日のA社との打ち合わせに向けて、関連資料と過去メールから論点を整理してください」 | 外部共有してよい情報か |
| 受信箱整理 | 「重要度の高い未返信メールを抽出し、返信案を作成してください。送信前に確認します」 | 誤返信、社外秘情報、優先度 |
| 資料作成 | 「添付した提案メモをもとに、10枚程度のPowerPoint構成案を作成してください」 | スライドの論理構成、社名や数値の正確性 |
ポイントは、Coworkに「成果物」だけでなく「判断基準」も渡すことです。たとえば「重要なメールを探して」ではなく、「顧客、契約、期限、障害、役員依頼を含むメールを重要と判断して」と伝えると、期待値に近づきやすくなります。
開発者が確認すべきカスタムスキルとプラグイン
Coworkは、利用者個人がOneDrive上にSKILL.mdを配置してカスタムスキルを作る方法と、組織向けにMicrosoft 365アプリパッケージとしてプラグインを配布する方法があります。公式FAQでは、OneDriveの/Documents/Cowork/skills/配下にSKILL.mdを置くことで、最大50個のカスタムスキルを作成できると説明されています。(Microsoft Learn)
個人または小規模検証ならSKILL.mdから始める
カスタムスキルは、特定業務の進め方をCoworkに教えるためのMarkdownベースの手順書と考えると分かりやすいです。たとえば、週次レポート作成、契約書レビュー、営業日報整理、問い合わせ分類など、毎回同じ判断軸で進めたい業務に向いています。
基本構成は次のようになります。
---
name: weekly-report
description: Generates a weekly status report from recent emails and calendar events.
---
# Weekly Report
## Workflow
1. 過去1週間の会議とメールから主要トピックを抽出する
2. プロジェクト別に進捗、課題、次のアクションを整理する
3. Word文書として週次報告の形式で出力する実装時は、nameとフォルダー名を一致させる、説明文に「どの依頼で使うか」を具体的に書く、出力形式を明示する、といった点が重要です。Microsoftの開発者向け情報でも、descriptionはスキルの起動判断に使われるため具体的なトリガーフレーズを含めること、ワークフローを番号付き手順にすること、出力形式を定義することが推奨されています。(Microsoft Learn)
組織展開するならMicrosoft 365アプリパッケージで管理する
組織全体や部門単位で使わせたい場合は、Coworkプラグインとしてパッケージ化する選択肢があります。開発者向け情報では、CoworkプラグインはMicrosoft 365 App Packageとして配布され、スキルとコネクタをまとめられるとされています。パッケージにはmanifest.json、アイコン、skills/配下のSKILL.mdなどを含めます。(Microsoft Learn)
プラグイン開発では、次のように設計を分けると判断しやすくなります。
| パターン | 向いている用途 | 注意点 |
|---|---|---|
| スキルのみ | 文書レビュー、文章作成、社内手順の標準化 | 外部システムのリアルタイムデータは扱えない |
| スキル + リモートコネクタ | CRM、法務DB、財務データ、社内APIとの連携 | 認証、API権限、応答時間、監査を設計する |
| コネクタのみ | 既存のCowork標準スキルから外部データを使わせたい場合 | データ取得範囲と権限を最小化する |
| 既存Claudeプラグインから変換 | 既存のAgent Skills資産をMicrosoft 365向けに活用したい場合 | 未対応機能やmanifest差分を検証する |
開発者がやりがちな失敗は、スキルに秘密情報を埋め込むこと、広すぎるスキルを作ること、組み込みスキルと重複する名前や役割を作ることです。Microsoftの開発者向け情報でも、API資格情報はSKILL.mdに埋め込まず、認証付きのagentConnectorsを使うこと、スキルを広げすぎないこと、ファイルパスやシステムコマンドをハードコードしないことが注意点として示されています。(Microsoft Learn)
既存プラグインやスキルの移行で注意すること
既存のClaude CodeプラグインやAgent Skills資産を持っている場合、Microsoft 365向けパッケージに変換できる可能性があります。Microsoftの開発者向け情報では、Claude Codeプラグインのplugin.json、.mcp.json、skills/ディレクトリを読み取り、M365の.zipパッケージを生成する変換スクリプトが紹介されています。(Microsoft Learn)
ただし、移行は「そのまま本番投入」ではなく、差分確認が前提です。公式情報では、Claudeプラグインのcommands/、agents/、hooks/などはMicrosoft 365 manifestでは未対応とされています。(Microsoft Learn)
移行時の確認リストは次のとおりです。
| 確認項目 | 見るべきポイント |
|---|---|
| スキル名 | フォルダー名とfrontmatterのnameが一致しているか |
| 命名規則 | kebab-caseになっているか。大文字、アンダースコア、連続ハイフンを避けているか |
| 未対応機能 | slash command、sub-agent、hookなどに依存していないか |
| 認証 | APIキーやOAuth情報をファイルに直書きしていないか |
| コネクタ | HTTPS、認証方式、応答時間、権限範囲を確認しているか |
| 検証環境 | Microsoft 365 admin centerでカスタムアプリとしてアップロードし、対象グループでテストしているか |
| 管理者承認 | 利用可能なプラグイン、管理者展開、コンプライアンスポリシーに沿っているか |
特に、開発者が作ったスキルが便利でも、部門や全社に展開する場合は管理者のプラグイン管理、利用者への説明、監査ログの確認まで含めてリリース計画を作る必要があります。
展開前チェックリスト
Coworkは便利な機能ですが、最初から全社に広げると、問い合わせ、権限管理、誤送信リスク、プラグイン承認が一気に増える可能性があります。展開前には次の項目を確認しましょう。
| 項目 | 管理者・開発者が確認すること | 判断基準 |
|---|---|---|
| 利用目的 | どの業務にCoworkを使うか | 会議準備、週次報告、受信箱整理など、効果が測りやすい業務から始める |
| 対象者 | 誰に表示・展開するか | 部門横断ではなく、最初は少人数のセキュリティグループに限定する |
| Frontier | 対象者と管理者がFrontierに参加しているか | 管理画面でCoworkが見えるかまで確認する |
| ライセンス | Microsoft 365 Copilotライセンスが割り当てられているか | パイロット対象者のライセンス不足をなくす |
| Anthropic設定 | サブプロセッサ設定と地域条件を確認したか | 法務・セキュリティの承認を得る |
| DLP | 機密情報や秘密度ラベルの扱いを確認したか | Cowork利用時にも既存ポリシーが機能するか検証する |
| 監査ログ | Coworkの利用ログを確認できるか | 監査担当が検索・確認できる状態にする |
| プラグイン | 許可するプラグインと禁止するプラグインを決めたか | 外部接続や追加認証が必要なものを優先的に確認する |
| 承認運用 | 送信・投稿・会議設定前に何を確認するか決めたか | 宛先、本文、添付、共有範囲を必ず見る |
| 教育 | 利用者向けのプロンプト例と禁止事項を用意したか | 「何を頼むか」「何を任せないか」を明文化する |
よくある疑問
Coworkはすぐ全社展開してよいのか
おすすめしません。公式情報では、管理者がCoworkの可用性を全ユーザー、特定ユーザーまたはグループ、ブロックに制御できるとされています。まずは特定グループで業務効果、承認ミス、ログ、問い合わせ内容を確認してから広げるのが安全です。(Microsoft Learn)
Coworkはローカルファイルを直接編集できるのか
公式FAQでは、Coworkはローカルデバイス上のファイルにアクセスまたは編集できず、OneDriveやSharePoint上のファイルを扱うとされています。ローカルにある重要資料を扱わせたい場合は、組織の情報管理ルールに従ってクラウド上に配置し、権限とラベルを確認してから使うべきです。(Microsoft Learn)
管理者がプラグインを展開した場合、利用者は何もしなくてよいのか
プラグイン自体は管理者が展開できますが、外部サービス接続が必要な場合、利用者自身が一度サインインや同意フローを完了する必要があります。公式情報では、管理者が利用者の代わりにサービスへサインインすることはできないと説明されています。(Microsoft Learn)
開発者は最初に何を作ればよいのか
最初は大規模な外部連携プラグインよりも、SKILL.mdだけで完結する小さなスキルがおすすめです。たとえば「週次報告」「契約書の一次レビュー」「問い合わせ分類」など、判断軸と出力形式を明確にできる業務から始めると、効果検証もしやすくなります。外部データが必要になった段階で、コネクタやMicrosoft 365アプリパッケージ化を検討するとよいでしょう。
まず取るべき次の行動
Copilot Cowork common questions (Frontier)の要点は、Microsoft 365 Copilotが「回答するAI」から「承認を挟みながら業務を進めるAIエージェント」へ広がることです。利用者にとっては日常業務の効率化が期待できますが、管理者にとってはアクセス制御、DLP、監査ログ、Anthropicモデル、プラグイン管理まで含めた運用設計が欠かせません。
最初の一歩としては、次の順序で進めるのが現実的です。
- Frontier参加、Microsoft 365 Copilotライセンス、Coworkの表示可否を確認する
- Anthropicモデルの設定と社内承認を確認する
- セキュリティグループで小規模パイロットを作る
- DLP、監査ログ、データ所在地、プラグイン制御を検証する
- 利用者向けに「良い依頼例」「承認時の確認項目」「使ってはいけない情報」を配布する
- 開発者は小さなSKILL.mdから始め、必要に応じてプラグイン化する
Coworkはプレビュー機能であり、仕様や利用可能範囲は変わる可能性があります。だからこそ、本番業務にいきなり組み込むのではなく、限定された業務、限定されたユーザー、明確なレビュー手順から始めることが、失敗しない展開の近道です。
コメント