顧客からの問い合わせがメール・Webチャット・SNS・WhatsApp などに分散し、対応履歴があちこちに散らばってしまう。Intercom や Zendesk のような商用 SaaS を使えば一元化できますが、利用人数や会話数に応じてコストが膨らみ、顧客データを外部のクラウドに預けることへの懸念も残ります。
「データは自社で管理したい、けれどチャネルは統合したい」という要件を両立させようとすると、選択肢は一気に絞られます。そこで候補に挙がるのが、オープンソースかつセルフホスト可能なカスタマーサポート基盤である Chatwoot です。
ただ、いざ採用を検討すると「これは具体的に何の代替になるのか」「自社の要件（チャネル・AI・レポート）を満たすのか」「セルフホストの技術要件はどの程度か」「ライセンスは本当に無料で使えるのか」「Zammad など他の OSS とどう違うのか」といった疑問が次々に湧いてきます。これらが解消されないままでは、採用の意思決定はできません。
本記事では、GitHub リポジトリ chatwoot/chatwoot と公式ドキュメントをもとに、Chatwoot の立ち位置・主要機能・技術構成・ライセンス・類似OSSとの違いを整理します。検証はすべてドキュメントベースで行っており、最終的に「自社で採用すべきか／見送るべきか」を自分で判断できる状態を目指します。
Chatwootとは｜Intercom・Zendeskのオープンソース代替
一行で何をするOSSか
Chatwoot は、複数のチャネルにまたがる顧客との会話を 1 つの受信トレイに集約する、オープンソースのカスタマーサポートプラットフォームです。GitHub リポジトリ（chatwoot/chatwoot）の説明文では「Open-source live-chat, email support, omni-channel desk. An alternative to Intercom, Zendesk, Salesforce Service Cloud etc.」と定義されており、Intercom・Zendesk・Salesforce Service Cloud といった商用カスタマーサポート SaaS のオープンソース代替という位置づけが明確に示されています。
最大の特徴は、セルフホスト（自社サーバーでの運用）に対応している点です。これにより顧客データを完全に自社管理しつつ、ライブチャット・メール・各種 SNS をチャネル横断で扱えます。クラウド版（公式サイトが提供するホスティング）も用意されているため、「まず試したい」段階と「本番でデータを自社管理したい」段階の両方に対応できます。
リポジトリ基本情報でメンテナンス健全性を確認
採用検討で最初に気になるのは「このプロジェクトは今も活発に開発されているか」という点です。リポジトリのメタデータを整理すると次のようになります。
項目 | 値 |
|---|---|
リポジトリ | chatwoot/chatwoot |
主要言語 | Ruby |
スター数 | 32,737 |
Fork 数 | 7,771 |
最終更新（push） | 2026-06-19 |
アーカイブ状態 | アーカイブされていない（active） |
フォーク | 本家リポジトリ（フォークではない） |
スター数 32,737・Fork 数 7,771 という規模はカスタマーサポート系 OSS のなかでも大きく、コミュニティが厚いことを示します。最終 push が直近（2026-06-19）であり、リポジトリはアーカイブされておらず（archived=false）、他リポジトリのフォークでもない（fork=false）本家のアクティブなプロジェクトです。メンテナンスが途絶えた OSS を採用してしまうリスクは、現時点では低いと判断できます。
なお、これらの数値は記事執筆時点（2026年6月）の GitHub 上の値です。最新の状態は公式リポジトリで確認してください。
Chatwootの主要機能｜オムニチャネル・AI・ヘルプセンター
「自社の要件を満たすか」を判断するには、機能カテゴリごとに何ができるかを押さえる必要があります。ここでは受信トレイ・AI・ナレッジベースという 3 つの軸で整理します。
オムニチャネル受信トレイと対応チャネル
Chatwoot の中核は、複数のチャネルからの問い合わせを 1 つの受信トレイにまとめるオムニチャネル機能です。README によると、対応チャネルにはライブチャット（Web サイト埋め込み）、メール、Facebook、Instagram、Twitter、WhatsApp、Telegram、LINE、SMS が含まれます（README）。
顧客がどのチャネルから連絡してきても、エージェントは同じ画面で対応履歴を確認しながら返信できます。問い合わせチャネルが分散している企業にとっては、この一元化が導入の主目的になることが多いでしょう。
AIエージェント Captain と Copilot
Chatwoot には AI 機能として Captain と Copilot が用意されています。Captain は、ヘルプセンター・過去のチャット・FAQ から学習し、よくある質問に自動で回答する AI エージェントです（Captain ドキュメント）。定型的な問い合わせを自動解決することで、人間のエージェントの負荷を下げる役割を担います。
一方の Copilot は、エージェント向けに回答候補をサジェストする AI アシスタントです。会話履歴やヘルプ記事へのクイックアクセスを通じて、エージェントが素早く適切な回答を作成できるよう支援します。AI による一次対応の自動化と、人間の対応支援の両方を備えている点は、要件に AI 活用が含まれる場合の判断材料になります。
ヘルプセンター・レポート・連携
問い合わせ対応そのもの以外の機能も充実しています。
- ヘルプセンターポータル: ヘルプ記事・FAQ・ガイドを公開できる組み込みのナレッジベース。多言語ポータル・独自ドメイン・SSL に対応します。
- コラボレーション/生産性: プライベートノート、@メンション、ラベル、定型返信（Canned Responses）、自動アサイン、営業時間・自動応答、チーム単位の自動化、エージェントのキャパシティ管理など。
- 顧客データ管理: 連絡先管理（プロフィール・対応履歴）、セグメント、キャンペーン、カスタム属性、プレチャットフォーム。
- 連携（Integrations）: Slack、Dialogflow、Shopify、Google 翻訳、Linear など。
- レポート・分析: ライブビュー、会話・エージェント・受信トレイ・ラベル・チーム別レポート、CSAT（顧客満足度）レポート、ダウンロード可能なレポート。
機能の詳細や最新の対応範囲は公式ヘルプセンターで確認できます。レポート機能が会話・エージェント・チームなど複数の切り口で用意されているため、運用後の改善サイクルを回したい場合にも対応しやすい構成です。
Chatwootの技術構成とセルフホスト要件
セルフホストを前提にする場合、「自社で運用できる技術スタックか」「運用コストはどの程度か」がそのまま採用可否に直結します。
アーキテクチャ（Rails / Vue / Sidekiq / PostgreSQL / Redis）
Chatwoot のアーキテクチャは、Ruby/Rails エコシステムを中心に構成されています（Docker 本番デプロイガイド）。
- バックエンド: Ruby on Rails（アプリケーションサーバーは Puma、ポート 3000）
- フロントエンド: Vue.js
- バックグラウンドジョブ: Sidekiq（Web と同一の Docker イメージを別サービスとして起動し、Redis をキューとして共有）
- データベース: PostgreSQL（AI 機能のベクトル検索に pgvector 拡張を利用）
- キャッシュ/キュー: Redis
主要言語は Ruby で、リポジトリの言語構成は Ruby が大部分を占め、フロントエンドの Vue、JavaScript が続きます。Rails と PostgreSQL/Redis の運用経験がある組織であれば、技術スタックの学習コストは比較的抑えられます。逆に、これらの運用知見が社内にない場合は、後述の「向かないケース」も含めて検討が必要です。
デプロイ方法（Docker / Kubernetes / ワンクリック / クラウド版）
セルフホストの導入手段は複数用意されています（Docker 本番デプロイガイド、README）。
- Docker / Docker Compose: 公式が本番デプロイガイドを提供する標準的な方法
- Kubernetes: Helm chart が用意され、Artifact Hub で公開
- ワンクリックデプロイ: Heroku の Deploy ボタン、DigitalOcean の 1-Click Kubernetes
- クラウド版: 自社で運用したくない場合は chatwoot.com のホスティングを利用
必須インフラは Docker、PostgreSQL、Redis、そして Nginx 等のリバースプロキシです。データベースの初期化には専用の Rake タスクが用意されています。公式ドキュメントでは、Docker 環境での初回セットアップやイメージ更新時に次のコマンドを実行する手順が示されています。
docker compose run --rm rails bundle exec rails db:chatwoot_prepare
出典: Docker Chatwoot Production deployment guide - Chatwoot Developer Docs
通常の rails db:migrate ではなく、Chatwoot 固有の db:chatwoot_prepare を使う点が注意点です。また、Web サービスと Sidekiq サービスで SECRET_KEY_BASE や暗号化キーなどの環境変数を一致させる必要があります。これらはドキュメントに明記された手順であり、本記事では実際の構築・動作確認は行っていません。実装時は必ず公式デプロイドキュメントの最新手順に従ってください。
Chatwootのライセンス｜MITとEnterpriseの違い
採用判断で最も見落とされやすいのが、本番運用時のライセンスとコストです。GitHub の自動ライセンス判定では、Chatwoot のライセンスは NOASSERTION（単一ライセンスとして自動確定できない状態）と表示されます。これはリポジトリ内に2 種類のライセンスが混在しているためで、ライセンスが不明・未設定という意味ではありません。
- コミュニティ版（大部分のコード）: MIT ライセンス。README 末尾にも「Released under the MIT License」と明記されています（LICENSE）。セルフホストで自由に利用・改変できます。
enterprise/ディレクトリ: 別途の商用ライセンス。SAML/SSO、SCIM プロビジョニング、監査ログといったエンタープライズ向けのガバナンス機能がこの配下にあり、本番環境でこれらを使うには有料サブスクリプションが必要です。
GitHub API のライセンス判定が NOASSERTION になるのは、この MIT と商用ライセンスの混在を自動判定ツールが単一ライセンスに確定できないことが理由です（Chatwoot Pricing Teardown 2026 - DEV Community）。
つまり、コミュニティ版の機能であればセルフホストで無料利用できる一方、SSO や監査ログなどのエンタープライズ機能が必須要件の場合は商用サブスクリプションのコストを前提に検討する必要があるということです。「OSS だから完全無料で全機能が使える」と思い込んで導入を進めると、本番運用の段階でガバナンス要件を満たせない、という落とし穴があります。自社の要件にエンタープライズ機能が含まれるかを、採用判断の早い段階で確認しておくことをおすすめします。
類似OSS・SaaSとの違い｜Zammad・Tawk.to・Intercom
「他の選択肢とどう違い、どういう場合に Chatwoot を選ぶべきか」は、採用判断の核心です。代表的な類似ツールとの違いを整理します。
Zammad との違い（会話駆動 vs チケット駆動）
Zammad（zammad/zammad）は、Chatwoot と同じく Ruby on Rails 系のオープンソースのヘルプデスク／サポートデスクです。強力なプロセス制御やチケット管理、オムニチャネルを備えています。
両者の最も大きな違いは設計思想です。Zammad はチケット駆動の「サポートデスク」志向で、問い合わせを 1 件ずつチケットとして管理・追跡するワークフローに強みがあります。一方の Chatwoot は会話（チャット）駆動で、リアルタイムのライブチャットやメッセージングを中心に据えています。ライブチャットや SNS でのカジュアルなやり取りが多いプロダクトでは Chatwoot、厳密なチケット管理プロセスが必要な業務サポートでは Zammad、という棲み分けが目安になります。コミュニティ規模では、GitHub スター数で Chatwoot が Zammad の約 5 倍と大きくなっています（Chatwoot vs Zammad - openalternative）。
Tawk.to・Intercom/Zendesk との違い（データ所有・コスト）
Tawk.to は完全無料のライブチャットツールですが、オープンソースではなくプロプライエタリで、SaaS としてのみ提供されます。料金面では魅力的なものの、セルフホストやデータの自社所有、オムニチャネル統合の自由度がない点が Chatwoot との大きな違いです（tawk.to vs Chatwoot - StackShare）。
Intercom や Zendesk は商用 SaaS の本家であり、Chatwoot が標榜する「オープンソース代替」の比較元です。機能の成熟度やサポート体制では商用 SaaS に分がありますが、利用規模に応じた料金、顧客データの外部保管、カスタマイズ性の制約がトレードオフになります。Chatwoot は、これらを「セルフホストによるデータ所有」と「オープンソースによるカスタマイズ自由度」で置き換える選択肢です。
比較表
ツール | 種別 | データ所有/セルフホスト | コスト | 主な設計思想 |
|---|---|---|---|---|
Chatwoot | OSS（Rails系） | 可能（セルフホスト） | コミュニティ版は無料、Enterprise機能は商用 | 会話駆動・オムニチャネル |
Zammad | OSS（Rails系） | 可能（セルフホスト） | OSS版は無料 | チケット駆動のサポートデスク |
Tawk.to | プロプライエタリSaaS | 不可（SaaSのみ） | 完全無料 | ライブチャット特化 |
Intercom / Zendesk | 商用SaaS | 不可（SaaSのみ） | 有料（規模課金） | 統合カスタマーサポート（本家） |
Chatwoot が選ばれる軸は、データの自社所有、オープンソースによるカスタマイズ性、複数チャネルの統合、そして厚いコミュニティ規模に集約されます。
Chatwootが向いているケース・向かないケース
最後に、ここまでの整理を採用判断の形にまとめます。
Chatwoot が向いているケース
- 顧客データを外部 SaaS に預けず、自社で完全に管理したい
- ライブチャット・メール・SNS など複数チャネルを 1 つの受信トレイに統合したい
- 商用 SaaS のランニングコストを抑えたい、または規模課金を避けたい
- Rails / PostgreSQL / Redis の運用知見があり、カスタマイズ前提で使いたい
- AI による一次対応（Captain）やエージェント支援（Copilot）を活用したい
検討・注意が必要なケース
- セルフホストの運用工数（インフラ保守・アップデート・監視）を割けない
- SAML/SSO・SCIM・監査ログなどのエンタープライズ機能が必須要件である（商用サブスクリプションのコストが前提になる）
- Docker / PostgreSQL / Redis の運用知見が社内になく、学習・運用の負担が大きい
- 厳密なチケット管理プロセスが中心の業務である（この場合は Zammad など他の選択肢も比較する価値があります）
Chatwoot は、スター数 32,737・最終更新が直近というアクティブなプロジェクトであり、メンテナンス健全性の面では安心して検討できる OSS です。「データを自社管理しながらチャネルを統合したい」という要件に対しては有力な候補になりますが、本番運用ではセルフホストの運用負荷とライセンス（MIT のコミュニティ版か、商用の Enterprise 機能か）を切り分けて評価することが、後悔しない採用判断につながります。実際の機能範囲やデプロイ手順は、本記事で挙げた公式サイト・公式ドキュメント・開発者向けデプロイドキュメントで最新情報を確認したうえで、自社の要件と照らし合わせてください。
