テクニカル翻訳：正確なドキュメントのための実践的ワークフロー

テクニカル翻訳は、専門的な情報を別の言語に伝達し、読者が概念を理解したり、仕様を比較したり、タスクを正確に実行できるようにするものです。機器のマニュアル、エンジニアリング仕様書、ソフトウェアドキュメント、調査報告書などの文書を対象としています。語彙を知ることは必要ですが、指示、値、図表、バージョンの関係性を維持することも同様に重要です。

テクニカルライターやプロジェクトオーナーにとって、最初の決定事項は翻訳エラーがもたらし得る影響であり、どのツールが最も速くドラフトを作成できるかではありません。翻訳を誤った概要段落と、逆になった動作条件を、同じ優先順位で同じレビューキューに入れるべきではありません。

このガイドでは、ドキュメント横断型のワークフローを提供します。フォーマット固有の詳細な作業については、ユーザーマニュアル翻訳ガイドまたは研究論文翻訳ガイドを使用してください。テクニカル翻訳コントロールマトリックスをダウンロードして、以下の決定事項を割り当てられたチェック項目に変えてください。

主題だけでなく用途によってドキュメントを分類する

技術文書はいくつかの目的に役立ちます。エンジニアは、背景情報を得るために翻訳された調査報告書を読んだり、購買決定のために仕様をコピーしたり、稼働中の機器で手順に従ったりする場合があります。主題が同一であっても、エラーの結果は大きく異なる可能性があります。

プロジェクトを定義する際は、このリスクマップを使用してください。これは認証スキームではなく、計画フレームワークです。

ファイルが短いからといって低リスクであると推測しないこと。1ページの仕様書は、長い解説レポートよりも重大な情報を含んでいる場合がある。

規制対象または安全性がクリティカルな資料の場合、機械翻訳が一切許可されるかどうかを責任ある専門家に判断してもらうこと。見た目の良いドラフトは、規制当局の承認や運用の安全性の証拠にはならない。

翻訳を依頼する前に受入要件定義書を作成する

ターゲットロケール、オーディエンス、目的、ソースの改訂版、出力フォーマット、承認オーナーを定義する。「スペイン語に翻訳する」では、読者がメキシコのエンジニアなのか、スペインの消費者なのか、社内作業コピーを使用する研究者なのかが決まらない。

米国翻訳者協会（ATA）の技術プロジェクトに関するガイダンス米国翻訳者協会（ATA）の技術プロジェクトに関するガイダンスは、編集可能なソース資料、オーディエンスと目的の情報、参考資料、およびレビューのための時間の準備を推奨している。また、一般的なバイリンガル能力があれば十分だと安易に考えるのではなく、翻訳者の関連する専門性を確認することを勧めている。

要件定義書は、次の運用上の質問に回答するものである必要がある：

• どのソースファイルとリビジョンが権威あるものか？
• どの添付資料、埋め込み図、スプレッドシート、またはリンクされたファイルが含まれているか？
• 出力は閲覧用のコピーか、編集可能な作業用ドキュメントか、それともリリース成果物か？
• どの数値、識別子、製品ラベル、用語について管理された処理が必要か？
• 技術的な曖昧さを解消できるのは誰であり、ターゲット言語の表現を承認できるのは誰か？
• 完了を示す証拠は何か：レビュー済みファイル、課題ログ、解決された参照、または署名されたリリースレコードか？

ソースを任意のサービスと共有する前に、機密性とアップロードの権限を設定する。文書翻訳プライバシーチェックリストは、有用なベンダーへの質問と、根拠のないセキュリティの思い込みを切り分けている。

コンテキストを維持するソースパッケージの準備

可能な限り、ネイティブのオーシャリングファイルと、意図された表現を示すPDFリファレンスを要求します。編集可能な図のラベルやリンクされたアセットも同梱してください。PDFが唯一のソースである場合は、欠落したオーシャリング構造を常に復元できると仮定するのではなく、その制限事項を記録してください。

翻訳の前に、テキスト選択可能なPDFと画像のみのスキャンを区別します。OCRには認識ステップが追加されます。間違った文字が、誤ったソースのそれらしい翻訳になってしまう可能性があります。その分岐については、次のツールを使用して認識品質を検証します。スキャン済みPDFワークフロー.

曖昧なソースの表現を明確にします。次の架空の仕様文を考えてみます。

コントロールモジュールはドライブユニットを監視します。点検の前に切断してください。

代名詞により、2文目の目的語が不明確になっています。翻訳者はどのコンポーネントを指しているのか尋ねることができますが、流暢な自動出力では、その未解決の疑問が隠されてしまう可能性があります。ドキュメントの所有者は、誰も翻訳を承認する前に、ソース内でそのコンポーネントを指定する必要があります。翻訳者に操作手順を勝手に作らせないでください。

Microsoftのグローバルコミュニケーション向けライティングガイダンスは、明確な文の構成、一貫した用語、翻訳が困難な表現の回避をサポートします。必要な技術的詳細を削ぎ落とすのではなく、これらの原則を適用して曖昧さを取り除きます。

概念をリテラル文字列とは別に管理する

理解に影響を与える概念を中心に、短い用語レジスターを作成します。各エントリには、定義、ソースコンテキスト、承認されたターゲット用語、却下された代替案、決定所有者を含めます。単純な2列の単語リストのままでは、「bearing」、「terminal」、「range」のどの意味が適用されるのか翻訳者が推測せざるを得なくなります。

部品番号、コマンド名、URL、ファイルパス、実際の製品と一致する必要があるインターフェイスラベルなど、リテラル文字列の別個のリストを維持します。ローカライズすべきラベルもあれば、表示されたままにする必要があるラベルもあります。「すべて翻訳する」という1つのグローバルなルールを適用する代わりに、選択内容を記録します。

たとえば、reset_cacheという名前のコマンドは、説明フレーズ「キャッシュをリセットする」とは異なる種類の項目です。コマンドには完全一致チェックが必要であり、フレーズには正確で自然な翻訳が必要です。

未解決の質問を、ソースの場所とドキュメントを変更する回答とともに1か所に記録します。翻訳者からの質問ワークフローは、複数のレビュアーや言語が同じ不明確さを共有している場合に役立ちます。

成果物に合わせてワークフローを選択する

次の分岐により、一般的な技術翻訳プロセスが手動のみのチェックリストになってしまうのを防ぎます。

承認された翻訳がバージョン間で繰り返し使用される場合はCATベースのワークフローが役立つことがあり、1回限りの閲覧やレビュー作業にはファイルレベルの翻訳ドラフトが適している場合があります。どちらを選択した場合でも、最終文書の確認作業が不要になるわけではありません。CATツールと機械翻訳の比較では、人間主導、自動、ハイブリッドのワークフローからどのように選択すべきかを解説しています。

パッケージ全体を処理する前に、代表的なセクションを使用して、選択したワークフローが必要なフォーマットに対応できるかどうかを確認してください。簡単な導入ページだけでなく、難易度の高い素材も含めてください。表、図表、数式をレビュー環境まで正常に持ち込めない場合は、スケールアップする前にその問題を解決してください。

6つのレイヤーを検証し、それぞれに担当者を割り当てる

以下のマトリクスをリリースチェックリストとして扱ってください。誰かが文書に目を通しただけではチェックは完了しません。ソースの場所、ターゲットの場所、および結果が必要です。

レビュー中は数値と単位をまとめておく。具体的なルールの1つとして、NISTのSIガイドラインは、摂氏度を含め、数値とその単位記号の間にスペースを配置します。次のようなソース値25 °Cには単なるスペルチェック以上のものが必要です。つまり、数値、記号、そしてそれが説明する条件のすべてが重要です。単位の変換は個別の編集上の判断であり、翻訳中に黙って値を変換したり丸めたりしないでください。

PDF特有の納品確認については、引き続きPDF翻訳QAチェックリストをご覧ください。より幅広い翻訳品質管理ハブでは、関連する用語やポストエディティングのタスクを取り上げています。

実際のレビュー例：言葉は正しいが仕様が間違っている場合

架空の製品シートに次の2行が含まれていると仮定します。

ターゲットテーブルでモデルラベルが入れ替わっているものの、すべての数値が保持されている場合、数値の存在チェックはパスしますが、ドキュメントでは誤った制限値が伝えられることになります。これらの架空の値はドキュメントの関係性を示すものであり、実製品の動作に関するアドバイスではありません。

ダウンロード可能なマトリックスでは、これがチェックNUM-02になります。各モデル識別子、値、単位、条件を1つのグループとして比較します。ドメインレビュアーが修正を記録し、本番レビュアーがエクスポートされたファイルを再び開いて、修正によってセルが再度ズレていないことを確認します。

この教訓は表にとどまりません。個々の文字列が依然として存在するかどうかだけでなく、関係性を確認してください。

承認役割の分離と、その後のリビジョンの管理

ドメインエキスパートは、すべてのターゲット言語のニュアンスを判断する資格を持っていなくても、仕様の意味を確認することができます。言語レビュアーは、どのソース仕様が信頼できるかを知らなくても、誤訳を特定できます。双方にドキュメント所有者への明確なルートを提供し、「エンジニアリングによるレビュー済み」という理由ですべてのチェックを代用させないでください。

1人で複数の役割を正当に兼務する場合でも、次の4つの明確な責任を設けてください。

1. ドキュメント所有者： 原文に関する疑問を解決し、スコープや要件の変更を承認します。
2. 言語レビュアー： 原文と訳文の意味を比較し、想定読者に合わせて編集します。
3. 専門領域レビュアー： 技術的概念、条件、および意思決定の根拠となる情報を検証します。
4. プロダクションオーナー： エクスポートされた成果物を確認し、正しいリビジョンをパッケージ化します。

リリースブロッカーには、未解決の技術的な曖昧さ、必要なコンテンツの欠落、誤った数値や条件、読者を誤った項目に誘導する図や参照などが含まれます。外観上の好みによって、これらの致命的な欠陥が隠されてはなりません。

原文に変更があった場合は、影響を受けるセクションと、それに付随する表、図、参照を特定してください。それらのチェックを再開してください。以前に承認された段落であっても、その運用コンテキストが変更された後は、承認済みのままであると仮定しないでください。原文のリビジョン、訳文のリビジョン、用語の決定事項、およびクローズされた課題ログをまとめて保存してください。

BookTranslator の活用場面

BookTranslator は、PDF および DOCX ファイルの丸ごと翻訳をサポートしています。アップロードして下書きとして使用するのに適したドキュメントについては、まず PDF 翻訳 または DOCX 翻訳 を使用し、その結果を受入基準書および管理マトリックスと比較してください。

ファイル形式のサポートや自動用語集があるからといって、すべての技術的な区別、図のラベル、またはレイアウトが維持されているとは限りません。OCR ワークフローは、ページを正確に再現することを保証するものではなく、認識されたコンテンツを再構築するものです。安全性が重視される文書、規制対象の文書、またはその他の重要な文書には、レビューなしの翻訳の後に土壇場で免責事項を添えるのではなく、最初に確立された専門的なワークフローが必要です。

有用なハンドオフとは、翻訳されたファイル に加えて、何を、誰が、どの原文に対してチェックしたかの記録が揃っていることです。これによって、次のリビジョン管理が可能になります。