はじめに
Azure Logic Appsを運用していると、一時的なエラーなどで失敗したワークフローを「再実行（Resubmit）」する作業が頻繁に発生します。通常、これを行うにはAzureポータルにログインし、対象のリソースを探し、実行履歴から該当のIDを特定してボタンを押す……という複数のステップが必要です。
「これをTeamsからチャット感覚で指示できたら楽なのに」という思いから、今回はLogic Apps (Consumption) に新しく追加された 「自律型AIエージェント (Autonomous Agent)」 を利用し、Teamsチャットのメッセージからリソースを特定して再実行まで完結させるBotを構築しました。
実は従来のLogic Appsの標準的なアクション（分岐やループ）だけでも実装は可能ですが、あえてエージェントを使うことで得られるメリットや、実装上の工夫をまとめました。
1. なぜ「自律型AIエージェント」なのか？
今回の「メッセージを解析してAPIを叩く」という要件は、普通のLogic Appsでも実装可能です。しかし、あえて自律型AIエージェントを使用した理由は以下の通りです。
・ 表記揺れへの対応
「Logic App Aを再送信」「Aの0858...をリサミット」といった曖昧な指示を、AIが文脈を汲み取って解釈してくれます。
従来のアプローチでは、正規表現や複雑な文字列操作が必要でしたが、AIを使うことで自然言語のバリエーションに柔軟に対応できます。
・ ロジックの極小化
これが最大のメリットです。 成功・失敗時の分岐条件や、返信メッセージの組み立て（Compose）をAIに委譲することで、デザイナー上のワークフローが劇的にシンプルになります。
従来のアプローチ（Conditionアクション使用）:
ツール 1実行 → Condition: 成功?
├─ True: ツール 2実行 → Condition: 成功?
│ ├─ True: ツール 3実行 → Condition: 成功?
│ │ ├─ True: 成功メッセージ作成 → Teams送信
│ │ └─ False: エラーメッセージ作成 → Teams送信
│ └─ False: エラーメッセージ作成 → Teams送信
└─ False: エラーメッセージ作成 → Teams送信
自律型エージェント:
Agent: ツール 1実行 → 判断 → 適切な次のツールを選択
重要
Logic Apps Autonomous Agentでは、ConditionやSwitch、Foreachなどの制御フローアクションが使用できません。そのため、従来のように「処理にConditionで分岐」することができず、ツールの分割とAIの自律判断に頼る設計が必須となります。
・ 動的な意思決定
実行失敗時に「何が原因か」をAIが判断し、次のツールを自律的に選択して適切なエラー案内を作成します。
例えば、ツール2で失敗した場合、AIは「ツール1は成功しているからメッセージ解析は問題ない。でもツール2で失敗したということはLogic Appが見つからなかった」と判断し、適切なエラーメッセージを生成します。
さらに重要なのは、メッセージの内容自体もAIが動的に生成することです。成功時には詳細情報を含む丁寧なメッセージを、エラー時には状況に応じた具体的な対処方法を含むメッセージを、AIが自律的に作成します。
これにより、メッセージ組み立て用の複雑なComposeアクションやテンプレート管理が不要になり、Agent Instructionsで出力フォーマットを指定するだけで、AIが適切なメッセージを生成してくれます。
2. アーキテクチャ全体像
AI（Agent）が「頭脳」となり、事前に定義した 5つの「ツール（手足）」 を必要に応じて呼び出します。
・ 5つのツール構成
| ツール名 | 役割（単一責任） | 特徴 |
|---|---|---|
| ツール 1: Parse Message | メッセージから文字列を抽出 | ChatCompletion APIで柔軟に解析 |
| ツール 2: Get Logic App Info | 名前からリソースIDを特定 | Resource Graphで全サブスクリプションを検索 |
| ツール 3: Get Trigger Name | トリガー名を取得 | 実行履歴APIから自動取得 |
| ツール 4: Resubmit Workflow | 再実行APIを実行 | Resubmit API呼び出し |
| ツール 5: Send Teams Reply | Teamsに投稿 | AIが生成したメッセージを送信 |
従来のLogic Appsでは、これらすべての矢印を「条件分岐（Switch/If）」で繋ぐ必要がありましたが、自律型エージェントでは 「次にどのツールを使うべきか」「どんなメッセージを送るべきか」をAIが自律的に判断 します。
実際のLogic Appsデザイナー上の構成は以下の通りです。
AIエージェントが「頭脳」となり、その配下に「ツール（手足）」となるアクション群が並ぶ、非常にスッキリした見た目になります。
・ 実行フローの例
成功時:
User: "resubmit TestApp 0858..."
Agent: ツール 1 (Parse Message) → 成功
workflowName: "TestApp", runName: "0858..."
Agent: ツール 2 (Get Logic App Info) → 成功
subscriptionId, resourceGroupを取得
Agent: ツール 3 (Get Trigger Name) → 成功
triggerName: "manual"
Agent: ツール 4 (Resubmit Workflow) → 成功（202）
Agent: "成功した！適切な成功メッセージを作成しよう"
message: "✅ Logic App実行の再送信が完了しました
📋 詳細:
- Logic App: TestApp
- 実行名: 0858...
- ステータス: 再送信受付完了（202 Accepted）
新しい実行が開始されました。"
Agent: ツール 5 (Send Teams Reply) → メッセージ送信
エラー時（権限不足）:
User: "resubmit TestApp 0858..."
Agent: ツール 1～3 → 成功
Agent: ツール 4 (Resubmit Workflow) → 失敗（403）
Agent: "403エラーだ。権限不足のエラーメッセージを作成しよう"
message: "❌ Logic App実行の再送信に失敗しました
📋 詳細:
- エラー: 権限が不足しています。
Logic App Contributor以上の権限が必要です
- ステータスコード: 403
対処方法:
- IT管理者に権限付与を依頼してください"
Agent: ツール 5 (Send Teams Reply) → エラーメッセージ送信
ポイント: メッセージ内容はAIが動的に生成するため、エラーの種類に応じて自然で適切な文章になります。
3. 権限設定
AgentがAzureリソースを操作するため、Logic AppのマネージドIDに以下のロールを付与します。
| 役割 (Role) | スコープ | 目的 |
|---|---|---|
| Reader | サブスクリプション | Resource Graphで対象のLogic App IDを検索するため |
| Logic App Contributor | サブスクリプション | 再実行 (Resubmit) APIを実行するため |
権限付与の省略
通常、Logic AppからAI（Azure OpenAI）を直接呼び出すには Cognitive Services OpenAI User 権限が必要です。しかし今回は、「別のLogic Appをプロキシとして経由し、ChatCompletion APIを呼び出す」 構成をとっています。これにより、本ワークフロー自体へのAI関連権限の付与を省き、権限管理の分離と簡素化を実現しました。
4. Agent インストラクション（AIへの指示書）
エージェントの挙動を左右する「インストラクション」は、Geminiなどの生成AIに叩き台を作成してもらうのが最も効率的です。
「以下のツール（API）を使って、Teamsからの再実行依頼を処理するLogic Appエージェントの指示書を書いて」と依頼して作成したものがこちらです。
・ 完全なAgent Instructions
あなたはAzure Logic Appsの再実行を担当するAIエージェントです。
## 役割
Teamsチャットから送信されたメッセージを解析し、指定されたLogic Appの実行を再送信（resubmit）します。
## 処理フロー
1. ユーザーのメッセージからLogic App名と実行名（Run Name）を抽出
2. Logic Appsのリソース情報を取得
3. トリガー名を取得
4. 実行を再送信
5. 結果に応じてメッセージを生成し、Teamsチャットに返信
## メッセージ解析ルール
ユーザーのメッセージには以下のいずれかの形式が含まれます:
- 「resubmit」キーワードが必ず含まれる
- Logic App名と実行名は柔軟な表現が可能
- 例1: "resubmit\nLogic apps A\n08584318751676908512439077168CU46"
- 例2: "TestLogicAppというLogic appsの08584318751676908512439077168CU46を再実行して"
- 例3: "resubmit TestLogicApp 08584318751676908512439077168CU46"
## エラーハンドリング
以下のエラーが発生した場合、適切なエラーメッセージをTeamsに返信してください:
- Logic Appが見つからない → "Logic App '{name}' が見つかりませんでした"
- 実行履歴が見つからない → "実行履歴 '{runName}' が見つかりませんでした"
- 権限不足 (403) → "権限が不足しています。Logic App Contributor以上の権限が必要です"
- その他のエラー → HTTPステータスコードとエラーメッセージを表示
## 出力フォーマット
成功時:
✅ Logic App実行の再送信が完了しました
📋 詳細:
- Logic App: {workflowName}
- 実行名: {runName}
- ステータス: 再送信受付完了（202 Accepted）
失敗時:
❌ Logic App実行の再送信に失敗しました
📋 詳細:
- エラー: {error_message}
- ステータスコード: {status_code}
・ Agent Instructionsのポイント
重要: 「出力フォーマット」セクションで、AIが生成すべきメッセージの具体例を明示しています。
これにより、AIは状況に応じて適切なメッセージを自動生成します。メッセージ組み立て用の複雑なComposeアクションやテンプレート管理が不要になり、メッセージフォーマットの変更もAgent Instructionsを修正するだけで完結します。
5. ツール実装と「単一責任の原則」
各ツールは 「一つの役割だけを完璧にこなす」 という単一責任の原則を遵守させます。これによりAIの迷いがなくなり、精度が向上します。
今回用意した5つのツールは以下の通りです。
| ツール名 | 役割（単一責任） | Agent Parameters |
|---|---|---|
| Parse Message | メッセージから必要な文字列を構造化データとして抽出する | messageContent |
| Get Logic App Info | 名前からAzureリソースIDを特定する | workflowName |
| Get Trigger Name | 管理APIから対象のトリガー名を取得する | subscription, resourceGroupName, workflowName, runName |
| Resubmit Workflow | 指定されたIDに対して再実行APIを実行する | subscription, resourceGroupName, workflowName, triggerName, runName |
| Send Teams Reply | AIが生成した文章をTeamsに投稿する | message |
Send Teams Replyツールの特徴:
- Agent Parameterは
messageの1つだけ -
messageの内容はAIが自動生成 - メッセージをそのまま送信するだけのシンプルな構造
6. 実装深掘り：Get Logic App Info
ここでは、エージェントが「名前」から「リソースの実体」を特定する重要なツールをご紹介します。
・ Agent Parameter の役割
エージェントはツールを呼び出す際、Agent Parameter を介して情報をやり取りします。
Zennの記事でも紹介されている通り、これは「AIがそのツールを使うために必要な引数」を定義するものです。
ここでは workflowName というパラメーターを定義し、AIが「ユーザーのメッセージから見つけた名前」をここに入れるよう指示しています。
・ 内部ロジック：Azure Resource Graph
ツールの内部では、AIから渡された名前を使って Azure Resource Graph をクエリします。
「Compose - ResourceGraphQuery」アクションで使用したKQLクエリ
resources
| where type == 'microsoft.logic/workflows' and name == '@{agentParameters('workflowName')}'
| project id, name, resourceGroup, subscriptionId
このクエリにより、AIは「名前」という断片的な情報から、API実行に必要な「完全なリソースID」へと情報を補完することができます。
なぜComposeアクションを使うのか？
- 保守性: クエリの変更が容易
- 可読性: デザイナー上で処理フローが明確
- デバッグ: 各ステップの出力を実行履歴で確認可能
7. Agent のデバッグ方法
「AIがなぜその行動をとったのか？」は、右側の実行履歴 Agent Log から詳細に確認できます。
ログを見ると、AIが「まずメッセージを解析し、次にリソース情報を探し……」というステップを順次踏んでいることがわかります。最後に「Logic App実行の再送信が完了しました」というメッセージをAIが自ら生成し、Send Teams Replyを叩いている様子まで一目瞭然です。
・ Agent Logで確認すべきこと
- ツール実行順序: 期待通りの順序でツールが呼ばれているか
- Agent Parameter: 各ツールに渡されたパラメータが適切か
-
AIが生成したメッセージ:
messageパラメータの内容が適切か
・ メッセージが期待と異なる場合
原因: Agent Instructionsの「出力フォーマット」が不十分
解決策:
- Agent Instructionsの「出力フォーマット」セクションをより詳細に
- 含めるべき情報を明示的に列挙
- 複数のシナリオ（成功、各種エラー）の例を追加
例:
## 出力フォーマット
成功時:
✅ Logic App実行の再送信が完了しました
📋 詳細:
- Logic App: {workflowName}
- 実行名: {runName}
- ステータス: 再送信受付完了(202 Accepted)
新しい実行が開始されました。
失敗時（権限不足）:
❌ Logic App実行の再送信に失敗しました
📋 詳細:
- エラー: 権限が不足しています。Logic App Contributor以上の権限が必要です
- ステータスコード: 403
対処方法:
- IT管理者に権限付与を依頼してください
失敗時（リソース未検出）:
❌ Logic App実行の再送信に失敗しました
📋 詳細:
- エラー: Logic App '{workflowName}' が見つかりませんでした
- ステータスコード: 404
対処方法:
- Logic App名のスペルを確認してください
- Logic Appが削除されていないか確認してください
8. 設計のポイントまとめ
・ 単一責任の原則
各ツールは1つの役割のみ担当。
Good:
ツール 1: Parse Message → メッセージ解析のみ
ツール 5: Send Teams Reply → メッセージ送信のみ
Bad:
ツール: Parse and Generate and Send
→ 解析 + メッセージ生成 + 送信 = 3つの責任
・ AIへの委譲の原則
可能な限りAIに判断・生成を委譲することで、Logic Appsの構成をシンプルに保ちます。
AIに委譲していること:
- ツール実行順序の判断 - 次にどのツールを呼ぶか
- エラーハンドリング - どの段階で失敗したか判断
- メッセージ生成 - 状況に応じた適切なメッセージ作成
開発者が定義すること:
- ツール定義 - 各ツールの責任と処理内容
- Agent Instructions - AIの行動指針と出力フォーマット
- Agent Parameter - ツールへの入力仕様
・ Agent Instructionsの重要性
メッセージ生成をAIに任せる場合、Agent Instructionsが極めて重要になります。
必須要素:
- 出力フォーマットの明確な例 - 成功時・失敗時の具体的なメッセージ
- エラーケースごとのメッセージ内容 - 403, 404, その他
- 含めるべき情報の指定 - workflowName, runName, statusCodeなど
おわりに
Consumption Logic App で自律型エージェントを構築する最大のメリットは、「ロジックの管理をAIに丸投げできる」 点にあります。
- 各ツールを 単一責任 で作成する。
- Agent Parameter を適切に定義してAIとツールを繋ぐ。
- メッセージ生成すらAIに任せて、アクション数を減らす。
これらを意識することで、メンテナンス性が高く、かつ自然言語の揺らぎに強い強力な運用Botが完成します。皆さんもぜひ、ポータルを開く手間をAIに肩代わりさせてみてください！
参考資料
- Create autonomous agent workflows - Azure Logic Apps | Microsoft Learn
- Logic AppsのAutonomous Agentを使ってみた | Zenn
- Azure Logic Apps limits and configuration | Microsoft Learn