Django 6.0の新機能

 (adamj.eu)
4 ポイント 投稿者 GN⁺ 2025-12-11 | 1件のコメント | WhatsAppで共有
  • 20周年を迎えた Django 6.0 は、テンプレート、バックグラウンド処理、セキュリティ、メールなどの中核領域を大幅に改善したメジャーリリース
  • Template partials 機能によりテンプレート内のコード再利用が容易になり、htmx のようなツールとの統合が強化
  • Tasks フレームワーク が新たに追加され、HTTP リクエスト・レスポンス周期の外でバックグラウンド処理を実行可能
  • Content Security Policy(CSP) が標準搭載され、XSS などのコンテンツ注入攻撃への防御が簡単に
  • メール API のモダナイズ、ORM 改善、主キー拡張などにより、開発者体験と拡張性が大きく向上

Django 6.0 概要

  • Django 6.0 は Python Web フレームワークの新しいリリースで、20年にわたる進化を引き継ぐバージョン
  • 主な変更点はテンプレート、バックグラウンド処理、セキュリティ、メール処理という4つの中核機能を中心に構成
  • 開発者コミュニティの多くの貢献者が参加し、公式リリースノートに基づく主要な改善点が整理されている

django-upgrade ツール

  • 既存プロジェクトを Django 5.2 以下からアップグレードする際、django-upgrade ツールを使うとコードの自動変換が可能
  • Django 6.0 関連の 5つの自動修正ツール(fixer) が含まれており、一部の警告を自動で解消

Template partials

  • テンプレート部分定義({% partialdef %}) 機能が追加され、テンプレート内のコード重複を減らして再利用可能に
    • 同一テンプレート内で定義した partial を複数回呼び出し可能
    • inline オプションを使うと、定義と同時にレンダリング可能
  • 部分レンダリング 機能により、特定の partial だけを独立してレンダリング可能
    • 例では htmx を使って view_count 部分を定期的に更新
    • URL に #partial_name を付けると特定部分のみレンダリング可能
  • この機能は Google Summer of Code プロジェクト を通じて Django に統合され、既存の django-template-partials パッケージから発展

Tasks フレームワーク

  • Django に バックグラウンド処理実行用 Tasks フレームワーク が新たに追加
    • HTTP リクエスト・レスポンス周期の外部でコードを実行可能
    • メール送信、データ処理、レポート生成などの非同期処理に活用
  • @task デコレータで処理を定義し、Task.enqueue() でキューに登録可能
  • 標準提供バックエンドは開発用の ImmediateBackend、DummyBackend の2種類で、
    django-tasks パッケージの DatabaseBackend を使えば SQL DB ベースで実行可能
  • db_worker コマンドでワーカーを実行し、ログを通じて状態を確認可能
  • この機能は Wagtail で始まったアイデアで、DEP 0014 提案を経て Django に統合

Content Security Policy(CSP) サポート

  • Django 6.0 は CSP 標準を標準サポート し、XSS などのコンテンツ注入攻撃への防御を強化
    • ContentSecurityPolicyMiddleware を MIDDLEWARE に追加して有効化
    • SECURE_CSP, SECURE_CSP_REPORT_ONLY 設定でポリシーを構成可能
  • Nonce ベースのセキュリティ が内蔵され、<script> および <style> タグに nonce="{{ csp_nonce }}" 属性を追加可能
    • リクエストごとにランダムな nonce が生成され、信頼されたリソースのみ実行される
  • CSP は 2004 年の提案以降 django-csp パッケージとして実装されてきたが、今回のバージョンで公式に組み込み

メール API 更新

  • Django のメール処理ロジックが Python 3.6 のモダンなメール API に移行
    • 内部的に email.message.EmailMessage クラスを使用
    • 既存の send_mail() および EmailMessage インターフェースはそのまま維持
  • 新しい API は バグ削減、セキュリティ向上、インライン添付ファイル処理の改善 などの利点を提供
  • MIMEPart オブジェクトを使って、HTML 本文内の画像など インライン添付 を簡単に追加可能
  • この変更は 2024 年に提案され、8か月の開発を経てマージ

メール API の位置引数制限

  • django.core.mail API では一部のパラメータが キーワード引数のみ許可 に変更
    • fail_silently などのオプション引数を位置引数で渡すと警告が発生
    • 可読性と保守性を高めるための措置
  • django-upgrade の mail_api_kwargs fixer で自動修正可能

Shell 自動 import 拡張

  • Django 5.2 の自動モデル import 機能が拡張され、
    settings, connection, models, functions, timezone などが自動 import されるように
  • ./manage.py shell -v 2 で自動 import 一覧を確認可能
  • 開発の利便性向上と繰り返しコードの削減に効果

ORM 改善: save() 時の動的フィールド更新

  • GeneratedField や式ベースのフィールドが save() 後に自動更新 されるように
    • RETURNING 句をサポートする DB(SQLite, PostgreSQL, Oracle) では即時反映
    • MySQL, MariaDB では遅延ロードで自動更新
  • 追加クエリなしで最新値をすぐ使えるため効率が向上

Universal StringAgg 集約関数

  • StringAgg 集約関数 がすべてのデータベースバックエンドで利用可能に
    • 入力値を区切り文字(delimiter)で連結した文字列を返す
    • PostgreSQL 専用機能だったが、今では django.db.models から直接利用可能
  • Value() 式で区切り文字を指定可能

BigAutoField のデフォルト化

  • DEFAULT_AUTO_FIELD の既定値が BigAutoField に変更
    • 64ビット整数型の主キーを使うことで Primary Key 枯渇問題 を予防
    • 新規プロジェクトでは追加設定なしで自動適用
  • Django 3.2 で導入された設定を簡素化し、ボイラープレートを削減

Template 改善

  • forloop.length 変数が追加され、ループ内で全体の長さを参照可能
    • {{ forloop.counter }}/{{ forloop.length }} の形で利用
  • querystring テンプレートタグ 改善
    • 空のマッピング時に ? を自動追加してリンク動作の一貫性を確保
    • 複数マッピング引数のマージをサポートし、クエリパラメータの組み合わせが容易に

まとめ

  • Django 6.0 には 174 人の貢献者が参加し、
    数多くの最適化とバグ修正が含まれる
  • アップグレードにより セキュリティ、保守性、開発者体験(DX) が全般的に向上
  • 公式リリースノートで追加の変更点を確認可能

関連記事

1件のコメント

 
GN⁺ 2025-12-11
Hacker News の意見

  • ここ数年、会社で Django を断続的に使ってきた。全体的には気に入っているが、ORM は今でも扱いづらく感じる
    Django は意見の強いフレームワークなので、「Django 流」に従う必要があることをようやく理解した。
    問題は、複数の事業部門の マルチデータベース を扱わなければならず、毎回その癖に合わせるのに苦労すること。
    結局、managed を無効にして inspectdb でスキーマを取り込み、Web に公開したくないテーブルを手動で削除する形で対処している。
    新しく作る Web アプリには、Django が今でも最良の選択だ

    • 同意する。ただ、DB マイグレーションのワークフロー には今でも不満がある
      Django はコードと一緒にスキーマ状態を保存しないので、DB コマンドを実行するたびに現在の状態を推論しなければならない。
      モデルコードで DB の状態を定義するのは、本質的に限界がある。
      自分は Rails のように明示的な DB コマンドでマイグレーションを構成し、その上にモデルを載せる方式のほうが好きだ
    • Django の マルチデータベースサポート を使っているのか気になる
    • 小さなプロジェクトで Aldjemy を使ったことがあるが、Django ORM では難しい 複雑なクエリの組み合わせ をかなりうまく処理してくれた
    • Django を 10 年以上使ってきたが、ORM は「悪くない」程度だ。かつて SQLAlchemy に切り替えようという流れもあったが、それほどの価値はなかった。
      Manager インターフェースは最初は紛らわしいが、マイグレーションツール は本当に素晴らしい
    • ORM 経由で ビューや materialized view を設定しておくと、性能改善に大いに役立つ。
      SQL チューニングの柔軟性と Django の便利さを同時に得られる。
      ただし、マイグレーションスクリプトの中で作成するのを忘れないこと

  • Django がリリースのたびに少しずつ 着実に改善 されているのが本当に気に入っている。
    特に 6.0 は有用な機能が多くて興味深い。
    信頼できる技術は退屈だというのは間違いだ。こういう形で進化するのが正しい

    • 自分も pre-1.0 の頃から使っていて、今でも好きだ。
      今は Django の生まれた場所の近くに住んでいる。
      ついでに言うと、昨日から求職中なので、経験豊富な Django 開発者 を探しているなら連絡してほしい (oldspiceap@gmail.com)

  • Adam の書くコードやブログはいつも読む価値がある。
    今後 tasks フレームワーク がどう発展するのか楽しみだ。
    ただ、素晴らしい Django-Q2 が Celery と一緒に言及されていたのは少し残念

    • 著者です。褒めてくれてありがとう。Celery に触れたのは単に 人気があるから というだけです ;)
    • Celery は完璧ではないが、最善の選択肢 だ。
      バグは多いが、ユーザー層が非常に大きいので、その問題に最初に遭遇することはまれだ。
      Celery + RabbitMQ の組み合わせで、1 日あたり数千万件のメッセージを安定して処理したことがある。
      今でも最初に検討すべきソリューションだ
    • 何年も Celery を使ってきたが、何が問題で Django Q2 がどう改善してくれるのか気になる。
      別のスタックでは Kafka も使うが、それはまったく別レベルのユースケースだ
    • なぜ Celery が「ひどい」と言われるのか気になる

  • Django を 5〜6 年ほど使ってきたが、「バッテリー同梱」 という利点は確かにあるものの、全体として 重い と感じる

  • Template partial 機能は良さそうに見える。
    React が人気を得た理由の 1 つが コードの再利用性 で、Django もその方向に進んでいるようだ

    • React の再利用性と合成可能性の核心は、テンプレートではなく すべてが関数であること だ
    • この機能は特に HTMX と組み合わせたときに価値が大きい。HTMX は多くの partial テンプレートを必要とする
    • React は単なるテンプレートではなく、状態をカプセル化したコンポーネント を提供する
    • 自分も Django 6 をテストしながらブログで partial を使ってみた
      例は ここのコード にある
    • Django がこうした機能を 2025 年になってようやく追加した のは驚きだ

  • 自分は主に Odoo を使っているが、Django と Celery も少し触ったことがある。
    Odoo の OCA queue モジュール をよく使っている立場として、
    Django がなぜ Postgres の LISTEN/NOTIFY 機能を活用しないのか、ずっと不思議に思っていた。
    単に自分が Django エコシステムに詳しくないだけかもしれない

  • Template Partials と HTMX は、Django 版の Rails View Components + Stimulus のように感じる。
    Tasks 機能が正式サポートされるのも嬉しい

    • Rails の partial レンダリングは 公式ガイド で見られる
    • 本番環境で Tasks を使うには django-tasks も一緒に使う必要があるのか気になる

  • Django 1.x の時代、ORM がなかった頃 から使っていた。
    今になって task 実行機能が追加されたのは本当に驚きだ。
    批判したいわけではなく、ただ興味深い進化だと思う

    • むしろ新鮮だ。Django は機能を 急がず、きちんと実装 する。
      各機能が十分に検証されてから取り込まれ、LTS と API の安定性に重点を置いている。
      そのおかげで、新バージョンが出てもアプリ全体を書き直す必要がほとんどない
    • Django は実際には 0.95 の時点で ORM を含んでいた。
      当時はシンプルだったが、かなり長い間 raw SQL を使う必要はなかった

  • 追加の議論は このスレッド で続いている

  • 自分は Django と HTMX を一緒に使っていて、コンポーネント単位のテンプレート があまりにも不便だったので、
    Python ベースのコンポーネントライブラリ Compone を自作した。
    Django だけでなく、すべての Python Web フレームワークで使えて、ずっと 快適な開発体験 を提供してくれる