GitHubで公開された「GitHub documentation update: feat: drop Python 3.9 support and add Python 3.14 support」は、Microsoft Graph Python Core SDKの対応Pythonバージョンを見直す更新です。結論から言うと、Python 3.9はサポート対象から外れ、最小対応バージョンはPython 3.10になります。あわせてPython 3.14が対応バージョンに追加されます。該当SDKを使っている開発者や、GitHub Actions、Dev Container、CI/CDでPython 3.9を前提にしている管理者は、実行環境と依存関係の確認が必要です。
今回の変更は「コードの書き方がすぐ変わる」というより、インストール可能なPythonバージョン、CIの検証対象、開発コンテナのベースイメージが変わる点に注意すべき更新です。特に、古いサーバーや社内ツールでPython 3.9を固定している場合、今後のパッケージ更新時にpip installやCIが失敗する可能性があります。
GitHub documentation updateの変更内容
この更新は、Microsoft Graph SDK for Pythonのコアライブラリであるmsgraph-sdk-python-coreのPull Requestとして、2026年5月19日にmainブランチへマージされました。PRの説明では、kiota-pythonとの整合性を取るためにPython 3.9をサポート対象から外し、Python 3.14を追加するとされています。最小対応バージョンはPython 3.10です。(GitHub)
変更された主なファイルは、pyproject.toml、GitHub Actionsのbuild.yml、README.md、.devcontainer/devcontainer.jsonの4つです。差分を見ると、パッケージメタデータ、CIのテストマトリクス、READMEの前提条件、Dev Containerのイメージ指定がまとめて更新されています。(GitHub)
| 変更箇所 | 変更前 | 変更後 | 実務上の意味 |
|---|---|---|---|
pyproject.toml | requires-python = ">=3.9" | requires-python = ">=3.10" | Python 3.9環境では新しいパッケージを解決できない可能性がある |
| Python classifier | Python 3.9を記載 | Python 3.9を削除、Python 3.14を追加 | PyPI上の対応バージョン表示が更新される |
| GitHub Actions | ["3.9", "3.10", "3.11", "3.12", "3.13"] | ["3.10", "3.11", "3.12", "3.13", "3.14"] | CIでPython 3.9のテストが行われなくなる |
| README | Python 3.9+ | Python 3.10+ | 開発者向けの前提条件が変わる |
| Dev Container | Python 3.13系のイメージなど | mcr.microsoft.com/devcontainers/python:3.14-bookworm | CodespacesやVS Code Dev Containersの標準環境がPython 3.14寄りになる |
この変更を含むmsgraph-core 1.4.0は、PyPI上でもPython 3.10以上を要求し、Python 3.10、3.11、3.12、3.13、3.14がclassifierに掲載されています。PyPIのリリース日は2026年5月20日です。(PyPI)
影響を受ける対象者
今回のGitHub documentation updateで最も影響を受けるのは、Microsoft Graph関連のPython SDKを使い、なおかつPython 3.9環境を残しているチームです。GitHub自体のアカウント設定やリポジトリ権限が変わる更新ではありませんが、GitHub上で管理しているCI、開発環境、SDK更新の運用には影響します。
影響が大きいケース
次のいずれかに当てはまる場合は、早めに確認したほうが安全です。
- GitHub Actionsで
python-version: "3.9"を指定している pyproject.toml、setup.cfg、tox.ini、noxfile.pyでPython 3.9をテスト対象にしている- DockerfileやDev ContainerでPython 3.9系イメージを使っている
- Microsoft Graph API連携ツールをPython 3.9のサーバーで運用している
msgraph-coreやmsgraph-sdkをバージョン固定せずにインストールしている- 社内の標準Pythonがまだ3.9のままになっている
特に注意したいのは、ローカル開発環境ではPython 3.11を使っているが、本番やCIだけPython 3.9のままというパターンです。この場合、開発者の手元では問題が見えず、デプロイ時や定期バッチの更新時に初めて失敗することがあります。
影響が小さいケース
すでにPython 3.10以上で運用している場合、今回の更新による影響は比較的小さいです。ただし、Python 3.14をCIに追加する場合は、依存パッケージ側が3.14に対応しているかを確認する必要があります。
また、古いバージョンのmsgraph-coreを明示的に固定しているプロジェクトは、すぐに壊れるとは限りません。ただし、固定を外したタイミングや、依存関係の再解決を行ったタイミングでPython要件に引っかかる可能性があります。
Python 3.9サポート終了が意味すること
Python 3.9をサポート対象から外すとは、単に「古いバージョンを推奨しない」という意味ではありません。requires-python = ">=3.10"が指定されると、Python 3.9環境ではパッケージ管理ツールが互換性のないバージョンとして扱います。
たとえばPython 3.9環境で新しいmsgraph-coreをインストールしようとすると、パッケージの解決に失敗する可能性があります。PRのテスト指示にも、Python 3.9環境でpip installを試すと、>=3.10を要求する旨のresolver errorが想定されると記載されています。(GitHub)
Python本体のライフサイクル上も、Python 3.9はすでにunsupported versionsに分類され、End of lifeは2025年10月31日とされています。一方、Python 3.10は2026年10月まで、Python 3.14は2030年10月までのEnd of life予定が示されています。(Python Developer’s Guide)
つまり今回の更新は、SDK単独の都合だけでなく、Pythonエコシステム全体のサポート状況に沿った整理と見てよいでしょう。
管理者が確認すべき設定
GitHubリポジトリの管理者は、まずCI/CDと開発環境の設定を確認します。アプリケーションコードよりも、先に実行環境を定義しているファイルを見るのが効率的です。
GitHub ActionsのPythonバージョン
.github/workflows/*.ymlに次のような指定がないか確認します。
strategy:
matrix:
python-version: ["3.9", "3.10", "3.11"]
Python 3.9が含まれている場合は、少なくともSDK更新時の検証対象から外すか、移行計画を立てます。今回のPRでは、CIのマトリクスから3.9を削除し、3.14を追加しています。(GitHub)
移行後の例は次のとおりです。
strategy:
matrix:
python-version: ["3.10", "3.11", "3.12", "3.13", "3.14"]
ただし、すべてのプロジェクトがいきなりPython 3.14までテストすべきとは限りません。依存ライブラリが3.14に未対応の場合、SDKではなく周辺パッケージで失敗することがあります。本番環境がPython 3.11なら、まず3.10、3.11、3.12あたりで安定性を確認し、その後に3.13や3.14を追加する進め方も現実的です。
Dev ContainerとCodespaces
.devcontainer/devcontainer.jsonを使っている場合は、ベースイメージを確認します。今回のPRでは、Python 3.9系のコメント行が削除され、アクティブなイメージがmcr.microsoft.com/devcontainers/python:3.14-bookwormへ更新されています。(GitHub)
開発環境をPython 3.14へ上げると、次のような差分が出ることがあります。
| 確認項目 | 起こりやすい問題 | 対応例 |
|---|---|---|
| 依存パッケージ | Python 3.14向けwheelがまだない | 一時的にPython 3.12/3.13で検証する |
| 型チェック | 新しいPython構文や標準ライブラリ差分で警告が変わる | mypyやpyrightのバージョンも更新する |
| テスト | 非推奨APIや挙動差でテストが落ちる | 失敗箇所をPythonバージョン差分として切り分ける |
| Dockerビルド | OSパッケージ名やビルド依存が変わる | bookworm前提でaptパッケージを見直す |
本番がPython 3.10や3.11の場合、開発コンテナだけ3.14にすると「開発では動くが本番では動かない」状態になることもあります。チームで使うDev Containerは、最新性だけでなく本番との差も意識して選ぶべきです。
パッケージのバージョン固定
requirements.txtやpyproject.tomlでmsgraph-coreを固定しているか確認します。
msgraph-core==1.3.8
このように固定している場合、すぐに1.4.0へ上がることはありません。ただし、セキュリティ更新や機能追加のために将来アップデートするなら、Python 3.10以上への移行は避けにくくなります。
一方、次のように広めに指定している場合は、依存関係の再解決で新しいバージョンが入る可能性があります。
msgraph-core>=1.0.0
安定運用を優先するなら、単に上限なしで指定するのではなく、検証済みバージョンを明示してから段階的に上げるのが安全です。
開発者が行うべき移行手順
Python 3.9からPython 3.10以上へ移行する場合は、いきなり本番環境を変更するのではなく、依存関係、テスト、CI、本番の順に確認します。
| 手順 | 作業内容 | 確認ポイント |
| -: | ——————- | ————————————————— |
| 1 | 現在のPythonバージョンを確認 | ローカル、CI、本番、コンテナで差がないか |
| 2 | 依存パッケージを一覧化 | msgraph-core、msgraph-sdk、azure-identityなどの互換性 |
| 3 | Python 3.10以上の環境を作成 | まずは本番に近い3.10または3.11で検証 |
| 4 | テストを実行 | 単体テスト、Microsoft Graph API連携、認証処理を確認 |
| 5 | CIのmatrixを更新 | Python 3.9を外し、必要なバージョンを追加 |
| 6 | 本番反映 | ロールバック手順と旧環境の扱いを決めてから展開 |
現在のPythonバージョンを確認する
まず、実行環境ごとにPythonバージョンを確認します。
python --version
python3 --version
仮想環境を使っている場合は、仮想環境を有効化したうえで確認します。
source .venv/bin/activate
python --version
GitHub Actionsでは、ワークフローのログにsetup-pythonで選択されたバージョンが出ます。ローカルだけでなく、CIで実際に使われているバージョンを見ることが重要です。
Python 3.10以上の仮想環境を作る
Python 3.10で検証する場合の例です。
python3.10 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
pip install -r requirements.txt
pyproject.tomlを使っている場合は、プロジェクトの管理方法に合わせてインストールします。
pip install -e .
この段階で失敗する場合は、msgraph-core以外の依存パッケージがPython 3.10以上に対応していない、または古い制約が残っている可能性があります。
Microsoft Graph連携を重点的にテストする
Microsoft Graph APIを使うアプリでは、単にimportできるかだけでは不十分です。認証、API呼び出し、例外処理まで確認します。
確認すべき代表的な観点は次のとおりです。
| テスト対象 | 確認内容 |
|---|---|
| 認証 | azure-identityを使ったトークン取得が成功するか |
| API呼び出し | /me、ユーザー一覧、メール送信など実際に使うエンドポイントが動くか |
| 権限 | アプリ登録、スコープ、管理者同意が変わっていないか |
| 非同期処理 | asyncio周りの例外処理やタイムアウトが想定通りか |
| ログ | エラー時に原因を追えるログが残るか |
PyPI上のmsgraph-core説明でも、このライブラリはMicrosoft Graph Python Client Libraryで使われるコアクラスを含み、非同期APIを前提にした説明が掲載されています。(PyPI) そのため、非同期処理をラップしている社内コードでは、イベントループや例外処理も確認しておくと安全です。
Python 3.14対応で注意したいこと
今回の更新ではPython 3.14が対応バージョンに追加されています。これは前向きな変更ですが、「すぐに全環境をPython 3.14へ上げるべき」という意味ではありません。
Python 3.14はPython Developer’s Guide上でbugfixステータスとして掲載されており、初回リリースは2025年10月7日、End of lifeは2030年10月とされています。(Python Developer’s Guide) ただし、業務アプリではPython本体だけでなく、利用しているライブラリ、OS、Dockerイメージ、監視ツール、セキュリティスキャンの対応状況も関係します。
Python 3.14へ上げる前に見るべき判断基準
| 判断基準 | Python 3.10〜3.12を優先したほうがよいケース | Python 3.14検証を進めやすいケース |
|---|---|---|
| 本番安定性 | 長期運用中の社内システム | 新規開発、検証環境、ライブラリ開発 |
| 依存関係 | C拡張や古いライブラリが多い | 純Python中心、依存が少ない |
| CI体制 | テストが少ない、手動確認が多い | 自動テストが充実している |
| コンテナ | 古いベースイメージを使っている | Dev ContainerやDockerを柔軟に更新できる |
| 障害対応 | ロールバックに時間がかかる | バージョン切り戻しが容易 |
現実的には、Python 3.9からの移行先としては、まずPython 3.10以上の安定した実行環境を確保し、その後にPython 3.14をCIの追加検証対象にする流れが扱いやすいです。
よくある失敗と回避策
今回のようなSDKの対応Pythonバージョン変更では、コード修正よりも環境差分でつまずくことが多くあります。
CIだけ失敗する
ローカルはPython 3.11、本番もPython 3.11なのに、GitHub ActionsだけPython 3.9のままというケースです。ワークフローのmatrixに古いバージョンが残っていると、新しいmsgraph-coreのインストール時に失敗します。
回避策は、.github/workflows/配下を検索し、3.9の指定を洗い出すことです。
grep -R '"3.9"\|3.9' .github/workflows
Dockerfileに古いPythonイメージが残っている
CIは更新済みでも、Dockerfileが次のような指定のままだと、コンテナ内ではPython 3.9が使われます。
FROM python:3.9-slim
移行する場合は、たとえば次のように更新します。
FROM python:3.11-slim
Python 3.14へ上げる場合は、アプリの依存関係と本番基盤の対応状況を確認してからにしましょう。特にC拡張を含むパッケージでは、wheelの提供状況によってビルド時間や失敗率が変わることがあります。
バージョン固定をしておらず、ある日突然失敗する
requirements.txtで広い範囲を許容していると、ある時点の再ビルドで新しいバージョンが入り、Python要件に引っかかることがあります。
msgraph-core>=1.0.0
回避策は、検証済みバージョンを固定し、定期的にアップデートする運用へ変えることです。
msgraph-core==1.4.0
ただし、固定は「更新しなくてよい」という意味ではありません。固定したうえで、月次やリリース前など決まったタイミングで更新検証を行うのが安全です。
READMEだけ更新して実環境を変えていない
READMEに「Python 3.10+」と書いても、CIやDocker、Dev Container、本番サーバーがPython 3.9のままでは意味がありません。今回のPRではREADMEだけでなく、pyproject.toml、CI、Dev Containerも合わせて更新されています。(GitHub)
社内プロジェクトでも、ドキュメント更新と環境定義ファイルの更新をセットで行うことが大切です。
社内プロジェクトでの展開チェックリスト
管理者やリードエンジニアは、次のチェックリストを使うと抜け漏れを減らせます。
| 確認項目 | 確認方法 | 対応の目安 |
|---|---|---|
| Python 3.9環境の有無 | サーバー、CI、Dockerfile、Dev Containerを検索 | 残っていれば移行対象にする |
| SDKの利用状況 | requirements.txt、pyproject.tomlを確認 | msgraph-coreやmsgraph-sdkを洗い出す |
| GitHub Actions | .github/workflows/*.ymlを確認 | matrixから3.9を外すか方針を決める |
| 依存関係 | pip freezeやlockファイルを確認 | Python 3.10以上で再解決する |
| テスト | 単体・結合・Graph API呼び出しを実行 | 認証とAPI通信を重点確認 |
| 本番移行 | リリース手順とロールバック手順を確認 | 先にステージングで検証する |
| ドキュメント | READMEや運用手順を更新 | 最小Pythonバージョンを3.10以上に統一 |
このチェックで重要なのは、Python 3.9という文字列を機械的に探すだけで終わらせないことです。古いDockerイメージ、社内テンプレート、GitHub Actionsの再利用ワークフロー、オンプレミスのバッチサーバーなど、明示的に見えにくい場所にも古いPythonが残ることがあります。
まず何をすべきか
今回のGitHub documentation updateは、Microsoft Graph Python Core SDKのサポート範囲をPython 3.10以上へ引き上げ、Python 3.14を新たに検証対象へ加える更新です。すでにPython 3.10以上を使っているプロジェクトでは大きな修正は不要な場合が多いものの、Python 3.9を使っている環境ではSDK更新時にインストールやCIが失敗する可能性があります。
まず行うべきことは、リポジトリ内でPython 3.9指定を探すことです。
grep -R '3.9' .github pyproject.toml setup.cfg setup.py tox.ini requirements.txt .devcontainer Dockerfile* 2>/dev/null
次に、Python 3.10以上の環境で依存関係を再インストールし、Microsoft Graph API連携のテストを実行します。Dev ContainerやGitHub Actionsを使っている場合は、READMEだけでなくCIと開発環境も同時に更新してください。
Python 3.14対応は将来の検証範囲を広げる意味がありますが、移行の最優先事項は「Python 3.9に依存した状態を解消すること」です。まずPython 3.10以上で安定稼働できる状態を作り、そのうえでPython 3.14をCIに追加するか判断すると、リスクを抑えて移行できます。

コメント