製品仕様書の英語翻訳では、読みやすさに加え、仕様の条件を変えずに伝えることが重要です。「必要」と「推奨」、「最大」と「標準」、説明文とコードなどの区別が曖昧になると、実装や評価で違う理解が生まれます。
この記事では2026年10月31日を基準に、製品・ソフトウェア仕様書の翻訳前に整理したい項目を紹介します。旧キャンペーンの割引率や取引件数を現在の条件として扱わず、原稿と確認工程に焦点を当てます。
対象の製品・版・読者を明確にする
同じ仕様書という名称でも、開発者が実装するための資料、購入者が性能を比較する資料、試験担当者が条件を確認する資料では読み方が異なります。製品の型式、ソフトウェアの版、読者、使用目的を依頼書にまとめます。
仕様の説明に関連する図面、画面、用語集、変更履歴を共有します。参考資料と翻訳対象の原稿は区別してください。旧版を参考に使う場合は、継承できる内容と廃止された機能を確認し、同じ用語があるという理由だけで文章を流用しないようにします。
資料の中で設計が未確定なら、その箇所を明示します。翻訳者が不明点を補って仕様を決めることは避け、設計者や製品担当へ照会する手順を用意します。原文の曖昧さを英語で断定に変えないことが大切です。
必須・推奨・任意の強さを保つ
「しなければならない」「することが望ましい」「できる」などは、要件の強さや意味が異なります。日本語の「できる」が、機能として可能なのか、許可されるのかも確認してください。英語へ置き換える前に、原文の意図を整理します。
例えばIETFのRFC 2119は、仕様の要件を表すMUST、SHOULD、MAYなどの意味を定めています。SHOULDは、特定の事情で例外があり得ても、影響を理解して判断することを含むため、単に弱い希望と扱うのは適切ではありません。
さらにRFC 8174は、この特別な意味を大文字の表記に限定する点を明確にしています。ただし、これらの規則をすべての企業の仕様書に自動的に適用するわけではありません。対象の文書が採用する規約と用語の定義を確認します。
原文に曖昧な表現がある場合は、どの強さの要件かを照会します。翻訳者の好みでshouldをmustへ変えたり、禁止を注意程度へ弱めたりしないようにします。採用した方針は、本文と表、試験条件の全体へ一貫して反映してください。
数値・単位・許容範囲をセットで確認する
仕様の数値は、単位、条件、範囲と一緒に照合します。上限と下限、標準値と保証値、測定時の環境条件などが別の場所に書かれている場合は、対応する箇所を確認します。数字だけが一致していても、仕様が同じとは限りません。
NISTのSI表記のチェックリストは、単位記号を複数形にしないこと、数値と単位記号の間隔などを説明しています。例えば質量の記号kgに複数形のsを付けない、といった確認ができます。平面角の記号には間隔の例外があるため、見た目だけで一括修正しないようにします。
単位の換算を行うかどうかは、翻訳と分けて合意します。元の単位を保つ、換算値を併記する、表示単位を変更する場合では、作業と承認が異なります。換算した数値の精度や丸め方は、製品の内容担当が確認します。
表から文章へ値を写すときは、符号、不等号、範囲、脚注も対象にします。比較の意味を持つ記号が欠けると、許容される条件が変わる場合があります。画像内の文字や小さな注記も、翻訳対象の一覧へ含めてください。
APIでは説明文と識別子を分ける
API仕様には、自然言語で書かれた説明と、プログラムが利用する名前や値が混在します。パス、パラメーター名、フィールド名、列挙値、コード例を、通常の文章と同じように訳してよいとは限りません。
参考例として、OpenAPI Specification 3.1.1は、フィールド名や値の多くで大文字・小文字を区別し、例外も示しています。またoperationIdには一意性と大文字・小文字の区別が定められています。この記事は3.1.1の記述を参照しており、全APIが同じ仕様を採用するとするものではありません。
例えば説明文の中の識別子を「読みやすくする」ために大文字へ変えたり、記号を全角に変えたりすると、実装と対応しなくなるおそれがあります。翻訳してよい部分と保持する部分を指定し、コードや構造を変えた場合は開発担当者の確認を受けます。
コード例の動作確認は、文章を翻訳しただけでは完了しません。検証に必要な環境、データ、権限を持つ担当者が確認し、実行していない例を「動作確認済み」と表示しないようにします。
設計者への質問と変更箇所を残す
原文の説明と図面が異なる、単位がない、参照先が旧版のままといった疑問は、該当箇所と一緒に整理します。質問には、原文、解釈が分かれる点、必要な回答を添えると、設計者が判断しやすくなります。
回答を得て仕様を確定したら、原文と訳文の双方を更新します。翻訳だけに正しい内容を入れると、後で日本語の旧説明から同じ問題が再発する可能性があります。変更の理由、承認者、適用する製品の版も記録してください。
複数の仕様書に同じ項目がある場合は、影響範囲を確認します。用語の置換だけで済む変更か、条件や図も変わる変更かを区別します。作業中の原稿と確定した原稿を別々に管理し、納品する版を明確にします。
翻訳の照合と製品の検証を分けて納品する
納品時は、原文と訳文の意味、用語、数字、単位、参照先、図表の対応を確認します。編集可能な元データ、完成PDF、用語表、照会記録など、必要な成果物を一覧にして受け取ります。
翻訳の正確さを確認することと、仕様に基づく製品の安全性、実装、試験結果を検証することは別です。翻訳によってバグや製品上の問題を必ず防げるとは説明できません。技術的な承認は、責任を持つ開発・品質担当者が行います。
JOHOへ仕様書の英語翻訳を相談する際は、製品と版、読み手、採用する規約、保持する識別子、単位の方針、照会先を共有してください。文書の条件を保つために必要な範囲と確認方法を整理します。
