大規模なオープンソースのチームコミュニケーション：Mattermost を自前で運用する

hands typing a message on a phone in a dark room

数年に一度、どこかの会社が Slack の請求書を眺め、ユーザーあたりの費用を足し合わせ、十年分の社内会話が別の司法管轄にある他人のデータベースに置かれていることに気づき、ほかの道はないのかと問い直します。あります。Mattermost は自前で運用する答えとして最も現実味のある選択肢で、しかもかなり以前からそうです。

同時に、導入前に最も誤解されやすいツールでもあります。手に入ると思っている無料版は、たいてい最終的に動かすことになる版とは別物だからです。この記事では、Mattermost が実際のところ何であるか、無料版に本当は何が含まれるのか、そして初めて自前で運用するほぼ全員がぶつかる三つの運用上の問題を扱います。

Mattermost とは何か

Go で書かれたサーバー、PostgreSQL のデータベース、React のウェブクライアント、そしてネイティブのデスクトップアプリとモバイルアプリ。チャンネル、スレッド、ファイル共有、検索、スラッシュコマンド、受信と送信の Webhook、ボット、そしてプラグイン基盤。Slack を使ったことがあれば午後一回で戦力になりますし、それは他の全員についても同じで、会社全体に引っ越しを頼むときにはどんな機能一覧よりもこの点が効きます。

その中核の周りに、チェックリスト駆動でインシデントやプロセスを回す Playbooks と、音声・映像・画面共有のための Calls があります。連携カタログはおなじみの顔ぶれを押さえています。GitLab、GitHub、Jira、Jenkins、PagerDuty。この製品が本当に強いのは ChatOps の領域で、エンジニアリングや運用のチームに支持者が多い理由もそこにあります。トラフィックを商用 SaaS にそもそも預けられない防衛・公共部門の組織にも同じことが言えます。

アーキテクチャ上の要点は、これらすべてが自分で選んだインフラの上で動くということです。Matomo で分析を自前運用することや、Mautic でマーケティングオートメーションを自前運用することと同じ原則です。メッセージは自分のデータベースにあり、ファイルは自分のオブジェクトストレージにあり、保持ポリシーや価格を誰かが断りなく変えることはありません。

ライセンスの実情、率直に言うと

ここで混乱が起きるので、はっきり書いておきます。

Team Edition がオープンソース版です。MIT ライセンス、無料、ユーザー数の上限なし。自前運用している人の多くが実際に動かしているのはこれです。メッセージ、チャンネル、スレッド、検索、連携、Webhook、プラグイン基盤が手に入ります。SAML や AD/LDAP のシングルサインオン、コンプライアンス用エクスポート、エンタープライズ検索、高可用クラスタ、ゲストアカウントは手に入りません。

Entry は無料の商用版です。高度な機能一式を解放しますが上限があります。メッセージ履歴に制限があり、Playbook の実行回数に制限があり、サポートはコミュニティのみで、想定はおおむね五十人未満のチームです。有償製品を評価する手段としては良いものです。会社の会話履歴を長く置く場所としては悪い選択で、履歴の上限はまさに、いずれ気にかけることになるものにかかるからです。

Professional、Enterprise、Enterprise Advanced が有償の階層です。Professional は SSO、MFA、詳細な権限管理を加えます。Enterprise は AD/LDAP 同期、コンプライアンスの自動化、エンタープライズ検索、高可用性、そして大規模な Playbooks を加えます。Enterprise Advanced は機密情報の取り扱い、ゼロトラスト制御、エアギャップ環境での配備を加え、防衛や行政の利用者がいるのはこの階層です。Mattermost はユーザー単価を公開しなくなったので、営業との会話は見込んでおいてください。

多くのチームが直面する判断は、階層の一覧が示唆するより単純です。自社の ID プロバイダーに対する SAML が必要なら支払うことになります。ローカルアカウントか GitLab の OAuth で足りるなら、Team Edition は驚くほど大きな組織を支えます。

構築の仕方

小規模な構成

数十人から数百人のチームなら、まともにサイズを決めた VPS 一台で本当に足ります。Mattermost 自身の指針は一人から千人までを 1 vCPU と 2GB のメモリに置いていますが、これはベンダーの最小要件がいつもそうであるように楽観的です。4 コアと 8GB を与えておけば、二度と気に留めずに済みます。

構成は Mattermost、PostgreSQL、そして TLS を終端するリバースプロキシです。Traefik と Let's Encrypt の組み合わせが最も手間がかかりません。

services:
  mattermost:
    image: mattermost/mattermost-team-edition:latest
    restart: unless-stopped
    environment:
      - MM_SQLSETTINGS_DRIVERNAME=postgres
      - MM_SQLSETTINGS_DATASOURCE=postgres://mmuser:your_secure_password@db:5432/mattermost?sslmode=disable
      - MM_SERVICESETTINGS_SITEURL=https://chat.example.com
    volumes:
      - mm_data:/mattermost/data
      - mm_config:/mattermost/config
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_USER=mmuser
      - POSTGRES_PASSWORD=your_secure_password
      - POSTGRES_DB=mattermost
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  mm_data:
  mm_config:
  db_data:

誰かを招待する前に SiteURL を正しく設定してください。SiteURL が誤っていたり欠けていたりすると、プッシュ通知、OAuth のコールバック、リンクのプレビューが壊れます。後から調べるのは面倒で、今なら避けるのは造作もありません。

ベンダー自身も言っていることなので繰り返しますが、コンテナは評価や小規模な本番導入には十分でも、その経路ではクラスタリングも高可用性も標準では手に入りません。それらが必要なら Linux に直接入れるか、Kubernetes オペレーターを使ってください。

本番構成

PostgreSQL 14 以降。MySQL のサポートは v11 から非推奨に入るので、今から立ち上げるなら MySQL で始めないでください。Amazon Aurora PostgreSQL はサポートされていて、AWS 上では妥当なマネージド選択肢です。

ファイルは初日から S3 互換のオブジェクトストレージに置いてください。ローカルファイルシステムでも動きますし既定値でもありますが、それこそがサーバーを静かに状態持ちにし、バックアップを巨大にし、移行を痛みに変えるものです。後から切り替えるのはファイルの移動とパスの書き換えを意味します。導入時に切り替えるのは設定値をいくつか入れることを意味します。

高可用性には Enterprise 階層が必要です。ロードバランサーの後ろに複数のアプリノード、共有のオブジェクトストア、読み取りレプリカ付きのデータベース。大規模な検索には Elasticsearch か OpenSearch が要り、これも Enterprise です。PostgreSQL の全文検索は数百人と数百万件のメッセージには十分で、CJK 検索は今では PostgreSQL で既定で動きます。かつてはこれが検索アドオンを買う実質的な理由でした。

うまくいかない三つのこと

ここまではすべてドキュメントに書かれています。ここから先は本番で気づく部分です。

プッシュ通知は期待するような意味では無料ではない

モバイルのプッシュは Apple と Google のネットワークを通る必要があり、つまり署名証明書をどこかが保持しなければなりません。Mattermost は Test Push Notification Service を運用していて、すぐ動きますが、本番用ではないと明示されています。本番用は Hosted Push Notification Service で、これは有償ライセンスに付いてきます。

三つ目の選択肢は自前のプッシュプロキシを動かすことです。文書は充実していて完全に実行可能ですが、自社の Firebase と APNs の資格情報で自社のモバイルアプリを作って配布することを意味します。それはアプリストアとの関係とリリース工程であって、午後一回の作業ではありません。

三つのどれで行くかは、携帯端末に展開する前に決めてください。最初の一人が「アプリを開いているときしかメッセージが来ない」と尋ねてきた後ではなく。この一点だけで、他のどんな理由よりも多くの Mattermost 移行が頓挫しています。

Calls にはポート以上のものが要る

Calls には二つのモードがあります。統合モードはメディアサービスを Mattermost サーバーの内部で動かし、アクティブユーザーがおよそ五十人未満のときに推奨されます。それを超えるなら rtcd が欲しくなります。通話メディアを本体サーバーから切り離し、水平にスケールする独立サービスです。rtcd には Enterprise が必要です。

いずれの場合も、クライアントは UDP のポート 8443 でメディアサービスに到達する必要があり、そのポートはメディアサービスが動いているホストで開いていなければなりません。nginx のリバースプロキシは転送してくれません。nginx はそもそも UDP の経路上にいないからです。「通話がつながらない」という趣旨のスレッドの半分は、結局のところ追加されなかったファイアウォール規則に行き着きます。

無料階層では、無制限のグループ通話ではなく時間制限のある一対一通話を想定してください。全社的なビデオ通話が要件なら、費用に織り込んでおくことです。

誰かが運用しなければならない

正直な費用比較は、ライセンス対ゼロではありません。ライセンス対、インフラとパッチを当てる人です。Mattermost のリリースは頻繁で、セキュリティ上の理由から最新に追随したくなりますし、アップグレードには本番以外のどこかで試しておくべきデータベース移行が伴います。

もともと自前のインフラを運用しているチームにとって、これは限界的な作業で、計算は圧倒的に有利です。運用の余力がない十人の会社にとっては、SaaS の請求書のほうが失われる火曜の午後より本当に安いこともあります。自分がどちらなのかについては正直でいてください。

Slack からの移行

Mattermost には Slack のエクスポートファイルからの取り込み経路があり、それは機能します。ただし前もって知っておくべき但し書きがあります。公開チャンネルのメッセージとユーザーはよく移ります。プライベートチャンネルとダイレクトメッセージは、そもそも自社の Slack プランが何をエクスポートさせてくれるか次第です。スレッド、添付ファイル、カスタム絵文字、連携は手当てが必要で、いくつかは作り直しになります。

うまくいくやり方は、履歴は検索できるアーカイブとして取り込み、切り替え日をきれいな出発点として扱うことです。Slack の挙動を一つ残らず再現しようとするのが、二週間の移行を二四半期の移行に変える道筋です。

二週間ほど両方を並行で走らせ、まず一つのチームを移し、停止日は最初に公表しておく。チャットの移行は技術ではなく人の側で失敗します。

ヨーロッパの観点

EU の企業にとって、これは費用だけの話ではありません。自前運用は社内コミュニケーションを自分が管理する境界の内側に置きます。それによって、GDPR の移転分析、NIS2 のサプライチェーン精査、そして公共調達で目にする機会が増え、クラウド・AI 開発法の主題そのものである主権の問いが、いっぺんに姿を変えます。

社内チャットは、会社が抱える機密性の高い素材のなかでも最も密度の高い集まりの一つです。インシデントの詳細、顧客名、貼るべきではなかったのに誰かが貼ってしまった認証情報、進行中のあらゆる商談がそこにあります。そのデータがどこにあるのかと問われたとき、副処理者の一覧ではなくリージョンとラックで答えられることには価値があります。

やめておくべき場合

社員が十五人で、コンプライアンス要件が軽く、誰もサーバーを抱えたくないなら、SaaS を使ってください。節約分は、そこに払う注意に見合いません。

すでに住んでいるエコシステムとの深い統合が必要なら、何を失うことになるかをよく見てください。Microsoft 365 の環境にいるチームは、自分で作り直さなければならないものを無料で受け取っています。

そして推進力が、費用や統制や管轄についての実際の要件ではなく、声の大きな一人のベンダー嫌いであるなら、移行はおよそ六割の利用率で止まります。コミュニケーションツールにとって、これは考えうる最悪の結果です。

お手伝いできること

私たちはヨーロッパで事業を行う企業向けに、自前運用のオープンソース基盤を構築し運用しています。プッシュプロキシ、オブジェクトストレージへの移行、アップグレード経路、そしてチャット導入を根づかせる ID 連携といった、地味な部分も含めてです。

適切にサイズを決めた Mattermost の構築、実際にやったことのある人間が計画する Slack からの移行、あるいは自前運用が自社のチームに見合うかどうかの率直な答えが必要でしたら、office@c9group.dev までご連絡ください。基盤まわりの仕事については AWS コスト最適化のページもご覧ください。

自前運用のスタックを一式そろえるのであれば、同じ考え方が分析にもマーケティングオートメーションにも当てはまります。

公開日：2026年8月8日 カテゴリー：コラボレーション、オープンソース、プライバシー