
この記事はenechain Advent Calendar 2025の14日目の記事です。
こんにちは!ET(@et_universe)です。普段は電力取引プロダクトのデザインをしています。
弊社では、お客様はもちろん、社内の仲間も国際化が進んでおり、過去のTech Blog記事にもあった通り英語の活用を推進しています。今回はそのような環境で、「英語のUIテキスト」について改めて考え、気づいた大切なことをまとめます。
まずはじめに伝えたいです。私は英語が得意ではありません!しかし、デザイナーとして、英語利用者のお客様にも、私たちのプロダクトの体験が快適であってほしいという思いが強くあります。
そんな英語が苦手の私が英語UIに向き合った結果、強く実感したのは、
英語UIテキストは直訳ではなく、設計である
というシンプルだけれど根源的な視点です。
この記事では、UIテキストライティングの実践を考えながら、どうあるべきかを検討した“英語UIテキスト設計ガイド”をお伝えします。
まずはじめに「POWER」この英単語を見て、何を思い浮かべるでしょうか?

どれも正しいですよね!同じ言葉でも、文脈によって意味はまったく変わります。言葉は、文脈の中でしか意味を持ちません。
そして、UIテキストも同じように、この“文脈”が大切です。どの画面で・どのタイミングで・誰に向けて書くかで、意味も印象もUXも大きく変わります。
UIテキストの「文脈」とは?
では、UIにおける「文脈」とはなんでしょうか?一般的な文章の前後関係だけではない文脈がUIテキストにはあると考えます。

言い換えると、その瞬間のユーザーの認知状態を含めた一連の状況こそ、UIテキストの文脈です。
だからこそ、正しい英語でも、文脈と合わなければ意味が壊れます。UIテキストで起きる「違和感の正体」は、ほぼすべて文脈の設計不足であり、ただの翻訳だけでは不十分な理由がここにもあります。
私は、UIテキストはユーザーとシステムの対話インターフェースのひとつと考えます。日本語でも、英語でも、UIに置かれた単語は、ボタンの色やアイコンと同じように、プロダクトの内でのユーザーの行動の指針となります。

つまりテキストは、美しさのための飾りではなく“インタラクションそのもの”です。適切なUIテキスト設計は、磨き上げられたプロダクトのポテンシャルを最大限に引き出し、UXをよりよいものへと導きます。
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 linkageUnlink /Disconnect文脈を汲み取らず単語単位で訳すと、原則② Avoid technical jargon を破壊し、ユーザーを混乱させます。
4. 日本語の情報圧縮 → 英語UIテキストでは文章詰め込みUIテキストになる
The entered quantity exceeds the market rule upper limit. This order cannot be accepted.Quantity exceeds market limit. Order rejected.直訳は原則①・③・④すべてを破壊してしまいます。直訳という行為は、言語構造の違いにより“UIテキストの原則”と根本的に相性が悪いのです。だから、直訳ではUXが作れません。
UIテキストの重要性と直訳では不十分なことはわかっても、毎回1つ1つの言葉を文脈を考えて言葉を当てはめるのは、多言語対応をするプロダクトでは膨大な労力がかかって現実的ではないですよね。
そこで、AIと壁打ちしながら、すべてを毎回ゼロから人力でやるのではなく、「設計+辞書+AI」で仕組み化し、 現場で回せる形に落とし込んだフローを考えてみました。
STEP 0:まずは“辞書になる画面”を設計する(人間の仕事)
いきなり全画面に手を付けるのではなく、以下の画面だけを選び、前章までの考え方で人間がちゃんとUIテキストを設計します。
トラブルになりやすい画面(権限/取引)
ここでやること:
この代表パターン群が、後でAIに学習させる“UIテキストの辞書”になります。
STEP1:用語集(Glossary)とスタイルガイドを作る
代表パターンから、繰り返し出てくる用語と表現ルールを抜き出します。
電力・業界用語例
ImbalanceIntraday MarketTradeUI用語例
SyncDeleteCancelトーン&ボイス
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に一括翻訳させます。
その上で、人間がしっかりレビューすべきは「ここ」というルールを決めておきます。例えば、以下のような内容です。
STEP4:フィードバックを“辞書とAI”に戻す
レビューした結果、知見が出たらサイクルに落とします。
↓
こうしていくと、プロダクトが成長するほど“うちのUIテキストに強い翻訳AI”が育っていく状態になります。
多言語対応のAIと人間の棲み分けとは?
多言語対応の現実解は、「翻訳をAIに投げる」ではなく、「UIテキストの設計ルールと辞書をAIに学習させて、任せられる範囲を最大化する」ことだと思います。
このように、英語UIテキストについて考えてきた学びは、そのまま日本語UIテキストにも効くと感じました。
日本語UIテキストの弱点
英語UIテキストで気づいたこと
上のような英語UIテキストの”心配り”をできる = どの言語でも優しいUIが書ける に直結するのではないでしょうか。言語を往復することで見えてくる新しい視点があり、各言語も洗練されそうです。
最後に、この記事の核心をもう一度おさらいします。
Instead of "translating", Let’s talk with users in the UI.
そのままの翻訳ではなく、対話をデザインするような視点がUIテキストには必要です。英語UIテキストを考える中で、日本語にも通じる「言葉の設計」と向き合うことができました。
この記事は社内開催のEnglish LT会で英語登壇した内容を元に、Tech Blog用に情報を補足して作成しています。enechainは英語活用を推進しており、英語を使った活動や海外カンファレンスへの参加もWelcomeな環境です!興味を持った方はぜひカジュアル面談へのご連絡をお待ちしています!
引用をストックしました
引用するにはまずログインしてください
引用をストックできませんでした。再度お試しください
限定公開記事のため引用できません。