2026年6月20日に確認された Microsoft の Notice は、Logic Apps Standard の .NET 10 対応に向けて、ホスティングモデルを Azure Functions の In-Proc から Out-of-Proc へ移行するという案内です。結論から言うと、多くの Logic Apps Standard では自動移行され、利用者側の作業は基本的に不要です。ただし、NuGet ベースのデプロイモデルを使っている Logic Apps Standard は例外で、移行前に設定・CI/CD・ローカル検証を確認する必要があります。Microsoft は、対象外のアプリは自動移行される一方、NuGet ベースのアプリでは LOGICAPP_INPROC_REDIRECT=1 を保持するよう案内しています。(TECHCOMMUNITY.MICROSOFT.COM)
.NET 利用者が最初に確認すべきことは、「自分の Logic Apps Standard が NuGet package-based の .NET プロジェクトか」「LOGICAPP_INPROC_REDIRECT をデプロイで消していないか」「アプリ再起動のタイミングを管理できているか」の3点です。今回の変更は、単なるバージョンアップ通知ではなく、Logic Apps Standard の実行基盤に関わる変更なので、運用中のワークフローでは事前確認をおすすめします。
Logic Apps の .NET 10対応に向けて何が変わるのか
今回の変更は、Logic Apps Standard が .NET 10 をサポートするための準備として、Azure Functions のホスティングモデルを In-Proc から Out-of-Proc に移すものです。In-Proc は Functions ホストと同じプロセスで動く方式、Out-of-Proc は別のワーカープロセスで動く方式と理解すると分かりやすいです。
Azure Functions の .NET では、In-Process モデルのサポート終了が 2026年11月10日に予定されており、Microsoft は分離ワーカーモデルへの移行を推奨しています。Functions の公式ドキュメントでも、Isolated worker model では関数コードが別の .NET worker process で実行され、Functions 4.x では .NET 10 が Isolated worker model 側に位置付けられています。(Microsoft Learn)
Logic Apps Standard は Azure Functions ランタイムの拡張モデルを使って動作するため、今回の変更は Azure Functions の .NET 実行モデル変更と無関係ではありません。Standard Logic Apps は、単一テナントの Logic Apps ランタイムが Azure Functions runtime 上の extension としてホストされる設計です。(Microsoft Learn)
| 変更点 | 内容 | 利用者への影響 |
|---|---|---|
| ホスティングモデルの変更 | In-Proc から Out-of-Proc へ移行 | 実行基盤の切り替え。多くは自動移行 |
| .NET 10対応の準備 | Logic Apps Standard の将来の .NET 10 対応に向けた前段階 | すぐに全アプリを .NET 10 化する話ではない |
| 例外対象 | NuGet ベースのデプロイモデルを使う Logic Apps | 設定保持と移行準備が必要 |
| 移行タイミング | 対象設定がないアプリは、次回再起動時に Out-of-Proc へ移行される | 再起動が変更適用のきっかけになる可能性がある |
重要なのは、今回の Notice を「.NET 10 に今すぐ移行しなければならない」という意味で読まないことです。Microsoft は .NET 10 サポートについて、Logic Apps runtime と workflow version のガイダンスが確認できた段階で別途案内するとしています。(TECHCOMMUNITY.MICROSOFT.COM)
影響を受ける可能性が高い対象者
影響確認が必要なのは、主に Logic Apps Standard を .NET / NuGet package-based project として運用しているチームです。
Microsoft Learn では、Visual Studio Code の Logic Apps Standard プロジェクトには、既定の Extension bundle-based（Node.js）と、変換して利用する NuGet package-based（.NET）の2種類があると説明されています。また、カスタム組み込み操作を開発・実行したい場合など、一部シナリオでは NuGet package-based project が必要になります。(Microsoft Learn)
まず確認すべき対象
| 対象 | 確認の優先度 | 理由 |
|---|---|---|
| Logic Apps Standard を利用している | 高 | 今回の Notice の中心対象 |
| NuGet package-based の Logic Apps Standard | 最優先 | 自動移行前に利用者側の対応が必要 |
| カスタム組み込みコネクタや custom built-in operation を使っている | 高 | NuGet ベース構成の可能性が高い |
| CI/CD で app settings を上書きしている | 高 | LOGICAPP_INPROC_REDIRECT が消えるリスクがある |
| Consumption の Logic Apps だけを使っている | 低 | 今回の主対象は Logic Apps Standard |
見分け方としては、リポジトリ内に Logic Apps Standard 用の .csproj、NuGet パッケージ参照、.bin フォルダー、Microsoft.Azure.Workflows.WebJobs.Extension などが含まれていないかを確認します。Microsoft のドキュメントでも、NuGet package-based project ではパッケージやライブラリを含む .bin フォルダーを持つなど、Extension bundle-based project とは構造が異なると説明されています。(Azure 中国ドキュメント)
LOGICAPP_INPROC_REDIRECT=1 は何のための設定か
LOGICAPP_INPROC_REDIRECT=1 は、Logic Apps Standard を現在の In-Proc ホスティングモデルに留め、自動的に Out-of-Proc へ移行されるのを防ぐための app setting です。Microsoft は、NuGet ベースのデプロイを使っている場合、この設定をアプリが移行準備できるまで保持するよう案内しています。(TECHCOMMUNITY.MICROSOFT.COM)
LOGICAPP_INPROC_REDIRECT=1この設定が重要なのは、Azure Portal で一度設定されていても、CI/CD や IaC のデプロイで app settings を丸ごと上書きすると消える可能性があるためです。Microsoft は、例外対象のアプリにこのフラグを追加するが、それは一度だけであり、その後の構成変更で上書きされる可能性があるため、デプロイプロセス側で値を保持する必要があると説明しています。(TECHCOMMUNITY.MICROSOFT.COM)
設定確認に使える Azure CLI
Azure CLI には Logic Apps の app settings を確認・更新する az logicapp config appsettings コマンドが用意されています。list は設定表示、set は設定更新に使えます。(Microsoft Learn)
az logicapp config appsettings list \
--name <logic-app-name> \
--resource-group <resource-group-name>設定を追加または保持したい場合は、次のように指定します。
az logicapp config appsettings set \
--name <logic-app-name> \
--resource-group <resource-group-name> \
--settings LOGICAPP_INPROC_REDIRECT=1本番環境で実行する前に、まず検証環境で同じ設定管理方法を確認してください。特に Azure DevOps、GitHub Actions、Bicep、ARM テンプレート、Terraform などで app settings を管理している場合は、ポータル上の手動設定だけでは不十分です。
すぐ確認したい設定と運用上の注意
今回の変更で失敗しやすいのは、コードそのものよりも 設定の消失と再起動タイミングの見落としです。対象外のアプリでは自動移行される可能性があるため、運用チームは「いつ切り替わるか」を把握できる状態にしておく必要があります。
| 確認項目 | 見る場所 | 判断基準 | 対応 |
|---|---|---|---|
| Logic Apps の種類 | Azure Portal、リソース一覧 | Standard か Consumption か | Standard なら次項目を確認 |
| プロジェクト形式 | リポジトリ、ビルド成果物 | NuGet package-based か | NuGet ベースなら優先対応 |
LOGICAPP_INPROC_REDIRECT | App settings | 1 が保持されているか | CI/CD 側にも反映 |
| デプロイ方式 | YAML、Bicep、ARM、Terraform | app settings を全置換していないか | 設定差分をレビュー |
| 再起動タイミング | App Service 操作、デプロイ、スケール操作 | 意図せず再起動しないか | メンテナンス枠で管理 |
| 監視 | Application Insights、実行履歴、ログ | 移行後の失敗を検知できるか | 重要ワークフローにアラート設定 |
Microsoft の案内では、LOGICAPP_INPROC_REDIRECT がないアプリは、次回再起動時に Azure Functions の Out-of-Proc ホスティングモデルへ自動移行されるとされています。つまり、デプロイ、構成変更、スケール操作、手動再起動などが、実質的な切り替えポイントになる可能性があります。(TECHCOMMUNITY.MICROSOFT.COM)
NuGet ベースの Logic Apps で取るべき対応
NuGet ベースの Logic Apps Standard を使っている場合、今すぐ本番環境で設定を外して移行するのではなく、まずは LOGICAPP_INPROC_REDIRECT=1 を保持し、検証準備を進めるのが現実的です。
Microsoft は、NuGet ベースのアプリでは、最新の Azure Functions Core Tools を入手し、プロジェクト構成を Azure Functions Out-of-Proc ホスティングモデルに更新し、ローカルで検証したうえでデプロイプロセスを更新する流れを示しています。(TECHCOMMUNITY.MICROSOFT.COM)
| 手順 | 作業内容 | 目的 |
|---|---|---|
| 対象洗い出し | Logic Apps Standard の一覧を作る | 影響範囲を明確にする |
| NuGet ベース判定 | .csproj、NuGet 参照、カスタム組み込み操作を確認 | 例外対象か判断する |
| 設定保持 | LOGICAPP_INPROC_REDIRECT=1 を app settings と CI/CD に反映 | 自動移行を防ぐ |
| ローカル検証準備 | Azure Functions Core Tools、Logic Apps Standard 拡張、.NET SDK を確認 | Out-of-Proc 検証の前提を整える |
| 構成更新 | プロジェクト構成を Out-of-Proc 前提に見直す | 実行モデル変更に備える |
| 非本番で検証 | 重要ワークフロー、コネクタ、エラー処理を確認 | 本番影響を抑える |
| 段階移行 | 検証後に設定削除と再起動を計画 | 管理された切り替えにする |
特に注意したいのは、Microsoft が NuGet デプロイモデル向けには、必要な Logic Apps runtime package guidance とサポートされる移行手順が確認できた段階で別途案内するとしている点です。NuGet ベースのアプリでは、現時点で「設定を外せば完了」と考えず、追加ガイダンスを待ちながら検証環境を整えるのが安全です。(TECHCOMMUNITY.MICROSOFT.COM)
うっかり設定を消した場合の影響
LOGICAPP_INPROC_REDIRECT=1 を誤って削除すると、そのアプリは Out-of-Proc ホスティングモデルへ移行される可能性があります。ただし、Microsoft の FAQ では、誤って削除した場合でも、設定を再適用してアプリを再起動することで動作を戻せると説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
とはいえ、本番環境で「戻せるから問題ない」と考えるのは危険です。移行後にワークフローの一部だけが失敗した場合、原因がホスティングモデル変更なのか、外部API、認証、接続、ネットワーク、パッケージ依存なのかを切り分けるのに時間がかかります。
そのため、次の3点を事前に決めておくと運用が安定します。
- 誰が
LOGICAPP_INPROC_REDIRECTの変更を承認するか - どの環境から Out-of-Proc 検証を始めるか
- 移行後に見るログ、実行履歴、アラートをどれにするか
.NET 利用者が誤解しやすいポイント
すべての .NET アプリが対象ではない
今回の Notice は、一般的な ASP.NET Core アプリや Azure Functions 全般に対する単独の移行案内ではありません。中心は Logic Apps Standard のホスティングモデル移行です。ただし、Logic Apps Standard は Azure Functions の実行基盤と関係が深いため、.NET、Azure Functions、Logic Apps を横断して運用しているチームは一緒に確認した方が安全です。
.NET 10 への即時移行ではない
今回の変更は .NET 10 対応に向けた準備です。Microsoft は .NET 10 サポートについて別途案内するとしているため、現時点では「自社の Logic Apps Standard が安全に Out-of-Proc へ移行できる状態か」を確認する段階と考えるべきです。(TECHCOMMUNITY.MICROSOFT.COM)
自動移行だから監視不要、ではない
多くのアプリでは自動移行され、作業不要とされています。ただし、業務上重要なワークフローでは、移行後の実行履歴、失敗率、外部接続、再試行、処理時間を確認できる状態にしておくべきです。自動移行は「影響がない」と同義ではなく、「利用者側の事前作業が少ない」という意味で捉えるのが実務的です。
本番運用でのチェックリスト
公開前・移行前のレビューでは、次のチェックリストを使うと抜け漏れを防ぎやすくなります。
| チェック | 確認内容 |
|---|---|
| 対象リソース | Logic Apps Standard の一覧を作成した |
| プロジェクト形式 | NuGet package-based かどうかを確認した |
| app settings | LOGICAPP_INPROC_REDIRECT=1 の有無を確認した |
| CI/CD | デプロイ時に app settings を消さないことを確認した |
| IaC | Bicep、ARM、Terraform などの定義に必要設定を反映した |
| 再起動管理 | デプロイや設定変更で意図せず再起動しないか確認した |
| ローカル検証 | Core Tools とプロジェクト構成を確認した |
| 非本番検証 | 主要ワークフローを実行し、接続・認証・エラー処理を確認した |
| 監視 | 移行前後のログ、実行履歴、アラートを確認できる |
| ロールバック | 設定再適用と再起動の手順を運用メモに残した |
まず取るべき行動
今回の Logic Apps Migration from In-Proc to Out-of-Proc hosting model で、.NET 利用者がすぐに行うべきことはシンプルです。
まず、Logic Apps Standard を使っているかを確認します。次に、NuGet package-based の .NET プロジェクトかどうかを見ます。該当する場合は、LOGICAPP_INPROC_REDIRECT=1 が Azure の app settings だけでなく、CI/CD や IaC の定義にも保持されているか確認してください。
そのうえで、最新の Azure Functions Core Tools、プロジェクト構成、ローカル検証、非本番での移行テストを準備します。本番環境では、再起動が移行のきっかけになり得るため、無計画な設定変更やデプロイを避け、監視とロールバック手順を用意してから段階的に進めるのが安全です。
コメント