i18nとは——「翻訳」ではなく「翻訳できる作り」のこと。l10n・g11nとの違いと対応12領域

「見積もりに i18n と書いてあるが、これは何のことなのか」——多言語対応を検討し始めた方から、こうした問いをよく受けます。読み方も分からない、翻訳のことなのか設計のことなのかも分からない。そのまま「多言語対応 180万円」という一行を承認していいのか、判断がつかない。ここでつまずく方は珍しくありません。

結論から言うと、i18n は internationalization(国際化)の略で、先頭の i と末尾の n の間に 18 文字あることから来た表記です。そして指しているのは「翻訳すること」ではなく、翻訳できる作りにしておくことです。実際にその地域向けに翻訳し、書式や表現を調整する作業は l10n(localization・地域化)と呼ばれ、国際化とは別の工程になります。この2つを分けて考えないと、見積もりの比較も、社内の分担も噛み合いません。

分けて考えられるようになると、見え方が変わります。開発会社が見積もっているのはたいてい「翻訳を流し込める仕組み」までで、訳文そのものと品質保証は発注側に残る。そのことが分かれば、2社の見積もりが2倍違う理由も、後から言語を1つ足すときの費用も、構造として説明できるようになります。

本記事では、i18n の由来と定義、l10n・g11n・a11y との違い、国際化で対応する12領域、翻訳ファイルの管理と翻訳の担い手、後から多言語化すると費用が跳ねる理由、見積もりの「多言語対応」に含まれるもの・含まれないもの、外部チームで進めるときに発注側が握る3点、よくある質問の順に解説します。定義と仕様は W3C、Unicode Consortium(CLDR)、MDN、各フレームワークの公式ドキュメントで直接確認しました(確認日は 2026年9月19日)。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。多言語対応で揉める原因は、技術ではなく責任分界です。誰が訳すのか、誰が用語を決めるのか、崩れた画面を誰が見つけるのか。この記事を読み終えるころには、その線を自分で引けるようになっているはずです。

i18nとは——internationalizationの i と n の間が18文字。「翻訳できる作り」にすることを指す

i18n は internationalization(国際化)を短く書いた表記です。数字の 18 は、先頭の i と末尾の n にはさまれた文字数を表しています。ここで大事なのは、i18n が指しているのが「翻訳そのもの」ではなく、翻訳できる作りにしておくことだという点です。この一点を外したまま見積もりや工程の話を始めると、発注側と開発側で話が噛み合いません。まずは由来と定義、そしてよく並べて使われる略語との違いを押さえます。

なぜ18なのか——W3Cが示す略記の作り方と読み方

W3C(World Wide Web Consortium)の国際化に関する解説では、この略記の作り方がはっきり書かれています。「Internationalization is often written in English as i18n, where 18 is the number of letters between i and n in the English word」(2026年9月19日確認)。日本語にすると「英語では i18n と書かれることが多く、18 はその英単語の i と n の間にある文字数である」となります。同じ作りで localization は l10n と書かれ、こちらは l と n の間が 10 文字です。

実際に数えてみると、internationalization は i / nternationalizatio / n の並びで、間の文字は 18 文字。localization は l / ocalizatio / n で 10 文字です。このように「語頭の1文字 + 間の文字数 + 語尾の1文字」で長い単語を短く書く表記は numeronym(ニューメロニム)と呼ばれます。

読み方は「アイ・エイティーン・エヌ」と英語読みされることが多く、日本語の会話では「アイ・イチハチ・エヌ」と読まれることもあります。どちらでも通じますが、海外のチームと話す場面では前者が無難です。

l10n・g11n・a11y——同じ作りの略語と、指すものの違い

同じ作りの略語がいくつも流通しているため、まとめて整理しておきます。特に i18n と l10n は対で語られますが、作業としては別物です。

W3C は internationalization を「Internationalization is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language」、localization を「Localization refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a locale)」と定義しています(いずれも 2026年9月19日確認)。前者は enables(可能にする)、後者は adaptation(適応)という語が使われており、作りと適応という役割の違いがそのまま出ています。

g11n については、正直に書いておきます。W3C は globalization に独立した定義を与えておらず、「同じ概念を指すのに globalization などの別の語を使う人もいる」と述べるに留まっています。業界では「i18n + l10n の全体」を指して使われることが多い語ですが、標準化された厳密な定義があるわけではありません。会話の中で g11n が出てきたら、相手が何を含めて言っているかを確認したほうが安全です。

a11y は accessibility の同じ作りの略記で、a と y の間が 11 文字です。W3C/WAI の文書では accessibility と綴られており、a11y という表記は開発現場や技術記事で広く使われているものです。W3C は「Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them」(2026年9月19日確認)と説明しています。国際化と混同されやすいのですが、目的が違います。国際化は「どの言語・地域の人でも使えるようにする」、アクセシビリティは「障害のある人が使えるようにする」ことです。

国際化と地域化は別作業——「翻訳できる作りにする」と「実際に翻訳する」

ここが本記事で最も伝えたい点です。国際化と地域化は、別の作業で、別の人が担い、別の成果物を生みます。

国際化(i18n)でやるのは、画面に出る文字列をソースコードから外に出す、日付や金額の書式を地域のデータに任せる、文字コードを Unicode に統一する、といった作りの変更です。この段階では日本語しか表示されなくても構いません。成果物はコードと翻訳ファイルの器です。

地域化(l10n)でやるのは、その器に実際の英語やベトナム語の訳文を入れ、その地域の書式や表現に合わせて調整することです。成果物は訳文と、地域ごとの設定です。

Ruby on Rails の公式ガイドは、この分担を端的に書いています。「The process of 'internationalization' usually means to abstract all strings and other locale specific bits (such as date or currency formats) out of your application. The process of 'localization' means to provide translations and localized formats for these bits」(2026年9月19日確認)。日本語にすると、国際化は「すべての文字列やロケール固有の要素(日付や通貨の書式など)をアプリケーションから抽象化すること」、地域化は「それらに翻訳とローカライズされた書式を与えること」です。

MDN Web Docs の日本語の用語集も、国際化対応を「さまざまな地域、言語、文化が異なるターゲットオーディエンスに簡単に適応できるようにシステムを設計すること」とし、「システムを特定のターゲット層に適合させる補完的なプロセスをローカライズと呼びます」と説明しています(2026年9月19日確認)。

順番も決まっています。国際化が先、地域化が後です。 器がないところに訳文だけ用意しても入れる場所がありません。逆に、器さえできていれば、言語を1つ足す作業は「訳文を書いて入れる」だけになります。後から多言語化する案件で費用が跳ね上がるのは、この器を作るところから始めなければならないからです。

では、その器は具体的に何を作り込むことなのか。次に対応する12の領域を一覧で見ていきます。

i18nで対応する12領域——日本語だけなら起きない問題の一覧

国際化で作り込む範囲は、文字の表示から画面のレイアウトまで広く分布しています。共通しているのは、どれも「日本語だけを相手にしている限り、問題として表面化しない」ことです。日本語決め打ちで作られたシステムに、これらの仕組みが最初から入っていることはまずありません。まずは全体を一覧で押さえ、そのうえで重い順に中身を見ていきます。

12領域の一覧表(領域・日本語だけなら起きない問題・確認する場所)

この12領域のうち、1と2は最初に手を付けないと後の全部がやり直しになります。3〜8は「書式のデータ」に任せれば機械的に解決できます。9〜12は設計とデザインの判断が必要で、後から直すと画面ごとの作り直しになります。以下、この順にまとめて説明します。

文字コードと文字列の外部化——ここを外すと後の全部がやり直しになる

文字コードは、文字を数値として記録するときの取り決めです。W3C は明確に一つを推奨しています。「As a content author or developer, you should nowadays always choose the UTF-8 character encoding for your content or data」(2026年9月19日確認)。つまり、現在は常に UTF-8 を選ぶべきということです。理由は「単一の文字コードで、必要になりそうなあらゆる文字を扱える」からです。

その裏づけが Unicode です。Unicode Consortium は 2026年9月16日に Unicode 18.0.0 を公開し、収録文字は 172,808 文字になりました(2026年9月19日確認)。ベトナム語の声調記号付きの文字も、中国語の漢字も、アラビア文字も、絵文字も、この1つの体系に収まっています。

注意が必要なのは、W3C が同じ解説で釘を刺している点です。「Note that just declaring a different encoding in your page won't change the bytes; you need to save the text in that encoding too」。ページに UTF-8 と宣言するだけではバイト列は変わらず、実際にその文字コードで保存されていなければ意味がありません。文字化け(いわゆる mojibake)の相談の多くは、HTML・アプリケーション・データベース・API のどこか1か所だけが別の文字コードのまま残っていることが原因です。どこか1か所でも取りこぼすと、そこを通ったデータは壊れます。壊れたデータは後から復元できないことが多く、ここは要注意です。

文字列の外部化は、画面に出る文言をソースコードの中から出して、言語ごとのファイルに置くことです。コードには「この場所に表示する文言のキー」だけを書き、実際の文言は翻訳ファイルから取り出します。W3C も国際化の中身として「Separating localizable elements from source code or content, such that localized alternatives can be loaded or selected based on the user's international preferences as needed」(ローカライズ可能な要素をソースコードやコンテンツから分離し、利用者の国際的な設定に応じて訳を読み込めるようにすること)を挙げています。

この作業は地味ですが、多言語化の工数の大半を占めます。画面数が多いシステムでは、日本語が書かれている箇所を1つずつ洗い出す作業になるためです。

日付・時刻・タイムゾーン・数値・通貨・単位——書式は「地域のデータ」に任せる

日付や金額の書き方は、地域ごとに違います。自前で分岐を書くと、言語が増えるたびに分岐が増え、いずれ破綻します。ここは「地域ごとの書式データ」を持つ仕組みに任せるのが定石です。

その書式データの標準が、Unicode Consortium が管理する CLDR(Common Locale Data Repository)です。CLDR は「supplies key information and structures critical for programs and operating systems around the world to ensure that they feel natural, no matter which language users speak or where they live」(2026年9月19日確認)とされ、日付と数値の書式パターン、通貨の表記、計量単位、並び順、複数形の規則、リストの書き方などを供給しています。CLDR は 48.2 が 2026年3月17日にリリースされており、毎年更新されます。

Web の世界では、この CLDR のデータをブラウザ側が持っており、JavaScript の Intl から使えます。MDN によれば Intl には DateTimeFormat(日時の書式)、NumberFormat(数値の書式)、Collator(言語に応じた文字列の比較と並び替え)、PluralRules(複数形の規則)、ListFormat(リストの書式)、RelativeTimeFormat(相対時間)、Segmenter(文の分割)などが用意されています(2026年9月19日確認)。自前で書式を組み立てる必要はほとんどありません。

タイムゾーンは別扱いが要ります。時差は固定ではなく、夏時間の開始日や地域の制度変更で動くためです。この履歴を保持しているのが IANA Time Zone Database で、「The Time Zone Database (often called tz or zoneinfo) contains code and data that represent the history of local time for many representative locations worldwide」と説明されています。最新版は 2026d(2026年9月11日リリース・2026年9月19日確認)。年に数回更新されるため、リリース後も追従が必要です。実装の原則はシンプルで、保存は UTC、表示のときだけ利用者の地域に変換する。ここを守らないと、日をまたぐ集計が地域によって合わなくなります。

通貨は、金額の数値と通貨の種類を分けて保存するのが基本です。「10000円」を文字列で持ってしまうと、他の通貨を入れる場所がありません。単位も同様で、メートル法が前提の値をそのまま表示すると、ヤード・ポンド法の地域では読み替えの負担を利用者に押し付けることになります。

並び順と複数形——言語によって「形の数」が違う

一覧の並び替えは、五十音順やアルファベット順だけでは足りません。アクセント付きの文字をどこに置くか、大文字と小文字をどう扱うかは言語ごとに決まっており、これも CLDR のデータと Intl.Collator に任せます。

見落とされやすいのが複数形です。日本語には単数・複数の区別がなく、「3件」と書けば済みます。ところが英語では 1 item / 3 items と形が変わり、言語によってはもっと複雑です。CLDR は複数形を zero / one / two / few / many / other の6つのカテゴリで表し、言語ごとにどれを使うかを定義しています。CLDR の解説は「A common mistake is to think that 'one' is only for only the number 1. Instead, 'one' is a category for any number that behaves like 1」(2026年9月19日確認)と注意しています。「one」は数字の1だけを指すのではなく、1のように振る舞うすべての数を指すカテゴリです。

CLDR の言語別の一覧(バージョン48・2026年9月19日確認)では、基数の複数形カテゴリの数は次のようになっています。

日本語(1形)しか考えずに作られた「件数 + 件」という文字列連結は、英語版を作った時点で破綻します。件数表示は必ず複数形の仕組みを通すようにしてください。

氏名・住所・電話番号とレイアウト——文字列は伸び、右から左に流れることもある

入力フォームは、国際化で最もほころびが出やすい場所です。W3C の人名に関する解説は「People who create web forms, databases, or ontologies are often unaware how different people's names can be in other countries」(2026年9月19日確認)と書き、続けて「If designing a form or database that will accept names from people with a variety of backgrounds, you should ask yourself whether you really need to have separate fields for given name and family name」と助言しています。姓と名を分ける必要が本当にあるのかをまず疑え、ということです。「first name」「last name」というラベルも、姓を先に書く文化の人には逆に読まれるため避けるよう勧めています。住所の必須項目や郵便番号の桁数、電話番号の形式も同じで、日本の形式を必須チェックに組み込むと、他の地域の利用者は登録すらできません。

レイアウトは、文字列が伸びることを前提に組む必要があります。W3C は IBM が公開した、英語から欧州言語へ翻訳したときの平均的な伸長率を引いています(2026年9月19日確認)。

W3C はここから「the smaller the source message, the higher the likely translation length」(元の文が短いほど、訳文は相対的に長くなりやすい)という指摘を引き出しています。つまり、ボタンやラベルのような短い文言ほど危ない。英語の views がイタリア語では visualizzazioni になり、3倍近くになる例が挙げられています。幅を固定したボタンは、ほぼ確実に崩れます。

最後が書字方向です。W3C は右から左に書くスクリプトとして Adlam、アラビア文字、ヘブライ文字、ンコ文字、シリア文字、ターナ文字の6種を挙げ、これらを使う言語としてアラビア語、ヘブライ語、ペルシア語、ウルドゥー語などを列挙しています。対応するには HTML の dir 属性を使います。「The dir attribute is used to set the base direction of text for display」「If the overall document direction is right-to-left, add dir="rtl" to the html tag」(2026年9月19日確認)。そして「Never use CSS to apply the base direction」、つまり基本の書字方向を CSS で当ててはいけない、とされています。方向は文書の意味に属する情報だからです。右から左に対応する場合、文字が反転するだけでなく、表の列の進む向き、フォームの開始位置、余白の付き方まで鏡像になります。デザインの作り直しに近い作業になると見込んでください。

ここまでが「国際化で作る器」の中身です。器ができると、今度はそこに入れる訳文を運用し続けるという、終わらない仕事が始まります。

翻訳ファイルの管理と、翻訳を誰がやるか——運用が始まってからの話

国際化を終えると、翻訳ファイルという新しい資産が手元に残ります。これは一度作って終わるものではありません。画面を追加すれば翻訳すべきキーが増え、文言を直せば全言語分を直すことになります。多言語対応の相談で後になって問題が噴き出すのは、たいていこの運用の設計が抜けているためです。ファイルの形、翻訳の担い手、更新の流れの順に整理します。

翻訳ファイルの形とキー設計——公式ドキュメントが示す2つの実例

翻訳ファイルの実体は、キーと訳文の対応表です。形式はフレームワークによって違いますが、考え方は共通しています。公式ドキュメントの実例を2つ挙げます。

Next.js の公式ガイドでは、言語ごとの JSON ファイルを「辞書(dictionaries)」と呼び、dictionaries/en.json と dictionaries/nl.json のように言語別に置きます。中身は products.cart というキーに対して英語なら "Add to Cart"、オランダ語なら "Toevoegen aan Winkelwagen" を対応させる、という形です(2026年9月19日確認)。

Ruby on Rails では、config/locales ディレクトリに YAML ファイルを置きます。公式ガイドは「adds all .rb and .yml files from the config/locales directory to the translations load path, automatically」と説明しており、このディレクトリに置いたファイルは自動で読み込まれます(2026年9月19日確認)。ファイルは models / views / defaults のように階層で分けて整理できます。

複数形の扱いも公式の仕組みに乗ります。Rails では :count という変数が特別な役割を持ち、「The :count interpolation variable has a special role in that it both is interpolated to the translation and used to pick a pluralization from the translations」とされています。件数を渡すと、その言語のルールに応じた形が選ばれる仕組みです。

発注側が知っておくとよいのは、次の3点です。

• キーは意味で付ける。「button_blue」ではなく「cart.add」のように、何を表す文言かが分かる名前にする。訳者がキーだけを見て文脈を推測できるかが、訳文の質に直結します
• 同じ文言でも文脈が違えば別キーにする。日本語の「登録」は、英語では Register にも Submit にも Add にもなります。1つのキーを使い回すと、どこかで不自然な訳になります
• 翻訳ファイルはソースコードと同じ場所で管理する。別管理にすると、画面の変更と訳文の更新がずれます

翻訳の担い手3パターンと、それぞれの責任の置き方

「翻訳は誰がやるのか」は、発注の段階で必ず決めておく項目です。実務では次の3パターンに分かれます。

どのパターンでも共通して決めておくのが、訳文の合否を誰が判定するかです。ここが空欄のまま進むと、「訳が不自然だ」という指摘が検収の段階で出て、誰の負担で直すのかで揉めます。当社が関わる案件でも、この一点を先に文書に書いておくかどうかで、後半の進み方がはっきり変わります。

機械翻訳だけで済ませるかどうかは、画面の性格で判断してください。社内の業務画面なら機械翻訳 + 事後修正で回ることが多く、契約や課金に関わる画面、ブランドの顔になる画面は人の確認を入れたほうが安全です。誤訳のまま出た規約が原因で問い合わせが増えれば、節約した翻訳費は簡単に飛びます。

更新のたびに起きること——未翻訳の扱い、CMSに持たせる選択肢、URLと検索エンジン

運用が始まると、次の3つを決めておく必要が出てきます。

1つ目は、未翻訳のキーをどう扱うかです。新しい画面を出したとき、英語の訳文がまだ用意できていないことは普通に起きます。このときの挙動は、「キー名がそのまま画面に出る」「日本語のまま出る」「エラーになる」のどれかです。何も決めないと3番目になり、本番で画面が落ちます。Next.js の公式ガイドも、対応していない言語が指定された場合に実行時エラーではなく 404 を返す書き方を示しています。未翻訳時に何を表示するかは、仕様として決めてください。

2つ目は、文言をどこに持つかです。画面のラベルやボタンは翻訳ファイルで問題ありませんが、記事やお知らせのような「中身のコンテンツ」は、ヘッドレスCMS 側で言語ごとに持たせる選択肢があります。CMS 側で持たせると、開発者を通さずに事業側が更新できる一方、プランによってロケール数に上限があるなどの制約が出ます。どちらに持たせるかはサービスの更新頻度と運用体制で決まるため、詳しくは『Contentfulとは』の記事を参照してください。

3つ目は、URL と検索エンジンです。多言語のページを公開するなら、どの言語版があるかを検索エンジンに伝える必要があります。Google 検索セントラルは hreflang による指定を示しており、HTML タグ・HTTP ヘッダー・XML サイトマップの3つの方法があり「The three methods are equivalent from Google's perspective」(2026年9月19日確認)としています。注意点は相互参照の要件で、「If two pages don't both point to each other, the tags will be ignored」——互いに参照し合っていないと無視されます。また、どの言語にも当てはまらない利用者向けには x-default を指定します。言語コードは ISO 639-1、地域コードは ISO 3166-1 Alpha 2 の形式で、「You can't specify the country code by itself」、地域コードだけを書くことはできません。

URL の形は、Next.js の公式ガイドが挙げるように「サブパス(/fr/products)」か「ドメイン(my-site.fr/products)」のどちらかを選びます。画面をクライアント側で描画する作りの場合は、言語切り替えのときに URL も変わるように設計されているかを確認してください。描画方式そのものについては『SPA開発』の記事で扱っています。

ここまでが、国際化を終えた後に続く運用の話です。では、これらをすべて「後から」やるとどうなるのか。次にコストの構造を見ます。

後から多言語化すると費用が跳ねる理由と、最初から入れておく場合の差

「後からでも多言語化できますか」という質問は、相談の場でほぼ必ず出ます。答えは「できます。ただし、想像しているより高くつきます」です。後付けが高いのは翻訳費が高いからではなく、翻訳を足す作業ではなく作りを変える作業になるからです。何が同時に発生するのかを分解します。

後付けで同時に発生する5つの作業

日本語だけで動いているシステムに多言語対応を入れる場合、次の5つがまとめて発生します。

このうち費用を跳ね上げるのは 2 と 4 です。1と3は地道な作業で、時間はかかっても見積もれます。ところが 2 は既存データの移行を伴い、稼働中のシステムでは移行のための停止計画まで必要になります。4 は「作り直し」なので、実質的に画面を再度作るのと変わりません。

私のところに来た相談で典型的だったのが、5年前に作った業務システムをベトナム拠点のスタッフにも使わせたい、というものでした。画面の文言はすべてソースコードに直書きされ、マスタデータの名称も日本語のみ。この状態から英語とベトナム語を足すとなると、上の5つが全部発生します。「後からでも足せる」は半分正しく、半分は誤りです。足せるのは翻訳であって、器は後から作ると高い。既存システムの作り替え全般については『レガシーシステム刷新 外注』の記事でも扱っています。

最初から設計に入れておくと安い理由——増えるのは「仕組み」ではなく「言語」だけ

逆に、最初の設計に国際化を入れておくと何が違うのか。答えは単純で、言語を増やすときに増えるのが「言語」だけになることです。

最初から翻訳ファイルの仕組みが入っていれば、2言語目の作業は「翻訳ファイルを1つ増やして訳文を入れる」ことと「その言語で全画面を確認する」ことに収まります。データベースが言語ごとの値を持てる形になっていれば、データの移行は発生しません。書式を仕組みに任せていれば、日付も金額も件数も自動的にその言語の形で出ます。レイアウトが文字数の伸びを前提に組まれていれば、崩れの修正は局所で済みます。

新規開発で国際化を最初から入れる場合、追加で必要になるのは主に設計と実装の一部で、後付けのような「棚卸し」「移行」「作り直し」「全面再テスト」は発生しません。同じ多言語対応でも、作業の種類そのものが違うのです。将来の海外展開や訪日利用者への対応が少しでも視野にあるなら、設計の段階で相談しておくのが最も安上がりです。

「まだ多言語にしない」ときでも入れておきたい3つ

とはいえ、今すぐ多言語にする予定がないのに、フル装備の国際化に予算を割くのは現実的ではありません。私が発注側に勧めているのは、次の3つだけを最初に入れておくことです。この3つは追加費用が小さく、後から直すと高い項目です。

1. 文字コードを UTF-8 に統一する。 データベース、アプリケーション、API、HTML のすべてで揃える。これは多言語化と関係なく、絵文字や旧字体を扱うだけでも効いてきます。後から直すとデータの作り直しになります
2. 画面の文言をコードの外に出す。 翻訳ファイルの形にしておけば、1言語のままでも文言の修正が楽になります。後からやると全画面の棚卸しになります
3. 日時は UTC で保存し、表示のときに変換する。 保存の形を後から変えると、過去のデータ全部の変換が必要になります

逆に言えば、この3つ以外(複数形、並び順、右から左に書く言語、通貨の切り替え)は、実際にその言語をやると決まってから着手して構いません。先に手を打つべきものと、後回しでよいものを分ける。ここを一緒くたにして「多言語対応は高いから見送る」と判断するのが、いちばんもったいない進め方です。

この切り分けが分かると、見積書の読み方も変わってきます。次に、見積もりの「多言語対応」という一行の中身を開けます。

見積もりの「多言語対応」に含まれるもの・含まれないもの——発注者が読む位置

ここからは発注側の実務です。見積書に「多言語対応(i18n) 一式」と一行で書かれていたとき、その金額が何を約束しているのか。私が受ける多言語対応の相談で最も多い誤解が、ここに翻訳が含まれていると思い込んでいたケースです。見積書はスコープを書いた文書であり、書いていないものは含まれません。切り分けを表にします。

含む/含まないの切り分け表と、金額が2倍違うときに起きていること

2社の見積もりが2倍違うとき、多くの場合は技術力の差ではなく、この表のどこまでを含めたかの差です。安いほうは「文字列の外部化と言語切り替えの仕組みまで」、高いほうは「訳文の作成、データの多言語化、言語ごとのテストまで」を入れている。金額だけを並べると安いほうが得に見えますが、含まれていない分は後から発注側の費用として出てきます。スコープを揃えずに金額だけ比べるのは失敗のもとです。見積もりの読み方そのものについては『システム開発 見積もり 内訳』の記事で扱っています。

もうひとつ、見積書に書かれにくいのが「どこまで作れば完了か」の基準です。多言語対応は「訳文が入った」だけでは終わらず、画面が崩れていないこと、文字化けがないこと、日付や金額が正しく出ることまでが実質的な完了条件になります。この種の「動くかどうかではなく、どの水準で動くか」を決める要件は非機能要件として整理しておくと、検収の基準として使えます。整理の仕方は『非機能要件とは』の記事にまとめています。

見積もりを依頼する前に決めておく5項目

見積もりの精度は、依頼する側がどこまで決めているかで決まります。次の5つを先に決めてから依頼してください。決まっていない項目は「未定」と書いて渡すだけでも、見積もりの前提が揃います。

1. 対象言語と、その優先順位。「英語と中国語とベトナム語」なのか「まず英語だけ、半年後に他」なのか。同時か段階かで設計が変わります
2. 対象範囲。 全画面か、利用者が見る画面だけか、管理画面は日本語のままでよいか。管理画面を外すだけで工数はかなり下がります
3. 翻訳の担い手。 自社で用意するのか、開発会社に頼むのか、機械翻訳 + レビューにするのか。前章の3パターンのどれかを選びます
4. データを多言語にするかどうか。 画面のラベルだけか、商品名や記事本文などのデータも言語ごとに持つか。ここが費用の分かれ目です
5. テストの範囲と合否の基準。 何言語分を、誰が、どの画面まで確認するのか。「文字化けなし・主要画面でレイアウト崩れなし」のように文章で書いておきます

この5つが決まっていれば、複数社の見積もりを同じ土俵に乗せられます。逆にこれらが白紙のまま「多言語対応をお願いします」と依頼すると、各社が勝手に前提を置いた見積もりが返ってきて、比較できません。前提を揃えるのは発注側の仕事です。

では、実際に開発を外部のチームで進めるとき、発注側は何を手元に残すべきか。最後にそこを整理します。

外部チームで多言語対応を進めるとき、発注側が握る3つ——当社の進め方

多言語対応を含む開発を外部のチームに任せる場合でも、発注側が手元に残しておくべきものがあります。渡してしまうと後から戻すのが難しい3つです。用語集、翻訳の責任範囲、そして文字化けとレイアウト崩れのテスト。順に説明します。

用語集——訳語のぶれは技術では直らない

最初に作るべきは用語集です。自社のサービスで使う言葉を一覧にし、それぞれの訳語を決めておきます。「申込」「お申し込み」「エントリー」を英語でどう訳すか、自社サービスの機能名を訳すのか原語のまま残すのか。こうした判断は事業側の言葉の問題であり、開発チームには決められません。

用語集がないまま進むと、画面ごとに別の訳語が当たります。翻訳の担い手が複数になればなおさらです。そして厄介なことに、このぶれは技術で検出できません。どちらも文法的には正しい英語なので、システムは何も警告しません。訳語のぶれは、公開後に利用者から指摘されて初めて気づくのが実情です。

作り方は難しくありません。表計算ソフトで「日本語 / 英語 / 備考(使う画面・使わない言い換え)」の3列から始めれば十分です。50語もあれば主要な画面はカバーできます。これを最初に渡しておくと、開発チームも翻訳者も迷わずに済みます。

翻訳の責任範囲とテスト——文字化けとレイアウト崩れは誰が見るか

2つ目は責任範囲です。契約書または仕様書に、次の4つを明記してください。

• 訳文を用意するのは誰か(発注側 / 開発会社 / 機械翻訳 + レビュー)
• 訳文の合否を判定するのは誰か
• 用語集を維持するのは誰か
• 公開後に新しい画面が増えたとき、訳文を追加するのは誰か

3つ目がテストです。多言語対応の不具合は、機能テストでは見つかりません。ボタンからはみ出した文字も、途中で切れたラベルも、プログラムとしては正常に動いているためです。文字化けとレイアウト崩れは、その言語の画面を人が目で見るしかない。だからこの確認は、受入テストの項目として発注側が持つべきです。受入テストの位置づけと進め方は『UATとは』の記事にまとめています。

確認する項目は次の5つで足ります。

1. 各言語で全画面を開き、文字化けがないか
2. ボタン・ラベル・メニューで文字がはみ出したり切れたりしていないか
3. 日付・金額・件数の表示が、その言語の形になっているか
4. 未翻訳のキーがそのまま画面に出ていないか
5. 入力フォームで、その地域の氏名・住所・電話番号が登録できるか

この5項目を、言語ごとに1回ずつ通す。地味ですが、これをやるかどうかで公開後の問い合わせ件数がはっきり変わります。外部チームに渡す仕様の書き方については『オフショア開発 仕様書 書き方』の記事も参考にしてください。

当社の体制——日本語の表現は日本側、実装と確認はベトナム側

当社はベトナム・ホーチミンの開発チームで、日本語のサービスを作っています。日本語を母語としないメンバーが日本語の画面を作るという構造上、言葉の責任分界は最初から明確にしておく必要がありました。現在の分け方は、日本語の表現と用語は日本人PMが持ち、実装と画面の確認はベトナム側のエンジニアが担うというものです。

体制は2パターンあり、日本人PM/ブリッジSEを置いてエンジニアと組む形(推奨)と、エンジニアのみの形を選べます。多言語対応を含む案件では、言葉の判断が頻繁に発生するため前者をお勧めしています。品質面では、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点を標準の工程に入れています。

介護記録SaaSの「CareViewer」では、日本語対応のブリッジSE1名とフルスタックエンジニア2名の体制で、週次で優先順位を見直しながら継続的に開発を進めています。ヘッドレスCMSを使ったWebサイトの構築実績もあります。エンジニアは、グループが持つ2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインしており、協力会社を経由しないため仲介マージンが発生しません。単価は公開しており、実務3年目安で1,500USD(約22.5万円)、5年で2,000USD、10年目安・ブリッジSEで3,000USDです(1USD=150円での換算目安)。1名から、最短2週間で開始でき、契約と支払いは日本国内法人・日本法準拠で海外送金は不要です。

多言語対応については、正直に書いておきます。当社が担えるのは国際化(翻訳できる作りにすること)と、実装後の画面確認までです。英語やベトナム語の訳文の品質保証、特に業界用語や法務に関わる文言の監修は、発注側または専門の翻訳会社の領域だと考えています。この線を先に引いておくほうが、結果として早く進みます。

【FAQ】i18n・多言語対応に関するよくある質問

i18n と多言語対応について、相談の場で繰り返し聞かれる質問を5つにまとめました。社内での説明にもお使いください。

Q1. i18n はなんと読みますか?

「アイ・エイティーン・エヌ」と英語読みするのが一般的です。日本語の会話では「アイ・イチハチ・エヌ」と読まれることもあります。18 は internationalization の i と n の間にある文字数で、W3C の解説にも同じ説明があります。海外のチームと話す場面では英語読みが無難です。

Q2. i18n と l10n はどちらを先にやるのですか?

i18n(国際化)が先です。国際化は「翻訳できる作り」を用意する工程で、地域化(l10n)はその器に実際の訳文と地域ごとの調整を入れる工程だからです。器がない状態で訳文だけ用意しても、入れる場所がありません。要件を決める段階の進め方は『要件定義とは』の記事を参照してください。

Q3. 機械翻訳だけで多言語対応は済みますか?

画面の性格によります。社内向けの業務画面であれば、機械翻訳と事後の修正で回ることが多いです。一方、契約・課金・規約に関わる画面や、ブランドの印象を左右する画面は、人によるレビューを入れたほうが安全です。誤訳が原因で問い合わせが増えれば、節約した翻訳費はすぐに消えます。いずれの場合も、公開前に人が目を通す工程は置いてください。

Q4. 言語を1つ増やす費用はどのくらいですか?

国際化が済んでいるかどうかで桁が変わります。済んでいれば、増えるのは訳文の作成とその言語での全画面テストが中心です。済んでいなければ、文字列の棚卸し、データの持ち方の変更、レイアウトの作り直し、全画面の再テストが同時に発生します。金額を出すには、対象言語・対象範囲・翻訳の担い手・データを多言語にするか・テストの範囲の5項目を先に決める必要があります。

Q5. 日本語と英語だけでも国際化は必要ですか?

必要です。日本語には単数と複数の区別がありませんが、英語には2つの形があり、件数表示を文字列の連結で作っていると英語版で必ず崩れます。日付の書式も入れ替わり、文字列は伸びてボタンからはみ出します。「2言語だから簡単」ではなく、2言語目で国際化の必要性がひととおり表面化する、というのが実際のところ。

まとめ: i18nは「翻訳できる作り」、l10nは「実際に翻訳する」——先に線を引いてから見積もりを読む

i18n は internationalization の略で、18 は i と n の間の文字数です。指しているのは翻訳ではなく、翻訳できる作りにしておくこと。実際にその地域向けに翻訳し調整する作業は l10n(地域化)で、担い手も成果物も別です。国際化が先、地域化が後という順番も変わりません。国際化で作り込むのは、文字コード、文字列の外部化、日付と時刻、タイムゾーン、暦、数値、通貨、単位、住所と氏名と電話番号、並び順、複数形、レイアウトの伸縮と書字方向の12領域です。どれも日本語だけなら表面化しない問題で、日本語決め打ちのコードには入っていません。

後から多言語化すると費用が跳ねるのは、翻訳を足す作業ではなく作りを変える作業になるからです。文字列の棚卸し、データの持ち方の変更、書式の載せ替え、レイアウトの作り直し、全画面の再テストが同時に発生します。逆に、今すぐ多言語にしないとしても、文字コードを UTF-8 に統一する、画面の文言をコードの外に出す、日時は UTC で保存する、の3つだけ入れておけば、後の追加は「言語が増えるだけ」に収まります。見積書の「多言語対応」という一行が約束しているのは、多くの場合ここまでの仕組みであって、訳文の作成・用語の統一・言語ごとのテストは含まれません。スコープを揃えずに金額だけを比べるのは失敗のもとです。

外部のチームで進めるときに発注側が握るのは、用語集、翻訳の責任範囲、そして文字化けとレイアウト崩れのテストの3つです。当社はベトナム・ホーチミンの開発チームで日本語のサービスを作っており、日本語の表現と用語は日本人PMが持ち、実装と画面の確認はベトナム側のエンジニアが担う分け方をしています。訳文の品質保証、とくに業界用語や法務に関わる文言の監修は発注側または翻訳会社の領域だと考えており、そこは正直にお伝えしています。外部チームを継続的に持つ体制についてはラボ型開発とは、見積もりの読み方はシステム開発の見積もりの内訳もあわせてご覧ください。現在の体制と要件をお聞かせいただければ、多言語対応を含めてどこまでを開発側で担えるか、概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。