「破壊的技術とは、それまでとは全く異なる価値観を市場にもたらすものである。一般に、破壊的な技術は、主流市場において既存の製品よりも性能が劣る。しかし、その技術には、少数の周辺顧客(一般に新規顧客)が価値を見出す別の特徴がある。破壊的技術に基づく製品は、一般に、より安価で、よりシンプルで、より小さく、そして多くの場合、より便利に使用できる。」C.クリステンセン『イノベーションのジレンマ』 DeepL（2023.1.4）による翻訳
“Disruptive technologies bring to a market a very different value proposition than had been available previously. Generally, disruptive technologies underperform established products in mainstream markets. But they have other features that a few fringe (and generally new) customers value. Products based on disruptive technologies are typically cheaper, simpler, smaller, and, frequently, more convenient to use.” Clayton M. Christensen, The Innocvagtor’s Dilemma, 1997
顧客は破壊的イノベーションを期待している
コロナ禍が長期化する中で、顧客企業はこれまで以上に翻訳業務のコストダウンに強い関心を寄せている。機械翻訳（MT）活用においても、まずはコストダウンに的を合わせた提案でないと土俵に上がれない。
ところが、NMTの登場でMTの翻訳性能が画期的に改善されたのにもかかわらず、闇雲にMTを導入しただけではコストダウン効果はがんばって30％、下手をすれば逆効果という経験をあちこちの翻訳業者（LSP）がするようになった。
それでは、と営業トークを「MTは実は納期短縮の画期的な手段です」に変えたところで、今度は闇雲にMTを導入しても品質要求を従来の人間翻訳（HT）と同じ水準に固定したままでは画期的な納期短縮は不可能だという現実をまたも思い知らされることになる。
つまりはこの数年間で、MTは重要な技術要素ではあってもただMTを採用しただけで自動的に破壊的イノベーションが実現されるわけではなく、この新技術を活かして使う「新しい翻訳サービス」のコンセプトが実は重要なのだということを皆わかってきたと思う。
それでは一体、どういうコンセプトで翻訳サービスを見直せばよいのか？
MTのフル活用を阻む三つの不具合
MTの出力に瑕疵が生じた場合、その原因はどこにあるのか？MTの品質要件として、一般には「流暢さ」（Fluency）と「正確さ」（Adequacy）の二点があげられるが、ここではさらに「表記の統一」（Consistency）を加えてMT品質の三要件とする。
MTの出力が翻訳として破綻している場合、これら三つの特性のすべてまたはいずれか一点で不具合が発生していると仮定する。裏返して言えば、これら三点で不具合を防ぐことができればMTの出力は破綻をまぬがれると想定する。
さらに、この論説では流暢さの不具合を「フルエンシー崩壊」略して「F崩壊」、正確さの不具合を「アデカシー事故」略して「A事故」、表記の不統一を「コンシステンシー不備」略して「C不備」と、それぞれ呼ぶことにする。
現時点のAI翻訳ではF崩壊やA事故はごく普通に発生するし、それをMT側のアルゴリズム等の改善で短期間に払拭できる見通しはたっていない。C不備の発生についても同様である。
MTPEと呼ばれる翻訳プロセスは、LSPがMT出力をPE（ポストエディット）してHT相当の翻訳品質まで仕上げて納品するサービスだと理解されているが、そこではリンギストが全文に目を通してF崩壊とA事故を検出して修正するとともにC不備をチェッカーがツール等で検出して修正している。C不備の検出と修正についてはQAツールや正規表現を駆使すれば少しは機械化できるものの、F崩壊とA事故の検出と修正については自動化の目処がたたず人手で行うしかない状況である。
それはそうだろう。F崩壊やA事故を自動的に検出して修正できるのであれば、とっくにそのアルゴリズムがMTサイドに組み込まれているはずである。（たとえばDeepLでは、それ以前のMTサービスと比較してF崩壊が減ったと多くの人が感じている）。GAFAが世界トップクラスの優秀なAI技術者を集めても自動化できていないからこそ、その「尻拭い」が人手のLSPに回ってくるわけである。
「ライトなポストエディットなので瑕疵は大目に見てください」という類の詭弁をいくら弄したところで（C不備ならともかく）F崩壊やA事故を起こしている訳文がそのままビジネスで通用するはずもない。AI翻訳が破壊的イノベーションとして大成するには、これらの不具合に本質的な対策を打つ必要がある。
MTの瑕疵に対処する三つの対策
原理的に考えれば不具合に対する対策は三つしかない。第一に不具合が発生しないように工程を改善すること、第二に発生した不具合が納品物に残らないように修正する後工程を設けること、第三にそれでも発生してしまう不具合品を「デグレード（難あり）品」として販売できるしくみを作ること、の三つである。
この三つの対策をMT出力の品質に適用してみると、MTの出力をPEするという方法が第二の対策（事後対応）であることはすぐわかる。しかし、第一の対策（発生予防）と第三の対策（要件緩和）はMTでいえば何に相当するのか？
この論説で提案したいのはまさにその二点、MTの瑕疵に対して発生予防ないし要件変更によって本質的に対策する方法である。
著者による翻訳を全力支援する
F崩壊の主な原因は原文のMT親和性の低さ、すなわちMT出力（訳文）でF崩壊を発生させやすいMT入力（原文）の特性にある。たとえば、くだけた表現や会話、修辞を駆使した文芸的コラムなどはMT親和性が低い。
文芸ならそれもありだが、ビジネス文書でMT親和性が低い場合はそもそも原文がビジネス文書として分かりにくい悪文なのかもしれない。そのため、F崩壊に対処するにはしばしば原文を修正することが合理的である。原文を修正できるのは著者だけであるから、F崩壊を発生段階で阻止する最適任者は著者である。
さらに、A事故の予防の最適任者もまた、能力的にもコスト的にも著者である。なぜなら、内容的には著者こそが最善のSME（=Subject Matter Expert＝その文書に書かれた内容に関する専門家）のはずだから。またコスト的には起きた不具合を改修するより不具合の発生を予防するほうが低コストで済むから。
F崩壊やA事故をLSPに修正させることはできるし、実際にこれまでのほとんどのMTPE工程ではそうしてきた。しかし、これらの作業をLSPに負担させたとたんに革新的な効率化は不可能になる。とにかくある工程に人手が一部でも組み込まれている限りはコストダウンや納期短縮は30%あたりが限界ではないかと感じている。
この瑕疵に発生予防の方法で対処するには、MTしてもF崩壊やA事故を起こさないような原文を著者に書いてもらうのが早い。そして著者が原文を修正するタイミングとしては、執筆内容に関する記憶がまだフレッシュな執筆時（同時翻訳）か、執筆直後（同日翻訳）が望ましいのはもちろんである。
読者による翻訳も全力支援する
日本取引所グループの山藤敦史氏は2019年11月19日に開催されたアジア太平洋機械翻訳協会主催のセミナーAAMT 2019,Tokyoで、海外投資家の4割程度が参考情報として機械翻訳技術を活用した汎用オンライン翻訳サービスを利用して日本の上場会社の開示資料を読んでいると述べた。
たとえMT出力にA事故が含まれる可能性があるとしても、この事例のように読者が投資の専門家としてSMEの役割を果たせるのであれば、A事故を含むMT出力をある程度は「脳内修正」して欲しい情報をそこから抽出できる可能性がある。
この他にも身近に見られるいくつかの読者翻訳の事例から学べるのは、一定の条件を満たす場合は読者もまた翻訳者としてF崩壊やA事故を修正する負荷を分担できる可能性があるということだ。
著者に加えて読者にも翻訳を分散できれば、それだけLSPの人手PEに依存する割合を減らすことができるから画期的な改善に近づく。
C不備を許容する余地を探る
C不備はFやAに悪影響を及ぼすわけではないので文書を読解する上での致命傷になることは考えにくいが、とにかく目立つのが問題である。言い回しの不統一や「である調とですます調の混在」などが頻発する翻訳には読者が不安を抱くようになる。
C不備の問題を解決するカギはデグレード（＝要件緩和）だろう。その翻訳の要件をまず検討し、導入予定のAI翻訳でその要件をクリアできそうか、もしクリアできない要件があればその要件は必須なのか、必須であればその統一を著者または読者に肩代わりさせることはできないか、と考えていく。
ですます調とである調の混在は許されるか？人名翻訳の不統一は許されるか？箇条書きの乱れは許されるか？等々…
また、これはCではないが、MTに限らずHTでも、たとえば固有名詞やソフトウェアの英文和訳におけるUIリソースの翻訳など、調べないと訳せないことがしばしばある。
これらは筆者やLSPであればきちんと調べて完成する必要があるが、読者が翻訳する場合、自分の利用目的に応じて適宜、C不備を無視したり固有名詞やUIを英語のままで残したり、というデグレード（要件緩和）を選択できる。
LSPを呪縛する「Cのジレンマ」
「MTPEだからコストも納期も30%ダウンね」という翻訳？業務を請け負ったLSPを待っているのは制限時間内でできるかぎりMTの瑕疵を潰していく「モグラ叩き型尻拭い」のタスクだが、ここにはひとつの罠がある。
前述したMT瑕疵の典型的な不具合パターン（F崩壊・A事故・C不備）のうち、訳文だけ読んでもすぐにバレるのがF崩壊とC不備であり、きちんと内容を理解したうえで原文とも照合しないと見逃しやすいのがA事故である。もちろん翻訳の納品物においてはいずれの不具合も原則として許されないが、F崩壊とC不備は最終読者でも（原文と照らし合わせることなく）訳文を読むだけですぐ不具合を検出できるので地雷化するリスクが低いといえる。対照的にA事故は、SME的な内容理解や原文との照合をしないと発覚しない分だけ地雷化しやすくたちが悪い。
LSPはF崩壊やC不備が納品後に必ず問題を招くことをわかっているから限られたPE時間のなかでF崩壊とC不備の修正を優先するが、時間もコストも30%削減されたツケが後回しされたA事故の検出と修正に回って来やすい。
本来は地雷化リスクの高いA事故をゼロにすることこそプロであるはずのLSPに期待されている役割だと思うが、LSPの現場におけるタスクプライオリティではそこが逆転してしまうのである。
特にCについては、そもそも不備があっても記載内容の本質的理解には大きな支障とならないことも多く、見栄えが悪いという理由で優先的に対処するというプライオリティ判断には、文書意味の伝達という翻訳本来の目的から考えればジレンマがある。
全体を俯瞰して翻訳回路を設計する
翻訳案件は組織の内外で日々発生している。ある翻訳案件が組織内外で通過する処理経路を、ここでは「翻訳回路」略して「T回路」と呼ぶことにする。
MT登場後は誰もがMTを使って著者または読者として翻訳する可能性が大幅に増したため、組織内外に張り巡らされるT回路のネットワークも以前と比べて格段に複雑化している。
このモデルでいえば、翻訳システムの設計者がはじめに行うべきことは、その組織におけるT回路をもれなく把握することである。
このとき、既存の翻訳外注に限らず組織内外に隠れたT回路まで列挙する必要がある。現状（As Is）のT回路の存在にとらわれすぎず、その組織が将来あるべき姿から、その組織の将来（ToBe）を支えるT回路を構想する視点が重要になる。
セルフ翻訳の支援環境を整備する
LSP（社内翻訳者含む）のPEを必要とするT回路については破壊的イノベーションを期待できないから、このT回路ネットワークの設計では「いかにしてT回路全体に占めるLSP依存T回路の割合を減らして著者翻訳ないし読者翻訳のT回路の割合を増やすか」という点がメインテーマになる。
著者翻訳でも読者翻訳でも放置して高い成果を得ることはできず、著者や読者を全力で支援できるようなツール環境の提供と動機づけの制度（＝教育と報奨）が必要だ。一般的には組織の内外で様々な抵抗を受けるためこの課題は簡単なものではないが、JTFジャーナル2020年5/6月号で紹介したジヤトコ株式会社のような成功例もあるので、信念と強運があれば実現は可能だと言える。
著者翻訳と読者翻訳を普及させるためにまず必要なことは、組織の状況にマッチした翻訳ツールを準備して著者・読者に提供することである。
著者に対しては「バイリンガルオーサリング」ができるツールを提供する。ただMTツールを提供するのと比較して、オーサリング機能をそなえたT環境（＝原文側のプリエディットやかな漢字変換のような英作文候補提示機能を備えた作業環境）が望ましい。DeepLがヒントになる。
読者に対しても、ただMTツールだけを提供せずに翻訳支援ツール（＝CAT/TMSツール）でくるんで提供することが生産性改善に寄与する。前述のジヤトコがJTFジャーナルで公開してくださったデータによると、翻訳ツールの導入にともない、レペティション効果（CATツールの導入）によって約2倍、レバレッジ効果（翻訳メモリの蓄積）によってさらに約2.4倍、ポストエディット効果（機械翻訳APIの導入）によってさらにさらに約1.3倍、それぞれ翻訳の生産性が向上したという。翻訳ツールの総合的な翻訳効率改善効果のうち、MTよりもむしろCATツールと翻訳メモリの寄与の比率が高いというのがこの事例のポイントである。
LSPはTMCへと進化する
MTをフル活用するためには以上で述べてきた業務改革が一定以上の規模のおそらくすべての組織で必要になる。
このような翻訳システムの革新を推進できる人材の必須条件は「翻訳をよく知っている」ことだ。ジヤトコの場合はすばらしい担当者が社内から得られたが、すべての組織でそのような幸運を期待するのは虫が良すぎるだろうから、次善の策として翻訳をよく知ったうえでこれからのMT活用推進をサポートしてくれる外部のプロフェッショナルを探すことになる。
そのようなプロフェッショナルを指し示す既存の用語が思いつかないので、ここでは暫定的にそれを「TMC」（翻訳マネジメントコンサルタント）と呼ぶことにする。TMCという呼称はロゼッタの五石代表が作った造語ではないかと思う。（五石さんが意図した職能とこの論説での定義がずれている可能性が高いがお許しください）
一昔前のLSPは営業せずに固定顧客から繰り返して翻訳業務を受けるか、少人数の営業が御用聞きに出て翻訳を請け負うという「受け身」のビジネスモデルだった。しかし、これからのMTを活用した翻訳ビジネスで生き残るには、新しい翻訳のしくみを顧客に提案し、実現していく積極的なビジネスモデルに脱皮する必要がある。
脱皮に成功したとき、そのLSPは従来型の翻訳会社から翻訳分野の業務改善コンサルタント（TMC）に進化しているはず、というのがこの論説で提案するLSPの未来である。
医療にたとえると、何かと注目されるAI翻訳のサービスはいわば市販薬（＝一般用医薬品＝医師による処方箋を必要とせずに購入できる医薬品）であり、手軽ではあるが患者の自己判断による我流の対応になるリスクがあるし各自の症状に合わせた個別対応もできない。対照的に医師が患者ひとりひとりを診て診断をくだし、処方薬を指示し、必要であれば手術を施すように、各組織の個別事情に合わせた翻訳システムを提案し導入支援し運用代行できるのが、これからのLSPに期待されるTMC的な役割ではないかと考える。
（初出『JTFジャーナル』#309 2020年9/10月号の記事をもとに編集しています）
