--- title: "システムチェックフレームワーク" version: 5.2 locale: ja source: https://docs.djangoproject.com/ja/5.2/topics/checks/ canonical: https://djangodocs.dev/ja/5.2/topics/checks/ --- # システムチェックフレームワーク システムチェックフレームワークは、Django プロジェクトを検証するための静的チェックのセットです。一般的な問題を検出し、それらを修正するヒントを提供します。このフレームワークは拡張性があり、独自のチェックを簡単に追加できます。 チェックは、[`check`](/ja/5.2/ref/django-admin/#django-admin-check) コマンドを介して明示的にトリガーできます。チェックは、[`runserver`](/ja/5.2/ref/django-admin/#django-admin-runserver) や [`migrate`](/ja/5.2/ref/django-admin/#django-admin-migrate) を含むほとんどのコマンドの前に暗黙的にトリガーされます。パフォーマンスのため、チェックはデプロイメントで使用される WSGI スタックの一部としては実行されません。デプロイメントサーバーでシステムチェックを実行する必要がある場合は、 [`check`](/ja/5.2/ref/django-admin/#django-admin-check) を使用して明示的にトリガーしてください。 重大なエラーは、Djangoのコマンド (たとえば [`runserver`](/ja/5.2/ref/django-admin/#django-admin-runserver)) の実行を完全に停止します。軽微な問題はコンソールに報告されます。警告の原因を調査し、無視しても問題ない場合は、プロジェクトの設定ファイルである [`SILENCED_SYSTEM_CHECKS`](/ja/5.2/ref/settings/#std-setting-SILENCED_SYSTEM_CHECKS) 設定を使用して特定の警告を非表示にできます。 Djangoが発生させる可能性のあるすべてのチェックの完全なリストは、 [システムチェックのリファレンス](/ja/5.2/ref/checks/) にあります。 ## 独自のチェックを書く フレームワークは柔軟で、必要に応じて任意の種類のチェックを実行する関数を書くことができます。以下は、例としてのスタブチェック関数です。 ``` from django.core.checks import Error, register @register() def example_check(app_configs, **kwargs): errors = [] # ... your check logic here if check_failed: errors.append( Error( "an error", hint="A hint.", obj=checked_object, id="myapp.E001", ) ) return errors ``` チェック関数は、 *必ず* `app_configs` 引数を受け入れる必要があります。この引数は、調査されるべきアプリケーションのリストです。 `None` の場合、チェックはプロジェクト内の *すべての* インストールされたアプリで実行される必要があります。 チェックは `databases` キーワード引数を受け取ります。これは、データベースレベルの構成を調査するために使用される可能性のあるデータベースエイリアスのリストです。 `databases` が `None` の場合、チェックはどのデータベース接続も使用してはいけません。 `**kwargs` 引数は将来の拡張のために必要です。 ### メッセージ 関数は、メッセージのリストを返さなければなりません。チェックの結果、問題が見つからない場合、チェック関数は空のリストを返さなければなりません。 チェックメソッドで発生させる警告やエラーは、必ず [`CheckMessage`](/ja/5.2/ref/checks/#django.core.checks.CheckMessage) のインスタンスでなければなりません。[`CheckMessage`](/ja/5.2/ref/checks/#django.core.checks.CheckMessage) のインスタンスは、1つの報告可能なエラーや警告をカプセル化します。また、メッセージに適用可能なコンテキストやヒント、フィルタリングの目的で使用される一意の識別子も提供します。 この概念は、 [メッセージフレームワーク](/ja/5.2/ref/contrib/messages/) や [ログフレームワーク](/ja/5.2/topics/logging/) のメッセージと非常に似ています。メッセージには、メッセージの深刻さを示す「レベル」が付けられます。 一般的なレベルのメッセージを簡単に作成するためのショートカットもあります。これらのクラスを使う場合、引数 `level` はクラス名によって省略できます。 - [`Debug`](/ja/5.2/ref/checks/#django.core.checks.Debug) - [`Info`](/ja/5.2/ref/checks/#django.core.checks.Info) - [`Warning`](/ja/5.2/ref/checks/#django.core.checks.Warning) - [`Error`](/ja/5.2/ref/checks/#django.core.checks.Error) - [`Critical`](/ja/5.2/ref/checks/#django.core.checks.Critical) ### チェックの登録とラベリング 最後に、チェック関数はシステムのチェックレジストリに明示的に登録する必要があります。チェックは、アプリケーションが読み込まれるときに読み込まれるファイル内に登録される必要があります。たとえば、 [`AppConfig.ready()`](/ja/5.2/ref/applications/#django.apps.AppConfig.ready) メソッド内などです。 #### `register(*tags)(function)` `register` には、チェックにラベルを付けるために必要な数のタグを渡すことができます。チェックにタグをつけると、特定のチェックグループだけを実行することができるので便利です。例えば、互換性チェックを登録するには、以下のように呼び出します: ``` from django.core.checks import register, Tags @register(Tags.compatibility) def my_check(app_configs, **kwargs): # ... perform compatibility checks and collect errors return errors ``` 以下のように、本番用の設定ファイルにのみ関係する「デプロイメントチェック」を登録できます: ``` @register(Tags.security, deploy=True) def my_check(app_configs, **kwargs): ... ``` これらのチェックが行われるのは、[`check --deploy`](/ja/5.2/ref/django-admin/#cmdoption-check-deploy) オプションが使用されたときだけです。 また、呼び出し可能オブジェクト（通常は関数）を `register` の第一引数に渡すことで、デコレータではなく関数として `register` を使用することもできます。 下記のコードは上記のコードと等価です: ``` def my_check(app_configs, **kwargs): ... register(my_check, Tags.security, deploy=True) ``` ### フィールド、モデル、マネージャ、テンプレートエンジン、およびデータベースのチェック 場合によっては、チェック機能を登録する必要はありません。既存の登録に「便乗させる」ことができます。 フィールド、モデル、モデルマネージャー、テンプレートエンジン、データベースバックエンドは、すべてチェックフレームワークに登録済みの `check()` メソッドを実装しています。追加のチェックを行いたい場合は、基底クラスの実装を拡張し、必要な追加チェックを実行して、基底クラスで生成されたメッセージに追記することができます。各チェックを個別のメソッドに委譲することを推奨します。 `RangedIntegerField` というカスタムフィールドを実装する例を考えてみましょう。このフィールドは `IntegerField` のコンストラクタに `min` と `max` 引数を追加します。ユーザの min 値が max 値以下であることを確認するチェックを追加できます。次のコードスニペットは、このチェックを実装する方法を示しています: ``` from django.core import checks from django.db import models class RangedIntegerField(models.IntegerField): def __init__(self, min=None, max=None, **kwargs): super().__init__(**kwargs) self.min = min self.max = max def check(self, **kwargs): # Call the superclass errors = super().check(**kwargs) # Do some custom checks and add messages to `errors`: errors.extend(self._check_min_max_values(**kwargs)) # Return all errors and warnings return errors def _check_min_max_values(self, **kwargs): if self.min is not None and self.max is not None and self.min > self.max: return [ checks.Error( "min greater than max.", hint="Decrease min or increase max.", obj=self, id="myapp.E001", ) ] # When no error, return an empty list return [] ``` モデルマネージャにチェックを追加したい場合は、 [`Manager`](/ja/5.2/topics/db/managers/#django.db.models.Manager) のサブクラスで同じアプローチを取ります。 モデルクラスにチェックを追加したい場合、アプローチは *ほとんど* 同じです。唯一の違いは、チェックがインスタンスメソッドではなくクラスメソッドであるということです: ``` class MyModel(models.Model): @classmethod def check(cls, **kwargs): errors = super().check(**kwargs) # ... your own checks ... return errors ``` > **Changed in Django 5.1** > > 以前のバージョンでは、テンプレートエンジンは `check()` メソッドを実装していませんでした。 ### テストを書く メッセージは比較可能なので、次のように簡単にテストを書くことができます。 ``` from django.core.checks import Error errors = checked_object.check() expected_errors = [ Error( "an error", hint="A hint.", obj=checked_object, id="myapp.E001", ) ] self.assertEqual(errors, expected_errors) ``` #### インテグレーションテストを書く アプリケーションの読み込み時には特定のチェックを登録する必要があるため、システムチェックフレームワーク内での統合をテストするのが便利です。これは [`call_command()`](/ja/5.2/ref/django-admin/#django.core.management.call_command) 関数を使うことで実現できます。 例えば、このテストは [`SITE_ID`](/ja/5.2/ref/settings/#std-setting-SITE_ID) の設定が整数でなければならないことを示しています。これは組み込みの [サイト フレームワークからのチェック](/ja/5.2/ref/checks/#sites-system-checks) のものです: ``` from django.core.management import call_command from django.core.management.base import SystemCheckError from django.test import SimpleTestCase, modify_settings, override_settings class SystemCheckIntegrationTest(SimpleTestCase): @override_settings(SITE_ID="non_integer") @modify_settings(INSTALLED_APPS={"prepend": "django.contrib.sites"}) def test_non_integer_site_id(self): message = "(sites.E101) The SITE_ID setting must be an integer." with self.assertRaisesMessage(SystemCheckError, message): call_command("check") ``` `ENABLE_ANALYTICS` というカスタム設定が `True` に設定されていない場合に、デプロイ時に警告を発行する以下のチェックを考えてみましょう: ``` from django.conf import settings from django.core.checks import Warning, register @register("myapp", deploy=True) def check_enable_analytics_is_true_on_deploy(app_configs, **kwargs): errors = [] if getattr(settings, "ENABLE_ANALYTICS", None) is not True: errors.append( Warning( "The ENABLE_ANALYTICS setting should be set to True in deployment.", id="myapp.W001", ) ) return errors ``` このチェックが `SystemCheckError` を発生させないことを考えると、以下のように、 `stderr` の出力に警告メッセージがあることをアサートできます: ``` from io import StringIO from django.core.management import call_command from django.test import SimpleTestCase, override_settings class EnableAnalyticsDeploymentCheckTest(SimpleTestCase): @override_settings(ENABLE_ANALYTICS=None) def test_when_set_to_none(self): stderr = StringIO() call_command("check", "-t", "myapp", "--deploy", stderr=stderr) message = ( "(myapp.W001) The ENABLE_ANALYTICS setting should be set " "to True in deployment." ) self.assertIn(message, stderr.getvalue()) ```