Movatterモバイル変換


[0]ホーム

URL:


enechain Tech Blog

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

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

ogp

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

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

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

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

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

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

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

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

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

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

power

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

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

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


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

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

UIの文脈3つ

言い換えると、その瞬間のユーザーの認知状態を含めた一連の状況こそ、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 processRun settlement
Archive initialization completedArchive ready
Unauthorized endpoint accessYou 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 deleteLinkage としても、現地のユーザーには伝わりません。

  • 日本語: 「紐付けを解除する」
  • 直訳: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に一括翻訳させます。

  • 日本語のUIテキスト(原文)
  • 画面の種類やコンポーネント種別(エラー、ボタン、トーストなど)
  • 関連するスクリーンショットor簡単な説明

その上で、人間がしっかりレビューすべきは「ここ」というルールを決めておきます。例えば、以下のような内容です。

  • 課金・請求まわり
  • アカウント・権限・セキュリティ関連
  • 法務リスクがありそうな部分
  • 重大な操作(削除・約定・キャンセル・決済など)


STEP4:フィードバックを“辞書とAI”に戻す

レビューした結果、知見が出たらサイクルに落とします。

  • 「この表現いいな」
  • 「この言い方は毎回こうしたい」
  • 「ここの訳は危なかったから禁止したい」

 ↓

  • 用語集・スタイルガイドを更新する
  • 代表パターンに追加する
  • 次回のAIプロンプトに反映する

こうしていくと、プロダクトが成長するほど“うちのUIテキストに強い翻訳AI”が育っていく状態になります。


多言語対応のAIと人間の棲み分けとは?

  • 人間の仕事:最初の設計
    • 用語とトーンのルール作り
    • 危険ゾーンの最終判断
  • AIの仕事:ルールと辞書を踏まえた一括翻訳
    • 大量の画面への適用
    • パターンの再利用

多言語対応の現実解は、「翻訳をAIに投げる」ではなく、「UIテキストの設計ルールと辞書をAIに学習させて、任せられる範囲を最大化する」ことだと思います。

英語UIテキストに向き合うことは、日本語UIを強くする

このように、英語UIテキストについて考えてきた学びは、そのまま日本語UIテキストにも効くと感じました。

  • 日本語UIテキストの弱点

    • 主体が消える
    • 専門用語が複雑
    • 丁寧語に逃げる
    • 情報を詰め込みがち
  • 英語UIテキストで気づいたこと

    • 短く・具体的に
    • 語彙はユーザー側に寄せる
    • 主語や操作主体を明確にする
    • トーンは長さでなく“言い回し”で作る

上のような英語UIテキストの”心配り”をできる = どの言語でも優しいUIが書ける に直結するのではないでしょうか。言語を往復することで見えてくる新しい視点があり、各言語も洗練されそうです。

まとめ:翻訳ではUXは作れない。言葉もインタラクションとして設計する。

最後に、この記事の核心をもう一度おさらいします。

  • UIテキストは、インタラクションの中心
  • 日本語→英語の直訳は優れたUIテキストの原則を破壊する
  • だからUIテキストは「翻訳」ではなく「設計」が必要
  • 英語UIテキストへの”心配り”の視点は日本語UIテキストにも効く

Instead of "translating", Let’s talk with users in the UI.

そのままの翻訳ではなく、対話をデザインするような視点がUIテキストには必要です。英語UIテキストを考える中で、日本語にも通じる「言葉の設計」と向き合うことができました。

この記事は社内開催のEnglish LT会で英語登壇した内容を元に、Tech Blog用に情報を補足して作成しています。enechainは英語活用を推進しており、英語を使った活動や海外カンファレンスへの参加もWelcomeな環境です!興味を持った方はぜひカジュアル面談へのご連絡をお待ちしています!

herp.careers

tech.enechain.com

enechain Tech Blog
id:enechain

enechainは、国内最大のエネルギーのマーケットプレイスを運営するスタートアップです。誰もが参加でき、あらゆるエネルギーの価値を交換できるフェアなマーケットを創ることで、社会が秘めたる可能性を掘り起こし、人々の豊かさと世界の平和に貢献します。

カテゴリー
人気記事
検索

引用をストックしました

引用するにはまずログインしてください

引用をストックできませんでした。再度お試しください

限定公開記事のため引用できません。

読者です読者をやめる読者になる読者になる

[8]ページ先頭

©2009-2025 Movatter.jp