翻訳者とAIが実際に使える用語集の作り方

翻訳用語集を作成するには、管理された表現が必要な概念を選び、それぞれが文書内で何を意味するかを定義し、言語と文脈ごとに訳語を承認し、それらの決定を維持する担当者を割り当てます。その後、翻訳者や翻訳ツールに渡す前に、実際の文章で項目をテストします。

最も役立つ区別は、あなたの決定を記録するマスター用語集と、ツールが取り込める小さなエクスポートの違いです。2列のインポートファイルが必要になることもありますが、それは2列を信頼できるものにした文脈、根拠、承認履歴に取って代わることはできません。

空の用語集テンプレートと記入済みの用語集例から始めましょう。どちらもUTF-8のCSVファイルです。この例では架空の製品と説明用の英語からフランス語への決定を使用しています。認定された用語リスト、顧客プロジェクト、BookTranslator用の既成インポートプリセットではありません。

用語集は辞書より小さく保つ

一貫性のない、または曖昧な選択が意味を変えたり、ナビゲーションを混乱させたり、重要な区別を弱めたり、避けられるレビュー作業を引き起こしたりする場合に用語を含めます。ソフトウェアが抽出したという理由だけで、すべての名詞を集めてはいけません。

有用な選別の手順では、次のように問いかけます。

• この概念はセクション、ファイル、または貢献者をまたいで繰り返し現れますか？
• 原語の単語には複数の関連する意味がありますか？
• 組織、著者、または主題分野が特定の訳語形式を要求していますか？
• 別の選択をすると、警告、指示、インターフェース、または議論が追いにくくなりますか？
• その用語は新しく、議論があり、またはこのプロジェクトで修正を引き起こしたことが知られていますか？

まれでも結果に影響する用語は、頻繁に使われる普通の単語よりも先に項目として登録する価値があります。現実的な曖昧さがない標準的な用語には、まったく項目が必要ないかもしれません。

COTSOESの翻訳のための用語管理スターターガイドは、組織に関連する用語と明示的な検証責任を推奨しています。また、項目数だけでは品質を確立できないと警告しています。ここでは、そのソフトウェア例の古さよりも、これらの原則の方が重要です。

候補の抽出は受信箱にすぎません。抽出されたフレーズは、それが何を意味し、いつ適用され、誰が訳語を承認したかを把握して初めて、有用な用語になります。

1つの意味につき1つのレコードを作成する

原語の文字列だけにレコードの所有権を与えないでください。英語の「charge」という単語は、電気的特性を表すことも、請求金額を表すこともあります。すべての出現箇所を1つのフランス語にマッピングする1行は、一貫性ではなくエラーをエンコードすることになります。

各概念に安定した識別子を与え、次に言語固有の決定を追加します。単純なスプレッドシートでは、概念と原語/訳語のロケールペアごとに1行を使用します。2つの行が同じ原語の綴りを共有していても、同じ概念を表しているとは限りません。

テンプレートには次のフィールドが含まれています。

コンテキスト参照があれば、レビュアーはその箇所をもう一度見つけられるはずです。ファイルのバージョンとセクション、権威ある用語記録、その他の永続的な情報源などです。「インターネットから」では不十分です。原著者が定義した概念であれば、原稿自体の定義が関連する証拠となり得ます。

定義と原文コンテキストは分けておきましょう。定義はその概念が何であるかを示し、コンテキストはそれがどのように使われるかを示します。「ワークスペースを選択」という文は使用例を示していますが、ワークスペースが何を含むのか、プロジェクトとどう違うのかは説明していません。

よくある5つの用語集エントリを修正する

以下の修正は、ダウンロード可能な架空の例に属するものです。これらは編集上の判断を示すものであり、フランス語用語の普遍的なルールではありません。サンプル箇所には、周辺のテキストが掲載されています。

1. 一つの訳語を無理に当てはめた多義語

弱いエントリ: charge → charge

修正: 別々の概念を作成します:

• 電気的性質: 原語 charge、訳語 charge électrique、分野「入門エレクトロニクス」、コンテキスト「The capacitor stores electric charge.」
• 請求額: 原語 charge、訳語 frais、分野「請求」、コンテキスト「The delivery charge is shown before payment.」

これは、どちらかの対応付けが「charge」のすべての出現箇所を上書きすべきだという意味ではありません。エントリの分野とコンテキストは決定の一部です。選択したツールがそれらを区別できない場合は、グローバルな置換ではなく、プロジェクトごとの別々のエクスポート、より長く曖昧さのないフレーズ、または人間によるレビューを使用してください。

2. 品詞が示されていない用語

弱いエントリ: seal → sceller

修正: 動詞と構成要素を区別します:

• 「封筒を封をする」：動詞で、このプロジェクトでは目標訳語を sceller と例示しています。
• 「ゴムパッキンを交換する」：部品を指す名詞で、目標訳語は joint です。

これでスプレッドシートは、ゴム部品が動作を表していると示唆するのではなく、2つの概念を記述するものになりました。実際の技術文書では、ドメインのレビュアーに部品の意味と推奨用語を検証してもらいましょう。

3. プロジェクトの優先指定がなく、どちらも許容される訳語

弱い項目： workspace → espace de travail / zone de travail

修正： 架空のアプリケーションにおける名前付きコンテナには espace de travail を承認します。zone de travail は、このインターフェース概念に対して却下された異形として記録し、フランス語一般として不適切なわけではないとします。通常の文法的な語形変化は許容されるという使用上の注記を加えましょう。

却下された異形には、理由と適用範囲が必要です。そうでなければ、レビュアーが別の文脈でまったく妥当な表現を「修正」してしまうかもしれません。

4. 暗黙のうちにしか保護されていない製品名

弱い項目： LeafDeck → LeafDeck

修正： do_not_translate=true を設定し、架空の製品名であることを明示し、大文字小文字を保持し、デモプロジェクトの命名判断を引用します。このルールは通常の説明に現れる無関係な語には適用されないと明記しましょう。

原文と訳文が一致しているだけでは、その保持が意図的なものか、単に作業が未完了なだけなのかは分かりません。より広い除外リストについては、翻訳しない判断ガイドを参照してください。

5. 承認済みとして提示されたドラフト判断

弱い項目： sync → synchroniser / mettre à jour。所有者も状態もありません。

修正： まず動作を定義します。デバイスライブラリを同期する架空のコマンドについては、動詞として synchroniser を承認し、代替案はこの特定のコマンドには適さないものとして記録します。所有者と、日付のある判断の出典を割り当てましょう。

別に提案された名詞ラベルは、レビュアーが解決するまで draft のままにしておきます。作業用 CSV には、そのドラフト行が意図的に含まれています。見た目が整ったスプレッドシートは、すべての行が承認済みである証拠にはなりません。

装飾的なスコアではなく、項目品質のゲートを使う

項目を承認する前に、6つの yes/no の問いを立てましょう。

1. 意味： 他の人がこの概念を近い概念と区別できるか？
2. 根拠： 裏付けとなる出典や作成者の判断を見つけられるか？
3. 言語： 目標訳語は、指定されたロケール、文法、ドメインに適合しているか？
4. 適用範囲： このルールがどこに適用され、どこには適用されないかを理解できるか？
5. 責任： 変更の解決に責任を持つ所有者がいるか？
6. 使用： 代表的な文の中でこの項目を確認したか？

答えが未解決の項目はドラフトのままにします。これは編集上の承認ルーブリックであり、翻訳品質を数値で検証する尺度ではありません。

専門知識に基づいて作業を分担します。著者または主題の専門家が概念を確認し、対象言語のレビュアーが使用法を確認し、用語管理者が決定を記録して承認済みバージョンを配布します。小規模なプロジェクトでは1人が複数の役割を兼ねることもありますが、問いには依然として答えが必要です。

レビュアーが項目に異議を唱えた場合は、競合する選択肢と、その対立を露呈した箇所を記録します。私的なメッセージが文書化されない例外になることを許さず、翻訳者クエリのワークフローに従ってください。

承認後にのみ、受け取り側のツール用にエクスポートする

マスター用語集とエンジンの辞書は目的が異なります。マスターは人間に決定を説明するものです。インポートファイルは、特定のツールのスキーマとマッチング動作に従わなければなりません。

用語集のインポートに対応するツールの場合:

1. 必要なソース/ターゲット言語ペアとプロジェクトドメインを選択します。
2. draft および deprecated の項目を除外します。
3. 受け取り側のツールが曖昧性を解消できない重複したソース文字列を解決します。
4. サポートされているフィールドのみを、ツールの現在のインポート形式にマッピングします。
5. 大文字小文字、語形変化、複数語用語、保護テキストの扱いを確認します。
6. 代表的な小規模な入力をテストし、返された翻訳を検査します。

たとえば、Google Cloud Translation の文書化された単方向 CSV 形式はヘッダーなしのソース/ターゲットペアを使用しますが、同等語セットの CSV は言語ヘッダーを使用します。その用語集マッチングはデフォルトで大文字小文字を区別し、一部のストップワード項目は無視されます。これらは Google Cloud のルールであり、一般的な CSV のルールや BookTranslator の機能ではありません。そのサービス用のエクスポートを準備する前に、最新の Google Cloud 用語集ドキュメントを確認してください。

この記事の注釈が豊富な CSV を、適当なインポートダイアログにアップロードしないでください。それは作業用のマスターです。逆に、ツールが2列しか受け付けないからといって、その定義と承認履歴を捨てないでください。

指示フィールドをサポートする AI システムを使用する場合は、関連する承認済みのサブセットと、意味を区別するために必要なコンテキストを提供します。指示は用語を要求できますが、出力がそれに従ったことを証明するものではありません。結果を検査してください。システムがサポートされた用語集入力を提供しない場合は、インポートする方法をでっち上げるのではなく、マスターをレビュアー用の参照資料として保持してください。

多言語のフロントラインチームを持つ組織では、翻訳後の用語の一貫性も重要です。トレーニング資料、ポリシー、業務連絡は、承認された文言を維持しながら、従業員が希望する言語で受け取れるようにする必要があるかもしれません。iTacit は、多言語コミュニケーションが言語、国、文化を超えて職場の情報をどのように支えるかを説明しています。

現地の決定を消さずに言語を追加する

別のターゲットロケールを追加するときは概念 ID を再利用しますが、そのロケールには独自のターゲット、ステータス、担当者、根拠を与えます。フランス語での承認は、ドイツ語の同等語を承認するものではありません。ターゲットが空欄であることは「未解決」を意味し、「ソースを自動的に使用する」という意味ではありません。

同じ規律は言語内にも当てはまります。実質的に異なる場合は、ロケール固有の決定を分割します。何も変わらない地域ラベルを追加するためだけに重複行を作成しないでください。

これらの状態はシンプルに保ちます:

• 下書き: 候補または係争中の決定。承認済みエクスポートには含まれません。
• 承認済み: 記載された範囲とバージョンで受け入れられたもの。
• 非推奨: 履歴と検出のために保持されますが、新しい作業には推奨されません。

実質的な変更については、旧形式、新形式、理由、有効バージョン、担当者、影響を受けるソース箇所を記録します。関連するエクスポートを再構築し、翻訳者に再検討が必要な箇所を伝えます。プロジェクトの途中で用語を黙って置き換え、すでに翻訳された章が自動的に更新されることを期待しないでください。

製品、ソース原稿、標準、または受け入れられた使用法が変更されたときに項目を見直します。カレンダーのリマインダーも役立ちますが、定義の変更こそがより強いきっかけとなります。

スケールする前に、訳文パッセージで用語集を検証する

用語集は内部的に整っていても、文中では失敗することがあります。意図的に次の要素を含む少数のパッセージを使ってください：

• 二つの意味を持つ曖昧な原語。
• 見出しとしての用語と、地の文の中での用語。
• 単数形、複数形、その他の文法的な変化形。
• 保護された固有名詞が通常の言語の隣にあるケース。
• 表、キャプション、指示文、その他の重要な文書構造の中にある用語。

ダウンロード可能なサンプルでは、「delivery charge」と「electric charge」を対にし、「seal」を名詞と動詞の両方として含めています。これらのケースは、スコープを限定しない置換が受け入れテストとして不適切である理由を明らかにします。

各パッセージについて、原文、用語集のバージョン、訳文出力、レビュアーの判断、必要に応じて修正を記録します。実際に翻訳サービスをテストする場合は、サービス／モデル、日付、設定、生の出力を追加してください。本記事の例は、そのようなサービステストが実施されたことを主張するものではありません。

文書全体の翻訳が完了したら、用語の一貫性レビューに進みます。用語集の構築はポリシーを確立し、出力レビューは、納品されたテキストが不自然になることなくそれに従っているかを判断します。

単なる単語リストではなく、判断記録を引き継ぐ

最終的な引き継ぎには、原文のバージョン、承認済みのマスター用語集、該当する場合は受け取りツール用のエクスポート、未解決の問い合わせログ、代表的な例を含めるべきです。翻訳を担当する人は、どのファイルが正式なもので、競合について誰に尋ねるべきかを知っている必要があります。

対応している書籍全体や長文書の場合、BookTranslatorのファイル翻訳ワークフローで、その後のレビュー用の下書きを提供できます。承認済みの用語集はその下書きと一緒に保管してください。ここにあるワークシートは外部の編集用リファレンスであり、BookTranslatorがユーザー管理のCSV用語集をインポートしたり、すべての項目を強制したりすることを主張するものではありません。

重要ないくつかの概念から始め、判断を検査可能にし、真の曖昧さやレビューでの発見から拡張していきます。目標は、次の文書で未解決の判断を減らすことであり、最大の用語集を作ることではありません。