LASSIC Media らしくメディア
Rocket.Chatで社内チャットをセルフホスト外注
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Rocket.Chatは、自社サーバーで稼働させられるMITライセンスのOSSチームチャットで、Slack・Teamsのようなクラウド型ツールに代わる社内コミュニケーション基盤として構築できます。
- 無料のCommunity版は上限100同時接続ユーザーという規模の目安があり、監査ログの書き出しなど高度な機能はEnterprise版（有償）で提供されます。
- Docker ComposeでのMongoDB構成やレプリカセット運用には専門知識が必要になるため、内製と外注のどちらで進めるかを費用構造とリスクの両面から判断する必要があります。
目次
Rocket.Chatとは？OSSでセルフホスト可能なチームチャット
Rocket.Chatとは、自社で用意したサーバー上に構築できる、オープンソースのチームチャットプラットフォームです。公式GitHubリポジトリでは2026年7月時点で45,000件を超えるスターを獲得しており、”open-source, secure, fully customizable communications platform”を掲げて開発が続けられています*1。リアルタイムのメッセージング機能に加え、音声通話やフェデレーション機能への対応もリポジトリ上で説明されています*1。
ライセンスの中核部分はMIT（Expat）ライセンスで提供されており、商用利用・複製・修正・配布が認められています*2。ただしEnterprise Edition向けのディレクトリは別ライセンスの対象であり、著作権はRocket.Chat Technologies Corpに帰属します*2。この構造を理解しておかないと、リポジトリ全体を無条件にMITとして扱ってしまい、後から利用条件の見直しを迫られる恐れがあります。
データは外部のSaaSではなく、自社で管理するサーバーに置かれる設計です。クラウド型のチャットサービスを利用する場合と比べ、保存先のインフラを自社で選べる点は、データ主権やコンプライアンス要件を検討する企業にとって比較材料になるでしょう。一方で、構築・運用を自社で担うか外部委託するかという別の判断が新たに生じます。
Slack・Teamsとの違いとセルフホストを選ぶ理由
SlackやMicrosoft Teamsは、提供事業者が運用するクラウド基盤上でサービスが稼働する形態が一般的です。これに対しRocket.Chatは、Docker・Podman・Kubernetesなどを使って自社インフラ上にセルフホストする運用が公式に案内されています*3。データの保存場所やアクセス権限の管理範囲を自社の裁量で設計できる点が、クラウド型サービスとの構造的な違いです。
公式ドキュメントでは、Snapsやパブリッククラウドのマーケットプレイス経由での導入、Ubuntu・Debian・CentOS・Windowsへの直接インストールについては、サポート対象外である旨が明記されています*3。”Rocket.Chat provides no support for these additional deployment methods”という記述のとおり*3、安定運用を目指すのであれば、公式が推奨するDocker系またはKubernetes系の構成に沿って構築する判断が現実的です。
また、各バージョンのサポート期間はリリース後6か月間とされています*3。サポート対象外のバージョンを使い続けると、クラウドサービスや公式アプリとの接続に制限がかかる場合があるため、バージョンアップ計画をあらかじめ運用ルールに組み込んでおく必要があるでしょう。
Community版とEnterprise版のライセンス・機能差
無料のCommunity版でできること
Rocket.Chatの公式プランページによると、Community版はMITライセンスに基づく無料版で、セルフホストのみに対応しています*6。同時接続ユーザーの上限は100までとされており、機能面ではチャンネル・ダイレクトメッセージといった基本的なメッセージング、JitsiおよびBigBlueButtonによる音声・映像通話に対応します*6。プッシュ通知は月間10,000件までという制限も設けられています*6。サポートはコミュニティフォーラムのみで、有償サポートは含まれません*6。
小規模なチームでの試験導入や、まず機能を確認したい場合には十分な選択肢となり得ますが、利用者数が増える見込みがある企業は、後述する有償プランへの移行時期をあらかじめ検討しておく方が無難でしょう。
有償プラン（Commercial・Government・Defense）との違い
公式サイトの料金ページでは、Commercial・Government・Defenseという3つの有償プランが案内されています*5。Commercialプランはオンプレミス・プライベートクラウド・専用ホスティングに対応し、エンドツーエンドの暗号化やロールベースのアクセス制御を備えるとされています*5。Governmentプランはデータが海外の法域に置かれないセルフホストまたは自国クラウドでの展開を想定し、Matrixプロトコルによるフェデレーション機能も案内されています*5。Defenseプランはエアギャップ環境やSCIF対応環境での展開を想定した内容です*5。
公式プランページでは、改ざん検知機能付きの監査ログやメッセージのエクスポート、標準サポートに加えたミッションクリティカルサポートといった機能も有償プランの特徴として挙げられています*6。監査ログの保全やコンプライアンス対応が求められる業種では、Community版の範囲を超えてこれらの機能が必要になる場面も想定されます。価格については両ページともお問い合わせベースとされており、公開情報としての具体的な金額は示されていません*5*6。
Docker Composeで構築する標準的な導入手順
リポジトリ取得から起動までの流れ
公式ドキュメントは、Docker Composeを使ったデプロイの流れを次のように案内しています*4。まずシステム要件の確認、ドメインの取得、ファイアウォール設定といった前提条件を整えます。次にDocker・Docker Compose v2・Gitをインストールし、公式のrocketchat-composeリポジトリを取得します*4。
取得したリポジトリの.env.exampleファイルを元に.envファイルを作成し、DOMAIN（公開ドメイン）やROOT_URL（ユーザーがアクセスするURL）、RELEASE（Rocket.Chatのバージョン）といった項目を設定します*4。設定後、compose.yml・compose.database.ymlなど用途別のymlファイルを指定してdocker composeコマンドを実行すると、コンテナ群が起動します*4。既定ではブラウザから「http://localhost:3000」でアクセスできる構成です*4。
構成に含まれる主なコンテナと役割
標準構成にはRocket.Chat本体のコンテナに加え、データベースを担うmongodb、内部のメッセージブローカーであるnats、メトリクス収集のprometheus、ログ集約のloki、ダッシュボード表示のgrafana、リバースプロキシのtraefikまたはnginxが含まれます*4。これらはcompose.database.yml・compose.nats.yml・compose.monitoring.yml・compose.traefik.ymlといったファイルに分割して定義される構成です*4。
ポート番号は、Rocket.Chatが3000、MongoDBが27017、Grafanaが5050、Traefik・Nginxが80および443という割り当てになっています*4。監視やログ集約まで含めた構成であるため、最小構成での検証段階から、どのコンポーネントを実運用でも維持するかをあらかじめ整理しておくと、後の運用設計がスムーズになるでしょう。
システム要件とMongoDBレプリカセットの考え方
公式のシステム要件ガイドでは、Rocket.Chat 8.5系の動作にMongoDB 8.0・Node.js 22.22.3・Deno 2.3.1が必要とされています*5。ハードウェア要件は同時接続ユーザー数に応じて段階的に示されており、同時接続500人以下の規模ではRocket.Chat側にvCPU2・メモリ4GB・ストレージ20GB、MongoDB側にvCPU2・メモリ4GB・ストレージ10GBが目安として挙げられています*5。同時接続500人以上、5,000人を超える規模ではそれぞれ段階的にリソースを引き上げる必要があり、5,000人超ではRocket.Chat側でvCPU16・メモリ12GB・ストレージ40GB、MongoDB側ではレプリカあたりvCPU4・メモリ16GB・ストレージ80GBという目安が示されています*5。
MongoDBについては、3メンバーによるレプリカセット構成が強く推奨されている点も見落とせないポイントです*5。単一のMongoDBインスタンドで運用すると、障害発生時にサービス全体が停止するリスクが高まるため、規模にかかわらずレプリカセットを前提とした設計が望ましいでしょう。ネットワーク面では、HTTPS用の443番ポートと、HTTPからのリダイレクト用に80番ポートの開放が案内されています*5。ファイルストレージについては、Amazon S3・GCS・MinIOの利用が推奨事項として挙げられています*5。
バックアップとアップグレードの運用
公式ドキュメントに示されたDocker構成では、MongoDBは別サービスとして管理され、Rocket.Chatコンテナを更新してもデータは保持される設計です*4。バックアップは、MongoDBコンテナに対して「mongodump –archive」を実行してアーカイブを作成し、復元時には「mongorestore –archive」を使う方法が案内されています*4。
アップグレードにあたっては、事前にバックアップを取得したうえで、.env内のRELEASE変数を更新し、docker composeコマンドで新しいイメージを適用する流れになります*4。各バージョンのサポート期間がリリース後6か月に区切られていることを踏まえると*3、バックアップ取得とバージョン確認を定期運用のタスクとしてあらかじめ組み込んでおく判断が求められます。
セルフホスト内製と外注委託のコスト構造比較
セルフホストによる内製構築と、外部パートナーへの委託では、費用構造・必要スキル・リスク対応の重心が異なります。以下の表に主な違いを整理しました。
| 比較項目 | セルフホスト内製 | 外注委託 |
|---|---|---|
| ライセンス費用 | Community版はMITライセンスの無料ソフトウェアのため発生しません*6 | ソフトウェア自体は無料ですが、構築・保守を委託する分の費用が発生します |
| 必要な専門知識 | Docker/Kubernetes運用・MongoDBレプリカセット設計・監視スタックの構築が必要です*4*5 | 専門パートナーが構築・調整を担うため、社内での知識習得は最小限で済みます |
| バックアップ・データ保全 | mongodump/mongorestoreによるバックアップ運用を自社で設計・実行します*4 | バックアップ設計から監視までを含めて委託できます |
| アップグレード対応 | 6か月というサポート期間を踏まえたバージョン管理を自社で行います*3 | 動作検証を含めて委託先が対応します |
| 高度な機能の利用 | 監査ログ等が必要な場合、Enterprise版のライセンス取得可否を自社で判断します*6 | 要件整理からライセンス選定まで含めて相談できます |
内製構築に必要なスキルと外注との違い
Docker運用・MongoDB設計・監視構築に求められる専門知識
Rocket.Chatを内製で構築・運用する場合、求められる専門知識は複数の分野にまたがります。Docker Compose・Podman・Kubernetesいずれかを使ったコンテナ運用、MongoDBのレプリカセット設計と保守、prometheus・loki・grafanaを含む監視スタックの構築、そしてmongodump/mongorestoreによるバックアップ運用がその内容です。自社の情報システム部門だけでこれらを完結させるには、複数の担当者が連携する体制を整える必要があるでしょう。
判断を先送りにしたまま自己流で構築を進めると、MongoDBを単一インスタンスのまま運用してしまい、障害発生時に復旧できないといった問題に後から気づくケースが生じます。特にサポート対象バージョンの管理を怠ると、いざクラウドサービスとの連携が必要になった場面で接続できないという事態にもつながりかねません*3。
専門パートナーに委託した場合の違い
専門パートナーに依頼すると、Docker/Kubernetes環境の構築からMongoDBレプリカセットの設計、監視スタックの構築、バージョンアップ時の互換性確認まで一連の工程を任せられます。自社では構成検討や動作検証だけで時間がかかる場面でも、複数のチャット基盤を扱ってきた知見を活用すれば、稼働までの期間を圧縮しやすくなります。内製と外注のどちらを選ぶ場合でも、まずは想定する同時接続ユーザー数とライセンス要件の整理が出発点と言えるでしょう。
まとめ：Rocket.Chatセルフホスト活用の3つの判断軸
本稿ではRocket.Chatの特徴とセルフホスト構築の要点を、公式ドキュメントとGitHubリポジトリの情報に基づいて整理しました。要点は次の3つに集約されるでしょう。第一に、MITライセンスのCommunity版はセルフホストのみで無料利用でき、上限100同時接続ユーザーという規模の目安があります*6。第二に、Docker Compose構成のMongoDBレプリカセット設計や監視スタックの構築には専門知識が求められ、バージョンごとのサポート期間管理にも注意が必要です*3*5。第三に、監査ログなど高度な機能が必要な場合はEnterprise版のライセンス要件を確認する必要があり、構築・運用の判断と実行は外部委託によって負担を抑えやすくなります*6。
よくある質問
Rocket.Chatは無料で商用利用できますか。
Community版はMIT（Expat）ライセンスで提供されており、商用利用・複製・修正・配布が認められています*2。ただしEnterprise Edition向けのディレクトリは別ライセンスの対象となるため、利用範囲を事前に確認することが大切です*2。
Community版とEnterprise版はどこが違いますか。
Community版は無料・セルフホスト限定で、上限100同時接続ユーザーという規模の目安があり、基本的なメッセージングとJitsi・BigBlueButtonによる通話に対応します*6。Enterprise系の有償プランでは、改ざん検知機能付きの監査ログやエンドツーエンドの暗号化、標準を超えるサポート体制が案内されています*5*6。
Rocket.Chatの構築にはどのくらいの専門知識が必要ですか。
Docker Composeでのコンテナ管理、MongoDBのレプリカセット設計、prometheus・loki・grafanaを含む監視スタックの構築など複数分野の知識が求められます*4*5。公式がサポート対象とする方法以外（Snapsや特定OSへの直接インストール等）は避ける判断も必要です*3。
バックアップはどのように行いますか。
公式ドキュメントでは、MongoDBコンテナに対して「mongodump –archive」でアーカイブを作成し、「mongorestore –archive」で復元する方法が案内されています*4。MongoDBは3メンバーのレプリカセット構成が強く推奨されている点も運用設計に反映する必要があります*5。
Slack・Teamsからの乗り換えで注意する点はありますか。
Rocket.Chatはセルフホストが前提となるため、SlackやTeamsのようにサービス提供事業者側がインフラを管理する形態とは運用体制が異なります*3。移行にあたっては、想定する同時接続ユーザー数に見合ったハードウェア要件を満たせるかどうかを事前に確認しておく必要があります*5。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Rocket.Chat公式GitHubリポジトリ「README」（https://github.com/RocketChat/Rocket.Chat）
- *2 出典：Rocket.Chat公式GitHubリポジトリ「LICENSE」（https://github.com/RocketChat/Rocket.Chat/blob/develop/LICENSE）
- *3 出典：Rocket.Chat公式ドキュメント「Deploy Rocket.Chat」（https://docs.rocket.chat/docs/deploy-rocketchat）
- *4 出典：Rocket.Chat公式ドキュメント「Deploy with Docker & Docker Compose」（https://docs.rocket.chat/docs/deploy-with-docker-docker-compose）
- *5 出典：Rocket.Chat公式ドキュメント「System Requirements」（https://docs.rocket.chat/docs/system-requirements）
- *6 出典：Rocket.Chat公式ドキュメント「Our Plans」（https://docs.rocket.chat/docs/our-plans）
