LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Mattermostセルフホストとは何か

Mattermostセルフホストとは、オープンソースのビジネスチャット基盤であるMattermostを、自社が管理するサーバーやプライベートクラウド上に自前で構築・運用する形態を指します^*1。クラウド版（Mattermostが提供するホスティング環境）を使わず、インフラの選定からミドルウェアの設定、アップグレードまでを自社または委託先が担う点が特徴です。

Mattermostはサーバー本体をGitHub上でオープンソース公開しており、無料のTeam Editionに加え、システム管理機能などを追加するEnterprise向けライセンス提供を行っています^*1。セルフホスト方式ではDocker・Ubuntu・tar形式などの手段でサーバーを展開でき、Kubernetes上でOperatorを使う構築方法も用意されています^*2。

構築後はチャネル単位でのやり取り、Webhookを使った外部システム連携、プラグインによる機能拡張などをすべて自社の管理下で設定します。SaaS型のように運用元がインフラを管理する形態ではなく、サーバーの選定・冗長化・監視までを自社の責任範囲に含む点が、セルフホストという言葉の指す実態です。

SaaS型ビジネスチャットとの違い

Slack・Microsoft TeamsなどのSaaS型ビジネスチャットは、提供事業者がサーバー・ネットワーク・可用性を管理し、利用企業はアカウントを契約するだけで使い始められます。対してMattermostのセルフホストでは、サーバーの調達からアップグレード・バックアップまでを利用企業側（または委託先）が担う点が根本的に異なります。

この違いはデータの保管場所にも直結します。SaaS型ではメッセージやファイルが事業者のクラウド環境に保存されるのに対し、セルフホストでは自社が指定したサーバー・ストレージにデータが留まります。閉域網や社内データセンターに構築すれば、外部ネットワークを経由せずにチャット基盤を運用する構成も選べます。

セルフホストが選ばれる理由

Mattermostのセルフホストが選ばれる背景には、機密情報を扱う業務でのデータ主権（データの保管場所や管理権限を自社が握ること）への要求があります。金融・官公庁・製造業の設計情報など、社外にメッセージデータを置くこと自体がリスクとなる業務では、閉域網内にチャット基盤を置く構成が検討対象になります。

Mattermostは air-gapped（外部ネットワークから完全に分離された）環境への展開手順も公式ドキュメントで示しており^*6、インターネット接続のない環境でもサーバーを構築できる設計になっています。この点は、外部SaaSでは代替が難しい要件です。

また、Mattermostのサーバー本体はオープンソースとして公開されており^*1、ソースコードを確認したうえで自社の要件に応じた改修やプラグイン開発を加える余地があります。SaaS型では提供元の機能範囲内でしか運用できませんが、セルフホストでは連携システムの仕様に合わせて挙動を調整する選択肢が残ります。

チャネル運用とWebhook・プラグイン連携

Mattermostのコミュニケーション単位はチャネル（channel）と呼ばれ、公開チャネル・非公開チャネル・ダイレクトメッセージに分かれます。プロジェクト単位・部署単位でチャネルを分け、必要なメンバーだけを招待する運用が基本形です。

外部システムとの連携には、Incoming Webhook（外部から特定チャネルへメッセージを投稿する仕組み）とOutgoing Webhook（チャネル内の投稿条件に応じて外部サービスへHTTP POSTを送る仕組み）の双方が用意されています^*7。Incoming Webhookでは、システム管理者が発行した一意のWebhook URLに対してJSON形式のデータを送信するだけで、監視アラートやCI/CD通知をチャネルに流し込めます。

Outgoing Webhookは公開チャネルでのみ利用でき、非公開チャネルやダイレクトメッセージでの同等機能はスラッシュコマンドで代替する設計です^*7。加えてMattermostはSlack互換のWebhook形式に対応しているため、既存の外部連携スクリプトを流用しやすい点も特徴です^*7。

より高度な拡張はプラグイン（manifestとサーバーバイナリ・JavaScriptバンドルで構成される追加モジュール）で実現します^*8。システム管理者はPlugin Marketplace（プラグインの中央リポジトリ）からプラグインを選び、System Console（システム管理画面）上で有効化・設定を行います^*8。Marketplace経由のプラグインは公開鍵証明書による署名検証の対象になるため、導入前に対象プラグインの提供元を確認する運用が求められます^*8。

SSO・LDAPによる認証連携の要点

社内チャット基盤として運用する以上、既存の社員IDとの統合は避けて通れない論点です。Mattermostは SAML 2.0 のService Provider（サービス提供側）として動作する構成に対応し、Okta・OneLogin・Microsoft ADFSなどのIdentity Provider（認証情報を管理する外部サービス）を公式にサポートしています^*9。Microsoft Entra IDやKeycloakとの連携手順も個別に用意されています^*10。

ディレクトリサービスとの統合にはLDAP（Lightweight Directory Access Protocol、社員情報などを一元管理するディレクトリサービスへの接続プロトコル）連携が使えます。SAML単体では属性の定期更新や自動的な利用停止（デプロビジョニング）に対応しませんが、AD/LDAPとの同期を組み合わせることで、人事システム側の異動・退職情報をチャット基盤のアカウント状態に反映できます^*11。

設定はSystem Console内のAuthentication（認証）セクションで、SAML 2.0の有効化とAD/LDAP同期のスイッチを切り替える形で進めます^*11。認証基盤を先に確定させたうえでMattermostの認証設定を組むと、後工程での手戻りを抑えられます。

アップグレード・バックアップ・可用性の運用負荷

セルフホストで最も見落とされやすいのが、構築後に継続する運用工数です。バージョンアップグレードでは、事前にデータベースとアプリケーション全体の完全なバックアップを取得したうえで作業する手順が公式に明記されています^*3。Kubernetesや高可用性（High Availability）環境では、通常のアップグレード手順と異なる専用の進め方が必要です^*12。

バックアップ対象は一枚岩ではありません。サーバー設定を保持するconfig.json、ローカルストレージを使う場合のユーザーファイル格納ディレクトリ、そしてデータベースの3つを、それぞれ個別に退避・復元する設計です^*13。復元時もこの3系統を元の配置に戻す手順を踏む必要があり、いずれか一つを欠くとメッセージ履歴やファイルの復旧が不完全になります。

可用性を高める場合は、冗長化されたアプリケーションサーバー・データベースサーバー・ロードバランサーを組み合わせた高可用性クラスタ構成を取ります^*4。ノード間の状態同期には専用の通信プロトコルを使い、config.jsonのClusterSettings項目で設定し、System Console上で各ノードの同期状態を緑色のステータスで確認する運用です^*4。データベースはPostgreSQLのクラスタリングまたはAmazon Auroraが推奨構成として挙げられています^*4。

これらの作業は一度構築すれば終わりではなく、バージョンが上がるたびに繰り返し発生します。専任の運用担当を置かずに継続すると、アップグレードの遅延によるセキュリティパッチ未適用や、バックアップ設定の陳腐化が生じやすくなります。

構築の流れと必要スキル

構築は要件定義・環境構築・認証連携・連携拡張・運用開始の順で進みます。要件定義では利用規模（想定ユーザー数・チャネル数）と、既存システムとの連携要件（Webhook対象・認証基盤）を洗い出します。

環境構築ではDocker・Ubuntu・tarいずれかの方式でサーバーを展開し、データベースとリバースプロキシ（NGINX等）、TLS証明書を設定します^*14。この工程には、Linuxサーバー運用・データベース管理・ネットワーク設定（リバースプロキシ・TLS）の知識が必要です。認証連携の工程ではSAML/LDAPの設定に加え、既存の認証基盤（Active Directory・IdPサービス）側の設定変更も伴います。

内製でこの一連の作業を担う場合、Linuxインフラ・データベース・認証プロトコルの3領域を横断して扱える人材が要ります。いずれかの知識が欠けると、構築自体は動いても、TLS設定の不備や認証連携の抜け漏れが後から表面化するリスクがあります。とくに認証連携の設定を誤ると、社員が意図せずログインできなくなる、あるいは退職者アカウントが残存するといった事態につながるため、設定内容の事前レビューが欠かせません。

外注と内製、判断の軸

内製と外注のどちらを選ぶかは、社内に前述の3領域（インフラ・DB・認証）を担える人材が既にいるか、そしてアップグレード・バックアップ・可用性確保を継続的に回せる体制があるかで分かれます。初期構築だけを外部に依頼し、運用は内製に切り替える段階的な進め方も選択肢の一つです。

専門パートナーに依頼した場合は、要件定義から認証連携・可用性設計までを一括して任せられるため、構築期間の見通しが立てやすくなります。一方で内製する場合は、構築後も自社エンジニアがMattermostのバージョン追従・障害対応を担い続ける前提になり、他の開発業務との工数配分が課題になりやすいです。

LASSIC IT事業部は、元請（プライムベンダー）としてシステムの保守・運用を受託する体制を持ち、セルフホスト型のコラボレーション基盤についても要件整理から構築・運用設計までの支援に対応します。閉域網構成や既存の認証基盤（Active Directory・IdPサービス）との連携要件がある場合も、既存システムとの整合を踏まえた設計を検討できます。

まとめ：Mattermostセルフホスト導入の3つの判断軸

本稿ではMattermostをセルフホストで構築する際の考え方を整理しました。要点を3つに集約すると、第一にデータ主権や閉域網要件がセルフホストを選ぶ主な動機になること、第二にWebhook・プラグイン・SSO/LDAP連携が拡張性を支える一方で設定の正確さが問われること、第三にアップグレード・バックアップ・可用性確保という継続的な運用負荷を誰が担うかが内製/外注の分岐点になることです。構築初期だけでなく運用フェーズまで見据えた体制設計が、チャット基盤を長期的に安定稼働させる前提になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Mattermost「Self-Hosted Subscriptions」
2. *2　出典：Mattermost「Host Mattermost on Your Own Infrastructure」
3. *3　出典：Mattermost「Upgrade Mattermost」
4. *4　出典：Mattermost「High availability cluster-based deployment」
5. *5　出典：Mattermost「GitHub – mattermost/mattermost」
6. *6　出典：Mattermost「Deploy in Air-Gapped Environments」
7. *7　出典：Mattermost「Webhooks」
8. *8　出典：Mattermost「Plugins configuration settings」
9. *9　出典：Mattermost「SAML Single Sign-On」
10. *10　出典：Mattermost「Configure SAML with Microsoft Entra ID」
11. *11　出典：Mattermost「Configure SAML synchronization with AD/LDAP」
12. *12　出典：Mattermost「Upgrade Mattermost in Kubernetes and High Availability environments」
13. *13　出典：Mattermost「Backup and disaster recovery」
14. *14　出典：Mattermost「Deployment Guide」
15. *15　出典：Mattermost「Migration guide」

Tweet