Django 6 がリリース

 (docs.djangoproject.com)
6 ポイント 投稿者 GN⁺ 2025-12-05 | 1件のコメント | WhatsAppで共有
  • Webフレームワークの Django 6.0版が公開され、Python 3.12以上をサポートし、セキュリティ、テンプレート、非同期機能が大幅に強化されました
  • Content Security Policy(CSP) が組み込み標準として追加され、XSSなどのコンテンツ注入攻撃対策のためのポリシー設定が可能です
  • Template Partials 機能により、テンプレート内で再利用可能なセクションを定義できるようになり、コードのモジュール化が向上しました
  • Background Tasks フレームワークが追加され、リクエスト・レスポンスサイクル外での非同期タスク実行がサポートされます
  • Pythonの最新メールAPI導入、MariaDB 10.5のサポート終了、DEFAULT_AUTO_FIELDのデフォルト値変更などにより互換性調整とモダン化が実施されました

Python互換性

  • Django 6.0はPython 3.12、3.13、3.14をサポートし、各シリーズの最新リリースのみを公式にサポートします
  • Django 5.2.xはPython 3.10および3.11をサポートする最後のバージョンです
  • Django 6.0以降、サードパーティアプリはDjango 5.2以前のバージョンサポートを停止することが推奨されます

主要な新機能

Content Security Policy(CSP)のサポート

  • DjangoにCSP標準が組み込まれ、XSSなどのコンテンツインジェクション攻撃への防御が強化されました
    • ContentSecurityPolicyMiddleware、csp() コンテキストプロセッサ、SECURE_CSP 設定を通じてポリシーを定義できます
    • Pythonの辞書ベース設定により、明確で安全なポリシー構成をサポートします
  • SECURE_CSP_REPORT_ONLYで監視モードを設定可能
  • ビュー単位でポリシーを再定義または無効化できるデコレーターを提供

Template Partials

  • テンプレートの一部（fragment）を定義して再利用できる partialdef および partial タグを追加
  • template_name#partial_name 構文で get_template()、render()、{% include %} などから直接参照可能
  • 既存のサードパーティパッケージ django-template-partials 利用者向けの移行ガイドを提供

Background Tasks フレームワーク

  • Djangoに非同期タスク実行用の組み込みフレームワークを追加
    • HTTPリクエスト・レスポンスサイクル外でメール送信、データ処理などを実行可能
    • @task デコレーターでタスクを定義し、enqueue()でキューに登録
  • バックエンドはTASKS設定で指定し、開発・テスト用のデフォルトバックエンドが2種類含まれます
  • Djangoはタスクの作成とキュー登録のみ担当し、実行は外部ワーカープロセスが行う必要があります

Python最新メールAPIの採用

  • Djangoのメール処理ロジックがPython 3.6以降の現代的なメールAPI（email.message.EmailMessage）へ移行
  • 以前のSafeMIMEText、SafeMIMEMultipartクラスは非推奨化されました
  • EmailMessage.message() の返り値の型がPythonのEmailMessageインスタンスに変更されます

詳細な改善点

Admin

  • Font Awesome Free 6.7.2アイコンセットを適用
  • AdminSite.password_change_form属性で管理者のパスワード変更フォームをカスタマイズ可能
  • messages.DEBUGとmessages.INFOに個別のアイコンとCSSスタイルを適用

Auth

  • PBKDF2ハッシュ反復回数が1,000,000 → 1,200,000に増加

GIS

  • GEOSGeometry.hasm属性でM次元の有無を確認可能
  • Rotate関数で指定角度の回転をサポート
  • BaseGeometryWidget.base_layer属性で地図タイルプロバイダーのカスタマイズが可能
  • MariaDB 12.0.1以上でcoveredby、isvalid、GeoHash、IsValidなどの機能をサポート
  • ウィジェットのレンダリング時にインラインJavaScriptを除去、カスタマイズ時はテンプレート修正が必要

PostgreSQL

  • Lexeme式の追加で全文検索クエリの制御を強化
  • CreateExtensionなど拡張関連操作にhintsパラメータを追加
  • django.contrib.postgres関連のフィールド・インデックス・制約にシステムチェックを追加

Staticfiles

  • ManifestStaticFilesStorageがパス整列の一貫性を保証し、不要なdiffを削減
  • collectstaticコマンドはデフォルトでサマリーのみを出力し、詳細は--verbosity 2以上で表示

その他

  • Haitian Creole言語サポートを追加
  • startproject、startappコマンドで存在しないディレクトリを自動作成
  • shellコマンドでdjango.conf.settingsなどの基本ユーティリティを自動インポート
  • マイグレーションでzoneinfo.ZoneInfoシリアライズをサポート
  • StringAgg、AnyValueなどの新しい集計関数を追加
  • AsyncPaginator、AsyncPageで非同期ページネーションをサポート
  • ASGI環境でHTTP/2マルチCookieヘッダーをサポート
  • テンプレート内のforloop.length変数を追加、querystringタグを改善
  • DiscoverRunnerがforkserver方式の並列テストをサポート

非互換な変更

データベースバックエンドAPI

  • BaseDatabaseSchemaEditorおよびPostgreSQLバックエンドは、カラム削除時のCASCADE使用を中止
  • return_insert_columns() → returning_columns()などメソッド名を変更
  • UPDATE … RETURNINGをサポートする場合は、DatabaseFeatures.can_return_rows_from_update=Trueを設定可能

サポート終了

  • MariaDB 10.5サポート終了（10.6以上が必要）
  • Python 3.12未満サポート終了
    • 主要ライブラリの最小バージョン: aiosmtpd 1.4.5、bcrypt 4.1.1、Pillow 10.1.0、psycopg 3.1.12など

Email

  • mixed_subtype、alternative_subtype、encoding属性を削除
  • 内部実装変更により、カスタムEmailMessageサブクラスの確認が必要

DEFAULT_AUTO_FIELDのデフォルト値変更

  • デフォルトがAutoField → BigAutoFieldに変更
  • Django 3.2以降の警告（models.W042）を処理していないプロジェクトは設定を追加する必要があります

ORM式

  • as_sql()メソッドの返り値パラメータはタプル形式である必要があります

その他

  • JSONシリアライズ時に常に改行を追加
  • asgirefの最小バージョンを3.9.1へ引き上げ

廃止予定機能

django.core.mail API

  • get_connection()、send_mail()などで省略可能引数はキーワード引数としてのみ渡す必要があります
  • EmailMessage、EmailMultiAlternatives作成時、最初の4つの引数以外はキーワード引数のみ許可

その他

  • BaseDatabaseCreation.create_test_db(serialize)を廃止し、serialize_db_to_string()を使用
  • PostgreSQL専用のStringAgg、OrderableAggMixinを廃止
  • urlize、urlizetruncのデフォルトプロトコルがDjango 7.0でHTTPSへ変更予定
  • ADMINS、MANAGERS設定は（名前、アドレス）のタプルではなく、メールアドレス文字列のリストで指定する必要があります
  • SafeMIMEText、SafeMIMEMultipart、BadHeaderErrorなどメール関連クラスを廃止

削除された機能

  • BaseConstraintの位置引数サポートを削除
  • DjangoDivFormRenderer、Jinja2DivFormRendererを削除
  • cx_Oracleデータベースドライバーサポートを廃止
  • forms.URLFieldのデフォルトスキームを"http" → "https"に変更
  • Model.save()およびModel.asave()の位置引数サポートを削除
  • ModelAdmin.log_deletion()、LogEntryManager.log_action()を削除
  • django.utils.itercompatモジュールを削除
  • GeoIP2.coords()、GeoIP2.open()メソッドを削除
  • ForeignObject.get_joining_columns()および関連メソッドを削除

Django 6.0はセキュリティの強化、非同期処理、最新メールAPIの導入を通じて、フレームワークの安定性と拡張性を高め、Python 3.12以上環境への移行を明確にしました。

関連記事

1件のコメント

 
GN⁺ 2025-12-05
Hacker Newsのコメント

  • 以前働いていた組織には、NodeJS+React の「モダンな」コードベースと、15年近く前の Python 2.7 ベースの Django レガシーアプリがあった。
    最初は古いコードがつらいだろうと心配していたが、むしろ逆だった。
    Django アプリは扱っていて楽しく、整理していく過程も本当に面白かった。新しい Go/React へのリライトに置き換えられる時が来たら、きっと寂しく感じると思う

    • なぜわざわざ置き換えようとしているのかわからない。壊れていないなら、わざわざ変える必要はない

  • Django チームに祝福を送りたい。
    私は長いあいだ Docker Compose ベースの Django + Celery + Postgres + Redis + esbuild + Tailwind スターターアプリを保守してきて、最近 Django 6.0 に合わせて更新した。
    GitHub リポジトリで確認できる。
    まだ CSP 設定はデフォルトで入れていないが、もう少し検討してから追加する予定だ

    • ブックマークしようとしたら、すでに 2023年12月に保存していたのを見つけた
    • Nick のリポジトリはいつも 最高水準だ。私も自分の資料でよく引用している。公開して共有してくれてありがとう
    • 数年前のプロジェクトでこのテンプレートを使ったことがあるが、本当に素晴らしかった
    • 最近の uv 追加を見て、継続的にメンテナンスされていることが伝わってきた

  • Django の "batteries included" 哲学は、AI コード生成に完璧に合っている。
    管理パネル、ログイン、パスワード再設定などの基本機能がすでによく揃っているので、AI が小さなコードベースでも完全なサイトを作れる。
    コードが小さく明快なので、AI が反復的に改善するのも簡単だ

    • Django の強みは 人間が読みやすいコード構造にある。
      巨大なコンポーネントの代わりに明確なモデルとテンプレートがあるので、AI が生成したコードもレビューしやすい。
      さらに Django admin が独立した ground truth として存在するため、フロントエンドが壊れてもデータを扱える。
      ただ、Python エコシステムが gevent モデルを採用しなかったのは残念だ。そうしていれば非同期への移行はずっと滑らかだったはずだ
    • Django の INSTALLED_APPS 構造のおかげで、アプリ単位で機能を簡単に追加・削除できる。
      Flask や FastAPI のような疎結合のフレームワークより、ずっと統合的だ。
      こうした違いが結局、多くの 小さな不便さ(papercuts) を減らしてくれる
    • Django と Rails の両方を使ったことがあるが、Claude Code でテストしたときは Rails のほうがはるかにうまく動いた。
      古い .NET アプリをリライトしたが、Rails はほぼ完璧に変換した一方で Django は苦戦していた
    • 実際のところ、Ruby on Rails のほうが、CSP、バックグラウンドワーカーなど多様な機能を以前から標準提供してきた
    • Django はオープンソースプロジェクトで長年使われてきたので、AI が学習するための コードデータが豊富だ

  • 今回のリリースの template partials 機能はかなり良さそうに見える。
    ただし 型注釈(type annotations) の状況は依然として不便だ。
    django-stubs には mypy プラグインが必要で、django-types は pyright 向けのフォークだが同期があまり取れていない。
    pylance はまた独自フォークを使っている。
    次のバージョンでは HttpRequest、HttpResponse、View、Model のような基本型だけでも公式に含めてほしい

  • Django のおかげで Web 開発は本当に楽しかった。
    他のフレームワークに移っても、結局 Django に戻ってきてしまう。後悔のない選択だった

    • 私は Ruby on Rails で同じ経験をした。
      他のフレームワークを試しても、Rails の便利さのせいでまた戻ってきてしまう。
      ただ、Rails に標準の Admin UI がないのは残念だ
    • バックエンドだけを見れば Django は素晴らしいが、フロントエンド面ではまだ石器時代レベルだ。
      完全なフルスタックを求めるなら Laravel や Rails を見たほうがいい
    • 正直、Django の魅力があまりわからない。
      PHP の時代から Web をやってきたが、Django はいつも 可もなく不可もなくという感じだった

  • Django は私にとって最初の フリーランスの大型プロジェクトで、今でもしっくりくる。
    いろいろ実験的なことも試してきたが、いつもちゃんとうまく動いた。Django に感謝している

  • 15年近く、ほぼ Django だけを使ってきた。
    他のフレームワークもたくさん試したが、Django ほど 手になじむものはなかった。
    今回のリリースで task framework が追加されたが、バックエンドとワーカーが含まれていないのは残念だ。
    むしろ次のバージョンで完全な形として含めてほしい

    • Django がその一線を越えるつもりがあるのか気になる。フレームワークの哲学として 境界の維持を重視していそうだ
    • 完璧さが善の敵になってはいけない。Django は結局 「締め切りのある完璧主義者」 のためのフレームワークだ

  • Django の 全部入りの構成(batteries included) のおかげで、規模を問わずどんなプロジェクトにも適している。
    チームとコントリビューターたちに賛辞を送りたい

  • 私たちはどうして SPA 時代に入ることになったのだろう。単にローディングスピナーをなくしたかっただけなのか、それとももっと深い理由があったのか知りたい

    • 主要な理由のひとつは モバイルアプリの登場だった。
      Web・iOS・Android がひとつのバックエンドを共有するようになり、自然と SPA パターンが広まった。
      私も今でも SPA を作っているが、いつか Django + htmx で大きなプロジェクトをやってみたい
    • 以前 Angular で データ可視化をしていたときに SPA へ移行した。
      ページリロードなしでアプリのように動くのが魅力的だったが、実際には 強制リフレッシュが必要になることも多かった。
      それでもデータと表現を分離する構造はエレガントだと思う
    • Web はもともと 文書レンダリング用に作られたが、ユーザーはアプリを求めていた。
      そのため JS で文書をアプリのように変えようとする試みが続いた
    • インターネットが遅く、バックエンド検証も遅かった時代には、フォーム検証のために JS を追加していくうちに複雑になっていった。
      結局フロントエンドとバックエンドを分離し、API 契約や検証手順が生まれた。
      その後、再びサーバーコンポーネントで統合しようとする流れが生まれ、今の私たちはその地点にいる。
      ちなみに昔ながらの Web フォームの例は このリンクで見られる
    • Django や Rails のようなテンプレートには 型安全性が不足していた。
      そのため私は TypeScript ベースのビルドプロセスを好むようになった

  • Django を使うたびに、ただただ 楽しいと感じる。それがすべてだ