アプリの表示文をAIで翻訳するときは、文の意味だけでなく、翻訳キー、変数名、複数形の分岐を保つ必要があります。「注文が1件あります」という文章が自然でも、変数が消えたり、件数ごとの分岐が壊れたりすれば、実際の画面では使えません。
まず採用している翻訳形式を確認し、文章として翻訳する部分と、プログラムが読む構造を分けて渡します。この記事では従来のICU MessageFormatと、それを扱うFormatJSの説明を参照します。i18nextなどの別形式、独自テンプレート、MessageFormat 2の構文へ、そのまま置き換えてよいという意味ではありません。例は説明用に作ったもので、特定アプリや翻訳モデルでの動作検証結果ではありません。
目次
最初に形式と翻訳単位を確認する
翻訳ファイルがJSONでも、値の中で使う文法はプロジェクトごとに異なります。波括弧があるという理由だけでICUと決めないでください。利用ライブラリ、バージョン、設定、既存の翻訳例を確認します。
表は横にスクロールできます
| 確認項目 | 先に決める内容 |
|---|---|
| キー | 変更・追加してよいか。今回の翻訳では既存キーを固定するか |
| 変数 | 名前と値の型。countは数値、userNameは表示名など |
| 分岐 | 件数、状態、権限などでどの文章へ分かれるか |
| 表示場所 | ボタン、通知、入力エラーなど。文字量や前後の文脈 |
| 保護対象 | URL、コード、タグ名、アプリが解釈する選択肢名 |
| 完了条件 | ファイル解析、メッセージ解析、代表値での表示、意味の確認 |
ICUの公式資料は、変数を含むメッセージを一つの単位として翻訳できることを説明しています。前半・変数・後半を別々の文字列にすると、翻訳先の語順へ組み替えにくくなります。画面上で一文になるものを、実装都合だけで細切れにしてAIへ渡さないようにします。ICU公式：メッセージの書式設定（新しいタブで開く）
文章と構造を一緒に確認できる入力を作る
AIへ値だけを大量に渡すと、「保存」がファイル保存か設定確定か分からなくなります。各キーに、用途、表示場所、変数の意味、既存の用語を添えます。実際の利用者名や注文情報は不要で、説明用の値で構いません。
例えば、cart.itemsというキーにcountを渡す場合は、「カート内の商品点数」「countは整数」「0件だけ専用の文を表示」と記録します。変数名を日本語へ訳さない、キーを読みやすく改名しない、未指定の機能説明を追加しないといった条件も明記します。
用語集は、単語の訳だけでなく使い分けを持たせます。cancelが操作の取り消しなのか、契約の解約なのかで意味が違います。短いボタンほど文脈の不足が誤訳につながるため、必要な説明を先に用意します。
複数形は、原文と同じ分岐数とは限らない
ICUのpluralは、数値と対象言語の規則で表示する文を選びます。selectは固定の選択肢で分かれる仕組みです。FormatJSでは、これらにフォールバックとなるotherが必要です。言語ごとに必要な複数形の区分が異なるため、分岐を原文から機械的にコピーしただけで十分とは限りません。FormatJS公式：ICU構文（新しいタブで開く）
次は、英語の原文と日本語訳の構造を比較するための架空の例です。別々の翻訳ファイルの値として示しています。
{
"cart.items": "{count, plural, =0 {No items} one {# item} other {# items}}"
}
{
"cart.items": "{count, plural, =0 {項目はありません} other {#件の項目}}"
}
この例では、日本語側で英語のone分岐を使わず、0件の専用表示と、それ以外の表示を残す設計にしています。実際に分岐を増減してよいかは、翻訳担当者と実装担当者が確認します。AIが勝手に分岐を削ることを認める例ではありません。
また、=0は数値0との明示的な一致、oneは言語の複数形規則上の区分です。すべての言語で「oneは常に整数1」と扱わないでください。小数を許す変数なら、小数の入力も対象言語の規則と実装に合わせて確認します。selectの状態名は、画面に出す文章ではなくアプリが渡す値と対応するため、訳語へ変更しないようにします。
AIへの依頼は、訳文と構造変更案を分ける
このアプリの表示文を翻訳してください。
形式：［実際のライブラリ・バージョン・メッセージ形式］。
対象言語：［言語と地域］。用途：［画面と操作］。
翻訳キーと変数名、変数の型、アプリが渡すselectの値は変更しないでください。
保護対象のURL・コード・タグ名を翻訳しないでください。
原文にない機能・保証・操作結果を追加しないでください。
言語上、pluralの分岐変更が必要なら、勝手に確定せず変更案と理由を示してください。
出力を「翻訳案」「構造変更案」「文脈不足の質問」に分けてください。
用語集：［承認済みの用語］
入力：［キー、原文、変数説明、表示場所］
この出力を翻訳ファイルへ取り込むときは、説明文や質問を値に混ぜません。構造変更が不要な行と、実装確認が必要な行を分け、未解決のキーだけ原文や既存訳を残すなど、プロジェクトで決めた扱いにします。
検査を四段階に分ける
第一に、JSONなど外側のファイルを解析します。末尾のカンマ、引用符、改行のエスケープなどを確認し、元のキー集合と比較します。JSONを読み込めても、中のICUメッセージが正しいとは限りません。
第二に、採用中のライブラリのパーサーやコンパイル機能で各メッセージを確認します。波括弧を数えるだけでは、入れ子、引用、分岐の意味を検査できません。変数名と型、selectの選択肢、必要なフォールバックも照合します。
第三に、代表値で実際の整形結果を確認します。次の表は上の架空例に対して確認したい結果で、実アプリで測定済みの出力ではありません。
表は横にスクロールできます
| count | 英語で確認したい表示 | 日本語で確認したい表示 |
|---|---|---|
| 0 | No items | 項目はありません |
| 1 | 1 item | 1件の項目 |
| 2 | 2 items | 2件の項目 |
必要に応じて、空の名前、長い名前、未設定値、大きな件数、各selectの選択肢も加えます。変数を渡し忘れたときの挙動はライブラリや実装によるため、空文字になると決めつけず、実際の処理を確認します。
第四に、画面上で意味と表示を確認します。文字切れ、改行、操作対象との対応、読み上げる名前などを見ます。構文が通っても、削除の確認文が保存の案内になっていれば使えません。特にエラー、取り消し、課金などの結果を伝える文は、機能の仕様へ戻って確認します。
訳文の修正で、コード側の契約を変えない
変数を使わず具体的な数字を埋め込む、URLを別のリンクへ置き換える、タグを見た目のために追加する、といった変更を翻訳と一緒に確定しないでください。表示文の修正と実装変更を分けてレビューします。
対象言語の差で必要になる分岐や語順は、単純な文字列一致だけでは判定できません。一方で、キーの欠落、変数の改名、説明文の混入は機械的に検出しやすい部分です。構造の検査を通してから、原文と訳文の意味を照合すると確認範囲が明確になります。
一般的な誤訳や用語の確認は、AI翻訳の品質をチェックする方法も使えます。表や文書の位置関係を保つ翻訳は、表や箇条書きのレイアウトを崩さず翻訳する方法へ進んでください。
参考資料
公式資料の確認日：2026年10月20日。実際の構文と挙動は、採用しているメッセージ形式とライブラリのバージョンで確認してください。