home‎ > ‎

IT翻訳入門【クライアント編】07:翻訳メモリの基礎知識

発表機会:『通訳・翻訳ジャーナル』(イカロス出版)2000年11月号掲載(雑誌記事)

1999年から一年あまり『通訳翻訳ジャーナル』(イカロス出版)という業界誌に「IT翻訳入門」というタイトルで連載記事を書かせていただく機会がありました。現在同誌は年四回発行ですが当時は月刊誌でした。このホームページの内容は、雑誌向けの原稿に加筆修正し、連載と並行して当時のホームページに公開したものです。『通訳・翻訳ジャーナル』の概要は下記のリンクから参照できます。


利用上の注意:このホームページは執筆当時(1999-2000年)の状況について述べており、すでにかなりの記述が「時代遅れ」となっていますが、原則として当時のままの内容を修正せずに公開しています。ご注意ください。

もう改版比較機能にはもどれない

旧版の翻訳をリサイクルする手段として、従来は Word や FrameMaker の版数比較機能が使われてきました。版数比較機能を使うと、旧版と比較して追加された箇所をたとえば赤く、削除された箇所をたとえば青く表示して、その情報を元に改版分の作業量を見積もったり、改版翻訳時に旧版を参照する参考に役立てたりできます。

この版数比較機能は、単語単位、あるいはセンテンス単位の追加、改訂、削除があった場合には役立ちますが、文書の流れが修正された場合、たとえばパラグラフ単位やセクション単位で旧版と異なる順序に並べ替えてある場合にはほとんどお手上げで、実際には旧版に訳があるのに新規翻訳と認識されてしまうことがしばしばあります。

版数比較機能と比べると、翻訳メモリを利用した旧版のリサイクルのほうがずっと効率的です。翻訳メモリの場合はセンテンス単位あるいはパラグラフ単位で旧版を参照するため、パラグラフやセクションの順序が旧版から入れ替えてあっても問題ありません。

では版数比較機能をまったく使わなくなったかというと、改版箇所が少ない場合には現在でも版数比較機能を使うほうが早く作業できるケースがあります。たとえば FrameMaker の改版で翻訳メモリを使おうとすると S-Tagger を使ってファイルをコンバートしたり戻したりする手間がかかりますから、改版箇所が少ない場合には、いちいちコンバートする手間をかけずに版数比較機能を使ったほうが短時間で処理できます。しかし、一般的には版数比較機能によるリサイクルは廃れてゆき、翻訳メモリを使ったリサイクルが主流になると思います。この道が避けて通れないのであれば、人より早く飛び込んで先手を打ってノウハウを蓄積するほうが上策でしょう。

翻訳メモリのオーナーシップ

翻訳メモリは現在のところ、翻訳エージェントや翻訳者の手元にあったりしますが、翻訳メモリの効果を最大化するには、翻訳メモリは発注者が自分の手元に置いておく (=翻訳メモリの「オーナーシップ」を発注側が保持する) のが望ましいように思います。その理由は、ひとつには翻訳の主導権をクライアントが維持するためです。現状でリサイクル翻訳がもっとも効果的に機能するのは改訂版の翻訳時です。翻訳メモリが発注側の手元にあれば、Ver.2 の翻訳は A 社に発注したが、Ver.3 の翻訳は B 社に発注する、ということが可能ですが、翻訳メモリを翻訳会社やローカライザーなどの翻訳ベンダーに丸投げして任せてしまうと、改訂翻訳時にもそのベンダーから離れにくくなります。

旧版の翻訳を担当したベンダーの仕事ぶりに特に不満がない場合は、短期的には丸投げしたほうがクライアント側は楽ができますが、特定ベンダーへの依存度が高まってしまうと、改版時のベンダーとの交渉において価格の点などでベンダー側の意向に左右されやすくなる不利が生じます。ベンダーやその担当者も時とともに変化していきますから、Ver.2 でいい仕事をしたベンダーが、Ver.4 や Ver.5 のときまでベスト チョイスのベンダーであり続けるという保証はどこにもありません。その点を考えると、はじめは多少面倒に思えても、発注側は社内に翻訳メモリを置いておき、その使い方のノウハウを社内に育てていくほうが良いように思います。

ここで注意が必要なのは、発注側が翻訳メモリを「手元に置く」必要があるからと言って、それは、翻訳メモリの作成やメンテナンスをすべてクライアントが自分でやるという意味ではないということです。ベンダーがウソをついたときにそれを見破るためには一定水準のノウハウはクライアントとして身につけておく必要がありますが、それ以上の翻訳メモリの加工・編集作業(のスキル)は、予算が許す限りアウトソーシングしてしまうほうが合理的でしょう。このあたりの事情をキャッチフレーズ的にまとめると、「翻訳メモリはクライアントが持ち、運用スキルはベンダーが持つ」のが妥当だと思います。

翻訳メモリの文脈依存性

翻訳メモリはリサイクルするのが目的ですが、実際に使ってみると、流用した訳文をリサイクル先にポコッとはめこんだときに、前後の文脈からそれが浮いてしまうことがしばしばあります。特に英文和訳の場合は文脈にあわせて多かれ少なかれ内容を意訳せざるを得ないわけですが、意訳されたセンテンスを、前後の文脈から切り離してセンテンス単位でリサイクルしても、流用先の文脈の中で浮いてしまい、多少なりとも修正が必要となるのは当然のことです。

これに対する一つの対策は、翻訳メモリをパラグラフ単位で生成することではないかと思いますが、これについては筆者もまだ実際に試したことがないので、効果について保証できません。パラグラフ単位の翻訳メモリであれば、ある程度は文脈そのものを翻訳メモリの中に閉じこめることができるため、異なる文脈中にリサイクルしてしまう失敗率は減らせますが、センテンス単位で同じ箇所をリサイクルするよりも当然ながらリサイクル率が低下します。この問題に対処するテクニックは今後現場で試行錯誤しながら生まれてくるでしょうが、今のところは「翻訳メモリは文脈に依存するので、リサイクル後に修正しなければならないことがある」という認識が必要だと思います。

翻訳メモリのクオリティ

旧版の翻訳の品質が悪いとか、旧版と新版で翻訳上の約束事が変わってしまったので修正が必要だとかいうことはしばしばあります。この問題に対するうまい対策というのはなく、地道に翻訳の品質を上げていくしかありません。もちろん、最初から下手な翻訳会社(翻訳者)には仕事を発注しないことが一番大事です。

TRADOS で翻訳メモリ化したところで下手な翻訳がうまくなるわけではありませんし、下手な翻訳をリサイクルすると、できあがった改版翻訳にも下手な翻訳が残ることになりますから、どこかでその連鎖を断ち切る必要があります。それができるのは、改訂箇所を担当する翻訳者が優秀で、流用された箇所についても見直しを行う場合でしょう。翻訳メモリそのものを編集することも可能ですが、現状の TRADOS では翻訳メモリの編集機能がまだまだ貧弱ですし、前後の文脈から切り離されたセンテンス単位の翻訳では適切なリライトは難しいので、品質の悪い翻訳メモリについては、思い切って捨てるか、新規翻訳にプレ翻訳をかけて文脈内にはめこまれた状態で改訂翻訳を担当する翻訳者にリライトしてもらうのが現実的な対処方法だろうと思います。

クライアント側として翻訳メモリのクオリティについて注意すべき点は、流用箇所の翻訳単価の設定でしょう。旧版の悪い品質の箇所をリライトしたい場合は、多少なりとも流用箇所に対する編集料金を支払う必要がでてきます。もともとコストを節約するために翻訳メモリを導入しているわけですから、旧版から流用できた箇所にまで新規翻訳と同等かそれに近いリライト コストをかけるのは、納得できないかもしれません。しかし、流用箇所のリライトの出費を絞ると、現場で実際にその箇所の翻訳を担当する翻訳者はリライトに時間もエネルギーも割けなくなりますから、品質の悪い旧訳からの流用箇所がまだらに残ることになります。読者は当然ながらどこが旧版からの流用箇所で、どこが新規翻訳箇所か、などということを考えずに全文を読みますから、結局できあがった改訂翻訳文書の品質が低いといわれてしまいます。

翻訳メモリと訳文の同期

チェックやレビューで訳文を修正する必要というのは常にあります。問題は、訳文の修正が翻訳メモリに反映されない可能性で、これは訳文と翻訳メモリが分離された瞬間からつきまとう問題です。この問題を、翻訳メモリの「同期(シンクロナイズ)」の問題と呼びます。

訳文と翻訳メモリが別々に存在していることが問題の原因であすから、対策としてまず思いつくのは、できる限り、訳文 (Clean Up 前の TRADOS 形式) のままで (翻訳メモリを抽出せずに) 翻訳を保存しておくという方法でしょう。

たいていの製品には E バグ (英語版マニュアルの内容的誤り)、J バグ (日本語化した際に生じたソフトの不具合)、J スペック (日本語版独自の機能に修正しているために英語版マニュアルの翻訳が当てはまらない箇所) の問題がつきまといますから、本質的には訳文と和文は「異なって」しまいます。訳文はあくまでも日本語マニュアルを作成するための「素材」にすぎません。そして、リサイクルしたいテキストは、E バグ修正前後のどちらなのか、J バグ修正前後のどちらなのか、J スペック反映前後のどちらなのか、このあたりが明示されることはあまりありません。J バグ、J スペックについては新版でも旧版と同様の編集が必要なこともあれば必要でないこともあり、J バグ、J スペック反映前後のどちらの翻訳を翻訳メモリとして保存しておくかはそれぞれ一長一短あるような気がします。

一般的に言えるのは、旧版でどのような J バグや J スペックがあったか、次版の改訂まで記憶(記録)する機能的な方法がないために、たいていは皆、どこをなおしたのかうろ覚えであてにならないということです。そうなると、J バグや J スペックが反映された訳文というのは、ただ単に「英文の訳が謎に修正されていて、それが翻訳ミスなのかそれとも J バグ や E バグの修正なのか、読んでもよくわからない」ような状況となることのほうが多い気がします。となると、最終的に日本語版として制作された文書を翻訳メモリ化するよりも、なるべく翻訳者のアウトプットをそのまま素材として翻訳メモリ化するほうが正しいような気もします。E バグはともかく、J バグ、J スペックの反映編集は、版がことなると製品も異なるのだから、そのつど発生する工程と割り切るのが正しいのではないでしょうか。

翻訳メモリのスコープ 

翻訳メモリについてしばしば迷う点として、どの範囲までの過去訳を翻訳メモリ化するか、ということがあります。たくさんの旧訳を翻訳メモリとして登録すればするほど、見かけのリサイクル率は向上しますが、訳語や仕様のばらつきも大きくなるので、旧版流用時の修正編集作業の負担があがってきます。また、肥大化した翻訳メモリを検索したり流用したりするときにかかる処理時間や CPU への負荷もどんどん増えてしまいます。そのようなデメリットを考えると、やたらに広い範囲の旧訳を翻訳メモリ化すべきではないと考えられます。ではどの範囲までの旧訳を流用するべきか、その問題を翻訳メモリの「スコープ」の問題と呼ぶことにしましょう。

「スコープ」の候補としては、全世界で1個、各言語で1個、各顧客で1個、各翻訳会社で1個、各翻訳者で1個、各プロダクトで1個、各マニュアルで1個、各ファイルで1個、などがあり得ます。

現実的には TRADOS のデータベースは現状の Edition3 ではスケーラビリティに乏しいので、プロダクトで1個にまとめるのが適当だと思います。リサイクル効果の高いメモリは世界全体にあまなく均一分布しているのではなく、特定の条件を満たす部分集合に高い密度で偏在するというのは経験則として確実に正しいので、データベースのパフォーマンスにかなり厳しい制限がある現状から言って、スコープをうまく見極めて設定することがメモリ翻訳の成功度を左右するでしょう。

しかし、データベースのパフォーマンスは今後継続的に改善されていきます。その進歩に合わせて、おそらく3~5年の周期で、翻訳の現実的な最適ワークフローを継続的に見直すのが妥当だと思います。新規マニュアルに対して当てる旧訳の「素材」の組み合わせ方は何通りでも可能ですから、膨大な計算量をいとわないのであれば、将来的に処理が自動化されて、最適な翻訳メモリ スコープの提案をソフトウェアが行うことも可能になるでしょう。しかし当面は、翻訳メモリ マネージャーが経験と直感を頼りにスコープを決定するという状況が続くと思います。

(2000年9月4日執筆)

利用上の注意:このホームページは執筆当時(1999-2000年)の状況について述べており、すでにかなりの記述が「時代遅れ」となっていますが、原則として当時のままの内容を修正せずに公開しています。ご注意ください。