Azure SDK documentation update(Remove support for python version 3.9 exporter)で最初に押さえるべき結論は、azure-monitor-opentelemetry-exporter をPython 3.9で使っている環境は、Python 3.10以上への移行確認が必要になったという点です。今回の変更は、Azure SDK for Pythonのすべてのパッケージが一斉にPython 3.9で使えなくなる、という話ではありません。対象はAzure Monitor向けのOpenTelemetry exporterで、READMEの前提条件、CHANGELOG、開発用依存関係、パッケージ分類が更新されています。PRでは azure-monitor-opentelemetry-exporter のREADMEが「Python 3.10 or later」に更新され、CHANGELOGにもPython 3.9サポート終了がBreaking Changesとして記録されています。(GitHub)
特に、Application InsightsやAzure MonitorへOpenTelemetryのトレース、ログ、メトリックを送っているPythonアプリは要確認です。AzureMonitorTraceExporter、AzureMonitorLogExporter、AzureMonitorMetricExporter を直接使っている場合だけでなく、azure-monitor-opentelemetry Distro経由で利用している場合も、exporterが構成要素に含まれるため影響を確認してください。Azure Monitor OpenTelemetry Distroは、OpenTelemetryの計装とAzure Monitor exporterをまとめて扱う「one-stop-shop」の構成として説明されています。(Microsoft Learn)
Azure SDK documentation updateで変わったこと
今回の変更は、単なる説明文の差し替えではなく、今後の運用判断に関わるサポート対象の変更です。主なポイントは次のとおりです。
| 確認項目 | 変更内容 | 実務上の見方 |
|---|---|---|
| 対象パッケージ | azure-monitor-opentelemetry-exporter | Azure MonitorへOpenTelemetryデータを送るPythonアプリが対象 |
| Python要件の表記 | READMEの前提条件がPython 3.10以上に更新 | Python 3.9環境は次リリース以降の検証対象から外れると考える |
| CHANGELOG | Python 3.9サポート終了がBreaking Changesに記載 | インストール可否だけでなく、運用上は破壊的変更として扱う |
| 開発依存関係 | aiohttp の開発用マーカーがPython 3.10以上に変更 | CI、テスト、開発環境のPython 3.9ジョブは見直しが必要 |
| パッケージ分類 | Programming Language :: Python :: 3.9 classifierが削除 | PyPI上の対応バージョン表示と実際のサポート方針を確認する |
注意したいのは、PRのチェックリストでは「breaking changesを導入しない」にチェックが入っている一方、CHANGELOG上ではBreaking Changesとして「Python 3.9を落とし、Python 3.10+をサポートする」と記録されている点です。読者側の運用では、チェックリストよりもCHANGELOGとREADMEのサポート要件を優先して判断するのが安全です。(GitHub)
なぜPython 3.9サポート終了が重要なのか
Python 3.9は、Python本体として2025年10月31日にend-of-lifeへ到達しています。PEP 596では、Python 3.9.25が最終セキュリティリリースであり、それ以降は更新もバグトラッカーでの受け付けも行われないと説明されています。(Python Enhancement Proposals (PEPs))
Azure SDK for Python側のサポートポリシーでも、Python 3.9のSDKサポート終了日は2026年4月30日とされています。つまり今回のAzure SDK documentation updateは、Python本体のEOLとAzure SDK側のサポート期限に沿って、Azure Monitor exporterのサポート範囲をPython 3.10以上へ寄せる流れと見てよいでしょう。(GitHub)
背景にはOpenTelemetry Python側の動きもあります。OpenTelemetry PythonではPython 3.9サポートを落とすPRが2026年4月にマージされ、CHANGELOGにも「Drop Python 3.9 support」が記録されています。Azure Monitor exporterはOpenTelemetry SDKと連携するため、上流のサポート方針に追随するのは自然な流れです。(GitHub)
影響を受ける環境・受けにくい環境
まず、次のどれかに当てはまる場合は対応が必要です。
| 利用状況 | 影響度 | 対応 |
|---|---|---|
Python 3.9で azure-monitor-opentelemetry-exporter を直接使っている | 高 | Python 3.10以上へ移行し、exporter更新後に動作確認する |
azure-monitor-opentelemetry DistroをPython 3.9で使っている | 中〜高 | Distro経由でexporterを使うため、依存関係を確認する |
| CI/CDのテストマトリクスにPython 3.9が残っている | 中 | Python 3.10以上へ置き換える |
| DockerfileやAzure実行環境がPython 3.9固定 | 高 | ベースイメージ、ランタイム設定、デプロイ設定を更新する |
| Python 3.10以上で利用中 | 低 | 念のため依存関係更新とテレメトリ送信を検証する |
| Azure StorageやAzure Identityなど、別のAzure SDKパッケージだけを利用 | 低 | このPRの直接対象ではないが、Azure SDK全体のPython 3.9サポート期限は確認する |
特に見落としやすいのは、アプリケーションコードではなく、CI、Docker、IaC、ロックファイルにPython 3.9が残っているケースです。ローカル開発環境だけをPython 3.11にしても、GitHub Actions、Azure Pipelines、Docker base image、App ServiceやFunctionsのランタイム設定が3.9のままなら、ビルドや本番環境で問題が出ます。
まず確認すべきコマンド
対象環境で、Pythonのバージョンとインストール済みパッケージを確認します。
python --version
python -m pip show azure-monitor-opentelemetry-exporter
python -m pip show azure-monitor-opentelemetry
python -m pip show opentelemetry-api opentelemetry-sdk
より正確に、インストール済みパッケージのメタデータを確認する場合は次のコマンドが便利です。
python - <<'PY'
import sys
from importlib.metadata import version, metadata, PackageNotFoundError
print("Python:", sys.version)
for name in [
"azure-monitor-opentelemetry-exporter",
"azure-monitor-opentelemetry",
"opentelemetry-api",
"opentelemetry-sdk",
]:
try:
print(name, version(name), "Requires-Python:", metadata(name).get("Requires-Python"))
except PackageNotFoundError:
print(name, "not installed")
PY
Windowsで py ランチャーを使っている場合は、次のようにPython 3.9環境が残っていないか確認できます。
py -0p
py -3.9 --version
py -3.10 --version
ここでPython 3.9が本番、検証、CIのどこかに残っている場合は、単にパッケージを更新する前に、実行基盤をPython 3.10以上へ上げる計画を作るべきです。
PyPIのメタデータ反映にはタイムラグがある点に注意
確認時点のPyPIでは、azure-monitor-opentelemetry-exporter の最新リリースとして 1.0.0b51 が表示され、Requires: Python >=3.8 やPython 3.9 classifierが残っています。これは、PRの変更が次のリリースにまだ反映されていない、またはパッケージメタデータ上の制御がREADMEやCHANGELOGより遅れて反映される可能性があることを示します。(PyPI)
さらに、GitHub上の setup.py ではPython 3.9 classifierは削除されていますが、python_requires=">=3.8" は残っています。Python Packaging User Guideでは、古いPythonバージョンを落とす場合、pipなどのインストーラーは Requires-Python メタデータを見てインストール可否を判断すると説明されています。つまり、README上はPython 3.10以上でも、Requires-Python が更新されるまではPython 3.9でインストールできてしまう可能性があります。運用上は「インストールできる=サポートされている」と判断しないでください。(GitHub)
Python 3.9から移行する手順
現在の利用箇所を棚卸しする
最初に、azure-monitor-opentelemetry-exporter を直接使っているか確認します。
grep -R "azure.monitor.opentelemetry.exporter" .
grep -R "AzureMonitorTraceExporter\|AzureMonitorLogExporter\|AzureMonitorMetricExporter" .
Distroを使っている場合は、次のようなコードを探します。
grep -R "configure_azure_monitor" .
grep -R "azure.monitor.opentelemetry" .
requirements.txt、pyproject.toml、poetry.lock、Pipfile.lock、constraints.txt、Dockerfile、CI設定も確認します。特に次のような記述が残っていれば修正対象です。
FROM python:3.9-slim
python-version: "3.9"
requires-python = ">=3.9"
Python 3.10以上の移行先を決める
最低限の移行先はPython 3.10です。ただし、長期的にはPython 3.11や3.12も候補になります。選ぶときは、次の順番で判断すると失敗しにくくなります。
| 候補 | 向いているケース | 注意点 |
|---|---|---|
| Python 3.10 | 最小変更でPython 3.9から抜けたい | サポート期限を見据えると、次の移行計画も必要 |
| Python 3.11 | 安定性と新しさのバランスを取りたい | 依存ライブラリの対応状況を確認する |
| Python 3.12以上 | 新しい環境へまとめて更新したい | Azureの実行環境、社内基盤、依存パッケージが対応済みか確認する |
本番環境で使う場合は、「最新版だから」という理由だけで選ばず、Azure上の実行基盤、コンテナイメージ、監視、セキュリティスキャン、CIのすべてで同じバージョンを扱えるかを確認してください。
仮想環境と依存関係を作り直す
Pythonのメジャー・マイナーを変えたら、既存の仮想環境を使い回さず、作り直すのが安全です。
python3.11 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip setuptools wheel
python -m pip install -r requirements.txt
python -m pip check
azure-monitor-opentelemetry-exporter はプレリリース版として提供されているため、直接インストールする検証環境では --pre が必要になる場合があります。PyPIのプロジェクト説明でも、exporterのインストール例として pip install azure-monitor-opentelemetry-exporter --pre が示されています。(PyPI)
python -m pip install --upgrade --pre azure-monitor-opentelemetry-exporter
Poetryを使っている場合は、Python制約を先に更新します。
[project]
requires-python = ">=3.10"
または、Poetry管理のプロジェクトでは次のように指定します。
[tool.poetry.dependencies]
python = ">=3.10,<4.0"
その後、ロックファイルを再生成し、CIで再現できるか確認します。
poetry env use python3.11
poetry lock
poetry install
poetry run python -m pip check
テレメトリ送信の動作確認で見るべきポイント
Pythonの移行後は、アプリケーションが起動するかだけでなく、Azure Monitorへの送信まで確認します。exporterはトレース、ログ、メトリックを扱うため、最低限次の観点をテストしてください。
| 確認項目 | 具体的な確認方法 | 失敗時に見る場所 |
|---|---|---|
| トレース | 1リクエストを発生させ、Application Insightsでトランザクションを確認 | 接続文字列、サンプリング設定、Span Processor |
| ログ | アプリの名前付きloggerからログを出す | logger設定、LogRecordProcessor、重複送信 |
| メトリック | カウンターやヒストグラムを記録する | MetricReader、送信間隔、属性数 |
| 認証 | connection stringまたはEntra ID認証で送信できるか | 環境変数、Managed Identity、権限 |
| オフラインストレージ | 一時的に送信失敗させ、再送用ファイルの扱いを確認 | storage directoryの書き込み権限 |
ログについては、root loggerへ安易にハンドラーを付けない点も重要です。READMEでは、exporterが azure-core に依存しており、root loggerへハンドラーを付けるとSDK内部ログまで取得して再帰的なログ送信につながる可能性があるため、名前付きloggerの利用が強く推奨されています。(GitHub)
import logging
logger = logging.getLogger("myapp.telemetry")
logger.setLevel(logging.INFO)
logger.info("telemetry migration test")
よくある失敗と回避策
pip installが成功したので対応不要と判断する
今回の変更では、READMEやCHANGELOGのサポート方針と、公開済みメタデータや python_requires の反映状況に差が出る可能性があります。Python 3.9でインストールできても、サポート対象として検証され続けるとは限りません。判断基準は、インストール可否ではなく、README、CHANGELOG、Azure SDKのサポートポリシー、実際のリリースメタデータの組み合わせです。
CIだけPython 3.9のまま残る
ローカルではPython 3.11へ移行しても、CIの python-version が3.9のままだと、将来の依存関係更新で突然失敗します。テストマトリクスからPython 3.9を外し、Python 3.10以上を最低1つ入れてください。
strategy:
matrix:
python-version: ["3.10", "3.11", "3.12"]
Dockerのベースイメージを更新し忘れる
Docker環境では、アプリの依存関係よりも先にベースイメージを確認します。
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN python -m pip install --upgrade pip \
&& python -m pip install -r requirements.txt \
&& python -m pip check
COPY . .
CMD ["python", "app.py"]
FROM python:3.9-slim が残っていると、依存関係だけを更新しても根本的な移行になりません。
Distro利用なのにexporterの変更を見落とす
azure-monitor-opentelemetry を使っている場合、コード上は AzureMonitorTraceExporter を直接importしていなくても、DistroがAzure Monitor exporterを構成要素として使います。Distro利用者も、Pythonバージョン、ロックファイル、依存関係の解決結果を確認してください。(Microsoft Learn)
本番のAzureランタイム設定を後回しにする
App Service、Functions、Container Apps、AKSなどで動かしている場合、アプリのリポジトリだけでなく、デプロイ先のランタイム設定も確認します。特にPaaSのランタイム、Dockerイメージ、ビルドエージェント、IaCテンプレートが別々に管理されている組織では、どこかにPython 3.9が残りやすくなります。
対応の優先順位
すべての環境を一度に更新するのが難しい場合は、次の順に進めるとリスクを抑えられます。
| 優先度 | 対応 | 理由 |
|---|---|---|
| 1 | 本番・ステージングのPython 3.9利用有無を確認 | 影響範囲を最短で把握できる |
| 2 | CIのPython 3.9ジョブをPython 3.10以上へ変更 | 依存関係更新時の破綻を早期に検知できる |
| 3 | ロックファイルをPython 3.10以上で再生成 | 古い依存解決を持ち越さない |
| 4 | exporter/Distro更新後にテレメトリを検証 | 監視データ欠落を防ぐ |
| 5 | IaC、Dockerfile、運用手順書を更新 | 再デプロイ時の巻き戻りを防ぐ |
今回の更新で取るべき次の行動
azure-monitor-opentelemetry-exporter を使っている場合は、まず本番、検証、CI、Docker、ローカル開発環境のPythonバージョンを確認してください。Python 3.9が見つかったら、Python 3.10以上へ移行し、仮想環境とロックファイルを作り直します。そのうえで、トレース、ログ、メトリックがAzure MonitorやApplication Insightsへ正しく送られるかを検証します。
今回のAzure SDK documentation updateは、単なるドキュメント修正として流すよりも、Python 3.9環境を棚卸しする良いタイミングです。特に監視基盤は「アプリは動いているがテレメトリが欠けている」という失敗が起きやすいため、依存関係の更新だけで終わらせず、送信結果まで確認してから本番へ反映しましょう。

コメント