← 開発ノート一覧
G
PRODUCT NOTE / FEATURE PRD
グループチャット
みんなで話す部屋に、AI を呼べる。
この文書は「どう使うか」ではなく、なぜ・誰のために・どんな判断で作ったかを記録した開発ノートです。
TL;DR
ひとことで
グループチャットは、複数の人が招待制のルームに集まってリアルタイムに会話でき、@チュッぽ と書くと AI をその場に呼び出せる WebSocket ベースのチャットです。リアクション絵文字・@メンションに対応し、AI 参加はルーム単位で ON/OFF できます。
Problem
背景・解きたい課題
設計意図を明記した文書は残っていないため、実装から読み取れる範囲での再構成。背景は推測
- 1 対 1 の AI から、みんなの AI へ — 個人用 AI アシスタント「チュッぽ」を、複数人が同席する場でも使いたい。
- 手軽に立てて共有したい — 6 桁のルームコードと招待リンクで、身内とすぐに部屋を作って集まれるようにしたい。
- AI が会話の主役を奪わない — AI は常駐ではなく「呼ばれたら答える」存在にしたい。
Who
ターゲットユーザー
プライマリ
運営者本人と、招待された知人。非ゲストは許可リストのメールのみ、ゲストは招待リンクから参加できる、クローズドな使い方が前提。
主なユースケース
- 身内で部屋を立ててリアルタイム会話
@チュッぽ で AI に質問・相談- リアクションと @メンションで軽くやりとり
Solution & Scope
解決策とスコープ
コア機能（In scope）
- WebSocket によるリアルタイム配信・在室リスト・入退室通知
- 6 桁ルームコード＋招待リンクで参加
@チュッぽ で AI をその場に呼ぶ（ルーム単位 ON/OFF）- リアクション絵文字のトグル
- @メンション補完・色分けハイライト
- 直近履歴の復元・表示名/アバター選択
やらないこと（Non-goals）
- 不特定多数への公開・大規模チャット
- 水平スケール（現状は単一プロセス前提）
- 常駐で発言し続ける AI
Success Metrics
成功指標（KPI）
「気軽に立てて、AI を含めて会話が回る」状態かを見る。数値は目標仮置き
2+ 人
1 ルームの同時接続
（複数人で使われるか）
Decision Log
主要な意思決定ログ
実装から読み取れる判断を、決定・仮説・結果の 3 点で残す。理由は実装から再構成
AI AI は常駐させず、@メンションで呼ばれたら答える
- DECISION
- 本文に
@チュッぽ が含まれ、かつルームの AI が有効なときだけ、直近の会話履歴を渡して AI が応答する。AI 参加はルーム単位で切り替えられる。
- WHY / 仮説
- 会話の主役は人間で、AI は割り込まず「呼ばれて助ける」存在であるべき。常時発言する AI は会話を壊す、と考えた（"育てる AI" の思想とも一致）。
- RESULT
- 人間同士の会話を保ちつつ、必要なときだけ AI を招ける自然な体験に。
privacy 表示名はメールアドレスを露出させない優先順位で決める
- DECISION
- 表示名を「指定名 → 認証トークンの名前 → メールのローカル部」の優先順位で決定する。
- WHY / 仮説
- 招待制でもメールアドレスがそのまま他人に見えるのは避けたい。名乗りを尊重しつつ、最低限の匿名性を守るべきだと考えた。
- RESULT
- 参加者のメールアドレスを晒さずに、分かりやすい表示名で会話できる。
scale ルーム管理をプロセス内メモリで持ち、単一プロセス前提に割り切る
- DECISION
- 接続・在室・ブロードキャストをプロセス内のメモリ（RoomManager）で管理し、共有バス（Redis 等）は導入しない。
- WHY / 仮説
- クローズドで小規模な用途では、水平スケールより実装のシンプルさと素早い提供を優先すべき。過剰な分散設計は個人開発の負担になる、と判断した。
- RESULT
- 短期間で機能を実現。スケールが必要になったら共有バス化する、という宿題を Non-goal として明示している。
Milestones
これまでの歩み
リリース2026-06-06WebSocket ベースのグループチャットを公開。@チュッぽ での AI 参加・リアクション・@メンションに対応
Roadmap / Open Questions
これから
- スケールが必要になった際の共有バス（Redis 等）への移行。
- AI の応答品質・ツール連携の強化。
- ルーム管理（権限・退室・削除）の整理。
未決事項：公開範囲の広げ方、ルームコードの衝突対策、AI 利用コストの上限設計。