Azure Logic Apps Codeful Workflows with Logic Apps Standard SDKは、Logic Apps StandardのワークフローをC#コードで定義できるようにするパブリックプレビュー機能です。結論から言うと、既存のLogic Appsの実行基盤を置き換えるものではなく、ワークフローの作り方を「デザイナー中心」から「コード中心」に広げる変更と捉えるのが正確です。
これにより、.NET開発者はVisual Studio Code、C#、Git、Pull Request、テストといった普段の開発プロセスにワークフロー定義を組み込みやすくなります。一方で、プレビュー段階のため、本番移行を急ぐよりも、まずは開発標準・認証方式・CI/CD・監視・既存ワークフローとの共存方針を確認することが重要です。Azure Updatesでは「In preview」は全Azure顧客が非本番用途の利用・テスト向けに利用できる段階と説明されています。(Microsoft Azure)
Azure Logic Apps Codeful Workflows with Logic Apps Standard SDKとは
Azure Logic Apps Codeful Workflows with Logic Apps Standard SDKは、Azure Logic Apps Standardのワークフローを、C#コードで構築できるようにする機能です。Microsoftの発表では、Logic Apps Standard SDK、正式にはMicrosoft.Azure.Workflows.Sdkを使い、トリガー、アクション、条件分岐、ループ、レスポンスなどのワークフロー定義をコードファーストで記述できるとされています。(TECHCOMMUNITY.MICROSOFT.COM)
従来のLogic Appsは、ビジュアルデザイナーで処理フローを組み立て、背後ではJSONベースのワークフロー定義を扱うモデルが中心でした。今回のCodeful Workflowsでは、開発者がC#のメソッドチェーンや型付きAPIを使ってワークフローを定義します。
重要なのは、これは「新しい実行環境」ではない点です。SDKで書いたワークフローはLogic Apps Standardの定義にコンパイルされ、既存のLogic Apps Standardランタイム上で動作します。つまり、運用・監視・接続・スケールといったLogic Apps Standardの強みを保ったまま、作成方法だけをコード寄りにできる変更です。(TECHCOMMUNITY.MICROSOFT.COM)
何が変わるのか
今回の変更で最も大きいのは、Logic Appsを「ローコードの自動化ツール」としてだけでなく、アプリケーション開発の一部として扱いやすくなることです。
Azure Logic Apps自体は、クラウド、オンプレミス、ハイブリッド環境のサービスやアプリ、データをつなぐ自動ワークフロー基盤です。Microsoft Learnでは、Logic Appsは1,400以上の事前構築済みコネクタを提供し、クラウドサービス、Office 365、SQL、SAP、IBM MQ、FTP/SFTPなどに接続できると説明されています。(Microsoft Learn)
Codeful Workflowsでは、この接続・オーケストレーション基盤を使いながら、定義部分をC#で書けるようになります。特に次のような点が実務上の変化です。
| 観点 | 従来の中心的な作り方 | Codeful Workflowsで変わること |
|---|---|---|
| 作成方法 | デザイナーとJSON定義が中心 | C#コードでワークフローを定義 |
| レビュー | JSON差分が読みづらい場合がある | Pull Requestで通常のコードとして確認しやすい |
| 品質管理 | 実行前に気づきにくい定義ミスがある | 型安全性やIntelliSenseにより、作成時に検出しやすい |
| 複雑なロジック | 式や分岐が読みにくくなることがある | C#のメソッドやライブラリに切り出しやすい |
| 開発体験 | ローコード利用者向けに強い | .NET開発者の標準的な開発フローに乗せやすい |
特に、複数チームで運用する基幹連携や、変更頻度の高いワークフローでは、差分レビューやテストのしやすさが大きなメリットになります。
対象になるユーザーとチーム
この機能の主な対象は、既にAzure Logic Apps Standardを使っている、または今後Logic Apps Standardで統合・自動化基盤を作るチームです。特に相性が良いのは次のようなケースです。
.NET中心の開発チーム
C#、Visual Studio Code、GitHub、Azure DevOps、CI/CDを日常的に使っているチームでは、ワークフロー定義をアプリケーションコードと同じ流れで管理できます。
たとえば、受注API、在庫確認、承認処理、通知、外部SaaS連携を組み合わせる処理を、アプリケーション側の変更と同じPull Requestでレビューできます。ワークフローだけ別管理になるより、変更理由や影響範囲を追いやすくなります。
複雑な条件分岐やカスタム処理を含む連携基盤
単純な「AからBへデータを送る」だけであれば、従来のデザイナーでも十分です。一方、次のような処理ではコードファーストの価値が出やすくなります。
- 金額や顧客属性に応じて承認ルートを変える
- 外部APIの戻り値を独自ルールで正規化する
- 例外時に補償処理や再通知を行う
- 複数システムの結果を集約して次の処理を決める
- 自社ライブラリを使ってバリデーションや変換を行う
Logic Apps Standard SDKでは、WorkflowFactoryがワークフロー定義・登録の主要な入口となり、Stateful、Stateless、Agentワークフローを作成できるとMicrosoft Learnで説明されています。(Microsoft Learn)
AIエージェント連携を検証するチーム
今回のSDKは、通常のエンタープライズ統合ワークフローだけでなく、Autonomous agentsやConversational agentsのようなエージェント型ワークフローにも触れています。Microsoftの紹介では、SDKはエンタープライズ統合ワークフローとエージェント型ワークフローの両方を同じSDKの構成要素で扱えるとされています。(TECHCOMMUNITY.MICROSOFT.COM)
ただし、AIエージェント系の機能はプレビューや関連サービスの条件が絡みやすいため、セキュリティ、データ保護、監査、利用規約の確認を通常の業務ワークフロー以上に慎重に行うべきです。
管理者が確認すべきポイント
Codeful Workflowsは開発者向けの変更に見えますが、管理者にも影響があります。特に確認すべきなのは、利用範囲、認証、接続情報、監視、デプロイ権限です。
プレビュー機能としての利用範囲
Azure Updates上の「In preview」は、非本番での利用・テスト向けの段階です。Azureのプレビュー機能には追加の使用条件が適用される場合があり、MicrosoftはAzure Legal Informationで、プレビュー補足条項がベータ、プレビュー、GA前のAzure機能に適用されると説明しています。(Microsoft Azure)
そのため、管理者は次のようなルールを先に決めておくと安全です。
| 確認項目 | 判断基準 |
|---|---|
| 利用環境 | 本番ではなく、開発・検証・PoCから開始する |
| データ | 個人情報、機密情報、規制対象データを扱うか確認する |
| SLA | プレビュー機能に本番SLAを期待しない |
| 変更管理 | SDKや拡張機能の更新で挙動が変わる前提で記録を残す |
| 承認 | クラウド管理者、セキュリティ担当、開発責任者で利用可否を合意する |
「動いたから本番に入れる」ではなく、「本番品質に必要な前提を満たせるか」を確認することが重要です。
接続情報と認証方式
Microsoftの紹介では、VS CodeでLogic Apps codefulプロジェクトを作成し、Azure上のコネクタを使う場合、現時点ではConnection Keysを選択する流れが案内されています。また、Managed Identity認証は開発中と説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
これは管理者にとって大きな確認ポイントです。Managed Identityを前提にしたゼロシークレット運用を標準化している組織では、プレビュー段階の認証方式が社内基準に合うかを確認する必要があります。
少なくとも、次の観点をチェックしてください。
- Connection Keyの保存場所
- ローカル開発環境に残る接続情報の扱い
- Gitにシークレットを含めない仕組み
- 開発者ごとのAzure権限
- 検証用サブスクリプションと本番サブスクリプションの分離
- Key VaultやCI/CD変数との連携方針
監視と運用の責任分界
SDKで作ったワークフローもLogic Apps Standardランタイム上で動くため、実行履歴や監視の考え方は従来のLogic Apps Standardに近いままです。Microsoftの紹介でも、SDKで作成したワークフローは従来と同様に実行履歴を確認でき、入力・出力の検査ができると説明されています。(Microsoft)
ただし、ワークフロー定義がコードになることで、障害調査の担当範囲は変わります。デザイナー上の設定だけを見る運用から、C#コード、ビルド結果、デプロイ履歴、コネクタ接続情報まで含めて確認する運用に変わります。
開発者が確認すべきポイント
開発者にとっての魅力は、C#で書けることです。ただし、通常のC#アプリケーションと同じ感覚で何でも書けると考えると、設計を誤る可能性があります。
SDKで何を定義するのか理解する
Logic Apps Standard SDKでは、IWorkflowProviderを実装して、ワークフローの定義をホストに登録する形が示されています。Microsoft Learnでは、IWorkflowProviderは依存関係注入を通じてワークフローホストに登録されるワークフロー定義を提供するインターフェースと説明されています。(Microsoft Learn)
つまり、開発者が書くのは「常駐アプリケーションの自由な処理」ではなく、Logic Appsのトリガーから始まるワークフローグラフです。この理解がないと、ロジックを詰め込みすぎて、Logic Appsの可視性や再実行性を損なう設計になりがちです。
トリガーとアクションの境界を意識する
Microsoft Learnでは、WorkflowTriggers.BuiltInからHTTPトリガー、Recurrenceトリガー、Conversational Agentトリガーなどを作成する例が示されています。(Microsoft Learn)
実務では、次のように整理すると設計しやすくなります。
| 処理 | Logic Appsに寄せるべきもの | C#コードに寄せるべきもの |
|---|---|---|
| 外部システム連携 | コネクタ、HTTP、Service Bus、SharePointなど | 独自SDKしかないAPI呼び出し |
| 分岐 | 業務フローとして見える条件分岐 | 複雑な判定ロジック |
| 変換 | 単純な整形、マッピング | ドメインルールを伴う変換 |
| 例外処理 | リトライ、タイムアウト、補償フロー | 例外内容の分類や独自ログ生成 |
| テスト | ワークフロー単位の結合確認 | メソッド単位の単体テスト |
すべてをC#に寄せると、Logic Appsの監視性や再利用性が下がります。逆に、すべてをワークフローアクションで表現しようとすると、複雑な業務ロジックが読みにくくなります。境界設計が成功の鍵です。
制御フローをコードで読みやすく保つ
SDKでは、条件分岐、Scope、繰り返しなどの制御フローも扱えます。Microsoft Learnでは、WorkflowActions.BuiltIn.ControlからScopeやConditionなどの制御アクションを作成する説明があります。(Microsoft Learn)
開発時は、次のようなルールを置くと保守しやすくなります。
- 1つのワークフローに処理を詰め込みすぎない
- 業務上のまとまりごとにScopeを分ける
- アクション名は運用担当者が見ても意味が分かる名前にする
- 例外時の分岐を後から追加するのではなく、最初から設計する
- コード上のメソッド名とワークフロー上のアクション名を揃える
特にアクション名は重要です。障害時に実行履歴を見るのは、必ずしもコードを書いた本人とは限りません。Step1やCompose2ではなく、ValidateOrder、CallPaymentApi、NotifyFailureのような名前にしておくと、調査時間を短縮できます。
現時点での制限と注意点
プレビュー段階では、できることだけでなく、できないことを先に把握しておく必要があります。Microsoftの紹介では、現時点の注意点として、Service Provider connectorsは未対応、Dynamic schemasは未対応、Managed Identity認証は開発中、Custom codeはcallback methodのみ対応、アクションは参照前に定義・命名する必要がある、といった制限が挙げられています。(Microsoft)
実務で特に影響が出やすいのは、次の3点です。
Service Provider connectorsを前提にしない
既存のLogic Apps StandardでService Providerベースの組み込みコネクタを多用している場合、Codeful Workflowsへそのまま置き換えられるとは限りません。まずは対象ワークフローで使っているコネクタの種類を棚卸ししてください。
「HTTPトリガーと標準的なManaged Connectorだけで構成された小さなワークフロー」から検証するのが安全です。
Dynamic schemaが必要な処理は慎重に扱う
接続先のスキーマが動的に変わる処理では、プレビュー段階のSDKで扱いづらい可能性があります。たとえば、SaaS側のカスタム項目、SharePointリスト、動的なフォーム項目などは、型付きAPIのメリットと相性が悪くなる場面があります。
この場合は、無理にCodeful Workflowsへ寄せず、従来のデザイナーやJSON定義の方が扱いやすいかを比較してください。
Managed Identity前提の本番設計は待つ
Managed Identity認証が開発中である点は、エンタープライズ運用では無視できません。社内標準で「シークレットをコードや設定ファイルに保持しない」「サービス間認証はManaged Identityを使う」と決めている場合、本番採用の判断は慎重に行うべきです。
検証段階ではConnection Keysを使い、GAや今後のプレビュー更新でManaged Identity対応が明確になってから、本番展開の設計を詰める流れが現実的です。
既存ワークフローは移行すべきか
既存のLogic Apps StandardワークフローをすぐにCodeful Workflowsへ移行する必要はありません。今回の機能は、既存ワークフローを置き換える強制的な変更ではなく、コードファーストという新しい選択肢の追加です。
移行を検討するなら、次の基準で優先度を決めるとよいでしょう。
| 優先度 | 対象ワークフロー | 判断 |
|---|---|---|
| 高 | 複雑な分岐、独自ロジック、頻繁な変更がある | PoC候補にする価値が高い |
| 中 | 開発チームが頻繁に改修する業務連携 | コードレビューやテストの効果を検証する |
| 低 | 単純な定期実行や通知 | 従来方式のままで十分な場合が多い |
| 保留 | Service Provider connectorsやDynamic schemaに強く依存 | SDK側の対応状況を待つ |
| 保留 | 本番で厳格なManaged Identity運用が必須 | 認証対応が明確になるまで検証に留める |
移行の目的は「新しいから使う」ではありません。変更履歴の追跡、レビュー品質、テスト自動化、複雑なロジックの整理といった課題がある場合に、Codeful Workflowsを検討する価値があります。
検証環境での進め方
最初の検証では、既存の重要ワークフローをいきなり移行しないでください。小さく作り、運用まで含めて確認することが大切です。
検証のおすすめ手順
| 手順 | 実施内容 | 確認ポイント |
|---|---|---|
| 1 | 検証用サブスクリプションまたはリソースグループを用意 | 本番データや本番接続を使わない |
| 2 | VS CodeとLogic Apps Standard拡張機能を準備 | 必要バージョンを満たすか確認 |
| 3 | 小さなHTTPトリガーのワークフローを作成 | ローカル実行、実行履歴、レスポンスを確認 |
| 4 | Managed Connectorを1つ追加 | 接続情報、認証、権限を確認 |
| 5 | 条件分岐とScopeを追加 | 実行履歴で分岐が追えるか確認 |
| 6 | エラー処理を追加 | 失敗時の通知、再実行、ログを確認 |
| 7 | CI/CDに組み込む | ビルド、テスト、デプロイ差分を確認 |
| 8 | 社内標準と照合 | セキュリティ、監査、命名、タグ、コスト管理を確認 |
Microsoftの紹介では、VS CodeのLogic Apps拡張機能からLogic Apps workspaceを作成し、ワークフロー種別としてLogic Apps codefulを選び、StatefulやAgent系のワークフローを選択する流れが説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
CI/CDとソース管理で見直すべきこと
Codeful Workflowsの価値を最大化するには、単にC#で書くだけでなく、開発プロセス全体を整える必要があります。
リポジトリ構成
アプリケーションコードと同じリポジトリに含めるか、Logic Apps専用リポジトリに分けるかを決めます。業務システムと密接に連動するワークフローであれば同一リポジトリ、複数システムから共通利用する連携基盤であれば専用リポジトリが向いています。
Pull Requestのレビュー観点
通常のC#レビューに加えて、次の観点をチェックしてください。
- トリガー条件が意図どおりか
- 外部システムへの呼び出し回数が増えすぎていないか
- リトライ時に二重登録や二重通知が起きないか
- 失敗時の分岐が用意されているか
- コネクタ接続先が検証環境と本番環境で分離されているか
- アクション名が運用者に伝わる名前になっているか
テストの分け方
C#で書けるからといって、すべてを単体テストで保証できるわけではありません。Logic Appsは外部サービス連携が本質なので、テストを分けて考える必要があります。
| テスト種別 | 目的 | 例 |
|---|---|---|
| 単体テスト | 独自ロジックの検証 | 金額判定、データ変換、入力検証 |
| ワークフローテスト | 分岐や例外処理の確認 | 正常系、タイムアウト、外部APIエラー |
| 結合テスト | コネクタ・認証・接続先の確認 | SharePoint、SQL、Service Bus連携 |
| 運用テスト | 監視・通知・再実行の確認 | Application Insights、Log Analytics、アラート |
Microsoft Learnでは、WorkflowContextがカスタムコードアクションに渡され、トリガー結果や既に実行されたアクション結果にアクセスできると説明されています。(Microsoft Learn) この仕組みを使う場合も、ワークフロー上の実行順序と依存関係を明確にしておくことが大切です。
よくある失敗パターン
既存のJSONワークフローをそのままコード化しようとする
最初から完全移行を狙うと、SDKの制限や命名、接続情報、デプロイ方法で詰まりやすくなります。まずは小さな新規ワークフローで作成・実行・監視・デプロイまでを確認し、その後に移行候補を選ぶ方が安全です。
C#に処理を詰め込みすぎる
C#で書けることはメリットですが、すべてをカスタムコードに閉じ込めると、Logic Appsの視覚的な実行履歴やコネクタの再利用性が弱くなります。業務フローとして追うべき処理はワークフロー上に残し、複雑な計算や変換だけをC#に切り出す設計が現実的です。
認証方式を後回しにする
PoCではConnection Keyで動いても、本番ではManaged IdentityやKey Vault連携、シークレットローテーションが求められることがあります。認証方式は最後に確認するのではなく、最初の検証項目に入れてください。
プレビューのまま本番標準に組み込む
Public Previewは、将来の仕様変更や制限の解消を前提に試す段階です。社内標準のテンプレートや共通基盤に組み込む場合は、GA後またはMicrosoftの公式ドキュメントで本番利用条件が明確になってから判断するのが無難です。
今回のアップデートで取るべき次のアクション
Azure Logic Apps Codeful Workflows with Logic Apps Standard SDKは、Logic Appsをより開発者フレンドリーにする重要なアップデートです。特に、C#、Git、Pull Request、CI/CDを中心に業務システムを開発しているチームでは、ワークフローを「運用担当だけが触る自動化設定」ではなく、「開発チームが品質管理するコード資産」として扱いやすくなります。
ただし、現時点ではPublic Previewです。まずは非本番環境で、HTTPトリガー、Managed Connector、条件分岐、Scope、エラー処理、CI/CD、監視までを一通り確認してください。そのうえで、複雑な業務ロジックを持つワークフローや、レビュー・テストの課題があるワークフローから段階的に適用候補を選ぶのが現実的です。
最初にやるべきことは、既存ワークフローの全面移行ではありません。小さなCodeful WorkflowsのPoCを作り、社内の開発標準・セキュリティ基準・運用基準に合うかを確認することです。そこまで確認できれば、GAに向けた移行判断や標準化の準備を無理なく進められます。
コメント