Django ORMはデータベースとのやり取りをエレガントに抽象化しますが、その手軽さの裏で重大なパフォーマンス問題が見えなくなることがあります。最適化が不十分なDjangoアプリケーションは、本来1つのクエリで済むところで何百ものクエリを発行しかねません。本記事では、こうした問題を見つけて解決するために欠かせない手法を順を追って解説します。

最適化の黄金ルール

最適化の前にまず計測することが大切です。開発環境でdjango-debug-toolbarを使用すると、生成されたSQLクエリを一つひとつ確認でき、ボトルネックを素早く特定できます。

N+1問題を理解する

N+1問題は、ORMで遭遇する最も典型的な落とし穴です。最初のクエリでN個のオブジェクトを取得した後、各オブジェクトのリレーションへアクセスするためにさらにN本のクエリが発行されます。クエリが乗算的に増えることで、パフォーマンスは大きく低下します。

python

# models.py
from django.db import models

class Author(models.Model):
    """書籍の著者を表すモデルです。"""
    name = models.CharField(max_length=200)
    email = models.EmailField(unique=True)
    bio = models.TextField(blank=True)

    def __str__(self):
        return self.name

class Book(models.Model):
    """著者と紐づく書籍を表すモデルです。"""
    title = models.CharField(max_length=300)
    author = models.ForeignKey(
        Author,
        on_delete=models.CASCADE,
        related_name='books'
    )
    published_date = models.DateField()
    isbn = models.CharField(max_length=13, unique=True)

    def __str__(self):
        return self.title

このシンプルなモデル構成によって、N+1問題を具体的に説明できます。

python

# views.py - 問題のある例
def list_books_bad(request):
    """❌ このビューはN+1クエリを生成します。"""
    books = Book.objects.all()  # 書籍取得用に1クエリ

    for book in books:
        # book.authorへアクセスするたびにSQLクエリが発生します
        print(f"{book.title} 著者: {book.author.name}")

    # 100冊の場合は101本のSQLクエリ!
    return render(request, 'books/list.html', {'books': books})

このコードは一見問題なさそうですが、書籍ごとに著者を取得するクエリが発行されます。

select_relatedでN+1を解決する

select_relatedメソッドはSQLのJOINを実行し、関連データを1つのクエリで取得します。ForeignKeyやOneToOneFieldのリレーションに対応します。

python

# views.py - select_relatedで最適化したパターン
def list_books_optimized(request):
    """✅ このビューはJOINを伴う単一クエリを生成します。"""
    # select_relatedはSQLのJOINを実行します
    books = Book.objects.select_related('author').all()

    for book in books:
        # 追加クエリは発生しません: 著者がすでにロード済み
        print(f"{book.title} 著者: {book.author.name}")

    # 合計: 書籍数に関係なくSQLは1本だけ
    return render(request, 'books/list.html', {'books': books})

生成されるSQLはLEFT OUTER JOINを利用し、著者と書籍を同時に取得します。

python

# select_relatedをチェーンしてネストしたリレーションへ対応
# models.py
class Publisher(models.Model):
    name = models.CharField(max_length=200)
    country = models.CharField(max_length=100)

class Book(models.Model):
    title = models.CharField(max_length=300)
    author = models.ForeignKey(Author, on_delete=models.CASCADE)
    publisher = models.ForeignKey(Publisher, on_delete=models.CASCADE)

# views.py
def list_books_with_details(request):
    """書籍・著者・出版社を1クエリでまとめて取得します。"""
    books = Book.objects.select_related(
        'author',      # AuthorへのForeignKey
        'publisher'    # PublisherへのForeignKey
    ).all()

    return render(request, 'books/list.html', {'books': books})

複数のリレーションをselect_relatedに列挙することで同時に最適化できます。

prefetch_relatedでManyToManyを最適化する

ManyToManyや逆方向のリレーション(他方から見たForeignKey)では、prefetch_relatedが分割された最適なクエリを実行し、巨大なJOINを避けます。

python

# models.py
class Tag(models.Model):
    """書籍を分類するためのタグです。"""
    name = models.CharField(max_length=50, unique=True)

    def __str__(self):
        return self.name

class Book(models.Model):
    title = models.CharField(max_length=300)
    author = models.ForeignKey(Author, on_delete=models.CASCADE)
    tags = models.ManyToManyField(Tag, related_name='books')

BookとTagのManyToMany関係を効率よく扱うためにはprefetch_relatedが必要です。

python

# views.py - ManyToManyの最適化
def list_books_with_tags(request):
    """✅ 書籍とそのタグを効率よく取得します。"""
    books = Book.objects.prefetch_related('tags').all()

    for book in books:
        # タグは事前ロードされているので追加クエリは発生しません
        tag_names = [tag.name for tag in book.tags.all()]
        print(f"{book.title}: {', '.join(tag_names)}")

    # 合計: 件数によらず2クエリ(書籍 + タグ)
    return render(request, 'books/list.html', {'books': books})

prefetch_relatedはタグ用に別クエリを実行し、結合はPython側で行います。

select_related と prefetch_related

ForeignKeyやOneToOneにはSQL JOINを行うselect_relatedを使用します。ManyToManyや逆リレーションには別クエリで取得するprefetch_relatedが向いています。同じQuerySetで併用も可能です。

Prefetchオブジェクトでプリロードをカスタマイズ

Prefetchオブジェクトは事前ロードされるデータをきめ細かく制御でき、フィルタリング、並び替え、件数の制限まで柔軟に行えます。

python

# views.py
from django.db.models import Prefetch

def list_authors_with_recent_books(request):
    """著者を、最近の書籍だけと一緒に取得します。"""
    # カスタムPrefetch: 2025年以降の書籍だけを対象にします
    recent_books_prefetch = Prefetch(
        'books',
        queryset=Book.objects.filter(
            published_date__year__gte=2025
        ).order_by('-published_date'),
        to_attr='recent_books'  # カスタム属性に保存します
    )

    authors = Author.objects.prefetch_related(
        recent_books_prefetch
    ).all()

    for author in authors:
        # カスタム属性からアクセスします
        for book in author.recent_books:
            print(f"{author.name}: {book.title}")

    return render(request, 'authors/list.html', {'authors': authors})

to_attr属性は通常のマネージャーではなくPythonのリストに結果を格納します。

python

# 高度な組み合わせ: select_related + Prefetch
def list_authors_complete(request):
    """多層的な最適化のフルセット例"""
    authors = Author.objects.prefetch_related(
        Prefetch(
            'books',
            queryset=Book.objects.select_related(
                'publisher'  # 各書籍の出版社も最適化
            ).prefetch_related(
                'tags'       # 各書籍のタグも事前ロード
            ).filter(published_date__year=2026)
        )
    ).all()

    return render(request, 'authors/complete.html', {'authors': authors})

この方式は、複雑なデータ構造でもクエリ数を大幅に削減します。

Djangoの面接対策はできていますか？

インタラクティブなシミュレーター、flashcards、技術テストで練習しましょう。

Djangoを探索する

only()とdefer()でカラムを限定する

Djangoはデフォルトでテーブルの全カラムを取得します。フィールドが多いモデルや巨大フィールドを持つモデルでは、カラムを絞ることでパフォーマンスが向上します。

python

# views.py
def list_books_minimal(request):
    """必要なカラムだけを取得します。"""
    # only()は取得するカラムを指定します
    books = Book.objects.only(
        'id',
        'title',
        'published_date'
    ).select_related('author')

    # 注意: 含めていないフィールドへアクセスするとクエリが発生します
    for book in books:
        print(book.title)  # OK、含めています
        # print(book.isbn)  # 追加クエリが発生します

    return render(request, 'books/list.html', {'books': books})

only()は指定したカラムのみをロードする「deferred」オブジェクトを生成します。

python

# defer()で特定のカラムを除外
def list_authors_without_bio(request):
    """あまり使わない大きなフィールドを除外します。"""
    # defer()は指定したカラムを除外します
    authors = Author.objects.defer(
        'bio'  # TextFieldはロードされません
    ).all()

    for author in authors:
        print(author.name)   # OK
        print(author.email)  # OK
        # author.bioは必要になった時点で取得されます

    return render(request, 'authors/list.html', {'authors': authors})

defer()はonly()の逆で、列挙されたカラムは初期ロード対象から外れます。

values()とvalues_list()で最適化する

モデルオブジェクト全体ではなく一部の値だけが必要な場合、values()とvalues_list()は軽量な辞書やタプルを返します。

python

# views.py
def get_book_titles(request):
    """タイトルだけをリストとして取得します。"""
    # values_listはタプルを返します
    titles = Book.objects.values_list('title', flat=True)
    # 結果: ['書籍1', '書籍2', ...]

    # valuesは辞書を返します
    book_data = Book.objects.values('title', 'published_date')
    # 結果: [{'title': '書籍1', 'published_date': ...}, ...]

    return render(request, 'books/titles.html', {'titles': titles})

これらのメソッドはモデルオブジェクトの生成を避け、メモリ消費を抑えます。

python

# 集計との組み合わせ
from django.db.models import Count, Avg

def get_author_statistics(request):
    """オブジェクトをロードせずに著者ごとの統計を計算します。"""
    stats = Author.objects.values('name').annotate(
        book_count=Count('books'),
        avg_year=Avg('books__published_date__year')
    ).order_by('-book_count')

    # 結果: [{'name': '著者', 'book_count': 5, 'avg_year': 2024}, ...]
    return render(request, 'authors/stats.html', {'stats': stats})

アノテーションを使えば、計算処理をデータベース側で実行できます。

インデックスを作成してクエリを高速化する

データベースのインデックスは検索を大幅に高速化します。Djangoではモデル内で直接インデックスを定義できます。

python

# models.py
from django.db import models

class Book(models.Model):
    title = models.CharField(max_length=300, db_index=True)
    author = models.ForeignKey(Author, on_delete=models.CASCADE)
    published_date = models.DateField()
    isbn = models.CharField(max_length=13, unique=True)
    status = models.CharField(max_length=20, default='available')

    class Meta:
        # 頻出クエリ向けの複合インデックス
        indexes = [
            # 出版日のインデックス(並び替えで頻繁に使用)
            models.Index(
                fields=['published_date'],
                name='book_pub_date_idx'
            ),
            # 著者 + ステータスでの絞り込み用複合インデックス
            models.Index(
                fields=['author', 'status'],
                name='book_author_status_idx'
            ),
            # 部分インデックス: 利用可能な書籍のみ
            models.Index(
                fields=['published_date'],
                name='book_available_idx',
                condition=models.Q(status='available')
            ),
        ]
        # インデックスを活かすデフォルトの並び順
        ordering = ['-published_date']

これらのインデックスは、対象カラムでフィルタするクエリのパフォーマンスを高めます。

インデックスと書き込み処理

インデックスは読み取りを高速化しますが、INSERTやUPDATEなどの書き込み処理を少し遅くします。WHERE、ORDER BY、JOINで頻繁に使うカラムに限定して作成するのが望ましいです。

必要な場合は生のSQLクエリを使う

複雑なクエリやデータベース固有の最適化が必要な場面では、生のSQLクエリで完全に制御できます。

python

# views.py
from django.db import connection

def get_books_with_raw_sql(request):
    """特殊ケース向けの生クエリ"""
    # 方法1: raw()でモデルオブジェクトを取得
    books = Book.objects.raw('''
        SELECT b.*, a.name as author_name
        FROM library_book b
        INNER JOIN library_author a ON b.author_id = a.id
        WHERE b.published_date > %s
        ORDER BY b.published_date DESC
    ''', ['2025-01-01'])

    return render(request, 'books/list.html', {'books': books})

def execute_custom_query(request):
    """SELECT以外のクエリを直接実行します。"""
    with connection.cursor() as cursor:
        # 複雑な集計を含むクエリ
        cursor.execute('''
            SELECT
                a.name,
                COUNT(b.id) as book_count,
                AVG(EXTRACT(YEAR FROM b.published_date)) as avg_year
            FROM library_author a
            LEFT JOIN library_book b ON b.author_id = a.id
            GROUP BY a.id, a.name
            HAVING COUNT(b.id) > 2
            ORDER BY book_count DESC
        ''')
        results = cursor.fetchall()

    return render(request, 'stats.html', {'results': results})

生クエリはORMを介しませんが、データベース間の移植性は失われます。

django-debug-toolbarでクエリを分析する

django-debug-toolbarを使うと、Djangoビューが発行したすべてのSQLクエリを可視化できます。

python

# settings.py - debug toolbar の設定
INSTALLED_APPS = [
    # ... ほかのアプリ
    'debug_toolbar',
]

MIDDLEWARE = [
    'debug_toolbar.middleware.DebugToolbarMiddleware',
    # ... ほかのミドルウェア
]

# ローカルからのリクエストでツールバーを表示
INTERNAL_IPS = ['127.0.0.1']

DEBUG_TOOLBAR_PANELS = [
    'debug_toolbar.panels.sql.SQLPanel',      # SQLクエリ
    'debug_toolbar.panels.timer.TimerPanel',  # 実行時間
    'debug_toolbar.panels.cache.CachePanel',  # キャッシュ
]

この設定で、最適化に役立つパネルが有効になります。

python

# 開発時にSQLクエリをロギング
# settings.py
LOGGING = {
    'version': 1,
    'handlers': {
        'console': {
            'class': 'logging.StreamHandler',
        },
    },
    'loggers': {
        'django.db.backends': {
            'level': 'DEBUG',
            'handlers': ['console'],
        },
    },
}

このロギング設定は、すべてのSQLクエリをコンソールに出力し、N+1問題の発見に役立ちます。

QuerySetをキャッシュする

アクセス頻度が高く更新が少ないデータでは、キャッシュによってクエリの繰り返しを防げます。

python

# views.py
from django.core.cache import cache
from django.views.decorators.cache import cache_page

def list_featured_books(request):
    """注目書籍をキャッシュ付きで取得します。"""
    cache_key = 'featured_books_list'

    # キャッシュからの取得を試みます
    books = cache.get(cache_key)

    if books is None:
        # キャッシュミス: クエリを実行
        books = list(
            Book.objects.select_related('author')
            .filter(featured=True)
            .order_by('-published_date')[:10]
        )
        # 5分間キャッシュに保存します
        cache.set(cache_key, books, timeout=300)

    return render(request, 'books/featured.html', {'books': books})

# ビュー全体をキャッシュするデコレーター
@cache_page(60 * 15)  # 15分キャッシュ
def list_all_tags(request):
    """タグ一覧(更新頻度の低いデータ)を表示します。"""
    tags = Tag.objects.annotate(
        book_count=Count('books')
    ).order_by('-book_count')

    return render(request, 'tags/list.html', {'tags': tags})

キャッシュは静的なデータのデータベース負荷を抑えます。

今すぐ練習を始めましょう！

面接シミュレーターと技術テストで知識をテストしましょう。

無料アカウントを作成

まとめ

Django ORMのクエリ最適化は、いくつかの基本原則に集約されます。

✅ 最適化前に計測する: django-debug-toolbarで実際の問題を可視化します

✅ N+1問題を排除する: ForeignKeyにはselect_related、ManyToManyにはprefetch_relatedを使います

✅ データを絞る: only()、defer()、values()で必要な情報だけを読み込みます

✅ 適切にインデックスを張る: 頻繁にフィルタや並び替えを行うカラムにインデックスを設けます

✅ 戦略的にキャッシュする: 更新が少ないデータほどDjangoのキャッシュ機構が活きます

✅ 生クエリ: データベース固有の最適化が必要なときの最終手段とします

これらの手法を体系的に適用することで、遅いDjangoアプリケーションは大量データを扱える高性能システムへと変貌します。Django ORMはその細部まで使いこなしてこそ、力強いツールであり続けます。

今すぐ練習を始めましょう！

面接シミュレーターと技術テストで知識をテストしましょう。

無料アカウントを作成

Django ORM: クエリを最適化して最大のパフォーマンスを引き出す

N+1問題を理解する

select_relatedでN+1を解決する

prefetch_relatedでManyToManyを最適化する

Prefetchオブジェクトでプリロードをカスタマイズ

Djangoの面接対策はできていますか？

only()とdefer()でカラムを限定する

values()とvalues_list()で最適化する

インデックスを作成してクエリを高速化する

必要な場合は生のSQLクエリを使う

django-debug-toolbarでクエリを分析する

QuerySetをキャッシュする

今すぐ練習を始めましょう！

まとめ

今すぐ練習を始めましょう！

関連記事

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

DjangoとPythonの面接質問：2026年版トップ25

Django 5: Django REST Frameworkで本格的なREST APIを構築する