Copilot Coworkの自動化｜スケジュールとイベント駆動

「Copilot Coworkを自動化したいが、人がいない時間でも本当に動くのか」「スケジュール実行とイベント駆動は何が違うのか」——Microsoft 365 Copilotの管理を任されている方から、こうした疑問をよく聞きます。

結論から言うと、Copilot Coworkの自動化には、時刻を指定して動かす「スケジュール実行」と、メールやTeamsの着信をきっかけに動く「イベント駆動」の2つの起動方法があります。どちらも人が都度指示を出さなくても動きますが、暴走させないための仕組みが組み込まれた設計になっています。

株式会社Fyveは中小企業のAI活用支援を行っており、私たちはMicrosoft 365 Copilotまわりの機能を継続的に確認しています。この記事では、2026年9月15日時点の公式情報をもとに、Copilot Coworkのスケジュール実行とイベント駆動タスクの作り方・管理方法、そして自動化を安全に運用するための設計を整理します。

この記事の範囲——Copilot Coworkの自動化に絞って解説

本記事が扱うのは、Microsoft 365 Copilotに搭載された「Copilot Cowork」の自動化機能です。名称の似た「Claude Cowork」（Anthropicが提供する別製品）とは別物ですが、技術的にはつながっています。両者の関係については、別の記事で詳しく整理しています。

また、自動化タスクに関わる権限設定・監査ログ・Purviewのポリシーといった詳細な管理手順は、セキュリティ・ガバナンスの観点から別記事でまとめます。本記事では、スケジュール実行とイベント駆動タスクを「どう作り、どう管理するか」という自動化そのものに絞って解説します。

人がいなくても動く、2つの起動方法

Microsoft Learnは、Copilot Coworkができる作業の一つとして「スケジュールを組んでの実行」と「イベント駆動タスク（メールやTeamsメッセージの着信で起動）」を挙げています。どちらも、チャットで都度指示を出さなくても、決めた条件でCoworkが自律的にタスクを開始できるしくみです。

違いは起動のきっかけです。スケジュール実行は「毎朝9時」のように時刻を指定して動かします。イベント駆動は、メールの受信やTeamsメッセージの着信など、何かが起きたことをきっかけに動きます。人が画面の前にいなくても、決めた時刻・決めた出来事に反応してタスクが動き出す点は共通していますが、何を起点にするかがまったく違うため、業務ごとにどちらが向いているかを判断する必要があります。どちらも一度設定すれば、あとは条件が満たされるたびに繰り返し動き続ける点も共通しています。次の章から、それぞれの作り方と管理方法を見ていきます。

スケジュール実行——時刻を指定して動かす

自然な文章で指示を書く

スケジュール実行の作成に、コードや専用の設定画面を組み立てる必要はありません。「毎朝9時に日次ブリーフィングを作成する」のように、自然な文章で指示を書くだけで登録できます。業務で普段使っている言葉のまま指示を書けば動き始める作りで、情シス担当者だけでなく、総務・経理など非エンジニアの担当者が自分の業務範囲で登録できる設計だと言えます。

指示を書くときは、「いつ」「何を」「どうするか」がひとつの文の中に収まっているほど、意図した通りに登録しやすくなります。「毎朝9時に日次ブリーフィングを作成する」であれば、いつ（毎朝9時）・何を（日次ブリーフィング）・どうするか（作成する）が一文の中に揃っています。曖昧な言い回しで登録すると、意図しない頻度や内容で動いてしまう可能性があるため、時刻・対象・アウトプットの3点を意識して書くとよいでしょう。

登録できるスケジュール実行の数には上限があり、Microsoft Learnによると最大25個までです。日次・週次のルーティン業務をひとつずつ登録していくと、この上限に近づく組織も出てくるはずです。優先度の低いスケジュールをまとめる、使わなくなったスケジュールを削除するなど、登録数を意識した運用が必要になります。

Automationsページでの管理

登録したスケジュール実行は、Automationsページでまとめて管理します。このページには「Runs」と「Manage schedules」の2つのタブがあり、Runsでは実行結果の履歴を、Manage schedulesでは登録済みのスケジュールそのものを確認できます。実行が意図した通りに終わっているかどうかを、都度チャットを遡らずにこの1画面で追える点が、運用担当者にとっての利点です。

Manage schedulesタブからは、スケジュールの編集・一時停止・再開・削除ができます。一度登録して終わりではなく、業務内容の変更に合わせて調整していく前提の設計です。担当者の異動や業務フローの変更があったときも、スケジュールを作り直すのではなく、既存の登録を編集する形で対応できます。

新しく作ったスケジュールを下書きの状態から有効化するときは、「Activate and run now」（有効化してすぐに実行する）と「Activate」（有効化するだけで、次の実行タイミングを待つ）のどちらかを選べます。内容をすぐに確認したい場合は前者を選んで一度動かしてみて、意図した結果になっているかを確認したうえで、決めた時刻からの運用を崩したくない場合は後者を選ぶ、という使い分けができます。初めて登録するスケジュールほど、いきなり本番の時刻を待つのではなく、まず「Activate and run now」で挙動を確認してから運用に乗せる進め方が現実的です。

イベント駆動——着信をきっかけに動かす

3つのトリガー元

イベント駆動タスクは、次の3つの着信をきっかけに起動できます。

• メールの受信
• Teamsチャネルへの投稿
• Teamsチャットへのメッセージ

Teamsチャットについては、すべてのメッセージに反応させるのではなく、自分への@メンションがあったメッセージだけに絞り込むことができます。チャンネル全体の会話をそのまま拾ってしまうと不要な起動が増えるため、この絞り込みは運用上意味があります。逆に言えば、Teamsチャネルへの投稿をトリガーにする場合は、チャネル内のやり取りに幅広く反応させる設計にもできるということです。どの範囲まで拾わせるかは、そのチャネルの用途や投稿頻度に合わせて選ぶ必要があります。

トリガー設定カードで確認できること

イベント駆動タスクを作成すると、「Set up trigger?」（トリガーを設定しますか）というカードが表示されます。このカードには、次の3つの項目が示されます。

• When（いつ・どの着信をきっかけにするか）
• Run in（どこで実行するか）
• What it does（何をするか）

あわせて、そのトリガーを動かすために必要な権限も、このカード上に表示されます。設定を確定する前に、何が起きたら・どこで・何をするタスクなのかを一画面でまとめて確認できる作りです。設定を確定した後に「実は違う挙動だった」と気づくのではなく、確定前にWhen／Run in／What it doesの3項目を見比べて、意図と一致しているかを確認してから有効化する運用が安全です。

状態と最終実行日時の確認

登録したイベント駆動タスクは、Active（稼働中）・Draft（下書き）・Paused（一時停止）のいずれかの状態を持ちます。また、そのタスクが最後にいつ発火したかも確認できます。しばらく発火していないタスクがあれば、トリガーの条件が実務と合わなくなっていないか（例えば対象のメールアドレスやチャネルが変わっていないか）を見直すきっかけになります。逆に、想定より頻繁に発火しているタスクがあれば、トリガーの範囲が広すぎないかを確認する材料になります。

自動化を暴走させない設計（安全策）

人が都度確認しなくても動く仕組みだからこそ、Copilot Coworkの自動化には歯止めが組み込まれています。Microsoft Learnが挙げている主な安全策は次のとおりです。

• 各タスクは、作成したユーザー自身の権限の範囲で動く
• 既定はdraft-and-approve方式。送信・投稿・共有システムの変更といった共有を伴う操作の前には、承認を求められる
• 実行頻度に制限がある
• 自己ループを防ぐ仕組みがある
• 実行内容は統合監査ログに記録され、Purviewのポリシーが適用される

作成者の権限で動く、という意味

スケジュール実行もイベント駆動タスクも、動かすのはあくまで作成した本人の権限です。管理者権限を持たない担当者が登録したタスクが、管理者しかアクセスできない情報を扱えるようになるわけではありません。自動化タスクの実行範囲は、そのタスクを作った人が普段アクセスできる範囲と同じだと考えておく必要があります。

共有アクションは承認待ちになる

既定のdraft-and-approve方式では、メール送信・Teams投稿・共有システムの変更といった、社外や他のメンバーに影響が及ぶ操作の前に承認が求められます。この中で運用時に見落としやすいのが、承認まわりの挙動です。共有を伴う操作の前に、同じチャットセッションに限り事前承認をまとめて設定することもできます。ただしその事前承認はそのチャットセッション限りで、新しいセッションには引き継がれません。前回のセッションで確認を省略する設定にしていても、次に開いたセッションでは改めて承認を求められる、という前提で運用する必要があります。スケジュール実行やイベント駆動タスクのように、日をまたいで繰り返し動くタスクほど、このセッション限定の性質を理解しておくことが重要です。

実行頻度の制限と自己ループ防止

自動化タスクが際限なく動き続けたり、自分の実行結果をきっかけに自分自身を再度呼び出してしまったりすることを防ぐため、実行頻度の制限と自己ループを防ぐ仕組みが備わっています。イベント駆動タスクは特に、Coworkが送るメールやTeams投稿そのものが別のトリガーを発火させてしまう可能性があるため、こうした歯止めが設計上の前提になっていると理解しておくとよいでしょう。

監査ログとPurview（詳細は別記事）

実行内容は統合監査ログに記録され、Purviewのポリシーが適用されます。誰が・どの権限で・何を承認したかという詳細な監査・ガバナンスの設定は、別記事でまとめて扱います。実行結果は、既定では作成した本人にのみ届きます。承認しない限り、他のメンバーに自動的に共有されることはありません。

自動化タスクもクレジットを消費する

スケジュール実行やイベント駆動タスクも、Coworkが実際にモデルを呼び出してタスクを実行する点は、チャットで都度指示する場合と変わりません。そのため、モデルの利用・文脈の取得量・ツール呼び出し・実行時間に応じて、通常のタスクと同じようにCopilot Creditsが消費されます。人が画面を見ていない時間に動く分、気づかないうちに消費が積み重なりやすい点は意識しておく必要があります。特にスケジュール実行は登録した頻度のまま動き続けるため、毎日・毎週といった高い頻度で登録したタスクほど、月間で見たときの消費量への影響が大きくなりやすいと考えられます。イベント駆動タスクについても同様に、着信の頻度が高いメールアドレスやチャネルをトリガーにするほど、実行回数が積み上がりやすくなります。Microsoft 365 Copilot全体の料金プランは、こちらの記事で整理しています。

CopilotCopilotの料金一覧｜個人・法人の全プラン【2026年版】

スケジュール実行とイベント駆動、何が違うか

時刻が決まっている定型業務にはスケジュール実行、何かが起きたタイミングで反応させたい業務にはイベント駆動、という形で起動方法そのものの性質が分かれています。日次ブリーフィングのように「毎日同じ時刻に必要な作業」と、メールの着信のように「発生したタイミングが読めない作業」では、そもそも向いている起動方法が違う、と捉えておくと選びやすくなります。どちらの方式も、登録直後に本番運用へ進めるのではなく、まず挙動を確認してから任せる範囲を広げていく進め方が共通しています。

自動化を任せる前に確認しておきたいこと

ここまでの仕組みを踏まえると、スケジュール実行・イベント駆動のどちらを組む場合でも、有効化する前に確認しておきたい点は共通しています。人が都度確認しない前提で動かすからこそ、動かし始める前の確認を丁寧にしておく価値があります。

• 自然文の指示に「いつ」「何を」「どうするか」の3点が入っているか。曖昧な言い回しのまま登録していないか
• スケジュール実行であれば、いきなり本番の時刻を待つのではなく、「Activate and run now」で一度動かして結果を確認したか
• イベント駆動であれば、「Set up trigger?」カードのWhen／Run in／What it doesの3項目が、意図した内容と一致しているか
• Teamsチャットをトリガーにする場合、@メンションだけに絞るべきか、チャネル全体に反応させるべきかを選んだか
• 共有を伴う操作は既定で承認待ちになる設計であることを理解したうえで、事前承認をどこまでセッション内で使うかを決めているか
• Automationsページの実行履歴や、イベント駆動タスクの最終発火日時を、定期的に見返す運用になっているか

この確認を最初の1回だけで終わらせず、担当者の異動や業務フローの変更があったタイミングで見直す運用に組み込んでおくと、登録したまま実態と合わなくなった自動化を放置せずに済みます。放置されたままのスケジュールやトリガーは、誰にも気づかれないままクレジットをずっと消費し続けることにもつながります。

非エンジニアの担当者が自動化を任されたときの進め方

Copilot Coworkの自動化は、専用のコードや開発環境を用意する必要がなく、自然な文章とトリガー設定カードの操作だけで組める設計です。とはいえ、情シス部門ではない総務・経理・営業事務の担当者が初めて任される場合、いきなり複数のスケジュールやイベント駆動タスクを一度に登録するのではなく、まず1つの業務——たとえば日次ブリーフィングのような定型のスケジュール実行——から始め、Automationsページで実行結果を確認する、という流れに慣れてから範囲を広げていく進め方が現実的です。イベント駆動タスクについても同様に、まずは影響範囲の小さいメール受信のトリガーから試し、承認待ちの挙動や最終発火日時の見え方を確認してから、Teamsチャネル・Teamsチャットへと対象を広げていくと、意図しない動作に気づいたときの対応もしやすくなります。

よくある質問

スケジュール実行は何個まで登録できますか？

Microsoft Learnによると、最大25個まで登録できます。

イベント駆動タスクはどんな着信で動きますか？

メールの受信、Teamsチャネルへの投稿、Teamsチャットへのメッセージが対象です。Teamsチャットは、自分への@メンションがあったメッセージだけに絞り込むこともできます。

自動化タスクは承認なしで送信やTeams投稿まで実行しますか？

いいえ。既定ではdraft-and-approve方式で、送信・投稿・共有システムの変更といった共有を伴う操作の前には承認を求められます。同じチャットセッション内であれば事前承認をまとめて設定することもできますが、新しいセッションには引き継がれません。

登録したスケジュール実行やイベント駆動タスクを止めたい場合は？

スケジュール実行はAutomationsページのManage schedulesタブから一時停止・再開・削除ができます。イベント駆動タスクはActive・Draft・Pausedの状態で管理します。

自動化タスクが暴走することはありませんか？

実行頻度の制限と、自己ループを防ぐ仕組みが組み込まれています。また各タスクは作成したユーザー自身の権限の範囲で動き、実行内容は統合監査ログに記録されます。

新しく作ったスケジュールは、すぐに実行結果を確認できますか？

下書きを有効化するときに「Activate and run now」を選べば、有効化した時点ですぐに実行され、結果を確認できます。次の実行時刻を待ちたい場合は「Activate」を選びます。

自動化タスクの実行結果は、他のメンバーにも共有されますか？

既定では作成した本人にのみ届きます。承認しない限り、他のメンバーに自動的に共有されることはありません。

スケジュール実行とイベント駆動は、同時に組み合わせて使えますか？

本記事の事実源では、2つの起動方法は別々の仕組みとして説明されており、併用を妨げる記載はありません。時刻が決まっている業務にはスケジュール実行、着信をきっかけにしたい業務にはイベント駆動、という形で業務ごとに使い分けて登録する運用になります。

登録した自動化タスクが増えすぎた場合、どう整理すればよいですか？

スケジュール実行はAutomationsページのManage schedulesタブから、使わなくなったものを削除・一時停止できます。イベント駆動タスクも同様にActive・Draft・Pausedの状態を見ながら、最終発火日時が古いタスクから見直すとよいでしょう。スケジュール実行は最大25個という上限があるため、登録するたびに「まだ必要な業務か」を見直しながら、定期的な棚卸しを運用に組み込んでおく必要があります。

まとめ

• Copilot Coworkの自動化には、時刻を指定するスケジュール実行と、着信をきっかけに動くイベント駆動の2つの起動方法がある
• スケジュール実行は自然な文章で指示を書いて登録でき、最大25個まで。Automationsページ（Runs／Manage schedules）で実行履歴と登録内容の両方を管理する
• イベント駆動はメール受信・Teamsチャネル投稿・Teamsチャット（@メンション）が対象。「Set up trigger?」カードで設定内容を確認できる
• 暴走を防ぐため、既定はdraft-and-approve方式。各タスクは作成者本人の権限で動き、実行頻度の制限・自己ループ防止・統合監査ログもあわせて備わっている
• 事前承認はそのチャットセッション限り。新しいセッションには引き継がれない

Copilot Coworkの全体像——できること・課金の仕組み・利用できる場所は、こちらにまとめています。

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