kubellのCTOをしている田中（@tan_yuki）です。
この記事は kubell Advent Calendar 2025 の25日目の記事です。
kubell Advent Calendar最終日ということで、今回はkubellの中でも特にChatworkの今後の技術的な展望と、現在地点についてお話します。
kubellの事業的な現在地点
kubellはビジネスチャットサービスである Chatwork を運営しています。
2025年現在、Chatworkは日本国内で約90万の企業が利用しており、ビジネスチャットサービスの市場では高いシェアを持っています。
そういった大規模な国産ビジネスチャットを運用している一方で、そのビジネスチャットを基盤とした「BPaaS」というものを展開しています。BPaaSに関して、そして我々が何を目指しているのかについては、ちょうど弊社COOが別Advent Calendarにまとめている記事がありますので、詳細はぜひこちらを参照してください。
前提： 技術的側面から見たChatwork
上記の事業を進めていくうえで、技術的に求められることをまとめてみます。
ビジネスチャットゆえの非常に高いスループットと求められる可用性
ビジネスチャットのプロダクトは一般的に以下のような性質が求められます。
高スループット
- ビジネスチャットなので、普段使いする人は常にチャットサービスを開いている
- ビジネスチャットゆえに一定のリアルタイム性も求められる（完全なリアルタイム反映ではないが、数分程度遅れてメッセージを受信するのは違和感がある）
高可用性
- ビジネスチャットはコミュニケーションのインフラとなるツールのため、システムダウンしていると仕事ができないのとほぼイコール
- それ故、システムダウンがあった場合にいかにはやく復旧できるかが重要（= レジリエンス）
- また、故障範囲を狭い範囲に留めるなど、フェイルセーフの考え方が重要
- メンテナンス時間も、できるだけ短くすることが期待される
また、システム特性としては、WriteよりReadのリクエストが圧倒的に多く、それを捌くための負荷分散の仕組みが重要です。現状のChatworkでいうと、だいたい9:1くらいでReadが多いです。（とはいえ、この1のWriteリクエストも総量としては非常に多く、このWriteをどう捌くかもまた重要なのですが…）
オープンプラットフォーム性
先程述べたのは一般的なビジネスチャットの特徴ですが、Chatwork独自の特徴として「オープンプラットフォーム性」があります。
ここでいうオープンプラットフォーム性とは、たとえば Slack のようなビジネスチャットでは「ワークスペース」という概念がありますが、Chatwork にはそういった概念がない、ということです。
私たちのユーザーには中小企業の方々が多いのですが、特に中小企業では、業務がすべて社内で完結するということはほとんどありません。さまざまな企業と連携して業務を行っています。
Chatwork では「コンタクト」さえつなげてしまえば、それだけで社外の方々とも連携ができるようになります。こういった特徴が、特に中小企業の方々に評価されています。
一方、このような仕様は技術的にはいろいろ考える必要があります。
ワークスペース単位で区切れれば、その単位で DB が分割でき、いわゆるマルチテナント的な運用ができますが、オープンプラットフォーム性はいわば「一つの世界（ワンワールド）」ですべてを実現する必要があります。
要するに、ある悪意あるユーザーが悪意ある使い方をした場合、他のユーザーにも影響が伝播しやすい構造です。そういったことを考慮した設計が必要になってくるため、高い負荷分散の仕組みや各種ガードレールなどが求められます。
システム的な現状：モノリスな構造とそれらに紐づく組織構造
Chatworkは10年以上運用している巨大なシステムでできています。 現状はこのシステムが巨大なモノリスであるが故に認知負荷が高く、コミュニケーションが複雑になりやすい性質を抱えています。そのため、機能変更・追加の難易度は非常に高い状況です。
また、この巨大なモノリスシステムを再構築するにしても、10年以上の歴史が積み重なった上にできているため、仕様にまとまっていない複雑なコンテキストを読み取り再構築するのは非常に難しいです。 このモノリスなシステムを解消するためにリプレイスプロジェクトは進んでいましたが、全体を構築し直すのはスコープ的にあまりにも広く、一部をサブシステム的に分割するにとどまっています。
また、このモノリスなシステム構造が故に、組織を分割するのもまた難易度が高い状況になっています。本来であればチームとシステムが紐付き、チーム内で意思決定やDevOpsができるような体制が望ましいと考えています。 しかし、現状のモノリスな構造では、たとえチームが分かれたとしてもその境界（責務）を探る難易度が高く、ボールが落ちやすくなってしまいます。 そのため、現状の組織構造としては、基本は職能別の組織となり、認証、決済機能などの一部の機能のみ機能別の組織体制としています。
Chat x BPaaS x AI
今後、特にBPaaSの世界を実現していくうえで、以下のCPO徳原の記事にもある通りAIのプロダクトやオペレーションへの組み込みは非常に重要になってきます。
私たちはいままでSaaSプロダクトとしてWebアプリケーション開発のCapabilityの獲得をしてきましたが、AIを取り巻く機能開発は今までのCapabilityとはかなり性質が違うものであり、今後適応していく必要があります。直近ではAIエンジニアの採用も進み、新しいCapability獲得にも力を入れています。社内でもAI関連のプロジェクトが多く立ち上がってきているので、手を上げた人がチャレンジできるような体制も整備していきたいと考えています。
また、BPaaSを含め、今後の事業展開としてはChatworkを中心に様々なプロダクトと連携をしていくため、その連携の基盤の準備もまた必要です。
今後のChatworkのアーキテクチャ
上記前提を含め、Chatworkについてはイベント駆動型のアーキテクチャを漸進的に目指します。
短期的にリプレイスを行うのではなく、長期的な目線でプロダクト開発と並行しながらすすめていく道を模索します。
最終的に目指すアーキテクチャ像は以下のような図を想定しています。
具体的な特徴としては、全てのイベントをMessageBusに集約し、各コンポーネントがそれを購読する形で動作するアーキテクチャを採用している点です。これにより、サブシステム間の連携もMessageBusを介して行われます。また、複数のサブシステムで構成されることを想定し、API Gatewayの層（弊社では「ファサード」と呼称）を設けています。
Why? – なぜイベント駆動型アーキテクチャなのか
前提として、高いスループットと可用性を維持し続けるために、よりスケーラブルなアーキテクチャへ移行する必要があると考えています。 現状のモノリスなシステムやDB構成はいずれ性能限界を迎えるため、システムやDBを適切に分割していく必要があります。
また、今後機能がどんどん拡張され、アジリティ高くプロダクトを進化させていくためには、システムを分割し、組織についてもスケールできるような体制を目指していく必要があります。
さらに、BPaaSなどの外部連携においてもイベント駆動は有効です。API連携ではシステム同士が強く依存してしまいますが、MessageBusを介することで「密結合」を回避できます。これにより、柔軟かつ可用性の高い連携基盤を実現していきたいと考えています。
How? – どう進めるのか
本プロジェクトは大規模な改修となるため、完了までには相応の時間を要する見込みです。過去にも類似の取り組みはありましたが、進捗したとはいえ部分的な改善にとどまっているのが現状です。
そのため、今回は最終的な全体像（大きな絵）を描きつつ、現実的に実施可能な範囲から段階的に移行を進めます。第一フェーズとしてファサード層を導入し、現在のAPIインターフェースの負債を解消します。その後、モノリスなシステムを徐々に分離し、サブシステム構成へと移行していく予定です。
細かい話は書ききれませんので、ご興味のある方はぜひイベント会場でお声がけください。
アーキテクチャ移行の現在地点
現在、ファサード層（API Gateway層）についての第一弾リリースを年内で（ほぼ）完了しています。
Chatworkシステムとしては歴代を見てもかなり大きな変更であり、非常に大きな一歩を踏み出せたと認識しています。技術としてはGraphQLを導入し、会社としては初のGo言語でのプロダクトをリリースしています。今後のアーキテクチャ刷新の第一歩になったことも大きいですが、それ以外にも、今まであったAPIのインターフェース負債がかなり解消できる見込みもあり、今後のプロダクト開発における生産性の向上にもつながる見込みです。
「今後はどうするの？」については、また別の機会にお話させていただきます。
まとめ
観点としては2点あります。
- ビジネスチャットという特性、特にオープンプラットフォーム性を持っているChatworkの可用性をどう担保するのか？
- 今後のBPaaSを含む他システムとの連携をどう考えるか？
それらへの回答として、MessageBusを中心としたイベント駆動型のアーキテクチャを目指していきたい、というお話と、その現在地点の共有でした。
今後も事業的なチャレンジも、技術的なチャレンジも続けていきます！Playful Challenge！（弊社のバリューです）
ということで、Advent Calendar 25日目の記事でした。メリークリスマス！
最後の蛇足
Advent Calendar、完走しました！
こう改めてみると、やはり弊社ってタレント揃いだなぁというのと、特に新卒の方々が非常に早く成長しているなというのが実感できました。一緒に事業とともに成長したい方、難易度の高いチャレンジがたくさんです！一緒にChat x BPaaS x AIの世界を実現していきましょう！
