Microsoft Azureの公式リポジトリで公開された「fix(DesignerV2): Added forceSave on run button, fixed connection panel issue (v5.961)」は、Azure Logic AppsのDesigner V2まわりに入った小規模な修正です。結論から言うと、通常のLogic Apps利用者が大規模な移行作業をする必要はありません。一方で、Designer V2、Standalone designer、VS Code拡張、またはLogic Apps UXコンポーネントを組み込んでいる開発者は、実行ボタンの保存挙動と接続パネルの表示確認を行う価値があります。
今回の変更は、PR #9201としてAzure/LogicAppsUXリポジトリにマージされ、リスクレベルは「Low」とされています。主な内容は、FloatingRunButtonへのforceSaveオプション追加、接続パネルのアイコン表示崩れ修正、Standalone v2関連の修正です。2026年5月21日のDaily Repo Statusでは、v5.961.4のハイライトとして「forceSave on run button, connection panel fixes」が掲載されています。(GitHub)
Microsoft AzureのDesignerV2 v5.961修正で何が変わったのか
今回の更新は、Azure Logic Appsのワークフロー実行環境そのものを大きく変える機能追加ではなく、Designer V2の操作体験と内部状態管理を安定させる修正です。
Azure/LogicAppsUXは、Azure Logic AppsのUXコンポーネント、Standalone designer、ドキュメントサイト、VS Code拡張などを含むモノレポです。つまり、この変更は「Azure Logic Appsのデザイナー画面や、その周辺ツールのUI実装」に関係します。(GitHub)
今回の修正点を実務目線で整理すると、次のようになります。
| 変更点 | 内容 | 利用者への影響 |
|---|---|---|
FloatingRunButtonにforceSaveを追加 | 実行ボタン側で、必要に応じて「未変更扱い」でも保存処理を通せるようにする | 実行前の保存漏れや状態不整合を避けやすくなる |
| 接続パネルの表示崩れ修正 | アクション一覧のアイコンが重なったり中央寄せになったりする問題を修正 | コネクタや接続の選択が見やすくなる |
getConnectionConfigurationのmanifest引数を任意化 | 接続設定取得処理の引数要件を緩和 | カスタム実装やStandalone designer利用時の互換性が上がる |
designerIDとWorkflowJsonの分離 | デザイナー識別子とワークフロー定義の状態を分ける | 状態復元や編集時の副作用を抑えやすくなる |
PR上では、ユーザー向けの影響として「Connections panel action list now renders icons inline and left-aligned instead of overlapping/centered」、開発者向けの影響として「FloatingRunButton accepts a new forceSave prop」「getConnectionConfiguration manifest param is now optional」と説明されています。(GitHub)
影響範囲はAzure Logic AppsのDesigner V2が中心
今回のMicrosoft Azure関連アップデートで影響を受けるのは、主にAzure Logic AppsのDesigner V2を使う場面です。特に、次のような利用者は確認対象になります。
- Azure portalでLogic Appsのデザイナーを使っている管理者
- StandardまたはConsumptionのLogic AppsをGUIで編集している開発者
- Standalone designerを検証・組み込みしているチーム
- Azure Logic Apps UXコンポーネントを利用して独自UIや検証環境を作っている開発者
- 接続パネルで複数のコネクタや接続を扱う運用担当者
Microsoft Learnでは、Azure Logic AppsのStandardワークフローデザイナーについて、Azure portal上でワークフローの作成、編集、実行、実行履歴の確認、コードビューでのJSON定義確認などを行えるものとして説明しています。また、プレビューデザイナーでは下書きワークフローと公開済みワークフローの扱いが明確に分かれる点も重要です。(Microsoft Learn)
今回のforceSave追加は、この「デザイナー上で編集した内容を保存し、実行する」という利用体験に関わる修正です。ワークフローのランタイム、課金体系、コネクタ仕様、認証方式を直接変更する内容ではありません。
forceSave追加で実行ボタンの保存挙動が安定しやすくなる
今回もっとも注目すべき変更は、FloatingRunButtonにforceSaveプロパティが追加された点です。
従来の実装では、ワークフローが読み取り専用の場合、または「dirtyではない」、つまり変更済みと判定されていない場合、保存処理をスキップしてシリアライズ済みワークフローを返す流れでした。修正後は、forceSaveが有効な場合、dirty判定が false でも保存処理を進められるようになっています。(GitHub)
実務では、次のようなケースで意味を持ちます。
| ケース | 起きやすい問題 | forceSave追加後に期待できること |
|---|---|---|
| デザイナーで編集後、すぐ実行する | UI上は変更済みに見えても内部のdirty判定とずれる | 実行前に保存を強制できる余地が増える |
| コードビューとデザイナーを行き来する | 状態復元時に保存対象が曖昧になる | 実行ボタン側の保存制御が明確になる |
| Standalone designerで独自実装している | ホスト側の状態管理とデザイナー側の判定がずれる | 呼び出し側で保存要否をより制御しやすい |
| 下書きワークフローを実行する | 公開済みとの差分管理を誤解しやすい | 実行前の保存フローを検証しやすい |
ここで注意したいのは、forceSaveは「必ずすべての環境で自動保存される」という意味ではない点です。あくまでFloatingRunButtonコンポーネントに追加されたプロパティであり、実際にどう有効化されるかは、そのコンポーネントを使う側の実装に依存します。
管理者よりも、Logic Apps UXを拡張・組み込みしている開発者が確認すべき変更です。
接続パネルの表示修正は運用時のミス防止につながる
もう一つの重要な修正は、Connections panel、つまり接続パネルの表示崩れ修正です。
PRでは、接続パネルのアクション一覧で、アイコンが重なったり中央寄せになったりするのではなく、インライン表示かつ左寄せで表示されるようになったとされています。ファイル差分では、NodeLinkButtonのアイコンに指定されていたposition: absoluteが外され、ボタン内容が左寄せになるよう調整されています。(GitHub)
一見すると単なるUI修正ですが、Logic Appsの運用では重要です。接続パネルは、Outlook、SQL Server、Azure Service Bus、HTTP、Dataverseなど、さまざまなコネクタや接続を扱う場所です。表示が崩れていると、似た名前の接続や複数環境の接続を選び間違えるリスクがあります。
たとえば、開発環境と本番環境で次のような接続名を使っている場合です。
| 接続名の例 | 想定用途 | 表示崩れ時のリスク |
|---|---|---|
sql-dev-connection | 開発用SQL Database | 本番接続と見間違える |
sql-prod-connection | 本番用SQL Database | 誤って開発用に差し替える |
teams-alert-dev | 検証通知 | 本番通知が飛ばない |
teams-alert-prod | 本番通知 | 検証中に本番通知を送る |
今回の修正は、こうした接続選択時の視認性を改善するものです。大規模な設定変更ではありませんが、運用ミスを減らすという意味では見逃せません。
StandardとConsumptionの両方で確認対象になる可能性がある
PRのテスト計画では、Standalone designerについて「Standard + Consumption」での手動テスト、および複数コネクタを含む接続パネルでの確認が行われたと記載されています。(GitHub)
Azure Logic Appsには、主にConsumptionとStandardの2種類があります。Microsoft Learnでは、Consumptionはマルチテナント環境で1つのロジックアプリリソースに1つのワークフローを持つ形式、Standardはシングルテナント環境で1つのロジックアプリリソースに複数のワークフローを持てる形式として整理されています。(Microsoft Learn)
今回の変更はランタイムの差異ではなくデザイナーUXの修正です。そのため、次のように確認範囲を切り分けるとよいでしょう。
| 利用形態 | 確認すべき内容 | 優先度 |
|---|---|---|
| Azure portalでConsumption Logic Appsを編集 | 接続パネルの表示、実行前保存の挙動 | 中 |
| Azure portalでStandard Logic Appsを編集 | 下書き、実行、公開、接続パネルの表示 | 高 |
| Visual Studio Code中心でStandardを開発 | ローカル編集後のデザイナー表示、保存・実行連携 | 中 |
| Standalone designerを利用 | forceSaveの利用有無、getConnectionConfigurationの引数 | 高 |
| ARM/Bicep/Terraformのみでデプロイ | デザイナーでの確認程度 | 低 |
特にStandardでは、下書きと公開済みワークフローの扱いを誤解すると、意図した変更が本番に反映されていない、または下書きだけが実行されている、といった混乱が起きやすくなります。Microsoft Learnでも、プレビューデザイナーでは下書きワークフローを公開するまで運用ワークフローは変更されず、デザイナーから実行すると下書きワークフローが実行されると説明されています。(Microsoft Learn)
管理者が確認すべきポイント
Azure管理者は、今回の修正を「緊急対応が必要なセキュリティ更新」として扱う必要は通常ありません。PRのリスクレベルはLowで、内容も限定的なUI・状態管理修正です。(GitHub)
ただし、次のような環境では、更新後に簡単な確認を入れておくと安心です。
| 確認項目 | 確認方法 | 判断基準 |
|---|---|---|
| 接続パネルの表示 | Logic Appsデザイナーで複数コネクタを含むワークフローを開く | アイコンとテキストが重ならず左寄せで表示される |
| 実行前の保存挙動 | 軽微な変更後に実行ボタンを押す | 意図した内容で実行履歴が作成される |
| 下書きと公開済みの差分 | Standardのプレビューデザイナーで確認 | 下書き実行と公開済み運用を混同していない |
| 接続先の誤選択 | 開発・本番接続名を見直す | 環境名、用途、所有者が名前で判別できる |
| 問い合わせ増加の有無 | ヘルプデスクや運用チケットを確認 | 表示崩れや保存できない報告が減っている |
運用で特に大事なのは、接続名の見直しです。UIが改善されても、connection1やsql-connectionのような曖昧な名前が並んでいると、接続ミスは防ぎきれません。
おすすめは、次のような命名です。
用途-環境-接続先
例:
orders-prod-sql
orders-dev-sql
alerts-prod-teams
alerts-stg-servicebus接続パネルの表示修正をきっかけに、接続名のルールも合わせて整理すると、運用品質を上げられます。
開発者が確認すべきポイント
開発者、とくにLogicAppsUXを直接利用しているチームは、今回の修正をもう少し詳しく見る必要があります。
FloatingRunButtonを使っている場合
FloatingRunButtonにforceSave?: booleanが追加されています。差分では、workflowReadOnly || !isDirtyで保存をスキップしていた条件が、workflowReadOnly || (!isDirty && !forceSave)に変更されています。(GitHub)
つまり、次のように考えると分かりやすいです。
| 状態 | 従来の挙動 | 修正後の考え方 |
|---|---|---|
| 読み取り専用 | 保存しない | 保存しない |
| dirty=true | 保存する | 保存する |
| dirty=false、forceSave=false | 保存しない | 保存しない |
| dirty=false、forceSave=true | 従来は保存しない | 保存できる余地がある |
Standalone designerや独自ホスト画面で「実行前に必ず最新状態を保存したい」という要件がある場合、forceSaveの指定を検討します。
ただし、安易に常時forceSave=trueにするのは避けたほうがよいです。保存APIの呼び出し回数が増えたり、意図しないタイミングで下書き状態が保存されたりする可能性があります。次のような条件で限定的に使うのが現実的です。
- 実行ボタンを押した直後だけ有効にする
- コードビューからデザイナーに戻った直後だけ有効にする
- ホスト側でワークフロー定義を差し替えた直後だけ有効にする
- 自動保存ではなく、明示的な実行操作に連動させる
getConnectionConfigurationを実装している場合
今回の修正では、getConnectionConfigurationのmanifest引数が任意になっています。(GitHub)
これは、接続設定を取得する処理で、必ずしもmanifestが渡らないケースを許容するための変更と考えられます。独自実装側でmanifestが必須であることを前提にしている場合は、undefinedやnull相当の入力でも落ちないように防御的に実装しておくべきです。
悪い例は、次のようにmanifestの存在を無条件に前提にする実装です。
const getConnectionConfiguration = async (connectionId: string, manifest: any) => {
return manifest.properties.connectionConfiguration[connectionId];
};より安全な例は、次のようにmanifestがない場合の分岐を入れる形です。
const getConnectionConfiguration = async (
connectionId: string,
manifest?: any,
useMcpConnections?: boolean
) => {
if (!connectionId) {
return undefined;
}
if (!manifest) {
// manifestが渡らないケースでは、既定値または別経路で設定を取得する
return await loadConnectionConfigurationById(connectionId, useMcpConnections);
}
return manifest?.properties?.connectionConfiguration?.[connectionId];
};実装方針はプロジェクトによって異なりますが、少なくとも「manifestは常にある」と決め打ちしないことが重要です。
WorkflowJsonとdesignerIDの分離を前提にする
差分では、Standalone designerの状態管理でWorkflowではなくWorkflowJsonを使う変更、ワークフロー定義にidを混ぜ込まず、designerIDを別に扱う変更が含まれています。(GitHub)
これは地味ですが、設計としては重要です。ワークフロー定義そのものと、デザイナーUIの識別子を混在させると、保存時に不要なプロパティが混ざる、監視ビューから戻ったときに状態がずれる、コードビューとデザイナー表示の同期が不安定になる、といった問題が起きやすくなります。
開発者は、次のように分けて管理すると安全です。
| 管理対象 | 含めるもの | 含めないほうがよいもの |
|---|---|---|
| ワークフロー定義 | definition、kind、metadata、接続参照など | UI用の一時ID、選択状態、表示モード |
| デザイナー状態 | designerID、表示モード、実行履歴表示状態 | 保存対象のJSON定義そのものへの不要な上書き |
| ホスト側状態 | 認証情報、接続設定取得関数、保存関数 | デザイナー内部の一時的なレンダリング情報 |
ワークフロー定義にUI都合の値を混ぜないことが、移行やデバッグを楽にします。
展開・移行時に注意すべきこと
今回のv5.961修正は低リスクですが、デザイナーを使う現場では「更新されたから問題ない」と放置せず、軽い回帰確認を入れるのが安全です。
本番ワークフローを直接編集しない
デザイナーの保存・実行まわりを確認するときは、いきなり本番ワークフローで試さないでください。特に接続パネルを触る検証では、誤って本番接続を差し替えるリスクがあります。
推奨手順は次のとおりです。
| 手順 | 作業内容 | 目的 |
|---|---|---|
| 1 | 検証用Logic Appまたは検証用ワークフローを用意する | 本番影響を避ける |
| 2 | 複数の接続を含むワークフローを開く | 接続パネルの表示を確認する |
| 3 | 軽微な変更を加えて保存・実行する | 実行前保存の挙動を確認する |
| 4 | 実行履歴で入力・出力を確認する | 意図した定義で実行されたか見る |
| 5 | Standardの場合は下書きと公開済みの状態を確認する | 公開忘れや誤実行を防ぐ |
Azure Logic Appsでは、トリガーやアクションを追加する際に、必要に応じて接続作成ペインで認証情報や接続情報を入力します。Microsoft Learnでも、トリガーやアクション追加時にCreate connectionペインが表示される場合があると説明されています。(Microsoft Learn)
このため、接続パネルの確認は「表示がきれいになったか」だけでなく、「正しい接続を選べるか」まで見るべきです。
CI/CD中心のチームでもデザイナー確認は必要
ARMテンプレート、Bicep、Terraform、GitHub Actions、Azure DevOpsなどでLogic Appsを展開しているチームは、デザイナー修正を軽視しがちです。しかし、次のような場面ではデザイナーの状態が運用に関わります。
- 障害対応中にAzure portalで一時的にワークフローを確認する
- 実行履歴から再実行や調査を行う
- 接続エラーの切り分けで接続パネルを見る
- 開発者がGUIで下書きを作り、その後コード化する
- Standardのプレビュー デザイナーで下書き実行を行う
CI/CDで定義を管理している場合でも、Azure portal上のデザイナー表示が崩れていると、調査や暫定対応の速度に影響します。更新後は、代表的なワークフローを1つ選び、デザイナー表示と接続パネルを確認しておくと安心です。
よくある誤解と失敗しやすいポイント
「forceSaveが追加されたので保存問題はすべて解消する」と考える
forceSaveは保存制御の選択肢を増やす修正です。すべての保存失敗や反映遅延を解消する万能機能ではありません。
保存されない問題が起きた場合は、次の切り分けが必要です。
| 確認対象 | 見るポイント |
|---|---|
| デザイナーのdirty判定 | 変更後に保存ボタンや実行ボタンの状態が変わるか |
| 下書きと公開済み | Standardで下書きだけ変更されていないか |
| 接続エラー | 認証切れや権限不足がないか |
| デプロイ方式 | CI/CDで後から上書きされていないか |
| ブラウザキャッシュ | 別ブラウザや再読み込みで表示が変わるか |
接続パネルの表示修正だけを見て接続名を放置する
UIが改善されても、接続名が曖昧だと誤操作は残ります。特に本番・検証・開発の接続が混在している場合は、接続名に環境名を入れるべきです。
避けたい名前は次のようなものです。
sql
connection1
teams
servicebus-new
prod2望ましい名前は次のようなものです。
orders-prod-sql
orders-stg-sql
alert-prod-teams
billing-dev-servicebus接続パネルが見やすくなったタイミングで、接続名と運用ルールを見直すと効果が出ます。
Standardの下書き実行と公開済み実行を混同する
Standardのプレビューデザイナーでは、下書きワークフローと公開済みワークフローの扱いに注意が必要です。Microsoft Learnでは、下書きワークフローを公開するまで運用ワークフローは変更されず、デザイナーから実行した場合は運用ワークフローではなく下書きワークフローが実行されると説明されています。(Microsoft Learn)
実務では、次のような会話が起きがちです。
「変更して実行したら成功したのに、本番では反映されていない」
この場合、下書きでは成功しているが、公開済みバージョンには反映されていない可能性があります。Designer V2の保存や実行ボタンまわりを確認するときは、必ず「下書き」「公開済み」「実行履歴」のどれを見ているのかを明確にしましょう。
今回の更新後に実施したいチェックリスト
管理者と開発者は、次のチェックリストを使うと短時間で確認できます。
| 対象者 | チェック項目 | 完了条件 |
|---|---|---|
| 管理者 | 代表的なLogic Appsをデザイナーで開く | エラーなく表示される |
| 管理者 | 接続パネルを開く | アイコンとテキストが重ならない |
| 管理者 | 開発・検証環境で実行する | 意図したワークフロー定義で実行履歴が残る |
| 管理者 | Standardの下書きと公開状態を確認する | 公開忘れがない |
| 開発者 | FloatingRunButton利用箇所を確認する | forceSaveを使うべき場面を判断できている |
| 開発者 | getConnectionConfiguration実装を確認する | manifest未指定でも落ちない |
| 開発者 | ワークフロー定義にUI用IDを混ぜていないか確認する | 保存対象JSONが整理されている |
| DevOps担当 | CI/CD後にデザイナー表示を確認する | デプロイ済み定義とUI表示が一致する |
優先順位を付けるなら、まずは「接続パネルの表示」「実行前保存」「Standardの下書きと公開済みの確認」の3点を見てください。
まとめ：大規模移行ではなく、Designer V2の品質改善として確認する
今回の「fix(DesignerV2): Added forceSave on run button, fixed connection panel issue (v5.961)」は、Azure Logic AppsのDesigner V2に対する低リスクの修正です。公式PRでは、forceSaveの追加、Standalone v2関連の修正、接続パネルのレンダリング問題修正が明記され、v5.961.4のリリースハイライトにも掲載されています。(GitHub)
通常の管理者は、大規模な移行や設定変更を急ぐ必要はありません。ただし、Azure portalでLogic Appsを編集・実行するチームは、検証環境で接続パネルの表示と実行前保存の挙動を確認しておくと安心です。
開発者は、FloatingRunButtonのforceSave、getConnectionConfigurationの任意manifest、WorkflowJsonとdesignerIDの分離を確認してください。とくにStandalone designerや独自ホスト画面を使っている場合、今回の修正は小さいながらも実装品質に関わります。
次に取るべき行動はシンプルです。代表的なLogic Appsを1つ選び、デザイナーで開き、接続パネルを確認し、検証環境で保存・実行まで試してください。そのうえで、接続名や下書き運用ルールが曖昧なら、この機会に整理しておくと、今後の運用トラブルを減らせます。
コメント