LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

アプリの多言語化・ローカライズとは — 翻訳だけでないi18nとl10nの違い

モバイルアプリの多言語化・ローカライズとは、アプリを複数の言語・地域に対応させるための開発・翻訳・デザイン調整の一連の取り組みを指します。単に表示テキストを別言語に差し替えるだけでなく、日付・通貨・単位の地域形式、RTL（右から左）レイアウト、文化差に応じた画像・アイコンの見直しまで含む包括的な工程です。

よく混同される用語として「i18n」と「l10n」があります。i18n（internationalization＝国際化）は、アプリを特定の言語・地域に依存しない構造に整えることです。文字列を外部ファイルに切り出したり、日付・通貨のフォーマットをロケール設定から取得するように改修したりする工程が含まれます。

l10n（localization＝地域化）は、i18nで整えた枠組みに各言語・地域向けのコンテンツを当てはめる工程です。翻訳テキストの作成・地域通貨への対応・地域に適した画像への差し替えなどが含まれます。i18nが先に完了していないとl10nを効率よく進めることができないため、外注依頼の前に自社アプリのi18n完了状況を確認することが大切です。

また、多言語化対応はリリース後の機能追加のたびに継続的なメンテナンスが発生する点も見落とされがちです。新機能のテキストを追加するたびに翻訳依頼・確認・反映のサイクルが必要になるため、継続運用も含めた外注体制の設計が求められます。

iOS/Androidのローカライズ仕組み — String Catalog・strings.xml・RTL・複数形

iOSとAndroidはそれぞれ固有のローカライズ機能をプラットフォームが提供しており、仕組みと実装方法が異なります。外注で進める際も、どちらのOSに対応するかによって必要な知識・工数・確認項目が変わります。

iOS：String Catalog（.xcstrings）とXcodeの管理機能

Appleの公式開発ドキュメントによると、Xcode 15以降はString Catalog（.xcstringsファイル）が文字列管理の推奨方式です^*1。従来の.stringsファイルや.stringsdictファイルを.xcstringsに統合して管理する方式に移行しています。String CatalogはJSON形式で複数言語の翻訳を一元管理でき、Xcode上でローカライズの進捗状況を一覧確認できます。

iOSのローカライズ対応では、文字列だけでなく複数形（Pluralization）への対応も必要です。たとえば「1件のメッセージ」「3件のメッセージ」のような数量に応じた表現の切り替えは、言語によってルールが異なります。英語は単数・複数の2形ですが、アラビア語には6形、ロシア語には4形のルールがあります。.xcstringsは複数形ルールを言語ごとに記述できる構造になっています。

日付・数値・通貨の表示は、Swiftの`DateFormatter`・`NumberFormatter`などのフォーマッタクラスを使ってロケール設定に基づき自動変換するのが推奨の実装です。ハードコードした日付形式（例：「YYYY/MM/DD」固定）を使うと、地域設定に応じた適切な表示にならないため修正が必要になります。

Android：resディレクトリとstrings.xml

Android Developersの公式ガイドによると、Androidのローカライズはリソース修飾子（Resource qualifiers）を使った`res`ディレクトリの構成によって実現します^*2。言語・地域ごとに`res/values-<言語コード>/strings.xml`を配置する構成で、たとえば日本語は`res/values-ja/strings.xml`、フランス語は`res/values-fr/strings.xml`と命名します。地域をさらに絞る場合は`res/values-fr-rFR/strings.xml`のようにリージョンコードを付加します。

Androidも複数形に対応するための`plurals`リソースを提供しています。英語・日本語・アラビア語などで異なる複数形ルールを言語ファイルで定義でき、コード側では`getQuantityString`を使って自動的に適切な形を取得できます。

RTL（右から左）レイアウトへの対応

アラビア語・ヘブライ語・ペルシャ語など、文字を右から左（RTL）に読む言語向けには、UI全体のレイアウトを左右反転させる対応が必要です。iOSではAutoLayoutのleading/trailing制約を正しく使うことで、システムがRTL言語のときに自動的に反転させます。Androidでは`android:supportsRtl=”true”`を宣言し、`start`/`end`属性を使うことで対応します（公式ガイド推奨）。

RTL対応では文字の方向だけでなく、アイコンの向き・スクロール方向・アニメーションの動きも確認が必要です。たとえば「次へ進む」を表す右矢印アイコンは、RTL環境では左矢印に反転させる必要があります。実機またはエミュレーターでRTLモードを有効にした動作確認を外注プロセスに組み込むことが大切です。

外注で進める流れ — 文字列外部化から翻訳連携・RTL検証・継続更新まで

多言語化対応を外注で進める場合、工程を明確に分割して発注範囲を定めることが重要です。一般的に以下の5工程で進めます。

STEP 1：文字列外部化とi18n基盤の整備

最初の工程は、アプリ内のハードコードされた文字列をすべて外部リソースファイルに移す作業です。iOSであれば.xcstringsファイル、Androidであれば`strings.xml`に文字列を切り出します。画面数が多いアプリでは文字列の洗い出しだけで相応の工数がかかるため、外注先に現状調査（i18n診断）から依頼することが有効です。

この工程では日付・数値・通貨のフォーマットがハードコードされていないかも合わせて確認します。フォーマッタクラスを使ったロケール対応への修正が必要な箇所をリストアップしておくと、後続工程がスムーズに進みます。

STEP 2：翻訳会社との連携と地域化コンテンツの作成

文字列外部化が完了したら、翻訳ファイルを翻訳会社に渡す工程に入ります。iOSではXcodeの「Export Localizations」機能でXLIFF（XML Localization Interchange File Format）形式で書き出し、翻訳後にインポートできます。Androidでは`strings.xml`を言語ごとにコピーして翻訳会社に渡す形が一般的です。

翻訳と並行して、地域ごとの通貨単位・日付形式・電話番号形式への対応と、文化的に不適切な画像・アイコンがないかの確認も必要です。外注先がアプリ開発と翻訳調整の両方に対応できるかを事前に確認してください。

STEP 3：RTLおよびUI崩れの検証

翻訳テキストを組み込んだ後は、RTL言語モードと各言語での画面表示を確認します。iOSのシミュレーターやAndroidエミュレーターでシステム言語を対象ロケールに切り替えて全画面を確認します。文字数増加によるボタン・ラベルのはみ出し、アラビア語等でのレイアウト反転、アイコンの向き不整合を順に確認していきます。

問題が多い場合は修正→再確認のサイクルが複数回発生します。外注契約では検証・修正のサイクル回数と対象言語を明記しておくことがトラブル防止に有効です。

STEP 4：App Store / Google Playのストア対応

アプリ本体の対応が完了したら、各ストアのアプリ説明文・スクリーンショット・キーワードも対象言語に対応させます。App Store ConnectとGoogle Play Consoleはそれぞれ言語ごとのメタデータ入力フォームを用意しています。ストアページの翻訳品質はインストール転換率に影響するため、機械翻訳のみに頼らずネイティブチェックを入れることが大切です。

STEP 5：継続的な翻訳更新体制

機能追加のたびに新しい文字列が発生するため、差分翻訳の依頼フローを定型化しておく必要があります。翻訳管理ツール（TMS）を導入して文字列ファイルと連携させると、追加・変更された文字列のみを自動抽出して翻訳依頼できます。外注先が差分対応を含めた保守契約を提供しているかは、初期選定の段階で確認すべき重要な観点です。

つまずきやすい落とし穴 — ハードコード・文字数増・日付/通貨・翻訳更新フロー

多言語化対応で実際に問題になりやすい箇所は、事前に把握して設計・外注仕様に反映しておくことで対処できます。代表的な4つの落とし穴を整理します。

ハードコードされた文字列の見落とし

エラーメッセージ・確認ダイアログ・プッシュ通知本文・ストア評価を促すメッセージなど、開発初期にコード内に直接埋め込まれた文字列が残っていることがあります。これらはローカライズ対象として認識されにくく、初回のi18n対応で見落とされる頻度が高い箇所です。

静的解析ツールや専用のローカライズ監査ツールを使って洗い出すことが有効です。外注先にi18n診断を依頼する際は、動的生成される文字列（APIレスポンスを直接表示しているケースなど）も確認対象に含めるよう明記してください。

文字数増加によるUI崩れ

英語の文字列を他言語に翻訳すると、文字数が増える場合があります。固定幅に設定されたボタン・タブラベル・ナビゲーションタイトルが翻訳後にはみ出す、または折り返してレイアウトが崩れる問題は頻繁に発生します。

対策として、翻訳前にPseudo-localization（疑似ローカライズ）を行う方法があります。実際の翻訳の代わりに元テキストを人工的に長くした仮テキストを使ってUI崩れを事前検出します。iOSのXcodeとAndroid Studioはどちらも疑似ローカライズモードをサポートしています。外注工程に疑似ローカライズによる事前確認を含めるよう発注仕様に盛り込むことが有効です。

日付・数値・通貨のフォーマット不整合

日付表示（年月日の順序・区切り文字）、数値の桁区切り（コンマと小数点の使い方が言語地域によって逆になる場合がある）、通貨記号の位置はロケールによって異なります。ハードコードされたフォーマット指定が残っている場合、英語圏以外では不自然な表示になります。

SwiftとKotlinはどちらもロケールを考慮したフォーマッタAPIを標準で提供しています。外注先がローカライズ対応の実装経験を持つかどうかは、このフォーマッタAPIの活用実績で確認するのが効率的です。

翻訳更新フローの未整備による作業の属人化

初回ローカライズ対応後に翻訳更新フローを定義していないと、機能追加のたびに作業が担当者ごとのやり方になり、翻訳漏れや品質のばらつきが発生します。外注先に継続対応を依頼する場合は、差分翻訳の依頼方法・確認フロー・リリースサイクルへの組み込み方を契約前に合意しておく必要があります。

外注の使いどころ — 実装・翻訳連携・検証の委託判断軸

多言語化対応を外注するかどうかは、自社エンジニアのローカライズ実装経験・対応言語数・リリーススケジュールによって判断が変わります。以下では委託が有効な場面と内製が現実的な場面を整理します。

内製が現実的な場面

対応言語が日本語・英語の2言語のみで、自社エンジニアがiOSまたはAndroidのローカライズAPIに習熟している場合は、内製対応が現実的な選択肢になります。ただし、翻訳品質の確認（ネイティブチェック）と継続的な更新フローの整備は内製・外注に関わらず必要です。

また、すでにi18n基盤が整備されているアプリへの追加言語対応（l10nのみ）は、翻訳ファイルを翻訳会社に依頼して自社で組み込む形が取りやすい場合があります。一方、i18n基盤が未整備のアプリに対して初めて多言語化対応を行う場合は、設計段階から外注先に入ってもらう方が手戻りを防ぎやすい状況です。

外注先の選定で確認する観点

外注先を選ぶ際は、iOS/Androidの両OS対応実績・RTL対応経験・翻訳会社との連携フロー・継続保守への対応可否を確認することが重要です。ローカライズ対応は開発完了後も継続的な作業が発生するため、初期費用だけでなく保守・運用体制まで含めて評価することが長期的なコスト最適化につながります。

要件定義段階での見積もりには、対象言語数・OSの種類・文字列数の目安・RTL対応の有無・ストアページ翻訳の要否を整理して伝えると精度が上がります。アプリ受託開発・国際化対応の知見

まとめ：モバイルアプリ多言語化外注で押さえる3つの判断軸

本稿では、モバイルアプリの多言語化・ローカライズの仕組みと外注で進める流れを整理しました。要点を3つに集約すると次の通りです。

第一に、多言語化はi18n（国際化）とl10n（地域化）の2段階で進めることが前提で、i18n基盤が整っていない状態でl10nを進めると後から大きな手戻りが発生します。外注前に自社アプリのi18n完了状況を確認することが先決です。

第二に、iOSはXcode 15以降推奨のString Catalog、AndroidはresディレクトリのXMLリソース方式という異なる仕組みを持ちます。RTL対応・複数形・日付/通貨フォーマットはプラットフォーム公式のAPIを使う実装が必要で、ローカライズ経験のある外注先かどうかの確認が重要です。

第三に、ローカライズ対応はリリース後も継続的なメンテナンスが発生します。初回対応だけでなく差分翻訳・UI検証・ストア対応の継続フローまで含めて外注体制を設計することが、長期的なコスト最適化と品質維持につながります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Apple Developer「Localizing and varying text with a string catalog」（Apple Developer Documentation）
2. *2　出典：Android Developers「Localize your app」（Android Developers Documentation）

Tweet