2026年5月21日に公開・更新された「Microsoft Azure documentation update: fix(designer-v2): Fix Agent Activity tab disabled for MCP-only agent (v5.961)」は、Azure Logic AppsのDesigner v2で、MCPクライアントツールだけを使うエージェントワークフローのAgent Activityタブが無効のままになる不具合を修正する低リスクの更新です。
結論から言うと、API変更やワークフロー定義の移行は基本的に不要です。影響を受けるのは、Azure Logic Appsのエージェント機能、特にMCP client toolsのみを含むAgentアクションをDesigner v2で確認・実行している利用者です。管理者と開発者は、修正が反映された環境でRun historyのAgent Activityタブが表示されるか、運用監視やテスト手順に抜けがないかを確認しておくとよいでしょう。公式PRでは、この変更はfix、リスクレベルはLow、開発者向けにはAPI変更なしとされています。(GitHub)
Microsoft Azure documentation updateで修正された内容
今回のMicrosoft Azure documentation updateの中心は、Azure Logic AppsのDesigner v2におけるRun historyパネルの表示制御です。
具体的には、AgentアクションがMCPクライアントツールだけで構成されているワークフローで、実行履歴を開いてもAgent Activityタブが有効にならない問題が修正されました。Agent Activityは、エージェントがどのようにツールを呼び出したか、どのステップで処理したかを確認するための重要な画面です。
| 項目 | 内容 |
|---|---|
| 対象 | Azure Logic AppsのDesigner v2 |
| 修正対象 | MCP client toolsのみを含むAgentワークフロー |
| 症状 | Run historyでAgent Activityタブが無効のままになる |
| 変更種別 | Bug fix |
| リスク | Low |
| API変更 | なし |
| 主な確認ポイント | Run history、Agent Activityタブ、MCPツール利用時の実行確認 |
この修正は、Azure Logic AppsでAIエージェントやCopilot連携を使うチームにとって、機能追加というよりも可観測性の回復に近い更新です。ワークフローの実行そのものではなく、実行後の確認画面に関する不具合修正と捉えると分かりやすいでしょう。
Agent Activityタブとは何か
Agent Activityタブは、Azure Logic Appsのエージェントワークフローを確認する際に重要な情報を表示する領域です。
Azure Logic Appsでは、LLMやAIエージェントが複数ステップの処理を進めるために、Agent loopを使ったワークフローを構成できます。公式ドキュメントでは、エージェントが指示や入力を受け取り、必要なツールを選択してタスクを実行する仕組みとして説明されています。(Microsoft Learn)
たとえば、次のような確認に使います。
- エージェントがどのツールを呼び出したか
- どの入力をもとに判断したか
- 実行が途中で止まったのか、ツール呼び出しで失敗したのか
- 旧Designerでは見えていたAgent logが、新Designerで見えない問題がないか
今回の修正に関連するIssueでは、旧DesignerではAgent logが確認できる一方、新Designerでは確認できないという報告がありました。対象はAzure Logic AppsのConsumption（Portal）で、DesignerV2のバグとして扱われています。(GitHub)
なぜMCP-only agentでAgent Activityタブが無効になっていたのか
今回の不具合は、AgentワークフローかどうかをDesigner v2側で判定するロジックに原因がありました。
修正前のDesigner v2では、useWorkflowHasAgentLoopという判定処理が、state.workflow.nodesMetadata内にsubgraphType === AGENT_CONDITIONのノードがあるかを見ていました。しかし、MCPクライアントツールはデシリアライズ時にAGENT_CONDITIONではなくMCP_CLIENTとして扱われます。そのため、AgentアクションがMCP client toolsのみで構成されている場合、Designer v2は「このワークフローにはAgent loopがない」と誤判定していました。(GitHub)
修正後は、nodesMetadataではなくstate.workflow.operationsを見て、type === 'agent'のoperationが存在するかどうかで判定するようになりました。これはv1 Designerの既存実装と同じ考え方です。(GitHub)
実務上は、次のように理解するとよいでしょう。
| 観点 | 修正前 | 修正後 |
|---|---|---|
| 判定対象 | ノードのメタデータ | |
| 判定条件 | AGENT_CONDITIONの有無 | |
| MCP-only構成での結果 | Agentなしと誤判定される可能性 | |
| 修正後の判定 | operationのtype === 'agent'を確認 | |
| 期待される結果 | MCP client toolsのみでもAgent Activityタブが表示される |
重要なのは、MCPツールそのものが動作していなかったというより、Designer v2の画面側がAgentワークフローとして正しく認識できていなかった点です。障害対応時に「ツール呼び出しが失敗した」と早合点しないよう注意が必要です。
MCPとAzure Logic Appsの関係
MCPはModel Context Protocolの略で、AIエージェントやLLMが外部システム、API、業務ワークフローなどのツールを安全かつ構造化された形で利用するためのプロトコルです。
Azure Logic Appsでは、StandardロジックアプリのワークフローをMCPサーバーとして構成し、AIエージェントやMCPクライアントから呼び出せるツールとして公開できます。公式ドキュメントでは、Standard logic appを1つ以上のリモートMCPサーバーとして設定し、ワークフローをツールとして公開できると説明されています。(Microsoft Learn)
たとえば、次のようなシナリオで使われます。
- 社内システムのデータをエージェントが参照する
- 問い合わせ内容に応じてLogic Appsのワークフローを呼び出す
- メール送信、チケット作成、承認依頼などをツール化する
- FoundryやCopilot系のエージェントから既存の業務フローを再利用する
Azure Logic Appsは多数のコネクタを備えているため、エージェントに直接複雑な業務ロジックを持たせるのではなく、Logic Apps側に業務処理を集約し、エージェントは必要なツールを選択する構成にしやすいのが特徴です。Microsoft Learnでも、FoundryのエージェントにAzure Logic Appsのワークフローをアクションとして追加し、複数ステップの業務タスクを実行できると説明されています。(Microsoft Learn)
影響を受ける可能性がある利用者
今回の更新で特に確認すべきなのは、Azure Logic AppsでAIエージェント関連のワークフローを運用しているチームです。
確認対象になりやすいケース
次の条件に当てはまる場合は、修正の影響を確認しておく価値があります。
| 利用状況 | 確認の必要性 |
|---|---|
| Designer v2でAgentワークフローを編集・確認している | 高い |
| AgentアクションがMCP client toolsのみで構成されている | 高い |
| Run historyでAgent Activityタブを使って調査している | 高い |
| 旧DesignerではAgent logが見えるが、新Designerでは見えなかった | 高い |
| APIやワークフロー定義だけをCI/CDで管理している | 中程度 |
| MCPやAgent loopを使っていない通常のLogic Apps | 低い |
この修正はUI側の判定ロジックに関するものなので、通常のHTTPトリガー、スケジュール実行、コネクタ中心のワークフローだけを使っている環境では、直接的な影響は小さいと考えられます。
管理者が見るべき観点
管理者は、単に「不具合が修正された」と見るだけでなく、運用監視と問い合わせ対応の観点で確認することが大切です。
特に、次のような社内問い合わせが過去にあった場合は、修正後の挙動を確認しておくと対応が楽になります。
- 「Agent Activityが表示されない」
- 「旧Designerではログが見えたのに、新Designerでは見えない」
- 「MCPツールを使うAgentワークフローだけ実行履歴が追いにくい」
- 「実行は成功しているが、エージェントの判断過程が確認できない」
このような問い合わせは、認証、MCPサーバー、ツール定義、Run history、Designer v2の表示問題が混同されやすい領域です。今回の修正をきっかけに、切り分け手順を整理しておくとよいでしょう。
管理者が確認すべき設定と運用ポイント
今回の修正ではAPI変更はありませんが、Azure管理者や情シス担当者は、次のポイントを確認しておくと安全です。
Designer v2でAgent Activityタブが表示されるか確認する
まず、影響がありそうなAgentワークフローを1つ選び、Designer v2で実行履歴を開きます。
確認手順は次の通りです。
| 手順 | 確認内容 |
|---|---|
| 1 | Azure portalで対象のLogic Appを開く |
| 2 | Agentアクションを含むワークフローを選ぶ |
| 3 | MCP client toolsのみで構成されたケースがあれば優先して確認する |
| 4 | ワークフローを実行する、または既存のRun historyを開く |
| 5 | Agent Activityタブが有効になっているか確認する |
| 6 | タブ内でエージェントの処理内容が追跡できるか確認する |
この確認は、本番環境でいきなり行うより、開発環境または検証用ワークフローで実施するのが無難です。特にMCPツールが外部APIや業務データを操作する場合は、テスト入力と実行先を明確に分けてください。
旧Designerとの差分を確認する
Issueでは、旧DesignerではAgent logが見えるが新Designerでは見えないという問題が報告されていました。(GitHub)
そのため、過去に旧Designerと新Designerを併用していたチームでは、修正後に以下を確認しましょう。
- 旧Designerで見えていたAgent log相当の情報がDesigner v2でも確認できるか
- Run historyの説明手順書やスクリーンショットが古くなっていないか
- 社内ナレッジに「新DesignerではAgent logが見えない」と書かれていないか
- 障害調査時に旧Designerへ戻す運用が残っていないか
小さなUI修正でも、運用手順書が古いままだと、現場では「どの画面を見ればよいか分からない」という混乱が起きます。
MCPサーバーや認証設定の問題と混同しない
今回の修正は、Agent Activityタブの有効・無効判定に関するものです。MCPサーバーへの接続、OAuth、Easy Auth、APIキー、ツール定義の不備を直接修正するものではありません。
Azure Logic AppsでMCPサーバーを構成する場合、公式ドキュメントではEasy Authの設定やAPIキー生成、MCPクライアントでのテストが手順として示されています。(Microsoft Learn) また、Easy Authを設定するには、Microsoft Entra IDのアプリ登録や、Logic Appリソースに対する適切な権限が必要です。(Microsoft Learn)
Agent Activityタブが表示されるようになっても、MCPツールの呼び出し自体が失敗する場合は、次の観点で切り分けます。
| 症状 | 主な確認ポイント |
|---|---|
| Agent Activityタブが表示されない | Designer v2の修正反映、Agent operationの有無 |
| MCPツールが呼び出せない | MCPサーバーURL、認証、Easy Auth、APIキー |
| ツール呼び出しは成功するが結果が不自然 | ツール説明、Requestトリガーの説明、入力スキーマ |
| Run historyに実行が残らない | ワークフローの実行状態、トリガー、保存状態 |
| 権限エラーが出る | Entra ID、RBAC、アプリ登録、トークン audience |
「Agent Activityが見えない」と「MCPツールが失敗する」は別問題です。調査時は、画面表示の問題なのか、実行時の認証・接続問題なのかを先に分けてください。
開発者が確認すべき実装・テスト観点
開発者にとって今回のポイントは、Designer v2のセレクター変更です。公式PRでは、開発者向けの影響としてAPI変更はないとされ、システム面でもパフォーマンスやアーキテクチャへの影響はないと説明されています。(GitHub)
ただし、UIや状態管理に依存するテストを持っている場合は、確認しておいた方がよい部分があります。
type === 'agent'を前提にした判定を確認する
修正後の判定は、operationのtypeがagentかどうかを見る方式です。これにより、MCP_CLIENTノードしかない場合でも、Agentワークフローとして扱われるようになります。
開発者が見るべきポイントは次の通りです。
- Agentアクションを含むワークフローで
operationsにtype: 'agent'が存在するか - MCP client toolsのみの場合でもAgent Activityタブが有効になるか
- 通常の非Agentワークフローで誤ってAgent Activityタブが出ないか
- v1 Designerとv2 Designerで表示差分がないか
- Regression testでMCP-only構成をカバーしているか
特に、Agentワークフローのテストが「通常のAgent conditionを含むケース」だけだと、今回のようなMCP-only構成の不具合を見逃しやすくなります。
テストケースにMCP-only構成を追加する
今後の回帰防止には、次のようなテストケースが有効です。
| テストケース | 期待結果 |
|---|---|
| Agent action + 通常ツール | Agent Activityタブが表示される |
| Agent action + MCP client toolsのみ | Agent Activityタブが表示される |
| MCP_CLIENTノードはあるがAgent operationがない | Agent Activityタブは不要 |
| 非Agentワークフロー | Agent Activityタブは表示されない |
| 旧DesignerとDesigner v2の比較 | Agent関連ログの確認体験に大きな差がない |
公式PRの自動レビューでも、対象ファイルとしてlibs/designer-v2/src/lib/core/state/designerView/designerViewSelectors.tsが挙げられ、セレクターに対するユニットテスト追加が推奨されています。(GitHub)
v2のRunボタンで強制保存される点も確認する
公式PRでは、v2のRunボタンでforce saveするフラグも追加されたと説明されています。(GitHub)
これは一見小さな変更ですが、検証時には重要です。Designer上で変更した内容が保存されないまま実行されると、開発者は「最新の定義で実行したはず」と思っていても、実際には古い定義の実行履歴を見てしまうことがあります。
確認すべき点は次の通りです。
- Designer v2で変更後にRunした際、最新の定義が実行されるか
- 保存前の変更を含めてRun historyに反映されるか
- CI/CDでデプロイされた定義と、ポータル上の手動変更が混在していないか
- 本番環境でポータル編集を禁止している場合、Run操作の運用ルールと矛盾しないか
本番環境では、ポータルから直接ワークフローを編集・実行する運用を制限している組織もあります。その場合は、修正内容そのものよりも、Runボタンの扱いが既存の変更管理ルールに合っているかを確認してください。
移行や展開で注意すべきこと
今回の修正は、ワークフロー定義やAPI仕様を変えるものではありません。そのため、大規模な移行作業は通常不要です。
ただし、Azure portalやDesigner v2の更新は、利用者の環境やリージョン、テナントへの反映タイミングによって体感が異なる可能性があります。2026年5月21日時点の情報として更新が公開されていても、現場では「まだ表示が変わっていない」と感じるケースがあり得ます。
移行不要でも確認は必要
「API変更なし」と「何もしなくてよい」は同じではありません。特に運用監視に関わるUI修正では、次の確認が重要です。
| 項目 | 確認内容 |
|---|---|
| ワークフロー定義 | 変更や移行は基本不要 |
| API | 変更なし |
| MCPサーバー設定 | 今回の修正対象ではないが、別途確認が必要 |
| Run history | Agent Activityタブが期待通り表示されるか確認 |
| 社内手順書 | Designer v2前提の画面説明に更新 |
| 問い合わせ対応 | 「表示されない場合」の切り分け手順を整理 |
運用チームにとっては、実行履歴の見え方が変わること自体が重要な変更です。障害調査や監査対応でAgent Activityを使う場合は、修正反映後の画面で手順を再確認しておきましょう。
本番展開前に検証環境で見るべきポイント
検証環境では、最低限次の3パターンを確認するのがおすすめです。
- MCP client toolsのみのAgentワークフロー
- 通常ツールを含むAgentワークフロー
- Agentを含まない通常ワークフロー
この3つを確認すると、今回の修正が期待通りに効いているか、逆にAgentではないワークフローで不要なタブが出ていないかを見分けやすくなります。
Agent Activityタブがまだ表示されない場合の切り分け
修正後もAgent Activityタブが表示されない場合、すぐにMCPや認証を疑うのではなく、順番に切り分けることが重要です。
まず確認するチェックリスト
| 確認項目 | 見るべきポイント |
|---|---|
| 対象ワークフロー | 本当にAgentアクションを含んでいるか |
| ツール構成 | MCP client toolsのみの構成か、通常ツールも含むか |
| Designer | Designer v2で確認しているか |
| 実行履歴 | 最新のRun historyを開いているか |
| 保存状態 | 変更後に保存またはRunされているか |
| ブラウザ | キャッシュや古い画面を見ていないか |
| Azure portal | 更新が環境に反映されているか |
| 権限 | Run historyを閲覧できる権限があるか |
よくある誤解
Agent Activityタブの問題では、次のような誤解が起きやすいです。
| 誤解 | 実際の見方 |
|---|---|
| MCPツールが壊れている | タブ表示の判定だけが誤っている可能性がある |
| API変更が必要 | 公式PRではAPI変更なし |
| ワークフロー定義を作り直す必要がある | 通常は不要 |
| 旧Designerで見えるなら問題ない | Designer v2での運用手順も確認すべき |
| Agent Activityが見えない＝実行失敗 | 実行結果と表示制御は分けて確認する |
特に、AIエージェント関連のワークフローでは、モデル、ツール、認証、UI、実行履歴が絡むため、問題の原因を一気に決めつけないことが重要です。
実務での活用シーン
今回の修正は、小さなUI修正に見えますが、AIエージェントを業務システムに組み込む現場では意味があります。
障害調査のスピードが上がる
Agent Activityタブが正しく表示されると、エージェントがどのツールを呼び出したかを確認しやすくなります。
たとえば、社内問い合わせ対応エージェントがMCP経由で顧客情報検索ツールを呼び出す場合、問題が起きたときに次のような切り分けができます。
- エージェントが検索ツールを選んだのか
- ツール呼び出し前に判断を誤ったのか
- ツール呼び出しで認証エラーが起きたのか
- ツールの戻り値を受け取った後の処理で失敗したのか
Agent Activityが見えない状態では、これらをRun historyや外部ログから推測する必要があります。表示が正しくなることで、調査の初動が速くなります。
MCP-only構成を採用しやすくなる
MCP client toolsのみでAgentアクションを構成する設計は、ツールの再利用性や分離の観点で有効です。
ただし、運用画面でAgent Activityが見えないと、管理者は「この構成は調査しづらい」と感じ、MCPの採用を避ける可能性があります。今回の修正により、MCP-only構成でもRun history上の可視性が確保されやすくなります。
社内標準設計を見直すきっかけになる
AIエージェントの導入が進むと、単に「動く」だけでは不十分です。次の観点を標準化しておく必要があります。
- エージェントが利用できるツールの一覧
- MCPサーバーの認証方式
- ツール説明と入力スキーマの書き方
- Run historyとAgent Activityの確認手順
- 障害時の一次切り分けフロー
- 本番環境でのポータル編集ルール
今回の更新は低リスクな修正ですが、エージェント運用の可観測性を見直す良いタイミングです。
管理者・開発者が今すぐ行うべきこと
最後に、今回のMicrosoft Azure documentation updateを受けて実施すべきことを整理します。
| 立場 | やるべきこと |
|---|---|
| Azure管理者 | MCP-only AgentワークフローでAgent Activityタブが表示されるか確認する |
| 開発者 | type === 'agent'を前提に、MCP-only構成のテストを追加する |
| 運用担当者 | 障害調査手順にDesigner v2のRun history確認を反映する |
| セキュリティ担当者 | MCPサーバーやEasy Authの設定と、今回のUI修正を混同しない |
| 情シス・社内展開担当 | 旧Designer前提の手順書や問い合わせ回答を更新する |
今回の修正は、Azure Logic Appsのエージェントワークフローを大きく変えるものではありません。しかし、MCP client toolsのみを使う構成でAgent Activityタブが正しく表示されることは、AIエージェント運用の調査性と信頼性に直結します。
まずは、対象になりそうなAgentワークフローを1つ選び、Designer v2のRun historyでAgent Activityタブが表示されるかを確認してください。そのうえで、MCPサーバー、認証、Run history、社内手順書の切り分けを整理しておくと、今後のAzure Logic AppsとAI/Copilot活用を安全に進めやすくなります。
コメント