Djangoのシグナルとは何ですか？

Question

Djangoのシグナルとは何ですか？

Accepted Answer

**シグナル** は、Djangoによるオブザーバーパターンの実装です。特定の **イベント**（モデルの保存や削除など）が発生したときに、特定の送信者が一連の受信者へ通知できるようにします。シグナルは **疎結合** なコードを可能にします。アプリのある部分が、直接的な結合なしに別の部分のイベントに反応するのです。

## 一般的な組み込みシグナル

```text
pre_save / post_save      → before / after a model instance is saved
pre_delete / post_delete  → before / after a model instance is deleted
m2m_changed               → a ManyToMany relationship changed
request_started / finished→ request lifecycle
user_logged_in / out      → authentication events
```

## 受信者をシグナルに接続する

```python
from django.db.models.signals import post_save
from django.dispatch import receiver

# automatically create a Profile whenever a User is created
@receiver(post_save, sender=User)
def create_profile(sender, instance, created, **kwargs):
    if created:                          # only on creation, not every save
        Profile.objects.create(user=instance)
```

`@receiver` デコレータは、関数を特定の送信者のシグナルに接続します。`User` が保存されると、Djangoはこの関数を呼び出し、ここでは関連する `Profile` を自動作成します。`created` フラグは、作成と更新を区別します。

## 典型的なユースケース

```python
@receiver(post_save, sender=Order)
def send_order_confirmation(sender, instance, created, **kwargs):
    if created:
        send_email(instance.customer.email, "Order confirmed")
# the Order-creation code doesn't need to know about emails → decoupled
```

注文を作成するコードは注文に専念したままで、メールのロジックは別の場所に存在しイベントに反応します。これにより関心が疎結合に保たれます。

## シグナルが役立つ場面

```text
✓ Reacting to model events from a DIFFERENT app/module (decoupling)
✓ Auto-creating related objects (Profile on User creation)
✓ Cache invalidation, search-index updates, audit logging on save/delete
✓ Cross-cutting reactions you don't want to embed in the core logic
```

## 重要な注意点: シグナルは明瞭さを損なうことがある

```python
# ⚠️ signals create IMPLICIT, "action at a distance" behavior:
# saving an Order triggers an email somewhere else — not obvious from the save call.
# This can make code HARDER to follow and debug.
```

```text
When to PREFER explicit code over signals:
  ✗ If the logic clearly belongs in the same flow → call it directly (more readable)
  ✗ Overusing signals → hidden, hard-to-trace behavior, debugging difficulty
  ✓ A common alternative: override the model's save() method, or use a service function,
    for logic tightly coupled to the operation
Use signals mainly for genuine DECOUPLING (reacting across app boundaries), not as
a default for all post-save logic.
```

## なぜ重要なのか

シグナルはコードを **疎結合** にするための便利なDjango機能です。アプリケーションのさまざまな部分が、直接的な依存関係なしにイベント（モデルの保存／削除、認証イベント）に反応できるようにします。これは、関連オブジェクトの自動作成、キャッシュの無効化、監査ログ、アプリ境界を越えたイベントへの反応といった横断的な関心事にとって価値があります。

シグナルを理解することは、それらを適切に *使う* ためにも、既存のコードベースで *認識する* ためにも重要です（シグナルは「なぜこれが起きたのか？」という混乱の一般的な原因です）。

しかし、シグナルを特に重要なトピックにしているのは、**いつ使うべきかという微妙な判断** です。シグナルはエレガントな疎結合を可能にする一方で、**暗黙的な「遠隔作用（action-at-a-distance）」の振る舞い** も生み出し、コードを追いかけたりデバッグしたりすることを難しくします（オブジェクトを保存すると、どこか別の場所で定義された効果が不思議と発動する）。

成熟したDjango開発者はこのトレードオフを理解しています。*本物の* 疎結合（ソースに結合すべきでないイベントへ、モジュール／アプリ境界を越えて反応する）のためにシグナルを使う一方で、ロジックが明らかに同じフローに属する場合は **明示的なコード**（ロジックを直接呼び出す、`save()` をオーバーライドする、サービス関数を使う）を好みます。明示的なコードのほうが読みやすく、追跡しやすいからです。

シグナルの仕組み（受信者の接続、`created` フラグ、一般的なシグナル）、正当なユースケース、そして決定的に **いつ使うべきでないか**（隠れていてデバッグしにくい振る舞いを避ける）を知っていることは、保守しやすいDjangoコードを書く開発者と、シグナルを多用してもつれた不透明なアプリケーションを作る開発者とを区別する、実践的で経験に基づいた理解を反映しています。