Azure FunctionsをPython 3.14へ更新する方法｜対応planとruntime移行チェックリスト

Azure Update 567646で、Azure FunctionsのLinux環境におけるPython 3.14サポートが一般提供されました。ただし、既存のFunction Appは、Pythonのバージョン設定だけを3.14へ変更すれば移行完了というわけではありません。

安全に移行するには、最初にホスティングplanを確認し、Python 3.14環境で依存パッケージを再ビルドします。そのうえで、native dependencies、Functions extensions、各トリガーをstaging環境で検証し、ロールバック手順を用意してから本番を切り替える必要があります。特にLinux ConsumptionではPython 3.14を利用できないため、Flex Consumptionなどへのplan移行が先に必要です。(Microsoft Learn)

まず確認するべき結論：planによって移行方法が異なる

Azure FunctionsをPython 3.14へ更新できるかどうかは、現在利用しているホスティングplanによって決まります。

Linuxのホスティングplan	Python 3.14	推奨する検証方法	主な注意点
Linux Consumption	非対応	新しいFlex Consumption Appで検証	Python 3.12が最後の対応版
Flex Consumption	対応	別の非本番Function Appで検証	Deployment Slotsは非対応
Premium	対応	staging slotへデプロイ	slot swapで切り替え可能
Dedicated／App Service	対応	staging slotへデプロイ	利用できるslot数はApp Service planに依存
カスタムコンテナー	構成による	新しいイメージを別環境へデプロイ	ベースイメージとOS依存ライブラリも更新

Flex ConsumptionはPython 3.10から3.14までをサポートしています。一方、Linux Consumptionに追加されるPythonは3.12までです。PremiumとDedicatedではdeployment slotを利用できますが、Flex Consumptionではslotを利用できません。(Microsoft Learn)

Linux Consumptionは直接Python 3.14へ更新できない

Linux Consumptionを利用している場合、Python 3.14への変更は単なるruntime更新ではなく、ホスティングplanの移行です。

Linux ConsumptionではPython 3.12が最後の対応版であり、同plan自体も2028年9月30日に廃止される予定です。Flex Consumptionへの移行は既存Function Appのplanをそのまま変更する方式ではありません。新しいFlex Consumption Function Appを作成し、設定とコードを移して再デプロイします。(Microsoft Learn)

移行先リージョンでPython 3.14を利用できるかは、作業前にAzure CLIで確認できます。

az functionapp list-flexconsumption-locations \
  --query "sort_by(@, &name)[].{Region:name}" \
  --output table

az functionapp list-flexconsumption-runtimes \
  --location <REGION> \
  --runtime python \
  --query "[].{Version:version}" \
  --output table

ポータルに3.14が表示されない場合、いきなりリソースを作り直すのではなく、まずリージョン、Azure CLI、IaCテンプレートのruntime指定を確認します。公式の対応表だけでなく、実際の移行先リージョンで列挙されるruntimeを作業時点の判断材料にするのが安全です。(Microsoft Learn)

重要なFunction Appはplan移行とPython更新を分ける

Linux Consumptionから移行する場合は、次の2段階に分けると問題の切り分けが容易になります。

現在のPythonバージョンを維持したままFlex Consumptionへ移行する
Flex Consumption上で動作を安定させてからPython 3.14へ更新する

planとPythonを同時に変更すると、障害が発生した際に、スケーリング、ネットワーク、アプリ設定、Python、依存パッケージのどれが原因か判別しにくくなります。

停止時間を厳しく管理するシステムや、Queue、Service Bus、Event Hubsなどを利用するFunction Appでは、変更を分ける方法が有効です。

Azure Functionsの「runtime」を4つに分けて確認する

Azure Functionsでは「runtime」という言葉が複数の意味で使われます。Python 3.14への移行では、次の4層を分けて管理する必要があります。

確認対象	役割	主な確認場所
Azure Functions runtime	Functionsホスト、トリガー実行、ワーカー管理	`FUNCTIONS_EXTENSION_VERSION`
Python runtime	アプリを実行するPython本体	Python Version、`PYTHON\|3.14`
Python worker	FunctionsホストとPythonコードの橋渡し	Python workerパッケージ、worker設定
Binding extensions	Storage、Service Busなどとの接続	`host.json`の`extensionBundle`

現在のAzure Functionsで使用すべきホストruntimeは4.xです。FUNCTIONS_EXTENSION_VERSIONが~4であることを確認してください。Pythonの設定を3.14へ変更しても、Functions runtimeが古いままでよいという意味ではありません。(Microsoft Learn)

また、Python 3.13以降ではPython workerの依存関係分離が標準となり、worker extensionsと共有メモリ機能のサポートが削除されています。次の設定や機能を利用している場合は、通常のPythonコードより優先して確認します。

PYTHON_ENABLE_WORKER_EXTENSIONS
Python worker extensionsを提供する外部パッケージ
共有メモリ機能を前提とした処理
grpcioやprotobufのバージョン競合を避けるための独自設定
azure-functions-runtimeなどによるworkerバージョン固定

Python 3.14では、従来の依存関係分離設定が期待どおりに作用するかだけでなく、その設定自体が不要または無効になっていないかも確認してください。(Microsoft Learn)

Python 3.14への移行期限は現在のバージョンから決める

すべてのFunction Appを直ちにPython 3.14へ更新しなければならないわけではありません。優先順位は、現在のPythonバージョンのサポート期限とホスティングplanで判断します。

現在のPython	Azure Functionsでのサポート終了予定	移行優先度
Python 3.10	2026年10月	高い。早急に検証を始める
Python 3.11	2027年10月	年間計画へ組み込む
Python 3.12	2028年10月	依存パッケージを確認しながら計画する
Python 3.13	2029年10月	緊急性は低いが3.14検証は可能
Python 3.14	2030年10月	最も長いサポート期間を確保できる

特にPython 3.10を利用しているFunction Appは、Python 3.14への直接移行だけでなく、依存パッケージの都合に応じてPython 3.13を中継先にすることも検討します。

Linux ConsumptionでPython 3.12を利用している場合は、Python自体の期限だけを見てはいけません。planの廃止予定日である2028年9月30日の方が先に到来するため、Flex Consumptionなどへの移行計画が必要です。(Microsoft Learn)

Azure FunctionsをPython 3.14へ安全に移行する手順

現在の構成とロールバック材料を保存する

変更前に、最低限次の情報を記録します。

Function App名、リソースグループ、リージョン
ホスティングplan
Functions runtime
Pythonバージョン
v1またはv2のプログラミングモデル
HTTP、Timer、Blob、Queueなどのトリガー一覧
入出力bindings
host.jsonとrequirements.txt
アプリ設定と接続文字列
マネージドIDとRBAC
VNet、Private Endpoint、アクセス制限
証明書
デプロイ方法と直前の正常なartifact
Application Insightsの正常時メトリクス

Azure CLIで構成を保存する例は次のとおりです。

az functionapp show \
  --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --output json > functionapp-before.json

az functionapp config appsettings list \
  --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --output json > appsettings-before.json

az functionapp deployment slot list \
  --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --output table

appsettings-before.jsonには、接続文字列、APIキー、共有シークレットなどが含まれる可能性があります。Gitリポジトリへ登録せず、暗号化された保管場所で管理し、移行完了後に不要なコピーを削除してください。(Microsoft Learn)

さらに、直前の正常なソースコードだけでなく、旧Pythonバージョンでビルドしたartifactも保存します。ロールバックでは、Pythonの設定だけを戻すのではなく、旧runtime用のartifactも一緒に再デプロイする必要があるためです。

Python 3.14の仮想環境を新しく作る

既存の.venvをそのまま使わず、Python 3.14で新しい仮想環境を作ります。

# Windows
py -3.14 -m venv .venv

# LinuxまたはmacOS
python3.14 -m venv .venv
source .venv/bin/activate

Windowsでは、仮想環境を有効化した後に次を実行します。

.venv\Scripts\Activate.ps1

依存関係のインストールと基本テストを実行します。

python -m pip install --upgrade pip
python -m pip install -r requirements.txt
python -m pip check
python -m pytest
func start

確認するのはテストの成否だけではありません。func startの出力に表示されるFunction数が本番と一致しているか、起動時にbindingやextensionの警告が出ていないかも確認します。

Microsoftは、Pythonバージョンを変更した場合、新しいPythonバージョンでアプリを再ビルドし、再デプロイする必要があると案内しています。既存のartifactと依存パッケージは、runtime設定を変えても自動では再ビルドされません。(Microsoft Learn)

requirements.txtをPython 3.14向けに点検する

requirements.txtでは、次の項目を確認します。

すべてのimport対象が記載されているか
Python 3.14をサポートしない古いバージョンが固定されていないか
廃止済みパッケージやメンテナンス停止パッケージがないか
Windows専用パッケージが含まれていないか
開発用パッケージが本番依存関係へ混入していないか
private feedから取得するパッケージがPython 3.14に対応しているか
間接依存関係に競合がないか

WindowsやmacOSの開発環境で実行したpip freezeの結果を、そのまま本番用requirements.txtへ上書きするのは避けます。OS固有の依存関係が入り、Linux上のAzure Functionsでimportに失敗することがあるためです。

移行前の調査用としてfreeze結果を保存する場合は、別ファイルにします。

python -m pip freeze > requirements-inventory.txt

requirements-inventory.txtは現状把握に使い、本番へ直接デプロイする依存関係はrequirements.txtで明示的に管理します。(Microsoft Learn)

native dependenciesをLinux環境で確認する

Python 3.14移行で問題になりやすいのが、C、C++、Rustなどで実装されたnative dependenciesです。

代表的な確認対象には次のようなパッケージがあります。

NumPy
pandas
cryptography
Pillow
lxml
grpcio
psycopg系ドライバー
orjson
機械学習や画像処理関連のパッケージ

これらを利用しているから必ず問題が発生するわけではありません。確認すべきなのは、採用しているパッケージバージョンに、Python 3.14とAzure FunctionsのLinux環境に対応したwheelがあるかどうかです。

ローカルのWindows環境でimportできても、Linux用wheelが提供されていなければAzure上で失敗します。典型的な症状は次のとおりです。

ModuleNotFoundError
ImportError
shared objectファイルを読み込めない
GLIBCやlibstdc++の不一致
undefined symbol
cygrpc関連のimportエラー

native dependenciesがある場合は、次のいずれかを採用します。

Azure側のremote buildを利用する
Azureと互換性のあるLinux環境でartifactをビルドする
Dockerを利用してnative dependenciesをビルドする
必要なOSライブラリが特殊な場合はカスタムコンテナーを検討する

非本番Function Appへnative dependenciesを含めて発行する例は次のとおりです。

func azure functionapp publish <NONPROD_APP_NAME> --build-native-deps

本番用CI/CDでも、Python 3.14かつLinuxのビルド環境を使用してください。過去のPythonバージョンで作った.python_packagesやwheelを再利用してはいけません。(Microsoft Learn)

Functions extensionsとhost.jsonを確認する

Pythonコードが正常でも、Functions extensionsが古いと、トリガーやbindingの読み込みで失敗することがあります。

host.jsonでextension bundleを利用している場合は、4.x系になっているか確認します。

{
  "version": "2.0",
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[4.*, 5.0.0)"
  }
}

既に別のバージョン範囲を意図的に固定している場合は、理由を確認せずに書き換えないでください。まず非本番環境で更新し、使用中のすべてのトリガーとbindingを検証します。(Microsoft Learn)

Flex Consumptionへ移行する場合は、Blob Storageトリガーにも注意が必要です。Flex Consumptionで利用できるBlobトリガーはEvent Gridベースです。従来のコンテナーポーリング方式を利用している場合は、Python 3.14更新とは別にトリガー構成を変更する必要があります。(Microsoft Learn)

トリガーごとにstaging環境を分離する

staging環境から本番のQueueやService Busへ接続すると、テスト中のFunctionが本番メッセージを処理する恐れがあります。

トリガー	staging環境での確認方法
HTTP	staging用URLで認証、レスポンス、ヘッダー、タイムアウトを確認
Timer	本番と異なる時刻にするか、検証時だけ有効化
Storage Queue	専用のテストQueueを使用
Service Bus	専用QueueまたはTopic／Subscriptionを使用
Event Hubs	専用consumer groupを使用
Blob Storage	専用コンテナーとEvent Grid subscriptionを使用
Cosmos DB	専用lease containerを使用
Durable Functions	新規instanceでオーケストレーション全体を確認

特にイベント駆動Functionでは、「起動したから正常」と判断してはいけません。再試行、重複実行、dead-letter、checkpoint、出力bindingまで確認します。

新旧Function Appを同じイベントソースへ同時接続する場合は、処理の冪等性が確保されていない限り、二重処理が発生する可能性があります。切り替え手順には、旧Functionの停止、新Functionの有効化、キュー残件の扱いを含めてください。(Microsoft Learn)

Premium／DedicatedでPython 3.14へ更新する方法

PremiumまたはDedicatedでは、productionへ直接適用せず、staging slotで更新します。

staging slotを作成する

az functionapp deployment slot create \
  --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --slot staging

staging用の接続先、APIキー、ストレージ、監視設定を構成します。productionと分ける必要がある設定はslot固有の設定として管理します。

利用可能なPython runtimeを確認する

az functionapp list-runtimes \
  --os linux \
  --query "[?runtime == 'python'].{Version:version,linuxFxVersion:linux_fx_version}" \
  --output table

一覧に表示されたlinuxFxVersionを使用して、staging slotをPython 3.14へ変更します。

az functionapp config set \
  --linux-fx-version "PYTHON|3.14" \
  --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --slot staging

その直後に、Python 3.14環境で作成したartifactをstaging slotへフルデプロイします。runtimeだけを変更し、以前のPython向けにビルドされたartifactを残してはいけません。(Microsoft Learn)

Azureポータルを利用する場合は、対象のstaging slotを開き、次の順に操作します。

「Settings」を開く
「Configuration」を開く
「General settings」を開く
Python Versionを3.14へ変更する
保存して再起動する
Python 3.14向けartifactをデプロイする

staging slotで受け入れテストを行う

最低限、次の条件を満たすまでproductionへ切り替えません。

すべてのFunctionが一覧に表示される
起動時にimportエラーが発生しない
triggerとbindingの読み込みエラーがない
Application Insightsへログが送信される
HTTPのステータスコードとレスポンス内容が一致する
QueueやService Busの再試行が正常に動く
Timerが想定した時刻に一度だけ実行される
native dependenciesを使う処理が実行できる
処理時間、メモリ、失敗率が許容範囲に収まる
外部API、データベース、Storageへの認証が成功する

問題がなければslot swapを実行します。

az functionapp deployment slot swap \
  --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --slot staging \
  --target-slot production

slot swapはロールバックを容易にしますが、実行中のFunctionが終了する可能性があり、完全な無停止を保証するものではありません。長時間実行処理、非同期処理、状態を持つ処理では、切り替え時の再試行と冪等性を確認してください。(Microsoft Learn)

Flex ConsumptionでPython 3.14へ更新する方法

Flex Consumptionではdeployment slotを利用できないため、本番Function Appを直接変更する前に、別の非本番Function Appで同じ構成を再現します。

推奨する流れは次のとおりです。

同じリージョンに検証用Flex Consumption Function Appを作成する
Python 3.14を指定する
本番と同じコードをPython 3.14で再ビルドしてデプロイする
staging専用のストレージやメッセージングリソースへ接続する
すべてのトリガーを検証する
新しい本番用Function Appを作成するか、検証済み手順を既存Appへ適用する
HTTPルーティングまたはイベントソースを切り替える
問題がなければ旧Appを停止する

Flex Consumptionでは、従来planのlinuxFxVersionではなく、properties.functionAppConfig.runtimeでruntimeを管理します。IaCで構築する場合、PremiumやDedicated用のテンプレートをそのまま流用しないでください。

また、Flex Consumptionでは次の従来設定が置き換えられているか、利用されません。

FUNCTIONS_WORKER_RUNTIME
FUNCTIONS_WORKER_RUNTIME_VERSION
properties.LinuxFxVersion
SCM_DO_BUILD_DURING_DEPLOYMENT
ENABLE_ORYX_BUILD
WEBSITE_RUN_FROM_PACKAGE

runtime設定やremote buildは、Flex Consumption向けのfunctionAppConfigとデプロイ設定を使用します。(Microsoft Learn)

本番切り替え後に確認する監視項目

移行直後は、Function Appの状態が「Running」になっているだけでは不十分です。

Application InsightsやAzure Monitorで、次の項目を旧環境の正常値と比較します。

Function execution count
成功率と失敗率
HTTP 5xx
Exception数
ModuleNotFoundErrorとImportError
平均処理時間と上位パーセンタイル
dependency failure
Queue length
Service Busのdead-letter件数
Event Hubsの処理遅延
Function hostの再起動
メモリ使用量
cold start時の応答時間
trigger syncの失敗
二重処理や欠損の有無

正常性の判定は「エラーがゼロ」だけではなく、移行前のベースラインとの差で行います。たとえばエラーが発生していなくても、平均処理時間が大幅に増えたり、Queueの滞留が増えたりしていれば、移行は成功とはいえません。

ロールバック手順を先に決めておく

ロールバックは、障害発生後に考えるのではなく、本番切り替え前に実行条件まで決めます。

Premium／Dedicatedの場合

stagingとproductionを再度swapする
stagingのPythonを旧バージョンへ戻す
旧Python向けの正常なartifactを再デプロイする
triggerと監視を再確認する

Flex Consumptionの場合

HTTPのルーティング先を旧Function Appへ戻す
新Function Appのイベントトリガーを停止する
旧Function Appのトリガーを再開する
consumer group、lease container、Queueなどを旧構成へ戻す
重複処理と未処理メッセージを確認する

productionを直接更新した場合

Pythonの設定だけでなく、旧Pythonバージョンで作成したartifactを再デプロイします。Python 3.14向けにビルドしたnative packageを、Python 3.13や3.12へ戻した環境で使い続けてはいけません。

Microsoftの公式手順でも、直接更新から戻す場合は旧言語バージョンへ変更したうえで、以前のコードを再デプロイする流れが示されています。(Microsoft Learn)

Python 3.14 runtime移行チェックリスト

フェーズ	確認項目	完了条件
plan確認	Linux Consumption、Flex、Premium、Dedicatedのどれか	3.14対応可否と移行経路が決まっている
Functions runtime	`FUNCTIONS_EXTENSION_VERSION`	`~4`になっている
Python環境	Python 3.14の仮想環境を新規作成	依存関係を新規インストールできる
コード	unit test、型、廃止API	Python 3.14ですべて成功する
依存関係	`requirements.txt`、`pip check`	競合と不足がない
native dependencies	Linux用Python 3.14 wheelまたはビルド	Azure相当のLinux環境でimportできる
Python worker	worker extensions、共有メモリ、依存関係分離	Python 3.13以降の変更に対応している
Extensions	`host.json`のextension bundle	4.x系でbindingを読み込める
トリガー	HTTP、Timer、Queue、Blobなど	入力から出力まで動作する
staging	slotまたは別Function App	productionと分離して検証できる
設定	app settings、ID、RBAC、VNet	本番相当の接続が成功する
監視	Application Insights	ログ、メトリクス、例外を確認できる
切り替え	slot swapまたはルーティング変更	手順と担当者が決まっている
ロールバック	旧runtimeと旧artifact	即時に復旧できる
切り替え後	エラー、遅延、滞留、重複	移行前の基準内に収まっている

失敗しやすいポイントと対処方法

失敗例	起こり得る問題	対処
Python Versionだけを3.14へ変更	importエラー、起動失敗	Python 3.14で再ビルド・再デプロイする
Linux Consumptionのまま更新しようとする	3.14を選択できない	Flex、Premium、Dedicatedへ移行する
Windowsで作った依存関係を配置	Linux用binaryを読み込めない	remote buildまたはLinux CIを使う
古い`.python_packages`を再利用	ABI不一致	ディレクトリを破棄して再生成する
extension bundleを確認しない	triggerやbindingのロード失敗	`host.json`を確認して4.x系を検証する
stagingを本番Queueへ接続	メッセージの二重処理	専用Queueやconsumer groupを使う
Flexでdeployment slotを前提にする	リリース手順が成立しない	別の非本番Function Appを作る
Flexで`linuxFxVersion`を設定する	runtime指定が反映されない	`functionAppConfig.runtime`を使う
BlobトリガーをそのままFlexへ移す	トリガーが非互換	Event Gridベースへ変更する
runtimeだけを旧版へ戻す	旧版でartifactが動かない	旧runtimeと旧artifactをセットで戻す
worker extensionsを見落とす	Python 3.14で機能しない	拡張機能を削除または代替する

すぐにPython 3.14へ上げられない場合の代替策

依存パッケージがPython 3.14へ対応していない場合、無理に本番更新する必要はありません。

現実的な選択肢は次のとおりです。

Python 3.13を一時的な移行先にする
Python 3.12を継続し、依存パッケージの対応を待つ
対応済みの後継パッケージへ置き換える
問題のある処理だけを別Function Appへ分離する
OSライブラリが必要な場合はカスタムコンテナー化する
Linux Consumptionでは、先にFlex Consumptionへ移行してからPythonを更新する

ただし、延期する場合は「対応待ち」のまま放置せず、現在のPythonサポート期限、対象パッケージ、再検証日、担当者を記録します。

カスタムコンテナーを利用すればOSパッケージやPythonビルドを細かく制御できますが、ベースイメージ、Python、OSライブラリの脆弱性対応を自組織で継続する必要があります。通常のbuilt-in Linux runtimeで解決できる場合は、そちらを優先した方が運用負担を抑えられます。(Microsoft Learn)

安全な移行はplan確認と再ビルドから始める

Azure FunctionsをPython 3.14へ更新する際の最重要ポイントは、runtime設定だけを変更しないことです。

最初にホスティングplanを確認し、Linux ConsumptionならFlex Consumptionなどへの移行計画を作ります。PremiumまたはDedicatedならstaging slot、Flex Consumptionなら別の非本番Function Appを用意します。

次に、Python 3.14環境で依存関係をゼロから再構築し、native dependencies、Functions extensions、すべてのトリガーを検証します。その後、旧runtimeと旧artifactをセットで戻せる状態を確保してから本番を切り替えます。

まず実行すべき作業は、対象Function Appをplan別に一覧化し、Pythonバージョン、native dependencies、使用トリガー、staging方法の4項目を埋めることです。ここまで整理できれば、単純なruntime更新で済むAppと、plan移行を伴うAppを分けて、安全な移行日程を決められます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure FunctionsをPython 3.14へ更新する方法｜対応planとruntime移行チェックリスト

まず確認するべき結論：planによって移行方法が異なる

Linux Consumptionは直接Python 3.14へ更新できない

重要なFunction Appはplan移行とPython更新を分ける

Azure Functionsの「runtime」を4つに分けて確認する

Python 3.14への移行期限は現在のバージョンから決める

Azure FunctionsをPython 3.14へ安全に移行する手順

現在の構成とロールバック材料を保存する

Python 3.14の仮想環境を新しく作る

requirements.txtをPython 3.14向けに点検する

native dependenciesをLinux環境で確認する

Functions extensionsとhost.jsonを確認する

トリガーごとにstaging環境を分離する

Premium／DedicatedでPython 3.14へ更新する方法

staging slotを作成する

利用可能なPython runtimeを確認する

staging slotで受け入れテストを行う

Flex ConsumptionでPython 3.14へ更新する方法

本番切り替え後に確認する監視項目

ロールバック手順を先に決めておく

Premium／Dedicatedの場合

Flex Consumptionの場合

productionを直接更新した場合

Python 3.14 runtime移行チェックリスト

失敗しやすいポイントと対処方法

すぐにPython 3.14へ上げられない場合の代替策

安全な移行はplan確認と再ビルドから始める

この記事を書いた人

コメント

コメントするコメントをキャンセル

Azure FunctionsをPython 3.14へ更新する方法｜対応planとruntime移行チェックリスト

まず確認するべき結論：planによって移行方法が異なる

Linux Consumptionは直接Python 3.14へ更新できない

重要なFunction Appはplan移行とPython更新を分ける

Azure Functionsの「runtime」を4つに分けて確認する

Python 3.14への移行期限は現在のバージョンから決める

Azure FunctionsをPython 3.14へ安全に移行する手順

現在の構成とロールバック材料を保存する

Python 3.14の仮想環境を新しく作る

requirements.txtをPython 3.14向けに点検する

native dependenciesをLinux環境で確認する

Functions extensionsとhost.jsonを確認する

トリガーごとにstaging環境を分離する

Premium／DedicatedでPython 3.14へ更新する方法

staging slotを作成する

利用可能なPython runtimeを確認する

staging slotで受け入れテストを行う

Flex ConsumptionでPython 3.14へ更新する方法

本番切り替え後に確認する監視項目

ロールバック手順を先に決めておく

Premium／Dedicatedの場合

Flex Consumptionの場合

productionを直接更新した場合

Python 3.14 runtime移行チェックリスト

失敗しやすいポイントと対処方法

すぐにPython 3.14へ上げられない場合の代替策

安全な移行はplan確認と再ビルドから始める

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル