# Django 6.0の全貌：複合主キー、バックグラウンドタスク、2026年の面接対策まで徹底解説
> Django 6.0の主要新機能を徹底解説。複合主キー（CompositePrimaryKey）、組み込みバックグラウンドタスク、テンプレートパーシャル、CSPミドルウェアの実装方法と、2026年のDjango面接頻出質問を網羅します。
- Published: 2026-06-09
- Updated: 2026-06-09
- Author: SharpSkill
- Tags: django, python, composite-primary-keys, background-tasks, csp
- Reading time: 8 min
---
Django 6.0は、Python Webフレームワークとして長年にわたり支持されてきたDjangoの最新メジャーリリースです。2025年12月に公開されたこのバージョンでは、組み込みのバックグラウンドタスクフレームワーク、テンプレートパーシャルによる再利用可能なテンプレート断片の管理、そしてネイティブなContent Security Policyミドルウェアが導入されました。さらに、Django 5.2で追加された複合主キー（Composite Primary Keys）と組み合わせることで、2026年のWeb開発に求められる堅牢かつ効率的なアーキテクチャの構築が可能になっています。
本記事では、これらの主要機能を実際のコード例とともに解説し、2026年のDjango技術面接で頻出する質問についても取り上げます。
> **2026年のDjangoバージョンタイムライン**
>
> Django 5.2 LTS（2025年4月）で複合主キーが導入されました。Django 6.0（2025年12月）ではバックグラウンドタスク、テンプレートパーシャル、CSPミドルウェアが追加されています。Django 6.1は現在開発中であり、Field Fetch ModesやさらなるORMの最適化が予定されています。
## CompositePrimaryKeyによる複合主キー
Djangoは18年以上にわたり、各モデルに単一カラムの主キーを強制してきました。Django 5.2では`CompositePrimaryKey`クラスの導入により、この長年の制約が解消され、ORMレベルで複数カラムによる主キーの定義が可能になりました。
複合主キーを使用することで、中間テーブルにおける人工的な`AutoField`カラムの必要性がなくなります。データベース自体が主キーレベルで一意性を保証するため、ストレージの効率化とインデックスアクセスにおけるクエリパフォーマンスの向上が期待できます。
```python
# models.py
from django.db import models
class Product(models.Model):
name = models.CharField(max_length=100)
sku = models.CharField(max_length=20, unique=True)
class Warehouse(models.Model):
code = models.CharField(max_length=10, primary_key=True)
location = models.CharField(max_length=200)
class Inventory(models.Model):
pk = models.CompositePrimaryKey("product_id", "warehouse_id")
product = models.ForeignKey(Product, on_delete=models.CASCADE)
warehouse = models.ForeignKey(Warehouse, on_delete=models.CASCADE)
quantity = models.PositiveIntegerField(default=0)
last_restocked = models.DateTimeField(auto_now=True)
```
上記の`Inventory`モデルは、データベース上で`PRIMARY KEY (product_id, warehouse_id)`制約を生成します。`id`カラムは自動生成されません。二つの外部キーの組み合わせがレコードの自然な識別子となるという、リレーショナルデータベースの標準的な設計パターンに沿ったアプローチです。
### 複合キーによるクエリ操作
複合主キーはPythonではタプルとして表現されます。フィルタリング、アクセス、代入のすべてがこのタプルインターフェースを通じて行われます。
```python
# views.py
from .models import Inventory, Product, Warehouse
# Create records
laptop = Product.objects.create(name="Laptop Pro", sku="LP-001")
warehouse_a = Warehouse.objects.create(code="WH-A", location="Berlin")
item = Inventory.objects.create(
product=laptop,
warehouse=warehouse_a,
quantity=50
)
# Access the composite pk as a tuple
print(item.pk) # (1, "WH-A")
# Filter by composite pk
result = Inventory.objects.filter(pk=(1, "WH-A")).first()
# Assign a composite pk directly
new_item = Inventory(pk=(2, "WH-B"))
print(new_item.product_id) # 2
print(new_item.warehouse_id) # "WH-B"
```
現時点で注意すべき制約が3つあります。第一に、`ForeignKey`は複合主キーを持つモデルに直接参照できないため、代わりに`ForeignObject`を使用する必要があります。第二に、Django管理画面は複合キーモデルの完全なサポートをまだ提供していません。第三に、既存のテーブルにおける単一キーと複合キー間の移行には手動SQLが必要です。
## Django 6.0の組み込みバックグラウンドタスクフレームワーク
Django 6.0以前は、リクエスト・レスポンスサイクルの外でコードを実行するには、Celery、Django-Q、またはそれに類するサードパーティのタスクキューライブラリに依存する必要がありました。Django 6.0はこのギャップを埋めるネイティブなタスクフレームワークを導入し、タスクの定義とキューイングをフレームワークコア内で直接サポートします。
`@task`デコレータは任意の関数をキューイング可能としてマークします。デコレートされた関数に対して`.enqueue()`を呼び出すことで、タスクは設定されたバックエンドに非同期実行のために送信されます。このフレームワークはタスクの定義と実行を明確に分離しています。Djangoがキューを管理し、別のワーカープロセスが実際の処理を担当する仕組みです。
```python
# tasks.py
from django.tasks import task
from django.core.mail import send_mail
@task
def send_welcome_email(user_email, username):
"""Send a welcome email after user registration."""
send_mail(
subject="Welcome to the platform",
message=f"Hello {username}, your account is ready.",
from_email=None, # uses DEFAULT_FROM_EMAIL
recipient_list=[user_email],
)
return f"Email sent to {user_email}"
@task
def generate_report(report_id, format="pdf"):
"""Generate an export report asynchronously."""
from .services import ReportService
report = ReportService.generate(report_id, format=format)
return report.file_path
```
```python
# views.py
from .tasks import send_welcome_email, generate_report
def register_user(request):
# ... user creation logic ...
# Enqueue the task for background execution
send_welcome_email.enqueue(
user_email=user.email,
username=user.username
)
return redirect("dashboard")
def export_view(request, report_id):
generate_report.enqueue(report_id=report_id, format="csv")
return JsonResponse({"status": "processing"})
```
`settings.py`の`TASKS`設定でバックエンドを構成します。Djangoは2つの組み込みバックエンドを提供しています。Immediateバックエンドは同一プロセス内でタスクを同期的に実行するもので、ローカル開発に適しています。Dummyバックエンドはキューイングされたすべてのタスクを破棄するもので、タスクの実行を伴わずにキューイングロジックのテストを行う際に使用します。本番環境では、RedisやRabbitMQなどのメッセージブローカーに接続するサードパーティ製バックエンドまたは独自実装が必要です。
> **バックグラウンドタスク vs Celery**
>
> Djangoの組み込みタスクフレームワークは、Fire-and-Forget型のタスク、メール送信、レポート生成といったシンプルなユースケースに対応します。タスクチェイニング、Celery Beatによる定期実行（cron的なスケジュール）、レートリミティング、結果バックエンド、Flowerを使ったモニタリングインフラなどの高度な機能が必要な場合は、引き続きCeleryが標準的な選択肢です。両方のアプローチは同一プロジェクト内で共存できます。
## テンプレートパーシャルによる再利用可能なフラグメント
Django 6.0では`{% partialdef %}`と`{% partial %}`テンプレートタグが導入されました。これにより、単一のファイル内で名前付きの再利用可能なテンプレート断片を定義できるようになり、テンプレートディレクトリに散在する多数の小さなインクルードファイルを減らすことができます。
```html
{% partialdef product_card %}
{{ product.name }}
{{ product.price|floatformat:2 }} EUR
{% if product.in_stock %}In Stock{% else %}Sold Out{% endif %}
{% endpartialdef %}
{% partialdef product_row %}
| {{ product.name }} |
{{ product.price|floatformat:2 }} EUR |
{{ product.quantity }} |
{% endpartialdef %}
```
```html
{% extends "base.html" %}
{% block content %}
{% for product in products %}
{% include "components/cards.html#product_card" %}
{% endfor %}
{% endblock %}
```
テンプレートパーシャルの主な利点は、関連する表示バリエーションをグループ化できる点にあります。`_product_card.html`と`_product_row.html`を別々のファイルとして作成する代わりに、一つの`cards.html`ファイルに同じ概念のすべての表示形式をまとめることができます。ハッシュセレクタ（`components/cards.html#product_card`）により、目的のフラグメントを正確に指定できます。この整理方法は、再利用可能なUIコンポーネントが多数存在する大規模プロジェクトにおいて、保守性を大幅に向上させます。
また、テンプレートパーシャルは部分的なHTML交換に基づくHTMXのようなライブラリとも親和性が高く、テンプレート全体をレンダリングすることなく、サーバーから個別のページフラグメントのみを返すことが可能です。
## ネイティブContent Security Policyミドルウェア
Django 6.0では、新しい`ContentSecurityPolicyMiddleware`によってCSPサポートがフレームワークコアに直接統合されました。これまでは、この機能を実現するためにサードパーティパッケージの`django-csp`が必要でした。
```python
# settings.py
from django.utils.csp import CSP
MIDDLEWARE = [
"django.middleware.security.SecurityMiddleware",
"django.middleware.security.ContentSecurityPolicyMiddleware",
# ... other middleware
]
SECURE_CSP = {
"default-src": [CSP.SELF],
"script-src": [CSP.SELF, CSP.NONCE],
"style-src": [CSP.SELF, "https://fonts.googleapis.com"],
"img-src": [CSP.SELF, "https:", "data:"],
"font-src": [CSP.SELF, "https://fonts.gstatic.com"],
"connect-src": [CSP.SELF],
}
# Report-only mode for testing (does not block, only reports violations)
SECURE_CSP_REPORT_ONLY = {
"default-src": [CSP.SELF],
"report-uri": ["/csp-report/"],
}
```
既存のセキュリティミドルウェアチェーンへの統合はシームレスに行われます。`CSP.NONCE`値はリクエストごとに暗号学的に安全なnonce値を自動生成し、テンプレート内では`{{ request.csp_nonce }}`コンテキスト属性を通じてアクセスできます。特に有用なのがReport-Onlyモードです。CSP違反はログに記録されますが、ブロックはされません。これにより、運用中のサービスに影響を与えることなく、CSP設定を段階的に本番環境でテストできます。検証が完了した後にのみ、ポリシーを強制モードに移行します。
## Django 6.0のその他の注目すべき変更点
主要機能以外にも、Django 6.0には日常の開発に影響を与える多くの変更が含まれています。
**BigAutoFieldがデフォルトの主キーに。** 新規プロジェクトでは、自動生成される主キーとして`AutoField`（32ビット）の代わりに`BigAutoField`（64ビット）がデフォルトで使用されるようになりました。この変更により、大量のデータを持つテーブルにおけるオーバーフローの問題が解消されます。`settings.py`で`DEFAULT_AUTO_FIELD`を明示的に設定していない既存プロジェクトには、マイグレーション時に警告が表示されます。
**非同期ページネーション。** 新しい`AsyncPaginator`と`AsyncPage`クラスにより、ページネーションロジックにネイティブな非同期サポートが追加されました。完全な非同期ビュースタック環境では、ページ計算時の同期的なブロッキングが不要になり、データ量の多いリストビューにおける全体的なパフォーマンスが向上します。
**シェルでの自動インポート。** `manage.py shell`コマンドは、プロジェクトのすべてのモデルと、`django.utils.timezone`や`datetime`などの一般的なDjangoユーティリティを自動的にインポートするようになりました。新しいシェルセッションを開くたびに手動でインポートを繰り返す必要がなくなり、探索的な作業やデバッグの効率が大幅に向上します。
**モダナイズされたメールAPI。** DjangoのメールクラスはPythonの`email.message.EmailMessage`を使用するようになり、非推奨のMIMEクラスに依存しなくなりました。この変更により、メールインフラがPython標準ライブラリの最新状態に更新され、モダンなメールプロトコルとの互換性が向上しています。
## 2026年のDjango面接質問
2026年の技術面接では、ORM最適化、ミドルウェアアーキテクチャ、RESTフレームワークの基礎といった定番トピックに加えて、Djangoの新しい機能についての質問が増加しています。以下の質問は特に頻出であり、最新のフレームワークバージョンに関する理論的理解と実践的経験の両方が問われます。
**複合主キーが解決する問題と、現在の制約は何ですか？**
この質問はデータベース設計の理解と実装上の制約に対する知識を試すものです。適切な回答では、中間テーブルにおける利点として、人工的なサロゲートキーの不要化、データベースレベルでの一意性保証、ストレージ使用量の削減を挙げます。同時に、3つの主要な制約にも言及する必要があります。`ForeignKey`は複合キーモデルを参照できない（代わりに`ForeignObject`を使用）、Django管理画面が完全にはサポートしていない、そして既存テーブルでの移行には手動SQLが必要であるという点です。
**Django 6.0のバックグラウンドタスクフレームワークとCeleryの違いは何ですか？**
組み込みフレームワークは、シンプルなFire-and-Forget型タスクを対象としており、開発環境では外部メッセージブローカーを必要としません。一方、Celeryはタスクチェイニング、Celery Beatによる定期実行、レートリミティング、結果バックエンド、Flowerによるモニタリングインフラなど、より高度な機能を提供します。回答では、両方のソリューションが異なる複雑度のユースケースに対応しており、多くのプロジェクトで並行して使用可能であることを示す必要があります。
**Djangoにおけるミドルウェアの実行順序と、CSPミドルウェアの配置について説明してください。**
Djangoは受信リクエストに対してミドルウェアを定義された順序で処理し、送信レスポンスに対しては逆順で処理します。CSPミドルウェアはHTTPレスポンスヘッダーを修正するため、`SecurityMiddleware`の後に配置する必要があります。候補者は強制モードとReport-Onlyモードの違いを説明し、nonceメカニズムがインラインスクリプトタグをどのように保護するかを解説できることが求められます。
**テンプレートパーシャルとは何か、`{% include %}`の代わりにいつ使用すべきですか？**
テンプレートパーシャルは、同一概念の複数の表示バリエーションを一つのファイルにグループ化する機能です。個別に参照する必要がある関連フラグメントが複数存在する場合に特に有効です。例えば、同じデータオブジェクトのカードビューとテーブルビューなどが該当します。従来の`{% include %}`は、論理的なグループ化を必要としない単独の独立したフラグメントに対して引き続き適切です。パーシャルは、テンプレートディレクトリに大量の小さなインクルードファイルが蓄積して見通しが悪くなりがちな大規模プロジェクトにおいて、ファイルの増殖を抑制する効果もあります。
> **Django 5.2から6.0への移行**
>
> Django 6.0ではPython 3.10および3.11のサポートが終了しています。`DEFAULT_AUTO_FIELD`のデフォルト値は`BigAutoField`に変更されます。メールクラスはPythonのモダンな`email.message` APIを使用するようになり、非推奨のMIME内部実装に依存しているコードは動作しなくなる可能性があります。本番アプリケーションを更新する前に、ステージング環境での徹底的なテストが必須です。
## まとめ
Django 5.2および6.0で導入された主要な新機能を総括します。
- **複合主キー**（`CompositePrimaryKey`）により、中間テーブルにおける人工的なサロゲートキーが不要になり、ORMレベルでの自然な複数カラム主キーの定義が可能になりました
- 組み込みの**`@task` / `.enqueue()`フレームワーク**は、外部のCelery依存なしにシンプルなバックグラウンドタスクを処理し、ローカル開発を簡素化します
- **テンプレートパーシャル**（`{% partialdef %}` / `{% partial %}`）は、関連するテンプレート断片を単一ファイルにグループ化し、プロジェクト構造を改善します
- ネイティブ**CSPミドルウェア**（`ContentSecurityPolicyMiddleware`）は、多くのユースケースでサードパーティパッケージ`django-csp`を置き換え、リスクの低いReport-Onlyモードを提供します
- 新しいデフォルトの**BigAutoField**、非同期ページネーション、シェルの自動インポート、モダナイズされたPythonメールAPIがリリースを補完しています
- **面接対策**としては、複合キーの制約事項、タスクフレームワークとCeleryの使い分け、ミドルウェアの実行順序が特に重要なテーマです
---
Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/ja/blog/django/django-6-composite-primary-keys-background-tasks-2026