ローカライズとは？翻訳・国際化との違いと対象範囲・実施可否の判断基準

ローカライズは、製品やサービスを対象地域の言語・表記習慣・法規に合わせて作り替える一連の作業を指します。この記事ではソフトウェア、Webサイト、業務システムを対象に、翻訳との線引き、国際化（i18n）との作業順序、どこまでを対象範囲に含めるかの判断軸を整理しました。費用が膨らむ変数、URL設計と言語切替で先に決めるべき条件、そして見送ってよい場面まで、発注側が意思決定するために必要な材料をまとめています。ゲームや映像作品のローカライズにも同じ語が使われますが、ここでは扱いません。

まとめ：ローカライズは対象範囲と国際化対応の有無で費用が決まる

ローカライズの費用と期間を左右するのは、翻訳する文字量ではありません。対象範囲をどこで区切るか、そして製品側に国際化（i18n）の下地があるかどうか、この2点でほぼ決まります。文字列がソースコードに直書きされたままの製品では、翻訳作業の前に改修工程が入り、見積りは言語数に比例せず跳ね上がります。

判断の順序は決まっています。まず国際化の対応状況を点検し、次に対象範囲を主要導線に絞り込み、最後に言語を選ぶ。この逆順で進めた案件が、公開直前に文字化けやレイアウト崩れで止まります。

実施可否についても線を引けます。対象言語圏からの利用が全体の数%に届かず、対象画面の更新が週次で走るサービスなら、全面ローカライズは見送ってよい判断です。翻訳された古い情報が放置される状態は、英語ページが無い状態より信用を損ないます。以降の章では、この結論に至る根拠と、範囲の決め方を具体的に説明します。

ローカライズとは何か｜翻訳との違いと対象になる要素の全体像を整理

まず語の範囲を確定させます。ローカライズ（localization）は、対象地域で違和感なく使える状態を作る作業全体を指し、その一部として翻訳が含まれる、という包含関係です。

ローカライズの定義｜言語だけでなく表記・単位・法規まで作り替える範囲

ローカライズが扱うのは、大きく3つの領域です。1つ目が言語、つまり翻訳。2つ目が表記の規約で、日付の並び順、小数点と桁区切り記号、通貨記号の位置、氏名の姓名順、住所の記述順、電話番号の書式が該当します。3つ目が法規と商習慣で、個人情報の同意取得画面、特定商取引法に相当する各国の表示義務、税の内税・外税表示などが入ります。

この3領域の切り分けは、実務でそのまま作業分担になります。1つ目は翻訳者、2つ目はエンジニア、3つ目は現地の法務や販売代理店。1つの発注先が全部を担うわけではないため、範囲を曖昧にしたまま「ローカライズをお願いします」と依頼すると、表記規約と法規対応が誰の担当でもない状態で残ります。

表記規約については、地域ごとの書式データがUnicode CLDRとして公開されています。2026年3月時点で48系が公開されており、日付・数値・通貨の書式や地域名の訳語はロケール単位で整理済みです。実装側はこのデータを参照する仕組みを使うため、表記規約の大半は手作業ではなくロケール設定の切り替えで処理できます。

対象要素ごとの改修量の差｜UI文言・日付/通貨・画像・帳票の4領域

ローカライズの見積りを読むときは、要素ごとに作業の性質が違う点を押さえておくと判断を誤りません。同じ「1画面ぶん」でも、必要な工数は数倍変わります。

実務でまず削れるのは画像です。文字を画像に焼き込む設計をやめ、画像の上にテキストを重ねる構造へ変えておけば、言語追加のたびに発生するデザイン作業が消えます。既存サイトの改修では、この判断だけで初期費用が数十万円単位で変わることがあります。

国際化(i18n)とローカライズ(l10n)の役割分担と作業が発生する順序

i18nはinternationalization、l10nはlocalizationの略記で、先頭と末尾の文字の間にある文字数を数字にした書き方です。この2語を混同したまま発注すると、後述する二重改修が起こります。

国際化(i18n)が担う設計と、ローカライズ(l10n)が担う地域差の実装

国際化は「どの地域にも対応できる構造を作る」設計側の作業です。文字列をコードから切り離して外部ファイルに置く、文字コードをUTF-8に統一する、日付や数値をロケール指定で出力する、可変長のテキストが入っても崩れないレイアウトにする。ここまでが国際化の範囲で、この段階では特定の言語は登場しません。

ローカライズは、その構造の上に個別地域の中身を入れる作業です。ja-JP、en-US、zh-Hansといったロケール識別子ごとに訳文と書式を用意していきます。この識別子の書き方はBCP 47として標準化されており、言語コード（ISO 639-1）と地域コードの組み合わせで表します。中国語のように簡体字と繁体字で分かれる場合は、地域ではなく文字体系のコードを使う点に注意が必要です。

複数形の扱いは国際化側の設計問題です。日本語は単数と複数を区別しませんが、英語は2種類、ロシア語やアラビア語はさらに多くの形を持ちます。「3件のメッセージ」を文字列連結で組み立てる実装は、英語対応の時点で破綻します。ICU MessageFormatのような、数に応じて文形を切り替える記法を最初から使う設計が必要です。フレームワーク側の実装手順は、i18n（国際化）とは何か？Angularアプリでの必要性と基本的な仕組みで具体的なコード構成まで解説しています。

翻訳の発注で足りる成果物と、ローカライズが必要になる成果物の見分け

すべての成果物にローカライズが要るわけではありません。判断は「その成果物が動作するか、読まれるだけか」で分かれます。

• 翻訳の発注で足りるもの：会社案内、プレスリリース、契約書、技術文書のうち読み物として完結するもの
• ローカライズが必要なもの：アプリやWebサービスのUI、業務システムの入力画面と帳票、ECの購入フロー、サポートサイトの検索機能を伴うページ

境界にあるのがマニュアルです。紙のPDFなら翻訳で済みますが、製品画面のスクリーンショットを含む場合は、画面側のローカライズが終わっていないと撮り直しができません。マニュアル翻訳を先に発注して、画面の訳語が後から変わり、全図版を差し替える。この手戻りは案件でよく起きます。訳語集（用語集）を画面側で先に確定させ、それを翻訳会社へ渡す順序で回避できます。

ローカライズの対象範囲を決める判断軸と、費用が膨らむ3つの変数

見積りが読めない理由は、範囲の定義が曖昧なまま言語数だけで話が進むからです。費用を動かす変数は3つに絞り込めます。

対応言語数・対象画面数・法規対応で決まる見積りの増え方と概算の考え方

1つ目が対応言語数。ただし単純な比例ではありません。1言語目には文字列の外部化やレイアウト調整という初期投資が乗るため最も高く、2言語目以降は訳文の追加が中心になって単価が下がります。逆に、右から左へ書くアラビア語やヘブライ語を含めると、レイアウトの左右反転という別工程が発生して単価が跳ね上がります。

2つ目が対象画面数。管理画面まで含めるか、利用者が触れる画面に限るかで総量が変わります。社内担当者しか使わない管理画面は日本語のまま残す判断が現実的で、ここを切るだけで対象が半分以下になるケースもあります。

3つ目が法規対応。EU圏を対象にするならGDPRの同意取得、決済を伴うなら各国の表示義務と税処理が必要です。この領域は翻訳作業ではなく要件定義と実装の話で、言語追加とは別枠で見積る必要があります。海外向けの物販を伴う場合の要件は範囲が広く、越境ECサイト構築の進め方｜多言語・海外決済・関税要件と失敗回避の判断軸で決済と関税まで含めて整理しています。

全画面を一括で訳さず主要導線から着手する優先順位の付け方と基準

全画面を一度に対象へ入れる進め方は勧めません。訳文の品質確認が追いつかず、公開が遅れ、公開後の更新も止まります。着手順は次の基準で決めます。

1. 成果に直結する導線：トップから問い合わせ・購入完了までの一本道。ここだけは訳文の品質を人手で保証する
2. 利用者が判断に使う情報：製品仕様、価格、対応環境、サポート範囲。誤訳が意思決定を誤らせる領域
3. 更新頻度が低い静的情報：会社概要、アクセス、採用情報
4. 更新頻度が高い読み物：ブログ、事例、ニュース。ここは後回しにするか、対象から外す

4番目を最初に手を出すと運用が破綻します。週次で増える記事を毎回翻訳し続ける体制は、外注でも内製でも維持が難しく、半年で更新が止まります。訳が止まった記事一覧が残るくらいなら、最初から対象外にして日本語のみで運用するほうが読者の判断を妨げません。

Webサイトのローカライズ｜URL設計と言語切替で先に決める運用条件

Webサイトの場合、翻訳作業の前に決めておかないと後戻りできない設計項目があります。URLの持ち方と、言語切替の仕組みです。

サブディレクトリ・サブドメイン・ccTLDのURL設計の選び方と条件

3つの選択肢には、それぞれ向く条件があります。

現地法人を持たない日本企業が英語ページを追加する段階なら、サブディレクトリで始める判断が妥当です。ccTLDは、現地に運用担当がいて独立した更新体制を組める場合に限るべきです。ドメインを分けた結果、更新できる人が日本に1人しかいない構成は、公開後に必ず止まります。制作工程全体の進め方と費用感は多言語サイト制作とは？進め方・費用相場と言語・URL設計の判断基準にまとめています。

hreflangと言語切替UIで起きる実装ミスと、公開前に確認する項目

hreflangは、同じ内容の別言語版がどこにあるかを検索エンジンへ伝える指定です。<link rel="alternate" hreflang="en" href="..."> の形でhead内に置くか、サイトマップやHTTPヘッダーで指定します。落とし穴は相互参照の要件で、日本語ページから英語ページへ指定するだけでは足りず、英語ページから日本語ページへの指定も必要です。片方向だけの記述は無視されます。

言語が特定できない利用者向けの受け皿として、hreflang="x-default" を1つ指定しておく運用も併せて検討します。指定漏れ自体は不具合になりませんが、地域判定に迷った場合の着地先を決められません。

言語切替UIでよくある失敗は、どのページからでもトップページへ飛ばす実装です。英語版の製品ページを見ている利用者が切替ボタンを押して日本語トップに戻される構造は、離脱の直接原因になります。対応する言語版ページへ1対1で飛ばす実装にし、対応ページが無い場合は切替候補に出さない。ここまで含めて設計するのが実務です。自社での判断が難しい場合は、英語サイト制作・多言語サイト制作のように、URL設計と運用体制の設計から入る制作会社に相談する進め方があります。

国際化を飛ばして翻訳から始めた案件が高くつく理由と着手前の確認項目

ここからは、上位の解説記事では手薄な論点を扱います。ローカライズの失敗で最も金額が動くのは、訳文の品質ではなく着手順の誤りです。

文字列のハードコードとレイアウト固定が招く二重改修のコスト構造

国際化を経ていない製品に翻訳から着手すると、作業が2回発生します。1回目は訳文を用意する作業。2回目は、その訳文を入れる場所がないと分かってからの改修作業です。

典型的な症状は3つあります。文字列がテンプレートやコードに直書きされていて差し替え箇所を機械的に抽出できない。ボタンやナビゲーションの幅が日本語の文字数前提で固定されていて、ドイツ語やフランス語の長い訳語が入ると折り返して崩れる。データベースの照合順序や文字数制限が日本語前提のままで、多バイト文字の扱いが揃わない。

この改修は、訳文を発注した後では見積り直しになります。翻訳費用そのものは支払い済みで、そこに改修費が上乗せされる構造です。国際化を先に済ませていれば、改修は1回で終わり、2言語目以降の追加費用も下がります。順序を守る判断は、そのまま総額の差になって現れます。

着手前に確認する国際化対応の状況｜コード・DB・帳票の3つの点検箇所

発注前に自社側で確認できる項目があります。開発ベンダーへ依頼する前に、次を社内の開発担当か既存ベンダーへ質問してください。

• コード：画面に出る文字列は外部ファイル（言語リソース）に分離されているか。直書きが残っている画面数はどれくらいか
• データベース：文字コードはUTF-8系で統一されているか。氏名・住所の項目に日本語前提の文字数制限や姓名分割が入っていないか
• 帳票・メール：テンプレートはA4固定か。フォントは埋め込みか、サーバー側の日本語フォントに依存しているか

この3点の回答が揃えば、見積りの精度が変わります。3つとも「対応済み」なら、ローカライズは訳文と表記書式の作業に収まります。どれか1つでも「未対応」があるなら、その改修を別工程として先に切り出し、翻訳の発注はその後に回してください。

ローカライズを見送ってよい条件と機械翻訳だけで公開して失敗する場面

ローカライズは、やらない判断も含めて設計するものです。ここでは条件を明示して結論を出します。

ローカライズを見送ってよい条件｜利用者数・売上比・更新頻度の基準

次の3条件が重なる場合、全面ローカライズは見送ってかまいません。海外からのアクセスが全体の数%程度にとどまり、そこからの売上や問い合わせが事業計画に組み込まれていない。対象にしたい画面や記事の更新が週次以上で発生する。訳文を確認できる担当者が社内にいない。

この状態で公開に踏み切ると、半年後には英語ページだけ情報が古い状態になります。価格や仕様が日本語版と食い違ったまま残るのは、ページが無い状態より不利です。代わりに取れる手はあります。問い合わせフォームと会社概要だけを英語化し、詳細は個別対応に回す。この最小構成なら維持できます。

逆に、着手すべき条件も明確です。海外代理店や現地パートナーとの商談で自社サイトを見せる場面がある。既に海外からの問い合わせが月数件届いている。この2つのいずれかに当てはまるなら、範囲を主要導線に絞って着手する判断が妥当です。

機械翻訳のみで公開して失敗する場面と、人手レビューを必須にする範囲

機械翻訳の品質は実用域に入っていますが、無条件に任せてよい範囲は限られます。人手レビューを必須にすべきなのは次の領域です。

1つ目が金額と契約条件を含む記述。価格表、支払条件、返品条件、保証範囲。ここの誤訳は金銭的な紛争に直結します。2つ目が法的表示。個人情報の取り扱い、免責事項、各国の表示義務にかかる文言。3つ目が製品の安全性や動作条件に関する記述で、業務システムや機器の操作手順が該当します。

反対に、機械翻訳で公開してよい範囲もあります。過去のニュース記事、更新が止まっている事例紹介、社内向けの補助的なドキュメント。読み違えても損害が生じない領域です。

ここは条件を付けて言い切ります。ブラウザの翻訳機能に任せる前提で、原文だけを公開する運用は避けてください。制御できない訳文が製品名や価格に適用され、それが自社サイトの表示として読まれます。訳文を自社で管理下に置き、金額と法的表示だけは人手で確認する。この線引きが、費用と信頼のバランスが取れる運用です。

ローカライズでよくある質問｜翻訳との違い・費用・機械翻訳の疑問

ローカライズの検討でよく寄せられる質問を、実務での回答としてまとめました。

ローカライズとローカリゼーションは同じ意味として使ってよいですか？

同じ意味です。localizationの日本語表記の揺れで、「ローカライゼーション」も同じ対象を指します。IT分野の実務では「ローカライズ」、翻訳業界や学術文脈では「ローカリゼーション」が使われる傾向がありますが、内容の違いはありません。略記のl10nも同義で、文書やコードのフォルダ名で見かけます。社内資料では表記を1つに統一しておくと、発注仕様書での誤解を防げます。

ローカライズと翻訳は、どちらを先に外部へ発注すればよいですか？

製品やWebサイトが対象なら、国際化（i18n）の対応状況を確認してから翻訳を発注してください。文字列がコードに直書きされた状態で訳文だけ用意しても、差し込む場所がなく改修が別途発生します。順序としては、国際化の点検、対象範囲の確定、用語集の作成、そのうえで翻訳の発注です。読み物として完結する会社案内やプレスリリースだけなら、翻訳の単独発注で問題ありません。

ローカライズの費用はどのような内訳で決まり、何を確認すべきですか？

内訳は、国際化のための改修費、翻訳費、表記書式やレイアウトの調整費、そして公開後の更新運用費に分かれます。見積りを比較するときは、翻訳の単価ではなく改修費と運用費の前提を確認してください。特に「1言語目の初期費用に何が含まれるか」で総額が変わります。管理画面を対象に含めるか、帳票やメールテンプレートを含むか、この2点を仕様書で明記すると見積りの幅が縮まります。

ゲームのローカライズとソフトウェアのローカライズは何が違いますか？

作業の対象と品質基準は別物です。ゲームでは世界観に合わせた台詞の再創作、音声収録、文化的表現の差し替えといった創作寄りの工程が中心で、原文からの離れ方が許容されます。業務ソフトウェアやWebサイトでは、用語の一貫性と操作手順の正確さが優先され、原文から離れた意訳は不具合の原因です。この記事で扱っているのは後者で、発注時も両者を得意とする会社は異なります。

AI翻訳だけでローカライズを済ませても品質は保てるものですか？

領域を限れば実用的です。過去のニュースや事例紹介など、誤読が損害につながらない読み物であれば機械翻訳のみの公開でも運用できます。ただし価格・契約条件・法的表示・製品の安全に関わる記述は、人手のレビューを必須にしてください。加えて、機械翻訳は表記書式や画像内の文字を処理しないため、日付形式や通貨表示、文字入り画像はローカライズの工程として別に扱う必要があります。

関連記事

• 多言語サイト制作とは？進め方・費用相場と言語・URL設計の判断基準：ローカライズを実際にWebサイトで進める際の工程と費用相場をまとめています。
• i18n（国際化）とは何か？Angularアプリでの必要性と基本的な仕組み：国際化の実装をフレームワーク上でどう組むかを、コード構成まで踏み込んで解説しています。
• 越境ECサイト構築の進め方｜多言語・海外決済・関税要件と失敗回避の判断軸：物販を伴う場合に追加で必要になる決済・関税・法規要件を整理しています。