ガイド

i18n とl10nの違いは何ですか？

それらが何であるか、そしてなぜ両方が必要なのかについての完全ガイド

ジョシュ・フェルプス Bablic

10月 7日、 2026日

イン・アンド・アウト・バーガーの有名な「裏メニュー」のように、あらゆる業界のニッチ分野には秘密の言語が存在し、それをマスターすれば、特別な内輪のグループの一員になったような気分になれる。翻訳・ローカライズ業界も例外ではない。数学の仲間たちと比べて常に少し劣等感を抱いている私たちの業界は、キーワードの間に数字を挟むことにしました。それが i18n とl10nです。

専門的で難しそうに聞こえますよね？

結局それは、 国際化 とローカライゼーションの略語に過ぎないことが判明した。

国際化、または i18n （「アイエイティーンエン」と発音）とは、ソフトウェアをあらゆる言語で実行できるようにするためのエンジニアリング作業を指します。これは、コードからテキスト文字列を抽出し、文字エンコーディングを処理し、日付、通貨、単位の柔軟な書式設定を構築することによって実現されます。 i18n は、ローカライズ (l10n) の準備として行われる技術的な裏方作業であり、これは地域ごと、市場ごとに行われます。

私が目にする解説ページのほとんどは、 i18n とl10n を同じタスクの2つのバリエーションとして扱い、記事の残りの部分をコードライブラリの説明に費やしているため、少し分かりにくくなっています。それらは同じ仕事ではない。国際化とは、エンジニアリングチームが一度だけ行うべき作業です。一方、ローカライゼーションとは、ウェブサイトに市場を追加するたびに行われる処理であり、多言語の訪問者がサイトを訪れた際に歓迎されていると感じるか、それとも不気味の谷に迷い込んだように感じるか（つまり、何かがおかしいのにそれが何なのかはっきりとは分からない）を左右する部分です。

この区別は、私が単に細かいことにこだわっているというだけではありません（確かにそれも事実ですが、この場合はローカライズを行うチームにとって重要な意味を持ちます！）。ウェブサイトが完全に国際化されていても、対象言語では「不自然」に感じられる場合がある。あなたのチームは、ドイツ語のテキスト展開に対応できるようボタンが拡張する設計、適切な通貨記号が付いた値札、読者にとって馴染みのある形式で日付が印字されるなど、細心の注意を払って設計しました。これで i18n回目だ！しかし、ボタンの横にある文章はどうでしょうか？市場を理解している人が書いたように聞こえますか？それとも翻訳アプリを通してそのままページに載せたように聞こえますか？それがローカライズの役割であり、訪問者がクリックして先に進むか、それとも離脱するかを決定づける要因となるのです。

i18n とは実際には何を意味するのか

以前にも言ったが、改めて明確にしておく価値がある（洒落を込めて）：国際化は数詞である。最初の文字（i）と最後の文字（n）を取り、その間の 18 文字を数えると、ほら、 i18nになります。これは略語であり、開発者たちがコードレビューでその単語を50回も綴らずに済む方法を求めていたことから定着した。したがって、ローカライゼーションには l10n 、アクセシビリティにはa11y などが割り当てられます。

しかし、略語を使うのはつまらない部分だ。重要なのは、 i18n が実際に何をするかだ。

これは、コードベースを構造化して、書き換えなしであらゆる言語やロケールをサポートできるようにするプロセスです。

コードから抽出されたテキスト文字列をハードコードする代わりに外部ファイルに書き出す
UTF-8エンコーディングにより、アクセント付き文字やラテン文字以外の文字が正しく表示されます。
テキストが常に左から右に読まれることを前提としないレイアウト
日付、数値、通貨の形式は固定的な仮定ではなく、変数として扱われます。

うまくやれば、 i18n は金魚にとっての水のようなもので、目に見えず、気づかれない（最高の意味で）。

l10n：決して終わらない部分

i18n が車だとすれば、l10n は燃料だ。フランス語を追加すると決めたら、ローカライズを行うことになります。日本語を追加すると、再びローカライズすることになります。これは完了する段階ではなく、繰り返し行うプロセスであるため、ローカライズには独自のワークフロー、担当者、ツールセットが必要であり、エンジニアリングとは切り離して管理する必要があるのです。

チームが真に国際化された製品を出荷したとしても、ローカライズの面で不十分な場合がある。なぜなら、ローカライズは単に単語を置き換えることではないからだ。慣用句や形式ばった表現、画像の差し替え、さらには微妙な色の変化なども含まれることがあります！

実際のページで違いがどこに現れるか

フォーマットの問題は、 i18n とl10n が別々に動作していることを示す最も簡単な方法です。

例えば、数字を考えてみましょう。アメリカでは1000ドル50セントを 1,000.50と表記する。ヨーロッパの多くの地域では、 1.000,50と同じ値を表す際に、コンマとピリオドを入れ替えて表記します。通貨欄には、米国では99.00 ドル、ドイツでは99,00 ユーロと表示され、それぞれの通貨記号が反対側に配置されている。日程はさらに細分化された。 03/04/2026 これは米国では3月4th 日、その他のほとんどの地域では4月3rd 日を意味します。そのため、ISO 8601 （YYYY-MM-DD）が存在し、国ごとに議論するのではなく、曖昧さを回避するために使用されています。言語コードも標準規格に準拠しています。ISO 639-1では、de、ja、ptなどの2文字のコードが割り当てられているため、ロケールシステムは国名から推測するのではなく、安定した識別子に基づいて作業を行うことができます。

テキスト展開は、エンジニアリングチームが最も過小評価している要素の一つです。 Phrase独自の i18n ドキュメント靴のサイズを分かりやすい例として挙げると、イギリスサイズ10 はヨーロッパサイズ38に相当し、アメリカサイズ 38 は全く異なるヨーロッパサイズ6に相当する。では、UIラベルを同じように翻訳すると、同じような単語の長さの不一致が生じます。ドイツ語とフィンランド語は、英語の原文よりも通常 20 ～35 パーセント長くなるため、「Submit」というラベルのボタンは問題なく収まりますが、「Zur Kasse gehen」は、レイアウトが柔軟なコンテナで構築されていない限り、収まりません。アラビア語とヘブライ語は右から左に書く言語であるため、全く別の問題が生じます。テキストの方向だけでなく、レイアウト全体が左右反転してしまうのです。

これらの問題は、翻訳段階ではどれも適切に解決されない。これはコード内で解決されるべき問題なので、 l10n を始める前にi18n をきちんと終わらせることを強く勧めているのです。

ワークフロー：強固な土台の上に家を建てる

健全なシステムでは、国際化は一度行われ、その後はローカライズがその上に無期限に繰り返される。文字列を抽出し、エンコーディングを設定し、柔軟なレイアウトを一度構築するだけで済みます。次に、フランス語にローカライズします。その後、日本語にローカライズします。さらにその後、アラビア語にも対応しましたが、基盤となるアーキテクチャには一切手を加えませんでした。なぜなら、そのアーキテクチャは最初からあらゆる地域に対応できるように構築されていたからです。

チームがつまずくのは、最初のステップを飛ばして、2番目のステップで付け足そうとすることだ。そういう時に、3階層も奥深くに埋め込まれたハードコードされた文字列や、MM/DD/YYYY形式しか理解できない日付ピッカーが出てくるのです。結局、翻訳プロジェクトは誰も想定していなかったリファクタリングへと発展してしまう。

スタックを再構築する必要があるのでしょうか？

私は数多くの営業電話会議に同席してきたので、ほとんどのチームが不安に思っていることが分かります。「これを正しく行うためには、既存のシステム構成を再構築する必要があるのだろうか？」ここで前提となっているのは、サイトが最初から国際化されていなかった場合、正しくローカライズするには完全な解体と再構築が必要になるという考え方です。ほとんどの場合、答えはNOです。

ローカライズレイヤーが既存のサイトのコードベース内ではなく、その上に構築される場合、再構築は不要です。少し手の内を明かしてしまうかもしれませんが、これがまさに Bablic 仕組みです。ほとんどの場合、軽量なJavaScriptコードが訪問者のブラウザで実行され、リクエスト時に適切なロケールに合わせて翻訳されたテキストに置き換えられます。これにより、元のサイト（ページが実際に存在する元のサーバー）をクロールしたり再構築したりする必要はなくなります。

通常、これに伴って生じるパフォーマンス上の懸念は、ブラウザ側のアプローチでは、ページビューごとに翻訳コーパス全体を読み込む必要があるという点である。それが本当に気になる点であれば、翻訳前のテキストをキャッシュする機能を備えたツールを選びましょう。この機能を使えば、ブラウザはリクエストごとに翻訳APIに新たにアクセスする必要がなくなります。

ここまで読んで、「でも私の製品は、深くネストされた条件ロジックと文字列とコードの分離がないネイティブアプリです」などと言っているでしょう。それは、ブラウザ側のレイヤーでは解決できない技術的な問題ですね！この場合は、SDK を使用したソリューションを探してください。しかし、マーケティングサイトやeコマースストアフロントなど、かつては1つの言語で構築され、現在は5つの市場に対応する必要があるページの場合、再構築という前提は概して誤りである。

文脈を無視して翻訳しないでください

ページが i18n 項目のチェック（通貨が正しい、日付の形式が正しいなど）をすべてクリアしたとしても、それが話しかけているはずの相手にとっては明らかに外国語のように読める可能性がある。顧客はメッセージが的外れだったり、少しでも間違っていたりするとすぐに気づき、それに気づいた人は購入に至らない。それが先ほど述べた不気味の谷現象であり、コンバージョンを阻害する真の要因です。

文脈を理解し、それを適用することが、この問題を解決するのに役立ちます。まず、ブランド名や製品の固有名詞といった特定の用語を制御することで、機械翻訳エンジンのデフォルト設定に関係なく、重要なフレーズが常に同じように翻訳されるようにすることができます。用語集があれば、そうした決定事項を確定できるため、翻訳されたページが特定の読者層に向けた汎用的なバージョンではなく、自社のブランドイメージに合ったものになるのです。

2つ目は、翻訳されたページを実際に見て、不自然な表現を見つけるために翻訳先の言語に堪能である必要なく、その場で間違いを修正できる能力です。コンテキストエディターを使用すると、翻訳されたページがリアルタイムで表示され、直接編集できます。つまり、スペイン語を話せる同僚は、翻訳者がスプレッドシートから全体をやり直す代わりに、数分で出力結果をチェックできるということです。

ほとんどのページにおいて、機械翻訳（MT）は妥当な出発点となる。 Bablicのデフォルトの翻訳エンジンはGoogle翻訳とDeepLで、人間のチームでは到底及ばないスピードで最初の草稿を作成します。私たちが話を聞いたほとんどの企業にとって、これらのエンジンに用語集と文脈に沿ったエディターによる抜き打ちチェックを組み合わせるだけで、サイトが真にローカライズされているという実感を得られるのに十分です。

よくある質問

なぜ国際化は「 i18n」と呼ばれるのか？ これは数詞を使った略語で、最初の文字（i）、最後の文字（n）、そしてその間の 18 文字を数えて、20文字の単語全体を綴る代わりに略記として使われます。

l10n は何の略で、i18nとはどう違うのですか？ l10n はローカライゼーションの略で、l、10 文字、そしてnです。i18n は、製品をあらゆる言語で実行できるようにする一度限りのエンジニアリング作業ですが、l10n は、フォーマット、文言、レイアウトを一度に1つの地域に合わせて実際に適応させる、市場固有の反復作業です。

小規模チームは機械翻訳を使うべきか、それとも人間の翻訳者を雇うべきか？ Bablicのデフォルトの機械翻訳エンジンはGoogle翻訳とDeepLであり、速度とコストの面で、ほとんどのサイトコンテンツにとって強力な出発点となる。機械翻訳だけでは埋められないギャップは、ブランドの文脈とトーンです。そのため、専任のローカライズ担当者がいないチームにとっては、機械翻訳のみ、あるいは完全手動翻訳よりも、機械翻訳出力の上に用語集と人間によるレビューのレイヤーを追加する方が、より良い結果をもたらす傾向があります。翻訳費用は言語や翻訳量によって大きく異なるため、完全人手による翻訳に踏み切る前に予算を立てておく価値がある。