LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

Djangoで作った社内システムが、いつまで修正が届くのか分からない。保守を担っていた担当者が異動し、どの版で動いているのかも把握できていない——。Webアプリケーションを長く運用している会社では、こうした状況が起こりがちです。Djangoのバージョンアップとは、Pythonで書かれたWebフレームワークであるDjangoを、セキュリティの修正が届く新しい版へ上げる作業を指します。

Djangoには長く修正が届くLTS（長期サポート）版と、それより短い通常版があり、どちらを使っているかで期限が大きく変わります。ただし版を上げれば終わりではなく、Pythonの版や周辺のパッケージも合わせて見直す必要があります。本記事では、社内システムの保守を任された担当者に向けて、LTS版と通常版の違い、Pythonの版との関係、バージョンアップの進め方、そして外部に頼むときに確認したい点を整理します。

Djangoのバージョンアップとは

Djangoの新しい版には、新しい機能を含む「機能リリース」と、不具合やセキュリティの修正だけを含む「パッチリリース」の2種類があります。公式サイトは、パッチリリースは元の機能リリースとの互換性を保つとしており、最新のパッチに上げるべきかという問いへの答えは常に「はい」だと案内しています。^*1

• 機能リリース：5.2から6.0のように番号の前半が変わる版。新しい機能が入り、互換性のない変更も一部含まれます^*2
• パッチリリース：5.2.18のように末尾が変わる版。必要に応じて出され、入れ替えるだけで済むのが基本です
• 非推奨（将来なくなる予定）の機能は、少なくとも2つの機能リリースのあいだ警告を出してから削除されます^*2

社内で問題になりやすいのは、機能リリースをまたぐ作業です。パッチの適用は日々の保守、機能リリースの更新は計画を立てて進める工事と分けて考えると、予定と予算を立てやすくなります。

LTS版と通常版の違い

Djangoの公式サイトは、版ごとに2段階の期限を示しています。通常のサポート期間には、セキュリティの修正に加えてデータの消失や異常終了につながる不具合の修正が入ります。その後の延長サポート期間に入るのは、セキュリティとデータ消失の修正だけです。^*1

違いは修正が届く期間の長さです。LTS（長期サポート）版には3年間セキュリティとデータ消失の修正が届きます。^*2 通常版の6.0は5.2より後に出た版ですが、修正が止まるのは5.2より1年早い2027年4月です。手を入れる機会が少ない社内システムでは、LTS版から次のLTS版へ上げる計画が立てやすくなります。なお、2028年に出る版からは版番号が年の形に変わり、LTSの区別をなくして、どの版も3年間（通常1年と延長2年）修正が届く仕組みに改められます。^*2

Pythonの版との関係

Djangoを上げるときは、土台となるPythonの版も確かめます。Djangoの版ごとに、動かせるPythonの版が決まっているためです。^*4

• Django 5.2：Python 3.10〜3.14
• Django 6.0と6.1：Python 3.12以降
• Django 4.2：Python 3.9に対応する最後の版

たとえば5.2をPython 3.10や3.11で動かしている場合、6.0以降へ上げる前にPythonも3.12以降へ上げる必要があります。公式のよくある質問は、サポートの終わったPythonの版はDjangoで使うべきではないとしています。^*4Python 3.9のサポート終了への対応はPython3.9サポート終了後のリスクと移行で扱っています。

バージョンアップの進め方

公式ドキュメントは、複数の機能リリースをまたぐときは一度に上げず、1つずつ順に上げるほうが進めやすいとしています。LTS版から次のLTS版へ上げる場合も同じです。^*3 全体は次の4つの段階で進めます。

• ステップ1：いまの版から目標の版までのリリースノートをすべて読み、互換性のない変更を洗い出す
• ステップ2：いまの版のまま非推奨の警告を表示して直す（警告は初期設定では表示されません）
• ステップ3：周辺のパッケージを対応版に上げ、Djangoを1版ずつ上げてテストを通す
• ステップ4：本番に反映し、Djangoのキャッシュを使っていれば消去する

つまずきやすいのはステップ3です。公式ドキュメントも、新しい版が出て間もない時期や、保守の止まったパッケージがある場合は、対応版が出るまで待つ必要があると注意しています。^*3 自動テストが少ないシステムでは、画面を操作して確かめる項目の一覧を先に作っておくと、版を上げるたびに同じ確認を繰り返せます。

外部に頼むときに確認しておきたい点

Djangoのバージョンアップは、版を上げる作業そのものより、互換性の調査とテストに手間がかかります。外部に頼むときは、見積もりの前に次の点を確かめておきます。

• 目標の版：次のLTS版に合わせるのか、最新の通常版まで上げるのか
• 調査の範囲：リリースノートの確認、非推奨の警告の洗い出し、周辺パッケージの対応状況の調査を見積もりに含めるか
• Pythonとサーバー：Pythonの版やOSの更新を同時に行うか、別の工事に分けるか
• テストの方法：自動テストの有無と、無い場合に画面の確認項目を誰が作るか
• 運用後の見直し：パッチリリースを誰がいつ当てるか。次の期限に向けた計画を残すか

特にパッチリリースの適用は、バージョンアップを終えた後も続く作業です。公式ドキュメントは、新しいパッチはそれ以前のパッチを置き換えるもので、古いパッチには既知のセキュリティの弱点が含まれ得るとしています。^*2 当てる頻度を決めておかないと、LTS版を選んでも古いパッチのまま止まりかねません。アプリ全般の版上げを外部に任せる考え方はアプリのバージョンアップの外注にまとめています。

まとめ：Djangoで確かめておきたい3つの点

Djangoのバージョンアップを計画するうえで、確かめておきたい点は3つに整理できます。第一に、いま動いている版がLTS版か通常版かを確かめ、セキュリティの修正が止まる時期を把握すること。第二に、目標の版が求めるPythonの版と、周辺パッケージの対応状況を先に調べること。第三に、機能リリースを1つずつ上げ、非推奨の警告とテストで確かめながら進めることです。この3点を踏まえておけば、「期限が切れてから慌てて上げたら、画面が動かなくなった」という事態を避けやすくなります。調査やテストの進め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：Django Software Foundation「Download Django」（Supported Versions）（https://www.djangoproject.com/download/）。出典：各版の通常サポートと延長サポートの終了時期、パッチリリースの互換性と更新の勧め、各サポート期間に入る修正の範囲、BSDライセンスの記述を参照（2026年11月確認）
2. *2　参考：Django documentation「Django’s release process」（https://docs.djangoproject.com/en/dev/internals/release-process/）。出典：機能リリースとパッチリリースの区分、LTS版の3年間の修正、非推奨の機能の削除の方針、Django 2028以降の版番号とサポート期間の記述を参照（2026年11月確認）
3. *3　参考：Django documentation「How to upgrade Django to a newer version」（https://docs.djangoproject.com/en/dev/howto/upgrade-version/）。出典：リリースノートの確認、機能リリースを1つずつ上げる進め方、周辺パッケージの対応、非推奨の警告の解消、テスト、更新後のキャッシュ消去の記述を参照（2026年11月確認）
4. *4　参考：Django documentation「FAQ: Installation」（https://docs.djangoproject.com/en/dev/faq/install/）。出典：Djangoの版ごとに対応するPythonの版、サポートの終わったPythonを使うべきでないとする記述を参照（2026年11月確認）

Tweet