概要（Django 設定＝「プロジェクト全体のルールブック」）
Django の設定（settings.py）は、
「このプロジェクトは、どんなルールで動くのか」を一箇所にまとめたファイルです。
どのアプリを使うか（INSTALLED_APPS）
どのデータベースにつなぐか（DATABASES）
どのタイムゾーン・言語で動かすか（TIME_ZONE, LANGUAGE_CODE）
テンプレートや静的ファイルの場所
セキュリティ関連（SECRET_KEY, DEBUG, ALLOWED_HOSTS）
といった「プロジェクト全体の設定」が全部ここに書かれます。
イメージとしては「学校の校則」「会社の就業規則」に近くて、
ここで決めたことに Django 全体が従います。
settings.py の基本構造をざっくりつかむ
BASE_DIR とファイルパス
settings.py の上の方に、だいたいこんなコードがあります。
from pathlib import Path
BASE_DIR = Path(__file__).resolve().parent.parent
BASE_DIR は「プロジェクトの一番上のフォルダ」を指す Path オブジェクトです。
テンプレートや静的ファイル、DB ファイル（SQLite）などのパスを
「BASE_DIR からの相対パス」で書けるようにするための基準点です。
例えば、SQLite を使うときはこうなります。
DATABASES = {
"default": {
"ENGINE": "django.db.backends.sqlite3",
"NAME": BASE_DIR / "db.sqlite3",
}
}
「プロジェクトをどこに置いても動く」ようにするために、
絶対パスではなく BASE_DIR ベースで書く、というのがポイントです。
SECRET_KEY と DEBUG
SECRET_KEY は、暗号化や署名に使われる「超重要な秘密鍵」です。
SECRET_KEY = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
開発環境ではあまり意識しなくても動きますが、
本番では「絶対に外に漏らさない」「GitHub に上げない」が鉄則です。
環境変数や .env ファイルから読み込むのが定番です。
DEBUG は「デバッグモードかどうか」を決めるフラグです。
DEBUG = True
True のときは、エラー画面に詳細なスタックトレースが出たり、
静的ファイルを自動で配信してくれたりします。
本番では必ず False にしないと、内部情報が丸見えになります。
ALLOWED_HOSTS
ALLOWED_HOSTS は、「どのホスト名からのアクセスを許可するか」を指定します。
ALLOWED_HOSTS = []
開発中は空でも動きますが、
DEBUG=False にすると、ここに自分のドメインや IP を入れないと
リクエストが拒否されます。
ALLOWED_HOSTS = ["example.com", "www.example.com"]
INSTALLED_APPS と MIDDLEWARE（Django の「拡張パーツ」を登録する場所）
INSTALLED_APPS＝「このプロジェクトで使うアプリ一覧」
INSTALLED_APPS は、
「このプロジェクトで有効にするアプリ」を列挙する設定です。
INSTALLED_APPS = [
"django.contrib.admin",
"django.contrib.auth",
"django.contrib.contenttypes",
"django.contrib.sessions",
"django.contrib.messages",
"django.contrib.staticfiles",
"myapp",
]
ここに書かれたアプリだけが、
マイグレーションの対象になる
テンプレートタグやシグナルなどが有効になる
といった扱いを受けます。
自分で作ったアプリ（python manage.py startapp myapp）は、
必ずここに追加しないと「存在しないもの」として扱われます。
初心者がよくやるミスは、
アプリを作ったのに INSTALLED_APPS に追加し忘れて
「モデルが認識されない」「管理画面に出てこない」と悩むパターンです。
MIDDLEWARE＝「リクエストとレスポンスの間に挟まる処理の列」
MIDDLEWARE は、
リクエストがビューに届く前、レスポンスがブラウザに返る前に
順番に通過する「フィルタ」のようなものです。
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",
"django.middleware.clickjacking.XFrameOptionsMiddleware",
]
セッション管理、認証、CSRF 対策など、
Django の重要な機能の多くはミドルウェアとして実装されています。
順番も大事で、
例えばセッションより前に認証はできないので、SessionMiddleware のあとに AuthenticationMiddleware が来ています。
初心者のうちは、
「よく分からなくても、とりあえずデフォルトの順番を崩さない」
というのが安全です。
URL, テンプレート、静的ファイルの設定
ROOT_URLCONF＝「最初に読む URLconf」
ROOT_URLCONF は、
「このプロジェクトの“入口”となる urls.py はどれか」を指定します。
ROOT_URLCONF = "config.urls"
ここで指定されたモジュール（例: config/urls.py）が、
最初に読み込まれる URLconf になります。
そこから include() で各アプリの urls.py に振り分けていく、
という構造でしたね（URLconf の話とつながります）。
TEMPLATES＝テンプレートエンジンと検索パス
TEMPLATES は、
「どのテンプレートエンジンを使い、どこを探すか」を決める設定です。
典型的にはこうなっています。
TEMPLATES = [
{
"BACKEND": "django.template.backends.django.DjangoTemplates",
"DIRS": [BASE_DIR / "templates"],
"APP_DIRS": True,
"OPTIONS": {
"context_processors": [
"django.template.context_processors.debug",
"django.template.context_processors.request",
"django.contrib.auth.context_processors.auth",
"django.contrib.messages.context_processors.messages",
],
},
},
]
重要なのは DIRS と APP_DIRS です。
DIRS は「プロジェクト共通のテンプレートフォルダ」を指定します。
例えば BASE_DIR / "templates" にしておくと、templates/ 直下のファイルを render(request, "index.html") のように呼び出せます。
APP_DIRS=True にすると、
各アプリ内の app_name/templates/ も自動で探索対象になります。
「アプリごとにテンプレートを分ける」標準的なスタイルがこれで実現されます。
STATIC_URL と STATICFILES_DIRS
静的ファイル（CSS, JS, 画像など）の設定も settings.py で行います。
STATIC_URL = "/static/"
開発中は、
各アプリの static/ フォルダや、STATICFILES_DIRS に指定したフォルダから
静的ファイルを探して配信してくれます。
STATICFILES_DIRS = [
BASE_DIR / "static",
]
本番では collectstatic コマンドで
全ての静的ファイルを STATIC_ROOT に集め、
Web サーバー（Nginx など）から配信する、という流れになりますが、
初心者のうちは「開発中は STATIC_URL と STATICFILES_DIRS だけ押さえる」で十分です。
データベース、言語、タイムゾーンの設定
DATABASES＝「どの DB にどうつなぐか」
DATABASES は、
使用するデータベースと接続情報をまとめた設定です。
開発のデフォルトは SQLite です。
DATABASES = {
"default": {
"ENGINE": "django.db.backends.sqlite3",
"NAME": BASE_DIR / "db.sqlite3",
}
}
PostgreSQL などに変えたいときは、ENGINE と NAME, USER, PASSWORD などを設定します。
DATABASES = {
"default": {
"ENGINE": "django.db.backends.postgresql",
"NAME": "mydb",
"USER": "myuser",
"PASSWORD": "mypassword",
"HOST": "localhost",
"PORT": "5432",
}
}
ここを変えると、
マイグレーションの適用先も変わるので、
「どの環境でどの DB を使っているか」を意識しておくことが大事です。
LANGUAGE_CODE と TIME_ZONE
LANGUAGE_CODE と TIME_ZONE は、
アプリのデフォルト言語とタイムゾーンを決めます。
LANGUAGE_CODE = "ja"
TIME_ZONE = "Asia/Tokyo"
USE_I18N = True
USE_TZ = True
日本向けのアプリなら、
TIME_ZONE を “Asia/Tokyo” にしておくのが基本です。
USE_TZ=True の場合、DB には UTC で保存され、
表示時に TIME_ZONE に合わせて変換されます。
「表示される時間が 9 時間ずれている」
といったトラブルは、だいたいここが原因です。
初心者が settings.py で意識しておくべき設計のポイント
「開発用」と「本番用」を分ける発想
最初は 1 つの settings.py で済みますが、
本番を意識し始めると、
DEBUG は本番で False にしたい
SECRET_KEY や DB パスワードは環境ごとに変えたい
ALLOWED_HOSTS も環境ごとに違う
といった要件が出てきます。
そこでよくやるのが、
共通設定（base.py）
開発用（dev.py）
本番用（prod.py）
のように設定ファイルを分割し、
環境変数 DJANGO_SETTINGS_MODULE で
どれを使うか切り替える、というパターンです。
初心者のうちは、
「いずれ開発用と本番用を分けることになる」
という未来だけ頭に置いておけば十分です。
「よく分からない設定は、まずは触らない」でいい
settings.py には、
最初から大量の設定が並んでいて圧倒されますが、
全部を理解する必要はありません。
最初にしっかり押さえるべきなのは、このあたりです。
SECRET_KEY / DEBUG / ALLOWED_HOSTS
INSTALLED_APPS / MIDDLEWARE
ROOT_URLCONF / TEMPLATES / STATIC_*
DATABASES
LANGUAGE_CODE / TIME_ZONE
それ以外は、
「何かを実現したくなったときに、その都度調べて追加する」
くらいのスタンスで大丈夫です。
設定ファイルは「一気に全部覚えるもの」ではなく、
開発を進めながら少しずつ仲良くなっていく相手、
くらいに思っておくと気が楽になります。
まとめ（Django 設定は「プロジェクトの性格を決める中枢」）
Django の設定（settings.py）を初心者目線でまとめると、こうなります。
settings.py は「プロジェクト全体のルールブック」であり、アプリ一覧、ミドルウェア、DB、テンプレート、静的ファイル、言語・タイムゾーン、セキュリティなどを一箇所で管理する。
SECRET_KEY / DEBUG / ALLOWED_HOSTS はセキュリティと動作モードに直結する重要設定で、本番では特に慎重に扱う必要がある。
INSTALLED_APPS と MIDDLEWARE は「どの機能を有効にするか」「リクエストにどんな処理を挟むか」を決めるリストで、自作アプリを使うには INSTALLED_APPS に追加するのを忘れない。
ROOT_URLCONF, TEMPLATES, STATIC_* , DATABASES, LANGUAGE_CODE, TIME_ZONE などを押さえておくと、「URL がどこから始まるか」「テンプレートや静的ファイルをどこに置くか」「どの DB・どの時間軸で動くか」が理解できる。