Deprecation of Python 3.9 for Dependabot は、GitHub の Dependabot が Python 3.9 をサポート対象外にした変更です。管理者が最初に確認すべきことは、組織内のリポジトリに Python 3.9 前提の Dependabot 設定や依存関係解決が残っていないか、そして Dependabot の更新プルリクエストが止まっていないかです。
GitHub は公式 Changelog で、Python 3.9 を使い続けると Dependabot が依存関係更新のプルリクエストを作成しないリスクがあると説明しています。Python 3.9 はすでに end-of-life であり、Python 公式サイトでも 3.9 のサポート終了が示されています。この記事では、GitHub 管理者・Organization オーナー・リポジトリ管理者が確認すべき影響範囲、権限、監査、移行、社内周知のポイントを実務目線で整理します。(The GitHub Blog)
Deprecation of Python 3.9 for Dependabot で何が変わったのか
GitHub の告知内容はシンプルです。Dependabot は Python 3.9 をサポートしなくなりました。対象リポジトリで Python 3.9 を前提に依存関係を解決している場合、Dependabot が依存関係更新のプルリクエストを作成できなくなる可能性があります。(The GitHub Blog)
ここで重要なのは、「GitHub 上の Python プロジェクトが即座に壊れる」という話ではない点です。問題になるのは、Dependabot が Python 依存関係を解析・解決・更新する場面です。たとえば、pyproject.toml、requirements.txt、Pipfile、poetry.lock、uv.lock などを使っているリポジトリで、Python 3.9 固定の制約が残っていると、Dependabot の更新処理が失敗したり、更新 PR が作られなかったりする可能性があります。
なお、該当の GitHub Changelog ページは確認時点で「Retired」と表示されています。実務上は通常の新機能リリースではなく、「サポート終了対応」「依存関係更新基盤の保守対応」として扱うのが安全です。(The GitHub Blog)
影響を受ける可能性が高いリポジトリ
影響確認では、単に「Python を使っているか」ではなく、「Dependabot が Python 依存関係を更新しているか」を見ます。GitHub Docs では、Dependabot は対応する依存関係マニフェストやロックファイルを含むリポジトリに対して更新を設定でき、Python 系では pip、pipenv、pip-compile、poetry などが対象になります。pipenv や poetry を使う場合でも、dependabot.yml の YAML 値は package-ecosystem: "pip" を使う点に注意が必要です。(GitHub Docs)
| 確認対象 | 影響の見方 | 具体例 |
|---|---|---|
dependabot.yml | Python 依存関係を Dependabot が監視しているか | package-ecosystem: "pip" がある |
| Python バージョン指定 | 3.9 固定または 3.9 だけを許可していないか | requires-python = "==3.9.*"、python_version = "3.9" |
| ロックファイル | 古い Python 前提でロックされていないか | poetry.lock、Pipfile.lock、requirements.txt |
| CI 設定 | Dependabot PR の検証環境が 3.9 のままではないか | actions/setup-python で 3.9 を指定 |
| Docker イメージ | 実行環境やテスト環境が 3.9 固定ではないか | FROM python:3.9-slim |
| プライベート依存関係 | Dependabot が依存関係を解決できる権限を持つか | 社内 PyPI、GitHub Packages、社内リポジトリ参照 |
特に優先度が高いのは、本番系サービス、外部公開サービス、セキュリティ更新を Dependabot に依存しているリポジトリです。Dependabot security updates は、脆弱性のある依存関係に対して修正版へのプルリクエストを作る仕組みです。GitHub Docs では、Dependabot security updates は Dependency graph と Dependabot alerts が有効なリポジトリで利用できると説明されています。(GitHub Docs)
管理者向けチェックリスト
まずは、Organization 全体で対象リポジトリを洗い出し、リポジトリごとに「対応不要」「設定修正のみ」「アプリ側の Python 移行が必要」に分けます。
| チェック項目 | 管理者が確認すること | 判断基準 |
|---|---|---|
| 対象リポジトリの棚卸し | .github/dependabot.yml に package-ecosystem: "pip" があるか | ある場合は優先調査 |
| Python 3.9 固定の有無 | pyproject.toml、Pipfile、Dockerfile、CI を検索 | 3.9 固定なら移行対象 |
| Dependabot の稼働状況 | Dependency graph の Dependabot タブで直近ジョブを確認 | 直近のチェックが止まっていないか |
| セキュリティ更新 | Dependabot alerts と security updates が有効か | 脆弱性対応 PR が作られる状態か |
| プライベート依存関係 | Dependabot secrets、レジストリ設定、組織内リポジトリアクセスを確認 | 解決不能エラーがないか |
| CI の互換性 | 3.10 以上、できれば 3.11 以上でテストが通るか | テスト通過後に制約を更新 |
| 監査ログ | Dependabot 関連設定の変更履歴を確認 | 誰がいつ無効化・変更したか |
| 社内周知 | 開発チームに対応期限と確認観点を通知 | PR 放置や重複対応を防ぐ |
GitHub Docs では、Dependabot version updates は .github/dependabot.yml をリポジトリにコミットすることで有効化し、Dependency graph の Dependabot タブで監視対象や直近チェック状況を確認できると説明されています。(GitHub Docs)
GitHub 管理者が最初に使う検索クエリ例
Organization 管理者は、GitHub のコード検索で次のような条件を使うと、対象を素早く絞り込めます。YOUR_ORG は自社 Organization 名に置き換えてください。
org:YOUR_ORG "package-ecosystem: \"pip\"" path:.github/dependabot.ymlorg:YOUR_ORG "python-version: \"3.9\"" path:.github/workflowsorg:YOUR_ORG "FROM python:3.9"org:YOUR_ORG "python_version = \"3.9\""org:YOUR_ORG "requires-python" "3.9"org:YOUR_ORG ".python-version" "3.9"検索結果が多い場合は、次の順で優先順位を付けると実務で進めやすくなります。
| 優先度 | 対象 | 理由 |
|---|---|---|
| 高 | 本番サービス、外部公開サービス、決済・認証・個人情報を扱うリポジトリ | 脆弱性対応 PR が止まる影響が大きい |
| 高 | Dependabot alerts が開いたままのリポジトリ | セキュリティ更新が必要な状態 |
| 中 | Python 3.9 固定だが、CI が整っているリポジトリ | 移行 PR を比較的安全に進めやすい |
| 中 | プライベートレジストリを使うリポジトリ | 認証や解決エラーが起きやすい |
| 低 | アーカイブ済み、実験用、Dependabot 未使用のリポジトリ | 影響は限定的だが記録は残す |
権限と設定で確認すべきポイント
Dependabot 対応では、リポジトリ管理者だけで完結しないことがあります。Organization 設定、セキュリティ設定、プライベート依存関係へのアクセス、監査ログ確認が関係するためです。
| 作業 | 主に必要な権限 | 確認場所 |
|---|---|---|
dependabot.yml の修正 | リポジトリへの書き込み権限 | .github/dependabot.yml |
| Dependabot version updates の有効化 | リポジトリの設定変更権限または書き込み権限 | Settings → Advanced Security |
| Dependabot security updates の有効化 | リポジトリ管理者または組織のセキュリティ管理者 | Settings → Advanced Security |
| Dependabot alerts の確認 | 管理者、Organization owner、write/maintain 権限など | Security / Dependabot |
| Organization 全体の設定確認 | Organization owner | Organization settings |
| 監査ログ確認 | Organization owner | Organization settings → Audit log |
| プライベート依存関係アクセス設定 | Organization owner またはリポジトリ管理者 | Dependabot secrets、registries 設定 |
GitHub Docs では、Organization の audit log は組織に影響するアクションについて「誰が、何を、いつ行ったか」を確認でき、Organization owner がアクセスできると説明されています。また、audit log は直近 180 日分のイベントを扱い、created や action などの条件で絞り込めます。(GitHub Docs)
Python 3.9 からどのバージョンへ移行すべきか
Python 3.9 を避けるだけなら、サポート中の Python に移行すればよいという話になります。ただし、管理者視点では「サポート期間」「依存ライブラリの互換性」「CI の安定性」「本番環境のベースイメージ」を合わせて判断する必要があります。
Python 公式サイトでは、確認時点で Python 3.9 は end-of-life、Python 3.10 は security、Python 3.11 以降もサポート対象として掲載されています。特に Python 3.10 はサポート終了が近いため、長期運用を前提にするなら 3.11 以上を候補にするのが現実的です。最新の Python 3.14 に一気に上げる選択肢もありますが、依存ライブラリや本番環境の対応状況を確認してから進めるべきです。(Python.org)
| 移行先候補 | 向いているケース | 注意点 |
|---|---|---|
| Python 3.10 | 短期的に 3.9 固定を外したい場合 | サポート期間の余裕が小さい |
| Python 3.11 | 安定性と移行しやすさのバランスを取りたい場合 | 古い依存ライブラリの互換性確認が必要 |
| Python 3.12 | 中期運用を見据えて移行したい場合 | ビルド済み wheel がない依存関係に注意 |
| Python 3.13 / 3.14 | 新規開発や先行移行できるチーム | フレームワークやライブラリの対応状況を事前確認 |
実務では、まず 3.11 または 3.12 で CI を通し、依存ライブラリの問題が少なければ 3.13 以降を検討する流れが無難です。重要なのは、Dependabot 対応だけを目的に本番環境まで一気に上げないことです。まずはテスト環境と依存関係解決を通し、段階的に本番へ反映します。
移行作業の実務手順
対象リポジトリを分類する
最初に、対象リポジトリを次の 3 種類に分けます。
| 分類 | 状態 | 対応 |
|---|---|---|
| 対応不要 | Python 3.9 指定がなく、Dependabot も正常稼働 | 監視のみ |
| 設定修正のみ | CI や Dependabot 設定に 3.9 が残っている | 設定 PR を作成 |
| アプリ移行が必要 | requires-python や依存ライブラリが 3.9 前提 | 開発チームで移行計画を作成 |
この分類をせずに全リポジトリへ一律対応を始めると、重要度の低いリポジトリに時間を取られ、脆弱性対応が必要なリポジトリの確認が後回しになります。
Python バージョン指定を更新する
代表的な更新箇所は次のとおりです。
# pyproject.toml の例[project]
requires-python = “>=3.11,<4.0”
# Pipfile の例[requires]
python_version = “3.11”
# .python-version の例
3.11.9# Dockerfile の例
FROM python:3.11-slim# GitHub Actions の例
- uses: actions/setup-python@v6
with:
python-version: "3.11"ここでありがちな失敗は、GitHub Actions の python-version だけを変更して、pyproject.toml や Pipfile の制約を残してしまうことです。Dependabot の依存関係解決では、プロジェクト側のマニフェストやロックファイルが重要です。CI だけ 3.11 にしても、依存関係ファイルが 3.9 固定なら問題が残ります。
dependabot.yml を確認する
Python 系の Dependabot 設定では、package-ecosystem: "pip" を使います。Poetry や Pipenv を使っている場合でも、GitHub Docs では pip の YAML 値を使用するよう案内されています。(GitHub Docs)
version: 2
updates:
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "weekly"モノレポの場合は、Python プロジェクトがあるディレクトリごとに設定を分けます。
version: 2
updates:
- package-ecosystem: "pip"
directory: "/services/api"
schedule:
interval: "weekly"
- package-ecosystem: "pip"
directory: "/jobs/batch"
schedule:
interval: "weekly"移行直後は依存関係更新 PR が増えることがあります。PR の量を抑えたい場合は、更新頻度、グループ化、open-pull-requests-limit などを検討します。GitHub Docs では、Dependabot version updates を止める方法として dependabot.yml の削除のほか、特定のパッケージマネージャーを一時的に止めるために open-pull-requests-limit: 0 を使う方法も説明されています。(GitHub Docs)
プライベートレジストリと社内依存関係の確認
社内 PyPI、GitHub Packages、Artifactory、Nexus などのプライベートレジストリを使っている場合は、Python バージョン移行だけでは不十分です。Dependabot が依存関係を解決できる認証情報を持っているかを確認します。
GitHub Docs では、Dependabot のプライベートレジストリへのアクセスは Organization レベルまたは dependabot.yml で構成でき、組織レベルのレジストリではトークン、ユーザー名とパスワード、OIDC 認証がサポートされると説明されています。dependabot.yml では、トップレベルの registries と、各 updates ブロック内の registries を組み合わせて指定します。(GitHub Docs)
確認すべきポイントは次のとおりです。
| 確認項目 | よくある問題 | 対応 |
|---|---|---|
| Dependabot secrets | トークン期限切れ、権限不足 | トークン更新、最小権限で再発行 |
| レジストリ URL | 旧 URL やミラー先を参照 | 現行 URL に修正 |
| Python 3.11 以上の wheel | 社内パッケージが 3.9 用しかない | パッケージ再ビルド |
| 依存関係のソース制約 | PyPI と社内レジストリが混在 | registries とパッケージ制約を整理 |
| 同一 Organization 内のプライベート依存 | Dependabot にアクセス権がない | Organization 設定でアクセス許可 |
GitHub Docs では、Dependabot が更新を行うには対象の依存関係ファイルにアクセスできる必要があり、プライベートまたは内部の依存関係がある場合は追加のアクセス設定が必要になると説明されています。(GitHub Docs)
監査ログで確認すべきこと
Dependabot の移行対応では、「設定が正しいか」だけでなく、「いつ誰が変更したか」も確認しておくと後のトラブル対応が楽になります。特に複数チームが同じ Organization を管理している場合、誰かが一時的に Dependabot security updates を無効化したまま戻していないケースがあります。
監査ログでは次の観点を見ます。
| 監査観点 | 確認内容 |
|---|---|
| Dependabot 関連設定の変更 | 有効化・無効化の履歴 |
| Security 設定の変更 | Dependabot alerts、Dependency graph、security updates の状態 |
| 権限変更 | リポジトリ管理者、チーム、外部コラボレーターの変更 |
| secrets 更新 | Dependabot secrets やレジストリ認証情報の更新タイミング |
| 期間指定 | 2026年6月前後から現在までの変更履歴 |
GitHub の audit log は action や created などの条件で検索でき、必要に応じて JSON または CSV でエクスポートできます。ただし、Organization の audit log には保持期間やエクスポート上限があるため、必要な期間に絞って確認するのが現実的です。(GitHub Docs)
Dependabot のエラー確認方法
移行後は、Dependabot が実際に動いているかを必ず確認します。GitHub Docs では、Dependabot の更新が失敗したり想定外の動作をしたりした場合、Dependency graph から Dependabot job logs を確認できると説明されています。(GitHub Docs)
確認手順は次の流れです。
| 手順 | 操作 | 見るべきポイント |
|---|---|---|
| 1 | リポジトリを開く | 対象リポジトリが正しいか |
| 2 | Insights を開く | Dependency graph へ移動 |
| 3 | Dependency graph → Dependabot を開く | 監視対象の ecosystem と directory を確認 |
| 4 | Recent update jobs を確認 | 失敗しているジョブがないか |
| 5 | ログを開く | Python バージョン、依存関係解決、認証エラーを見る |
Dependabot security updates の場合、Dependabot が脆弱性修正 PR を作れないときは、アラート側にエラーが表示されることがあります。GitHub Docs でも、Dependabot が PR を作成できない場合、Dependabot alert にエラーメッセージが表示されると説明されています。(GitHub Docs)
失敗しやすいポイント
Python 3.9 固定を一部だけ残してしまう
最も多い失敗は、CI だけを 3.11 に変更して、pyproject.toml、Pipfile、Dockerfile、.python-version のどれかに 3.9 が残るパターンです。Dependabot の問題は依存関係解決に関係するため、バージョン指定は横断的に確認する必要があります。
いきなり最新 Python に上げてアプリを壊す
Dependabot 対応をきっかけに Python 3.14 へ一気に上げる判断は、すべてのプロジェクトで正解とは限りません。ライブラリ、フレームワーク、社内パッケージ、Docker ベースイメージ、CI の互換性を確認してから進めるべきです。特に古い C 拡張を含むライブラリは、移行先バージョンでビルドに失敗することがあります。
Dependabot の権限不足を Python の問題と誤認する
Dependabot が PR を作らない原因は、Python 3.9 だけとは限りません。プライベートレジストリの認証情報が期限切れ、社内パッケージへのアクセス権がない、ロックファイルが壊れている、依存関係の制約が厳しすぎる、といった原因でも失敗します。ログとアラートを確認し、原因を切り分けます。
PR の増加を想定していない
Python バージョン制約を更新すると、Dependabot が保留されていた更新を一気に提案することがあります。レビュアーが足りないチームでは、PR が滞留してかえって運用が悪化します。重要リポジトリから順に移行し、必要に応じて更新頻度やグループ化を調整します。
社内周知で伝えるべき内容
開発チームへの周知では、単に「Python 3.9 が非推奨です」と伝えるだけでは不十分です。各チームが何を確認し、いつまでに、どの状態なら完了なのかを明確にします。
周知文は次のようにまとめると、開発者が行動しやすくなります。
件名: Dependabot の Python 3.9 サポート終了に伴うリポジトリ確認のお願い
GitHub Dependabot で Python 3.9 がサポート対象外になりました。
Python 3.9 前提のまま依存関係更新を行っているリポジトリでは、Dependabot が更新 PR を作成できない可能性があります。
各チームで以下を確認してください。
- .github/dependabot.yml に package-ecosystem: "pip" があるか
- pyproject.toml、Pipfile、Dockerfile、GitHub Actions、.python-version に Python 3.9 固定が残っていないか
- Dependabot の直近ジョブに失敗が出ていないか
- Dependabot alerts に未対応の脆弱性が残っていないか
- プライベートレジストリを使う場合、Dependabot secrets が有効か
対応方針:
- 可能なリポジトリは Python 3.11 以上で CI を通してください
- 影響が大きい場合は、管理者チームに移行予定日とブロッカーを共有してください周知のポイントは、開発チームに「Dependabot の問題」と「アプリケーション実行環境の移行」を混同させないことです。まずは Dependabot が依存関係更新 PR を作れる状態を回復し、その後に本番環境の Python 移行を計画的に進めます。
管理者が次に取るべき行動
Deprecation of Python 3.9 for Dependabot への対応では、最初の 1 回で完璧に直すよりも、対象を漏れなく把握し、重要リポジトリから順に安全に移行することが重要です。
まず、Organization 全体で package-ecosystem: "pip" を含む dependabot.yml を検索し、Python 3.9 固定が残るリポジトリを抽出します。次に、本番影響や Dependabot alerts の有無で優先順位を付け、Python 3.11 以上で CI が通る状態を作ります。最後に、Dependabot の job logs と alerts を確認し、更新 PR が再び作成されることを確認します。
管理者の完了条件は、「Python 3.9 という文字列を消したこと」ではありません。Dependabot が対象リポジトリで依存関係を解決でき、必要な security updates と version updates の PR を作成できる状態に戻すことです。ここまで確認して初めて、GitHub の依存関係更新運用として安全な状態に近づきます。
コメント