直訳で良いUXは作れない - 英語のUIテキストと向き合い学んだ「言葉の設計」

ogp

この記事はenechain Advent Calendar 2025の14日目の記事です。

こんにちは！ET(@et_universe)です。普段は電力取引プロダクトのデザインをしています。

弊社では、お客様はもちろん、社内の仲間も国際化が進んでおり、過去のTech Blog記事にもあった通り英語の活用を推進しています。今回はそのような環境で、「英語のUIテキスト」について改めて考え、気づいた大切なことをまとめます。

まずはじめに伝えたいです。私は英語が得意ではありません！ しかし、デザイナーとして、英語利用者のお客様にも、私たちのプロダクトの体験が快適であってほしいという思いが強くあります。

そんな英語が苦手の私が英語UIに向き合った結果、強く実感したのは、

英語UIテキストは直訳ではなく、設計である

というシンプルだけれど根源的な視点です。

この記事では、UIテキストライティングの実践を考えながら、どうあるべきかを検討した“英語UIテキスト設計ガイド”をお伝えします。

ことばの鉄則：「文脈」の力
UIテキストは“最小のUX”をつくる
UIテキストの基本原則
日本語から英語への“直訳”が原則を破壊する理由
UIテキストを“設計”として書くためのアイデア
英語UIテキストに向き合うことは、日本語UIを強くする
まとめ：翻訳ではUXは作れない。言葉もインタラクションとして設計する。

ことばの鉄則：「文脈」の力

まずはじめに「POWER」この英単語を見て、何を思い浮かべるでしょうか？

power

電力？ ⚡️
権力？ 🏯
魔法のような能力？ 🪄
筋肉…？ 💪

どれも正しいですよね！同じ言葉でも、文脈によって意味はまったく変わります。言葉は、文脈の中でしか意味を持ちません。

そして、UIテキストも同じように、この“文脈”が大切です。どの画面で・どのタイミングで・誰に向けて書くかで、意味も印象もUXも大きく変わります。

UIテキストの「文脈」とは？

では、UIにおける「文脈」とはなんでしょうか？一般的な文章の前後関係だけではない文脈がUIテキストにはあると考えます。

UIの文脈３つ

言い換えると、その瞬間のユーザーの認知状態を含めた一連の状況こそ、UIテキストの文脈です。

だからこそ、正しい英語でも、文脈と合わなければ意味が壊れます。UIテキストで起きる「違和感の正体」は、ほぼすべて文脈の設計不足であり、ただの翻訳だけでは不十分な理由がここにもあります。

UIテキストは“最小のUX”をつくる

私は、UIテキストはユーザーとシステムの対話インターフェースのひとつと考えます。日本語でも、英語でも、UIに置かれた単語は、ボタンの色やアイコンと同じように、プロダクトの内でのユーザーの行動の指針となります。

UIテキストが担うインタラクションとしての機能

つまりテキストは、美しさのための飾りではなく“インタラクションそのもの”です。適切なUIテキスト設計は、磨き上げられたプロダクトのポテンシャルを最大限に引き出し、UXをよりよいものへと導きます。

UIテキストの基本原則

UIテキストがインタラクションであるならば、日本語でも、英語でも、優れたUIテキストにはどのような原則があるのでしょうか？まずは基本を考えてみます。

① Keep it short and concrete（短く、具体的に）

ユーザーは読むのではなく言葉をScan（一目見るだけ）しています。文章は短いほど、行動が速くなります。情報密度の高い業務UIでは1語短いだけでストレスが激減します。特に、業務UIでは、数秒の判断が生産性を左右します。情報は最短距離で伝えるべきです。

Bad（よくある過剰丁寧＆冗長UI）	👍️ Good（短く・具体的）
Please confirm the details before proceeding.	Check details.
The data import process has completed successfully.	Import complete.
You can now proceed to place your next order.	Place next order.
Your filters have been successfully applied.	Filters applied.

② Avoid technical jargon（技術専門用語を避ける）

“開発者語”や“社内語”をそのまま画面に出してしまうことは、ユーザーの理解を損ねるので避けなければいけません。

英語でも技術的な専門用語を避けて、ユーザーがぱっとみてわかりやすい言葉にすることが重要です。普段から利用になれていない専門用語はユーザーにとって理解コストが高く、ストレスがかかります。UIテキストは“正確”より“わかりやすく理解できる”が重要なので、ユーザーの身近な言葉でわかりやすく伝えることがより良いのではないでしょうか。

Bad（内部の人しか理解できない）	👍️ Good（ユーザー語で書く）
Sync execution failed.	Sync failed.
Execute settlement process	Run settlement
Archive initialization completed	Archive ready
Unauthorized endpoint access	You don’t have permission

③ Use user-centered language（ユーザー中心の言葉にする）

UIテキスト最大の落とし穴は、“主語が曖昧なまま、システム中心で書かれること”です。

エラーや制限などの文章はユーザー目線、つまりユーザーを主語にして説明しないと強烈に冷たくなります。行動主体、操作主体をユーザーにした言葉は、ユーザーにとっても自然にわかりやすくなります。

Bad（主体不在・システム中心）	👍️ Good（ユーザー中心・行動中心）
Order will be canceled.	Cancel order?
File cannot be uploaded.	You can’t upload this file.
Market data is being fetched.	Loading market data…
Settlement cannot be executed.	You can’t run settlement now.

日本語から英語への“直訳”が原則を破壊する理由

では、日本語から英語での直訳ではなぜこの原則が達成できないのでしょうか？実例を見て考えてみましょう。

1. 日本語は主体が消える → 英語は主体が必須

日本語： 「エラーが発生しました」
直訳： An error has occurred.

この直訳の文法は正しいですが、原則の ③ Use user-centered language を無視しています。主語が曖昧で誰の操作なのか見えず、冷たくて怖い印象を与えます。主語の無い日本語をそのまま訳すと、このような表現になってしまいます。この場合は、Something went wrong. を使うのがよりシンプルで自然な表現です。

2. 日本語の丁寧表現 → 英語UIでは冗長で不自然

日本語： 「〜してください」「〜お願いいたします」
直訳： Please kindly… / We would like you to…

日本語では丁寧語をUIでも使うことが多いです。しかし、それをそのまま直訳すると原則の ① Keep it short and concrete が達成できません。

英語UIでは、 Enter your name. Select date. のようなシンプルで短く簡潔な文章が好まれます。謝罪文などのような意図がなければ、丁寧な表現ではなくシンプルなほうがよりユーザーフレンドリーです。

3. 専門用語の直輸出で“意味不明な英語UI”になる

日本語の管理画面などでよくある「論理削除」や「紐付け」といった開発用語由来の言葉。これを直訳して Logical delete や Linkage としても、現地のユーザーには伝わりません。

日本語： 「紐付けを解除する」
直訳： Release linkage
英語UI： Unlink / Disconnect

文脈を汲み取らず単語単位で訳すと、原則 ② Avoid technical jargon を破壊し、ユーザーを混乱させます。

4. 日本語の情報圧縮 → 英語UIテキストでは文章詰め込みUIテキストになる

日本語： 「入力された数量が市場ルールの上限を超えています。この注文は受け付けられません。」
直訳： The entered quantity exceeds the market rule upper limit. This order cannot be accepted.
英語UI： Quantity exceeds market limit. Order rejected.

直訳は原則①・③・④すべてを破壊してしまいます。直訳という行為は、言語構造の違いにより“UIテキストの原則”と根本的に相性が悪いのです。だから、直訳ではUXが作れません。

UIテキストを“設計”として書くためのアイデア

UIテキストの重要性と直訳では不十分なことはわかっても、毎回1つ1つの言葉を文脈を考えて言葉を当てはめるのは、多言語対応をするプロダクトでは膨大な労力がかかって現実的ではないですよね。

そこで、AIと壁打ちしながら、すべてを毎回ゼロから人力でやるのではなく、「設計＋辞書＋AI」で仕組み化し、 現場で回せる形に落とし込んだフローを考えてみました。

STEP 0：まずは“辞書になる画面”を設計する（人間の仕事）

いきなり全画面に手を付けるのではなく、以下の画面だけを選び、前章までの考え方で人間がちゃんとUIテキストを設計します。

代表的なフロー（ログイン、一覧、詳細、エラー、設定など）
ビジネス的に重要な画面
トラブルになりやすい画面（権限／取引）
ここでやること：
- 日本語で「ユーザー視点のメッセージ」を書き直す
- 英語で「短く・ユーザー語・主体明確・責めない」テキストに落とす
- 画面上で検証し、「これをベースにしたい」と思えるパターンを作る

この代表パターン群が、後でAIに学習させる“UIテキストの辞書”になります。

STEP1：用語集（Glossary）とスタイルガイドを作る

代表パターンから、繰り返し出てくる用語と表現ルールを抜き出します。

電力・業界用語例
- 「インバランス」→ Imbalance
- 「時間前市場」→ Intraday Market
- 「取引」→ Trade
UI用語例
- 「同期」→ Sync
- 「削除」→ Delete
- 「取消」→ Cancel
トーン&ボイス
- エラー時は Something went wrong. 系で責めない
- 権限エラーは You don’t have permission. で統一など

これを用語集＋UIテキストガイドとしてまとめておきます。

STEP2：AIに“わたしたちのUIの書き方”を学習させる

次に、AIで翻訳する用にこの用語集と代表パターンをAIの翻訳前提知識として読ませる設計にします。たとえばプロンプトのイメージは以下のようになります。

あなたはB2Bプロダクト専任の熟練したUXライターです。
私の入力する日本語のUIテキストを、以下のガイドラインに従って最適な英語のUIテキストに書き換えてください。
単なる「翻訳」ではなく、ユーザーの操作を支援する「設計」を行ってください。

# ガイドライン（Principles）
1. **Keep it short**: ユーザーは読みません。スキャンします。冠詞（a/the）や冗長な丁寧語（Please kindly）は極力削除してください。
2. **User-Centered**: システムログ（例: "Error occurred"）ではなく、ユーザーへの語りかけ（例: "Something went wrong"）や、次のアクション（例: "Try again"）に変換してください。
3. **No Jargon**: 開発用語（論理削除、紐付けなど）は使用せず、一般的な動詞（Delete, Connect）を使ってください。
4. **Active Voice**: 受動態（"Files are uploaded"）ではなく能動態（"Upload files"）を優先してください。

# トーン＆マナー
- 責めない（Blameless）：ユーザーのミスを指摘せず、中立的に伝えます。
- 明快（Clear）：曖昧さを排除します。

# 固定用語集（Glossary）
- 添付した `glossary.csv` を、UIテキスト生成の際の**絶対的な基準**として参照してください。
出力する英語の中に `Japanese_Term` に該当する概念がある場合は、必ず `English_UI_Term` を使用してください。

# 出力フォーマット
提案は必ず以下の形式で出力してください。
1. **推奨案**: [ここに英語テキスト]
2. **理由**: [なぜこの表現が適切か、文脈を踏まえた解説]
3. **別案（さらに短く）**: [極限まで削ったバージョン]

こうすることで、「ふつうの翻訳」ではなく「わたしたちのプロダクトらしい英語UIテキスト生成」としてAIを使えるようになります。

STEP3：文脈付きでAI翻訳 → 人間が“危険ゾーンだけ”レビュー

多言語対応や画面数が多いときは、以下のセットでAIに一括翻訳させます。