Novu

チャネルごとの送信実装を、workflowと1つのAPIへまとめる

プロダクト向け機能ではInbox/In-App、Email、SMS、Push、Chatを共通APIから扱い、workflow内でチャネルごとの条件分岐や配信手順を定義できます。複数イベントを一件へまとめるdigest、ノーコードのメール編集、利用者自身が通知方法を選べるpreferences、React向けのリアルタイムな<Inbox />コンポーネントも用意されています。SendGrid、Resend、Amazon SES、Twilioなど多数のproviderをNovuの後ろに置けるため、アプリ側を特定ベンダーのSDKへ直接結び付けずに通知レイヤーを作れます。

出典：[1]

AIエージェントへの受信と返信も、同じconversation modelへ正規化する

Agent Communication Infrastructureでは、Slack、Microsoft Teams、Telegram、WhatsApp、Emailなどから届くメッセージをNovuが受け取り、チャネル固有の形式を共通モデルへ正規化して既存のエージェントへ渡します。エージェントの返信も同じ層から元のチャネルへ返せるため、AI SDK、LangGraph、Claude系エージェントや独自実装など、エージェント本体をNovuへ移さずに通信部分だけを共通化できます。Novu自身がエージェントになるのではなく、『エージェントにユーザーとの会話経路を与える』役割です。

出典：[1]

通知チャネルが増え、配信ロジックやユーザー設定をアプリ本体から切り離したいチームへ

SaaSや業務システムで、メールだけでなくアプリ内通知、SMS、Push、Chatを増やしたいプロダクトチームに向きます。特に、複数providerの切り替え、通知条件、digest、ユーザーごとのpreferences、Inbox UIまで個別実装したくない場合に効果があります。また、AIエージェントをSlackやTeamsなど複数チャネルへ展開する際、チャネルごとにWebhook受信・スレッド・返信処理を作る負担を減らしたい場合にも比較候補になります。

出典：[1]

セルフホストは通知サーバー1個ではなく、複数サービスとprovider資格情報を運用する

セルフホストではNovuのAPI、Worker、WebSocket、Dashboardなどのアプリケーションサービスに加え、MongoDBやRedisなどの依存サービスを運用します。リポジトリのローカル向けDocker Composeは依存サービスだけを起動する開発用構成であり、本番構成そのものではありません。公式READMEでもJWT_SECRETやprovider資格情報を保護し、データベースをアプリケーションと分離するなど、本番向けの設計を別途行うことが推奨されています。各メール・SMS・Push事業者の契約、料金、送信制限もNovuとは別に残ります。

ライセンスはOpen Coreです。コア部分はMITライセンスですが、enterprise/packages配下などEnterprise EditionのコードにはNovu独自の商用ライセンスが適用されます。セルフホスト可能であることをリポジトリ全体がMITで自由利用できることと同一視せず、利用する機能がどちらのライセンス領域に属するかを確認する必要があります。

出典：[2][3][4]