Azure SDKでPython 3.9を使っている場合、特に azure-monitor-opentelemetry を導入してAzure Monitorへテレメトリを送っている環境は、Python 3.10以上への移行確認を始めるべきです。今回の「Remove support for python version 3.9 distro」は、Azure SDK for Python全体のすべてのパッケージが同時に動かなくなるという話ではなく、Azure Monitor OpenTelemetry Distroのドキュメント・メタデータ・CHANGELOGをPython 3.10以上前提へ更新する動きです。PRではREADMEの前提条件を「Python 3.10 or later」に変更し、CHANGELOGにPython 3.9サポート終了をBreaking Changesとして追加しています。(GitHub)
重要なのは、pip install が成功するかどうかだけで判断しないことです。Azure SDKのサポートポリシーではPython 3.10以上がランタイムとして示され、EOLになったランタイムや依存関係ではAzure SDKライブラリの動作保証がされない可能性があると説明されています。(Azure) そのため、Python 3.9で動いているアプリ、CI/CD、コンテナ、Azure Functions、App Serviceの設定を棚卸しし、少なくともPython 3.10以上で動作確認できる状態にしておくのが現実的な対応です。
何が変わったのか
今回の変更対象は、Azure SDK for Pythonリポジトリ内の sdk/monitor/azure-monitor-opentelemetry です。これはAzure Monitor OpenTelemetry Distroに関するパッケージで、アプリケーションのトレース、メトリック、ログなどをAzure Monitorへ送るために使われます。
PRの差分では、主に次の3点が確認できます。
| 確認箇所 | 変更内容 | 実務上の意味 |
|---|---|---|
README.md | 前提条件をPython 3.9以上からPython 3.10以上へ変更 | 新規導入・アップグレード時はPython 3.10以上を前提に設計する |
setup.py | Python 3.9のTrove classifierを削除 | パッケージの対応Pythonバージョン表示からPython 3.9が外れる方向 |
CHANGELOG.md | Python 3.9サポート終了をBreaking Changesに追加 | 既存のPython 3.9運用環境では移行計画が必要 |
PRのレビュー概要でも、azure-monitor-opentelemetry のパッケージメタデータとドキュメントをPython 3.10以上へ移行する内容だと整理されています。(GitHub)
注意したいのは、PRのチェックリスト上では「breaking changesを導入しない」とされている一方で、CHANGELOGの差分にはBreaking ChangesとしてPython 3.9サポート終了が追加されている点です。これはAPIの引数や戻り値が変わるタイプの破壊的変更ではなくても、Python 3.9で運用しているチームにとっては十分に影響のある変更だと考えるべきです。(GitHub)
背景はPython 3.9のEOLとOpenTelemetry側のサポート変更
Python 3.9は、Python公式のバージョン状況でEnd of Lifeに分類され、EOL日は2025年10月31日とされています。(Python Developer’s Guide) Azure SDKのPythonバージョンサポートポリシーでも、Python 3.9のSDKサポート終了日は2026年4月30日と示されています。(GitHub)
さらに、Azure Monitor OpenTelemetry DistroはOpenTelemetry Pythonの影響を強く受けます。OpenTelemetry PythonのCHANGELOGにも「Drop Python 3.9 support」が含まれており、Azure側の変更はこの上流依存関係のサポート方針に追随する意味合いがあります。(GitHub)
つまり今回のポイントは、単なるドキュメント表記の修正ではありません。Python本体、OpenTelemetry、Azure SDKのサポート方針がそろってPython 3.10以上へ移っているため、Azure Monitorの計装をPython 3.9で続けるほど、将来の依存関係解決やセキュリティ対応が難しくなります。
影響を受ける可能性が高い環境
次のいずれかに当てはまる場合は、対応優先度が高いです。
| 環境・利用状況 | 確認すべき理由 |
|---|---|
azure-monitor-opentelemetry を使っている | 今回のPRの直接的な対象パッケージ |
from azure.monitor.opentelemetry import configure_azure_monitor を使っている | Azure Monitor OpenTelemetry Distroを利用している可能性が高い |
| Python 3.9のAzure Functions、App Service、コンテナで監視を有効化している | ランタイム更新と監視ライブラリ更新が同時に必要になる可能性がある |
requirements.txt で azure-monitor-opentelemetry をバージョン固定せずに入れている | 将来のアップデートでPython 3.9非対応版を取り込むリスクがある |
| CI/CDのテストマトリクスにPython 3.9だけがある | 新しいパッケージや依存関係の互換性問題を検知できない |
Dockerfileで python:3.9 系イメージを使っている | ベースイメージ更新、依存関係更新、動作確認をまとめて行う必要がある |
一方、Python 3.10以上で運用しており、azure-monitor-opentelemetry のアップデート後もテストが通る環境では、すぐに大きな修正が必要になるとは限りません。ただし、Azure SDK全体のサポートポリシーはPython 3.10以上へ移っているため、Python 3.9がどこかに残っていないかは確認しておくべきです。
まず確認すべき設定
最初に、アプリ本体、開発環境、CI/CD、デプロイ先のPythonバージョンを確認します。
python --version
python -c "import sys; print(sys.version)"
次に、Azure Monitor OpenTelemetry Distroを使っているか確認します。
python -m pip show azure-monitor-opentelemetry
python -m pip freeze | grep -E "azure-monitor-opentelemetry|opentelemetry"
Windows PowerShellでは次のように確認できます。
python -m pip show azure-monitor-opentelemetry
python -m pip freeze | Select-String "azure-monitor-opentelemetry|opentelemetry"
コード内では、次のようなimportや関数呼び出しがあるかを探します。
from azure.monitor.opentelemetry import configure_azure_monitor
configure_azure_monitor()
この記述がある場合、Azure Monitor OpenTelemetry Distroを使っている可能性が高いため、Python 3.10以上での検証を優先してください。
Azure環境で見るべきポイント
Azure上でPythonアプリを動かしている場合、ローカルのPythonだけを上げても不十分です。ホスティング環境のランタイム設定も確認します。
App ServiceやAzure Functions
Azure App ServiceやAzure Functionsでは、ポータルやAzure CLIでランタイムスタックを確認します。Linux環境では、設定上のランタイムにPython 3.9が残っていないかを見ます。
az webapp config show \
--resource-group <resource-group> \
--name <app-name> \
--query linuxFxVersion
Azure Functionsの場合は、次のように確認できます。
az functionapp config show \
--resource-group <resource-group> \
--name <function-app-name> \
--query linuxFxVersion
ランタイムを変更する場合は、いきなり本番スロットで切り替えず、ステージングスロットや検証用リソースで次の点を確認します。
- アプリが起動するか
configure_azure_monitor()実行時に例外が出ないか- Application InsightsやAzure Monitorにテレメトリが届くか
- ログが重複していないか
- 依存パッケージの競合が発生していないか
コンテナ環境
DockerfileでPython 3.9系を指定している場合は、ベースイメージの更新が必要です。
# 変更前の例
FROM python:3.9-slim
# 変更後の例
FROM python:3.12-slim
ただし、単純に最新のPythonへ上げればよいとは限りません。業務アプリでは、OSパッケージ、ネイティブ拡張、データベースドライバ、OpenTelemetry関連パッケージとの相性を確認する必要があります。まずはPython 3.10、3.11、3.12のいずれかでテストし、自社のAzure実行基盤や依存ライブラリが安定して対応しているバージョンを選ぶのが安全です。
移行時に確認するファイル
Python 3.9を使っている箇所は、アプリのコードだけではありません。次のファイルに古い指定が残りやすいです。
| ファイル・設定 | よくある記述 | 見直し例 |
|---|---|---|
pyproject.toml | requires-python = ">=3.9" | >=3.10 以上へ変更 |
setup.py | python_requires=">=3.9" | python_requires=">=3.10" |
tox.ini | envlist = py39 | py310, py311, py312を追加 |
| GitHub Actions | python-version: "3.9" | "3.10" 以上へ変更 |
| Dockerfile | FROM python:3.9 | サポート対象のPythonイメージへ変更 |
requirements.txt | バージョン固定なし | 検証済みバージョンを固定 |
| Azure App設定 | Python 3.9ランタイム | Python 3.10以上のランタイムへ変更 |
特にCI/CDの更新は重要です。ローカルだけPython 3.12にしても、GitHub ActionsやAzure PipelinesがPython 3.9のままだと、リリース直前に依存関係の解決で失敗することがあります。
移行手順の実践例
安全に進めるなら、次の順序がおすすめです。
現在の依存関係を記録する
まず、現行環境の依存関係を保存します。
python -m pip freeze > requirements-current.txt
python -m pip check
pip check で依存関係の不整合が出ている場合は、Pythonを上げる前に内容を確認します。すでにOpenTelemetry関連で競合がある環境では、ランタイム更新後に問題が表面化しやすくなります。
Python 3.10以上の検証環境を作る
例としてPython 3.12で仮想環境を作ります。
python3.12 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -r requirements.txt
Windowsの場合は次のように有効化します。
py -3.12 -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install --upgrade pip
python -m pip install -r requirements.txt
Azure Monitorの計装を確認する
アプリ起動時に configure_azure_monitor() が実行される場合、起動ログとApplication Insights側の受信状況を確認します。
from azure.monitor.opentelemetry import configure_azure_monitor
configure_azure_monitor()
確認すべき観点は次の通りです。
- 起動時にImportErrorや依存関係エラーが出ないか
- トレースがAzure Monitorに届くか
- ログ、メトリック、例外情報が期待通りに出るか
- サンプリング設定が想定通りか
- 本番と同じ環境変数で動くか
Azure Monitor OpenTelemetry Distroのドキュメントでは、configure_azure_monitor による設定や、APPLICATIONINSIGHTS_CONNECTION_STRING などの環境変数が説明されています。(Microsoft Learn) 移行時は、Pythonバージョンだけでなく、接続文字列やOpenTelemetry関連の環境変数も合わせて確認してください。
「インストールできるから大丈夫」と判断しない
今回のPRでは、Python 3.9のclassifier削除とREADME/CHANGELOGの更新が中心です。一方で、レビューコメントでは python_requires がまだ >=3.8 のままだと、Python 3.9や3.8でもインストールできてしまい、READMEやCHANGELOGの3.10以上という説明と矛盾する可能性が指摘されています。(GitHub)
これは実務上かなり重要です。パッケージメタデータの反映タイミングによっては、Python 3.9環境でも pip install が通ることがあります。しかし、それは「サポートされている」ことを意味しません。
判断基準は次の順に見るのが安全です。
| 優先度 | 確認対象 | 理由 |
|---|---|---|
| 高 | リリース済みパッケージのCHANGELOG | 実際の変更内容が明記される |
| 高 | Requires-Python / python_requires | pipのインストール可否に影響する |
| 高 | READMEのPrerequisites | 利用者向けの前提条件 |
| 中 | Trove classifier | PyPI上の対応バージョン表示に影響する |
| 中 | Microsoft LearnやPyPIの説明 | 更新タイミングに差が出ることがある |
実際、Microsoft Learn上のAzure Monitor OpenTelemetry Distroのページには、現時点でPython 3.9以上という記述が残っています。(Microsoft Learn) ドキュメントの更新タイミングには差が出るため、最終的にはリリース済みのCHANGELOG、PyPIのメタデータ、公式リポジトリのREADMEをあわせて確認するのが確実です。
Python 3.10に上げれば十分か
最低ラインとしてはPython 3.10以上への移行が必要です。ただし、今から移行計画を立てるなら、単に3.10へ上げるだけでなく、サポート期間と周辺ライブラリの対応状況も見て判断したほうがよいです。
Python公式のバージョン状況では、Python 3.10はセキュリティフェーズに入り、EOLは2026年10月とされています。Python 3.11、3.12、3.13、3.14はそれぞれより新しいサポート期間を持ちます。(Python Developer’s Guide) そのため、短期的な互換性を重視するならPython 3.10、より長い運用期間を見込むならPython 3.11または3.12以降を候補にするのが現実的です。
ただし、Azure FunctionsやApp Serviceなどのマネージド実行環境では、選べるPythonバージョンがサービス側の対応状況に左右されます。自社が使っているAzureサービスでサポートされているバージョンを確認してから、移行先を決めてください。
よくある失敗と対策
CIだけPython 3.9のまま残る
開発PCや本番環境をPython 3.12にしても、CIがPython 3.9のままだと、将来のパッケージ更新で突然ビルドが失敗します。GitHub ActionsやAzure PipelinesのPythonバージョン指定を必ず見直してください。
strategy:
matrix:
python-version: ["3.10", "3.11", "3.12"]
ランタイム更新後にOpenTelemetry依存関係が競合する
azure-monitor-opentelemetry はOpenTelemetry関連パッケージを多く含みます。移行時に opentelemetry-sdk や各種instrumentationを個別に固定していると、バージョン競合が起きることがあります。
対策として、次の順で確認します。
python -m pip install --upgrade azure-monitor-opentelemetry
python -m pip check
python -m pip freeze | grep opentelemetry
個別にOpenTelemetryパッケージを固定している場合は、その固定が本当に必要かを見直してください。
Azure Monitorにデータが届いているつもりで確認を終える
アプリが起動しても、テレメトリが正しく送信されているとは限りません。移行後は、Azure MonitorやApplication Insightsで次のデータを確認します。
- リクエストトレース
- 例外
- カスタムログ
- メトリック
- サンプリング後の件数
- サービス名やリソース属性
特にサンプリング設定を使っている場合、移行前後で「送信量が減った」「ログが出ない」と誤解しやすいため、設定値と実際の取り込み件数をセットで確認しましょう。
古いパッケージを固定して移行を先送りする
一時的に古い azure-monitor-opentelemetry を固定すれば、Python 3.9環境を延命できる場合があります。ただし、これは根本対策ではありません。Azure SDKのPythonバージョンサポートポリシーでは、サポート終了後も古いSDKバージョンをPyPIからインストールできる可能性がある一方、未サポートのPythonバージョンでは新機能のサポート対象外になると説明されています。(GitHub)
本番運用では、延命策を使う場合でも期限を決め、Python 3.10以上への移行計画を別途立てるべきです。
対応方針のおすすめ
今回の変更に対しては、次の方針で進めると安全です。
| 優先度 | 対応 | 目安 |
|---|---|---|
| 最優先 | Python 3.9で azure-monitor-opentelemetry を使っている環境を洗い出す | すぐに実施 |
| 高 | Python 3.10以上の検証環境でアプリ起動とテレメトリ送信を確認 | 次回リリース前 |
| 高 | CI/CD、Dockerfile、Azureランタイム設定を更新 | 検証完了後 |
| 中 | requirements.txt やロックファイルを更新 | ステージング確認後 |
| 中 | 古いPython 3.9環境の廃止日を決める | 本番反映前に合意 |
判断に迷う場合は、「Azure Monitorの監視が止まると困る環境」から優先してください。監視系ライブラリの問題は、アプリ本体の障害より発見が遅れやすく、気づいたときにはログやトレースが欠落していることがあります。
まとめ:次にやること
Azure SDKの「Remove support for python version 3.9 distro」は、Azure Monitor OpenTelemetry DistroをPython 3.10以上前提へ移す変更です。Python 3.9はすでに公式EOLを迎えており、Azure SDK側でもPython 3.9のサポート終了日が過ぎています。今回の更新は、その流れに沿ってAzure Monitor OpenTelemetry Distroの前提条件を整理するものです。
まずは、次の3つを確認してください。
- Python 3.9で動いているAzureアプリがあるか
azure-monitor-opentelemetryやconfigure_azure_monitor()を使っているか- CI/CD、Dockerfile、Azureランタイム設定にPython 3.9が残っていないか
該当する環境があれば、Python 3.10以上の検証環境を作り、アプリ起動、依存関係、Azure Monitorへのテレメトリ送信を確認します。pip install が通るかどうかではなく、公式サポート対象のPythonバージョンで安定して運用できるかを基準に判断することが、今回の変更で最も重要なポイントです。

コメント