Copilot Coworkのセキュリティと権限管理

Copilot Coworkにどこまでの権限を与えていいのか、セキュリティ面で何が守られていて何が守られていないのか——導入を検討する情シス・総務の担当者から、こうした不安の声をよく聞きます。メールを送信し、資料を作成し、ファイルを整理する仕事を代わりに実行するしくみだからこそ、権限や情報漏洩のリスクをどこまで統制できているのかが気になるのは当然です。

結論から言うと、Copilot Coworkにはデータの隔離処理・権限の継承・承認フロー・統合監査ログという複数の統制が組み込まれています。ただし、すべてが自動で完結するわけではありません。誰にどこまでの権限を持たせるか、どのスキルの出所を信頼するかといった判断は、導入する組織側に委ねられている部分です。

株式会社Fyveは中小企業のAI活用を支援しており、私たちはMicrosoft 365 Copilotまわりの機能を継続的に確認しています。この記事では、2026年9月15日時点の公式情報をもとに、Copilot Coworkのセキュリティ・権限・監査ログまわりの設計を、統制されている部分と運用側で決める必要がある部分に分けて整理します。

タスク実行中のデータはどう扱われるか

Copilot Coworkがタスクを実行している間、対象になるファイルはMicrosoft 365サービス境界の内側にある一時的な隔離環境で処理されます。たとえば「フォルダ内の複数のExcelファイルを集計して1つの表にまとめる」というタスクを頼んだ場合、その集計作業はこの隔離環境の中で進み、作業用に複製されたデータが外部のどこかに残り続けることはありません。

この処理は、タスクが終了すると同時に破棄されます。作業の途中経過や一時的に生成された中間データを、利用者側があとから確認することもできません。「タスクの実行中に何が起きているか」を覗き見ることはできない代わりに、「タスクが終わればその場のデータは残らない」という設計になっています。

データの所在地(どの地域のサーバーで処理・保存されるか)については、Copilot本体と同じ考え方に従うと案内されています。Coworkだけが別の地域にデータを移すわけではなく、すでにCopilotで運用しているデータ所在地のポリシーが、Coworkのタスクにもそのまま適用される、という理解になります。

収集・処理されるデータに対するセキュリティ・コンプライアンス管理は、Microsoft Purviewから行えます。情報保護ラベルの適用状況やDLPポリシーの適用状況など、すでにM365環境で運用しているPurviewのしくみを、Coworkが実行するタスクに対しても確認できる設計です。

なお、Copilot CoworkはAnthropicのモデルも選択できます。Anthropicのモデルを使った場合にデータがどう保持されるかは本記事の対象外です。Microsoft 365 Copilot経由でClaude Fable 5.1を使う場合のデータの扱いは、こちらの記事で詳しく解説しています。

CopilotClaude Fable 5.1はCopilotで使えるのか｜入口でデータの扱いが逆になる

権限は作成者から継承される——Coworkが独自の権限を持つわけではない

Copilot Coworkが実行する自動タスクは、そのタスクを作成した本人の権限の範囲で動きます。作成者がアクセスできるファイル・メール・Teamsチャネルだけが対象になり、作成者本人が見えないものにCoworkが代わりにアクセスすることはありません。

たとえば、あるユーザーがアクセス権を持っていないSharePointサイトがあったとします。そのユーザーがCoworkに「そのサイトの資料を検索してまとめて」と指示しても、Coworkは作成者本人と同じ理由でそのサイトにアクセスできません。Coworkというしくみが、ユーザー本人の権限を超えて何かを見つけ出してくれるわけではない、という点は誤解しやすいところです。

つまり、Coworkは新しい強い権限を組織に持ち込むわけではなく、すでにMicrosoft 365上で設定されている個々のユーザーの権限が、そのままCoworkの実行範囲にも適用されるという考え方です。組織内検索やOneDrive・SharePointのファイル管理を任せる場合も、検索・閲覧できる範囲は作成者本人のアクセス権を超えません。

スケジュール実行やイベント駆動タスクのように、人の目を離れて自動で動くタスクについても同じ考え方が当てはまります。実行結果は作成者本人にのみ届き、権限の範囲もタスクを作成した時点の作成者の権限に従います。誰にどこまでの権限を持たせるかは、Coworkの個別設定ではなく、Microsoft 365上のユーザー・グループの権限設計そのものに帰着する、というのがこの節の要点です。

既定は承認待ち——共有を伴う操作は自動で進まない

権限の範囲内であっても、Copilot Coworkはすべての操作を無条件に実行するわけではありません。メール送信・Teams投稿・共有システムの変更など、社外・社内を問わず「共有」を伴う操作は、既定で承認待ちの状態になります。作成した下書きをCoworkが確認を求めたうえで、人が最終的に送信・実行するかどうかを判断する動き方です。

承認は1件ずつ個別に確認する方法のほかに、保留中の承認をまとめて許可する操作も用意されています。ここで注意したいのが、この「以後は確認せずに進めてよい」という許可の有効範囲です。この事前承認は、その時開いているセッション限りの効力しか持ちません。新しく別のセッションを開いてCoworkに作業を頼むときは、あらためて承認を求められます。

現在どの操作にどこまでの許可を与えているかは、サイドパネルのPermissionsから確認・取り消しができます。「あるタスクの最中にまとめて許可したことを忘れて、そのまま放置してしまう」というのはありがちな失敗ですが、この画面を定期的に見に行く運用を挟むことで、許可の状態を把握し直すことができます。

この承認フローは、Coworkが意図せず情報を外部へ送ってしまうタイプの事故を防ぐための、最初の防波堤にあたります。ただし承認そのものは人が行う操作なので、内容を確認せずに承認してしまえば、この防波堤は機能しません。誰が・どんな基準で承認するかという運用ルールを、あわせて決めておく必要があります。

実行内容は統合監査ログに記録される

Copilot Coworkが実行したタスクの内容は、Microsoft 365の統合監査ログに記録されます。誰が・いつ・どのタスクを・どんな権限のもとで実行したかを、あとから追跡できるしくみです。「Coworkに何を頼んだか」が記録に残らず、あとから確認できないということはありません。

この記録は、ブラウザ操作を伴うタスクについても同様です。Coworkがブラウザを操作して情報を取得したり、フォームを入力したりする場合も、実行のたびに統合監査ログへ記録が残ります。ブラウザ上の操作だからといって、記録の外側で進むわけではありません。

統合監査ログに記録された内容には、Purviewのポリシーが適用されます。すでにPurviewで運用している監査ログの保持期間や、監査ログをもとにしたアラートのルールを、Coworkが実行した操作に対しても適用できます。監査ログの存在そのものは、事後に「誰が何をしたか」をたどるための最低限の土台です。実際にその記録をどれくらいの頻度で確認し、異常な操作をどう検知するかは、運用側で決める必要がある部分になります。

ブラウザ操作は利用者の端末上で動く——既存の統制がそのまま効く

Copilot Coworkがブラウザ操作を伴うタスクを実行する場合、その操作はMicrosoft Edgeの、利用者本人の端末上にあるタブの中で動きます。Copilot側の別のサーバー環境で、利用者の目に見えない形でブラウザが動くわけではありません。

この設計のため、組織側がすでに設定している条件付きアクセス・DLP(データ損失防止)ポリシー・閲覧ポリシーは、Coworkのブラウザタスクに対してもそのまま適用されます。特定のサイトへのアクセスを許可・ブロックするリストを運用している場合、そのリストもCoworkの操作に対して尊重されます。

言い換えると、Coworkがブラウザ操作を行うからといって、組織が持つ既存のセキュリティ境界の外側に出るわけではありません。社外の任意のサイトに無制限にアクセスできてしまうということはなく、人がブラウザを使うときと同じ制約の中で動きます。

ただし、これはあくまで「組織側の統制が正しく設定されていれば効く」という話でもあります。条件付きアクセスやDLPの設定自体に抜けがあれば、その抜けはCoworkのブラウザタスクにもそのまま影響します。Coworkを使い始めるタイミングは、既存の条件付きアクセス・DLPの設定を見直す機会としても位置づけられます。

スキルの出所がリスクになる——「スキルはAIへの指示そのもの」

Copilot Coworkはカスタムスキルを追加でき、日々の業務に合わせて機能を広げられます。その一方で、出所の分からないスキルを取り込むことは、セキュリティ上の明確なリスクになります。Microsoft Learnは、カスタムスキルについて次のように明記しています。

「"A skill runs as instructions to the AI. Only upload skills from sources you trust."」（スキルはAIへの指示そのものとして動きます。信頼できる出所のスキルだけをアップロードしてください）——Microsoft Learn。

つまり、スキルは単なる設定ファイルではなく、Coworkの振る舞いを直接左右する「指示」そのものだということです。誰が作ったか分からないスキルを取り込むと、意図しない指示が紛れ込む、いわゆるプロンプトインジェクションのリスクにつながります。社内で作った覚えのないスキルや、出所不明なテンプレートをそのまま使うことは避けたほうがよい、ということが公式の表現からも読み取れます。

この点を踏まえ、Coworkにはスキルを取り込む際の自動評価のしくみが組み込まれています。評価には、プロンプトインジェクションを検出する静的チェックと、Trust and safety gate(信頼性・安全性の関門)が含まれます。ここで注意しておきたいのが、評価のスコアとこのゲートが別々の軸だという点です。Microsoft Learnは次のように説明しています。

「"This gate is independent of the score—a high score doesn't grant a pass."」（このゲートはスコアとは独立しています。スコアが高いからといって通過が保証されるわけではありません）——Microsoft Learn。

評価スコアが高い＝安全というわけではなく、スコアとTrust and safety gateは独立して判定されます。カスタムスキルを社内で共有・運用する際は、この自動評価を通っているかどうかに加えて、そもそも誰が・どこからそのスキルを持ち込んだのかを確認する運用が欠かせません。自動評価は最低限のふるいであって、それだけで「安全なスキルだけが残る」と考えるのは早計です。

なお、評価の深さそのものにも段階があります。スキルが到達する範囲とリスクレベルに応じて、Minimal・Standard・Full・Maximalという段階で評価の深さが変わり、リスクの高いスキルほど、最低でもFullの深さで評価される設計です。すべてのスキルが同じ浅さで一律にチェックされているわけではなく、影響範囲が大きいスキルほど厳しく見られる、という理解になります。

権限を役割で分ける——閲覧だけを渡す選択肢もある

セキュリティ統制のもうひとつの観点が、権限をどの役割にどこまで渡すかです。Copilot Coworkの管理・コスト管理の画面では、変更権限を渡さずに状況の確認だけを任せる、閲覧専用の役割を用意できます。Microsoft Learnは次のように説明しています。

「"Supported reader-based roles can review consumption dashboards and reports without receiving permissions to change spending policies or billing configurations."」（対応する閲覧ロールを持つ担当者は、支出ポリシーや課金設定を変更する権限を持たなくても、消費状況のダッシュボードやレポートを確認できます）——Microsoft Learn。

これにより、経理・運用・ライセンス管理・統制を担当する複数の担当者に、それぞれ必要な範囲だけの権限を割り当てられます。「設定を変更できる人」と「状況を確認できる人」を分けておくと、誰か一人の操作ミスや、必要以上に広い権限を持たせたことによる設定の崩れを防ぎやすくなります。

先に触れた、作成者の権限の範囲でしかタスクが動かないという設計とあわせると、Copilot Coworkの権限まわりは「Coworkに何ができるか」ではなく「その人がもともと何にアクセスできるか」を土台にしていることが分かります。権限設計の起点は、結局のところCowork導入前からの組織内の権限管理そのものです。閲覧専用の役割をどの担当者に割り当てるかも、既存の職務分掌に沿って決めることになります。

支出ポリシーも、実はアクセス制御のしくみ

なお、Copilot Coworkを誰が使えるかを決める「支出ポリシー」も、単なる予算設定ではなくアクセス制御のしくみとして機能します。上限額を小さく設定しただけでは、そのユーザーを締め出したことにはならないなど、見た目の設定と実際の効果がずれやすいポイントです。詳しい落とし穴と点検リストは、支出ポリシーを扱った別記事で整理しています。

統制できる部分と、運用で決める必要がある部分

ここまで見てきた統制を、技術的に組み込まれている部分と、導入する組織側の判断に委ねられている部分に分けると、次のようになります。

こうして並べると、Copilot Coworkは処理の実行そのものについては複数の技術的な統制を持っていますが、「誰にどこまでの権限を与えるか」「どのスキルの出所を信頼するか」「監査ログをどれくらいの頻度で確認するか」といった判断は、導入する組織側に委ねられていることが分かります。

「Coworkを導入すればセキュリティ対策になる」という理解ではなく、組織側の権限設計・承認ルール・監査運用と組み合わせて初めて機能する、という捉え方のほうが実情に近いといえます。統制できている部分と、まだ決めていない部分を分けて把握しておくことが、導入前の点検としてはいちばん実務的です。

導入前に確認しておきたいチェックポイント

ここまでの内容を、導入前に確認しておきたい項目として並べ直すと、次のようになります。技術的な統制と、運用側で決める部分がそれぞれどこにあるかを、あわせて意識しておくと点検しやすくなります。

• Coworkのタスクを作成できるユーザーが、それぞれどこまでの権限(アクセスできるファイル・メール・Teamsチャネル)を持っているか棚卸しをしたか
• メール送信・投稿・共有システムの変更など、共有を伴う操作の承認を誰がどんな基準で行うか決めたか
• 「以後聞かない」の事前承認がセッション限りであることを利用者に周知し、サイドパネルのPermissionsを定期的に確認する運用にしているか
• 統合監査ログをどのくらいの頻度で確認し、異常な操作をどう検知するかを決めたか
• 条件付きアクセス・DLPポリシー・閲覧ポリシーが、ブラウザ操作にも及ぶ前提で最新の状態になっているか
• カスタムスキルを持ち込んでよい出所の範囲(自作・社内共有・外部配布物など)を決めたか
• 経理・運用・統制の各担当者に、閲覧専用ロールと変更権限をどう割り振るか決めたか

よくある質問

Copilot Coworkは情報漏洩のリスクが高いのでしょうか？

タスク実行中のファイルが隔離環境で処理されタスク終了時に破棄されること、権限が作成者本人の範囲を超えないこと、共有を伴う操作が既定で承認待ちになることなど、複数の統制が組み込まれています。ただし、支出ポリシーの対象設定やスキルの出所管理のように、運用側の判断に委ねられている部分も残るため、統制の設計次第でリスクの大きさは変わります。

監査ログはどこで、何を確認できますか？

Copilot Coworkが実行したタスクの内容は、Microsoft 365の統合監査ログに記録されます。ブラウザ操作を伴うタスクも、実行のたびに記録される設計です。記録された内容にはPurviewのポリシーが適用されます。

誰にCoworkの利用権限を持たせるかは、どのように決まりますか？

Coworkが実行できる範囲は、そのタスクを作成した本人がもともと持っている権限の範囲を超えません。誰にどこまでの権限を持たせるかを決めるには、Coworkの個別設定ではなく、Microsoft 365上の既存のユーザー・グループの権限設計を見直す必要があります。

カスタムスキルの自動評価に通れば、そのスキルは安全だと考えてよいですか？

そうとは言い切れません。評価には、プロンプトインジェクションを検出する静的チェックとTrust and safety gateが含まれますが、この2つは独立した判定軸です。評価スコアが高いことと、Trust and safety gateを通過することは別で、自動評価を通っているかどうかに加えて、誰が・どこからそのスキルを持ち込んだのかを確認する運用が必要です。

まとめ

Copilot Coworkのセキュリティ・権限まわりの設計は、データの隔離処理・権限の継承・承認フロー・統合監査ログ・スキルの出所チェックという複数の統制の組み合わせでできています。ただし、これらはあくまで土台であり、「導入すればそれだけで安全になる」と言い切れるものではありません。誰にどこまでの権限を与えるか、どのスキルを信頼するか、監査ログをどう運用するかは、導入する組織側で決める必要があります。

セキュリティ・権限まわりの前提を押さえたうえで、Copilot Cowork全体の位置づけやできることについても、こちらの記事もあわせてご覧ください。

CopilotCopilot Coworkとは｜Copilotが仕事を代行