OpenL logo

モバイルアプリをローカライズする方法

OpenL Team 3/14/2026

TABLE OF CONTENTS

モバイルアプリのローカライズ方法を検索しているなら、おそらく「翻訳のコツ」は必要ないでしょう。必要なのは、アプリ文字列、レイアウト、複数形ルール、右から左（RTL）のサポート、スクリーンショット、ストアメタデータをカバーし、プロダクトを壊さないリリース対応のワークフローです。

ここが重要な区別です。モバイルアプリのローカライズとは、単にテキストを翻訳することではありません。アプリ、プロダクトページ、QAプロセスをターゲット市場ごとに適応させることです。Appleによると、App Storeは175の地域と40の言語で利用可能であり、Android 13ではシステムレベルのアプリごとの言語設定が導入されました。つまり、両方の主要プラットフォームは今や、言語選択を付随的なものではなく、コアなプロダクト体験として位置づけています。

このガイドでは、iOSとAndroidチーム向けの実践的な手順を解説します。

概要：

  • アプリ内のローカライズとApp Store・Google Playのローカライズを分けて考える。
  • 翻訳を始める前に文字列を外部化する。
  • 複数形、変数、日付、通貨、RTLに早い段階で対応する。
  • 実際の翻訳を投入する前に疑似言語でテストする。
  • 説明文だけでなく、スクリーンショットやストアアセットもローカライズする。

モバイルアプリのローカライズに実際含まれるもの

ローカライズ作業は通常、2つのトラックに分かれます。

1. アプリ内ローカライズ

これはプロダクトそのものです：

  • UI文字列
  • エラーメッセージとオンボーディングコピー
  • 日付、時刻、数値、通貨、単位
  • 複数形および性別に依存する文字列
  • レイアウトの拡張と右から左への動作
  • テキストや方向的な意味を含む画像やアイコン

Appleは、グローバル市場向けにアプリを準備するために、Xcode、Foundation API、Auto Layout、Unicodeサポート、ローカライズされたアセットカタログ、方向対応シンボルの使用を明示的に推奨しています。Androidも同様に、ハードコードされたテキストや配置ではなく、ロケール対応リソース、アプリ言語サポート、RTL対応レイアウトの使用を推奨しています。

2. ストアリスティングのローカライズ

これはユーザーがアプリを発見する方法です：

  • アプリ名
  • サブタイトルまたは短い説明
  • 詳細説明
  • キーワード
  • スクリーンショット
  • アプリプレビューまたはプロモーション動画

これは別の成果物として扱いましょう。よくローカライズされたアプリでも、プロダクトページが汎用的で未翻訳であったり、ターゲット市場と視覚的にミスマッチであれば、パフォーマンスが低下する可能性があります。

翻訳ではなく、国際化から始める

翻訳は、構造から始まるパイプラインの最後のステップです。

文字列を外部化し、完全なフォールバックロケールを維持する

Androidでは、Googleはデフォルトのres/values/strings.xmlにアプリが必要とするすべての文字列を定義するよう警告しています。デフォルトファイルが不完全で、デバイスがサポートされていないロケールで動作している場合、アプリの読み込みに失敗し、強制終了ボタン付きのエラーが表示されることがあります。だからこそ、ローカライズは言語選択ではなく、リソースの衛生管理から始まるのです。

iOSでは、Appleはユーザーに表示されるテキストや画像を実行可能コードから分離し、リソースファイルとしてローカライズできるようにすることを推奨しています。最新のAppleのワークフローでは、Xcode 15以降でString Catalogが複数形を含む文字列に推奨されるアプローチです。

実践的なルール：

  • UIテキストをビューやコントローラーにハードコードしない
  • 1つの正式なソース言語を維持する
  • すべてのユーザー向け文字列に安定したキー、コンテキスト、フォールバックを持たせる
  • 曖昧な文字列には翻訳者向けのコメントを含める

小さな例で具体的にイメージしてみましょう。

Androidでは通常、デフォルトのstrings.xmlファイルから始めます：

<!-- Primary CTA on the checkout screen. Keep it short. -->
<string name="checkout_cta">Pay now</string>
<string name="welcome_title">Welcome back, %1$s</string>

次に、UIは英語をハードコードする代わりにリソースを読み取ります：

Text(text = stringResource(R.string.checkout_cta))

Appleプラットフォームでは、Xcode 15以降は同じ考え方をString Catalogで管理することが多くなっています。簡略化したLocalizable.xcstringsの抜粋は次のようになります：

{
  "sourceLanguage": "en",
  "strings": {
    "Pay now": {
      "localizations": {
        "en": { "stringUnit": { "value": "Pay now" } },
        "fr": { "stringUnit": { "value": "Payer maintenant" } }
      }
    }
  }
}

ファイルフォーマットを暗記する必要はありません。運用上の教訓はもっとシンプルです。すべてのユーザー向け文字列には、信頼できる唯一のソース、翻訳者への十分なコンテキスト、ロケールが不完全な場合の安全なフォールバックが必要です。

アプリが構造化された言語ファイルも出荷している場合は、2026年のベストJSONトランスレーターのガイドが自動化とフォーマット保持について考えるのに役立ちます。

アプリリソースファイル向けのツールオプションとしては、OpenL JSON Translatorが注目に値します。キーや構造を壊さずに.jsonファイルを翻訳するために設計されており、アプリの文字列が機械可読なローカライズファイルに保存されている場合にまさに必要なものです。ワークフローはシンプルです。アプリ、CMS、またはローカライズパイプラインからエクスポートしたJSONをアップロードし、ターゲット言語を選択し、同じ構造の翻訳済みJSONファイルをダウンロードします。プロダクトページによると、100以上の言語と最大50MBのファイルに対応しており、構造化コンテンツを扱うアプリローカライズチームにとって実用的なファーストパスツールです。

アプリレベルの言語選択をサポートする

ユーザーは、デバイスの言語とは別にアプリの言語を選択できることをますます期待しています。

Appleプラットフォームでは、ユーザーはデバイスの言語とは独立して、アプリの優先言語を選択できます。Androidでは、Android 13で一元化されたアプリ言語設定が追加され、Googleは自動的なアプリごとの言語サポートを有効にするか、ピッカーを公式APIに接続することを推奨しています。

これは実際のプロダクトにとって重要です。バイリンガルやマルチリンガルのユーザーは、スマートフォンを英語のまま使いながら、ショッピング、バンキング、デリバリーアプリは別の言語で使いたいと思うかもしれません。アプリが1つの言語モデルを強制すると、翻訳品質が問題になる前にフリクションを生んでしまいます。

プラットフォームのローカライズスタックを使う

本当に必要でない限り、並行したローカライズシステムを独自に作ろうとする衝動を抑えましょう。

ほとんどのチームにとって、デフォルトのプラットフォームスタックで十分です：

  • iOS：String Catalog、Localizable.strings、.stringsdict、Foundationフォーマッター、Auto Layout
  • Android：res/values/、ロケール固有のリソースフォルダ、LocaleConfig、setApplicationLocales()、supportsRtl

カスタムローカライズインフラは非常に大規模な場合に意味がありますが、運用オーバーヘッドが増えます。ネイティブシステムから始めて、本当に困った時にだけ拡張しましょう。

ほとんどのチームが見落とすパーツをローカライズする

チームは表示されている文章を翻訳しても、その周りのプロダクトの仕組みを見落としがちです。

複数形、変数、文法

複数形ルールは普遍的ではありません。Unicode CLDRの複数形ルールはzero、one、two、few、many、otherなどのカテゴリを定義しており、言語によって使用するサブセットが異なります。Appleは、古い.stringsdictワークフローではotherが唯一の必須カテゴリであると述べていますが、言語固有のカテゴリをスキップすると文法的に誤った出力が生成される可能性があります。AndroidとiOSの両方がロケール対応の複数形処理に依存しているのには理由があります。

ここが素朴な機械翻訳が破綻するポイントです：

  • 1 file vs 2 filesは英語では簡単
  • スラヴ系言語は3つ以上の複数形が必要なことが多い
  • 一部の言語は名詞、動詞、または周囲の単語を一緒に変化させる

"You have " + count + " messages"のようにフラグメントを連結して複数形のUIを構築してはいけません。代わりにプラットフォームの複数形リソースを使いましょう。

各プラットフォームでの最小限の形は次のとおりです。

Android：

<plurals name="files_remaining">
  <item quantity="one">%1$d file remaining</item>
  <item quantity="other">%1$d files remaining</item>
</plurals>
Text(text = pluralStringResource(R.plurals.files_remaining, count, count))

iOSのレガシー.stringsdictの例：

<plist version="1.0">
<dict>
  <key>%#@files@</key>
  <dict>
    <key>NSStringLocalizedFormatKey</key>
    <string>%#@files@</string>
    <key>files</key>
    <dict>
      <key>NSStringFormatSpecTypeKey</key>
      <string>NSStringPluralRuleType</string>
      <key>NSStringFormatValueTypeKey</key>
      <string>d</string>
      <key>one</key>
      <string>%d file remaining</string>
      <key>other</key>
      <string>%d files remaining</string>
    </dict>
  </dict>
</dict>
</plist>

Xcode 15以降では、AppleはString Catalogで複数形を処理することを推奨していますが、原則は同じです。プラットフォームに1つのメッセージパターンを与え、適切な言語形式を選ばせましょう。

プレースホルダーや構造化文字列に関するワークフローのより深いガードレールについては、コードを壊さずに技術文書を翻訳する方法を参照してください。

日付、数値、通貨、単位

Appleは、ロケール間で日付、長さ、重量、価格、通貨記号をフォーマットするためにFoundation APIを使用することを明示的に推奨しています。同じ原則がAndroidにも当てはまります。句読点、小数点記号、単位の順序をハードコードする代わりに、ロケール対応のAPIでデータをフォーマットしましょう。

典型的な失敗例：

  • 03/04/2026が地域によって異なる意味を持つ
  • USD以外の市場でドル記号をハードコード
  • カンマを小数点区切りに使うロケールで1,234.56が不正確に表示される
  • 計測単位が間違った体系で表示される

アプリにスケジューリング、請求、配送ウィンドウ、またはアナリティクスが含まれている場合、これはポリッシュではなくローカライズの一部です。

レイアウトの拡張と右から左のサポート

英語は通常コンパクトです。ドイツ語はより長くなります。アラビア語とヘブライ語は読む方向が逆になります。英語では問題なく見えるレイアウトが、他のロケールではひどく壊れることがあります。

Appleは、実際の翻訳をインポートする前に、右から左の疑似言語や倍長の疑似言語を含む疑似言語でテストすることを推奨しています。Androidは、leftとrightの代わりにstartとendを使用し、android:supportsRtl="true"を有効にし、Force RTLでデバイス上のRTLレイアウトをテストすることを推奨しています。

チェックリストはシンプルです：

  • ボタンやラベルが拡張できるようにする
  • 重要なUIに固定幅のテキストコンテナを使わない
  • 適切な場合に方向性のあるUIをミラーリングする
  • RTLでアイコン、シェブロン、進行フロー、カルーセルを確認する
  • アラビア語UIにラテン文字の商品名やクーポンコードが混在するような、混合方向テキストをテストする

画像、アイコン、スクリーンショット、動画

Appleのローカライズガイダンスは、多くのチームが見落とす重要なポイントを指摘しています。画像もローカライズできるということです。これにはイメージセット、シンボルセット、カスタムシンボルの方向性が含まれます。スクリーンショットに英語のUI、バナー内の英語テキスト、または左から右の矢印が含まれている場合、そのスクリーンショット自体はローカライズされていません。

これはオンボーディング画面、チュートリアルカード、App Storeアセットにとって特に重要です。ユーザーは「マーケティングビジュアル」と「プロダクトの言語」を心の中で分けません。体験全体を一度に判断します。

App StoreとGoogle Playページを別々にローカライズする

アプリ内の作業をうまく行った後でも、ここで多くのチームがインストールを失います。

計画すべきApp Storeの要件

AppleはApp Store Connectでメタデータをローカライズすることを推奨しており、アプリの説明、キーワード、アプリプレビュー、スクリーンショットが含まれます。Appleはまた、プロダクトページに最大10枚のスクリーンショットを掲載でき、サポートされているデバイスサイズと言語ごとに最大3つのアプリプレビューを表示できると述べています。アプリプレビューは最大30秒で、プレビューがない場合はスクリーンショットがさらに重要になります。最初の1〜3枚のスクリーンショットが検索結果に表示される可能性があるからです。

これには2つの意味があります：

  1. 最初のスクリーンショットは単なるドキュメントではなく、発見可能性のためのアセットです。
  2. 英語のアセットをどこでも使い回すのではなく、優先度の高い市場向けにスクリーンショットとプレビューをローカライズすべきです。

計画すべきGoogle Playの要件

Google Playもリスティングのローカライズを独自のワークフローとして扱っています。Play Consoleでは、ローカライズされたテキスト、対象言語のスクリーンショット、ローカライズされたグラフィックアセットを追加できます。テキストの翻訳を追加してもローカライズされたグラフィックアセットを追加しない場合、Googleはデフォルト言語のビジュアルが引き続き表示されると述べています。

Googleはまた、自分でストアリスティングの翻訳を追加しない場合、ユーザーには自動的に生成されたという通知付きの自動翻訳が表示される可能性があると述べています。これはフォールバックとしては有用ですが、強力な市場参入戦略ではありません。

特に関連する現在の機能として、Play ConsoleはGeminiモデルを使用してアプリ文字列を無料で継続的に翻訳できると述べています。具体的には、Googleはこれがドラフトリリースにアップロードされたアプリバンドルのstrings.xmlからのアプリ文字列に適用され、公開前に組み込みエミュレーターで生成された翻訳をプレビューできると述べています。これはファーストパスのカバレッジを加速する強力な方法ですが、重要なフローについては人間によるレビューが引き続き必要です。

リリースとQAワークフローを構築する

良いローカライズプロセスとは、翻訳を速くすることよりも、サプライズを少なくリリースすることです。

ステップ1. ターゲットロケールを意図的に選ぶ

「すべてを20言語に翻訳する」から始めないでください。

次のことから始めましょう：

  • 現在のダウンロードミックス
  • 積極的にサポートしている国
  • 請求、法務、カスタマーサポートのカバレッジ
  • アプリとストアリスティングを一緒にローカライズできるかどうか

1つの市場をエンドツーエンドで出荷する方が、5つの市場を中途半端に出荷するよりも通常は良い結果をもたらします。

ステップ2. ローカライズ対応アセットを作成する

翻訳を始める前に、以下を固定して準備します：

  • コンテキスト付きのソース文字列
  • ロケールごとのスクリーンショットリスト
  • 用語集とプロダクト名のルール
  • プレースホルダーのルール
  • ストアコピーの文字数制限ガイダンス
  • ロケール固有のレビュー担当者

アプリが別々のリポジトリや複数のファイルフォーマットを使用している場合は、命名と抽出を早い段階で標準化しましょう。

ステップ3. まず疑似ローカライズでテストする

Appleプラットフォームでは、倍長および右から左の疑似言語を使用します。Androidでは、未サポートのロケール、Force RTL、アプリ言語設定をテストします。これにより以下が検出されます：

  • 切り詰められたボタン
  • クリップされたヘッダー
  • 隠れたテキスト
  • 間違った配置
  • ローカライズされていない文字列
  • ハードコードされた左/右の前提

これは実行できる最もコストの低いQAパスの1つです。

ステップ4. 実機で言語QAを実行する

翻訳が完了した後：

  • 各ターゲット言語で重要なフローをテストする
  • システム言語とアプリ言語の動作を比較する
  • 複数形の動作とプレースホルダーを検証する
  • 決済、日付、住所を確認する
  • スクリーンショットとストアリスティングを対象市場で確認する

バグがオンボーディング、チェックアウト、本人確認、または通知に影響する場合は、リリースブロッカーとして扱いましょう。

初回ローカライズスプリントチェックリスト

初めての本格的なロールアウトなら、スプリントをクリーンに完了できる程度に小さく保ちましょう：

  • ターゲットロケールは10ではなく1つを選ぶ。
  • 1つのリリースブランチのソース文字列をフリーズする。
  • オンボーディング、チェックアウト、アカウント、通知のすべての文字列をコンテキストコメント付きでエクスポートする。
  • App StoreとGoogle Play向けにローカライズしたいスクリーンショットをキャプチャする。
  • 実際のテキストを翻訳者に送る前に、疑似ローカライズパスを1回実行する。
  • アプリ文字列とストアリスティングコピーを同じスプリントで翻訳する。
  • 翻訳を再インポートし、iOSとAndroidの両方でアプリ言語切り替えをテストする。
  • 実機で上位5つのユーザージャーニーをQAする。
  • 同じロケールのスクリーンショット、アプリプレビュー、ストアメタデータを更新する。
  • まずTestFlightまたは内部トラックにリリースし、サポートチケットとクラッシュレポートを監視する。

このチェックリストは意図的に狭くしています。1つのロケールでクリーンなアプリ体験と同期されたストアアセットを実現することは、多数の市場に急いでローンチするよりもはるかに多くのことを教えてくれます。

実際の事例

上記のコアとなるアイデアは理論上のものではありません。

DoorDashは翻訳をプラットフォームの問題として構築した

2022年、DoorDashは4つの言語にわたって100万以上の文字列を翻訳し、新しい言語のオンボーディングを開発者の数時間の作業から1分で1コマンドに短縮したと述べました。興味深い教訓は単なるスケールだけではありません。構造です。DoorDashは静的文字列と動的文字列を分離し、用語集とスタイルガイドのサポートを追加し、未翻訳の文字列が漏れないようにガードレールを構築しました。

2026年2月2日のDoorDashのブログ投稿で、同社は再構築されたオンボーディングプラットフォームがすべてのDoorDash市場でのサインアップを支えており、シームレスなローカライズによる迅速な国際展開をサポートしていると述べました。これこそ成熟したローカライズの姿です。再利用可能なワークフロー、地域の柔軟性、そしてより少ないアドホックな対応です。

Metaはローカライズを言語の問題とアプリサイズの問題の両方として扱った

Metaは、Facebook for Androidユーザーの約57%とFacebook for iOSユーザーの49%が英語以外の言語でアプリを使用していると述べています。同じ記事で、Metaはバンドルされた翻訳ファイルの削除によりiOSアプリで最大16.6MBを節約し、Androidではアプリサイズを増やすことなくほぼ12の言語を追加できたと述べています。

この教訓は小規模なチームにとっても有用です。ローカライズにはエンジニアリング上の結果が伴います。バイナリサイズ、ランタイムの読み込み、翻訳の配信、リリースメカニクスに影響し、単なるコピーライティングではないのです。

リリース前の最終チェックリスト

最終確認として使用してください：

  • すべてのユーザー向け文字列が外部化されている。
  • デフォルトのフォールバックリソースが完全である。
  • 複数形とプレースホルダーがプラットフォームネイティブのローカライズサポートを使用している。
  • 日付、時刻、数値、通貨、単位がロケール対応である。
  • RTLレイアウトと混合方向テキストがテスト済みである。
  • ストアリスティングテキストがターゲット市場向けにローカライズされている。
  • スクリーンショットとプレビューが優先言語向けにローカライズされている。
  • iOSとAndroidでアプリ内言語選択が期待通りに動作する。
  • 言語QAが最も重要なユーザージャーニーをカバーしている。

まとめ

モバイルアプリのローカライズについて最もシンプルに考える方法はこうです。プロダクトを翻訳し、体験をローカライズし、リリースをテストする。

初めてこれを行う場合、初日から完璧なグローバルカバレッジを目指さないでください。1つか2つの戦略的なロケールを選び、アプリとストアページを一緒にローカライズし、本格的なQAパスを実行し、実際の使用から学びましょう。すでにリソースファイルや開発者向けコンテンツを管理している場合は、このワークフローをコードを壊さずに技術文書を翻訳する方法や2026年のベストJSONトランスレーターと組み合わせてください。

今週1つだけアクションを取るなら、これをしましょう。1つのロケールを選び、1回の疑似ローカライズパスを実行し、1つのApp StoreまたはGoogle Playリスティングをローカライズする。この3つのテストは、20のロケールを並行して翻訳するよりも、あなたの準備状況について多くのことを教えてくれます。

アプリコピー、スクリーンショット、または構造化された言語ファイルの迅速なファーストパスが必要な場合は、自動化を使ってドラフトを加速し、リリース前に人間のQAステップを維持しましょう。これがユーザーの信頼を守り、「翻訳はされているが本当にはローカライズされていない」ローンチを防ぐ部分です。

参考文献

Tags

i18n how to
Share this post on:
Share this post on X Share this post on Facebook Share this post via WhatsApp

Related Posts

グローバルマーケット向けにAmazonリスティングを翻訳する方法

グローバルマーケット向けにAmazonリスティングを翻訳する方法

Amazonの規則を考慮しながら、商品タイトルポリシー、ブランド分析、A+コンテンツ、そしてローンチ前の品質確認を含めたAmazon商品ページの翻訳方法を学びましょう。

2026/3/24
出生証明書を翻訳する方法

出生証明書を翻訳する方法

移民、ビザ申請、法的手続きのために出生証明書を翻訳する手順を解説。国ごとの認証翻訳要件や、却下につながりやすい典型的なミスも紹介します。

2026/3/6
卒業証書の翻訳方法

卒業証書の翻訳方法

移民、大学進学、または海外での就職のために認定された卒業証書の翻訳が必要ですか？ここでは、認証、公証、アポスティーユの仕組みと、国ごとの規則や却下を避けるためのポイントについてご説明します。

2026/1/25