Azure Functions Core Tools 4.11.0の変更点と影響範囲を解説

Azure Functionsの「Azure Functions documentation update: Release prep 4.11.0」は、Azure上のFunction Appランタイムを大きく変える更新ではなく、主にAzure Functions Core Toolsの4.11.0リリース準備に関する変更です。結論から言うと、Core Toolsのバージョン表記が4.10.0から4.11.0へ更新され、リリースノートの見出しも4.11.0に変わりました。一方で、PR上ではHost versionは変更なしと明記されています。ローカル開発、CI/CD、func publishやfunc packを使うチームは、実行環境のCore Toolsバージョンとデプロイ手順を確認しておくべき更新です。(GitHub)

Azure Functions documentation update: Release prep 4.11.0でまず押さえるべき結論

今回の更新は、Azure Functions Core Toolsのリリース準備PRとして、2026年5月20日にAzure公式GitHubリポジトリのmainブランチへマージされたものです。PRの変更内容は非常に小さく、Directory.Version.propsのVersionPrefixを4.10.0から4.11.0へ変更し、release_notes.mdの見出しをAzure Functions CLI 4.11.0へ更新する内容でした。コミット上の差分も2ファイル、2行追加・2行削除に限られています。(GitHub)

実務上のポイントは、「Azure Functionsのホストランタイム更新」と「Core ToolsのCLI更新」を混同しないことです。Core Toolsはローカル開発、テンプレート生成、パッケージ作成、発行、設定操作などに使うCLIツールです。Microsoft Learnでも、Core Toolsはローカルで関数を開発・テストし、準備ができたらAzureへデプロイしたりアプリケーション設定を操作したりするためのツールと説明されています。(Microsoft Learn)

確認項目	今回の内容	実務上の見方
Core Toolsのバージョン	4.10.0 → 4.11.0	ローカルPC、ビルドエージェント、開発コンテナーのCLI更新対象
リリースノート	見出しをAzure Functions CLI 4.11.0へ変更	ドキュメント・リリース管理上の更新
Host version	PR上は変更なし	Function Appのランタイム移行作業とは切り分けて判断
変更ファイル	release_notes.md、src/Cli/func/Directory.Version.props	アプリコードやhost.jsonへの直接変更ではない
差分規模	2ファイル、2行追加・2行削除	大規模な破壊的変更を示すPRではない

4.11.0のリリースノート上で確認できる追加変更

リリース準備PRそのものはバージョン表記の更新が中心ですが、GitHubの4.11.0リリースページでは、Azure Functions CLI 4.11.0として複数の変更点も掲載されています。リリースページ上ではHost Runtime Versionは4.1048.200、In-Proc CLIはCLI Version 4.5.0、Host Runtime Version 4.48.100と記載されています。(GitHub)

リリースノート上の主な変更は、local.settings.jsonやFUNCTIONS_WORKER_RUNTIMEがない場合のfunc packエラー表示の改善、Node.js 24のスタック定義更新、SSL/TLS証明書エラーの明確化、func kubernetes deployとfunc kubernetes deleteの修正、dotnet-isolated向けMcpPromptTriggerテンプレート追加、Azure Storage接続文字列取得時のARM整合性に関する修正などです。(GitHub)

リリースノート上の変更	影響を受けやすい利用者	確認ポイント
func packのエラー改善	パッケージ化を自動化している開発者、CI担当者	FUNCTIONS_WORKER_RUNTIMEが明示されているか
Node.js 24のスタック定義更新	Node.js Functions、Flex Consumption検討中のチーム	Azureポータルや公式サポート表の反映状況も確認
SSL/TLS証明書エラーの明確化	企業プロキシ、SSLインスペクション環境	証明書エラーをネットワーク起因として切り分けやすくなる
Kubernetes deploy/delete修正	Kubernetes向けデプロイを使うチーム	kubectl rollout statusや--no-docker利用時の挙動を再検証
McpPromptTriggerテンプレート追加	dotnet-isolatedでMCP関連テンプレートを試す開発者	テンプレート追加であり、既存Function Appへの強制変更ではない
Storage接続文字列取得の修正	func azure storage fetch-connection-stringを使うチーム	作成直後のStorage Account参照エラーが改善される可能性

注意したいのは、Node.js 24についてです。4.11.0のリリースノートには「Node.js 24をGAとしてstacks.jsonに反映する」趣旨の変更が記載されていますが、Microsoft Learnのサポート言語ページでは、記事作成時点でNode.js 24がPreview、Node.js 22と20がGAとして掲載されています。運用環境でNode.js 24を採用する場合は、Core Tools側のスタック定義だけで判断せず、Azureポータル、サポート言語ページ、利用中のホスティングプランでの選択可否を合わせて確認してください。(GitHub)

影響範囲：Azure上の実行環境よりもローカル開発・CI/CDに注意

今回の更新で最も影響を受けるのは、Azure FunctionsをローカルやCI/CDで扱う環境です。Azure上で既に動作しているFunction Appが、Core Tools 4.11.0への更新だけで自動的にコード変更されたり、トリガー設定が書き換わったりするわけではありません。

一方で、Core Toolsはfunc start、func init、func new、func pack、func azure functionapp publish、設定取得・発行などに関わります。Microsoft Learnでも、Core ToolsのメジャーバージョンはAzure Functionsランタイムのメジャーバージョンにリンクしており、Core Tools 4.xはFunctions Runtime 4.xをサポートする推奨バージョンと説明されています。現在のCore Toolsバージョンはfunc --versionで確認できます。(Microsoft Learn)

対象	影響度	確認すべきこと
Azure上で稼働中のFunction App	低	FUNCTIONS_EXTENSION_VERSIONを不要に変更しない
ローカル開発PC	中	func --versionでCore Toolsのバージョンを確認
VS CodeでのAzure Functions開発	中	VS Code拡張とCore Toolsの組み合わせでfunc startが通るか確認
GitHub Actions / Azure Pipelines	中〜高	ビルドエージェント上のCore Toolsインストール方法とバージョン固定方針を確認
func publishによる手動・自動デプロイ	中	発行前後でアプリ設定、接続文字列、スロットを確認
Kubernetes向けデプロイ	高	4.11.0リリースノートのdeploy/delete修正に関係する手順を再テスト

管理者が確認すべき設定

Azure Functions管理者が最初に確認すべきなのは、Core Toolsの更新に合わせてFunction Appのランタイム設定を不用意に変更していないかです。Azure Functionsでは、Function AppのランタイムはFUNCTIONS_EXTENSION_VERSIONで制御されます。Microsoft Learnでは、メジャーバージョンだけを~4のように指定すると、新しいマイナーバージョンが利用可能になった際に自動更新されると説明されています。(Microsoft Learn)

今回のRelease prep 4.11.0はCore Tools側の更新であり、通常はFUNCTIONS_EXTENSION_VERSIONを4.11.0のように変える作業ではありません。FUNCTIONS_EXTENSION_VERSIONはAzure Functionsホストランタイムのターゲット設定であり、Core ToolsのCLIバージョン番号とは役割が異なります。特定のマイナーバージョンへのピン留めは、Microsoftやサポートから指示された場合など、明確な理由があるときに限定するのが安全です。Microsoft Learnも、可能な場合はサポートされている最新ランタイムで実行し、ピン留めは最新バージョンに問題がある場合などに限定する考え方を示しています。(Microsoft Learn)

管理者向けの確認コマンド例は次のとおりです。

az functionapp config appsettings list \
  --name <function_app_name> \
  --resource-group <resource_group_name> \
  --query "[?name=='FUNCTIONS_EXTENSION_VERSION' || name=='FUNCTIONS_WORKER_RUNTIME']"

LinuxのFunction Appでは、ランタイムや言語スタックの実体がlinuxFxVersionにも関係します。Core Tools 4.11.0へ更新しただけで、Node.js、Python、.NETなどのアプリ実行スタックを変更する必要はありません。言語バージョンを変える場合は、Core Tools更新とは別の変更として、ステージングスロットや検証環境でテストしてください。

開発者が確認すべきローカル環境

開発者は、まず自分のローカル環境で使っているCore Toolsのバージョンを確認します。

func --version

Core Toolsを更新する場合は、元のインストール方法と同じ方法で更新するのが原則です。Microsoft Learnでは、WindowsでMSIを使っていた場合は現在のMSIをアンインストールして最新MSIをインストールし、npmを使っていた場合はnpm installコマンドを再実行する、といった考え方が示されています。また、特定のコンピューターには1つのCore Toolsバージョンのみをインストールできる点にも注意が必要です。(Microsoft Learn)

環境	確認・更新の考え方
Windows MSI	旧MSIをアンインストールしてから最新のv4.xを導入
macOS Homebrew	azure-functions-core-tools@4を更新し、必要に応じてリンクを確認
Ubuntu / Debian	Microsoftパッケージリポジトリ経由でazure-functions-core-tools-4を更新
npm	既存のnpm導入手順を再実行し、PATH上のfuncが想定どおりか確認
Dev Container / Docker	イメージ内のCore Toolsバージョンを明示し、チームで再現性を確保

Windowsでは、複数のパッケージ管理ツールや古いPATH設定が原因で、更新したつもりでも別のfunc.exeが呼ばれることがあります。更新後はfunc --versionだけでなく、必要に応じて次のように実体の場所も確認してください。

where func
func --version

macOSやLinuxでは次のように確認できます。

which func
func --version

CI/CDでは「最新版を入れる」だけでなく再現性を確認する

CI/CDでAzure Functions Core Toolsを使っている場合、4.11.0への更新は開発PCよりも慎重に扱うべきです。ビルドエージェントが毎回最新のCore Toolsを取得する構成だと、ある日突然func packやfunc publishの挙動が変わり、ビルド結果の差分調査が難しくなります。

実務では、次の流れで確認すると安全です。

手順	内容	失敗しやすいポイント
現状確認	CIログにfunc --versionを出力する	どのバージョンで成功していたか分からない
検証環境で更新	4.11.0でfunc start、テスト、func packを実行	ローカルでは通るがCIで設定不足が出る
デプロイ検証	ステージングスロットや検証用Function Appへ発行	本番アプリ設定を上書きしてしまう
本番反映	成功したバージョンを明示して本番パイプラインへ反映	「latest」運用で再現性が落ちる
ロールバック方針	直前のCore Toolsバージョンへ戻せる手順を残す	CLI更新とアプリ変更を同時に行い、原因切り分け不能になる

特にfunc azure functionapp publishを使っている場合、--publish-local-settingsの扱いに注意してください。Microsoft Learnでは、プロジェクトをAzureへ発行してもローカル設定は既定では自動移行されず、必要に応じて--publish-local-settingsを使うこと、またConnectionStringsセクションの値は発行されないことが説明されています。(Microsoft Learn)

local.settings.jsonとFUNCTIONS_WORKER_RUNTIMEは必ず見直す

4.11.0のリリースノートには、local.settings.jsonがなく、FUNCTIONS_WORKER_RUNTIMEも未設定の場合にfunc packが分かりにくいUnsupported runtime: Noneエラーを出す問題の修正が含まれています。これはエラー表示の改善として有用ですが、根本的にはプロジェクト側でワーカーランタイムを明確にしておくべきです。(GitHub)

local.settings.jsonのValuesには、通常次のような設定が入ります。

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "node",
    "AzureWebJobsStorage": "UseDevelopmentStorage=true"
  }
}

開発チームでは、言語ごとにFUNCTIONS_WORKER_RUNTIMEが正しく設定されているかを確認してください。例として、Node.jsならnode、Pythonならpython、.NET isolatedならdotnet-isolatedを使います。ローカル設定ファイルには接続文字列などのシークレットが含まれる可能性があるため、リモートリポジトリに保存しないよう注意が必要です。Microsoft Learnでも、local.settings.jsonにはシークレットが含まれる可能性があるため、リモートリポジトリに格納しないよう注意が示されています。(Microsoft Learn)

.NETインプロセスモデル利用者はSDKバージョンも確認する

Core Toolsの更新時に見落としやすいのが、.NETインプロセスモデルのSDKバージョンです。Microsoft Learnでは、Core Tools 4.0.6517以降、インプロセスモデルのプロジェクトはMicrosoft.NET.Sdk.Functionsバージョン4.5.0以降を参照する必要があり、古いバージョンを使っているとfunc startがエラーになると説明されています。(Microsoft Learn)

古いFunctionsプロジェクトを保守している場合は、Core Toolsだけを更新して終わりにせず、.csprojも確認してください。

<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.5.0" />

ただし、依存パッケージの更新はアプリケーションコードへの影響があり得ます。Core Tools更新、SDK更新、.NET実行モデル変更を同時に行うと、問題発生時の原因切り分けが難しくなります。まずCore Tools 4.11.0で既存構成が動くか確認し、必要に応じてSDK更新を別タスクとして扱うのが安全です。

Node.js 24を検討する場合の注意点

4.11.0のリリースノートにはNode.js 24関連のスタック定義更新が含まれていますが、既存のNode.js Function Appを自動的にNode.js 24へ移行する変更ではありません。Node.jsのバージョン変更は、アプリの依存関係、Azure Functionsのサポート状況、ホスティングプラン、OS設定を含めて判断する必要があります。

Microsoft Learnのサポート言語ページでは、Node.js 24はPreview、Node.js 22とNode.js 20はGAとして掲載されています。また、Node.js 22はLinux従量課金プランでサポートされる最後のNode.jsバージョンで、新しいNode.jsバージョンはLinux Consumptionには追加されない旨も説明されています。(Microsoft Learn)

Node.js 24を検討する場合は、次の順に確認すると失敗を避けやすくなります。

確認項目	判断基準
公式サポート状態	Microsoft Learn、Azureポータル、利用リージョンで選択可能か
ホスティングプラン	Linux ConsumptionではなくFlex Consumptionなどが必要か
ローカル実行	Node.js 24でnpm install、func start、単体テストが通るか
依存パッケージ	ネイティブモジュールや古いSDKがNode.js 24に対応しているか
本番展開	スロット、検証用Function App、段階的ロールアウトを使うか

Kubernetesデプロイ利用者は4.11.0で再テストする価値がある

func kubernetes deployやfunc kubernetes deleteを利用しているチームは、4.11.0の変更を優先的に確認すべきです。リリースノートでは、Deployment登録前にkubectl rollout statusが走る競合状態の修正と、func kubernetes deleteで--no-dockerを尊重する修正が掲載されています。(GitHub)

この種の修正は、普段は問題が見えにくくても、ネットワーク遅延、Kubernetes APIサーバーの応答タイミング、CIエージェントの性能差によって再現することがあります。4.10.0以前で断続的に失敗していたデプロイがある場合は、4.11.0で同じ条件の再実行ログを比較してください。

確認時は、少なくとも次の情報をログに残すと後から調査しやすくなります。

func --version
kubectl version --client
kubectl config current-context

展開前チェックリスト

本番環境に関係するチームでは、Core Tools 4.11.0を導入する前に次のチェックを行ってください。

チェック	理由
func --versionをローカルとCIで確認した	開発者PCとCIの差異を把握するため
FUNCTIONS_EXTENSION_VERSIONを不用意に変更していない	Core Tools更新とホストランタイム設定を混同しないため
FUNCTIONS_WORKER_RUNTIMEが明示されている	func packやローカル実行時のランタイム判定を安定させるため
local.settings.jsonをリポジトリに含めていない	接続文字列やシークレット漏えいを防ぐため
func startと主要トリガーの動作確認をした	ローカルランタイムで基本動作を確認するため
func packやfunc publishを検証環境で試した	パッケージ化・発行手順の差分を確認するため
Node.js 24などの言語更新を同時に進めていない	CLI更新とランタイム更新の原因切り分けを容易にするため
ロールバック手順を残した	CI/CDでCLI更新起因の障害が起きたときに戻せるようにするため

よくある誤解と判断基準

Core Tools 4.11.0にするとAzure上のFunction Appも4.11.0になる？

なりません。Core Toolsはローカル開発やデプロイに使うCLIであり、Azure上のFunction Appが使用するランタイムはFUNCTIONS_EXTENSION_VERSIONなどのアプリ設定やサイト設定で管理されます。~4のようにメジャーバージョンを指定している場合、Functionsランタイムのマイナー更新は自動更新の対象になりますが、これはCore Toolsのバージョン番号とは別の仕組みです。(Microsoft Learn)

Host version unchangedなら何もしなくてよい？

Azure上の実行環境だけを見れば大きな対応は不要なケースが多いです。ただし、Core Toolsを使うローカル開発、CI/CD、Kubernetesデプロイ、パッケージ作成では影響が出る可能性があります。特にビルドエージェントが毎回最新CLIをインストールする運用では、バージョン確認と検証ログの保存が重要です。

4.11.0へすぐ更新すべき？

新規開発や検証環境では、4.11.0を使って問題ありません。既存の本番デプロイパイプラインでは、いきなり全面更新するより、まず検証環境でfunc start、func pack、func publishを通し、差分がないことを確認してから反映するのが現実的です。

Node.js 24へ移行するタイミングと同時に進めてよい？

同時に進めると、問題が起きたときにCore Tools更新が原因なのか、Node.js更新が原因なのか分からなくなります。まずCore Tools 4.11.0を既存ランタイムで検証し、その後にNode.js 24などの言語ランタイム更新を別の変更として扱うのが安全です。

次に取るべき行動

今回のAzure Functions documentation update: Release prep 4.11.0は、Core Toolsの4.11.0リリース準備として見るべき更新です。Host versionはPR上で変更なしとされているため、Function Appのランタイム設定を慌てて変更する必要はありません。一方で、Core Toolsは開発、テスト、パッケージ化、デプロイに関わるため、ローカルPCとCI/CDのバージョン確認は必須です。(GitHub)

まずはチーム内でfunc --versionを確認し、CIログにもCore Toolsバージョンを出力してください。次に、検証環境でfunc start、func pack、func publishを実行し、FUNCTIONS_WORKER_RUNTIMEやlocal.settings.jsonの扱いに問題がないか確認します。Node.js 24、Kubernetesデプロイ、.NETインプロセスモデルを使っている場合は、今回の4.11.0リリースノートに関連する変更点を個別にチェックしてから本番反映するのが安全です。