LASSIC Media らしくメディア
Python3.9サポート終了とバージョンアップ移行の外注
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Python 3.9のサポート終了スケジュールと、放置した場合に生じるリスクを整理します。
- 3.11・3.12・3.13という移行先の選択肢を、性能改善・API変更の観点で比較します。
- 依存ライブラリ互換や回帰テストなど、内製で移行を進める際の難所を解説します。
目次
Python 3.9は2025年10月末でサポート終了
Python 3.9とは、2025年10月31日にコミュニティサポートが終了したPythonのマイナーバージョンである*1。2020年10月にリリースされ、以降約5年間のサポート期間を経て、バグ修正・セキュリティパッチの提供が完全に停止した状態を指す*1。
Pythonの公式ドキュメント（devguide.python.org）では、各マイナーバージョンのリリースから約5年間を機能追加・バグ修正・セキュリティ修正の3段階に分けて管理している*1。3.9はこの5年サイクルを終え、以降は脆弱性が見つかっても修正版が提供されない状態にある。
2026年7月時点でサポートが継続しているのは、3.10（2026年10月まで）・3.11（2027年10月まで）・3.12（2028年10月まで）・3.13（2029年10月まで）である*1。移行先を検討する際は、このサポート残存期間も判断材料になるでしょう。
サポート終了後も3.9を使い続けるリスク
サポート終了（EOL、End of Life。ソフトウェアの開発・保守が終了する時点を指す）後も3.9を使い続けると、複数の観点でリスクが積み重なります。まず、CPython本体に新たな脆弱性が発見されても、Python Software Foundationから修正パッチが提供されません*1。脆弱性対応を自社で行うには、CPythonのソースコードを追跡し、パッチを自前で当てる体制が必要になります。
次に、サードパーティ製ライブラリの側でも3.9向けのホイール（ビルド済みパッケージ）提供を段階的に停止する動きが進みます。ライブラリの最新版がインストールできず、セキュリティ修正を含む更新が受けられない状態が生じやすくなるでしょう。
さらに、クラウドサービス側のマネージドランタイム（AWS LambdaやAzure Functionsなど、実行環境をクラウド事業者が管理するサービス）でも、EOLを迎えたバージョンのサポートは順次終了します。新規デプロイができなくなったり、既存環境の強制アップグレードが発生したりする可能性があるため、移行の先送りは選択肢を狭める結果につながりやすいと言えます。
脆弱性対応が遅れた状態で本番稼働を続けると、外部からの攻撃を受けた際に自社の脆弱性管理体制そのものが問われかねません。取引先からセキュリティ対応状況の照会を受けた場合に、サポート終了バージョンの継続利用を説明せざるを得ない状況は、B2Bの取引関係において望ましいものではないでしょう。
3.11・3.12・3.13、移行先3バージョンの比較
3.9からの移行先としては、現在サポート中の3.10〜3.13が候補になります。ここでは実務上の選択肢として挙がりやすい3.11・3.12・3.13を比較します。それぞれサポート残存期間・性能改善・言語機能の観点で特徴が異なるためです。
| バージョン | サポート終了 | 主な特徴 | 選びやすいケース |
|---|---|---|---|
| Python 3.11 | 2027年10月*1 | Faster CPythonプロジェクトによる実行速度改善が中心。3.10比で60%高速化した処理もあるとされる*2。 | 依存ライブラリの3.12対応が未確認で、まずは実績のある版に留めたい場合。 |
| Python 3.12 | 2028年10月*1 | 型パラメータ構文（PEP 695）やf-string仕様の緩和など言語機能が拡張。distutilsが標準ライブラリから削除された*3。 | 型ヒントを本格活用し始めたい・新しい言語機能を使ったコードを書きたい場合。 |
| Python 3.13 | 2029年10月*1 | PEP 594に基づき、telnetlibやcgiなど古い標準ライブラリモジュールが削除された*4。サポート残存期間が最も長い。 | 今回の移行を数年単位で長持ちさせたい・レガシーモジュール依存が少ない場合。 |
3.11は実行速度の改善効果が大きく、依存ライブラリへの影響も比較的小さいため、移行の第一歩として選ばれやすいバージョンです。一方、3.12以降は言語機能・標準ライブラリの変更が加わるため、依存関係の精査に時間を要する傾向があります。
一括移行と段階移行、どちらを選ぶか
移行の進め方には、全システムを一度に最新版へ切り替える一括移行と、システムごとに段階を分けて進める段階移行の2つがあります。どちらを選ぶかは、対象システムの数・依存関係の複雑さ・許容できる停止時間によって変わるでしょう。
一括移行は、移行作業そのものは一度で完了する利点があります。ただし対象システムが複数にわたる場合、依存ライブラリの互換確認と回帰テスト（既存機能が壊れていないかを確認するテスト）を同時並行で進める必要があり、検証工数が短期間に集中しやすい点に留意が必要です。
段階移行は、優先度の高いシステムから順に移行し、問題が発生した際の影響範囲を限定できる進め方です。反面、移行期間中は複数のPythonバージョンが混在するため、CI/CD環境（継続的インテグレーション・継続的デリバリー環境）を複数バージョン対応にしておく管理コストが発生します。
3.9から見た主な非推奨・削除API
3.9から3.11・3.12・3.13へ移行する際に確認すべき変更点は多岐にわたります。ここでは実務でつまずきやすい論点をH3で分けて解説します。
標準ライブラリの削除モジュール（PEP 594）
Python 3.13では、PEP 594（標準ライブラリから使われなくなった古いモジュールを削除する提案）に基づき、telnetlib・cgi・cgitb・nntplib・smtpdなど19の古いモジュールが標準ライブラリから削除された*4。これらのモジュールを利用しているコードは、3.13へ移行する前に代替ライブラリへの置き換えが必要になります。
distutilsの削除とsetuptoolsへの移行
ビルド設定に使われてきたdistutilsパッケージは、Python 3.12で標準ライブラリから削除された*3。長年distutilsに依存していたビルドスクリプトは、サードパーティのsetuptoolsパッケージへ置き換える対応が求められます。
型ヒント関連の構文拡張
Python 3.12では、ジェネリッククラス・関数を簡潔に書ける型パラメータ構文（PEP 695）が追加された*3。3.9時点の型ヒントの書き方（TypeVarを個別に定義する方式）は引き続き動作するものの、新構文への統一を検討する余地があるでしょう。
実行速度の改善とC拡張への影響
Python 3.11では、実行中の型の変化が少ない箇所を検出して処理を最適化するSpecializing Adaptive Interpreter（PEP 659）が導入され、3.10比で平均1.25倍、処理によっては60%の高速化が確認されている*2。この最適化はPython実装のコードに主に作用するため、NumPyのようなC拡張（C言語で実装された拡張モジュール）中心の処理では、恩恵の度合いが異なる点に注意が必要です。
内製で移行を進める際に立ちはだかる難所
3.9からの移行を内製で進める場合、いくつかの技術的な難所に直面しやすくなります。ここでは代表的な4点を整理します。
- 依存ライブラリの互換確認：requirements.txtに列挙された全パッケージについて、移行先バージョンでの動作確認が必要になります。パッケージ数が多いプロジェクトほど確認範囲が広がるでしょう。
- C拡張・ネイティブ依存の再ビルド：NumPyやPillowのようにC言語で実装された部分を含むライブラリは、Pythonバージョンごとにビルド済みバイナリ（ホイール）が異なります。対応ホイールが未提供の場合、ソースからのビルド環境を自前で用意する必要が生じます。
- 回帰テストの整備：既存のテストカバレッジが低いプロジェクトでは、非推奨API改修による挙動変化を検知できません。移行前にテストを補強する工程自体が追加の作業になります。
- CI/CD環境の更新：GitHub ActionsやJenkinsなどのCI設定でPythonバージョンを指定している場合、パイプライン定義ファイルの更新と、ビルドイメージの入れ替えが同時に必要になります。
これらの作業を内製で行うには、Python言語仕様の変更点を追える人材と、対象システムの依存関係を把握した人材の両方が必要です。社内で確保できない場合、移行スケジュールそのものが後ろ倒しになりやすいでしょう。
必要となる知識領域は、Python言語仕様の変更点・依存ライブラリのバージョニング・C拡張のビルド環境・CI/CD設定という広い範囲にわたります。対象システムが複数ある場合、これらを1〜2名の担当者だけで並行して対応するのは負荷が大きく、他の開発業務を圧迫しかねません。
移行を誤った場合の影響も見過ごせません。依存ライブラリの非互換を検知できずに本番へ反映すると、特定の処理でのみ発生する不具合が後から判明し、原因調査に時間を要することがあります。回帰テストが不十分な状態での移行は、こうした不具合の発見を遅らせるリスクを伴います。
移行を外部パートナーに委託するメリット
Python 3.9からのバージョンアップ移行を誤ると、依存ライブラリの非互換によるアプリケーション停止や、回帰テスト不足による本番障害のリスクがあります。特に複数システムが同一のPython環境を共有している場合、1つのシステムの移行不備が他システムにも影響しかねません。
移行作業を内製で行うには、依存関係の洗い出し・互換確認・回帰テスト整備・CI/CD更新という一連の工程を、限られた社内人材で並行して進める必要があります。外部の専門パートナーに委託すれば、こうした工程を体系的な進め方で実施できるうえ、移行後の運用保守まで一括して任せられる点も実務上の利点です。
まとめ：Python 3.9移行で押さえる3つの判断軸
本稿では、Python 3.9のサポート終了スケジュールと、3.11・3.12・3.13への移行を検討する際の論点を整理しました。要点を3つに集約すると次の通りです。第一に、3.9は2025年10月末でサポートが終了しており、放置すれば脆弱性対応やライブラリ更新の面でリスクが積み重なるでしょう。第二に、移行先は性能改善を重視するなら3.11、言語機能や長期サポートを重視するなら3.12・3.13が候補になります。第三に、依存ライブラリ互換・C拡張の再ビルド・回帰テスト・CI/CD更新という内製移行の難所は、専門パートナーへの委託によって解消しやすいと言えます。
よくある質問
Python 3.9をそのまま使い続けることはできますか。
技術的には起動・実行は可能ですが、2025年10月末以降は公式のバグ修正・セキュリティパッチが提供されません*1。脆弱性が発見されても自社で対応する必要があるため、業務システムでの継続利用は推奨されません。
3.10ではなく3.11以降を選ぶ理由はなんですか。
3.10のサポート終了は2026年10月と、3.11以降と比べて残存期間が短いためです*1。移行作業の頻度を抑えたい場合は、サポート期間がより長い3.11〜3.13を検討する価値があります。
移行にどのくらいの期間がかかりますか。
対象システムの規模・依存ライブラリの数・テストカバレッジによって幅があり、一律の目安を示すことは困難です。まずは依存関係の洗い出しと影響範囲の棚卸しから着手し、必要な工数を見積もる進め方が現実的です。
依存ライブラリが移行先バージョンに対応していない場合はどうすればよいですか。
代替ライブラリへの置き換え、または対応版がリリースされるまで移行を待つという選択肢があります。C拡張を含むライブラリの場合はソースからのビルドで対応できることもあるため、パートナーと相談しながら判断するとよいでしょう。
移行作業を外注する場合、契約形態はどのようになりますか。
依存関係の調査から改修・テストまでを一括で委託する請負契約が一般的です。移行後の運用保守を継続して依頼する場合は、別途保守契約を組み合わせる形になります。詳細は個別にご相談ください。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Python Software Foundation「Status of Python versions」（devguide.python.org）
- *2 出典：Python Software Foundation「What’s New In Python 3.11」（docs.python.org）
- *3 出典：Python Software Foundation「What’s New In Python 3.12」（docs.python.org）
- *4 出典：Python Software Foundation「PEP 594 – Removing dead batteries from the standard library」（peps.python.org）
