Djangoのミドルウェアとは何ですか？

Question

IT Interview Practice · Accepted Answer

**ミドルウェア**は、Webサーバーとビューの間に位置し、**すべてのリクエストとレスポンスを**グローバルに処理するフックのフレームワークです。各ミドルウェアは、入ってくるリクエストを検査・修正したり、出ていくレスポンスを修正したりできます。認証、セキュリティヘッダー、セッション、ログなど、横断的関心事に最適です。

## ミドルウェアを通じたリクエスト/レスポンスフロー

```text
Request  → MW1 → MW2 → MW3 → VIEW
Response ← MW1 ← MW2 ← MW3 ← VIEW

Middleware wraps the view like layers of an onion:
  - on the way IN (request): top-to-bottom
  - on the way OUT (response): bottom-to-top (reverse order)
```

## Djangoの組み込みミドルウェア（settings.pyの場合）

```python
MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",          # security headers (HSTS, etc.)
    "django.contrib.sessions.middleware.SessionMiddleware",   # enables request.session
    "django.middleware.common.CommonMiddleware",
    "django.middleware.csrf.CsrfViewMiddleware",              # CSRF protection
    "django.contrib.auth.middleware.AuthenticationMiddleware",# enables request.user
    "django.middleware.clickjacking.XFrameOptionsMiddleware", # clickjacking protection
]
# ORDER MATTERS — e.g. SessionMiddleware must come before AuthenticationMiddleware
```

Djangoのコア機能の多くはミドルウェアです。セッション（`request.session`）、認証（`request.user`）、CSRF保護、セキュリティヘッダーはすべて組み込みミドルウェアから提供されます。**順序が重要**です。一部のミドルウェアは他のミドルウェアが先に実行されることに依存しています。

## カスタムミドルウェアの作成

```python
class TimingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response          # the next middleware/view

def __call__(self, request):
        # --- code here runs on the way IN (before the view) ---
        import time; start = time.time()

response = self.get_response(request)     # call the next layer (eventually the view)

# --- code here runs on the way OUT (after the view) ---
        response["X-Response-Time"] = f"{time.time() - start:.3f}s"
        return response
```

ミドルウェアはコール可能なオブジェクトです。`self.get_response(request)`の前のコードはリクエスト時に実行され、後のコードはレスポンス時に実行されます。これにより、ビューの実行前後の両方で動作できます。

## ミドルウェアの一般的な用途

```text
✓ Authentication / setting request.user
✓ Security headers (CSP, HSTS, X-Frame-Options)
✓ Request/response logging, timing, metrics
✓ Sessions, locale/i18n detection, CORS
✓ Rate limiting, maintenance mode, custom request preprocessing
```

## ミドルウェア対ビュー/デコレータ

```text
Middleware → GLOBAL, cross-cutting concerns affecting EVERY (or most) request
Decorators/view logic → per-view concerns specific to certain endpoints
→ Use middleware for app-wide behavior; decorators for selective behavior.
```

## なぜ重要なのか

ミドルウェアはDjangoがリクエストを処理する方法の基本であり、これを理解することでフレームワークのコア機能がどのように実装されているかが明確になり、**グローバルな横断的関心事**に対する適切なメカニズムが提供されます。

セッション、認証（`request.user`）、CSRF保護、セキュリティヘッダーがすべて組み込みミドルウェアから提供されていることを認識することで、これらの機能がなぜ「そのまま動作する」のかが理解できます。**オニオンレイヤーのリクエスト/レスポンスフロー**（ミドルウェアがビューをラップし、リクエストは上から下へ、レスポンスは下から上へ処理される）と**順序が重要**である（認証はセッションが先に実行される必要があるなど、ミドルウェア間に依存性がある）ことを理解することは、Djangoを正しく設定し問題をデバッグするために重要です。

**カスタムミドルウェアを作成**できる能力は、ログ記録、計時、カスタムヘッダー、レート制限、メンテナンスモードなどのアプリケーション全体の動作をきれいに実装するのに価値があります。これはビュー全体で繰り返すのではなく、1か所で実装できます。

ミドルウェア（ほとんどのリクエストに影響するグローバルな関心事）対デコレータまたはビューロジック（エンドポイント単位の関心事）をいつ使用するかを知ることは、重要なアーキテクチャ上の決定です。

ミドルウェアは、アプリケーション全体に適用されるリクエスト/レスポンス処理をDjangoが処理する場所であり、フレームワークの内部機構を理解し、横断的関心事を適切に分離した構造の良いアプリケーションを構築するための実践的で関連性の高い知識となります。

ミドルウェアを通じたリクエスト/レスポンスフロー

Djangoの組み込みミドルウェア（settings.pyの場合）

カスタムミドルウェアの作成

ミドルウェアの一般的な用途

ミドルウェア対ビュー/デコレータ

なぜ重要なのか

関連する質問