---
title: "シグナル"
version: 6.0
locale: ja
source: https://docs.djangoproject.com/ja/6.0/ref/signals/
canonical: https://djangodocs.dev/ja/6.0/ref/signals/
---
# シグナル

Djangoが送信する全てのシグナルのリストです。全ての組み込みシグナルは [`send()`](/ja/6.0/topics/signals/#django.dispatch.Signal.send) メソッドを使用して送信されます。

> **See also**
>
> シグナルの登録方法と受信方法に関する情報については、[シグナルディスパッチャ](/ja/6.0/topics/signals/) のドキュメントを参照してください。
>
> [認証フレームワーク](/ja/6.0/topics/auth/) は、ユーザーがログイン / ログアウトしたときに [シグナルを送信します](/ja/6.0/ref/contrib/auth/#topics-auth-signals) 。

## モデルのシグナル

[`django.db.models.signals`](#module-django.db.models.signals) モジュールは、モデルシステムによって送信される一連のシグナルを定義しています。

> **Warning**
>
> シグナルはコードの保守を難しくする可能性があります。モデルを更新し、追加ロジックを実行するために、 [カスタムマネージャ](/ja/6.0/topics/db/managers/#custom-managers) にヘルパーメソッドを実装するか、あるいはモデルのシグナルを使用する前に [モデルメソッドをオーバーライド](/ja/6.0/topics/db/models/#overriding-model-methods) することを検討してください。

> **Warning**
>
> これらのシグナルの多くは、 `__init__()` や [`save()`](/ja/6.0/ref/models/instances/#django.db.models.Model.save) のような、自分のコードでオーバーライドできる様々なモデルメソッドによって送信されます。
>
> これらのメソッドをモデルでオーバーライドする場合、これらのシグナルが送信されるように、親クラスのメソッドを呼び出さなければなりません。
>
> Note also that Django stores signal handlers as weak references by default,
> so if your handler is a local function, it may be garbage collected. To
> prevent this, pass `weak=False` when you call the signal's
> [`connect()`](/ja/6.0/topics/signals/#django.dispatch.Signal.connect).

> **Note**
>
> モデルシグナルの `sender` モデルは、レシーバを接続する際にその完全なアプリケーションラベルを指定することで、遅延参照ができます。例えば、 `polls` アプリケーションで定義された `Question` モデルは、`'polls.Question'` として参照できます。この種の参照は、循環インポートの依存関係や交換可能なモデルを扱う際に非常に便利です。

### `pre_init`

#### `django.db.models.signals.pre_init`

Django モデルをインスタンス化するたびに、このシグナルはモデルの `__init__()` メソッドの開始時に送信されます。

このシグナルとともに送信される引数は以下の通りです:

**`sender`**

  たった今インスタンスが作成されたモデルクラス。

**`args`**

  `__init__()` に渡される位置引数のリストです。

**`kwargs`**

  `__init__()` に渡されるキーワード引数の辞書。

例えば、 [チュートリアル](/ja/6.0/intro/tutorial02/) にはこのような行があります：

```
q = Question(question_text="What's new?", pub_date=timezone.now())
```

[`pre_init`](#django.db.models.signals.pre_init) ハンドラーに送信される引数は次の通りです：

| 引数 | 値 |
| --- | --- |
| `sender` | `Question` （クラスそのもの） |
| `args` | `[]` （位置引数が `__init__()` に渡されなかったため、空のリスト） |
| `kwargs` | `{'question_text': "What's new?",`<br>`'pub_date': datetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=datetime.UTC)}` |

### `post_init`

#### `django.db.models.signals.post_init`

pre\_init と似ていますが、このイベントは `__init__()` メソッドが終了した時に送信されます。

このシグナルとともに送信される引数は以下の通りです:

**`sender`**

  上記の通り: たった今インスタンスが作成されたモデルクラス。

**`instance`**

  たった今作成されたモデルの実際のインスタンス。

  > **Note**
  >
  > [`instance._state`](/ja/6.0/ref/models/instances/#django.db.models.Model._state) は、`post_init` シグナルを送信する前に設定されていないため、`_state` 属性は常にそのデフォルト値を持ちます。例えば、`_state.db` は `None` です。

> **Warning**
>
> パフォーマンス上の理由から、 `pre_init` または `post_init` シグナルのレシーバでクエリを実行するべきではありません。なぜなら、クエリセットのイテレート中に返される各インスタンスに対して実行されるからです。

### `pre_save`

#### `django.db.models.signals.pre_save`

これは、モデルの [`save()`](/ja/6.0/ref/models/instances/#django.db.models.Model.save) メソッドの始まりに送信されます。

このシグナルとともに送信される引数は以下の通りです:

**`sender`**

  モデルクラス。

**`instance`**

  保存される実際のインスタンス。

**`raw`**

  真偽値です。モデルがそのままの形 (例えば [フィクスチャ](/ja/6.0/topics/db/fixtures/#fixtures-explanation) を読み込む時) で保存されている場合は `True` となります。データベースがまだ一貫した状態にない可能性があるため、他のレコードをクエリしたり変更したりするべきではありません。

**`using`**

  使用されているデータベースのエイリアス。

**`update_fields`**

  [`Model.save()`](/ja/6.0/ref/models/instances/#django.db.models.Model.save) に渡された更新するフィールドのセット、もしくは `update_fields` が `save()` に渡されなかった場合は `None`  。

### `post_save`

#### `django.db.models.signals.post_save`

[`pre_save`](#django.db.models.signals.pre_save) に似ていますが、 [`save()`](/ja/6.0/ref/models/instances/#django.db.models.Model.save) メソッドの最後に送信されます。

このシグナルとともに送信される引数は以下の通りです:

**`sender`**

  モデルクラス。

**`instance`**

  保存される実際のインスタンス。

**`created`**

  ブール値。レコードが作成された場合に `True` を返す。

**`raw`**

  真偽値です。モデルがそのままの形 (例えば [フィクスチャ](/ja/6.0/topics/db/fixtures/#fixtures-explanation) を読み込む時) で保存されている場合は `True` となります。データベースがまだ一貫した状態にない可能性があるため、他のレコードをクエリしたり変更したりするべきではありません。

**`using`**

  使用されているデータベースのエイリアス。

**`update_fields`**

  [`Model.save()`](/ja/6.0/ref/models/instances/#django.db.models.Model.save) に渡された更新するフィールドのセット、もしくは `update_fields` が `save()` に渡されなかった場合は `None`  。

### `pre_delete`

#### `django.db.models.signals.pre_delete`

モデルの [`delete()`](/ja/6.0/ref/models/instances/#django.db.models.Model.delete) メソッドとクエリセットの [`delete()`](/ja/6.0/ref/models/querysets/#django.db.models.query.QuerySet.delete) メソッドの開始時に送信されます。

このシグナルとともに送信される引数は以下の通りです:

**`sender`**

  モデルクラス。

**`instance`**

  実際に削除されるインスタンス。

**`using`**

  使用されているデータベースのエイリアス。

**`origin`**

  削除の起点となった `Model` または `QuerySet` インスタンス、すなわち `delete()` メソッドが呼び出されたインスタンス。

### `post_delete`

#### `django.db.models.signals.post_delete`

[`pre_delete`](#django.db.models.signals.pre_delete) のようですが、モデルの [`delete()`](/ja/6.0/ref/models/instances/#django.db.models.Model.delete) メソッドとクエリセットの [`delete()`](/ja/6.0/ref/models/querysets/#django.db.models.query.QuerySet.delete) メソッドの終わりに送信されます。

このシグナルとともに送信される引数は以下の通りです:

**`sender`**

  モデルクラス。

**`instance`**

  実際に削除されるインスタンス。

  このオブジェクトはデータベース内に存在しなくなるため、このインスタンスをどのように扱うか非常に注意してください。

**`using`**

  使用されているデータベースのエイリアス。

**`origin`**

  削除の起点となった `Model` または `QuerySet` インスタンス、すなわち `delete()` メソッドが呼び出されたインスタンス。

### `m2m_changed`

#### `django.db.models.signals.m2m_changed`

モデルインスタンス上の [`ManyToManyField`](/ja/6.0/ref/models/fields/#django.db.models.ManyToManyField) が変更されたときに送信されます。厳密には、これはモデルシグナルではありません。なぜなら、これは [`ManyToManyField`](/ja/6.0/ref/models/fields/#django.db.models.ManyToManyField) によって送信されるためです。しかし、モデルへの変更を追跡する際に、 [`pre_save`](#django.db.models.signals.pre_save)/[`post_save`](#django.db.models.signals.post_save) および [`pre_delete`](#django.db.models.signals.pre_delete)/[`post_delete`](#django.db.models.signals.post_delete) を補完するものであるため、ここに含まれています。

このシグナルとともに送信される引数は以下の通りです:

**`sender`**

  [`ManyToManyField`](/ja/6.0/ref/models/fields/#django.db.models.ManyToManyField) を記述する中間モデルクラスです。多対多フィールドが定義されたときに自動的に作成されます。多対多フィールドの `through` 属性を使用してアクセスできます。

**`instance`**

  多対多のリレーションが更新されたインスタンス。これは `sender` のインスタンス、または [`ManyToManyField`](/ja/6.0/ref/models/fields/#django.db.models.ManyToManyField) が関連づけられているクラスのインスタンスのいずれかです。

**`action`**

  リレーションに対して行われた更新の種類を表す文字列です。次のいずれかの値を取ります。

  **`"pre_add"`**

    リレーションにオブジェクトが1つ以上追加される *前* に送信されます。

  **`"post_add"`**

    リレーションに1つ以上のオブジェクトが追加された *後* に送信されます。

  **`"pre_remove"`**

    リレーションから 1 つ以上のオブジェクトが削除される *前* に送信されます。

  **`"post_remove"`**

    リレーションから1つ以上のオブジェクトが削除された *後に* 送信されます。

  **`"pre_clear"`**

    リレーションがクリアされる *前に* 送信されます。

  **`"post_clear"`**

    リレーションがクリアされた *後* に送信されます。

**`reverse`**

  リレーションのどちらの側が更新されているかを示します (つまり、更新されているのが順方向のリレーションか、逆方向のリレーションかを表します)。

**`model`**

  リレーションに追加、削除、またはクリアされるオブジェクトのクラス。

**`pk_set`**

  `pre_add` と `post_add` アクションの場合、これはリレーションに追加される、または追加された主キー値のセットです。既存の値をフィルタリングしてデータベースの `IntegrityError` を避ける必要があるため、追加されることが提出された値のサブセットである可能性があります。

  `pre_remove` と `post_remove` アクションにおいて、これはリレーションから削除されることが提案された主キーの値のセットです。これは、値が実際に削除されるか、または削除されたかどうかに依存しません。特に、存在しない値が提出されることもあり、`pk_set` に表示されますが、データベースには影響を与えません。

  `pre_clear` と `post_clear` アクションの場合、これは `None` です。

**`using`**

  使用されているデータベースのエイリアス。

たとえば、`Pizza` が複数の `Topping` オブジェクトを持てるとしたら、次のようにモデル化されます。

```
class Topping(models.Model):
    # ...
    pass

class Pizza(models.Model):
    # ...
    toppings = models.ManyToManyField(Topping)
```

このようにハンドラーを接続した場合：

```
from django.db.models.signals import m2m_changed

def toppings_changed(sender, **kwargs):
    # Do something
    pass

m2m_changed.connect(toppings_changed, sender=Pizza.toppings.through)
```

そして、次のようにした場合:

```pycon
>>> p = Pizza.objects.create(...)
>>> t = Topping.objects.create(...)
>>> p.toppings.add(t)
```

[`m2m_changed`](#django.db.models.signals.m2m_changed) ハンドラ (上記の例では `toppings_changed`) に送信された引数は、次の通りです:

| 引数 | 値 |
| --- | --- |
| `sender` | `Pizza.toppings.through` (中間の m2m クラス) |
| `instance` | `p` (変更されている `Pizza` インスタンス) |
| `action` | `"pre_add"` (その後に別のシグナルで `"post_add"` が続く) |
| `reverse` | `False` (`Pizza` には [`ManyToManyField`](/ja/6.0/ref/models/fields/#django.db.models.ManyToManyField) が含まれているため、この呼び出しは順方向のリレーションを変更します) |
| `model` | `Topping` ( `Pizza` に追加されるオブジェクトのクラス) |
| `pk_set` | ```{t.id}``（リレーションには ``Topping t``` だけが追加されたため） |
| `using` | `"default"` (デフォルトルーターが書き込みをここに送るため) |

そして、次のようなことをした場合：

```pycon
>>> t.pizza_set.remove(p)
```

[`m2m_changed`](#django.db.models.signals.m2m_changed) ハンドラに送信される引数は以下の通りです:

| 引数 | 値 |
| --- | --- |
| `sender` | `Pizza.toppings.through` (中間の m2m クラス) |
| `instance` | `t` (変更されている `Topping` インスタンス) |
| `action` | `"pre_remove"` (その後に別のシグナルとして `"post_remove"` が続きます) |
| `reverse` | `True` (`Pizza` は [`ManyToManyField`](/ja/6.0/ref/models/fields/#django.db.models.ManyToManyField) を含んでいるため、この呼び出しは逆方向のリレーションを変更します) |
| `model` | `Pizza` (`Topping` から取り除かれたオブジェクトのクラス) |
| `pk_set` | `{p.id}` (リレーションから `Pizza p` のみが削除されたため) |
| `using` | `"default"` (デフォルトルーターが書き込みをここに送るため) |

### `class_prepared`

#### `django.db.models.signals.class_prepared`

モデルクラスが「準備完了」したとき――つまり、モデルが定義され、Djangoのモデルシステムに登録された後に送信されます。Djangoはこのシグナルを内部的に使用しています。通常、サードパーティのアプリケーションで使用されることはありません。

このシグナルはアプリ登録プロセス中に送信されます。そして [`AppConfig.ready()`](/ja/6.0/ref/applications/#django.apps.AppConfig.ready) はアプリ登録が完全に終了した後に実行されますので、レシーバーをそのメソッド内で接続することはできません。一つの可能性としては、 `AppConfig.__init__()` の中でそれらを接続することですが、モデルをインポートしたり、アプリ登録への呼び出しを触発しないよう注意が必要です。

このシグナルで送信される引数：

**`sender`**

  たった今準備されたモデルクラス。

## 管理シグナル

[django-admin](/ja/6.0/ref/django-admin/) によって送信されるシグナル。

### `pre_migrate`

#### `django.db.models.signals.pre_migrate`

[`migrate`](/ja/6.0/ref/django-admin/#django-admin-migrate) コマンドによって、アプリケーションのインストールを開始する前に送信されます。`models` モジュールがないアプリケーションには発行されません。

このシグナルとともに送信される引数は以下の通りです:

**`sender`**

  マイグレーションまたは同期される予定のアプリケーションのための [`AppConfig`](/ja/6.0/ref/applications/#django.apps.AppConfig) インスタンスです。

**`app_config`**

  `sender` と同じ。

**`verbosity`**

  `manage.py` が画面上にどれだけ情報を表示しているかを示します。詳細については [`--verbosity`](/ja/6.0/ref/django-admin/#cmdoption-verbosity) フラグを参照してください。

  [`pre_migrate`](#django.db.models.signals.pre_migrate) のためにリスナーとなる関数は、この引数の値に基づいて画面出力を調整するべきです。

**`interactive`**

  `interactive` が `True` の場合、コマンドラインでユーザーに入力を求めるのは安全です。 `interactive` が `False` の場合、このシグナルを待ち受ける関数は何も求めてはいけません。

  たとえば、[`django.contrib.auth`](/ja/6.0/topics/auth/#module-django.contrib.auth) アプリは、`interactive` が `True` のときのみスーパーユーザーの作成を促します。

**`stdout`**

  冗長な出力をリダイレクトすべきストリームのようなオブジェクト。

**`using`**

  コマンドが操作を行うデータベースのエイリアスです。

**`plan`**

  マイグレーション実行に使用されるマイグレーションプランです。プランはパブリックAPIではありませんが、プランを知る必要がある稀なケースに対応します。プランは2値タプルのリストで、最初の項目はマイグレーションクラスのインスタンスであり、2番目の項目はマイグレーションがロールバックされた (`True`) か適用された (`False`) かを示します。

**`apps`**

  マイグレーションを実行する前のプロジェクトの状態を含む [`Apps`](/ja/6.0/ref/applications/#module-django.apps) のインスタンスです。操作を行いたいモデルを取得するために、グローバルな [`apps`](/ja/6.0/ref/applications/#django.apps.apps) レジストリの代わりに使用すべきです。

### `post_migrate`

#### `django.db.models.signals.post_migrate`

[`migrate`](/ja/6.0/ref/django-admin/#django-admin-migrate) コマンドの終わりに (マイグレーションが行われなくても)、そして [`flush`](/ja/6.0/ref/django-admin/#django-admin-flush) コマンドの後に送信されます。`models` モジュールがないアプリケーションには発行されません。

このシグナルのハンドラは、データベーススキーマの変更を行ってはなりません。なぜなら、そのような変更を行うと、[`migrate`](/ja/6.0/ref/django-admin/#django-admin-migrate) コマンド実行中に [`flush`](/ja/6.0/ref/django-admin/#django-admin-flush) コマンドが失敗する可能性があるからです。

このシグナルとともに送信される引数は以下の通りです:

**`sender`**

  インストールされたばかりのアプリケーション用の [`AppConfig`](/ja/6.0/ref/applications/#django.apps.AppConfig) インスタンスです。

**`app_config`**

  `sender` と同じ。

**`verbosity`**

  `manage.py` が画面上にどれだけ情報を表示しているかを示します。詳細については [`--verbosity`](/ja/6.0/ref/django-admin/#cmdoption-verbosity) フラグを参照してください。

  [`post_migrate`](#django.db.models.signals.post_migrate) を待ち受ける関数は、この引数の値に基づいて画面に出力する内容を調整する必要があります。

**`interactive`**

  `interactive` が `True` の場合、コマンドラインでユーザーに入力を求めるのは安全です。 `interactive` が `False` の場合、このシグナルを待ち受ける関数は何も求めてはいけません。

  たとえば、[`django.contrib.auth`](/ja/6.0/topics/auth/#module-django.contrib.auth) アプリは、`interactive` が `True` のときのみスーパーユーザーの作成を促します。

**`stdout`**

  冗長な出力をリダイレクトすべきストリームのようなオブジェクト。

**`using`**

  同期に使用されるデータベースエイリアスです。デフォルトは `default` データベースです。

**`plan`**

  マイグレーション実行に使用されたマイグレーションプラン。プランはパブリックAPIではありませんが、プランを知る必要がある稀な場合に対応します。プランは2値タプルのリストで、最初の項目はマイグレーションクラスのインスタンスであり、2番目の項目はマイグレーションがロールバックされたか（`True`）適用されたか（`False`）を示します。

**`apps`**

  マイグレーション実行後のプロジェクトの状態を保持する [`Apps`](/ja/6.0/ref/applications/#django.apps.apps) のインスタンスです。グローバルな [`apps`](/ja/6.0/ref/applications/#django.apps.apps) レジストリの代わりに、操作を行いたいモデルを取得するために使用するべきです。

たとえば、次のように [`AppConfig`](/ja/6.0/ref/applications/#django.apps.AppConfig) にコールバックを登録できます:

```
from django.apps import AppConfig
from django.db.models.signals import post_migrate

def my_callback(sender, **kwargs):
    # Your specific logic here
    pass

class MyAppConfig(AppConfig):
    ...

    def ready(self):
        post_migrate.connect(my_callback, sender=self)
```

> **Note**
>
> [`AppConfig`](/ja/6.0/ref/applications/#django.apps.AppConfig) インスタンスを sender 引数として提供する場合は、シグナルが [`ready()`](/ja/6.0/ref/applications/#django.apps.AppConfig.ready) で登録されていることを確認してください。 `AppConfig` は、 [`INSTALLED_APPS`](/ja/6.0/ref/settings/#std-setting-INSTALLED_APPS) の変更されたセットで実行されるテストのために再作成されます（例えば設定が上書きされた場合など）し、そのようなシグナルは新しい `AppConfig` インスタンスごとに接続されるべきです。

## リクエスト/レスポンス シグナル

リクエストを処理する際にコアフレームワークによって送信されるシグナル。

> **Warning**
>
> シグナルはコードのメンテナンスを難しくする可能性があります。リクエスト/レスポンスシグナルを使用する前に、 [ミドルウェアを使用する](/ja/6.0/topics/http/middleware/) ことを検討してください。

### `request_started`

#### `django.core.signals.request_started`

Django が HTTP リクエストの処理を開始したときに送信されます。

このシグナルとともに送信される引数は以下の通りです:

**`sender`**

  リクエストを処理したハンドラクラス。例えば `django.core.handlers.wsgi.WsgiHandler` が該当します。

**`environ`**

  リクエストに提供される `environ` 辞書。

### `request_finished`

#### `django.core.signals.request_finished`

クライアントへの HTTP レスポンスの配信が完了したときに送信されます。

このシグナルとともに送信される引数は以下の通りです:

**`sender`**

  上述のようなハンドラークラスです。

### `got_request_exception`

#### `django.core.signals.got_request_exception`

このシグナルは、Djangoが受信HTTPリクエストの処理中に例外に遭遇したときにいつでも送信されます。

このシグナルとともに送信される引数は以下の通りです:

**`sender`**

  使用されません (常に `None`)。

**`request`**

  [`HttpRequest`](/ja/6.0/ref/request-response/#django.http.HttpRequest) オブジェクト。

## テストシグナル

テストを [実行しているとき](/ja/6.0/topics/testing/overview/#running-tests) のみ送信されるシグナル。

### `setting_changed`

#### `django.test.signals.setting_changed`

このシグナルは、 `django.test.TestCase.settings()` コンテキストマネージャや [`django.test.override_settings()`](/ja/6.0/topics/testing/tools/#django.test.override_settings) デコレータ/コンテキストマネージャを通じて設定の値が変更されたときに送信されます。

実際には2回送信されます。新しい値が適用されたとき（"setup"）と、元の値が復元されたとき（"teardown"）。2つを区別するには、`enter` 引数を使用してください。

このシグナルは `django.core.signals` からインポートすることもできます。これにより、テスト以外の状況で `django.test` からインポートすることを避けられます。

このシグナルとともに送信される引数は以下の通りです:

**`sender`**

  設定ハンドラ。

**`setting`**

  設定の名前。

**`value`**

  設定変更後の設定値です。初めに存在しない設定の場合、 "teardown" フェーズでは `value` は `None` です。

**`enter`**

  真偽値。設定が適用されている場合は `True`、復元された場合は `False`。

### `template_rendered`

#### `django.test.signals.template_rendered`

テストシステムがテンプレートをレンダリングするときに送信されます。このシグナルは、Djangoサーバーの通常の操作中には発生しません。テスト中にのみ利用可能です。

このシグナルとともに送信される引数は以下の通りです:

**`sender`**

  レンダリングされた [`Template`](/ja/6.0/ref/templates/api/#django.template.Template) オブジェクト。

**`template`**

  送信者と同じ

**`context`**

  テンプレートがレンダリングされた際の [`Context`](/ja/6.0/ref/templates/api/#django.template.Context) 。

## データベースラッパー

データベース接続が開始されたときに、データベースラッパーによって送信されるシグナル。

### `connection_created`

#### `django.db.backends.signals.connection_created`

Sent when the database wrapper makes the initial connection to the
database. This is particularly useful if you'd like to send any post
connection commands to the SQL backend.

このシグナルとともに送信される引数は以下の通りです:

**`sender`**

  データベースラッパークラス ― つまり、 `django.db.backends.postgresql.DatabaseWrapper` や `django.db.backends.mysql.DatabaseWrapper` などです。

**`connection`**

  オープンされたデータベース接続です。これは、複数のデータベース設定を使用する際に、異なるデータベースからの接続シグナルを区別するために使用されます。

## Tasks signals

> **New in Django 6.0**

Signals sent by the [tasks](/ja/6.0/ref/tasks/) framework.

### `task_enqueued`

#### `django.tasks.signals.task_enqueued`

Sent once a Task has been enqueued.

このシグナルとともに送信される引数は以下の通りです:

**`sender`**

  The backend class which the Task was enqueued on to.

**`task_result`**

  The enqueued [`TaskResult`](/ja/6.0/ref/tasks/#django.tasks.TaskResult).

### `task_started`

#### `django.tasks.signals.task_started`

Sent when a Task has started executing.

このシグナルとともに送信される引数は以下の通りです:

**`sender`**

  The backend class which the Task was enqueued on to.

**`task_result`**

  The started [`TaskResult`](/ja/6.0/ref/tasks/#django.tasks.TaskResult).

### `task_finished`

#### `django.tasks.signals.task_finished`

Sent once a Task has finished executing, successfully or otherwise.

このシグナルとともに送信される引数は以下の通りです:

**`sender`**

  The backend class which the Task was enqueued on to.

**`task_result`**

  The finished [`TaskResult`](/ja/6.0/ref/tasks/#django.tasks.TaskResult).