日本語のアプリUIを自然な英語にするには、経験のある英語ネイティブ翻訳者が必要です。AIや自動翻訳は英文をすぐに作れます。しかし、その英文がアプリの機能、対象ユーザー、専門分野に合っているかは別の問題です。日本語を一語ずつ置き換えた英語は、正しそうに見えても不自然で、ときには機能を誤解させます。アプリ翻訳の品質は、ツールの性能よりも、最終的に誰が調べ、判断し、責任を持って英語を選ぶかで決まります。
ポイント
- アプリUIには英語ネイティブの判断が必要
- 良い翻訳者は製品と専門用語を調べる
- AIと翻訳管理ツールは人の判断を支える
Contents
なぜアプリUIの英訳には、経験のある英語ネイティブが必要なのですか？
英語として自然なアプリUIは、原文の意味を理解したうえで、英語ユーザー向けに書き直す必要があるからです。日本語と英語では、丁寧さの表し方、自然な長さ、主語の置き方、機能名の付け方が違います。文法が正しいだけでは、使いやすい英語UIになりません。
日本語では「内容をご確認のうえ、登録をお願いいたします」のような丁寧な表現が使われます。英語アプリで同じ情報量を残すと、Please check the information and then proceed with registration. のような重い文になります。画面によっては Review and save や Save で十分です。
この判断には、英語を母語として使ってきた感覚とアプリUIの経験が要ります。英語ネイティブでも、アプリ翻訳に慣れていなければ、原文に引っ張られた長い文章を書いてしまいます。アプリ内の短い言葉で、動作と結果を自然に伝える経験が必要です。
ローカライゼーションは、製品を対象市場の言語や文化に合わせて調整する作業です。日本語の意味を保ちながら、英語圏のユーザーが普段使うアプリと同じ感覚で操作できるように言葉を整えます。
自社アプリの英語が直訳調に見える場合は、MacroLingoの翻訳・ローカライゼーションサービスで、現在のUIを確認できます。新規翻訳にも、既存英語版の全面的な見直しにも対応しています。
短いUI文言なら、AIや自動翻訳でも十分ではありませんか？
短いUI文言ほど、AIや自動翻訳には判断しにくいものです。一つの日本語に複数の英訳があり、正解は画面の機能と文法上の役割で変わります。短い原文には手掛かりが少ないため、ツールはもっともらしい候補を選んでも、その場面に合うとは限りません。
たとえば「連携」は、link、connect、cooperate、integrate などに訳せます。名詞なら integration や connection、ボタンなら Connect、状態表示なら Integrated が合う場合もあります。翻訳ソフトやAIは、同じ「連携」に複数の英語を混在させることがあります。反対に、すべてを integration に統一し、文法や動作に合わない英語を作ることもあります。
| 日本語 | 英訳の候補 | 人が確認すること |
|---|---|---|
| 連携 | link / connect / integrate / cooperate | システム接続、情報共有、企業間協力のどれか |
| 登録 | save / add / register / create | 保存、追加、会員登録、作成のどれか |
| 規約 | Terms of Use / Terms and Conditions / 独自名称 | 文書の内容、社内表記、法務上の位置づけ |
| 明細 | line item / details / statement | 個別項目、詳細画面、帳票のどれか |
「規約」を Terms とだけ訳しても、何の規約か分からないことがあります。Terms of Use や Terms and Conditions が合う場合もあれば、製品固有の正式名称が決まっている場合もあります。アプリ内の見出し、リンク、同意文では文法上の形も変わります。
Androidの公式ガイドも、アプリの文字列についていつ、どこで、何のために表示されるかを翻訳者へ伝えるよう案内しています。文字列そのものを入力するだけでは、AIにも人にも必要な文脈が届きません。
AI翻訳の英語が正しそうに見えるのに、なぜ危険なのですか？
英語を十分に判断できない担当者は、AIの出力が自然か、機能を正しく説明しているかを確認できないからです。単語や文の断片をDeepLやChatGPTへ入れると、流暢な英語が返ってきます。流暢さは正確さを保証しません。誤りに気づく人がいないまま、アプリへ実装される危険があります。
これは、英語ネイティブがスワヒリ語やロシア語を知らないまま、自動翻訳の出力を採用する状況と同じです。文章が整って見えても、自然さ、専門用語、文法上の役割を判断できません。翻訳を発注する側に多少の英語力があっても、ネイティブ向けUIの細かな違和感までは見抜けないことがあります。
AI翻訳は、学習させた用語、過去訳、スタイルガイドが不足すると、その場で一般的な候補を返します。専門分野の意味や社内ルールが変わっても、自動では追従しません。十分なトレーニング、再学習、更新、テストを続ける必要があります。
機械翻訳後の英文には、アプリの機能、実際の画面、用語集との照合が必要です。自然に読める英文でも、ボタンの動作や社内用語と合っていなければ、そのまま採用できません。
AIは翻訳者の作業を速められます。初稿、過去訳の検索、表記の確認には使えます。採用する言葉を決める人がいなければ、誤訳も速く大量に広がります。
経験のある英語ネイティブ翻訳者は、何をしているのですか？
経験のある翻訳者は、知らない分野をそのまま訳しません。社内の用語集、スタイルガイド、辞書、過去訳から調査を始めます。必要に応じて外部資料を読み、製品担当者や専門家へ確認します。翻訳を進めながら、新しく決まった用語と使い分けを資料へ追加します。
MacroLingoの代表は、ジャーナリストとリサーチャーとして訓練を受けています。知らないテーマを調べ、適切な情報源を探し、専門家へ質問することは通常の仕事の一部です。科学や技術の内容で正確な言葉が必要な場合は、その分野の専門家をプロジェクトへ加えることもあります。
アプリ翻訳者が最初から会計、契約、医療機器、電子工学の専門家である可能性は高くありません。それ自体は問題ではありません。良いジャーナリストや翻訳者と同じように、必要な知識を調べ、分からない点を質問し、採用した表現の根拠を残せることが必要です。
W3Cは、簡潔な文章は翻訳しやすく、母語以外で読む人にも理解しやすいと説明しています。翻訳者は日本語の丁寧さや長さを機械的に残さず、英語UIに必要な情報量へ調整します。
専門用語は、英語ネイティブなら正しく訳せるのですか？
英語ネイティブという条件だけでは、専門用語を正しく訳せません。翻訳者は、その用語が属する制度、業界、機能を調べる必要があります。辞書に載っている英語が正しくても、対象ユーザーやアプリ内の使い方に合わない場合があります。
たとえば「インボイス制度」は、日本国内では制度名だけで意味が通じます。英語では Invoicing System と訳せますが、海外の読者には何の制度か分かりません。Japan’s Qualified Invoicing System のように日本の制度だと示す必要がある場合があります。海外ユーザーに関係しない機能なら、英語版から説明ごと外す判断も考えられます。
この判断は、単語の英訳を選ぶ作業を超えています。誰がアプリを使うのか、その制度が操作に影響するのか、英語版でも表示する必要があるのかを確認します。翻訳者は製品担当者から情報を受け取り、海外ユーザーに必要な表現を提案します。
MacroLingoは、Sansan株式会社のB2B SaaSサービスとアプリの英訳に長く携わってきました。請求書関連のアプリでは会計用語を調べ、契約管理のアプリでは契約用語を学びました。ほかにも、大手日本企業の技術文書、医療機器メーカー、テクノロジー企業の英語制作を担当しています。
この経験で得たのは、すべての分野を最初から知っているという立場ではありません。必要な調査を行い、専門家と確認し、製品ごとの表現を長期的に育てる方法です。MacroLingoと代表者の経歴では、日本企業と英語圏の読者をつないできた背景を紹介しています。
長く同じ翻訳者と仕事をするメリットは何ですか？
同じ翻訳者が継続して担当すると、製品知識と用語の判断が蓄積されます。最初の翻訳時に作った用語集を、機能追加や市場の変化に合わせて修正できます。過去に選んだ英語が新しい画面で合わなくなった場合も、理由を確認してアプリ全体を見直せます。
社内用語集がある場合、MacroLingoはそこから作業を始めます。用語集がなければ、翻訳を進めながら作成します。既存の表記にも、文脈や対象ユーザーに合わせた使い分けを加えます。
たとえば「連携」の基本訳を integration と定めても、ボタンには Connect、解除操作には Disconnect が必要になる場合があります。用語集には単語の対応に加え、品詞、使用画面、採用しない表現、判断理由も残します。
こうした資料は一度作って終わりません。アプリの更新とともに育てます。数年間にわたって同じクライアントと仕事をすると、翻訳者は製品、社内用語、ユーザーの期待を深く理解できるようになります。
Lokaliseのような翻訳管理ツールがあれば、人の翻訳者は不要ですか？
翻訳管理ツールは、文字列、用語集、コメント、過去訳、承認状況を整理するためのものです。Lokaliseは一例で、ほかにも多くの選択肢があります。ツールは継続的な更新を管理しやすくしますが、どの英語が自然で正確かを決める役割は人に残ります。
よく使われるツールには、次のようなものがあります。
| ツール | 日本企業のアプリ翻訳で向いているケース | アプリ翻訳でできること | 注意点 |
|---|---|---|---|
| Smartling | 多数のアプリや言語を扱う大規模な企業 | 画面を見ながら翻訳できるビジュアルコンテキスト、翻訳メモリ、用語集、承認フローを一つの環境で管理できる | 企業向けの機能が中心で、小規模なチームには費用や運用負担が大きくなる場合がある |
| Phrase | 複数の社内チーム、翻訳会社、海外拠点が関わる継続的な翻訳 | アプリやソフトウェアの文字列、翻訳メモリ、用語、担当者、ワークフローをまとめて管理できる。FigmaやGitHubとの連携にも対応している | 機能と設定項目が多く、翻訳以外の担当者には導入や操作が複雑に感じられる場合がある |
| Crowdin | GitHubやGitLabを使う開発チーム、コミュニティ翻訳を行う製品 | リポジトリとの同期、ブランチごとの翻訳管理、品質チェック、画面プレビューに対応する。 | 用語集、スタイルガイド、スクリーンショットなどを用意しなければ、製品固有の文脈は翻訳へ反映されない |
| DeepL Pro API | APIを使って仮訳を素早く生成したい小規模なチーム | 開発環境や社内ツールへ組み込み、日英の初稿を自動生成できる。用語集も利用できる | 翻訳管理、画面上での確認、質問、承認、人によるレビューを単体では管理できない |
| Lokalise | Figmaを使うデザイン・製品チームと、継続的に更新されるアプリ | Figma、GitHub、GitLabなどと連携し、文字列、コメント、用語集、翻訳メモリ、承認状況を管理できる。DeepLやGoogle Translateを使った仮訳も作成できる | 利用できる自動化やAI機能は料金プランによって異なる。ツール内に文字列を入れただけでは、対象ユーザーや専門分野の判断までは得られない |
これらの翻訳管理プラットフォームは、それぞれ異なる画面や機能を持っています。ただし、自動で初稿を作る際には、DeepL、Google Translate、汎用AIなど、同じような外部エンジンを利用するケースが多くあります。エンジンが変わらなければ、管理画面が違っても、翻訳そのものが製品を深く理解するわけではありません。
自動生成された英語は、レイアウト確認、文字数のテスト、開発中のダミー表示などに使えます。この段階では、暫定的な仮訳として役立ちます。公開するUIには、画面の目的、操作後の結果、対象ユーザー、社内用語、業界知識を踏まえた人の判断が必要です。
翻訳管理の仕組みがあれば、用語を変更した際にアプリ全体を検索し、関連する表現をまとめて修正できます。過去の判断や質問も残せます。
同じツールへAI翻訳を組み込んでも、判断の問題は消えません。AIが「連携」を link と訳した画面と integrate と訳した画面を、人が確認します。違いに理由があるのか、表記が乱れているのかを判断し、必要なら全体を修正します。
翻訳管理ツールは、人が調べ、相談し、決めた内容をアプリ全体へ反映するために役立ちます。ツールだけを導入し、判断できる翻訳者を置かなければ、誤訳を効率よく管理するだけの状態になります。
日本側に英語が分かる担当者は必要ですか？
日本側には、英語ネイティブ翻訳者からの質問を理解し、製品の意図を説明できる担当者が必要です。求められるのは流暢な英作文よりも、日本語と英語の構造が違うことを理解し、一対一の置き換えに固執しない姿勢です。
日本語は英語より形式的で、説明が長くなる傾向があります。日本語の略語や制度名には、海外ユーザー向けの説明を加える場合もあります。自然な英語にするため、語順、長さ、品詞、情報量を変える必要があります。
日本側の担当者が原文と同じ単語数や構造を求め続けると、翻訳者は自然な英語を書けません。ユーザーは外国語を無理に当てはめたようなUIを目にします。操作のたびに違和感が続けば、製品そのものへの信頼も下がります。
担当者は、翻訳者の質問に答え、必要な社内確認を行い、英語版で変えてよい部分を判断します。英語ネイティブ翻訳者は、その情報から自然なUIを作ります。
アプリの翻訳チームは、何を基準に選べばいいですか？
翻訳チームを選ぶ人は、単価や納期に加え、誰が最終的な英語を判断するかを確認してください。ネイティブ確認という言葉だけでは、その人の経験や担当範囲が分かりません。アプリUIの経験、製品を理解する時間、専門用語の調査方法、継続更新への対応を聞く必要があります。
確認したい項目は次のとおりです。
- 英語ネイティブがすべての最終表現を確認するか
- 翻訳者が日本語を理解し、原文の意図を質問できるか
- 未知の専門分野を調べ、必要に応じて専門家へ相談するか
- 用語集とスタイルガイドを長期的に更新できるか
MacroLingoは、英語ネイティブによる翻訳、日本語原文の理解、専門分野の調査、翻訳管理ツールを使った継続対応を一つのプロセスにしています。アプリの新規英訳、AIで作られた既存UIの修正、長期的な更新について、お問い合わせください。
アプリUI翻訳について、発注前に何を確認すればいいですか？
発注前には、英語版の対象ユーザー、社内用語集の有無、日本側の担当者、継続更新の予定を共有します。すべてが決まっていなくても構いません。翻訳チームが何を調べ、誰へ質問し、誰が最終判断するかを先に確認してください。
AI翻訳をネイティブが最後にチェックすれば十分ですか？
最後に英文だけを読むチェックでは足りません。ネイティブ担当者がアプリの機能、画面上の文脈、社内用語を理解し、必要な箇所を書き直す必要があります。作業範囲は校正より広くなります。
英語ネイティブなら、日本語が分からなくても翻訳できますか？
日本語原文の意図を理解できる人が必要です。翻訳者本人に十分な日本語力があるか、日本語担当者と直接確認できる体制を用意します。機械翻訳された原文だけを見て英語を直す方法では、元の意味が失われていても気づけません。
翻訳者が専門家でない場合は問題ですか？
最初からその分野の専門家である必要はありません。用語を調べ、信頼できる資料を読み、専門家へ確認する能力が必要です。調査時間を見積もりと工程に含めます。
社内に用語集がない場合でも依頼できますか？
依頼できます。既存のアプリ、資料、過去訳を確認し、翻訳を進めながら用語集とスタイルガイドを作ります。次回以降の更新では、その資料を使って判断を揃えます。
翻訳管理ツールは何を選べばいいですか？
Lokaliseを含め、多くの選択肢があります。現在の開発方法、承認の流れ、更新頻度に合うものを選びます。ツール名よりも、経験のある翻訳者と日本側の担当者が使い続けられる仕組みかどうかを確認してください。
