この記事ではDevOps・自動化文脈で、社内コラボレーション基盤OSSとしてのMattermostを掘り下げます。AI時代の自動化ツール全体像は AI自動化ツール完全ガイド2026｜ノーコードからコードまで徹底比較 をご覧ください。

この記事のポイント
  • ・MattermostはGitHubで36,600スターを集めるオープンソースのSlack代替。
  • ・チャット・WebRTC通話・ChatOps・AIアシスタントが1つの自社サーバーで完結する。
  • ・GoとReact、PostgreSQL一本の構成でDocker Compose5分起動が可能。
  • ・Mattermost AgentsプラグインでOpenAI・Anthropic・Ollamaを切り替え使い分け。
  • ・DevSecOpsとインシデント対応向けのPlaybooks・Boardsを標準搭載する。

1. Mattermostとは何か：自社サーバーで動くSlack代替の本命

Mattermostは、チャット・ワークフロー自動化・音声/ビデオ通話・画面共有・AI統合を1つにまとめたオープンソースのコラボレーションプラットフォームで、GitHubで36,600スター以上を獲得している。GoとReactで構築され、Linuxの単一バイナリとして動作し、データストアはPostgreSQLのみという潔い構成だ。

公式README冒頭の表現を借りるなら「open core, self-hosted collaboration platform」となる。MITライセンスのコア部分は毎月16日にコンパイル版がリリースされており、コミュニティへの透明性も高い。

開発主体のMattermost社は米国カリフォルニア州を拠点に2016年から運営されており、米国防総省・NASA・ヨーロッパの大手金融機関といったハイセキュリティ業種に採用実績がある。「データの主権を自社で握れるSlack」というポジショニングが受けて、エンタープライズ市場で確固たる地位を築いている。

1.1 Mattermostが解決する課題

SaaSベースのSlackやMicrosoft Teamsを使うと、機微なデータが第三者クラウドに渡ることになる。金融・医療・政府・防衛といった規制業種では、これがコンプライアンス上のブロッカーになりやすい。

Mattermostはオンプレミスサーバー・プライベートクラウドにデプロイできるため、データ主権の問題を根本から解決する。さらにEUのGDPR、米国のFedRAMP、医療業界のHIPAAといった規制要件にも柔軟に対応できる設計だ。

1.2 リポジトリの規模感

GitHubのスター数は36,600件、フォーク数は8,600件で、コラボレーション系OSSとしては最大級のコミュニティを擁する。デフォルトブランチはmaster、言語はTypeScript・Goが中心で、月次リリースが安定運用されている。

トピックタグにはcollaboration・golang・react・react-native・monorepoが並ぶ。モノレポ構成のため、サーバー・Web・モバイル・デスクトップアプリを単一リポジトリで追跡できる点も好評だ。

「open core」の意味
Mattermostは「コア機能はOSS、エンタープライズ機能は商用」というopen coreモデルを採用している。SSO・コンプライアンスエクスポート・データ保持ポリシーといった企業向け機能は商用ライセンスに含まれるが、チャット・通話・Playbooks・Boardsといった基本機能は無料版で完結する。中小規模なら無料版で十分、大企業は商用版を契約する設計だ。

2. なぜSlack代替の本命と呼ばれるのか：3つの構造的優位

Mattermostが「Slack代替の本命」として語られる理由は、機能の多寡ではなく設計思想にある。

2.1 データ主権を握れる

Slackの生データはSlack Technologies社のサーバーに保管され、エクスポートも条件付きだ。Mattermostは自社のオンプレ・プライベートクラウドに置けるため、PostgreSQLに全メッセージが溜まる。

監査・コンプライアンス対応で「誰が何時にどのチャンネルで発言したか」を検索する用途でも、SQLで自由にクエリできる。データを完全に自社管理下に置きたい組織にとって、これは譲れない要件だ。

2.2 ChatOps前提の設計

SlackもWebhook・APIを提供するが、Mattermostは「DevSecOpsの作業基盤」として強化されたコマンド体系を持つ。CIサーバーから直接インシデントを起票するPlaybooks、Trelloライクなカンバンを統合したBoards、/jiraや/githubスラッシュコマンドが標準で揃う。

オンコール体制を運営する組織では、「Slackで議論→別ツールでインシデント管理」という分断が日常的に発生する。Mattermostは議論とインシデント管理を同じ画面で完結させる設計で、Mean Time To Resolution（MTTR）短縮に直結する。

2.3 AI統合がデータ越境ゼロで完結する

Mattermost AgentsプラグインはOpenAI・Anthropic・Azure OpenAI・Ollama・vLLMといった幅広いLLMバックエンドに対応する。ローカルLLMを使えば、機微なチャット内容を一切外部に出さずに要約・アクション抽出・スマートリアクションを動かせる。

SlackのAIアシスタントは便利だが、メッセージ本文がSlack側のAI処理基盤を経由するという前提がある。データ越境を許容できない業種では、これが致命的な障害になる。Mattermost Agentsはこの問題に対する直接的な回答だ。

3. アーキテクチャ：シンプルさで運用負荷を削る

Mattermostの構成は驚くほどシンプルだ。アプリケーションサーバー・データベース・オプションのオブジェクトストレージという3層構成で完結する。

flowchart LR subgraph Client["クライアント"] C1["Webブラウザ"] C2["デスクトップ
(Electron)"] C3["モバイル
(React Native)"] end subgraph Server["Mattermostサーバー"] S1["Go API
サーバー"] S2["WebRTC
通話プラグイン"] S3["Agents
プラグイン"] S4["Playbooks
プラグイン"] end subgraph Storage["永続化層"] D1["PostgreSQL
メッセージ/メタ"] D2["S3互換
ファイル"] end subgraph LLM["LLMバックエンド"] L1["OpenAI
API"] L2["Anthropic
Claude"] L3["Ollama
ローカル"] end C1 --> S1 C2 --> S1 C3 --> S1 S1 --> D1 S1 --> D2 S2 -.->|"WebRTC"| C1 S3 -->|"OpenAI互換API"| L1 S3 --> L2 S3 --> L3

3.1 単一バイナリの利点

Mattermostサーバーは静的リンクされたGoの単一バイナリだ。mattermostコマンドだけで起動でき、依存ライブラリのバージョン管理に悩むことがない。

これはDockerfileを書く時にも、Kubernetes Manifestを書く時にも効いてくる。COPY mattermost /usr/local/bin/の1行でアプリ層がデプロイ完了する単純さは、運用工数を確実に削る。

3.2 プラグイン拡張モデル

Mattermostは「コア＋プラグイン」モデルで進化してきた。Playbooks・Boards・Calls・Agents・GitHub Bot・Jira Botといった主要機能はすべて公式プラグインとして提供される。

プラグインはGoで書かれ、サーバー本体と同じプロセス内で動作する。プラグインAPIは安定しており、サードパーティ製プラグインも700種類以上がMattermost Marketplaceに登録されている。

3.3 マルチプロダクト統合

Mattermostは単なるチャットアプリではなく、Boards（カンバンボード）・Playbooks（インシデント対応自動化）・Calls（WebRTC通話）を統合した「コラボレーションスイート」として進化している。

これらはすべて同じユーザー認証・同じチャンネル権限の上で動作する。Notion・Trello・Slack・Zoomを別々に契約する代わりに、Mattermost1つで完結する組織が増えているのはこのためだ。

4. Slack・Rocket.Chat・Zulipとの比較

OSSのSlack代替を選ぶときに必ず比較対象になる3製品とMattermostを並べる。中心軸は「セルフホスト容易性」「データ主権」「DevOps適性」だ。

項目 Mattermost Slack Rocket.Chat Zulip
ライセンス MIT（コア） プロプラ MIT Apache 2.0
セルフホスト ◎（公式推奨） × ◎ ◎
データベース PostgreSQL – MongoDB PostgreSQL
主要言語 Go + React – JavaScript Python + Django
デスクトップ Electron（公式） Electron Electron Electron
モバイル React Native（公式） ネイティブ React Native ネイティブ
音声/ビデオ WebRTC（公式Calls） Huddles Jitsi連携 外部連携
AI統合 Agents（OSS） Slack AI（有償） RC AI –
E2E暗号化 ✕（TLS+at-rest） – ◎（部屋単位） ✕
インシデント対応 Playbooks内蔵 別契約 – –
カンバン Boards内蔵 – – –
最低メモリ 4GB – 2GB 2GB
主要採用業種 防衛/金融/政府 全業種 カスタマー対応 開発者コミュニティ
GitHubスター 36,600 – 41,800 22,500

4.1 セットアップの簡潔さで勝る

＜悪い例＞ Rocket.Chatは多機能だがMongoDBの運用が必要で、レプリカセット構成・バックアップ・バージョンアップで地雷を踏みやすい。

＜改善例＞ MattermostはPostgreSQL一本で済む。AWS RDS・Cloud SQL・Aiven・Supabaseといったマネージドサービスをそのまま使えるため、DBA負担が小さい。

PostgreSQLは多くの組織で既に運用ノウハウが蓄積されている。これに乗れるという点が、長期運用コストで大きな差を生む。

4.2 DevOps用途で勝る

Playbooksはインシデント対応の各ステップをチェックリスト化し、実行ログを自動でタイムライン化する。Slackで同等のことをやろうとすると、PagerDutyやIncident.ioといった別ツールを契約する必要がある。

Mattermostは「コラボレーションツール＋ライトウェイトなインシデント管理」を1つでこなせる。SREチームの「常駐するルームをそのままインシデントルームに昇格」という運用が自然に成立する。

4.3 AIの自由度で勝る

Slack AIは有償アドオンで、しかもSlack社のクラウド上でしか動かない。Mattermost AgentsはOSSプラグインで、好きなLLMバックエンドに繋ぎ替えられる。

Ollamaでローカル動作させればAPIコストゼロでチャット要約が手に入る。「AIの利便性は欲しいが、データは社外に出せない」という組織にとって、これは唯一無二の選択肢だ。

5. Docker Composeで5分セットアップ

ここからは実装に入る。最も手軽な方法はDocker Composeで、Mattermost本体とPostgreSQLの2コンテナだけで完結する。

5.1 docker-compose.yml の雛形

version: "3.8"

services:
  postgres:
    image: postgres:15-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: mmuser
      POSTGRES_PASSWORD: change_me_strong_password
      POSTGRES_DB: mattermost
    volumes:
      - postgres_data:/var/lib/postgresql/data

  mattermost:
    image: mattermost/mattermost-team-edition:latest
    restart: unless-stopped
    depends_on:
      - postgres
    ports:
      - "8065:8065"
    environment:
      MM_SQLSETTINGS_DRIVERNAME: postgres
      MM_SQLSETTINGS_DATASOURCE: "postgres://mmuser:change_me_strong_password@postgres:5432/mattermost?sslmode=disable"
      MM_BLEVESETTINGS_INDEXDIR: /mattermost/bleve-indexes
      MM_SERVICESETTINGS_SITEURL: "https://chat.example.com"
    volumes:
      - mattermost_data:/mattermost/data
      - mattermost_logs:/mattermost/logs
      - mattermost_config:/mattermost/config
      - mattermost_plugins:/mattermost/plugins

volumes:
  postgres_data:
  mattermost_data:
  mattermost_logs:
  mattermost_config:
  mattermost_plugins:

docker compose up -dで起動し、http://localhost:8065/にアクセスすれば管理者アカウント作成画面が表示される。

5.2 リバースプロキシ設定（Caddy推奨）

本番運用では必ずTLSを噛ませる。Caddyfileなら3行で済む。

chat.example.com {
    reverse_proxy localhost:8065
    encode gzip
}

caddy run --config Caddyfileで起動すれば、Let’s Encryptで証明書を自動取得しTLS終端する。Nginxでも同等の構成は可能だが、Caddyの方が設定量は圧倒的に少ない。

5.3 PostgreSQLチューニング

100ユーザー以上の本番環境では、PostgreSQLのshared_buffersを割り当てメモリの25%程度に設定する。max_connectionsは200程度を目安に、work_memは16MB前後が現実的だ。

Mattermost公式ドキュメントに性能ガイドラインが整備されており、ユーザー数・チャンネル数・1秒あたりメッセージ数別の推奨スペック表が公開されている。

本番運用での注意
Docker Composeはあくまでも検証・小規模運用向けだ。100ユーザー超やHA要件がある環境では、Kubernetes Operator（mattermost-operator）または公式のtarインストールで構成し、PostgreSQLをマネージドサービス化することを公式が推奨している。

6. ChatOps実装：Incoming Webhookと/slashコマンド

Mattermostの本領は「CIサーバー・監視ツールから直接通知が飛び、その場でオペレーションを完結できる」点にある。

6.1 Incoming Webhookで通知を受ける

管理画面の「Integrations → Incoming Webhooks」で発行したURLにJSONをPOSTすれば、指定チャンネルに通知が飛ぶ。Slackと完全互換のペイロード形式なので、既存のSlack向けスクリプトをほぼそのまま使える。

#!/usr/bin/env bash
WEBHOOK_URL="https://chat.example.com/hooks/abcd1234efgh5678"
curl -X POST -H "Content-Type: application/json" \
  -d '{
    "channel": "ops-alerts",
    "username": "deploy-bot",
    "icon_emoji": ":rocket:",
    "text": "**Production Deploy**\nVersion v2.5.0 deployed successfully\nCommit: `a1b2c3d`\nDuration: 4m23s"
  }' \
  "$WEBHOOK_URL"

GitHub Actions・GitLab CI・Jenkinsから上記のcurlを叩くだけで、デプロイ通知をMattermostに流せる。channelを上書きすれば、Webhook1本で複数チャンネルに振り分けることも可能だ。

6.2 Outgoing WebhookとSlashコマンド

Mattermost側のメッセージをトリガーに外部システムを動かしたい場合は、Outgoing Webhookまたはカスタムスラッシュコマンドを使う。/deploy productionと打ったらJenkinsジョブを実行する、といった連携が10行のスクリプトで書ける。

# /deploy エンドポイント（FastAPIサンプル）
from fastapi import FastAPI, Form
import httpx

app = FastAPI()
JENKINS_URL = "https://jenkins.example.com/job/deploy/build"
JENKINS_TOKEN = "your_jenkins_api_token"

@app.post("/deploy")
async def deploy(
    token: str = Form(...),
    text: str = Form(...),
    user_name: str = Form(...),
):
    if token != "EXPECTED_MM_SLASH_TOKEN":
        return {"response_type": "ephemeral", "text": "Unauthorized"}
    env = text.strip() or "staging"
    async with httpx.AsyncClient() as client:
        await client.post(
            f"{JENKINS_URL}?token={JENKINS_TOKEN}",
            params={"ENV": env, "TRIGGERED_BY": user_name},
        )
    return {
        "response_type": "in_channel",
        "text": f":hourglass: {user_name} triggered deploy to **{env}**",
    }

このエンドポイントを管理画面の「Slash Commands」で登録し、トリガーワードを/deployにすれば実装完了だ。response_type: in_channelにすると応答がチャンネル全員に見え、ephemeralなら実行者本人にしか見えない。

6.3 GitHub PluginとJira Plugin

公式GitHub PluginをインストールすればPRイベント・Issueイベントが指定チャンネルに自動投稿される。Jira Pluginも同様で、/jira createでその場からチケットを発行できる。

ChatOpsツールチェーンを自前で組む手間が省け、開発チームの作業基盤として一気通貫した体験を提供できる。「チャットを離れずに開発・運用が回る」のがMattermostの理想形だ。

7. Mattermost AgentsでローカルLLM統合

Mattermost AgentsはOpenAI互換APIに対応するLLM統合プラグインだ。OpenAI・Anthropic・Azure OpenAI・Ollama・vLLM・LM Studioと幅広く接続できる。

7.1 主要機能

Agentsプラグインで使える代表機能は次のとおりだ。

  • スレッド要約：長くなったスレッドを1クリックで要約
  • チャンネル要約：直近24時間のチャンネル投稿を要約
  • アクション抽出：会議メモから「誰が何をするか」を箇条書きに
  • ミーティング書き起こし：CallsプラグインのWebRTC通話を文字起こし
  • セマンティック検索：埋め込み検索で意味の近い過去メッセージを発見
  • スマートリアクション：投稿内容から適切な絵文字リアクションを提案
  • AIボットチャット：専用チャンネルでAIに自由に質問

複数のAIボットを「ペルソナ」として登録できるので、社内向け（Ollama）と社外向け（Claude）を別ボットで運用するのも自然だ。

7.2 Ollama接続の設定例

OllamaをホストOSで起動し、llama3.1:8bモデルをpullしておく。Mattermost管理画面の「Plugins → Mattermost Agents → Bots」で次のように設定する。

  • ・ボット名：Local LLM
  • ・サービスタイプ：OpenAI Compatible
  • ・APIキー：任意の文字列（Ollamaは認証不要だが入力必須）
  • ・APIベースURL：http://host.docker.internal:11434/v1
  • ・モデル：llama3.1:8b

設定後にチャンネルで@local-llm このスレッドを要約してと発言すると、ローカルLLMが要約を返す。ネットワークアクセスはMattermostサーバーとOllamaの間だけで完結し、外部APIへは一切出ない。

7.3 コスト感とユースケース

OpenAI GPT-4oで全社チャットを要約しまくると、月額コストが$300〜$1000に達することは珍しくない。Ollamaに切り替えれば電気代だけで済む。

ただしローカルLLMは推論速度・要約品質でクラウドモデルに劣ることが多い。「機微なチャンネルだけローカル、社外メンバーがいるチャンネルはClaude」というハイブリッド運用が現実解だ。Mattermost Agentsはチャンネル別にボットを切り替えられるため、これが自然に成立する。

8. 監視・バックアップ・コンプライアンス

本番運用ではメトリクス監視・バックアップ・コンプライアンスエクスポートが必須だ。

8.1 Prometheus / Grafanaで監視

Mattermostは/metricsエンドポイントを公開し、PrometheusでスクレイプできるOpenMetrics形式で出力する。「アクティブユーザー数」「DBコネクション数」「APIレイテンシ分布」「WebSocket接続数」といった指標が標準で取得可能だ。

公式GitHubにはmattermost/mattermost-grafana-dashboardとしてGrafanaダッシュボードのJSONが公開されている。grafana-cli plugins installしてインポートすれば、すぐに使える可視化が手に入る。

8.2 PostgreSQLバックアップ

Mattermostの全データはPostgreSQL＋ファイルストレージに集約されるので、バックアップは次の2点だけを押さえれば良い。

  • ・PostgreSQLのフルダンプ（pg_dump）
  • ・mattermost_dataボリューム（添付ファイル）の同期

クラウド前提なら、PostgreSQLはRDSのスナップショット、ファイルはS3のバージョニング有効化で済む。バックアップ自動化の詳細は DatabaseMent徹底解説：データベースバックアップを統合管理するセルフホストOSS に書いた手順が応用できる。

8.3 監査ログとコンプライアンスエクスポート

商用版Mattermostは監査ログとコンプライアンスエクスポート機能を提供する。すべてのチャンネル投稿・DM・ファイル添付を指定期間でCSV/XMLエクスポートでき、SECやFINRAといった金融規制要件を満たす設計だ。

OSS版でもAPIでPOST /api/v4/auditsをスクレイピングすれば、簡易的な監査ログ運用は可能だ。組織のログ集約基盤に流したい場合は LogBull徹底解説：複数サーバーのログを1つに集めるセルフホストOSS と組み合わせると運用が安定する。

9. プロダクトアナリティクスとの組み合わせ

社内チャットの利用状況やDevOps施策の効果測定では、プロダクトアナリティクスとの連携が効く。

9.1 Mattermost自体の利用状況

Mattermostの「System Console → Site Statistics」で、月間アクティブユーザー数・投稿数・チャンネル数といった基本指標を確認できる。商用版ではより詳細な統計が解放され、ユーザーエンゲージメント分析も可能だ。

これらの指標を時系列で残してダッシュボード化したい場合は、PrometheusとGrafanaが第一選択肢になる。

9.2 デプロイとMattermost通知の効果測定

「デプロイ通知をMattermost経由でやり始めてからインシデント検知が速くなった」といった効果測定では、外部プロダクトアナリティクスツールが便利だ。Webhookでイベントを送信し、ファネル分析・コホート分析にかける。

OSSのプロダクトアナリティクスとしては PostHog徹底解説：GA4の代替になるオープンソースのプロダクトアナリティクス が定番だ。Mattermost自体のメトリクスはPrometheus、ユーザー行動はPostHogという棲み分けが現実的だ。

9.3 ChatOpsダッシュボードの作り方

各ChatOpsスラッシュコマンド（/deploy・/rollback・/incident）が呼ばれた回数を集計すれば、組織のDevOps成熟度が見えてくる。「デプロイ頻度」「ロールバック率」「インシデント平均解決時間」といったDORAメトリクスとも直接結びつく。

Mattermost側でslashコマンドのアクセスログを取り、Prometheusのexporterを書くだけで実現できる。

10. まとめ：データ主権とDevOps適性で選ぶならMattermost

Mattermostは「Slackを置き換える」というより、「Slackでは届かないユースケースを埋める」OSSとして成熟してきた。データ主権を握り、DevOps作業基盤を一体化し、ローカルLLMでAI機能まで自社完結する。

導入判断の指針
  • ・規制業種・データ主権重視：Mattermostは第一選択肢。MIT版＋自社PostgreSQLで完結。
  • ・DevSecOps・インシデント対応：PlaybooksとCallsのセットが強力。
  • ・AI機能を社内データで：Mattermost Agents＋Ollamaで外部APIゼロ運用が可能。
  • ・外部パートナー連携が多い：Slack Connectの代替はないため、SaaSとの併用が現実的。
  • ・カスタマーサポート用途：Live Chat機能のあるRocket.Chatが向く。

無料版Mattermost Team EditionでもAPI・Webhook・プラグイン・Agents・Playbooks・Boards・Callsが揃う。中小規模なら無料版で十分、規制業種・1000ユーザー超の組織でEnterprise版を検討するのが筋の良い導入経路だ。

導入の第一歩はDocker Composeで30分の動作確認から始めるのが推奨だ。docker compose up -dの1コマンドで、自社オフィスでSlack体験を再現できる。そこからGitHub Plugin・Agentsを順次足していけば、「外部SaaSに依存しないコラボレーション基盤」が3ヶ月で完成する。

参照ソース