先に結論
Dependabot を使っている Python repository は、2026-06-23 より前に Python 3.9 の残存箇所を洗い出したほうがいいです。
GitHub は 2026-05-19 に、Dependabot の Python 3.9 サポートを 2026-06-23 で終了 すると案内しました。
放置すると、Python 3.9 前提の repository で Dependabot が依存更新PRを作れなくなるおそれ があります。
大事なのは、CI のバージョン番号を 1 か所だけ直して終わりにしないことです。
- Dependabot が見る設定
- CI の setup-python
- Dockerfile や dev container
pyproject.tomlと lockfile の生成元
前提がばらけたままだと、更新後に別の場所で詰まります。
何が変わるのか
今回の主語は新機能ではなく、期限付きのサポート終了 です。
GitHub の changelog は、Python 3.9 がすでに end-of-life に達していることを踏まえ、2026-06-23 以降は Dependabot が Python 3.9 をサポートしないと明記しています。
同じ告知では、2026-05 時点の最新サポート版として Python 3.14 にも触れています。
ただし、ここで急いで「全員 3.14 に上げるべきだ」と読む必要はありません。
先に確認すべきなのは、いま自分の repository が 3.9 に依存しているかどうか です。
まず見るべき場所
最初に見るべきなのは、Python の実行バージョンが書かれている場所を広く拾うことです。
1. Dependabot が追う manifest と設定
dependabot.yml の対象 directory を確認し、その中にある pyproject.toml、requirements.txt、Pipfile、poetry.lock などを見ます。
とくに requires-python や生成元の Python バージョンが 3.9 前提のまま残っていないかが重要です。
2. CI の Python 指定
GitHub Actions なら actions/setup-python の version 指定を見ます。
ここだけを先に上げても、lockfile の生成元やローカル開発環境が 3.9 のままだと、PR は開いても差分の再現が揺れます。
3. Dockerfile と dev container
アプリ本体や依存解決を Docker で回しているなら、base image の Python が 3.9 のまま残っていないかを確認します。
更新PRが開いても、後段の test や build が古い image で落ちるなら、運用全体では止まったのとあまり変わりません。
4. lockfile を誰がどこで作るか
Poetry や pip-tools を使っている team では、lockfile の更新手順がローカル PC なのか CI job なのか self-hosted runner なのかを見ておくと後で楽です。
ここが 3.9 前提のままだと、Dependabot 本体だけ先に寄せても整合しません。
一番避けたいのは「一部だけ上げる」こと
今回いちばん起きやすい事故は、CI だけ直して安心することです。
たとえば、GitHub Actions の setup-python は 3.11 にしたのに、Dockerfile や requires-python や lockfile 生成手順が 3.9 のまま残るケースです。
この状態だと、更新PRは出ても merge 後の build が不安定になったり、ローカル再現だけ失敗したりします。
要するに、見るべき対象は Python 本体ではなく Python を前提にした更新経路全体 です。
先にやると進めやすい順番
急いでバージョンアップ PR を量産するより、次の順番のほうが失敗しにくいです。
- Python 3.9 が残る repository を洗い出す
dependabot.ymlと manifest の差分を整理する- CI と Docker と lockfile 手順の前提を並べる
- どのサポート版へ上げるかを team で決める
- Dependabot の更新PRが通常どおり出るか確認する
このやり方なら、更新PRが止まってから慌てて原因を探すよりずっと楽です。
private registry の認証設計まで見直すなら、GitHub Dependabot OIDC support update｜Cloudsmith / Google Artifact Registry を org-wide private registry に足す前に確認すべきこと もつながります。
CI/CD 全体の境界まで広く見たいなら、GitHub Actions security roadmap 2026 で何が変わる？CI/CD セキュリティ選定ガイド が参考になります。
誰から動くべきか
今回すぐ動く価値が高いのは、Python を主力で使い、Dependabot で更新運用を回している team です。
とくに次の条件があるなら優先度は高めです。
- 複数 repository で Python バージョンがそろっていない
- lockfile 更新を自動化している
- self-hosted runner や Docker image に古い runtime が残りやすい
- security fix を Dependabot 任せにしている
逆に、Python を使わない repository や、Dependabot の対象が npm / Docker だけの repository なら、この告知は直接の優先事項ではありません。
今の時点で言えること
今回の changelog は短いですが、実務影響は軽くありません。
2026-06-23 までに、Python 3.9 がどこに残っているかを把握しておく。
まずはこれで十分です。
そのうえで、Dependabot、CI、Docker、lockfile 生成元の前提をそろえれば、更新PRが止まるリスクはかなり下げられます。
一気に最新へ上げる判断より、止まる前に棚卸しする判断 のほうが先です。