ブログに戻る
Split-screen flat illustration on a white background. Left side shows a simple document icon labeled “.txt” in muted blue-grey, producing a single output document tagged “EN.” Right side shows a JSON file with visible nested keys, connected to three separate document outputs labeled “EN,” “FR,” and “ES.” The right side uses teal and amber accents. A thin vertical line divides the two halves. Clean geometric style, minimal detail, no people or branding.

PolyLingo vs DeepL API:どちらがJSONとMarkdownをよりよく保持しますか?

By Robert M

PolyLingo vs DeepL API: どちらがJSONとMarkdownをよりよく保持するか?

DeepLは本当に優れた翻訳ソフトウェアを作っています。そのニューラル翻訳エンジンは利用可能な中で最高のものの一つと広く評価されており、普通の散文の翻訳ではなかなか敵いません。文や段落、連続したテキストとして書かれた文書を翻訳する場合、DeepLは強力な選択肢です。

この投稿が答える質問はより狭いものです:コンテンツに構造がある場合、DeepL APIはどのように機能するのでしょうか?キーに触れずにJSONのロケールファイルを翻訳したり、Markdownのブログ投稿を構文を壊さずに翻訳したり、HTMLページの属性を壊さずに翻訳したりする必要がある場合です。そして、その特定のユースケースにおいてPolyLingoと比べてどうでしょうか?


DeepL APIの構造

DeepLのテキスト翻訳APIはプレーンテキストを受け入れます。これがネイティブの入力形式です。各リクエストは最大50のテキスト文字列を受け入れ、それらは独立して翻訳され、間で共有コンテキストはありません。リクエストごとに指定できるターゲット言語は1つだけです。5言語必要なら5回リクエストします。

DeepLはPDF、Word、PowerPoint、HTMLなどのフォーマットのドキュメント翻訳もサポートしていますが、それは別のドキュメントエンドポイントを通じて異なるフローで行われます:ファイルをアップロードし、完了をポーリングし、結果をダウンロードします。これはオフィス文書向けに設計されており、プログラム的なコンテンツパイプライン向けではありません。

HTMLに特化しては、tag_handlingパラメータをhtmlに設定でき、DeepLに入力をHTMLとして扱いタグを保持しようと指示します。これは単純なマークアップにはかなりうまく機能しますが、設定を知っている必要があるオプションのフラグであり、JSONやMarkdownには拡張されません。

JSONについてはネイティブサポートはありません。DeepLのテキストエンドポイントはJSONキーが何かを知りません。シリアライズされたJSONオブジェクトを送ると、内容を文字列として翻訳し、キーや構造、非文字列の値が無傷で残る保証はありません。Markdownコンテンツ用にDeepLをラップするbabeldown Rライブラリは、DeepLがMarkdownリンクやフォーマット内の句読点を混同する事例を文書化しており、これは構造化テキストをプレーンテキスト翻訳エンジンに通す際の既知の制限です。

これはDeepLへの批判ではありません。APIが設計された目的の説明です。DeepLのコアユースケースは人間が読める散文の高品質翻訳です。そこに最適化されており、非常に優れています。


実際に差が現れる場面

コンテンツが単なる散文でない瞬間に違いが見えます。

標準的なNext.jsのロケールファイルを考えてみましょう:

{
  "nav": {
    "home": "Home",
    "about": "About us",
    "contact": "Get in touch"
  },
  "hero": {
    "title": "Welcome to our platform",
    "subtitle": "Everything you need in one place"
  }
}

これをDeepL APIで5言語に翻訳するには:

  1. 各文字列の値を個別に抽出する
  2. 言語ごとに別々にAPIリクエストを行う(5言語なら5回リクエスト)
  3. 翻訳された値を正しい場所に入れてJSON構造を再構築する
  4. 翻訳で句読点が変わったりJSONの有効性を壊す文字が入った場合に対処する これはかなりの量の接着コードになります。また脆弱です。翻訳結果がパーサーの期待と異なると、アプリケーションで静かな失敗や実行時エラーが発生します。

PolyLingoでは、オブジェクトをそのままformat: "json"で送信し、ターゲット言語ごとに完全な構造の翻訳版を1回のレスポンスで受け取ります。キーは触られません。ネストは保持されます。非文字列の値はそのままです。出力はそのままプロジェクトに投入できます。

curl -sS -X POST "https://api.usepolylingo.com/v1/translate" \
  -H "Authorization: Bearer $POLYLINGO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "{\"nav\":{\"home\":\"Home\",\"about\":\"About us\"}}",
    "format": "json",
    "targets": ["fr", "de", "es", "ja", "nl"]
  }'

1回のリクエスト。5言語。構造はそのまま。


Markdownコンテンツ

同じパターンはMarkdownにも当てはまります。DeepLのテキストエンドポイントはMarkdown構文の概念がありません。ブログ投稿を送ると全体を文字列として処理します。見出しは残るかもしれません。コードブロックはほぼ確実に残りません。中身は翻訳可能なテキストとして扱われる可能性が高いです。リンクの構文は特にリンクテキストの境界の句読点周りで壊れることがあります。

PolyLingoのmarkdownフォーマットフラグは、モデルにMarkdown構文を翻訳対象ではなく構造的なものとして扱うよう指示します。見出しは見出しのまま。フェンス付きコードブロックはそのまま。リンクのURLは変更されません。変わるのは散文の内容だけです。

ドキュメントサイトや技術的な内容のブログでは、この違いは重要です。チュートリアルのコードブロックが壊れるのは小さな見た目の問題ではなく、チュートリアルが壊れていることを意味します。


1リクエスト vs 言語ごと1リクエストの違い

これはコスト面の影響が大きいため注目に値します。

DeepLのAPIはリクエストごとに1つのターゲット言語しか受け付けません。10言語に翻訳するには10回APIコールをします。大規模サイトや頻繁に公開するCMSでは、リクエストのオーバーヘッドが10倍、管理すべきレイテンシも10倍、障害ポイントも10倍になります。

PolyLingoはターゲット言語コードの配列を受け取り、すべての翻訳を1つのレスポンスで返します。36言語は1リクエスト、36リクエストではありません。

小規模プロジェクトでは差は管理可能ですが、大規模になると翻訳パイプラインの構築アーキテクチャが変わります。


価格モデル

DeepLは文字数で課金します。APIの無料プランは月に最大500,000文字まで許可し、有料プランは文字数消費に基づいて請求します。言語ごとに1リクエストするため、コンテンツの文字数はターゲット言語数で掛けられ、別々のリクエストに分かれます。

PolyLingoはトークン単位で課金し、1リクエスト内のすべての言語の入力と出力の合計をカウントします。請求は透明で予測可能です:無料枠は月に50,000トークン、有料プランは600,000トークンで月9ドルから始まります。

2つのモデルは単語あたりのコストで直接比較できません。単位が異なるためですが、PolyLingoの全言語一括リクエストのアーキテクチャは、ターゲット言語数に比例してリクエスト数が増えることを防ぎます。


それぞれの適した用途

DeepL APIが適しているのは:

  • コンテンツが構造的要件のない単純な散文である場合

  • 人間が読めるテキストの翻訳品質が最優先の場合

  • 少数の言語に翻訳し、リクエスト量が少ない場合

  • すでにDeepLのエコシステムに投資していて、用語集やフォーマリティ機能を使っている場合

  • PolyLingoの現在の36言語外の言語サポートが必要な場合(DeepLは100以上の言語をサポート) PolyLingoが適しているのは:

  • コンテンツがJSON、Markdown、またはHTMLで構造を保持する必要がある場合

  • 1回のAPIコールで複数言語に翻訳する必要がある場合

  • CMS統合やi18nパイプラインを構築していてリクエスト効率が重要な場合

  • フォーマット固有の回避策なしで全コンテンツ形式に一貫したインターフェースを望む場合

  • 予測可能な月間付与のトークンベース課金を望む場合


並べてのまとめ

PolyLingoDeepL API
ネイティブJSONサポートはいいいえ
ネイティブMarkdownサポートはいいいえ
HTMLサポートはいはい(tag_handlingフラグ)
すべての言語を1リクエストではいいいえ、1リクエストにつき1言語
コンテンツ形式の自動検出はいいいえ
対応言語数36100以上
無料枠月50,000トークン月500,000文字
課金単位トークン文字
ノーコードWeb翻訳ツールはいはい(Webアプリ)

DeepLはより多くの言語カタログと散文翻訳品質の長い実績があります。PolyLingoはフォーマットの完全性が絶対条件の構造化コンテンツワークフロー向けに特化して作られています。

両者は隣接する問題を解決しています。適切な選択は実際のコンテンツの形状によります。


PolyLingoを試す

無料枠は月50,000トークンを含みます。クレジットカード不要。完全なAPIドキュメントはusepolylingo.com/docsにあります。

curl -sS -X POST "https://api.usepolylingo.com/v1/translate" \
  -H "Authorization: Bearer $POLYLINGO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "# Hello\n\nThis is **structured** content.",
    "format": "markdown",
    "targets": ["fr", "de", "es"]
  }'

APIキーを取得する