Microsoft Azure documentation update: fix(DesignerV2): Added forceSave on run button, fixed connection panel issue は、Azure Logic Apps の Designer V2 に関する小規模な不具合修正です。結論から言うと、一般的な利用者がワークフロー定義を移行する必要は基本的にありません。ただし、Azure Logic Apps の Standalone Designer V2 や Logic Apps UX コンポーネントを組み込んでいる開発チームは、実行ボタン押下時の保存処理、接続パネルの表示、ワークフローIDの扱いを確認しておくべきです。
この変更は、2026年5月21日に公開された Azure/LogicAppsUX の Release v5.962.0 に含まれており、対象PRは fix(DesignerV2): Added forceSave on run button, fixed connection panel issue です。PR自体は2026年5月20日に main ブランチへマージされています。(GitHub)
Microsoft Azure documentation updateで押さえるべき結論
今回の更新は、Azure Logic Apps の実行基盤やコネクタ仕様を大きく変えるものではなく、主に Logic Apps Designer V2 の操作性と内部状態管理を整える修正です。
特に重要なのは、次の3点です。
| 確認ポイント | 内容 | 実務上の見方 |
|---|---|---|
forceSave の追加 | FloatingRunButton に forceSave プロパティが追加された | 「変更なし」と判定された状態でも、必要に応じて実行前保存を行える |
| 接続パネルの表示修正 | Connections panel のアクション一覧で、アイコンの重なりや中央寄せ表示を修正 | 複数コネクタやカスタムコネクタを使う画面で確認したい |
| Designer V2の状態管理整理 | designerID と WorkflowJson の扱いを分離 | Standalone Designerを組み込む開発者は、workflow IDへの依存を見直す |
PR本文では Commit Type が fix、Risk Level が Low とされ、ユーザー向けには「Connections panel action list のアイコンが重ならず、左寄せで表示される」と説明されています。開発者向けには、FloatingRunButton が新しい forceSave prop を受け取ること、getConnectionConfiguration の manifest パラメーターが optional になったことが明記されています。(GitHub)
対象はAzure Logic AppsのDesigner V2周辺
Azure/LogicAppsUX リポジトリは、Azure Logic Apps のUXコンポーネント、Standalone Designer、ドキュメントサイト、VS Code拡張などを含むモノレポです。つまり今回の変更は、Azure Logic Apps のワークフロー作成・編集画面に関係する更新と考えると分かりやすいです。(GitHub)
Azure Logic Apps では、デザイナー上でトリガーやアクションを追加し、必要に応じてコネクタ接続を作成します。Microsoft Learnでも、トリガーやアクションの追加時にコネクタ一覧や接続作成ペインを使う流れが説明されています。(Microsoft Learn)
今回の修正が関係しやすいのは、次のような環境です。
| 対象 | 影響の可能性 |
|---|---|
| Azure Portal上でLogic Appsを編集する利用者 | 接続パネルの表示改善を受ける可能性がある |
| Visual Studio Codeや拡張機能でLogic Apps Designerを使う開発者 | UI更新が取り込まれるタイミングに注意 |
| Standalone Designer V2を組み込んでいる開発チーム | forceSave、designerID、WorkflowJson 周辺の確認が必要 |
| LogicAppsUXのUIコンポーネントを直接利用している開発者 | FloatingRunButton と接続パネル関連の回帰テストが必要 |
一方で、Azure Logic Apps の Consumption と Standard のホスティングモデルそのものを変更する更新ではありません。Microsoft Learnでは、Consumption は1つのロジックアプリリソースに1つのワークフロー、Standard は1つのロジックアプリリソースに複数ワークフローを持てると整理されていますが、今回のPRはこの設計差を変えるものではありません。(Microsoft Learn)
変更点を具体的に見る
実行ボタンにforceSaveが追加された
もっとも開発者向けの影響が大きいのは、FloatingRunButton に forceSave?: boolean が追加された点です。
変更前は、ワークフローが読み取り専用、または dirty 状態ではない場合、実際の保存処理をスキップしてシリアライズ済みワークフローを返す挙動でした。変更後は、!isDirty && !forceSave の場合に保存をスキップする条件へ変わっています。つまり、forceSave が true のときは、dirty ではない状態でも保存処理へ進めるようになります。(GitHub)
実務では、次のような場面で意味があります。
| シーン | forceSaveが役立つ理由 |
|---|---|
| 実行前に最新状態を必ず保存したい | UI上は変更なしでも、ホスト側では保存を保証したい場合がある |
| Standalone Designerを別アプリに組み込んでいる | アプリ側の状態管理とDesigner側のdirty判定が完全に一致しない場合がある |
| 接続情報やメタデータ更新を伴う操作 | ワークフロー本文以外の更新が実行前に反映されるか確認したい |
| コードビュー・デザイナービューを行き来する | 画面切り替え後の状態が保存済みかをテストしやすくなる |
ただし、forceSave は「常にtrueにすれば安全」という機能ではありません。保存回数が増えると、不要な保存処理、競合、確認しにくい差分が増える可能性があります。基本方針は、実行前保存が業務上必要なホストシナリオだけで有効化することです。
実装側で確認したい例
<FloatingRunButton
forceSave={true}
isConsumption={false}
/>上記は考え方を示す簡略例です。実際には既存の props、保存処理、ドラフトモード、読み取り専用状態との関係を見て設定してください。
特に注意したいのは、読み取り専用状態です。今回の条件変更でも、workflowReadOnly の場合は保存スキップの考え方が残っています。読み取り専用画面で forceSave を付ければ保存できる、という理解は避けるべきです。
Connections panelのアイコン表示が修正された
今回のPRでは、接続パネル内の NodeLinkButton について、アイコンの position: absolute が削除され、ボタン内容が左寄せになるように修正されています。Designer V2だけでなく、既存の designer 側にも同様の変更が入っています。さらに、アイコンサイズも 24px や 32px に整えられています。(GitHub)
これにより、接続パネルのアクション一覧でアイコンとテキストが重なったり、中央に寄って見えたりする問題が改善されます。
確認すべき画面は、次のようなケースです。
| 確認する画面 | チェック内容 |
|---|---|
| 接続パネルに複数アクションが並ぶ画面 | アイコンとアクション名が重ならないか |
| カスタムコネクタを使う画面 | 独自アイコンの縦横比で崩れないか |
| 既存DesignerとDesigner V2の両方 | 同じ接続パネルで見た目に大きな差が出ないか |
| 高解像度・狭い画面幅 | テキスト折り返しやボタン幅で崩れないか |
Azure Logic Apps のコネクタは、外部サービスやシステムへアクセスするための操作群を提供し、多くの場合は接続作成や認証設定が必要になります。今回の修正は認証方式そのものではなく、接続パネルの表示と操作性に関する修正として見るのが適切です。(Microsoft Learn)
Standalone Designer V2の状態管理が整理された
PRでは、Standalone Designer V2周辺で Workflow 型から WorkflowJson 型への整理、designerID とワークフロー内容の分離、監視ビューから戻る際のワークフロー復元処理の簡素化が行われています。ファイル差分では、DesignerProvider の id や workflowId に workflow?.id ではなく designerID を渡す変更も確認できます。(GitHub)
この点は、一般利用者よりも、Standalone Designerを組み込む開発者にとって重要です。
これまで workflow.id を「デザイナー画面の識別子」として扱っていた実装がある場合、今回の変更後はズレが出る可能性があります。ワークフロー本文の識別子と、画面上のDesignerインスタンス識別子は分けて考える必要があります。
管理者が確認すべきポイント
Azure管理者や運用担当者は、今回の更新を「緊急の移行案件」として扱う必要は高くありません。ただし、Logic Appsを業務システムで使っている場合は、次の確認をおすすめします。
| 確認項目 | 判断基準 |
|---|---|
| 利用中の編集環境 | Azure Portalのみか、VS Code/Standalone Designerも使っているか |
| 接続パネルの利用頻度 | 複数コネクタ、カスタムコネクタ、MCP関連などを頻繁に扱うか |
| 実行前保存の要件 | 実行ボタンを押す前に必ず保存される必要があるか |
| 本番反映手順 | UI更新後にステージングでデザイナー操作を確認できるか |
| ロールバック方法 | 拡張機能や組み込みパッケージを前バージョンへ戻せるか |
Azure PortalだけでLogic Appsを使っている場合、通常はMicrosoft側のUI更新を待つ形になります。表示崩れが続く場合は、ブラウザキャッシュ、別ブラウザ、シークレットウィンドウで再確認すると、ローカル環境由来の問題か切り分けやすくなります。
Standardロジックアプリでは、ワークフロー、接続、アプリ設定、ストレージなどが運用に関係します。Microsoft Learnでは、Standardロジックアプリの作成例として、複数ワークフローを持てることや、マネージドコネクタ接続が個別のAzureリソースとして扱われることが説明されています。(Microsoft Learn)
今回のPRは接続リソースの作成方式を変えるものではありませんが、接続パネルの表示が修正されるため、接続の選択・表示・再認証画面に問題がないかは確認しておくと安心です。
開発者が確認すべき実装ポイント
FloatingRunButtonの呼び出し側を確認する
LogicAppsUX のコンポーネントを直接利用している場合は、FloatingRunButton の呼び出し箇所を検索してください。
確認する観点は次の通りです。
| 観点 | 確認内容 |
|---|---|
forceSave を使うべきか | 実行前に保存必須のシナリオだけ true にする |
| dirty判定との関係 | isDirty が false でも保存したいケースがあるか |
| 読み取り専用画面 | read-only時に保存を期待していないか |
| 保存後実行の順序 | 保存失敗時に実行が進まないよう制御できているか |
| テスト | dirty=false、forceSave=true、readOnly=true の組み合わせを確認する |
特に、実行ボタンのクリックで「保存してから実行」する設計にしている場合は、forceSave の有無で挙動が変わる可能性があります。
getConnectionConfigurationのmanifest引数を確認する
PRでは、getConnectionConfiguration の _manifest 引数が optional に変更されています。これは互換性の面では扱いやすい変更ですが、呼び出し側の実装が「manifestは必ずある」と仮定している場合は注意が必要です。(GitHub)
確認すべき例は次の通りです。
// manifestがundefinedでも落ちないか確認する
await getConnectionConfiguration(connectionId, undefined, useMcpConnections);接続情報の取得処理では、manifestがないときにUIを落とすのではなく、必要なエラー表示や代替処理へ進める設計が望ましいです。
workflow.idへの依存を見直す
Standalone Designer V2では、ワークフローJSONの内容とデザイナーの識別子を分ける方向で整理されています。これにより、ワークフロー本文に不要な id を混ぜる実装や、Designer Providerの識別子として workflow.id を使う実装は見直し対象になります。
安全な考え方は次の通りです。
| 識別子 | 使い道 |
|---|---|
designerID | デザイナー画面・インスタンスの識別 |
| ワークフロー名やリソースパス | Azure上のワークフローリソース識別 |
WorkflowJson | ワークフロー定義、kind、metadataなどの内容 |
workflow.id | 画面識別用として安易に使わない |
この整理を怠ると、監視ビューからデザイナーへ戻る、コードビューからデザイナービューへ戻る、Copilot提案や外部入力でワークフローを差し替える、といった操作で状態がずれる可能性があります。
展開前に実施したいテスト
PRには、接続パネルの NodeLinkButton に関するユニットテスト追加が含まれています。テストでは、ノード表示名の描画、アイコンの描画、position: absolute が使われていないこと、左寄せ表示、クリック時の openPanel dispatch などが確認されています。(GitHub)
自社環境で確認するなら、次のテスト観点を追加すると実用的です。
| テスト項目 | 手順 | 期待結果 |
|---|---|---|
| 実行前保存 | ワークフローを開き、変更なし状態で実行ボタンを押す | forceSave有効時に必要な保存処理が行われる |
| dirty状態の通常保存 | アクションを編集して実行する | 保存後に実行され、変更内容が反映される |
| 読み取り専用表示 | 読み取り専用状態で実行ボタンを確認する | 不要な保存が走らない |
| 接続パネル表示 | 複数コネクタを含むワークフローを開く | アイコンとテキストが重ならず左寄せで表示される |
| カスタムコネクタ | 独自アイコンを持つコネクタを表示する | アイコンサイズが極端に崩れない |
| 監視ビュー復帰 | 実行履歴や監視ビューからデザイナーへ戻る | ワークフロー内容とDesigner状態がずれない |
| コードビュー切替 | コードビューで変更し、Designerへ戻る | definition、kind、metadataが期待通り維持される |
Low riskとされている更新でも、保存処理とID管理に触れている点は軽視しない方がよいです。特に、Logic AppsをCI/CDで展開しているチームや、独自ポータルにDesignerを組み込んでいるチームでは、UI修正ではなく「実行前の状態確定処理」として確認するのが安全です。
よくある誤解と注意点
ワークフロー定義の移行は必要か
基本的には不要です。今回の変更はDesigner V2のUIコンポーネントとStandalone Designerの状態管理が中心であり、Azure Logic Appsのワークフロー定義スキーマ自体を変更する内容ではありません。
ただし、独自実装でワークフローJSONに画面用IDを混ぜている場合は、今回の整理方針に合わせて見直す価値があります。
接続情報や認証方式は変わるのか
今回のPRから読み取れる主な変更は、接続パネルの描画、getConnectionConfiguration の引数、Designer状態管理です。コネクタの認証方式や接続リソースの作成ルールを直接変更する内容ではありません。
ただし、接続パネルのUIが変わるため、ユーザーが「どの接続を選んでいるか」を見間違えないかは確認してください。
forceSaveは常に有効化すべきか
常時有効化はおすすめしません。保存が必要なケースでだけ使うべきです。
たとえば、Standalone Designerを組み込んだアプリで、実行前に必ず最新のワークフロー定義を保存しなければならない場合は有効です。一方、単に「念のため」で全実行に保存を入れると、保存回数の増加、競合、予期しない差分発生につながる可能性があります。
Azure Portal利用者は何をすればよいか
Azure PortalでLogic Appsを編集しているだけなら、まずは接続パネルの表示と実行ボタンの挙動を通常業務の範囲で確認すれば十分です。表示崩れや実行前保存に違和感がある場合は、発生日時、ブラウザ、対象ワークフロー、使用コネクタ、再現手順を記録しておくと、サポートや開発チームへ共有しやすくなります。
次に取るべき行動
今回の Microsoft Azure documentation update は、Azure Logic Apps Designer V2の操作性と安定性を改善する低リスクな修正です。一般利用者は、接続パネルの表示が改善されているか、実行前の保存・実行に違和感がないかを確認すれば十分です。
一方、管理者や開発者は、次の順で確認すると効率的です。
- Logic Appsをどの編集環境で使っているかを確認する
- Standalone Designer V2やLogicAppsUXコンポーネントを直接利用しているかを確認する
FloatingRunButtonのforceSaveが必要な実行シナリオを洗い出すworkflow.idを画面識別子として使っていないか確認する- 接続パネル、監視ビュー復帰、コードビュー切替をステージング環境でテストする
特に、独自ポータルや社内ツールにAzure Logic Apps Designerを組み込んでいる場合は、単なるUI修正として流さず、保存・実行・接続表示・ID管理の4点セットで回帰テストを行うのが実務的です。
コメント