1.解決したい課題
ライブ配信のコメント欄を眺めていると、しばしば次のような同期現象が観察される:
- 配信終了直後、30 秒以内に「おつー」「おつかれ」「乙」が次々と飛ぶ → 文化的伝染。
- 配信中に何かが起きた直後、5 秒以内に「うおお」「すげー」が複数ユーザーから同時に上がる → 歓声同期。
- 誰かのコメントに反応して、同じ語が「リプライ的に」連鎖する → 文脈伝染。
こうした現象は配信のハイライトを判定する強い手掛かりだが、検出するには「同じキーが」「短時間内に」「異なる複数ユーザーから」という 3 条件を組み合わせて判定する必要がある。さらに「ｗ／w／笑」「！／!」のような表記揺れを吸収しないと、本来同じ語が別キーとして扱われてしまう。
本手法は、これらを軽量な sliding window 1 パスで処理するためのアルゴリズムである。
2.手法の概要
処理は以下の 3 段階で構成される:
- 正規化（Normalization）: コメント本文を「視覚的に同じものを同じキー」に変換する。
- キー別 sliding window 管理: 正規化キーごとに、現在進行中のバースト窓（firstAt, lastAt, users, count）を保持する。新しいコメントが来るたび、そのキーの窓が「閉じる」べきか「延長」されるべきかを判定する。
- バースト判定: 窓が閉じる際に、含まれるユニークユーザー数がしきい値以上ならバーストとして出力する。
パラメータは windowMs（窓幅、ms）と minDistinctUsers（必要ユニークユーザー数）の 2 つ。これを (30000, 3) にすれば「コメ伝染」、(5000, 3) にすれば「コメ被り瞬間」の検出に切り替わる。
3.アルゴリズム詳細
3-1. 正規化規則
本手法における文字列正規化は、視覚的同等性を基準に以下を順に適用する:
- 全角 W／ｗ → 半角 w（日本語ライブの「笑い」表現の表記揺れ対策）
- 全文字を 小文字に統一
- 句読点・記号（
!?！？。、,．＋空白）を除去 - 長さ 0 ならばノイズとして除外
- ASCII 1 文字（"a" "1" など）はノイズとして除外（漢字・ひらがな・カタカナ・絵文字 1 字は通す）
これにより、「ｗｗｗ」「www」「WWW」「W W W」「w!w!」が全て www という単一キーに帰着する。
3-2. 入力データ
// 1 件あたりの最低限のフィールド
{
capturedAt: 1714532400000, // Unix エポックミリ秒
userId: "user-12345", // 文字列の安定 ID（数値・匿名 184 ハッシュも可）
text: "おつー" // 正規化対象の本文
}3-3. sliding window 管理
各正規化キー k に対して、現在進行中の窓を以下の構造で保持する:
{
firstAt: 1714532400000, // 窓の最初のコメント時刻
lastAt: 1714532411000, // 窓の最後のコメント時刻
users: Set { "u1", "u2", "u3" },
commentCount: 5
}新しいコメント (at, uid, key) が到着すると、キー key の窓を引き、次のいずれかの処理を行う:
- 窓が存在しない → 新しい窓を開く（firstAt = lastAt = at, users = {uid}, count = 1）。
- 窓が存在し、at − firstAt ≤ windowMs → 窓を延長（lastAt = at, users.add(uid), count++）。
- 窓が存在するが、at − firstAt > windowMs → 既存窓を「閉じて」判定し、新しい窓に置き換える。
3-4. バースト判定
窓が「閉じる」タイミングで、users.size ≥ minDistinctUsers ならバーストとして出力する:
{
text: "おつー",
firstAt: 1714532400000,
lastAt: 1714532411000,
userCount: 5, // ユニークユーザー数（重要指標）
commentCount: 7 // 全コメント数（同一ユーザーの連投も含む）
}処理ループ終了時に未閉鎖の窓があれば、最後にまとめて判定する（flush）。
出力は userCount 降順、同点ならば commentCount 降順でソートする。
4.参考実装（JavaScript / 純粋関数）
以下は本拡張機能で実際に使用している実装の抜粋である（src/lib/commentEchoDetector.js）。
/** 視覚的同等性に基づく正規化 */
export function normalizeForEcho(text) {
let s = String(text == null ? '' : text);
s = s.replace(/[Ｗｗ]/g, 'w');
s = s.toLowerCase();
s = s.replace(/[!?！？。、,．\s]/g, '');
s = s.trim();
if (s.length === 0) return '';
if (s.length === 1 && s.charCodeAt(0) < 128) return '';
return s;
}
/** sliding window によるバースト検出（共通実装） */
function detectClusters(comments, cfg) {
const items = collectKeys(comments);
if (items.length === 0) return [];
const open = new Map();
const bursts = [];
for (const it of items) {
const cur = open.get(it.key);
if (cur && it.at - cur.firstAt <= cfg.windowMs) {
// 窓を延長
cur.lastAt = it.at;
cur.users.add(it.uid);
cur.commentCount += 1;
} else {
// 窓を閉じてバースト判定
if (cur && cur.users.size >= cfg.minDistinctUsers) {
bursts.push({
text: it.key,
firstAt: cur.firstAt,
lastAt: cur.lastAt,
userCount: cur.users.size,
commentCount: cur.commentCount
});
}
// 新しい窓を開始
open.set(it.key, {
firstAt: it.at, lastAt: it.at,
users: new Set([it.uid]),
commentCount: 1
});
}
}
// 残りの窓を flush
for (const [, cur] of open) {
if (cur.users.size >= cfg.minDistinctUsers) {
bursts.push({
text: cur.key,
firstAt: cur.firstAt, lastAt: cur.lastAt,
userCount: cur.users.size,
commentCount: cur.commentCount
});
}
}
bursts.sort((a, b) =>
b.userCount - a.userCount || b.commentCount - a.commentCount
);
return bursts;
}
/** L1 コメ伝染（30 秒窓 / 3 ユーザー以上） */
export function detectCommentPropagation(comments, opts = {}) {
return detectClusters(comments, {
windowMs: opts.windowMs ?? 30_000,
minDistinctUsers: opts.minDistinctUsers ?? 3
});
}
/** L5 コメ被り瞬間（5 秒窓 / 3 ユーザー以上） */
export function detectCommentSyncBursts(comments, opts = {}) {
return detectClusters(comments, {
windowMs: opts.windowMs ?? 5_000,
minDistinctUsers: opts.minDistinctUsers ?? 3
});
}5.なぜこの設計なのか
5-1. なぜキー別の sliding window なのか
「30 秒以内に同じ語が複数ユーザーから出た」を判定するナイーブな実装は O(n²) になる（各コメントから過去 30 秒のコメントを全部見る）。本手法はキー別に状態を保持することで、各コメントの処理を O(1) 償却に抑えている。
5-2. なぜ「窓を閉じてから判定」なのか
窓に新しいコメントが追加されるたびに判定してしまうと、同じバーストが何度もカウントされる。窓を閉じる瞬間に 1 度だけ判定することで、各バーストが正確に 1 回だけ出力されることが保証される。
5-3. なぜ ASCII 1 文字を弾くのか
"a", "1", "?" のような 1 文字 ASCII は、誤打や記号として偶然多発しやすく、伝染現象として見ると noise が支配的になる。しかし、漢字 1 字（例: 「神」「乙」）は意味のある反応として頻出するため、ASCII 1 文字のみを除外し CJK 1 文字は残す運用にしている。
5-4. なぜユニークユーザー数で評価するのか
同じユーザーが連投した場合のコメント数をいくら増やしても「伝染」「同期」の証拠にはならない。異なるユーザーが何人同じ反応をしたかが本質的な指標である。
6.計算量と運用コスト
7.既知の限界と拡張可能性
7-1. 限界
- 表記揺れの吸収範囲は正規化規則で固定: より高度な表記揺れ（「おつー／おつかれ／お疲れ様」など意味は同じだが文字列が違う）は捉えられない。意味マッチを入れるなら追加で形態素解析や word embedding が必要。
- 窓の境界依存: 30 秒窓の場合、ちょうど 30 秒の境界をまたぐ伝染は 2 つに分割される可能性がある。実用上はしきい値の設定で吸収する想定。
7-2. 拡張可能性
- multiscale 検出: 同じ実装を
(5s, 3)(30s, 3)(120s, 5)で並列に走らせ、複数粒度のバーストを同時取得する。 - 意味マッチへの拡張: 正規化キーを文字列ではなく word embedding のクラスタ ID にする。
- 配信者反応との相関: バーストの 5 ～ 10 秒前に配信者がどんな発言・動作をしたかを抽出し、伝染の引き金イベントを推定する。
8.関連する既知技術（先行技術）
8-1. Burst Detection in Streams
Kleinberg の "Bursty and Hierarchical Structure in Streams" (KDD 2002) など、時系列イベント流からのバースト検出は古くからある。本手法はそれをキーごとに分離して sliding window で軽量化した特殊形。
8-2. Trending Topics Algorithms
Twitter のトレンド検出に使われるような頻度ベース集計手法。本手法はリアルタイム性とユニークユーザー数による厳格な閾値判定を組み合わせた点が異なる。
8-3. Spam Detection (Echo Spam)
同一文字列の連投をスパムとして検出する手法は古くから存在するが、それらは同一ユーザーの繰り返しを狙うのが主流。本手法は逆に「異なるユーザーが同じ文字列を出す」現象を検出する点が決定的に異なる。
8-4. ライブチャット可視化ツール
Twitch や YouTube Live のサードパーティ拡張・ボット（Chatty, Nightbot 等）には、頻出語のフィルタリング機能はあるが、「短時間内の異なるユーザーからの同期発火」を抽出してバーストイベント化する公知の実装例は、本記事執筆時点で著者は確認していない。
9.本記事の位置づけ・ライセンス
本記事は、Chrome 拡張機能『君斗りんくの追憶のきらめき』内で 2026 年 4 月 30 日（バージョン 0.1.25）に投入された commentEchoDetector.js モジュールの設計思想と実装を、2026 年 5 月 1 日付で公開するものである。
公開目的:
- ライブチャット解析を行う他の開発者・研究者が同じ手法を自由に応用できるようにする
- 本手法に関する先行技術 (prior art) として、本記事の公開日時を公的記録に残す（防御的公開／defensive publication）
参考実装は MIT ライセンス、本記事文章は CC BY 4.0 のもとで自由に複製・引用可。
https://tsuioku-no-kirameki.com/articles/comment-echo-detection.html