研究所の技術報告書を社内の用語集と過去の訳にそろえて英訳し、数値・単位・図表番号の対応を確かめてから海外拠点へ配る

処理の起点を決める

取りまとめ担当が、文書管理システムで報告書に「海外配布」の印を付けたことを起点にします。 承認だけを起点にしないのは、承認された報告書のすべてを海外へ配るわけではないからです。

印を付けられる条件を、輸出管理の確認が済んでいることにします。 文書管理システムの属性に「輸出管理の確認」の欄を持たせ、確認済みでなければ印を付けられないようにします。英訳の工程に入ってから止めるのではなく、入口で止めます。

印が付いたら Azure Functions が動き、報告書のファイルを取り出します。1冊ずつ処理し、処理中の報告書には「英訳中」の印を付けます。 同じ報告書に二度印を付けても、二重に英訳しないためです。

承認後に原文が改訂されたときは、改訂版を新しい処理として扱います。 前の版の訳文を上書きせず、変わった段落だけを訳し直す形にします（第7章の前処理の6番目）。

入力データを集める

質を決めるのは、用語集の「使ってはいけない訳」の列です。 指定訳を添えるだけだと、AIは文脈に合わせて別の訳を選ぶことがあります。「硬化は curing。hardening は使わない」まで書いておくと、照合のときに機械で検出できます。

表記のきまりは、照合の物差しになります。 「℃」を「°C」と書く、千の位をカンマで区切る、「図3」を「Fig. 3」、「表2」を「Table 2」と書く、といった対応です。このきまりが無いと、照合のプログラムが原文と訳文の数値を対応させられません。

データの取得方法を決める

報告書の本文は、Word のファイルから段落・表・図表の見出しの単位で取り出します。図の中に画像として埋め込まれた文字は取り出せないので、この構成では訳しません。 図の中に日本語の文字がある報告書は、一覧で研究者に知らせます。

用語集は、段落に出てくる語だけを添えます。 3,000語を毎回すべて渡すと、関係の無い語の指定訳に引きずられることがあり、処理も重くなります。段落の文字列に用語集の日本語が含まれるものだけを、その段落の指示に入れます。

表はセルの位置を付けたまま持ちます。 訳した後に、どのセルの数値がどのセルに対応するかを照合するためです。表を1つの文章にまとめて訳させると、行と列の対応が崩れます。

AIへ渡す前に整形する

1. 分割 … 本文を段落、表をセル、図表を見出しの単位に分け、それぞれに番号を振ります
2. 同じ文の再利用 … 過去の対訳に原文が完全に一致する段落があれば、確定した訳をそのまま使い、英訳に回しません
3. 似た文の検索 … 一致しない段落には、過去の対訳から文字の重なりの多いものを2件まで参考として添えます
4. 用語の当てはめ … 段落に含まれる用語集の語と、その指定訳・使ってはいけない訳を添えます
5. 数値・単位・図表番号の抜き出し … 原文から正規表現で抜き出し、段落の番号とともに控えておきます
6. 改訂版の差分 … 前の版がある場合は、変わった段落だけを英訳に回し、変わらない段落は前の版の確定訳を使います

5番目を英訳の前にやっておくのが要です。 原文の数値を先に控えておけば、訳文から同じ数の数値が同じ順で出てくるかを後で機械的に確かめられます。訳した後で原文と訳文の両方から抜き出すと、どちらが正しいかの基準がぶれます。

2番目の再利用は、訳語の揺れを止める効果も大きい部分です。 試験方法や装置の説明は、報告書をまたいで同じ文が繰り返し出てきます。一度確定した訳を使い続ければ、同じ文が報告書ごとに違う英語になることがありません。

5番目で抜き出すものは、最初に型を決めておきます。

「約」「以上」「未満」は、数値と一緒に控えます。 「85℃以上」が「85 °C」だけになると、値は合っていても意味が変わります。 照合では、数値の前後の語が「above」「at least」「less than」などの対応する語になっているかも見ます。

AIに処理させる

させるのは、段落ごとの英訳と、その段落で指定訳をどう使ったかの報告です。

4行目がいちばん起きやすい失敗です。 原文の数値が前の表と食い違っているとき、AIは文脈から「正しそうな値」で訳すことがあります。訳文だけが直っていると、原文と訳文が別の内容になり、どちらが正しいかが分からなくなります。 気づいたことは報告の欄に書かせ、訳文は原文どおりにします。

段落の前後の文脈は、1段落ずつ添えます。 段落だけを渡すと、「これ」「同条件」が何を指すかが分からず、AIが補って訳します。前後の段落を参考として渡し、訳すのは対象の段落だけと指示すると、指示語の取り違えが減ります。

指示内容を固定する

あなたは電子部品メーカーの研究所で、技術報告書を英訳する担当です。
渡された1つの段落を、技術報告書の英語の文体で訳してください。

【この段落で使う指定訳】
{glossary_entries}
（例：硬化 → curing ／ 使ってはいけない訳：hardening）

【参考：過去の似た段落の確定訳】
{similar_pairs}

【表記のきまり】
- 温度は °C、千の位はカンマで区切る
- 図は Fig. 番号、表は Table 番号と書く
- 数値と単位の間には半角スペースを1つ入れる

【厳守事項】
- 指定訳がある語は、必ず指定訳を使ってください。
  使ってはいけない訳は使わないでください。
- 数値は原文の値をそのまま書いてください。
  単位の換算、丸め、桁の言い換えをしないでください。
- 原文に無い説明や補足を加えないでください。
- 原文に誤りと思われる箇所があっても、訳文では直さないでください。
  気づいたことは source_issues に書いてください。
- 専門用語と思われるが指定訳の無い語は、選んだ訳とともに
  new_terms に書いてください。
- 意味が一つに決まらない箇所は、訳したうえで ambiguities に
  理由を書いてください。推測で一つに決めたことを隠さないでください。

【段落】
番号：{segment_id}
{source_text}

「単位の換算、丸め、桁の言い換えをしない」を書かないと、親切な訳になります。 「1万回」を「10 thousand cycles」と書くのは誤りではありませんが、照合のプログラムが原文の「10,000」と対応させられなくなります。 表記のきまりで「10,000 cycles」と決め、言い換えを禁じます。

「推測で一つに決めたことを隠さない」は、訳の正しさより、確認のしやすさのための指示です。 日本語の技術文は主語や対象が省かれることが多く、AIはどれかに決めて訳します。決めたこと自体は問題ではなく、決めたことが研究者に見えないのが問題です。

出力形式を固定する

段落ごとに、次の形のJSONで受け取ります。 構造化出力のスキーマで、すべての項目を必須にし、additionalProperties を false にします。値が無いときは空の配列を返させます。

{
  "segment_id": "S-0412",
  "target_text": "",
  "glossary_usage": [
    { "ja": "硬化", "required_en": "curing", "used": true }
  ],
  "new_terms": [
    { "ja": "", "chosen_en": "" }
  ],
  "ambiguities": [
    { "phrase": "", "reason": "" }
  ],
  "source_issues": []
}

照合の結果は、Azure Functions が段落ごとに次の形で足します。

1つ目の理由は、AIの自己申告と機械の照合を並べて見られることです。 glossary_usage で used: true と返していても、訳文に指定訳が無ければ照合で分かります。自己申告だけを信じない作りにしておくと、どちらかの誤りが必ず表に出ます。

2つ目は、スキーマの制約に合わせて形を浅くできることです。 ドキュメントでは、スキーマに含められるのは最大100個のオブジェクトのプロパティ、入れ子は5段までとされ、すべての項目を必須にする必要があります。段落ごとに1回呼ぶ形にしておけば、この範囲に収まります。 報告書1冊を1回で返させる形にはしません。

3つ目は、new_terms が用語集を育てる材料になることです。 毎月の新しい語を集めると、研究所で新しく使われ始めた用語が分かります。

システムへ連携する

過去の対訳に書き込むのは、研究者が確定した訳だけです。 AIの訳をそのまま登録すると、直される前の訳が次の報告書で「確定した訳」として再利用されます。 登録は、研究者が確定の操作をしたときに行います。

海外拠点への配布は、この構成からは行いません。 配布先の選び方や、配布の記録の付け方は、これまでどおり取りまとめ担当が行います。

研究者に返す Word のファイルは、原文と訳文を段落ごとに左右に並べた形にします。 照合でずれた段落には色を付け、横に source_issues と ambiguities を注記します。研究者は色の付いた段落から順に読み、直した訳文をそのまま確定の操作に回せます。

人が確認する

AIの訳をそのまま海外拠点へ配る運用にはしません。 研究者と取りまとめ担当が次の順で確かめます。

1. 照合のずれを先に直す … numbers_match などが false の段落を開き、原文と訳文の数値を見比べます
2. source_issues を確かめる … 原文の誤りの指摘であれば、原文を直すかどうかを先に決めます
3. ambiguities を確かめる … AIが一つに決めた解釈が正しいかを見ます
4. 訳文全体を通して読む … 技術の中身として正しいか、書いた本人が確かめます
5. 取りまとめ担当が照合の解消を確かめる … ずれが残っていない英訳版だけを配ります

2番目で原文を直したときは、原文の改訂として扱います。 訳文だけを直すと、日本語版と英語版の内容が食い違ったまま残ります。

新しい語の訳は、研究者が決めずに用語集の担当へ回します。 研究者がその場で決めた訳は、その報告書では使ってかまいませんが、用語集に入れるかどうかは月に1回まとめて決めます。

確認の時間の目安は、1冊90分です。 照合のずれと注記の箇所を直すのに30分、訳文を通して読むのに60分という配分を想定しています。通して読む時間を削って一覧の箇所だけを見る運用にはしません。 照合で拾えるのは数値と用語の誤りまでで、文の意味の取り違えは、技術の中身を知る人が読まないと見つかりません。

例外に対処する

2行目は、技術報告書では避けられません。 グラフの軸の名前、写真の中の注記は、本文の英訳だけでは英語になりません。一覧で知らせて、研究者が図を直す工程を残します。

記録を残す

• 原文の報告書番号・版と、英訳版の版の対応
• 段落ごとの原文、AIの訳文、研究者が確定した訳文
• 段落ごとに添えた指定訳と参考の対訳
• 照合の結果（数値・単位・図表番号・使ってはいけない訳）と、研究者が直した記録
• new_terms と、用語集の担当が決めた訳
• 使ったモデルとデプロイの名前、スキーマの版

2つ目でAIの訳文と確定した訳文の両方を残すのは、直された箇所の傾向を見るためです。 同じ種類の直しが続くなら、指示か用語集のどちらかに足すべきものがあります。

最後の行は、訳の質が変わったときの手がかりです。 モデルやデプロイを替えた月から直しが増えたなら、そこを疑えます。