日本語の一段落を「1単語」と数えてしまう単語カウント

自己紹介の入力欄が「2単語以上」でないと次に進めない。日本語のユーザーが「東京に住んでいます」と打つ。完全な一文だ。なのに、はじかれる。カウントは1だった。ユーザーは何も間違えていない。間違えたのはゲートのほうだ。

これはomiで見つけたバグそのままで、コードは len(transcript.split()) >= 2。スペースで split すると、スペースを持たないテキストは1要素で返る。だから日本語の回答はその奥のチェックに永遠に届かず、質問は「未回答」のまま固まる。言語が変わっただけで、動いていた機能が静かに止まる。

僕が集めた97件のCJKバグのうち、この種類は2件と少ない。ただ、1件ごとにCJKユーザー全員に対して機能が黙って壊れる。もう1つはemdashで、エディタのフッタの単語数と読了時間がスペース分割のカウンタ由来だった。結果、2,000文字の日本語の下書きが「1 word · 1 min read」と表示される。一覧はCJK failure corpusに置いてある。

# スペース分割はCJKを分割しない

単語カウンタはたいてい同じ書き出しから始まる。

const words = text.trim().split(/\s+/).filter(Boolean).length;

英語は語のあいだにスペースを置くから、これで動く。日本語・中国語・韓国語は置かない。区切る対象がないので、ひと続きがまるごと1トークンになる。

"I live in Tokyo".split(/\s+/).length;   // 4
"東京に住んでいます".split(/\s+/).length;  // 1  ← 文まるごと

この失敗は英語のレビューでは見えず、日本語では全面的だ。長さに関係なくCJKの文章は1単語。読了ラベルは「1分」に潰れ、最小文字数のバリデーションはスカスカの回答を通し、中身のある回答をはじく。守りたかったはずのユーザーを、そのゲートが締め出す。

# 直し方その1: CJKの文字を別枠で数える

読了時間の見積もりに、本物の単語分割は要らない。要るのは「読むのにどれくらいかかるか」を追える数字で、CJKはだいたい一定の毎分文字数で読める。だから2つの体系をそれぞれの流儀で数えて足す。英字は空白区切りの単語、CJKは文字。

function estimateMinutes(text) {
  const cjk = /[\p{Script=Han}\p{Script=Hiragana}\p{Script=Katakana}\p{Script=Hangul}]/gu;
  const cjkChars = (text.match(cjk) ?? []).length;
  const latinWords = text.replace(cjk, " ").split(/\s+/).filter(Boolean).length;
  return Math.max(1, Math.round(latinWords / 220 + cjkChars / 500));
}

いま読んでいるこのページの読了時間も、まさにこの形から出している。英単語を毎分220語、CJKを毎分500文字。これは「単語」数ではないし、そのふりもしていない。読む労力の正直な見積もりで、ラベルが本当に約束しているのはそこだ。

# 直し方その2: Intl.Segmenter の word 粒度で区切る

本当に語が要るとき、たとえば実際のカウント、トークナイザ、検索なら、Intl.Segmenter の word 粒度がランタイムの辞書でCJKを語らしき単位に割る。

function countWords(text, locale) {
  const seg = new Intl.Segmenter(locale, { granularity: "word" });
  let n = 0;
  for (const s of seg.segment(text)) if (s.isWordLike) n += 1;
  return n;
}

countWords("東京に住んでいます", "ja"); // 1ではなく、語らしき4前後

isWordLike が true のセグメントだけ残せば、句読点や空白は落ちる。Node 16以降と最近のブラウザで動く。代わりにロケール依存で辞書ベースなので、文字数カウントより重く、日本語の出力は近似になる。その限界は最後に書く。

# どの直し方をどこに使うか

これらのバグが実際に刺さる読了時間と最小文字数ゲートでは、文字数カウントは妥協ではなく、むしろ正解だ。語を語として数えたいときだけ Intl.Segmenter に手を伸ばせばいい。

# どこで止まるか

「単語」は日本語では曖昧な概念だ。Intl.Segmenter でさえ「住んでいます」の切れ目について人間の直感とも他のトークナイザとも食い違う。唯一の正解がないからで、分割はモデルであって事実ではない。だから読了時間の見積もりでは、文字を数えるほうが単に簡単なだけでなく、答えのない問いを迂回できる。自分の機能が本当に必要としているのはどっちかを見極めればいい。長さゲートが知りたいのは「中身が足りているか」で、それは文字数が直接答える。本物の単語数が要るときだけ segmenter を出す。しかもその数字は、自信ありげな顔をした近似だ。近い症状として、変換中に発火するEnterやおかしな位置で折り返す行がある。どれも同じ形をしている。英語では正しく、日本語のキーボードを念頭に読まれたことが一度もなかったコードだ。