--- title: "設定" version: 5.2 locale: ja source: https://docs.djangoproject.com/ja/5.2/ref/settings/ canonical: https://djangodocs.dev/ja/5.2/ref/settings/ --- # 設定 - [コアの設定](#core-settings) - [認証](#auth) - [メッセージ](#messages) - [セッション](#sessions) - [サイト](#sites) - [静的ファイル](#static-files) - [コア設定 トピック別インデックス](#core-settings-topical-index) > **Warning** > > 設定を上書きするとき、特にデフォルト値が空でないリストや辞書の場合、例えば [`STATICFILES_FINDERS`](#std-setting-STATICFILES_FINDERS) などは、注意してください。Djangoの使用したい機能に必要なコンポーネントを保持するようにしてください。 ## コアの設定 ここでは、Django の core で利用できる設定とそのデフォルト値をリストしました。contrib アプリで提供される設定のリストは、core の設定のトピックのインデックスの下にあります。入門的な資料については、 [settings のトピックガイド](/ja/5.2/topics/settings/) を参照してください。 ### `ABSOLUTE_URL_OVERRIDES` デフォルト値: `{}` (空の辞書) `"app_label.model_name"` 文字列をモデルオブジェクトを受け取り、その URL を返す関数へのマッピングを行う辞書です。これは、インストールごとに `get_absolute_url()` メソッドを挿入またはオーバーライドする方法です。例： ``` ABSOLUTE_URL_OVERRIDES = { "blogs.blog": lambda o: "/blogs/%s/" % o.slug, "news.story": lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug), } ``` この設定で使用するモデル名は、実際のモデルクラス名の大文字小文字に関わらず、すべて小文字である必要があります。 ### `ADMINS` デフォルト値: `[]` (空のリスト) コードエラー通知を受け取る全ての人々のリストです。 [`DEBUG=False`](#std-setting-DEBUG) が設定され、 [`AdminEmailHandler`](/ja/5.2/ref/logging/#django.utils.log.AdminEmailHandler) が [`LOGGING`](#std-setting-LOGGING) に設定されている場合（デフォルトで設定されています）、Djangoはこれらの人々にリクエスト/レスポンスサイクルで発生した例外の詳細をメールで送信します。 リスト内の各項目は、(フルネーム、メールアドレス) のタプルである必要があります。例: ``` [("John", "john@example.com"), ("Mary", "mary@example.com")] ``` ### `ALLOWED_HOSTS` デフォルト値: `[]` (空のリスト) Django サイトを配信できるホスト/ドメイン名を表す文字列のリストです。これはセキュリティ対策の手段の1つで、一見安全な設定の Web サーバでも晒される可能性が高い、 [HTTP Host header 攻撃](/ja/5.2/topics/security/#host-headers-virtual-hosting) を防ぐことができます。 このリスト中の値は完全修飾名 (fully qualified names) (例: `'www.example.com'`) でも大丈夫です。その場合には、リクエストの `Host` ヘッダに完全一致するかチェックされます (ポートを含まない、大文字小文字を無視した比較になります)。ピリオドで始まる値は、サブドメインのワイルドカードとして利用できます。たとえば、`'.example.com'` は `example.com` や `www.example.com` などの他のすべての `example.com` サブドメインにマッチします。`'*'` という値はあらゆるヘッダにマッチします。この場合には、責任を持って自前の `Host` ヘッダ検証機 (おそらくミドルウェアの形になり、その場合は [`MIDDLEWARE`](#std-setting-MIDDLEWARE) 設定の最初に置く必要があります) を書かなければなりません。 Django はあらゆるエントリで [fully qualified domain name (FQDN)](https://en.wikipedia.org/wiki/Fully_qualified_domain_name) を許可しています。ブラウザの中には `Host` ヘッダの最後にドットを付けるもありますが、Django は host の検証機でそれを取り除きます。 `Host` ヘッダ (と [`USE_X_FORWARDED_HOST`](#std-setting-USE_X_FORWARDED_HOST) が有効な場合は `X-Forwarded-Host`) が、このリストのどれとも一致しない場合、 [`django.http.HttpRequest.get_host()`](/ja/5.2/ref/request-response/#django.http.HttpRequest.get_host) は [`SuspiciousOperation`](/ja/5.2/ref/exceptions/#django.core.exceptions.SuspiciousOperation) 例外を起こします。 [`DEBUG`](#std-setting-DEBUG) が `True` であり、かつ `ALLOWED_HOSTS` が空の場合、ホストは `['.localhost', '127.0.0.1', '[::1]']` に対して検証されます。 `ALLOWED_HOSTS` は、テストを実行する際にも [チェックされます](/ja/5.2/topics/testing/advanced/#topics-testing-advanced-multiple-hosts) 。 このヘッダの検証は [`get_host()`](/ja/5.2/ref/request-response/#django.http.HttpRequest.get_host) メソッドの実行時にのみ適用されます。もし `request.META` から直接 `Host` ヘッダにアクセスするコードを書いてしまうと、このセキュリティプロテクションを回避してしまうので注意してください。 ### `APPEND_SLASH` デフォルト値: `True` `True` に設定すると、リクエスト URL が URLconf 内のどのパターンにもマッチせず、/ で終わっていなかった場合に、末尾に / を追加した URL への HTTP リダイレクトを発行します。ただし、リダイレクトすると POST リクエストで送信するデータが失われることがあるので注意が必要です。 [`APPEND_SLASH`](#std-setting-APPEND_SLASH) 設定は [`CommonMiddleware`](/ja/5.2/ref/middleware/#django.middleware.common.CommonMiddleware) がインストールされているときのみ有効です。詳しくは see [ミドルウェア (Middleware)](/ja/5.2/topics/http/middleware/) を参照。また [`PREPEND_WWW`](#std-setting-PREPEND_WWW) も参照してください。 ### `CACHES` デフォルト値: ``` { "default": { "BACKEND": "django.core.cache.backends.locmem.LocMemCache", } } ``` Django で使用されるすべてのキャッシュの設定を含む辞書です。これは、キャッシュのエイリアスを個々のキャッシュのオプションを含む辞書にマッピングする内容のネストされた辞書です。 [`CACHES`](#std-setting-CACHES) 設定では、`default` キャッシュを設定する必要があります。追加で任意の数のキャッシュを指定することもできます。ローカルメモリキャッシュ以外のキャッシュバックエンドを使用する場合、または複数のキャッシュを定義する必要がある場合は、他のオプションが必要になります。以下のキャッシュオプションが利用可能です。 #### `BACKEND` デフォルト値: `''` (空文字列) 使用するキャッシュ用バックエンド。ビルトインのキャッシュ用バックエンドには、次のものがあります。 - `'django.core.cache.backends.db.DatabaseCache'` - `'django.core.cache.backends.dummy.DummyCache'` - `'django.core.cache.backends.filebased.FileBasedCache'` - `'django.core.cache.backends.locmem.LocMemCache'` - `'django.core.cache.backends.memcached.PyMemcacheCache'` - `'django.core.cache.backends.memcached.PyLibMCCache'` - `'django.core.cache.backends.redis.RedisCache'` Django に同梱されていないキャッシュ用バックエンドを使用する時は、[`BACKEND`](#std-setting-CACHES-BACKEND) にバックエンドのクラスの完全修飾パス (例: `mypackage.backends.whatever.WhateverCache`) を設定してください。 #### `KEY_FUNCTION` ドット区切りパスを含む文字列で、プレフィックス、バージョン、キーを最終的なキャッシュキーに組み合わせる方法を定義する関数（または任意の呼び出し可能オブジェクト）を指します。デフォルトの実装は次の関数と同等です: ``` def make_key(key, key_prefix, version): return ":".join([key_prefix, str(version), key]) ``` 好きなキー関数を使用できますが、同じ引数のシグネチャを持つことが条件です。 詳細は [キャッシュのドキュメント](/ja/5.2/topics/cache/#cache-key-transformation) を参照してください。 #### `KEY_PREFIX` デフォルト値: `''` (空文字列) Djangoサーバーで使用されるすべてのキャッシュキーにデフォルトで自動的に追加（先頭に付けられる）される文字列。 詳細は [キャッシュのドキュメント](/ja/5.2/topics/cache/#cache-key-prefixing) を参照してください。 #### `LOCATION` デフォルト値: `''` (空文字列) 使用するキャッシュの位置。これはファイルシステムキャッシュ用のディレクトリ、memcacheサーバーのホストとポート、またはローカルメモリキャッシュの識別名などが該当します。例: ``` CACHES = { "default": { "BACKEND": "django.core.cache.backends.filebased.FileBasedCache", "LOCATION": "/var/tmp/django_cache", } } ``` #### `OPTIONS` デフォルト値: `None` キャッシュバックエンドに渡す追加パラメータ。利用可能なパラメータは、使用しているキャッシュバックエンドによって異なります。 利用可能なパラメータに関する情報は、 [キャッシュ式数](/ja/5.2/topics/cache/#cache-arguments) のドキュメントに記載されています。詳細については、バックエンドモジュールの独自のドキュメントを参照してください。 #### `TIMEOUT` デフォルト値: `300` キャッシュエントリが古いとみなされるまでの秒数。この設定の値が `None` である場合、キャッシュエントリは期限切れになりません。値が `0` の場合、キーは即座に期限切れになります（実質的に「キャッシュしない」）。 #### `VERSION` デフォルト値: `1` Django サーバーによって生成されるキャッシュキーのデフォルトのバージョン番号。 詳細は [キャッシュのドキュメント](/ja/5.2/topics/cache/#cache-versioning) を参照してください。 ### `CACHE_MIDDLEWARE_ALIAS` デフォルト値: `'default'` [キャッシュミドルウェア](/ja/5.2/topics/cache/#the-per-site-cache) に使用するキャッシュ接続。 ### `CACHE_MIDDLEWARE_KEY_PREFIX` デフォルト値: `''` (空文字列) キャッシュキーの生成時に [キャッシュミドルウェア](/ja/5.2/topics/cache/#the-per-site-cache) からプレフィックスとして追加される文字列です。このプレフィックスは [`KEY_PREFIX`](#std-setting-CACHES-KEY_PREFIX) 設定と組み合わされます。それを置き換えるものではありません。 [Django のキャッシュフレームワーク](/ja/5.2/topics/cache/) を参照。 ### `CACHE_MIDDLEWARE_SECONDS` デフォルト値: `600` [キャッシュミドルウェア](/ja/5.2/topics/cache/#the-per-site-cache) 用のページをキャッシュするデフォルトの秒数。 [Django のキャッシュフレームワーク](/ja/5.2/topics/cache/) を参照。 ### `CSRF_COOKIE_AGE` デフォルト値: `31449600` (約1年、秒単位) CSRF クッキーの有効期間 (秒単位)。 長期間の有効期限を設定する理由は、ユーザーがブラウザを閉じたり、ページをブックマークして、後でそのページをブラウザのキャッシュから読み込む場合の問題を避けるためです。永続的なクッキーがなければ、この場合にフォームの送信は失敗するでしょう。 一部のブラウザ（特にInternet Explorer）では、永続的なクッキーの使用を禁止したり、クッキージャーのインデックスがディスク上で破損して、CSRF保護チェックが（時々断続的に）失敗する原因となることがあります。この設定を `None` に変更すると、クッキーを永続的なストレージではなくメモリ内に保持するセッションベースのCSRFクッキーを使用します。 ### `CSRF_COOKIE_DOMAIN` デフォルト値: `None` CSRFクッキーを設定する際に使用されるドメインです。通常のクロスサイトリクエストフォージェリ保護から除外されるクロスサブドメインリクエストを簡単に許可するのに役立ちます。フォームからのPOSTリクエストが別のサブドメインから提供されるビューで受け入れられるようにするには、 `".example.com"` のような文字列で設定する必要があります。 この設定が存在することは、デフォルトで Django の CSRF 保護が、クロスサブドメイン攻撃から安全であることを意味するものではありません。詳細については、 [CSRF の制限](/ja/5.2/ref/csrf/#csrf-limitations) セクションを参照してください。 ### `CSRF_COOKIE_HTTPONLY` デフォルト値: `False` CSRFクッキーに `HttpOnly` フラグを使用するかどうか。これが `True` に設定されている場合、クライアントサイドのJavaScriptはCSRFクッキーにアクセスできません。 CSRFクッキーを `HttpOnly` として指定しても、実際のところ保護にはなりません。なぜなら、CSRFはクロスドメイン攻撃を防ぐためだけに存在するからです。攻撃者がJavaScript経由でクッキーを読み取ることができる場合、ブラウザが知っている限りでは既に同一ドメイン上にいるので、何でも好きなことを行うことができます。(XSSはCSRFよりもずっと大きな脅威です。) この設定が実際に大きな利益を提供することは少ないですが、セキュリティ監査員によっては必要とされることがあります。 これを有効にし、AJAXリクエストでCSRFトークンの値を送信する必要がある場合、JavaScriptは [クッキーから](/ja/5.2/howto/csrf/#acquiring-csrf-token-from-cookie) ではなく、 [隠されたCSRFトークンのフォーム入力から](/ja/5.2/howto/csrf/#acquiring-csrf-token-from-html) 値を取得する必要があります。 `HttpOnly` の詳細については、[`SESSION_COOKIE_HTTPONLY`](#std-setting-SESSION_COOKIE_HTTPONLY) を参照してください。 ### `CSRF_COOKIE_NAME` デフォルト値: `'csrftoken'` CSRF 認証トークンに使用するクッキーの名前。他のクッキー名と異なる限り、任意の名前を使用できます。詳細は、 [クロスサイトリクエストフォージェリ (CSRF) 対策](/ja/5.2/ref/csrf/) を参照してください。 ### `CSRF_COOKIE_PATH` デフォルト値: `'/'` CSRFクッキーに設定されたパス。これは、DjangoインストールのURLパスと一致するか、そのパスの親である必要があります。 複数の Django インスタンスを同じホスト名で実行している場合に便利です。異なるクッキーパスを使用でき、各インスタンスは自身の CSRF クッキーのみを確認できます。 ### `CSRF_COOKIE_SAMESITE` デフォルト値: `'Lax'` CSRFクッキーの [SameSite](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#samesitesamesite-value) フラグの値です。このフラグは、クロスサイトリクエストでクッキーが送信されるのを防ぎます。 `SameSite` についての詳細は、[`SESSION_COOKIE_SAMESITE`](#std-setting-SESSION_COOKIE_SAMESITE) を参照してください。 ### `CSRF_COOKIE_SECURE` デフォルト値: `False` CSRF（Cross-Site Request Forgery）クッキーにセキュアクッキーを使用するかどうかを指定します。これを `True` に設定すると、そのクッキーは「セキュア」としてマークされ、ブラウザはそのクッキーがHTTPS接続でのみ送信されることを確認できます。 ### `CSRF_USE_SESSIONS` デフォルト値: `False` ユーザーのセッション内にCSRFトークンをCookieではなく保存するかどうか。これを使用するには、 [`django.contrib.sessions`](/ja/5.2/topics/http/sessions/#module-django.contrib.sessions) の使用が必要です。 CSRF トークンをクッキーに保存する（Django のデフォルト）は安全ですが、他のウェブフレームワークではセッションに保存することが一般的であり、そのためセキュリティ監査員によってしばしば要求されます。 [デフォルトのエラービュー](/ja/5.2/ref/views/#error-views) が CSRF トークンを必要とするため、`CSRF_USE_SESSIONS` を使用している場合、エラービューをトリガーする可能性のある例外（例えば [`PermissionDenied`](/ja/5.2/ref/exceptions/#django.core.exceptions.PermissionDenied) など）を引き起こす可能性があるミドルウェアよりも前に、 [`SessionMiddleware`](/ja/5.2/ref/middleware/#django.contrib.sessions.middleware.SessionMiddleware) が [`MIDDLEWARE`](#std-setting-MIDDLEWARE) に登録されている必要があります。 [Middleware の順序](/ja/5.2/ref/middleware/#middleware-ordering) を参照してください。 ### `CSRF_FAILURE_VIEW` デフォルト値: `'django.views.csrf.csrf_failure'` [CSRF保護](/ja/5.2/ref/csrf/) によって受信リクエストが拒否された場合に使用されるビュー関数へのドット区切りパス。関数には次のシグネチャが必要です: ``` def csrf_failure(request, reason=""): ... ``` `reason` は、リクエストが拒否された理由を示す短いメッセージ（開発者やログ用であり、エンドユーザー向けではありません）です。これは [`HttpResponseForbidden`](/ja/5.2/ref/request-response/#django.http.HttpResponseForbidden) を返すべきです。 `django.views.csrf.csrf_failure()` は追加の `template_name` パラメータを受け付け、デフォルトでは `'403_csrf.html'` になっています。その名前のテンプレートが存在する場合、ページのレンダリングに使用されます。 ### `CSRF_HEADER_NAME` デフォルト値: `'HTTP_X_CSRFTOKEN'` CSRF認証に使用されるリクエストヘッダーの名前。 `request.META` の他の HTTP ヘッダと同様に、サーバーから受信したヘッダ名は、すべての文字を大文字に変換し、ハイフンをアンダースコアに置き換え、名前に `'HTTP_'` プレフィックスを追加することで正規化されます。たとえば、クライアントが `'X-XSRF-TOKEN'` ヘッダを送信する場合、設定は `'HTTP_X_XSRF_TOKEN'` であるべきです。 ### `CSRF_TRUSTED_ORIGINS` デフォルト値: `[]` (空のリスト) 安全でないリクエスト (例: `POST`) のための信頼できるオリジンのリスト。 `Origin` ヘッダーを含むリクエストに対して、Django の CSRF 保護は、そのヘッダーが `Host` ヘッダーに存在するオリジンと一致することを要求します。 `Origin` ヘッダーを含まない [`secure`](/ja/5.2/ref/request-response/#django.http.HttpRequest.is_secure) でないリクエストには、`Host` ヘッダーに存在するオリジンと一致する `Referer` ヘッダーが必要です。 これらのチェックは、例えば、`subdomain.example.com` からの `POST` リクエストが `api.example.com` に対して成功するのを防ぎます。クロスオリジンで安全でないリクエストが必要な場合、例を続けると、このリストに `'https://subdomain.example.com'` を追加してください（そして、リクエストが安全でないページから発生する場合は `http://...` も追加します）。 この設定はサブドメインもサポートしているので、例えば `'https://*.example.com'` を追加することで、`example.com` の全サブドメインからのアクセスを許可できます。 ### `DATABASES` デフォルト値: `{}` (空の辞書) Django で使用される全てのデータベースの設定を含む辞書です。これは、データベースエイリアスを個々のデータベースのオプションを含む辞書にマッピングする内容のネストされた辞書です。 [`DATABASES`](#std-setting-DATABASES) 設定では、`default` データベースを設定する必要があります。追加で任意の数のデータベースを指定することもできます。 最もシンプルな設定ファイルは、SQLite を使用した単一データベース設定です。これは以下のように設定できます。 ``` DATABASES = { "default": { "ENGINE": "django.db.backends.sqlite3", "NAME": "mydatabase", } } ``` MariaDB、MySQL、Oracle、または PostgreSQL などの他のデータベースバックエンドに接続する場合、追加の接続パラメータが必要になります。他のデータベースタイプを指定する方法については、以下の [`ENGINE`](#std-setting-DATABASE-ENGINE) 設定を参照してください。この例は PostgreSQL 用です: ``` DATABASES = { "default": { "ENGINE": "django.db.backends.postgresql", "NAME": "mydatabase", "USER": "mydatabaseuser", "PASSWORD": "mypassword", "HOST": "127.0.0.1", "PORT": "5432", } } ``` より複雑な設定に必要な次の内部オプションが利用可能です: #### `ATOMIC_REQUESTS` デフォルト値: `False` これを `True` に設定すると、このデータベース上の各ビューをトランザクションでラップします。[HTTP リクエストにトランザクションを結びつける](/ja/5.2/topics/db/transactions/#tying-transactions-to-http-requests) を参照してください。 #### `AUTOCOMMIT` デフォルト値: `True` これを `False` に設定すると、 [Djangoのトランザクション管理を無効にして](/ja/5.2/topics/db/transactions/#deactivate-transaction-management) 、独自のトランザクション管理を実装したい場合に利用できます。 #### `ENGINE` デフォルト値: `''` (空文字列) 使用するデータベースバックエンドです。組み込みのデータベースバックエンドは次の通りです: - `'django.db.backends.postgresql'` - `'django.db.backends.mysql'` - `'django.db.backends.sqlite3'` - `'django.db.backends.oracle'` Django に同梱されていないデータベースバックエンドを使用するには、`ENGINE` を完全修飾パス (例: `mypackage.backends.whatever`) に設定します。 #### `HOST` デフォルト値: `''` (空文字列) データベースに接続する際に使用するホストです。空の文字列の場合は localhost を意味します。SQLite では使用されません。 この値がスラッシュ (`'/'`) で始まり、MySQL を使用している場合、MySQL は指定されたソケットに Unix ソケット経由で接続します。例えば: ``` "HOST": "/var/run/mysql" ``` MySQLを使用している場合、この値がスラッシュで *始まらない* 場合、この値はホストとみなされます。 PostgreSQL を使用している場合、デフォルトでは ([`HOST`](#std-setting-HOST) が空の場合)、UNIXドメインソケット (`pg_hba.conf` の 'local' 行) を通じてデータベースに接続されます。UNIXドメインソケットが標準の場所にない場合は、`postgresql.conf` の `unix_socket_directory` の値と同じ値を使用してください。TCPソケットを通じて接続したい場合は、[`HOST`](#std-setting-HOST) を 'localhost' または '127.0.0.1' (`pg_hba.conf` の 'host' 行) に設定してください。Windows では、UNIXドメインソケットが利用できないため、常に [`HOST`](#std-setting-HOST) を定義する必要があります。 #### `NAME` デフォルト値: `''` (空文字列) 使用するデータベースの名前。SQLite の場合、データベースファイルへのフルパスになります。パスを指定する場合は、Windows であっても常にスラッシュを使用してください（例: `C:/homes/user/mysite/sqlite3.db` ）。 #### `CONN_MAX_AGE` デフォルト値: `0` データベース接続の寿命を秒単位の整数で指定します。各リクエストの終了時にデータベース接続を閉じる場合は `0` を使用します（Django の従来の動作）。無制限の [永続的なデータベース接続](/ja/5.2/ref/databases/#persistent-database-connections) の場合は `None` を使用します。 #### `CONN_HEALTH_CHECKS` デフォルト値: `False` もし `True` に設定されている場合、データベースアクセスを行う各リクエストで再利用される前に、既存の [永続的なデータベース接続](/ja/5.2/ref/databases/#persistent-database-connections) がヘルスチェックされます。ヘルスチェックが失敗した場合、接続は再確立され、データベースサーバーは新しい接続を受け入れ、提供する準備が整っているが、接続が使用できなくなったときにリクエストが失敗することはありません（例：データベースサーバーが再起動し、既存の接続を閉じた後）。 #### `OPTIONS` デフォルト値: `{}` (空の辞書) データベースに接続する際に使用する追加パラメータ。利用可能なパラメータは、使用しているデータベースバックエンドによって異なります。 利用可能なパラメータに関する情報は、 [データベースのバックエンド](/ja/5.2/ref/databases/) のドキュメントに記載されています。詳細については、バックエンドモジュール独自のドキュメントを参照してください。 #### `PASSWORD` デフォルト値: `''` (空文字列) データベースに接続する際に使用するパスワード。SQLiteでは使用しません。 #### `PORT` デフォルト値: `''` (空文字列) データベースに接続する際に使用するポート。空の文字列はデフォルトポートを意味します。SQLiteでは使用されません。 #### `TIME_ZONE` デフォルト値: `None` このデータベース接続のためのタイムゾーンを表す文字列、または `None` です。 [`DATABASES`](#std-setting-DATABASES) 設定のこの内部オプションは、一般的な [`TIME_ZONE`](#std-setting-TIME_ZONE) 設定と同じ値を受け付けます。 [`USE_TZ`](#std-setting-USE_TZ) が `True` のとき、データベースからの日時の読み込みは、タイムゾーンが `None` ではない場合はその値に、そうでない場合は UTC に設定された意識的な日時を返します。 [`USE_TZ`](#std-setting-USE_TZ) が `False` の場合、このオプションを設定するとはエラーになります。 - データベースバックエンドがタイムゾーンをサポートしていない場合（例えば SQLite、MySQL、Oracle など）、このオプションが設定されている場合は Django はローカルタイムで日時を読み書きし、設定されていない場合は UTC で行います。 接続のタイムゾーンを変更すると、データベースの読み書きに影響が出ます。 - Django がデータベースを管理しており、別の強い理由がない限り、このオプションを設定しないでおくべきです。UTC で日時を保存することが最善です。これにより、サマータイムの変更時に曖昧な日時や存在しない日時を回避できます。また、UTC で日時を受け取ることで、日時の計算が簡単になります。夏時間の移行時にオフセットの変化を考慮する必要がないからです。 - もしUTCではなくローカル時間で日時を保存するサードパーティーのデータベースに接続する場合は、このオプションを適切なタイムゾーンに設定する必要があります。同様に、Djangoがデータベースを管理しているが、サードパーティーシステムが同じデータベースに接続し、ローカル時間で日時を取得することを期待している場合は、このオプションを設定する必要があります。 - データベースバックエンドがタイムゾーンをサポートしている場合（例えば、PostgreSQL）、データベース接続のタイムゾーンはこの値に設定されます。 `TIME_ZONE` オプションを設定する必要はほとんどありませんが、状況によっては必要になることがあります。特に、PostgreSQLの `date_trunc()` や `generate_series()` などの日時関数を使用するクエリに関わる場合、特にサマータイムの切り替えなど、時間ベースのシリーズを生成するときには、一般的な [`TIME_ZONE`](#std-setting-TIME_ZONE) 設定と一致させることが推奨されます。 この値はいつでも変更可能であり、データベースは日時を設定されたタイムゾーンに変換します。 ただし、これには欠点があります。すべての日時をローカルタイムで受け取ると、日時の算術がより複雑になります。DST（サマータイム）の変更期間を考慮に入れる必要があります。 素のSQLクエリで `TIME_ZONE` オプションを設定する代わりに、`AT TIME ZONE` を使用して明示的にローカルタイムに変換することを検討してください。 #### `DISABLE_SERVER_SIDE_CURSORS` デフォルト値: `False` もし [`QuerySet.iterator()`](/ja/5.2/ref/models/querysets/#django.db.models.query.QuerySet.iterator) でサーバーサイドのカーソルの使用を無効にしたい場合は、これを `True` に設定してください。 [トランザクションプールとサーバーサイドカーソル](/ja/5.2/ref/databases/#transaction-pooling-server-side-cursors) には使用例が記載されています。 これは PostgreSQL 固有の設定です。 #### `USER` デフォルト値: `''` (空文字列) データベースに接続する際に使用するユーザー名。SQLiteでは使用されません。 #### `TEST` デフォルト値: `{}` (空の辞書) テスト用データベースの設定辞書。テスト用データベースの作成と使用に関する詳細については、 [test データベース](/ja/5.2/topics/testing/overview/#the-test-database) を参照してください。 以下はテスト用データベースの設定例です: ``` DATABASES = { "default": { "ENGINE": "django.db.backends.postgresql", "USER": "mydatabaseuser", "NAME": "mydatabase", "TEST": { "NAME": "mytestdatabase", }, }, } ``` `TEST` 辞書で利用可能なキーは以下のとおりです: ##### `CHARSET` デフォルト値: `None` テストデータベースを作成する際に使用される文字セットエンコーディングです。この文字列の値はデータベースに直接渡されるため、その形式はバックエンドに依存します。 [PostgreSQL](https://www.postgresql.org/docs/current/multibyte.html) (`postgresql`) および [MySQL](https://dev.mysql.com/doc/refman/en/charset-charsets.html) (`mysql`) バックエンドでサポートされています。 ##### `COLLATION` デフォルト値: `None` テストデータベースを作成する際に使用する照合順序 (collation)。この値はバックエンドに直接渡されるため、その形式はバックエンドに依存します。 `mysql` バックエンドでのみサポートされています ([MySQL manual](https://dev.mysql.com/doc/refman/en/charset-charsets.html) を参照してください)。 ##### `DEPENDENCIES` デフォルト値: `['default']` で、 `default` 以外のすべてのデータベースには依存関係は設定されていません。 データベースの作成順序の依存関係です。詳細については、 [テストデータベースの作成順序を制御する](/ja/5.2/topics/testing/advanced/#topics-testing-creation-dependencies) ドキュメントを参照してください。 ##### `MIGRATE` デフォルト値: `True` `False` に設定されている場合、テストデータベースを作成するときにマイグレーションは実行されません。これは [`MIGRATION_MODULES`](#std-setting-MIGRATION_MODULES) に `None` を値として設定するのと似ていますが、すべてのアプリに適用されます。 ##### `MIRROR` デフォルト値: `None` このデータベースがテスト中にミラーリングするべきデータベースのエイリアスです。トランザクションに依存しているため、 [`TestCase`](/ja/5.2/topics/testing/tools/#django.test.TestCase) の代わりに [`TransactionTestCase`](/ja/5.2/topics/testing/tools/#django.test.TransactionTestCase) 内で使用する必要があります。 この設定は、複数のデータベースのプライマリ/レプリカ (一部のデータベースではマスター/スレーブと呼ばれる) 構成のテストを可能にするために存在します。詳細については、 [プライマリ/レプリカ構成のテスト](/ja/5.2/topics/testing/advanced/#topics-testing-primaryreplica) のドキュメントを参照してください。 ##### `NAME` デフォルト値: `None` テストスイートを実行する際に使用するデータベースの名前。 デフォルト値 (`None`) をSQLiteデータベースエンジンで使用すると、テストはメモリ内のデータベースを使用します。そのほかのデータベースエンジンでは、テストデータベースは `'test_' + DATABASE_NAME` という名前が使われます。 [テストデータベース](/ja/5.2/topics/testing/overview/#the-test-database) を参照。 ##### `TEMPLATE` これは PostgreSQL 固有の設定です。 テストデータベースを作成するための [template](https://www.postgresql.org/docs/current/sql-createdatabase.html) の名前 (例: `'template0'`)。 ##### `CREATE_DB` デフォルト値: `True` これは Oracle 固有の設定です。 `False` に設定されている場合、テストテーブルスペースはテストの開始時に自動的に作成されることも終了時に削除されることもありません。 ##### `CREATE_USER` デフォルト値: `True` これは Oracle 固有の設定です。 `False` に設定されている場合、テストの開始時にテストユーザーは自動的に作成されず、終了時に削除されません。 ##### `USER` デフォルト値: `None` これは Oracle 固有の設定です。 テストを実行する際に、Oracle データベースに接続するために使用するユーザー名です。指定しない場合、Django は `'test_' + USER` を使用します。 ##### `PASSWORD` デフォルト値: `None` これは Oracle 固有の設定です。 テスト実行時に Oracle データベースに接続するために使用するパスワードです。指定しない場合、Django はランダムなパスワードを生成します。 ##### `ORACLE_MANAGED_FILES` デフォルト値: `False` これは Oracle 固有の設定です。 `True` に設定された場合、Oracle Managed Files (OMF) テーブル空間が使用されます。 [`DATAFILE`](#std-setting-DATAFILE) と [`DATAFILE_TMP`](#std-setting-DATAFILE_TMP) は無視されます。 ##### `TBLSPACE` デフォルト値: `None` これは Oracle 固有の設定です。 テスト実行時に使用されるテーブル空間の名前。省略した場合、Django は `'test_' + USER` を使用します。 ##### `TBLSPACE_TMP` デフォルト値: `None` これは Oracle 固有の設定です。 テスト実行時に使用される一時テーブルスペースの名前。指定しない場合、Djangoは `'test_' + USER + '_temp'` を使用します。 ##### `DATAFILE` デフォルト値: `None` これは Oracle 固有の設定です。 使用する TBLSPACE のデータファイル名です。指定されない場合、Django は `TBLSPACE + '.dbf'` を使用します。 ##### `DATAFILE_TMP` デフォルト値: `None` これは Oracle 固有の設定です。 使用する TBLSPACE\_TMP のデータファイルの名前です。指定されていない場合、Django は `TBLSPACE_TMP + '.dbf'` を使用します。 ##### `DATAFILE_MAXSIZE` デフォルト値: `'500M'` これは Oracle 固有の設定です。 DATAFILE が許容される最大サイズ。 ##### `DATAFILE_TMP_MAXSIZE` デフォルト値: `'500M'` これは Oracle 固有の設定です。 DATAFILE\_TMP が拡大することが許可されている最大サイズ。 ##### `DATAFILE_SIZE` デフォルト値: `'50M'` これは Oracle 固有の設定です。 DATAFILE の初期サイズ。 ##### `DATAFILE_TMP_SIZE` デフォルト値: `'50M'` これは Oracle 固有の設定です。 DATAFILE\_TMP の初期サイズ。 ##### `DATAFILE_EXTSIZE` デフォルト値: `'25M'` これは Oracle 固有の設定です。 DATAFILE がより多くのスペースを必要としたときに拡張される量。 ##### `DATAFILE_TMP_EXTSIZE` デフォルト値: `'25M'` これは Oracle 固有の設定です。 空き領域が不足するときに DATAFILE\_TMP が拡張される量。 ### `DATA_UPLOAD_MAX_MEMORY_SIZE` デフォルト値: `2621440` (例: 2.5 MB)。 リクエストボディの最大サイズ (バイト単位) で、このサイズを超えると [`SuspiciousOperation`](/ja/5.2/ref/exceptions/#django.core.exceptions.SuspiciousOperation) (`RequestDataTooBig`) が発生します。このチェックは `request.body` や `request.POST` へのアクセス時に行われ、ファイルアップロードデータを除いた総リクエストサイズに対して計算されます。このチェックを無効にするためには、この値を `None` に設定できます。通常よりも大きなフォーム投稿を受け取ることが予想されるアプリケーションは、この設定を調整する必要があります。 リクエストデータの量は、リクエストを処理しGETおよびPOST辞書を作成するのに必要なメモリ量に関連しています。大きなリクエストは、精査されていないままの場合、サービス妨害攻撃の手段として使用される可能性があります。通常、Webサーバーは深いリクエスト検査を行わないため、同様のチェックをそのレベルで行うことはできません。 関連項目: [`FILE_UPLOAD_MAX_MEMORY_SIZE`](#std-setting-FILE_UPLOAD_MAX_MEMORY_SIZE) ### `DATA_UPLOAD_MAX_NUMBER_FIELDS` デフォルト値: `1000` GET または POST 経由で受け取り可能なパラメータの最大数を超えると、 [`SuspiciousOperation`](/ja/5.2/ref/exceptions/#django.core.exceptions.SuspiciousOperation) (`TooManyFields`) が発生します。このチェックを無効にするには、これを `None` に設定してください。通常よりも多くのフォームフィールドを受け取ることが予想されるアプリケーションは、この設定を調整する必要があります。 リクエストパラメータの数は、リクエストを処理して GET と POST の辞書を満たすために必要な時間と相関しています。大きなリクエストは、チェックされないままにしておくと、サービス拒否攻撃のベクトルとして使用される可能性があります。Webサーバは通常、深いリクエスト検査を行わないため、そのレベルで同様のチェックを行うことはできません。 ### `DATA_UPLOAD_MAX_NUMBER_FILES` デフォルト値: `100` POSTで `multipart/form-data` エンコードされたリクエスト経由で受信できるファイルの最大数です。この数を超えると [`SuspiciousOperation`](/ja/5.2/ref/exceptions/#django.core.exceptions.SuspiciousOperation) (`TooManyFiles`) が発生します。このチェックを無効にするには、これを `None` に設定できます。通常よりも多くのファイルフィールドを受信することが予想されるアプリケーションは、この設定を調整する必要があります。 受け入れられるファイルの数は、リクエストを処理するために必要な時間とメモリに関連しています。大きなリクエストは、チェックなしに放置されると、サービス拒否攻撃のベクトルとして使用される可能性があります。Web サーバーは通常、リクエストの深い検査を行わないため、そのレベルで同様のチェックを行うことはできません。 ### `DATABASE_ROUTERS` デフォルト値: `[]` (空のリスト) データベースクエリを実行する際に使用されるデータベースを決定するために使用されるルーターのリスト。 [複数データベース構成での自動データベースルーティング](/ja/5.2/topics/db/multi-db/#topics-db-multi-db-routing) に関するドキュメントを参照してください。 ### `DATE_FORMAT` デフォルト値: `'N j, Y'` (例: `Feb. 4, 2003`) システムのどの部分でも日付フィールドを表示する際に使用するデフォルトのフォーマット。ただし、ロケールによって指定されたフォーマットが優先され、代わりに適用されます。 [`使用可能な日付フォーマット文字列`](/ja/5.2/ref/templates/builtins/#std-templatefilter-date) を参照してください。 関連項目: [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT), [`TIME_FORMAT`](#std-setting-TIME_FORMAT), [`SHORT_DATE_FORMAT`](#std-setting-SHORT_DATE_FORMAT) ### `DATE_INPUT_FORMATS` デフォルト値: ``` [ "%Y-%m-%d", # '2006-10-25' "%m/%d/%Y", # '10/25/2006' "%m/%d/%y", # '10/25/06' "%b %d %Y", # 'Oct 25 2006' "%b %d, %Y", # 'Oct 25, 2006' "%d %b %Y", # '25 Oct 2006' "%d %b, %Y", # '25 Oct, 2006' "%B %d %Y", # 'October 25 2006' "%B %d, %Y", # 'October 25, 2006' "%d %B %Y", # '25 October 2006' "%d %B, %Y", # '25 October, 2006' ] ``` 日付フィールドにデータを入力する際に受け入れられる形式のリストです。形式は順番に試され、最初の有効なものが使用されます。これらの形式文字列は、 [`date`](/ja/5.2/ref/templates/builtins/#std-templatefilter-date) テンプレートフィルタからの形式文字列ではなく、Python の [datetime モジュールの構文](https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior) を使用していることに注意してください。 ロケールが指定するフォーマットが優先され、代わりに適用されます。 関連項目: [`DATETIME_INPUT_FORMATS`](#std-setting-DATETIME_INPUT_FORMATS) [`TIME_INPUT_FORMATS`](#std-setting-TIME_INPUT_FORMATS) ### `DATETIME_FORMAT` デフォルト値: `'N j, Y, P'` (例: `Feb. 4, 2003, 4 p.m.`) システムのどの部分で日時フィールドを表示する際に使用するデフォルトのフォーマット。ロケールで指定されたフォーマットの方が優先され、代わりに適用されることに注意してください。許可される日付フォーマット文字列については、 [`使用可能な日付フォーマット文字列`](/ja/5.2/ref/templates/builtins/#std-templatefilter-date) を参照してください。 関連項目 [`DATE_FORMAT`](#std-setting-DATE_FORMAT), [`TIME_FORMAT`](#std-setting-TIME_FORMAT), [`SHORT_DATETIME_FORMAT`](#std-setting-SHORT_DATETIME_FORMAT) ### `DATETIME_INPUT_FORMATS` デフォルト値: ``` [ "%Y-%m-%d %H:%M:%S", # '2006-10-25 14:30:59' "%Y-%m-%d %H:%M:%S.%f", # '2006-10-25 14:30:59.000200' "%Y-%m-%d %H:%M", # '2006-10-25 14:30' "%m/%d/%Y %H:%M:%S", # '10/25/2006 14:30:59' "%m/%d/%Y %H:%M:%S.%f", # '10/25/2006 14:30:59.000200' "%m/%d/%Y %H:%M", # '10/25/2006 14:30' "%m/%d/%y %H:%M:%S", # '10/25/06 14:30:59' "%m/%d/%y %H:%M:%S.%f", # '10/25/06 14:30:59.000200' "%m/%d/%y %H:%M", # '10/25/06 14:30' ] ``` 日時フィールドにデータを入力する際に受け入れられるフォーマットのリスト。フォーマットは順番に試され、最初の有効なものが使用されます。これらのフォーマット文字列は、[`date`](/ja/5.2/ref/templates/builtins/#std-templatefilter-date) テンプレートフィルタからのフォーマット文字列ではなく、Python の [datetime モジュールの構文](https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior) を使用することに注意してください。日付のみのフォーマットは含まれていません。というのも、datetime フィールドは最終手段として自動的に [`DATE_INPUT_FORMATS`](#std-setting-DATE_INPUT_FORMATS) を試みるからです。 ロケールが指定するフォーマットが優先され、代わりに適用されます。 関連項目: [`DATE_INPUT_FORMATS`](#std-setting-DATE_INPUT_FORMATS) および [`TIME_INPUT_FORMATS`](#std-setting-TIME_INPUT_FORMATS) を参照。 ### `DEBUG` デフォルト値: `False` デバッグモードをオン/オフにする真偽値です。 [`DEBUG`](#std-setting-DEBUG) をオンにした状態でサイトを本番環境にデプロイしないでください。 デバッグモードの主な特徴の一つは、詳細なエラーページの表示です。あなたのアプリが [`DEBUG`](#std-setting-DEBUG) が `True` のときに例外を発生させた場合、Djangoは詳細なトレースバックを表示します。これには、`settings.py` から現在定義されているすべてのDjango設定など、環境に関する多くのメタデータが含まれています。 セキュリティ対策として、Djangoでは [`SECRET_KEY`](#std-setting-SECRET_KEY) のような機密性の高い設定を *含めない* ことにしています。具体的には、以下のいずれかを含む名前の設定は除外されます: - `'API'` - `'KEY'` - `'PASS'` - `'SECRET'` - `'SIGNATURE'` - `'TOKEN'` これらは *部分一致* であることに注意してください。 `'PASS'` は PASSWORD にも一致し、 `'TOKEN'` は TOKENIZED にも一致します。 それでも、デバッグ出力のセクションには、公開に適さないものが常に存在することに注意してください。ファイルパス、設定オプションなどは、攻撃者にサーバーについての追加情報を提供してしまいます。 また、[`DEBUG`](#std-setting-DEBUG) をオンにして実行している場合、Djangoは実行するすべてのSQLクエリを記憶します。デバッグ時に便利ですが、本番サーバーでは急速にメモリを消費します。 最後に、[`DEBUG`](#std-setting-DEBUG) が `False` の場合は、[`ALLOWED_HOSTS`](#std-setting-ALLOWED_HOSTS) も適切に設定する必要があります。これを怠ると、すべてのリクエストが "Bad Request (400)" として返されます。 > **Note** > > [`django-admin startproject`](/ja/5.2/ref/django-admin/#django-admin-startproject) によって作成されるデフォルトの `settings.py` ファイルは、利便性のために `DEBUG = True` に設定されています。 ### `DEBUG_PROPAGATE_EXCEPTIONS` デフォルト値: `False` `True` に設定されている場合、Djangoのビュー関数の例外処理 ([`handler500`](/ja/5.2/ref/urls/#django.conf.urls.handler500) 、または [`DEBUG`](#std-setting-DEBUG) が `True` の場合はデバッグビュー) と500レスポンスのログ記録 ([django.request](/ja/5.2/ref/logging/#django-request-logger)) がスキップされ、例外は上に伝播します。 これは、一部のテスト設定で役立つ場合があります。Django の代わりに Web サーバーが "Internal Server Error" のレスポンスを生成することを望む場合を除いて、ライブサイトで使用するべきではありません。その場合、サーバーがレスポンスでスタックトレースやその他の機密情報を表示しないようにしてください。 ### `DECIMAL_SEPARATOR` デフォルト値: `'.'` (ドット) 小数をフォーマットする際に使用されるデフォルトの小数点区切り記号です。 ロケールが指定する形式が優先され、それが適用されるので注意してください。 関連項目: [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING), [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR), [`USE_THOUSAND_SEPARATOR`](#std-setting-USE_THOUSAND_SEPARATOR) ### `DEFAULT_AUTO_FIELD` デフォルト値: `'`[`django.db.models.AutoField`](/ja/5.2/ref/models/fields/#django.db.models.AutoField)`'` フィールドに [`primary_key=True`](/ja/5.2/ref/models/fields/#django.db.models.Field.primary_key) の属性がないモデルに使用するデフォルトの主キーのフィールドタイプ。 > **自動生成された中間テーブルをマイグレーションする** > > 新しい自動生成された多対多のリレーションシップ用の through テーブルを作成する際には、`DEFAULT_AUTO_FIELD` の値が尊重されます。 > > 残念ながら、現在はマイグレーションフレームワークで自動作成された中間テーブルの主キーを更新することはできません。 > > これは、`DEFAULT_AUTO_FIELD` の値を切り替えてマイグレーションを生成した場合、リレーション先モデルの主キーと中間テーブルからの外部キーは更新されますが、自動作成された中間テーブルの主キーはマイグレーションされないことを意味します。 > > これを解決するには、必要な `ALTER TABLE` ステップを実行するために、マイグレーションに [`RunSQL`](/ja/5.2/ref/migration-operations/#django.db.migrations.operations.RunSQL) 操作を追加する必要があります。既存のテーブル名は、`sqlmigrate`、`dbshell`、またはフィールドの `remote_field.through._meta.db_table` プロパティを介して確認できます。 > > モデルで明示的に定義されているものは、既にマイグレーションシステムで処理されています。 > > 既存の自動生成された中間テーブルの主キーに対して自動的なマイグレーションを許可する機能は、将来実装されるかもしれません [#\<32674\>](https://code.djangoproject.com/ticket/<32674>) 。 ### `DEFAULT_CHARSET` デフォルト値: `'utf-8'` 手動で MIME タイプが指定されていない場合に、全ての `HttpResponse` オブジェクトで使用するデフォルトの文字セット。`Content-Type` ヘッダを構築する際に使用されます。 ### `DEFAULT_EXCEPTION_REPORTER` デフォルト値: `'`[`django.views.debug.ExceptionReporter`](/ja/5.2/howto/error-reporting/#django.views.debug.ExceptionReporter)`'` まだ [`HttpRequest`](/ja/5.2/ref/request-response/#django.http.HttpRequest) インスタンスに割り当てられていない場合に使用されるデフォルトの例外レポータークラス。 [カスタムエラーレポート](/ja/5.2/howto/error-reporting/#custom-error-reports) を参照してください。 ### `DEFAULT_EXCEPTION_REPORTER_FILTER` デフォルト値: `'`[`django.views.debug.SafeExceptionReporterFilter`](/ja/5.2/howto/error-reporting/#django.views.debug.SafeExceptionReporterFilter)`'` まだ [`HttpRequest`](/ja/5.2/ref/request-response/#django.http.HttpRequest) インスタンスに割り当てられていない場合に使用されるデフォルトの例外レポートフィルタクラス。 [エラーレポートのフィルタリング](/ja/5.2/howto/error-reporting/#filtering-error-reports) を参照してください。 ### `DEFAULT_FROM_EMAIL` デフォルト値: `'webmaster@localhost'` サイト管理者からの自動対応用のデフォルトのメールアドレスです。このアドレスは送信メールの `From:` ヘッダに使用され、選択したメール送信プロトコルで有効なあらゆる形式を取ることができます。 これは [`ADMINS`](#std-setting-ADMINS) と [`MANAGERS`](#std-setting-MANAGERS) へ送信されるエラーメッセージには影響しません。それについては [`SERVER_EMAIL`](#std-setting-SERVER_EMAIL) を参照してください。 ### `DEFAULT_INDEX_TABLESPACE` デフォルト値: `''` (空文字列) バックエンドがサポートしている場合 ([テーブル空間（tablespace）](/ja/5.2/topics/db/tablespaces/) を参照)、指定されていないフィールドのインデックスに使用するデフォルトのテーブル空間です。 ### `DEFAULT_TABLESPACE` デフォルト値: `''` (空文字列) バックエンドがサポートしている場合、指定していないモデル用に使用するデフォルトのテーブル空間 ([テーブル空間（tablespace）](/ja/5.2/topics/db/tablespaces/) を参照)。 ### `DISALLOWED_USER_AGENTS` デフォルト値: `[]` (空のリスト) どのページも訪れることを許可されていないユーザーエージェント文字列を表すコンパイル済み正規表現オブジェクトのリスト。これはボット/クローラー用です。 `CommonMiddleware` がインストールされている場合にのみ使用されます（詳細は、 [ミドルウェア (Middleware)](/ja/5.2/topics/http/middleware/) を参照）。 ### `EMAIL_BACKEND` デフォルト値: `'`[`django.core.mail.backends.smtp.EmailBackend`](/ja/5.2/topics/email/#django.core.mail.backends.smtp.EmailBackend)`'` 使用するメール送信のバックエンド。利用可能なバックエンドのリストについては、 [メールのバックエンド](/ja/5.2/topics/email/#topic-email-backends) を参照してください。 ### `EMAIL_FILE_PATH` デフォルト値: 定義されていません [ファイルメールバックエンド](/ja/5.2/topics/email/#topic-email-file-backend) が出力ファイルを保存するために使用するディレクトリ。 ### `EMAIL_HOST` デフォルト値: `'localhost'` E メール送信に使われるホストです。 [`EMAIL_PORT`](#std-setting-EMAIL_PORT) も参照してください。 ### `EMAIL_HOST_PASSWORD` デフォルト値: `''` (空文字列) [`EMAIL_HOST`](#std-setting-EMAIL_HOST) 内で定義された SMTP サーバで使われるパスワードです。この設定は、STMP サーバへの認証の際に [`EMAIL_HOST_USER`](#std-setting-EMAIL_HOST_USER) と組み合わせて用いられます。どちらかの設定が空の場合、Django は認証を試みません。 [`EMAIL_HOST_USER`](#std-setting-EMAIL_HOST_USER) も参照してください。 ### `EMAIL_HOST_USER` デフォルト値: `''` (空文字列) [`EMAIL_HOST`](#std-setting-EMAIL_HOST) 内で定義された SMTP サーバで使われるユーザ名です。空の場合、Django は認証を試みません。 [`EMAIL_HOST_PASSWORD`](#std-setting-EMAIL_HOST_PASSWORD) も参照してください。 ### `EMAIL_PORT` デフォルト値: `25` [`EMAIL_HOST`](#std-setting-EMAIL_HOST) 内で定義された SMTP サーバで使われるポート番号です。 ### `EMAIL_SUBJECT_PREFIX` デフォルト値: `'[Django] '` `django.core.mail.mail_admins` や `django.core.mail.mail_managers` で送信される E メールメッセージ用の表題行のプレフィックスです。最後の文字はスペースにするのが良いでしょう。 ### `EMAIL_USE_LOCALTIME` デフォルト値: `False` 電子メールメッセージのSMTPの "Date" ヘッダーをローカルタイムゾーンで送信する (`True`) かUTCで送信する (`False`) か。 ### `EMAIL_USE_TLS` デフォルト値: `False` SMTP サーバと通信する際に TLS (セキュア) 接続を使うかどうかです。明示的な TLS 接続に使われ、通常はポート 587 で行われます。接続がハングしてしまう場合は、暗黙的な TLS を示す [`EMAIL_USE_SSL`](#std-setting-EMAIL_USE_SSL) を確認してみてください。 ### `EMAIL_USE_SSL` デフォルト値: `False` SMTP サーバと通信する際に TLS (セキュア) 接続を使うかどうかです。ほとんどの E メールのドキュメントでは、この TLS 接続のタイプは SSL として参照されます。通常はポート 465 が使われます。接続がハングしてしまう場合は、暗黙的な TLS を示す [`EMAIL_USE_TLS`](#std-setting-EMAIL_USE_TLS) を確認してみてください。 [`EMAIL_USE_TLS`](#std-setting-EMAIL_USE_TLS)/[`EMAIL_USE_SSL`](#std-setting-EMAIL_USE_SSL) は相互に排他的であることに注意してください。したがって、どちらか一方だけを `True` にセットしてください。 ### `EMAIL_SSL_CERTFILE` デフォルト値: `None` [`EMAIL_USE_SSL`](#std-setting-EMAIL_USE_SSL) または [`EMAIL_USE_TLS`](#std-setting-EMAIL_USE_TLS) が `True` で、SMTP サーバーへの安全な接続にクライアント認証が必要な場合、この設定を使用して PEM 形式の証明書チェーンファイルへのパスを指定します。これは [`EMAIL_SSL_KEYFILE`](#std-setting-EMAIL_SSL_KEYFILE) と併せて使用する必要があります。 `EMAIL_SSL_CERTFILE` は、自己署名のサーバー証明書や私設認証局（CA）の証明書と併用すべきではありません。これらの場合、サーバー証明書（または私設 CA のルート証明書）をシステムの CA バンドルにインストールする必要があります。これは、プラットフォーム固有のルート CA 証明書のインストール手順に従うか、OpenSSL の `SSL_CERT_FILE` または `SSL_CERT_DIR` 環境変数を使用してカスタム証明書バンドルを指定することで行えます（システムのバンドルを変更できない、または変更したくない場合）。 より複雑なシナリオでは、SMTP の [`EmailBackend`](/ja/5.2/topics/email/#django.core.mail.backends.smtp.EmailBackend) をサブクラス化し、[`ssl.SSLContext.load_verify_locations()`](https://docs.python.org/3/library/ssl.html#ssl.SSLContext.load_verify_locations) を用いてその `ssl_context` にルート証明書を追加できます。 ### `EMAIL_SSL_KEYFILE` デフォルト値: `None` [`EMAIL_USE_SSL`](#std-setting-EMAIL_USE_SSL) または [`EMAIL_USE_TLS`](#std-setting-EMAIL_USE_TLS) が `True` の場合、SSL 接続のクライアント認証のための PEM 形式の秘密鍵ファイルへのパスを、[`EMAIL_SSL_CERTFILE`](#std-setting-EMAIL_SSL_CERTFILE) と併せて任意で指定できます。 [`EMAIL_SSL_CERTFILE`](#std-setting-EMAIL_SSL_CERTFILE) と [`EMAIL_SSL_KEYFILE`](#std-setting-EMAIL_SSL_KEYFILE) を設定しても、いかなる証明書のチェックも行われません。これらは基礎となる SSL 接続に渡されます。証明書チェーンファイルと秘密鍵ファイルの取り扱いの詳細については、Python の [`ssl.SSLContext.wrap_socket()`](https://docs.python.org/3/library/ssl.html#ssl.SSLContext.wrap_socket) 関数のドキュメントを参照してください。 ### `EMAIL_TIMEOUT` デフォルト値: `None` 接続試行のような操作をブロックするためのタイムアウトを秒で指定します。 ### `FILE_UPLOAD_HANDLERS` デフォルト値: ``` [ "django.core.files.uploadhandler.MemoryFileUploadHandler", "django.core.files.uploadhandler.TemporaryFileUploadHandler", ] ``` アップロードに使用するハンドラのリストです。この設定を変更すると、Djangoのアップロードプロセスを完全にカスタマイズできます。代替も可能です。 詳細は [ファイルの管理](/ja/5.2/topics/files/) を参照してください。 ### `FILE_UPLOAD_MAX_MEMORY_SIZE` デフォルト値: `2621440` (例: 2.5 MB)。 ファイルシステムにストリーミングされる前のアップロードの最大サイズ（バイト単位）。詳細は、 [ファイルの管理](/ja/5.2/topics/files/) を参照してください。 関連項目: [`DATA_UPLOAD_MAX_MEMORY_SIZE`](#std-setting-DATA_UPLOAD_MAX_MEMORY_SIZE) ### `FILE_UPLOAD_DIRECTORY_PERMISSIONS` デフォルト値: `None` ファイルのアップロードの過程で作成されるディレクトリに適用する数値モード。 この設定は、 [`collectstatic`](/ja/5.2/ref/contrib/staticfiles/#django-admin-collectstatic) 管理コマンドを使用する際の、収集された静的ディレクトリのデフォルト権限も決定します。それを上書きする方法の詳細については、 [`collectstatic`](/ja/5.2/ref/contrib/staticfiles/#django-admin-collectstatic) を参照してください。 この値には [`FILE_UPLOAD_PERMISSIONS`](#std-setting-FILE_UPLOAD_PERMISSIONS) 設定の機能と同様の注意点があります。 ### `FILE_UPLOAD_PERMISSIONS` デフォルト値: `0o644` 新しくアップロードされたファイルに設定する数値モード（例えば `0o644` ）です。これらのモードが何を意味するのかについての詳細は、 [`os.chmod()`](https://docs.python.org/3/library/os.html#os.chmod) のドキュメントを参照してください。 もし `None` なら、OS 依存の動作が得られます。ほとんどのプラットフォームでは、一時ファイルは `0o600` のモードを持ち、メモリから保存されるファイルはシステムの標準の umask を使用して保存されます。 セキュリティ上の理由から、これらの権限は [`FILE_UPLOAD_TEMP_DIR`](#std-setting-FILE_UPLOAD_TEMP_DIR) に保存される一時ファイルには適用されません。 この設定は、[`collectstatic`](/ja/5.2/ref/contrib/staticfiles/#django-admin-collectstatic) 管理コマンドを使用して静的ファイルを収集する際のデフォルト権限も決定します。それをオーバーライドする方法については、 [`collectstatic`](/ja/5.2/ref/contrib/staticfiles/#django-admin-collectstatic) を参照してください。 > **Warning** > > **モードは常に** `0o` **で始めてください。** > > ファイルモードに慣れていない場合は、 `0o` プレフィックスが非常に重要であることに注意してください。これは8進数を示しており、モードを指定する際にはこの方法を使用しなければなりません。`644` を使用しようとすると、全く正しくない動作になってしまいます。 ### `FILE_UPLOAD_TEMP_DIR` デフォルト値: `None` ファイルをアップロードしている間にデータ (通常は [`FILE_UPLOAD_MAX_MEMORY_SIZE`](#std-setting-FILE_UPLOAD_MAX_MEMORY_SIZE) より大きなファイル) を一時的に保存するディレクトリ。`None` の場合、Djangoはオペレーティングシステムの標準的な一時ディレクトリを使用します。たとえば、これは \*nix スタイルのオペレーティングシステムではデフォルトで `/tmp` になります。 詳細は [ファイルの管理](/ja/5.2/topics/files/) を参照してください。 ### `FIRST_DAY_OF_WEEK` デフォルト値: `0` (日曜日) 週の最初の日を表す数字。カレンダーを表示する際に特に役立ちます。この値は、フォーマットの国際化が行われていない場合や、現在のロケールに対応するフォーマットが見つからない場合にのみ使用されます。 値は0から6までの整数でなければなりません。0は日曜日、1は月曜日、以降も同様です。 ### `FIXTURE_DIRS` デフォルト値: `[]` (空のリスト) [フィクスチャ](/ja/5.2/topics/db/fixtures/#fixtures-explanation) ファイルを検索するために、各アプリケーションの `fixtures` ディレクトリに加えて検索されるディレクトリのリスト。検索順。 これらのパスは、Windows でも Unix スタイルのスラッシュ (/) を使う必要があります。 [フィクスチャでデータを投入する](/ja/5.2/howto/initial-data/#initial-data-via-fixtures) と [フィクスチャのロード](/ja/5.2/topics/testing/tools/#topics-testing-fixtures) を参照してください。 ### `FORCE_SCRIPT_NAME` デフォルト値: `None` `None` でない場合、これはHTTPリクエストにおける `SCRIPT_NAME` 環境変数の値として使用されます。この設定により、サーバーが提供する `SCRIPT_NAME` の値を上書きできます（好きな値に書き換えることもできますし、何も提供しなくても構いません）。また、これはリクエスト/レスポンスサイクルの外部（例えば、管理コマンドやスタンドアロンのスクリプト）でURLリゾルバースクリプトのプレフィックスを設定するために [`django.setup()`](/ja/5.2/ref/applications/#django.setup) によって使用され、`FORCE_SCRIPT_NAME` が提供されたときに正しいURLを生成します。 ### `FORM_RENDERER` デフォルト値: `'`[`django.forms.renderers.DjangoTemplates`](/ja/5.2/ref/forms/renderers/#django.forms.renderers.DjangoTemplates)`'` フォームやフォームウィジェットをレンダリングするクラスです。[低レベルレンダリングAPI](/ja/5.2/ref/forms/renderers/#low-level-widget-render-api) を実装する必要があります。含まれるフォームレンダラは次の通りです。 - `'`[`django.forms.renderers.DjangoTemplates`](/ja/5.2/ref/forms/renderers/#django.forms.renderers.DjangoTemplates)`'` - `'`[`django.forms.renderers.Jinja2`](/ja/5.2/ref/forms/renderers/#django.forms.renderers.Jinja2)`'` - `'`[`django.forms.renderers.TemplatesSetting`](/ja/5.2/ref/forms/renderers/#django.forms.renderers.TemplatesSetting)`'` ### `FORMS_URLFIELD_ASSUME_HTTPS` > **Deprecated since Django 5.0** > > バージョン 5.0 で非推奨. デフォルト値: `False` この移行用設定を `True` に設定し、Django 5.x リリースサイクル中に新しいデフォルト値 `"https"` を使用するように [`URLField.assume_scheme`](/ja/5.2/ref/forms/fields/#django.forms.URLField.assume_scheme) の設定を変更するオプションを選択します。 ### `FORMAT_MODULE_PATH` デフォルト値: `None` プロジェクトのロケールに対するカスタムフォーマット定義を含むPythonパッケージへの完全なPythonパス。`None` でない場合、Djangoは現在のロケールとして名付けられたディレクトリの下にある `formats.py` ファイルをチェックし、このファイルで定義されているフォーマットを使用します。 フォーマットの定義があるディレクトリ名は、[locale name](/ja/5.2/topics/i18n/#term-locale-name) 表記を使用した名前であることが期待されます。たとえば、`de`、`pt_BR`、`en_US` などです。 たとえば、[`FORMAT_MODULE_PATH`](#std-setting-FORMAT_MODULE_PATH) が `mysite.formats` に設定され、現在の言語が `en` (英語) である場合、Djangoは次のようなディレクトリ構造を期待します: ```text mysite/ formats/ __init__.py en/ __init__.py formats.py ``` この設定には、Python のパスのリストを設定することもできます。たとえば: ``` FORMAT_MODULE_PATH = [ "mysite.formats", "some_app.formats", ] ``` Django が特定のフォーマットを検索する際、与えられた Python パス全体を通過し、実際にそのフォーマットを定義しているモジュールが見つかるまで探します。つまり、リストの上位にあるパッケージで定義されたフォーマットが、下位にある同じフォーマットより優先されます。 利用可能なフォーマットは以下の通りです: - [`DATE_FORMAT`](#std-setting-DATE_FORMAT) - [`DATE_INPUT_FORMATS`](#std-setting-DATE_INPUT_FORMATS) - [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT), - [`DATETIME_INPUT_FORMATS`](#std-setting-DATETIME_INPUT_FORMATS) - [`DECIMAL_SEPARATOR`](#std-setting-DECIMAL_SEPARATOR) - [`FIRST_DAY_OF_WEEK`](#std-setting-FIRST_DAY_OF_WEEK) - [`MONTH_DAY_FORMAT`](#std-setting-MONTH_DAY_FORMAT) - [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING) - [`SHORT_DATE_FORMAT`](#std-setting-SHORT_DATE_FORMAT) - [`SHORT_DATETIME_FORMAT`](#std-setting-SHORT_DATETIME_FORMAT) - [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR) - [`TIME_FORMAT`](#std-setting-TIME_FORMAT) - [`TIME_INPUT_FORMATS`](#std-setting-TIME_INPUT_FORMATS) - [`YEAR_MONTH_FORMAT`](#std-setting-YEAR_MONTH_FORMAT) ### `IGNORABLE_404_URLS` デフォルト値: `[]` (空のリスト) HTTP 404 エラーをメールで報告する際に無視すべき URL を記述した、コンパイルされた正規表現オブジェクトのリストです（詳細は、[エラーレポートの管理](/ja/5.2/howto/error-reporting/) を参照）。正規表現は、 [`リクエストのフルパス`](/ja/5.2/ref/request-response/#django.http.HttpRequest.get_full_path) (クエリ文字列を含む) と照合されます。 `favicon.ico` や `robots.txt` のような一般的なファイルを提供していない場合に使用してください。 これは、 [`BrokenLinkEmailsMiddleware`](/ja/5.2/ref/middleware/#django.middleware.common.BrokenLinkEmailsMiddleware) が有効になっている場合にのみ使用されます（詳細は、 [ミドルウェア (Middleware)](/ja/5.2/topics/http/middleware/) を参照）。 ### `INSTALLED_APPS` デフォルト値: `[]` (空のリスト) このDjangoインストールで有効になっているすべてのアプリケーションを示す文字列のリスト。各文字列は、Pythonのドット区切りパスである必要があります。 - アプリケーションの設定クラス（推奨）、または - アプリケーションを含むパッケージ。 [アプリケーション設定について詳しく知る](/ja/5.2/ref/applications/) 。 > **アプリケーションレジストリを利用してインストロスペクションを行う** > > コードからは直接 [`INSTALLED_APPS`](#std-setting-INSTALLED_APPS) にアクセスしないでください。代わりに [`django.apps.apps`](/ja/5.2/ref/applications/#django.apps.apps) を使用してください。 > **アプリケーション名とラベルは、 INSTALLED_APPS 内で一意である必要があります。** > > アプリケーションの属性 [`names`](/ja/5.2/ref/applications/#django.apps.AppConfig.name) （アプリケーションパッケージへのドット区切りのPythonパス）はユニークである必要があります。同じアプリケーションを2度含める方法はなく、コードを別の名前で複製する以外にありません。 > > アプリケーション [`labels`](/ja/5.2/ref/applications/#django.apps.AppConfig.label) （デフォルトでは名前の最後の部分） も一意でなければなりません。例えば、 `django.contrib.auth` と `myproject.auth` を両方含めることはできません。しかし、異なる [`label`](/ja/5.2/ref/applications/#django.apps.AppConfig.label) を定義するカスタム設定でアプリケーションのラベルを変更することはできます。 > > これらのルールは、 [`INSTALLED_APPS`](#std-setting-INSTALLED_APPS) がアプリケーション設定クラスを参照しているか、アプリケーションパッケージを参照しているかに関わらず適用されます。 いくつかのアプリケーションが同じリソース（テンプレート、静的ファイル、管理コマンド、翻訳）の異なるバージョンを提供する場合、 [`INSTALLED_APPS`](#std-setting-INSTALLED_APPS) で最初にリストされたアプリケーションが優先されます。 ### `INTERNAL_IPS` デフォルト値: `[]` (空のリスト) 文字列としての IP アドレスのリストで、以下の条件を満たします: - [`debug()`](/ja/5.2/ref/templates/api/#django.template.context_processors.debug) コンテキストプロセッサを許可して、テンプレートコンテキストにいくつかの変数を追加します。 - スタッフユーザーとしてログインしていなくても、 [admindocsブックマークレット](/ja/5.2/ref/contrib/admin/admindocs/#admindocs-bookmarklets) を使用できます。 - [`AdminEmailHandler`](/ja/5.2/ref/logging/#django.utils.log.AdminEmailHandler) の電子メールで（"EXTERNAL" に対して）"internal" とマークされます。 ### `LANGUAGE_CODE` デフォルト値: `'en-us'` このインストールに対する言語コードを表す文字列です。標準の [言語 ID フォーマット](/ja/5.2/topics/i18n/#term-language-code) 内にある文字列を指定します。例えば、U.S. の英語は `"en-us"` です。[list of language identifiers](http://www.i18nguy.com/unicode/language-identifiers.html) と [国際化とローカライズ](/ja/5.2/topics/i18n/) も参照してください。 これは次の3つの目的を果たします。 - ロケールミドルウェアが使用されていない場合、全ユーザにどの翻訳を提供するかを決めます。 - ロケールミドルウェアがアクティブの場合、ユーザの好む言語が不明な場合やウェブサイトでサポートされていない場合に備えて、フォールバックの言語として利用されます。また、与えられた文字列に対して、ユーザの好む言語に対応する翻訳が存在しない場合にも、この設定が利用されます。 - ローカライズが [`unlocalize`](/ja/5.2/topics/i18n/formatting/#std-templatefilter-unlocalize) フィルターや [`{% localize off %}`](/ja/5.2/topics/i18n/formatting/#std-templatetag-localize) タグで明示的に無効にされた場合、代わりにフォールバックのローカライズ形式が適用されます。詳細については、[テンプレートでのローカライズの制御](/ja/5.2/topics/i18n/formatting/#topic-l10n-templates) を参照してください。 詳しくは [Django はどうやって言語の優先順位を検出するのか？](/ja/5.2/topics/i18n/translation/#how-django-discovers-language-preference) を参照してください。 ### `LANGUAGE_COOKIE_AGE` デフォルト値: `None` (ブラウザを閉じると期限切れとなります) 言語クッキーの age で、秒で表します。 ### `LANGUAGE_COOKIE_DOMAIN` デフォルト値: `None` 言語クッキーに使用するドメインです。クロスドメインのクッキーのために `"example.com"` のような文字列に設定するか、標準のドメインクッキーには `None` を使用します。 本番サイトでこの設定を更新する際には注意してください。これまで標準ドメインのクッキーを使用していたサイトでこの設定を更新してクロスドメインのクッキーを有効にすると、古いドメインの既存のユーザークッキーは更新されません。これにより、これらのクッキーが残存している限り、サイトのユーザーは言語を切り替えることができなくなります。スイッチを行う唯一の安全で確実なオプションは、言語クッキーの名前を ( [`LANGUAGE_COOKIE_NAME`](#std-setting-LANGUAGE_COOKIE_NAME) 設定により) 恒久的に変更し、古いクッキーから新しいクッキーへ値をコピーし、古いものを削除するミドルウェアを追加することです。 ### `LANGUAGE_COOKIE_HTTPONLY` デフォルト値: `False` 言語クッキーに `HttpOnly` フラグを使用するかどうか。これが `True` に設定されている場合、クライアントサイドの JavaScript は言語クッキーにアクセスできません。 `HttpOnly` の詳細については、[`SESSION_COOKIE_HTTPONLY`](#std-setting-SESSION_COOKIE_HTTPONLY) を参照してください。 ### `LANGUAGE_COOKIE_NAME` デフォルト値: `'django_language'` 言語クッキーに使用するクッキーの名前です。これはあなたが望むものであれば何でも構いません（ただし、アプリケーション内の他のクッキー名と異なる必要があります）。詳細は [国際化とローカライズ](/ja/5.2/topics/i18n/) を参照してください。 ### `LANGUAGE_COOKIE_PATH` デフォルト値: `'/'` 言語クッキーのパス。これは、Django のインストール先の URL パスと一致するか、そのパスの親である必要があります。 これは、同じホスト名の下で複数の Django インスタンスが実行されている場合に便利です。異なるクッキーパスを使用でき、各インスタンスは自身の言語クッキーのみを確認できます。 本番サイトでこの設定を更新する際には慎重に行ってください。もし、この設定で以前よりも深いパスを使用するように更新した場合、古いパスを持つ既存のユーザークッキーは更新されません。これにより、これらのクッキーが存在する限り、サイトのユーザーは言語を切り替えることができなくなります。切り替えを安全かつ確実に行う唯一の方法は、言語クッキーの名前を永続的に変更すること ([`LANGUAGE_COOKIE_NAME`](#std-setting-LANGUAGE_COOKIE_NAME) 設定を通じて)、そして古いクッキーから新しいクッキーへ値をコピーしてから古いクッキーを削除するミドルウェアを追加することです。 ### `LANGUAGE_COOKIE_SAMESITE` デフォルト値: `None` 言語クッキーの [SameSite](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#samesitesamesite-value) フラグの値です。このフラグは、クロスサイトリクエストでクッキーが送信されるのを防ぎます。 `SameSite` についての詳細は、[`SESSION_COOKIE_SAMESITE`](#std-setting-SESSION_COOKIE_SAMESITE) を参照してください。 ### `LANGUAGE_COOKIE_SECURE` デフォルト値: `False` 言語クッキーにセキュアクッキーを使用するかどうか。これが `True` に設定されている場合、クッキーは "secure" としてマークされ、ブラウザーはそのクッキーが HTTPS 接続下でのみ送信されることを保証する場合があります。 ### `LANGUAGES` デフォルト値: 利用可能な全言語のリストです。このリストは常に拡大しており、ここにコピーを含めると速やかに時代遅れになってしまいます。現在の翻訳された言語のリストは、 [django/conf/global\_settings.py](https://github.com/django/django/blob/stable/5.2.x/django/conf/global_settings.py) で確認できます。 リストは、([言語コード](/ja/5.2/topics/i18n/#term-language-code), `言語名`) の形式の 2値タプルのリストです。例えば、`('ja', 'Japanese')` です。これは言語選択で利用可能な言語を指定します。詳細は [国際化とローカライズ](/ja/5.2/topics/i18n/) を参照してください。 一般的には、デフォルト値で十分です。Django が提供する言語の部分集合に選択肢を限定したいときにのみ、この設定を自分でセットしてください。 カスタム [`LANGUAGES`](#std-setting-LANGUAGES) 設定を定義した場合、 [`gettext_lazy()`](/ja/5.2/ref/utils/#django.utils.translation.gettext_lazy) 関数を使って言語名を翻訳文字列としてマークすることができます。 以下はサンプルの設定ファイルです: ``` from django.utils.translation import gettext_lazy as _ LANGUAGES = [ ("de", _("German")), ("en", _("English")), ] ``` ### `LANGUAGES_BIDI` デフォルト値: 右から左へ向かって書く言語のコード一覧です。これらの言語の現在の一覧は、 [django/conf/global\_settings.py](https://github.com/django/django/blob/stable/5.2.x/django/conf/global_settings.py) を見ることで確認できます。 リストには、右から左へ書かれる言語の [言語コード](/ja/5.2/topics/i18n/#term-language-code) が含まれています。 基本的にはデフォルト値で十分です。Django が提供する言語のサブセットに言語選択を制限したい場合にのみ、この設定を設定してください。カスタムな [`LANGUAGES`](#std-setting-LANGUAGES) 設定を定義すると、双方向言語のリストに、特定サイトで有効になっていない言語コードが含まれる可能性があります。 ### `LOCALE_PATHS` デフォルト値: `[]` (空のリスト) Django が翻訳ファイルを探すディレクトリのリストです。[Djangoはどうやって翻訳を見つけるのか？](/ja/5.2/topics/i18n/translation/#how-django-discovers-translations) を参照してください。 実装例: ``` LOCALE_PATHS = [ "/home/www/project/common_files/locale", "/var/local/translations/locale", ] ``` Django は、実際の翻訳ファイルを含む `/LC_MESSAGES` ディレクトリに対して、これらのパス内をそれぞれ見ていきます。 ### `LOGGING` デフォルト値: ロギング設定のディレクトリ。 設定情報を含むデータ構造です。このデータ構造が空でない場合、その内容は [`LOGGING_CONFIG`](#std-setting-LOGGING_CONFIG) で説明されている設定メソッドへの引数として渡されます。 デフォルトのロギング設定では、 [`DEBUG`](#std-setting-DEBUG) が `False` の場合、HTTP 500 サーバーエラーをメールログハンドラーに送信します。詳細は、 [ロギングを設定する](/ja/5.2/topics/logging/#configuring-logging) を参照してください。 デフォルトのログ設定は、 [django/utils/log.py](https://github.com/django/django/blob/stable/5.2.x/django/utils/log.py) で確認できます。 ### `LOGGING_CONFIG` デフォルト値: `'logging.config.dictConfig'` Django プロジェクトでロギングを設定するために使用される呼び出し可能オブジェクトへのパス。デフォルトでは Python の [dictConfig](https://docs.python.org/3/library/logging.config.html#logging-config-dictschema) 設定形式のインスタンスを指しています。 [`LOGGING_CONFIG`](#std-setting-LOGGING_CONFIG) を `None` に設定すると、ロギング設定プロセスはスキップされます。 ### `MANAGERS` デフォルト値: `[]` (空のリスト) [`ADMINS`](#std-setting-ADMINS) と同じ形式のリストで、 [`BrokenLinkEmailsMiddleware`](/ja/5.2/ref/middleware/#django.middleware.common.BrokenLinkEmailsMiddleware) が有効な場合に、誰がリンク切れ通知を受け取るべきかを指定します。 ### `MEDIA_ROOT` デフォルト値: `''` (空文字列) [ユーザーがアップロードしたファイル](/ja/5.2/topics/files/) を保存するディレクトリへの絶対ファイルシステムパス。 例: `"/var/www/example.com/media/"` 関連項目: [`MEDIA_URL`](#std-setting-MEDIA_URL) > **Warning** > > [`MEDIA_ROOT`](#std-setting-MEDIA_ROOT) と [`STATIC_ROOT`](#std-setting-STATIC_ROOT) は異なる値である必要があります。[`STATIC_ROOT`](#std-setting-STATIC_ROOT) が導入される前は、静的ファイルを提供するために [`MEDIA_ROOT`](#std-setting-MEDIA_ROOT) に依存したりフォールバックしたりすることが一般的でしたが、これは重大なセキュリティ上の影響を与える可能性があるので、これを防ぐための検証チェックが行われています。 ### `MEDIA_URL` デフォルト値: `''` (空文字列) [`MEDIA_ROOT`](#std-setting-MEDIA_ROOT) から提供されるメディアを扱う URL は、[保存されたファイルの管理](/ja/5.2/topics/files/) に使用されます。空でない値に設定されている場合は、スラッシュで終わる必要があります。開発環境と本番環境の両方で、これらのファイルが配信されるように [設定する必要があります](/ja/5.2/howto/static-files/#serving-uploaded-files-in-development) 。 テンプレートで `{{ MEDIA_URL }}` を使用したい場合は、 [`TEMPLATES`](#std-setting-TEMPLATES) の `'context_processors'` オプションに `'django.template.context_processors.media'` を追加してください。 例: `"https://media.example.com/"` > **Warning** > > 信頼できないユーザーからコンテンツアップロードを許可する場合、セキュリティリスクが存在します！緩和策の詳細は、[ユーザーがアップロードしたコンテンツ](/ja/5.2/topics/security/#user-uploaded-content-security) のセキュリティガイドを参照してください。 > **Warning** > > [`MEDIA_URL`](#std-setting-MEDIA_URL) と [`STATIC_URL`](#std-setting-STATIC_URL) は異なる値を持つ必要があります。詳細については [`MEDIA_ROOT`](#std-setting-MEDIA_ROOT) を参照してください。 > **Note** > > もし [`MEDIA_URL`](#std-setting-MEDIA_URL) が相対パスである場合、それは `SCRIPT_NAME` の値（設定されていない場合は `/` ）で接頭辞が付けられます。これにより、追加の設定を行わずにDjangoアプリケーションをサブパスで提供するのが簡単になります。 ### `MIDDLEWARE` デフォルト値: `None` 使用するミドルウェアのリストです。 [ミドルウェア (Middleware)](/ja/5.2/topics/http/middleware/) を参照してください。 ### `MIGRATION_MODULES` デフォルト値: `{}` (空の辞書) アプリごとにマイグレーションモジュールを検索できるパッケージを指定する辞書です。この設定のデフォルト値は空の辞書ですが、マイグレーションモジュールのデフォルトパッケージ名は `migrations` です。 実装例: ``` {"blog": "blog.db_migrations"} ``` この場合、`blog` アプリに関連するマイグレーションは `blog.db_migrations` パッケージに含まれます。 `app_label` 引数を提供した場合、[`makemigrations`](/ja/5.2/ref/django-admin/#django-admin-makemigrations) はパッケージがまだ存在しない場合、自動的にパッケージを作成します。 アプリに対して `None` を値として指定すると、Djangoはそのアプリをマイグレーションを持たないアプリとみなします。これは、例えば、テストの設定ファイルにおいてマイグレーションをスキップしながらテストを行うために使用できます (アプリのモデルのためにテーブルは依然として作成されます)。テスト中にすべてのアプリのマイグレーションを無効にするには、代わりに [`MIGRATE`](#std-setting-TEST_MIGRATE) を `False` に設定できます。プロジェクトの一般的な設定で `MIGRATION_MODULES` を使用している場合、アプリのためにテーブルを作成したい場合は [`migrate --run-syncdb`](/ja/5.2/ref/django-admin/#cmdoption-migrate-run-syncdb) オプションを使用してください。 ### `MONTH_DAY_FORMAT` デフォルト値: `'F j'` admin change-list のページの日付をフォーマットする時のデフォルト値です。システムの他の場所で月と日だけが表示される場合に使用される可能性があります。 たとえば、Django の admin change-list のページを日付でフィルタする時、与えられた日付のヘッダには月と日が表示されます。 対応するロケールによる書式が優先され、適用されることに留意してください。 [`使用可能な日付フォーマット文字列`](/ja/5.2/ref/templates/builtins/#std-templatefilter-date) を参照してください。また、[`DATE_FORMAT`](#std-setting-DATE_FORMAT), [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT), [`TIME_FORMAT`](#std-setting-TIME_FORMAT), [`YEAR_MONTH_FORMAT`](#std-setting-YEAR_MONTH_FORMAT) も参照してください。 ### `NUMBER_GROUPING` デフォルト値: `0` 数の整数部分をまとめるときの桁数です。 よくある使われ方は、1000倍の区切り文字を表示するときです。`0` に設定すると、数に対してグルーピングを行いません。`0` より大きい値を指定すると、 [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR) が区切り位置を求めるのに使います。 一部の地域では、数字の桁区切りが一様でないことがあります。たとえば、`en_IN` では `10,00,00,000` のようになります。この場合、適用するべき桁グループの数を示すシーケンスを提供できます。最初の数値は小数点区切り記号の前のグループのサイズを定義し、それに続く各数値は前のグループのサイズを定義します。シーケンスが `-1` で終了すると、さらなるグループ分けは行われません。シーケンスが `0` で終了すると、最後のグループのサイズが残りの数値に適用されます。 `en_IN` のための例のタプル: ``` NUMBER_GROUPING = (3, 2, 0) ``` ロケールが指定する形式が優先され、それが適用されるので注意してください。 [`DECIMAL_SEPARATOR`](#std-setting-DECIMAL_SEPARATOR), [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR), [`USE_THOUSAND_SEPARATOR`](#std-setting-USE_THOUSAND_SEPARATOR) も参照してください。 ### `PREPEND_WWW` デフォルト値: `False` "www." サブドメインが URL に含まれていない時、自動的に頭に追加するかどうかを指定します。この設定が有効になるのは、 [`CommonMiddleware`](/ja/5.2/ref/middleware/#django.middleware.common.CommonMiddleware) がインストールされている時のみです (参照: [ミドルウェア (Middleware)](/ja/5.2/topics/http/middleware/))。[`APPEND_SLASH`](#std-setting-APPEND_SLASH) も参照してください。 ### `ROOT_URLCONF` デフォルト値: 定義されていません あなたのルートURLconfへの完全なPythonインポートパスを表す文字列です。例えば `"mydjangoapps.urls"` のようになります。受け取る `HttpRequest` オブジェクトの `urlconf` 属性を設定することで、リクエストごとにオーバーライドできます。詳細については [Django のリクエスト処理](/ja/5.2/topics/http/urls/#how-django-processes-a-request) を参照してください。 ### `SECRET_KEY` デフォルト値: `''` (空文字列) Django のインストールごとに設定される個別の秘密鍵です。[暗号署名](/ja/5.2/topics/signing/) に使われる鍵であり、ユニークかつ予測できない値でなければなりません。 [`django-admin startproject`](/ja/5.2/ref/django-admin/#django-admin-startproject) コマンドを実行すると、新しいプロジェクトを作成するたびに、ランダムに生成された `SECRET_KEY` を自動的に設定してくれます。 キーを使用する際、テキストまたはバイトであるとは仮定すべきではありません。使用する際は必ず、それを目的の型に変換するために、 [`force_str()`](/ja/5.2/ref/utils/#django.utils.encoding.force_str) または [`force_bytes()`](/ja/5.2/ref/utils/#django.utils.encoding.force_bytes) を通して行う必要があります。 [`SECRET_KEY`](#std-setting-SECRET_KEY) が設定されていない場合、Django は起動しません。 > **Warning** > > **この値は、絶対に秘密にしてください。** > > Django を既知の [`SECRET_KEY`](#std-setting-SECRET_KEY) で実行してしまうと、Django の多数のセキュリティプロテクションが破られ、結果的に、コンピュータの重要な権限が取得されてリモートコード実行の脆弱性に晒されてしまいます。 秘密鍵は次のような場合に使われます。 - `django.contrib.sessions.backends.cache` 以外のセッションバックエンドを使用しているか、デフォルトの [`get_session_auth_hash()`](/ja/5.2/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser.get_session_auth_hash) を使用している場合は、すべての [sessions](/ja/5.2/topics/http/sessions/) 。 - [`CookieStorage`](/ja/5.2/ref/contrib/messages/#django.contrib.messages.storage.cookie.CookieStorage) または [`FallbackStorage`](/ja/5.2/ref/contrib/messages/#django.contrib.messages.storage.fallback.FallbackStorage) を使用している場合、すべての [messages](/ja/5.2/ref/contrib/messages/) 。 - すべての [`PasswordResetView`](/ja/5.2/topics/auth/default/#django.contrib.auth.views.PasswordResetView) トークン。 - 異なるキーが指定されていない限り、すべての [暗号署名](/ja/5.2/topics/signing/) の使用。 [`SECRET_KEY`](#std-setting-SECRET_KEY) で設定されていない、または [`SECRET_KEY_FALLBACKS`](#std-setting-SECRET_KEY_FALLBACKS) に含まれていない秘密鍵は、上記のすべてが無効になります。秘密鍵をローテーションさせるときは、古い鍵を一時的に [`SECRET_KEY_FALLBACKS`](#std-setting-SECRET_KEY_FALLBACKS) に移動するべきです。秘密鍵は、ユーザーのパスワードには使用されず、鍵のローテーションがそれらに影響を与えることはありません。 > **Note** > > [`django-admin startproject`](/ja/5.2/ref/django-admin/#django-admin-startproject) で作成されるデフォルトの `settings.py` ファイルは、利便性のため、ユニークな `SECRET_KEY` を生成します。 ### `SECRET_KEY_FALLBACKS` デフォルト値: `[]` 特定のDjangoインストールに関連するフォールバックの秘密鍵のリストです。これらは、 `SECRET_KEY` のローテーションを可能にするために使用されます。 秘密鍵をローテーションするために、新しい `SECRET_KEY` を設定し、以前の値を `SECRET_KEY_FALLBACKS` の最初に移動してください。その後、それらを使用するセッション、パスワードリセットトークンなどを期限切れにする準備ができたら、`SECRET_KEY_FALLBACKS` の最後から古い値を削除してください。 > **Note** > > 署名操作は計算コストが高いものです。 `SECRET_KEY_FALLBACKS` に複数の古いキー値を持つことは、以前のキーと一致しないすべてのチェックに追加のオーバーヘッドをもたらします。 > > そのため、適切な期間が経過した後には、フォールバック値を削除し、キーローテーションを行うべきです。 秘密キーの値の使用時は、それらがテキストまたはバイトであると仮定すべきではありません。使用する際には、希望のタイプに変換するために [`force_str()`](/ja/5.2/ref/utils/#django.utils.encoding.force_str) または [`force_bytes()`](/ja/5.2/ref/utils/#django.utils.encoding.force_bytes) を通じて行うべきです。 ### `SECURE_CONTENT_TYPE_NOSNIFF` デフォルト値: `True` `True` であれば、 [`SecurityMiddleware`](/ja/5.2/ref/middleware/#django.middleware.security.SecurityMiddleware) は、既にそれを持っていないすべてのレスポンスに [X-Content-Type-Options: nosniff](/ja/5.2/ref/middleware/#x-content-type-options) ヘッダーを設定します。 ### `SECURE_CROSS_ORIGIN_OPENER_POLICY` デフォルト値: `'same-origin'` `None` に設定されていない限り、 [`SecurityMiddleware`](/ja/5.2/ref/middleware/#django.middleware.security.SecurityMiddleware) はそれが既に設定されていないすべてのレスポンスに、提供された値を使用して [同一生成元ポリシー (Cross-Origin Opener Policy)](/ja/5.2/ref/middleware/#cross-origin-opener-policy) ヘッダを設定します。 ### `SECURE_HSTS_INCLUDE_SUBDOMAINS` デフォルト値: `False` `True` の場合、 [`SecurityMiddleware`](/ja/5.2/ref/middleware/#django.middleware.security.SecurityMiddleware) は [HTTP Strict Transport Security](/ja/5.2/ref/middleware/#http-strict-transport-security) ヘッダーに `includeSubDomains` ディレクティブを追加します。 [`SECURE_HSTS_SECONDS`](#std-setting-SECURE_HSTS_SECONDS) が 0 でない値に設定されていない限り、効果はありません。 > **Warning** > > これを誤って設定すると、 [`SECURE_HSTS_SECONDS`](#std-setting-SECURE_HSTS_SECONDS) の値に対して不可逆的にサイトを壊すことがあります。まず [HTTP Strict Transport Security](/ja/5.2/ref/middleware/#http-strict-transport-security) のドキュメントを読んでください。 ### `SECURE_HSTS_PRELOAD` デフォルト値: `False` `True` の場合、 [`SecurityMiddleware`](/ja/5.2/ref/middleware/#django.middleware.security.SecurityMiddleware) は `preload` 指令を [HTTP Strict Transport Security](/ja/5.2/ref/middleware/#http-strict-transport-security) ヘッダーに追加します。これは [`SECURE_HSTS_SECONDS`](#std-setting-SECURE_HSTS_SECONDS) が非ゼロの値に設定されていない限り、効果がありません。 ### `SECURE_HSTS_SECONDS` デフォルト値: `0` ゼロでない整数値に設定されている場合、 [`SecurityMiddleware`](/ja/5.2/ref/middleware/#django.middleware.security.SecurityMiddleware) は、まだ設定されていないすべてのレスポンスに対して [HTTP Strict Transport Security](/ja/5.2/ref/middleware/#http-strict-transport-security) ヘッダを設定します。 > **Warning** > > 設定を誤ると、しばらくの間サイトが壊れてしまう可能性があります。まずは [HTTP Strict Transport Security](/ja/5.2/ref/middleware/#http-strict-transport-security) のドキュメントをお読みください。 ### `SECURE_PROXY_SSL_HEADER` デフォルト値: `None` リクエストが安全であることを示す HTTP ヘッダー/値の組み合わせを表すタプル。これはリクエストオブジェクトの `is_secure()` メソッドの動作を制御します。 デフォルトでは、`is_secure()` はリクエストがセキュアかどうかを確認するためにリクエストされたURLが `https://` を使用しているかどうかを判定します。このメソッドはDjangoのCSRF保護に重要であり、あなた自身のコードやサードパーティのアプリでも使用されるかもしれません。 もし Django アプリがプロキシの背後にある場合、プロキシが元のリクエストが HTTPS を使用しているかどうかを「隠して」しまうことがあります。プロキシと Django の間に非 HTTPS 接続がある場合、`is_secure()` は常に `False` を返します。これはエンドユーザーが HTTPS 経由で行ったリクエストであってもです。対照的に、プロキシと Django の間に HTTPS 接続がある場合、`is_secure()` は常に `True` を返します。これは元々 HTTP 経由で行われたリクエストであってもです。 この状況では、プロキシを設定してカスタムHTTPヘッダーを設定し、リクエストがHTTPS経由で来たかどうかをDjangoに伝え、そして `SECURE_PROXY_SSL_HEADER` を設定してDjangoがどのヘッダーを探すべきかを知らせます。 2つの要素を持つタプルを設定します。検索するヘッダーの名前と必要な値です。例えば: ``` SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https") ``` これは、次のような場合に、プロキシから来る `X-Forwarded-Proto` ヘッダーを Django が信頼し、リクエストが安全であること（つまり、元々は HTTPS を介して入ってきた）を保証するように指示します: - ヘッダーの値が `'https'` であるか、または - その初期値、プロトコルのカンマ区切りリスト (例: `'https,http,http'`) の最も左の値が `'https'` の場合。 この設定は、プロキシを制御している場合、またはこのヘッダーを適切に設定/削除するという他の保証がある場合にのみ設定すべきです。 ヘッダーは `request.META` で使われる形式にする必要があります。すべて大文字で、おそらく `HTTP_` で始まります。(Django は、ヘッダー名の先頭に `'HTTP_'` を自動的に追加してから、ヘッダーを `request.META` で利用可能にします。) > **Warning** > > **この設定を変更すると、サイトのセキュリティが損なわれる可能性があります。変更する前に、設定を完全に理解してください。** > > 次のすべてが真であることを設定する前に確認してください（上記の例からの値を想定しています）: > > - あなたの Django アプリがプロキシの背後にあること。 > - プロキシは、カンマ区切りのプロトコルリストが含まれている場合でも、すべての受信リクエストから `X-Forwarded-Proto` ヘッダーを削除すること。言い換えると、エンドユーザーがそのヘッダーをリクエストに含めた場合、プロキシはそれを破棄すること。 > - プロキシは `X-Forwarded-Proto` ヘッダを設定して Django に送ること、これは HTTPS 経由で元々来たリクエストに対してのみです。 > > これらのいずれかが真でない場合は、この設定を `None` に設定したままにして、カスタムミドルウェアを介して HTTPS を決定する別の方法を見つけるべきです。 ### `SECURE_REDIRECT_EXEMPT` デフォルト値: `[]` (空のリスト) このリスト内の正規表現にURLパスが一致する場合、リクエストはHTTPSへリダイレクトされません。 [`SecurityMiddleware`](/ja/5.2/ref/middleware/#django.middleware.security.SecurityMiddleware) はURLパスから先頭のスラッシュを削除するため、パターンにはそれを含めるべきではありません。例: `SECURE_REDIRECT_EXEMPT = [r'^no-ssl/$', …]` 。[`SECURE_SSL_REDIRECT`](#std-setting-SECURE_SSL_REDIRECT) が `False` の場合、この設定は効果がありません。 ### `SECURE_REFERRER_POLICY` デフォルト値: `'same-origin'` 設定されていれば、 [`SecurityMiddleware`](/ja/5.2/ref/middleware/#django.middleware.security.SecurityMiddleware) は、それがまだ設定されていないすべてのレスポンスに対して、提供された値に従って [リファラ・ポリシー](/ja/5.2/ref/middleware/#referrer-policy) ヘッダーを設定します。 ### `SECURE_SSL_HOST` デフォルト値: `None` 文字列 (例: `secure.example.com`) を設定すると、すべてのSSLリダイレクトが元々リクエストされたホスト (例: `www.example.com`) の代わりにこのホストに向けられます。 [`SECURE_SSL_REDIRECT`](#std-setting-SECURE_SSL_REDIRECT) が `False` の場合、この設定は無効です。 ### `SECURE_SSL_REDIRECT` デフォルト値: `False` もし `True` なら、 [`SecurityMiddleware`](/ja/5.2/ref/middleware/#django.middleware.security.SecurityMiddleware) は、全てのHTTPSではないリクエストをHTTPSに [リダイレクト](/ja/5.2/ref/middleware/#ssl-redirect) します ([`SECURE_REDIRECT_EXEMPT`](#std-setting-SECURE_REDIRECT_EXEMPT) でリストされた正規表現に一致するURLを除く)。 > **Note** > > `True` に変更するとリダイレクトが無限に発生する場合、おそらくサイトがプロキシの後ろで実行されており、どのリクエストがセキュアかを判断できていないことを意味しています。おそらくプロキシはセキュアなリクエストを示すヘッダを設定しています。この問題を修正するには、そのヘッダが何かを調べ、 [`SECURE_PROXY_SSL_HEADER`](#std-setting-SECURE_PROXY_SSL_HEADER) 設定を適切に設定してください。 ### `SERIALIZATION_MODULES` デフォルト値: 定義されていません シリアライゼーションタイプに対する文字列識別子をキーとし、シリアライザ定義 (文字列として提供される) を含むモジュールのディクショナリです。例えば、YAML シリアライザを定義するには、以下を使用します。 ``` SERIALIZATION_MODULES = {"yaml": "path.to.yaml_serializer"} ``` ### `SERVER_EMAIL` デフォルト値: `'root@localhost'` エラーメッセージが送信されるメールアドレスは、 [`ADMINS`](#std-setting-ADMINS) や [`MANAGERS`](#std-setting-MANAGERS) に送信されるメールの送信元となるアドレスです。このアドレスは、選択したメール送信プロトコルで有効な任意の形式を取ることができます。 > **私のメールが異なるアドレスから送信されるのはなぜですか？** > > このアドレスはエラーメッセージ専用です。普通のメールメッセージが [`send_mail()`](/ja/5.2/topics/email/#django.core.mail.send_mail) で送信される際のアドレスとは *異なります* 。そのためには、 [`DEFAULT_FROM_EMAIL`](#std-setting-DEFAULT_FROM_EMAIL) を参照してください。 ### `SHORT_DATE_FORMAT` デフォルト値: `'m/d/Y'` (例: `12/31/2003`) テンプレートで日付フィールドを表示するために利用できるフォーマットです。但し、対応するロケールによって指定されたフォーマットが優先され、代わりに適用されます。詳細は、 [`使用可能な日付フォーマット文字列`](/ja/5.2/ref/templates/builtins/#std-templatefilter-date) を参照してください。 関連項目: [`DATE_FORMAT`](#std-setting-DATE_FORMAT), [`SHORT_DATETIME_FORMAT`](#std-setting-SHORT_DATETIME_FORMAT) ### `SHORT_DATETIME_FORMAT` デフォルト値: `'m/d/Y P'` (例: `12/31/2003 4 p.m.`) テンプレートで日時フィールドを表示するために使用できる利用可能なフォーマットです。対応するロケールに従ったフォーマットが優先され、代わりに適用されます。詳細は、 [`利用可能な文字列フォーマット`](/ja/5.2/ref/templates/builtins/#std-templatefilter-date) をご覧ください。 関連項目: [`DATE_FORMAT`](#std-setting-DATE_FORMAT), [`SHORT_DATE_FORMAT`](#std-setting-SHORT_DATE_FORMAT) ### `SIGNED_COOKIE_LEGACY_SALT_FALLBACK` > **New in Django 5.2.15** デフォルト値: `True` Controls whether [`get_signed_cookie()`](/ja/5.2/ref/request-response/#django.http.HttpRequest.get_signed_cookie) accepts cookies signed with Django's historical signed-cookie salt derivation based on `key + salt`. Set this to `False` to reject those legacy signed cookies and only accept cookies signed with Django's current unambiguous signed-cookie salt derivation. This transitional setting will be removed in Django 7.0, when the legacy signed cookies will no longer be accepted. ### `SIGNING_BACKEND` デフォルト値: `'django.core.signing.TimestampSigner'` クッキーやその他のデータに署名する際に使用されるバックエンド。 関連項目: [暗号署名](/ja/5.2/topics/signing/) ドキュメント ### `SILENCED_SYSTEM_CHECKS` デフォルト値: `[]` (空のリスト) システムチェックフレームワークによって生成されたメッセージの識別子リスト (例: `["models.W001"]`) で、永久に認識し、無視したいものです。無視されたチェックはコンソールに出力されません。 関連項目: [システムチェックフレームワーク](/ja/5.2/ref/checks/) ドキュメント ### `STORAGES` デフォルト値: ``` { "default": { "BACKEND": "django.core.files.storage.FileSystemStorage", }, "staticfiles": { "BACKEND": "django.contrib.staticfiles.storage.StaticFilesStorage", }, } ``` Djangoで使用されるすべてのストレージの設定を含む辞書です。 ストレージエイリアスを個々のストレージのオプションを含む辞書にマッピングした入れ子構造の辞書です。 ストレージには任意のエイリアスを指定できます。ただし、特別な意味を持つ2つのエイリアスがあります。 - `default` は [ファイルを管理する](/ja/5.2/topics/files/) ためのものです。 `'`[`django.core.files.storage.FileSystemStorage`](/ja/5.2/ref/files/storage/#django.core.files.storage.FileSystemStorage)`'` がデフォルトのストレージエンジンです。 - `staticfiles` は [静的ファイルの管理](/ja/5.2/ref/contrib/staticfiles/) 用です。 `'`[`django.contrib.staticfiles.storage.StaticFilesStorage`](/ja/5.2/ref/contrib/staticfiles/#django.contrib.staticfiles.storage.StaticFilesStorage)`'` がデフォルトのストレージエンジンです。 以下は、カスタムファイルストレージ `example` を定義する `settings.py` のコードの例です。 ``` STORAGES = { # ... "example": { "BACKEND": "django.core.files.storage.FileSystemStorage", "OPTIONS": { "location": "/example", "base_url": "/example/", }, }, } ``` `**kwargs` を使って、 `BACKEND` の初期化時に `OPTIONS` が渡されます。 使用可能なストレージバックエンドのインスタンスは、 [`django.core.files.storage.storages`](/ja/5.2/ref/files/storage/#django.core.files.storage.storages) から取得できます。 [`STORAGES`](#std-setting-STORAGES) でのバックエンド定義に対応するキーを使用してください。 > **私の値はデフォルト値とマージされますか？** > > この設定を定義すると、デフォルト値を上書きし、それとは *結合されません* 。 ### `TEMPLATES` デフォルト値: `[]` (空のリスト) Django で使用されるすべてのテンプレートエンジンの設定を含むリストです。リストの各項目は、個々のエンジンのオプションを含む辞書です。 以下の設定では、Django テンプレートエンジンに対し、インストールされた各アプリケーション内の `templates` サブディレクトリからテンプレートを読み込むよう指示します: ``` TEMPLATES = [ { "BACKEND": "django.template.backends.django.DjangoTemplates", "APP_DIRS": True, }, ] ``` すべてのバックエンドで利用可能なオプションは以下の通りです: #### `BACKEND` デフォルト値: 定義されていません 使用するテンプレートバックエンドです。内蔵のテンプレートバックエンドは以下の通りです: - `'django.template.backends.django.DjangoTemplates'` - `'django.template.backends.jinja2.Jinja2'` Django に付属していないテンプレートバックエンドを使用するには、`BACKEND` を完全修飾パス (例： `'mypackage.whatever.Backend'`) で設定します。 #### `NAME` デフォルト値: 下記を参照してください この特定のテンプレートエンジンのエイリアス。エンジンを選択するための識別子です。エイリアスは、構成されたすべてのテンプレートエンジンで一意である必要があります。 エンジンクラスを定義するモジュールの名前がデフォルト値です。つまり、指定されていない場合 [`BACKEND`](#std-setting-TEMPLATES-BACKEND) の最後から2番目の要素になります。例えば、バックエンドが `'mypackage.whatever.Backend'` であれば、そのデフォルト名は `'whatever'` になります。 #### `DIRS` デフォルト値: `[]` (空のリスト) エンジンがテンプレートのソースファイルを探すべきディレクトリ、検索順序付き。 #### `APP_DIRS` デフォルト値: `False` エンジンがインストールされたアプリケーション内でテンプレートのソースファイルを探すべきかどうか。 > **Note** > > [`django-admin startproject`](/ja/5.2/ref/django-admin/#django-admin-startproject) によって生成されるデフォルトの `settings.py` ファイルは `'APP_DIRS': True` を設定します。 #### `OPTIONS` デフォルト値: `{}` (空のディクショナリ) テンプレートバックエンドに渡す追加のパラメーターです。 利用可能なパラメーターは、テンプレートバックエンドによって異なります。 組み込みバックエンドのオプションについては、 [`DjangoTemplates`](/ja/5.2/topics/templates/#django.template.backends.django.DjangoTemplates) と [`Jinja2`](/ja/5.2/topics/templates/#django.template.backends.jinja2.Jinja2) を参照してください。 ### `TEST_RUNNER` デフォルト値: `'django.test.runner.DiscoverRunner'` テストスイートを開始するために使用するクラスの名前。 [ほかのテストフレームワークを使う](/ja/5.2/topics/testing/advanced/#other-testing-frameworks) を参照してください。 ### `TEST_NON_SERIALIZED_APPS` デフォルト値: `[]` (空のリスト) `TransactionTestCase` やトランザクションを使用しないデータベースバックエンドのテスト間でデータベースの状態を復元するために、Djangoはテスト実行が開始されると [すべてのアプリの内容をシリアライズ](/ja/5.2/topics/testing/overview/#test-case-serialized-rollback) し、それを必要とするテストを実行する前にそのコピーからリロードできるようにします。 これによって、テストランナーの起動時間が遅くなります。この機能が不要なアプリがある場合は、完全な名前をここに追加して、このシリアライズ処理から除外できます (例: `'django.contrib.contenttypes'`)。 ### `THOUSAND_SEPARATOR` デフォルト値: `','` (カンマ) 数字のフォーマット時に使用するデフォルトの千の区切り記号です。この設定は、[`USE_THOUSAND_SEPARATOR`](#std-setting-USE_THOUSAND_SEPARATOR) が `True` であり、[`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING) が `0` より大きい場合にのみ使用されます。 ロケールが指定する形式が優先され、それが適用されるので注意してください。 関連項目: [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING), [`DECIMAL_SEPARATOR`](#std-setting-DECIMAL_SEPARATOR), [`USE_THOUSAND_SEPARATOR`](#std-setting-USE_THOUSAND_SEPARATOR) ### `TIME_FORMAT` デフォルト値: `'P'` (例: `4 p.m.`) システムのどの部分でも、時間フィールドを表示する際に使用するデフォルトの書式設定です。ロケールに依存する書式が優先され、代わりに適用されます。 [`使用可能な日付フォーマット文字列`](/ja/5.2/ref/templates/builtins/#std-templatefilter-date) を参照してください。 関連項目: [`DATE_FORMAT`](#std-setting-DATE_FORMAT), [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT) ### `TIME_INPUT_FORMATS` デフォルト値: ``` [ "%H:%M:%S", # '14:30:59' "%H:%M:%S.%f", # '14:30:59.000200' "%H:%M", # '14:30' ] ``` 時間フィールドでデータを入力するときに受け入れられる形式のリストです。形式は順番に試され、最初の有効なものが使用されます。これらの形式文字列は、 [`date`](/ja/5.2/ref/templates/builtins/#std-templatefilter-date) テンプレートフィルタからの形式文字列ではなく、Pythonの [datetime モジュールの構文](https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior) を使用していることに注意してください。 ロケールが指定するフォーマットが優先され、代わりに適用されます。 関連項目: [`DATE_INPUT_FORMATS`](#std-setting-DATE_INPUT_FORMATS) および [`DATETIME_INPUT_FORMATS`](#std-setting-DATETIME_INPUT_FORMATS) を参照してください。 ### `TIME_ZONE` デフォルト値: `'America/Chicago'` このインストールのタイムゾーンを表す文字列です。タイムゾーンの一覧は、 [list of time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) を参照してください。 > **Note** > > Django は最初 [`TIME_ZONE`](#std-setting-TIME_ZONE) を `'America/Chicago'` にしてリリースされていたので、後方互換性のために (プロジェクト内で `settings.py` が定義されていないときに使われる) グローバル設定は `'America/Chicago'` のままになっています。新しいプロジェクトのテンプレートではデフォルトは `'UTC'` です。 これは必ずしもサーバのタイムゾーンではないことに注意してください。たとえば、1 つのサーバ内に Django 製のサイトがあり、それぞれが異なるタイムゾーン設定を持つこともできます。 [`USE_TZ`](#std-setting-USE_TZ) が `False` のとき、これは Django が日時を保持するタイムゾーンとなります。[`USE_TZ`](#std-setting-USE_TZ) が `True` のとき、これは Django がテンプレート内で日時を表示するため、およびフォーム内で入力された日時を解釈するために使う、デフォルトのタイムゾーンです。 Unix 環境 (ここで [`time.tzset()`](https://docs.python.org/3/library/time.html#time.tzset) が実装されている場合)では、Djangoは `os.environ['TZ']` 変数を [`TIME_ZONE`](#std-setting-TIME_ZONE) 設定で指定したタイムゾーンに設定します。したがって、すべてのビューとモデルは自動的にこのタイムゾーンで動作します。しかし、 [手動で設定を行う](/ja/5.2/topics/settings/#settings-without-django-settings-module) で説明されているような手動設定オプションを使用している場合は、Djangoは `TZ` 環境変数を設定しません。Djangoが `TZ` 環境変数を設定しない場合は、プロセスが正しい環境で実行されていることを確認するのはあなたの責任です。 > **Note** > > Django は、Windows 環境で代替タイムゾーンを正しく扱うことができません。Django を Windows で実行している場合、[`TIME_ZONE`](#std-setting-TIME_ZONE) はシステムのタイムゾーンに合わせてセットする必要があります。 ### `USE_I18N` デフォルト値: `True` Djangoの翻訳システムを有効にするかどうかを指定する真偽値です。パフォーマンスのためにオフにする方法を提供します。これが `False` に設定されている場合、Djangoは翻訳システムを読み込まないように一部の最適化を行います。 関連項目: [`LANGUAGE_CODE`](#std-setting-LANGUAGE_CODE) および [`USE_TZ`](#std-setting-USE_TZ) > **Note** > > [`django-admin startproject`](/ja/5.2/ref/django-admin/#django-admin-startproject) によって作成されるデフォルトの `settings.py` ファイルには、利便性のため、 `USE_I18N = True` が含まれています。 ### `USE_THOUSAND_SEPARATOR` デフォルト値: `False` 真偽値で、数値を 1,000 単位で表示するかどうかを指定します。 `True` に設定すると、Django は数値を [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING) と [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR) の設定に従ってフォーマットします。最後の 2 つの設定はロケールによっても決定される可能性があり、そちらが優先されます。 関連項目: [`DECIMAL_SEPARATOR`](#std-setting-DECIMAL_SEPARATOR), [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING), [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR) ### `USE_TZ` デフォルト値: `True` デフォルトで日時がタイムゾーンを意識するかどうかを指定する真偽値です。これが `True` に設定されている場合、Django は内部的にタイムゾーンを意識した日時を使用します。 `USE_TZ` が False の場合、Django はローカルタイムで naive な日時を使用しますが、ISO 8601 形式の文字列を解析するときには、タイムゾーン情報が存在すれば常に保持されます。 関連項目:[`TIME_ZONE`](#std-setting-TIME_ZONE) および [`USE_I18N`](#std-setting-USE_I18N) ### `USE_X_FORWARDED_HOST` デフォルト値: `False` `X-Forwarded-Host` ヘッダを `Host` ヘッダより優先して使用するかどうかを指定する真偽値です。このヘッダを設定するプロキシが使用されている場合にのみ有効化すべきです。 この設定は [`USE_X_FORWARDED_PORT`](#std-setting-USE_X_FORWARDED_PORT) よりも優先されます。[**RFC 7239 Section 5.3**](https://datatracker.ietf.org/doc/html/rfc7239.html#section-5.3) によると、`X-Forwarded-Host` ヘッダにはポート番号を含めることができるため、その場合は [`USE_X_FORWARDED_PORT`](#std-setting-USE_X_FORWARDED_PORT) を使用すべきではありません。 ### `USE_X_FORWARDED_PORT` デフォルト値: `False` `X-Forwarded-Port` ヘッダを `SERVER_PORT` `META` 変数より優先して使用するかどうかを指定する真偽値です。このヘッダを設定するプロキシが使用されている場合のみ、これを有効にするべきです。 この設定より [`USE_X_FORWARDED_HOST`](#std-setting-USE_X_FORWARDED_HOST) の方が優先されます。 ### `WSGI_APPLICATION` デフォルト値: `None` Djangoの組み込みサーバー (例えば [`runserver`](/ja/5.2/ref/django-admin/#django-admin-runserver)) が使用するWSGIアプリケーションオブジェクトの完全なPythonパスです。[`django-admin startproject`](/ja/5.2/ref/django-admin/#django-admin-startproject) 管理コマンドは標準の `wsgi.py` ファイルを作成し、その中に `application` 呼び出し可能オブジェクトを含め、この設定をその `application` にポイントします。 設定されていない場合は、 `django.core.wsgi.get_wsgi_application()` の返り値が使用されます。この場合、[`runserver`](/ja/5.2/ref/django-admin/#django-admin-runserver) の動作は以前のDjangoバージョンと同一になります。 ### `YEAR_MONTH_FORMAT` デフォルト値: `'F Y'` Django管理サイトのチェンジリストページで、年と月のみが表示される場合に、デフォルトの日付フィールドの書式設定を使用する方法。そして、システムの他の部分でも同様に適用される可能性があります。 たとえば、Djangoの管理画面のチェンジリストページが日付で絞り込まれている場合、指定された月のヘッダーには月と年が表示されます。異なるロケールには異なる形式があります。例えば、米国英語では「January 2006」と表示されますが、別のロケールでは「2006/January」のように表示されるかもしれません。 対応するロケールによる書式が優先され、適用されることに留意してください。 許可される日付フォーマット文字列については、 [`使用可能な日付フォーマット文字列`](/ja/5.2/ref/templates/builtins/#std-templatefilter-date) を参照してください。また、 [`DATE_FORMAT`](#std-setting-DATE_FORMAT) 、 [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT) 、 [`TIME_FORMAT`](#std-setting-TIME_FORMAT) および [`MONTH_DAY_FORMAT`](#std-setting-MONTH_DAY_FORMAT) も参照してください。 ### `X_FRAME_OPTIONS` デフォルト値: `'DENY'` [`XFrameOptionsMiddleware`](/ja/5.2/ref/middleware/#django.middleware.clickjacking.XFrameOptionsMiddleware) によって使用される X-Frame-Options ヘッダのデフォルト値については、[クリックジャッキング保護](/ja/5.2/ref/clickjacking/) のドキュメントを参照してください。 ## 認証 [`django.contrib.auth`](/ja/5.2/topics/auth/#module-django.contrib.auth) の設定 ### `AUTHENTICATION_BACKENDS` デフォルト値: `['django.contrib.auth.backends.ModelBackend']` ユーザーを認証しようとするときに使用する認証バックエンドクラスのリスト（文字列形式）。詳細については [認証バックエンドのドキュメント](/ja/5.2/topics/auth/customizing/#authentication-backends) を参照してください。 ### `AUTH_USER_MODEL` デフォルト値: `'auth.User'` User を表すために使うモデルです。[カスタムの User モデルを置き換える](/ja/5.2/topics/auth/customizing/#auth-custom-user) を参照してください。 > **Warning** > > プロジェクトのライフサイクル中 (つまり、それに依存するモデルを作成しマイグレーションした後 )に AUTH\_USER\_MODEL 設定を変更することは困難です。プロジェクト開始時に設定し、参照するモデルは、それが存在するアプリの最初のマイグレーションで利用可能である必要があります。詳細は、 [カスタムの User モデルを置き換える](/ja/5.2/topics/auth/customizing/#auth-custom-user) を参照してください。 ### `LOGIN_REDIRECT_URL` デフォルト値: `'/accounts/profile/'` [`LoginView`](/ja/5.2/topics/auth/default/#django.contrib.auth.views.LoginView) が `next` GET パラメータを受け取らないときにログイン後にリダイレクトされる URL または [名前付き URL パターン](/ja/5.2/topics/http/urls/#naming-url-patterns) 。 ### `LOGIN_URL` デフォルト値: `'/accounts/login/'` [`login_required()`](/ja/5.2/topics/auth/default/#django.contrib.auth.decorators.login_required) デコレータ、[`LoginRequiredMixin`](/ja/5.2/topics/auth/default/#django.contrib.auth.mixins.LoginRequiredMixin)、[`AccessMixin`](/ja/5.2/topics/auth/default/#django.contrib.auth.mixins.AccessMixin) を使っているとき、または [`LoginRequiredMiddleware`](/ja/5.2/ref/middleware/#django.contrib.auth.middleware.LoginRequiredMiddleware) ミドルウェアがインストールされている場合に、ログインのためにリダイレクトされる URL または [名前付き URL パターン](/ja/5.2/topics/http/urls/#naming-url-patterns) です。 ### `LOGOUT_REDIRECT_URL` デフォルト値: `None` リクエストがログアウト後にリダイレクトされるURLまたは [名前付きURLパターン](/ja/5.2/topics/http/urls/#naming-url-patterns) で、 [`LogoutView`](/ja/5.2/topics/auth/default/#django.contrib.auth.views.LogoutView) が `next_page` 属性を持っていない場合に使用されます。 `None` の場合、リダイレクトは行われず、ログアウトビューがレンダリングされます。 ### `PASSWORD_RESET_TIMEOUT` デフォルト値: `259200` (秒単位で、3日) パスワードリセットリンクの有効期間 (秒単位)。 [`PasswordResetConfirmView`](/ja/5.2/topics/auth/default/#django.contrib.auth.views.PasswordResetConfirmView) によって使用されます。 > **Note** > > このタイムアウトの値を減らしても、攻撃者がパスワードリセットトークンをブルートフォース（総当たり攻撃）で解読する能力には何の違いもありません。トークンは、タイムアウトなしでブルートフォースから安全であるように設計されています。 > > このタイムアウトは、例えば古く使われていないパスワードリセットトークンを含む可能性のあるメールアーカイブに誰かがアクセスを得るなど、考えにくい攻撃シナリオに対して保護するために存在します。 ### `PASSWORD_HASHERS` 関連項目: [Djangoのパスワード保存方法](/ja/5.2/topics/auth/passwords/#auth-password-storage) デフォルト値: ``` [ "django.contrib.auth.hashers.PBKDF2PasswordHasher", "django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher", "django.contrib.auth.hashers.Argon2PasswordHasher", "django.contrib.auth.hashers.BCryptSHA256PasswordHasher", "django.contrib.auth.hashers.ScryptPasswordHasher", ] ``` ### `AUTH_PASSWORD_VALIDATORS` デフォルト値: `[]` (空のリスト) ユーザーのパスワードの強度をチェックするために使用されるバリデータのリストです。詳細については [パスワードの妥当性検証](/ja/5.2/topics/auth/passwords/#password-validation) を参照してください。デフォルトでは、バリデーションは実行されず、すべてのパスワードが受け入れられます。 ## メッセージ [`django.contrib.messages`](/ja/5.2/ref/contrib/messages/#module-django.contrib.messages) の設定。 ### `MESSAGE_LEVEL` デフォルト値: `messages.INFO` メッセージフレームワークによって記録されるメッセージレベルの最小値を設定します。 詳細については、 [メッセージレベル](/ja/5.2/ref/contrib/messages/#message-level) を参照してください。 > **循環インポートの回避** > > 設定ファイルで `MESSAGE_LEVEL` をオーバーライドし、組み込み定数に依存する場合は、循環インポートの可能性を避けるために、定数モジュールを直接インポートする必要があります。例えば: > > ``` > from django.contrib.messages import constants as message_constants > > MESSAGE_LEVEL = message_constants.DEBUG > ``` > > 必要であれば、上記の [定数表](/ja/5.2/ref/contrib/messages/#message-level-constants) にある値に従って、定数の数値を直接指定できます。 ### `MESSAGE_STORAGE` デフォルト値: `'django.contrib.messages.storage.fallback.FallbackStorage'` Django がメッセージデータをどこに保存するかを制御します。有効な値は次の通りです: - `'django.contrib.messages.storage.fallback.FallbackStorage'` - `'django.contrib.messages.storage.session.SessionStorage'` - `'django.contrib.messages.storage.cookie.CookieStorage'` 詳細については、 [メッセージストレージバックエンド](/ja/5.2/ref/contrib/messages/#message-storage-backends) を参照してください。 Cookieを使用するバックエンド -- [`CookieStorage`](/ja/5.2/ref/contrib/messages/#django.contrib.messages.storage.cookie.CookieStorage) および [`FallbackStorage`](/ja/5.2/ref/contrib/messages/#django.contrib.messages.storage.fallback.FallbackStorage) -- は、クッキーを設定する際に [`SESSION_COOKIE_DOMAIN`](#std-setting-SESSION_COOKIE_DOMAIN), [`SESSION_COOKIE_SECURE`](#std-setting-SESSION_COOKIE_SECURE), [`SESSION_COOKIE_HTTPONLY`](#std-setting-SESSION_COOKIE_HTTPONLY) の値を使用します。 ### `MESSAGE_TAGS` デフォルト値: ``` { messages.DEBUG: "debug", messages.INFO: "info", messages.SUCCESS: "success", messages.WARNING: "warning", messages.ERROR: "error", } ``` これは、メッセージレベルとHTMLで通常CSSクラスとしてレンダリングされるメッセージタグのマッピングを設定します。値を指定すると、デフォルトを拡張します。つまり、オーバーライドする必要がある値のみを指定すればよいことを意味します。詳細については、上記の [メッセージを表示する](/ja/5.2/ref/contrib/messages/#message-displaying) を参照してください。 > **循環インポートの回避** > > 設定ファイルで `MESSAGE_TAGS` を上書きし、組み込み定数に依存する場合、循環インポートの可能性を避けるために、 `constants` モジュールを直接インポートする必要があります。例えば: > > ``` > from django.contrib.messages import constants as message_constants > > MESSAGE_TAGS = {message_constants.INFO: ""} > ``` > > 必要であれば、上記の [定数表](/ja/5.2/ref/contrib/messages/#message-level-constants) にある値に従って、定数の数値を直接指定できます。 ## セッション [`django.contrib.sessions`](/ja/5.2/topics/http/sessions/#module-django.contrib.sessions) の設定。 ### `SESSION_CACHE_ALIAS` デフォルト値: `'default'` [キャッシュベースのセッションストレージ](/ja/5.2/topics/http/sessions/#cached-sessions-backend) を使用している場合、これによって使用するキャッシュが選択されます。 ### `SESSION_COOKIE_AGE` デフォルト値: `1209600` (2 週間の秒表記) セッションクッキーの寿命 (秒単位)。 ### `SESSION_COOKIE_DOMAIN` デフォルト値: `None` セッションクッキーに使用するドメインです。クロスドメインクッキーの場合は `"example.com"` のような文字列に設定するか、標準ドメインクッキーには `None` を使用してください。 [`CSRF_USE_SESSIONS`](#std-setting-CSRF_USE_SESSIONS) を使用してクロスドメインのクッキーを使用する場合、CSRFミドルウェアのリファラチェックを受け入れるために、先頭にドット (例: `".example.com"`) を含めなければなりません。 本番サイトでこの設定を更新する場合は慎重に行ってください。以前は標準ドメインのクッキーを使用していたサイトでこの設定を更新してクロスドメインのクッキーを有効にした場合、既存のユーザークッキーは古いドメインに設定されます。これにより、これらのクッキーが存在する限り、ログインできなくなる可能性があります。 この設定は、 [`django.contrib.messages`](/ja/5.2/ref/contrib/messages/#module-django.contrib.messages) によって設定されるクッキーにも影響します。 ### `SESSION_COOKIE_HTTPONLY` デフォルト値: `True` セッションクッキーに `HttpOnly` フラグを使用するかどうか。これが `True` に設定されている場合、クライアント側の JavaScript はセッションクッキーにアクセスできません。 [HttpOnly](https://owasp.org/www-community/HttpOnly) は Set-Cookie HTTPレスポンスヘッダーに含まれるフラグです。クッキーのための [**RFC 6265 Section 4.1.2.6**](https://datatracker.ietf.org/doc/html/rfc6265.html#section-4.1.2.6) 標準の一部であり、クライアントサイドのスクリプトが保護されたクッキーデータにアクセスするリスクを軽減する有用な方法です。 これにより、攻撃者がクロスサイトスクリプティングの脆弱性を利用してユーザーのセッションを完全に乗っ取ることが困難になります。これをオフにする正当な理由はほとんどありません。コードは JavaScript からセッションクッキーを読み取るべきではありません。 ### `SESSION_COOKIE_NAME` デフォルト値: `'sessionid'` セッションに使用するクッキーの名前です。これはあなたが望むものであれば何でも構いません（ただし、アプリケーション内の他のクッキー名と異なる必要があります）。 ### `SESSION_COOKIE_PATH` デフォルト値: `'/'` セッションクッキーに設定されたパス。これは、DjangoインストールのURLパスと一致するか、そのパスの親であるべきです。 これは、同じホスト名の下で複数の Django インスタンスが実行されている場合に便利です。異なるクッキーパスを使用でき、各インスタンスは自身のセッションクッキーのみを確認できます。 ### `SESSION_COOKIE_SAMESITE` デフォルト値: `'Lax'` セッションクッキーの [SameSite](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#samesitesamesite-value) フラグの値。このフラグは、クロスサイトリクエストでクッキーが送信されるのを防ぎ、CSRF攻撃を防ぎ、セッションクッキーを盗むいくつかの方法を不可能にします。 設定で指定できる値は次のとおりです: - `'Strict'`: ブラウザが全てのクロスサイトブラウジングコンテキストにおいて、通常のリンクをたどる場合であっても、ターゲットサイトへクッキーを送信することを防ぎます。 例えば、GitHubのようなウェブサイトでは、ログインしたユーザーが企業のディスカッションフォーラムやメールに掲載された非公開のGitHubプロジェクトへのリンクをたどる場合、GitHubはセッションクッキーを受け取らず、ユーザーはそのプロジェクトにアクセスできなくなります。一方、銀行のウェブサイトでは、おそらく外部サイトからの取引ページへのリンクを許可したくないため、 `'Strict'` フラグが適切でしょう。 - `'Lax'` (デフォルト): 外部リンクからユーザーが訪れた後でも、ユーザーのログイン状態を維持したいウェブサイトに対して、セキュリティと利便性のバランスを提供します。 GitHub のシナリオでは、外部ウェブサイトから通常のリンクをたどる際にはセッションクッキーが許可され、CSRFに対して脆弱なリクエストメソッド (例: `POST`) ではブロックされます。 - `'None'` (文字列): セッションクッキーは、同一サイトおよびクロスサイトの全てのリクエストに対して送信されます。 - `False`: フラグを無効にします。 > **Note** > > モダンブラウザは、明示的な値が設定されていないクッキーについて、`SameSite` フラグに対してより安全なデフォルトポリシーである `Lax` を適用します。 ### `SESSION_COOKIE_SECURE` デフォルト値: `False` セッションクッキーにセキュアクッキーを使用するかどうかです。これが `True` に設定されている場合、クッキーは「セキュア」にマークされ、ブラウザはそのクッキーが HTTPS 接続下でのみ送信されることを保証するかもしれません。 この設定をオフにしておくことは良いアイデアではありません。なぜなら、攻撃者がパケットスニファーで暗号化されていないセッションクッキーをキャプチャし、そのクッキーを使用してユーザーのセッションを乗っ取る可能性があるからです。 ### `SESSION_ENGINE` デフォルト値: `'django.contrib.sessions.backends.db'` Djangoがセッションデータを保存する場所を制御します。含まれているエンジンには、以下があります: - `'django.contrib.sessions.backends.db'` - `'django.contrib.sessions.backends.file'` - `'django.contrib.sessions.backends.cache'` - `'django.contrib.sessions.backends.cached_db'` - `'django.contrib.sessions.backends.signed_cookies'` 詳細は [セッションエンジンを設定する](/ja/5.2/topics/http/sessions/#configuring-sessions) を参照してください。 ### `SESSION_EXPIRE_AT_BROWSER_CLOSE` デフォルト値: `False` ユーザーがブラウザを閉じたときにセッションを終了させるかどうか。 [ブラウザ起動中のみ有効なセッション vs. 永続的なセッション](/ja/5.2/topics/http/sessions/#browser-length-vs-persistent-sessions) を参照してください。 ### `SESSION_FILE_PATH` デフォルト値: `None` ファイルベースのセッションストレージを使用している場合、この設定は Django がセッションデータを格納するディレクトリを設定します。デフォルト値 (`None`) が使用される場合、Django はシステムの標準的な一時ディレクトリを使用します。 ### `SESSION_SAVE_EVERY_REQUEST` デフォルト値: `False` すべてのリクエストにおいてセッションデータを保存するかどうか。これが `False` (デフォルト) の場合、セッションデータは変更された場合にのみ保存されます。つまり、その辞書の値に何らかの代入や削除が行われた場合です。この設定が有効であっても、空のセッションは作成されません。 ### `SESSION_SERIALIZER` デフォルト値: `'django.contrib.sessions.serializers.JSONSerializer'` セッションデータのシリアライズに使用するシリアライザクラスの完全なインポートパスです。含まれているシリアライザは次のとおりです: - `'django.contrib.sessions.serializers.JSONSerializer'` 詳細については、 [セッションのシリアライズ](/ja/5.2/topics/http/sessions/#session-serialization) を参照してください。 ## サイト [`django.contrib.sites`](/ja/5.2/ref/contrib/sites/#module-django.contrib.sites) の設定。 ### `SITE_ID` デフォルト値: 定義されていません `django_site` データベーステーブルの現在のサイトの ID（整数）です。これを使用することで、アプリケーションデータが特定のサイトにフックでき、単一のデータベースで複数のサイトのコンテンツを管理できます。 ## 静的ファイル [`django.contrib.staticfiles`](/ja/5.2/ref/contrib/staticfiles/#module-django.contrib.staticfiles) の設定。 ### `STATIC_ROOT` デフォルト値: `None` [`collectstatic`](/ja/5.2/ref/contrib/staticfiles/#django-admin-collectstatic) がデプロイメント用に静的ファイルを収集するディレクトリの絶対パスです。 例: `"/var/www/example.com/static/"` [staticfiles](/ja/5.2/ref/contrib/staticfiles/) contrib アプリが有効になっている場合（デフォルトのプロジェクトテンプレートにあるように）、 [`collectstatic`](/ja/5.2/ref/contrib/staticfiles/#django-admin-collectstatic) 管理コマンドは静的ファイルをこのディレクトリに収集します。使用法についての詳細は、 [静的ファイルの管理](/ja/5.2/howto/static-files/) のHow-toをご覧ください。 > **Warning** > > これは、永続的な場所から静的ファイルを一つのディレクトリに集めて、デプロイを容易にするための最初は空の宛先ディレクトリであることに注意してください。これは、静的ファイルを永続的に保存する場所 **ではありません** 。静的ファイルを永続的に保存するためには、 [staticfiles](/ja/5.2/ref/contrib/staticfiles/) の [`finders`](#std-setting-STATICFILES_FINDERS) によって見つかるディレクトリ（デフォルトでは、`'static/'` アプリサブディレクトリと、[`STATICFILES_DIRS`](#std-setting-STATICFILES_DIRS) で含めた任意のディレクトリ）に保存してください。 ### `STATIC_URL` デフォルト値: `None` [`STATIC_ROOT`](#std-setting-STATIC_ROOT) に位置する静的ファイルを参照する際に使用する URL。 例: `"static/"` または `"https://static.example.com/"` `None` でない場合、これは [アセット定義](/ja/5.2/topics/forms/media/#form-asset-paths) (`Media` クラス) および [staticfiles アプリ](/ja/5.2/ref/contrib/staticfiles/) において基本パスとして使用されます。 空でない値に設定されている場合、スラッシュで終わらなければなりません。 これらのファイルを開発環境で提供するためには [設定が必要になるかもしれません](/ja/5.2/howto/static-files/#serving-static-files-in-development) し、本番環境では間違いなくそうする必要があります [本番環境](/ja/5.2/howto/static-files/deployment/) 。 > **Note** > > [`STATIC_URL`](#std-setting-STATIC_URL) が相対パスの場合、サーバーが提供する `SCRIPT_NAME` の値（設定されていない場合は `/`）によってプレフィックスが付けられます。これにより、追加の設定を settings に追加することなく、Django アプリケーションをサブパスで提供することが簡単になります。 ### `STATICFILES_DIRS` デフォルト値: `[]` (空のリスト) この設定は `FileSystemFinder` のファインダーが有効になっている場合に staticfiles アプリが通過する追加の場所を定義します。たとえば、[`collectstatic`](/ja/5.2/ref/contrib/staticfiles/#django-admin-collectstatic) や [`findstatic`](/ja/5.2/ref/contrib/staticfiles/#django-admin-findstatic) 管理コマンドを使用している場合や、 静的ファイル提供ビューを使用している場合などです。 これは、追加のファイルディレクトリへのフルパスを含む文字列のリストに設定する必要があります。例: ``` STATICFILES_DIRS = [ "/home/special.polls.com/polls/static", "/home/polls.com/polls/static", "/opt/webfiles/common", ] ``` これらのパスは、WindowsでもUnixスタイルのスラッシュを使用する必要があることに注意してください（例： `"C:/Users/user/mysite/extra_static_content"` ）。 #### プレフィックス(オプション) 追加の名前空間である場所の一つを参照したい場合、 **オプションで** `(prefix, path)` の形のタプルとしてプレフィックスを提供できます。例えば: ``` STATICFILES_DIRS = [ # ... ("downloads", "/opt/webfiles/stats"), ] ``` たとえば、[`STATIC_URL`](#std-setting-STATIC_URL) を `'static/'` に設定しているとします。この場合、 [`collectstatic`](/ja/5.2/ref/contrib/staticfiles/#django-admin-collectstatic) 管理コマンドは、 [`STATIC_ROOT`](#std-setting-STATIC_ROOT) の `'downloads'` サブディレクトリ内の "stats" ファイルを収集します。 これにより、テンプレート内でローカルファイル `'/opt/webfiles/stats/polls_20101022.tar.gz'` を `'/static/downloads/polls_20101022.tar.gz'` として参照できるようになります。例えば： ```html+django ``` ### `STATICFILES_FINDERS` デフォルト値: ``` [ "django.contrib.staticfiles.finders.FileSystemFinder", "django.contrib.staticfiles.finders.AppDirectoriesFinder", ] ``` 様々な場所にある静的ファイルを見つける方法を知っているファインダーバックエンドのリストです。 デフォルトでは、 [`STATICFILES_DIRS`](#std-setting-STATICFILES_DIRS) 設定で指定された場所に保存されているファイル（ `django.contrib.staticfiles.finders.FileSystemFinder` を使用して）と、各アプリの `static` サブディレクトリにあるファイル（ `django.contrib.staticfiles.finders.AppDirectoriesFinder` を使用して）を見つけます。同じ名前のファイルが複数存在する場合、最初に見つかったファイルが使用されます。 デフォルトで無効になっているファインダーが 1 つあります: `django.contrib.staticfiles.finders.DefaultStorageFinder` 。これを [`STATICFILES_FINDERS`](#std-setting-STATICFILES_FINDERS) 設定に追加すると、 [`STORAGES`](#std-setting-STORAGES) 設定の `default` キーで定義されたデフォルトファイルストレージ内の静的ファイルを探します。 > **Note** > > `AppDirectoriesFinder` ファインダーを使用する場合、サイトの [`INSTALLED_APPS`](#std-setting-INSTALLED_APPS) 設定にアプリを追加して、staticfiles によってアプリが見つけられるようにしてください。 静的ファイルファインダーは現在、プライベートインターフェースとみなされており、このインターフェースはドキュメント化されていません。 ## コア設定 トピック別インデックス ### キャッシュ - [`CACHES`](#std-setting-CACHES) - [`CACHE_MIDDLEWARE_ALIAS`](#std-setting-CACHE_MIDDLEWARE_ALIAS) - [`CACHE_MIDDLEWARE_KEY_PREFIX`](#std-setting-CACHE_MIDDLEWARE_KEY_PREFIX) - [`CACHE_MIDDLEWARE_SECONDS`](#std-setting-CACHE_MIDDLEWARE_SECONDS) ### データベース - [`DATABASES`](#std-setting-DATABASES) - [`DATABASE_ROUTERS`](#std-setting-DATABASE_ROUTERS) - [`DEFAULT_INDEX_TABLESPACE`](#std-setting-DEFAULT_INDEX_TABLESPACE) - [`DEFAULT_TABLESPACE`](#std-setting-DEFAULT_TABLESPACE) ### デバッグ - [`DEBUG`](#std-setting-DEBUG) - [`DEBUG_PROPAGATE_EXCEPTIONS`](#std-setting-DEBUG_PROPAGATE_EXCEPTIONS) ### Eメール - [`ADMINS`](#std-setting-ADMINS) - [`DEFAULT_CHARSET`](#std-setting-DEFAULT_CHARSET) - [`DEFAULT_FROM_EMAIL`](#std-setting-DEFAULT_FROM_EMAIL) - [`EMAIL_BACKEND`](#std-setting-EMAIL_BACKEND) - [`EMAIL_FILE_PATH`](#std-setting-EMAIL_FILE_PATH) - [`EMAIL_HOST`](#std-setting-EMAIL_HOST) - [`EMAIL_HOST_PASSWORD`](#std-setting-EMAIL_HOST_PASSWORD) - [`EMAIL_HOST_USER`](#std-setting-EMAIL_HOST_USER) - [`EMAIL_PORT`](#std-setting-EMAIL_PORT) - [`EMAIL_SSL_CERTFILE`](#std-setting-EMAIL_SSL_CERTFILE) - [`EMAIL_SSL_KEYFILE`](#std-setting-EMAIL_SSL_KEYFILE) - [`EMAIL_SUBJECT_PREFIX`](#std-setting-EMAIL_SUBJECT_PREFIX) - [`EMAIL_TIMEOUT`](#std-setting-EMAIL_TIMEOUT) - [`EMAIL_USE_LOCALTIME`](#std-setting-EMAIL_USE_LOCALTIME) - [`EMAIL_USE_SSL`](#std-setting-EMAIL_USE_SSL) - [`EMAIL_USE_TLS`](#std-setting-EMAIL_USE_TLS) - [`MANAGERS`](#std-setting-MANAGERS) - [`SERVER_EMAIL`](#std-setting-SERVER_EMAIL) ### エラーのレポート - [`DEFAULT_EXCEPTION_REPORTER`](#std-setting-DEFAULT_EXCEPTION_REPORTER) - [`DEFAULT_EXCEPTION_REPORTER_FILTER`](#std-setting-DEFAULT_EXCEPTION_REPORTER_FILTER) - [`IGNORABLE_404_URLS`](#std-setting-IGNORABLE_404_URLS) - [`MANAGERS`](#std-setting-MANAGERS) - [`SILENCED_SYSTEM_CHECKS`](#std-setting-SILENCED_SYSTEM_CHECKS) ### ファイルアップロード - [`FILE_UPLOAD_HANDLERS`](#std-setting-FILE_UPLOAD_HANDLERS) - [`FILE_UPLOAD_MAX_MEMORY_SIZE`](#std-setting-FILE_UPLOAD_MAX_MEMORY_SIZE) - [`FILE_UPLOAD_PERMISSIONS`](#std-setting-FILE_UPLOAD_PERMISSIONS) - [`FILE_UPLOAD_TEMP_DIR`](#std-setting-FILE_UPLOAD_TEMP_DIR) - [`MEDIA_ROOT`](#std-setting-MEDIA_ROOT) - [`MEDIA_URL`](#std-setting-MEDIA_URL) - [`STORAGES`](#std-setting-STORAGES) ### フォーム - [`FORM_RENDERER`](#std-setting-FORM_RENDERER) - [`FORMS_URLFIELD_ASSUME_HTTPS`](#std-setting-FORMS_URLFIELD_ASSUME_HTTPS) ### グローバル化 (`i18n`/`l10n`) #### 国際化 (`i18n`) - [`FIRST_DAY_OF_WEEK`](#std-setting-FIRST_DAY_OF_WEEK) - [`FORMAT_MODULE_PATH`](#std-setting-FORMAT_MODULE_PATH) - [`LANGUAGE_COOKIE_AGE`](#std-setting-LANGUAGE_COOKIE_AGE) - [`LANGUAGE_COOKIE_DOMAIN`](#std-setting-LANGUAGE_COOKIE_DOMAIN) - [`LANGUAGE_COOKIE_HTTPONLY`](#std-setting-LANGUAGE_COOKIE_HTTPONLY) - [`LANGUAGE_COOKIE_NAME`](#std-setting-LANGUAGE_COOKIE_NAME) - [`LANGUAGE_COOKIE_PATH`](#std-setting-LANGUAGE_COOKIE_PATH) - [`LANGUAGE_COOKIE_SAMESITE`](#std-setting-LANGUAGE_COOKIE_SAMESITE) - [`LANGUAGE_COOKIE_SECURE`](#std-setting-LANGUAGE_COOKIE_SECURE) - [`LANGUAGES`](#std-setting-LANGUAGES) - [`LANGUAGES_BIDI`](#std-setting-LANGUAGES_BIDI) - [`LOCALE_PATHS`](#std-setting-LOCALE_PATHS) - [`TIME_ZONE`](#std-setting-TIME_ZONE) - [`USE_I18N`](#std-setting-USE_I18N) - [`USE_TZ`](#std-setting-USE_TZ) #### ローカライズ (`l10n`) - [`DATE_FORMAT`](#std-setting-DATE_FORMAT) - [`DATE_INPUT_FORMATS`](#std-setting-DATE_INPUT_FORMATS) - [`DATETIME_FORMAT`](#std-setting-DATETIME_FORMAT) - [`DATETIME_INPUT_FORMATS`](#std-setting-DATETIME_INPUT_FORMATS) - [`DECIMAL_SEPARATOR`](#std-setting-DECIMAL_SEPARATOR) - [`LANGUAGE_CODE`](#std-setting-LANGUAGE_CODE) - [`MONTH_DAY_FORMAT`](#std-setting-MONTH_DAY_FORMAT) - [`NUMBER_GROUPING`](#std-setting-NUMBER_GROUPING) - [`SHORT_DATE_FORMAT`](#std-setting-SHORT_DATE_FORMAT) - [`SHORT_DATETIME_FORMAT`](#std-setting-SHORT_DATETIME_FORMAT) - [`THOUSAND_SEPARATOR`](#std-setting-THOUSAND_SEPARATOR) - [`TIME_FORMAT`](#std-setting-TIME_FORMAT) - [`TIME_INPUT_FORMATS`](#std-setting-TIME_INPUT_FORMATS) - [`USE_THOUSAND_SEPARATOR`](#std-setting-USE_THOUSAND_SEPARATOR) - [`YEAR_MONTH_FORMAT`](#std-setting-YEAR_MONTH_FORMAT) ### HTTP - [`DATA_UPLOAD_MAX_MEMORY_SIZE`](#std-setting-DATA_UPLOAD_MAX_MEMORY_SIZE) - [`DATA_UPLOAD_MAX_NUMBER_FIELDS`](#std-setting-DATA_UPLOAD_MAX_NUMBER_FIELDS) - [`DATA_UPLOAD_MAX_NUMBER_FILES`](#std-setting-DATA_UPLOAD_MAX_NUMBER_FILES) - [`DEFAULT_CHARSET`](#std-setting-DEFAULT_CHARSET) - [`DISALLOWED_USER_AGENTS`](#std-setting-DISALLOWED_USER_AGENTS) - [`FORCE_SCRIPT_NAME`](#std-setting-FORCE_SCRIPT_NAME) - [`INTERNAL_IPS`](#std-setting-INTERNAL_IPS) - [`MIDDLEWARE`](#std-setting-MIDDLEWARE) - セキュリティ - [`SECURE_CONTENT_TYPE_NOSNIFF`](#std-setting-SECURE_CONTENT_TYPE_NOSNIFF) - [`SECURE_CROSS_ORIGIN_OPENER_POLICY`](#std-setting-SECURE_CROSS_ORIGIN_OPENER_POLICY) - [`SECURE_HSTS_INCLUDE_SUBDOMAINS`](#std-setting-SECURE_HSTS_INCLUDE_SUBDOMAINS) - [`SECURE_HSTS_PRELOAD`](#std-setting-SECURE_HSTS_PRELOAD) - [`SECURE_HSTS_SECONDS`](#std-setting-SECURE_HSTS_SECONDS) - [`SECURE_PROXY_SSL_HEADER`](#std-setting-SECURE_PROXY_SSL_HEADER) - [`SECURE_REDIRECT_EXEMPT`](#std-setting-SECURE_REDIRECT_EXEMPT) - [`SECURE_REFERRER_POLICY`](#std-setting-SECURE_REFERRER_POLICY) - [`SECURE_SSL_HOST`](#std-setting-SECURE_SSL_HOST) - [`SECURE_SSL_REDIRECT`](#std-setting-SECURE_SSL_REDIRECT) - [`SIGNED_COOKIE_LEGACY_SALT_FALLBACK`](#std-setting-SIGNED_COOKIE_LEGACY_SALT_FALLBACK) - [`SIGNING_BACKEND`](#std-setting-SIGNING_BACKEND) - [`USE_X_FORWARDED_HOST`](#std-setting-USE_X_FORWARDED_HOST) - [`USE_X_FORWARDED_PORT`](#std-setting-USE_X_FORWARDED_PORT) - [`WSGI_APPLICATION`](#std-setting-WSGI_APPLICATION) ### ロギング - [`LOGGING`](#std-setting-LOGGING) - [`LOGGING_CONFIG`](#std-setting-LOGGING_CONFIG) ### モデル - [`ABSOLUTE_URL_OVERRIDES`](#std-setting-ABSOLUTE_URL_OVERRIDES) - [`FIXTURE_DIRS`](#std-setting-FIXTURE_DIRS) - [`INSTALLED_APPS`](#std-setting-INSTALLED_APPS) ### セキュリティ - クロスサイトリクエストフォージェリ (CSRF) 保護 - [`CSRF_COOKIE_DOMAIN`](#std-setting-CSRF_COOKIE_DOMAIN) - [`CSRF_COOKIE_NAME`](#std-setting-CSRF_COOKIE_NAME) - [`CSRF_COOKIE_PATH`](#std-setting-CSRF_COOKIE_PATH) - [`CSRF_COOKIE_SAMESITE`](#std-setting-CSRF_COOKIE_SAMESITE) - [`CSRF_COOKIE_SECURE`](#std-setting-CSRF_COOKIE_SECURE) - [`CSRF_FAILURE_VIEW`](#std-setting-CSRF_FAILURE_VIEW) - [`CSRF_HEADER_NAME`](#std-setting-CSRF_HEADER_NAME) - [`CSRF_TRUSTED_ORIGINS`](#std-setting-CSRF_TRUSTED_ORIGINS) - [`CSRF_USE_SESSIONS`](#std-setting-CSRF_USE_SESSIONS) - [`SECRET_KEY`](#std-setting-SECRET_KEY) - [`SECRET_KEY_FALLBACKS`](#std-setting-SECRET_KEY_FALLBACKS) - [`X_FRAME_OPTIONS`](#std-setting-X_FRAME_OPTIONS) ### シリアライズ - [`DEFAULT_CHARSET`](#std-setting-DEFAULT_CHARSET) - [`SERIALIZATION_MODULES`](#std-setting-SERIALIZATION_MODULES) ### テンプレート - [`TEMPLATES`](#std-setting-TEMPLATES) ### テスト - データベース: [`テスト`](#std-setting-DATABASE-TEST) - [`TEST_NON_SERIALIZED_APPS`](#std-setting-TEST_NON_SERIALIZED_APPS) - [`TEST_RUNNER`](#std-setting-TEST_RUNNER) ### URL - [`APPEND_SLASH`](#std-setting-APPEND_SLASH) - [`PREPEND_WWW`](#std-setting-PREPEND_WWW) - [`ROOT_URLCONF`](#std-setting-ROOT_URLCONF)