DjangoのEOLとサポート期限一覧【2026年8月】バージョン確認と移行判断

Djangoは約8か月ごとにフィーチャーリリースを出し、通常リリースは16か月、LTSは3年でサポートが切れます。2026年8月28日時点でサポートを受けられるのは5.2 LTS・6.0・6.1の3系統だけで、長く使われてきた4.2 LTSは2026年4月7日にEOLへ到達しました。この記事では、公式ダウンロードページとリリースプロセスの一次情報をもとに、各バージョンの終了日、稼働中プロジェクトのバージョン確認手順、DjangoとPythonの対応関係、EOL版からの移行順序を整理します。あわせて2026年8月10日に公表された年次リリースサイクルへの移行が、これから立てる3年計画に何をもたらすかも扱います。

まとめ：EOL版を残す条件と上げ先バージョンの決め方

結論から書きます。2026年8月時点で本番稼働しているDjangoが4.2以下なら、その環境はすでにセキュリティ修正を受け取っていません。上げ先は、外部公開しているサービスなら6.1、社内向けで改修頻度が低いなら2028年4月まで延びる5.2 LTSが基準になります。

判断を分ける軸は3つ。Django本体のサポート終了日、そこで動くPythonのサポート終了日、そして2027年4月の6.2 LTSを最後にLTSという区分が消えるという事実。Djangoだけを見て5.2 LTSを選ぶと、Python 3.10のまま残った環境が2026年10月にPython側で先に期限を迎えます。

アップグレードを見送ってよい場面もあります。外部から到達できないこと、コード改修が凍結されていること、撤去日が決まっていること。この3つが揃わないなら、見送りは先送りにしかなりません。判断の材料を、以下で順に具体化します。

8か月サイクルと3年LTSで決まるDjangoのサポート期限の構造

Djangoのサポート期限は日付を暗記するものではなく、リリースプロセスから機械的に導けます。構造を押さえると、公式表を見なくても自分の環境があと何か月もつか計算できる。前提となるフレームワーク自体の位置づけはDjangoとは？特徴・メリットとMVTの仕組みで確認してください。

フィーチャーリリース8か月とメインサポート・拡張サポートの16か月

公式のリリースプロセスでは、フィーチャーリリース（A.B形式）は約8か月ごとに出ます。あるバージョンは、次のフィーチャーリリースが出るまでの約8か月がメインストリームサポート期間で、ここではバグ修正が入る。その後さらに約8か月が拡張サポート期間となり、セキュリティ修正とデータ損失バグの修正だけを受け取ります。

つまり通常リリースの寿命は合計16か月です。6.0を例に取ると、メインサポートは6.1が出た2026年8月4日に終わり、拡張サポートは2027年4月まで。8か月ごとに上げ続ける運用でない限り、通常リリースを本番の長期基盤に据えると1年半で追われることになります。

LTSに指定されるX.2系と3年間のセキュリティ修正が届く範囲

3リリースに1回、X.2系がLTS（長期サポートリリース）に指定されます。実績は3.2・4.2・5.2、そして2027年4月予定の6.2。LTSは典型的に3年間、セキュリティ修正とデータ損失バグの修正を受け取ります。

注意したいのは、LTSでも新機能や通常のバグ修正が3年間入り続けるわけではない点です。5.2 LTSのメインサポートは6.0が出た2025年12月3日で終わっており、以後2028年4月までに入るのはセキュリティ修正とデータ損失バグ修正だけ。LTSだから放置して構わないという理解は、修正されないバグを抱え込む形になります。

セキュリティ修正が入るのは直近2リリースとLTSに限られる条件

Djangoがセキュリティ修正をバックポートする先は、mainブランチ、直近2つのフィーチャーリリース、そしてLTSブランチだけです。2026年8月時点なら6.1・6.0・5.2 LTSの3系統。この範囲から外れた瞬間、公開されたCVEに対する公式パッチは配布されません。

非推奨機能の扱いも同じプロセスに紐づきます。ある機能が非推奨になると、最低2つのフィーチャーリリースをまたいでから削除される決まり。4.2で非推奨になった機能は5.0と5.1では警告付きで動き、5.1で削除されます。この余裕があるうちに警告を潰しておけば、次のアップグレードでコードが動かなくなる事態を避けられます。

2026年8月時点で使えるバージョンとEOL済みバージョンの一覧

ここからは公式ダウンロードページの実データです。2026年8月28日時点の状態を、サポート中とサポート終了済みに分けて示します。

サポート中の5.2 LTS・6.0・6.1と終了日の対応表の読み方

サポートを受けられるのは次の3系統です。6.2は2027年4月のリリース予定で、参考として並べます。

最新は2026年8月5日にリリースされた6.1で、モデルフィールドのfetch mode、外部キーのDB側削除オプション、複数バックエンドを設定できるMAILERS、管理画面のアクセシビリティ改善が入りました。表の見方として押さえておきたいのは、5.2 LTSの拡張サポート終了（2028年4月）が6.1の終了（2027年12月）より4か月遅いこと。新しい版を選べば長く使えるとは限りません。

2026年4月7日にEOLへ到達した4.2 LTSと残存プロジェクト

4.2 LTSは最終リリース4.2.30をもって、2026年4月7日に拡張サポートが終了しました。国内で稼働しているDjangoアプリの多くが4.2で止まっているため、この日付は実務上の分水嶺です。

EOL到達後もアプリは動き続けます。壊れるのはコードではなく、修正が届く経路のほう。以後に公表されたCVEはすべて未修正のまま残り、時間の経過とともに件数だけが積み上がります。実際にどんな脆弱性が公表され、どれを緊急扱いにするかの判断はDjangoの脆弱性への対応とセキュリティリリースの追い方で扱っています。

EOL済みバージョンの終了日一覧と有償の延命サポートの位置づけ

すでにサポートが切れている主なバージョンは次のとおりです。

EOL版に対して第三者がパッチを提供する有償の延命サービスも存在します。ただしこれは移行の代替ではなく、移行までの時間を買う手段。契約期間中にアップグレードを終える計画とセットでなければ、翌年も同じ費用を払い続ける構図になります。延命に年額を払うくらいなら、その予算を一度の移行工数へ振り向けたほうが総額は下がるケースが大半です。

稼働中プロジェクトのDjangoバージョン確認と依存関係の点検手順

移行の前に、いま何が動いているかを確定させます。requirements.txt に書かれた値と、本番環境に実際に入っている値がずれている例は珍しくありません。

python -m django –version とpipで稼働版を確定させる手順

確認の起点は3つのコマンドです。仮想環境を有効にしたうえで python -m django --version を実行すると、そのインタープリタから見えるDjangoのバージョンが返ります。django-admin --version でも同じ値が取れますが、複数の仮想環境が混在する開発機では前者のほうが取り違えを防げる。

パッケージとしての導入状態は pip show django で確認します。インストール先のパスまで表示されるため、意図しないシステム側のPythonへ入っていないかも同時に判定できる。アプリケーション内部から取得したい場合は django.get_version() を呼びます。本番のバージョンは、デプロイ済みコンテナやサーバー上で実行して確かめてください。

requirementsと制約ファイルの固定値と実体のずれを洗う点検

次に見るのは依存の宣言側です。pip list --outdated を流すと、Djangoを含む更新可能なパッケージが一覧で出ます。ここでDjango本体だけでなく、django- で始まるサードパーティパッケージの状況も同時に把握しておくと、後の調査が一度で済みます。

点検で確認する項目は次の3点に絞れます。

• requirements.txt の指定が範囲指定になっており、環境ごとに違う版が入っていないか
• 制約ファイルやロックファイルがあり、本番と開発で同一の版が再現できるか
• Djangoに依存するパッケージが、上げ先バージョンに対応済みか

3点目が移行の所要時間をいちばん左右します。本体のアップグレード自体は半日で終わっても、対応版が出ていないパッケージが1つあるだけで計画は数か月単位で動く。ここを先に潰すかどうかで、見積もりの精度が変わります。

非推奨警告を-Waで先に洗い出して差分を見えるようにする実行

公式のアップグレード手順が最初に挙げるのが、非推奨警告の解消です。python -Wa manage.py test のように警告をすべて表示させた状態でテストを流すと、次のフィーチャーリリースで削除される機能を先に検出できます。

この工程を飛ばして本体だけ上げると、削除済みAPIの呼び出しがランタイムエラーとして本番で表面化します。警告を出す作業は現行バージョンのまま実施できるため、移行の意思決定より前に着手して差し支えない。テストカバレッジが薄いプロジェクトでは、警告が拾える範囲もその分狭くなる点は織り込んでおいてください。

DjangoとPythonの対応関係から決まるアップグレード先の組み合わせ

Djangoのバージョンを決めるとき、Python側の期限を同時に見ていないと計画が破綻します。DjangoのEOLだけを追った移行計画が1年で作り直しになる典型が、ここにあります。

5.2・6.0・6.1が受け付けるPythonの範囲を表で突き合わせる

公式FAQの対応表に、Python側のサポート終了予定を突き合わせたものが次の表です。

5.2 LTSがPython 3.14へ対応したのは5.2.8からで、LTSの途中で対応Pythonが追加される点も計画に効きます。6.0以降はPython 3.11以下を切っているため、3.11で動いている環境は6系へ上げる時点でPythonのアップグレードが同時に必要になる。Python側の変更点はPython 3.14の新機能とフリースレッド版の要点にまとめています。

Python 3.10のEOLが2026年10月に来る組み合わせの落とし穴

表の1行目が問題です。5.2 LTSはPython 3.10を受け付け、Django側の期限は2028年4月。ところがPython 3.10のセキュリティサポートは2026年10月に終わる予定で、Djangoより1年半早い。

5.2 LTSにしたから2028年まで安心、と判断した環境が、2か月後にはPythonインタープリタ側で未修正の脆弱性を抱え込む構図になります。Django公式も、Pythonのセキュリティサポートが切れた版をDjangoで使わないよう明記しています。上げ先を決める際は、Django側とPython側の終了日を並べて短いほうを計画の期限として採用してください。5.2 LTSを選ぶならPythonは3.12以上に揃える。これが最低条件です。

EOL版から現行バージョンへ上げる移行順序と本番反映までの段取り

上げ先が決まったら、順序を固定します。公式が示す原則は一度に1つのフィーチャーリリースずつで、4.2から6.1へ一足飛びに上げるやり方は推奨されていません。

4.2から5.2 LTSへ中間リリースを一段ずつ踏むアップグレード順序

4.2からの移行は、次の順で進めます。

1. 4.2の最終版（4.2.30）まで上げ、非推奨警告をすべて解消する
2. 5.0へ上げ、リリースノートの後方互換性の無い変更を潰してテストを通す
3. 5.1へ上げ、4.2で非推奨だった機能の削除に対応する
4. 5.2 LTSへ上げ、Pythonを3.12以上に揃えて本番相当環境で通す
5. 外部公開サービスなら、続けて6.0・6.1と段階的に上げる

一段ごとにテストを通す手間は増えますが、失敗したときに原因が1リリース分の差分に限定されます。まとめて上げて落ちた場合、どのリリースの変更が原因か切り分けるコストのほうが高くつく。各段でスキーマ変更が発生するため、マイグレーションの適用と巻き戻しの扱いはDjango migrateの実務と本番適用・巻き戻しの手順を前提にしてください。

サードパーティパッケージの対応状況を先に確定させる事前調査の手順

本体を上げる前に、依存パッケージ側の対応状況を全件確認します。調べる順番は、まずPyPIの最新版が上げ先Djangoをメタデータで宣言しているか、次にGitHubのIssueやChangelogで対応予定が示されているか、最後に代替パッケージが存在するか。

ここで未対応が見つかったパッケージは、対応待ち・自前フォーク・置き換え・機能ごと廃止の4択になります。対応待ちを選ぶなら、いつまで待つかの期限を先に決めておく。期限のない待機は、そのままEOL版での運用継続に変わってしまいます。

本番反映の切り替え順序とロールバック先を事前に決めておく段取り

本番反映では、コードの入れ替えとマイグレーション適用の順序を先に決めます。後方互換のあるスキーマ変更を先に流し、コードを入れ替え、不要になった列の削除は次回に回す。この分割にしておくと、切り戻しがコードの巻き戻しだけで済みます。

静的ファイルの再収集、設定値の差分、依存のインストール順といった本番構成側の詰めはDjangoのデプロイ手順とgunicorn＋nginx構成にまとめてあります。自社に追従を続ける体制がない、あるいは前回の移行から数年空いていて手順が残っていない場合は、保守運用・内製化支援で調査から移行、以後のバージョン追従までを引き受けています。

2028年の年次リリース移行でLTSという区分が消える影響と備え

2026年8月10日、Django公式ブログとDEP 20で、リリースサイクルそのものの変更が公表されました。これから3年計画を立てるなら、この変更を織り込まないと前提がずれます。

毎年1月リリース・全リリース3年サポートへ変わる新しい運用体系

変更点は3つです。バージョン番号がYYYY.N形式のカレンダーバージョニングになり、最初の適用版は従来なら7.0にあたる Django 2028。リリースは2028年1月から毎年1月の年1回になります。そして各リリースが一律で3年（正確には35か月）サポートされ、1年目がメインストリーム、2〜3年目がセキュリティとデータ損失修正のみという内訳。

結果として、LTSという特別な区分は無くなります。全リリースが同じ3年コミットメントを持つため、LTSを選ぶか通常リリースを選ぶかという分岐自体が消える。Python対応も、各リリースが公開時点の最新3バージョンを受け付け、メインストリーム1年目の10月に新しいPythonへの対応を追加する形へ整理されます。

6.2 LTSが最後のLTSになる前提で考える3年計画の立て方

移行期間に出るのは6.1（2026年8月）と6.2 LTS（2027年4月）だけで、6.2が最後の従来型LTSです。6.2のサポート終了は2030年4月。ここから逆算すると、取るべき道は2つに絞れます。

ひとつは6.2 LTSで止めて2030年4月まで引っ張り、その間に年次リリースへの追従体制を整える道。改修頻度が低い社内システムはこれで足ります。もうひとつは6.1から6.2、そして Django 2028 へ順に追従し、以後は毎年1月のリリースに合わせて年1回の更新を定例化する道。年1回で済むぶん、8か月ごとに追われる現行サイクルより計画に組み込みやすくなる。

避けたいのは、2027年4月の6.2 LTSを逃して6.1のまま2027年12月を迎える形です。通常リリースの16か月が切れた状態から、いきなり Django 2028 まで飛ぶ移行になります。この3年計画をそもそも引き受けるべきかという採用側の判断は、Djangoの将来性を2026年8月の数値で判断で条件を数値にして整理しています。

アップグレードを見送ってよい条件と見送りが破綻する3つの分岐点

すべてのDjangoアプリを常に最新へ追従させる必要はありません。ただし見送りには条件があり、条件を満たさないまま止めるのは判断ではなく先送りです。ここは条件で言い切ります。

見送ってよいのは非公開・凍結済み・撤去日が確定の3条件が揃う場合

アップグレードを見送ってよいのは、次の3つが同時に成立するときだけです。

• インターネットから到達できない（閉域網に限定され、認証済み利用者しかアクセスしない）
• 機能追加が凍結され、コードへの変更が発生しない
• 撤去または後継システムへの切り替え日が、意思決定を伴う形で確定している

3条件が揃うなら、残りの寿命が2年を切ったEOL版をそのまま運用するのは合理的な判断です。移行工数を、撤去が決まったシステムに投じる理由がない。逆に、いまは影響が出ていないという一点だけを根拠にした見送りは条件ではなく感覚であり、次の分岐点で必ず破綻します。

破綻する分岐点はCVE公開・Python側のEOL・依存の打ち切り

見送りが成立しなくなる分岐点は3つです。第1に、そのバージョンに該当するCVEが公表されたとき。EOL版には公式パッチが出ないため、自前でのバックポートか緊急移行のどちらかを選ぶことになり、計画的な移行より工数が膨らみます。

第2に、Python側がEOLを迎えたとき。Djangoの版を据え置いたままでも、インタープリタ側の未修正脆弱性は残る。第3に、依存パッケージが旧Django向けのリリースを打ち切ったとき。1つでも該当したら、そこが移行を開始する期日です。

見送りを選んだ場合に必ず決めておく撤退期限と異常検知の仕組み

見送りを選ぶなら、あわせて2つを文書化します。撤退期限（この日を過ぎたら無条件で移行に着手する日付）と、分岐点を検知する仕組み。検知は、Djangoのセキュリティ告知の購読と、依存パッケージの脆弱性通知の2系統で足ります。

期限と検知のない見送りは、数年後に動いているから触れないシステムとして残ります。4.2 LTSがEOLを迎えた2026年4月の時点で、3.2や4.0のまま止まっている環境が国内に相当数残っているのは、この決めをしなかった結果です。

よくある質問

Djangoのバージョンとサポート期限について、実務で問い合わせの多い点をまとめます。

Djangoのバージョンはどうやって確認しますか？

仮想環境を有効にしたうえで python -m django --version を実行するのが確実です。django-admin --version でも同じ値が返りますが、複数環境が混在する開発機ではインタープリタを明示できる前者を推奨します。インストール先のパスまで見たい場合は pip show django、アプリケーション内部からは django.get_version() を使ってください。本番の値は、必ず本番環境で実行して確認します。

Django 4.2はまだ使っても大丈夫ですか？

4.2 LTSは2026年4月7日に拡張サポートが終了しており、以後のセキュリティ修正は配布されません。アプリ自体は動きますが、公表済みのCVEは未修正のまま残った状態です。インターネットに公開しているサービスであれば、移行の着手時期を決める段階を過ぎています。閉域で改修が凍結され撤去日が確定している場合に限り、撤退期限を決めたうえでの継続運用が成立します。

LTSと通常リリースはどちらを選ぶべきですか？

判断軸は更新頻度です。年1回程度しか改修枠を取れないならLTS、8か月ごとに追従できる体制があるなら通常リリースで新機能を早く取り込む選択もあります。ただし2028年1月からは全リリースが一律3年サポートになり、この区分自体が無くなります。いま新規に選ぶなら、2030年4月まで延びる6.2 LTS（2027年4月リリース予定）を軸に計画するのが扱いやすい形です。

EOLのDjangoを使い続けると具体的に何が起きますか？

EOL当日に何かが壊れることはありません。変わるのは修正が届かなくなる点だけです。以後に公表される脆弱性は未修正のまま蓄積し、依存パッケージも順に旧バージョン向けのリリースを止めます。加えて、セキュリティ基準を持つ取引先の監査やクラウド側のコンプライアンス要件で、サポート切れフレームワークの利用が指摘対象になる場面が出てきます。

Django 2028へのバージョン体系の変更で既存のプロジェクトはどうなりますか？

既存プロジェクトのコードが、バージョン体系の変更だけで動かなくなることはありません。変わるのは番号の付け方とリリース間隔で、2028年1月以降は毎年1月に Django 2028・2029 という形です。6.2 LTSは2030年4月までサポートされるため、そこまでに年次リリースへ追従する計画を立てれば足ります。非推奨から削除までの猶予は、新サイクルでも2リリース分が確保されます。

関連記事

• Djangoのデプロイ手順：gunicorn＋nginx構成と本番設定・配置先の選び方：移行後の本番反映で押さえる設定
• Spring Bootバージョン一覧とサポート期限【2026年8月】：同じ判断をJava側で行う場合の対応表
• Laravelの最新バージョンは13｜対応PHPバージョン・サポート期限一覧とアップグレード判断：言語側の期限と揃える考え方の類例
• Laravel 11の変更点とサポート期限｜EOL後の実態と移行判断：EOL後に残る未修正脆弱性の実態