# Django 5.0.9.dev20240806133106 ドキュメント

# システムチェックフレームワーク

システムチェックフレームワークは、Django プロジェクトを検証するための静的チェックのセットです。一般的な問題を検出し、それらを修正するヒントを提供します。このフレームワークは拡張性があり、独自のチェックを簡単に追加できます。

独自のチェックを追加し、Django のシステムチェックと統合する方法については、 システムチェックのトピックガイド を参照してください。

## API リファレンス

### `CheckMessage`

class `CheckMessage`(level, msg, hint=None, obj=None, id=None)

システムチェックで発生する警告やエラーは `CheckMessage` のインスタンスでなければなりません。インスタンスは1つの報告可能なエラーや警告をカプセル化します。また、メッセージに適用されるコンテキストとヒント、フィルタリングに使用される一意の識別子も提供します。

コンストラクタの引数は以下の通りです：

`level`
  メッセージの重大度。定義済みの値、 `debug`、 `info`、 `warning`、 `error`、 `critical` のいずれかを使用します。レベルが `ERROR` 以上の場合、Django は管理コマンドの実行を抑止します。レベルが `ERROR` より低いメッセージ (つまり警告) はコンソールに報告されますが、抑制することもできます。
`msg`
  問題を説明する短い (80 文字未満) 文字列。文字列には改行を含めてはいけません。
`hint`
  問題を解決するためのヒントを示す1行の文字列。ヒントを提供できない場合、またはヒントがエラーメッセージから明らかな場合は、ヒントを省略するか、 `None` を使用できます。
`obj`
  オプション。メッセージのコンテキストを提供するオブジェクト (例えば、問題が発見されたモデル)。オブジェクトはモデル、フィールド、マネージャ、または `__str__()` メソッドを定義する他のオブジェクトでなければなりません。このメソッドはすべてのメッセージを報告するときに使用され、その結果はメッセージの前に置かれます。
`id`
  オプションの文字列。issueの一意な識別子。識別子は `applabel.X001` というパターンに従うべきです。ここで `X` はメッセージの重大度を示す文字 `CEWID` のいずれかです（クリティカルは `C`、エラーは `E` など）。この番号はアプリケーションによって割り当てることができますが、アプリケーション内で一意である必要があります。

共通のレベルを持つメッセージを簡単に作成するためのサブクラスがあります。これらを使用する場合、引数 `level` は省略できます。

class `Debug`(msg, hint=None, obj=None, id=None)

class `Info`(msg, hint=None, obj=None, id=None)

class `Warning`(msg, hint=None obj=None, id=None)

class `Error`(msg, hint=None, obj=None, id=None)

class `Critical`(msg, hint=None, obj=None, id=None)

## 組み込みタグ

Django のシステムチェックは、以下のタグを使って整理されています：

- `admin`: admin サイトの宣言をチェックします。
- `async_support`: 非同期関連の設定をチェックします。
- `caches`: キャッシュ関連の設定をチェックします。
- `compatibility`: バージョンアップに伴う潜在的な問題にフラグを立てます。
- `database`: データベース関連の設定問題をチェックします。データベースチェックは通常のチェックのように静的なコード解析以上のことを行うため、デフォルトでは実行されません。 `migrate` コマンドを実行するか、 `check` コマンドを呼び出す際に `--database` オプションを使用して設定済みのデータベースエイリアスを指定した場合のみ実行されます。
- `files`: ファイル関連の設定をチェックします。
- `models`: モデル、フィールド、およびマネージャー定義をチェックします。
- `security`: セキュリティ関連の設定をチェックします。
- `signals`: シグナルの宣言とハンドラーの登録に関するチェックを行います。
- `sites`: `django.contrib.sites` の設定をチェックします。
- `staticfiles`: `django.contrib.staticfiles` の設定をチェックします。
- `templates`: テンプレート関連の設定をチェックします。
- `translation`: 翻訳関連の設定をチェックします。
- `urls`: URLの構成をチェックします。

いくつかのチェックは複数のタグで登録されていれる可能性があります。

## コアシステムチェック

### 非同期サポート

以下のチェックは、非同期サポート のセットアップを検証します。

- async.E001: 本番環境では、`DJANGO_ALLOW_ASYNC_UNSAFE` 環境変数を設定しないでください。これにより、 非同期安全性保護 が無効になります。

### 後方互換性

互換性チェックは、Django をアップグレードした後に起こりうる問題を警告します。

- 2_0.W001: URL パターン `<pattern>` の `route` に `(?P<` が含まれているか、 `^` で始まっているか、 `$` で終わっています。おそらく、`url()` から `path()` に移行する際の見落としです。
- 4_0.E001: Django 4.0 では、 `CSRF_TRUSTED_ORIGINS` 設定の値は通常 `http://` や `https://` のようなスキームで始まる必要がありますが、`<hostname>` が見つかりました。

### キャッシュ

以下のチェックでは、`CACHES` 設定が正しく構成されていることを確認します：

- caches.E001: `CACHES` 設定で `'default'` キャッシュを定義する必要があります。
- caches.W002: `<cache>` の設定が、キャッシュを公開したりデータの破損を招く可能性があります。なぜなら、その `LOCATION` が `MEDIA_ROOT`/`STATIC_ROOT`/`STATICFILES_DIRS` と一致するか含まれるからです。
- caches.W003: `<cache>` キャッシュの `LOCATION` が相対パスです。絶対パスを使用してください。

### データベース

#### MySQL と MariaDB

MySQLまたはMariaDBを使用している場合、以下のチェックが行われます：

- mysql.E001: MySQL/MariaDB では、ユニークな `CharField` の `max_length` を 255 より大きくすることはできません。このチェックは、実際の最大サイズが多くの要因に依存するため、Django 3.1 では `mysql.W003` に変更されました。
- mysql.W002: MySQL/MariaDB Strict Mode がデータベース接続 `<alias>` に設定されていません。 sql_mode の設定 も参照してください。
- mysql.W003: MySQL/MariaDBでは、一意な `CharField` の `max_length` が255を超えることが許可されていない場合があります。

### ファイルの管理

次のチェックは、 ファイルの管理 の設定を検証します。

- files.E001: `FILE_UPLOAD_TEMP_DIR` 設定は存在しないディレクトリ `<path>` を参照しています。

### モデルフィールド

- fields.E001: フィールド名はアンダースコアで終わってはいけません。
- fields.E002: フィールド名には `"__"` を含めることはできません。
- fields.E003: `pk` はフィールド名として使用できない予約語です。
- fields.E004: `choices` は、マッピング (例: 辞書) またはイテラブル (例: リストまたはタプル) でなければなりません。
- fields.E005: `choices` は実際の値と人間が読める名前のマッピング、または `(実際の値, 人間が読める名前)` タプルを含むイテラブルでなければなりません。
- fields.E006: `db_index` は `None`、`True`、`False` のいずれかでなければいけません。
- fields.E007: 主キーは `null=True` を持ってはいけません。
- fields.E008: すべての `validators` は呼び出し可能オブジェクトでなければなりません。
- fields.E009: `max_length` が小さすぎて `choices` の最長の値 (`<count>` 文字) を収めることができません。
- fields.E010: すべてのフィールドインスタンス間で共有されないように、`<field>` のデフォルトはインスタンスではなく呼び出し可能オブジェクトであるべきです。
- fields.E011: `<database>` は式 (`db_default`) を使ったデフォルトのデータベース値をサポートしていません。
- fields.E012: `<expression>` は `db_default` では使用できません。
- fields.E100: `AutoField` は primary_key=True を設定する必要があります。
- fields.E110: `BooleanField` はnull値を受け付けません。 このチェックは、Django 2.1でnull値をサポートする前に追加されました。
- fields.E120: `CharField` の場合、`max_length` 属性を定義する必要があります。
- fields.E121: `max_length` は正の整数でなければなりません。
- fields.W122: `max_length` は `<integer field type>` と一緒に使用した場合、無視されます。
- fields.E130: `DecimalField` は `decimal_places` 属性を定義しなければなりません。
- fields.E131: `decimal_places` は非負の整数でなければなりません。
- fields.E132: `DecimalField` は `max_digits` 属性を定義する必要があります。
- fields.E133: `max_digits` は正の整数でなければなりません。
- fields.E134: `max_digits` は `decimal_places` 以上でなければなりません。
- fields.E140: `FilePathField` は `allow_files` または `allow_folders` のどちらかを True に設定する必要があります。
- fields.E150: `GenericIPAddressField` は `null=False` の場合 `blank=True` にすることはできません。空白の値は null として保存されるためです。
- fields.E160: `auto_now`、`auto_now_add`、`default` オプションは互いに排他的です。これらのオプションは1つしか指定できません。
- fields.W161: 固定のデフォルト値が提供されました。
- fields.W162: `<database>` は `<field data type>` カラムにデータベースインデックスをサポートしていません。
- fields.W163: `<database>` では、列にコメント (`db_comment`) をサポートしていません。
- fields.E170: `BinaryField` の `default` に文字列を使用することはできません。代わりにバイトコンテンツを使用してください。
- fields.E180: `<database>` は `JSONField` をサポートしていません。
- fields.E190: `<database>` は `<field_type>` のデータベース照合順序 (collation) をサポートしていません。
- fields.E220: `<database>` は `GeneratedField` をサポートしていません。
- fields.E221: `<database>` は永続化されていない `GeneratedField` をサポートしていません。
- fields.E222: `<database>` は永続 `GeneratedField` をサポートしていません。
- fields.E223: `GeneratedField.output_field` に次のエラーがあります: ...
- fields.W224: `GeneratedField.output_field` に次の警告があります: ...
- fields.E900: `IPAddressField` は、履歴マイグレーションのサポートのために削除されました。
- fields.W900: `IPAddressField` は非推奨になりました。このフィールドのサポートは (履歴マイグレーションを除いて) Django 1.9 で削除されます。 このチェックは Django 1.7 と 1.8 で登場しました。
- fields.W901: `CommaSeparatedIntegerField` は非推奨になりました。Django 2.0 では (履歴マイグレーションを除いて) サポートがなくなります。 このチェックは Django 1.10 と 1.11 で登場しました。
- fields.E901: `CommaSeparatedIntegerField` は履歴マイグレーションでのサポートを除いて削除されました。
- fields.W902: `FloatRangeField` は非推奨で、Django 3.1 で削除されます。 このチェックは Django 2.2 と 3.0 で登場しました。
- fields.W903: `NullBooleanField` は非推奨です。Django 4.0 で (履歴マイグレーションを除いて) サポートが削除されます。 このチェックは Django 3.1 および 3.2 で登場しました。
- fields.E903: `NullBooleanField` は、履歴マイグレーションのサポートのために削除されました。
- fields.W904: `django.contrib.postgres.fields.JSONField` は非推奨です。Django 4.0 では (履歴マイグレーションを除いて) サポートがなくなります。このチェックは Django 3.1 と 3.2 で登場しました。
- fields.E904: `django.contrib.postgres.fields.JSONField` は履歴マイグレーションでのサポートを除いて削除されました。
- fields.W905: `django.contrib.postgres.fields.CICharField` は非推奨です。履歴マイグレーションを除いて、Django 5.1 でサポートが削除されます。
- fields.W906: `django.contrib.postgres.fields.CIEmailField` は非推奨です。Django 5.1 では、このフィールドのサポート (履歴マイグレーション以外) が削除されます。
- fields.W907: `django.contrib.postgres.fields.CITextField` は非推奨です。Django 5.1 では (履歴マイグレーションを除いて) サポートが削除されます。

#### ファイルフィールド

- fields.E200: `unique` は `FileField` の有効な引数ではありません。 このチェックは Django 1.11 で削除されました 。
- fields.E201: `primary_key` は `FileField` に対して有効な引数ではありません。
- fields.E202: `FileField` の `upload_to` 引数は絶対パスではなく、相対パスでなければなりません。
- fields.E210: Pillow がインストールされていないため、`ImageField` を使用できません。

#### 関連フィールド

- fields.E300: フィールドはモデル `<model>` とのリレーションを定義していますが、そのモデルはインストールされていないか、抽象です。
- fields.E301: フィールドは、スワップアウトされたモデル `<app_label>.<model>` とのリレーションを定義しています。
- fields.E302: `<app_label>.<model>.<field name>` の逆アクセサ `<related model>.<accessor name>` はフィールド名 `<app_label>.<model>.<field name>` と衝突します。
- fields.E303: `<app_label>.<model>.<field name>` の逆引きクエリ名が `<app_label>.<model>.<field name>` のフィールド名と衝突しています。
- fields.E304: 逆アクセサ `<related model>.<accessor name>` が `<app_label>.<model>.<field name>` の逆アクセサと衝突しています。
- fields.E305: `<app_label>.<model>.<field name>` の逆引きクエリ名が `<app_label>.<model>.<field name>` の逆引きクエリ名と衝突しました。
- fields.E306: 名前 `<name>` はフィールド `<model>.<field name>` の `related_name` として無効です。
- fields.E307: フィールド `<app label>.<model>.<field name>` は `<app label>.<model>` への遅延参照で宣言されましたが、アプリ `<app label>` がインストールされていないか、モデル `<model>` を提供していません。
- fields.E308: 逆引きクエリ名 `<related query name>` はアンダースコアで終わってはいけません。
- fields.E309: 逆向きクエリ名 `<related query name>` には `'__'` を含めることはできません。
- fields.E310: モデル `<model>` におけるフィールド `<field1>`, `<field2>`, ... のいずれのサブセットも一意ではありません。
- fields.E311: `<model>.<field name>` は `ForeignKey` によって参照されているため、一意でなければなりません。
- fields.E312: リレーション先モデル `<app label>.<model>` に存在しない `to_field` `<field name>` です。
- fields.E320: フィールドは `on_delete=SET_NULL` を指定していますが、null にはできません。
- fields.E321: フィールドには `on_delete=SET_DEFAULT` が指定されていますが、デフォルト値がありません。
- fields.E330: `ManyToManyField` をユニークにすることはできません。
- fields.E331: フィールドは、インストールされていないモデル `<model>` を介した多対多のリレーションを指定しています。
- fields.E332: 中間テーブルを持つ多対多のフィールドは対称であってはいけません。 このチェックは Django 3.0. 以前にもありました。
- fields.E333: このモデルは `<model>` の中間モデルとして使われますが、 `<model>` への外部キーが 2 つ以上あり、曖昧です。キーワード引数 `through_fields` を使って、 Django がどの外部キーを使うかを指定しなければなりません。
- fields.E334: このモデルは `<model>` によって中間モデルとして使われますが、 `<model>` からの外部キーが複数あり、曖昧です。キーワード引数 `through_fields` を使って、 Django がどの外部キーを使うかを指定する必要があります。
- fields.E335: このモデルは `<model>` の中間モデルとして使われていますが、 `<model>` への外部キーが複数あり、曖昧です。キーワード引数 `through_fields` を使って、 Django がどの外部キーを使うかを指定する必要があります。
- fields.E336: モデルは `<model>` の中間モデルとして使用されていますが、 `<model>` または `<model>` への外部キーを持っていません。
- fields.E337: フィールドは `through_fields` を指定していますが、`<model>` を介したリレーションに使用する 2 つのリンクフィールドの名前を指定していません。
- fields.E338: 中間モデル `<through model>` に `<field name>` というフィールドがありません。
- fields.E339: `<model>.<field name>` は `<model>` の外部キーではありません。
- fields.E340: フィールドの中間テーブル `<table name>` が、 `<model>`/`<model>.<field name>` のテーブル名と衝突しています。
- fields.W340: `null` は `ManyToManyField` には影響しません。
- fields.W341: `ManyToManyField` は `validators` をサポートしていません。
- fields.W342: `ForeignKey` に `unique=True` を設定すると、`OneToOneField` を使用したのと同じ効果があります。
- fields.W343: `limit_choices_to` は `through` モデルを持つ `ManyToManyField` には影響しません。 このチェックは Django 4.0 より前に登場しました。
- fields.W344: フィールドの中間テーブル `<table name>` が `<model>`/`<model>.<field name>` のテーブル名と衝突しています。
- fields.W345: `related_name` は、"self" のような対称なリレーションシップを持つ `ManyToManyField` に対しては効果がありません。
- fields.W346: `db_comment` は `ManyToManyField` に影響を与えません。

### モデル

- models.E001: `<swappable>` が `app_label.app_name` の形式ではありません。
- models.E002: `<SETTING>` は `<model>` を参照していますが、インストールされていないか抽象的です。
- models.E003: モデルには、中間モデル `<app_label>.<model>` を介した同一の多対多のリレーションが 2 つあります。
- models.E004: `id` はフィールドに `primary_key=True` を設定している場合のみフィールド名として使用できます。
- models.E005: 親モデル `<model>` のフィールド `<field name>` は、親モデル `<model>` のフィールド `<field name>` と衝突します。
- models.E006: フィールド `<field name>` はモデル `<model>` のフィールド `<field name>` と衝突しています。
- models.E007: フィールド `<field name>` は他のフィールドで使用されている列名 `<column name>` を持っています。
- models.E008: `index_together` はリストまたはタプルでなければなりません。
- models.E009: すべての `index_together` 要素はリストまたはタプルでなければなりません。
- models.E010: `unique_together` はリストまたはタプルでなければなりません。
- models.E011: すべての `unique_together` 要素はリストまたはタプルでなければなりません。
- models.E012: `constraints/indexes/index_together/unique_together` は存在しないフィールド `<field name>` を参照しています。
- models.E013: `constraints/indexes/index_together/unique_together` は `ManyToManyField` `<field name>` を参照していますが、`ManyToManyField` はそのオプションでサポートされていません。
- models.E014: `ordering` はタプルかリストでなければなりません (1つのフィールドだけで並び替えたい場合でも) 。
- models.E015: `ordering` は存在しないフィールド、リレーション先フィールド、またはルックアップ `<field name>` を指しています。
- models.E016: `constraints/indexes/index_together/unique_together` は、モデル `<model>` に属していないフィールド `<field_name>` を参照しています。
- models.E017: プロキシモデル `<model>` にモデルのフィールドが含まれています。
- models.E018: フィールド `<field>` に対して自動生成される列名が長すぎます。データベース `<alias>` の最大長は `<maximum length>` です。
- models.E019: M2M フィールド `<M2M field>` に対して自動生成されるカラム名が長すぎます。データベース `<alias>` の最大長は `<maximum length>` です。
- models.E020: `<model>.check()` クラスメソッドは現在オーバーライドされています。
- models.E021: `ordering` と `order_with_respect_to` は同時に使用できません。
- models.E022: `<function>` は `<app label>.<model>` への遅延参照を含んでいますが、アプリ `<app label>` がインストールされていないか、モデル `<model>` を提供していません。
- models.E023: モデル名 `<model>` はアンダースコアで始まるか終わることはできません。これはクエリルックアップの構文と衝突するためです。
- models.E024: モデル名 `<model>` には2重のアンダースコアを含めることはできません。これはクエリルックアップの構文と衝突するためです。
- models.E025: プロパティ `<property name>` はリレーション先フィールドのアクセサと衝突します。
- models.E026: モデルは `primary_key=True` を持つフィールドを複数持つことはできません。
- models.W027: `<database>` ではチェック制約がサポートされていません。
- models.E028: `db_table` `<db_table>` は複数のモデルで使用されています: `<model list>` 。
- models.E029: インデックス名 `<index>` がモデル `<model>` で一意ではありません。
- models.E030: インデックス名 `<index>` はモデルの中で一意ではありません: `<model list>` 。
- models.E031: モデル `<model>` に対して制約名 `<constraint>` が一意ではありません。
- models.E032: 制約名 `<constraint>` は、モデル間で一意ではありません: `<model list>` 。
- models.E033: インデックス名 `<index>` はアンダースコアまたは数字で始めることはできません。
- models.E034: インデックス名 `<index>` は `<max_length>` 文字を超えることはできません。
- models.W035: `db_table` `<db_table>` は複数のモデルで使用されています: `<model list>` 。
- models.W036: `<database>` は条件付きのユニーク制約をサポートしていません。
- models.W037: `<database>` では条件付きインデックスをサポートしていません。
- models.W038: `<database>` は、遅延可能 (deferrable) なユニーク制約をサポートしていません。
- models.W039: `<database>` は、非キーカラムでのユニーク制約をサポートしていません。
- models.W040: `<database>` は、非キーカラムを持つインデックスをサポートしていません。
- models.E041: `constraints` は、結合されたフィールド `<field name>` を参照しています。
- models.W042: 主キーの型を定義していないときは、自動作成の主キーが使用されます。デフォルトで `django.db.models.AutoField` です。
- models.W043: `<database>` は式のインデックスをサポートしていません。
- models.W044: `<database>` は式に対するユニーク制約をサポートしていません。
- models.W045: チェック制約 `<constraint>` に `RawSQL()` 式が含まれているため、この制約はモデルの `full_clean()` 実行中には検証されません。
- models.W046: `<database>` はテーブルにコメント(`db_table_comment`) をサポートしていません。
- models.W047: `<database>` はNULLを含むユニーク制約をサポートしていません。

### セキュリティ

セキュリティチェックはサイトを安全にするものではありません。コードの監査や侵入検知など、特に複雑な処理も行いません。その代わり、自動化された、簡単なチェックリストを実行して、サイトのセキュリティを向上させるのに役立ちます。

これらのチェックの中には、特定のデプロイメント構成に適切でないものもあるかもしれません。たとえば、HTTPからHTTPSへのリダイレクトをロードバランサーで行っている場合、 `SECURE_SSL_REDIRECT` が有効になっていないと常に警告されるのはイライラするでしょう。 `SILENCED_SYSTEM_CHECKS` を使って、不要なチェックを行わないようにしましょう。

`check --deploy` オプションを使用すると、以下のチェックが実行されます:

- security.W001: `MIDDLEWARE` に `django.middleware.security.SecurityMiddleware` がないため、`SECURE_HSTS_SECONDS`, `SECURE_CONTENT_TYPE_NOSNIFF`, `SECURE_REFERRER_POLICY`, `SECURE_CROSS_ORIGIN_OPENER_POLICY`, および `SECURE_SSL_REDIRECT` の設定に効果がありません。
- security.W002: `MIDDLEWARE` 内に `django.middleware.clickjacking.XFrameOptionsMiddleware` がないため、ページは `'x-frame-options'` ヘッダーが付与されずに提供されます。サイトがフレーム内で提供される必要がない場合は、クリックジャッキング攻撃を防ぐため、このヘッダーを有効にすることを検討してください。
- security.W003: ミドルウェアによる Django 組み込みのクロスサイトリクエストフォージェリ (CSRF) 防御を使っていないようです (`django.middleware.csrf.CsrfViewMiddleware` が `MIDDLEWARE` にありません)。ミドルウェアを有効にすることが、セキュリティホールを作らないための最も安全な方法です。
- security.W004: `SECURE_HSTS_SECONDS` 設定の値を設定していません。サイト全体がSSL経由でのみ提供されている場合は、値を設定して、 HTTP Strict Transport Security を有効にすることを検討してください。注意してドキュメントをよく読んでください。HSTSを不用意に有効にすると、取り返しのつかない深刻な問題を引き起こす可能性があります。
- security.W005: `SECURE_HSTS_INCLUDE_SUBDOMAINS` 設定を `True` に設定していません。これを設定しないと、サイトはサブドメインへの安全でない接続を介して攻撃を受ける可能性があります。ドメインのすべてのサブドメインがSSL経由でのみ提供されることが確実な場合のみ、これを `True` に設定してください。
- security.W006: `SECURE_CONTENT_TYPE_NOSNIFF` の設定が `True` に設定されていないため、 `'X-Content-Type-Options: nosniff'` ヘッダーが付いたページが表示されません。このヘッダを有効にすることで、ブラウザがコンテンツタイプを誤って認識することを防ぐことができます。
- security.W007: `SECURE_BROWSER_XSS_FILTER` 設定が `True` に設定されていないため、ページに `'X-XSS-Protection: 1; mode=block'` ヘッダが付与されません。このヘッダを有効にしてブラウザのXSSフィルタリングを起動すると、XSS攻撃を防ぐのに役立ちます。 このチェックはDjango 3.0で削除されました。 `X-XSS-Protection` ヘッダは現代のブラウザではもはや機能しません。
- security.W008: `SECURE_SSL_REDIRECT` の設定が `True` に設定されていません。SSL接続と非SSL接続の両方で利用できるサイトでない限り、この設定を `True` にするか、ロードバランサーまたはリバースプロキシサーバーですべての接続をHTTPSにリダイレクトするように設定してください。
- security.W009: あなたの `SECRET_KEY` の文字数が 50 文字未満か、一意な文字が 5 文字未満か、 Django が自動的に生成したことを示す `'django-insecure-'` が先頭に付いています。長くてランダムな値を生成してください。そうしないと、 Django のセキュリティ上重要な機能の多くが攻撃に対して脆弱になります。
- security.W010: `django.contrib.sessions` モジュールが `INSTALLED_APPS` にありますが、 `SESSION_COOKIE_SECURE` を `True` に設定していません。セキュアなセッションクッキーのみを使用することで、ネットワークトラフィックの傍受者がユーザーセッションを乗っ取ることがより困難になります。
- security.W011: `django.contrib.sessions.middleware.SessionMiddleware` を `MIDDLEWARE` に設定していますが、 `SESSION_COOKIE_SECURE` を `True` に設定していません。セキュアオンリーのセッションクッキーを使用すると、ネットワークトラフィックの傍受者がユーザーセッションを乗っ取ることが難しくなります。
- security.W012: `SESSION_COOKIE_SECURE` が `True` に設定されていません。セキュアオンリーのセッションクッキーを使用すると、ネットワークトラフィックの傍受者がユーザーセッションを乗っ取ることがより困難になります。
- security.W013: `django.contrib.sessions` が `INSTALLED_APPS` にありますが、 `SESSION_COOKIE_HTTPONLY` を `True` に設定していません。`HttpOnly` セッションクッキーを使用すると、クロスサイトスクリプティング攻撃によるユーザーセッションの乗っ取りが困難になります。
- security.W014: `MIDDLEWARE` に `django.contrib.sessions.middleware.SessionMiddleware` がありますが、`SESSION_COOKIE_HTTPONLY` を `True` に設定していません。 `HttpOnly` セッションクッキーを使用すると、クロスサイトスクリプティング攻撃によるユーザーセッションの乗っ取りがより困難になります。
- security.W015: `SESSION_COOKIE_HTTPONLY` が `True` に設定されていません。 `HttpOnly` セッションクッキーを使用すると、クロスサイトスクリプティング攻撃によるユーザーセッションの乗っ取りが難しくなります。
- security.W016: `CSRF_COOKIE_SECURE` が `True` に設定されていません。セキュアなCSRFクッキーのみを使用すると、ネットワークトラフィックの傍受者がCSRFトークンを盗むことが難しくなります。
- security.W017: `CSRF_COOKIE_HTTPONLY` が `True` に設定されていません。 `HttpOnly` CSRF クッキーを使うと、クロスサイトスクリプティング攻撃による CSRF トークンの盗用がより困難になります。 `CSRF_COOKIE_HTTPONLY` 設定は実用的な利点をもたらさないので、このチェックは Django 1.11 では削除されました。
- security.W018: 本番環境で `DEBUG` を `True` に設定してはいけません。
- security.W019: `MIDDLEWARE` に `django.middleware.clickjacking.XFrameOptionsMiddleware` がありますが、`X_FRAME_OPTIONS` が `'DENY'` に設定されていません。サイトの他の部分をフレーム内に表示する、よほどの必要性がない場合は、`'DENY'` に変更してください。
- security.W020: 本番環境では、 `ALLOWED_HOSTS` は空にしてはいけません。
- security.W021: `SECURE_HSTS_PRELOAD` の設定を `True` にしていません。これがないと、あなたのサイトはブラウザの事前読み込みリストに登録できません。
- security.W022: `SECURE_REFERRER_POLICY` 設定を設定していません。これがないと、サイトは Referrer-Policy ヘッダーを送信しません。ユーザーのプライバシーを保護するために、このヘッダーを有効にすることを検討してください。
- security.E023: `SECURE_REFERRER_POLICY` 設定に無効な値が設定されています。
- security.E024: `SECURE_CROSS_ORIGIN_OPENER_POLICY` 設定に無効な値が設定されています。
- security.W025: あなたの `SECRET_KEY_FALLBACKS[n]` の文字数が 50 文字未満か、一意な文字が 5 文字未満か、 Django が自動的に生成したことを示す `'django-insecure-'` が先頭に付いています。長くてランダムな値を生成してください。そうしないと、 Django のセキュリティ上重要な機能の多くが攻撃に対して脆弱になります。

以下のチェックは、セキュリティ関連の設定が正しく構成されているかを確認します:

- security.E100: `DEFAULT_HASHING_ALGORITHM` は `'sha1'` か `'sha256'` でなければなりません。 このチェックは Django 3.1 と 3.2 で登場しました。
- security.E101: CSRF 失敗のビュー `'path.to.view'` が正しい数の引数を取っていません。
- security.E102: CSRF 失敗のビュー `'path.to.view'` をインポートできませんでした。

### シグナル

- signals.E001: `<handler>` は送信元 `<app label>.<model>` への遅延参照で `<signal>` シグナルに接続されましたが、アプリ `<app label>` がインストールされていないか、モデル `<model>` を提供していません。

### テンプレート

以下のチェックは、`TEMPLATES` 設定が正しく構成されているかどうかを確認します。

- templates.E001: `'APP_DIRS': True` が `TEMPLATES` にあり、同時に `OPTIONS` で `'loaders'` を指定しています。 `APP_DIRS` を削除するか、`'loaders'` オプションを削除してください。
- templates.E002: `TEMPLATES` `OPTIONS` 内の `string_if_invalid` は文字列でなければなりませんが、渡された値は `{value}` (`{type}`) です。
- templates.E003: `<name>` は複数のテンプレートタグモジュールで使用されています: `<module list>` 。 このチェックはDjango 4.1.2で `templates.W003` に変更されました。
- templates.W003: `<name>` は複数のテンプレートタグモジュールで使用されています: `<module list>` 。

### 翻訳

以下のチェックが翻訳の設定に対して実行されます:

- translation.E001: `LANGUAGE_CODE` 設定に無効な値 `<value>` が指定されています。
- translation.E002: `LANGUAGES` 設定で無効な言語コード `<value>` が指定されています。
- translation.E003: `LANGUAGES_BIDI` 設定で無効な言語コード `<value>` が指定されています。
- translation.E004: `LANGUAGE_CODE` 設定に、`LANGUAGES` 設定に含まれていない値が指定されています。

### URL

以下のチェックがURL設定に対して実行されます:

- urls.W001: あなたのURLパターン `<pattern>` は、 `include()` を使用して、`route` が `$` で終わっています。 問題を避けるために、`route` からドル記号を削除してください。
- urls.W002: URL パターン `<pattern>` は `/` から始まる `route` を持っています。このスラッシュは不要なため削除してください。このパターンが `include()` で対象としている場合は、`include()` パターンには末尾に `/` があることを確認してください。
- urls.W003: URL パターン `<pattern>` の `name` に `:` が含まれています。あいまいな名前空間参照を避けるためにコロンを取り除いてください。
- urls.E004: URLパターン `<pattern>` は無効です。`urlpatterns` が `path()` および/または `re_path()` インスタンスのリストであることを確認してください。
- urls.W005: URL 名前空間 `<namespace>` は一意ではありません。この名前空間に含まれるすべてのURLを逆引きできない場合があります。
- urls.E006: `MEDIA_URL`/ `STATIC_URL` 設定はスラッシュで終わる必要があります。
- urls.E007: カスタム `handlerXXX` ビュー `'path.to.view'` は正しい数の引数を取っていません (...)。
- urls.E008: カスタムの `handlerXXX` ビュー `'path.to.view'` をインポートできませんでした。
- urls.E009: URL パターン `<pattern>` には無効なビューがあります。 `<view>` の代わりに `<view>.as_view()` を渡してください。
- urls.W010: URL パターン `<pattern>` に一致しない `<angle bracket>` があります。

## `contrib` アプリのチェック

### `admin`

admin チェックはすべて `admin` タグの一部として実行されます。

管理サイトに登録されている `ModelAdmin` (またはサブクラス) に対して、以下のチェックが実行されます:

- admin.E001: `raw_id_fields` の値はリストまたはタプルでなければなりません。
- admin.E002: `raw_id_fields[n]` の値 `<field name>` は、`<model>` のフィールドではありません。
- admin.E003: `raw_id_fields[n]` の値は、外部キーもしくは多対多のフィールドでなければなりません。
- admin.E004: `fields` の値はリストまたはタプルでなければなりません。
- admin.E005: `fieldsets` と `fields` の両方が指定されています。
- admin.E006: `fields` の値に重複するフィールドが含まれています。
- admin.E007: `fieldsets` の値はリストまたはタプルでなければなりません。
- admin.E008: `fieldsets[n]` の値はリストまたはタプルでなければなりません。
- admin.E009: `fieldsets[n]` の値は長さ 2 でなければなりません。
- admin.E010: `fieldsets[n][1]` の値は辞書でなければなりません。
- admin.E011: `fieldsets[n][1]` の値には、`fields` キーを含める必要があります。
- admin.E012: `fieldsets[n][1]` に重複するフィールドがあります。
- admin.E013: `fields[n]/filter_horizontal[n]/filter_vertical[n]/fieldsets[n][m]` の値に `ManyToManyField` `<field name>` を含めることはできません。そのフィールドはリレーション先のモデルを手動で指定しているからです。
- admin.E014: `exclude` の値はリストまたはタプルでなければなりません。
- admin.E015: `exclude` の値に重複するフィールドが含まれています。
- admin.E016: `form` の値は `BaseModelForm` から継承する必要があります。
- admin.E017: `filter_vertical` の値はリストかタプルでなければなりません。
- admin.E018: `filter_horizontal` の値はリストまたはタプルでなければなりません。
- admin.E019: `filter_vertical[n]/filter_horizontal[n]` の値が `<field name>` を参照しています。これは `<model>` のフィールドではありません。
- admin.E020: `filter_vertical[n]/filter_horizontal[n]` の値は多対多フィールドでなければなりません。
- admin.E021: `radio_fields` の値は辞書でなければなりません。
- admin.E022: `radio_fields` の値は `<field name>` を参照していますが、これは `<model>` のフィールドではありません。
- admin.E023: `radio_fields` の値は `<field name>` を参照しており、これは `ForeignKey` のインスタンスではなく、`choices` 定義も持っていません。
- admin.E024: `radio_fields[<field name>]` の値は `admin.HORIZONTAL` または `admin.VERTICAL` でなければなりません。
- admin.E025: `view_on_site` の値は呼び出し可能オブジェクトか真偽値でなければなりません。
- admin.E026: `prepopulated_fields` の値は辞書でなければなりません。
- admin.E027: `prepopulated_fields` の値は、`<model>` のフィールドである `<field name>` を参照していますが、存在しません。
- admin.E028: `prepopulated_fields` の値は `<field name>` を参照しており、これは `DateTimeField`、`ForeignKey`、`OneToOneField`、または `ManyToManyField` フィールドであってはいけません。
- admin.E029: `prepopulated_fields[<field name]>` の値はリストかタプルでなければなりません。
- admin.E030: `prepopulated_fields` の値は `<field name>` を参照しており、これは `<model>` のフィールドではありません。
- admin.E031: `ordering` の値はリストまたはタプルでなければなりません。
- admin.E032: `ordering` の値はランダムな順序マーカー `?` を持っていますが、他のフィールドも含まれています。
- admin.E033: `ordering` の値は `<field name>` を参照していますが、これは `<model>` のフィールドではありません。
- admin.E034: `readonly_fields` の値は、リストまたはタプルでなければなりません。
- admin.E035: `readonly_fields[n]` の値は `<field_name>` を指し、それは呼び出し可能オブジェクトでも `<ModelAdmin class>` の属性でも `<model>` の属性でもありません。
- admin.E036: `autocomplete_fields` の値はリストまたはタプルでなければなりません。
- admin.E037: `autocomplete_fields[n]` の値が `<field name>` を参照していますが、これは `<model>` のフィールドではありません。
- admin.E038: `autocomplete_fields[n]` の値は、外部キーまたは多対多フィールドでなければなりません。
- admin.E039: `<modeladmin>.autocomplete_fields` によって参照されるため、モデル `<model>` の admin が登録されている必要があります。
- admin.E040: `<modeladmin>` は、`<other_modeladmin>.autocomplete_fields` で参照されているため、`search_fields` を定義する必要があります。

#### `ModelAdmin`

管理サイトに登録されている `ModelAdmin` には、以下のチェックが行われます:

- admin.E101: `save_as` の値は真偽値でなければなりません。
- admin.E102: `save_on_top` の値は真偽値でなければなりません。
- admin.E103: `inlines` の値はリストかタプルでなければなりません。
- admin.E104: `<InlineModelAdmin class>` は `InlineModelAdmin` から継承する必要があります。
- admin.E105: `<InlineModelAdmin class>` には `model` 属性が必要です。
- admin.E106: `<InlineModelAdmin class>.model` の値は `Model` 型でなければなりません。
- admin.E107: `list_display` の値は、リストまたはタプルでなければなりません。
- admin.E108: `list_display[n]` の値は `<label>` を参照していますが、呼び出し可能オブジェクトや `<ModelAdmin クラス>` の属性、`<model>` の属性やメソッドではありません。
- admin.E109: `list_display[n]` の値は、多対多のフィールドや逆参照外部キーであってはいけません。
- admin.E110: `list_display_links` の値は、リスト、タプル、または `None` のいずれかでなければなりません。
- admin.E111: `list_display_links[n]` の値が `<label>` を参照していますが、`list_display` で定義されていません。
- admin.E112: `list_filter` の値はリストまたはタプルでなければなりません。
- admin.E113: `list_filter[n]` の値は `ListFilter` を継承している必要があります。
- admin.E114: `list_filter[n]` の値は `FieldListFilter` を継承してはいけません。
- admin.E115: `list_filter[n][1]` の値は `FieldListFilter` を継承する必要があります。
- admin.E116: `list_filter[n]` の値は `<label>` を参照していますが、Field を参照していません。
- admin.E117: `list_select_related` の値は真偽値、タプル、またはリストでなければなりません。
- admin.E118: `list_per_page` の値は整数でなければなりません。
- admin.E119: `list_max_show_all` の値は整数でなければなりません。
- admin.E120: `list_editable` の値はリストまたはタプルでなければなりません。
- admin.E121: `list_editable[n]` の値は `<model>` のフィールドではない `<label>` を参照しています。
- admin.E122: `list_editable[n]` の値は `<label>` を参照しており、`list_display` には含まれていません。
- admin.E123: `list_editable[n]` の値を `list_editable` と `list_display_links` の両方に入れることはできません。
- admin.E124: `list_editable[n]` の値は `list_display` の最初のフィールド (`<label>`) を参照していますが、`list_display_links` が設定されていないと使用できません。
- admin.E125: `list_editable[n]` の値は `<field name>` を参照しており、これは admin を通じて編集できません。
- admin.E126: `search_fields` の値はリストまたはタプルでなければいけません。
- admin.E127: `date_hierarchy` の値は `<field name>` を参照していますが、Field を参照していません。
- admin.E128: `date_hierarchy` の値は `DateField` または `DateTimeField` でなければなりません。
- admin.E129: `<modeladmin>` は `<action>` アクションのために `has_<foo>_permission()` メソッドを定義する必要があります。
- admin.E130: `<modeladmin>` で定義されたアクションの `__name__` 属性は一意でなければなりません。名前 `<name>` は一意ではありません。

#### `InlineModelAdmin`

以下のチェックは `ModelAdmin` のインラインとして登録された `InlineModelAdmin` に対して行われます。

- admin.E201: フィールド `<field name>` を除外できません。それは親モデル `<app_label>.<model>` の外部キーです。
- admin.E202: `<model>` は `<parent model>` への `ForeignKey` を持っていません。/ `<model>` は `<parent model>` へ複数の `ForeignKey` を持っています。 `fk_name` 属性を指定する必要があります。
- admin.E203: `extra` の値は整数でなければなりません。
- admin.E204: `max_num` の値は整数でなければなりません。
- admin.E205: `min_num` の値は整数でなければなりません。
- admin.E206: `formset` の値は `BaseModelFormSet` を継承する必要があります。

#### `GenericInlineModelAdmin`

以下のチェックは `GenericInlineModelAdmin` のインラインとして登録された `ModelAdmin` に対して行われます。

- admin.E301: `'ct_field'` は `<label>` を参照していますが、これは `<model>` のフィールドではありません。
- admin.E302: `ct_fk_field'` は `<label>` を参照していますが、これは `<model>` のフィールドではありません。
- admin.E303: `<model>` に `GenericForeignKey` がありません。
- admin.E304: `<model>` の `GenericForeignKey` が、コンテンツタイプのフィールド `<field name>` とオブジェクトIDのフィールド `<field name>` を使用していません。

#### `AdminSite`

デフォルトの `AdminSite` には、以下のチェックが実行されます。

- admin.E401: admin アプリケーションを使用するには、`INSTALLED_APPS` に `django.contrib.contenttypes` を含める必要があります。
- admin.E402: デフォルトの認証バックエンドを使用する場合、admin アプリケーションを使用するためには、 `TEMPLATES` (`DjangoTemplates`) で `django.contrib.auth.context_processors.auth` を有効にする必要があります。
- admin.E403: admin アプリケーションを使用するには、`TEMPLATES` で `django.template.backends.django.DjangoTemplates` インスタンスを設定する必要があります。
- admin.E404: admin アプリケーションを使用するには、 `DjangoTemplates` (`TEMPLATES`) で `django.contrib.messages.context_processors.messages` を有効にする必要があります。
- admin.E405: admin アプリケーションを使用するには、`INSTALLED_APPS` に `django.contrib.auth` を含める必要があります。
- admin.E406: admin アプリケーションを使用するには `django.contrib.messages` が `INSTALLED_APPS` に入っていなければなりません。
- admin.E408: admin アプリケーションを使用するには `django.contrib.auth.middleware.AuthenticationMiddleware` を `MIDDLEWARE` に設定する必要があります。
- admin.E409: admin アプリケーションを使用するには `django.contrib.messages.middleware.MessageMiddleware` が `MIDDLEWARE` に入っていなければなりません。
- admin.E410: admin アプリケーションを使用するには `django.contrib.sessions.middleware.SessionMiddleware` が `MIDDLEWARE` に入っていなければなりません。
- admin.W411: admin のナビゲーション・サイドバーを使うには、 `DjangoTemplates` (`TEMPLATES`) で `django.template.context_processors.request` を有効にする必要があります。

### `auth`

- auth.E001: `REQUIRED_FIELDS` はリストまたはタプルでなければなりません。
- auth.E002: カスタムユーザーモデルの `USERNAME_FIELD` として指定されたフィールドは、`REQUIRED_FIELDS` に含めることはできません。
- auth.E003: `<field>` は `USERNAME_FIELD` という名前であるため、一意でなければなりません。
- auth.W004: `<field>` は `USERNAME_FIELD` として命名されていますが、一意ではありません。
- auth.E005: コードネーム `<codename>` のパーミッションは、モデル `<model>` の組み込みパーミッションと衝突します。
- auth.E006: モデル `<model>` に対して、パーミッションコード名 `<codename>` が重複しています。
- auth.E007: モデル `<model>` の `verbose_name` は、組み込みのパーミッション名が最大 255 文字になるように、最大 244 文字でなければなりません。
- auth.E008: モデル `<model>` の `<name>` というパーミッションが 255 文字より長いです。
- auth.C009: `<User model>.is_anonymous` はメソッドではなく、属性またはプロパティでなければなりません。これを無視すると匿名ユーザーが認証済みとして扱われるため、セキュリティ上の問題となります！
- auth.C010: `<User model>.is_authenticated` はメソッドではなく属性またはプロパティでなければなりません。これを無視すると匿名ユーザーが認証済みとして扱われるため、セキュリティ上の問題となります！
- auth.E011: モデル `<model>` の名前は、組み込みのパーミッション名が100文字以下になるように、最大93文字にする必要があります。
- auth.E012: モデル `<model>` のコードネーム `<codename>` というパーミッションが 100 文字より長いです。

### `contenttypes`

モデルに `GenericForeignKey` または `GenericRelation` が含まれる場合、以下のチェックが行われます:

- contenttypes.E001: `GenericForeignKey` オブジェクトの ID が存在しないフィールド `<field>` を参照しています。
- contenttypes.E002: `GenericForeignKey` が存在しないフィールド `<field>` を参照しています。
- contenttypes.E003: `<field>` は `ForeignKey` ではありません。
- contenttypes.E004: `<field>` が `ForeignKey` を `contenttypes.ContentType` に持っていません。
- contenttypes.E005: モデルの名前は最大100文字でなければなりません。

### `postgres`

`django.contrib.postgres` モデルフィールドに対しては、以下のチェックが実行されます。

- postgres.E001: 配列のベース・フィールドに次のエラーがあります: ...
- postgres.E002: 配列のベース・フィールドをリレーション先フィールドにすることはできません。
- postgres.E003: `<field>` のデフォルト値はインスタンスではなく、呼び出し可能オブジェクトにすべきです。これによりすべてのフィールドインスタンスで共有されることがなくなります。このチェックは Django 3.1 で `fields.E010` に変更されました。
- postgres.W004: 配列のベース・フィールドに次の警告があります: ...

### `sites`

以下のチェックは `CurrentSiteManager` を使用しているモデルに対して行われます:

- sites.E001: `CurrentSiteManager` は `<field name>` というフィールドを見つけられませんでした。
- sites.E002: `CurrentSiteManager` は、外部キーや多対多のフィールドではないため、`<field>` を使用できません。

以下のチェックは、`django.contrib.sites` が正しく設定されているかを確認します:

- sites.E101: `SITE_ID` 設定は整数でなければなりません。

### `staticfiles`

以下のチェックは、`django.contrib.staticfiles` が正しく設定されていることを確認します。

- staticfiles.E001: `STATICFILES_DIRS` 設定がタプルまたはリストではありません。
- staticfiles.E002: `STATICFILES_DIRS` 設定に `STATIC_ROOT` 設定を含めるべきではありません。
- staticfiles.E003: `STATICFILES_DIRS` 設定内のプレフィックス `<prefix>` はスラッシュで終わってはいけません。
- staticfiles.W004: `<directory>` というディレクトリは、`STATICFILES_DIRS` 内に存在しません。
- staticfiles.E005: `STORAGES` 設定は `staticfiles` ストレージを定義する必要があります。