セルフホスト型Slack代替4製品を比較

小規模チームで運用する価値があるセルフホスト型 Slack 代替サービス

小規模チームで運用する時間に見合うセルフホスト型 Slack 代替サービスは、Mattermost、Rocket.Chat、Matrix with Synapse、Zulip です。1 台のサーバーで社内チーム向けツールを運用するなら、Mattermost を選びます。公開コミュニティ向けなら、Zulip を選びます。他の組織が所有するサーバーと通信する必要がある場合に限り、Matrix with Synapse を運用します。連合機能は他のサービスでは代替できない唯一の機能ですが、管理者の業務内容も変えるためです。

機能一覧だけでは、この 4 つを比較しきれません。どのサービスも、チャンネル、スレッド、検索、ファイルアップロード、モバイルアプリに対応しています。違いは、毎月どのような運用負担が発生するかにあります。必要なメモリ量、稼働を維持する必要があるデータベース、管理できない可能性があるモバイルプッシュ通知の経路、そして必要な機能が有料になるかどうかを決めるライセンスです。以下では、10 ユーザーの場合と 100 ユーザーの場合について、これらの観点から比較します。

4 つの製品の実体

Mattermost は、PostgreSQL データベースを使用する Go 製サーバーです。バイナリ、データベース、設定ファイルがそれぞれ 1 つずつあります。スレッドや slash command も含めて Slack に似た動作をします。4 つの中では運用が最も単純で、その点が長所です。

Rocket.Chat は、MongoDB 上で動作する Node.js アプリケーションです。音声通話やビデオ通話に加え、メールやソーシャルチャネルから顧客との会話を同じインターフェースに集約する omnichannel inbox も備えており、この中で最も機能が豊富です。inbox が選定理由であれば、まず 専用の Chatwoot サポートデスク と比較してください。サポート業務を担う chat server と、チーム業務を担う chat server では役割が異なるためです。

Matrix は製品ではなく、プロトコルです。Synapse がリファレンスサーバーで、Python と PostgreSQL を使用します。Element は多くのユーザーが利用するクライアントです。ここで、運用していないサーバーとも通信できるのは Matrix だけです。

Zulip は、PostgreSQL、RabbitMQ、memcached、Redis を背後で使用する Python 製サーバーです。Django と Tornado で構成され、専用スクリプトによって 1 つの単位としてインストールされます。チャネル内にトピックを設けるモデルのため、火曜日の会話を金曜日にも検索できます。Version 12.0 は 2026 年 4 月にリリースされました。

10 ユーザーと 100 ユーザーで必要な RAM とデータベース

以下の表の数値はすべて、2026 年 8 月に確認した各プロジェクトの公式ドキュメントに基づいています。私が測定した値や、独自に作成した値はありません。すべての行で基準は同じです。各プロジェクトが公開している最小構成を示し、プロジェクトがデータベースを別に見積もっている場合は、その分も含めています。

[
  {
    "label": "Synapse",
    "published_ram_gb": 1,
    "notes": "Synapse install docs: at least 1 GB free RAM if you want to join large public rooms. PostgreSQL is required for production and is not sized."
  },
  {
    "label": "Mattermost",
    "published_ram_gb": 2,
    "notes": "Mattermost requirements: 1 to 1,000 users on 1 vCPU and 2 GB RAM, single server, database included."
  },
  {
    "label": "Zulip",
    "published_ram_gb": 2,
    "notes": "Zulip requirements: under 100 users on 1 CPU, 2 GB RAM and 2 GB swap. 100 users and above needs 2 CPUs and 4 GB."
  },
  {
    "label": "Rocket.Chat",
    "published_ram_gb": 8,
    "notes": "Rocket.Chat requirements: smallest published tier is 4 GiB for the app plus 4 GiB for MongoDB, rated up to 500 concurrent users."
  }
]

各行の前提は同じではありません。これが最初に確認すべき点です。Synapse の 1 GB は、Synapse プロセスに必要な下限です。ただし、大規模な公開ルームに参加する場合は、その容量の 空き RAM が必要だとドキュメントに記載されています。PostgreSQL はこの数値に含まれません。Mattermost の 2 GB は、データベースを含むマシン全体の容量です。1 つの vCPU で 1 ～ 1,000 ユーザーを対象としています。Zulip は、100 ユーザー未満では 2 GB と 1 CPU に加え、2 GB の swap を推奨しています。100 ユーザー以上では、4 GB と 2 CPU が必要です。Rocket.Chat はこの中で最大の数値である 8 GB を公開しています。アプリケーションに 4 GiB、MongoDB に 4 GiB を割り当てる構成で、最大 500 の同時接続ユーザーを対象としているためです。

10 ユーザーであれば、4 個の構成はいずれも、特別に検討する必要がないハードウェアで動作します。100 ユーザーになると差が出ます。Mattermost は引き続き 2 GB の構成に収まり、Zulip は 4 GB と 2 つ目の CPU を必要とします。Rocket.Chat は、MongoDB のメモリ使用量がユーザー数ではなくマシンによって決まるため、最小の公式構成が 8 GB のまま変わりません。

データベースの選択は、日々の性能よりも将来のアップグレードに大きく影響します。Mattermost には PostgreSQL 14 以降が必要です。また、v11 以降は MySQL のサポートが非推奨になっているため、今日 MySQL を導入すると、明日は移行が必要になります。Synapse は SQLite で動作しますが、公式ドキュメントには、大規模なルームで性能が低下するため、SQLite はテスト用途に限って使用できると明記されています。Rocket.Chat 8 には MongoDB 8.0 が必要です。そのため、データベースのアップグレードとチャットシステムのアップグレードを別々ではなく、1 つのプロジェクトとして進めることになります。

2 GB VPS で実際に得られるもの

2 GB プランは多くのプロバイダーで最小構成です。4 つのうち 2 つには、現実的な選択肢になります。

• Mattermost は収まります。 ベンダーが、PostgreSQL を同じサーバーで実行し、最大 1,000 ユーザーまでこのサイズを明確に文書化している唯一の製品です。2 GB で 10 人なら、余裕を持って運用できます。
• Zulip は swap を使えば収まります。 ドキュメントでは 5 GB 未満の環境に swap を推奨しており、RAM が少ないマシンではアップグレード中に out of memory エラーが発生すると警告しています。この場合、tools/webpack が失敗するステップです。これはインストール時ではなく、アップグレード時に実際に遭遇する障害です。
• Synapse は負荷が低い間なら収まります。 アイドル時の消費量は少なめです。問題はスパイクであり、その原因は以下の Federation のセクションで説明します。
• 2 GB では Rocket.Chat を避けるべきです。 原因は MongoDB のストレージエンジンです。WiredTiger は、(RAM から 1 GB を引いた値) の 50% と 256 MB の大きい方を内部キャッシュのサイズにするため、2 GB のマシンでは Node.js が起動する前に約 512 MB を確保します。その結果、明確な拒否エラーが出るわけではありません。インストールでき、動作もしますが、履歴が増えるにつれて遅くなり、最終的には kernel の out of memory killer が、その時点で最大だったプロセスを停止します。

プロバイダーによって RAM の数え方は free と異なるため、判断する前に実際の割り当てを確認してください。

free -h
swapon --show

チャットサーバーだけがそのマシン上で動作するわけではありません。TLS (transport layer security) 終端、バックアップ、コンテナランタイムもメモリを使用します。選択したサーバーは、理解している reverse proxy、Nginx、Caddy、Traefik のいずれかの背後に配置してください。コンテナでデプロイする場合は、VPS 向け Docker Compose の基本を最初に正しく整えることが重要です。

モバイルアプリに独自の push server は必要ですか

これは、デプロイ後に利用者が気付く判断軸であり、最終的な選択を最も左右する要素です。

仕組みは次のとおりです。Apple Push Notification service (APNs) と Firebase Cloud Messaging (FCM) は、そのアプリ固有の署名認証情報を保持する事業者からの通知だけを受け付けます。自分でビルドしていないアプリには、サーバーから push 通知を送信できません。そのため、ベンダーの App Store ビルドを使用する self-hosted chat server は、通知をベンダーの gateway に渡す必要があり、利用条件もベンダーが定めます。

• Mattermost。 無料で利用できる方法は https://push-test.mattermost.com の Test Push Notification Service (TPNS) です。ドキュメントでは、本番環境での利用は推奨されておらず、service level agreement (SLA) もないと説明されています。App Store と Play Store のビルドでのみ動作します。Hosted Push Notification Service (HPNS) は本番運用向けですが、有料 subscription が必要です。もう 1 つの方法は push proxy を自分でコンパイルすることです。この場合は、独自の APNs と FCM の認証情報を使った独自アプリのビルドが必要になります。
• Rocket.Chat。 push 通知を利用するには、workspace を Rocket.Chat Cloud に登録する必要があります。community workspace の上限は、月 10,000 件の push 通知です。workspace 全体で 1 日あたり約 330 件に相当します。quota を使い切ると、月がリセットされるまで通知が届かなくなり、利用者にはアプリが壊れているように見えます。
• Matrix with Element。 Synapse は通知を push gateway に送信します。公式の Element アプリは、https://matrix.org/_matrix/push/v1/notify で matrix.org が運用する gateway を参照します。payload にはメッセージ本文ではなく event と room の識別子が含まれ、アプリが自分のサーバーから内容を取得します。そのため gateway が認識するのは会話ではなく metadata です。独自の Sygnal gateway もサポートされており、その場合は独自アプリをビルドして配布します。Android では中間的な方法として、自分でホストする ntfy server と UnifiedPush を利用できます。
• Zulip。 無料プランには、最大 10 ユーザー向けの mobile push service が含まれます。10 ユーザーを超える場合は plan が必要ですが、無料の Community plan は多くの非営利組織を対象としています。2026 年 4 月の Zulip 12.0 では、push payload の end to end encryption が追加されました。

10 ユーザーであれば、いずれのサービスでも費用をかけずに通知を動作させられます。100 ユーザーになると状況が変わります。Zulip では plan が必要になり、Mattermost は SLA も support もない test service で動作し続けます。Rocket.Chat では月間上限が制約になり、Matrix には gateway を無料で利用できるため影響がありません。

無料でシングルサインオンを利用できる製品

シングルサインオン（SSO）は、オープンコアのビジネスモデルの違いが最も明確に表れる部分です。

• Zulip は、セルフホスト型サーバーで SAML（security assertion markup language）と LDAP（lightweight directory access protocol）を無料で利用できます。別途購入が必要なプランはありません。
• Synapse は、独自の設定ファイルで OpenID Connect（OIDC）、SAML、CAS を無料でサポートします。新しい構成では Matrix Authentication Service の利用が増えています。これは独立したサービスで、従来の Synapse 認証からの一方向移行になります。後から気づいて対応するのではなく、あらかじめ移行を計画してください。
• Rocket.Chat Community Edition は、基本的な LDAP と SAML ログインに対応します。拡張ユーザー属性の同期、グループとチームのマッピング、バックグラウンド同期にはエンタープライズライセンスが必要です。
• Mattermost の無料の Team Edition で利用できるのは GitLab OAuth だけです。SAML、AD/LDAP、OpenID Connect は有料機能です。

複数のサービスを 1 つのログインで運用する予定なら、セルフホスト型の Authentik アイデンティティプロバイダーを前段に配置し、保有しているライセンスで 4 つの製品が実際に Authentik と連携できるか確認してください。

フェデレーションに実際にかかるコスト

フェデレーションは、Matrix が存在する理由です。ユーザーは他者のサーバーでホストされているルームに参加し、そのサーバーにアカウントを持つユーザーと会話します。これは、メールサーバーがメールを交換する仕組みと同じです。ここで挙げる他の選択肢には、この機能はありません。必要であれば、このページの他の選択肢で代替することはできません。

同時に、フェデレーションは Synapse を異なる種類のワークロードにします。ユーザーがフェデレーションされたルームに参加すると、サーバーはそのルームの状態とイベントのコピーを保持します。また、他のサーバーのユーザーが投稿したアバター、画像、ファイルなどのメディアをキャッシュします。その結果、ディスク使用量は、自分で作成していないルームや、自分のサーバーにアカウントを持たないユーザーによって左右されます。このため、Synapse のインストールでは、自分のユーザーが送信したメッセージの総量を大幅に上回るメディアストアが増大します。また、大規模な公開ルームへの参加に対して、ドキュメントがメモリ要件を明記している理由でもあります。

ディスクが満杯になった日ではなく、初日に保持ポリシーを設定してください。

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Synapse 1.61 で media_retention が追加され、ローカルメディアとリモートメディアに別々の保持期間を設定できるようになりました。リモートメディアはキャッシュです。そのため、削除済みのファイルをユーザーが再度要求すると、Synapse は元のサーバーから再取得します。ローカルメディアはキャッシュではありません。そのため、短い local_media_lifetime を設定すると、自分のユーザーがアップロードしたファイルが完全に削除されます。

要点を率直に言えば、ユーザー同士だけが会話する場合、フェデレーションは何ももたらさず、ディスク、帯域幅、そしてより複雑なアップグレード運用の負担だけが増えます。無効にするか、別のサーバーを選択してください。

アップグレードの進め方

Zulip が最も簡単です。 1 本のスクリプトで完了し、大規模なデータベース移行がなければ、文書化されているダウンタイムは 30 秒未満です。インストールとアップグレードは、サーバー上で次のように実行します。

cd $(mktemp -d)
curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
tar -xf zulip-server-latest.tar.gz

インストーラーは root として実行します。--push-notifications フラグを指定すると、インストール中にサーバーがモバイルプッシュサービスへ登録されます。この時点で利用規約への同意を求められるため、開始前に内容を確認してください。

sudo ./zulip-server-*/scripts/setup/install --push-notifications --certbot \
    --email=YOUR_EMAIL --hostname=YOUR_HOSTNAME

以降のアップグレードは、同じ tarball と 1 つのコマンドで実行します。

curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
sudo /home/zulip/deployments/current/scripts/upgrade-zulip zulip-server-latest.tar.gz

Mattermost の手順は予測しやすいです。 バイナリを置き換えて再起動すると、起動時にマイグレーションが実行されます。2025 年 8 月のリリース以降、Extended Support Release（ESR）トラックは 9 か月ごとにリリースされ、サポート期間は 12 か月です。ESR から ESR へのアップグレードが、テスト済みの手順です。複数の ESR を一度に飛ばすこともサポートされていますが、テストはされていません。実際には、自分でテストする必要があります。

Rocket.Chat では 3 つのアップグレードを組み合わせます。 2026 年 8 月時点では 8.x 系列が現行で、8.7.0 は 2026 年 8 月 6 日にリリースされています。このバージョンには MongoDB 8.0 と、対応する Node.js のバージョンが必要です。メジャーバージョンを飛ばすと、アプリケーションが開くことを拒否するデータベースになることがあります。Rocket.Chat Docker Compose インストールガイドでは、これらのバージョンをまとめて固定できます。そのため、ここではコンテナ方式を選ぶ主な理由になります。

Synapse ではリリースノートを読む必要があります。 各リリースにアップグレードに関する注意事項があるため、移行先のバージョンだけでなく、経由する各バージョンの注意事項を読む必要があります。アップグレード後、Synapse はデータベースに対してバックグラウンド更新を実行します。小規模なサーバーでは、この処理によって数時間にわたりマシンの動作が遅くなることがあります。これは障害ではなく、想定された動作です。

ライセンス条件を簡単に説明

Mattermost は、コンパイル済みの Team Edition ビルドを MIT ライセンスで配布しています。一方、ソースコードは AGPLv3 または商用ライセンスで提供されています。リポジトリの一部には Mattermost Source Available License が適用されており、本番環境で実行するには有料ライセンスが必要です。Rocket.Chat は ee/ ディレクトリを除いて MIT ライセンスです。ee/ ディレクトリには、それぞれ独自のエンタープライズライセンスが適用されます。Synapse は version 1.99.0 で Apache 2.0 から AGPLv3 に移行しました。貢献者は CLA に署名します。この CLA により、Element はこのライセンスの例外を販売できます。Zulip は Apache 2.0 で、エンタープライズ用ディレクトリはありません。そのため、SSO の説明に例外注記がありません。

実務上は、サーバーを変更し、それをサービスとして他者に提供する予定がある場合に限り、AGPL が問題になります。小規模チームにとっては、オープンコアの範囲、つまり無料ビルドで利用できない機能がどれかのほうが、はるかに重要です。利用できない機能が最も少ないのは Zulip で、最も多いのは Mattermost です。

どれを選ぶべきか

社内チーム用のツール。 Mattermost が適しています。公式ドキュメントに記載された構成要件が最も小さく、アップグレード時の変更も少なく、説明なしで使える一般的なインターフェースを備えています。SSO が必要になった時点で有料プランを想定してください。ほとんどのチームでは、その時期がいずれ訪れます。

コミュニティ向けのサーバー。 Zulip が適しています。トピックにより、活発な公開チャンネルでも数か月後まで読みやすさを維持できます。SAML と LDAP を追加費用なしで利用でき、アップグレードも 1 コマンドで実行できます。コミュニティの使い方がライブチャットより投稿と返信に近い場合は、まず セルフホスト型フォーラムソフトウェア と比較してください。フォーラムのほうが検索でインデックス化されやすく、プッシュ用のインフラも必要ありません。音声、ビデオ、オムニチャネル機能が必要で、独自ドキュメントが求める 8 GB を割り当てられる場合は、Rocket.Chat を選んでください。

相互接続が必要なネットワーク。 Synapse と Element を使用する Matrix が適しています。メディアデータの増加を受け入れ、初日から保持期間を設定し、PostgreSQL と想定以上のディスク容量を用意してください。自分で管理していないサーバーと通信することで、真価を発揮します。一度もフェデレーションを行わないチームで Synapse を選ぶと、そのコストを無駄に負担することになります。

FAQ

小規模チームに最適なセルフホスト型 Slack 代替製品はどれですか？

ほとんどの社内チームでは Mattermost です。Mattermost のドキュメントでは、PostgreSQL を同じマシンで実行する場合、1 vCPU と 2 GB の RAM で 1〜1,000 ユーザーを扱えると説明されています。そのため、多くのプロバイダーが提供するエントリーレベルの VPS プランに適しています。注意点はシングルサインオンです。無料の Team Edition が対応するのは GitLab OAuth のみで、SAML、AD/LDAP、OpenID Connect にはすべて有料プランが必要です。Slack に似たインターフェースより無料の SSO を優先するなら、代わりに Zulip を運用してください。

2 GB の VPS でセルフホスト型チャットサーバーを実行できますか？

Mattermost は実行できます。Zulip も、swap を追加すれば実行できます。Zulip 自身のドキュメントでは、5 GB 未満の場合に swap の追加を推奨しています。問題になるのは Rocket.Chat です。MongoDB の WiredTiger エンジンは、キャッシュ用に (RAM - 1 GB) の 50% と 256 MB の大きい方を確保するため、2 GB のマシンではアプリケーションの起動前におよそ 512 MB が消費されます。インストール自体はできますが、履歴が増えるにつれて性能が低下し、最終的には out of memory による kill が発生します。Rocket.Chat が公開している最小構成は、アプリケーションに 4 GiB、MongoDB に 4 GiB です。

セルフホスト型チャットサーバーには、独自のモバイルプッシュ通知サーバーが必要ですか？

通常は必要ありません。Apple の APNs と Google の FCM は、アプリに署名した事業者からの通知だけを受け付けるため、ベンダーのアプリはベンダーのゲートウェイを使用します。条件はサービスごとに異なります。Mattermost は、SLA のない無料のテストサービスと、有料のホステッドサービスを提供しています。Rocket.Chat はコミュニティワークスペースを月間 10,000 件のプッシュ通知までに制限しており、上限に達すると月がリセットされるまで配信が停止します。Zulip は最大 10 ユーザーまでプッシュ通知を無料で含み、それを超える場合はプランが必要です。Matrix の homeserver は、Element アプリが使用するゲートウェイを無料で介してプッシュ通知を送信します。独自のアプリビルドも配布する場合に限り、独自のゲートウェイが必要です。

他のサーバーと一切通信しないチームで、Matrix と Synapse をセルフホストすべきですか？

いいえ。Synapse はフェデレーションのためのソフトウェアであり、フェデレーションによって運用も重くなります。他のサーバー上のルームに参加すると、その状態とメディアがローカルディスクに取得され、チーム内のユーザーとは無関係な理由でストレージが増加します。その前に、短い remote_media_lifetime を指定して media_retention を設定してください。自分たちだけで通信するチームでは、運用コストだけが発生し、メリットは得られません。Mattermost または Zulip なら、より少ないハードウェアで同じ用途に対応できます。

無料のシングルサインオンに対応するセルフホスト型 Slack 代替製品はどれですか？

Zulip と Synapse です。Zulip はセルフホスト型サーバーで SAML と LDAP を無料で利用できます。Synapse は設定で OpenID Connect、SAML、CAS に対応しており、新しいインストールでは別の Matrix Authentication Service へ移行が進んでいます。Rocket.Chat の community edition は基本的な LDAP と SAML ログインに対応しますが、属性同期、グループマッピング、バックグラウンド同期は enterprise licence が必要です。Mattermost の無料の Team Edition が対応するのは GitLab OAuth のみです。