---
title: "デプロイチェックリスト"
version: 4.1
locale: ja
source: https://docs.djangoproject.com/ja/4.1/howto/deployment/checklist/
canonical: https://djangodocs.dev/ja/4.1/howto/deployment/checklist/
---
# デプロイチェックリスト

The internet is a hostile environment. Before deploying your Django project,
you should take some time to review your settings, with security, performance,
and operations in mind.

Django には多くの [セキュリティ機能](/ja/4.1/topics/security/) があります。いくつかはビルトインで、常に有効です。その他は任意となっており、これは常に適切とは限らなかったり、開発に対しては不便だったりするためです。たとえば、HTTPS を強制することは、すべてのウェブサイトに対して適切とは言えず、またローカル開発では実践的ではありません。

パフォーマンスの最適化は、利便性とのトレードオフとなるもう 1 つの要素です。たとえば、キャッシングは本番環境では役立ちますが、ローカル開発では役立ちません。同様に、エラーレポートの必要性にも大きな違いがあります。

以下のチェックリストは、次の設定項目を含みます:

- Django が想定したレベルのセキュリティを提供するために適切にセットされる必要があるもの;
- 各環境で異なると予期されるもの;
- オプションのセキュリティ機能を有効にするもの;
- パフォーマンスの最適化を有効にするもの;
- エラーレポートを提供するもの;

これらの設定の多くは秘匿的で、機密的に扱う必要があります。プロジェクトに対してソースコードをリリースする場合、一般的な方法は、開発に適した設定を公開し、本番用のプライベートな設定モジュールを使うことです。

## `manage.py check --deploy` を実施しよう

以下で説明しているチェックのいくつかは、[`check --deploy`](/ja/4.1/ref/django-admin/#cmdoption-check-deploy) オプションを使用して自動化できます。オプションのドキュメントで説明しているとおり、本番環境の設定に対してこのチェックを実施してください。

## 最重要な設定

### [`SECRET_KEY`](/ja/4.1/ref/settings/#std-setting-SECRET_KEY)

**シークレットキーは、長いランダム文字列で、秘匿される必要があります。**

本番環境で使われるキーは、他の場所で使われておらず、ソースコントロール中に記述してしまわないよう十分注意してください。これにより、攻撃者がキーを取得してしまう恐れを軽減できます。

設定モジュールにシークレットキーを直接書き込む代わりに、環境変数から読み込む方法を検討してください:

```
import os
SECRET_KEY = os.environ['SECRET_KEY']
```

もしくはファイルから読み込みます:

```
with open('/etc/secret_key.txt') as f:
    SECRET_KEY = f.read().strip()
```

If rotating secret keys, you may use [`SECRET_KEY_FALLBACKS`](/ja/4.1/ref/settings/#std-setting-SECRET_KEY_FALLBACKS):

```
import os
SECRET_KEY = os.environ['CURRENT_SECRET_KEY']
SECRET_KEY_FALLBACKS = [
    os.environ['OLD_SECRET_KEY'],
]
```

Ensure that old secret keys are removed from `SECRET_KEY_FALLBACKS` in a
timely manner.

> **Changed in Django 4.1**
>
> The `SECRET_KEY_FALLBACKS` setting was added to support rotating secret
> keys.

### [`DEBUG`](/ja/4.1/ref/settings/#std-setting-DEBUG)

**デバッグは、本番環境では決して有効化してはいけません。**

プロジェクトの開発中は [`DEBUG = True`](/ja/4.1/ref/settings/#std-setting-DEBUG) だったはずですが、これはブラウザ内の全トレースバックといった便利な機能を使えるようにするためです。

しかし、本番環境に対してはこれはまったく不適切です。なぜなら、プロジェクトに関する多くの情報を公にしてしまうからです: ソースコードからの引用、ローカル変数、設定、使われているライブラリ、等。

## 環境に合わせた設定

### [`ALLOWED_HOSTS`](/ja/4.1/ref/settings/#std-setting-ALLOWED_HOSTS)

[`DEBUG = False`](/ja/4.1/ref/settings/#std-setting-DEBUG) のとき、[`ALLOWED_HOSTS`](/ja/4.1/ref/settings/#std-setting-ALLOWED_HOSTS) が適切に設定されない限り Django は一切動作しません。

この設定は、いくつかの CSRF 攻撃からあなたのサイトを保護するために必要です。もしワイルドカードを使用した場合、`Host` HTTP のバリデーションを自分自身で行う必要があります。さもなければ、この種の攻撃に脆弱なサイトとなってしまいます。

You should also configure the web server that sits in front of Django to
validate the host. It should respond with a static error page or ignore
requests for incorrect hosts instead of forwarding the request to Django. This
way you'll avoid spurious errors in your Django logs (or emails if you have
error reporting configured that way). For example, on nginx you might set up a
default server to return "444 No Response" on an unrecognized host:

```nginx
server {
    listen 80 default_server;
    return 444;
}
```

### [`CACHES`](/ja/4.1/ref/settings/#std-setting-CACHES)

もしキャッシュを使うなら、開発環境と本番環境とでコネクションパラメータは異なるでしょう。そうでない場合、デフォルトはref:local-memory-caching\`のper-process に設定されています。

キャッシュサーバーは認証に弱点を持っています。あなたのアプリケーションからのコネクションだけを受け入れるようにしてください。

### [`DATABASES`](/ja/4.1/ref/settings/#std-setting-DATABASES)

データベースの接続パラメータは、開発環境と本番環境でおそらく異なります。

データベースパスワードは非常に機密的なものです。[`SECRET_KEY`](/ja/4.1/ref/settings/#std-setting-SECRET_KEY) と同様の方法で保護してください。

セキュリティを最大化するために、データベースサーバーがあなたのアプリからの未接続を受け入れるようにしてください。

もしデータベースのバックアップの設定をしていなければ、今すぐに行ってください!

### [`EMAIL_BACKEND`](/ja/4.1/ref/settings/#std-setting-EMAIL_BACKEND) と関連する設定

あなたのサイトが E メールを送信する場合、設定値が正しくセットされている必要があります。

デフォルトでは、Django は [webmaster@localhost](mailto:webmaster@localhost) と [root@localhost](mailto:root@localhost) から E メールを送信します。しかし、いくつかのメールプロバイダはこれらのアドレスを拒否します。異なる送信者アドレスを使用するには、[`DEFAULT_FROM_EMAIL`](/ja/4.1/ref/settings/#std-setting-DEFAULT_FROM_EMAIL) と [`SERVER_EMAIL`](/ja/4.1/ref/settings/#std-setting-SERVER_EMAIL) 設定を修正してください。

### [`STATIC_ROOT`](/ja/4.1/ref/settings/#std-setting-STATIC_ROOT) と [`STATIC_URL`](/ja/4.1/ref/settings/#std-setting-STATIC_URL)

静的ファイルは、開発用サーバーでは自動的に提供されます。本番環境では、[`collectstatic`](/ja/4.1/ref/contrib/staticfiles/#django-admin-collectstatic) が静的ファイルをコピーする [`STATIC_ROOT`](/ja/4.1/ref/settings/#std-setting-STATIC_ROOT) ディレクトリを設定する必要があります。

より詳しくは [How to manage static files (e.g. images, JavaScript, CSS)](/ja/4.1/howto/static-files/) を参照してください。

### [`MEDIA_ROOT`](/ja/4.1/ref/settings/#std-setting-MEDIA_ROOT) と [`MEDIA_URL`](/ja/4.1/ref/settings/#std-setting-MEDIA_URL)

メディアファイルは、あなたのユーザーによってアップロードされます。彼らは信用なりません! ウェブサーバーが決してこれらを解読しようとしないようにしてください。たとえば、ユーザーが `.php` ファイルをアップロードしたとき、ウェブサーバーはその内容を実行するべきではありません。

この機会に、こうしたファイルに対するバックアップ戦略をチェックしておきましょう。

## HTTPS

ユーザーにログインさせるあらゆるウェブサイトは、アクセストークンを平文で送信するのを防ぐため、サイト全体の HTTPS を強制するべきです。Django では、アクセストークンはログインとパスワード、セッションクッキー、パスワードリセットトークンを含みます。(パスワードリセットトークンを E メール送信する場合、それほど保護されてはいません。)

ユーザーアカウントやアドミンといった機密領域を保護するだけでは十分ではありません。同じセッションクッキーが HTTP や HTTPS に使われるからです。ウェブサーバーはすべての HTTP トラフィックを HTTPS にリダイレクトし、Django には HTTPS リクエストのみが送信されなければなりません。

一度 HTTPS をセットアップしたら、以下の設定項目が有効になります。

### [`CSRF_COOKIE_SECURE`](/ja/4.1/ref/settings/#std-setting-CSRF_COOKIE_SECURE)

誤って HTTP によって CSRF クッキーを送信してしまうのを防ぐには、`True` をセットしてください。

### [`SESSION_COOKIE_SECURE`](/ja/4.1/ref/settings/#std-setting-SESSION_COOKIE_SECURE)

誤って HTTP によってセッションクッキーを送信してしまうのを防ぐには、`True` をセットしてください。

## パフォーマンスの最適化

[`DEBUG = False`](/ja/4.1/ref/settings/#std-setting-DEBUG) をセットすることで、開発向けの複数の機能が無効化されます。加えて、以下の設定をチューンすることもできます。

### セッション

Consider using [cached sessions](/ja/4.1/topics/http/sessions/#cached-sessions-backend) to improve
performance.

If using database-backed sessions, regularly [clear old sessions](/ja/4.1/topics/http/sessions/#clearing-the-session-store) to avoid storing unnecessary data.

### [`CONN_MAX_AGE`](/ja/4.1/ref/settings/#std-setting-CONN_MAX_AGE)

[永続的なデータベース接続](/ja/4.1/ref/databases/#persistent-database-connections) を有効化すると、リクエストのプロセス時間の多くの部分に対するデータベースアカウントへの接続において、高速になります。

限られたネットワーク性能の仮想化ホストにおいて、とても効果的です。

### [`TEMPLATES`](/ja/4.1/ref/settings/#std-setting-TEMPLATES)

Enabling the cached template loader often improves performance drastically, as
it avoids compiling each template every time it needs to be rendered. When
[`DEBUG = False`](/ja/4.1/ref/settings/#std-setting-DEBUG), the cached template loader is enabled
automatically. See [`django.template.loaders.cached.Loader`](/ja/4.1/ref/templates/api/#django.template.loaders.cached.Loader) for more
information.

## エラーのレポート

あなたの書いたコードを本番環境に送信するまでは、頑強であることが望まれますが、予期しないエラーを除外することはできません。ありがたいことに、Django はエラーをキャッチして適切にお知らせします。

### [`LOGGING`](/ja/4.1/ref/settings/#std-setting-LOGGING)

本番環境に置く前に、ロギング設定を見直しましょう。また、トラフィックを受け取ったらすぐにそれらが想定通り動作していることを確認してください。

ロギングに関する詳細は [ロギング](/ja/4.1/topics/logging/) を参照してください。

### [`ADMINS`](/ja/4.1/ref/settings/#std-setting-ADMINS) と [`MANAGERS`](/ja/4.1/ref/settings/#std-setting-MANAGERS)

[`ADMINS`](/ja/4.1/ref/settings/#std-setting-ADMINS) は、500 エラーの通知を E メールで受け取ります。

[`MANAGERS`](/ja/4.1/ref/settings/#std-setting-MANAGERS) は、404 エラーの通知を受け取ります。[`IGNORABLE_404_URLS`](/ja/4.1/ref/settings/#std-setting-IGNORABLE_404_URLS) により不要なレポートをフィルタリングできます。

E メールによるエラーレポートの詳細は、[How to manage error reporting](/ja/4.1/howto/error-reporting/) を参照してください。

> **E メールによるエラーレポートはスケールしない**
>
> あなたの受信箱がレポートであふれかえる前に、[Sentry](https://docs.sentry.io/) などのエラーモニタリングツールの導入を検討してください。Sentry もログを集計することができます。

### デフォルトのエラービューをカスタムする

Django includes default views and templates for several HTTP error codes. You
may want to override the default templates by creating the following templates
in your root template directory: `404.html`, `500.html`, `403.html`, and
`400.html`. The [default error views](/ja/4.1/ref/views/#error-views) that use these
templates should suffice for 99% of web applications, but you can
[customize them](/ja/4.1/topics/http/views/#customizing-error-views) as well.