Skip to main content
パッケージから通知の配信方法を増やしたいときは、チャネルの選択と通知先の決定を分けて設計します。このページでは運用イベントをログに記録する小さなチャネルを例に、パッケージで提供するクラスの解決経路と、更新時に必要な検証を説明します。外部サービスへの送信に置き換える場合も、チャネルと通知の責任分担は同じです。 Laravel Framework v13.38.0 の実装を確認しています。通知の基本操作は通知、パッケージのテスト環境はパッケージのテストを参照してください。

クラス名は配信方法、ルートは宛先

via() に返すチャネルクラス名は、どのオブジェクトの send() を呼ぶかを指定します。一方、routeNotificationFor() から取得する値は、そのチャネルが使う宛先です。両者を同じ名前にする必要はありません。 NotificationSender は via() が選んだチャネル名を ChannelManager::driver() に渡します。ChannelManager は組み込み名や登録済みの名前で見つからず、名前が実在するクラスなら、コンテナでそのクラスを解決します。クラス名で使うだけなら Notification::extend() やパッケージのサービスプロバイダーは不要です。Composerのオートロードでクラスが見つかり、コンストラクターの依存をコンテナが解決できるようにします。

チャネル本体をパッケージで提供する

例の Acme\OperationsLog パッケージは、機密情報を含まないイベント名を、通知先の運用チーム名とともに記録します。Laravelアプリケーションでは Psr\Log\LoggerInterface がログサービスに割り当てられるため、コンストラクターから受け取れます。
受け取るオブジェクトは Notifiable トレイトを使うモデルか、Notification::route() が作るオンデマンド通知先を想定しています。前者では routeNotificationForOperationsLog()、後者では route('operationsLog', ...) の登録値が返ります。宛先がないまま配信済みとして扱わないよう、この例では例外にします。実際の外部配信に置き換える場合も、宛先や送信結果を確認し、失敗を成功として握りつぶさない設計にします。
ログに記録するイベント名や宛先に、アクセストークンや個人情報を含めないでください。この例はチャネル解決とテストを示すためのログ送信であり、外部サービスへの配信実装ではありません。

利用側で通知と宛先を定義する

アプリケーションの通知はチャネルクラスを返し、チャネルに渡すメッセージだけを定義します。ShouldQueue と Queueable を使うと、通常の notify() 呼び出しはキュー経由になります。
宛先をその場で指定する場合、Notification::route() のキーはチャネルクラス名ではなく、チャネル内で呼ぶ routeNotificationFor('operationsLog', ...) のキーです。
アプリケーションのモデルから送る場合は、Notifiable を使うモデルに次のメソッドを用意します。
このモデルに対する $user->notify(new HealthCheckPassed()) でも同じチャネルが選ばれます。キュー接続を設定し、operations-log キューを処理するワーカーを起動してください。
OperationsLogChannel 自体はチャネルごとにManagerへ保持されるため、通知先や通知本文をチャネルのプロパティに保存しないで、毎回の send() の引数から取り出してください。長時間稼働するキューワーカーでも前の通知の情報を持ち越さないためです。

名前の短いエイリアスが必要な場合

利用者に via() でクラス名でなく短い名前を指定させたい場合だけ、パッケージの通常のサービスプロバイダーで Notification::extend() を使います。
プロバイダーはパッケージの自動検出などで、配信処理が始まる前に読み込ませます。エイリアスを選ぶ通知では via() を ['acme-operations-log'] に、viaQueues() のキーも同じ名前に変更します。宛先取得用の operationsLog は別のキーなので変更不要です。組み込みチャネル名と衝突しない名前を使ってください。 Managerは解決したチャネルを名前ごとに保持します。同じプロセスでエイリアスの生成処理を再登録しても、すでに生成済みのインスタンスは置き換わりません。登録方法の変更は、新しく起動したアプリケーションやワーカーでも検証してください。

fakeとは別に配信処理をテストする

Notification::fake() は通知を送る意図を検証するためのものです。チャネルの send() やルートの取得が動くことは確認できません。配信のテストでは本物の通知Managerを使い、LoggerInterface をテスト用に置き換えます。 次はTestbenchの TestCase から実行する例です。notifyNow() を使うと、ShouldQueue 通知でもワーカーを起動せずチャネルの処理を実行できます。
加えて、宛先がない場合に例外になること、エイリアスを提供する場合に新規起動から解決できることを確認します。キュー経由で使う場合は、別途キューワーカーを動かす検証アプリケーションで、operations-log キューにジョブが届き処理されることもテストします。 NotificationSender は ShouldQueue の通知をチャネルごとにジョブへ分け、viaQueues() のキーでキューを選びます。チャネルの send() が例外を投げた場合は NotificationFailed を発火して例外を再送出し、正常に戻った場合に NotificationSent を発火します。キューの再試行設定はアプリケーションの設定に従います。例外をチャネル内で握りつぶすと、配信に失敗しても成功として扱われる点に注意してください。

参照した一次情報

最終更新日 2026年10月22日