同じ資料の中で、見出しの大文字、単位の書き方、画面の名称がばらついていると、読む人は内容の違いなのか、単なる表記の違いなのか迷います。英語翻訳では、意味が正しいことに加えて、必要な箇所の書き方をそろえる作業が大切です。
ただし、統一とは同じ日本語をすべて同じ英単語に置換することではありません。この記事では、用語の定義そのものより、綴りや記号などの表記を整える方法に焦点を当てます。参照資料は2026年10月31日時点で確認し、例は編集上の提案として示します。
まず、どの資料のどのルールに合わせるか決める
翻訳の着手前に、対象国・地域、読者、媒体、既存資料の指定をまとめます。米国向けと英国向けで綴りの選択が異なることがありますが、地域名だけで全文の細かな書き方が自動的に決まるわけではありません。顧客や出版社が指定するスタイルも確認します。
Googleの技術文書向けガイドは、プロジェクト固有の指針を先に参照し、その後に同ガイドや外部資料を使う順序を示しています。これを参考に、自社の案件でも「承認済みの製品表記」「案件の指定」「参照する一般ガイド」の関係を決めると判断が揃いやすくなります。
以前の資料に書かれているからという理由で、誤りまで継承する必要はありません。既存の指定が規格や現行製品と衝突した場合は、変更案と理由を確認者へ渡します。採用する版、判断日、適用する資料の範囲を残し、未承認の案を正式ルールとして配らないようにします。
綴り・大文字・約物を小さな表にする
最初から大きなルール集を作るより、今回の原稿に実際に出てくる項目をまとめると実用的です。綴り、見出しの大文字、ハイフン、引用符、略語の初出など、迷いやすい箇所に例を添えます。
Microsoftのスタイルガイドは、見出しなどで先頭語と固有名詞を大文字にするsentence-styleを基本にしています。これは同社の指針であり、すべての英文見出しに強制される唯一の方式ではありません。Title Caseを採用する媒体なら、その媒体のルールに合わせます。
| 項目 | 決める内容 | 例外の扱い |
|---|---|---|
| 綴り | 対象地域と指定辞書 | 固有名称や引用内の綴りは別に確認 |
| 見出し | sentence caseかtitle caseか | 製品名の正式表記を保持 |
| 略語 | 初出で正式名称を併記する範囲 | 読者が知っている略語も用途で判断 |
| 日付・時刻 | 年月日の順、時差の明示方法 | システム入力欄の指定は別に扱う |
| 数値・単位 | 規格と分野の要件 | 仕様値の変更は表記修正と分離 |
例を示す際は、採用形と不採用形だけでなく、どこに適用するかも書きます。本文、画面、引用、ファイル名では同じルールを使えないことがあるためです。全文検索で見つかった候補を、文脈を見ずに一括修正しないようにします。
単位記号は、数字と意味を一緒に確認する
BIPMの国際単位系(SI)第9版・2026年6月更新版では、数値と単位記号の間に空白を置く書き方が説明されています。たとえば質量なら「8 kg」、温度なら「20 °C」という形です。平面角の「45°」などは例外なので、度の記号があるものをすべて同じ処理にしないでください。
また、単位記号は通常の英単語の略語と同じではなく、複数を示すsを付けません。数値の後のkgをkgsへ変更したり、見出しの大文字ルールに合わせて単位記号を任意に大文字化したりしないようにします。名称を単語で書く場合と記号で書く場合も区別します。
表記を整える過程で、測定値や許容差まで変えないことも重要です。たとえば原文の桁数を勝手に増減すると、元の測定や仕様の示し方が変わる可能性があります。単位換算を求められた場合は、換算の条件、丸め方、確認者を別に定めます。読みやすくする修正と、数値を計算し直す作業を同じ扱いにしないでください。
操作説明では、実際に表示される名前を照合する
製品マニュアルでは、文章だけが自然でも、画面にないボタン名を書けば操作できなくなります。画面の言語、ソフトウェアの版、対象機能を確認し、説明文と表示名の対応を取ります。承認済みの画面一覧やスクリーンショットがあると確認しやすくなります。
Microsoftの操作手順の書式ガイドも、画面との一致が必要な場合の大文字の扱いを区別しています。一般の文章を整える規則と、利用者が探すラベルを正しく指すことは両立させる必要があります。
たとえば製品に「Save draft」という表示があるなら、本文の説明で別の操作名を創作しません。画面の表記を引用するのか、機能を普通の文章で説明するのかを決めます。UIの訳語がまだ確定していない場合は、マニュアル側だけ先に確定させず、照合待ちとして管理します。

同じ語を使うことと、同じ意味を保つことは別
原文の日本語が同じでも、指すものが違えば英語を分ける必要があります。たとえば「画面」が物理的な表示装置を指す場合と、アプリ内の一つの表示領域を指す場合を、機械的に同じ単語へそろえるとは限りません。先に概念を確かめ、その意味ごとに呼称を統一します。
反対に、同じ機能を説明しているのに担当者ごとに別の呼称が使われているなら、読者は複数の機能だと思うかもしれません。こちらは用語集や製品の正式名称へ戻って修正する対象です。「見た目を同じにする」ためのルールと「何を指すかをそろえる」ための用語管理を分けると、確認の漏れを減らせます。
長い文書であっても、必ず冒頭にすべての単語の定義章を設ける必要はありません。対象読者と媒体に応じて、用語集、初出説明、別紙のスタイル表などを選びます。利用者が必要な説明へ到達できる配置を考えてください。
納品前は、検索と表示確認を組み合わせる
文書全体から、綴りの揺れ、旧製品名、略語、単位記号などの候補を検索します。ただし、検索で見つからないことだけを合格の根拠にせず、本文・見出し・表・図・画面画像を実際に読みます。図に焼き込まれた文字は通常の本文検索で検出できない場合があるためです。
Wordや編集用データで揃っていても、PDFやWebへの変換で、改行や文字化けが起きることがあります。数値と単位が別の行に分かれて読みづらくなっていないか、引用符や記号が正しく表示されるか、図と本文の名称が一致するかを最終形式で確認します。
納品時には訳文に加えて、採用した表記ルール、例外、未回答の照会事項を残します。次の改訂で担当者が変わっても、選択の理由が追えるようにするためです。JOHOへ相談する際も、対象地域、既存の指定、用語集、画面資料を共有すると、必要な統一と照合の範囲を具体化できます。



