最後の3.10.22が出て、Python 3.10は終了。OSのpython3と自分で入れたPythonで対応が分かれる理由

こんにちは、インフラエンジニアのryuです。

2026年10月1日に、Python 3.10.22がリリースされました。これがPython 3.10の最後のリリースです。

python.orgのダウンロードページには、3.10系はもうサポートされておらず、今後はセキュリティ修正も出ないと書かれています。

みなさんの担当しているサーバーにも、Python 3.10は入っていませんか？

ただ、ここで慌ててOSのPythonを入れ替えようとするのはおすすめしません。同じ3.10でも、OSに最初から入っているものと、自分で入れたものとでは、やるべきことがまったく違うからです。

今日は、その違いを中心に、Python 3.10の終了で何を確認すればいいのかを整理していきます。

Python 3.10のサポート終了で、何が変わったのか？¶

まず、Pythonのサポートの決まりを確認しておきます。

Pythonは毎年10月ごろに新しいバージョンが出て、それぞれ約5年間サポートされます。最初の約2年はバグ修正も入り、残りの期間はセキュリティ修正だけになります。

3.10は2021年10月に出たバージョンなので、5年たってちょうど終わりを迎えたことになります。いまのバージョンごとの状況を表にまとめます。

3.10.22と同じ日に、3.11.17・3.12.15・3.13.16・3.14.8もまとめて出ています。3.10だけが、これで打ち止めになったという形です。

サポート終了とは、Pythonの開発チームが新しい脆弱性を見つけても、3.10向けの修正版を出さなくなることです。プログラムが急に動かなくなるわけではありません。

3.10.22は、ソースコードだけの配布¶

もう1つ知っておきたいのが、配布の形です。

3.10は、セキュリティ修正だけの期間に入ってから、WindowsやmacOS向けのインストーラーが出ていません。バイナリのインストーラーが付いた最後の版は3.10.11です。

それ以降の3.10.12〜3.10.22は、ソースコードだけの配布でした。つまり、Windowsのインストーラーで入れた3.10は、3.10.11のまま止まっている可能性が高いです。

手元のPCで確認してみてください。

python3 --version
# Python 3.10.11 のように表示される

OSに入っているpython3は、すぐには困らない¶

ここからが本題です。

Linuxサーバーの多くは、OSのパッケージとしてpython3が最初から入っています。主なOSのデフォルトのバージョンを見てみましょう。

Ubuntu 22.04のpython3は、まさに今回終わった3.10です。

ただ、OSのpython3は、Pythonの開発チームではなくOSの配布元がメンテナンスしています。CanonicalはUbuntu 22.04向けに、3.10.12-1~22.04.x のような版でセキュリティ修正を出し続けてきました。

RHEL 9も同じ考え方です。Red Hatは、上流で2025年10月に終わったPython 3.9を、RHEL 9のサポート期間中は修正を当てながら維持すると説明しています。

つまり、OSに付いてきたpython3は、OSのサポート期間が切れるまではOSの更新で守られるということです。

実際にCanonicalが修正を出しているかは、パッケージの更新履歴で確認できます。

# いま入っているpython3.10のバージョン
dpkg -l | grep python3.10

# 更新履歴（CVE番号が並んでいれば、セキュリティ修正が入っている）
apt changelog python3.10 | head -40

# 未適用の更新があるか
apt list --upgradable 2>/dev/null | grep python3

OSのpython3を入れ替えてはいけない理由¶

「3.10は終わったから、OSのpython3を3.12に差し替えよう」と考える人もいるかもしれません。

これはやめておきましょう。cloud-initのように、OSの道具の中にはpython3で書かれているものがあります。/usr/bin/python3 の向き先を変えると、そうした道具が動かなくなることがあります。

OSのPythonを新しくしたいなら、OSごと新しいバージョンに上げるのが正しい順番です。Ubuntuなら22.04から24.04に上げれば、python3は3.12になります。

Ubuntu 22.04の標準サポートは2027年5月までなので、それまでにOSのアップグレードを計画しておけば十分間に合います。OSの選び方は『2026年のLinuxディストリビューション選び』も参考にしてください。

困るのは、自分で入れたPythonのほう¶

一方で、すぐに手を打ったほうがいいのは、OSのパッケージ以外の方法で入れたPythonです。

たとえば、次のようなものがあります。

これらは、OSの更新では直りません。上流の3.10が終わった以上、新しい脆弱性が見つかっても修正版は出てきません。

まずは、どこに3.10が残っているのかを洗い出すところから始めましょう。

# サーバー上にあるPythonの実体を探す
ls -l /usr/bin/python3* /usr/local/bin/python3* 2>/dev/null

# pyenvを使っている場合
pyenv versions

# リポジトリの中でpython:3.10のイメージを使っている箇所
grep -rn "python:3.10" --include="Dockerfile*" .

# 手元にあるイメージ
docker images | grep python

venvで作った仮想環境も見落としやすいところです。venvは作ったときのPythonを指しているので、中身を確認しておきます。

# 仮想環境が使っているPythonのバージョン
cat /path/to/venv/pyvenv.cfg
# version = 3.10.12 のように表示される

Lambdaのpython3.10ランタイムの期限¶

AWS Lambdaを使っているなら、ランタイムの期限も確認しておきましょう。

Lambdaの公式ドキュメントでは、python3.10 ランタイムの期限が次のように案内されています。

非推奨になった後も、関数はしばらくそのまま動きます。ただ、更新ができなくなると、障害が起きてもコードを直せません。

python3.10 ランタイムはAmazon Linux 2がベースです。AL2そのものも2026年6月に標準サポートが終わっているので、Amazon Linux 2023ベースの python3.12 以降に移すのが自然です。AL2からAL2023への違いは『Amazon Linux 2のサポート終了後に移行で変わること』にまとめています。

対象の関数は、AWS CLIで一覧にできます。

aws lambda list-functions \
  --query "Functions[?Runtime=='python3.10'].[FunctionName,Runtime]" \
  --output table

リージョンごとに結果が違うので、使っているリージョンをすべて確認してください。

洗い出してみると、思ったより多くの場所に3.10が残っていることがあります。全部を一度に移すのは大変なので、順番を決めて進めましょう。

優先したいのは、インターネットから直接リクエストを受けるものです。Webアプリや外部からのWebhookを受けるLambdaは、脆弱性を突かれたときの影響が大きくなります。社内だけで使う集計スクリプトなどは、そのあとでも構いません。

洗い出した結果は、場所・入れ方・移行先・担当者を表にしておくと、チームで進めやすくなります。

ライブラリのほうが先に3.10を外している¶

もう1つ、見落としやすい点があります。Python本体より先に、ライブラリやツールのほうが3.10を対象から外しているのです。

たとえば、NumPyは2.3系からPython 3.11以上が対象です。運用自動化でよく使うansible-coreも、2.20ではコントロールノードのPythonの最低バージョンが3.12になっています。

3.10のままだと、ライブラリを新しくしようとしても、pipが古いバージョンしか入れてくれません。セキュリティ修正の入ったライブラリを使えなくなるのが、実は一番困るところです。

移行先のバージョンはどう選ぶ？¶

では、どのバージョンに移せばいいのでしょうか。

移行先は、なるべくOSのデフォルトと同じバージョンにそろえるのがおすすめです。OSのパッケージと同じバージョンなら、OSの更新でセキュリティ修正を受けられるからです。

3.11にすると、2027年10月にまた同じ作業がやってきます。せっかく移すなら、サポート期間が長いバージョンを選んだほうが手間は少なくなります。

venvを作り直す手順¶

自分で作ったvenvは、中のPythonだけを差し替えることはできません。新しいPythonで作り直します。

# 1. いまのライブラリの一覧を書き出す
/path/to/old-venv/bin/pip freeze > requirements.txt

# 2. 新しいPythonで仮想環境を作る（Ubuntu 24.04の例）
python3.12 -m venv /path/to/new-venv

# 3. ライブラリを入れ直す
/path/to/new-venv/bin/pip install -r requirements.txt

# 4. 動作を確認してから、systemdのユニットやcronのパスを新しいvenvに向ける

pip freeze で固定したバージョンの中には、新しいPythonに対応していないものもあります。エラーが出たら、そのライブラリだけバージョンを上げて試してみてください。

移したあとに確認しておきたいこと¶

venvを作り直して動いたように見えても、それで終わりにしないほうが安全です。

よくあるのは、古いvenvのパスがどこかに残っているケースです。systemdのユニットファイル、cronの設定、シェルスクリプトの1行目（シバン）などに、古いパスが直接書かれていることがあります。

次のように検索して、古いパスが残っていないかを確かめておきましょう。

# 古いvenvやpython3.10を直接指している設定を探す
grep -rn "old-venv\|python3.10" /etc/systemd/system/ /etc/cron* /opt/ 2>/dev/null

Dockerイメージの場合も同じです。FROM のタグを python:3.12-slim に変えたら、イメージをビルドし直して、テストを通してからデプロイしてください。タグを変えただけで本番に出すと、ライブラリのビルドに失敗して起動しない、ということが起こりえます。

すべて移し終えたら、古いvenvや使わなくなったPythonは削除しておきます。残しておくと、半年後に誰かがうっかり古いほうを使ってしまう原因になります。

LinuxにPythonを入れる基本的な流れは『LinuxでPythonを使う方法』で解説しています。

Linuxの土台から学び直したい人へ¶

今回の話は、Pythonそのものというより、Linuxのパッケージ管理の考え方の話でした。

どのソフトを誰がメンテナンスしているのかが分かっていると、サポート終了のニュースを見ても、自分の環境で何をすればいいかを落ち着いて判断できます。先月のOpenSSL 3.0の終了（『OpenSSL 3.0のサポート終了』）も、同じ考え方で整理できます。

InfraAcademyでは、Linuxのパッケージ管理やサービスの管理を、順番に手を動かしながら学べる Linuxロードマップ を用意しています。こうした判断の土台を固めたい方は、のぞいてみてください。

まとめ¶

Python 3.10は、2026年10月1日の3.10.22を最後にサポートが終わりました。

ただ、対応の仕方は、どうやって入れたPythonかで分かれます。

• Ubuntu 22.04などOSのpython3は、OSのサポート期間中は配布元が修正を出す。入れ替えずにOSのアップグレードを計画する
• pyenv・ソースビルド・Dockerイメージ・venvは、自分で新しいバージョンへ移す
• Lambdaの python3.10 は2026年10月31日に非推奨。2027年3月3日には関数を更新できなくなる

まずは、ls や grep で、どこに3.10が残っているかを書き出すところから始めてみてください。場所さえ分かれば、あとは1つずつ移していくだけです。

参考¶

• Python Release Python 3.10.22（python.org）
• PEP 619 – Python 3.10 Release Schedule
• Status of Python versions（Python Developer's Guide）
• Lambda runtimes（AWS Lambda Developer Guide）
• Ubuntu release cycle（Canonical）
• Package: python3 (jammy)（Ubuntu Packages）
• Python 3.9 reaches end of life: What it means for RHEL users（Red Hat Developer）
• Technology Preview of Ansible Core 2.20 in Ansible Automation Platform（Red Hat）
• NumPy 2.3.3 Release Notes（NumPy）