私がオンラインカスタマーサポートシステムを個人開発のテーマに選び、長年情熱を注ぎ続けていることに対し、時折「なぜその分野なのか？」と聞かれることがあります。競合がひしめくレッドオーシャンであり、すでに多くの選択肢が存在する市場で、なぜあえて勝負するのか。その理由をこのブログで詳しくお話ししたいと思います。
市場環境と技術路線の2つの観点から、このレッドオーシャンにまだ開拓の余地がある理由、そして、その技術的ハードルが想像以上に高い理由を分析していきます。
市場の観点：小規模チーム向けのオンプレミス型（私有化）システムは本当に多いのか？
中小規模のチームにとって、オンラインカスタマーサポートシステムの選択肢は本当に多いのでしょうか？実はそうではありません。市場にある製品を横断的に分類すると、大きく以下の3つに分けられます。
大手SaaS製品
SaaS形式がメインで、サブスクリプション料金が高めに設定されています。利用量やオペレーター数が多い場合、中小チームにとっては大きな負担となります。また、オンプレミス（私有化）対応をしていないか、対応していてもプロジェクト案件として扱われるため、費用が極めて高額になります。二番手グループの製品
SaaS形式がメインで、オンプレミス（私有化）対応は二の次というスタンスです。サブスクリプション料金はピンキリで、製品の品質も玉石混交です。オンプレミス導入に関しては価格が公表されていないことがほとんどで、営業担当者を通じた個別交渉が必要になります。私が調査した数社では、導入費用に 数万ドルから十数万ドル ほどかかり、しかも「買い切り」モデルは存在せず、毎年技術保守料を支払い続ける必要があります。小規模ベンダーによる簡易的な製品
このレベルの製品は無数に存在します。「粗悪だが安い」のが特徴で、中には数百ドルでソースコードを販売しているものもあり、そのほとんどが純粋なWeb版です。ローカル環境で数人のテスターを動かす分には問題ありませんが、本番環境で運用を始めると、メッセージの消失、誤配信、長時間の接続維持ができない（ランダムなフリーズや切断）といった問題が露呈します。
また、これらすべての製品に共通しているのが、情報の「不透明さ」です。
公式サイトに詳細な技術資料はなく、オンプレミス用のインストールパッケージを直接ダウンロードすることもできません。必ず営業担当者に連絡する必要があります。私が実際に2社に問い合わせたところ、用途や規模を細かく聞かれ、電話での確認まで求められました。相手の規模を見て価格を決める、いわゆる「足元を見る」ような対応に不快感を覚えました。さらに、パッケージ自体は渡されず、ドメインを提供して彼らにデプロイを任せなければなりません。おそらく、こちらのビジネス規模や支払い能力を把握し、「カスタマイズ価格」を提示するためでしょう。
結論として、あなたが中小チームの責任者で、「100%オンプレミスで構築でき、価格は手頃で、機能はシンプルながらも品質は妥協したくない」というシステムを探しているなら、実は**「選択肢がない」**ことに気づくはずです。レッドオーシャンに見えて、実は理想の選択肢が存在しないのです。
そこが、私の切り込んだ方向性です。「小さくて美しい、安定性と信頼性を兼ね備えた、大手企業並みの品質を持つシステム」を目指しました。オンプレミス導入のコストを抑え、興味のある人が直接ダウンロードできるよう、無料のオンプレミス版を堂々と公開し、詳細な技術資料もすべてオープンにしています。
それこそが、私が ShenDesk で実現したいことなのです。
技術的側面：なぜオンラインカスタマーサポートシステムは難しいのか
続いて、技術的な次元の話をしましょう。私は、99% の人がカスタマーサポートシステムの技術的な実現難易度を大幅に低く見積もっていると断言できます。多くの「CRUDエンジニア」はこう言うでしょう。「WebSocket でメッセージをやり取りするだけでしょ？」と。
これは、文系の学生が Python で「Hello World」を書けるようになっただけで、「プログラミングなんてこんなものか」と感嘆しているのと似たようなものです。
こうした考えが浅薄なのは、彼らがソフトウェア開発の真の概念を理解していないからです。カスタマーサポートシステムは、サーバー側であれクライアント側であれ、内部で非常に複雑な**「状態マシン（State Machine）」**を維持し続ける必要があります。これは、ステートレスな CRUD 系のシステムとは全くの別物です。
接続管理と安定性の問題
あなたが扱うのは数件の接続ではありません。数万、あるいはそれ以上の**ロングコネクション（長残接続）**です。ブラウザ、モバイル端末、不安定なネットワーク環境（弱電界）、断線後の再接続、プロキシ、企業用ファイアウォールなど、あらゆるエッジケースに対応しなければなりません。
- ハートビート（生存確認）メカニズム
- 動的な再接続戦略
- セッション復旧メカニズム
これらを緻密に設計する必要があります。処理が甘ければ、即座にメッセージの消失や、別の人にメッセージが届く「誤配信」につながります。
メッセージの信頼性と一貫性
「メッセージを送信した」ことと「相手が受信した」ことはイコールではありません。以下の要素を確実に処理する必要があります。
- ACK（受領確認）とリトライ（再送）
- べき等性（重複排除）の確保
- 順序保証
このプロセスには、メッセージのルーティング、配信、永続化、そして過去ログへの遡及が複雑に絡み合います。さらに、次のような問いに答えを出さなければなりません。
- メッセージの順序が入れ替わることを許容するか？
- 同一セッション内での厳密な順序をどう保証するか？
- ストレージへの保存に失敗した場合、どうリカバリーするか？
いわゆる「小規模ベンダーの玩具」レベルの製品は、この段階で既に崩壊し始めます。
さらに踏み込んでみましょう。カスタマーサポートシステムのメッセージ送受信は「リアルタイム」でなければなりませんが、それは同時に、高頻度の通信、低遅延、そして絶え間ないリソース消費を意味します。
- 各接続にどれだけのメモリを割くべきか？
- ハートビートの間隔をどう設定するか？
- ブロードキャスト（一斉送信）によるメッセージストームをどう回避するか？
- データベースの書き込みがボトルネックにならないための策は？
次に、複雑なビジネスステート（状態）管理の問題があります。深く理解していない開発者は、サポートシステムを単なる「チャットルーム」と混同しがちですが、実際には極めて複雑なビジネスプロセスが存在します。
- セッション割り当て（ラウンドロビン、重み付け、スキルグループ別）
- 転送（コンテキストを維持したまま、中断なしで引き継ぐ）
- キュー（待ち行列）管理（優先順位、タイムアウト処理）
- AI 連携（ボットから人間へのスムーズな切り替え）
- オフラインメッセージと訪問者トラッキング
これらの状態は動的に変化し、かつ強力に結合しています。高負荷な環境で処理を誤れば、メッセージの紛失、誤配信、無応答、あるいは突然の切断といった混乱を招きます。二番手グループの製品でさえ、この段階で挙動が怪しくなることが少なくありません。
さらに重要なのが、セキュリティと悪用防止です。サポートシステムは金銭が絡む「注文」と直結していることが多いため、以下の防御策が不可欠です。
- WebSocket の悪用（コネクション・フラッディング）防止
- メッセージインジェクション / XSS 対策
- メッセージの連投（スパム）対策
- API のスクレイピングや DDoS 攻撃からの保護
これらを実現するためのレート制限（Rate Limiting）、認証、隔離メカニズムをどう構築するか、という問いが常に付きまといます。
最後に、オンプレミス（私有化）展開についてです。今でこそ、私のウェブサイトからいつでもパッケージをダウンロードしていただけるようになっていますが、ここに至るまでには多くの泥臭い課題がありました。
- 異なるネットワーク環境（国を跨ぐケースも含む）への適合
- 異なる OS（Linux、Windows、Docker）への対応
- 同じ Ubuntu でも、クラウドベンダーによって異なるOSイメージの差異
- ログ収集、モニタリング、診断システムの構築
- ワンクリックで完了するインストールスクリプトの作成
- バージョンアップデートの仕組み作り
これらすべての課題を振り返ってみて、それでもまだ「ただ WebSocket でメッセージを送受信するだけ」と言えるでしょうか？
確かに、これら多岐にわたる課題を解決するには膨大な時間と労力が必要です。それどころか、特定のエッジケースにおける問題を「発見」すること自体にさえ、多大なリソースを要します。特にユーザーからのフィードバックという協力が得られなければ、一生気づくことのできない不具合も数多く存在します。
しかし、こうした高い「ハードル」こそが、私がオンラインカスタマーサポートシステムの開発を続けている重要な理由でもあります。数年間にわたる執拗なアップデートと知見の蓄積を経て、かつての困難は、今や私を支える強力な「堀（キャッスル・モート）」へと姿を変えました。
独立開発者として、この高い参入障壁があるからこそ、いわゆる「個人開発の三種の神器（家計簿、メモ帳、ToDoリスト）」のような、激しい直接競争にさらされることのない独自の領域を築けているのです。