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

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

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

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

通常、単体の Django プロジェクトを用いる場合、`django-admin` よりも `manage.py` の方が簡単に利用できます。もし複数の Django 設定ファイル間での切り替えが必要な場合は、`django-admin` を [`DJANGO_SETTINGS_MODULE`](/ja/4.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/4.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/4.2/ref/checks/) を使用して、Django プロジェクト全体のよくある問題を検査します。

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

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

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

システムチェック フレームワークは、:ref:タグでカテゴリ化された \<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/4.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/4.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) をコンパイルされたファイルに含めます

Example usage:

```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) スタイルのパターンに一致するディレクトリを無視します。 何度も無視するためには複数回使用してください。

Example usage:

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

### `createcachetable`

#### `django-admin createcachetable`

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

#### `--database DATABASE`

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

#### `--dry-run`

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

### `dbshell`

#### `django-admin dbshell`

[`USER`](/ja/4.2/ref/settings/#std-setting-USER) や [`PASSWORD`](/ja/4.2/ref/settings/#std-setting-PASSWORD) などの設定で指定されたコネクション パラメータを使用して、[`ENGINE`](/ja/4.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**
>
> 必ずしもデータベース設定の [`OPTIONS`](/ja/4.2/ref/settings/#std-setting-OPTIONS) 部分で指定されたすべてのオプションがコマンドライン クライアントに渡されるわけではないことに注意してください (例: `'isolation_level'`)。

### `diffsettings`

#### `django-admin diffsettings`

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

デフォルトに現れない設定には `"###"` が続きます。たとえば、デフォルト設定が [`ROOT_URLCONF`](/ja/4.2/ref/settings/#std-setting-ROOT_URLCONF) を定義していない場合、`diffsettings` の出力内の [`ROOT_URLCONF`](/ja/4.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/4.2/howto/initial-data/#initial-data-via-fixtures) として活用できます。

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

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

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

#### `--format FORMAT`

出力のシリアル化フォーマットを指定します。デフォルトは JSON です。対応フォーマットは [Serialization formats](/ja/4.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` オブジェクトをダンプする場合、おそらくこのフラグを使う必要があります。このオプションと次のオプションの詳細については、[natural keys](/ja/4.2/topics/serialization/#topics-serialization-natural-keys) ドキュメントを見てください。

#### `--natural-primary`

Omits the primary key in the serialized data of this object since it can be
calculated during deserialization.

#### `--pks PRIMARY_KEYS`

Outputs only the objects specified by a comma separated list of primary keys.
This is only available when dumping one model. By default, all the records of
the model are output.

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

Specifies a file to write the serialized data to. By default, the data goes to
standard output.

When this option is set and `--verbosity` is greater than 0 (the default), a
progress bar is shown in the terminal.

#### Fixtures compression

The output file can be compressed with one of the `bz2`, `gz`, `lzma`, or
`xz` formats by ending the filename with the corresponding extension.
For example, to output the data as a compressed JSON file:

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

### `flush`

#### `django-admin flush`

Removes all data from the database and re-executes any post-synchronization
handlers. The table of which migrations have been applied is not cleared.

If you would rather start from an empty database and rerun all migrations, you
should drop and recreate the database and then run [`migrate`](#django-admin-migrate) instead.

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

Suppresses all user prompts.

#### `--database DATABASE`

Specifies the database to flush. Defaults to `default`.

### `inspectdb`

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

Introspects the database tables in the database pointed-to by the
[`NAME`](/ja/4.2/ref/settings/#std-setting-NAME) setting and outputs a Django model module (a `models.py`
file) to standard output.

You may choose what tables or views to inspect by passing their names as
arguments. If no arguments are provided, models are created for views only if
the [`--include-views`](#cmdoption-inspectdb-include-views) option is used. Models for partition tables are
created on PostgreSQL if the [`--include-partitions`](#cmdoption-inspectdb-include-partitions) option is used.

Use this if you have a legacy database with which you'd like to use Django.
The script will inspect the database and create a model for each table within
it.

As you might expect, the created models will have an attribute for every field
in the table. Note that `inspectdb` has a few special cases in its field-name
output:

- If `inspectdb` cannot map a column's type to a model field type, it'll
  use `TextField` and will insert the Python comment
  `'This field type is a guess.'` next to the field in the generated
  model. The recognized fields may depend on apps listed in
  [`INSTALLED_APPS`](/ja/4.2/ref/settings/#std-setting-INSTALLED_APPS). For example, [`django.contrib.postgres`](/ja/4.2/ref/contrib/postgres/#module-django.contrib.postgres) adds
  recognition for several PostgreSQL-specific field types.
- If the database column name is a Python reserved word (such as
  `'pass'`, `'class'` or `'for'`), `inspectdb` will append
  `'_field'` to the attribute name. For example, if a table has a column
  `'for'`, the generated model will have a field `'for_field'`, with
  the `db_column` attribute set to `'for'`. `inspectdb` will insert
  the Python comment
  `'Field renamed because it was a Python reserved word.'` next to the
  field.

This feature is meant as a shortcut, not as definitive model generation. After
you run it, you'll want to look over the generated models yourself to make
customizations. In particular, you'll need to rearrange models' order, so that
models that refer to other models are ordered properly.

Django doesn't create database defaults when a
[`default`](/ja/4.2/ref/models/fields/#django.db.models.Field.default) is specified on a model field.
Similarly, database defaults aren't translated to model field defaults or
detected in any fashion by `inspectdb`.

By default, `inspectdb` creates unmanaged models. That is, `managed = False`
in the model's `Meta` class tells Django not to manage each table's creation,
modification, and deletion. If you do want to allow Django to manage the
table's lifecycle, you'll need to change the
[`managed`](/ja/4.2/ref/models/options/#django.db.models.Options.managed) option to `True` (or remove
it because `True` is its default value).

#### Database-specific notes

##### Oracle

- Models are created for materialized views if [`--include-views`](#cmdoption-inspectdb-include-views) is
  used.

##### PostgreSQL

- Models are created for foreign tables.
- Models are created for materialized views if
  [`--include-views`](#cmdoption-inspectdb-include-views) is used.
- Models are created for partition tables if
  [`--include-partitions`](#cmdoption-inspectdb-include-partitions) is used.

#### `--database DATABASE`

Specifies the database to introspect. Defaults to `default`.

#### `--include-partitions`

If this option is provided, models are also created for partitions.

Only support for PostgreSQL is implemented.

#### `--include-views`

If this option is provided, models are also created for database views.

### `loaddata`

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

Searches for and loads the contents of the named
[fixture](/ja/4.2/topics/db/fixtures/#fixtures-explanation) into the database.

#### `--database DATABASE`

Specifies the database into which the data will be loaded. Defaults to
`default`.

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

Ignores fields and models that may have been removed since the fixture was
originally generated.

#### `--app APP_LABEL`

Specifies a single app to look for fixtures in rather than looking in all apps.

#### `--format FORMAT`

Specifies the [serialization format](/ja/4.2/topics/serialization/#serialization-formats) (e.g.,
`json` or `xml`) for fixtures [read from stdin](#loading-fixtures-stdin).

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

Excludes loading the fixtures from the given applications and/or models (in the
form of `app_label` or `app_label.ModelName`). Use the option multiple
times to exclude more than one app or model.

#### Loading fixtures from `stdin`

You can use a dash as the fixture name to load input from `sys.stdin`. For
example:

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

When reading from `stdin`, the [`--format`](#cmdoption-loaddata-format) option
is required to specify the [serialization format](/ja/4.2/topics/serialization/#serialization-formats)
of the input (e.g., `json` or `xml`).

Loading from `stdin` is useful with standard input and output redirections.
For example:

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

The [`dumpdata`](#django-admin-dumpdata) command can be used to generate input for `loaddata`.

> **See also**
>
> For more detail about fixtures see the [フィクスチャー](/ja/4.2/topics/db/fixtures/#fixtures-explanation) topic.

### `makemessages`

#### `django-admin makemessages`

Runs over the entire source tree of the current directory and pulls out all
strings marked for translation. It creates (or updates) a message file in the
conf/locale (in the Django tree) or locale (for project and application)
directory. After making changes to the messages files you need to compile them
with [`compilemessages`](#django-admin-compilemessages) for use with the builtin gettext support. See
the [i18n documentation](/ja/4.2/topics/i18n/translation/#how-to-create-language-files) for details.

This command doesn't require configured settings. However, when settings aren't
configured, the command can't ignore the [`MEDIA_ROOT`](/ja/4.2/ref/settings/#std-setting-MEDIA_ROOT) and
[`STATIC_ROOT`](/ja/4.2/ref/settings/#std-setting-STATIC_ROOT) directories or include [`LOCALE_PATHS`](/ja/4.2/ref/settings/#std-setting-LOCALE_PATHS).

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

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

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

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

Example usage:

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

Separate multiple extensions with commas or use `-e` or `--extension`
multiple times:

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

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

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

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

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

Example usage:

```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`

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

Example usage:

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

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

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

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

Example usage:

```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}]`

Controls `#: filename:line` comment lines in language files. If the option
is:

- `full` (the default if not given): the lines include both file name and
  line number.
- `file`: the line number is omitted.
- `never`: the lines are suppressed (same as [`--no-location`](#cmdoption-makemessages-no-location)).

Requires `gettext` 0.19 or newer.

#### `--keep-pot`

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

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

### `makemigrations`

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

検出されたモデルの変更に基づいて、新しいマイグレーションを作成します。マイグレーションおよびそのアプリとの関係は、詳しくは  the migrations documentation1 で説明しています。

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

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

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

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

#### `--empty`

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

#### `--dry-run`

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

#### `--merge`

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

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

Allows naming the generated migration(s) instead of using a generated name. The
name must be a valid Python [identifier](https://docs.python.org/3/reference/lexical_analysis.html#identifiers).

#### `--no-header`

Generate migration files without Django version and timestamp header.

#### `--check`

Makes `makemigrations` exit with a non-zero status when model changes without
migrations are detected. Implies `--dry-run`.

> **Changed in Django 4.2**
>
> In older versions, the missing migrations were also created when using the
> `--check` option.

#### `--scriptable`

> **New in Django 4.1**

Diverts log output and input prompts to `stderr`, writing only paths of
generated migration files to `stdout`.

#### `--update`

> **New in Django 4.2**

Merges model changes into the latest migration and optimize the resulting
operations.

The updated migration will have a generated name. In order to preserve the
previous name, set it using `--name`.

### `migrate`

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

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

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

- 引数なし: 全てのアプリが、それぞれが持つマイグレーションを全て実行します。
- `<app_label>`: 指定したアプリに最新のマイグレーションまで実行させます。依存関係によっては、他のアプリのマイグレーションも実行される場合もあります
- `<app_label> <migrationname>`: Brings the database schema to a state where
  the named migration is applied, but no later migrations in the same app are
  applied. This may involve unapplying migrations if you have previously
  migrated past the named migration. You can use a prefix of the migration
  name, e.g. `0001`, as long as it's unique for the given app name. Use the
  name `zero` to migrate all the way back i.e. to revert all applied
  migrations for an app.

> **Warning**
>
> When unapplying migrations, all dependent migrations will also be
> unapplied, regardless of `<app_label>`. You can use `--plan` to check
> which migrations will be unapplied.

#### `--database DATABASE`

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

#### `--fake`

Marks the migrations up to the target one (following the rules above) as
applied, but without actually running the SQL to change your database schema.

This is intended for advanced users to manipulate the
current migration state directly if they're manually applying changes;
be warned that using `--fake` runs the risk of putting the migration state
table into a state where manual recovery will be needed to make migrations
run correctly.

#### `--fake-initial`

Allows Django to skip an app's initial migration if all database tables with
the names of all models created by all
[`CreateModel`](/ja/4.2/ref/migration-operations/#django.db.migrations.operations.CreateModel) operations in that
migration already exist. This option is intended for use when first running
migrations against a database that preexisted the use of migrations. This
option does not, however, check for matching database schema beyond matching
table names and so is only safe to use if you are confident that your existing
schema matches what is recorded in your initial migration.

#### `--plan`

Shows the migration operations that will be performed for the given `migrate`
command.

#### `--run-syncdb`

Allows creating tables for apps without migrations. While this isn't
recommended, the migrations framework is sometimes too slow on large projects
with hundreds of models.

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

Suppresses all user prompts. An example prompt is asking about removing stale
content types.

#### `--check`

Makes `migrate` exit with a non-zero status when unapplied migrations are
detected.

#### `--prune`

> **New in Django 4.1**

Deletes nonexistent migrations from the `django_migrations` table. This is
useful when migration files replaced by a squashed migration have been removed.
See [Squashing migrations](/ja/4.2/topics/migrations/#migration-squashing) for more details.

### `optimizemigration`

> **New in Django 4.1**

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

Optimizes the operations for the named migration and overrides the existing
file. If the migration contains functions that must be manually copied, the
command creates a new migration file suffixed with `_optimized` that is meant
to replace the named migration.

#### `--check`

Makes `optimizemigration` exit with a non-zero status when a migration can be
optimized.

### `runserver`

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

Starts a lightweight development web server on the local machine. By default,
the server runs on port 8000 on the IP address `127.0.0.1`. You can pass in an
IP address and port number explicitly.

If you run this script as a user with normal privileges (recommended), you
might not have access to start a port on a low port number. Low port numbers
are reserved for the superuser (root).

This server uses the WSGI application object specified by the
[`WSGI_APPLICATION`](/ja/4.2/ref/settings/#std-setting-WSGI_APPLICATION) setting.

DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through
security audits or performance tests. (And that's how it's gonna stay. We're in
the business of making web frameworks, not web servers, so improving this
server to be able to handle a production environment is outside the scope of
Django.)

The development server automatically reloads Python code for each request, as
needed. You don't need to restart the server for code changes to take effect.
However, some actions like adding files don't trigger a restart, so you'll
have to restart the server in these cases.

If you're using Linux or MacOS and install both [pywatchman](https://pypi.org/project/pywatchman/) and the
[Watchman](https://facebook.github.io/watchman/) service, kernel signals will be used to autoreload the server
(rather than polling file modification timestamps each second). This offers
better performance on large projects, reduced response time after code changes,
more robust change detection, and a reduction in power usage. Django supports
`pywatchman` 1.2.0 and higher.

> **Large directories with many files may cause performance issues**
>
> When using Watchman with a project that includes large non-Python
> directories like `node_modules`, it's advisable to ignore this directory
> for optimal performance. See the [watchman documentation](https://facebook.github.io/watchman/docs/config#ignore_dirs) for information
> on how to do this.

> **Watchman timeout**
>
> #### `DJANGO_WATCHMAN_TIMEOUT`
>
>
>
>
> The default timeout of `Watchman` client is 5 seconds. You can change it
> by setting the [`DJANGO_WATCHMAN_TIMEOUT`](#envvar-DJANGO_WATCHMAN_TIMEOUT) environment variable.

When you start the server, and each time you change Python code while the
server is running, the system check framework will check your entire Django
project for some common errors (see the [`check`](#django-admin-check) command). If any
errors are found, they will be printed to standard output. You can use the
`--skip-checks` option to skip running system checks.

You can run as many concurrent servers as you want, as long as they're on
separate ports by executing `django-admin runserver` more than once.

Note that the default IP address, `127.0.0.1`, is not accessible from other
machines on your network. To make your development server viewable to other
machines on the network, use its own IP address (e.g. `192.168.2.1`), `0`
(shortcut for `0.0.0.0`), `0.0.0.0`, or `::` (with IPv6 enabled).

ブラケットで囲まれた IPv6 アドレス (例 `[200a::1]:8000`) を与えることもできます。その場合には、IPv6 のサポートが自動的に有効になります。

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

If the [staticfiles](/ja/4.2/ref/contrib/staticfiles/) contrib app is enabled
(default in new projects) the [`runserver`](#django-admin-runserver) command will be overridden
with its own [runserver](/ja/4.2/ref/contrib/staticfiles/#staticfiles-runserver) command.

Logging of each request and response of the server is sent to the
[django.server](/ja/4.2/ref/logging/#django-server-logger) logger.

#### `--noreload`

Disables the auto-reloader. This means any Python code changes you make while
the server is running will *not* take effect if the particular Python modules
have already been loaded into memory.

#### `--nothreading`

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

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

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

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

Port 8000 on IP address `127.0.0.1`:

```console
django-admin runserver
```

Port 8000 on IP address `1.2.3.4`:

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

Port 7000 on IP address `127.0.0.1`:

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

Port 7000 on IP address `1.2.3.4`:

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

Port 8000 on IPv6 address `::1`:

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

Port 7000 on IPv6 address `::1`:

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

Port 7000 on IPv6 address `2001:0db8:1234:5678::9`:

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

Port 8000 on IPv4 address of host `localhost`:

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

Port 8000 on IPv6 address of host `localhost`:

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

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

By default, the development server doesn't serve any static files for your site
(such as CSS files, images, things under [`MEDIA_URL`](/ja/4.2/ref/settings/#std-setting-MEDIA_URL) and so forth). If
you want to configure Django to serve static media, read
[静的ファイル (画像、JavaScript、CSS など) を管理する](/ja/4.2/howto/static-files/).

#### Serving with ASGI in development

Django's `runserver` command provides a WSGI server. In order to run under
ASGI you will need to use an [ASGI server](/ja/4.2/howto/deployment/asgi/).
The Django Daphne project provides [Integration with runserver](/ja/4.2/howto/deployment/asgi/daphne/#daphne-runserver) that you can use.

### `sendtestemail`

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

Sends a test email (to confirm email sending through Django is working) to the
recipient(s) specified. For example:

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

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

#### `--managers`

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

#### `--admins`

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

### `shell`

#### `django-admin shell`

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

#### `--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
```

If you have a "rich" shell installed but want to force use of the "plain"
Python interpreter, use `python` as the interface name, like so:

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

#### `--nostartup`

Disables reading the startup script for the "plain" Python interpreter. By
default, the script pointed to by the [`PYTHONSTARTUP`](https://docs.python.org/3/using/cmdline.html#envvar-PYTHONSTARTUP) environment
variable or the `~/.pythonrc.py` script is read.

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

Lets you pass a command as a string to execute it as Django, like so:

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

You can also pass code in on standard input to execute it. For example:

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

On Windows, the REPL is output due to implementation limits of
[`select.select()`](https://docs.python.org/3/library/select.html#select.select) on that platform.

### `showmigrations`

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

Shows all migrations in a project. You can choose from one of two formats:

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

Lists all of the apps Django knows about, the migrations available for each
app, and whether or not each migration is applied (marked by an `[X]` next to
the migration name). For a `--verbosity` of 2 and above, the applied
datetimes are also shown.

Apps without migrations are also listed, but have `(no migrations)` printed
under them.

This is the default output format.

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

Shows the migration plan Django will follow to apply migrations. Like
`--list`, applied migrations are marked by an `[X]`. For a `--verbosity`
of 2 and above, all dependencies of a migration will also be shown.

`app_label`s arguments limit the output, however, dependencies of provided
apps may also be included.

#### `--database DATABASE`

Specifies the database to examine. Defaults to `default`.

### `sqlflush`

#### `django-admin sqlflush`

Prints the SQL statements that would be executed for the [`flush`](#django-admin-flush)
command.

#### `--database DATABASE`

Specifies the database for which to print the SQL. Defaults to `default`.

### `sqlmigrate`

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

Prints the SQL for the named migration. This requires an active database
connection, which it will use to resolve constraint names; this means you must
generate the SQL against a copy of the database you wish to later apply it on.

Note that `sqlmigrate` doesn't colorize its output.

#### `--backwards`

Generates the SQL for unapplying the migration. By default, the SQL created is
for running the migration in the forwards direction.

#### `--database DATABASE`

Specifies the database for which to generate the SQL. Defaults to `default`.

### `sqlsequencereset`

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

Prints the SQL statements for resetting sequences for the given app name(s).

Sequences are indexes used by some database engines to track the next available
number for automatically incremented fields.

Use this command to generate SQL which will fix cases where a sequence is out
of sync with its automatically incremented field data.

#### `--database DATABASE`

Specifies the database for which to print the SQL. Defaults to `default`.

### `squashmigrations`

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

Squashes the migrations for `app_label` up to and including `migration_name`
down into fewer migrations, if possible. The resulting squashed migrations
can live alongside the unsquashed ones safely. For more information,
please read [Squashing migrations](/ja/4.2/topics/migrations/#migration-squashing).

When `start_migration_name` is given, Django will only include migrations
starting from and including this migration. This helps to mitigate the
squashing limitation of [`RunPython`](/ja/4.2/ref/migration-operations/#django.db.migrations.operations.RunPython) and
[`django.db.migrations.operations.RunSQL`](/ja/4.2/ref/migration-operations/#django.db.migrations.operations.RunSQL) migration operations.

#### `--no-optimize`

Disables the optimizer when generating a squashed migration. By default, Django
will try to optimize the operations in your migrations to reduce the size of
the resulting file. Use this option if this process is failing or creating
incorrect migrations, though please also file a Django bug report about the
behavior, as optimization is meant to be safe.

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

Suppresses all user prompts.

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

Sets the name of the squashed migration. When omitted, the name is based on the
first and last migration, with `_squashed_` in between.

#### `--no-header`

Generate squashed migration file without Django version and timestamp header.

### `startapp`

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

Creates a Django app directory structure for the given app name in the current
directory or the given destination.

By default, [the new directory](https://github.com/django/django/blob/stable/4.2.x/django/conf/app_template) contains a
`models.py` file and other app template files. If only the app name is given,
the app directory will be created in the current working directory.

If the optional destination is provided, Django will use that existing
directory rather than creating a new one. You can use '.' to denote the current
working directory.

例えば:

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

#### `--template TEMPLATE`

Provides the path to a directory with a custom app template file, or a path to
an uncompressed archive (`.tar`) or a compressed archive (`.tar.gz`,
`.tar.bz2`, `.tar.xz`, `.tar.lzma`, `.tgz`, `.tbz2`, `.txz`,
`.tlz`, `.zip`) containing the app template files.

For example, this would look for an app template in the given directory when
creating the `myapp` app:

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

Django will also accept URLs (`http`, `https`, `ftp`) to compressed
archives with the app template files, downloading and extracting them on the
fly.

For example, taking advantage of GitHub's feature to expose repositories as
zip files, you can use a URL like:

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

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

Specifies which file extensions in the app template should be rendered with the
template engine. Defaults to `py`.

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

Specifies which files in the app template (in addition to those matching
`--extension`) should be rendered with the template engine. Defaults to an
empty list.

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

Specifies which directories in the app template should be excluded, in addition
to `.git` and `__pycache__`. If this option is not provided, directories
named `__pycache__` or starting with `.` will be excluded.

The [`template context`](/ja/4.2/ref/templates/api/#django.template.Context) used for all matching
files is:

- Any option passed to the `startapp` command (among the command's supported
  options)
- `app_name` -- the app name as passed to the command
- `app_directory` -- the full path of the newly created app
- `camel_case_app_name` -- the app name in camel case format
- `docs_version` -- the version of the documentation: `'dev'` or `'1.x'`
- `django_version` -- the version of Django, e.g. `'2.0.3'`

> **Warning**
>
> When the app template files are rendered with the Django template
> engine (by default all `*.py` files), Django will also replace all
> stray template variables contained. For example, if one of the Python files
> contains a docstring explaining a particular feature related
> to template rendering, it might result in an incorrect example.
>
> To work around this problem, you can use the [`templatetag`](/ja/4.2/ref/templates/builtins/#std-templatetag-templatetag)
> template tag to "escape" the various parts of the template syntax.
>
> In addition, to allow Python template files that contain Django template
> language syntax while also preventing packaging systems from trying to
> byte-compile invalid `*.py` files, template files ending with `.py-tpl`
> will be renamed to `.py`.

> **Warning**
>
> The contents of custom app (or project) templates should always be
> audited before use: Such templates define code that will become
> part of your project, and this means that such code will be trusted
> as much as any app you install, or code you write yourself.
> Further, even rendering the templates is, effectively, executing
> code that was provided as input to the management command. The
> Django template language may provide wide access into the system,
> so make sure any custom template you use is worthy of your trust.

### `startproject`

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

Creates a Django project directory structure for the given project name in
the current directory or the given destination.

By default, [the new directory](https://github.com/django/django/blob/stable/4.2.x/django/conf/project_template) contains
`manage.py` and a project package (containing a `settings.py` and other
files).

If only the project name is given, both the project directory and project
package will be named `<projectname>` and the project directory
will be created in the current working directory.

If the optional destination is provided, Django will use that existing
directory as the project directory, and create `manage.py` and the project
package within it. Use '.' to denote the current working directory.

例えば:

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

#### `--template TEMPLATE`

Specifies a directory, file path, or URL of a custom project template. See the
[`startapp --template`](#cmdoption-startapp-template) documentation for examples and usage.

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

Specifies which file extensions in the project template should be rendered with
the template engine. Defaults to `py`.

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

Specifies which files in the project template (in addition to those matching
`--extension`) should be rendered with the template engine. Defaults to an
empty list.

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

Specifies which directories in the project template should be excluded, in
addition to `.git` and `__pycache__`. If this option is not provided,
directories named `__pycache__` or starting with `.` will be excluded.

The [`template context`](/ja/4.2/ref/templates/api/#django.template.Context) used is:

- Any option passed to the `startproject` command (among the command's
  supported options)
- `project_name` -- the project name as passed to the command
- `project_directory` -- the full path of the newly created project
- `secret_key` -- a random key for the [`SECRET_KEY`](/ja/4.2/ref/settings/#std-setting-SECRET_KEY) setting
- `docs_version` -- the version of the documentation: `'dev'` or `'1.x'`
- `django_version` -- the version of Django, e.g. `'2.0.3'`

Please also see the [rendering warning](#render-warning) and
[trusted code warning](#trusted-code-warning) as mentioned for
[`startapp`](#django-admin-startapp).

### `test`

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

Runs tests for all installed apps. See [Django におけるテスト](/ja/4.2/topics/testing/) for more
information.

#### `--failfast`

Stops running tests and reports the failure immediately after a test fails.

#### `--testrunner TESTRUNNER`

Controls the test runner class that is used to execute tests. This value
overrides the value provided by the [`TEST_RUNNER`](/ja/4.2/ref/settings/#std-setting-TEST_RUNNER) setting.

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

Suppresses all user prompts. A typical prompt is a warning about deleting an
existing test database.

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

The `test` command receives options on behalf of the specified
[`--testrunner`](#cmdoption-test-testrunner). These are the options of the default test runner:
[`DiscoverRunner`](/ja/4.2/topics/testing/advanced/#django.test.runner.DiscoverRunner).

#### `--keepdb`

Preserves the test database between test runs. This has the advantage of
skipping both the create and destroy actions which can greatly decrease the
time to run tests, especially those in a large test suite. If the test database
does not exist, it will be created on the first run and then preserved for each
subsequent run. Unless the [`MIGRATE`](/ja/4.2/ref/settings/#std-setting-TEST_MIGRATE) test setting is
`False`, any unapplied migrations will also be applied to the test database
before running the test suite.

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

Randomizes the order of tests before running them. This can help detect tests
that aren't properly isolated. The test order generated by this option is a
deterministic function of the integer seed given. When no seed is passed, a
seed is chosen randomly and printed to the console. To repeat a particular test
order, pass a seed. The test orders generated by this option preserve Django's
[guarantees on test order](/ja/4.2/topics/testing/overview/#order-of-tests). They also keep tests grouped
by test case class.

The shuffled orderings also have a special consistency property useful when
narrowing down isolation issues. Namely, for a given seed and when running a
subset of tests, the new order will be the original shuffling restricted to the
smaller set. Similarly, when adding tests while keeping the seed the same, the
order of the original tests will be the same in the new order.

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

Sorts test cases in the opposite execution order. This may help in debugging
the side effects of tests that aren't properly isolated. [Grouping by test
class](/ja/4.2/topics/testing/overview/#order-of-tests) is preserved when using this option. This can be used
in conjunction with `--shuffle` to reverse the order for a particular seed.

#### `--debug-mode`

Sets the [`DEBUG`](/ja/4.2/ref/settings/#std-setting-DEBUG) setting to `True` prior to running tests. This may
help troubleshoot test failures.

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

Enables [SQL logging](/ja/4.2/ref/logging/#django-db-logger) for failing tests. If
`--verbosity` is `2`, then queries in passing tests are also output.

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

#### `DJANGO_TEST_PROCESSES`

Runs tests in separate parallel processes. Since modern processors have
multiple cores, this allows running tests significantly faster.

Using `--parallel` without a value, or with the value `auto`, runs one test
process per core according to [`multiprocessing.cpu_count()`](https://docs.python.org/3/library/multiprocessing.html#multiprocessing.cpu_count). You can
override this by passing the desired number of processes, e.g.
`--parallel 4`, or by setting the [`DJANGO_TEST_PROCESSES`](#envvar-DJANGO_TEST_PROCESSES) environment
variable.

Django distributes test cases — [`unittest.TestCase`](https://docs.python.org/3/library/unittest.html#unittest.TestCase) subclasses — to
subprocesses. If there are fewer test cases than configured processes, Django
will reduce the number of processes accordingly.

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

> **Note**
>
> If you have test classes that cannot be run in parallel, you can use
> `SerializeMixin` to run them sequentially. See [Enforce running test
> classes sequentially](/ja/4.2/topics/testing/advanced/#topics-testing-enforce-run-sequentially).

This option requires the third-party `tblib` package to display tracebacks
correctly:

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

This feature isn't available on Windows. It doesn't work with the Oracle
database backend either.

If you want to use [`pdb`](https://docs.python.org/3/library/pdb.html#module-pdb) while debugging tests, you must disable parallel
execution (`--parallel=1`). You'll see something like `bdb.BdbQuit` if you
don't.

> **Warning**
>
> When test parallelization is enabled and a test fails, Django may be
> unable to display the exception traceback. This can make debugging
> difficult. If you encounter this problem, run the affected test without
> parallelization to see the traceback of the failure.
>
> This is a known limitation. It arises from the need to serialize objects
> in order to exchange them between processes. See
> [What can be pickled and unpickled?](https://docs.python.org/3/library/pickle.html#pickle-picklable) for details.

#### `--tag TAGS`

Runs only tests [marked with the specified tags](/ja/4.2/topics/testing/tools/#topics-tagging-tests).
May be specified multiple times and combined with [`test --exclude-tag`](#cmdoption-test-exclude-tag).

Tests that fail to load are always considered matching.

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

Excludes tests [marked with the specified tags](/ja/4.2/topics/testing/tools/#topics-tagging-tests).
May be specified multiple times and combined with [`test --tag`](#cmdoption-test-tag).

#### `-k TEST_NAME_PATTERNS`

Runs test methods and classes matching test name patterns, in the same way as
[`unittest's -k option`](https://docs.python.org/3/library/unittest.html#cmdoption-unittest-k). Can be specified multiple times.

#### `--pdb`

Spawns a `pdb` debugger at each test error or failure. If you have it
installed, `ipdb` is used instead.

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

Discards output (`stdout` and `stderr`) for passing tests, in the same way
as [`unittest's --buffer option`](https://docs.python.org/3/library/unittest.html#cmdoption-unittest-b).

#### `--no-faulthandler`

Django automatically calls [`faulthandler.enable()`](https://docs.python.org/3/library/faulthandler.html#faulthandler.enable) when starting the
tests, which allows it to print a traceback if the interpreter crashes. Pass
`--no-faulthandler` to disable this behavior.

#### `--timing`

Outputs timings, including database setup and total run time.

### `testserver`

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

Runs a Django development server (as in [`runserver`](#django-admin-runserver)) using data from
the given fixture(s).

For example, this command:

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

...would perform the following steps:

1. Create a test database, as described in [test データベース](/ja/4.2/topics/testing/overview/#the-test-database).
2. Populate the test database with fixture data from the given fixtures.
   (For more on fixtures, see the documentation for [`loaddata`](#django-admin-loaddata) above.)
3. Runs the Django development server (as in [`runserver`](#django-admin-runserver)), pointed at
   this newly created test database instead of your production database.

This is useful in a number of ways:

- When you're writing [unit tests](/ja/4.2/topics/testing/overview/) of how your views
  act with certain fixture data, you can use `testserver` to interact with
  the views in a web browser, manually.
- Let's say you're developing your Django application and have a "pristine"
  copy of a database that you'd like to interact with. You can dump your
  database to a [fixture](/ja/4.2/topics/db/fixtures/#fixtures-explanation) (using the
  [`dumpdata`](#django-admin-dumpdata) command, explained above), then use `testserver` to run
  your web application with that data.  With this arrangement, you have the
  flexibility of messing up your data in any way, knowing that whatever data
  changes you're making are only being made to a test database.

Note that this server does *not* automatically detect changes to your Python
source code (as [`runserver`](#django-admin-runserver) does). It does, however, detect changes to
templates.

#### `--addrport ADDRPORT`

Specifies a different port, or IP address and port, from the default of
`127.0.0.1:8000`. This value follows exactly the same format and serves
exactly the same function as the argument to the [`runserver`](#django-admin-runserver) command.

例:

To run the test server on port 7000 with `fixture1` and `fixture2`:

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

(The above statements are equivalent. We include both of them to demonstrate
that it doesn't matter whether the options come before or after the fixture
arguments.)

To run on 1.2.3.4:7000 with a `test` fixture:

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

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

Suppresses all user prompts. A typical prompt is a warning about deleting an
existing test database.

## Commands provided by applications

Some commands are only available when the `django.contrib` application that
[implements](/ja/4.2/howto/custom-management-commands/) them has been
[`enabled`](/ja/4.2/ref/settings/#std-setting-INSTALLED_APPS). This section describes them grouped by
their application.

### `django.contrib.auth`

#### `changepassword`

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

This command is only available if Django's [authentication system](/ja/4.2/topics/auth/) (`django.contrib.auth`) is installed.

Allows changing a user's password. It prompts you to enter a new password twice
for the given user. If the entries are identical, this immediately becomes the
new password. If you do not supply a user, the command will attempt to change
the password whose username matches the current user.

#### `--database DATABASE`

Specifies the database to query for the user. Defaults to `default`.

Example usage:

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

#### `createsuperuser`

#### `django-admin createsuperuser`

#### `DJANGO_SUPERUSER_PASSWORD`

This command is only available if Django's [authentication system](/ja/4.2/topics/auth/) (`django.contrib.auth`) is installed.

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

When run interactively, this command will prompt for a password for
the new superuser account. When run non-interactively, you can provide
a password by setting the [`DJANGO_SUPERUSER_PASSWORD`](#envvar-DJANGO_SUPERUSER_PASSWORD) environment
variable. Otherwise, no password will be set, and the superuser account will
not be able to log in until a password has been manually set for it.

In non-interactive mode, the
[`USERNAME_FIELD`](/ja/4.2/topics/auth/customizing/#django.contrib.auth.models.CustomUser.USERNAME_FIELD) and required
fields (listed in
[`REQUIRED_FIELDS`](/ja/4.2/topics/auth/customizing/#django.contrib.auth.models.CustomUser.REQUIRED_FIELDS)) fall back to
`DJANGO_SUPERUSER_<uppercase_field_name>` environment variables, unless they
are overridden by a command line argument. For example, to provide an `email`
field, you can use `DJANGO_SUPERUSER_EMAIL` environment variable.

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

Suppresses all user prompts. If a suppressed prompt cannot be resolved
automatically, the command will exit with error code 1.

#### `--username USERNAME`

#### `--email EMAIL`

The username and email address for the new account can be supplied by
using the `--username` and `--email` arguments on the command
line. If either of those is not supplied, `createsuperuser` will prompt for
it when running interactively.

#### `--database DATABASE`

Specifies the database into which the superuser object will be saved.

You can subclass the management command and override `get_input_data()` if you
want to customize data input and validation. Consult the source code for
details on the existing implementation and the method's parameters. For example,
it could be useful if you have a `ForeignKey` in
[`REQUIRED_FIELDS`](/ja/4.2/topics/auth/customizing/#django.contrib.auth.models.CustomUser.REQUIRED_FIELDS) and want to
allow creating an instance instead of entering the primary key of an existing
instance.

### `django.contrib.contenttypes`

#### `remove_stale_contenttypes`

#### `django-admin remove_stale_contenttypes`

This command is only available if Django's [contenttypes app](/ja/4.2/ref/contrib/contenttypes/) ([`django.contrib.contenttypes`](/ja/4.2/ref/contrib/contenttypes/#module-django.contrib.contenttypes)) is installed.

Deletes stale content types (from deleted models) in your database. Any objects
that depend on the deleted content types will also be deleted. A list of
deleted objects will be displayed before you confirm it's okay to proceed with
the deletion.

#### `--database DATABASE`

Specifies the database to use. Defaults to `default`.

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

Deletes stale content types including ones from previously installed apps that
have been removed from [`INSTALLED_APPS`](/ja/4.2/ref/settings/#std-setting-INSTALLED_APPS). Defaults to `False`.

### `django.contrib.gis`

#### `ogrinspect`

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

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

### `django.contrib.sessions`

#### `clearsessions`

#### `django-admin clearsessions`

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

### `django.contrib.sitemaps`

#### `ping_google`

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

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

### `django.contrib.staticfiles`

#### `collectstatic`

This command is only available if the [static files application](/ja/4.2/howto/static-files/) (`django.contrib.staticfiles`) is installed.

Please refer to its [`description`](/ja/4.2/ref/contrib/staticfiles/#django-admin-collectstatic) in the
[staticfiles](/ja/4.2/ref/contrib/staticfiles/) documentation.

#### `findstatic`

This command is only available if the [static files application](/ja/4.2/howto/static-files/) (`django.contrib.staticfiles`) is installed.

Please refer to its [`description`](/ja/4.2/ref/contrib/staticfiles/#django-admin-findstatic) in the [staticfiles](/ja/4.2/ref/contrib/staticfiles/) documentation.

## Default options

Although some commands may allow their own custom options, every command
allows for the following options by default:

#### `--pythonpath PYTHONPATH`

Adds the given filesystem path to the Python [import search path](https://diveinto.org/python3/your-first-python-program.html#importsearchpath). If this
isn't provided, `django-admin` will use the [`PYTHONPATH`](https://docs.python.org/3/using/cmdline.html#envvar-PYTHONPATH) environment
variable.

This option is unnecessary in `manage.py`, because it takes care of setting
the Python path for you.

Example usage:

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

#### `--settings SETTINGS`

Specifies the settings module to use. The settings module should be in Python
package syntax, e.g. `mysite.settings`. If this isn't provided,
`django-admin` will use the [`DJANGO_SETTINGS_MODULE`](/ja/4.2/topics/settings/#envvar-DJANGO_SETTINGS_MODULE) environment
variable.

This option is unnecessary in `manage.py`, because it uses
`settings.py` from the current project by default.

Example usage:

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

#### `--traceback`

Displays a full stack trace when a [`CommandError`](/ja/4.2/howto/custom-management-commands/#django.core.management.CommandError)
is raised. By default, `django-admin` will show an error message when a
`CommandError` occurs and a full stack trace for any other exception.

This option is ignored by [`runserver`](#django-admin-runserver).

Example usage:

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

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

Specifies the amount of notification and debug information that a command
should print to the console.

- `0` means no output.
- `1` means normal output (default).
- `2` means verbose output.
- `3` means *very* verbose output.

This option is ignored by [`runserver`](#django-admin-runserver).

Example usage:

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

#### `--no-color`

Disables colorized command output.  Some commands format their output to be
colorized. For example, errors will be printed to the console in red and SQL
statements will be syntax highlighted.

Example usage:

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

#### `--force-color`

Forces colorization of the command output if it would otherwise be disabled
as discussed in [Syntax coloring](#syntax-coloring). For example, you may want to pipe
colored output to another command.

#### `--skip-checks`

Skips running system checks prior to running the command. This option is only
available if the
[`requires_system_checks`](/ja/4.2/howto/custom-management-commands/#django.core.management.BaseCommand.requires_system_checks) command
attribute is not an empty list or tuple.

Example usage:

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

## Extra niceties

### Syntax coloring

#### `DJANGO_COLORS`

The `django-admin` / `manage.py` commands will use pretty
color-coded output if your terminal supports ANSI-colored output. It
won't use the color codes if you're piping the command's output to
another program unless the [`--force-color`](#cmdoption-force-color) option is used.

#### Windows support

On Windows 10, the [Windows Terminal](https://www.microsoft.com/en-us/p/windows-terminal-preview/9n0dx20hk701) application, [VS Code](https://code.visualstudio.com), and PowerShell
(where virtual terminal processing is enabled) allow colored output, and are
supported by default.

Under Windows, the legacy `cmd.exe` native console doesn't support ANSI
escape sequences so by default there is no color output. In this case either of
two third-party libraries are needed:

- Install [colorama](https://pypi.org/project/colorama/), a Python package that translates ANSI color codes
  into Windows API calls. Django commands will detect its presence and will
  make use of its services to color output just like on Unix-based platforms.
  `colorama` can be installed via pip:

  ```doscon
  ...\> py -m pip install colorama
  ```
- Install [ANSICON](http://adoxa.altervista.org/ansicon/), a third-party tool that allows `cmd.exe` to process
  ANSI color codes. Django commands will detect its presence and will make use
  of its services to color output just like on Unix-based platforms.

Other modern terminal environments on Windows, that support terminal colors,
but which are not automatically detected as supported by Django, may "fake" the
installation of `ANSICON` by setting the appropriate environmental variable,
`ANSICON="on"`.

#### Custom colors

The colors used for syntax highlighting can be customized. Django
ships with three color palettes:

- `dark`, suited to terminals that show white text on a black
  background. This is the default palette.
- `light`, suited to terminals that show black text on a white
  background.
- `nocolor`, which disables syntax highlighting.

You select a palette by setting a [`DJANGO_COLORS`](#envvar-DJANGO_COLORS) environment
variable to specify the palette you want to use. For example, to
specify the `light` palette under a Unix or OS/X BASH shell, you
would run the following at a command prompt:

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

You can also customize the colors that are used. Django specifies a
number of roles in which color is used:

- `error` \- A major error.
- `notice` \- A minor error.
- `success` \- A success.
- `warning` \- A warning.
- `sql_field` \- The name of a model field in SQL.
- `sql_coltype` \- The type of a model field in SQL.
- `sql_keyword` \- An SQL keyword.
- `sql_table` \- The name of a model in SQL.
- `http_info` \- A 1XX HTTP Informational server response.
- `http_success` \- A 2XX HTTP Success server response.
- `http_not_modified` \- A 304 HTTP Not Modified server response.
- `http_redirect` \- A 3XX HTTP Redirect server response other than 304.
- `http_not_found` \- A 404 HTTP Not Found server response.
- `http_bad_request` \- A 4XX HTTP Bad Request server response other than 404.
- `http_server_error` \- A 5XX HTTP Server Error response.
- `migrate_heading` \- A heading in a migrations management command.
- `migrate_label` \- A migration name.

Each of these roles can be assigned a specific foreground and
background color, from the following list:

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

Each of these colors can then be modified by using the following
display options:

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

A color specification follows one of the following patterns:

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

where `role` is the name of a valid color role, `fg` is the
foreground color, `bg` is the background color and each `option`
is one of the color modifying options. Multiple color specifications
are then separated by a semicolon. For example:

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

would specify that errors be displayed using blinking yellow on blue,
and notices displayed using magenta. All other color roles would be
left uncolored.

Colors can also be specified by extending a base palette. If you put
a palette name in a color specification, all the colors implied by that
palette will be loaded. So:

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

would specify the use of all the colors in the light color palette,
*except* for the colors for errors and notices which would be
overridden as specified.

### Bash による補完

If you use the Bash shell, consider installing the Django bash completion
script, which lives in [extras/django\_bash\_completion](https://github.com/django/django/blob/stable/4.2.x/extras/django_bash_completion) in the Django source
distribution. It enables tab-completion of `django-admin` and
`manage.py` commands, so you can, for instance...

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

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

### Black formatting

> **New in Django 4.1**

The Python files created by [`startproject`](#django-admin-startproject), [`startapp`](#django-admin-startapp),
[`optimizemigration`](#django-admin-optimizemigration), [`makemigrations`](#django-admin-makemigrations), and
[`squashmigrations`](#django-admin-squashmigrations) are formatted using the `black` command if it is
present on your `PATH`.

If you have `black` globally installed, but do not wish it used for the
current project, you can set the `PATH` explicitly:

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

For commands using `stdout` you can pipe the output to `black` if needed:

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

# Running management commands from your code

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

To call a management command from code use `call_command`.

**`name`**

  the name of the command to call or a command object. Passing the name is
  preferred unless the object is required for testing.

**`*args`**

  a list of arguments accepted by the command. Arguments are passed to the
  argument parser, so you can use the same style as you would on the command
  line. For example, `call_command('flush', '--verbosity=0')`.

**`**options`**

  named options accepted on the command-line. Options are passed to the command
  without triggering the argument parser, which means you'll need to pass the
  correct type. For example, `call_command('flush', verbosity=0)` (zero must
  be an integer rather than a string).

例:

```
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)
```

Note that command options that take no arguments are passed as keywords
with `True` or `False`, as you can see with the `interactive` option above.

Named arguments can be passed by using either one of the following syntaxes:

```
# 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)
```

Some command options have different names when using `call_command()` instead
of `django-admin` or `manage.py`. For example, `django-admin
createsuperuser --no-input` translates to `call_command('createsuperuser',
interactive=False)`. To find what keyword argument name to use for
`call_command()`, check the command's source code for the `dest` argument
passed to `parser.add_argument()`.

Command options which take multiple options are passed a list:

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

The return value of the `call_command()` function is the same as the return
value of the `handle()` method of the command.

## Output redirection

Note that you can redirect standard output and error streams as all commands
support the `stdout` and `stderr` options. For example, you could write:

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