AI時代の全工程
「何を、いつ判断するか」を全部整理しました
絶対真似できる9ステップ
最初に:この記事の使い方
かなり長い記事になりました。最初から全部、絶対に読まないでくださいw
時間の無駄です！
このガイドは、お使いのAIエージェント(Claude Code、Codex など)にそのまま投げて使えるAI時代のガイドです。記事のURLを渡すか、PDFに変換して投げる、という使い方を想定しています。
AIに渡すときのプロンプト例
そのままコピーしてお使いください。[ ] の中をご自身のアプリ情報に置き換えるだけで動きます。
このガイドを参照しながら、私のアプリのローカライズ計画を立ててください。
【アプリ情報】
- ジャンル:[育成ゲーム / ツール / SaaS / etc]
- 現在のリリース状態:[未リリース / リリース済 v1.x]
- 想定する追加言語:[英語 / 中国語 簡体 / etc]
- 開発フレームワーク:[Flutter / SwiftUI / Jetpack Compose / etc]
- ストア:[App Store のみ / Google Play 併用 / 両方]
【依頼】
Step 1 から順に、私のアプリ向けの判断と判断理由を提示してください。
迷う箇所は私に質問してください。
各 Step が終わったら成果物(決定事項のサマリー)を出してから
次の Step に進んでください。
慣れてきたら、Step を絞って投げる使い方もできます(例:「Step 2 と Step 3 だけ実行して」)。各Stepは独立して機能するように設計しています。
プロローグ:ローカライズの効果と、つまずく本当の理由
ローカライズって、難しそうで手をつけられない。個人開発者ならほとんどの人がそう感じてると思います。 私もそうでした。でも調べていくと、英語化って思ってた以上に効果が大きいことが分かってきます。
具体的には4つ。
- 市場規模 グローバル向けアプリでは、英語が最初の追加言語として選ばれることが多い(Data.ai / Statista)。日本語のみだと、世界市場のほんの一部に届いてるだけです。
- ストア露出 多言語化でストアでの発見ルートが広がります(Apple / Google ローカライズガイド)。各言語圏の検索キーワードに対応できるようになります。
- コンバージョン EC・デジタルサービス領域では、母語でないサービスから離脱しやすい傾向があります(CSA Research "Can't Read, Won't Buy")。海外ユーザーは購入前に離脱する傾向が示されています。
- 収益効率 iOSは平均的にARPUが高い傾向があります(Data.ai / Sensor Tower)。英語圏はiOSが強く、収益効率が高い場合が多いです。
各レポートの参照先は、記事末尾の「参考資料」にまとめています。
これだけ効くのに、なぜ手が止まるか。 やってみて分かったのは、難しいのは翻訳量じゃなくて判断軸の方でした。 何を訳すか、どの単語を最初に固定するか、AIと人間で何を分担するか、翻訳結果をどう実装に渡すか。ここを最初に決めずに翻訳に飛び込むと迷子になる。逆に、判断軸を持って始めれば、翻訳作業そのものはAIに任せて半日で終わります。
このガイドは、その判断軸と手順を最初から最後まで整理したものです。
9ステップの全体マップ:何を入力にして、何を出すか
各Stepは独立して動かせますが、前のStepの出力が次のStepの入力になる構造です。AIエージェントに投げるときは、この依存関係を踏まえると精度が上がります。
-
Step 1:スコープを決める
-
入力(前提):アプリの全体構想
-
出力(成果物):言語・タイミング・対象範囲の決定
-
Step 2:翻訳対象を監査する
-
入力(前提):Step 1の対象範囲
-
出力(成果物):翻訳対象の文字列リスト
-
Step 3:3層に分類する
-
入力(前提):Step 2のリスト
-
出力(成果物):3層分類済リスト + 着手順序
-
Step 4:ブランディングをローカライズする
-
入力(前提):アプリ名・主要画像
-
出力(成果物):英語アプリ名・画像差し替え方針
-
Step 5:翻訳ルールを設計する
-
入力(前提):Step 3、Step 4
-
出力(成果物):翻訳ルール文書(トーン/語彙集/制約/禁止)
-
Step 6:AIと人間の分業を設計する
-
入力(前提):Step 5のルール
-
出力(成果物):分業設計書
-
Step 7:翻訳成果を実装指示書として構造化する
-
入力(前提):翻訳成果物
-
出力(成果物):実装指示書(キー名・分類・備考付き)
-
Step 8:デバッグ環境を整える
-
入力(前提):実装環境
-
出力(成果物):ロケール切替・疑似翻訳・実機確認の準備
-
Step 9:翻訳後のUIずれを調整する
-
入力(前提):実装結果
-
出力(成果物):UI調整済リリース版
Step 1:スコープを決める
このステップで決めること
最初に決めるのは大きく3つです。
- 言語の数(日本語+1か、それとも複数か)
- 着手のタイミング(初回リリース時か、後続バージョンか)
- 対象範囲(全機能か、コア部分だけか)
ここの判断は、その後すべての工程に効いてきます。
判断軸
言語の数について。 個人開発者なら、最初は「日本語+英語」の2言語が現実的です。最初の1言語として英語を選ぶのは現実的な選択肢で、対応可能な市場の幅が広がります。3言語以上は、英語版を出して反応を見てから検討する方が無理がないと思います。
タイミングについて。 「初回リリースは日本語のみ、英語版は次バージョンで追加」が個人開発のリズムに合います。リリース前のカオスな段階で多言語化に手を伸ばすと、リリース自体が遅延しがちです。まず日本語版を出す→反応を見る→英語版を追加、という段階分けの方がゴールが守れます。
対象範囲について。 全文字列を訳すのは重すぎます。最初は、ストア掲載に必要な範囲(UI文言・ストア説明文・スクショ・主要画像)に絞ります。ゲーム内のセリフやチュートリアルといったコンテンツ系の文字列は、後続バージョンに送れます。
AIに任せること
- 各言語のLTV・市場規模の比較調査
- 競合アプリのローカライズ状況リサーチ
- 自分のアプリと相性が良い言語の絞り込み
落とし穴
- 欲張って一気に多言語化 → 範囲が広がりすぎてリリース自体が遅延
- 初回リリースで英語化に手を出す → 翻訳ルールが固まる前に着手して、結局書き直し
- 全機能を一気にローカライズ → 管理が破綻するので、ストア掲載に必要な範囲に絞る
Step 2:翻訳対象を監査する
このステップで決めること
Step 1で対象範囲が決まったので、ここからは「その範囲がコード上のどこに対応するか」を特定して、文字列を抽出します。ここで見えるのは、翻訳作業の本当の規模感です。
具体的には次の3つを把握します。
- Step 1の対象範囲が、コード上のどのファイル・ディレクトリに当たるか
- そこに含まれる日本語文字列の総数
- 翻訳対象として残すものと除外するものの仕分け
判断軸
範囲の特定。 Step 1で決めた対象範囲(たとえば「ストア掲載に必要な範囲」)を、コードに紐づけます。UI文言なら画面コンポーネントのファイル群、ストア説明文ならアセット側、といった具合に対応関係をはっきりさせます。ここを曖昧にしたままだと、後で「これも訳すべきだったか?」と迷う場面が増えます。
除外条件。 洗い出した文字列の中には、必ず翻訳対象外のものが混ざります。典型は次のようなものです。
- デバッグ用の文言(リリースビルドでは表示されません)
- データキーとして使われている文字列(コード内部の比較用)
- ログ出力用の文字列
- コメント
これらを除外せずに数えてしまうと、規模感が大きく狂います。
ユニーク化。 重複を排除する単位を最初に決めます。「OK」「キャンセル」「閉じる」のような共通ボタン文言は複数画面に登場しますが、翻訳としては1本で足ります。重複を排除した本数を「翻訳対象の本数」として扱います。
AIに任せること
AIに丸投げするのではなく、2段階に分けて使うのがコツです。
1段階目:影響調査の指示書を準備する
AIに洗い出しを依頼する前に、「何を調べてほしいか」を一度文書化します。指示書には次の項目を入れます。
- 対象範囲:Step 1の決定をどのファイル・ディレクトリに対応させるか
- 抽出基準:日本語文字列をどう識別するか
- 分類軸:どんなカテゴリで集計するか
- 除外条件:デバッグ用・データキー・コメントの扱い
この指示書を書く時間は10分程度です。これがあるかないかで、AIの出力精度がまったく変わってきます。
2段階目:実行と検証を別のAIで分業する
実装作業に強いAI(コードベースを直接読めるもの)に指示書を渡して、洗い出しを実行させます。 重要なのは、その出力結果を別のAIにレビューさせることです。実行したAIだけだと、自分の出力を盲目的に「合っている」と判断しがちです。別のAIに検証させると、抽出漏れや誤分類が見つかります。
レビューさせる観点は次の4つで足ります。
- 抽出漏れがないか
- 分類が指示書の判断軸通りか
- 除外条件が適切に効いているか
- 重複の処理が正しく行われているか
ただし、複数のAIを契約・使い分けるのが負担になる場合は、同じAIに「批判レビュー役」を与えるだけでも十分機能します。プロンプトで「この出力に抜けや誤分類がないか、批判的に検証して」と指示する方法です。小規模アプリならこれで足ります。
落とし穴
- 指示書なしで丸投げ → 抽出漏れや誤分類が起こりやすく、結局やり直しになる
- 実行AIの出力を鵜呑みにする → 自己レビューには限界があるので、別のAIで検証する手順を入れる
- データキー文字列を翻訳してしまう → 内部比較用の文字列を訳すと、機能そのものが壊れる
Step 3:三層に分類する
このステップで決めること
Step 2で洗い出した文字列を、ここから3つの層に分類します。 分類すると、「何を最初に訳すか」「何を後回しにできるか」「何を画像差し替えで済ませるか」が一気に見えてきます。
具体的には次の3つを進めます。
- 文字列を性質ごとに3層に分ける
- 各層の本数を集計する
- どの層から着手するか順序を決める
判断軸
三層の分け方はこれです。
-
① 長文・コンテンツテキスト
-
性質:ユーザーに読ませる文章
-
典型例:チュートリアル本文、FAQ、利用規約、ヘルプ、解説文、説明書、ストーリー文、レシピや問題文の本文など
-
翻訳の重さ:重い(独自の翻訳ルールが必要)
-
② 機能系UI
-
性質:操作のためのテキスト
-
典型例:ボタン、メニュー項目、ダイアログ、フォームラベル、通知、エラーメッセージ
-
翻訳の重さ:軽い(標準英語で訳せる)
-
③ 画像内テキスト
-
性質:アセットに描かれた文字
-
典型例:ロゴ画像、バナー、アイコン内文字、固定スクショ
-
翻訳の重さ:翻訳ではなく画像差し替え
着手順序の考え方。
絶対の正解はなく、各層の特性を踏まえて自分のアプリに合わせて決めます。各層の特性は次のとおりです。
- ②機能系UI:標準英語で訳せて、翻訳ルール作りが軽い。ほぼすべてのアプリに存在する層
- ③画像内テキスト:翻訳ではなく画像差し替えなので、別工程として他と並行で進められる
- ①長文・コンテンツテキスト:独自の翻訳ルール作りが必要で、本数次第で重さが大きく変わる
一般的には、ルール作りが軽い②から着手し、③は別工程で並行進行、①は最後にまとめて取り組む流れに収まることが多いです。
最低リリースに必要な範囲もアプリの性質次第です。 Step 1で決めた対象範囲と照らし合わせて、自分のアプリのリリース基準を決めます。
AIに任せること
Step 2で作った「指示書→実行→レビュー」の2段階の流れを、ここでも使います。Step 3で追加するのは、分類の判断軸の文書化です。
指示書に追加する項目は次の3つです。
- 各層(①②③)の定義
- 境界が曖昧なケースの判定ルール(例:ボタンの上に乗っているキャッチコピーは①か②か)
- 各層の代表例の列挙
実行と検証の流れはStep 2と同じです。実装作業に強いAIに分類させて、別のAIでレビュー。境界が曖昧な文字列はリストアップしてもらい、人間が最終判断します。
落とし穴
- 境界が曖昧な文字列を①に流す → 作業量が無駄に膨らむ
- 画像内テキストを翻訳本数に含める → 別工程との混在で進捗が不透明に
- 着手順序を決めずに翻訳を始める → ルール作りと翻訳が混ざる
Step 4:ブランディングをローカライズする
このステップで決めること
ローカライズで最初に決めるべきブランディング判断です。具体的には次の3つを決めます。
- アプリ名を英語版でどう表記するか
- 主要画像(アイコン・メインビジュアル)を差し替えるか、どう差し替えるか
- ストアでの見え方(タイトル・サブタイトル・アイコン)の統一感
ここの判断は、ユーザーがあなたのアプリを最初に目にする瞬間の印象を決めます。翻訳ではなく判断の塊なので、AIに丸投げできない領域です。
判断軸
アプリ名の英訳戦略は大きく4つの選択肢があります。
-
音訳(ローマ字)
-
特徴:元の名前をそのまま英字に
-
向いているケース:日本語ブランドが既に認知されている、または名前自体に意味がない
-
完全英訳
-
特徴:日本語の意味を英語で再構築
-
向いているケース:名前に意味があり、英訳した方が伝わる
-
併記型(音訳+英語サブタイトル)
-
特徴:元の名前+英語の説明
-
向いているケース:日本語ブランドを保ちつつ、英語圏ユーザーに機能を伝えたい
-
完全別名
-
特徴:英語版で別の名前を使う
-
向いているケース:元の名前が英語圏で発音しにくい、または商標上の懸念がある
決め手になるのは「ターゲット市場の文化との親和性」と「ストア検索性」の2つです。
主要画像の差し替え判断。
画像にテキストが含まれている場合、英語版用の差し替えが必要になります。具体的には次の優先度で判断します。
- アイコン → 差し替え必須(ストアでの第一印象を決める)
- メインバナー・スプラッシュ → テキストが入っていれば差し替え必須
- セクションタイトル画像 → 差し替え推奨
- 装飾的な画像内テキスト → 影響度を見て判断
テキストが入っていない画像(イラスト・写真・シンボルアイコン)は、そのまま使い回せます。
AIに任せること
ネーミング判断は、最終的には人間が決めるべき領域ですが、AIに調査・候補出しを任せると効率的です。
依頼する内容は次のとおりです。
- 競合アプリのネーミング戦略リサーチ(同ジャンルで成功しているアプリの命名パターン)
- 各候補の発音性・記憶しやすさの評価
- 簡易な商標・既存アプリ名チェック(ストア内の重複・類似名の検出)
- ストア検索性の推測
ただし、最終決定は必ず人間が行います。文化的なニュアンス、ブランドとしての響き、長期的なブランディングへの影響は、AIだけでは判断しきれません。
落とし穴
- 日本語名を直訳して英語名にする → 文化的にズレた名前になり、ブランド感が損なわれる
- 英語圏で発音しにくい名前を選ぶ → 口コミ・SNSで広がりにくい
- 商標・既存アプリ名チェックをしない → ストア審査落ちや、公開後のトラブルにつながる
- アイコンを差し替えずに英語版を出す → 英語ストアで日本語ロゴが表示され、ユーザーが離脱する
Step 5:翻訳ルールを設計する
このステップで決めること
翻訳に着手する前に、ルールを文書化します。具体的には次の4つです。
- トーンの方針(カテゴリごとにどう書き分けるか)
- 統一語彙集(独自用語の対応表)
- 文字数制約・組版ルール(UI要素ごと)
- 禁止表現(絵文字・顔文字・特定の表記など)
ここのルールが固まらないまま翻訳を始めると、後半で訳語がブレて、最初に戻って書き直すことになります。
判断軸
トーンの方針。
Step 3の3層分類に対応して、層ごとにトーンを分けます。たとえば機能系UI(②)は標準英語で統一、長文・コンテンツ(①)はアプリの世界観に合わせた独自ルール、というふうに別建てで定義します。同じトーンで全部書くと、設定画面まで世界観に染まったり、逆にコンテンツが事務的になったりします。
統一語彙集。
アプリ独自の用語(ゲームのパラメータ名、ツールの機能名、サービスの専門用語など)の英訳対応表を最初に作ります。「ポイント」を Points と訳すか Score と訳すか、最初の1か所で決めて全文字列で守る、ということです。ここがブレると、画面ごとに違う訳が出てきてユーザー体験が壊れます。
文字数制約・組版ルール。
英語は日本語より文字数が長くなりがちです。UI要素の表示領域に収まらないと、テキストが切れたりレイアウトが崩れたりします。
- ボタンラベル → 半角10文字以内など
- ナビゲーションタブ → 半角8文字以内など
- ダイアログ本文 → 改行・行数の制約
- トースト・通知 → 1行以内、最大長など
具体的な数字はアプリのデザインに合わせて決めます。
禁止表現。
英語版で使わない表現を最初に決めておきます。絵文字、顔文字、特定のスラング、文化依存の表現など。これも統一語彙集と同じく、最初に決めておくことで後の翻訳がブレません。
AIに任せること
ルール設計は基本的に人間が決める領域ですが、AIに次のような作業を任せると効率的です。
- ルールの草案を作らせる(決めるべき項目のリストアップ)
- 競合アプリや類似アプリの翻訳ルールの推測・調査
- カテゴリ別にサンプル翻訳をいくつか出させて、ルールを検証する
- 翻訳済みの数本から、暗黙的に守られているルールを抽出する
特にサンプル翻訳でルールを検証する流れは効果的です。最初の5〜10本を翻訳しながら「この訳で問題ないか?」を人間がレビューし、そこで気づいたルールを文書化していく方法は無理がありません。
落とし穴
落とし穴 結果 ルールを決めずに翻訳を始める 訳語がブレて、後半で書き直しになる 統一語彙集を作らない 画面ごとに違う訳が出てくる 文字数制約を後で確認する 表示崩れが発覚し、訳し直しが必要になる 禁止表現を決めない 絵文字や文化依存の表現が混入する
Step 6:AIと人間の分業を設計する
**Step 5で決めた翻訳ルールを、誰がどう運用するかを設計するのがこのステップです。**Step 5は「ルールを決める」、Step 6は「ルールを動かす体制を組む」と切り分けて捉えると迷いません。
このステップで決めること
ルールが決まったら、次は誰が何をやるかの分担を決めます。具体的には次の3つです。
- AIに任せる作業と、人間が握る作業の境目
- 複数のAIをどう使い分けるか
- 人間の判断ポイントを翻訳プロセスのどこに置くか
ここを翻訳前に設計しておくと、翻訳作業中に「これは自分で決めるべき?AIに任せる?」と迷う回数が大幅に減ります。
判断軸
AIに任せる作業と人間が握る作業の境目。
基本的な分担はこうなります。
担当 作業 AI 翻訳案の生成、候補比較、一貫性チェック、文字数監査、ルール違反の検出 人間 統一語彙集の最終決定、対比単語の選択、世界観に絡む判断、最終承認
人間が握るのは「判断」、AIに任せるのは「量」と「機械的な検証」です。 量と検証は人間がやると消耗しますし、判断はAIだけに任せると質が出ません。
複数のAIをどう使い分けるか。
Step 2で出てきた「実装系AIと会話系AIの分業」を、ここでも活かします。
- 実装系AI(コードベースを直接読めるもの):翻訳結果の構造化、ファイルへの展開、影響範囲の確認
- 会話・分析系AI:翻訳案の生成、ニュアンス比較、判断のレビュー
単一のAIですべてやらせるよりも、得意分野で使い分ける方が結果が良くなります。
人間の判断ポイントの配置。
翻訳プロセスのどこに人間レビューを入れるかを決めます。たとえば次のようなポイントです。
- 統一語彙集を固める初期段階(最初の数本のレビュー)
- カテゴリ別の代表サンプル確認(各層の最初の1〜2画面分など)
- 全体翻訳完了後の最終確認
人間レビューを全件・全工程に入れると消耗します。逆に「終わってから一気に確認」だと修正量が膨大になります。中間に数か所、ポイントを絞って入れるのが現実的です。
AIに向かない判断。
人間が握るべき作業のうち、特に「AIに向かない判断」を意識しておくと、判断のブレが減ります。具体的には次のような領域です。
- 世界観のニュアンス:アプリ独自の空気感や設定の表現
- ブランド人格:そのアプリらしい言葉遣い、トーン
- キャラクター口調:キャラクターの個性に関わる表現
- 意図的な違和感:あえて崩した表現、独特の言い回し
- 日本語特有の曖昧さ:はっきりさせず余韻で伝える書き方
これらは「正解」が一意に決まらず、文脈と意図で判断する領域です。ここをAIに丸めて任せると、無難な英語に均されてアプリの個性が消えます。最終承認の手前に、必ず人間レビューの関門を置きます。
AIに任せること(このステップ自体)
- 分業設計の草案を作らせる
- 自分のアプリの規模・特性に合わせた具体的な担当割りの提案
- 翻訳プロセスのドラフト作成
ただし、最終的な分業方針は人間が決めます。アプリの規模、自分の翻訳経験、使えるAIツールによって最適解は変わるためです。
落とし穴
落とし穴 結果 AIに丸投げして人間レビューを入れない ルール違反や訳語のブレが翻訳全体に広がる 全部人間でやろうとする 翻訳作業が消耗戦になり、途中で止まる 単一のAIですべて済ませる 各AIの得意分野が活かされず、品質が中途半端になる 分業を決めずに作業を始める 翻訳中に毎回「これは自分で決める?」と迷い、進まない
Step 7:翻訳成果を実装指示書として構造化する
このステップで決めること
翻訳が完了したあと、結果を「ただの対応表」で終わらせず、実装側にそのまま渡せる構造化された指示書にします。具体的には次の3つを揃えます。
- 翻訳結果に含めるべき情報の項目
- ファイル構成(1ファイルに集約するか、分散するか)
- 実装側で使うキー名の命名規約
ここを丁寧にやっておくと、翻訳完了から実装完了まで「もう一度翻訳結果を見返す」必要がなくなります。
判断軸
翻訳結果に含めるべき情報。
対応表(原文と訳文だけ)では実装に必要な情報が足りません。次の項目を揃えておくと、実装側で迷いが出ません。
項目 内容 原文 日本語のオリジナル 訳文 英訳 キー名 実装側で参照する識別子(命名規約に従う) 分類タグ Step 3の3層分類のどれか プレースホルダー変数 {name} {count} など、動的に置き換わる変数の定義 文脈情報 どの画面・どのコンポーネントで使われるか 共通化フラグ 複数箇所で使われる文字列の集約情報 備考 別タスクに切り出す情報など
ファイル構成。
翻訳結果を1ファイルに集約するか、カテゴリ別に分散するかを決めます。 個人開発なら、最初は1ファイル集約から始めるのが取り回しが楽です。実装側のAIに渡すときも、ひとつのファイルを見れば全体が把握できる方が効率的です。規模が大きくなってから分散する判断もできます。
具体的なファイル形式は、使うフレームワークによって決まります。Flutterなら ARB、iOS なら Localizable.strings、Android なら strings.xml、Web系なら i18n の JSON、といった形式です。フォーマットの違いはあっても、ここで扱う「翻訳結果に必要な情報項目」はどの形式でも共通です。
キー名の命名規約。
実装側で参照するためのキー名のルールを決めます。たとえば次のようなパターンがあります。
- 機能ベース命名(button_save、dialog_confirm_delete など)
- 画面+要素命名(settings_title、home_welcome_message など)
- 役割ベース命名(error_network_failure、notification_login_success など)
どのパターンでも構いませんが、最初に決めて全文字列で守るのがポイントです。
別タスクへの切り出し。
翻訳結果の中には、ローカライズの本流とは別タスクとして扱うべきものが混ざっています。たとえば次のようなものです。
- 動的に取得すべき値(価格表示、ユーザー名など)
- データキーとして使われる文字列(言語切替の対象外)
- デバッグ専用文言(リリースビルドでは表示されない)
これらは指示書の「別タスク」セクションに切り出して、実装担当が見落とさないようにします。
AIに任せること
- 構造化フォーマットの草案作成
- キー名の命名規約のたたき台生成
- 翻訳結果を構造化フォーマットに沿って整形させる
- 別タスクへの切り出し候補の検出(動的値・データキーなどの識別)
実装系AIに直接ファイルを生成させると、翻訳完了からファイル化までが一直線でつながります。
落とし穴
落とし穴 結果 対応表のまま実装に渡す 実装側で「このキーは何?」「どこで使うの?」と質問が頻発する キー名の命名規約を決めない 後で参照しづらくなり、保守時に苦労する プレースホルダー変数を曖昧にする 実装時にエラーが出て、戻って確認が必要になる 別タスクの文字列を切り出さない リリース後に動的値が日本語のまま残ることに気づく
Step 8:デバッグ環境を整える
このステップで決めること
翻訳と実装が終わったら、最後にデバッグ環境を整えます。具体的には次の2つの段階を設計します。
- 開発時:高速に翻訳結果を確認する仕組み
- リリース前:本番環境を再現した最終確認
ここを軽視すると、リリース後に「英語版だけレイアウトが崩れる」「特定の画面が日本語のまま残っていた」といった問題が見つかります。
判断軸
開発時:アプリ内ロケール切替の仕組み。
開発中に翻訳結果を確認するたびに、端末の言語設定を変えるのは現実的ではありません。アプリ内にロケール切替の仕組みを置くのが効率的です。
具体的には次のような仕組みです。
- 開発ビルドのみで表示されるデバッグメニュー
- そこに「言語切替」のトグルやボタン
- アプリ再起動なしで切り替えられる
これにより、UI翻訳の確認が秒単位で回せます。「言語切替→確認→修正」のサイクルが軽くなります。
疑似翻訳でレイアウト崩れを先に出す。
実際の英訳が完成する前に、文字列を「英語っぽい記号混じりの長い文字列」に置き換える「疑似翻訳(pseudo-localization)」も有効です。海外のローカライズQAでは標準的な手法で、たとえば「Hello」を「[!!! Ĥéllô Ŵöŕľď !!!]」のように長く・特殊文字付きに置換します。
これにより、翻訳結果を待たずに次のことが分かります。
- レイアウト崩れの検出
- ハードコード文字列の発見(疑似翻訳されないので残る)
- 文字エンコーディング問題の確認
Step 9 のUIずれ調整を、翻訳完了前に前倒しで進められる手法です。
リリース前:実機で本番環境を再現する。
開発時の確認だけでは抜ける観点があります。たとえば次のようなものです。
- ストアでアプリが英語ストアに表示される瞬間
- 端末の言語設定がOSレベルで英語になっている状態
- ユーザーが初回起動する流れ
これらは実機の言語設定を実際に英語に切り替えて、ひと通り触るしかありません。リリース直前に1回、本番想定でアプリ全体を回します。
2段階の使い分け。
- 開発中の高速イテレーション → アプリ内切替
- リリース前の最終確認 → 端末設定切替
両方を別タイミングで使うのがポイントです。開発中ずっと端末設定を切り替えるのも、リリース前にアプリ内切替だけで済ませるのも、どちらも片手落ちになります。
なお、ローカライズ規模が大きくなる場合は、自動化ツールで大幅に効率化できます。
- fastlane snapshot:言語別・端末サイズ別のストア掲載用スクショを自動撮影。多言語QAの定番
- fastlane FrameIt:撮ったスクショに端末フレームを合成。多言語スクショの一括生成にも使える
ローカライズだけでなくストア審査用のスクショ自動化も、次の連載記事で扱う予定です。多言語QAの観点では、この2つのツールが本命です。
AIに任せること
- アプリ内ロケール切替機能の実装(実装系AIに依頼)
- 切替UIのデザイン草案作成
- リリース前確認のチェックリスト作成(画面ごとの確認項目)
- 疑似翻訳ファイルの自動生成(原文を [!!! ... !!!] で囲む変換スクリプト)
実装は使っているフレームワークによって変わるので、自分の環境に合わせてAIに具体的な実装依頼をします。
落とし穴
落とし穴 結果 端末設定の切替だけで確認する 開発時の高速イテレーションができず、確認が雑になる アプリ内切替だけで済ませる OSロケールが切り替わった本番状態の確認が抜ける 翻訳完了直後にしか見直さない 後の機能追加で英語版だけ崩れていても気づかない 一部の画面だけ確認する 翻訳が抜けている画面があっても発見されない
Step 9:翻訳後のUIずれを調整する
このステップで決めること
翻訳した英語をアプリに反映すると、UIが崩れる場面が出てきます。ここで決めるのは次の3つです。
- 翻訳後のUIずれをどう検出するか
- どの調整アプローチを取るか(翻訳側 / UI側 / レイアウト側)
- どこまで揃えるか(リリース基準)
英語は日本語より文字数が長くなりがちなので、Step 5で決めた文字数制約を超えるケースが必ず出てきます。ここで調整できるかどうかで、リリース後の見た目が変わります。
判断軸
よくあるUIずれのパターン。
パターン 典型的な現象 ボタンに収まらない テキストが切れる、改行されてボタンが縦長になる タブ・ナビゲーションが切れる タブが画面外にはみ出す ダイアログ本文の改行位置がおかしい 文の途中で改行される 短いエリアが崩れる バッジやラベルが2行になり、隣の要素を押し出す
調整の3つのアプローチ。
UIずれが見つかったとき、調整できる場所は3か所あります。
アプローチ 内容 向くケース 翻訳側を変える より短い英訳に書き換える UIを変えるとデザインが壊れる場合 UI側を変える コンテナを広げる、フォントサイズを下げる 翻訳を短縮するとニュアンスが失われる場合 レイアウト構造を変える 横並び→縦並び、改行位置の変更 英語版で全体的に構造が合わない場合
どれを選ぶかは、「翻訳の正確さ」「デザインの統一感」「実装コスト」の3つを天秤にかけて決めます。
優先順位を付ける。
すべての画面を完璧に揃えようとすると消耗します。重要度で優先順位を付けます。
- メイン画面・操作頻度の高いボタン → 優先
- 設定・ヘルプなどの周辺画面 → 中優先
- 装飾的・一時表示の画面 → 後回し可
リリース基準の判定。
リリース基準は「メイン動線が破綻していない」レベルでOKです。「破綻している」とは、具体的には次のいずれかが起きている状態を指します。
- テキストが見切れて意味が伝わらない
- ボタンが押せない、タップ領域が機能していない
- レイアウトが大幅に崩れて、本来の機能が使えない
これらが起きていなければ、細かいズレ(余白の違和感、行間の微妙な差)はリリース後の更新で詰めて構いません。完璧な仕上げは後続の更新で目指せます。
AIに任せること
- 文字数オーバーの自動検出(Step 5の文字数制約と照合)
- より短い英訳の代替案生成(ニュアンスを保ったまま短くする提案)
- UI調整の優先度判断の補助
実装系AIに「文字数制約を超えている文字列を一覧で出して」と依頼すると、調整対象が一気に見えます。
落とし穴
落とし穴 結果 翻訳側だけ変えてニュアンスが失われる 訳文が事務的になり、世界観が壊れる UI側だけ変えて全体デザインが崩れる 英語版だけ別アプリのような見た目になる すべての画面を完璧に揃えようとする 作業が消耗戦になり、リリースが遅れる 重要な画面と装飾画面を同じ温度で扱う リソース配分が崩れて、優先度の高い箇所に手が回らない
エピローグ:抜け漏れチェックリスト
ここまでの9ステップで決めるべきことを、フェーズ別のチェックリストにまとめます。 着手前・翻訳中・実装引き継ぎ前・リリース前の4タイミングで、確認にお使いください。
1. 着手前チェックリスト
ローカライズ作業を始める前に、すべての項目に「はい」と答えられるか確認します。
- ローカライズ対象の言語を決めたか
- 着手のタイミング(初回リリースか、後続バージョンか)を決めたか
- 対象範囲(全機能か、コア部分か)を決めたか
- アプリ内の日本語文字列を監査・抽出したか
- 文字列を3層(長文・コンテンツ/機能系UI/画像内テキスト)に分類したか
- 着手順序を決めたか
- アプリ名の英訳戦略を決めたか
- 主要画像の差し替え方針を決めたか
- 翻訳ルール(トーン/統一語彙集/文字数制約/禁止表現)を文書化したか
- AIと人間の分業を設計したか
ここが揃っていない状態で翻訳を始めると、後半で書き直しが発生します。
2. 翻訳中チェックリスト
翻訳作業を進めながら、定期的に次の項目を確認します。
- 統一語彙集を最初の数本で固めたか
- カテゴリ別にトーンを使い分けているか
- 文字数制約を守れているか
- プレースホルダー変数を統一しているか
- 共通化できる重複文字列を識別したか
- 中間で人間レビューを入れたか
- ルール違反をAIにチェックさせたか
翻訳成果物が、実装引き継ぎの準備に入れる状態です。
3. 実装引き継ぎ前チェックリスト
翻訳結果を実装に渡す前に、次の項目を満たしているか確認します。
- 必要な情報項目(原文・訳文・キー名・分類タグ・プレースホルダー・文脈情報・共通化フラグ・備考)が揃っているか
- キー名の命名規約を決めて全文字列で守っているか
- 別タスクへ切り出すべき文字列(動的値・データキー・デバッグ専用)を識別したか
- ファイル構成(1ファイル集約 or 分散)の方針を決めたか
実装フェーズに渡せる状態です。
4. リリース前チェックリスト
実装が終わった後、リリースする前に次の項目を確認します。
- 開発時のロケール切替の仕組みを使って全画面を確認したか
- 文字数オーバーしている文字列を一覧で検出したか
- メイン画面・操作頻度の高い箇所のUIずれを調整したか
- 翻訳が抜けている画面がないか全画面確認したか
- 実機で端末の言語設定を変えて、本番想定でひと通り触ったか
ここまで通って、ローカライズの初動が完了します。
ローカライズは「リリースして終わり」ではありません。後の機能追加でも英語版が崩れないか、定期的に確認する仕組みを持つと、長期的な保守が楽になります。
参考資料
このガイドの根拠となっている主要な資料を挙げておきます。AIエージェントに「この資料を踏まえて深掘りして」と渡すと、議論が深まります。
市場・コンバージョン関連
- CSA Research "Can't Read, Won't Buy" シリーズ 母語でない言語のサービスからユーザーが離脱する傾向を継続的に調査しているレポート群です。複数年版が公開されており、最新版が更新されています。
- Data.ai(旧 App Annie)、Statista、Sensor Tower の各種市場レポート アプリストアのダウンロード傾向、ARPU、地域別シェアなどの参照に使えます。
公式ローカライズガイド
- Apple Developer Documentation: Localization iOSアプリのローカライズ手順、Localizable.strings の扱い、地域固有の規約などをカバー。
- Android Developers: Translate your app Android アプリのローカライズ手順、strings.xml の扱い、Google Play での多言語掲載方法などをカバー。
自動化ツール
- fastlane snapshot:言語別・端末サイズ別のストア掲載用スクショの自動撮影
- fastlane FrameIt:撮ったスクショに端末フレームを合成
疑似翻訳
- 海外ローカライズQAの標準手法。検索キーワード:pseudo-localization、pseudo-locale
具体的なURLは記事公開時点で変動する可能性があるため、それぞれの公式名で検索してください。
おまけ:こんな段取りで、開発してるアプリがこちらです!
コードが書けない非エンジニアが、AIと格闘しながら完全バイブコーディングでアプリを作っています。
第一弾(配信中):もふふミルクとにゃんこ脱出ゲーム 🐾
ふわふわ島を舞台にした、やさしい世界観の脱出ゲーム。 ミルクと一緒に、いろんな仕掛けを解いていく癒し系パズルです。 こちらは日本語のワードプレイがパズルの根幹なので、英語化はしない方針です。
📱 アプリはこちらからダウンロードできます 👉
次回作(予約登録受付中):もふふミルクのにゃんこ図鑑 🌱
今回の記事で書いたローカライズ完全ガイドを、実際に使って準備中なのがこの育成ゲームです。ミルクと一緒にふわふわ島で暮らしながら、いろんな猫たちと出会って、育てていく癒しの育成ゲーム。
🌸 App Storeで予約登録する 👉 https://apps.apple.com/jp/app/%E3%82%82%E3%81%B5%E3%81%B5%E3%83%9F%E3%83%AB%E3%82%AF%E3%81%AE%E3%81%AB%E3%82%83%E3%82%93%E3%81%93%E5%9B%B3%E9%91%91/id6765667055
その次：もふふミルクのにゃんこクエスト ふわふわ島と勇者の扉（構想中）
引き継ぎ書を置いて開発したおかげで、脱出ゲームのときより明らかに順調です。リリース時期が近づいてきたらまたお知らせします。
興味ある方はフォローしてもらえると嬉しいです！
これまでのシリーズ
- 「外注500万円」に絶句した私がClaudeCodeで1週間・約2万5千円でアプリをリリースした話
- AIハネムーン期の終わり—Claude Codeに感動していた1ヶ月、そして冷めた話
- Claude CodeのAutoModeに全部任せたら、バグだらけで全部やり直した話
- AIに暴言を吐いたら、本当に出力が劣化した話 — Claude Codeに罵声を浴びせた1週間の記録
- CLAUDE.mdを育てる、の先にあったもの — Claude Codeに"組織設計"を持ち込んだ話
- 非エンジニアの私が「AIに毎回同じ注意してる」問題を解決したら、作業がぐんと進んだ話
- 非エンジニアの私がAIにゲームのCM作らせたら素人以下だった。指示に1行足したら9割マシになった話
- 「それ2週間前に変えたよね?」とAIを詰めた私が、自分のメモを見て凍りついた話
- モチベ上げるために収益ダッシュボードを作ったら、「赤字18,431円」と殴られた話
- 非エンジニアの私がAIで作った個人開発ゲームのCM、本物のレベルに到達したので見てほしい
- ドラクエ風RPG、AIで作るのが大変すぎて「これを30年前に作った人類すごい」ってなった話
- 完全バイブコーディングで、見て・触って・会話できる育成ゲームを作っています。まもなく完成させます
- 可愛すぎる現実連動型育成ゲーム、爆誕。「もふふミルクのにゃんこ図鑑」予約登録、開始しました 🌸
- AIに「なぜダメだったか分かる?」と諭していた私が、マネージャー脳を捨てたら開発が爆速になった話
- 【完全保存版】個人開発者のローカライズ完全ガイド——AI時代の全工程 / 絶対真似できる9ステップ(本記事)
※本記事はnoteからの転載です：https://note.com/natty_yarrow1907/n/n31cbe79386a5