「ＴＯＤＯ」と「todo」を同じように探すには？サイト内検索で学ぶ文字の正規化

全角・半角や英字の大文字・小文字をそろえると、検索はどう変わる？Appli Parkのサイト内検索を使い、NFKC正規化と部分一致の流れ、吸収できる表記ゆれとできない表記ゆれを図と実測で解説します。

CONTENTSこの記事の目次7項目

サイト内検索の処理へ、同じつもりで入力した「ＴＯＤＯ」「Todo」「TO DO」を渡してみました。検索対象を「todo」だけに固定すると、前の2つは一致し、途中に空白が入ったTO DOは不一致です。人には似た言葉でも、プログラムが同じように扱うかどうかは、比較前の処理で決まります。

Appli Parkでは、入力と検索対象の両方にNFKC正規化と小文字化を行い、文字列が含まれているかを調べています。何でも賢く推測してくれる検索ではなく、対応する表記ゆれの範囲を決めた仕組みです。

正規化は、比較するための形をそろえる処理

Unicodeには、見た目や用途が近くても異なる文字として表されるものがあります。NFKCは互換性のある表現を分解・再構成してそろえる正規化形式です。全角英数字を半角へそろえたり、半角カタカナを通常のカタカナへそろえたりする例が、その一部です。

ただし、NFKCだけでTODOがtodoになるわけではありません。英字の大文字・小文字をそろえるのは、その後のtoLocaleLowerCase('ja')の役割です。正規化と小文字化は、連続して使っていても別の処理です。

入力にはtrim()を適用し、前後の空白を除いてからNFKC正規化と小文字化を行います。空になった検索語には結果を返しません。検索対象の各文字列にもNFKC正規化と小文字化を行い、includes()で検索語が含まれるかを調べます。

対象側を変換しないと、入力をtodoにそろえても、対象にＴＯＤＯと書かれている場合を拾えません。今回の検証では対象側が全角の場合も確認しました。表示用のタイトル自体を書き換えるのではなく、比較するときに変換しています。

記事の増減で結果が変わらないよう、2026年9月12日のsearchSiteを小さな作例データへ実行しました。各行の対象文字列だけを記事タイトルへ入れ、他の検索項目は空にしています。公開サイト全体の検索件数ではありません。

検索語を空白で分割して、それぞれを探す処理はありません。「todo 共有」と入力した場合は、その連続した文字列を探します。タイトルにtodo、タグに共有があっても、別項目の一致を組み合わせるAND検索にはなりません。

記事で検索しているのはタイトル、概要、カテゴリー名、タグ名、特集名です。記事本文を調べる処理はなく、本文だけにある言葉は対象外です。アプリでは名前、短い名前、説明、補足、関連キーワードなどを調べます。

たとえばアプリの関連キーワードへ「珈琲」が登録されていれば、珈琲という入力でそのアプリを見つけられます。これはNFKCが珈琲をコーヒーへ翻訳したのではなく、運営側が用意した検索項目に同じ文字列があるためです。今回の固定データ検証でも、関連キーワードに登録した語が一致することを確認しました。

NFKCは全角・半角専用の変換ではありません。今回の確認では「①」も「1」へ変わりました。検索の入口では便利でも、丸付き番号と通常の数字の違いを残したい場面には注意が必要です。Unicodeの資料でも、意味のある区別まで失う場合があるため、任意の文章へ無条件に適用しないよう説明されています。

この検索では比較用の文字列を変換し、表示するタイトルや保存済みの記事はそのまま使います。「検索では同じように見つける」と「原文を同じ文字へ上書きする」を分けると、探しやすさと元の表現を両立しやすくなります。

この仕組みなら、「全角・半角や英字の大小文字をそろえて、アプリの説明と記事のタイトル・概要などを部分一致で探します。本文全文、同義語、誤字の自動補正には対応していません」と説明できます。何が見つからないかまで言葉にできると、検索の「わかったつもり」から一歩進めます。

Unicode Standard Annex #15「Unicode Normalization Forms」（Unicode 17.0.0）。NFKCの定義と、失われる区別に関する説明を確認。
MDN Web Docs「String.prototype.normalize()」。正規化形式と互換文字の変換を確認。
Appli Parkのsite-search.ts、検索ページ、候補取得処理、アプリ定義。2026年9月12日の実装で15チェックを実行。検索結果の順位や公開記事の総数を測定したものではありません。