フロムデプロ

株式会社デプロは、自社の翻訳サービスに関わるワークフローがガイドラインに即しているかを審査いただき、お客様の期待に沿えるサービスを提供することを目的に2016年7月に翻訳に関する国際規格ISO17100の認証を取得いたしました。その後、毎年の維持審査、ならびに2回の更新審査を経て運用を進めてまいりました。その間、特筆すべき改善事項や是正措置をいただくことはありませんでしたが、審査員の方との対話を通してさらなる改善のヒントをいただいたり、業界の状況や規格自体の変更点などを教えていただいたりする中で、社内のフローをさらに改善してまいりました。
ただ昨今、MT、AIの台頭により、取得当初とは案件自体の質が変わり、お客様の求める基準も変化してきております。
また、社内ではこの規格の目的、意義、この規格に基づくワークフローが各担当者に十分浸透したことを受け、2026年４月をもちまして、認証を返上することといたしました。今後も約10年にわたる規格認証の実績を活かし、お客様のプロジェクトをさらなる成功へと押し上げるための要素を組み入れていきたいと考えております。

なお返上の決定に至った経緯については、以下をご確認ください。
ISO17100返上に至る経緯

皆さんはTradosのエディターで翻訳する際、書式タグの表示はどのように設定していますか？
「表示」タブの「オプション」セクションにある以下の部分で設定でき、「タグ テキストなし」、「部分的なタグのテキスト」、「完全なタグのテキスト」、「タグID」があります。

翻訳時には、「部分的なタグのテキスト」または「完全なタグのテキスト」に設定し、書式タグがboldなのか、italicなのか、または参照タグなのかを確認しながら翻訳すると便利です。

ただし、見直し段階では、「タグID」表示を使用し、原文とタグのID番号を一致させることを推奨します。
このタグID番号は、文書内の各タグのペアとプレースホルダタグに自動的に割り当てられる一意の識別子です。この表示方法では、一見書式タグの種類は把握できませんが、タグの上にカーソルを合わせると、以下のようにタグの内容がツールチップに表示されます。

なぜ「タグID」の表示を推奨するかというと、タグIDが原文と一致しない状態で訳文を翻訳メモリ（TM）に登録すると、次回のTM更新のタイミングでタグそのものの情報がTMから抜け落ちてしまうからです。

実験してみましょう。

サンプルテキスト
Double-click the Search icon to open the Search Files dialog box. Then, enter “AAA” in the Search Files dialog box.

をTradosで翻訳してみましょう。
「完全なタグのテキスト」を選択すると、boldタグはすべて<cf bold=True>と表示されます。

これを「タグID」の表示にすると、それぞれ5や11、29のようなID番号で表示されます。

空のTMを作成し、太字の箇所はすべて同じboldタグなので、ID番号5のタグをコピーして翻訳してみます。

5のタグにカーソルを合わせると、ツールチップに<cf bold=True>と表示され、タグの内容を把握できます。

では、同じTMで少し異なるサンプルテキストを翻訳してみます。

Double-click the Search icon to open the Advanced Search dialog box. Then, enter “AAA” in the Advanced Search dialog box.

この段階では、2文目のSearch FilesからAdvanced Searchに原文が変わった箇所のboldタグは、タグID番号が異なっていても同じboldタグと判断され、TMからタグのついた訳文を取得できます。「Advanced Search」に合わせて翻訳を変更し、タグID番号はズレたままで確定します。

訳を追加したTMを使用し、新しいプロジェクトで下記のサンプルテキストを翻訳してみましょう。
Click the Search icon to open the Global Search dialog box. Then, enter “BBB” in the Global Search dialog box.

すると、1文目はタグのついたあいまい一致の訳文を取得できましたが、2文目のエントリでは、TM内の訳文からboldタグの情報が消えてしまいました。

このようなエントリが頻出すると、改めてタグを付ける作業が増え、作業効率が悪くなるほか、原文側ではタグの変化がないように見えるため、訳文にタグを付け忘れるミスにもつながります。
タグID番号が一致していなくても、Trados上の通常の検証機能ではエラーにはなりません。もちろん、タグの削除はエラーになるのでそこで気付くこともできますが、やはり余分な修正作業が増えてしまいます。デプロでは、納品時のTMの品質を維持するためにも、翻訳時には原文と訳文のタグIDを一致させることをお願いしております。

「繰り返し」とは、CATツールで最初に出てきたときは「新規」とカウントされるが、それ以降、反復して出現する場合に「繰り返し」という分類になるカテゴリのことを指します。この「繰り返し」の文の処理は厄介です。なぜかというと、ファイルが複数あり、複数の翻訳者が同時に作業する場合、別々に訳してしまうと同じ意味の違う訳が返ってきてしまう。さらに、お客様への見積もりで、複数ファイルすべてで一度に解析を行った場合、受注上は「繰り返し」は新規単価の約１０～２５％の単価（案件により異なります）であるにもかかわらず、翻訳者には「新規」としてカウントすることになってしまうからです。このような状況が起きないようにシングルソースで翻訳する（1つのファイルのみを翻訳して、複数の出力形態に展開する）というのが主流ですが、諸々の理由でソースがそろっていないケースも多々あるようです。

これを解決するために、TMをサーバー上に置いて作業者がシェアすればいいという考え方があります。でもその場合、最初に翻訳した人の訳を別の人が取得してしまうことになります。その訳がよくなかったら、どうでしょう。そこに引っ張られた全体の品質は下がり、誰かが気づいて直したとしても、またそこに不統一が発生します。できるだけ、翻訳単位の品質はひとつひとつしっかりと管理していきたい。

こういう場合、弊社では全ファイルに対し、この繰り返しの２回目以降に出現するところをCATツールのエディター上でロックします。ただし、CATツール上でそのツールの機能を使ってロックすることが出来ない場合もあります。ファイルのサイズが大きすぎる場合です。たとえば、最近弊社で扱った案件では、Trados上ですべてのファイルを一度に開き、Tradosの機能を使って２回目以降に出現するところにロックをかけるのは不可能でした。そのため、弊社のエンジニアが最初の１度だけを翻訳対象とし、２度目以降はTradosでLockをかけたように処理をしました。
ちなみにCATツール上でこの処理をする場合は、どのファイルにある1度目を翻訳対象とするか、という指定はできません。
でも弊社のやり方ではこのファイルを優先的に1度目としてほしい、という指定が可能です。結果、先にそのファイルだけを翻訳し、校正してしまえば、他のファイルにどんどん展開ができるのです。この処理により、不要な複数訳文の統一作業を避け、複数の翻訳者への新規での支払いも避けることができます。一貫性も保てます。

このスキルは弊社ではよく使用しています。
似たようなマニュアルを効率的に翻訳したい、コストも削減したい、品質も落としたくない、そのようにお考えの方は是非デプロにご相談ください。

MadCap Flareで作ったファイルセットがあって、これを翻訳したいのだけれど、どうしたらいいのでしょうか。

そんなお問い合わせを頂くことがあります。デプロでは過去15年にわたり、
MadCap Flareを使って作成されたソースファイルの翻訳フローについて、ナレッジを蓄積してきました。
ファイルセットを丸ごとお渡しいただければ、翻訳用ファイルセットの作成（必要な場合、設定のカスタマイズも含む）、翻訳、コンパイル、チェック、最終出力、アセットの管理まですべておまかせいただけます。

・MadCap Flareとは？
MadCap Flareはオーサリングツールのひとつで、xmlベースのシングルソースから複数のアウトプットを生成できるツールです。たとえば、PDFとHTMLの双方を出力したいとき、製品が複数ある場合、共通のファイルは共有し、製品固有のファイルは別々に処理して最終的に製品ごとのPDFやHTMLを出力したりできます。
翻訳する際には、翻訳対象のファイルをMadCap独自の設定を適用して、TradosなどのCATツールに読み込み、翻訳します。翻訳完了後、ターゲット言語でファイルをエクスポートし、MadCap Flareのファイルセットに戻し、コンパイルして出力します。イメージは以下のとおりです。ファイルセットの中に含まれている画像も翻訳します。画像キャプチャがある場合はローカライズ画像に置き換えて、大きさを整え、出力ファイルに含めます。英語のキャプチャ画像は日本語の画像と同じサイズとは限らないので、必要に応じてHTML上で調整します。

コンパイル段階では、弊社の経験豊富なエンジニアがファイルセットに含まれるCSSファイルなどを日本語環境に合わせて調整します。その後、コンパイルしてPDFの場合は、1ページずつ、OLHの場合は、HTMLを1ファイルずつ比べて、チェックを行います。

ここで、翻訳の段階で気を付けなければいけないこと、翻訳メモリに何らかのマーキングをいれておく必要が出てくると、翻訳のスタイルガイドに指示を加えたり、翻訳メモリにマーキングを追加します。CATツールでは処理できないものはCATツールからエクスポートしたターゲットファイルに処理を加えます。次回、同じところが発生すると思われる個所はスクリプト化しておきます。この処理により、MadCap Flareソースファイルが更新された場合、バージョンアップされた場合に効率よくファイル処理が出来ます。

・エンジニアコストの算出方法
デプロではMadCap Flareのプロジェクトをハンドリングする際のエンジニアリングコストは、出力ベースで以下のメトリックに従ってお見積もりしています。
PDF：40ページ/１時間
OLH：100トピック/1時間
CHM：デコンパイルしたHTMLの数により上記OLHのメトリック 100トピック/1時間

例：出力がPDF、CHM、OLHの3種類で
PDF（120ページ）、HTML（Online Help）（230ファイル）、CHM（デコンパイル後200ファイル）の場合

PDF出力：計5時間
日本語環境のセッティング 1時間
コンパイルチェック 120ページ /40＝3で3時間とカウント
最終出力 1時間

OLH出力：計4.5時間
日本語環境のセッティング 1時間
コンパイルチェック 230ページ /100＝2.3で2.5時間とカウント
最終出力 1時間

CHM出力：計4時間
日本語環境のセッティング 1時間
コンパイルチェック 200ページ /100＝2で2時間とカウント
最終出力 1時間

なお、翻訳メモリの適用、過去のファイルからのパーフェクトマッチ処理等は、エンジニアリングコストとは別に翻訳前のファイル処理として、プロジェクトファイル1ファイルに付き1時間分のコストがかかります。

・アセット管理
翻訳終了後は、翻訳メモリ、バイリンガルファイルに必要なマーキング、カテゴリを追加して次回の更新用のアセットを作成いたします。こちらは特別な処理がない限り、プロジェクト管理費に含まれます。

不明点がございましたら、どうかお気軽にお問い合わせください。

デプロではお客様のニーズに沿った機械翻訳（以下MT）への取り組みを行っております。
その取り組みの歴史は長く、2011年に弊社のクライアントの1つであるマルチリンガル・サービス・プロバイダー様からMTについてのトレーニングを受けたのが最初です。その時はまだ日本語に適用できるレベルではなかったのですが、Distanceという概念を教えていただきました。つまりMTでサジェストされた結果と最終のエディットの結果を比較し、そのDistanceを独自のアルゴリズムで計算して、あるしきい値以上であればそのプロジェクトはMTには向かない、という判定を行うということでした。同じアルゴリズムは使用できませんが、デプロでもクライアント様のほうで機械翻訳エンジンの適用を行った場合、差分を取って、どの程度の変更があったのかを確認し、あまりにもひどい場合は翻訳者にCompensationを行い、クライアント様へもクレームを出しています。

もう一つ、MTを使ったPremium（高）品質の翻訳案件とMTを使って早く、安く翻訳を行う案件では、初期工程は同じでもプロジェクトとしての質が全く異なるということです。この点をお客様ときちんと交渉することが大切ということでした。

2015年には、当時SDLで提供していたBeGlobalのサブスクリプションを開始しました。長年の友人であり、協力会社であるドイツのTranscript社からエンジニアを招き、実際のワークフローを確立するためのアドバイスをもらいました。
2016年、GoogleがNMTサービスを開始。機械翻訳の品質が一気に上がり、通常使用する分には、遜色のないくらいの品質が提供されるようになりました。

これを踏まえて2017年、実際にお客様に機械翻訳のサービスを提供し始めました。

2018年、プロの翻訳者を介さない「MT Adjusted」というサービスの提供を開始しました。
MT Adjustedサービスは通常のMT案件とは異なる考え方からはじまっています。多くの方はどのエンジンを使えば品質の良いサジェッションが出るのだろう、ということを気にされると思いますが、弊社では、サジェストされた翻訳そのものを評価するのではなく、サジェストされた翻訳をいかに各プロジェクトに合わせて置き換えることができるか、というところに重きを置きました。つまり出力品質自体は徐々に良くなっていくだろうから、出力されたものを加工する方に注力しよう、ということです。

翻訳をするときにスタイルや用語集を確認することが大変です。この部分を先にMTの出力に対し、処理してしまうんです。また、日本語の場合、タグによる分断のために訳語がおかしくなってしまいます。
以下の例をご覧ください。
Raw Output （MTエンジンから吐き出されたそのままの翻訳）

この1文が左のように2文に分かれてしまっています。

これをMT Adjustedで処理すると

ちゃんと1文で処理されます。この場合は”check”が「確認」でいいかどうか判断するだけです。OKな場合、Distanceはゼロです。

すべてを後処理で行うというわけではなく、先に用語集がある場合は、MTエンジンに登録してしまいます。たとえば、日本語の場合、User interfaceという言葉だけでもいく通りものいい方があります。ユーザ・インタフェース、ユーザ・インターフェイス、ユーザーインターフェイス、ユーザー インターフェイスなど。
MT処理のみでは、これらの用語は適当に出てきますが、スタイルはクライアント別に決まっているはずなので、MT Adjustedではこれを事前に入れ込んでしまうか、MTの出力後、パターン別に一気に置き換えます。
翻訳済みのUser Interfaceについては、UIのファイルとCATツールのタグ番号を照合して正しいUIに置き換えます。UIにすでに複数訳がある場合やタグでマーキングされていない場合などは、完璧に置き換え可能というわけにはいきませんが、上手くいかないところはその後のファイル処理担当者（翻訳者、またはMT処理担当者）が修正を行います。

同じエラーが頻出している場合は、そのエラーをエンジニアに報告し、次回の処理までに提案できる解決策がある場合は、その解決策をインプリします。以下のようなイメージです。

MT Adjusted処理した後は、クライアント様との事前交渉に沿って、最終品質を決めていきます。
たとえば、MT Adjusted処理後、
1） 翻訳者にFull Post Editを依頼し、最終品質はHuman Translationと同じPremium品質の翻訳をご提供する。
2） 「翻訳者ではない」担当者が確認を行い、最終納品まで持っていく。

上記２）の処理の弱点は、翻訳者を介していないため、「正確」ではありません。本来翻訳者がPost Editして間違ったMTのサジェッションを修正するステップをスキップしていますので、最終のアウトプットは「正確ではない」翻訳である可能性があります。

そのため、MT Adjustedのみの処理は以下の様な条件があてはまるお客様にお勧めしたいサービスです。
1． 大量のコンテンツをMT処理したいが、Raw MT（後処理を全くしないMT出力）よりもう少しいい品質が欲しい。
2． 日本語を読んで、おかしいと思ったときに読者は対応する英語のコンテンツを参照できる。
3． 品質よりもコストとスピードを重視する。
4． 一度MT Adjustedのみで処理を行ったプロジェクトを、Premium品質に戻すことは容易ではない。最初からHuman Translationで処理した場合よりもコストがかかる場合がある（実際にそうなったプロジェクトがありました）。

実際にMT Adjustedのみを採用されたクライアント様からは「非常に満足している」というコメントを頂いており、更新についても対応させていただいております。
またMT Adjusted処理後にPost Editに対応いただいた翻訳者様からは、「今まで処理した中で一番の品質」「生産性は確実に上がっており、処理単価に見合っている」「通常はMT案件は断っているが、このMTであれば、今後も受注したい」という声を頂いております。

ドキュメントがバージョンアップされたときはどうするのか、というご質問については、以下の図をご参照ください。

1度目にMT Adjusted処理したコンテンツは次回アップデートで英語が変わらない場合、そのまま前回の訳が適用されます。追加/変更があったコンテンツについてのみ、最初からMT Adjusted処理を行います。さらに、前回からMT Adjustedのシステムに追加されたエラーのFixは前回のコンテンツにも適用されます。そのため、バージョンアップを重ねるたびに品質が良くなっていきます。

機械翻訳については、色々な考え方があると思いますが、「機械翻訳後の出力をできるだけ良くする」ということよりも、むしろ「Post Editしやすいような機械翻訳の出力」を目指し、「後の出力を先にプログラムでEditしてしまおう」という考え方に基づくものです。ご興味がある方は是非一度ご相談ください。

Tradosのエディターで日本語の翻訳単位の最後に半角スペースがある場合、訳文生成やExportによってこのスペースがなくなってしまうことはあまり知られていないようです。

たとえば原文ファイル (word) に以下のようにコロンの後に半角スペースが入っている場合:

Tradosにファイルを入れると、以下のように半角スペースは見えなくなります。

これは、表示を

にしていた場合です。これをすべてのコンテンツを表示

にすると

それぞれの翻訳単位の後にスペースが非表示で存在することが分かります。

日本語でコロンを半角にして、その後に半角スペースを入れるスタイルの場合（Microsoftもこのスタイル）、日本語で訳すときにどう処理すればいいか。
単純に考えれば、スペースは非表示で残っているんだから、何もしなくてもいいのでは？と思いますよね。つまりAll Contents表示で

と処理する。ところが、これで訳文を生成（またはExport）すると、以下のように半角コロンの後のスペース（非表示部にあるスペース）は消えてしまうんです。

これについては、Trados2007の時代から翻訳単位の最後に入れた半角スペースは消える、と公式にSDLさん自身が認めていらっしゃいます。

SDL Trados Studio 2015 SR2で

*****************
Enhancements to processing white spaces when using Japanese as a target language. As a general rule and as before, a space at the end of the segment is removed. However, a space is added or kept after the following characters: single-byte colon, semi-colon, question mark or exclamation mark. Studio makes sure that the space between the segments is kept after these characters.
セグメントの末尾のスペースはこれまで通り削除されるが、半角コロン、セミコロン、疑問符、感嘆符が末尾にある場合は、1つスペースが追加／保持される。
*****************
ということなのですが、実際、プロジェクトを運用していく上では、以前と変わらず特別な処理が必要です。

そこで弊社では長年、このような場合は翻訳者様にお願いして末尾にスペースを入れて「●●」を追加するという処理をしてきました。つまり、
英語：

日本語：

でもこうすると非表示の半角スペースがあるのだから、●●のあとにスペースが残って生成後に●●を取った後はスペースが2つ重なりそうですよね。でも生成してみると以下のとおり、●●の後にはスペースは入っていません。

生成後のファイルで「●●」だけを削除すればOKです。
ではスペースを1つ入れて●●を入れなければどうなるか。つまり、
英語：

日本語：

です。生成してみると以下のとおり、スペースが1つちゃんと入っています。

これでよくない？って思われるかもしれませんが、実はこのスペース、TMでは保持されないんです。この翻訳単位を登録したTMをTMX形式でExportすると、スペースが登録されていません。

●●を付けたほうはスペースも登録されています。

ということで、やはり正解は
英語：

日本語：

です。

ちなみに、同じファイルに更新があった場合、Perfect Matchをかけると、末尾のスペースは以下のように保持されます。

でもTMには登録されていませんので、別の場所で100％マッチとなったところは、
TMから取得するとスペースが取れてしまいます。

TMに記号が入っているのを嫌がられるお客様もいらっしゃるのですが、このような事情によるものですので、ご理解いただければ幸いです。

日本語でのDTP（Desk Top Publishing）をご依頼いただく際、前もってお客様に決めていただきたいいくつかの必須項目がありますので、以下に例とともにまとめます。

• ① ソースファイルの有無。

PDFしかないのだけれど、というご相談をよく頂きます。PDFからでも同じ体裁のものを作成することは可能ですが、そのPDFの元となるソースファイルがあれば、コストを低く抑え、品質も良いものが作成できます。また翻訳ツールを使用して、翻訳を行うことで、バージョンアップ時のコスト削減にもつながります。

• ② ソースファイルがある場合は、アプリケーションとそのバージョン。
• ③ 用紙サイズ：原本はLetterサイズであるが、日本語版はA4にしてほしい。またはLetterのままでいい、など。

• ④ フォント：アルファベットと数字のフォントおよび日本語のフォント。
  複合フォントを使用する場合、フォントサイズの違いが出ることがあります。
  たとえば、アルファベットと数字に「Calibri」を、日本語に「メイリオ」を選択された場合、以下のようになります。

フォントサイズは同じ18ポイントですが、英語は小さく見えてしまい、バランスが悪くなります。
そのため、日本語のフォントサイズを下げるか、英語のフォントサイズを上げるか、で調整します。

バランスはよくなりますが、アプリケーションによってはこのフォントの調整は手作業になってしまいます。ソースファイルがWordやPPTXの場合です。前もって複合フォントを使用できる場合はドキュメントを通してそのフォントを使用します。

• ⑤ ジョブオプション：昨今、PDFの多くは印刷目的よりもWebからダウンロードするものが多いため、ファイルサイズは小さいほうが好まれます。ただ、中にある画像の解像度は上げたい。そのようなPDFの作成仕様をお客様の方でお持ちの場合、ご提供いただければ、一定の品質でPDFが作成できます。固有のものがない場合でも印刷するものなのか、Webに載せておくものなのか、など用途をお知らせいただければ既成の仕様で作成いたします。

• ⑥ イタリックの使用：日本語では通常イタリック（斜体）は使用しませんが、原文がイタリックになっている場合、日本語ではどうするか。翻訳中にタグを削除してしまえばいいのですが、CATツールを使用した場合、翻訳後のQAでタグ数の不一致となってしまうため、そのまま残しておいて欲しいというお客様が多いです。その場合DTPやコンパイル時にイタリックスタイルを削除したり、ボールドにしたりすることがあります。