はじめに
Copilot Studio のフローメニューを開くと、最近「新しいワークフロー」と「新しいエージェント フロー」の2つの選択肢が並ぶようになりました。
「ワークフロー」を選んでみると、Build / Activity / Analytics の3タブで構成された新しいデザイナが立ち上がり、Agent / Prompt / Classify / M365 Copilot / Human review / Connector / Function / Variable / If/Else といったノードが並んでいます。
触ってみた所感は以下の記事で紹介しております。
また、機能面の細かな違いは公式ドキュメントを参照いただくとして、本記事では「なぜ2つが生まれたのか」という設計思想の違いに絞って整理してみます。個人的には、この思想の違いを理解することが、使い分けを考えるうえで最も大事なポイントではないかと考えています。
エージェントフローの思想:エージェントが主役、フローはその手足
エージェントフローを一言で表すとすれば、「エージェントが主役で、フローはその手足」という設計です。
Copilot Studio でエージェントを作るとき、エージェントには会話や推論の能力があります。しかし、メールを送ったり SharePoint にデータを書き込んだりといった確定的な処理を実行するには、エージェント単体では限界があります。そこで Power Automate のフロー(エージェントフロー)を「ツール」として登録し、エージェントが必要なときに呼び出す、という構造になっています。
※エージェントからコネクタを直接呼び出すこともできますが、少し複雑なロジックを組む場合は、エージェントフローを利用する方が作りやすいです
例えば、以下のシナリオは、総務部門向けへメールで問い合わせがあったら、ナレッジ検索して回答を生成してメールの返信をするエージェントの画面です。この際、ナレッジから回答できなかった際は、総務部門に対してその旨連絡をしており、この部分をエージェントフローで実装しています。ナレッジを検索して回答を生成する部分、結果を判定して適切なツールを呼び出す判定はエージェント、タスク自体の実行はエージェントフローといった感じです。
イメージとしては、
- エージェントが司令塔
- Power Automate のフローがその手足として動く
- トリガーも Power Automate のフロー側に設定する
という形です。「エージェント + Power Automate」という組み合わせで業務を実現するのが、これまでの Copilot Studio の基本的なアプローチでした。エージェントフローという名前は、この文脈のなかで生まれた呼称である印象で、実態としては Copilot Studio 側で管理できるようになった Power Automate フローです。Power Automate 側からも引き続き編集できます。
※エージェントフロー独自の機能も少なからずありますが、個人的には、基本は Power Automate、もしくは、Power Automate の延長線上という印象があります
新しいワークフローの思想:ワークフローが主役、エージェントはその一部
これに対して、新しいワークフローは「ワークフローが主役で、エージェントはその処理の一部」という思想で設計されています。
例えば、以下のワークフローでは、上記と同様に、総務部門向けにメールで問い合わせが来たら、エージェントが調査して、回答が得られたか、Prompt でサクッと判定して、次に条件判定して、回答が得られていたらメールに返信、回答できなかった場合は総務に代理で問い合わせを行ってます。
もちろん、上述の通り、従来の方法でも同じようなものを作れるのです。しかし、
| # | ステップ | 作業内容 | 成果物 |
|---|---|---|---|
| 1 | トリガーの Power Automate フローの作成 | Automate を作成して、エージェントに情報を渡すトリガーフローを構築する | Power Automate フロー |
| 2 | トリガー追加とエージェント指示文への反映 | エージェント内の指示文で、トリガーから受け取る情報を明示的に指定する | エージェント指示文(トリガー対応) |
| 3 | ナレッジ追加とエージェント指示文への反映 | ナレッジから検索して回答を生成する。検索する条件や対象範囲を指示文に記載する | ナレッジ設定+エージェント指示文 |
| 4 | ツールの定義・作成 | コネクタやエージェントフローなど、エージェントが呼び出すツールを定義・作成する | コネクタ/エージェントフロー |
| 5 | ツール作成とエージェント指示文への反映 | 生成した回答を条件判定し、呼び出すツールや応答の内容を指示文で指定する | エージェント指示文(条件分岐対応) |
このような感じになり、エージェントの指示文が少なからず増える (コンテキストが増える) ことや作成する部品が増えることになると思います。
これらの条件判定や情報の受け渡しはプログラム的というかワークフロー的に実装できると思います。そのため、上記方法で実装する場合、エージェントはナレッジからの回答生成に特化させ、コンテキストを減らすことが出来るメリットもあると思います。
整理すると、新しいワークフローでは、業務プロセスの入り口から出口まで、一つのワークフローとして表現します。そのなかに、エージェントを処理の一ステップとして組み込むことができます。しかも、Copilot Studio で作成したエージェントだけでなく、M365 Copilot 側のエージェントも呼び出せる点が特徴的です。
たとえば、
「メールを受信する → エージェント A が内容を判断する → エージェント B が回答案を作成する → 担当者に確認を依頼する → 承認されたら送信する」
といった一連の業務プロセスを、ワークフロー上で表現できます。エージェントはこのワークフローのなかの一処理として位置づけられ、ワークフローがその全体を束ねる役割を担います。
なぜこの転換が生まれたのか
エージェント起点の設計(エージェントにツールを追加していく方法)でも、実現できることは多くあります。ただ、複数のエージェントやツールを連携させようとしたとき、エージェントの外側にも部品を作り、エージェント同士やツール間でつなぎ合わせる構造が複雑になっていきます。
ワークフロー主軸の設計では、業務プロセスの流れ自体をワークフローが受け持ち、推論が必要なところにだけエージェントを差し込む、という構造になります。エージェント A、エージェント B、エージェント C がワークフローのなかでつながり、プログラム的に実行したい処理もその間に入れながら、業務の入り口から出口まで一本の流れとして表現できる形です。
「エージェントを業務プロセスに組み込む」のではなく、「業務プロセスのなかにエージェントがある」という発想の転換が、新しいワークフローの背景にあるのではないかと考えています。AIエージェントが業務に組み込まれていくという流れを踏まえると、この方向性は自然な進化ではないかと感じています。
個人的に思うこと:市民開発者にとっての難しさ
ここからは個人的な見立てです。
設計思想としては理解できるものの、現時点で市民開発者の方にとっては、少なからず難易度が上がっている印象を受けます。
Power Automate を覚え、その延長で Copilot Studio にチャレンジされてきた方からすると、「エージェントフロー」「ワークフロー」「Topic」と、作り方の異なるものが増えてきており、どれを選べばいいのかが判断しにくい状況になっています。
また、新しいワークフローは現時点でプレビュー段階であり、UI も英語中心のため、日本の一般的な従業員の方が今すぐ使いこなすのは難しいと感じています。エンジニア寄りの方や、Power Platform に深く慣れている方にとっては歓迎される変化だと思いますが、ライトな市民開発者の方に対しては、もう少し落ち着いてから取り上げるのが現実的ではないかと思います。
当面は既存のエージェントフローを継続運用しつつ、新しいワークフローは GA (一般提供) になってから改めて検討する、というスタンスで良いかと考えています。
補足:ライセンスについて
両者ともに Copilot Studio のキャパシティ(Copilot Credits)で動作します。Power Automate のライセンスは不要で、プレミアムコネクタも追加課金なしで利用できます。
Microsoft 365 Copilot ライセンスをお持ちのユーザーがエージェントフローを実行した場合、キャパシティが枯渇しても影響を受けない旨が公式ドキュメントに明記されています。新しいワークフローについても同様の記述が公式ドキュメントにはありますが、実際に検証してみるとクレジット消費が発生するケースが見られました。プレビュー段階のため詳細は不明であり、一般提供時に改めて確認が必要と考えています。
まとめ
今回は、Copilot Studio の「ワークフロー」と「エージェントフロー」の設計思想の違いを整理してみました。
- エージェントフロー:エージェントが主役。Power Automate のフローをツール(手足)として呼び出す構造
- 新ワークフロー:ワークフローが主役。業務プロセスの流れのなかにエージェントが処理の一部として組み込まれる構造
細かな機能の違いよりも、この思想の違いを理解することが、どちらを選ぶかを考えるうえで最も重要なポイントではないかと考えています。
新しいワークフローはまだプレビュー段階であり、安定しない部分もあると思います。私の理解が誤っている部分もあるかもしれませんので、「私の手元ではこうだった」「こういう使い方が合っていた」といった情報をいただけると大変参考になります。引き続き情報が入り次第、整理していきたいと考えています。
本記事が、Copilot Studio のフロー周りの整理にお役に立てば幸いです。
参考リンク(Microsoft Learn / Microsoft 公式ブログ)
- Agent flows and workflows overview - Microsoft Copilot Studio | Microsoft Learn
- Edit and manage your agent flow or workflow in the designer - Microsoft Copilot Studio | Microsoft Learn
- Agent flows in Microsoft Copilot Studio FAQ - Microsoft Copilot Studio | Microsoft Learn
- Add an agent node to an agent flow or workflow - Microsoft Copilot Studio | Microsoft Learn
- What's new in Copilot Studio - Microsoft Copilot Studio | Microsoft Learn
- Automate business processes with agents plus workflows in Microsoft Copilot Studio | Microsoft Copilot Blog(2026年4月10日)




