Deprecation of Python 3.9 for Dependabotとは？期限と移行対応を実務目線で整理

Deprecation of Python 3.9 for Dependabot は、GitHub の Dependabot が Python 3.9 をサポート対象から外した変更です。結論から言うと、Python 3.9 を前提にしたリポジトリでは、Dependabot が依存関係更新の Pull Request を作成できなくなる可能性があります。2026年6月24日時点で優先すべき対応は、pyproject.toml、setup.cfg、Dockerfile、GitHub Actions、.github/dependabot.yml を確認し、Python 3.9 固定をサポート中の Python へ移行することです。GitHub Changelog では、Python 3.9 が EOL に達したため、2026年6月23日以降 Dependabot が Python 3.9 をサポートしないと説明されています。 (The GitHub Blog)

Deprecation of Python 3.9 for Dependabot の期限・移行対応で見落としやすい点

今回の変更は、アプリケーション本体が突然停止するという意味ではありません。見落としやすいのは、Dependabot による依存関係更新の自動化が静かに止まるリスクです。

Python 3.9 のままでもアプリや CI が一見動いていると、対応を後回しにしがちです。しかし、Dependabot が依存関係を解決できず、セキュリティアップデートや通常のバージョン更新 PR が作られなくなると、脆弱性対応の初動が遅れます。

確認項目	内容
変更日	2026年6月23日
対象	Python 3.9 を使う Dependabot の更新処理
主な影響	依存関係更新 PR が作成されない可能性
課金への直接影響	該当 Changelog では新たな課金変更は示されていない
優先対応	Python 3.9 固定を洗い出し、サポート中の Python へ移行
実務上の扱い	GitHub Changelog 上は「Retired」として表示されており、廃止対応として管理するのが安全

GitHub の告知では、Python 3.9 を使い続けると Dependabot が依存関係更新の Pull Request を作成しないリスクがあると明記されています。分類名を「Release」と見るか「Retired」と見るかよりも、実務では「自動更新が止まる可能性のある廃止対応」として扱うのが重要です。 (The GitHub Blog)

影響を受ける可能性が高いリポジトリ

影響を受けやすいのは、単に GitHub Actions で python-version: 3.9 を使っているリポジトリだけではありません。Dependabot が Python 依存関係を解決する際に参照するファイルや、プロジェクトの対応 Python バージョン指定が 3.9 に固定されている場合も確認が必要です。

確認場所	典型的な記述例	見るべきポイント
pyproject.toml	requires-python = ">=3.9,<3.10"	Python 3.9 のみを許可していないか
setup.cfg / setup.py	python_requires=">=3.9,<3.10"	パッケージメタデータが 3.9 固定でないか
Pipfile	python_version = "3.9"	Pipenv の実行環境が 3.9 固定でないか
.python-version	3.9.x	pyenv などのローカル実行環境が古くないか
Dockerfile	FROM python:3.9	コンテナベースイメージが 3.9 のままか
GitHub Actions	python-version: "3.9"	CI のテスト対象が 3.9 のみになっていないか
tox.ini / noxfile.py	py39	テスト環境が 3.9 前提になっていないか
.github/dependabot.yml	package-ecosystem: "pip"	Python 依存関係更新の対象ディレクトリが正しいか

GitHub Docs では、Dependabot の Python 系エコシステムとして pip、pipenv、pip-compile、poetry が整理されており、Poetry や Pipenv を使う場合も dependabot.yml では package-ecosystem: "pip" を使うと説明されています。つまり、プロジェクトで Poetry を使っているから無関係、とは判断できません。 (GitHub Docs)

まず確認すべきチェックリスト

最初にやるべきことは、全リポジトリの中から Python 3.9 固定を探すことです。規模が小さい場合は手作業でも対応できますが、組織内に複数リポジトリがある場合は、検索で一括確認した方が漏れを減らせます。

git grep -nE 'python-version|python_requires|requires-python|FROM python:3\.9|python:3.9|3\.9'

この検索結果をすべて機械的に置換するのは危険です。たとえば、README の古い説明、テスト対象として残している py39、互換性メモの 3.9 など、移行対象ではない記述も混ざります。実務では、次の順番で確認すると判断しやすくなります。

優先度	確認するもの	対応判断
高	pyproject.toml、setup.py、setup.cfg	パッケージの対応 Python を決めるため最優先
高	Dockerfile、本番イメージ	実行環境に直結するため影響確認が必要
高	GitHub Actions の CI	移行後にテストが通るか確認する
中	Pipfile、poetry.lock、requirements 系ファイル	ロック再生成が必要になる場合がある
中	.github/dependabot.yml	Dependabot が対象ファイルを見ているか確認する
低	README、ドキュメント	移行後に利用者向け説明を更新する

ポイントは、CI の Python バージョンだけを上げて終わりにしないことです。pyproject.toml の requires-python が Python 3.9 固定のままだと、Dependabot やパッケージ解決の挙動が期待通りにならない可能性があります。

移行先の Python バージョンはどう選ぶべきか

移行先は、単に「3.9 より新しければよい」ではなく、サポート期間とライブラリ互換性を見て決める必要があります。Python.org のアクティブリリース一覧では、Python 3.9 は EOL、3.10 以降がサポート対象として掲載されています。ただし、Python 3.10 も 2026年10月にサポート終了予定のため、今から移行するなら長めに使えるバージョンを選ぶのが現実的です。 (Python.org)

バージョン	2026年6月時点の見方	実務でのおすすめ度
Python 3.14	新しい安定系として有力	新規開発や検証環境から採用候補
Python 3.13	比較的新しく、サポート期間も長い	多くのプロジェクトで有力候補
Python 3.12	既存ライブラリとの互換性を見やすい	安定重視の移行先として現実的
Python 3.11	まだサポート中だが期限は短め	短期移行や互換性重視なら候補
Python 3.10	2026年10月にサポート終了予定	今からの本格移行先としては避けたい
Python 3.9	EOL	移行対象

迷った場合は、まず Python 3.12 または 3.13 で CI を通し、主要ライブラリの対応状況を見てから 3.14 を検討する進め方が堅実です。ライブラリのバイナリ配布、フレームワークの対応状況、OS パッケージとの組み合わせによっては、最新版へ一気に上げるより段階移行の方が安全です。

Dependabot 設定で確認するポイント

Dependabot の設定ファイルは、通常 .github/dependabot.yml に置きます。GitHub Docs では、version、updates、package-ecosystem、directory または directories、schedule.interval が主要な必須項目として整理されています。 (GitHub Docs)

Python 依存関係を更新する基本形は次のようになります。

version: 2
updates:
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "09:00"
      timezone: "Asia/Tokyo"
    open-pull-requests-limit: 5
    labels:
      - "dependencies"
      - "python"

複数ディレクトリに Python プロジェクトがある場合は、ルートだけでなく対象ディレクトリを追加します。たとえば、backend/ と worker/ に別々の pyproject.toml があるのに directory: "/" だけを指定していると、Dependabot が期待したファイルを見ていない可能性があります。

version: 2
updates:
  - package-ecosystem: "pip"
    directories:
      - "/backend"
      - "/worker"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "09:00"
      timezone: "Asia/Tokyo"

ただし、dependabot.yml を直すだけでは Python 3.9 の移行は完了しません。requires-python、Docker イメージ、CI、ロックファイル、ランタイムの整合性をそろえる必要があります。

移行作業の実務手順

Python 3.9 からの移行は、依存関係管理と実行環境を同時に見ると失敗しにくくなります。

手順	作業内容	完了基準
1	Python 3.9 固定箇所を検索	対象ファイル一覧ができている
2	移行先 Python を決める	3.12、3.13、3.14 など候補が決まっている
3	requires-python を更新	パッケージメタデータが新バージョンを許可している
4	Docker / devcontainer を更新	開発環境と本番相当環境が新 Python で起動する
5	CI の Python バージョンを更新	テスト、lint、型チェックが通る
6	ロックファイルを再生成	poetry.lock、Pipfile.lock、requirements 系が整合している
7	Dependabot のジョブを確認	対象ファイルが監視され、エラーが出ていない
8	既存 PR とリリース手順を確認	更新 PR を安全にマージできる

移行後は、Dependabot が実際に動いているかを必ず確認してください。GitHub Docs では、Dependabot が監視している依存関係はリポジトリの Insights から Dependency graph、Dependabot で確認でき、対象が抜けている場合はログや設定ファイルを見直すよう案内されています。 (GitHub Docs)

移行時に失敗しやすいポイント

CI だけ Python 3.11 にして満足してしまう

GitHub Actions の actions/setup-python を 3.11 や 3.12 に変えるだけでは不十分です。pyproject.toml の requires-python、Dockerfile の FROM python:3.9、.python-version が古いままだと、開発環境・本番環境・Dependabot の見ている前提がずれます。

Python 3.10 を移行先にして再対応が近くなる

Python 3.10 は 3.9 より新しいものの、サポート期限が近いバージョンです。短期的な互換性確保として選ぶことはありますが、2026年後半以降も継続運用するリポジトリでは、3.12 以降を優先して検証する方が手戻りを減らせます。Python.org のサポート表では、Python 3.10 のサポート終了は 2026年10月と示されています。 (Python.org)

ロックファイルを再生成せずに PR だけ通そうとする

Poetry、Pipenv、pip-tools などを使っている場合、Python バージョンを変えると解決される依存関係が変わることがあります。pyproject.toml だけを直してロックファイルを更新しないと、CI や Dependabot の更新 PR で不整合が出やすくなります。

プライベートレジストリの認証を見落とす

社内 PyPI、GitHub Packages、Artifactory、Nexus などを使っている場合、Dependabot が依存関係を解決するにはレジストリへのアクセスが必要です。GitHub Docs では、Dependabot にプライベートレジストリやプライベートパッケージへのアクセス権を与えられること、認証情報は Dependabot secrets や dependabot.yml から参照できることが説明されています。 (GitHub Docs)

Dependabot のログを見ずに「PR が来ない」と判断する

Dependabot の PR が来ない場合、単に更新がないのではなく、ジョブが失敗している可能性があります。GitHub Docs では、Dependabot のジョブログにジョブ種別、実行時刻、関連 PR、失敗時のエラーメッセージなどが記録されると説明されています。 (GitHub Docs)

課金面で確認すべきこと

今回の Python 3.9 廃止告知そのものは、課金体系の変更を主題にしたものではありません。実務上の主な影響は、Dependabot による依存関係更新 PR の作成可否です。 (The GitHub Blog)

一方で、Dependabot は GitHub Actions ランナー上で実行されるため、組織の Actions 運用ポリシーとは切り離さずに確認する必要があります。GitHub Docs では、Dependabot が有効な場合、Dependabot のジョブは GitHub Actions で実行され、標準 GitHub ホストランナーまたはセルフホストランナーで実行する Dependabot は GitHub Actions の含まれる分数にカウントされず、larger runners を使う場合は通常料金で課金されると説明されています。 (GitHub Docs)

利用形態	課金面の見方
標準 GitHub ホストランナーで Dependabot を実行	通常は Actions 分数にカウントされない
セルフホストランナーで Dependabot を実行	通常は Actions 分数にカウントされないが、運用コストは自社側
larger runners で Dependabot を実行	通常料金で課金対象
この Python 3.9 廃止告知	追加課金ではなく、サポート対象外化による自動更新リスクが中心

GitHub Actions の課金ドキュメントでも、標準的な GitHub ホストランナーの無料使用対象として Dependabot が挙げられています。ただし、larger runners は常に課金されるため、Dependabot を高性能ランナーに寄せている組織では設定を確認しておくべきです。 (GitHub Docs)

移行後に確認するべき状態

移行作業は、コードを直してマージしただけでは終わりません。Dependabot が継続的に PR を作成できる状態になっているかを確認して完了です。

確認項目	確認方法	OK の目安
Python 3.9 固定が残っていない	git grep やリポジトリ検索	意図しない固定がない
CI が新 Python で通る	GitHub Actions の実行結果	テスト、lint、型チェックが成功
ロックファイルが整合している	poetry lock、pip-compile など	差分が説明できる
Dependabot 対象が表示される	Insights → Dependency graph → Dependabot	対象マニフェストが表示される
ジョブログに致命的エラーがない	Dependabot job logs	認証・解決・互換性エラーがない
PR 運用が詰まっていない	open PR 数や reviewer 設定	更新 PR がレビュー可能な量に収まる

特に、open-pull-requests-limit を低く設定している場合、古い Dependabot PR が残っていて新しい PR が出にくくなることがあります。Python 移行後は、古い PR を整理し、必要に応じて一度クローズして再作成させると運用がすっきりします。

まとめ：Python 3.9 固定の棚卸しを先に終わらせる

Deprecation of Python 3.9 for Dependabot で最も重要なのは、2026年6月23日以降、Python 3.9 を使い続けるリポジトリでは Dependabot の依存関係更新 PR が作成されない可能性がある点です。アプリが今動いているかどうかではなく、セキュリティアップデートを自動で受け取れる状態を維持できるかで判断してください。 (The GitHub Blog)

今すぐ行うべきことは明確です。まずリポジトリ内の Python 3.9 固定を洗い出し、requires-python、Docker、CI、ロックファイル、Dependabot 設定をそろえて更新します。そのうえで、Dependabot の監視対象とジョブログを確認し、更新 PR が作成できる状態まで確認してください。

Python 3.9 からの移行は、単なるバージョンアップではなく、依存関係更新の自動化とサプライチェーンセキュリティを維持するための運用対応です。後回しにするほど、脆弱性対応の遅れや移行差分の肥大化につながります。まずは主要リポジトリから Python 3.9 固定を検索し、影響度の高いものから順に移行計画へ落とし込みましょう。