［Transformed］第2回：翻訳メモリの近未来

AI翻訳（機械翻訳）は日進月歩で発展している。新しい仕組みや応用事例を常に追い続けるのは難しい。本連載「Transformed」では、機械翻訳コンサルタントの河野弘毅氏が最新情報を紹介し、独自の視点から解説を加える。

---

---

翻訳メモリの歴史

「翻訳メモリ」というアイディアはかなり早い時期（一説によると1970年代）からあったようですが、翻訳業界でひろく使われるようになったのは1990年代後半に（SDLが買収する以前の）Tradosが普及してからです。

当時の翻訳業界ではデスクトップ向けソフトウェア製品のローカリゼーションがブームになっていましたが、そのトレンドをリードしていたマイクロソフトがいちはやく自社製品で使用すべき翻訳支援ツールとしてTradosを指定したことで一気にIT翻訳市場で使われるようになりました。

登場した当初は翻訳者の間で「他人が訳した文を自分の訳文に混ぜて使うなんて我慢できない」という強い否定的な反応がありましたが、ソースクライアントがトップダウンで指定したツールを拒否すれば仕事が別の（新人）翻訳者に流れるだけ、という市場原理を前にして抵抗も数年で消えていきました。

しかし、翻訳メモリはその登場直後に予想されたようには産業翻訳市場に普及しませんでした。

当初はIT翻訳以外の、「特許翻訳」や「医薬翻訳」などの個別分野に普及するのは時間の問題と思われていましたが、5年たっても10年たっても開発元が期待したようには他の翻訳分野に拡がりませんでした。

当時の私は、翻訳メモリが普及しない原因を「IT翻訳以外の分野では翻訳メモリが絶大な効果を発揮する改版翻訳の需要があまりないからだろう」と考えていましたが、その後、明らかにバージョンアップを繰り返す文書を翻訳しているにもかかわらず翻訳メモリという技法の存在すら知らないソースクライアントが多くいることが分かり、ソースクライアントが主体的にリードしない限り翻訳メモリがボトムアップで普及することはないのだという経験則を得て、現在では、翻訳メモリが当時の産業翻訳市場全体に普及しなかった最大の原因はソースクライアントの認知ないし支持の獲得が困難だったためだと考えるようになりました。

IPOをあきらめたTradosは2005年にSDLに自社を売却し、翻訳メモリは「産業翻訳の特定分野で必須ツールとして使われる翻訳支援ツールの主たる機能」という位置付けに落ち着いてさらに10年余りが過ぎました。

TMものまねMTエンジンの登場

そんな「あって当たり前だけど特に派手ではない」役どころにあった翻訳メモリですが、2020年あたりから翻訳オートメーションのカギを握る存在としてクローズアップされつつあると個人的には感じています。そのきっかけは機械翻訳におけるアダプテーション手法の発展です。

ニューラル機械翻訳が大量のコーパスを必要とすること、翻訳メモリがコーパスとして利用できること、そして大量のコーパスで学習済みの機械翻訳エンジン（以下MTエンジン）をもとに追加学習をほどこすとその分野の翻訳性能が改善されること（＝アダプテーション）の三点はこの文の読者にはおそらく既知の話と思われるので詳細は省きますが、これら三点をふまえて話を先に進めます。

アダプテーションがGoogle AutoMLとしてサービス提供され実際に翻訳現場で利用可能になったのは2018年ですが、このサービスが登場したときにはアダプテーションを行うにも数万文対から数十万文対の翻訳メモリが必要だと考えられていたことと、それだけの文対でAutoMLのMTエンジンを追加訓練しても素人目にわかるような明らかな翻訳性能改善が実感されにくかったこと、さらにGoogle AutoMLのユーザーインターフェイスが一般ユーザーではなくエンジニアを想定したものであったことから、すぐには大きなインパクトが起きませんでした。

しかし、2020年にロゼッタが発表したT-3MTが、アダプテーションを発展させた先にある可能性を示唆するという意味で注目すべき製品になりました。T-3MTは「ニューラル機械翻訳ではコーパスが大量にないと価値がない」という固定観念をくつがえして、たとえば数文というごく少量の翻訳メモリでも出力する訳文のテイストを大きく変更して翻訳メモリに近づけることができます。

私の推理では、T-3MTは機械学習において「過学習」と呼ばれる現象を逆手にとって機能化した製品で、翻訳メモリと編集距離が近い原文は過学習MTエンジンで訳出し、編集距離が遠い原文はアダプテーション前の一般MTエンジンで訳出するように複数のMTエンジンを使い分けているのではないかと思いますが、これは外部の人間の一推察にすぎません。

ただ、内部のアルゴリズムはどうあれ、T-3MTが少量の翻訳メモリを基準訳として訳文の出力をその基準訳にかなり明確に合わせ込む翻訳性能があることは使ってみればわかります。ここで考えたいことは、T-3MTが先鞭をつけた「翻訳メモリをそっくり真似する機能」が産業翻訳においてどのような意味と価値をもつか、という点です。

アダプテーション登場以前の翻訳メモリは、100%マッチのセンテンスをそっくり流用するか、あるいはファジーマッチのセンテンスをもとに訳文を翻訳支援ツール上で編集する素材に使うかのどちらかでした（コンコーダンス検索で翻訳メモリを訳し方の参照資料として使う利用法を別にすれば、ですが）。

これに対して、アダプテーションによって「TMものまねMTエンジン」（TMは翻訳メモリの意味）が使えるようになると、ファジーマッチが当たらないセンテンスに対しては「TMものまねMTエンジン」の訳文を下訳に使うワークフローが選択肢に加わります。

このような「TMものまねMTエンジン」は、その翻訳性能が一定水準を超えれば、従来の一般的なAI翻訳エンジンと比べて、産業翻訳業界における翻訳支援ツールとしての価値がずっと高いのではないかと私自身は考えています。なぜなら、ポストエディットの作業負荷を（あわよくば大幅に）減らせる可能性があるからです。

もちろん製品化された翻訳支援ツールが市場に普及するには、一定水準以上に洗練されたユーザーインターフェイスと市場に受け入れられる価格を備えていることが条件になりますが、少なくともT-3MTによって「TMものまねMTエンジン」の有効性は実証されたわけですから、市場で成功する製品が産まれるのは時間の問題だと思います。

また、翻訳メモリにとっては「TMものまねMTエンジン」のトレーニング教材として活用される可能性が産まれたことで、従来はリサイクル用途しかないと思われていた少量の翻訳メモリに新しい重要な使いみちが拓けました。

文書単位MTサービスの登場

翻訳メモリについては、この他にも2020年から登場した新しいテーマがあります。それは翻訳単位を分節するときの粒度に関する問題です。

翻訳支援ツールではリンギストがそのつど編集するテキストの単位を「翻訳単位」と呼んでおり、一般的に「文」（＝センテンス）が翻訳単位となることはよく知られています。原文と翻訳メモリとの一致率も翻訳単位ごとに算出する必要があるので、翻訳メモリもまた、翻訳単位ごと（つまり一文ごと）に分節された形式でファイルに保存されていますし、翻訳支援ツールのエディターから機械翻訳の出力を呼び出すときも翻訳単位ごとにMTエンジンで処理して訳文生成しています。

ところが昨年（2020年）あたりから、人気のあるMTサービスが文書単位で翻訳を行うようにアルゴリズムを改善してきました。それ以前のMTエンジンは文単位で翻訳していましたが、一度に機械翻訳する範囲を文書全体（あるいはパラグラフかもしれませんが少なくとも一文よりも広範囲）に拡張することによって、その範囲内については文脈情報を読み取って機械翻訳の出力を文脈に合わせて変更できるようになりました。DeepLは2020年3月に日本語での翻訳サービス提供を開始した当初から文書単位で翻訳していたようですし、現在（2021年4月）ではGoogle翻訳も文書単位での翻訳に切り替えていると言われています。
このため、翻訳支援ツールからMTエンジンを呼び出すときの翻訳単位の「粒度」が無視できない問題としてにわかに浮上してきました。

MTエンジンが文書単位での翻訳に対応して文脈に応じた訳文を生成できるようになったのに、翻訳支援ツールからMTエンジンを呼び出す段階で文書を文単位まで分節（細切れ）してしまうので、せっかくのMTエンジンの翻訳性能改善を活かせない状況が各社の翻訳支援ツールで起きています（2021年4月現在）。

この問題を翻訳支援ツールのメーカー各社は把握しているはずなので近い将来に対応策を講じてくると期待していますが、問題は翻訳メモリです。

これまで（企業によっては二十年近い）長い年月をかけて蓄積してきた翻訳メモリはほぼすべて文単位であり、その資産を活用するには原文を文単位に分節して翻訳メモリとのマッチ率を解析する必要があります。ですが、今後ますます性能改善を追求していくMTエンジンが文単位ではなく文書単位の翻訳に移行していくのは不可逆的な進化になるので、TM資産の活用とMTエンジンの活用が翻訳単位の分節粒度をめぐって矛盾した運用を求める状況になっています。

この問題は「文脈をどう反映するのがよい翻訳か」という昔からある翻訳品質に関する議論の現代におけるバリエーションですが、同じ産業翻訳市場のなかにあっても「既存の翻訳をどこまで尊重すべきか」が専門分野によって（ときに大きく）異なるため、正解は専門分野によって異なるように思います。

翻訳メモリでおなじみの諸問題

私が強調したいのは、現在の翻訳メモリの主流である「文単位での分節」という考え方がAI翻訳登場以前の「訳文のリサイクルによる翻訳負荷軽減」という枯れた技術の要請に基づく言語資産管理スキームであったのに対して、これに対抗する形で浮上した「文書単位での機械翻訳」というAI翻訳からの要件は、今後さらなる発展が予想される新しい技術の要請に基づく言語資源管理スキームであるという点です。

私は、これからますますAI翻訳の活用が進むことによって、産業翻訳の翻訳プロセスが「翻訳がポストエディットに置き換えられる」という目先の変化にとどまらず、より根本的に変化していくと考えていますが、その翻訳プロセスの根本的変化に大きく関わる存在となるのが「翻訳メモリ」もっと広く言えば「翻訳的言語資産」だと予想しています。

翻訳プロセスの未来像に話を進める前に、ここで翻訳メモリにまつわるよくある課題についてまとめておきましょう。

問題1. セグメント不一致

セグメンテーションルールのばらつきのために本来なら当たるべき翻訳メモリが当たらない。言い換えれば与えられた翻訳メモリがどのようなセグメンテーションルールを適用して分節化されたのかは翻訳メモリを全調査しなければわからない。

問題2. レトロフィット

顧客からの最終校正が翻訳支援ツール上ではなく出力した訳文ファイルに対して行われた結果として、最終校正を反映しない旧訳にもとづいて翻訳メモリが生成される。その翻訳メモリが新版の訳文内に流用されたときに顧客から「前回の校正指示が反映されておらずまた同じ間違いをくり返しているじゃないか」というクレームを招く（レトロフィットという呼び方はTradosの機能名に由来する）。

問題3. ローカライズ

（レトロフィット問題のうち、テキスト修正のレベルを超えた大幅な編集が行われる場合を特に別の問題としてとりあげる）

翻訳時は原文と訳文が対応していたとしても、ローカライズ上の要請から納品時までに訳文側で文の追加・削除・変更が行われるケースがある（具体例として英和IT翻訳の場合に日本語版だけの機能に関する追加記述がある場合など）。このような場合には翻訳支援ツールの出力だけを保存してもその後の工程でどの文が追加・削除・変更されたのかわからないが、後工程での追加・削除・変更箇所を再現性のある形で記録に残せるツールが（少なくとも定番ツールとしては）存在しない。

問題4. コンテキスト消失

翻訳を分節したときに文脈情報が失われる。翻訳単位の前後の文まで翻訳メモリに保存する「パーフェクトマッチ方式」は文脈の継承方法として不完全だしファイル構成上もムダが多い。XLIFFなら文脈を維持できるが異なるツール間のファイル形式の互換性が保証されず、翻訳支援ツールを変更やバージョンアップしたときに旧い翻訳メモリが読み込めない問題が起きやすい。

問題5. クリーンナップ

翻訳終了後のテキストを翻訳メモリとして保存するときには表記の統一や用語集への準拠、セグメンテーションの修正などさまざまにテキストを整える編集作業（クリーンナップ）が必要だが、現実には作業者がクリーンナップの時間をとれない現場が大部分である（＝クリーンナップを行うことに対して会社の理解が得られない）。もう次の仕事が始まっていて、納品した仕事の後処理をやる余裕がない。

問題6.（ソースクライアントの場合）翻訳メモリの保管と再利用

ソースクライアントの大企業であちこちの部門で翻訳が行われているようなケースでは、大量の翻訳メモリが部門の壁を越えて社内に分散し、整理が追いつかないために、新しい翻訳案件が発生したときにその案件とマッチする翻訳メモリをアーカイブの中から探し出せない。その結果として過去訳があるのに流用できない事態が生じる。翻訳メモリの管理業務において会社全体としての統制がとれていないと、運が良くて部門単位、運が悪ければ担当者の個人単位でしか翻訳メモリを活用できない。

問題7.（翻訳会社の場合）翻訳メモリの破棄

翻訳会社では伝統的に翻訳した原文・訳文・関連資料は機密保持の観点から業務完了後すみやかに返却ないし削除する契約を発注元と締結してきた。翻訳支援ツールにもこの考え方が反映されているせいか、主流の翻訳支援ツールはいずれも翻訳作業を行うワークベンチとして設計されており、いわば副産物にすぎない翻訳メモリを永続性のあるファイルとして保存したり構造化したりする視点が弱い。それらの事情により、翻訳会社がよほど強く決心しないと翻訳メモリの保存や活用が社内制度として確立されにくい。

翻訳メモリのワークフローを再考する

以上に列挙したように翻訳メモリをめぐっては翻訳のプロセスと相関して簡単には解決できない問題が複数あり、問題が一切存在しない翻訳現場というのはおそらくどこにもないのではないでしょうか？

このような従来からの課題に加えて「TMものまねMTエンジン」をどう活用するか、また、文書単位で翻訳するMTエンジンの翻訳性能をどう引き出すか、という新しい課題が加わった現在、翻訳メモリをフル活用する視点にたって産業翻訳のプロセスを再考する時期にきていると私は考えています。

そういうわけでここからは、どうすればこれらの課題を解決できるか翻訳プロセスの原点にかえって再考してみます。

翻訳プロセス再考の出発点となるのは「文書単位の機械翻訳」です。その理由は、くり返しますが文単位から文書単位への機械翻訳の移行は今後ますます主流となり後戻りしないと考えているためです。

はじめに原文を文書単位で機械翻訳すると訳文も当然に文書単位になります。一方、旧版の翻訳をできる限り流用したいとなると文単位で旧版の訳文を新版に流し込み、100%マッチの文についてはほぼ修正不要としたいでしょう。

この前提条件から導き出されるワークフローは何通りもあり得ると思いますが、ここでは私は以下のように考えてみました。

以上に説明した新しい手順で、前節で列挙した翻訳メモリの諸問題がどのように解決されるか、みてみましょう。

まず、新旧の原文を同じタイミングで同一の分節規則に基づいて分節するので、問題１（セグメント不一致）が解消されます。

また、翻訳アーカイブに保管された旧版の訳文は客先からの最終校正まで反映された完成版ですから、問題２（レトロフィット）が解消されます。過去訳の翻訳後に翻訳メモリを生成しませんから、問題5（クリーンナップ）は行う必要がなくなります。

ここで分節とアライメントについては、自然言語処理分野の研究で優れた新手法が毎年のように発表されていますから、おそらく数年以内にかなり自動化の精度があがり人手検査の負荷が下がることを期待できると思います。問題3（ローカライズ）については近い将来でも人手による確認が必要かと思いますが、どこをローカライズしたか詳細な変更履歴を記録して管理するタスクの信頼性をあげようとするよりもいずれにしても必要なアライメントチェックの人手工程にローカライズチェックの手順を追加するほうが現実的だろうと思います。

ここで述べた手順は翻訳メモリの生成をいわばオンデマンドで行うわけですが、これにより旧版文書はしあがりの文書ファイル単位で行えばよいことになり、翻訳メモリを保持管理する必要がなくなります。これで問題6（翻訳メモリの保管と再利用）が消滅します。文書単位のプールから新しい案件の文書と近い文書を探し出すアルゴリズムは自然言語処理の分野で以前から研究されているので、その成果を利用できると想定しています。

また、このワークフローであれば分節化する前に文書単位でマッチをとっていますから、従来通りのパーフェクトマッチ方式を用いるとしても、不特定多数の原文からプールされた文単位の翻訳メモリから一致した文を探す従来の運用環境と比べて翻訳メモリの素性がわかっているぶんだけ精度が増しますし、翻訳メモリそのものが一時的にしか作成されず翻訳プロセス完了後に廃棄されますから、ファイル容量のムダもなくなります。すなわち、問題4（コンテキスト消失）も解決できます。

新しい技術は新しいツールを産む

すこし説明がくどくなってしまいましたが、要するに機械翻訳をはじめとする自然言語処理の近年の成果をうまくとりまとめて適用できれば、現在主流となっている翻訳支援ツールで想定されている翻訳プロセスで不可避的に発生する諸問題をかなり解決できる可能性があることを、ここで指摘したいと思います。

私はAI翻訳がいわゆる「破壊的イノベーション」だと考えていますが、破壊的イノベーションの通例にみられるように、AI翻訳は既存の産業翻訳の翻訳プロセスもまた刷新すると予想しています。

破壊的イノベーションの理論では、従来技術に準拠して成功した製品は、それを支持するユーザーからの需要を尊重する必要があることが足かせとなって破壊的イノベーションへの対応が後手に回る結果として、新製品との競争に敗れて淘汰されていきます。

機械翻訳と自然言語処理が短期間に長足で進歩している現在、前節で述べた新しいワークフローの予想が外れたとしても、なんらかの別の新しいワークフローに基づいて構想された次世代の翻訳支援ツールが登場し、それ以前のワークフローを前提として構想された旧世代の翻訳支援ツール（すなわち今日主流となっているすべての翻訳支援ツール）はおしなべて時代遅れとなる可能性が高いのではないでしょうか。

パラダイムシフト：プロセスからデータへ

従来の翻訳支援ツールは「翻訳」というプロセスを中心に据えて構想されています。それと対比して言うならば、次世代の翻訳支援ツールは「言語資源」というデータを中心に据えて構想されるというのが私の近未来予想です。

最後に、もう少し根本的な問題を提起したいと思います（これは私があるセミナーで参加者の方から実際に受けた質問です）。「TMものまねMTエンジン」がもしも普及したら、それでも以上に述べたような「煩雑な」TM流用の翻訳プロセスがまだ必要なのでしょうか？

この質問への回答の鍵を握るのはソースクライアントだと思います。このコラムの冒頭でソースクライアントの選択から翻訳支援ツールが普及した歴史を紹介しましたが、そのソースクライアントが「やっぱり旧版から変更されていない箇所は旧版と訳文が完全に一致してほしい」と希望する限りは、翻訳メモリを流用する現在のワークフローは生きながらえるでしょう。

しかし、ある日突然にソースクライアントが「これだけ翻訳メモリと似せてくれるのなら、もう機械翻訳でいいんじゃない？機械翻訳なら工程がシンプルになって納期も単価も半分になるでしょ？」と言い出したとき、翻訳メモリの流用という技法の終わりが始まると思います。

もちろん、流用で使われなくなったとしても「TMものまねMTエンジン」を訓練するという翻訳メモリの需要はなくなりません（それどころか今以上に重要視されます）から、翻訳メモリの価値は今後ますますあがっていき、問題7（翻訳メモリの破棄）も昔話になる、というのが翻訳メモリに関する私の近未来予想です。

---