DeepL API の評価を支えているのは、何より訳文の自然さだ。とりわけ日本語と英語の間の翻訳では、直訳調に陥らず文意を汲んだ訳になるという声が多く、ビジネス文書や製品 UI の翻訳で「そのまま使える度合い」が他社より高いと感じる場面が多い。
単なる文字列翻訳を超える機能
テキスト翻訳だけでなく、PDF や DOCX、PPTX といったドキュメントをレイアウトを保ったまま丸ごと翻訳できる。さらに Glossary（用語集）で「この語はこう訳す」を固定でき、製品名や社内用語の訳ブレを抑えられる。フォーマル/カジュアルの文体指定もあり、対応言語では敬体・常体のトーンを揃えられる。
採用判断の分かれ目
無料枠は月あたりの文字数で区切られ、Pro は従量課金になる。コストは翻訳する文字量に素直に比例するので、ドキュメント一括翻訳を多用するなら量の見積もりが要る。判断のポイントは「対応言語の幅」と「訳質」のどちらを取るかだ。DeepL の対応言語は 30 言語超で、主要言語は厚いものの、マイナー言語を含む 100 言語以上を広くカバーしたい場合は Google 翻訳系に分がある。
Free と Pro でエンドポイントが分かれる
DeepL API は Free 版と Pro 版で接続先のホスト名が異なり、認証キーも別系統になる。Free で試作して Pro へ移行する際は、キーの差し替えだけでなくエンドポイントの切り替えも必要になる点を見落とさないようにしたい。また機械翻訳は文脈をまたいだ用語統一が苦手なため、製品ドキュメントのように一貫性が求められる翻訳では Glossary の整備が品質を左右する。
機密データの扱い
翻訳のために原文を外部 API へ送る以上、社外秘や個人情報を含むテキストをそのまま投げてよいかは事前に判断が要る。Pro 契約でのデータ取り扱い条件を確認し、機微な情報はマスキングしてから送るなどの運用ルールを決めておくと安全だ。日本語が絡む翻訳の品質がサービスの価値に直結するなら、DeepL を軸に据える判断は理にかなっている。
文字数課金という前提が設計を変える
DeepL のコストは翻訳した文字数にほぼ比例する。これは分かりやすい反面、設計を素直に組むと無駄が出やすい。同じ文言を画面表示のたびに翻訳し直す実装にすると、文字数がそのまま積み上がる。翻訳結果をキャッシュして再利用する、更新があった箇所だけ差分翻訳する、といった作り込みが、そのままコスト削減になる。
api-free.deepl.com と api.deepl.com でホスト名が分かれており、認証キーも別系統です。Free で作り込んでから Pro に移行するとき、キーだけ差し替えて接続先をそのままにすると認証エラーになります。接続先を設定値として外に出しておいてください。
用語集をいつ整備するか
Glossary は後から足すより、翻訳対象が固まった時点で先に作るほうが結果的に安い。製品名・機能名・社内用語を放置したまま大量翻訳すると、訳ブレが全体に散ってしまい、後から直すコストのほうが大きくなる。翻訳対象がドキュメントや UI のように「同じ語が何度も出てくる」性質なら、最初の数十語を登録するだけで品質が目に見えて安定する。