ウェブサイト翻訳のための DeepL API：実践ガイド

2021 年にドイツの eコマースクライアントが Seahawk のところに来た。ブリーフはこう書かれていた：「WooCommerce ストアを英語、フランス語、ポーランド語で必要だ。3 月までに。」当時は 11 月。そして人間翻訳の予算は、率直に言って、間違った方向で野心的だった。Google Translate の API は以前何件かのプロジェクトで使っていたが、ボタンラベル以上のものに関しては、正直なところ出力は恥ずかしいものだった。だから探し始めた。

そこで DeepL を本格的に試してみた。開発者スレッドで何度か言及されているのを見かけていたが、真剣に受け止めていなかった。この 5 年間で一番大きな失敗だ。同じ商品説明を両方の API で実行してクライアントに並べて出力を見せたとき、勝負は決まった。ドイツのストアを 3 言語でクリスマス前に展開し、クライアントは 6 カ月後に Dutch を追加したが、全く問題なかった。このプロジェクトは今でも、API 統合がどのようなものか分かりやすく説明する際に指す案件だ。DeepL. I'd seen it mentioned in a few developer threads but hadn't taken it seriously. Biggest mistake I made in that half-decade. Once I ran the same product descriptions through both APIs and showed the client side-by-side output, there was no contest. We shipped the German store in three languages before Christmas, the client added Dutch six months later without breaking a sweat, and that project is still one I point to when people ask what good API integration looks like.

このポストは、DeepL をウェブサイトに組み込む実践的な現実についての内容だ。マーケティングコピーではなく。実装の決定、コストモデル、落とし穴、そして始める前に過去の自分に何を伝えるかについてだ。

DeepL が実際に競合他社を上回る理由

ぶっちゃけ言うと、ヨーロッパ言語に関しては DeepL は別格だ。このモデルは Europarl コーパスと他の高品質な並列テキストで大量に学習させられており、それはドイツ語、フランス語、スペイン語、イタリア語、オランダ語、ポーランド語、ポルトガル語の出力で即座に感じられる。文構造が単語を入れ替えたというより、考慮されたものとして感じられる。

Google TranslateのAPI（v2およびv3）はより安価で、より多くの言語に対応しています。2024年中盤時点で、133言語対DeepLの29言語です。スワヒリ語やベンガル語が必要な場合、DeepLは選択肢ではありません。話は終わりです。ただし、クライアントがEU全域または日本に拡大しているのであれば（DeepLは日本語の翻訳が優れています）、習慣でGoogleをデフォルトにすることはクライアントの損失になります。

誰もあまり話さないもう一つのポイント：DeepLの形式度パラメータです。formality=moreまたはformality=lessを設定できれば、APIは出力の言語レジスターを相応に調整します。これはドイツ語では非常に重要です。du/Sieは単なるスタイルの選択ではありません。DTCファッションブランドはB2B SaaSカンパニーとは異なるレジスターを必要とします。クライアントが指摘する前に、翻訳文の中でこの違いに気づいたことがあります。formality parameter. You can set formality=more or formality=less and the API will adjust the register of the output accordingly. That matters enormously for German, where du/Sie isn't a minor stylistic choice. A DTC fashion brand wants a different register than a B2B SaaS company. I've had clients notice this distinction in their translated copy without me even pointing it out.

コミットする前にコストモデルを理解する

DeepLは翻訳文字数に応じて課金されます。無料APIプラン（DeepL API Free）は月間500,000文字を提供します。800製品の長い説明文を持つWooCommerceカタログを翻訳するまでは、かなり多いように聞こえます。

Proプランは月額約$6.99で500,000文字から始まり、そこからスケールします。私が運営するほとんどのエージェンシープロジェクトでは、カタログサイズと更新頻度に応じて月額15～60ドルの間のコストになります。プロの人間による翻訳料金（英国市場では通常1単語あたり£0.10～£0.18）と比較すると、APIは最初の200単語以内で元が取れます。

初期段階で私を苦しめた一つのこと：HTMLの処理です。DeepLは生のHTMLを受け取り、それを翻訳する代わりにタグを保持しようとします。リクエストにtag_handling=htmlを渡します。ただし、HTMLが不正形式であるか、製品説明にインラインスクリプトが含まれている場合（一部のWooCommerceプラグインを見ていますが）、出力が破損する可能性があります。APIに到達する前ではなく、その後でコンテンツをサニタイズする方法を学びました。HTML handling. DeepL can receive raw HTML and will attempt to preserve tags rather than translate them. You pass tag_handling=html in your request. But if your HTML is malformed or your product descriptions contain inline scripts (looking at you, some WooCommerce plugins), the output can get mangled. I learned to sanitise content before it hits the API, not after.

2つの統合パス：WordPressとカスタムビルド

WordPressサイト

WordPressの場合、私が使用した最も直接的なパスはWPML統合です。WPMLの翻訳管理モジュール内に、DeepLネイティブコネクターが組み込まれています。WPML設定内でDeepL APIキーを認証し、自動翻訳するコンテンツタイプを選択すれば、キューを処理します。魔法ではありません。人間によるレビューステップをワークフローに組み込む価値がありますが、300ページのサイトの場合、数週間を節約できます。WPML integration. WPML has a native DeepL connector built into their Translation Management module. You authorise your DeepL API key inside WPML's settings, select which content types to auto-translate, and it handles the queue. It's not magic, a human review step is still worth building into the workflow, but for a 300-page site it saves weeks.

別の方法は、DeepLアドオン付きのPolylang Proです。ライセンス料は若干安く、翻訳管理側はやや洗練されていません。昨年、フレンチレストラングループサイトでPolyglangを使用しました。その規模では問題ありません。ただし、カスタム投稿タイプとACFフィールドを含むものについては、WPMLは私の経験ではエッジケースをより良く処理します。

headless WordPress（Gatsby や Next.js のフロントエンドで GraphQL 経由で WP から取得）を構築している場合、DeepL API をビルドパイプラインやサーバーレス関数から直接呼び出したいところです。そのアーキテクチャではプラグイン経由でこじつけようとしないでください。スケーリングがきれいに進みません。

カスタム / WordPress 以外のビルド

ここからが興味深いところです。DeepL は Python、Node.js、PHP、Ruby、.NET、Java の公式クライアントライブラリを公開しています。Node.js ライブラリは堅牢です。Next.js プロジェクトで Redis に翻訳をキャッシュして、繰り返される文字列の冗長な API 呼び出しを避けた経験があります。official client libraries for Python, Node.js, PHP, Ruby.NET, and Java. The Node.js library is solid. I've used it on a Next.js project where we cached translations in Redis to avoid redundant API calls on repeated strings.

基本的な Node.js の呼び出しは次のようになります：

`` const deepl = require('deepl-node'); const translator = new deepl.Translator('YOUR_AUTH_KEY'); const result = await translator.translateText('Hello, world', null, 'fr'); console.log(result.text); // 'Bonjour le monde' `` const deepl = require('deepl-node'); const translator = new deepl.Translator('YOUR_AUTH_KEY'); const result = await translator.translateText('Hello, world', null, 'fr'); console.log(result.text); // 'Bonjour le monde' ``

シンプルです。本当のアーキテクチャの問題はキャッシングです。ページロードのたびに API を叩きたくありません。翻訳をデータベースまたはキャッシュレイヤー（Redis がうまくいきます。小規模なサイトなら簡単な JSON ファイルでもいい）に保存してください。ソースコンテンツが変わったときにキャッシュを無効化してください。それだけです。複雑さのほとんどは API 呼び出し自体ではなく、キャッシュの無効化ロジックにあります。

プレースホルダーと動的コンテンツの処理

これは Seahawk の開発者が SaaS プロジェクトで詰まりました。UI 文字列に {{user_name}} や {{count}} のような変数が含まれていました。それらを生のまま DeepL に送ると、変数名を翻訳することがあります。{{nombre_de_usuario}} がスペイン語の UI に入ってくるのは理想的ではありません。{{user_name}} and {{count}}. Feed those raw to DeepL and it'll sometimes translate the variable names. Not ideal when {{nombre_de_usuario}} ends up in your Spanish UI.

修正方法：DeepL の XML 処理を使用して、送信前にプレースホルダーを無視タグでラップします。XML handling and wrap your placeholders in ignore tags before sending.

`` <deepl:ignore>{{user_name}}</deepl:ignore> has {{count}} new messages. `` <deepl:ignore>{{user_name}}</deepl:ignore> has {{count}} new messages. ``

リクエストパラメータで tag_handling=xml と ignore_tags=deepl:ignore を設定してください。API はこれらのタグ内のコンテンツを保持します。DeepL の API リファレンスに記載されていますが、最初の読み込みで見落としやすいです。私の SaaS プロジェクトでは約 3 時間のデバッグに費やしました。あなたはそうならないといいですね。tag_handling=xml and ignore_tags=deepl:ignore in your request parameters. The API preserves anything inside those tags. This is documented in DeepL's API reference but it's easy to miss on a first read. Cost me about three hours of debugging on that SaaS project. Hopefully it costs you none.

実用的なレビューワークフローを構築する

機械翻訳は公開ボタンではありません。特にカスタマー向けの内容については、DeepL の出力をネイティブスピーカーのレビューを経ずにライブサイトに直接公開することは決して推奨しません。ただし、ワークフロー自体が辛いものである必要はありません。

ほとんどのクライアントプロジェクトで設定しているのは以下の通りです：

DeepL API を使用して初期翻訳を実行します。
出力をステージング翻訳テーブルにプッシュします（WPML では自動的に行われます。カスタムビルドでは translations DB テーブルに書き込み、status カラムをデフォルトで pending にします）。translations DB table with a status column defaulting to pending).
クライアントの現地レビュアー（多くの場合、クライアント自身のローカルチームまたは ProZ からのフリーランサー）へリンクを送信します。ProZ).
レビュアーが CMS または私が構築したシンプルなレビューインターフェースで直接編集します。
ステータスを approved にフリップして、コンテンツをライブにします。approved, content goes live.
文字列をロックして、次の API 同期で上書きされないようにします。

その最後のステップが重要です。ソース言語のコンテンツ更新が全体の再翻訳をトリガーして、人間による修正をすべて消してしまうというセットアップを見たことがあります。他に何かを構築する前に、ロックメカニズムを構築してください。

多言語サイトのSEO対策

翻訳されたコンテンツだけではランクされません。言語バリアントごとに HTML の <head> に hreflang タグが必要で、それらは正確である必要があります。hreflang の設定が一致していないと、実は国際的なページを検索結果から除外してしまう可能性があります。言語コード( fr-FR vs fr )を間違えたため、美しく翻訳されたフランス語サイトが4ヶ月間も目立たない状態にあったクライアントを見たことがあります。hreflang tags in your HTML <head> for every language variant, and they need to be correct. A mismatched hreflang setup can actually suppress your international pages in search results. I've seen this happen to a client who had a beautiful translated French site sitting in obscurity for four months because someone got the language codes wrong ( fr-FR vs fr).

hreflang の先へ：翻訳された URL です。理想的には、スラッグも翻訳したいです。/fr/how-to-cook-pasta ではなく /fr/comment-cuire-les-pates という形です。DeepL はスラッグを翻訳できますが、その後スラグフォーマッター（小文字、ハイフン、特殊文字を削除）を実行することをお勧めします。WPML はこれを自動で行います。カスタムビルドの場合は手動で処理してください。/fr/how-to-cook-pasta but /fr/comment-cuire-les-pates. DeepL can translate slugs but you'll want to run them through a slug formatter afterwards (lowercase, hyphens, remove special characters). WPML does this automatically. In custom builds, handle it manually.

そしてメタデータです。ページタイトル、メタディスクリプション、画像の alt テキスト。すべてが翻訳対応が必要です。私はメタデータを本文コンテンツのバッチの一部ではなく、パイプラインで別に DeepL を通します。その方が文字数制限を管理しやすいからです。

DeepL が不得意な領域

正直に言うと、ブランド特有の用語です。DeepL はクライアントが製品機能をどう呼んでいるかを知りません。フィンテックのクライアントが「Smart Vault」を製品名として使っていれば、DeepL はそれを翻訳します。毎回です。

その解決策は DeepL の用語集機能です。API 経由で用語ペア（ソース用語、ターゲット用語、言語ペア）を定義し、翻訳リクエストに用語集 ID を添付します。その Smart Vault はすべての言語で「Smart Vault」になります。これを指定したからです。用語集は DeepL のダッシュボード経由でプログラムで管理するか、手動で管理できます。私は今ではプロジェクトのキックオフの一部として用語集を設定します。20分で済み、レビューで何時間もかかるはずだった一連のエラーを防ぎます。glossary feature. You define term pairs via the API (source term, target term, language pair) and attach the glossary ID to your translation requests. That Smart Vault becomes "Smart Vault" in every language because you've told it to. You can manage glossaries programmatically or via DeepL's dashboard. I set up glossaries as part of every project kickoff now. It takes 20 minutes and prevents a category of errors that would otherwise cost hours to catch in review.

もう一つ正直な制限：DeepL の言語カバレッジです。29言語は、クライアントがヨーロッパと東アジアを超えた野心を持っている場合、本当に制限的です。アラビア語が必要な場合、ハイブリッドアプローチを検討することになります：ヨーロッパの言語には DeepL、それ以外はすべて Google Cloud Translation または Microsoft Azure Translator を使い、言語ペアでルーティングする単一の内部 API レイヤーで統合します。一度構築するのは面倒です。メンテナンスはとても便利です。

FAQ

DeepL APIは無料で使用できますか？

月間50万文字の無料枠があり、テストと小規模プロジェクトには十分です。無料プランではクレジットカード登録が必要ですが、制限を超過するかアップグレードしない限り課金されません。実際のトラフィックやコンテンツ量がある本番サイトの場合、有料プランがほぼ必須です。Proプランは月額約6.99ドルからで、文字数使用量に応じてスケールします。

プラグインなしでDeepLをWordPressで使用できますか？

技術的には可能です。WordPress カスタムプラグインまたは functions.php から wp_remote_post() を使用して REST API を直接呼び出せます。ただし車輪の再発明を楽しまない限り、WPML や Polylang の統合は翻訳キュー、文字列同期、コンテンツロックを自動処理します。カスタム API ダイレクトを WordPress で使用するのは、非常に特殊なアーキテクチャ上の理由がある場合のみです。wp_remote_post(). But unless you enjoy reinventing wheels, the WPML or Polylang integrations handle the translation queue, string syncing, and content locking for you. I'd only go custom-API-direct in WordPress if you have a very specific architecture reason.

DeepL APIを使用したウェブサイト翻訳