カスタムユーザーモデルは、Django のデフォルトの User を置き換え、アプリケーションの要件に合わせることができます — フィールドの追加、ログイン識別子の変更（例：ユーザー名の代わりにメール）、または動作のカスタマイズが可能です。重要で、何度も強調される助言があります：カスタムユーザーモデルをプロジェクトの最初から設定してください。後で変更するのは非常に大変だからです。
The default User has fixed fields (username, email, first/last name) and uses
USERNAME as the login field. Real apps often need:
✓ Email-based login (no username)
✓ Extra fields (phone, avatar, role, preferences) on the user itself
✓ Custom authentication behavior
⚠️ Changing the user model AFTER migrations exist is VERY hard — the User model is
referenced by auth, admin, sessions, foreign keys throughout the database.
Swapping it later requires complex, risky data migrations.
→ ALWAYS define a custom user model at project START (before the first migration),
even an empty one, so you can extend it freely later. Django's docs strongly
recommend this for EVERY new project.
これが重要な実践的な教訓です：初日にカスタムユーザーモデルを設定するのはほぼコスト無しですが、確立されたプロジェクトに後付けするのは大変で、エラーが起きやすい取り組みです — ですからあらかじめ保険として設定します。
# models.py — add fields, keep Django's auth behavior
from django.contrib.auth.models import AbstractUser
class User(AbstractUser):
phone = models.CharField(max_length=20, blank=True)
avatar = models.ImageField(upload_to="avatars/", blank=True)
is_premium = models.BooleanField(default=False)
# settings.py — tell Django to use it
AUTH_USER_MODEL = "myapp.User"
AbstractUser は Django のすべてのデフォルトフィールドと認証メカニズムを保持します — フィールドを追加するだけです。最もシンプルで一般的なアプローチです。
from django.contrib.auth.models import AbstractBaseUser, BaseUserManager, PermissionsMixin
class User(AbstractBaseUser, PermissionsMixin):
email = models.EmailField(unique=True)
USERNAME_FIELD = "email" # log in with EMAIL instead of username
REQUIRED_FIELDS = []
objects = CustomUserManager() # a manager defining create_user/create_superuser
AbstractBaseUser はユーザーモデルの完全な制御を提供します（例：メールのみのログインのためにユーザー名を完全に削除）— より多くの作業が必要ですが、最大の柔軟性があります。
from django.conf import settings
from django.contrib.auth import get_user_model
# in models — reference via settings.AUTH_USER_MODEL
author = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)
# in code — get the active user model dynamically
User = get_user_model() # NOT a direct import of the default User
ユーザーモデルは常に settings.AUTH_USER_MODEL（モデル内）と get_user_model()（コード内）経由で参照してください。デフォルトの User を直接インポートしないでください — そうすることでコードがカスタムモデルで動作します。
カスタムユーザーモデルの使用は重要な知識です。すべての Django 開発者が内面化すべき重要で、頻繁に強調される実践的な教訓があります：すべてのプロジェクトの最初から設定してください。
これがこれほど重要なのは、困難さの大きな非対称性があるからです — 初日にカスタムユーザーモデルを定義する（空の AbstractUser サブクラスでも）のはほぼコスト無しで、計り知れない柔軟性を提供します。一方、プロジェクトがマイグレーションとデータを持った後にカスタムユーザーモデルに切り替えるのは非常に大変でリスキーです。なぜなら、User モデルは Django 全体（認証、admin、セッション）で深く参照されており、データベース全体の外部キーによっても参照されているためです。複雑で、エラーが起きやすいデータマイグレーションが必要です。
これが Django の公式ドキュメントが新しいプロジェクトすべてのカスタムユーザーモデルを強く推奨する理由です。差し迫ったニーズがなくても、それは将来のマイグレーションの悪夢に対する保険です。
この重要なタイミングの助言を超えて、カスタムユーザーモデルの作成方法を理解することは重要です — AbstractUser は Django の認証動作を保持しながらフィールドを追加するだけの場合（一般的で簡単な場合）、AbstractBaseUser はメールベースのログイン（ユーザー名を完全に削除）のような完全な制御を可能にします — これは実際のアプリケーション要件（追加ユーザーフィールド、代替ログイン識別子、カスタム認証）を満たすために価値があります。
等しく重要なのは、ユーザーモデルを正しく参照する方法を知ることです（settings.AUTH_USER_MODEL と get_user_model() 経由で、直接インポートではなく）。設定されたユーザーモデルで動作するコードになります。
ほぼすべての実際のアプリケーションは Django のデフォルトを超えたユーザー固有の要件があります（そうでないものでさえ柔軟性の恩恵を受けます）。また、この設定を早期にしないのコストが非常に高いため、カスタムユーザーモデルの理解は — 特に、プロジェクト開始時に設定する命令の重要性 — 重要で、実践的に重要な知識です。これは一般的で深刻なプロジェクトレベルの間違いを防ぎ、Django のベストプラクティスの知恵の中で頻繁に引用される要素です。