社内バッチ処理や外部システム連携のトリガー起点として、Azure Functionsを長年運用してきた企業のアプリケーション基盤担当者は多い。中でも、.NET Frameworkで書かれたv1.xランタイムのFunctionsや、in-processモデル（Functionsホストと同一プロセスでコードを実行する方式）で動くC#アプリを、作った当時のまま塩漬けにしている現場は少なくない。
Microsoftは、Azure Functionsランタイムv1.x（.NET Framework 4.8.1を使うC#アプリ専用）のサポートを2026年9月14日に終了する[1]。さらに、v4.xランタイムの中でもin-processモデルのサポートは2026年11月10日に終了する[1]。いずれも移行先はisolated workerモデル（別プロセスでコードを実行する方式）で、コード変更を伴う[2]。
v1.xの期限まで2週間を切った今、必要なのは「サポート切れがすぐに停止を意味するわけではない」ことを踏まえた優先順位の判断だ。本稿では、何がいつ終わるのか、実務上何をすべきか、そして日本企業の保守体制でこの種の期限をどう扱うべきかを整理する。
予備知識
- in-processモデル: Functionsのホストプロセスと同じプロセス内でユーザーのコードを実行する方式。C#の旧来の標準的な作り方。
- isolated workerモデル: ユーザーのコードを別プロセスで実行する方式。.NETのバージョンアップに追従しやすく、Microsoftが現在推奨する構成。
- LTS（Long Term Support）: 長期サポート版を指す。.NET 8はLTSとして2026年11月10日までサポートされる[1]。
- FUNCTIONS_EXTENSION_VERSION: Functionsアプリがどのランタイムバージョンで動くかを決めるアプリケーション設定。
移行前にAzure Functionsのトリガー・バインディングの基本を体系的に再確認したい担当者向け。
現状分析：何が、いつ終わるのか
対象は2つある。1つ目はランタイムv1.x自体で、.NET Framework 4.8.1を使うC#アプリのみが対象になる。サポート終了日は2026年9月14日だ[1]。2つ目はv4.xランタイムのin-processモデルで、.NET 8（LTS）を使うアプリが対象になる。こちらのサポート終了日は2026年11月10日だ[1]。両者はランタイムのメジャーバージョンが違うだけで、実行モデルとしては別の軸にある。
サポート終了後の挙動について、Microsoftは既に廃止済みのv2.x・v3.xについては「CI/CDパイプラインからのデプロイは可能で、既存アプリは破壊的変更なく動き続ける。ただし新機能・セキュリティパッチ・パフォーマンス最適化の対象外になる」と明記している[1]。一方、v1.xとin-processモデルの終了後の挙動について同種の記述は公開ドキュメントに見当たらない。過去の廃止と同じ扱いになる可能性は高いが、「終了＝即停止ではない」と断定できる根拠は現時点では確認できていない。なお、v2.x・v3.xは既に2022年12月13日に延長サポートも終了済みで、特にLinux Consumption プランでv3を使うアプリは2026年9月30日以降起動できなくなる[1]。今回のv1.x・in-process終了は、この一連のEOLサイクルの延長線上にある。
isolated workerモデルへの移行先となるモダンな.NETの基本を、.NET Frameworkとの違いを踏まえて学べる一冊。
解決の方向性：isolated workerモデルへの移行アーキテクチャ
Microsoftが推奨する移行先は、v1.x・in-processモデルのいずれも同じくisolated workerモデルだ。isolated workerモデルは、Functionsのホストとは別プロセスでユーザーコードを実行するため、.NETのバージョンアップに合わせてアプリ側を個別に更新でき、依存関係の衝突も起きにくい。isolated workerモデルでは.NET 8・9・10に加え、.NET Framework 4.8.1もサポート対象に含まれるため[1]、.NET Framework資産をすぐに全面書き換えできない場合でも移行の選択肢がある。
移行作業の中心は、プロジェクトファイル（.csproj）のターゲットフレームワークとAzureFunctionsVersion指定の変更、そしてトリガー・バインディングの記述方法の書き換えだ[2]。v1.xからの移行はv4.xへの直接アップグレードとなり、.NET Frameworkのままisolated workerモデルへ移す経路と、.NET 8以降へフル移行する経路の両方が選べる[2]。
| 現状 | 移行先 | 主な変更点 |
|---|---|---|
| v1.x（.NET Framework、in-process相当） | v4.x isolated worker（.NET Framework 4.8.1のまま可） | ランタイムバージョン指定とトリガー記述の書き換え |
| v4.x in-process（.NET 8） | v4.x isolated worker（.NET 8/9/10） | プロセスモデルの変更、依存パッケージの見直し |
数百のWebアプリをAzure App Serviceで運用し、年次のセキュリティ監査を受ける企業のプラットフォーム担当者は、2026年後半に複数のランタイムが立て続けにサポート終了を迎える事態に向き合うことになる。対象はAzure Ap[…]
具体施策：優先順位付けと検証手順
社内で運用しているFunctionsアプリの一覧を作り、ランタイムバージョンと実行モデルを棚卸しするのが最初の一歩だ。FUNCTIONS_EXTENSION_VERSIONアプリケーション設定を確認すれば、対象アプリを機械的に洗い出せる[1]。次に、v1.x対象アプリを最優先（期限が2週間後）、in-process対象アプリを次点（期限が2ヶ月後）として順位付けする。
移行後は、検証環境でトリガーの発火・バインディングの入出力・依存パッケージの互換性を確認してから本番へ反映する。isolated workerモデルはプロセス分離の影響で、環境変数の参照方法やミドルウェアの登録方法がin-processモデルと異なるため、単純な設定変更だけでは動かないケースがある点に注意が必要だ。
Microsoft Entra ID（旧Azure AD）の動的メンバーシップグループで部署や役職ごとにTeamsとSharePointの権限を配り、年1回の内部監査でアクセス権の棚卸し証跡を求められている。数千人規模の企業でID基盤を預[…]
塩漬けFunctionsアプリが多い日本企業の棚卸し課題
海外の開発チームは、リポジトリのCI設定やIaC（Infrastructure as Code）定義からランタイムバージョンを機械的に検出しやすい体制を持つことが多い。一方、日本企業では、部門ごとに個別発注したツールとしてFunctionsアプリが乱立し、開発を担当したSIerや担当者が既に離任しているケースが珍しくない。ソースコード自体は残っていても、どのアプリがどのランタイムで動いているかを一元的に把握できていない状況が起きやすい。
内部統制の観点でも、部門が個別に構築したFunctionsアプリは、全社的なIT資産台帳に載っていないことがある。今回のような期限付きのランタイム終了は、こうした「見えていない資産」を洗い出す契機にもなるが、洗い出し自体に時間がかかり、期限に間に合わない懸念がある。
| 観点 | 海外の典型的な動き | 日本企業で起きやすいこと |
|---|---|---|
| 資産の把握 | IaC定義やCIパイプラインから機械的に検出 | 部門ごとの個別発注で全社台帳に未反映のことがある |
| 移行の実行主体 | 開発チームが自律的に対応 | SIerへの追加発注が必要になることが多い |
| 期限管理 | ベンダーの非推奨アナウンスを自動監視 | 情シス部門が個別に情報を追いかける必要がある |
IT部門担当者の次の一手は、FUNCTIONS_EXTENSION_VERSIONを軸にした全社的なFunctionsアプリの棚卸しだ。決裁側の判断材料は、棚卸しと移行にかかる追加のSIer発注費用を、通常の保守契約の範囲内で吸収できるか、緊急予算が必要かの見極めになる。
まとめ
Azure Functionsのv1.xは2026年9月14日、in-processモデルは2026年11月10日にサポートが終了する[1]。いずれもisolated workerモデルへの移行が推奨経路だ[2]。9月14日の期限まで残りわずかである以上、全アプリの移行を間に合わせるより、対象の特定と影響度の切り分けを先に終えるほうが現実的だ。過去の廃止バージョンの扱いから見れば猶予はあると考えられるが、公開ドキュメントでそれが保証されているのはv2.x・v3.xについてだけであり、猶予を前提に「対応不要」と読み違えないことが重要だ。
よくある質問（FAQ）
Q. サポートが切れたら、Functionsアプリはすぐに動かなくなるのか？
A. 過去に廃止されたv2.x・v3.xについては、Microsoftが「デプロイ・実行を継続できる」と明記している[1]。ただしv1.x・in-processの終了後の挙動について同じ記述は公開ドキュメントにない。いずれの場合も新機能・セキュリティパッチ・パフォーマンス改善の対象外になり、関連サービスサポートを受けるにはバージョンアップが前提になる[1]。
Q. 自社のFunctionsアプリがv1.xかin-processか、どう確認すればよいか？
A. アプリケーション設定のFUNCTIONS_EXTENSION_VERSIONを確認する。~1はv1.x、~4はv4.xを示す。in-process/isolated workerの別は、プロジェクトのSDK参照やホスティングモデルの設定から確認できる。
Q. isolated workerモデルへの移行は必ず.NET Frameworkから.NET 8以降への書き換えが必要か？
A. 必須ではない。isolated workerモデルは.NET Framework 4.8.1もサポート対象に含むため、実行モデルだけを先に移行し、.NETバージョン自体のアップグレードは段階的に行う選択肢もある。
出典
[1] https://learn.microsoft.com/en-us/azure/azure-functions/functions-versions[2] https://learn.microsoft.com/en-us/azure/azure-functions/migrate-version-1-version-4
