2021 年にドイツの eコマース クライアントが Seahawk のところに来た。ブリーフはこう書かれていた：「WooCommerce ストアを英語、フランス語、ポーランド語で必要だ。3 月までに。」当時は 11 月。そして人間翻訳の予算は、率直に言って、間違った方向で野心的だった。Google Translate の API は以前何件かのプロジェクトで使っていたが、ボタンラベル以上のものに関しては、正直なところ出力は恥ずかしいものだった。だから探し始めた。
そこで DeepL を本格的に試してみた。開発者スレッドで何度か言及されているのを見かけていたが、真剣に受け止めていなかった。この 5 年間で一番大きな失敗だ。同じ商品説明を両方の API で実行してクライアントに並べて出力を見せたとき、勝負は決まった。ドイツのストアを 3 言語でクリスマス前に展開し、クライアントは 6 カ月後に Dutch を追加したが、全く問題なかった。このプロジェクトは今でも、API 統合がどのようなものか分かりやすく説明する際に指す案件だ。
このポストは、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カンパニーとは異なるレジスターを必要とします。クライアントが指摘する前に、翻訳文の中でこの違いに気づいたことがあります。
コミットする前にコストモデルを理解する
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に到達する前ではなく、その後でコンテンツをサニタイズする方法を学びました。
2つの統合パス：WordPressとカスタムビルド
WordPressサイト
WordPressの場合、私が使用した最も直接的なパスはWPML統合です。WPMLの翻訳管理モジュール内に、DeepLネイティブコネクターが組み込まれています。WPML設定内でDeepL APIキーを認証し、自動翻訳するコンテンツタイプを選択すれば、キューを処理します。魔法ではありません。人間によるレビューステップをワークフローに組み込む価値がありますが、300ページのサイトの場合、数週間を節約できます。
別の方法は、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 呼び出しを避けた経験があります。
基本的な 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' ``
シンプルです。本当のアーキテクチャの問題はキャッシングです。ページロードのたびに API を叩きたくありません。翻訳をデータベースまたはキャッシュレイヤー（Redis がうまくいきます。小規模なサイトなら簡単な JSON ファイルでもいい）に保存してください。ソースコンテンツが変わったときにキャッシュを無効化してください。それだけです。複雑さのほとんどは API 呼び出し自体ではなく、キャッシュの無効化ロジックにあります。
プレースホルダーと動的コンテンツの処理
これは Seahawk の開発者が SaaS プロジェクトで詰まりました。UI 文字列に {{user_name}} や {{count}} のような変数が含まれていました。それらを生のまま DeepL に送ると、変数名を翻訳することがあります。{{nombre_de_usuario}} がスペイン語の UI に入ってくるのは理想的ではありません。
修正方法：DeepL の XML 処理を使用して、送信前にプレースホルダーを無視タグでラップします。
`` <deepl:ignore>{{user_name}}</deepl:ignore> has {{count}} new messages. ``
リクエストパラメータで tag_handling=xml と ignore_tags=deepl:ignore を設定してください。API はこれらのタグ内のコンテンツを保持します。DeepL の API リファレンスに記載されていますが、最初の読み込みで見落としやすいです。私の SaaS プロジェクトでは約 3 時間のデバッグに費やしました。あなたはそうならないといいですね。
実用的なレビューワークフローを構築する
機械翻訳は公開ボタンではありません。特にカスタマー向けの内容については、DeepL の出力をネイティブスピーカーのレビューを経ずにライブサイトに直接公開することは決して推奨しません。ただし、ワークフロー自体が辛いものである必要はありません。
ほとんどのクライアントプロジェクトで設定しているのは以下の通りです：
- DeepL API を使用して初期翻訳を実行します。
- 出力をステージング翻訳テーブルにプッシュします（WPML では自動的に行われます。カスタムビルドでは
translationsDB テーブルに書き込み、status カラムをデフォルトでpendingにします）。 - クライアントの現地レビュアー（多くの場合、クライアント自身のローカルチームまたは ProZ からのフリーランサー）へリンクを送信します。
- レビュアーが CMS または私が構築したシンプルなレビューインターフェースで直接編集します。
- ステータスを
approvedにフリップして、コンテンツをライブにします。 - 文字列をロックして、次の API 同期で上書きされないようにします。
その最後のステップが重要です。ソース言語のコンテンツ更新が全体の再翻訳をトリガーして、人間による修正をすべて消してしまうというセットアップを見たことがあります。他に何かを構築する前に、ロックメカニズムを構築してください。
多言語サイトのSEO対策
翻訳されたコンテンツだけではランクされません。言語バリアントごとに HTML の <head> に hreflang タグが必要で、それらは正確である必要があります。hreflang の設定が一致していないと、実は国際的なページを検索結果から除外してしまう可能性があります。言語コード( fr-FR vs fr )を間違えたため、美しく翻訳されたフランス語サイトが4ヶ月間も目立たない状態にあったクライアントを見たことがあります。
hreflang の先へ：翻訳された URL です。理想的には、スラッグも翻訳したいです。/fr/how-to-cook-pasta ではなく /fr/comment-cuire-les-pates という形です。DeepL はスラッグを翻訳できますが、その後スラグフォーマッター（小文字、ハイフン、特殊文字を削除）を実行することをお勧めします。WPML はこれを自動で行います。カスタムビルドの場合は手動で処理してください。
そしてメタデータです。ページタイトル、メタディスクリプション、画像の alt テキスト。すべてが翻訳対応が必要です。私はメタデータを本文コンテンツのバッチの一部ではなく、パイプラインで別に DeepL を通します。その方が文字数制限を管理しやすいからです。
DeepL が不得意な領域
正直に言うと、ブランド特有の用語です。DeepL はクライアントが製品機能をどう呼んでいるかを知りません。フィンテックのクライアントが「Smart Vault」を製品名として使っていれば、DeepL はそれを翻訳します。毎回です。
その解決策は DeepL の用語集機能です。API 経由で用語ペア（ソース用語、ターゲット用語、言語ペア）を定義し、翻訳リクエストに用語集 ID を添付します。その Smart Vault はすべての言語で「Smart Vault」になります。これを指定したからです。用語集は DeepL のダッシュボード経由でプログラムで管理するか、手動で管理できます。私は今ではプロジェクトのキックオフの一部として用語集を設定します。20分で済み、レビューで何時間もかかるはずだった一連のエラーを防ぎます。
もう一つ正直な制限：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 で使用するのは、非常に特殊なアーキテクチャ上の理由がある場合のみです。
DeepLは人間翻訳と比べてどの程度正確ですか？
ヨーロッパ言語については、DeepL は BLEU スコアベンチマークで人間翻訳の数パーセント以内の精度を定期的に達成しています。実用的には：商品説明と UI 文字列には十分ですが、法務文書、クリエイティブコピー、あるいはトーンと文化的ニュアンスが全てという内容には不十分です。クライアントプロジェクトには常に人間レビューステップを組み込んでください。
DeepL翻訳はSEOに影響しますか？
レビューされていない機械翻訳コンテンツは、特に不自然な文体の場合、検索エンジンによって低品質としてフラグされる可能性があります。Google は自動翻訳コンテンツ自体にペナルティを与えないと述べていますが、薄いまたは不正確なコンテンツは低下します。私のルール：インデックス化後ではなく、インデックス化前にレビューしてください。
ソースコンテンツが変更される場合、翻訳更新の最良の方法は何ですか？
コンテンツハッシュ（ソース文字列の MD5 で十分）をデータベースの各翻訳と一緒に追跡してください。ソースコンテンツが更新されると、ハッシュが変わり、翻訳が古くなったとしてフラグされます。パイプラインはページ全体ではなく、変更された文字列のみを再翻訳します。これにより API コストが削減され、既に人間がレビューした文字列の不要な変動が防げます。
DeepL APIは、多言語プロジェクトの規模設定方法を本当の意味で変えた、そういうツールの一つです。人間の判断の必要性を排除するからではなく、退屈な初稿翻訳から意味のある編集レビューへと作業をシフトさせるからです。これは誰もの時間、そしてあなたのクライアントの予算のより良い活用です。慎重に接続し、積極的にキャッシュし、初日からレビュープロセスを組み込むなら、それはあなたにとってよく機能するでしょう。
DeepL APIは、多言語プロジェクトの規模設定方法を本当の意味で変えた、そういうツールの一つです。人間の判断の必要性を排除するからではなく、退屈な初稿翻訳から意味のある編集レビューへと作業をシフトさせるからです。これは誰もの時間、そしてあなたのクライアントの予算のより良い活用です。慎重に接続し、積極的にキャッシュし、初日からレビュープロセスを組み込むなら、それはあなたにとってよく機能するでしょう。
関連記事：2026年のAI検索キーワードリサーチ：その内容、従来型検索との違い、テクニカルSEO、およびAI検索。