チャットシステムの作り方【2026年9月版】先に決める7つと、リアルタイム通信・既読・通知の設計

「自社のサービスにチャットを載せたいだけなのに、何から決めればいいのか分からない」——チャット機能の相談を受けると、最初に出てくるのがこの言葉です。画面は単純なのに、仕様を書き始めた途端、既読はどうする、通知は出すのか、画像は送れるのか、相手をブロックできるのか、と決めることが芋づる式に増える。検索しても、出てくるのはノーコードツールの紹介か、チャットボットの作り方ばかり。これが実情です。

結論から言うと、チャットシステムの作り方は、先に7つを決めれば設計が固まります。用途(ユーザー同士のメッセージ / カスタマーサポート / AIチャットボット)、リアルタイム通信の方式、既読と通知、メッセージの保存とデータ量、画像・ファイルの添付、グループの設計、通報とブロック。この7つです。同じ材料から、既製のチャットSDKで足りるのか自前で作るのか、費用と期間がどれくらいかも出てきます。

逆に、決めずに着手すると、実装が終わってから設計をやり直すことになります。既読をメッセージごとのフラグで作ってしまい、参加者が増えた途端に書き込みが膨らむ。通報とブロックを後回しにして、リリース後にトラブルが起きて緊急対応になる。どちらも、順番の問題です。

本記事では、用途3分類と設計が変わる点、リアルタイム通信の4つの選択肢(ポーリング / WebSocket / Server-Sent Events / Firebase等のBaaS)、既読・通知・保存・添付の設計、グループチャットと通報・ブロック、既製SDKと自前の分岐と概算費用、外部チームへの任せ方、よくある質問の順に解説します。サービスの料金は2026年9月15日に各社の公式ページで確認した値だけを載せ、確認できなかったものはプラン名と無料枠の有無に留めました。通信方式の仕様はMDNとRFCを参照しています。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。当社が担当した求人プラットフォームやマッチングサービスにもメッセージ機能が含まれており、どこで工数が膨らむかは何度も見てきました。あわせて、既製SDKで十分なケースも率直に書きます。作らずに済むなら、そのほうが早いからです。

チャットシステムの作り方は用途で決まる——ユーザー同士・カスタマーサポート・AIチャットボットの3分類

チャットシステムという言葉は、中身の違う3つのものをまとめて指しています。ユーザー同士がやり取りするメッセージ機能、企業と顧客がやり取りするカスタマーサポートの問い合わせチャット、そして機械が応答するAIチャットボットです。画面は似ていますが、誰と誰が話すか、履歴を何のために残すか、監視が要るかがそれぞれ違い、そこから先の設計がすべて分かれます。作り方を考えるときは、まずここを確定してください。

用途3分類の比較表——誰と誰が話すか、履歴は何のために残すか、監視は要るか

3分類のうち、いちばん作るものが多いのはユーザー同士のメッセージです。相手をブロックできるか、通報を受け付けるか、過去のやり取りをどこまでさかのぼれるか——このあたりが全部、設計の対象になります。当社が担当してきた求人プラットフォーム(ATS)や介護業界向けのマッチングアプリも、この分類に入ります。

用途が変わると設計が変わる3点——会話の単位、履歴の保持期間、誰が読めるか

1つ目は会話の単位です。ユーザー同士なら「AさんとBさんの会話」という関係が続くため、会話は一度作ったら閉じません。一方、問い合わせチャットは「この用件」ごとに開いて閉じるため、同じ顧客から3回問い合わせがあれば会話は3つになります。ここを取り違えると、問い合わせチャットなのに過去の全用件が1本の長いスレッドにつながり、オペレーターが探せなくなります。

2つ目は履歴の保持期間です。ユーザー同士のメッセージは、トラブル時の証跡として一定期間残す必要があり、退会後の扱い(相手側の画面にどう見えるか)まで決めておく必要があります。問い合わせチャットは対応品質の管理が目的なので、保持期間を明確に区切れます。AIチャットボットのログは、個人情報を含む可能性を前提に、保持と学習利用の線を引いておく必要があります。

3つ目は誰が読めるかです。ユーザー同士のメッセージを運営が読めるようにするかどうかは、利用規約とプライバシーポリシーに直結します。通報があったときだけ該当部分を開ける、といった運用の設計が要ります。「全部読める」も「一切読めない」も、後から変えるのが難しい決定です。

AIチャットボットは「チャットの作り方」とは別物——本記事で扱う範囲

AIチャットボットは、見た目こそチャットですが、作るものが違います。メッセージ基盤ではなく、モデルの選定、APIの費用、社内データを答えさせる仕組み(RAG)、プロンプトの管理、回答の評価が中心になります。本記事はメッセージ基盤の設計を扱うため、AIチャットボットは用途の1つとして位置づけるに留めます。

AIエージェントを含む開発の依頼先や費用感は「AIエージェント開発会社」の記事、LLMを組み込むときの技術論点は「生成AIアプリ開発」の記事にまとめてあります。有人チャットにあとからAIを足す構成は現実的で、当社もLLMを使った24時間対応のAIチャットボットを手掛けていますが、先に人と人のやり取りを成立させてから足すほうが、順番として確実です。

着手前に決める5項目——要件メモの型

見積もりを取る前に、次の5項目だけでもメモにしてください。ここが埋まっていないと、開発会社から出てくる金額は前提が違うまま並ぶことになり、比較ができません。

1. 用途: 上の3分類のどれか。複数なら、どれを先に出すか
2. 話す相手の関係: 1対1か、グループか。グループなら最大人数の想定
3. 即時性の要求: 送信から相手の画面に出るまで、何秒なら許容できるか
4. 利用規模: 月にやり取りする人数(MAU)と、1日あたりのメッセージ通数の想定
5. 扱う情報: 個人情報・機微情報を含むか。ファイルを送るか。データを国内に置く必要があるか

私は2018年からホーチミンで約100社の開発体制の相談に乗ってきましたが、チャット機能の相談でよく見るのは、この5項目を決めないまま「チャット一式」で見積もりを取り、金額が跳ねて承認が下りずに止まる案件です。とくに3番目の即時性は、次に説明する通信方式の選択を直接左右します。ここから、その4つの選択肢を見ていきます。

リアルタイム通信の4つの選択肢——ポーリング、WebSocket、Server-Sent Events、BaaS

チャットシステムの作り方でいちばん誤解が多いのが、ここです。「リアルタイム=WebSocket」と思われがちですが、実務で選べる方式は4つあり、どれを選ぶかは即時性の要求と運用体制で決まります。常時接続は即時性を得る代わりに、接続の管理・再接続・複数サーバーへの分散という運用を持ち込みます。得られるものと持ち込まれるものを、先に天秤にかけてください。

4方式の比較表——通信の向き、接続の持ち方、向く用途、運用の重さ

表の順に見ていきます。結論だけ先に言うと、1回目のリリースはポーリングで出し、利用が伸びてからWebSocketに切り替えるのが、当社が相談を受けたときにいちばん多く勧める進め方です。

ポーリングとロングポーリング——最初の版ではこれで足りることが多い

ポーリングは、クライアントから「新しいメッセージはありますか」と定期的に問い合わせる方式です。通常のHTTP APIと同じ作りなので、既存のWebアプリにそのまま載ります。認証もログもエラー処理も、いま使っている仕組みが流用できます。

欠点は無駄な問い合わせが発生することと、間隔の分だけ遅延することです。ただし問い合わせチャットのように、相手が返信を書くのに数十秒かかる用途では、3秒間隔でも体感は十分です。「リアルタイムでなければならない」という要求は、実は「入力中です」の表示と、通知が即時に届くことの2つに分解できることが多く、後者はプッシュ通知で解けます。

ロングポーリングは、サーバーが新着が出るまで応答を保留する方式です。RFC 6455(The WebSocket Protocol、2011年)は、WebSocketが生まれた背景として「複数のHTTP接続を開くことに依存せずにサーバーと双方向通信を行う必要があるブラウザベースのアプリケーション」を挙げており、ロングポーリングはまさにその「依存していた」側の手法です。いまから新規に選ぶ理由は少なく、WebSocketが使えない環境の代替と考えてください。

WebSocket——双方向の常時接続。得られるものと、持ち込まれる運用

WebSocketは、MDNの説明によれば「ユーザーのブラウザーとサーバーとの間で双方向の対話的な通信セッションを開くことを可能にする」API です。サーバーから送られてくる返答をポーリングで待つ必要がなくなります。1本の接続で双方向にやり取りできるため、メッセージの到達も、相手の入力中の表示も、既読の反映も同じ接続に載せられます。

持ち込まれる運用は3つあります。1つ目は接続の維持です。モバイル回線では電波状況や画面のスリープで接続が切れるため、再接続と、切れている間に発生したメッセージの取り直しを必ず実装します。2つ目はサーバーの分散です。アプリケーションサーバーを複数台に増やすと、AさんとBさんが別のサーバーにつながる状況が起き、サーバー間でメッセージを配る仕組み(Redisのpub/subなど)が要ります。3つ目は接続数の上限です。1台が保持できる接続数には限界があり、想定MAUではなく同時接続のピークで設計します。

MDNは「ページが WebSocket 接続を開いていると、ブラウザーがそのページを bfcache に追加しない場合がある」ため、ユーザーが使い終わったら接続を閉じるのがよい習慣だとも述べています。常時接続は「つないだままにする」だけでは成立しない、というのがここでの要点です。

Server-Sent Events——サーバーからの一方通行。HTTP/1.1では1ブラウザ6接続の壁

Server-Sent Events(SSE)は、サーバーからクライアントへの一方向の通信です。MDNは「これは一方向の接続なので、クライアントからサーバーへイベントを送ることはできません」と明記しています。送信は通常のHTTP、受信はSSE、という組み合わせになります。接続が切れたときに自動で再接続する仕組みが標準で備わっているのが利点です。

注意点が1つあります。MDNによれば、HTTP/2 を使わない場合、SSEは開ける接続数の上限の影響を受け、「その上限はブラウザーごとで、非常に小さい数(6)に設定されている」ため、複数タブを開いたときに問題になります。同じドメインに対して6接続までという制約なので、アプリのタブを複数開く使い方が想定されるなら、HTTP/2 での配信を前提にしてください。

Firebaseなどのマネージド(BaaS)——サーバーを持たずに始める

自前でサーバーを運用せず、SDK経由でデータの同期を任せる選択肢です。Firebaseの公式料金ページ(2026年9月15日確認)によると、Realtime Databaseの無料のSparkプランは同時接続100・保存1GB・ダウンロード月10GBが上限で、従量課金のBlazeプランでは1データベースあたり同時接続20万、保存は1GBまで無料でそれ以降1GBあたり5USD、ダウンロードは1日360MBまで無料でそれ以降1GBあたり1USDです。Cloud Firestoreの無料枠は保存1GiB・読み取り5万/日・書き込み2万/日・削除2万/日・下り10GiB/月です。

小規模で始めるには十分な枠がありますが、チャットは読み取りが膨らみやすい機能です。画面を開くたびに全メッセージを読み直す作りにすると、読み取り回数が想定を超えます。BaaSを選ぶ場合は、料金表より先に「1画面あたり何回読むか」を設計してください。

ここまでが通信方式の選択です。次は、方式を決めたあとに必ず出てくる既読・通知・保存・添付の設計に移ります。

既読・未読、プッシュ通知、メッセージの保存とデータ量、画像・ファイルの添付

ここからが、チャットシステムの作り方で実際に工数が積み上がる部分です。既読、通知、保存、添付の4つは、どれも「あって当たり前」に見えるため要件から漏れやすく、後から足すと作り直しになります。とくに既読の持ち方とデータ量の見積もりは、最初の設計を誤ると利用が伸びたときに効いてきます。順に見ていきます。

既読・未読は「メッセージごとのフラグ」ではなく「どこまで読んだか」で持つ

最初に思いつくのは、メッセージ1通ごとに「誰が読んだか」を持つ形です。これは1対1でも書き込みが通数分発生し、グループになると参加者数×通数に膨らみます。100人のグループで1,000通なら、既読の記録だけで10万件です。

実装で標準的なのは、会話ごとに「その人が最後に読んだ位置」を1件だけ持つ形です。ユーザーが画面を開いたら、その会話の最新メッセージのIDか時刻を保存します。未読件数は「自分の最終既読位置より後のメッセージ数」で計算でき、書き込みは会話数×参加者数に収まります。1対1の会話が1万件あっても、既読の記録は2万件で済みます。

この形にすると、次の3点が自動的に決まります。1つ目、未読バッジの数は計算で出せるので、別に持つ必要がありません。2つ目、「既読」の表示タイミングは「画面に表示された時点」か「アプリを開いた時点」かを選ぶだけになります。3つ目、既読を見せるかどうかを後から切り替えられます。読んだ位置は記録しつつ、相手には見せない設定を用意する、といった運用が可能です。

あわせて決めておくのは、既読の表示を「必要」と言い切ってよいかです。ユーザー同士のメッセージでは既読表示がプレッシャーになり、かえって返信が減る場合があります。求人やマッチングのように、返信率が事業の指標になるサービスでは、既読を出さない選択も検討に値します。

プッシュ通知——アプリが閉じている間の唯一の手段と、4,096バイトの制約

WebSocketをつないでいても、アプリを閉じている相手には届きません。アプリが動いていない状態で相手に気づいてもらう手段は、プッシュ通知だけです。AndroidとWebはFirebase Cloud Messaging(FCM)、iOSはAppleのAPNs(FCM経由でも送れます)を使います。

設計で押さえる点は4つです。

本文を載せるかどうかは、機微な情報を扱うサービスほど慎重に決めてください。ロック画面に本文が出ることを嫌う利用者は一定数います。「本文を出す/出さない」をユーザーが選べるようにするのが無難です。

メッセージの保存とデータ量——1通あたりの容量から3年分を概算する

チャットは1件が小さく、件数が多いデータです。設計の勘所は、件数の伸び方を最初に計算しておくことにあります。概算は次の式で足ります。

月間のメッセージ通数 × 1通あたりの平均容量 × 保存月数 = 必要な保存容量

1通あたりの容量は、本文だけなら数百バイトですが、送信者ID・会話ID・時刻・状態・インデックスを含めると1〜2KB程度で見ておくと安全です。月10万通なら1か月で約100〜200MB、3年で約4〜7GBです。テキストだけなら、この規模は問題になりません。

気をつけるのは容量よりも読み取りの回数です。会話を開くたびに全件を読む作りにすると、件数が増えた分だけ遅くなり、従量課金のデータベースでは費用も比例します。会話ごとに新しい順で50件だけ取得し、上にスクロールしたら追加で取得する形(ページング)を、最初の版から入れてください。

保存の上限にも注意が要ります。Firestoreを使う場合、公式のクォータでは1ドキュメントの最大サイズが1MiB(1,048,576バイト)です。会話1件のドキュメントにメッセージを配列で持つ設計にすると、この上限に当たって書き込めなくなります。メッセージは1通=1ドキュメントで持つのが基本です。

画像・ファイルの添付は本文と分けて置く——署名付きURL、容量、ウイルス対策

添付ファイルをメッセージ本体と同じ場所に入れてはいけません。ファイルはオブジェクトストレージ(Amazon S3、Cloud Storage等)に置き、メッセージにはその場所への参照だけを持たせます。決めることは4つです。

1. アップロードの経路: クライアントから直接ストレージへ上げる(署名付きURLを発行する)。アプリケーションサーバーを経由させると、帯域とメモリを圧迫します
2. 閲覧の制御: ストレージを公開にせず、閲覧のたびに有効期限つきの署名付きURLを発行します。URLが外に出ても期限で切れます
3. 上限と形式: 1ファイルあたりの容量上限、受け付ける拡張子、画像の自動縮小。上限を決めないと、動画1本でストレージ費用が跳ねます
4. 安全性: アップロード後のウイルススキャン、実行可能ファイルの拒否、画像から位置情報(Exif)を落とすかどうか

オフショアの開発チームに任せる場合、ファイルの保管場所と開発環境のデータの扱いは契約前に決めておく論点です。この点は「オフショア開発のセキュリティ対策」の記事にまとめてあります。

ここまでの4つは、どれも後から足すと既存のデータを移し替える作業が伴います。既読の持ち方を途中で変えれば過去の既読は復元できませんし、添付をデータベースに入れてしまえば取り出す作業が発生する。最初の版で作らないのは構いませんが、どう作るかは最初に決めておく。これが、作り直しを避ける唯一の方法です。

グループチャットの設計と、通報・ブロック・不適切投稿への対応

1対1のチャットが動いたあと、次に要望が上がるのがグループです。そして同じ時期に、必ず起きるのがトラブルへの対応です。この2つをまとめて扱うのは、どちらも「参加者」という概念を軸に設計するからです。グループの作りを間違えると通報とブロックが載せられなくなり、通報の導線がないとグループは運用できません。順番としては、グループを作る前に通報の設計を済ませておくのが安全です。

グループは「会話」「参加者」「メッセージ」の3つに分ける——参加前の履歴をどう見せるか

1対1のチャットを、そのまま人数だけ増やして作ると行き詰まります。データの持ち方を、次の3つに分けてください。

この3分割ができていれば、参加前の履歴をどこまで見せるかが設定1つで切り替えられます。選択肢は3つです。参加日時より後だけ見せる(社内の業務グループに向く)、全履歴を見せる(公開のコミュニティに向く)、直近N件だけ見せる(折衷案)。最初にどれかに決め打ちして実装すると、後から変えるのが高くつきます。参加者に参加日時を持たせておけば、あとは絞り込みの条件を変えるだけです。

削除も同様です。メッセージを物理的に消すのではなく、状態を「削除」に変えて本文を返さない形(論理削除)にしておくと、通報の調査や、誤削除からの復旧ができます。

グループで壊れやすい3か所——メンション、退出後の見え方、大量参加時の通知

1つ目はメンションです。「@名前」で特定の人を呼ぶ機能を入れると、通知の条件が「全員」から「メンションされた人だけ」「全員」「ミュート中」の3系統に分かれます。メンションはメッセージ本文の中に埋め込むのではなく、メッセージに紐づく対象者リストとして別に持つのが確実です。本文の文字列を解析して通知先を決める作りにすると、名前の変更や同名のユーザーで破綻します。

2つ目は退出後の見え方です。退出した人が過去に書いたメッセージを残すのか消すのか、退出者の名前をどう表示するのか(「退出したユーザー」にするのか)を決めます。ここを決めずにリリースすると、退会処理を実装する段階で会話の表示が崩れます。

3つ目は大量参加時の通知です。参加者が100人を超えるグループでは、1通のメッセージが100件の通知になります。通知の送信をメッセージの保存と同じ処理の中で行うと、送信が遅くなり、失敗したときにメッセージまで巻き戻ります。通知は保存とは別の処理(キュー経由)に切り出してください。

通報・ブロック・不適切投稿への対応は最初の版から入れる

ユーザー同士がやり取りする機能を出す以上、誹謗中傷、個人情報の交換、外部サービスへの勧誘、不適切な画像の送信は必ず起きます。当社が相談を受けた案件でも、リリース後1か月以内に何らかの申し立てが発生したケースは珍しくありません。最低限、次の4つは初回リリースに含めてください。

加えて、自動の検知(NGワード、外部リンクの制限、同一文面の連投検知)を入れておくと、運営の負荷が大きく下がります。ただし自動検知は誤検知するため、必ず人が確認して覆せる導線とセットにしてください。

日本の制度の流れ——情報流通プラットフォーム対処法は対象外でも設計の参考になる

2025年4月1日に、情報流通プラットフォーム対処法(プロバイダ責任制限法を改正したもの。正式名称は「特定電気通信役務提供者の損害賠償責任の制限及び発信者情報の開示に関する法律の一部を改正する法律」)の一部が施行されました。総務省の説明によれば、大規模特定電気通信役務提供者に指定された事業者には、削除申出の窓口と手続を整備・公表すること、申出に対して一定期間内に判断と通知を行うこと、削除の基準を定めて公表することなどが義務づけられています。

この義務の対象は総務大臣が指定した大規模事業者であり、一般の事業会社が自社サービスに載せるチャット機能は対象外です。ただし、「通報の窓口を用意する」「判断の基準をあらかじめ決めて公表する」「期限を決めて対応し、結果を通知する」という考え方は、規模にかかわらず運用の設計として参考になります。対応の基準を作らないまま通報だけ受け付ける状態が、いちばん危険です。基準がなければ判断が担当者ごとにぶれ、後から説明できなくなります。ここを後回しにするのは失敗のもとです。

既製のチャットSDK・BaaSを使うか、自前で作るか——公式料金の実際と分岐

ここまでの論点を一通り決めると、次の問いが出てきます。「これ、全部作るのか」。答えは、作らなくてよい場合があります。既読・通知・グループ・通報・添付をひととおり備えたチャットSDKが複数あり、無料枠も広がっています。一方で、既製では成立しない要件もはっきりしています。判断は価格ではなく要件で行ってください。順番としては、先に既製で足りるかを確かめ、足りない部分だけを作るのが確実です。

主なサービスの料金と無料枠【2026年9月15日時点・各公式ページで確認】

以下は各社の公式料金ページを2026年9月15日に直接確認した値です。まとめサイトの数値は使っていません。料金は改定されるため、検討時は必ず公式ページで再確認してください。円換算は1USD=150円での目安です。

表から読み取れるのは、1,000MAU前後までは無料で試せること、5,000〜10,000MAU帯で月5万〜10万円程度になること、そしてTwilio Conversationsのように従量課金で小さく始められる型もあることです。自前で作った場合、この金額帯はエンジニア0.5人月にも届きません。規模が小さいうちは、既製のほうが安いのが実情です。

既製SDKで十分なケース4つ——作らないほうが早い条件

次の4つに当てはまるなら、既製のチャットSDKを使ってください。当社は開発を請ける側ですが、この条件では自前実装を勧めません。

1. チャットが主機能ではなく、付随機能である。本体のサービスに価値があり、チャットは連絡手段として付いていればよい場合
2. 要件が一般的なチャットの範囲に収まる。1対1とグループ、既読、通知、添付、通報。いずれも既製SDKの標準機能です
3. データの保管場所に制約がない。海外のサーバーにメッセージが保存されることが、社内規程や顧客との契約に抵触しない
4. MAUの見通しが1万人以下。この帯域では月額が自前の人件費を下回ります

とくに1つ目は重要です。本体の機能に集中すべき段階で、チャットの再接続やスケールの面倒を見ることになるのは、費用以前に時間の損失です。

自前で作るべきケース4つ——価格ではなく要件で決まる

一方、次に当てはまるなら自前で作る判断になります。

1. 自社データと深く結合する。会話に案件・注文・カルテといった自社の業務データを紐づけ、権限も業務側の役割で制御する必要がある場合。当社が担当した求人プラットフォームやマッチングサービスは、応募や案件の状態とメッセージが不可分でした
2. データを国内に置く必要がある。業界の規制、顧客との契約、社内規程による制約がある場合
3. チャットそのものが商品である。会話の体験が競争力になるなら、外部SDKの制約が事業の制約になります
4. MAUが大きく、既製の月額が人件費を上回る。数万MAU以上の規模では、この逆転が起きます

逆に言えば、この4つに当てはまらないのに自前を選んでいるなら、一度立ち止まってください。「自社で持ちたい」という理由だけで作り始めるのは、失敗のもとです。ノーコードツールで代替できないかを含めた作らない判断の考え方は「ノーコードとは」の記事、社内向けに作る場合の企画の進め方は「社内システム開発」の記事にまとめてあります。

費用と期間の考え方——人月×単価×期間に、チャット固有の3つを足す

自前で作る場合の費用は、システム開発の一般的な式(人月単価×人数×期間)で概算します。相場の全体像は「アプリ開発 費用 相場」の記事に譲り、ここではチャット固有の上乗せ要因を3つだけ挙げます。

• リアルタイム通信の方式: ポーリングなら通常のAPI開発と変わりません。WebSocketを選ぶと、接続管理・再接続・分散の設計と検証が加わり、実装だけでなくテストの工数が増えます
• 通知の検証: iOS・Android・Webのそれぞれで、フォアグラウンド・バックグラウンド・アプリ終了時の3状態を検証します。端末とOSのバージョンの組み合わせが効いてくる部分です
• モデレーションの運用画面: 通報の一覧、削除、凍結、監査ログ。ユーザー向けの画面とは別に、運営向けの画面が1つ増えると考えてください

期間は、1対1のテキストだけなら数週間、既読・通知・グループ・添付・通報まで含めると数か月が目安です。ここで大事なのは、全部を1回で出さないことです。次の章で、段階の分け方と外部チームへの任せ方を説明します。

外部チームに任せる場合の進め方——段階の分け方と、当社の位置づけ

自前で作ると決めて、社内に手が足りない場合は外部のチームに任せることになります。チャットは「作って終わり」の機能ではなく、リリース後に既読の表示、通知の頻度、通報への対応と、必ず手を入れ続ける機能です。この性質が、発注の仕方と体制の選び方を決めます。ここでは、渡すもの、段階の切り方、当社の位置づけ、そして向かない案件の順に書きます。

発注前に渡すと早い5点——見積もりのぶれはここで決まる

相見積もりの金額が会社によって大きく違うとき、原因の多くは前提のずれです。次の5点をA4で1〜2枚にまとめて渡すと、返ってくる金額の比較ができるようになります。

1. 用途と話す相手の関係: 3分類のどれか。1対1かグループか、グループなら最大人数
2. 即時性の要求と規模: 何秒までなら許容できるか。想定MAUと1日あたりの通数
3. 初回リリースに含める機能と、含めない機能: 含めないものを明記するのが重要です
4. 扱う情報とデータの保管場所の制約: 個人情報の有無、国内保管の要否、添付ファイルの種類
5. 既存システムとの接続点: 認証、ユーザー情報、業務データのどれと結合するか

要件定義そのものの進め方は「要件定義の進め方」の記事に、開発会社の選定軸は「システム開発会社の選び方」の記事にまとめてあります。

段階の分け方——4版に割ると承認も検証も通りやすい

この順に出すと、第1版で「使われない」ことが分かった場合に、残りを作らずに済みます。私が2018年からホーチミンで約100社の相談に乗ってきたなかで、チャット機能の失敗としていちばん多いのは、全部作ってから使われないと気づく型です。とくに第4版のWebSocketは、利用実態が見えてから判断する項目だと考えてください。

当社の位置づけ——求人プラットフォームとマッチングのメッセージ機能を担当してきた体制

当社(TALENTBASE VIETNAM)は、ホーチミンを拠点にベトナムのエンジニアで開発チームを組成するラボ型開発を提供しています。求人プラットフォーム(ATS)、介護業界向けのマッチングアプリ、金融系のマッチングサービスを担当してきており、いずれもメッセージ機能を含みます。業務データと結合したメッセージ機能を、段階的に育てていく進め方が中心です。

体制は、日本人PMまたはブリッジSEをフロントに置いてエンジニアを組み合わせるパターンAを推奨しており、最小構成は日本人PMフロント+2〜3人月で月額約80万円からです。単価は公開しており、実務3年目安で1,500USD(約22.5万円)、5年で2,000USD、10年以上・ブリッジSEで3,000USDです(1USD=150円換算目安)。グループが持つ2,000名以上のIT人財データベースから直接アサインするため、協力会社経由の仲介マージンが乗りません。

進め方は、打ち合わせ→アサイン(約1週間)→候補者面談(約1週間)→開始で、1名から、最短2週間で立ち上がります。増員は約1週間、縮小と交代は1か月単位です。品質は仕組みで担保しており、日本人PMの設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点を標準にしています。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。ラボ型そのものの仕組みは「ラボ型開発とは」の記事、担当した案件の詳細は「オフショア開発の事例」の記事に記載しています。

向く案件・向かない案件

向く案件は、自社データと結合するメッセージ機能を、リリース後も継続的に手を入れながら育てていく案件です。第1版から第4版まで段階的に出す進め方と、月額固定で専属チームを持つラボ型の相性がよいためです。

向かない案件は3つあります。1つ目は、既製のチャットSDKで要件が満たせる案件。この場合は作らないほうが早く、安く済みます。2つ目は、1対1のテキストだけを1回作って終わりにしたい案件。継続的な体制を組む意味が薄く、請負のほうが適しています。3つ目は、社内で優先順位を判断する担当を置けない案件です。チャットは使われ方を見ながら調整する機能なので、判断役がいないと稼働だけが消費されます。

さて、自社の案件はどちらでしょうか。判断に迷う場合は、第1版に何を含めるかだけでも書き出してみてください。そこが決まれば、既製で足りるかどうかも自然に見えてきます。

チャットシステムの作り方でよくある質問

チャット機能の相談で繰り返し聞かれる質問を5つにまとめました。社内の検討会や、開発会社への確認事項にそのままお使いください。

Q1. 既製のチャットSDKと自前実装、どちらが安いですか?

規模によって逆転します。1,000MAU前後までは無料枠で収まり、5,000〜10,000MAU帯でも各社の公式料金は月5万〜10万円程度です(2026年9月15日時点)。この金額はエンジニア0.5人月にも届かないため、小規模なら既製が安くなります。数万MAU以上か、自社データとの結合が深い場合に自前が有利になります。判断は価格表ではなく、要件の側から行ってください。

Q2. WebSocketは必須ですか?

必須ではありません。問い合わせチャットのように返信までに時間がかかる用途では、3〜10秒間隔のポーリングで体感は足ります。「リアルタイムでなければ」という要求は、多くの場合「入力中の表示」と「通知が即時に届くこと」に分解でき、後者はプッシュ通知で解決します。常時接続は再接続・分散・接続数の管理という運用を持ち込むため、必要になってから切り替える判断で構いません。

Q3. 社内チャットはSlackやTeamsで足りませんか?

多くの場合は足ります。自作を選ぶ理由が「ライセンス費用の削減」だけなら、開発費と保守費で回収できないことがほとんどです。作る理由になるのは、基幹システムのデータと会話をひも付ける必要がある場合と、外部のSaaSに出せない情報を扱う場合の2つです。この2つがないなら、既製のツールを使うほうが早く、確実です。

Q4. 既読機能はどこまで作るべきですか?

データの持ち方は最初に決め、表示するかどうかは後から決められる形にしてください。会話ごとに「その人が最後に読んだ位置」を1件持つ設計にしておけば、未読件数の計算も既読表示の切り替えも後から対応できます。逆に、メッセージ1通ごとに読んだ人を記録する設計にすると、グループで書き込みが人数×通数に膨らみます。なお、既読表示が返信のプレッシャーになる場合もあるため、出すかどうかは事業側の判断です。

Q5. 何人まで耐えられますか?

設計すべき数字はMAUではなく、同時接続のピークです。ポーリングなら通常のWeb APIと同じ考え方で拡張できます。WebSocketの場合は1台のサーバーが保持できる接続数で上限が決まり、複数台に分散するとサーバー間でメッセージを配る仕組みが必要になります。Firebaseを使う場合、公式の料金ページによれば無料のSparkプランは同時接続100まで、従量課金のBlazeプランは1データベースあたり20万まで。まず自社のピーク時同時接続数を見積もることが出発点。

まとめ: 先に7つを決め、既製で足りるかを確かめ、足りない分だけを段階的に作る

チャットシステムの作り方は、用途(ユーザー同士 / カスタマーサポート / AIチャットボット)、リアルタイム通信の方式、既読と通知、メッセージの保存とデータ量、画像・ファイルの添付、グループの設計、通報とブロックの7つを決めれば固まります。通信方式は4択で、最初の版はポーリングで足りることが多く、WebSocketは接続管理・再接続・分散という運用を持ち込みます。既読は「どこまで読んだか」の位置で持ち、添付は本文と分けてストレージに置く。通報とブロックは初回リリースから入れる。この4点が、作り直しを避ける具体的な勘所です。

次に、既製のチャットSDKで足りるかを確かめてください。2026年9月15日時点の各社公式ページでは、Sendbirdが1,000MAUまでのFree trial、Streamが1,000MAUまでのBuildプラン、Twilio Conversationsが200ユーザーまで無料、Firebaseも無料枠を公開しています。有料でも5,000〜10,000MAU帯で月5万〜10万円程度で、この金額はエンジニア0.5人月にも届きません。チャットが付随機能で、要件が一般的な範囲に収まり、データの保管場所に制約がないなら、作らないほうが早いというのが率直なところです。自前を選ぶ理由になるのは、自社データとの深い結合、国内保管の要件、チャット自体が商品であること、そして規模の4つです。

自前で作る場合は、第1版(1対1のテキストと通報の導線)、第2版(既読・通知・ブロック)、第3版(グループと添付)、第4版(WebSocketへの切り替え)の4段階に割ってください。全部を1回で出すと、見積もりが跳ねて承認が下りないか、使われないものまで作ることになります。費用相場の全体像はアプリ開発の費用相場、AIチャットボットを別に検討される場合はAIエージェント開発会社の選び方もあわせてご覧ください。現在の体制と要件をお聞かせいただければ、既製で足りるかどうかの判断と、自前で作る場合の概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。