本文へスキップ

Dittofeedの代替ツール(2026年)

Dittofeedのメンテナーは2026年8月、プロジェクトがメンテナンスモードに入り、機能開発を停止したと表明しました。ソフトウェアは今も動き、クラウド版も販売中なので、多くのチームは急いでいません。移るなら、同等のオープンソースはMautic、同等のマネージドはCustomer.io、本格的なジャーニーを最も安く使えるのはLoops、通知の配管だけが必要だったならNovuです。

更新日:9分で読めます執筆 fromHello

要点

  1. 状態の変化は本物ですが、目立ちません。ユーザーの質問という体裁のGitHub issueに投稿され、2分以内にクローズされたため、Dittofeedを運用している人の多くはこのことを知りません。

  2. メンテナンスモードは放棄ではありません。MITライセンスのコアは今も動き、ホスト型のクラウドも販売されています。コメントが投稿された日に、インストール済みの環境の何かが動かなくなったわけではありません。

  3. ロックインはされていません。管理APIはジャーニー、セグメント、ユーザープロパティ、ユーザー、生のイベント、配信記録、購読状態を返し、データ取り込みはSegment互換でした。そのため、移行は記憶を頼りにしたつくり直しではなく、エクスポートで済みます。

  4. Mauticなら、Dittofeedの形をそのまま、成熟したオープンソースで取り戻せます。セルフホスト、送信プロバイダーの持ち込み、ビジュアルのジャーニー、セグメントです。セルフホストのfromHelloも4つすべてを満たしますが、コードベースはより新しいものです。それ以外の移行先では、どれか1つを手放すことになります。

候補ツール

2026年8月10日、あるユーザーがDittofeedはまだ活動しているのかと質問しました。メンテナーは、プロジェクトはメンテナンスモードで、バグ修正はまれにしか行わず、新機能は追加しないと回答し、その1秒後、issueが開かれてから94秒後にクローズしました。発表はそれだけで、issueトラッカーの外には出ていません。公開の変更履歴は2024年11月から更新されておらず、料金ページにも注記はありません。そのため、Dittofeedを運用している人の多くは知りませんし、この検索語で上位に出るディレクトリサイトは、沈黙しているどころかもっと悪い状況です。中には、Webサイトがもう表示されず、自らのREADMEでも開発とサポートの終了を記しているLaudspeakerを、今も推奨しているところがあります。このページは、その立場にいたら私たちが読みたいと思う内容です。実際に何が変わったのか、なぜ見た目ほど急ぐ必要がないのか、移行の際にデータがどうなるのか、そしてチームが行き着く4つの移行先です。

選定方法

Dittofeedと同じ形を取り戻すために何を手放す必要があるかで、移行先を分類しました。基準は、セルフホスト、送信プロバイダーの持ち込み、イベントトリガーのジャーニー、動的セグメントの4つです。4つすべてを満たすのは2つで、成熟したMauticと、セルフホストのfromHelloです。ここに挙げた情報はすべて、2026年10月9日に各ベンダーのドキュメント、料金ページ、リポジトリで確認しました。Dittofeedについての情報は、ディレクトリサイトではなく、Dittofeed自身のissueトラッカー、ドキュメント、料金ページによるものです。いくつかのサイトでは価格が実際のブラウザーでしか表示されず、単純な取得では何も表示されないため、レンダリングされた状態で確認しました。私たちはfromHelloを開発しています。そのため、fromHelloは最後に掲載し、及ばない点も含めて同じ基準で評価しています。

  1. 向いている用途

    PHPのスタックとcronのタイミングを受け入れてでも、Dittofeedで得ていたもの(セルフホスト、自前の送信プロバイダー、ビジュアルのジャーニー、セグメント)をすべて残したいチーム。

    強み

    • 4つの特性をすべて同時に満たす、成熟した移行先です。自社でホストし、自前のプロバイダーを指定でき、条件と判断を備えたドラッグアンドドロップのキャンペーンビルダーと動的セグメントを使えます。
    • 活発に開発されており、それこそが移行の目的です。バージョン7.2は2026年9月2日にリリースされ、リリースは着実に続き、コミットは毎週入っています。
    • GPLv3で、コア機能に有料版はなく、コミュニティによって運営され、大規模なプラグインのエコシステムがあります。そもそもオープンソースを選んだ理由であるライセンスの問題も、同じ形で解決します。

    注意点

    • キャンペーンはcronに依存します。Mauticのドキュメントでは、セグメント、キャンペーンへの参加、mautic:campaigns:triggerにcronジョブが必要とされています。そのため、セグメントに基づくエントリー、待機、行動しなかったコンタクト向けの経路は次の実行まで待つことになり、即時に実行されるのは、開封やフォーム送信といったコンタクト自身の行動の直後のアクションだけです。Dittofeedのジャーニーがすべてのイベントにリアルタイムで反応していたなら、これは大きな変化です。
    • 送信プロバイダーの持ち込みは確かにできますが、ばらつきがあります。Mauticによると、サードパーティのSymfonyトランスポートはバッチ送信に対応せず、バウンスのコールバックも処理しません。そのため、プロバイダーの選択がこれまで以上に重要になります。
    • 運用するスタックは重くなります(PHP、MySQL、cron、アップグレード)。今のツールが機能追加を止めたと知ったその日に、多くの人が望むものとは正反対です。
  2. Customer.io

    プロプライエタリ(SaaS)

    向いている用途

    メッセージングプラットフォームの運用自体をやめると決め、これまで構築したものに最も近いマネージドの選択肢を求めるチーム。

    強み

    • 機能面で最も近い移行先です。ビジュアルワークフロービルダーとセグメントは上位プランに限定されず入門プランに含まれているため、Dittofeedで設計したジャーニーの移し先があります。
    • カテゴリーの多くが価格を公開しなくなった中で、今も価格を公開しています。Essentialsは5,000件のプロファイルと1,000,000通のメールで月額$100からで、超過料金も問い合わせではなく公開されています。
    • スタートアッププログラムでは、調達額が1,000万ドル未満で、これまで顧客になったことがなければ、30,000件までのプロファイルについて最大12か月無料になります。移行の最初の1年を費用ゼロにできる可能性があります。

    注意点

    • セルフホストは手放すことになります。Customer.ioはデータを自社のクラウド(USまたはEU)に保管するため、セルフホストのツールを選んだデータ所有の理由は、移行後には残りません。ただし、カスタムSMTPで自前のプロバイダーからメールを送ることはできます。
    • 料金はプロファイル単位なので、メッセージを送るかどうかにかかわらず、リストとともに請求額が増えます。すでに費用を払っているサーバーとは異なる形です。
  3. Loops

    プロプライエタリ(SaaS)

    向いている用途

    イベントトリガーのジャーニーを素早く安く取り戻したい、もともとDittofeedをメールだけで使っていた小規模なSaaSチーム。

    強み

    • 多くの人がないと思い込んでいる部分を備えています。ワークフローはイベント、コンタクトのプロパティの変更、新規コンタクトをきっかけに動き、分岐もあり、保存済みのセグメントも使えます。
    • 本格的なジャーニーとしては、このリストで最も安価です。1,000件のコンタクトまで無料、その後は5,000件で月額$49で、有料プランでは送信が別途課金されません。
    • すっきりしたモダンな開発者体験と素早いセットアップで、これから離れる運用の重さとは正反対です。

    注意点

    • セルフホストも、自前のプロバイダーの持ち込みもできません。送信者はLoopsなので、所有という点では出発点から最も遠い選択です。
    • 料金は表ではなくページ上のスライダーでしか公開されていないため、数千件を超えるコンタクトの予算を立てるには、自分でスライダーを動かす必要があります。
    • SaaSのライフサイクルメール向けにつくられています。DittofeedでSMSやWebhookのチャネルに頼っていたなら、それは移行先にはありません。
  4. 向いている用途

    調べてみると、Dittofeedをマーケティングオートメーションではなく通知の配管として使っていたと分かったチーム。

    強み

    • 無料で始められ、プロバイダーを本当に自由に持ち込めます。月10,000回のワークフロー実行まで費用はかからず、配信は自前のメール、SMS、プッシュ通知のプロバイダー経由です。
    • MITライセンスのコアでセルフホストでき、非常に活発に開発されていて、コミュニティも大きいです。まさに、確認すべきだと学んだばかりの健全性のシグナルです。
    • 待機、ダイジェスト、スロットルのステップを含むマルチステップのワークフローに加え、Dittofeedが一度も提供しなかった、埋め込み可能なアプリ内受信トレイがあります。

    注意点

    • これは通知インフラであり、マーケティングオートメーションではありません。対象指定は購読者とトピックの単位なので、Dittofeedでつくった行動ベースのセグメントに直接相当するものはありません。
    • Novu自身のドキュメントが、基本のセルフホスト用composeファイルは本番向けの構成ではないと警告しています(データベースは同じマシン上に置かれ、ストレージは模擬的なものです)。本格的なインフラ作業を見込んでおいてください。
  5. fromHello

    AGPL-3.0Cloudはアーリーアクセス中

    向いている用途

    オープンソースとセルフホストを続けながら、アプリ内メッセージと広告オーディエンスを標準で備え、活発に開発されているプラットフォームに移りたいDittofeedのチーム。fromHello Cloudはアーリーアクセス中です。

    強み

    • 人の行動をきっかけに動くジャーニーを、ファーストパーティトラッキング、イベントごとに再計算されるセグメント、14種類のノードを備えたビジュアルビルダーで組み立てられます。チャネルはメール、SMS、アプリ内のバナーとモーダル、広告オーディエンスで、Webプッシュもプラットフォームに組み込まれています。返信はコンタクトのプロファイルに届き、ジャーニーを開始できます。
    • 手持ちのAIをMCPで接続できます。59種類のツールにより、Claude、Cursor、その他のMCPクライアントからセグメント、ジャーニー、テンプレートを作成し、分析データを読み取れます。メッセージを送信するツールはなく、お使いのAIが作成したジャーニーは、公開されるまで下書きのままです。
    • AGPL-3.0のオープンソースです。自社のPostgresとRedisで無料でセルフホストするか、月額€39から(税別)でユーザー数無制限のfromHello Cloudを利用できます。

    注意点

    • fromHello Cloudはウェイトリスト経由のアーリーアクセスです。Mautic、Customer.io、Loops、Novuは一般提供中です。
    • ニュースレターや単発の一斉配信はありません(多くの人へのメッセージはジャーニーで送ります)。モバイルプッシュとWhatsAppにも対応していません。SMSは常に自社のプロバイダー経由で送信します。

オープンソースのマーケティングオートメーション、fromHelloを見る。

FAQ

よくある質問

  • Dittofeedは終わったのですか?

    いいえ。そしてこの違いは重要です。2026年8月、メンテナーはプロジェクトがメンテナンスモードに入ったと表明しました。機能開発は停止し、バグ修正は機会があれば行うというものです。7月に動いていた環境は今も動き、コードはMITライセンスで公開されています。止まったのはロードマップです。正直に言えば、慌てる理由ではなく、選ぶための時間があるということです。期待値は約束ではなくリポジトリから判断してください。デフォルトブランチは2026年3月下旬から10月まで動きがなく、10月にメンテナーが3つの小さなメンテナンス修正をマージし、新しいプレリリースを出しました。最新の安定版リリースは、今も2025年12月のv0.23.0です。

  • 状態が変わったことに、どうすれば気づけますか?

    簡単には気づけません。それが実際の問題です。この表明は、ユーザーの質問という体裁で2分以内に開かれてクローズされたissueの、1つのコメントにあるだけです。公開の変更履歴も2024年11月から更新されていません。Dittofeedを運用しているなら、正直なシグナルはリポジトリです。マーケティングページではなく、コミットの動き、リリース、未解決のissueの進み具合を見てください。

  • Dittofeedからデータを取り出せますか?

    はい。しかも、多くのセルフホストツールより完全に取り出せます。管理APIは、ビルダーのノードとエッジを含むジャーニーの完全な定義、セグメントの定義、ユーザープロパティの定義、プロパティとセグメントへの所属を含むページ分割されたユーザー一覧、traitsとcontextを含む生のイベント履歴、配信記録、購読グループの状態を返します。CSVエクスポートもありますが、対象はセグメントの割り当てだけなので、本当の手段はAPIです。

  • プロダクトの計測を実装し直す必要はありますか?

    おそらく必要ありません。Dittofeedのデータ取り込みAPIはSegment互換と明記されており、identify、track、page、screenのエンドポイントがSegmentと同じ形です。SegmentからWebhookソース経由で送っていたなら、移行は送信先の変更だけで、SDKの作業はまったく不要です。Dittofeed独自のSDKを使っていた場合も、メソッドはSegment形式のクライアントに1対1で対応するため、書き直しではなく差し替えで済みます。

  • 移行で引き継げないものは何ですか?

    ジャーニーの構造は、どこに移っても手作業でつくり直す必要があります。ノードの語彙が共通するビルダーは2つとないからです。APIで得られるのは読むための定義であり、ほかのツールがインポートできるものではありません。Dittofeed自身のチャネルのドキュメントには、メール、SMS、Webhookだけが記載され、モバイルプッシュとアプリ内メッセージは今後のものとされています。そのため、コードにモバイルプッシュの何かがあったとしても、引き継げる設定はありません。Dittofeedの管理APIに対して構築したものはすべて動かなくなり、セルフホストしていた場合、スタックのClickHouseとTemporalの部分は移行されず、なくなります。

  • すでに運用しています。実際に何をすべきですか?

    ほとんどのチームは、今四半期は何もしなくて構いません。7月に動いていた環境は今も動き、ライセンスはMITなので自分で修正やフォークができ、コードは公開されていて、消えるのではなく安定しています。変わるのは、自分たちが最後の頼みのメンテナーになることです。コメント以降に報告されたバグは未解決のままで、8月中旬以降に寄せられたコミュニティの修正もマージされていません(マージされたのはメンテナー自身のメンテナンス修正だけです)。修理は自分たちで行うものと考えてください。妥当な計画は、すべてが動いている今のうちに定義をエクスポートし、環境はそのまま残し、ほかの誰かではなく自分たちのスケジュールで移ることです。

あわせて読みたい

すべての比較

アーリーアクセス

fromHello Cloud

小さくまとまるために始めたわけではない。

fromHello Cloudのアーリーアクセスは、段階的にご案内します。 オンボーディングは伴走型です。セットアップからコンタクトの移行まで、私たちがお手伝いします。

ご利用の準備が整い次第、メールでお知らせします。スパムは送りません。

まだ登録する段階ではありませんか?GitHubで見る