GitHubで公開された「GitHub documentation update: feat: drop Python 3.9 and add Python 3.14 support across packaging, CI, and docs」は、GitHub全体の仕様変更ではなく、microsoftgraph/msgraph-sdk-python、つまりMicrosoft Graph SDK for PythonのサポートPythonバージョンを整理する更新です。結論からいうと、SDKの最小要件はPython 3.10になり、Python 3.9は対象外、Python 3.14が新たにサポート対象へ追加されました。Python 3.9でmsgraph-sdkを使っているアプリ、GitHub Actions、Docker、devcontainer、デプロイ環境は、SDK更新前にランタイムと依存関係を確認する必要があります。2026年5月20日のv1.58.0リリースでは、この変更がFeatureとして反映されています。(GitHub)
GitHub documentation updateで何が変わったのか
今回の「GitHub documentation update: feat: drop Python 3.9 and add Python 3.14 support across packaging, CI, and docs」は、単なるREADMEの文言修正ではありません。パッケージ定義、CIのテスト対象、公開ワークフロー、開発コンテナ、ユーザー向けドキュメントをそろえて、Microsoft Graph SDK for Pythonの対応バージョンをPython 3.10以上へ統一する変更です。
PR #1481は2026年5月19日にmainブランチへマージされ、v1.58.0のリリースノートでは2026年5月20日付のFeatureとして記載されています。PR本文では、Kiotaの現在の期待値に合わせるため、Python 3.9サポートを削除し、最小バージョンを3.10に設定し、Python 3.14サポートを追加すると説明されています。(GitHub)
| 変更箇所 | 変更内容 | 実務上の意味 |
|---|---|---|
pyproject.toml | requires-pythonが>=3.9から>=3.10へ変更 | Python 3.9環境では新しいSDKをインストール・更新できない可能性が高くなる |
| パッケージ分類 | Python 3.9 classifierを削除し、Python 3.14 classifierを追加 | PyPIなどで表示される対応バージョンが3.10〜3.14に整理される |
| GitHub Actions CI | テストマトリクスから3.9を削除し、3.10〜3.14へ拡張 | 自社CIでも3.9を残していると失敗や非対応状態を見落としやすい |
| Publish workflow | パッケージ公開時のPythonランタイムを3.14へ変更 | 公開・ビルド用環境も新しいPython前提になる |
| README | SDKはPython 3.10以上をサポートすると明記 | 利用者向けの案内が「Python 3.10+」に統一される |
| devcontainer | Python 3.14のdevcontainerイメージへ更新 | CodespacesやVS Code Dev Containers利用者は開発環境の再構築が必要になる |
現在のREADMEにも、このライブラリはPython 3.10以上をサポートする旨が記載されています。(GitHub)
影響を受ける対象者
今回の更新で最も影響を受けるのは、Microsoft Graph SDK for PythonをPython 3.9環境で利用している開発者・管理者です。特に、GitHub ActionsやDockerイメージではPythonのバージョン指定が見落とされやすいため、ローカル環境だけでなくCI/CDと本番環境まで確認する必要があります。
| 対象 | 影響 | 最初に確認すべきこと |
|---|---|---|
Python 3.9でmsgraph-sdkを使っているアプリ | SDK更新時にインストール不可、または互換性問題が発生する可能性 | アプリの実行Python、requirements、lockファイル |
| GitHub Actionsで3.9をテストしているリポジトリ | CIが古い前提を維持し、公式対応範囲とずれる | .github/workflows/*.ymlのpython-version |
Dockerでpython:3.9系を使っている環境 | コンテナ内で新しいSDKを扱えない可能性 | Dockerfile、ベースイメージ、ビルドログ |
| devcontainer / Codespaces利用チーム | 開発環境と公式SDKの想定環境がずれる | .devcontainer/devcontainer.json |
| ライブラリや社内SDKの管理者 | 自社パッケージの対応Python表記が古くなる | pyproject.toml、README、CIマトリクス |
| 本番運用担当者 | 開発環境だけ更新され、本番だけ3.9のまま残るリスク | デプロイ先のランタイム、クラウド実行環境、監視ログ |
一方で、すでにPython 3.10以上で運用しており、CI/CDや本番環境も3.10以上に統一されている場合、影響は比較的小さいと考えられます。ただし、Python 3.14対応が追加されたからといって、すべての周辺ライブラリや自社コードがPython 3.14で問題なく動くとは限りません。SDKだけでなく、依存パッケージ全体で検証することが重要です。
Python 3.9廃止はなぜ重要なのか
Python 3.9は公式のPython Developer’s Guide上で、2025年10月31日にEnd of Lifeとなっています。End of Lifeになると、そのブランチは凍結され、以後の変更は行われません。つまり、セキュリティ修正や不具合修正を前提にした長期運用には向きません。(Python Developer’s Guide)
今回のMicrosoft Graph SDK for Pythonの更新は、この流れに沿ったものです。ライブラリ側が古いPythonをサポートし続けると、CIの負担が増え、依存ライブラリの更新にも制約が出ます。特にMicrosoft Graph SDKのように、KiotaやAzure Identityなど周辺パッケージと連携するSDKでは、ランタイムの古さが依存関係の解決失敗につながりやすくなります。
注意したいのは、「最小要件がPython 3.10になった」ことと「移行先としてPython 3.10が最適」という意味は別だという点です。Python 3.10は2026年10月にEnd of Life予定のため、これから新しく移行計画を立てるなら、利用中のクラウド環境や依存ライブラリが対応している範囲で、Python 3.12、3.13、3.14も候補に入れるべきです。Python Developer’s Guideでは、Python 3.14は2025年10月7日に初回リリースされ、End of Lifeは2030年10月とされています。(Python Developer’s Guide)
まず確認すべき設定ファイル
移行作業では、アプリのソースコードより先に「どこでPython 3.9が指定されているか」を洗い出します。よくある失敗は、ローカル環境だけPythonを上げて、CIや本番Dockerイメージに3.9が残るケースです。
リポジトリ直下で、次のように検索すると見落としを減らせます。
grep -R "3.9\|python:3.9\|python-version\|msgraph-sdk" \
.github pyproject.toml requirements*.txt Dockerfile docker-compose*.yml .devcontainer \
2>/dev/nullWindowsのPowerShellで確認する場合は、次のように検索できます。
Select-String -Path ".github\*","pyproject.toml","requirements*.txt","Dockerfile",".devcontainer\*" `
-Pattern "3.9","python:3.9","python-version","msgraph-sdk" -Recurse確認すべき主な場所は次のとおりです。
| ファイル・設定 | 確認ポイント | 修正例 |
|---|---|---|
pyproject.toml | requires-pythonが>=3.9のままになっていないか | requires-python = ">=3.10" |
requirements.txt | msgraph-sdkのバージョンが無制限、または古い固定になっていないか | 検証後に明示的なバージョンへ更新 |
requirements.lock / poetry.lock / uv.lock | Python 3.9で生成されたlockが残っていないか | 新しいPython環境でlockを再生成 |
.github/workflows/*.yml | python-version: "3.9"が残っていないか | 3.10以上のマトリクスに変更 |
Dockerfile | FROM python:3.9系を使っていないか | 対応済みのPythonイメージへ変更 |
.devcontainer/devcontainer.json | devcontainerのPythonイメージが古くないか | 3.10以上、必要に応じて3.14系へ変更 |
| 本番ランタイム | クラウド実行環境が3.9のままではないか | 対応ランタイムへ移行 |
GitHub ActionsのCIマトリクスを見直す
GitHub ActionsでPython 3.9を含むマトリクスを使っている場合は、公式SDKの対応範囲とずれます。最低限、3.9を削除し、3.10以上でテストする構成に変更しましょう。
たとえば、Microsoft Graph SDK for Pythonを利用するアプリで、複数バージョンの互換性を確認したい場合は次のような構成が考えられます。
name: Python CI
on:
push:
pull_request:
jobs:
test:
runs-on: ubuntu-latest
strategy:
fail-fast: false
matrix:
python-version: ["3.10", "3.11", "3.12", "3.13", "3.14"]
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: ${{ matrix.python-version }}
- name: Install dependencies
run: |
python -m pip install --upgrade pip
python -m pip install -r requirements.txt
- name: Run tests
run: |
python -m pytestすべてのプロジェクトで3.10〜3.14を必ずテストすべき、という意味ではありません。業務アプリなら、本番で使うPythonバージョンと、次期移行候補の1〜2バージョンを優先するのが現実的です。ライブラリやSDKを配布している場合は、サポート表明しているバージョンをマトリクスに含めるべきです。
パッケージ管理で注意すべき点
今回の変更ではrequires-pythonが>=3.10に変わっています。Python Packagingの仕様では、Requires-Pythonはその配布物が互換性を持つPythonバージョンを示すフィールドで、インストールツールがインストール対象バージョンを選ぶ際に参照できます。(Python Packaging)
そのため、Python 3.9環境で新しいmsgraph-sdkを入れようとすると、次のような問題が起きる可能性があります。
| 起きやすい問題 | 原因 | 対処 |
|---|---|---|
| 最新版がインストールされない | Python 3.9がrequires-python >=3.10を満たさない | Pythonを3.10以上へ更新 |
| lockファイル更新が失敗する | 古いPythonで依存関係を解決している | 新しいPython環境でlockを作り直す |
| CIでは成功するが本番で失敗する | CIだけPythonを上げ、本番が3.9のまま | 本番ランタイムも同じバージョンへ移行 |
| 一部依存パッケージだけビルド失敗する | Python 3.14対応がSDK以外で未完了 | 3.12や3.13も含めて移行先を比較する |
すぐに本番を更新できない場合は、既存環境で動いているmsgraph-sdkのバージョンを一時的に固定し、移行計画を立てるのが安全です。ただし、古いバージョン固定は恒久対策ではありません。Python 3.9自体がEnd of Lifeであるため、セキュリティと保守性の観点では、ランタイム移行を前提に進めるべきです。
移行手順：Python 3.9利用中のプロジェクトでやること
Python 3.9から移行する場合、いきなり本番環境を更新するのではなく、依存関係、CI、デプロイ環境を段階的にそろえるのが安全です。
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 現状確認 | ローカル、CI、本番のPythonバージョンを確認 | どこに3.9が残っているか一覧化する |
| 移行先選定 | 3.10以上から候補を決める | 本番環境、依存ライブラリ、社内標準に合うか |
| 検証ブランチ作成 | PythonバージョンとSDKを更新 | 既存機能のテストが通るか |
| lock再生成 | 新しいPythonで依存関係を解決 | 古いlockを流用しない |
| CI更新 | GitHub Actionsのマトリクスを変更 | 本番予定バージョンでテストできるか |
| コンテナ更新 | Dockerfileやdevcontainerを更新 | 開発・CI・本番の差分を減らせるか |
| ステージング検証 | Graph API呼び出し、認証、例外処理を確認 | 認証フローや非同期処理に問題がないか |
| 本番展開 | 小さくリリースし監視する | エラー率、API失敗、依存パッケージ警告を確認 |
ローカル環境では、まず実行中のPythonとSDKバージョンを確認します。
python --version
python -m pip show msgraph-sdk
python -m pip check移行用の仮想環境を作る例は次のとおりです。
python3.14 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -r requirements.txt
python -m pytestWindowsでは次のように確認できます。
py -0p
py -3.14 -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install --upgrade pip
python -m pip install -r requirements.txt
python -m pytestここで重要なのは、Python 3.14を使うかどうかを最初から決め打ちしないことです。SDKは3.14対応になりましたが、アプリ全体の依存関係が3.14に対応していない場合があります。安定性を重視する本番環境では、3.12や3.13を候補にし、将来的に3.14へ進める判断も現実的です。
管理者が確認すべき展開上の注意点
管理者やSREが見るべきポイントは、開発者のPCではなく「実際にコードが動く場所」です。GitHub Actionsが通っていても、本番の実行環境がPython 3.9のままなら、リリース時に失敗する可能性があります。
特に次の設定は確認しておきましょう。
| 項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| GitHub Actions | CIのPythonバージョン | テスト用だけ3.14、本番ビルド用が3.9のまま |
| Dockerビルド | ベースイメージ | python:3.9-slimが残っている |
| デプロイ先 | Azure、AWS、オンプレなどのランタイム | 利用中のサービスが移行先Pythonに未対応 |
| シークレット・認証 | Graph APIの認証方式 | SDK更新と同時に認証コードの警告を見落とす |
| 監視 | SDK更新後のAPIエラー率 | 依存関係更新による例外型やログ形式の変化 |
| 開発環境 | devcontainer、Codespaces | コンテナ再ビルドをしないまま古い環境で作業する |
PRでは、devcontainerのターゲットイメージもPython 3.14へ更新され、3.14-bullseyeが使われ、3.14-bookwormがコメント付きの代替として記載されたことが説明されています。devcontainerを使っているチームでは、設定ファイルを変えただけでなく、コンテナの再ビルドまで実施してください。(GitHub)
開発者がコード面で確認すべきポイント
Microsoft Graph SDKの今回の変更は、主にPythonバージョンのサポート範囲に関する更新です。そのため、アプリコードのAPI呼び出しが必ず変更になるわけではありません。ただし、Python 3.9から3.10以上へ移行する過程で、依存パッケージやランタイム差分による問題が出ることがあります。
確認すべきコード面のポイントは次のとおりです。
| 確認項目 | 具体例 |
|---|---|
| 非同期処理 | asyncio.run()、イベントループ、非同期クライアントの使い方 |
| 認証処理 | ClientSecretCredential、DeviceCodeCredential、InteractiveBrowserCredentialなど |
| 型ヒント | Python 3.10以上の構文を使うか、古い記法を維持するか |
| 例外処理 | APIErrorの扱い、リトライ処理、ログ出力 |
| 日時・タイムゾーン | Graph APIから返る日時データの処理 |
| テスト | ユーザー取得、メール、OneDrive、SharePointなど実際に使うAPIの結合テスト |
特に、Microsoft Graph SDKは認証、HTTP通信、シリアライズなど複数の依存ライブラリと組み合わせて動きます。単にimport msgraphが成功するだけでは不十分です。実際にGraph APIを呼び出し、認証、ページング、エラー処理まで確認してください。
Python 3.14対応をどう活用するか
Python 3.14対応が追加されたことで、最新のPythonランタイムを採用しやすくなります。ただし、これは「すぐに全環境を3.14へ上げるべき」という意味ではありません。
おすすめの判断基準は次のとおりです。
| プロジェクトの状況 | 推奨判断 |
|---|---|
| 新規開発で依存関係が少ない | Python 3.13または3.14を候補にする |
| 本番運用中で安定性重視 | まず3.12または3.13で検証し、3.14は段階導入 |
| ライブラリを配布している | サポート表明する範囲をCIで必ずテストする |
| クラウドランタイム制約がある | 利用サービスが公式対応しているPythonを優先する |
| 社内標準が3.10のまま | 3.10は最小要件として維持しつつ、次期標準を早めに決める |
Python 3.10は今回の最小要件ですが、長期運用の移行先としては残り期間が短い点に注意が必要です。新しいプロジェクトや大規模な移行では、「最低限3.10」ではなく「どのPythonを次の標準にするか」を決める視点が重要です。
よくある誤解と注意点
GitHub全体でPython 3.9が使えなくなるわけではない
今回の更新は、GitHubというサービス全体のPythonサポート変更ではありません。GitHub上のmicrosoftgraph/msgraph-sdk-pythonリポジトリにおける、Microsoft Graph SDK for Pythonの変更です。GitHub ActionsでPython 3.9が即座に使えなくなる、という意味ではありません。
既存のPython 3.9環境が即日停止するわけではない
すでに動いているアプリが、今回のPRだけで突然停止するわけではありません。ただし、新しいSDKへ更新する、依存関係を解決し直す、CIを再構築する、といったタイミングで問題が出る可能性があります。
Python 3.14対応は「アプリ全体の3.14対応」ではない
SDKがPython 3.14に対応していても、アプリで使っているすべてのパッケージが3.14に対応しているとは限りません。特に、C拡張やOS依存のパッケージを使っている場合は、ビルド済みwheelの有無やコンパイラ要件を確認してください。
READMEだけでなくCIと公開ワークフローも変わっている
今回の更新は、ユーザー向けドキュメントだけではなく、パッケージメタデータ、CI、publish workflow、devcontainerまで含む整理です。自社プロジェクトでも、READMEだけ更新してCIやDockerを直さないと、環境差分が残ります。
今回の更新に対する実務対応まとめ
今回のGitHub documentation updateで押さえるべき要点は、Microsoft Graph SDK for Pythonのサポート範囲がPython 3.10以上に整理され、Python 3.14が追加されたことです。Python 3.9で運用している環境は、SDK更新の前に移行計画を立てる必要があります。
まずはリポジトリ内の3.9指定を洗い出し、GitHub Actions、Docker、devcontainer、本番ランタイムを確認してください。そのうえで、Python 3.10以上のどれを採用するかを決めます。短期的には3.10で要件を満たせますが、長期運用を考えるなら3.12、3.13、3.14も含めて検証するのが安全です。
次に取るべき行動は明確です。msgraph-sdkを使っているリポジトリでPython 3.9指定を検索し、CIマトリクスとデプロイ環境を3.10以上へ更新できるか確認しましょう。更新できない環境がある場合は、SDKバージョンを一時固定しつつ、Pythonランタイム移行を優先度の高い保守タスクとして扱うべきです。
コメント