新規登録
基礎知識Read this article in English

CATツールとは — 翻訳支援ツールの仕組みと、ゲームの文字列・見積もりへの影響

CATツール(Computer-Assisted Translation、翻訳支援ツール)は、プロの翻訳者が作業に使う編集ソフトです。機械翻訳とは別物で、訳文を自動で作るものではありません。原文をセグメント(文単位の区切り)に分け、過去の訳文をためた翻訳メモリ(TM)と、決まった訳語をまとめた用語ベースから、使える候補を並べて見せます。訳すのも確定するのも翻訳者です。

開発者に関係するのは、見積もりの前にツールがファイルを分析する部分です。各セグメントは「ファイル内の繰り返し」「過去訳と完全一致」「似た過去訳あり(ファジーマッチ)」「新規」のどれかに振り分けられ、見積もりはこの内訳をもとに組まれることが多いです。そして、原文の書き方しだいで行がどの区分に入るかが変わります。この記事では、ツール内で起きること、一致率の試算、繰り返しの数え方、引き渡し前に直せることと翻訳者に聞くことを扱います。

CATツールの中で文字列ファイルに起きること

画面や機能名は製品ごとに違っても、流れはおおむね次のとおりです。なお機械翻訳は単独で下書きを作る仕組みで、CATツールでは設定次第で翻訳メモリの候補と並んで案が出ますが、採否は人が決めます。案件や担当者を管理する翻訳管理システム(TMS)と一体の製品もあり、呼び名はよく混ざります。

  • ファイルフィルターで読み込む: CSV・JSON・XLIFF・リソースファイルを読み、どこが訳すべき文でどこがキーやIDなどの構造かを判定します。事故はここの誤判定から始まります。キーの列が本文扱いになれば訳されてしまい、コードと認識されなかったプレースホルダは普通の文字として編集・削除できる状態になります。
  • セグメントに区切る: 区切り方の規則はツールが持っています。参考までに、JavaScript標準の文分割機能(Intl.Segmenter。ICUの規則で動き、CATツールの規則とは別物)では「宝箱を開けた。金貨を3枚手に入れた!」は句点で2つに、「え…本当に?行こう。」は疑問符の後で2つに割れます。英語では「Talk to Dr. Mira in the lab.」がDr.の後で切れました。実際の区切りはツールと設定次第なので、翻訳者に聞くか分析結果で確かめます。
  • 翻訳メモリと照合する: 過去に同じ原文があれば完全一致として訳文が入り、似た原文があれば一致率付きのファジーマッチとして候補が出ます。どちらも無ければ新規です。用語ベースにある語は画面上で強調されます。
  • 訳してチェックする: 翻訳者は原文と訳文の2列の画面で作業します。プレースホルダやタグの欠落、原文と違う数字、用語ベースに反する訳語は、組み込みのチェックで指摘できます。
  • 書き出してメモリに足す: 訳文は元と同じ形式で書き出され、確定したセグメントは翻訳メモリに追加されます。同じゲームの2回目の発注が安くなりやすいのはこのためです。メモリのファイルの中身はTMXとTBX(翻訳メモリと用語集のファイル形式)で扱っています。
Intl.Segmenter("ja" / "en", { granularity: "sentence" })  ※ICUの規則。CATツールの規則ではない

"宝箱を開けた。金貨を3枚手に入れた!"
  -> ["宝箱を開けた。", "金貨を3枚手に入れた!"]
"え…本当に?行こう。"
  -> ["え…本当に?", "行こう。"]
"Talk to Dr. Mira in the lab. She has your map."
  -> ["Talk to Dr. ", "Mira in the lab. ", "She has your map."]

ファジーマッチの一致率はどう計算されうるか — 6組の文字列で試算

一致率は、新しい原文と翻訳メモリ内の原文がどれだけ似ているかを表す数値です。計算式はツールごとに異なり、公開されていないことも多いです。そこで、どんな違いが数値を動かすかを見るために、教科書的な方法の一例として文字単位の編集距離(一方をもう一方に変えるのに必要な1文字の挿入・削除・置換の最小回数)を使い、1から「距離÷長い方の文字数」を引いた値を一致率としました。比較用に、Python標準ライブラリのdifflib(別の照合アルゴリズム)の値も並べます。どちらも特定のCATツールの計算方法だと主張するものではありません。

  • 数字だけの違いでも、11文字の短い文では90.9%まで下がります。訳文の数字は直す必要があり、ファジーマッチはまさにその修正のための候補です。ツールの数字チェックが効くのもこの場面です。
  • プレースホルダの名前を{0}から{count}に変えただけで、編集距離では70.6%、difflibでは80.0%になりました。訳文は1文字も変わらないはずの違いです。プレースホルダを1つの記号とみなして比べると100%でした。自分のプレースホルダをツールが保護対象のタグとして扱うかはファイルフィルターの設定次第なので、作業前に確認します。
  • 短い文ほど1語の重みが大きくなります。扉を門に変えると6文字の文は83.3%、同じ置き換えでも25文字の文では96.0%です。UIのラベルでは1語が文のほとんどを占めます。
  • 語順の入れ替えは計算方法で最も差が出ます。「終了する前にセーブしてください。」と「セーブしてから終了してください。」は、意味がほぼ同じでも編集距離で43.8%、difflibで62.5%でした。
  • 見えない違いも数えられます。句点が1つ無いだけで1文字分の差になり、英語の例では改行コードがLFかCR LFかの違いだけでも一致率が下がりました。画面上で同じに見える文が完全一致になるとは限りません。
  • 大事なのは個々の数値ではありません。見積もりの区分は、あるツールがあなたの原文をどう採点したかの結果であり、プレイヤーには何も変わらない違いで割引の区分から外れることがある、という点です。どの一致率から何円になるかは業界共通の決まりではないので、見積書で区分の境目と単価を確認し、採点の仕組みはツールの公式ドキュメントで確認してください。
メモリ内の原文                              新しい原文                          編集距離  difflib
金貨を3枚手に入れた。                        金貨を5枚手に入れた。                  90.9%    90.9%
金貨を{0}枚手に入れた。                      金貨を{count}枚手に入れた。            70.6%    80.0%
扉を開けた。                                門を開けた。                          83.3%    83.3%
古い扉は封印されている。3つの鍵を…(25文字)   古い門は封印されている。3つの鍵を…     96.0%    96.0%
終了する前にセーブしてください。             セーブしてから終了してください。        43.8%    62.5%
Aボタンで続ける。                           Aボタンで続ける                        88.9%    94.1%

プレースホルダを1つの記号に置き換えてから比べた場合:
金貨を{0}枚 / 金貨を{count}枚  -> 完全に同じ文字列(100%)

繰り返し(リピティション) — 同じ文に2回払わないための数え方

リピティションは、同じ依頼の中に2回以上出てくるセグメントです。翻訳者が最初の1つを訳せば、ツールは残りに同じ訳を候補として出すため、分析レポートでは新規の分量と分けて数えられるのが一般的です。小さなゲームのメニュー・ショップ・確認ダイアログにありそうな18行の文字列表で、どれくらいの量になるかを数えました。

  • 書いたままの状態では、18行中5行が前の行の繰り返しで、164文字中26文字(15.9%)にあたります。「つづける」が3つのキーに、「設定」「タイトルに戻る」「お金が足りません。」が2つずつ出てきます。
  • 2つの戦利品の行は同じ内容なのにプレースホルダ名が違うため、別の文として数えられます。{count}を{0}にそろえると、繰り返しは6行・39文字(160文字中24.4%)に増えます。プレイヤーから見た変化はありません。
  • 繰り返しが同じ訳でよいとは限りません。タイトル画面の「つづける」はContinue、ゲームオーバー画面の「つづける」はTry Againと訳し分けたい、ということは起こりえます。最初の訳を全部に写すツールにはその区別がつかないので、menu.continueやgameover.continueといったキーを翻訳者が見られるようにしておきます。文脈が伝わるキーの付け方は文字列キーの命名設計で扱っています。
  • 見積もりの前に自分のファイルも数えておきます。下のスクリプトはキーと本文の組の一覧に使え、繰り返しが多ければその単価と確認方法を聞く理由になります。
strings.json(サンプルの文字列表)
  menu.continue        つづける
  menu.new_game        はじめから
  menu.options         設定
  pause.continue       つづける
  pause.options        設定
  pause.quit           タイトルに戻る
  gameover.continue    つづける
  gameover.quit        タイトルに戻る
  confirm.quit         終了しますか?セーブしていない進行状況は失われます。
  confirm.overwrite    このデータに上書きしますか?元には戻せません。
  shop.buy             買う
  shop.sell            売る
  shop.not_enough      お金が足りません。
  craft.not_enough     お金が足りません。
  loot.gold            金貨を{0}枚手に入れた。
  loot.gold_chest      金貨を{count}枚手に入れた。
  quest.accept         この依頼を受けますか?
  npc.blacksmith.greet いらっしゃい。何か鍛えていくかい?

node -e '
const rows = JSON.parse(require("fs").readFileSync("strings.json", "utf8"));
const seen = new Set(); let total = 0, repeated = 0;
for (const [key, text] of rows) {
  const n = [...text].length;
  total += n;
  if (seen.has(text)) repeated += n; else seen.add(text);
}
console.log(total + "文字中 " + repeated + "文字が繰り返し");'
# 164文字中 26文字が繰り返し

次の引き渡し前に原文ファイルで直せる5つのこと

どれも新しい道具は要りません。照合する側には見えて、プレイヤーには見えない違いを1つずつ消す作業です。

  • よく出る言い回しは1つの書き方にそろえる: 「タイトルに戻る」「タイトルへ戻る」「タイトル画面に戻る」は新規が3つですが、1つにそろえれば新規1つと繰り返し2つです。原文の列を並べ替えて読めば、表記ゆれの多くは見つかります。
  • プレースホルダの書式と名前の付け方を1つに決め、どの書式かを翻訳者に伝える: ツールが認識できるプレースホルダは打ち間違いが起きず、一致率も下げません。認識されなければ、どちらの問題も起こりえます。何を書き残すかはローカライズキットの準備のプレースホルダ規則の節にまとめています。
  • 書き出し前に改行コードと行末の空白をそろえる: 自分には見えなくても、照合では差になります。
  • 更新時は、変わらないキーのまま新規行と変更行だけを渡し、前回の訳文も添える: 変わっていない文はどちらにしても完全一致になるはずですが、小さいファイルのほうが確認も見積もりも速く済みます。版の間でキーを整理のために改名するのは避けます。翻訳メモリは原文で照合しますが、ゲームへの取り込みはキーで照合するからです。
  • 受け渡しの形式を翻訳者と決める: CSVでも列とエスケープの約束がそろえば足ります。XLIFFは書き出しの手間が増える代わりに、プレースホルダをタグとして、注記をメタデータとして運べます。中身はXLIFFとは(1.2と2.0の違い)で見られます。

CATツールで見積もる翻訳者に確認すること

答えは翻訳者やツールによって違うので、次の点は書面で確認しておきます。

  • どんな一致区分を使い、それぞれの単価はいくらか。区分の境目と単価は見積書そのものに書いてもらいます。
  • 完全一致と繰り返しは文脈の中で見直すのか、確定するだけか。短いUI文字列では、安いほうを選ぶとゲーム画面で困ることがあります。
  • この案件で育った翻訳メモリを納品してもらえるか、形式は何か。手元にあれば、別の翻訳者に頼むときにも再利用できます。
  • ツールの中で機械翻訳を使うか、そのとき原文が外部に送られるか。自社の機密保持の方針と照らし合わせます。
  • 日本語の原文をどの単位で数えるか。空白で区切る語数の数え方は日本語には使えず、「金貨を3枚手に入れた。」は11文字なのに1語と数えられます。語数か文字数か、ツールがどう数えるかを見積書で確認します。
  • ファイル以外に何が要るか(スクリーンショット、文字数制限、用語集など)。あわせて、訳文が入ったビルドの確認も計画します。CATツールは文字がゲーム画面でどう見えるかを知らないので、その工程はLQA(ローカライズQA)で扱っています。

関連記事