---
title: "django-admin と manage.py"
version: 5.2
locale: ja
source: https://docs.djangoproject.com/ja/5.2/ref/django-admin/
canonical: https://djangodocs.dev/ja/5.2/ref/django-admin/
---
# `django-admin` と `manage.py`

`django-admin` は Django の管理タスクのためのコマンドラインユーティリティです。このドキュメントでは、その機能の全体を一通り説明します。

さらに、`manage.py` は各 Django プロジェクト内に自動的に作成されます。`jango-admin` と同じことができますが、[`DJANGO_SETTINGS_MODULE`](/ja/5.2/topics/settings/#envvar-DJANGO_SETTINGS_MODULE) を設定することもでき、プロジェクトの `settings.py` を指定できます。

Django を `pip` 経由でインストールした場合、 `django-admin` はシステムパス上に設定されているはずです。もしシステムパスにない場合、仮想環境が有効になっていることを確認してください。

通常、単体の Django プロジェクトを用いる場合、`django-admin` よりも `manage.py` の方が簡単に利用できます。もし複数の Django 設定ファイル間での切り替えが必要な場合は、`django-admin` を [`DJANGO_SETTINGS_MODULE`](/ja/5.2/topics/settings/#envvar-DJANGO_SETTINGS_MODULE) もしくは [`--settings`](#cmdoption-settings) オプションと共に利用してください。

本項ではコマンドラインの実行例は一貫して `django-admin` を使用しますが、実行例は全て `manage.py` もしくは `python -m django` でも同様に利用可能です。

## 使い方

```console
$ django-admin <command> [options]
$ manage.py <command> [options]
$ python -m django <command> [options]
```

*Windows*

```doscon
...\> django-admin <command> [options]
...\> manage.py <command> [options]
...\> py -m django <command> [options]
```

`command` にはこのドキュメントに一覧されたコマンドの1つでなければなりません。`options` はオプションで、与えられたコマンドで利用できる 0 個以上のオプションを指定します。

### ランタイムのヘルプを表示する

#### `django-admin help`

`django-admin help` を実行すると、使用方法の情報と、各アプリケーションが提供するコマンドのリストが表示されます。

`django-admin help --commands` を実行すると、利用可能な全てのコマンドの一覧が表示されます。

`django-admin help <command>` を実行すると、与えられたコマンドの説明と利用可能なオプションの一覧が表示されます。

### アプリ名

多くのコマンドは「アプリ名」のリストを取ります。1つの「アプリ名」はモデルを含むパッケージのベースネーム (basename) となります。たとえば、[`INSTALLED_APPS`](/ja/5.2/ref/settings/#std-setting-INSTALLED_APPS) が文字列 `'mysite.blog'` を含む場合、アプリ名は `blog` になります。

### バージョンを特定する

#### `django-admin version`

`django-admin version` を実行すると、現在の Django のバージョンが表示されます。

出力は、次のように [**PEP 440**](https://peps.python.org/pep-0440/) で説明されたスキーマに従います。

```text
1.4.dev17026
1.4a1
1.4
```

### デバック出力を表示する

サポートされている場合に [`--verbosity`](#cmdoption-verbosity) を使うと、`django-admin` がコンソールに表示する通知とデバッグ情報の量を指定できます。

## 利用可能なコマンド

### `check`

#### `django-admin check [app_label [app_label ...]]`

[システムチェック フレームワーク](/ja/5.2/ref/checks/) を使用して、Django プロジェクト全体のよくある問題を検査します。

デフォルトでは、全てのアプリがチェックされます。アプリのサブセットをチェックするには、次のようにアプリのラベルの一覧を引数として渡します。

```console
django-admin check auth admin myapp
```

#### `--tag TAGS, -t TAGS`

システムチェック フレームワークは、 [タグでカテゴリ化された](/ja/5.2/ref/checks/#system-check-builtin-tags) さまざまな種類のチェックを実行します。これらのタグを使用すると、特定のカテゴリ内のタグだけに実行するチェックを制限できます。たとえば、モデルと互換性のチェックだけを実行するには、次のコマンドを実行します。

```console
django-admin check --tag models --tag compatibility
```

#### `--database DATABASE`

データベースアクセスが必要なチェックを実行するには、次のようにデータベースを指定します。

```console
django-admin check --database default --database other
```

デフォルトでは、これらのチェックは実行されません。

#### `--list-tags`

利用可能なタグを一覧します。

#### `--deploy`

デプロイメントの設定にだけ関係のある、いくつかの追加チェックを有効化します。

このオプションはローカルの開発環境で使えますが、ローカルの開発の設定モジュールは本番の設定の多くがないかもしれないため、おそらく [`DJANGO_SETTINGS_MODULE`](/ja/5.2/topics/settings/#envvar-DJANGO_SETTINGS_MODULE) 環境変数を設定するか、`--settings` オプションを渡すことで、異なる設定モジュールを指定したくなるでしょう。

```console
django-admin check --deploy --settings=production_settings
```

あるいは、(`--settings` を省略して) 正しい設定が使用されていることを検証するために、本番かステージングのデプロイメントで直接実行することも可能です。

#### `--fail-level {CRITICAL,ERROR,WARNING,INFO,DEBUG}`

0 以外のステータスでコマンドを終了させるメッセージレベルを指定します。デフォルトは `ERROR` です。

### `compilemessages`

#### `django-admin compilemessages`

ビルトインの gettext サポートで使用できるように、[`makemessages`](#django-admin-makemessages) が作成した `.po` ファイルを `.mo` ファイルにコンパイルします。詳しくは [国際化とローカライズ](/ja/5.2/topics/i18n/) を参照してください。

#### `--locale LOCALE, -l LOCALE`

処理する locale を指定します。提供されなかった場合、すべてのロケールが処理されます。

#### `--exclude EXCLUDE, -x EXCLUDE`

処理から除外する locale を指定します。提供されなかった場合、どのロケールも除外されません。

#### `--use-fuzzy, -f`

[fuzzy な翻訳](https://www.gnu.org/software/gettext/manual/html_node/Fuzzy-Entries.html) をコンパイルされたファイルに含めます

使用例:

```console
django-admin compilemessages --locale=pt_BR
django-admin compilemessages --locale=pt_BR --locale=fr -f
django-admin compilemessages -l pt_BR
django-admin compilemessages -l pt_BR -l fr --use-fuzzy
django-admin compilemessages --exclude=pt_BR
django-admin compilemessages --exclude=pt_BR --exclude=fr
django-admin compilemessages -x pt_BR
django-admin compilemessages -x pt_BR -x fr
```

#### `--ignore PATTERN, -i PATTERN`

与えられた [`glob`](https://docs.python.org/3/library/glob.html#module-glob) スタイルのパターンに一致するディレクトリを無視します。 何度も無視するためには複数回使用してください。

使用例:

```console
django-admin compilemessages --ignore=cache --ignore=outdated/*/locale
```

### `createcachetable`

#### `django-admin createcachetable`

設定ファイルからの情報を使用して、データベース キャッシュ バックエンドで使用するためのキャッシュテーブルを作成します。詳細な情報については、 [Django のキャッシュフレームワーク](/ja/5.2/topics/cache/) を参照してください。

#### `--database DATABASE`

キャッシュテーブルを作成するデータベースを指定します。デフォルトは `default` です。

#### `--dry-run`

実行予定の SQL を、実際には実行せずに出力します。これにより、SQL をカスタマイズしたり、マイグレーション フレームワークを使用できます。

### `dbshell`

#### `django-admin dbshell`

[`USER`](/ja/5.2/ref/settings/#std-setting-USER) や [`PASSWORD`](/ja/5.2/ref/settings/#std-setting-PASSWORD) などの設定で指定されたコネクション パラメータを使用して、[`ENGINE`](/ja/5.2/ref/settings/#std-setting-DATABASE-ENGINE) 設定で指定されたデータベースエンジン用のコマンドライン クライアントを実行します。

- PostgreSQL の場合、`psql` コマンドライン クライアントが実行されます。
- MySQL の場合、`mysql` コマンドライン クライアントが実行されます。
- SQLite の場合、`sqlite3` コマンドライン クライアントが実行されます。
- Oracle の場合、`sqlplus` コマンドライン クライアントが実行されます。

このコマンドは、プログラム名 (`psql`、`mysql`、`sqlite3`、`sqlplus`) の呼び出しで正しい場所にあるプログラムが見つかるように `PATH` が設定されているを想定しています。プログラムの場所を手動で指定する方法はありません。

#### `--database DATABASE`

シェルをオープンするデータベースを指定します。デフォルトは `default` です。

#### `-- ARGUMENTS`

`--` 区切り文字に続く引数は、ベースのコマンドライン クライアントに渡されます。たとえば、PostgreSQL では、次のように `psql` コマンドの `-c` フラグを使うことで、素の SQL クエリを直接実行できます。

```console
$ django-admin dbshell -- -c 'select current_user'
 current_user
--------------
 postgres
(1 row)
```

*Windows*

```doscon
...\> django-admin dbshell -- -c 'select current_user'
 current_user
--------------
 postgres
(1 row)
```

MySQL/MariaDB では、次のように `mysql` の `-e` フラグを使用すると実行できます。

```console
$ django-admin dbshell -- -e "select user()"
+----------------------+
| user()               |
+----------------------+
| djangonaut@localhost |
+----------------------+
```

*Windows*

```doscon
...\> django-admin dbshell -- -e "select user()"
+----------------------+
| user()               |
+----------------------+
| djangonaut@localhost |
+----------------------+
```

> **Note**
>
> [`DATABASES`](/ja/5.2/ref/settings/#std-setting-DATABASES) のデータベース設定の [`OPTIONS`](/ja/5.2/ref/settings/#std-setting-OPTIONS) 部分で設定されたすべてのオプションがコマンドラインクライアントに渡されるわけではないことに注意してください。例えば、`'isolation_level'` などです。

### `diffsettings`

#### `django-admin diffsettings`

現在の設定ファイルと Django のデフォルトの設定 (または他の [`--default`](#cmdoption-diffsettings-default) で指定された設定ファイル) の違いを表示します。

デフォルトに現れない設定には `"###"` が続きます。たとえば、デフォルト設定が [`ROOT_URLCONF`](/ja/5.2/ref/settings/#std-setting-ROOT_URLCONF) を定義していない場合、`diffsettings` の出力内の [`ROOT_URLCONF`](/ja/5.2/ref/settings/#std-setting-ROOT_URLCONF) の後には `"###"` が表示されます

#### `--all`

Django のデフォルト値が設定されていたとしても、すべての設定を表示する。このような設定には、前に `"###"` という接頭辞が付きます。

#### `--default MODULE`

現在の設定の比較対象にする設定モジュール。空にすると、Django のデフォルトの設定と比較します。

#### `--output {hash,unified}`

出力フォーマットを指定します。指定可能な値は `hash` と `unified` です。`hash` はデフォルトのモードで、上に説明したような出力を表示します。`unified` は `diff -u` に似た出力を表示します。デフォルトの設定はマイナス記号が前に付き、その後にプラス記号が前についた変更された設定が続きます。

### `dumpdata`

#### `django-admin dumpdata [app_label[.ModelName] [app_label[.ModelName] ...]]`

名前を指定したアプリケーションと関連するデータベースの中のすべてのデータを、標準出力にアウトプットします。

アプリケーション名が指定されなかった場合、インストールされたすべてのアプリケーションをダンプします。

`dumpdata` のアウトプットは [`loaddata`](#django-admin-loaddata) に対するインプットして使用できます。

`dumpdata` の出力をファイルとして保存すると、 [テスト](/ja/5.2/topics/testing/tools/#topics-testing-fixtures) の [フィクスチャ](/ja/5.2/topics/db/fixtures/#fixtures-explanation)  や、 [初期データ](/ja/5.2/howto/initial-data/#initial-data-via-fixtures) として活用できます。

`dumpdata` は、ダンプするレコードを選択するために、モデルのデフォルトのマネージャを使用することに注意してください。[カスタム マネージャ](/ja/5.2/topics/db/managers/#custom-managers) をデフォルトのマネージャとして使用していて、利用できるレコードの一部をフィルタリングしている場合、必ずしもすべてのオブジェクトがダンプされるわけではありません。

#### `--all, -a`

レコードをダンプする際に、フィルタリングまたは変更される可能性があるカスタム マネージャーの代わりに、Django のベース マネージャを使用します。

#### `--format FORMAT`

出力のシリアライズフォーマットを指定します。デフォルトは JSON です。対応フォーマットは [シリアライズフォーマット](/ja/5.2/topics/serialization/#serialization-formats) に一覧があります。

#### `--indent INDENT`

出力で使用するインデントのスペースの数を指定します。デフォルトは `None` で、全てのデータを1行で表示します。

#### `--exclude EXCLUDE, -e EXCLUDE`

(`app_label.ModelName` の形式で指定された) 特定のアプリケーションやモデルがダンプされるのを防ぎます。モデル名を指定した場合には、アプリケーション全体ではなく、そのモデルだけが除外されます。アプリケーション名とモデル名を混ぜることもできます。

複数のアプリケーションを除外したいときは、`--exclude` を複数回渡してください。

```console
django-admin dumpdata --exclude=auth --exclude=contenttypes
```

#### `--database DATABASE`

データをダンプするデータベースを指定します。デフォルトは `default` です。

#### `--natural-foreign`

`natural_key()` モデルメソッドを使用して、任意の外部キーと多対多リレーションを、メソッドを定義している種類のオブジェクトにシリアルライズします。`contrib.auth` の `Permission` オブジェクトや `contrib.contenttypes` の `ContentType` オブジェクトをダンプする場合、おそらくこのフラグを使う必要があります。このオプションと次のオプションの詳細については、[ナチュラルキー](/ja/5.2/topics/serialization/#topics-serialization-natural-keys) のドキュメントを参照しください。

#### `--natural-primary`

このオブジェクトのシリアライズされたデータの主キーを省略します。これが省略できるのは、デシリアライズ時に計算できるためです。

#### `--pks PRIMARY_KEYS`

カンマで区切られた主キーのリストで指定されたオブジェクトだけを出力します。これは1つのモデルをダンプするときのみ有効です。デフォルトでは、モデルのすべてのレコードが出力されます。

#### `--output OUTPUT, -o OUTPUT`

シリアライズされたデータを書き込むファイルを指定します。デフォルトでは、データは標準出力に出力されます。

このオプションが設定されていて、 `--verbosity` が 0 (デフォルト) より大きい場合、ターミナルにプログレスバーが表示されます。

#### フィクスチャの圧縮

出力ファイルは、ファイル名の最後に対応する拡張子をつけることで、 `bz2`、`gz`、`lzma`、`xz` のいずれかの形式で圧縮できます。たとえば、データを圧縮された JSON ファイルとして出力するには、次のようにします：

```console
django-admin dumpdata -o mydata.json.gz
```

### `flush`

#### `django-admin flush`

データベースからすべてのデータを削除し、同期後のハンドラを再実行します。マイグレーションが適用されたテーブルはクリアされません。

空のデータベースから始めて、すべてのマイグレーションを再実行したい場合は、代わりにデータベースを削除して再作成してから [`migrate`](#django-admin-migrate) を実行してください。

#### `--noinput, --no-input`

すべてのユーザープロンプトを表示しません。

#### `--database DATABASE`

フラッシュするデータベースを指定します。デフォルトは `default` です。

### `inspectdb`

#### `django-admin inspectdb [table [table ...]]`

[`NAME`](/ja/5.2/ref/settings/#std-setting-NAME) 設定で指定されたデータベースのテーブルをイントロスペクトし、 Django モデルモジュール (`models.py` ファイル) を標準出力に出力します。

引数にテーブルやビューの名前を渡すことで、検査するテーブルやビューを選択できます。引数を指定しなかった場合、 [`--include-views`](#cmdoption-inspectdb-include-views) オプションが使用された場合のみ、ビューのモデルが作成されます。PostgreSQL で [`--include-partitions`](#cmdoption-inspectdb-include-partitions) オプションが使用された場合、パーティションテーブルのモデルが作成されます。

Django で使いたいレガシーデータベースがある場合に使ってください。このスクリプトはデータベースを検査し、各テーブルのモデルを作成します。

ご想像の通り、作成されたモデルはテーブルのすべてのフィールドに対して属性を持ちます。 `inspectdb` はフィールド名の出力において、いくつかの特殊なケースを持つことに注意してください：

- カラムの型をモデルのフィールド型にマッピングできない場合、`inspectdb` は `TextField` を使用し、生成されたモデルのフィールドの横に `'This field type is a guess.'` という Python のコメントを挿入します。 認識されるフィールドは [`INSTALLED_APPS`](/ja/5.2/ref/settings/#std-setting-INSTALLED_APPS) にリストされているアプリに依存します。たとえば、 [`django.contrib.postgres`](/ja/5.2/ref/contrib/postgres/#module-django.contrib.postgres) はいくつかの PostgreSQL 固有のフィールドタイプの認識を追加します。
- データベースのカラム名が Python の予約語 (`pass'`, `class'`, `for'` など) の場合、 `inspectdb` は属性名に `'_field'` を追加します。 例えば、テーブルに `'for'` というカラムがある場合、生成されるモデルはフィールド `'for_field'` を持ち、 `db_column'` 属性は `'for'` に設定されます。その際、 `inspectdb` はフィールドの横に `'Field renamed because it was a Python reserved word."` という Python コメントを挿入します。

この機能は、決定的なモデル生成としてではなく、ショートカットとして意図されています。 この機能を実行した後、生成されたモデルを自分で見て、カスタマイズしてください。特に、他のモデルを参照するモデルが適切に並ぶように、モデルの順序を並べ替える必要があるでしょう。

Django はモデルフィールドに [`default`](/ja/5.2/ref/models/fields/#django.db.models.Field.default) が指定されても、データベースのデフォルト値を作成しません。 同様に、データベースのデフォルト値はモデルフィールドのデフォルト値に変換されませんし、 `inspectdb` によって検出されることもありません。

デフォルトでは、 `inspectdb` は非管理モデルを作成します。 つまり、モデルの `Meta` クラスで `managed = False` を指定することで、 Django は各テーブルの作成、変更、削除を管理しないようになります。テーブルのライフサイクルを Django に管理させたい場合は、 [`managed`](/ja/5.2/ref/models/options/#django.db.models.Options.managed) オプションを `True` に変更する必要があります (あるいは、 `True` がデフォルト値なので削除してください)。

#### データベース固有の注意事項

##### Oracle

- [`--include-views`](#cmdoption-inspectdb-include-views) が使用されている場合、モデルはマテリアライズドビューのために作成されます。

##### PostgreSQL

- モデルは外部テーブル用に作成されます。
- [`--include-views`](#cmdoption-inspectdb-include-views) が使用されている場合、モデルはマテリアライズドビューのために作成されます。
- [`--include-partitions`](#cmdoption-inspectdb-include-partitions) が使用されている場合、モデルはパーティションテーブルに対して作成されます。

#### `--database DATABASE`

イントロスペクトするデータベースを指定します。デフォルトは `default` です。

#### `--include-partitions`

このオプションを指定すると、パーティション用のモデルも作成されます。

PostgreSQL 向けのサポートのみが実装されています。

#### `--include-views`

このオプションを指定すると、データベースビュー用のモデルも作成されます。

### `loaddata`

#### `django-admin loaddata fixture [fixture ...]`

指定された [フィクスチャ](/ja/5.2/topics/db/fixtures/#fixtures-explanation) の内容を検索してデータベースにロードします。

#### `--database DATABASE`

データを読み込むデータベースを指定します。デフォルトは `default` です。

#### `--ignorenonexistent, -i`

フィクスチャが最初に生成されてから削除された可能性のあるフィールドやモデルを無視します。

#### `--app APP_LABEL`

すべてのアプリでフィクスチャを探すのではなく、一つのアプリでフィクスチャを探すように指定します。

#### `--format FORMAT`

[stdin から読み込む](#loading-fixtures-stdin) フィクスチャの [シリアライズフォーマット](/ja/5.2/topics/serialization/#serialization-formats) (`json` や `xml` など) を指定します。

#### `--exclude EXCLUDE, -e EXCLUDE`

(`app_label` または `app_label.ModelName` の形で) 指定されたアプリケーションやモデルからのフィクスチャの読み込みを除外します。複数のアプリやモデルを除外するには、このオプションを複数回使います。

#### `stdin` からフィクスチャを読み込む

`sys.stdin` から入力を読み込むには、フィクスチャ名としてハイフンを使用します。たとえば下記のようにします：

```console
django-admin loaddata --format=json -
```

`stdin` から読み込む場合、 [`--format`](#cmdoption-loaddata-format) オプションで入力の [シリアライズフォーマット](/ja/5.2/topics/serialization/#serialization-formats) (例 `json` や `xml`) を指定する必要があります。

`stdin` からの読み込みは、標準入出力をリダイレクトするのに便利です。たとえば：

```console
django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -
```

[`dumpdata`](#django-admin-dumpdata) コマンドは `loaddata` の入力を生成するために使用できます。

> **See also**
>
> フィクスチャの詳細については [フィクスチャ (fixture)](/ja/5.2/topics/db/fixtures/#fixtures-explanation) トピックを参照してください。

### `makemessages`

#### `django-admin makemessages`

現在のディレクトリのソースツリー全体を走査し、翻訳が必要な文字列をすべて取り出します。conf/locale ディレクトリ (Django ツリーの場合) か locale ディレクトリ (プロジェクトとアプリケーションの場合) にメッセージファイルを作成 (または更新) します。メッセージファイルを変更した後は、組み込みの gettext サポートを使うために [`compilemessages`](#django-admin-compilemessages) でコンパイルする必要があります。詳しくは [国際化のドキュメント](/ja/5.2/topics/i18n/translation/#how-to-create-language-files) を参照してください。

このコマンドは設定を必要としません。しかし、設定が構成されていない場合、コマンドは [`MEDIA_ROOT`](/ja/5.2/ref/settings/#std-setting-MEDIA_ROOT) と [`STATIC_ROOT`](/ja/5.2/ref/settings/#std-setting-STATIC_ROOT) ディレクトリを無視したり、 [`LOCALE_PATHS`](/ja/5.2/ref/settings/#std-setting-LOCALE_PATHS) をインクルードしたりすることはできません。

#### `--all, -a`

利用可能な全ての言語に対してメッセージファイルを更新します。

#### `--extension EXTENSIONS, -e EXTENSIONS`

検査するファイル拡張子のリストを指定します (デフォルト: `html`、`txt`、`py`、 `js` ([`--domain`](#cmdoption-makemessages-domain) が `djangojs` の場合)。

使用例:

```console
django-admin makemessages --locale=de --extension xhtml
```

複数の拡張子はカンマで区切るか、`-e` または `--extension` を複数回使用してください：

```console
django-admin makemessages --locale=de --extension=html,txt --extension xml
```

#### `--locale LOCALE, -l LOCALE`

処理する場所 (locale) を指定します。

#### `--exclude EXCLUDE, -x EXCLUDE`

処理から除外する locale を指定します。提供されなかった場合、どのロケールも除外されません。

使用例:

```console
django-admin makemessages --locale=pt_BR
django-admin makemessages --locale=pt_BR --locale=fr
django-admin makemessages -l pt_BR
django-admin makemessages -l pt_BR -l fr
django-admin makemessages --exclude=pt_BR
django-admin makemessages --exclude=pt_BR --exclude=fr
django-admin makemessages -x pt_BR
django-admin makemessages -x pt_BR -x fr
```

#### `--domain DOMAIN, -d DOMAIN`

メッセージファイルのドメインを指定します。サポートされているオプションは以下の通りです:

- `*.py`、`*.html`、`*.txt` ファイルすべてに対して `django` (デフォルト)
- `*.js` ファイルに対して `djangojs`

#### `--symlinks, -s`

新しい翻訳文字列を探すときに、ディレクトリへのシンボリックリンクをたどります。

使用例:

```console
django-admin makemessages --locale=de --symlinks
```

#### `--ignore PATTERN, -i PATTERN`

与えられた [`glob`](https://docs.python.org/3/library/glob.html#module-glob) スタイルのパターンに一致するファイルやディレクトリを無視します。 何度も無視するためには複数回使用してください。

次のパターンはデフォルトで使われます: `'CVS'`、`'.*'`、`'*~'`、`'*.pyc'`。

使用例:

```console
django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html
```

#### `--no-default-ignore`

`--ignore` のデフォルト値を無効化します。

#### `--no-wrap`

言語ファイル内で、長いメッセージ行の複数行への分割を無効化します。

#### `--no-location`

言語ファイル内に '`#: filename:line`' コメント行を書き込むのを抑制します。このオプションを使うと、技術的な翻訳者がそれぞれのメッセージの文脈を理解することが難しくなります。

#### `--add-location [{full,file,never}]`

言語ファイル中のコメント行 `#: filename:line` をコントロールします。オプションは下記です：

- `full` (省略時のデフォルト): ファイル名と行番号の両方を含む行を表示します。
- `file`: 行番号は省略されます。
- `never`: 行の出力が抑制されます ([`--no-location`](#cmdoption-makemessages-no-location) と同じ)。

`gettext` 0.19 以降が必要です。

#### `--no-obsolete`

廃止されたメッセージ文字列を `.po` ファイルから削除します。

#### `--keep-pot`

`.po` ファイルが作成される前に生成される一時的な `.pot` ファイルを削除しないようにします。最終的な言語ファイルが生成されるのを妨げるようなエラーをデバッグするために有用です。

> **See also**
>
> [`makemessages`](#django-admin-makemessages) が `xgettext` に渡すキーワードをカスタマイズする方法を知りたい場合は、[makemessages コマンドをカスタマイズする](/ja/5.2/topics/i18n/translation/#customizing-makemessages) を参照してください。

### `makemigrations`

#### `django-admin makemigrations [app_label [app_label ...]]`

検出されたモデルの変更に基づいて、新しいマイグレーションを作成します。マイグレーションおよびそのアプリとの関係は、詳しくは  [マイグレーションのドキュメント](/ja/5.2/topics/migrations/) で説明しています。

1つ以上のアプリ名を引数として与えると、作成するマイグレーションを、指定されたアプリとそれに必要な依存関係 (たとえば、外部キーで繋がれた他のテーブルなど) に限定されます。

マイグレーションを `migrations` ディレクトリが存在しないアプリに追加するには、`makemigrations` にアプリの `app_label` を付けて実行します。

#### `--noinput, --no-input`

すべてのユーザープロンプトを抑制します。もし、抑制されたプロンプトが自動的に解決できなかった場合は、エラーコード 3 で終了します。

#### `--empty`

手動で編集するために、指定されたアプリに対する空のマイグレーションを出力します。このオプションは詳しいユーザーのためのもので、マイグレーションのフォーマット、マイグレーション・オペレーション、およびマイグレーション間の依存関係について十分理解していない限り、使うべきではありません。

#### `--dry-run`

実際にマイグレーションをディスクには書き込まず、作成される予定のマイグレーションを表示します。このオプションを `--verbosity 3` オプションと併用することで、書き込まれる予定のマイグレーションファイルの内容そのものを表示できます。

#### `--merge`

マイグレーションで発生するコンフリクトの修復を有効にする

#### `--name NAME, -n NAME`

生成されたマイグレーションに名前を付けることができます。名前は有効な Python [識別子](https://docs.python.org/3/reference/lexical_analysis.html#identifiers) でなければなりません。

#### `--no-header`

Django のバージョンとタイムスタンプヘッダなしでマイグレーションファイルを生成します。

#### `--check`

マイグレーションを伴わないモデル変更が検出された場合に、 `makemigrations` を 0 以外のステータスで終了するようにします。これは `--dry-run` を意味します。

#### `--scriptable`

ログ出力と入力プロンプトを `stderr` に流し、生成されたマイグレーションファイルのパスのみを `stdout` に書き込みます。

#### `--update`

モデルの変更を最新のマイグレーションにマージし、その結果生じるオペレーションを最適化します。

更新されたマイグレーションは生成された名前を持ちます。以前の名前を保持するには、`--name` を使って設定してください。

### `migrate`

#### `django-admin migrate [app_label] [migration_name]`

データベースの状態を、現在のモデルとマイグレーションのセットを基づいて同期します。マイグレーションおよびそのアプリとの関係については、詳しくは [マイグレーションのドキュメント](/ja/5.2/topics/migrations/) で説明しています。

このコマンドの動作は、次のように与えられた引数によって変化します。

- 引数なし: 全てのアプリが、それぞれが持つマイグレーションを全て実行します。
- `<app_label>`: 指定したアプリに最新のマイグレーションまで実行させます。依存関係によっては、他のアプリのマイグレーションも実行される場合もあります
- `<app_label> <migrationname>`: データベーススキーマを、指定した名前のマイグレーションが実行された状態になるようにします。指定したよりも後のマイグレーションは適用されません。指定されたより前のマイグレーションがすでに適用されていた場合など、指定の仕方によってはマイグレーションが実行できない場合があります。アプリに対するすべてのマイグレーションの適用をリセットするには、`zero` という名前を指定してください。指定したアプリ名で一意であれば、マイグレーション名のプレフィックス、例えば `0001` を使用できます。アプリに適用されたマイグレーションをすべて元に戻すには `zero` という名前を指定してください。

> **Warning**
>
> マイグレーションの適用を取り消すと、`<app_label>` に関係なく、依存するマイグレーションもすべて取り消されます。どのマイグレーションが取り消されるかを調べるには `--plan` を使用してください。

#### `--database DATABASE`

マイグレートするデータベースを指定します。デフォルトは `default` です。

#### `--fake`

（上記のルールに従って）ターゲットのマイグレーションまでを適用されたものとしてマークしますが、データベーススキーマを変更するSQLを実際には実行しません。

これは上級ユーザが手動で変更を適用する場合に、現在のマイグレーション状態を直接操作することを想定しています。 `--fake` を使用すると、マイグレーションを正しく実行するためにマイグレーション状態テーブルを手動で回復する必要がある状態になる危険性があることに注意してください。

#### `--fake-initial`

マイグレーションに含まれる全ての [`CreateModel`](/ja/5.2/ref/migration-operations/#django.db.migrations.operations.CreateModel) オペレーションで作成された全てのモデルの名前を持つデータベーステーブルが既に存在する場合、 Django がアプリの初期マイグレーションをスキップできるようにします。このオプションは、マイグレーションを使用する前のデータベースに対してマイグレーションを初めて実行するときに使用することを想定しています。しかし、このオプションは、テーブル名の一致以外のデータベーススキーマの一致をチェックしないので、既存のスキーマが初期マイグレーションに記録されているものと一致することを確信している場合のみ安全に使用できます。

#### `--plan`

指定された `migrate` コマンドに対して実行されるマイグレーション・オペレーションを表示します。

#### `--run-syncdb`

マイグレーションせずにアプリ用のテーブルを作成できるようにします。これは推奨されませんが、マイグレーションフレームワークは何百ものモデルがある大規模なプロジェクトでは遅すぎることがあります。

#### `--noinput, --no-input`

すべてのユーザープロンプトを表示しません。プロンプトの例は、古くなったコンテンツタイプの削除に関する質問です。

#### `--check`

適用されていないマイグレーションが検出された場合に、 `migrate` を 0 以外のステータスで終了するようにします。

#### `--prune`

存在しないマイグレーションを `django_migrations` テーブルから削除します。これはスカッシュしたマイグレーションによって置き換えられたマイグレーションファイルが削除された場合に便利です。詳細は [マイグレーションのスカッシュ (Squash)](/ja/5.2/topics/migrations/#migration-squashing) を参照してください。

### `optimizemigration`

#### `django-admin optimizemigration app_label migration_name`

指定されたマイグレーション・オペレーションを最適化し、既存のファイルを上書きします。マイグレーションに手動でコピーしなければならない関数が含まれている場合、このコマンドは `_optimized` で終わる新しいマイグレーションファイルを作成し、指定されたマイグレーションを置き換えます。

#### `--check`

マイグレーションを最適化できる場合に、 `optimizemigration` を 0 以外のステータスで終了するようにします。

### `runserver`

#### `django-admin runserver [addrport]`

ローカルマシンで軽量の開発用ウェブサーバを起動します。デフォルトでは、IPアドレス `127.0.0.1` のポート 8000 で動作します。IPアドレスとポート番号を明示的に渡すこともできます。

このスクリプトを通常の権限を持つユーザ（推奨）で実行した場合、小さいポート番号のポートを起動するためのアクセス権がない可能性があります。小さいポート番号はスーパーユーザ（root）のために予約されています。

このサーバーは [`WSGI_APPLICATION`](/ja/5.2/ref/settings/#std-setting-WSGI_APPLICATION) 設定で指定された WSGI アプリケーションオブジェクトを使用します。

> **Warning**
>
> このサーバーは本番環境で使用しないでください。
>
> この軽量な開発用サーバーは、セキュリティ監査やパフォーマンステストを受けていないため、本番環境には不適切です。このサーバーを本番環境で使用できるようにすることは、Django のスコープ外です。

開発サーバーは必要に応じてリクエストごとにPythonコードを自動的にリロードします。コード変更の効果を得るためにサーバーを再起動する必要はありません。しかしながら、ファイルの追加のようないくつかの行動は再起動をトリガーしません、このような場合はサーバーを再起動する必要があります。

Linux や MacOS を使用していて、 [pywatchman](https://pypi.org/project/pywatchman/) と [Watchman](https://facebook.github.io/watchman/) サービスの両方をインストールしている場合、カーネルシグナルがサーバーの自動再ロードに使用されます(毎秒ファイルの変更タイムスタンプをポーリングするのではなく)。これにより、大規模なプロジェクトでのパフォーマンスが改善され、コード変更後の 応答時間が短縮され、変更検出がより強固になり、消費電力が削減されます。Django は `pywatchman` 1.2.0 以降をサポートしています。

> **巨大なディレクトリに多くのファイルが含まれる場合、パフォーマンスの問題を引き起こす可能性があります。**
>
> `node_modules` のような大きな非 Python ディレクトリを含むプロジェクトで Watchman を使う場合、最適なパフォーマンスのためにこのディレクトリを無視することをお勧めします。この方法については [watchman documentation](https://facebook.github.io/watchman/docs/config#ignore_dirs) を参照してください。

> **Watchman のタイムアウト**
>
> #### `DJANGO_WATCHMAN_TIMEOUT`
>
>
>
>
> Watchman クライアントのデフォルトのタイムアウトは 5 秒です。これを変更するには [`DJANGO_WATCHMAN_TIMEOUT`](#envvar-DJANGO_WATCHMAN_TIMEOUT) 環境変数を設定します。

サーバを起動したとき、そしてサーバ起動中に Python コードを変更するたびに、システムチェックフレームワークが Django プロジェクト全体に一般的なエラーがないかチェックします ([`check`](#django-admin-check) コマンドを参照してください)。エラーが見つかった場合、標準出力に出力されます。システムチェックの実行をスキップするには `--skip-checks` オプションを使います。

`django-admin runserver` を複数回実行することで、異なるポート上であれば、好きなだけ並列でサーバーを実行できます。

デフォルトの IP アドレス `127.0.0.1` は、同じネットワーク上の他のマシンからはアクセスできないことに注意してください。開発用サーバーを他のマシンから見られるようにするには、ネットワーク上の自分のローカル IP アドレス (例 `192.168.2.1`) または `0` (`0.0.0.0` のショートカット)、 `0.0.0.0` 、または `::` (IPv6を有効にした場合) を使用します。

ブラケットで囲んだ IPv6 アドレス (例 `[200a::1]:8000`) も使用できます。その場合は、IPv6 のサポートが自動的に有効になります。

ホスト名には ASCII 文字のみからなる文字列も使用できます。

[staticfiles](/ja/5.2/ref/contrib/staticfiles/) contrib アプリが有効になっている場合 (新しいプロジェクトのデフォルト)、 [`runserver`](#django-admin-runserver) コマンドは独自の [runserver](/ja/5.2/ref/contrib/staticfiles/#staticfiles-runserver) コマンドで上書きされます。

サーバの各リクエストとレスポンスのログは [django.server](/ja/5.2/ref/logging/#django-server-logger) ロガーに送られます。

#### `--noreload`

自動リローダを無効にします。これは、もし特定の Python モジュールが既にメモリに読み込まれている場合、サーバの実行中に行った Python コードの変更は *反映* されないことを意味します。

#### `--nothreading`

開発サーバーでのスレッドの使用を無効にします。デフォルトではサーバーはマルチスレッドです。

#### `--ipv6, -6`

開発用サーバーで IPv6 を使用します。これにより、デフォルトの IP アドレスが `127.0.0.1` から `::1` に変わります。

#### `DJANGO_RUNSERVER_HIDE_WARNING`

> **New in Django 5.2**

デフォルトでは、`runserver` は本番環境には適さないという警告がコンソールに表示されます。

```text
WARNING: This is a development server. Do not use it in a production setting. Use a production WSGI or ASGI server instead.
For more information on production servers see: https://docs.djangoproject.com/en/|version|/howto/deployment/
```

警告を非表示にする場合、この環境変数を `"true"` に設定します。

#### 異なるポートとアドレスを使用する場合の引数例

IP アドレス `127.0.0.1` 上でポート 8000 を使用する場合:

```console
django-admin runserver
```

IP アドレス `1.2.3.4` 上でポート 8000 を使用する場合:

```console
django-admin runserver 1.2.3.4:8000
```

IP アドレス `127.0.0.1` 上でポート 7000 を使用する場合:

```console
django-admin runserver 7000
```

IP アドレス `1.2.3.4` 上でポート 7000 を使用する場合:

```console
django-admin runserver 1.2.3.4:7000
```

IPv6 アドレス `::1` 上でポート 8000 を使用する場合:

```console
django-admin runserver -6
```

IPv6 アドレス `::1` 上でポート 7000 を使用する場合:

```console
django-admin runserver -6 7000
```

IPv6 アドレス `2001:0db8:1234:5678::9` 上でポート 7000 を使用する場合:

```console
django-admin runserver [2001:0db8:1234:5678::9]:7000
```

IPv4 アドレスのホスト `localhost` 上でポート 8000 を使用する場合:

```console
django-admin runserver localhost:8000
```

IPv6 アドレスのホスト `localhost` 上でポート 8000 を使用する場合:

```console
django-admin runserver -6 localhost:8000
```

#### 開発用サーバーで静的 (static) ファイルを配信する

デフォルトでは、開発サーバはサイトの静的ファイル (CSS ファイルや画像、 [`MEDIA_URL`](/ja/5.2/ref/settings/#std-setting-MEDIA_URL) 以下にあるものなど) を配信しません。Django が静的メディアを配信するように設定したい場合は、 [静的ファイル (画像、JavaScript、CSS など) を管理する](/ja/5.2/howto/static-files/) を参照してください。

#### 開発中に ASGI サーバーを使う

Django の `runserver` コマンドは WSGI サーバーを提供します。ASGI で実行するには、 [ASGI サーバー](/ja/5.2/howto/deployment/asgi/) を使う必要があります。Django Daphne プロジェクトは、 [runserver との統合](/ja/5.2/howto/deployment/asgi/daphne/#daphne-runserver) を提供しています。

### `sendtestemail`

#### `django-admin sendtestemail [email [email ...]]`

（Django によるメール送信が動作していることを確認するために）指定した受信者にテストメールを送信します。たとえば以下のようにします：

```console
django-admin sendtestemail foo@example.com bar@example.com
```

いくつかのオプションがあるので、次のようにそれらを任意に組み合わせて使用できます。

#### `--managers`

[`mail_managers()`](/ja/5.2/topics/email/#django.core.mail.mail_managers) を使用して [`MANAGERS`](/ja/5.2/ref/settings/#std-setting-MANAGERS) で指定されたメールアドレスにメールします。

#### `--admins`

[`mail_admins()`](/ja/5.2/topics/email/#django.core.mail.mail_admins) を使用して [`ADMINS`](/ja/5.2/ref/settings/#std-setting-ADMINS) で指定されたメールアドレスにメールします。

### `shell`

#### `django-admin shell`

Python のインタラクティブ・インタープリタを開始します。

インストール済みアプリのすべてのモデルは、シェル環境に自動的にインポートされます。 [`INSTALLED_APPS`](/ja/5.2/ref/settings/#std-setting-INSTALLED_APPS) において先に記述されたアプリのモデルが優先されます。 `--verbosity` を 2 以上に設定すると、自動的にインポートされたオブジェクトが一覧表示されます。自動インポートを完全に無効にしたい場合は、 `--no-imports` フラグを使用してください。

自動インポートを追加または削除するには、 [挙動をカスタマイズする](/ja/5.2/howto/custom-shell/#customizing-shell-auto-imports) ガイドを参照してください。

> **Changed in Django 5.2**
>
> 自動モデルインポートが追加されました。

#### `--interface {ipython,bpython,python}, -i {ipython,bpython,python}`

使用するシェルを指定します。デフォルトでは、Django はインストールされている場合には  [IPython](https://ipython.org/) または [bpython](https://bpython-interpreter.org/) を使用します。両方インストールされている場合には、次のようにして使いたいシェルを指定してください。

IPython:

```console
django-admin shell -i ipython
```

bpython:

```console
django-admin shell -i bpython
```

"リッチな" シェルをインストールしているが、"プレーン" な Python インタプリタを強制的に使いたい場合は、インターフェイス名として `python` を次のように使用します：

```console
django-admin shell -i python
```

#### `--no-startup`

"プレーン" Python インタプリタのスタートアップスクリプトを読み込まないようにします。デフォルトでは [`PYTHONSTARTUP`](https://docs.python.org/3/using/cmdline.html#envvar-PYTHONSTARTUP) 環境変数か `~/.pythonrc.py` スクリプトが指すスクリプトが読み込まれます。

#### `--no-imports`

> **New in Django 5.2**

[`INSTALLED_APPS`](/ja/5.2/ref/settings/#std-setting-INSTALLED_APPS) からモデルの自動インポートを無効にします。

#### `--command COMMAND, -c COMMAND`

以下のように、コマンドを文字列で渡して、Django として実行できます：

```console
django-admin shell --command="import django; print(django.__version__)"
```

標準入力にコードを渡して実行することもできます。たとえば：

```console
$ django-admin shell <<EOF
> import django
> print(django.__version__)
> EOF
```

Windowsでは、そのプラットフォームでの [`select.select()`](https://docs.python.org/3/library/select.html#select.select) の実装制限に応じて REPL が出力されます。

### `showmigrations`

#### `django-admin showmigrations [app_label [app_label ...]]`

プロジェクト内のすべてのマイグレーションを表示します。2つの形式から選択できます：

#### `--list, -l`

Django が知っている全てのアプリ、各アプリで利用可能なマイグレーション、各マイグレーションが適用されているかどうか（マイグレーション名の横に `[X]` と表示されます）を一覧表示します。また、 `--verbosity` が 2 以上の場合、適用された日時も表示されます。

マイグレーションのないアプリもリストアップされますが、その下に `(no migrations)` と表示されます。

これはデフォルトの出力形式です。

#### `--plan, -p`

Django が適用するマイグレーションの計画を表示します。 `list` と同様に、適用されたマイグレーションは `[X]` でマークされます。また、 `--verbosity` が 2 以上の場合、マイグレーションの全ての依存関係も表示されます。

`app_label` 引数によって出力は制限されますが、提供されたアプリの依存関係も含めることができます。

#### `--database DATABASE`

検査するデータベースを指定します。デフォルトは `default` です。

### `sqlflush`

#### `django-admin sqlflush`

[`flush`](#django-admin-flush) コマンドで実行される SQL 文を表示します。

#### `--database DATABASE`

SQLを表示するデータベースを指定します。デフォルトは `default` です。

### `sqlmigrate`

#### `django-admin sqlmigrate app_label migration_name`

指定された名前のマイグレーション用の SQL を出力します。これは、制約名の解決に使用するアクティブなデータベース接続を必要とします。つまり、後で適用したいデータベースのコピーに対して SQL を生成する必要があります。

`sqlmigrate` は出力に色をつけないことに注意してください。

#### `--backwards`

マイグレーションの適用を取り消すSQLを生成します。デフォルトでは、マイグレーションを順方向に実行するための SQL が生成されます。

#### `--database DATABASE`

SQL を生成するデータベースを指定します。デフォルトは `default` です。

### `sqlsequencereset`

#### `django-admin sqlsequencereset app_label [app_label ...]`

指定されたアプリ名のシーケンスをリセットする SQL 文を出力します。

シーケンスは、自動的にインクリメントされるフィールドの次に利用可能な番号を追跡するために、いくつかのデータベースエンジンで使用されるインデックスです。

このコマンドを使用して、シーケンスが自動的にインクリメントされたフィールドデータと同期していないケースを修正するSQLを生成できます。

#### `--database DATABASE`

SQLを表示するデータベースを指定します。デフォルトは `default` です。

### `squashmigrations`

#### `django-admin squashmigrations app_label [start_migration_name] migration_name`

`migration_name` までの `app_label` のマイグレーションを、可能であればより少ないマイグレーションにスカッシュします。スカッシュされたマイグレーションは、スカッシュされていないマイグレーションと安全に共存できます。詳しくは [マイグレーションのスカッシュ (Squash)](/ja/5.2/topics/migrations/#migration-squashing) を参照してください。

`start_migration_name` を指定すると、 Django はこのマイグレーションから始まり、このマイグレーションを含むマイグレーションだけを取り込みます。これは [`RunPython`](/ja/5.2/ref/migration-operations/#django.db.migrations.operations.RunPython) と [`django.db.migrations.operations.RunSQL`](/ja/5.2/ref/migration-operations/#django.db.migrations.operations.RunSQL) マイグレーション・オペレーションのスカッシュ制限を緩和するのに役立ちます。

#### `--no-optimize`

スカッシュされたマイグレーションを生成する際に、オプティマイザを無効にします。デフォルトでは、 Django はマイグレーションする際の処理を最適化し、結果のファイルサイズを小さくしようとします。この処理が失敗したり、正しくないマイグレーションを作成したりする場合は、このオプションを使ってください。最適化は安全であることを意図しているので、その動作について Django バグレポートを提出してください。

#### `--noinput, --no-input`

すべてのユーザープロンプトを表示しません。

#### `--squashed-name SQUASHED_NAME`

スカッシュされたマイグレーションの名前を設定します。省略した場合は、最初と最後のマイグレーションの間に `_squashed_` を加えた名前になります。

#### `--no-header`

Django のバージョンとタイムスタンプのヘッダなしで、スカッシュしたマイグレーションファイルを生成します。

### `startapp`

#### `django-admin startapp name [directory]`

指定されたアプリ名の Django アプリディレクトリ構造を、カレントディレクトリか、指定された保存先に作成します。

デフォルトでは、[新しいディレクトリ](https://github.com/django/django/blob/stable/5.2.x/django/conf/app_template) には `models.py` ファイルと他のアプリテンプレートファイルが含まれます。アプリ名だけが与えられた場合、アプリディレクトリは現在の作業ディレクトリに作成されます。

オプションで保存先を指定すると、 Django は新しいディレクトリを作成するのではなく、既存のディレクトリを使用します。現在の作業ディレクトリを表すには "." を使用してください。

例:

```console
django-admin startapp myapp /Users/jezdez/Code/myapp
```

#### `--template TEMPLATE`

カスタムアプリテンプレートファイルを含むディレクトリへのパス、または圧縮されていないアーカイブ (`.tar`) や圧縮されたアーカイブ (`.tar.gz`, `.tar.bz2`, `.tar.xz`, `.tar.lzma`, `.tgz`, `.tbz2`, `.txz`, `.tlz`, `.zip`) 内のアプリテンプレートファイルを含むパスを指定します。

たとえば、`myapp` アプリを作成するときに、指定されたディレクトリのアプリテンプレートを探すには以下のようにします：

```console
django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp
```

Djangoは、アプリテンプレートファイルを含む圧縮アーカイブへのURL (`http`、`https`、`ftp`) も受け付けることができ、それらをダウンロードしてリアルタイムで展開します。

たとえば、GitHub の zip ファイルとしてリポジトリを公開する機能を使えば、次のような URL を使うことができます：

```console
django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/main.zip myapp
```

> **Warning**
>
> `--template` で指定されたテンプレートはそのまま使用されます。悪意のある、あるいは不適切に作成されたテンプレートは、セキュリティ上の脆弱性や意図しない動作を引き起こす可能性があります。さらに、圧縮アーカイブは展開時に過剰なリソースを消費し、クラッシュやフリーズを引き起こすおそれがあります。
>
> テンプレートの内容は、使用する前に慎重に検査されるべきです。

#### `--extension EXTENSIONS, -e EXTENSIONS`

アプリテンプレート内のどの拡張子をテンプレートエンジンでレンダリングするかを指定します。デフォルトは `py` です。

#### `--name FILES, -n FILES`

(`--extension` にマッチするものに加えて) アプリテンプレート内のどのファイルをテンプレートエンジンでレンダリングするかを指定します。デフォルトは空のリストです。

#### `--exclude DIRECTORIES, -x DIRECTORIES`

`.git` と `__pycache__` に加えて、アプリテンプレート内のどのディレクトリを除外するかを指定します。このオプションを指定しない場合、`__pycache__` という名前のディレクトリや、`.` で始まるディレクトリは除外されます。

マッチする全てのファイルに使用される [`テンプレートコンテキスト`](/ja/5.2/ref/templates/api/#django.template.Context) は以下の通りです：

- `startapp` コマンドに渡されたオプション (コマンドでサポートされているオプションに限る)
- `app_name` -- コマンドに渡されたアプリ名
- `app_directory` -- 新規作成されたアプリのフルパス
- `camel_case_app_name` -- キャメルケース形式のアプリ名
- `docs_version` -- ドキュメントのバージョン: `'dev'` または `1.x'`
- `django_version` -- Django のバージョン、例えば `'2.0.3'` 。

> **Warning**
>
> アプリのテンプレートファイルが Django テンプレートエンジンでレンダリングされるとき (デフォルトではすべての `*.py` ファイル)、Django は含まれるすべての不明なテンプレート変数も置き換えます。たとえば、 Python ファイルの 1 つに、テンプレートレンダリングに関連する特定の機能を説明する docstring が含まれていた場合、間違った結果を生むかもしれません。
>
> この問題を回避するために、テンプレートタグ [`templatetag`](/ja/5.2/ref/templates/builtins/#std-templatetag-templatetag) を使ってテンプレートの構文の様々な部分を「エスケープ」することができます。
>
> さらに、パッケージングシステムが無効な `*.py` ファイルをバイトコンパイルしようとするのを防ぐと同時に、 Django テンプレート言語構文を含む Python テンプレートファイルを許可するために、 `.py-tpl` で終わるテンプレートファイルは `.py` にリネームされます。

> **Warning**
>
> カスタムアプリ（またはプロジェクト）テンプレートのコンテンツは、使用前に必ず監査されるべきです。 これらのテンプレートは、プロジェクトの一部となるコードを定義しており、これらのコードは、インストールしたアプリや自分で書いたコードと同じくらい信頼されることを意味します。さらに、テンプレートをレンダリングすることは、事実上、提供されたコードを管理コマンドへの入力として実行することにすらなります。Django のテンプレート言語は、システムへの広いアクセスを提供する可能性がありますので、使うカスタムテンプレートが信頼に値するものであることを確認してくだ さい。

### `startproject`

#### `django-admin startproject name [directory]`

指定されたプロジェクト名の Django プロジェクトディレクトリ構造を、カレントディレクトリか指定された保存先に作成します。

デフォルトでは、 [新しいディレクトリ](https://github.com/django/django/blob/stable/5.2.x/django/conf/project_template) には `manage.py` とプロジェクトパッケージ (`settings.py` と他のファイルを含む) があります。

プロジェクト名だけを指定した場合、プロジェクトディレクトリとプロジェクトパッケージは `<projectname>` という名前になり、プロジェクトディレクトリは現在の作業ディレクトリに作成されます。

オプションで保存先を指定すると、 Django はその既存のディレクトリをプロジェクトディレクトリとして使用し、 `manage.py` とその中にプロジェクトパッケージを作成します。現在の作業ディレクトリを表すには "." を使用してください。

例:

```console
django-admin startproject myproject /Users/jezdez/Code/myproject_repo
```

#### `--template TEMPLATE`

ディレクトリ、ファイルパス、またはカスタムプロジェクトテンプレートの URL を指定します。使用例については [`startapp --template`](#cmdoption-startapp-template) のドキュメントを参照してください。なお、 `startapp` テンプレートに関して説明されている **セキュリティ上の考慮事項** が同様に適用されます。すなわち、悪意のある、あるいは不適切に作成されたテンプレートは脆弱性をもたらしたり、過剰なリソースを消費する可能性があり、テンプレートは使用前に慎重に検査されるべきです。

#### `--extension EXTENSIONS, -e EXTENSIONS`

プロジェクトテンプレート内のどの拡張子をテンプレートエンジンでレンダリングするかを指定します。デフォルトは `py` です。

#### `--name FILES, -n FILES`

(`--extension` にマッチするものに加えて) プロジェクトテンプレート内のどのファイルをテンプレートエンジンでレンダリングするかを指定します。デフォルトは空のリストです。

#### `--exclude DIRECTORIES, -x DIRECTORIES`

`.git` と `__pycache__` に加えて、プロジェクトテンプレート内のどのディレクトリを除外するかを指定します。このオプションを指定しない場合、`__pycache__` という名前のディレクトリや、`.` で始まるディレクトリは除外されます。

使用される [`テンプレートコンテキスト`](/ja/5.2/ref/templates/api/#django.template.Context) は以下の通りです：

- `startproject` コマンドに渡されたオプション (コマンドでサポートされているオプションに限る)
- `project_name` -- コマンドに渡されたプロジェクト名
- `project_directory` -- 新規作成されたプロジェクトのフルパス
- `secret_key` -- [`SECRET_KEY`](/ja/5.2/ref/settings/#std-setting-SECRET_KEY) 設定用のランダムなキー。
- `docs_version` -- ドキュメントのバージョン: `'dev'` または `1.x'`
- `django_version` -- Django のバージョン、例えば `'2.0.3'` 。

[`startapp`](#django-admin-startapp) で説明した [レンダリングに関する警告](#render-warning) と [信頼されたコードに関する警告](#trusted-code-warning) も参照してください。

### `test`

#### `django-admin test [test_label [test_label ...]]`

インストールされている全てのアプリのテストを実行します。詳しくは [Django におけるテスト](/ja/5.2/topics/testing/) を参照してください。

#### `--failfast`

テストが失敗したら直ちにテストの実行を停止し、失敗を報告します。

#### `--testrunner TESTRUNNER`

テストの実行に使われるテストランナークラスを制御します。この値は [`TEST_RUNNER`](/ja/5.2/ref/settings/#std-setting-TEST_RUNNER) 設定によって提供される値を上書きします。

#### `--noinput, --no-input`

すべてのユーザープロンプトを表示しません。典型的なプロンプトは、既存のテストデータベースの削除に関する警告です。

#### テストランナーのオプション

`test` コマンドは指定された [`--testrunner`](#cmdoption-test-testrunner) の代わりにオプションを受け取ります。これらはデフォルトのテストランナーである [`DiscoverRunner`](/ja/5.2/topics/testing/advanced/#django.test.runner.DiscoverRunner) のオプションです。

#### `--keepdb`

テスト実行の間、テストデータベースを保持します。これには、作成と破棄の両方のアクションを省略できるという利点があり、 特に大規模なテストスイートにおけるテストの実行時間を大幅に短縮できます。テストデータベースが存在しない場合は、最初の実行時に作成され、それ以降の実行時に保存されます。[`MIGRATE`](/ja/5.2/ref/settings/#std-setting-TEST_MIGRATE) テスト設定が `False` でない限り、テストスイートを実行する前に、未適用のマイグレーションもテストデータベースに適用されます。

#### `--shuffle [SEED]`

テストを実行する前に、テストの順番をランダムにします。これは、適切に分離されていないテストの検出に役立ちます。このオプションで生成されるテストの順番は、 与えられた整数シードの決定論的な関数です。シードが渡されない場合は、ランダムにシードが選ばれてコンソールに出力されます。特定のテスト順序を繰り返すには、シードを渡します。このオプションで生成されるテスト順序は Django の [テスト順序における保証](/ja/5.2/topics/testing/overview/#order-of-tests) を保持します。また、テストはテストケースクラスごとにグループ化されます。

シャッフルされた順序は、分離の問題を絞り込む際に有用な特別な一貫性を持っています。つまり、シードを指定してテストのサブセットを実行する場合、新しい順序はより小さなセットに制限されつつ、元のシャッフル順序を維持します。同様に、シードを同じに保ちながらテストを追加すると、元のテストの順序は新しい順序でも同じままです。

#### `--reverse, -r`

テストケースを逆の実行順序で並べ替えます。これは適切に分離されていないテストの副作用をデバッグする際に役立つかもしれません。 [テストクラス](/ja/5.2/topics/testing/overview/#order-of-tests) によるグループ化は、このオプションを使用しても保持されます。 `--shuffle` と組み合わせて使用することで、特定のシードの順番を逆にできます。

#### `--debug-mode`

テストを実行する前に [`DEBUG`](/ja/5.2/ref/settings/#std-setting-DEBUG) 設定を `True` に設定します。これはテストの失敗のトラブルシューティングに役立ちます。

#### `--debug-sql, -d`

失敗したテストの [SQL ロギング](/ja/5.2/ref/logging/#django-db-logger) を有効にします。もし `--verbosity` が `2` なら、パスしたテストのクエリも出力されます。

#### `--parallel [N]`

#### `DJANGO_TEST_PROCESSES`

別々の並列プロセスでテストを実行します。現代のプロセッサは複数のコアを備えているため、これによってテストの実行速度を大幅に向上させることができます。

値を指定せずに `--parallel` を使用した場合、または値 `auto` を指定した場合、 [`multiprocessing.cpu_count()`](https://docs.python.org/3/library/multiprocessing.html#multiprocessing.cpu_count) に従って各コアに 1 つのテストプロセスを実行します。これをオーバーライドするには、必要なプロセス数、たとえば `--parallel 4` を渡すか、 [`DJANGO_TEST_PROCESSES`](#envvar-DJANGO_TEST_PROCESSES) 環境変数を設定します。

Django はテストケース ([`unittest.TestCase`](https://docs.python.org/3/library/unittest.html#unittest.TestCase) サブクラス) をサブプロセスに分散します。設定されたプロセス数よりもテストケースクラスの数が少ない場合、 Django はそれに応じてプロセス数を減らします。

各プロセスごとに個別のデータベースを持つため、異なるテストケースクラスが同じリソースにアクセスしないように注意が必要です。たとえば、複数のテストケースクラスがファイルシステムにアクセスするような場合には、各テストケースクラスごとに個別に一時ディレクトリを作成するようにしてください。

> **Note**
>
> 並列で実行できないテストクラスがある場合は、 `SerializeMixin` を使って逐次的に実行できます。 [テストクラスの逐次実行を強制する](/ja/5.2/topics/testing/advanced/#topics-testing-enforce-run-sequentially) を参照してください。

このオプションはトレースバックを正しく表示するために、サードパーティの `tblib` パッケージが必要です：

```console
$ python -m pip install tblib
```

この機能はWindowsでは使用できません。Oracleデータベースのバックエンドでも動作しません。

テストのデバッグ中に [`pdb`](https://docs.python.org/3/library/pdb.html#module-pdb) を使用したい場合は、並列実行を無効にする必要があります (`--parallel=1`) 。そうしないと `bdb.BdbQuit` のようなメッセージが表示されます。

> **Warning**
>
> テストの並列化が有効で、テストが失敗した場合、 Django は例外のトレースバックを表示できないかもしれません。これはデバッグを困難にします。この問題に遭遇した場合は、並列化せずに該当するテストを実行して、失敗のトレースバックを確認してください。
>
> これは既知の制限です。これは、プロセス間でオブジェクトを交換するためにオブジェクトをシリアライズする必要があることから生じます。詳しくは [What can be pickled and unpickled?](https://docs.python.org/3/library/pickle.html#pickle-picklable) を参照してください。

#### `--tag TAGS`

[指定したタグ](/ja/5.2/topics/testing/tools/#topics-tagging-tests) でマークされたテストのみを実行します。[`test --exclude-tag`](#cmdoption-test-exclude-tag) と組み合わせて複数回指定できます。

ロードに失敗したテストは常にマッチしたとみなされます。

#### `--exclude-tag EXCLUDE_TAGS`

[指定したタグ](/ja/5.2/topics/testing/tools/#topics-tagging-tests) でマークされたテストを除外します。[`test --tag`](#cmdoption-test-tag) と組み合わせて複数回指定できます。

#### `-k TEST_NAME_PATTERNS`

[`unittest の -k オプション`](https://docs.python.org/3/library/unittest.html#cmdoption-unittest-k) と同じように、テスト名のパターンにマッチするテストメソッドとクラスを実行します。複数回指定できます。

#### `--pdb`

テストのエラーや失敗のたびに `pdb` デバッガを起動します。インストールされている場合は、代わりに `ipdb` が使用されます。

#### `--buffer, -b`

[`unittest の --buffer オプション`](https://docs.python.org/3/library/unittest.html#cmdoption-unittest-b) と同じように、テストに合格した出力 (`stdout` と `stderr`) を破棄します。

#### `--no-faulthandler`

Django はテストの開始時に [`faulthandler.enable()`](https://docs.python.org/3/library/faulthandler.html#faulthandler.enable) を自動的に呼び出します。これにより、インタプリタがクラッシュした場合にトレースバックを表示します。この動作を無効にするには `--no-faulthandler` を渡してください。

#### `--timing`

データベースのセットアップや総実行時間などのタイミングを出力します。

#### `--durations N`

最も遅い N 個のテストケースを表示します（N=0 の場合はすべて）。

> **Python 3.12 以降が必要です**
>
> この機能は Python 3.12 以降でのみ利用可能です。

### `testserver`

#### `django-admin testserver [fixture [fixture ...]]`

([`runserver`](#django-admin-runserver) のように) 与えられたフィクスチャのデータを使って Django 開発サーバを起動します。

たとえばこのコマンドは、：

```console
django-admin testserver mydata.json
```

... 以下のステップを実行します：

1. [test データベース](/ja/5.2/topics/testing/overview/#the-test-database) で説明されているように、テスト用データベースを作成します。
2. 与えられたフィクスチャからフィクスチャデータをテストデータベースに投入します。(フィクスチャの詳細については、上記の [`loaddata`](#django-admin-loaddata) のドキュメントを参照してください)。
3. Django 開発サーバを実行します ([`runserver`](#django-admin-runserver) のように)。本番用データベースの代わりに、新しく作成したテスト用データベースを指定します。

これはいろいろな面で便利です：

- [ユニットテスト](/ja/5.2/topics/testing/overview/) を書くとき、フィクスチャデータを使ってビューがどのように動作するか、 `testserver` を使ってウェブブラウザでビューと手動でやりとりできます。
- Django アプリケーションを開発していて、対話したいデータベースの "まっさらな" コピーがあるとします。データベースを [フィクスチャ](/ja/5.2/topics/db/fixtures/#fixtures-explanation) にダンプし (上で説明した [`dumpdata`](#django-admin-dumpdata) コマンドを使います)、そのデータを使って `testserver` で Web アプリケーションを実行します。この方法では、どんなデータの変更もテスト用のデータベースに対してだけ行われるため、柔軟にデータを変更できます。

このサーバは Python のソースコードの変更を ([`runserver`](#django-admin-runserver) のように) 自動的に検出することは **しない** ことに注意してください。しかし、テンプレートの変更は検出します。

#### `--addrport ADDRPORT`

デフォルトの `127.0.0.1:8000` とは異なるポート、または IP アドレスとポートを指定します。この値は [`runserver`](#django-admin-runserver) コマンドの引数と全く同じフォーマットで、全く同じ機能を果たします。

例:

ポート7000で `fixture1` と `fixture2` を使ってテストサーバを動かすには、以下のようにします：

```console
django-admin testserver --addrport 7000 fixture1 fixture2
django-admin testserver fixture1 fixture2 --addrport 7000
```

（上の2つは等価です。オプションがフィクスチャの引数の前でも後でも問題ないことを示すために、この2つを紹介しています）

1.2.3.4:7000 で `test` フィクスチャを使って実行するには、下記のようにします：

```console
django-admin testserver --addrport 1.2.3.4:7000 test
```

#### `--noinput, --no-input`

すべてのユーザープロンプトを表示しません。典型的なプロンプトは、既存のテストデータベースの削除に関する警告です。

## アプリケーションが提供するコマンド

いくつかのコマンドは、それを [実装した](/ja/5.2/howto/custom-management-commands/) `django.contrib` アプリケーションが [`有効に`](/ja/5.2/ref/settings/#std-setting-INSTALLED_APPS) なっていないと利用できません。この節では、それらをアプリケーションごとに分類して説明します。

### `django.contrib.auth`

#### `changepassword`

#### `django-admin changepassword [<username>]`

このコマンドは Django の [認証システム](/ja/5.2/topics/auth/) (`django.contrib.auth`) がインストールされている場合のみ利用できます。

ユーザのパスワードを変更できます。指定されたユーザの新しいパスワードを2回入力するよう求められます。入力が同じであれば、これが直ちに新しいパスワードになります。ユーザを指定しなかった場合、コマンドはユーザ名が現在のユーザと一致するパスワードを変更しようとします。

#### `--database DATABASE`

ユーザーをクエリするデータベースを指定します。デフォルトは `default` です。

使用例:

```console
django-admin changepassword ringo
```

#### `createsuperuser`

#### `django-admin createsuperuser`

#### `DJANGO_SUPERUSER_PASSWORD`

このコマンドは Django の [認証システム](/ja/5.2/topics/auth/) (`django.contrib.auth`) がインストールされている場合のみ利用できます。

superuser アカウント (すべての権限を持ったユーザー) を作成します。このコマンドは、最初に superuser アカウントを作成する場合や、サイトの superuser アカウントをプログラムから自動生成する必要がある場合に便利です。

対話的に実行すると、このコマンドは新しいスーパーユーザアカウントのパスワードを要求します。非対話的に実行する場合、 [`DJANGO_SUPERUSER_PASSWORD`](#envvar-DJANGO_SUPERUSER_PASSWORD) 環境変数を設定することでパスワードを設定できます。そうでない場合、パスワードは設定されず、スーパーユーザーアカウントはパスワードが手動で設定されるまでログインできません。

非インタラクティブモードでは、 [`USERNAME_FIELD`](/ja/5.2/topics/auth/customizing/#django.contrib.auth.models.CustomUser.USERNAME_FIELD) と必須フィールド ([`REQUIRED_FIELDS`](/ja/5.2/topics/auth/customizing/#django.contrib.auth.models.CustomUser.REQUIRED_FIELDS) にリストされています) はコマンドライン引数で上書きされない限り、環境変数 `DJANGO_SUPERUSER_<uppercase_field_name>` にフォールバックします。例えば、 `email` フィールドを指定するには、環境変数 `DJANGO_SUPERUSER_EMAIL` を使用します。

#### `--noinput, --no-input`

すべてのユーザープロンプトを表示しません。もし、抑制されたプロンプトが自動的に解決できなかった場合は、エラーコード 1 で終了します。

#### `--username USERNAME`

#### `--email EMAIL`

新しいアカウントのユーザー名とメールアドレスはコマンドラインの `--username` と `--email` 引数で指定できます。これらのどちらかが与えられない場合、 `createsuperuser` は対話的に実行する際にその入力を要求します。

#### `--database DATABASE`

スーパーユーザ・オブジェクトを保存するデータベースを指定します。

データの入力とバリデーションをカスタマイズしたい場合は、管理コマンドをサブクラス化して `get_input_data()` をオーバーライドします。既存の実装やメソッドのパラメータの詳細についてはソースコードを参照してください。たとえば、[`REQUIRED_FIELDS`](/ja/5.2/topics/auth/customizing/#django.contrib.auth.models.CustomUser.REQUIRED_FIELDS) に `ForeignKey` があり、既存のインスタンスの主キーを入力する代わりにインスタンスを作成できるようにしたい場合に便利です。

### `django.contrib.contenttypes`

#### `remove_stale_contenttypes`

#### `django-admin remove_stale_contenttypes`

このコマンドは Django の [contenttypes アプリ](/ja/5.2/ref/contrib/contenttypes/) ([`django.contrib.contenttypes`](/ja/5.2/ref/contrib/contenttypes/#module-django.contrib.contenttypes)) がインストールされている場合のみ利用できます。

（削除されたモデルの）古くなったコンテンツタイプをデータベースから削除します。削除されたコンテンツタイプに依存しているオブジェクトも削除されます。削除されたオブジェクトのリストが表示された後、削除を続行できます。

#### `--database DATABASE`

使用するデータベースを指定します。デフォルトは `default` です。

#### `--include-stale-apps`

[`INSTALLED_APPS`](/ja/5.2/ref/settings/#std-setting-INSTALLED_APPS) から削除された、以前にインストールされたアプリのものを含む、古くなったコンテンツタイプを削除します。デフォルトは `False` です。

### `django.contrib.gis`

#### `ogrinspect`

このコマンドは、[GeoDjango](/ja/5.2/ref/contrib/gis/) (`django.contrib.gis`) がインストールされている場合のみ使用できます。

GeoDjango のドキュメントの [`description`](/ja/5.2/ref/contrib/gis/commands/#django-admin-ogrinspect) を参照してください。

### `django.contrib.sessions`

#### `clearsessions`

#### `django-admin clearsessions`

cron job に設定したり、直接実行することで、期限切れのセッションを削除できます。

### `django.contrib.staticfiles`

#### `collectstatic`

このコマンドは [static files アプリケーション](/ja/5.2/howto/static-files/) (`django.contrib.staticfiles`) がインストールされている場合のみ使用できます。

[staticfiles](/ja/5.2/ref/contrib/staticfiles/) ドキュメントの [`description`](/ja/5.2/ref/contrib/staticfiles/#django-admin-collectstatic) を参照してください。

#### `findstatic`

このコマンドは [static files アプリケーション](/ja/5.2/howto/static-files/) (`django.contrib.staticfiles`) がインストールされている場合のみ使用できます。

[staticfiles](/ja/5.2/ref/contrib/staticfiles/) ドキュメントの [`description`](/ja/5.2/ref/contrib/staticfiles/#django-admin-findstatic) を参照してください。

## デフォルトのオプション

コマンドによっては独自のカスタムオプションを使用できるものもありますが、どのコマンドでもデフォルトでは以下のオプションが使用できます：

#### `--pythonpath PYTHONPATH`

与えられたファイルシステムのパスを Python [`sys.path`](https://docs.python.org/3/library/sys.html#sys.path) モジュール属性に追加します。これが指定されていない場合、`django-admin` は [`PYTHONPATH`](https://docs.python.org/3/using/cmdline.html#envvar-PYTHONPATH) 環境変数を使用します。

このオプションは `manage.py` では不要です。Python のパスの設定は `manage.py` が行ってくれるからです。

使用例:

```console
django-admin migrate --pythonpath='/home/djangoprojects/myproject'
```

#### `--settings SETTINGS`

使用する設定モジュールを指定します。設定モジュールは Python パッケージの構文である必要があります (例: `mysite.settings`)。これが指定されていない場合、 `django-admin` は [`DJANGO_SETTINGS_MODULE`](/ja/5.2/topics/settings/#envvar-DJANGO_SETTINGS_MODULE) 環境変数を使用します。

このオプションは `manage.py` では不要です。デフォルトでは現在のプロジェクトの `settings.py` を使用するからです。

使用例:

```console
django-admin migrate --settings=mysite.settings
```

#### `--traceback`

[`CommandError`](/ja/5.2/howto/custom-management-commands/#django.core.management.CommandError) が発生した場合、完全なスタックトレースを表示します。デフォルトでは、 `django-admin` は `CommandError` が発生するとエラーメッセージを表示し、それ以外の例外が発生すると完全なスタックトレースを表示します。

このオプションは [`runserver`](#django-admin-runserver) では無視されます。

使用例:

```console
django-admin migrate --traceback
```

#### `--verbosity {0,1,2,3}, -v {0,1,2,3}`

コマンドがコンソールに表示する通知とデバッグ情報の量を指定します。

- `0` は出力なしを意味します。
- `1` は通常の出力を意味します（デフォルト）。
- `2` は詳細な出力を意味します。
- `3` は *非常に* 詳細な出力を意味します。

このオプションは [`runserver`](#django-admin-runserver) では無視されます。

使用例:

```console
django-admin migrate --verbosity 2
```

#### `--no-color`

カラー表示されたコマンドの出力を無効にします。一部のコマンドは、出力をカラー表示するようにフォーマットされます。たとえば、エラーは赤色でコンソールに表示され、SQL文はシンタックスハイライトされます。

使用例:

```console
django-admin runserver --no-color
```

#### `--force-color`

[シンタックスカラーリング](#syntax-coloring) で説明されているように、コマンドの出力が無効になる場合でも出力のカラー表示を強制します。例えば、色付きの出力を別のコマンドにパイプしたい場合などに使用します。

#### `--skip-checks`

コマンドを実行する前のシステムチェックをスキップします。このオプションは [`requires_system_checks`](/ja/5.2/howto/custom-management-commands/#django.core.management.BaseCommand.requires_system_checks) コマンド属性が空のリストやタプルでない場合にだけ有効です。

使用例:

```console
django-admin migrate --skip-checks
```

## 追加の便利機能

### シンタックスカラーリング

#### `DJANGO_COLORS`

`django-admin` / `manage.py` コマンドは、ターミナルが ANSI カラー出力をサポートしている場合、色分けされた出力を使用します。 [`--force-color`](#cmdoption-force-color) オプションが使用されていない限り、コマンドの出力を他のプログラムにパイプしてもカラー出力は使用されません。

#### Windows でのサポート

Windows 10 では、 [Windows Terminal](https://www.microsoft.com/en-us/p/windows-terminal-preview/9n0dx20hk701) アプリケーション、 [VS Code](https://code.visualstudio.com) 、および PowerShell (仮想ターミナル処理が有効になっている場合) では色付きの出力が可能で、デフォルトでサポートされています。

Windows では、レガシーの `cmd.exe` ネイティブコンソールは ANSI エスケープシーケンスをサポートしていないため、デフォルトではカラー出力ができません。この場合、2つのサードパーティライブラリのどちらかが必要になります：

- [colorama](https://pypi.org/project/colorama/) は、ANSI カラーコードを Windows API 呼び出しに変換する Python パッケージです。Django のコマンドはこのパッケージの存在を検出し、Unix ベースのプラット フォームと同じように、このパッケージのサービスを利用して出力に色をつけます。 `colorama` は pip でインストールできます：

  ```doscon
  ...\> py -m pip install "colorama >= 0.4.6"
  ```
- [ANSICON](http://adoxa.altervista.org/ansicon/) をインストールします。これは、 `cmd.exe` が ANSI カラーコードを処理できるようにするサードパーティツールです。Django のコマンドはこのツールの存在を検出し、Unix ベースのプラットフォームと同じように、このツールのサービスを利用して出力に色をつけます。

ターミナルカラーをサポートしているが、Django がサポートしていることを自動的に検出しない Windows の他のモダンなターミナル環境では、 `ANSICON="on"` という適切な環境変数を設定することで、 `ANSICON` のインストールを「偽装」することができます。

#### カラーをカスタマイズする

シンタックスハイライトに使う色はカスタマイズできます。Django には 3 つのカラーパレットが同梱されています：

- `dark`, 黒い背景に白いテキストを表示する端末に適しています。これはデフォルトのパレットです。
- `light`, これは白い背景に黒いテキストを表示する端末に適しています。
- `nocolor`, これはシンタックスハイライトを無効にします。

パレットを選択するには [`DJANGO_COLORS`](#envvar-DJANGO_COLORS) 環境変数を設定して使用したいパレットを指定します。例えば、UnixやOS/XのBASHシェルで `light` パレットを指定するには、ターミナルで以下のように実行します：

```shell
export DJANGO_COLORS="light"
```

使用する色をカスタマイズすることもできます。Django は色が使われる役割（ロール）をいくつか指定しています：

- `error` \- 主なエラー。
- `notice` \- 軽微なエラー。
- `success` \- 成功。
- `warning` \- 警告。
- `sql_field` \- SQL のモデルフィールドの名前。
- `sql_coltype` \- SQL のモデルフィールドの型。
- `sql_keyword` \- SQLキーワード。
- `sql_table` \- SQL 内のモデルの名前。
- `http_info` \- 1XX HTTP Informational サーバーレスポンス。
- `http_success` \- 2XX HTTP Success サーバーレスポンス。
- `http_not_modified` \- 304 HTTP Not Modified サーバーレスポンス。
- `http_redirect` \- 304以外の3XX HTTPリダイレクトサーバーレスポンス。
- `http_not_found` \- 404 HTTP Not Found サーバーレスポンス。
- `http_bad_request` \- 404 以外の 4XX HTTP Bad Request サーバーレスポンス。
- `http_server_error` \- 5XX HTTP サーバーエラー。
- `migrate_heading` \- マイグレーション管理コマンドの見出し。
- `migrate_label` \- マイグレーション名。

これらの各ロールには、以下のリストから特定の前景色と背景色を割り当てることができます：

- `black`
- `red`
- `green`
- `yellow`
- `blue`
- `magenta`
- `cyan`
- `white`

これらの色はそれぞれ、以下の表示オプションを使って変更できます：

- `bold`
- `underscore`
- `blink`
- `reverse`
- `conceal`

色の指定は、次のいずれかのパターンに従います：

- `role=fg`
- `role=fg/bg`
- `role=fg,option,option`
- `role=fg/bg,option,option`

ここで `role` は有効な色の役割の名前、 `fg` は描画色、 `bg` は背景色、そしてそれぞれの `option` は色を変更するオプションの一つです。複数の色の指定はセミコロンで区切ります。たとえば以下のようにします：

```shell
export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"
```

これを指定すると、エラーは青地に黄色の点滅で表示され、通知はマゼンタで表示されます。それ以外の色の役割には色を付けません。

色はベースパレットを拡張して指定することもできます。色指定にパレット名を入れると、そのパレットが意味するすべての色が読み込まれます。つまり：

```shell
export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"
```

これを指定すると、light カラーパレットのすべての色の使用が指定されますが、error と notice の色は指定どおりにオーバーライドされます。

### Bash による補完

Bash シェルを使用している場合は、Django bash 補完スクリプトのインストールを検討してください。スクリプトは Django のソース配布元の [extras/django\_bash\_completion](https://github.com/django/django/blob/stable/5.2.x/extras/django_bash_completion) にあります。このスクリプトを使うと、`django-admin` と `manage.py` コマンドで tab キーによる補完が有効になります。使い方を説明すると、

- まず、`django-admin` とタイプします。
- \[TAB\] キーをクリックし、利用できるオプション一覧を表示します。
- `sql` とタイプし、\[TAB\] キーを押すと、名前が `sql` で始まるオプション一覧が表示されます。

独自のカスタムアクションを追加したい場合は、[カスタム django-admin コマンドの作り方](/ja/5.2/howto/custom-management-commands/) を読んでください。

### Black フォーマッタ

[`startproject`](#django-admin-startproject), [`startapp`](#django-admin-startapp), [`optimizemigration`](#django-admin-optimizemigration), [`makemigrations`](#django-admin-makemigrations), [`squashmigrations`](#django-admin-squashmigrations) によって作成された Python ファイルは、 `black` コマンドが `PATH` にあれば、それを使ってフォーマットされます。

もし `black` がグローバルにインストールされているが、現在のプロジェクトで使用したくない場合は、 `PATH` を明示的に設定できます：

```shell
PATH=path/to/venv/bin django-admin makemigrations
```

`stdout` を使用するコマンドでは、必要に応じて出力を `black` にパイプできます：

```shell
django-admin inspectdb | black -
```

# コードから管理コマンドを実行する

#### `django.core.management.call_command(name, *args, **options)`

コードから管理コマンドを呼び出すには `call_command()` を使います。

**`name`**

  呼び出すコマンドの名前またはコマンド・オブジェクト。オブジェクトがテストに必要でない限り、名前を渡すことが望ましいです。

**`*args`**

  コマンドが受け付ける引数のリスト。引数は引数パーサに渡されるので、コマンドラインと同じスタイルで使用できます。たとえば、`call_command('flush', '--verbosity=0')` のようにします。

**`**options`**

  コマンドラインで受け付ける名前付きオプション。オプションは引数パーサを起動することなくコマンドに渡されるため、正しい型を渡す必要があります。例えば、`call_command('flush', verbosity=0)` (ゼロは文字列ではなく整数でなければなりません)。

例:

```
from django.core import management
from django.core.management.commands import loaddata

management.call_command("flush", verbosity=0, interactive=False)
management.call_command("loaddata", "test_data", verbosity=0)
management.call_command(loaddata.Command(), "test_data", verbosity=0)
```

上の `interactive` オプションのように、引数を取らないコマンドオプションはキーワードとして `True` または `False` で渡されることに注意してください。

名前付き引数は、以下の構文のいずれかを使って渡すことができます：

```
# Similar to the command line
management.call_command("dumpdata", "--natural-foreign")

# Named argument similar to the command line minus the initial dashes and
# with internal dashes replaced by underscores
management.call_command("dumpdata", natural_foreign=True)

# `use_natural_foreign_keys` is the option destination variable
management.call_command("dumpdata", use_natural_foreign_keys=True)
```

コマンドオプションの中には、 `djangoo-admin` や `manage.py` の代わりに `call_command()` を使用すると異なる名前になるものがあります。たとえば、 `django-admin createsuperuser --no-input` は `call_command('createsuperuser', interactive=False)` となります。 `call_command()` で使用するキーワード引数名を調べるには、コマンドのソースコードで `parser.add_argument()` に渡される `dest` 引数を確認してください。

複数のオプションを取るコマンドオプションは、リストで渡します：

```
management.call_command("dumpdata", exclude=["contenttypes", "auth"])
```

`call_command()` 関数の戻り値は、コマンドの `handle()` メソッドの戻り値と同じです。

## 出力のリダイレクト

すべてのコマンドは `stdout` と `stderr` オプションをサポートしているので、標準出力やエラーのストリームはリダイレクトできます。例えば、次のように書くことができます：

```
with open("/path/to/command_output", "w") as f:
    management.call_command("dumpdata", stdout=f)
```