翻訳会社の用語集管理と下訳・校正フローをClaude Codeで整える方法

金曜の夕方、納品済みのマニュアル翻訳にクレームが入りました。「製品名の表記、前の号と違いますよね」。

確認すると、確かに違う。前回は「お客様アカウント」、今回は「ユーザーアカウント」。用語集には「お客様アカウント」と書いてあったのに、急ぎで巻いた翻訳者がそこを見落とし、校正者も見落とした。僕が3年やってきた翻訳会社の現場で、いちばん多い手戻りがこれです。

誰が悪いという話じゃありません。用語集はExcelで200行。案件ごとに微妙に増える。翻訳者は締切に追われ、校正者は全文を目で追う。人間の注意力だけで表記ゆれを全部止めるのは、もう無理がある。

そこで僕は、Claude Codeに「用語チェックの一次フィルター」をやらせてみました。判断は人間が残したまま、機械でわかるミスだけ先に潰す。これが想像以上に効いたので、翻訳会社のコーディネーター目線で手順をまとめます。

この記事の要点

• 表記ゆれや訳語の不統一は「機械でわかるミス」が多く、Claude Codeの一次チェックで大半を拾える
• 用語集はExcelのまま使わず、CSVやテキストにして「ルールの一覧」としてAIに渡すと精度が上がる
• 下訳・校正フローは「AIが拾う／人が決める」を分けると手戻りが減る
• 顧客の原文や用語集には固有名詞・未公開情報が含まれるので、送信範囲の管理が必須
• 案件1本あたり校正の前処理で30〜60分、月に10本回せば数時間〜十数時間が浮く計算になる

翻訳会社の現場で何が起きているか

まず読者像を揃えます。この記事が想定するのは、翻訳会社で案件を回すコーディネーターです。自分で全文を訳すより、翻訳者と校正者の間に立ち、用語集を管理し、納期と品質の板挟みになる人。プログラミングの経験はほぼないか、あってもマクロを少し触る程度。

翻訳会社のよくある業務フローは、だいたいこうなっています。

1. 顧客から原文と過去訳・用語集を受け取る
2. 翻訳者に下訳を依頼する
3. 校正者（チェッカー）が訳文を点検する
4. コーディネーターが最終確認して納品する

この流れのどこで手戻りが起きるか。経験上、ほとんどが2と3の間です。

• 用語集にある訳語を翻訳者が使っていない（表記ゆれ）
• 数字や単位が原文とずれている（「3.5kg」が「3.5g」になる等）
• 訳抜け（原文の1文が訳文に存在しない）
• 全角・半角や括弧の種類が案件のルールと違う

どれも「読めば気づくはず」のミスです。でも全文を人の目で追うと、長い案件ほど見落とす。校正者が見落としたものはコーディネーターに回り、最後は納品後のクレームになる。この「機械でわかるはずのミスを人が探している時間」が、翻訳会社の隠れたコストです。

AIに任せる範囲と、人が必ず判断する範囲

ここを最初にはっきりさせないと事故ります。Claude Codeは賢いですが、翻訳の品質を最終判断させてはいけません。線引きはこうです。

工程	Claude Codeに任せる	人（校正者・コーディネーター）が判断する
用語チェック	用語集と訳文を突き合わせ、不一致箇所を一覧化	その不一致が誤りか、文脈上の例外か
表記ゆれ	全半角・括弧・送り仮名の揺れを抽出	顧客の好みに合わせた最終表記
数字・単位	原文と訳文の数値の差分を検出	単位換算の正否、意味の妥当性
訳抜け	原文の文数と訳文の文数のズレを報告	意図的な統合・分割かどうか
訳文の質	（任せない。下訳の補助まで）	自然さ・トーン・誤訳の最終判断

ポイントは、AIに「正解を決めさせない」こと。AIがやるのは「ここ怪しいですよ」と付箋を貼るところまで。剥がすか残すかは人が決める。この役割分担を崩すと、AIの誤判定をそのまま納品する事故が起きます。

任せる範囲をどう書くかで迷ったら、claude-code-prompt-engineering-advanced のプロンプト設計が参考になります。指示を曖昧にすると、AIは勝手に「直して」しまうので、出力形式まで指定するのがコツです。

Use case 1：用語集との突き合わせ

いちばん効くのがこれです。用語集と訳文を渡し、不一致だけを表で返させます。

まず用語集をExcelからCSVにします。AIにExcelをそのまま渡すより、「原語, 訳語, 備考」の3列のテキストにしたほうが、ルールとして読み取りやすい。下準備のプロンプトはこうです。

あなたは翻訳会社の校正アシスタントです。
以下の用語集に従って、訳文の用語不一致だけを指摘してください。

# ルール
- 用語集の「訳語」が使われていない箇所のみ報告する
- 文脈上の言い換えかどうかは判断せず、機械的な不一致を全部挙げる
- 直さない。指摘だけする
- 出力は表形式: | 行番号 | 原語 | あるべき訳語 | 実際の訳語 |

# 用語集（原語, 訳語, 備考）
顧客アカウント, お客様アカウント, 全案件共通
サインイン, ログイン, この顧客はログイン表記で統一
delete, 削除, 「消去」は不可

# 訳文
（ここに訳文を貼る）

返ってくるのは「修正案」ではなく「不一致の一覧」です。校正者はその表を上から見て、直すかどうかだけ決める。全文を読み直すより圧倒的に速い。

導入前は、校正者がExcelの用語集を別ウィンドウで開きながら訳文を目視で照合していました。導入後は、AIが貼った付箋を確認する作業に変わった。同じ「確認」でも、ゼロから探すのと、候補を見て判断するのとでは負荷がまるで違います。

Use case 2：下訳の前処理チェックリスト

翻訳者に渡す前、または下訳が上がった直後に、機械チェックを一回かませます。チェック項目はこのリストをそのまま使ってください。

• 用語集の訳語が全箇所で使われているか
• 原文と訳文で数字・単位が一致しているか
• 訳抜け（原文にあって訳文にない文）がないか
• 全角・半角、括弧の種類が案件ルール通りか
• 製品名・人名・固有名詞の表記が過去訳と揃っているか
• 禁止表現（顧客が嫌う言い回し）が混ざっていないか

このチェックを下訳の段階でやると、校正者に渡る前にミスが減ります。校正者は「機械で拾える部分は済んでいる」前提で、訳の自然さや誤訳という人にしかできない判断に集中できる。

下訳そのものをAIに手伝わせる場合も、いきなり全文を任せず、「過去訳と用語集を踏まえた下訳のたたき台」までにとどめます。最終的な訳は人が仕上げる。AIを使い始めたばかりのチームなら、claude-code-for-non-engineers を先に読むと、どこまで任せるかの感覚がつかめます。

Use case 3：表記ゆれの定期棚卸し

案件が長く続くと、用語集自体が古くなります。「前は削除だったけど、今期から消去でいいことになった」みたいな変更が口頭で流れ、用語集に反映されないまま現場が混乱する。

そこで月1回、過去の納品物をまとめてAIに読ませ、「同じ概念に複数の訳語が当たっている箇所」を洗い出します。これで用語集のメンテナンス漏れが見つかる。プロジェクトの共通ルールをファイルにまとめておくと、AIが毎回それを参照してくれるので、claude-md-best-practices のやり方で案件ごとの規約を1ファイルに集約しておくと運用が楽になります。

コピペで使えるプロンプト雛形

校正の一次チェックに使う、汎用の雛形を置いておきます。案件名と用語集を差し替えるだけで使えます。

# 役割
翻訳会社の校正一次チェック担当として、機械的に検出できるミスだけを報告する。

# 入力
- 用語集（原語, 訳語）
- 原文
- 訳文

# やること（この順で）
1. 用語不一致を抽出
2. 数字・単位の原文との差分を抽出
3. 訳抜け（原文の文数 > 訳文の文数）の疑いを報告
4. 全半角・括弧の揺れを抽出

# やらないこと
- 訳文を書き換えない
- 訳の良し悪しを評価しない
- 例外判断をしない（判断は人が行う）

# 出力フォーマット
## 用語不一致
| 該当箇所 | あるべき訳語 | 実際 |
## 数字・単位
| 原文 | 訳文 | 差分 |
## 訳抜けの疑い
- （箇所）
## 表記揺れ
- （箇所）
問題がなければ各セクションに「指摘なし」と書く。

実行できる検証スクリプト：数字の不一致を機械で拾う

AIに渡す前に、確実に機械でわかる「数字のズレ」だけを先に潰しておくと、AIへの依存度が下がって安全です。Node.jsで動く小さなスクリプトを用意しました。原文と訳文をテキストで渡すと、片方にしかない数字を一覧で出します。

import { readFile } from "node:fs/promises";

// 原文・訳文ファイルのパスをコマンド引数で受け取る
const [srcPath, tgtPath] = process.argv.slice(2);
if (!srcPath || !tgtPath) {
  console.error("使い方: node check-numbers.mjs 原文.txt 訳文.txt");
  process.exit(1);
}

const src = await readFile(srcPath, "utf8");
const tgt = await readFile(tgtPath, "utf8");

// 数字（小数・カンマ区切りを含む）を全部拾う
const pick = (text) => (text.match(/\d[\d,.]*/g) || []).map((n) => n.replace(/,/g, ""));

const srcNums = pick(src);
const tgtNums = pick(tgt);

// 片方にしかない数字を差分として出す
const diff = (a, b) => a.filter((n) => !b.includes(n));

const onlyInSrc = diff(srcNums, tgtNums);
const onlyInTgt = diff(tgtNums, srcNums);

console.log("原文だけにある数字:", onlyInSrc.length ? onlyInSrc.join(", ") : "なし");
console.log("訳文だけにある数字:", onlyInTgt.length ? onlyInTgt.join(", ") : "なし");

if (onlyInSrc.length || onlyInTgt.length) {
  console.log("→ 数字のズレが疑われます。該当箇所を確認してください。");
  process.exit(2);
}
console.log("→ 数字は一致しています。");

保存して実行するだけです。

node check-numbers.mjs source.txt target.txt

完璧な検出ではありません。語順が変われば誤検知も出ます。でも「3.5が訳文から消えている」のような致命的なズレは、目視より速く確実に見つかります。AIの判断に頼る前に、こういう確定的なチェックを先に置いておくのがコツです。Claude Codeの導入が初めてなら、claude-code-getting-started-guide の手順で環境を整えてから試してください。

セキュリティと個人情報の注意点

翻訳会社にとってここは死活問題です。原文には未公開の製品情報、契約書、個人名が含まれます。扱いを間違えると、効率化どころか信用を失う。

• 顧客との秘密保持契約（NDA）で、外部AIサービスへのデータ送信が許されているか必ず確認する
• 許可がない案件は、固有名詞や数値をダミーに置き換えてからチェックにかける
• 個人情報（氏名・住所・連絡先）はチェック前にマスキングする
• 送信したデータが学習に使われない設定・契約形態を選ぶ
• 案件ごとに「AI利用可／不可」を管理表で記録し、コーディネーター間で共有する

迷ったら「送らない」が正解です。用語集の突き合わせは、固有名詞を伏せても表記ルールのチェックとして十分機能します。個人情報の扱いに不安があれば、個人情報保護委員会のガイドラインで自社の運用が外れていないか確認しておくと安心です。

ROIの目安

ざっくりした概算ですが、感覚を共有します。中規模のマニュアル翻訳1本（原文1万字程度）の校正で、用語照合と数字チェックの前処理に人が使う時間は、これまで30〜60分でした。

一次フィルターをAIと検証スクリプトに任せると、その前処理が10分前後に縮みます。差し引き20〜50分の短縮。月に10本回す翻訳会社なら、月あたり数時間から十数時間が浮く計算です。

浮いた時間で、校正者は誤訳やトーンといった人にしかできない判断に回れる。単なる時短ではなく、品質の最終ラインに人手を寄せられるのが大きい。

よくある質問

Q. AIに訳文を直接修正させてはダメですか。 おすすめしません。修正まで任せると、AIの誤判定がそのまま訳文に入り込み、かえって校正が増えます。AIは「指摘だけ」、修正は人が行う分担を守ってください。

Q. 用語集が500行を超えます。全部渡せますか。 案件に関係する範囲に絞って渡すのが現実的です。全部渡すと精度が落ちます。案件のジャンルごとに用語集を分割しておくと運用しやすくなります。

Q. 機械翻訳エンジンと何が違うのですか。 役割が別です。機械翻訳は訳文を生成するもの、ここで紹介したのは生成された訳文を点検する一次フィルターです。両方を組み合わせると、生成と点検の両端をカバーできます。

Q. 校正者の仕事がなくなりませんか。 逆です。機械でわかるミス探しから解放され、誤訳やニュアンスという人にしかできない判断に集中できます。価値の高い工程に時間を寄せる話です。

Q. 会社として導入したいのですが、どこから始めれば。 1案件で試すのが安全です。まず数字チェックの検証スクリプトから入れ、慣れたら用語照合に広げてください。チーム全体の運用設計が必要なら、研修・相談 で具体的なフローまで一緒に組めます。

実際に試した結果

手元の擬似案件（製品マニュアルの一部、原文約3000字）で実際に回しました。わざと「お客様アカウント」を3箇所「ユーザーアカウント」に変え、数字を1つ「3.5」から「35」に書き換えて仕込みました。

数字の検証スクリプトは、仕込んだ「35」を一発で「訳文だけにある数字」として拾いました。用語照合のプロンプトは、3箇所の表記ゆれを全部表に出してきた。一方で、文脈上あえて言い換えた1箇所も「不一致」として挙げてきたので、ここは人が「これは例外」と判断して残しました。

確かめたかったのは、「AIが付箋を貼り、人が剥がすか決める」分担が実務で回るか、でした。結論として、機械が拾った候補を人が確認する形に変えるだけで、ゼロから探す心理的な負荷が大きく減ります。完璧な自動化ではなく、人の最終判断を守りながら前処理を肩代わりさせる。翻訳会社の現場には、この距離感がちょうどよさそうです。