よくある質問
CJK を Unicode のまま使わずローマ字化するのはなぜですか?
ブラウザは Unicode URL を問題なく扱いますが、その先の経路は必ずしもそうではありません。サーバログ、Slack のスニペット、メールにコピペされたリンク、解析ダッシュボード、監視ツール、多くの CLI は非 ASCII パスを壊したり、パーセントエンコードの呪文(`%EC%84%9C%EC%9A%B8`)として表示したりします。ASCII スラッグはあらゆる経路を生き残ります。代償は URL バーでのスキャン性がやや落ちることで、得られるのはログとダッシュボードの可読性です。CJK URL を残すチームもあれば、ローマ字化を選ぶチームもあります。耐えられるほうの痛みを選んでください。
`café` のアクセントは除去されますか、保持されますか?
除去されます。本ツールは Unicode の NFKD 正規化を実行し、`é` を基底文字 `e` と結合用アキュートアクセント(U+0301)に分解した後、結合マークをすべて削除します。`naïve` → `naive`、`crème brûlée` → `creme-brulee` のようになります。これは多くの CMS のスラッグ生成(WordPress・Hugo・Jekyll など)と同じ挙動です。アクセントを保持したスラッグが必要なら URL を Unicode のまま保つ必要があります。純粋な ASCII ルールとアクセント保持は両立しません。
スラッグはどのくらいの長さが望ましいですか?
意味のある単語 3〜5 個、ソフト上限 60〜75 文字を目安にしてください。Google の SEO ドキュメントには厳密な上限はありませんが、「短く、説明的に」と書かれています。検索結果のスニペットでは URL がおよそ 60 文字あたりで視覚的に切り詰められます。ログやダッシュボードはフルパスを表示できますが、200 文字のパスは SNS プレビューでスパムっぽく見え、口頭で共有するのも困難です。WordPress は既定で上限なし、Hugo・Jekyll・主要な静的サイトジェネレータも長いスラッグを受け付けますが、タイトル自体を短くすることが推奨されています。
漢字が日本語読みではなく拼音で出るのはなぜですか?
漢字を日本語読みに対応付けるには辞書照合が必要です。`日` は `nichi`・`hi`・`jitsu`、または `nihon` のような熟語の一部にもなり、正解は文脈に依存します。形態素解析器(kuromoji・MeCab など)を組み込まないと、ツールがメガバイト級の辞書データを抱える必要が出てくるため、Unicode CJK Unified Ideographs ブロックに基づく文字単位のローマ字化(`日` → `ri` のような拼音風)にフォールバックします。日本語比重の高いタイトルでは、スラッグ欄に手書きの romaji を入れるか、辞書を持つ CMS プラグインを併用してください。
アポストロフィ — `don't` が `don-t` ではなく `dont` になるのはなぜですか?
アポストロフィは前後の文字が同じ単語に属するため、区切り文字を挟まず除去します。`don-t-think` は読みづらく、単語認識を壊します。`dont-think` のほうが読み手の期待に合致します。多くのスラッグライブラリも同じ処理です。スタイルガイドが何らかの理由でアポストロフィでの分割を求める場合は、出力をワン置換で後処理してください。
ストップワード(`the`・`a`・`is` など)を除去できますか?
組み込みではありません。本ツールは入力に忠実な結果を返す方針です。ストップワード除去は「どれをストップワードとするか」が主観的で、言語にも依存します。「10 ways to improve your SEO」を「10-ways-improve-your-seo」に縮めると、わずかな文字数と引き換えに可読性をほんの少し落とします。最近の SEO の通説では短いストップワードはスラッグに残すべきとされています。それでも削りたい場合は出力に対して sed を一発走らせるか、手で編集してください。残したままでも害はありません。
関連する概念
URL スラッグとは、パスの中で読みやすく URL セーフな部分のことです — `/blog/seoul-eseo-ilbon-it/` の `seoul-eseo-ilbon-it` がそれにあたります。任意のテキストをスラッグに変える変換は 2 段階あります。**ローマ字化** は非ラテン文字をラテン文字に対応付けます。ハングルは国語のローマ字表記法(2000 年)、日本語の仮名はヘボン式(1867 年制定、現在も最も普及した規格)です。**Unicode 正規化 + アクセント除去** はアクセント付きラテン文字を NFKD で基底文字と結合マークに分解し(RFC 3454 IDNA、Unicode TR15)、続いて結合マークを除去します。この一連の処理は設計上、不可逆です。異なる 2 つのタイトルから同じスラッグが生まれることがあります。したがって、スラッグはストレージ側の安定したレコード ID と組み合わせて運用するのが基本です。
根本にある選択は **ASCII URL と Unicode URL** です。現代のブラウザ・検索エンジン・HTTP ライブラリは IRI(国際化リソース識別子、RFC 3987)を問題なく扱います。判断はあくまで実用です。ASCII スラッグはログ・ターミナル・コピー / ペースト・監視ツール・アナリティクスを綺麗に通り抜けます。Unicode URL はネイティブ話者にとっての可読性を守りますが、デコードしない UI ではパーセントエンコードの塊(`%EC%84%9C%EC%9A%B8`)として現れます。成熟した CMS はどちらの方向にも整合した結果を返します。WordPress はキリル文字はローマ字化、CJK は既定で Unicode のまま、Hugo はパーマリンクごとに選択を許す、といった具合です。どちらを選んでも、後からスラッグ規則を変えると既存 URL がすべて孤児になるため、初期に決めて一貫させてください。
隣接する 3 つの概念があります。**IDN / Punycode**(`xn--…`)はドメイン側を担います。ホスト名はパーセントエンコードを使えないため、国際化ドメインは非 ASCII を ASCII の包みに隠します(例: `日本.jp` → `xn--wgv71a.jp`)。**パーマリンク** は、公開された URL がどう見えるかを定め、それが変わらないことを約束するポリシー層です。スラッグが部品、パーマリンクが契約です。**ファイル名正規化** はほぼ同じアルゴリズムを使いますが、区切り文字の好み(URL は `-`、ファイル名は `_` が多い)と、より厳しい長さ制限(多くのファイルシステムで 255 バイト、実務的なクロスプラットフォーム互換ではさらに短く)が違います。