問い合わせ対応の現場は、気づかないうちに「分散」している。メールは共有アドレスで受けて、チャットはWebサイトの別ツールで動いていて、InstagramのDMは担当者の個人スマホで確認している——そういう状態が、中小企業ではごく普通に起きています。
この分散が引き起こすのは、劇的な失敗よりも「静かな損失」です。対応漏れに気づくのが翌日になる。同じ問い合わせに二人が別々に返信してしまう。担当者が休んだら誰も状況を把握できない。どれも致命的ではないけれど、積み重なると顧客の信頼を少しずつ削っていきます。
Chatwootは、そういった問い合わせの分散を一画面に集めるためのオープンソースのカスタマーサポートプラットフォームです。2020年にOSSとして公開され、GitHubで現在も活発に開発が続いています。UIのイメージはSlackに近く、左サイドバーにチャンネル（メール受信箱・ライブチャット・WhatsApp・Facebookメッセンジャーなど）が並び、中央ペインに会話スレッドが一覧表示される。担当者はこの一画面だけを開いていれば、どのチャネルから来た問い合わせも見落とさずに拾える、という設計です。
「オムニチャネル」という言葉は少し大げさに聞こえるかもしれませんが、Chatwootがやっていることは実務的にシンプルです。バラバラに届く問い合わせを一か所に集め、チームで分担して返せるようにする。それだけです。この記事では、Chatwootを自社サーバーで動かすことが現実的かどうかを、コストと運用の両面から正直に整理します。
ZendeskやIntercomと何が違うのか
Chatwootと比較されることが多いのは、IntercomやZendeskといったSaaSのカスタマーサポートツールです。機能の優劣を細かく比べても、プランの詳細はすぐ変わるので意味が薄い。ここでは「費用構造」「データの置き場所」「カスタマイズの自由度」という3つの軸で整理します。
- 費用構造：IntercomもZendeskも、基本的にエージェント（対応担当者）の人数に応じて月額が上がる課金モデルです。担当者が増えるほどコストが重くなる構造で、組織が成長するにつれて費用の伸びが目立ってきます。Chatwootのセルフホスト版はエージェント数の制限がなく、何人追加しても追加費用はかかりません。
- データの置き場所：SaaSはデータがベンダーのクラウドに置かれます。Chatwootのセルフホストは、顧客データが自社サーバー上に残ります。業種によっては個人情報の保管場所に制約があるケースもあり、そういった場合にセルフホストが選ばれることがあります。
- カスタマイズの自由度：OSSなのでソースコードを改変できます。ただし、これを活かせるのは社内にその技術力がある場合に限ります。
一方で、正直に言うと、機能の成熟度・外部サービスとの連携の豊富さ・サポート体制という点では、IntercomやZendeskに分があります。Salesforceや各種CRMとの深い連携、細かいレポーティング、充実したヘルプドキュメント——これらはSaaSが長年かけて積み上げてきたものです。Chatwootはそこに追いついてはいますが、まだ差があります。
「コストを下げたい」という動機だけで飛びつくと、機能面で物足りなさを感じる場面が出てくる可能性があります。判断の軸は費用だけでなく、「自社の問い合わせ量と複雑さに対して、Chatwootの機能で十分かどうか」にあります。
Docker Composeで試験起動するまで
「まず触ってみたい」という場合、Chatwootの公式ドキュメントはDocker Composeを使った手順を案内しています。Dockerが動く環境（VPSやローカルのLinuxマシンなど）があれば、以下の流れで試験起動できます。
まず、公式が用意している設定ファイルを取得します。公式ドキュメント（developers.chatwoot.com/self-hosted/deployment/docker）では最新の安定版URLが案内されているため、実際に試す際はそちらを参照してください。以下はドキュメントに沿った手順の概要です。
# 作業ディレクトリを作成して移動
mkdir chatwoot && cd chatwoot
# 公式ドキュメントに記載のURLから設定ファイルを取得する
# （URLは公式ドキュメントで確認してください）
wget -O docker-compose.yaml <公式ドキュメント記載のURL>
wget -O .env <公式ドキュメント記載のURL>
次に .env ファイルを編集して、最低限の環境変数を設定します。
# .env（抜粋・最低限設定が必要な項目）
SECRET_KEY_BASE=ここに長いランダム文字列を入れる
FRONTEND_URL=http://localhost:3000
# メール送信を使う場合はSMTP設定も必要
SMTP_ADDRESS=smtp.example.com
SMTP_USERNAME=your@example.com
SMTP_PASSWORD=yourpassword
SECRET_KEY_BASE は openssl rand -hex 64 などで生成したランダム文字列を使います。ここを空のままにすると起動しても正常に動きません。環境変数を設定したら、公式ドキュメントの手順に従ってデータベースの初期化とサービスの起動を行います。
# サービスをバックグラウンドで起動（公式ドキュメント記載のコマンド）
docker compose up -d
コンテナが立ち上がると http://localhost:3000 にアクセスできるようになります。ただし、この状態では外部からアクセスできません。コンテナはlocalhostにしかバインドされていないため、インターネット越しに使うにはNginxなどのリバースプロキシを前段に置き、SSL証明書（Let's Encrypt等）を設定する必要があります。「Dockerで動かした」と「外部公開できる状態にした」の間には、もう一段の作業があります。
初期管理者アカウントについても注意が必要です。公式のDockerガイドには初期ユーザーのID・パスワードが明記されていないため、GitHubのDiscussionでも「管理者アカウントをどう作るのか」という質問が複数上がっています。実際には、起動後に http://localhost:3000 へアクセスすると初回セットアップ画面が表示され、そこで管理者アカウントを作成する流れになっています。ドキュメントを読んでいると「アカウントはどこで作るのか」で詰まりやすいので、先に知っておくと安心です。
「無料で使える」の正体と、向いている会社・向いていない会社
Chatwootはオープンソースなので、ソフトウェアのライセンス費用はかかりません。ただし「無料で使える」という言葉は、かなり限定的な意味でしか正しくありません。
自前で運用するということは、サーバー費用・SSL証明書の管理・データベースのバックアップ・定期的なバージョンアップ・障害発生時の復旧対応、これらをすべて自社で負担するということです。SaaSならベンダーが担っている領域が、まるごと自社の責任範囲になります。
これらを誰がやるか、というのが最大の問いです。LinuxサーバーとDockerを日常的に触れる人が社内にいれば、運用負荷はそれほど高くありません。しかし、そういう人がいない場合、外部のエンジニアに依頼することになります。その費用が積み重なると、SaaSの月額と大差なくなる——あるいは超えることもあります。
もう一つ見落とされがちなリスクがあります。担当者が辞めたら誰も触れないという状態です。OSSの自前運用は、設定した人の頭の中にノウハウが集中しやすい。その人が抜けたとき、サーバーの構成もバックアップの仕組みも誰も把握していない、という状況は決して珍しくありません。SaaSならベンダーがすべて管理しているので、担当者が変わっても継続できます。
では、自社に向いているかどうか。断定的な答えを出すよりも、自問してみる問いを渡す方が実用的だと思っています。
- 社内に、Linuxサーバーを日常的に管理できる人間がいるか？
- 問い合わせチャネルが複数あって、一元化の必要性を実際に感じているか？
- 顧客データを自社サーバーに置く必要がある業種・ポリシーか？
- SaaSの月額が、今の問い合わせ量に対して明らかに重いと感じているか？
これらに「はい」が多いほど、Chatwootのセルフホストを試してみる価値があります。逆に「エンジニアはいないが、とにかく安くしたい」という動機だけで進めると、運用でつまずく可能性が高いです。
「まず試す」という選択も、「SaaSのまま続ける」という選択も、どちらも正解になり得ます。大事なのは、「無料OSS＝コストゼロ」という前提を外した上で判断することです。ソフトウェアのライセンスが無料なのと、運用が無料なのは、まったく別の話です。
株式会社ホコサキは、山口県宇部を拠点にWeb制作・業務システム開発・AI活用支援を手がけています。Chatwootの導入検討や、自社に合ったサポートツールの選定について相談したい場合は、お問い合わせページからお気軽にどうぞ。