# Django 5.2 カスタムミドルウェアとシグナル処理：技術面接で差をつける実践ガイド

> Django 5.2のカスタムミドルウェアとシグナル処理を技術面接の観点から徹底解説。非同期ミドルウェア、カスタムシグナル、実装パターンを網羅した実践ガイドです。

- Published: 2026-04-29
- Updated: 2026-04-29
- Author: SharpSkill
- Tags: django, python, middleware, signals, interview
- Reading time: 9 min

---

Django の技術面接において、ミドルウェアとシグナルはアーキテクチャの理解度を測る重要なテーマとして頻出します。単にコードが書けるだけでなく、リクエスト処理の流れやイベント駆動設計の本質を理解しているかどうかが問われるためです。Django 5.2 では非同期ミドルウェアのサポートが安定し、シグナルにも `asend()` / `asend_robust()` といった非同期対応が加わりました。本記事では、技術面接で問われやすいポイントに焦点を当てながら、カスタムミドルウェアとシグナル処理の実装パターンを体系的に解説します。

> **面接クイックリファレンス**
>
> Django のミドルウェアは MIDDLEWARE リストの上から下へリクエストを処理し、レスポンスは下から上へ返されます。シグナルはパブリッシュ・サブスクライブパターンに従い、送信側がイベントをブロードキャストし、受信側が直接的な結合なしに反応します。どちらの概念もシニアレベルの Django 面接で出題されやすいテーマです。構文の知識だけでなく、アーキテクチャ全体への理解が試されるからです。

## ミドルウェアの基本構造を理解する

Django のミドルウェアは、リクエストとレスポンスの間に介入する処理レイヤーです。すべてのミドルウェアは共通のインターフェースに従っており、`__init__` メソッドでの初期化と `__call__` メソッドでのリクエスト・レスポンス処理という2つの要素で構成されます。

```python
# middleware.py - Basic middleware structure
class SimpleMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response
        # One-time configuration happens here at server start

    def __call__(self, request):
        # Code executed BEFORE the view (and later middleware)
        response = self.get_response(request)
        # Code executed AFTER the view (on the way back)
        return response
```

この構造は面接で最初に問われる基礎知識です。`__init__` はサーバー起動時に一度だけ実行され、`__call__` はリクエストごとに呼び出されます。`get_response` は次のミドルウェアまたはビュー関数への参照であり、この呼び出しの前後にカスタムロジックを配置できるという点が設計の核心です。

面接官が確認したいのは、この「前処理と後処理」の概念を正しく理解しているかどうかです。`self.get_response(request)` の呼び出し前に書かれたコードはリクエストの受信時に実行され、呼び出し後に書かれたコードはレスポンスの返却時に実行されます。

## 実践的なリクエストロギングミドルウェア

実際のプロジェクトでは、リクエストのログ記録は最も一般的なミドルウェアのユースケースの一つです。以下の例は、リクエストの処理時間、HTTPメソッド、パス、ステータスコード、クライアントIPを記録する実装です。

```python
# apps/core/middleware.py
import logging
import time

logger = logging.getLogger('django.request')

class RequestLoggingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        start_time = time.monotonic()
        # Attach metadata before view processing
        request.start_time = start_time

        response = self.get_response(request)

        duration = time.monotonic() - start_time
        logger.info(
            'method=%s path=%s status=%d duration=%.3fs ip=%s',
            request.method,
            request.get_full_path(),
            response.status_code,
            duration,
            request.META.get('REMOTE_ADDR'),
        )
        return response

    def process_exception(self, request, exception):
        # Called only when the view raises an exception
        duration = time.monotonic() - getattr(request, 'start_time', 0)
        logger.error(
            'method=%s path=%s exception=%s duration=%.3fs',
            request.method,
            request.get_full_path(),
            str(exception),
            duration,
        )
        return None  # Let Django's default exception handling continue
```

ここで注目すべきポイントは `process_exception` フックです。このメソッドはビューが例外を送出した場合にのみ呼び出されます。`None` を返すことで Django のデフォルトの例外処理に委ねることができ、`HttpResponse` を返すことでカスタムエラーレスポンスを生成することも可能です。技術面接では、`process_exception` の戻り値によって処理フローがどう変わるかを問われることがあります。

また、`time.monotonic()` を使用している点も重要です。`time.time()` はシステムクロックの調整に影響されますが、`time.monotonic()` は単調増加が保証されており、経過時間の計測に適しています。

## ミドルウェアの実行順序

ミドルウェアの実行順序は、`settings.py` の `MIDDLEWARE` リストで定義されます。この順序はリクエスト処理の正確性に直接影響するため、面接でも頻繁に問われるテーマです。

```python
# settings.py - Middleware ordering matters
MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    # Custom middleware placed after Django's core stack
    'apps.core.middleware.RequestLoggingMiddleware',
]
```

リクエストはリストの上から下へ処理され、レスポンスは下から上へ返されます。この「玉ねぎ構造」とも呼ばれるパターンにより、例えば `SecurityMiddleware` は最初にリクエストを受け取り、最後にレスポンスを処理します。

面接で特に問われるのは、「なぜ `AuthenticationMiddleware` は `SessionMiddleware` の後に配置する必要があるのか」という質問です。認証処理はセッションデータに依存するため、セッションミドルウェアが先にリクエストを処理してセッション情報をアタッチしている必要があります。カスタムミドルウェアを追加する際も、依存関係を考慮した配置が求められます。

## Django 5.2 の非同期ミドルウェア

Django 5.2 では、非同期ビューとの統合がさらに強化されました。非同期ミドルウェアを実装するには、`async_capable` と `sync_capable` のフラグを設定し、`__call__` メソッドを `async` として定義します。

```python
# apps/core/middleware.py
import asyncio
import time

class AsyncTimingMiddleware:
    # Mark this middleware as async-capable
    async_capable = True
    sync_capable = False

    def __init__(self, get_response):
        self.get_response = get_response

    async def __call__(self, request):
        start = time.monotonic()
        # get_response is awaitable in async context
        response = await self.get_response(request)
        duration = time.monotonic() - start
        response['X-Request-Duration'] = f'{duration:.4f}s'
        return response
```

`sync_capable = False` を設定すると、このミドルウェアは非同期コンテキストでのみ動作します。同期ビューと非同期ビューの両方をサポートする場合は、`sync_capable = True` も設定し、`__call__` メソッド内で適切に分岐する必要があります。

面接では、「同期ミドルウェアと非同期ミドルウェアが混在した場合、Django はどのように処理するか」という質問がよく出されます。Django は必要に応じてスレッドプールを使って同期・非同期の変換を自動的に行いますが、この変換にはオーバーヘッドが伴います。パフォーマンスが重要なアプリケーションでは、ミドルウェアスタック全体を同期または非同期に統一することが推奨されます。

## シグナルの基本：post_save と pre_save

シグナルは Django のイベント駆動アーキテクチャの中核を成すメカニズムです。モデルのライフサイクルイベント（保存、削除など）に対して、疎結合な形で処理を追加できます。

最も頻繁に使用されるのは `post_save` シグナルです。以下の例は、ユーザー作成時に自動的にプロフィールを生成する実装です。

```python
# apps/accounts/signals.py
from django.db.models.signals import post_save
from django.dispatch import receiver
from django.contrib.auth import get_user_model
from apps.accounts.models import UserProfile

User = get_user_model()

@receiver(post_save, sender=User)
def create_user_profile(sender, instance, created, **kwargs):
    # 'created' is True only on INSERT, False on UPDATE
    if created:
        UserProfile.objects.create(
            user=instance,
            display_name=instance.get_full_name() or instance.username,
        )
```

`created` パラメータは、そのレコードが新規作成（INSERT）されたのか、既存レコードの更新（UPDATE）なのかを判別するためのフラグです。面接では、このパラメータを使わずに毎回プロフィールを作成しようとするとどうなるかを問われることがあります（`IntegrityError` が発生します）。

一方、`pre_save` シグナルはモデルがデータベースに保存される前に発火します。以下は、ブログ記事のスラッグを自動生成する例です。

```python
# apps/blog/signals.py
from django.db.models.signals import pre_save
from django.dispatch import receiver
from django.utils.text import slugify
from apps.blog.models import Article

@receiver(pre_save, sender=Article)
def auto_generate_slug(sender, instance, **kwargs):
    if not instance.slug:
        base_slug = slugify(instance.title)
        slug = base_slug
        counter = 1
        # Ensure slug uniqueness
        while Article.objects.filter(slug=slug).exclude(pk=instance.pk).exists():
            slug = f'{base_slug}-{counter}'
            counter += 1
        instance.slug = slug
```

この実装では、スラッグの一意性を保証するためにデータベースクエリを実行しています。面接では、この処理が競合状態（Race Condition）を引き起こす可能性について質問されることがあります。高トラフィック環境では、データベースレベルのユニーク制約と `try/except IntegrityError` を組み合わせるアプローチが推奨されます。

## シグナルの登録と AppConfig.ready()

シグナルのレシーバーを正しく登録することは、Django アプリケーションの動作を保証する上で不可欠です。Django の公式ドキュメントが推奨する方法は、`AppConfig.ready()` メソッド内でシグナルモジュールをインポートすることです。

```python
# apps/accounts/apps.py
from django.apps import AppConfig

class AccountsConfig(AppConfig):
    default_auto_field = 'django.db.models.BigAutoField'
    name = 'apps.accounts'

    def ready(self):
        # Import signals module to register receivers
        import apps.accounts.signals  # noqa: F401
```

面接で頻出する質問の一つは、「なぜ `ready()` メソッドを使うのか。なぜモデルファイル内でシグナルを登録しないのか」というものです。`ready()` メソッドはアプリケーションレジストリの準備が完了した後に一度だけ呼び出されるため、すべてのモデルが利用可能な状態でシグナルを安全に登録できます。モデルファイル内でシグナルをインポートすると、循環インポートやモデルの初期化順序の問題が発生する可能性があります。

## カスタムシグナルでビジネスロジックを分離する

Django の組み込みシグナルだけでなく、独自のシグナルを定義してビジネスロジックの分離を実現できます。これは、大規模なアプリケーションにおけるアーキテクチャ設計の重要な要素です。

```python
# apps/orders/signals.py
from django.dispatch import Signal

# Define custom signals with documentation
order_completed = Signal()  # Sent after payment confirmation
order_refunded = Signal()   # Sent after refund processing

# apps/orders/services.py
from apps.orders.signals import order_completed

def complete_order(order):
    order.status = 'completed'
    order.save()
    # Dispatch signal with relevant context
    order_completed.send(
        sender=order.__class__,
        order=order,
        total=order.total_amount,
    )

# apps/notifications/receivers.py
from django.dispatch import receiver
from apps.orders.signals import order_completed

@receiver(order_completed)
def send_order_confirmation_email(sender, order, **kwargs):
    # Email logic decoupled from order processing
    from apps.notifications.services import send_email
    send_email(
        to=order.customer.email,
        template='order_confirmation',
        context={'order': order},
    )
```

カスタムシグナルの利点は、注文処理モジュールが通知モジュールの存在を知る必要がないという点です。新しい処理（例えば在庫更新や分析イベントの送信）を追加する場合も、注文処理のコードを変更せずにレシーバーを追加するだけで対応できます。

ただし、面接ではシグナルの過度な使用に対する批判についても言及できると評価が高まります。シグナルは暗黙的な処理フローを生み出すため、デバッグが困難になることがあります。明示的なサービスレイヤーでの関数呼び出しの方が適切な場合も多いため、使い分けの判断力が問われます。

## 面接で問われるピットフォール

技術面接では、ミドルウェアとシグナルに関する典型的な落とし穴についても質問されます。

> **シグナルと QuerySet.update() の注意点**
>
> Django の QuerySet.update() や bulk_create() メソッドは、モデルの save() メソッドを完全にバイパスします。これは、pre_save および post_save シグナルが発火しないことを意味します。同様に、QuerySet に対する delete() と単一モデルインスタンスに対する delete() では挙動が異なります。これは面接で最も頻繁に出題される Django シグナルの質問の一つです。

この挙動を理解しているかどうかは、実務経験の有無を判断する指標として面接官に利用されることが多いです。バルク操作でシグナルが必要な場合は、個別のインスタンスに対して `save()` をループで呼び出すか、カスタムマネージャーでシグナル発火を明示的に実装する必要があります。

## ミドルウェアとシグナルの使い分け

面接では、ミドルウェアとシグナルの適切な使い分けについても問われます。以下の比較表は、それぞれの適用領域を整理したものです。

| 観点 | ミドルウェア | シグナル |
|---|---|---|
| リクエスト/レスポンスの変更 | 可能 | 不可 |
| 認証と認可 | 可能 | 不可 |
| モデルライフサイクルフック | 不可 | 可能 |
| 横断的関心事（ログ、計測） | 可能 | 可能だが非推奨 |
| 疎結合なビジネスロジック | 不可 | 可能 |
| Django 5.2 での非同期サポート | 完全対応 | 完全対応（asend/asend_robust） |
| 実行スコープ | すべての HTTP リクエスト | 特定のイベント（save、delete、カスタム） |

この表が示す通り、ミドルウェアは HTTP リクエスト・レスポンスサイクルに関連する処理に適しており、シグナルはモデルのライフサイクルやビジネスイベントに対するリアクティブな処理に適しています。

> **Django 5.2 LTS**
>
> Django 5.2 は長期サポート（LTS）リリースであり、2028年4月までセキュリティアップデートが提供されます。非同期ミドルウェアおよびシグナルの改善は本番環境での使用が安定しているとみなされています。面接官は、従来の同期的な Django の知識に加えて、非同期パターンへの理解も候補者に求めるようになっています。

## まとめ

Django 5.2 におけるカスタムミドルウェアとシグナル処理は、技術面接で頻繁に問われるテーマです。本記事で解説した内容を整理すると、以下のポイントが重要です。

- **ミドルウェアの基本構造**: `__init__` はサーバー起動時に一度、`__call__` はリクエストごとに実行される。`get_response` の前後でリクエスト処理とレスポンス処理を分離する
- **実行順序の重要性**: `MIDDLEWARE` リストの順序がリクエスト処理フローを決定する。依存関係（セッション → 認証など）を正しく理解する
- **非同期ミドルウェア**: `async_capable` と `sync_capable` フラグによる非同期対応。Django 5.2 で安定した本番利用が可能
- **シグナルの基本**: `pre_save`、`post_save` の違いと `created` パラメータの使い方。`AppConfig.ready()` での正しい登録方法
- **カスタムシグナル**: ビジネスロジックの分離と疎結合アーキテクチャの実現。ただし過度な使用はデバッグを困難にする
- **バルク操作の落とし穴**: `QuerySet.update()` や `bulk_create()` はシグナルを発火しない。面接での頻出テーマ
- **使い分けの判断**: ミドルウェアは HTTP サイクル、シグナルはモデルイベントとビジネスイベントという明確な基準で選択する

これらの知識を体系的に整理し、実装経験に基づいた説明ができるようにしておくことが、技術面接での高評価につながります。

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/ja/blog/django/django-5-2-custom-middleware-signals