LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・保守を受託

翻訳・ローカライズ管理システム(TMS)とは——翻訳資産を再利用し多言語展開を回す仕組み

翻訳・ローカライズ管理システム(TMS。Translation Management System)とは、製品やマニュアル、UI、Webサイトの多言語化にあたって、翻訳対象の文字列を切り出し、過去の翻訳や用語を引き当てながら、翻訳・レビュー・承認・反映という一連の作業を管理するための仕組みを指します。中核にあるのは、過去の訳文を再利用する翻訳メモリ(TM)と、訳語を統一する用語集(termbase)です^*2。人手の翻訳と機械翻訳を組み合わせつつ、翻訳会社や翻訳者への発注状況まで一元的に扱う点が特徴になります。

ワークフローの起点は、翻訳対象となる文字列の抽出です。ソースファイルからコードやレイアウトと切り離して翻訳すべきテキストだけを取り出し、文・段落といった単位(セグメント)に分割します^*2。抽出したテキストは、翻訳者がツールの種類を問わず扱えるようXLIFF(XML Localization Interchange File Format)などの交換フォーマットに格納され、翻訳後にもとのファイルへ組み戻されます^*1*3。

この抽出・翻訳・組み戻しを人手だけで管理すると、更新のたびに全文を翻訳し直すことになりかねません。TMSは既訳の再利用と用語の統一を仕組みとして支える点に価値があるといえるでしょう。次章では、なぜ今こうした仕組みが求められるのかを整理していきましょう。

なぜ今TMSなのか——多言語展開とアジャイル開発で翻訳が分散・繰り返す課題

グローバル製品やSaaS、業務システムを多言語で提供する場面では、UIの文言・ヘルプ・マニュアル・Webサイトといった翻訳対象が複数のファイルやリポジトリに散らばりがちです。しかも製品は継続的に更新されるため、リリースのたびに追加・変更された文言の翻訳が発生します。翻訳資産を管理していないと、同じような文言を毎回ゼロから訳し直し、訳語も担当者ごとにばらつくという状態に陥りやすいのです。

翻訳メモリはこの繰り返しを吸収する仕組みです。過去のプロジェクトで翻訳したセグメントを蓄積し、新しい案件に同じ、あるいは似た文が現れたときに再利用できます^*2。プロジェクトを重ねるほどメモリは充実し、一致する箇所が増えていきます^*2。訳し直しの範囲が差分に絞られれば、翻訳の一貫性を保ちながら作業量を抑えられるでしょう。

用語のずれも見過ごせない課題でしょう。製品開発が進むにつれて呼称や表記は変わり、用語集と翻訳メモリの内容が食い違ってくることは珍しくありません^*2。翻訳資産は製品のコードと同じく、放置すれば価値が下がる資産であり、継続的な保守が必要だとされています^*2。TMSは、この資産をチームや外注先をまたいで維持するための土台になります。

TMSの中核機能——翻訳メモリ・用語集・機械翻訳連携とワークフロー

翻訳メモリ(TM)——過去の訳文を再利用する資産

翻訳メモリは、原文のセグメントと訳文のセグメントを対にして蓄えたデータベースです。セグメントの単位は単語・文・段落のいずれもあり得ます^*2。新しい原文を照合すると、原文がそのまま一致するフルマッチ、前後の文脈まで一致するコンテキストマッチ、部分的に一致するファジーマッチに分類され、ファジーマッチには一致度がパーセンテージで示されます^*2。翻訳費用の面でも、完全一致するセグメントは最も安く、まったく新規の文は最も高く設定されるのが一般的です^*2。翻訳メモリの交換にはTMX(Translation Memory eXchange。1.4b版は2005年公開)というXML形式が広く使われています^*2。

用語集(termbase)——訳語を統一する辞書

用語集は、製品名・機能名・専門用語などの訳語を概念単位で定義し、定義文とともに管理する辞書です^*3。用語集を整備すると、複数の翻訳者が関わっても訳語がぶれにくくなります。用語データの交換にはTBX(TermBase eXchange)が用いられ、その最新版はISO 30042:2019として標準化されています^*3。

機械翻訳(MT)連携とポストエディット

機械翻訳は、新規に訳す文の下訳として組み込まれることが増えています。ただし機械翻訳の出力をそのまま公開できるとは限りません。ISO 18587:2017は、機械翻訳出力に対する人手のポストエディット(post-editing)の要件と、ポストエディターに求められる力量を定めた国際規格です。同規格では、最終的な訳文が用途に適し、人手翻訳に相当する品質に達していることを求めています(出典：ISO 18587:2017)。TMS上でMTと人手のレビューをどう組み合わせるかは、品質設計の要になります。誇張した精度をうたうのではなく、人手の確認を前提に運用する姿勢が現実的でしょう。

翻訳ワークフローとファイル形式

依頼・翻訳・レビュー・承認という工程をTMS上で管理し、担当者や進捗を可視化します。ここで基盤となるのがXLIFFです。XLIFFはセグメントごとに原文と訳文を対で持つXMLベースの形式で、ソースの体裁を気にせず翻訳作業を進め、完了後にファイルを組み戻せます^*1*3。XLIFF 2.1は2018年2月13日にOASIS標準として承認され、のちにISO 21720としても採択されました^*1。抽出・翻訳・組み戻しをこの共通形式で通すことで、特定のツールに縛られずに作業を回せます。

CMS・ドキュメント管理・PIMとの違いと連携——輸配送TMSとの混同にも注意

まず用語の混同を避けておきましょう。本稿のTMSはTranslation Management System(翻訳・ローカライズ管理)であり、物流分野の輸配送管理システム(Transportation Management System)や、勤怠管理のシステムとは名称が似ているだけの別物です。ここでは翻訳資産とローカライズ工程を扱う仕組みとして話を進めます。

そのうえで、隣接するシステムとの役割分担を整理します。CMS(コンテンツ管理システム)は、Webページや記事といったコンテンツそのものを作成・公開する仕組みです。TMSはそのコンテンツを多言語化する工程を担い、CMSから原文を受け取り、訳文を返す関係になります。ドキュメント管理システムの主眼はファイルの保管・版管理であり、翻訳資産の再利用は対象外です。PIM(商品情報管理)は商品マスタや属性を一元管理して各チャネルへ配信する仕組みで、その商品説明文などを各言語へ展開する局面でTMSと連携します。

整理すると次の通りです。

パッケージ(TMS SaaS)とスクラッチ——TMS開発の選び方

TMSを用意する道は大きく二つあります。既製のパッケージ(TMS SaaS)を採用する道と、自社要件に合わせてスクラッチで開発する道です。翻訳メモリ・用語集・XLIFF入出力といった基本機能は、成熟したSaaSであればひと通り備わっています。標準機能で足りるなら、まずパッケージを軸に検討するのが現実的でしょう。

一方で、既存の開発パイプラインや社内システムとの連携が深い場合、あるいは自社固有の承認フローや権限管理が必須の場合は、スクラッチや大幅なカスタマイズが視野に入ります。判断の分かれ目は、翻訳メモリや用語集を業界標準の形式(TMX・TBX・XLIFF)で入出力できるか、そして翻訳資産を自社の管理下に置けるかという点です^*2*3。標準形式でやり取りできれば、将来ツールを乗り換える際も資産を移行しやすくなります^*2。

パッケージであってもスクラッチであっても、外部システムとの接続部分(コネクタやAPI)は個別開発になることが多いでしょう。CMSやリポジトリと自動連携させる部分こそ、外注先の設計力が問われる領域です。次章で、外注時に確認すべき点を具体的に見ていきます。

TMS開発を外注する際の確認点と内製との分かれ目

翻訳資産(TM・用語集)の帰属と形式

まず確認したいのは、翻訳メモリと用語集の所有権とエクスポート可否です。翻訳資産は蓄積するほど価値が高まる資産であり、TMXやTBXといった標準形式で自社に取り出せるかどうかを契約前に明確にしておく必要があります^*2*3。資産が外注先やツールに囲い込まれると、乗り換えのたびに再構築を強いられかねません。

継続的ローカライズ(開発パイプライン連携)

製品の更新に合わせて翻訳を回すには、開発リポジトリやCMSと連携し、追加・変更された文言を自動で抽出して翻訳工程へ送る仕組みが効きます。文字列の抽出とセグメント化はソースコードから翻訳対象を切り離す作業であり、通常はエンジニアが担います^*2。この連携部分の設計・実装力は、外注先を見極めるうえで重要な観点になるでしょう。どのリポジトリやCMSと、どの粒度で連携するのかを具体的にすり合わせておくことをおすすめします。

機械翻訳とレビューの品質基準

機械翻訳を使う場合は、ポストエディットの範囲とレビュー体制を明文化しておきます。ISO 18587は機械翻訳出力のポストエディットについて、最終訳文が用途に適し人手翻訳に相当する品質に達することを求めています(出典：ISO 18587:2017)。また翻訳品質の国際規格であるISO 17100は、翻訳者本人とは別の担当者によるレビュー(revision)を要件としています(出典：ISO 17100:2015)。どの言語・どのコンテンツに人手レビューを入れるか、品質評価(LQA)をどう回すかを、あらかじめ取り決めておくとよいでしょう。

内製と外注の分かれ目

対象言語が少なく更新頻度も低いなら、SaaSを契約して社内で運用する形で十分な場合もあります。判断が分かれるのは、対象言語が多い、更新が頻繁、既存システムとの連携が複雑、という条件が重なるケースでしょう。内製では既存の担当者が通常業務と兼務することになり、抽出の自動化や品質基準の設計まで手が回らないこともあります。元請（プライムベンダー）として要件定義から連携開発、運用までを一括で引き受けられる体制かどうかを、委託先選びの軸に据えると判断しやすくなります。

まとめ：TMS開発の外注で押さえる3つの判断軸

本稿では翻訳・ローカライズ管理システム(TMS)の役割と外注の進め方を、公的な標準情報をもとに整理しました。要点は3つに集約できます。第一に、TMSは翻訳メモリと用語集で過去の翻訳を資産化し、抽出から反映までのワークフローを回す仕組みです^*2。第二に、CMS・ドキュメント管理・PIMとは役割が異なり、輸配送のTMSとは名称が似た別概念であるため、連携を前提に整理する必要があります。第三に、外注では翻訳資産の帰属と標準形式(TMX・TBX・XLIFF)での入出力、開発パイプラインとの連携、機械翻訳とレビューの品質基準という3点が、委託先を見極める判断軸になります^*1*2*3。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：OASIS「XLIFF Version 2.1」（OASIS Standard、2018年2月13日）（https://docs.oasis-open.org/xliff/xliff-core/v2.1/xliff-core-v2.1.html）
2. *2　出典：Microsoft Learn「Maintain translation memories」（Globalization documentation）（https://learn.microsoft.com/en-us/globalization/localization/translation-memories）
3. *3　出典：Microsoft Learn「Localization file formats」（Globalization documentation）（https://learn.microsoft.com/en-us/globalization/localization/localization-file-formats）
4. *4　出典：ISO「ISO 18587:2017 Translation services — Post-editing of machine translation output — Requirements」（国際標準化機構）※iso.orgはbotアクセスを制限（www.iso.org/standard/62970.html）
5. *5　出典：ISO「ISO 17100:2015 Translation services — Requirements for translation services」（国際標準化機構）※iso.orgはbotアクセスを制限（www.iso.org/standard/59149.html）

Tweet