韓国語のローマ字表記: 文化観光部2000年式(RR) vs マッキューン・ライシャワー(MR)

韓国語の姓である김は、ほとんどのパスポートでKimと書かれますが、都市の 부산は公式にはBusanである一方で古い地図にはPusanと記され、이は尋ねる 相手によってLee、Yi、Iとローマ字化されます。これらのいずれも誤りでは ありません。異なるローマ字表記体系から来ているうえに、体系をまったく無視 する人名表記の慣習がもう一層加わっているためです。一つの綴りを選んで確定 しなければならなかった経験があるなら、今どの体系の中にいるのかを知っている だけで、迷いを大きく減らせます。

一つの韓国語の単語が複数の綴りに対応する理由

ローマ字表記は*翻字(transliteration)*です。ある文字体系を別の文字体系で 表現することです。ハングルは音を正確に記録しますが、英語の綴りは韓国語の 音にきれいには対応しないため、どのローマ字表記でも選択をしなければなりま せん。とりわけ英語の有声音と無声音の間に位置する子音、そして英語に対応する 文字がない母音でそうです。異なる体系はその選択を異なって行い、そのうち 二つが主流となりました。

文化観光部2000年式(RR) — 公式のもの

**文化観光部2000年式(RR)**は、韓国政府が2000年に採用した体系であり、今日 道路標識、駅名、政府文書で目にするのがこれです。その際立った特徴は、 純粋なASCII文字だけを使う点です。発音区別符号も、アポストロフィも ありません。まさにこの点ゆえに、標識やURLでうまく機能します。

子音の選択が最も目につく違いです。

• 부산 → Busan (Pusanではない)
• 대구 → Daegu (Taeguではない)
• 제주 → Jeju (Chejuではない)
• 광주 → Gwangju (Kwangjuではない)

RRは該当する子音をb/d/g/jで表記しますが、古い体系は同じ位置で p/t/k/chを使っていました。英語に対応語がない母音ㅓとㅡは、二字綴りの eoとeuになります。そのため서울はSeoulで、인천はIncheonです。 公式・公開・機械可読のいずれかであるべきものの綴りを生成するなら、RRが 既定です。

マッキューン・ライシャワー(MR) — 古い標準

1937年に生まれたマッキューン・ライシャワー(MR)は、20世紀の大半に わたって主流の体系であり、今でも学術界の多くの分野や北朝鮮、そして古い 書籍や地図で標準として使われています。英語話者の読者により近く発音を反映 することを目指しており、その代償として発音区別符号とアポストロフィを 払います。

• ブレーヴェは母音を示します。ㅓはŏで、ㅡはŭなので、서울はSŏulです。
• アポストロフィは帯気を示します。ㅋはk'でㄱはk、ㅌはt'でㄷはtです。

そのため古い文献ではPusan、Taegu、Kyŏngjuを目にします。MRは音声的に より多くの情報を含みますが、特殊文字は脆弱です。プレーンテキストの システムでは脱落し、URLでは壊れ、入力が面倒です。これが韓国がMRから離れた 現実的な理由です。

ハングル	文化観光部2000年式(RR)	マッキューン・ライシャワー(MR)
부산	Busan	Pusan
대구	Daegu	Taegu
서울	Seoul	Sŏul
경주	Gyeongju	Kyŏngju
김치	gimchi	kimch'i

人名はそれ自体が別個の規則です

どの体系も解決しない落とし穴がここにあります。人名はRRもMRも一貫して 従いません。 韓国人は自分の名前を好きなようにローマ字化でき、家系ごとの 綴りは何世代にもわたって固まってきました。そのため김はほとんど常にKimで (RRのGimではない)、이は通常LeeまたはYi、박はParkです(Bakでは ない)。人の名前をローマ字化するときの正解は、その人がすでに使っている表記 です。ローマ字変換器は体系上の既定値を示せるだけで、名前はその既定値を いくらでも上書きしうるのです。

どちらを使うか

• 公開・公式・機械処理のいずれかであるすべてには文化観光部2000年式を 使います。標識、住所、URL、ソフトウェアがそうです。現行の標準であり、 ASCIIで損なわれずに保たれます。
• 学術引用、2000年以前の資料、またはすでにMRを使っている北朝鮮の資料に 合わせる必要があるときはマッキューン・ライシャワーを使います。
• 人の名前には、どちらの体系よりもその人自身の表記を常に使います。

ローマ字変換器は体系上の規則を適用します。이がLeeになりたがっていることは 知りようがありません。私たちの韓国語ローマ字変換器は、 ハングルをブラウザ内で文化観光部2000年式に変換し、地名や単語、そして後で 手作業で調整する名前の妥当な既定値をカバーします。目標が具体的にURLに安全な 文字列であるなら、発音区別符号と衝突という関連する問題は URLスラグの作成で扱っています。