自前配信プラットフォーム構想とUI/UX・選考運用・モデレーション方針
2026-03-22 会議 — リサーチレポート+AIアドバイス+要件定義付き
議事録パート
会議での議論と決定事項
自前プラットフォーム構想(マンション/ギルド)
既存PFに依存せず自前運用。選抜・招待で「面白い人」だけが配信。ランキングや民意投票に依存しない。
UI/UX要件
スワイプ必須(Tinder的)、3D不採用、2D検討余地あり、指向性フィルタ、音声・通話に近い体験。
アルゴリズムとデータ課題
YouTube的精密アルゴリズムにはビッグデータ必要。Twitter公開アルゴリズム参照の可能性。PFの「色」管理が重要。
既存事例・歴史的参照
ニコ生初期の「枠」、ツイキャス、Twitch、ストレスクラブの課題。
入居者募集・選考
スワイプで面接・選抜。リアルタイム短面談で面白い人を採用。
収益化よりアート志向
金儲け優先はコンテンツを歪める。コスト抑えた「アートとしてのWebサービス」。
AIリサーチパート
各トピックの調査結果と分析
用語ガイド — このレポートに出てくるサービス・技術
サーバー・インフラ
| 用語 | ざっくり説明 | 用途 |
|---|---|---|
| VPS | 仮想専用サーバー。月額数百円〜で借りられるレンタルサーバーの一種 | 配信サーバーの設置場所 |
| Hetzner | ドイツの格安VPS業者。月€4(約700円)〜でサーバーが借りられる | 配信サーバーのホスティング先 |
| CDN | 世界中に分散したキャッシュサーバー群。動画を視聴者の近くから配信し、遅延と負荷を軽減する | 大人数に同時配信するための高速化 |
| Bunny CDN | 格安CDNサービス。1GBあたり約3〜5円と安く、動画配信に適している | 配信映像を高速・安価に届ける |
| Cloudflare | CDN+セキュリティの大手サービス。無料プランあり。動画専用の「Stream」プランもある | CDN、DNS、SSL証明書 |
配信ソフト(OSS = オープンソースソフトウェア、無料で使える)
| 用語 | ざっくり説明 | 向いているケース |
|---|---|---|
| Owncast | 自前配信プラットフォームを1コマンドで構築できるオールインワンソフト。チャット機能も内蔵。Go言語製で軽量 | 最速で始めたい。2名体制に最適 |
| SRS | 中国発の軽量配信サーバー。複数の配信プロトコルに対応し、低遅延が強み | 低遅延が必要な場合、Phase 3での移行先 |
| OvenMediaEngine (OME) | 韓国発の高機能配信サーバー。大規模配信に強い | 将来的に大規模化する場合 |
| LiveKit | WebRTC特化の配信基盤。ビデオ通話やリアルタイム通信向け | 超低遅延が必要。ただし学習コスト高 |
| Janus | 汎用WebRTCサーバー。高機能だが設定が複雑 | 上級者向け。2名体制には不向き |
| OBS Studio | 配信者が使う無料の配信ソフト。画面やカメラの映像をサーバーに送る | 配信者側のツール(YouTubeでもおなじみ) |
配信プロトコル(映像の送り方)
| 用語 | ざっくり説明 | 遅延 |
|---|---|---|
| RTMP | OBSからサーバーに映像を送るための規格。YouTubeやTwitchでも使われている | —(送信用) |
| HLS | Apple規格の動画配信形式。ブラウザで再生できる。最も普及しているが遅延が大きい | 15〜30秒 |
| LL-HLS | HLSの低遅延版。細切れのデータを先読みして遅延を大幅に削減 | 2〜5秒 |
| WebRTC | ブラウザ同士でリアルタイム通信する技術。ビデオ通話等で使われる。最も低遅延 | 0.5秒以下 |
| SFU | WebRTCで1対多の配信を実現するサーバー構成。映像を効率的に中継する仕組み | —(構成の種類) |
| ABR | 回線速度に応じて画質を自動切替する仕組み。遅い回線では低画質、速い回線では高画質 | —(画質制御) |
フロントエンド(画面の作り方)
| 用語 | ざっくり説明 |
|---|---|
| scroll-snap | CSSの機能。スクロールが「カチッ」と次の画面にスナップする。TikTok風の縦スワイプUIを実現 |
| IntersectionObserver | 画面内に要素が表示されたかを検知するブラウザの仕組み。スワイプで表示された動画だけ再生する等に使う |
| Next.js | React(Web画面を作るライブラリ)ベースのフレームワーク。本格的なWebアプリを効率的に構築できる |
| Flutter | Google製のアプリ開発フレームワーク。1つのコードでiOS/Android/Web全対応 |
| OAuth | 「Googleでログイン」「Discordでログイン」等、外部サービスの認証を借りてログインする仕組み |
レコメンド(おすすめ機能)
| 用語 | ざっくり説明 |
|---|---|
| 協調フィルタリング | 「あなたと似た好みの人はコレも見てます」方式のおすすめ。Amazonの「この商品を買った人は〜」と同じ原理 |
| KNN(K近傍法) | データの中から「似ているもの」を探すシンプルなアルゴリズム。小規模に最適 |
| Surprise | Python用のレコメンドライブラリ。pip install一発で導入でき、小規模データに最適 |
| LightFM | タグ情報+行動データを組み合わせたハイブリッド推薦ライブラリ |
| SQLite | ファイル1つで動く超軽量データベース。サーバー設定不要で、小規模サービスに最適 |
| PostgreSQL | 本格的なデータベース。大規模・高機能だがセットアップが必要 |
| FastAPI | Python製の高速APIフレームワーク。バックエンドのAPI(データのやり取り窓口)を作るのに使う |
技術スタック・OSS比較
Owncast(自前配信サーバーソフト)が最適。1コマンドでインストールでき、VPS(レンタルサーバー)1台・月約1,000円で運用可能。
配信サーバーソフト(OSS)の比較
※いずれも無料で使えるオープンソースソフトウェア。詳細は上の「用語ガイド」参照。
段階的アプローチ
スワイプUI事例・実装
TikTok Live方式の縦スワイプが最も実績あり。WebRTC(ブラウザ間リアルタイム通信技術)またはLL-HLS(低遅延配信プロトコル)が必須。
配信プロトコル比較
実装方法
| プラットフォーム | ライブラリ |
|---|---|
| Web | CSS scroll-snap(スクロール制御)+ IntersectionObserver(表示検知) |
| Flutter | flutter_card_swiper |
| React Native | rn-swiper-list |
注意点
スキップ率を配信者に見せない設計が重要。
選抜制コミュニティ事例
排他性そのものを売りにしない。「中に入ったら何があるか」が最重要。初期45〜80人が最適。
成功・失敗事例
| 事例 | 結果 | 教訓 |
|---|---|---|
| Gmail | 成功 | 排他性+圧倒的実用価値 |
| Superhuman | 成功 | 厳選オンボーディング |
| mixi2 | 成功 | 5日で120万人 |
| Clubhouse | 失敗 | 排他性自体が製品に |
| Vero | 失敗 | 公約違反で崩壊 |
| Ello | 失敗 | コアバリュー不明確 |
ダンバー数
推奨選考プロセス
軽量レコメンド
初期はタグベース+手動キュレーションで十分。50〜200アイテムならSQLiteで全探索でも<1ms。
行動データ重み
段階的導入
構築・運用コスト
月1万円以下で同時500人規模まで対応可能。推奨はOwncast(配信ソフト)+ Hetzner VPS(格安レンタルサーバー)+ Bunny CDN(格安動画配信ネットワーク)で月約2,500〜4,000円。
コスト比較
構成詳細
| 構成 | 月額 | 同時接続 | 内容 |
|---|---|---|---|
| A | 1,000〜2,000円 | 50〜100人 | Owncast(配信ソフト)+ Hetzner(格安サーバー) |
| B | 3,000〜5,000円 | 300〜500人 | 構成A + Bunny CDN(動画配信ネットワーク) |
| C | 4,000〜4,500円 | 500〜1,000人 | +Cloudflare Pro |
AIアドバイス&要件定義パート
実現可能性評価・要件定義・アーキテクチャ
実現可能性評価
実現可能性は高い。2名体制・月3,000円で500人規模まで対応可能。技術的ハードルは低く、Owncast 1台で半日で最低限動く。
強み
- 技術的ハードル低い(Owncast 1台で即稼働)
- 月額コスト極めて安い(月3,000〜5,000円で500人)
- 既存PFへの不満が追い風
- shoboboのYouTube66万人から人材発掘パイプラインあり
リスク
| リスク | 深刻度 | 対策 |
|---|---|---|
| 排他性が製品になる | 高 | 「中に入ったら何が楽しいか」を明確に |
| スワイプ+配信の技術的複雑さ | 中 | Phase 1ではスワイプ後回し |
| 配信者確保の鶏と卵 | 中 | 最初の10人は人脈から直接声がけ |
| 2名での障害対応 | 低 | 趣味サービスなので許容度高い |
最大のアドバイス
「作りすぎない」こと。技術より「最初の10人の配信者」の質が9割を決める。
- Week 1: Owncast+VPSで配信開始。知り合い5〜10人で始める
- Week 2-4: 使って分かった「本当に必要な機能」だけ追加
- Month 2-3: データに基づいて必要なら本格開発
ざっくり要件定義
Phase 1 MVP(2〜3日)
| 機能 | 実装方法 | 工数 |
|---|---|---|
| ライブ配信 | Owncast標準 | 設定のみ |
| チャット | Owncast標準 | 設定のみ |
| 配信者一覧 | HTML/CSS | 1日 |
| プロフィール | JSON+静的ページ | 1日 |
| 招待制 | ストリームキー管理 | 半日 |
Phase 2(1〜2週間)
| 機能 | 実装方法 | 工数 |
|---|---|---|
| スワイプUI | CSS scroll-snap(スクロール制御) | 2〜3日 |
| 複数同時配信 | マルチストリーム | 2〜3日 |
| タグフィルタ | JS | 1日 |
| 投げ銭 | Stripe連携(決済サービス) | 2〜3日 |
Phase 3(1〜2ヶ月)
| 機能 | 実装方法 | 工数 |
|---|---|---|
| ユーザー認証 | OAuth(Google/Discordでログイン) | 3〜5日 |
| レコメンド | Surprise(推薦ライブラリ)/自前 | 2〜3日 |
| 選考フロー | Webフォーム+管理画面 | 3〜5日 |
| WebRTC移行 | SRS/LiveKit(低遅延配信サーバー) | 1〜2週間 |
システムアーキテクチャ
全体像
技術スタック
| レイヤー | Phase 1 | Phase 2-3 |
|---|---|---|
| 配信サーバー | Owncast(オールインワン配信ソフト) | SRS/OME(高機能配信サーバー) |
| フロント(画面) | HTML/CSS/JS | Next.js(Reactベースのフレームワーク) |
| バックエンド(API) | 不要 | FastAPI(Python)/ Node.js |
| DB(データベース) | JSON/SQLite(軽量) | PostgreSQL(本格) |
| CDN(配信高速化) | Cloudflare Free | Bunny CDN(格安) |
| 認証(ログイン) | Basic認証(パスワード) | OAuth 2.0(Google/Discordログイン) |
コスト推移
企画概要パート
このアプリは何か・スケーリング・コメント・ビジュアルの方向性
これは何のアプリ?
「面白い人だけが配信できる、招待制のライブ配信アプリ」 — ニコ生 × Tinder × 会員制マンション
既存サービスとの違い
| 観点 | YouTube Live / Twitch | このアプリ |
|---|---|---|
| 誰が配信できるか | 誰でも | 運営が選んだ人だけ(ヘッドハンティング・招待制) |
| 配信の見つけ方 | 検索・ランキング | スワイプ(TikTokのように上下に切り替え) |
| 評価の仕組み | 登録者数・投げ銭ランキング | ランキングなし。金で目立つのではなく面白さで選ばれる |
| 映像 | 実写(顔出し)が主流 | 2Dビジュアル(ドット絵・アバター等) |
| 目的 | 収益化・集客 | アートとしてのWebサービス。趣味プロジェクト |
| 運営コスト | — | 月3,000〜5,000円(サーバー代のみ) |
「マンション(ギルド)」の比喩
このプラットフォームはマンションに例えられています。
- 大家(運営)が入居者(配信者)を審査して選ぶ
- 入居者はそれぞれの「部屋」で配信する
- 視聴者はエレベーターに乗るようにスワイプで部屋を移動
- 大家がマンションの雰囲気(色)を守る — 治安とクオリティの維持
- 住民同士の化学反応(コラボ・掛け合い)が生まれる場を作る
リアルタイム配信が可能
| 段階 | 配信方式 | 遅延 | 体験イメージ |
|---|---|---|---|
| Phase 1 | Owncast(HLS配信) | 約5〜15秒 | YouTube Liveと同じ感覚 |
| Phase 3 | WebRTC(リアルタイム通信) | 0.5秒以下 | ビデオ通話と同じ感覚。配信者と視聴者の掛け合いが可能 |
自動スケーリング
CDN(動画配信ネットワーク)を入れた時点で視聴者側は自動スケーリング。視聴者が100人でも1万人でもサーバーの負荷は変わらない。
仕組み
視聴者数別コスト(自動スケール時)
配信者が同時に増えた場合は?
| 方式 | 難易度 | 説明 |
|---|---|---|
| マネージドサービス(Amazon IVS等) | 低 | 完全自動。何もしなくていい。ただしコスト高め |
| Docker + クラウド自動スケール | 中 | SRSをコンテナ化し、Fly.io等で負荷に応じて自動増減。月数千円で実現可能 |
| Kubernetes | 高 | 本格的だが2名体制にはオーバー |
ポイント: 配信者10人程度ならサーバー1台で余裕。気にすべきは「同時に何人が配信するか」だけで、視聴者のスケーリングはCDNが勝手にやってくれます。
コメント表示方式
視聴者画面にはリアルタイムでコメントが表示される。配信者のチェックは低頻度(30分に1回程度)でOK、スパチャは優先対応。
表示方式の選択肢
比較
| 方式 | イメージ | 向いている場面 | 実装 |
|---|---|---|---|
| ニコ生型 | 画面上を右→左にコメントが流れる | ツッコミ・一体感重視。ライブ感が最も強い | Canvas / CSSアニメーション(1〜2日) |
| チャット欄型 | 画面右 or 下にチャット欄 | 会話・議論向き | Owncast標準搭載(設定のみ) |
| ハイブリッド | 普段はチャット欄、スパチャ・ハイライトだけ画面上に流す | バランス型 | 両方を組み合わせ(2〜3日) |
2Dビジュアル — 画面に何を映すか
配信者の映像は実写ではなく2Dの何かを表示する。「何を映すか」がプラットフォームの個性を決める最大の要素。
4つの方向性
案1: Live2Dアバター(VTuber方式)
配信者の表情・動きに連動して2Dキャラが動く。
| ツール | VTube Studio(無料)、nizima LIVE、Live2D Cubism |
| 制作コスト | 1体 3〜10万円(外注)/ 自作なら無料 |
| メリット | 顔出し不要で配信ハードルが下がる。キャラの個性が出る |
| デメリット | 配信者全員にモデルが必要。統一感を出すならテンプレ化が要る |
| マンションとの相性 | 入居者にアバターを「支給」する=「制服」的な統一感。PFの「色」を作りやすい |
案2: イラスト一枚絵 + 音声波形
静止画のキャラ絵が表示され、話すと音声に連動して波形やエフェクトが動く。ラジオ配信的。
| ツール | OBSのオーディオビジュアライザープラグイン |
| 制作コスト | イラスト1枚 5,000〜3万円(外注) |
| メリット | 制作コスト最安。配信者の負担ゼロ(OBS設定だけ) |
| デメリット | 動きが少ない。映像としての面白みは弱い |
| マンションとの相性 | 全員同じフォーマットで統一しやすい。「ラジオ局」的な世界観 |
案3: ドット絵マンション(おすすめ)
レトロゲーム風のドットキャラが動く。マンション断面図の中で配信。
| ツール | Aseprite(ドット絵制作ソフト、約2,000円) |
| 制作コスト | 1体あたり数時間で自作可能。量産しやすい |
| メリット | 統一感が自然に出る。「ゲームの中にいる」感覚。唯一無二の世界観 |
| デメリット | 表情の表現に限界。声と動きの連動は簡易的 |
| マンションとの相性 | ⭐ 最高。断面図で部屋が見え、スワイプ=エレベーター移動の演出が可能 |
- 画面にマンションの断面図が表示される
- 各部屋に配信者のドットキャラがいる
- スワイプで部屋を移動(エレベーター的な演出)
- 配信者が話すとキャラがアニメーションする(口パク・ジェスチャー)
- コメントはニコ生型で部屋の中を流れる
- プラットフォーム全体が一つの作品になる
案4: ジェネラティブアート(抽象ビジュアル)
配信者の声に反応して幾何学模様や色が変化する。固定キャラなし。
| ツール | p5.js、Three.js、TouchDesigner |
| 制作コスト | プログラミングで自作(無料) |
| メリット | 「アートとしてのWebサービス」コンセプトに最も合致。唯一無二 |
| デメリット | 配信者の個性が出にくい。音声メインの体験になる |
| マンションとの相性 | 部屋ごとに異なるビジュアルテーマ。「美術館のインスタレーション」的 |
コメント対応方針
30分に1回程度の低頻度チェック。スパチャは優先対応。配信者が常時監視不要で合意。