Azure Functionsの「Updating prerelease feed」は、既存のFunction Appが突然アップグレードされる変更ではありません。結論から言うと、Visual Studio、Visual Studio Code、Azure Functions Core Toolsなどが参照するプリリリース向けツールフィードの更新であり、影響を受けやすいのは「プレビュー機能を試す開発者」「新規プロジェクト作成テンプレートを使うチーム」「ローカル開発環境やCIでCore Toolsのバージョン差を厳密に管理している管理者」です。
今回の更新では、Azure Functions tooling feedのPR「Updating prerelease feed」がマージされ、v4-prereleaseの参照先が4.126.0から4.127.0へ、v0-prereleaseの参照先が4.126.0-inprocessから4.127.0-inprocessへ更新されました。通常のGA運用だけをしている場合は慌てて本番設定を変更する必要はありませんが、プレビュー系フィードや新しい.NETテンプレートを使っている環境では、Core Tools、SDK、ターゲットフレームワーク、ネットワーク許可設定を確認しておくべき更新です。(GitHub)
Azure Functionsの「Updating prerelease feed」は何が変わったのか
「Azure Functions documentation update: Updating prerelease feed」という名前だけを見ると、単なるドキュメント修正のように見えます。実際には、Azure Functionsのローカル開発ツールやテンプレート選択に関わるtooling feedのJSON更新です。
Azure/azure-functions-tooling-feedリポジトリの説明では、このフィードはVisual Studio、Visual Studio Code、その他のツールが最新のCore Toolsと対応テンプレートを使うために消費するメタデータとして位置付けられています。フィードには、リリースタグ、リリース品質、テンプレート、Core ToolsのダウンロードURL、SHA2などが含まれます。(GitHub)
今回のPRで確認できる主な変更は次の通りです。
| 変更項目 | 更新内容 | 実務上の意味 |
|---|---|---|
v4-prerelease | 4.126.0から4.127.0へ変更 | 標準のv4プリリリース系ツール・テンプレートの参照先が更新される |
v0-prerelease | 4.126.0-inprocessから4.127.0-inprocessへ変更 | in-process向けと思われるプリリリース系エントリも更新される |
| 新規リリースエントリ | 4.127.0と4.127.0-inprocessを追加 | 新しいテンプレート、SDK指定、Core Toolsパッケージ情報が追加される |
| Core Toolsリンク | 標準側はAzure Functions CLI 4.11.0、in-process側は_inproc付きCLI 4.5.0のパッケージを参照 | ローカル実行やテンプレート生成時のツール差分に注意が必要 |
releaseQuality | Prerelease | GAではなく、検証用途として扱うべき更新 |
hidden | true | 一般ユーザー向けに明示表示される通常リリースではない |
ここで重要なのは、4.127.0というフィード上のリリースIDと、Azure Functions Core Tools本体のバージョンが同じ意味ではない点です。今回の差分では、フィードのリリースIDは4.127.0ですが、Core ToolsのダウンロードリンクにはAzure Functions CLI 4.11.0が含まれています。バージョン番号だけを見て「Core Toolsが4.127.0になった」と判断しないようにしましょう。(GitHub)
既存のAzure Functions本番環境にすぐ影響するのか
多くの本番環境では、今回の更新だけでFunction Appの実行ランタイムや言語バージョンが自動的に切り替わるわけではありません。
Azure上のFunction Appは、FUNCTIONS_EXTENSION_VERSION、FUNCTIONS_WORKER_RUNTIME、Windows/Linuxのスタック構成、linuxFxVersion、プロジェクト側のTargetFrameworkや依存パッケージなどによって実行環境が決まります。Microsoft Learnでは、FUNCTIONS_EXTENSION_VERSION=~4はFunctions 4.xの最新メジャー系で実行することを示す設定として説明されています。(Microsoft Learn)
一方で、ローカル開発や新規プロジェクト作成では影響が出る可能性があります。たとえば、Visual StudioやVS Code拡張機能がプリリリースフィードを参照している場合、新規作成時のテンプレート、既定の.NETモデル、Core Toolsの取得先が変わることがあります。
影響を整理すると、次のようになります。
| 利用状況 | 影響の可能性 | 確認すべきこと |
|---|---|---|
| 本番Function Appを通常のGA構成で運用している | 低い | FUNCTIONS_EXTENSION_VERSION、言語スタック、デプロイ履歴を確認 |
| Visual Studio/VS CodeでAzure Functionsのプレビュー機能を試している | 中〜高 | 新規作成テンプレート、Core Toolsのバージョン、生成される.csprojを確認 |
CIでfuncコマンドを使ってビルド・デプロイしている | 中 | CI上のfunc --version、インストール元、キャッシュを確認 |
| .NET in-processモデルを使っている | 中〜高 | Microsoft.NET.Sdk.Functions、.NET 8 in-process設定、移行計画を確認 |
| 社内プロキシやFirewallで外部通信を制限している | 中 | cdn.functions.azure.comやNuGet取得先への通信可否を確認 |
開発者が特に確認すべき.NET関連の変更
今回のフィード差分では、.NET isolatedと.NET in-processの両方に関わる情報が含まれています。
標準側の4.127.0には、.NET 8 isolatedが既定として設定され、.NET 10 isolatedのエントリも含まれています。in-process側の4.127.0-inprocessでは、.NET 8が既定として設定され、FUNCTIONS_INPROC_NET8_ENABLED=1も含まれています。(GitHub)
ただし、ここで注意すべきなのは「フィードにエントリがある」ことと「自分の本番アプリで今すぐ採用すべき」ことは別だという点です。
Microsoft Learnのサポート言語情報では、.NETのサポートはFunctionsランタイムのバージョンと実行モデルによって異なり、in-processモデルは2026年11月10日にサポート終了予定とされています。また、isolated worker modelでは.NET 8、.NET 9、.NET 10などのサポート情報が示されています。(Microsoft Learn)
.NET isolatedを使っている場合
.NET isolatedを使っている開発者は、次の点を確認してください。
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
| ターゲットフレームワーク | .csprojの<TargetFramework> | net8.0、net9.0、net10.0など、実行環境と一致しているか |
| Worker SDK | Microsoft.Azure.Functions.Worker.Sdk | 対象.NETバージョンをサポートするバージョンか |
| Functions Worker | Microsoft.Azure.Functions.Worker | 古いバージョンのままになっていないか |
| Azure側スタック | Portalの構成、またはAzure CLI | ローカルで使う.NETとAzure側のスタックが一致しているか |
| ホスティングプラン | Consumption、Flex Consumption、Premium、Dedicated | 新しい言語バージョンがそのプランで使えるか |
特に.NET 10を検証する場合は、単にローカルでビルドが通るだけでは不十分です。Azure側のホスティングプラン、Linux/Windows、デプロイスロット、CIのSDKバージョンまで揃えて確認する必要があります。
.NET in-processを使っている場合
in-processモデルを使っている場合は、今回のプリリリースフィード更新を「短期的なテンプレート確認」だけでなく「移行計画を見直すきっかけ」として扱うのが現実的です。
Microsoft Learnでは、in-processモデルのサポート終了予定が明記されており、継続的なフルサポートのためにはisolated worker modelへの移行が推奨されています。(Microsoft Learn)
in-processで確認すべきポイントは次の通りです。
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>
</PropertyGroup><ItemGroup>
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.5.0" />
</ItemGroup>Core Toolsの公式ドキュメントでは、Core Tools 4.0.6517以降、in-processモデルのプロジェクトはMicrosoft.NET.Sdk.Functions 4.5.0以降を参照する必要があり、古いバージョンではfunc startがエラーになると説明されています。(Microsoft Learn)
管理者が確認すべきローカル開発環境とCIの設定
今回のようなプリリリースフィード更新でトラブルが起きやすいのは、本番アプリそのものよりも、開発者PCやCI/CD環境です。
代表的な失敗パターンは次の3つです。
1つ目は、開発者ごとにAzure Functions Core Toolsのバージョンが違うケースです。ある開発者のPCでは新しいテンプレートで作成され、別の開発者のPCでは古いテンプレートが使われると、.csproj、SDK、local.settings.json、host.jsonの差分が混在します。
2つ目は、CIだけ古いfuncコマンドを使っているケースです。ローカルではビルドできるのに、GitHub ActionsやAzure Pipelinesではfunc azure functionapp publishやfunc packで失敗することがあります。
3つ目は、社内ネットワークでCDNやNuGetの取得先がブロックされるケースです。今回の差分には、cdn.functions.azure.com配下のCore Toolsパッケージや、NuGet上のテンプレートパッケージへの参照が含まれています。プロキシ、SSLインスペクション、Firewallを使っている企業では、開発者だけでなくネットワーク管理者の確認も必要です。(GitHub)
まず実行すべき確認コマンド
ローカルでは、まずCore Toolsのバージョンを確認します。
func --versionMicrosoft Learnでも、現在インストールされているCore Toolsのバージョン確認コマンドとしてfunc --versionが案内されています。(Microsoft Learn)
Azure上のFunction App設定は、次のように確認できます。
az functionapp config appsettings list \
--name "<FUNCTION_APP_NAME>" \
--resource-group "<RESOURCE_GROUP_NAME>" \
--query "[?name=='FUNCTIONS_EXTENSION_VERSION' || name=='FUNCTIONS_WORKER_RUNTIME' || name=='FUNCTIONS_INPROC_NET8_ENABLED']"Linuxアプリのスタック候補を確認する場合は、次のようなコマンドも役立ちます。
az functionapp list-runtimes \
--os linux \
--query "[?runtime == 'dotnet-isolated'].{Version:version, linuxFxVersion:linux_fx_version}" \
--output tableMicrosoft Learnでは、Azure CLIのaz functionapp list-runtimesやaz functionapp config setを使って、サポートされるランタイム値の確認やスタック更新を行う手順が紹介されています。(Microsoft Learn)
移行・展開前に確認すべきチェックリスト
今回の更新を受けて新しいテンプレートやCore Toolsを使う場合は、すぐ本番に反映するのではなく、次の順序で確認してください。
| 手順 | 作業 | 失敗しやすいポイント |
|---|---|---|
| 1 | ローカルのfunc --versionを確認する | 開発者PCとCIでCore Toolsのバージョンが違う |
| 2 | .csprojのTargetFrameworkとSDKを確認する | net8.0なのに古いWorker SDKを使っている |
| 3 | host.jsonの拡張バンドルを確認する | 古いExtension Bundleで新しいバインディングや言語バージョンに対応できない |
| 4 | local.settings.jsonを確認する | FUNCTIONS_WORKER_RUNTIMEがプロジェクト種別と合っていない |
| 5 | Azure側のスタック構成を確認する | Portal上の言語バージョンとCIのビルドターゲットがずれる |
| 6 | ステージングスロットで起動確認する | 本番直反映でロールバック手順がない |
| 7 | ログと依存関係を確認する | 起動失敗時にパッケージ、バインディング、ランタイムのどれが原因か切り分けできない |
Microsoft Learnでは、言語バージョン更新前に拡張バンドル、バインド拡張機能、パッケージ依存関係、ローカルツールを確認し、新しいターゲットバージョンでローカルテストすることが推奨されています。さらに、ダウンタイムを抑え、ロールバックしやすくするためにステージングスロットでの検証も推奨されています。(Microsoft Learn)
Visual StudioやVS Codeで新規作成する場合の注意点
Azure Functionsの新規プロジェクト作成では、テンプレートの差分が意外と大きな影響を持ちます。
たとえば、同じ「HTTP trigger」を作るだけでも、選択した実行モデルがisolatedかin-processか、ターゲットが.NET 8か.NET 10か、生成されるパッケージ参照が古いか新しいかによって、CI、デプロイ方法、将来のサポート方針が変わります。
新しいテンプレートを使うときは、作成直後に次を確認してください。
dotnet --info
func --versiondotnet list package.csprojでは、少なくとも次の3点を見ます。
<TargetFramework>net8.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion><PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="..." />
<PackageReference Include="Microsoft.Azure.Functions.Worker" Version="..." />in-processの場合は、次のような参照も確認対象です。
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.5.0" />ポイントは、IDEで作成できたかどうかではなく、チームの標準ランタイム、Azure側の構成、CI/CDのビルド環境と一致しているかです。テンプレートが新しくなるほど、古い社内手順書やCIテンプレートとのズレが起きやすくなります。
Core Tools 4.11.0を使う場合に見ておきたい修正点
今回のプリリリースフィードには、Azure Functions CLI 4.11.0のパッケージリンクが含まれています。Core Tools 4.11.0のリリースノートでは、func packでlocal.settings.jsonがない場合の分かりにくいエラー改善、Node.js 24のGA反映、SSL/TLS証明書エラーの明確化、Kubernetesデプロイ・削除関連の修正、McpPromptTriggerテンプレート追加、Storage接続文字列取得時の修正などが挙げられています。(GitHub)
特に企業環境で重要なのは、SSL/TLS証明書エラーの明確化です。社内プロキシやSSLインスペクションがある環境では、Core ToolsがCDNやAzure APIに接続する際に証明書周りで失敗することがあります。今回の修正により、原因の切り分けがしやすくなる可能性があります。
ただし、Core Toolsを更新する場合も、すべての開発者PCに一斉反映する前に、代表的なFunction Appで次を確認してください。
func start
func new
func pack
func azure functionapp publish <FunctionAppName>KubernetesやAzure Container Appsにデプロイしている場合は、デプロイコマンドの挙動も確認しておくと安心です。Core Toolsの公式ドキュメントでは、Core Toolsを使ってプロジェクトファイル、Azure Container Apps、Kubernetesクラスターへのデプロイができると説明されています。(Microsoft Learn)
本番反映で避けたい判断ミス
今回の「Updating prerelease feed」で最も避けたいのは、プリリリースフィードの更新を本番ランタイムの強制変更と誤解することです。
やってはいけない判断は次の通りです。
| 避けたい判断 | なぜ危険か | 正しい対応 |
|---|---|---|
4.127.0をCore Tools本体のバージョンだと思う | フィードのリリースIDとCLIバージョンは別物 | func --versionとリリースノートで確認する |
フィードに.NET 10があるので即本番採用する | ホスティングプランやCI、依存パッケージが未対応の可能性がある | ステージングスロットや検証用Function Appで確認する |
| in-processの新テンプレートだけで長期運用を決める | in-processモデルにはサポート終了予定がある | isolated worker modelへの移行計画を立てる |
| 開発者PCだけ更新してCIを放置する | ローカルとCIで生成物やデプロイ結果が変わる | CI上のCore Tools、.NET SDK、Node/Python等も固定・確認する |
| CDNやNuGet通信を確認しない | テンプレート取得やCore Tools取得が失敗する | Proxy、Firewall、SSLインスペクションの許可設定を確認する |
どのチームが対応すべきか
すべてのAzure Functions利用者が緊急対応する必要はありません。優先度を付けるなら、次の順番で確認すると効率的です。
| 優先度 | 対象 | 理由 |
|---|---|---|
| 高 | プレビュー版テンプレートやプリリリースフィードを使う開発チーム | 今回の変更を直接受けやすい |
| 高 | .NET in-processモデルのFunction Appを運用しているチーム | サポート終了予定とSDK要件の確認が必要 |
| 中 | Core ToolsをCI/CDで使っているチーム | ローカルとCIの差分がデプロイ失敗につながる |
| 中 | Visual Studio/VS Codeで新規Azure Functionsプロジェクトを頻繁に作るチーム | テンプレート差分がプロジェクト標準に影響する |
| 低 | 既存Function AppをGA構成で安定運用し、新規作成やツール更新をしていないチーム | 直ちに本番へ反映される変更ではない |
よくある疑問
Azure Functionsの実行ランタイムが勝手に変わるのですか
通常は変わりません。今回の更新はプリリリース向けtooling feedの更新であり、既存のAzure上のFunction App設定を直接書き換えるものではありません。実行ランタイムは、FUNCTIONS_EXTENSION_VERSIONや言語スタック、ホスティングプラン、プロジェクト構成によって決まります。(Microsoft Learn)
v4-prereleaseを使うべきですか
本番用途では、明確な検証目的がない限りプリリリースフィードを常用しない方が安全です。releaseQualityがPrereleaseで、hiddenもtrueになっているため、通常のGAリリースとは切り分けて扱うべきです。(GitHub)
.NET 8 isolatedと.NET 8 in-processはどちらを選ぶべきですか
新規開発では、長期的にはisolated worker modelを優先して検討するのが現実的です。Microsoft Learnではin-processモデルのサポート終了予定が示され、isolated worker modelへの移行が推奨されています。既存のin-processアプリは、機能差分や移行工数を評価したうえで段階的に移行計画を立てましょう。(Microsoft Learn)
まず何を確認すればよいですか
最初に確認するのは、開発者PCとCIのfunc --version、プロジェクトのTargetFramework、Azure側のFUNCTIONS_EXTENSION_VERSION、FUNCTIONS_WORKER_RUNTIMEです。次に、ステージングスロットまたは検証用Function Appでfunc start、ビルド、デプロイを確認してください。
まとめ：今回の更新は「本番即対応」より「開発環境の差分確認」が重要
Azure Functionsの「Updating prerelease feed」は、Azure上の本番Function Appを即座に変更する更新ではなく、プリリリース向けのツールフィード、テンプレート、Core Tools参照先を更新するものです。
管理者と開発者が取るべき行動は明確です。
まず、プリリリースフィードを使っているかを確認します。次に、開発者PCとCIのCore Toolsバージョンを揃えます。そのうえで、.csproj、SDK、FUNCTIONS_EXTENSION_VERSION、FUNCTIONS_WORKER_RUNTIME、Azure側のスタック構成を確認し、必要ならステージングスロットで検証します。
特に.NET in-processを使っているチームは、今回の更新を単なるテンプレート差分として見過ごさず、isolated worker modelへの移行計画も合わせて見直すのがおすすめです。新しいフィードを使う前に、ローカル、CI、Azure本番の3点でバージョンと構成をそろえることが、Azure Functions運用での不要なデプロイトラブルを防ぐ近道です。
コメント