先日の第4回もやもや会の続き記事です。
こちらもCHECK
-
-
【セミナー報告】2025/04/02（水）第 4 回 MTPE もやもや会 (オンサイト＆オンライン)
先日、「第4回 MTPE もやもや会」にて、現在公開に向けて開発中の「GreenT for Phrase」を用いた改善提案を発表しました。会場にお越しくださったみなさま、またオンラインでご視聴いただい ...
もやもや会の後で、当日の発表者3名（燃脇さん、山本さんと私新田）がオンラインで話し合う機会を持ちました。いただいたアンケート結果を見ながら意見交換をし、お互いに質問をしながら理解を深めました。気が付いたら、2時間ほど話し込んでいました。
そのときに話をした内容をレッドハットの燃脇さんにまとめていただきましたので、以下ご覧ください。
このまとめには相当な労力が必要だったと思います。燃脇さん、どうもありがとうございました！
＜目次＞
第４回 MTPE もやもや会アフタートークまとめ
第４回 MTPE もやもや会に登壇した３人が再び集まりアフタートークを実施しました。発表者の１人である燃脇が、その内容をまとめました。発言者の名前が明記されていない部分は、３人の発言内容を要約したものです。
第４回もやもや会
MTPE の壁を乗り越える：現場の課題とツールの活用
発表および登壇者：
Phrase での MTPE 効率化用の機械翻訳および QA 支援アプリの紹介
新田順也氏 (エヌ・アイ・ティー株式会社)
燃脇綾子 (レッドハット株式会社)
翻訳者が開発した医薬分野 AI 翻訳サイト LingaMed-αのご紹介
山本隆之氏 (合同会社クリニカルランゲージ)
－参加者の職業、所属先、翻訳の分野が多岐にわたっていました。
MT/AI や MTPE を取り上げると多様な意見や質問が集まりますが、MT/AI の品質は、分野だけでなく、どのコンテンツを訳し、どのエンジンを選び、どのように使用 (カスタマイズ) するかといったさまざまな要因によって決まるため、有効な方法を一概に示すことはできません。一見すると「MT の品質が悪い」原因と改善策が明確なように見えても、具体的なアドバイスを提示するのは簡単ではありません。ただ言えることは、翻訳者が対応可能な範囲には限りがあり、Red Hat のようなクライアント企業、もしくは企業から発注を受けた翻訳会社において、たとえば「CAT ツールで選択できる MT を利用する」以上の対応をするかどうかが重要になります。このように、MT/AI の品質が低い背景には、企業や翻訳会社の取り組みが十分ではない、またはコストをかける余裕がない可能性があります。
また翻訳者側の課題についても話をしました。翻訳者が一番気になる点としては、収入が減ることです。単純に言えば単価の下落です。ただし、留意すべき点としては、単価の下落が必ずしも収入減につながるとは限りません。クライアント企業もしくは翻訳会社が MT/AI の品質をきちんとコントロールし、たとえば翻訳者が無理なくスピードを上げられる場合は、単価が下がっても全体の収入減にはつながりません。実際、MTPE もくもく会では、課題に使用した MT の品質が高かったため「これなら単価が半分になっても受注する」という意見もありました。一方で、求められている以上の作業を行う、たとえば MTPE 作業であるにもかかわらず、本来求められていないレベルまで品質を追求してしまう「スキルの過剰提供」をしていることも課題として挙がりました。
－事前アンケートでは翻訳業務に MT や生成 AI を使っている人が多く、また、翻訳支援 (校正、用語集作成、スクリプト作成など) やその他の事務作業に生成 AI を活用している人も多く見られました。
MT/AI の活用、加えてリスク分散の観点から MTPE の案件を積極的に受け入れる動きが広がりつつあります。アンケートで、MTPE のデメリットとして売上の減少を指摘している方がいましたが、上述したように、状況の全体像を把握することは難しく、たとえば本人の適応の問題なのか、環境に起因するのか、原因を特定するのは容易ではありません。ただ、重要なのは、翻訳者が一方的に不利益を被らないための制度や体制を整備することです。企業、翻訳会社、翻訳者の間で十分な意思疎通がなされていない、または MT/AI を適切に活用・応用できる人が企業や翻訳会社に十分に確保されていないことも想定されます。これまでとは異なるアプローチを取り入れることで、品質向上につながる可能性もあるでしょう。クライアント企業や翻訳会社がより理解を深め、カスタマイズできるようになれば変化が期待できます。
翻訳者にとって AI を使う一番のメリットとしては「調べ物」が挙げられますが、今回は、プログラミング経験のある３名が集まっていたこともあり、特にプログラミングに関する話題で盛り上がりました。生成 AI を参考にする機会もあるため、全員が最近の、生成 AI によるプログラミングの精度や有効性について言及し、具体的な体験談として、単純なエラーメッセージから解決策を得られた事例が紹介されました。一方で、生成 AI によって誰もが容易にプログラミングできるようになるとは限りません。翻訳と同じように、便利なツールとして使用するには、生成 AI が出力した内容の正確性を判断する能力が必要になります。たとえば、調査の方向性を探る際や、記憶が曖昧な情報を確認する際に、生成 AI を活用しています。
事前アンケートに、スクリプト等で、自動的にチェックできる項目 (スタイルガイドに準拠しているか、校閲、用語集のチェック等) はすべてチェックしていると回答した方もおり、その方法について関心が寄せられ、実現手段についても議論が交わされました。
－事前アンケートに「MTPE ができる翻訳者は、単なる翻訳者より高いレベルが要求されると考えるかどうか」という質問がありました。
MTPE に対応できる翻訳者には、通常より高いスキルが求められると考えます。特にスピードが重視される場面では、特定分野のターゲット文書への深い理解が重要です。MT/AI があらゆる作業を担えるわけではないので、専用エンジンを使用し、翻訳者も専門性を持っていることが理想です。少なくとも、翻訳者の負担が増えないように (企業や) 翻訳会社が積極的に取り組むべきだとは思いますが、実際の進捗状況は、企業・翻訳会社ごとに大きく異なるのが実情です。対応方法を外部に発信する企業・翻訳会社ばかりではないので実態はわかりません。また、翻訳会社が積極的に取り組むことが、翻訳会社自身や翻訳者にとって必ずしもメリットになるとは限らないため、翻訳会社のモチベーションとなるかもわかりません。ただ、翻訳会社を中心に、業界の構造は今後変わっていくことが予想されます。たとえば、短納期を実現するのに、MT/AI (既存サービスの活用) や MTPE (人的努力) だけでは十分とは言えません。翻訳業務や翻訳関連業務の効率化が、各社の競争力を左右するポイントとなるでしょう。また、将来的には、AI エージェントの活用が一般化する可能性もあります。たとえば、翻訳を行う AI エージェント、QC を行う AI エージェント、ネイティブチェックを行う AI エージェント、調べ物を行う AI エージェントです。いかなる立場であっても、今後も継続的な情報収集は欠かせません。
－イベント後アンケートで「３人が楽しんで MT の可能性を広げる取り組みをし、成果を得られている様子にワクワクした」という意見が出ました。
(燃脇) これは私自身も登壇者の１人として強く共感しました。全員が現在の状況やその限界を、共通した視点で理解しており、現時点で何が可能か、今後どのような展開があるのかを前向きに捉えているように感じました。イベント後アンケートで、山本さんがプログラミングを学び AI 翻訳サイトを構築したことを賞賛するものがありましたが、内容もさることながら、その取り組み姿勢に深く感銘を受けました。実際に構築された翻訳サイトも完成度が高く、非常に優れたものでした。さらにはこの話を山本さんにした時に「今後は生成 AI 翻訳以外の分野にも取り組みたい」と話していたのが印象に残りました。新田さんは、弊社の課題に短期間でソリューションを提案してくださり、それに対する弊社の厳しいフィードバックにも明るく次々と対応してくださり、大変信頼できる存在だと感じました。さまざまな業種・企業の話を聞く機会がある新田さんのお話 (注記: 個別の企業や特定の資料についてではなく、たとえば希望するタグの処理方法が企業によって異なるといった事例を、守秘義務に抵触しない形で共有しました (新田)) は、弊社としても非常に勉強になりました。
MT/AI や MTPE についてはこれまでも発表されている方がたくさんいますが、取り組みの有無によって、発信内容に偏りが見受けられます。現在 MTPE に取り組んでいるか否かにかかわらず、現状を把握し、ご自身の方向性を見極めるうえでも、取り組みを実践している方々の声に耳を傾けることがますます重要になるでしょう。今後さらに、実践と発信を両立されている方々の登壇機会が増えることを期待しています。
－その他、以下のような質問が挙がりました。
山本さんへ。API の費用はどれくらいかかりましたか。
それほどではない。Google は小規模ならかからない。Google 翻訳のカスタムモデルは翻訳自体の費用とトレーニングにも費用がかかる。以前 15,000 対訳でトレーニングしたときは 15,000 円くらい (和訳・英訳別個にトレーニングが必要)。今は円安のため値上がりしている可能性あり。Google Cloud は、規模にもよるが、ごく小規模であれば月額数千円 ~ 1 万円くらいではないか？詳細は Google のドキュメントを参照してほしい。
新田さんへ。日英の QA チェックの工夫はありますか。
GreenT for Phrase では、英日翻訳でも日英翻訳でも、原文と訳文の双方向でチェックをしている。具体例として、原文にある数字が訳文に存在するのか、そして訳文にある数字が原文に存在するのかを確認している。これに加え、和文中の英字が英文中に存在するかも確認している。
よって、翻訳方向によるチェック内容の差はない。原文と訳文の表記のパターンをみつけて、どう対応するかを決めている。想定外の表記パターンがある場合に、原文と訳文の等価な表記を比較する手順を追加している。今回の Red Hat とのプロジェクトにおいても、私が想定していなかった表記があり、対応できるように工夫をした。
新田さんへ。タグの近くに [] が入るのと [] が入らないのは翻訳ツールが異なるからですか。
これは今回のプロジェクトで使用した機械翻訳エンジンの出力に原因がある。機械翻訳の仕組みはまだブラックボックスである。今回も、タグ内に [] が入る場合と入らない場合があった。
Web 上の無料の DeepL や Google 翻訳でも訳文の変化の度合いを体験できる。同じ翻訳エンジンに対して同じような原文 (記号が一部違う、大文字小文字が違うなど) を入力すると、出力される文が少し変化することがある。これと同じ現象が起きており、原文の何かしらの記述が原因になり出力に変化が出たと思われる。
以下、私が 2020 年 12 月に書いた記事だが、現在も同じような傾向が見られる。
【機械翻訳】愚直なGoogle翻訳と考えすぎなDeepL翻訳
新田さんへ。スピードは生成 AI でも現状遅いですが、今後解決されていくのでしょうか。
現状、GreenT の翻訳はそれほど速くない。1 セグメントに対して 2 秒程度かかる。原因は、1 セグメントずつを翻訳していることだと思う。DeepL や Google 翻訳の API にデータを送信して受信する際に時間がかかるが、1 セグメントずつその送受信に時間をかけて処理をしている。
タグの翻訳やタームベースの適用など、細かな前処理と後処理をしているため、現在は 1 セグメントずつ細かく処理している。安定した処理フローを構築できたのちに、複数のセグメントを同時にデータ送受信をして翻訳できれば、ボトルネックになっているデータ送受信の時間を減らせるので理論上は処理速度が向上すると考えている。
生成 AI による翻訳も今後は速くなっていくだろうと考えている。
イベント後アンケートより。新田さんへ。GreenT for Phrase の話は大変興味深いですが、Phrase 側をフリーランス翻訳者がいじれないのが難点です。
現状は企業向けとして開発をしている。GreenT for Phrase は Phrase の API にアクセスをしているため、翻訳者がこの仕組みを使う場合は、データの保有者である翻訳会社やソースクライアントからの許可が必要になるのではないかと考えている。
私も、アンケートにコメントをいただいた通り、フリーランス翻訳者の方が自分にあうようにツールをカスタマイズできるのが好ましいと考えているので、今後できるようにしたいと思う。特に、生成 AI を使った翻訳では、翻訳者が自分独自のプロンプトで出力される訳文をコントロールしたほうがいい場合もあると思う。そのような役割分担を実現できるように企業クライアントに話をしていくつもり。
３人へ。ユーザーやクライアントの求めているものに対するソリューションを翻訳会社で提供できるようになると翻訳業界全体としてより良いものになると思います。
従来のビジネスモデルは、今後徐々に成立しにくくなる可能性がある。今後、フリーランスがクライアント企業と直接取引するケースが増え、中間業者としての機能を十分に果たせていない翻訳会社は選ばれにくくなると予想される。ただし、企業によってはフリーランスへの発注をポリシーで制限している場合もある。こうした状況の中で、業界構造や取引の在り方がどのように変わっていくのか、引き続き注視していきたい。
