URL スラッグジェネレーター

任意のテキストから ASCII の URL スラッグを生成。ハングルや仮名は自動でローマ字化、非 ASCII 記号は除去・置換。ブログ記事 URL やファイル名の正規化に。

Loading…

すべての処理はブラウザ内で実行されます — ファイルや入力はサーバへ送信されません。

使い方

タイトルやファイル名を貼り付けると、URL パス・CSS クラス・正規化されたファイル名として使える ASCII スラッグが生成されます。区切り文字(`-`・`_`・`.`)を選び、小文字化を切り替え、必要なら最大長を指定すると単語境界で切り詰めます。ハングルは国語のローマ字表記法(Revised Romanization)で変換され(`서울` → `seoul`)、かなはヘボン式(`ありがとう` → `arigatou`)、ラテン語のアクセントは NFKD 分解後に除去されます(`café` → `cafe`、`naïve` → `naive`)。

ブログ記事や CMS の項目、ファイル名で、CJK やアクセント付きのタイトルから安定した ASCII ハンドルが欲しい場面に使ってください。Google は Unicode URL もインデックスしますが、ASCII スラッグはコピー / ペースト、ターミナルログ、監視ダッシュボード、マルチバイトが化けやすいチームチャットに通りやすいです。ハングル用のローマ字化テーブルとヘボン式のロジックはブラウザ内に組み込まれているため、社外秘の記事タイトルがサーバに届くことはありません。

韓国語タイトル → ローマ字 ASCII スラッグ

入力
서울에서 일본 IT 회사 다니는 이야기
出力
seoul-eseo-ilbon-it-hoesa-daninun-iyagi

ハングルは韓国国立国語院が 2000 年に発表した国語のローマ字表記法(Revised Romanization)で変換されます。各音節が一貫してマップされ(`서울` → `seoul`、`회사` → `hoesa`)、`IT` のようなラテン部分はそのまま通り抜けます。結果は韓国語話者がタイトルとして認識できる程度に逆引き可能でありながら、関わるすべてのシステムを通る ASCII 安全な形に収まります。

日本語の混在タイトル → ヘボン式スラッグ

入力
日本企業のAWSコスト管理でよくある失敗
出力
ri-ben-qi-ye-noawskosutoguan-li-deyokuarushi-bai

ひらがな・カタカナはヘボン式で変換されます(`コスト` → `kosuto`、`よくある` → `yokuaru`)。漢字は辞書照合をしないため、各文字に対するピンイン風の読みにフォールバックします。`日本企業` が `nihon-kigyou` ではなく `ri-ben-qi-ye` になるのはそのためです。日本語の比重が高い URL では、URL に日本語を残してブラウザのパーセントエンコードに任せる(`/日本企業の…`)か、ローマ字を手書きするサイトが多いです。本ツールのローマ字化は実用的なデフォルトであり、翻訳ではありません。

アクセント付きラテン語タイトル、長さ制限あり

入力
Pourquoi mon application Node.js consomme trop de mémoire en production ?
separator: -
lowercase: yes
max length: 60
出力
pourquoi-mon-application-node-js-consomme-trop-de-memoire

NFKD は `é` を `e` と結合用アキュート記号に分解し、続いてアキセントが除去されます。末尾の疑問符と `en production ?` の部分は 60 文字制限の外に出ますが、切り詰めは単語境界で行われるため、スラッグが単語の途中で終わることはありません。CMS やフレームワークがより厳しい制限を課している場合は上限をさらに下げてください。Google が推奨するソフト上限は 75 文字です。

よくある質問

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 バイト、実務的なクロスプラットフォーム互換ではさらに短く)が違います。

関連記事

関連ツール