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

インターネットは敵意ある環境です。あなたの Django プロジェクトをデプロイする前に、セキュリティ、パフォーマンスおよびオペレーションに関する設定を一通り見直す時間を取ってください。

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

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

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

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

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

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

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

## 最重要な設定

### [`SECRET_KEY`](/ja/2.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()
```

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

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

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

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

## 環境に合わせた設定

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

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

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

加えて、Django の手前にいるウェブサーバーにも、ホストを検証するよう設定をする必要があります。これにより、不適切なホストに対して、Django にリクエストを転送する代わりに、エラーページを表示したりリクエストを無視するようにできます。そして、Django のログ内で誤ったエラーが起きる (もしくは設定しだいでは E メールが送信される) のを防ぎます。たとえば、nginx では認識されないホストに対してデフォルトサーバーが "444 No Response" を返します:

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

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

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

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

もしあなたがMemcachedを使うなら、より性能を向上させるために cached sessions を使うことも検討してください。

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

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

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

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

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

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

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

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

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

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

より詳しくは [静的ファイル (画像、JavaScript、CSS など) を管理する](/ja/2.1/howto/static-files/) を参照してください。

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

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

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

### [`FILE_UPLOAD_PERMISSIONS`](/ja/2.1/ref/settings/#std-setting-FILE_UPLOAD_PERMISSIONS)

With the default file upload settings, files smaller than
[`FILE_UPLOAD_MAX_MEMORY_SIZE`](/ja/2.1/ref/settings/#std-setting-FILE_UPLOAD_MAX_MEMORY_SIZE) may be stored with a different mode
than larger files as described in [`FILE_UPLOAD_PERMISSIONS`](/ja/2.1/ref/settings/#std-setting-FILE_UPLOAD_PERMISSIONS).

Setting [`FILE_UPLOAD_PERMISSIONS`](/ja/2.1/ref/settings/#std-setting-FILE_UPLOAD_PERMISSIONS) ensures all files are uploaded with
the same permissions.

## HTTPS

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

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

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

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

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

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

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

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

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

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

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

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

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

キャッシュされたテンプレートローダーを有効化すると、描画のたびにテンプレートを変換しなくなるので、しばしばパフォーマンスを劇的に改善します。詳しくは [テンプレートローダーのドキュメント](/ja/2.1/ref/templates/api/#template-loaders) を参照してください。

## エラーのレポート

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

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

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

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

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

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

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

E メールによるエラーレポートの詳細は、[エラーのレポート](/ja/2.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/2.1/ref/views/#error-views) that use these
templates should suffice for 99% of Web applications, but you can
[customize them](/ja/2.1/topics/http/views/#customizing-error-views) as well.