GVATECHブログ
🗻

Copilot Studio エージェントからツールとしてエージェントフローを呼び出した際の100秒タイムアウトの解決方法

に公開

1.はじめに

社内の業務改革の調査の一環としてCopilot Studioのエージェントとエージェントフローを活用しようと模索していたのですが、3分程度の処理を動かしてみると「504 Gateway Timeout」が起こってしまい、あまり適切な記事もこの段階では見つからなかったため解決策を残しておきたいと思います。
(もっといい方法はあるかもしれませんがご了承ください🙇)
エージェントフローを呼び出す流れとしてはエージェントのトピック から ツールとしてエージェントフロー を呼び出しています。

2.この記事を読むための前提知識

本記事は、以下の Microsoft Copilot Studio および Power Platform 関連の技術要素について、ある程度の知識と構築経験をお持ちの読者を対象としています。

  • Copilot Studio: エージェント(ボット)の基本的な作成・管理方法。
  • トピック: ユーザーの入力に応答するための会話ロジックの設計。
  • ツール: Copilot Studio から外部システム連携を行うための呼び出し機能。
  • エージェントフロー: ツールとして利用する Power Automate Cloud Flow の構築と、エージェントとの入出力連携。

システム変数: $System.Conversation.Id や $System.Bot.Id など、エージェントのコンテキスト情報を取得する方法。

これらの要素を組み合わせてエージェントを構築したことがある方を想定して、記事の解説を進めています。

3.事象

ActionResponseTimedOut. The execution of template action 'Respond_to_the_agent' is failed: the client application timed out waiting for a response from service. This means that workflow took longer to respond than the alloted timeout value. The connection maintained between the client application and service will be closed and client application will get an HTTP status code 504 Gateway Timeout.

自分が作成したエージェントフローはエージェントにレスポンスを返すまでの間に3分経過してました。
調べてみると公式ドキュメントに以下記載がありました。

100秒のアクション制限内にエージェントに応答してください。フローロジック、クエリ、返されるデータ量を最適化し、通常の実行時間がこの100秒の制限を下回るようにしてください。フロー内でより長い実行時間が必要なアクションは、「Copilotへの応答」アクションの後に配置することで、フロー実行期間の制限である30日間まで実行を継続できます。

100秒以内にエージェントへレスポンスを返さないといけない仕様のようです。

4.解決方法

4-1.エージェントフローの修正

フロー内でより長い実行時間が必要なアクションは、「Copilotへの応答」アクションの後に配置することで、フロー実行期間の制限である30日間まで実行を継続できます。

こちらの公式ドキュメントには上記記載がありましたので、エージェントフローで長い処理の部分は「エージェントに応答アクション」の後に配置を行うロジックに変更しました。その後長い処理した結果のエージェントに値を渡すような仕組みも今回取り入れています。

before

1.エージェントがフローを呼び出したとき
2.長い処理
3.エージェントに応答する

after

1.エージェントがフローを呼び出したとき
2.エージェントに応答する
3.長い処理
4.Direct Line API 3.0用のシークレットを取得
5.HTTPアクションでエージェントに会話送信する

afterの処理の「4.Direct Line API 3.0用のシークレットを取得と5.HTTPアクションでエージェントに会話送信する」の部分が、長い処理をした結果をエージェントに返すために必要な部分になります。
ステップごとに詳しく記載していきます。

1.エージェントがフローを呼び出したとき

最後の「5.HTTPアクションでエージェントに会話送信する」のステップに必要になる以下3つの項目を入力で受け取れるようにします。

  • 会話ID
  • エージェントID
  • ユーザーID

2.エージェントに応答する

今回は「処理を受け付けました。完了したら通知します。」という応答を行います。(任意の値で大丈夫です)

3.長い処理

本来はLLMへの呼び出しなど長い処理が入る想定ですが、Delayアクションで長い時間を再現します。

4.Direct Line API 3.0用(エージェントにメッセージを送信する為)のシークレットを取得

今回はエージェントのシークレットをAzure key vaultに作成し、エージェントフローで環境変数として呼び出せるように行なっています。
Azure key vaultあたりの設定方法はこちらのドキュメントを参考にしました。

5.HTTPアクションでエージェントに会話送信する

  • Body
    • type: message
    • text: エージェントに渡したい値をここに入れる
    • from.id: 1.の入力の「エージェントID」を指定する
    • recipient.id: 1.の入力の「ユーザーID」を指定する
    • locale(任意): ja-JP
{
  "type": "message",
  "text": "【処理完了】結果は:\n\n{エージェントに渡したい値}",
  "from": {
    "id": "{1.の入力の「エージェントID」}"
  },
  "recipient": {
    "id": "{1.の入力の「ユーザーID」}"
  },
  "locale": "ja-JP"
}

Direct Line API 3.0のアクティビティ送信エンドポイントはユーザー -> エージェント宛に会話を送信する時にも使えますが、上記はエージェント -> ユーザーに会話を送信する値にしています。

from.id フィールドは、アクティビティの送信元を示します。
recipient.id フィールドは、アクティビティの受信先を示します。

余談ですがユーザーがメッセージを送る場合(クライアント -> エージェント)は、from.idにユーザーID、recipient.idにエージェントIDを設定します。

4-2.トピックでエージェントフローを呼び出している箇所の修正

ツールとしてエージェントフローを呼び出している箇所で、エージェントフローからエージェントにアクティビティをAPI経由で送信するために必要な情報を入力として追加します。

どの値もシステム変数に入っています。

  • 会話ID: System.Conversation.Id
  • エージェントID: System.Bot.Id
  • ユーザーID: System.Activity.From.Id

以上手順を取り入れることで100秒タイムアウト制限対策と、エージェントフローで長い100秒以上の長い処理をした結果をエージェントに送ることができます。

6. おわりに

本記事では、Copilot Studio のエージェントフローにおける 100秒のタイムアウト制限 を、非同期処理と Direct Line API を利用して回避する具体的な方法を解説しました。
もし、この記事の手法よりも良さそうな解決策をご存知でしたら、ぜひコメントでご教示ください!
最後までお読みいただきありがとうございました。

GVATECHブログ
GVATECHブログ

Discussion