.NET 10対応に向けたLogic Apps Standardの移行で、管理者が最初に確認すべきことは「自社のLogic AppsがNuGetベースのデプロイモデルを使っているか」と「LOGICAPP_INPROC_REDIRECT=1 がCI/CDで上書きされないか」です。Microsoftの公式発表では、多くの環境は自動移行の対象で追加作業は不要とされていますが、NuGetベースのデプロイを使うLogic Appsは例外として事前確認が必要です。移行そのものはIn-ProcからOut-of-Proc hosting modelへの変更であり、運用管理者にとってはアプリ設定、再起動タイミング、監査ログ、権限、周知の整備が重要になります。(TECHCOMMUNITY.MICROSOFT.COM)
まず確認すべき結論
2026年6月20日頃に確認されたIntegration on Azure BlogのNoticeでは、Logic Apps Standardが.NET 10サポートへ向かう準備として、Azure FunctionsのIn-Proc hosting modelからOut-of-Proc hosting modelへ移行する方針が示されました。Microsoft Tech Community上の公開日はUTCでは2026年6月19日表示のため、日本時間では6月20日として扱うと分かりやすいです。(TECHCOMMUNITY.MICROSOFT.COM)
管理者が取るべき対応は、次の3つに整理できます。
| 確認項目 | 管理者が見るべきポイント | 対応の目安 |
|---|---|---|
| 対象範囲 | Logic Apps Standardを使っているか。特にNuGetベースのデプロイか | NuGetベースなら追加確認が必要 |
| アプリ設定 | LOGICAPP_INPROC_REDIRECT が存在するか、値が 1 か | 移行準備が終わるまで上書き・削除を防ぐ |
| CI/CD | ARM/Bicep、Azure DevOps、GitHub Actionsなどでアプリ設定を置き換えていないか | パイプラインに保持ルールを追加する |
| 再起動 | デプロイ、設定変更、スケール操作でアプリが再起動されるか | 再起動時に移行が進む可能性を前提にする |
| 監査 | 誰がいつ設定変更したか追跡できるか | Activity Logと診断設定を確認する |
| 周知 | 開発、運用、業務部門に影響を説明済みか | 「多くは自動だが、例外がある」と伝える |
重要なのは、「自動移行だから何もしなくてよい」と判断しないことです。例外環境では、アプリ設定を誤って消したり、CI/CDが設定を丸ごと置き換えたりすると、意図しないタイミングでOut-of-Procへ移行する可能性があります。
In-ProcからOut-of-Proc hosting modelへの移行とは
In-Procは、アプリの処理がAzure Functionsホストと同じプロセス内で動作するモデルです。一方、Out-of-Procは、ワーカーがホストとは別プロセスで動作するモデルです。Azure Functionsの.NET isolated worker modelでは、ホストとアプリ側の依存関係の衝突を減らし、アプリ側で起動処理や依存性注入などを制御しやすくなる利点が説明されています。(Microsoft Learn)
今回のLogic Apps Standard向けのNoticeは、単に「.NET 10が使えるようになる」という案内ではありません。実務上は、.NET 10サポートに備えるためのホスティングモデル変更として捉えるべきです。Microsoftの発表でも、.NET 10サポートに関するLogic Apps runtimeやworkflow versionの詳細ガイダンスは別途案内されるとされています。(TECHCOMMUNITY.MICROSOFT.COM)
つまり、管理者が今やるべきことは、.NET 10へすぐ上げることではなく、Out-of-Proc移行で壊れやすい運用ポイントを先に洗い出すことです。
影響を受ける可能性が高い環境
Microsoftの発表では、多くの顧客では移行が自動で行われ、追加アクションは不要とされています。一方で、現在のNuGetベースのデプロイモデルを使うLogic Appsは例外として扱われ、事前に顧客側の更新が必要になる可能性があります。(TECHCOMMUNITY.MICROSOFT.COM)
特に注意したいのは、次のような環境です。
| 環境 | リスク | 確認方法 |
|---|---|---|
| NuGetベースのデプロイを使っているLogic Apps Standard | 事前更新なしで移行するとビルド・実行・依存関係で問題が出る可能性 | リポジトリ、パッケージ、デプロイ手順を確認 |
| CI/CDでアプリ設定を管理している環境 | LOGICAPP_INPROC_REDIRECT が上書き・削除される可能性 | パイプラインの変数、Bicep、ARM、YAMLを確認 |
| 本番と検証で設定差分が大きい環境 | 検証では成功しても本番で挙動が変わる | App settings、host.json、接続情報を比較 |
| 自動再起動が頻繁に発生する環境 | 設定がない場合、次回再起動時に移行が進む可能性 | デプロイ頻度、スケール操作、設定変更履歴を確認 |
| 監査ログを長期保存していない環境 | いつ誰が設定を変えたか追えない | Activity Log、Log Analytics、診断設定を確認 |
Azure Functionsのアプリ設定は変更時に既定でアプリ再起動を伴います。また、ARMテンプレートやREST APIでアプリ設定を更新する場合、既存設定を置き換える動きに注意が必要です。これは今回のLOGICAPP_INPROC_REDIRECTを守るうえで重要なポイントです。(Microsoft Learn)
LOGICAPP_INPROC_REDIRECT=1 の意味と扱い方
今回のNoticeで最も重要な設定が、次のアプリ設定です。
LOGICAPP_INPROC_REDIRECT=1この設定は、Logic Appsを現在のIn-Proc hosting modelに残し、自動的にAzure FunctionsのOut-of-Proc hosting modelへ移行されることを防ぐために使われます。Microsoftは、例外条件に該当するアプリにはこのフラグを追加すると説明していますが、この処理は一度だけであり、その後の構成変更で上書きされる可能性があります。(TECHCOMMUNITY.MICROSOFT.COM)
すぐ削除してはいけないケース
次に該当する場合は、LOGICAPP_INPROC_REDIRECT=1 を安易に削除しないでください。
| 状況 | 判断 |
|---|---|
| NuGetベースのデプロイを使っている | 移行準備が終わるまで保持 |
| Microsoftの追加ガイダンスがまだ出ていない | 公式手順確認まで保持 |
| ローカル検証が未実施 | 保持 |
| CI/CDが設定を丸ごと置き換える | 先にパイプライン修正 |
| 本番の切り戻し手順が未整備 | 保持 |
MicrosoftのFAQでは、誤ってLOGICAPP_INPROC_REDIRECT=1を削除した場合、アプリがOut-of-Proc hosting modelへ移行される可能性がある一方、設定を再適用してアプリを再起動すれば挙動を戻せると説明されています。ただし、本番環境では実行中ワークフローや接続先システムへの影響があり得るため、復旧手順として事前に文書化しておくべきです。(TECHCOMMUNITY.MICROSOFT.COM)
管理者向けチェックリスト
対象リソースを棚卸しする
まず、サブスクリプション内のLogic Apps Standardを一覧化します。運用台帳が古い場合は、AzureポータルだけでなくAzure CLIやResource Graphも使って確認してください。
確認すべき項目は次のとおりです。
| 項目 | 記録する内容 |
|---|---|
| Logic App名 | 本番・検証・開発の区別が分かる名称 |
| リソースグループ | 管理単位、権限単位 |
| サブスクリプション | 請求・監査・権限の単位 |
| 担当チーム | 開発、運用、業務オーナー |
| デプロイ方式 | 手動、Zip、Azure DevOps、GitHub Actions、Bicep、ARMなど |
| NuGet利用 | NuGetベースのデプロイかどうか |
| アプリ設定 | LOGICAPP_INPROC_REDIRECT の有無 |
| 重要度 | 業務停止時の影響、SLA、連携先 |
Azure CLIでは、Logic Appのアプリ設定を表示・更新するaz logicapp config appsettingsコマンドが用意されています。設定値は出力でマスクされる場合があるため、存在確認と設定管理の用途を分けて使うと安全です。(Microsoft Learn)
az logicapp config appsettings list \
--resource-group <resource-group-name> \
--name <logic-app-name>設定を追加・更新する場合は、次のように指定します。
az logicapp config appsettings set \
--resource-group <resource-group-name> \
--name <logic-app-name> \
--settings LOGICAPP_INPROC_REDIRECT=1ただし、本番環境でこの操作を直接行う前に、既存設定が失われないこと、変更に伴う再起動の影響、パイプライン側で次回デプロイ時に上書きされないことを確認してください。
CI/CDでアプリ設定が上書きされないようにする
最も起きやすい失敗は、Azure側ではLOGICAPP_INPROC_REDIRECT=1が入っているのに、次回デプロイでCI/CDが古い設定一式を投入し、フラグを消してしまうパターンです。
特に次のファイルや設定を確認してください。
azure-pipelines.yml
.github/workflows/*.yml
main.bicep
parameters.json
ARM template
Terraform定義
環境別変数ファイル
デプロイ用PowerShell
デプロイ用Azure CLIスクリプト確認のポイントは、「個別の設定を追加しているか」「アプリ設定全体を置き換えているか」です。置き換え型の実装では、テンプレートに含まれていない設定が消えることがあります。Azure Functionsの公式ドキュメントでも、REST APIやARMテンプレートでアプリ設定を更新する場合は既存設定の置き換えに注意するよう説明されています。(Microsoft Learn)
権限を最小限に見直す
今回の対応では、アプリ設定の閲覧・変更、アプリ再起動、デプロイ、監査ログ確認が発生します。便利だからといって全員にContributorを付与すると、誰が重要設定を変更できるのか分からなくなります。
Logic Apps Standardには、Standardロジックアプリとワークフローを管理できるLogic Apps Standard Contributorロールが用意されています。ただし、アクセス権や所有権の変更はできません。一般的なContributorロールは多くのリソース管理操作を許可しますが、RBACロール割り当てまでは許可しないロールです。(Microsoft Learn)
実務では、次のように分けると管理しやすくなります。
| 役割 | 推奨権限の考え方 | 注意点 |
|---|---|---|
| 開発者 | 検証環境のLogic Apps編集・デプロイ権限 | 本番設定を直接変えられないようにする |
| 運用管理者 | 本番のアプリ設定確認、再起動、監視設定の管理 | 変更は申請・承認ベースにする |
| CI/CDサービスプリンシパル | 必要なリソースグループまたはLogic App単位に限定 | サブスクリプション全体に広げない |
| 監査担当 | Activity Log、診断ログ、変更履歴の閲覧 | 設定値やシークレットを不用意に見せない |
| 業務部門 | 変更日程、影響、連絡先を把握 | Azureリソース操作権限は原則不要 |
LOGICAPP_INPROC_REDIRECTは秘密情報ではありませんが、アプリ設定には接続文字列やキーが含まれることがあります。設定の一覧を共有する場合は、値をマスクし、キー名と有無だけを共有する運用にしてください。
監査ログとアラートを整備する
設定変更の監査では、Azure Activity Logを必ず確認対象にします。Azure MonitorのActivity Logは、リソースの作成、更新、削除、デプロイエラーなどの管理操作を記録し、既定で収集されます。保持期間は90日で、それ以上の長期保管が必要な場合は診断設定でLog Analytics、Storage Account、Event Hubsなどに送る設計が必要です。(Microsoft Learn)
少なくとも、次のイベントを追跡できるようにしておきます。
| 監査対象 | 見るべき内容 |
|---|---|
| アプリ設定変更 | Microsoft.Web/sites/config系のWrite操作、変更者、時刻 |
| Logic App再起動 | 再起動の実行者、実行タイミング |
| デプロイ | ARM/Bicep、Zip Deploy、パイプライン実行履歴 |
| RBAC変更 | ロール割り当ての追加・削除 |
| 診断設定変更 | ログ転送先の変更、無効化 |
| アラート変更 | 重要アラートの削除・無効化 |
監査の目的は、犯人探しではありません。移行後に障害が起きたとき、「何がいつ変わったか」を短時間で特定するためです。特にOut-of-Proc移行では、再起動や設定変更のタイミングが原因調査の起点になります。
NuGetベースのLogic Appsで必要な移行準備
NuGetベースのデプロイを使っている場合、Microsoftは次の準備を案内しています。
| 手順 | 内容 | 管理者の確認ポイント |
|---|---|---|
| 最新のAzure Functions Core Toolsを取得 | ローカル検証環境を更新する | 開発端末、ビルドエージェントのバージョンをそろえる |
| プロジェクト構成をOut-of-Proc hosting model向けに更新 | プロジェクト設定や依存関係を見直す | リポジトリ差分をレビューする |
| ローカルで検証 | デプロイ前にワークフロー実行を確認する | 接続先、環境変数、ログ出力を確認する |
| デプロイプロセスを更新 | CI/CDが新構成に対応するよう修正する | LOGICAPP_INPROC_REDIRECTを誤って削除しない |
| 準備完了後にリダイレクト設定を削除 | Out-of-Procへ移行可能にする | Microsoftの追加ガイダンス確認後に実施する |
公式発表では、NuGetベースのアプリについては、必要なLogic Apps runtime package guidanceとサポートされる移行手順が確認された時点で別途案内するとされています。そのため、ローカル検証に成功しただけで本番のLOGICAPP_INPROC_REDIRECTを削除するのは避け、公式ガイダンス、検証結果、切り戻し手順がそろってから判断するのが安全です。(TECHCOMMUNITY.MICROSOFT.COM)
移行前後のテスト観点
Out-of-Procへの移行では、単にワークフローが起動するかだけでなく、依存関係、ログ、例外処理、パフォーマンスを確認する必要があります。
| テスト観点 | 確認する内容 | よくある見落とし |
|---|---|---|
| トリガー | HTTP、スケジュール、Service Bus、Storageなどが想定どおり起動するか | 検証環境でイベントが流れていない |
| コネクタ | 認証、接続、再試行、タイムアウト | 接続先のIP制限やPrivate Endpoint |
| カスタムコード | 依存パッケージ、ターゲットフレームワーク、例外処理 | NuGet依存関係のバージョン差 |
| アプリ設定 | 環境変数、Key Vault参照、接続文字列 | 本番だけ設定名が違う |
| host.json | 並列度、タイムアウト、ログ設定 | 検証環境と本番の差分 |
| 監視 | Application Insights、Run history、メトリック | 移行後にログ粒度が変わったように見える |
| 性能 | コールドスタート、実行時間、スループット | 初回だけ遅い挙動を障害と誤認する |
| 切り戻し | 設定再適用、再起動、パイプライン戻し | 誰が実行するか決まっていない |
Azure Functionsのisolated worker modelでは、アプリがホストとは別プロセスで動くため、起動処理や依存性注入、ミドルウェアなどをアプリ側で制御しやすくなります。一方で、その分だけプロジェクト構成や起動処理の確認が重要になります。(Microsoft Learn)
周知すべき相手と伝える内容
今回のNoticeは、開発者だけでなく、運用管理者、セキュリティ担当、業務部門にも関係します。特に本番ワークフローが販売、請求、通知、データ連携などに使われている場合、影響の説明を先にしておくと混乱を避けられます。
開発チームに伝えること
開発チームには、技術的な変更点と作業依頼を明確に伝えます。
Logic Apps Standardの.NET 10対応準備として、In-ProcからOut-of-Proc hosting modelへの移行が予定されています。
NuGetベースのデプロイを使うアプリは例外対応が必要になる可能性があります。
確認してほしいこと:
- 対象Logic AppがNuGetベースのデプロイか
- ローカル検証に必要なAzure Functions Core Toolsの更新
- プロジェクト構成のOut-of-Proc対応
- CI/CDでLOGICAPP_INPROC_REDIRECT=1を保持できるか運用チームに伝えること
運用チームには、変更監視と復旧手順を中心に伝えます。
LOGICAPP_INPROC_REDIRECT=1が削除されると、再起動時にOut-of-Procへの移行が進む可能性があります。
本番環境では、設定変更・デプロイ・再起動の前後でActivity Logと実行履歴を確認してください。
監視対象:
- アプリ設定変更
- Logic App再起動
- デプロイ履歴
- 失敗したワークフロー実行
- Application Insightsの例外増加業務部門に伝えること
業務部門には、技術用語を減らして、業務影響と連絡ルートを伝えます。
Microsoftの基盤更新に伴い、一部の自動処理ワークフローで事前検証を行います。
多くの処理は自動的に更新されますが、重要な連携については検証環境で確認後、本番反映します。
業務側にお願いしたいこと:
- 重要な処理時間帯の共有
- 停止できない期間の共有
- 異常時の連絡先確認失敗しやすいポイント
「自動移行だから放置」で進めてしまう
多くの環境で自動移行されることと、すべての環境で確認不要であることは別です。NuGetベースのデプロイという例外が明記されているため、最低限の棚卸しは必要です。
CI/CDがLOGICAPP_INPROC_REDIRECTを消してしまう
Microsoftが例外アプリにフラグを追加しても、その後のデプロイで設定が消えれば意味がありません。設定をAzureポータルで確認するだけでなく、パイプラインがその設定を保持するかまで確認してください。
検証環境と本番環境の差分を見落とす
Logic Apps Standardでは、アプリ設定、host.json、接続情報、ネットワーク、マネージドID、Key Vault参照などが環境ごとに異なることがあります。検証環境で成功しても、本番だけ接続先の制限や権限不足で失敗することがあります。
監査ログの保持期間を過信する
Activity Logは既定で利用できますが、保持期間は90日です。監査要件や障害調査で長期保管が必要な場合は、診断設定でLog AnalyticsやStorage Accountに送る設計を事前に行ってください。(Microsoft Learn)
.NET 10対応と今回の移行を同一視する
今回の案内は.NET 10対応に向けた道筋であり、Logic Apps runtimeやworkflow versionの.NET 10対応詳細は別途案内されるとされています。すぐに.NET 10へ上げる話ではなく、まずホスティングモデル移行に備える話として整理してください。(TECHCOMMUNITY.MICROSOFT.COM)
管理者が次に行うべきこと
まずは、サブスクリプション内のLogic Apps Standardを一覧化し、NuGetベースのデプロイを使っているアプリを特定してください。次に、対象アプリのLOGICAPP_INPROC_REDIRECT=1が保持されるよう、CI/CD、Bicep、ARM、スクリプト、手動運用を確認します。そのうえで、Activity Logと診断設定を見直し、誰がいつアプリ設定を変更したか追跡できる状態にします。
今回の変更は、すぐに全環境で大規模な改修が必要という話ではありません。しかし、例外環境を見落とすと、再起動やデプロイのタイミングで意図せず移行が進む可能性があります。管理者は「対象の棚卸し」「設定保持」「権限と監査」「検証と周知」を先に済ませ、Microsoftの追加ガイダンスが出た段階で安全に移行判断できる状態を作っておくことが重要です。
コメント