【Python】Djangoモデル設計：なぜ null=True は避けるべきか？3つの実践的テクニック

2025年10月24日

Djangoでモデルを設計する際、null=True, blank=Trueというオプションは、「このフィールドは必須ではない」ことを示す便利な指定のように思えます。しかし、データベースレベルでNULLを許容することは、多くの場合、アプリケーションロジックを不必要に複雑にし、曖昧さを生み出し、潜在的なバグの原因となります。

データベースにおけるNULLは、「値がない」のか、「不明」なのか、「適用外」なのか、その意味が曖昧です。この曖昧さが、コードにif value is None:という余計な分岐を生み出します。

今回は、NULLを避け、よりクリーンで堅牢なモデル設計を行うための3つの実践的なテクニックを、具体的なフィールドタイプごとに解説します。

1. 文字列 (`CharField`)：「2種類の空」をなくす

最もよくあるNULLの誤用は、文字列フィールドです。

失敗例：`None`と`""`という2つの「空」が存在する

ユーザープロフィールに「自己紹介」欄を持たせるケースを考えてみましょう。

# 悪い例
class UserProfile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)
    # 必須ではないため、null=True, blank=True を設定
    bio = models.CharField(max_length=255, null=True, blank=True)

# アプリケーション側でのチェック
def get_user_bio(user):
    profile = user.userprofile
    # "データがない"状態を確認するために、Noneと空文字の両方をチェックする必要がある
    if profile.bio is None or profile.bio == "":
        return "自己紹介はまだありません。"
    return profile.bio

この設計では、「自己紹介がない」状態を表現するために、データベース上にはNULLと""（空文字）という2つの異なる値が共存してしまいます。これにより、ロジックは常に両方の可能性を考慮しなければなりません。

ベストプラクティス：`NULL`を禁止し、「空文字」に統一する

DjangoのCharFieldやTextFieldでは、**「空の値はNULLではなく空文字で保存する」**のが標準的な慣習です。

# 良い例
class UserProfile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)
    # DBレベルではNOT NULL制約を課す
    # フォームでの空入力を許可し、DBには空文字を保存する
    bio = models.CharField(max_length=255, blank=True, default="")

# アプリケーション側でのチェック
def get_user_bio(user):
    profile = user.userprofile
    # "空文字"はFalseと評価されるため、チェックが劇的に簡潔になる
    if not profile.bio:
        return "自己紹介はまだありません。"
    return profile.bio

null=False（デフォルト）とdefault=""を組み合わせることで、「空」の状態は常に""（空文字）に統一されます。これにより、データベースのNOT NULL制約によるデータ整合性が保たれ、Pythonコードもシンプルになります。

2. 日時 (`DateTimeField`)：「番兵」でロジックを単純化する

次に、オプショナルな日付、例えば記事の「公開終了日時」を考えてみましょう。NULLの場合は「無期限公開」を意味させたいとします。

失敗例：`None`チェックによるロジックの分岐

# 悪い例
class Article(models.Model):
    title = models.CharField(max_length=200)
    # NULLの場合は「無期限」
    expires_at = models.DateTimeField(null=True, blank=True)

    def is_visible(self):
        now = timezone.now()
        # ロジックがここで分岐する
        if self.expires_at is None:
            return True # 無期限公開
        return now < self.expires_at

このif self.expires_at is None:という分岐は、このロジックを扱うすべての場所で必要になり、コードの可読性を下げます。

ベストプラクティス：「センチネル値（番兵）」をデフォルトにする

NULLの代わりに、そのフィールドの文脈において「無期限」や「無限」を意味する**「センチネル値（番兵の値）」**をデフォルトとして設定します。日時の場合は、非常に遠い未来の日付がこれにあたります。

from datetime import datetime
from django.utils import timezone

# 非常に遠い未来の日付（例: 3000年1月1日）を「無期限」の代理として定義
FAR_FUTURE_DATETIME = datetime(3000, 1, 1, tzinfo=timezone.utc)

# 良い例
class Article(models.Model):
    title = models.CharField(max_length=200)
    # デフォルトを「非常に遠い未来」に設定
    expires_at = models.DateTimeField(default=FAR_FUTURE_DATETIME)

    def is_visible(self):
        now = timezone.now()
        # if文による分岐が不要になり、単一の比較ロジックで完結する
        return now < self.expires_at

NULLの可能性を排除することで、is_visibleメソッドはif文の分岐を持たない、非常にシンプルで堅牢なロジックになりました。

3. 外部キー (`ForeignKey`)：「関連の不在」で表現する

オプショナルな関連、例えば「ユーザーは複数のプロジェクトに参加できる（必須ではない）」というケースはどうでしょうか。

失敗例：`null=True`で「所属していない」を表現する

# 悪い例
class User(models.Model):
    username = models.CharField(max_length=100)
    # 多くのプロジェクトに参加する可能性があるのに、ForeignKeyでは不十分
    # さらに、所属していない状態をNULLで表現している
    project = models.ForeignKey(Project, null=True, blank=True, on_delete=models.SET_NULL)

この設計は、「所属していない」状態をNULLで表現するだけでなく、ユーザーが複数のプロジェクトに参加できるというビジネス要件も満たせていません。

ベストプラクティス：中間テーブルで「関係性」をモデル化する

NULLで関係の有無を表現する代わりに、**「関係性そのもの」**をモデル化する中間テーブル（関連モデル）を導入します。

# 良い例
class Project(models.Model):
    name = models.CharField(max_length=100)

class User(models.Model):
    username = models.CharField(max_length=100)
    # UserからProjectへの直接のForeignKeyは持たない

class Participation(models.Model):
    """ユーザーとプロジェクトの「参加」という関係性を表すモデル"""
    user = models.ForeignKey(User, on_delete=models.CASCADE)
    project = models.ForeignKey(Project, on_delete=models.CASCADE)
    role = models.CharField(max_length=50) # 例: 'Admin', 'Member'
    joined_at = models.DateTimeField(auto_now_add=True)

この設計では、「ユーザーがプロジェクトに参加していない」状態は、NULLによってではなく、**「そのユーザーとプロジェクトに対応するParticipationレコードが存在しない」**ことによって明確に表現されます。

これにより、NULLの曖昧さが排除されるだけでなく、「役割（role）」や「参加日（joined_at）」といった、関係性に関する追加情報を保持できるという大きなメリットも生まれます。