アプリのUI（ユーザーインターフェース）は、ユーザーが製品を操作するための画面やボタン、メッセージを指します。日本語UIを英語にする際は、原文の意味だけでなく、ユーザーがその場で何を判断し、ボタンを押すと何が起きるかまで伝える必要があります。文法が正しくても、操作を誤解させる英語では、使いやすいUIになりません。
AIや機械翻訳で候補を作る作業は速くなりましたが、短い文言には訳を選ぶための手掛かりが少ないという問題が残ります。日本語を理解し、英語UIに慣れた翻訳者が製品担当者と確認を重ねることで、機能と読み手に合う表現を選べます。この記事では、文脈の渡し方、用語の管理、AIの使い方、公開前の確認まで説明します。
日本語の丁寧さを、そのまま英語UIに残すべきか
日本語の「内容をご確認のうえ、登録をお願いいたします」を、そのまま Please check the information and then proceed with registration. と訳すと、ボタンとしては長く、登録の内容も曖昧です。アカウント作成なら Create account、編集内容の保存なら Save のように、実際の動作に合わせて書き分けます。確認が必要な情報はボタンの近くに残し、短くするために説明や同意事項を削らないことも大切です。
英語UIでは、丁寧な依頼を繰り返すより、操作と結果が分かる表現が役立ちます。英語を母語とする人でも、製品の機能やUIの書き方を知らなければ適切に判断できないため、翻訳者を選ぶ際は日本語の理解とアプリ翻訳の経験を併せて確認します。
W3Cが説明するローカライゼーションは、製品を対象市場の言語や文化に合わせる作業です。UIでは英文だけでなく、日付、通貨、入力形式、エラーメッセージなども対象になります。読み手に必要な情報を保ちながら、英語圏で使うアプリとして無理なく操作できる形にします。
短い言葉ほど、画面の文脈が必要になる
「連携」は、システムを接続する操作なのか、接続済みの状態なのか、企業間の協力なのかによって英語が変わります。ボタンに Connect、機能名に Integration、状態表示に Connected を使うように、同じ日本語でも品詞と役割を確認します。単語を一つの英訳に固定すると、表記はそろっても意味や文法が合わなくなるためです。
| 日本語 | 英訳の候補 | 訳を決めるために確認すること |
|---|---|---|
| 連携 | Connect / Integration / Connected | 接続する操作、機能名、接続済みの状態のどれか |
| 登録 | Create account / Add contact / Save | アカウント作成、連絡先追加、編集内容の保存のどれか |
| 明細 | Line item / Details / Statement | 帳票の個別項目、詳細画面、取引明細書のどれか |
| 規約 | Terms of Use / Terms and Conditions | 文書の正式名称と、リンクや同意文での使い方 |
Androidのローカライズガイドでも、画面上の使われ方などの情報を翻訳者へ渡すよう案内しています。実務では、文字列のID、画面のスクリーンショット、表示条件、操作後の結果、文字数や表示幅の制約を一緒に共有すると、質問と判断を具体化できます。
たとえば「解除」だけを渡すと、Disconnect、Unlink、Cancel などの候補が出ます。外部サービスとの接続を切るのか、関連づけだけを外すのか、手続き全体を中止するのかを説明すれば、翻訳者はユーザーに伝えるべき動作を判断できます。スクリーンショットだけで操作結果が分からない場合は、仕様の説明も必要です。
AI翻訳には、何を渡して何を人が確認するか
AIの英文が流暢でも、製品の動作に合っているとは限りません。レビューでは「英語として読めるか」に加え、「この操作を実行した人が、結果を予測できるか」を確認します。日本語原文と実際の画面を読まずに英文だけを校正すると、最初の訳で失われた意味を見逃します。
AIへは、対象ユーザー、画面の目的、関連する文字列、承認済みの用語集、過去訳、文体の方針を渡します。用語を変更するたびにモデル自体を再学習させる必要があるわけではなく、指示文や参照資料、用語集の設定を更新して対応できる方法もあります。どの情報が生成時に使われたかを確認し、変更後の出力を人が検証する工程が必要です。
2026年10月時点のDeepL APIの仕様では、翻訳対象とは別に文脈を渡す context パラメータや、用語集を指定する機能が用意されています。また、一度のリクエストに複数の文字列を入れても、文字列同士が自動で文脈を共有するわけではありません。画面の文言をまとめて送るだけで十分だと判断せず、必要な説明を明示します。
こうした機能を使えば、AIが文脈をまったく参照できない状態は改善できます。ただし、渡した仕様が古い、例外条件が抜けている、用語集の意味が曖昧といった問題までは自動で解消されません。AIは候補の作成や表記確認に使い、翻訳者と製品担当者が意味、操作、用語を確認して採用する運用が現実的です。
翻訳者が調べることと、製品担当者が答えること
経験のある翻訳者は、用語集や過去訳を読み、必要に応じて業界の資料や公式文書を調べます。会計、契約、医療機器などの専門用語では、辞書の英訳だけでなく、制度や対象ユーザーにとっての意味を確認し、製品固有の判断は担当者へ質問します。調査の結果と採用した表現の理由を残しておけば、次の更新でも同じ確認をやり直さずに済みます。
MacroLingoの代表アダム・ゴールストンは、ジャーナリストとリサーチャーとしての経験をもとに、資料を調べ、日本語で意図を確認しながら英語を制作しています。翻訳者がすべての分野を最初から知っていることよりも、不明点を見つけ、適切な資料や専門家を通じて確かめられることが実務では役立ちます。
たとえば日本の「インボイス制度」を単に Invoicing System とすると、一般的な請求書発行システムと区別できません。日本の制度を説明する場面では、制度の正式な英語表記を調べ、対象読者が知らない前提を補います。海外ユーザーに関係しない機能を非表示にするかどうかは、翻訳者が独断で決めず、製品と法務の担当者へ確認します。
MacroLingoは、Sansan株式会社のB2B SaaSサービスやアプリの英訳に継続して携わり、請求書や契約管理など、製品ごとに必要な用語を確認してきました。代表者の経歴も参考に、UIの翻訳経験、日本語での確認体制、専門分野の調査方法を確認してください。
用語集には、単語の対応だけでなく使い分けを残す
用語集に「登録＝register」とだけ記載しても、会員登録とデータ保存の違いは伝わりません。機能の意味、使う画面、品詞、採用する例文、避ける表現、判断理由を記録すると、翻訳者や担当者が変わっても過去の判断を参照できます。機能追加で意味が変わった際は、関連する画面とヘルプも確認します。
同じ翻訳者が長く担当する利点は、製品知識と判断の経緯が蓄積されることです。ただし、担当者の記憶だけに依存すると引き継ぎが難しくなるため、承認済みの表現と更新履歴を共有できる資料として残します。MacroLingoは、既存の社内用語集を確認し、資料がない場合は翻訳を進めながら用語と使用例を記録します。
翻訳管理ツールは、開発と承認の流れに合わせて選ぶ
翻訳管理ツールは、文字列、過去訳、用語集、質問、承認状況を一か所で扱うための仕組みです。Lokalise、Phrase、Crowdin、Smartlingなどの候補を比較する際は、製品の更新頻度、開発環境、翻訳者への画面共有、レビューの担当者を先に確認します。導入するツール名だけで翻訳品質が決まるわけではありません。
| 候補 | 確認したい運用 |
|---|---|
| Lokalise | デザインと開発の変更を翻訳へ渡す方法、画面の文脈共有、承認の流れ |
| Phrase | 複数チームの役割分担、過去訳と用語集の運用、更新の追跡 |
| Crowdin | リポジトリとの連携、ブランチごとの翻訳とリリースの管理 |
| Smartling | 画面を参照する翻訳とレビュー、複数言語の担当者や進捗の管理 |
| DeepL API | 仮訳の生成と文脈・用語集の指定。画面確認や承認の工程は別途用意する |
利用できる連携やAI機能は契約と設定によって異なるため、候補のツールで自社の文字列を試し、質問から承認、実装まで追えるか確認します。同じ翻訳エンジンでも、渡す文脈や用語集、承認済みの過去訳が違えば出力は変わります。エンジンの名称だけを比べるより、翻訳者が必要な情報を参照できる運用かどうかを確かめます。
公開前に、英語を実際の画面で確認する
翻訳一覧で英文を確認した後は、英語版を実際に操作して検証します。ボタンを押した結果が文言と合うか、エラーから復帰する方法が分かるか、狭い画面や文字を拡大した状態で表示が切れないかを確認します。英語の文字数だけで判断せず、表示幅と改行も見ます。
開発段階では、文字を長くしたり記号を加えたりする擬似ローカライズで、表示の崩れを探す方法も使えます。翻訳が届く前にレイアウトの問題を見つけるための確認であり、英文の意味や自然さを検証するものではありません。翻訳後の画面確認と組み合わせて使います。
アクセシビリティの確認では、画面に表示するボタン名と、支援技術が参照する名前を別々に訳したままにしないよう注意します。WCAG 2.2の「Label in Name」は、文字による表示ラベルを、その操作部品のアクセシブルな名前に含めることを求めています。たとえば画面が Save なのに読み上げ用の名前が Submit changes だけでは、表示をもとに音声で操作する人が目的のボタンを指定しにくくなります。
アカウント数やファイル数などの表示は、0、1、複数で試し、変数や単位が正しく表示されるかも確認します。日付や通貨は利用する市場に合わせ、翻訳担当者が英文を承認した後も、開発担当者が実装結果を確認する流れにします。ユーザーテストを行う場合は、操作の迷い、やり直し、誤った選択を記録すると、どの文言を見直すべきか判断できます。
日本側の担当者と、翻訳を発注する前に確認すること
日本側には、機能の意図を説明し、仕様や用語の質問を社内で確認できる担当者を置きます。翻訳者が日本語でやり取りできれば、担当者全員に高度な英語力が必要なわけではありません。英語版で変えてよい表現と、同意事項など変更に承認が必要な内容を決めておくと、確認の行き違いを減らせます。
発注時には、対象市場とユーザー、翻訳する画面の範囲、用語集や過去訳の有無、公開予定、更新頻度を共有します。文字列だけを渡して納品日を決めるより、質問への回答、英文の承認、実装後の確認を誰が担当するかまで決めておくほうが、公開直前の修正を管理できます。
- 日本語原文と画面の意図を理解し、英語UIの表現を判断できる担当者がいるか
- 用語の調査や製品担当者への質問が、見積もりと工程に含まれているか
- 翻訳中に仕様が変わった場合、どの文字列を再確認するか追跡できるか
- 実装後の画面確認と、公開後の更新対応を依頼できるか
MacroLingoは、日本語の意図を確認し、対象ユーザーと機能に合う英語を提案します。新規のUI英訳、既存英語版の見直し、AI翻訳後の修正については、お問い合わせから、製品と必要な作業範囲をお知らせください。
UI翻訳を依頼する際によくある質問
AI翻訳を最後にネイティブが読むだけで十分ですか？
英文だけを読む確認では、原文の誤解や操作との食い違いを見逃します。日本語、仕様、実際の画面を参照できる担当者が、必要な箇所を書き直し、実装後の表示まで確認する範囲を決めてください。
翻訳者は、最初から業界の専門家である必要がありますか？
すべてを知っている必要はありませんが、用語を調べ、専門家へ確認する能力と時間は必要です。医療や法務に関わる文言では、英語の自然さを確認する担当者と、内容を承認する専門担当者の役割を分けておくと、確認範囲が明確になります。
社内に用語集がなくても依頼できますか？
既存の画面や資料、過去訳をもとに、翻訳と並行して用語集を作れます。単語の対応だけでなく、使用例と採用理由を残すことが、次の機能追加や担当者の引き継ぎに役立ちます。
