Power AutomateとCopilotを連携させて業務を効率化したいけれど、具体的にどう呼び出せばいいのか分からずに悩んでいませんか。Power Automateの連携機能を使えば、対話型エージェントから処理を自動起動したり、ワークフローの中からAI推論を実行したりと、自動化の幅が格段に広がります。
しかし、いざ設定を始めるとタイムアウトエラーが発生したり、パラメータの引き渡しが上手くいかなかったりと、細かいところでつまずきがちですよね。設定の全体像や注意点があらかじめ整理されていれば、迷わずスムーズに構築を進められるはずです。
この記事では、初心者の方向けにPower AutomateとCopilotの双方向呼び出しに関する基本概念から、エラーの回避策、ライセンスの考え方まで分かりやすく解説します。ぜひ最後まで読んで、日々の業務自動化に役立ててみてくださいね。
- Power AutomateとCopilotを連携させる2つの基本パターンの仕組み
- 100秒タイムアウトエラーを防ぐための二段階分離設計の手順
- AI Builderやコネクタを活用したデータ抽出・処理の具体的な実装ポイント
- 連携時に発生しやすい代表的なエラーの解決方法とライセンスの注意点
Power AutomateとCopilot呼び出しの基本
Power AutomateとCopilotの連携を成功させる第一歩は、どちらが起点となって処理を呼び出すのか、その構造をしっかり整理することです。ここをあらかじめ理解しておくと、設定時につまずきにくくなりますよ。
Copilot Studioと連携する仕組み
Copilot StudioからPower Automateを呼び出す場合、Copilot（チャットボット）がユーザーの発話を理解し、必要なアクションを実行するための「ツール」としてクラウドフローを起動する仕組みになります。ユーザーがチャット画面で「今月の売上データを集計して」や「経費申請を行いたい」と呼びかけた際、Copilotがその意図を汲み取って裏側で連携されたPower Automateを起動するイメージですね。
この連携を実現させるためには、いくつかの明確なルールが存在します。
まず押さえておきたいのが、通常の「マイ フロー」として作成したフローはCopilotから直接認識されないという点です。Copilot Studioのエージェントと呼び出したいフローは、必ず同じDataverse環境内に存在し、かつ同じDataverseソリューションの内部に含まれている必要があります。環境やソリューションの境目を越えて直接参照させることはできない仕様になっているため、構築初期段階での箱作りが極めて重要になってきます。
Copilot Studioのツール画面から「新しいフローを作成」を選ぶと、必要なトリガーとアクションが入った専用のフロー雛形がソリューション内に自動作成されます。ゼロから作るよりも間違いが少ないのでおすすめですよ。
具体的なソリューション構造やエージェント連携の全体像について深く知りたい方は、Copilot Studioで何ができるか解説した記事も合わせて参考にしてみてください。
エージェントフローで自動化する手順
Copilotから呼び出される専用フロー（エージェントフロー）の作成手順は、非常にシンプルです。従来のPower Virtual Agents時代に作成されていたフローと基本構文は似ていますが、最新のCopilot環境ではエージェント専用のトリガーとアクションが組み合わさる形で提供されています。
作成の基本となる流れは以下のとおりです。
- Copilot Studioの「ツール」タブからフローの新規作成を選択する
- トリガー「エージェントがフローを呼び出したとき」で入力パラメータを定義する
- 必要なビジネスロジック（メール送信、データ検索、更新処理など）をアクションとして配置する
- 終端アクション「エージェントに応答する」でCopilotに返す出力値を設定する
各ノードでの設定における重要ポイント
ステップ2の入力パラメータ定義では、Copilotがチャットの文脈から引き渡すべき変数（例：ユーザー名、申請ID、検索キーワードなど）をデータ型（テキスト、数値、ブール値など）を指定して定義します。ステップ3では、SharePoint listsやExcel Online、Dynamics 365といった多様なコネクタを配置して実際の業務処理を組み込んでいきます。
最後のステップ4である終端ノード「エージェントに応答する」では、処理結果メッセージや取得したデータ値を応答プロパティとして割り当てます。エージェントフローの最大の役割は、チャット上での会話データを受け取り、裏側で決定論的な業務処理を行って、その結果を再びチャット画面へと戻すことにあります。
100秒タイムアウトエラーの回避方法
Copilot Studioからフローをリアルタイムで同期呼び出しする際、絶対に知っておくべき制限が100秒のタイムアウトです。
チャットで話しかけているユーザーは、Copilotからの返答をその場で待っている状態になります。そのため、呼び出されたフローが応答を返すまでに時間がかかりすぎると、プラットフォーム側で処理が強制終了されてしまいます。結果としてチャット画面にはシステムエラーが表示され、ユーザー体験を著しく損ねることになってしまいます。
標準のタイムアウト上限は2分（120秒）ですが、実用上の推奨ラインとして100秒以内の応答完了が厳格に定められています。承認処理や重いデータ集計などを同期処理のまま組み込むと、ほぼ確実にタイムアウトエラーが発生してしまいます。
この問題を回避するための王道テクニックが「二段階分離設計（Split Pattern）」です。
| フェーズ | 配置する位置 | 主な処理内容 | 所要時間の目安 |
|---|---|---|---|
| フェーズ1（同期フェーズ） | 「エージェントに応答する」の前 | 入力値のチェック、受付番号の発行、仮登録 | 数秒以内（100秒制限を余裕でクリア） |
| フェーズ2（非同期フェーズ） | 「エージェントに応答する」の後 | 上長への承認依頼カード送信、大規模バッチ処理、完了メール送信 | 数分〜最大30日間（バックグラウンドで実行） |
このように、「受け付けました」という応答だけを数秒でCopilotへ返して会話を一旦終了させ、重い処理は応答アクションの後ろに配置してバックグラウンドでじっくり実行させるのが、タイムアウトを防ぐ最も確実な方法です。フローの後続処理はバックグラウンドで独立して動き続けるため、長時間かかる処理であってもエラーで途切れることがありません。
非同期応答のオフ設定に関する注意点
前述の二段階分離設計を正しく動作させるためには、フローの終端にある「エージェントに応答する」アクションのプロパティ設定に注意が必要です。
アクションの詳細設定内にある「非同期応答（Asynchronous response）」トグルは、必ず「オフ」にしておかなければなりません。
なぜ「非同期応答」をオフにする必要があるのか？
一見すると「非同期で動かすのだからオンにするのでは？」と混乱しやすい部分ですよね。しかし、この設定項目の意味は「Copilot側がフローの応答を待たずに非同期で処理を進めるか」という制御フラグになっています。
ここがオンになっていると、Copilotはフローの完了や戻り値を待たずに後続の会話を進めようとしてしまうため、せっかく準備した戻り値（受付番号など）が対話文脈に引き渡されず、会話が支障をきたす原因になります。応答アクションより前の同期フェーズで確実にデータを返しつつ、後続アクションを裏で動かすためには「非同期応答：オフ」が必須条件となります。初期設定をしっかり確認しておきましょうね。
入力パラメータと説明文の最適化
Copilotからフローに必要なデータを正しく引き渡すためには、トリガーノード「エージェントがフローを呼び出したとき」の設定がカギを握ります。
パラメータ名を設定するだけでなく、各パラメータの「説明（Description）」欄を丁寧に記述することが非常に重要です。
説明文設定のコツ：
Copilotの自律推論エンジンは、ユーザーの発話から抽出する値を決める際にこの「説明文」を読み取ります。
例えば、「商品名（名詞のみで抽出）」や「申請日（YYYY-MM-DD形式に正規化）」のように具体的な指示を書いておくと、ユーザーが「明日のリンゴの在庫は？」と自然言語で入力した際にも、正確な値だけをフローに受け渡せるようになります。
説明文（Description）は単なる人間用のメモ書きではなく、生成AIに対するプロンプト（指示文）として機能しています。曖昧な記述にしておくと、Copilotが「どの値をフローに渡せばいいのか」を正しく判断できず、会話の中で何度も聞き返しが発生したり、意図しない引数が渡されてフロー側で型エラーになったりします。型や制約条件を含めて、できるだけ明確に記述する癖をつけておきましょう。
実践Power AutomateとCopilot呼び出し活用
ここからは、Power Automate（ワークフロー）を起点としてCopilotやAI推論機能を呼び出す、より実践的な活用方法やよくあるトラブルの対策について詳しく見ていきましょう。
AI BuilderプロンプトでJSONを出力
「メールを受信したときに要約したい」「クレーム内容の緊急度を判定したい」といったテキスト解析タスクを行う場合、Copilot Studio全体を呼び出すよりも、Power AutomateからAI Builderの「プロンプトを実行する（Run prompt）」アクションを使うのが最もスマートです。構築手順がシンプルになり、呼び出しのオーバーヘッドも抑えられます。
AIモデルの返答は表現の表記揺れが発生しやすいのが難点ですが、AI Builderでプロンプトを作成する際に出力形式を「JSON」に指定しておくと、この問題を見事に解決できます。
JSON指定とスキーマ解析のメリット
AIに対して「以下のメール本文を解析し、件名・緊急度（高/中/低）・要約の3項目をJSON形式で返してください」と指定し、プロンプトの出力設定をJSON形式にしておきます。確定した構造（キーと値のペア）でデータを出力させることで、後続の「JSON の解析」アクションを使って正確な変数として展開できるようになります。型エラーに悩まされることなく、条件分岐やデータベースへの登録を確実に行えますよ。
詳しいAIエージェントの作成概念やデータ抽出手法については、Copilotエージェントの基本解説記事でも触れていますので、参考にしてみてくださいね。
コネクタを使ったエージェントの実行と待機
自動化ワークフローの中で、すでに作成済みのCopilot Studioエージェントに問い合わせを行い、その回答結果をメールやTeamsに転送したい場合は「Microsoft Copilot Studio」標準コネクタを利用します。
フローデザイナーでこのコネクタを選択し、「エージェントの実行と待機（Run agent and wait）」アクションを配置しましょう。
主な設定手順と動的コンテンツの活用
アクションのパラメータにメッセージ本文（メールの件名や本文などの動的コンテンツ）を渡し、ロケールを「ja-JP」などに設定します。フローが実行されると、システムは指定されたCopilotエージェントに対してバックグラウンドでセッションを開始し、AIが回答を作成し終えるまで同期的に待機します。
処理が完了すると、Copilotからの最新の返答文がlastResponseという動的コンテンツとして出力されます。これをTeamsへの投稿アクションなどに渡すだけで、FAQボットの回答を自動でスレッド返信させるような高度な連携が数ステップで完成します。
エージェントハーネスの制約と適用業務
Power AutomateからCopilot Studioエージェントを呼び出す際、エージェントがどのランタイム構造（ハーネス）で動いているかによって、コネクタから直接呼び出せるかどうかが決まります。プラットフォーム側のアーキテクチャ設計に依存する部分ですので、事前に各ハーネスの特徴を把握しておきましょう。
| ハーネス種別 | Power Automateからの直接呼び出し | 特徴と機能の範囲 | 適した業務シナリオ |
|---|---|---|---|
| 標準ハーネス | 完全対応 | 定義されたトピックやルールに基づき、決まった手順で確実な結果を返す。 | 社内問い合わせの自動回答、定型データの自動仕分け |
| GitHub Copilot ハーネス | 直接呼出不可 | 高度な多段階推論やエラーの自律回復、Officeファイルの直接生成などに対応。 | 複雑な請求書と発注書の照合、高度な例外処理 |
| Copilot チャット ハーネス | 直接呼出不可 | Microsoft 365 Copilot内で組織ナレッジ（SharePoint等）を活用する専用機能。 | 社内文書検索、新入社員のオンボーディング補助 |
自律推論機能を持つ「GitHub Copilot ハーネス」などの高度なエージェントは、セキュリティや仕組みの都合上、クラウドフローのコネクタから直接呼ぶことができません。こうしたエージェントを組み合わせたい場合は、Copilot Studio側のワークフロー機能を使って全体の流れを設計するのが基本です。自社が導入したいシナリオがどのハーネスに該当するか、事前に十分な検証を行いましょう。Copilot Studioの具体的な活用事例や社内データ連携についてはCopilot Studio活用事例の記事で詳しく紹介されています。
ライセンス費用とクレジット消費の仕組み
導入時に多くの方が高確率で疑問に思うのがライセンスやコストの仕組みですよね。どこでどのライセンスが消費されるのか、パターン別に整理しておきましょう。
よくある注意点：
個人向けの「Microsoft 365 Copilot」ライセンスを持っているだけでは、Power Automateからエージェントを自律実行させたりすることはできません。これらはPower Platformの機能となるため、組織単位での「Microsoft Copilot Studio」容量ライセンスやAzure従量課金の設定が必要になります。
具体的には、Copilot StudioからPower Automateを呼び出す、あるいはPower AutomateからAI Builder/Copilotを起動するたびに、テナントに付与されている「Copilot Studioメッセージクレジット」や「AI Builderクレジット」が消費されます。詳細な料金プランやコスト最適化の考え方については、公式のライセンスドキュメント（出典：Microsoft Learn『Power Automate ライセンスに関してよく寄せられる質問』）を確認しておくと確実です。
コストを最適化するための重要なテクニックとして、Power Automate側のトリガー条件（Trigger Conditions）の活用が挙げられます。
例えば「メールが届いたとき」をトリガーにする場合、無条件ですべてのメールに対してAIプロンプトを実行するとクレジットが激しく消費されてしまいます。トリガー設定で「件名に【見積依頼】が含まれている場合のみ起動する」といったフィルタを設けておくことで、無駄な実行とコストを大幅にカットできますよ。
FlowActionBadRequestの対処法
開発中によく遭遇するのが、フローのテストを実行した際に発生する「FlowActionBadRequest」というエラーです。
このエラーの主な原因は、フロー側でパラメータの追加や名前の変更を行ったことで、Copilot Studio側が保持しているスキーム情報とズレが生じてしまったことにあります。フローを変更したにもかかわらず、Copilot側が古い定義情報を参照し続けているために通信拒否が発生してしまうのですね。
FlowActionBadRequestが発生したときの解決手順：
1. Copilot Studioのトピック編集画面を開き、該当するフローアクションのメニューから「更新（Refresh）」を実行する
2. エージェントを一度保存し、改めて「公開（Publish）」を行う
3. Teams上でテスト中の場合はキャッシュが残っていることがあるため、チャット欄に /debug clearstate と入力して会話コンテキストをリセットする
この手順を順に行うだけで、スキームの不一致が解消されて再び正しく動くようになるケースがほとんどです。設定を変更した際は「フロー保存 → Copilot側で更新 → 公開」という一連のキャッシュクリア手順をセットで行う習慣をつけておくとトラブルを防げますよ。
初心者向けPower AutomateとCopilot呼び出しまとめ
今回は、Power AutomateとCopilotの双方向呼び出しについて、基本的な仕組みからエラー回避のTipsまでを分かりやすく解説しました。
Copilot Studioからフローを呼び出す際は「ソリューション内での作成」と「100秒タイムアウトを意識した二段階設計」が成功のカギです。一方、フローからAIを呼び出す際は「AI BuilderのJSON構造化出力」や「トリガー条件によるコスト削減」がポイントになってきます。
それぞれの強みを正しく理解して連携させれば、これまで手作業で行っていた複雑な業務もスマートに自動化できるようになります。まずはシンプルなフローから、ぜひチャレンジしてみてくださいね。
