PolyLingo と Polylang の違いとそれぞれを使うべきタイミング

ここにたどり着いたということは、おそらく次のどちらかの状況にいるでしょう。WordPress 内の Polylang に満足しているが、WordPress 以外のプロジェクトで同等のものがあるか気になっている、または WordPress から完全に移行し、多言語設定がどうなるかを調べている。

この記事はその両方の質問に直接答えます。各ツールが実際に何をするのか、どこに適しているのか、そしてどのように選べばよいのかを説明します。

Polylang とは（そして何ではないか）

Polylang は WordPress のプラグインです。WordPress エコシステムの中で最高の多言語プラグインの一つです。言語切替機能を管理し、投稿やページの翻訳版を作成でき、hreflang タグを扱い、WordPress ブロックエディターときれいに統合されます。WordPress サイトを運営しているなら、これは真剣にメンテナンスされているツールで、数百万のアクティブインストールがあるのも納得です。

制限は説明の中にあります：WordPress のプラグインであること。WordPress の外部から呼び出せる API はありません。JSON ロケールファイル、Markdown コンテンツファイル、Next.js プロジェクト内の HTML テンプレートの概念はありません。全てのモデルはコンテンツが WordPress のデータベースにあり、WordPress によってレンダリングされることを前提としています。

これは批判ではありません。単にツールの範囲です。

PolyLingo とは

PolyLingo は翻訳 API です。コンテンツ（プレーンテキスト、Markdown、JSON、HTML）を送ると、要求したすべての言語で翻訳版を一度のリクエストで返します。CMS やフレームワーク、デプロイ環境についての意見は持ちません。HTTP リクエストができる場所ならどこでも動作します。

コアの設計目標はフォーマットの保持です。ほとんどの翻訳 API は文単位で作られています：文字列を送ると文字列が返ってきます。このモデルはコンテンツに構造があるとすぐに破綻します。典型的な翻訳サービスに JSON ロケールファイルを貼り付けると、キー名が翻訳されたり、区切り文字が壊れたり、オブジェクトだったところが文章になったりします。PolyLingo は構造を触ってはいけないものとみなします。文字列の値だけが変わり、それ以外は送ったまま返ってきます。

具体例。これを送ると：

{"btn": {"save": "Save", "cancel": "Cancel"}}

文単位の翻訳者はこう返すかもしれません：

{"button": {"save": "Guardar", "cancel": "Cancelar"}}

キー btn が button に変わっています。これはアプリケーションを壊します。PolyLingo はこう返します：

{"btn": {"save": "Guardar", "cancel": "Cancelar"}}

キーはそのまま。値だけが翻訳されています。

同じ原則は Markdown（見出しは見出しのまま、コードブロックはそのまま、リンクの URL は変わらない）や HTML（タグや属性は保持され、テキストノードと適切な属性だけが翻訳される）にも適用されます。

実際の違い：範囲

簡単に言うと：

Polylang は WordPress 内の多言語コンテンツを管理します。 CMS のレイヤーです。どの投稿がどの英語投稿のスペイン語版かを管理し、言語切替を生成し、コンテンツ更新時に翻訳を同期させます。

PolyLingo は API を通じて構造化コンテンツを翻訳します。 翻訳のレイヤーです。コンテンツを渡すと翻訳を返します。その翻訳をどう使うかはあなた次第です。

隣接する問題を解決しているのであって、同じ問題ではありません。だから比較は「どちらが良いか」ではなく「どんな問題を抱えているか」です。

Polylang を使うべき時

サイトが WordPress 上で動いていて、WordPress に留まりたい
コンテンツ管理のワークフローが必要：編集者が言語版を切り替え、翻訳状況を追跡し、テーマに言語切替を入れる
開発者ではなく、UI ベースのソリューションが欲しい
WooCommerce を使っていて、WordPress 内で商品翻訳を管理したい

Polylang はこれらすべてに優れています。WordPress がスタックなら、適切なツールです。

PolyLingo を使うべき時

Next.js、Nuxt、SvelteKit、Astro、その他の非 WordPress フレームワークで構築している
ヘッドレス CMS（Contentful、Sanity、Prismic）を使い、公開時や webhook 経由でコンテンツを翻訳したい
JSON ロケールファイルにあるコンテンツをキー構造を壊さずに翻訳する必要がある
WordPress から移行中で、多言語ワークフローを引き継ぎたい
Markdown コンテンツ（ブログ投稿、ドキュメント、商品説明）があり、フォーマットを壊さずに翻訳版が欲しい
言語ごとに API を呼ぶのではなく、一度の API 呼び出しで複数言語に翻訳したい

PolyLingo の /translate エンドポイントは targets 配列を受け付けるので、一回のリクエストでサポートされている36言語すべてを返せます。10言語で出荷する必要があるロケールファイルなら、10回ではなく1回の API 呼び出しです。

WordPress からの移行は？

WordPress サイトをヘッドレスや静的セットアップに移す場合、Polylang のコンテンツは自動的にはついてきません。翻訳は WordPress の投稿メタデータとして保存されており、Markdown ファイルや JSON 構造にきれいにエクスポートされません。

多くのチームが取る実用的な方法：

WordPress コンテンツを Markdown または JSON にエクスポート（wordpress-export-to-markdown のようなツールが機械的な部分を処理）
PolyLingo を使ってエクスポートしたコンテンツをターゲット言語に翻訳
結果のファイルを新しいコンテンツ構造にソース言語と並べて保存

PolyLingo のバッチエンドポイント（POST /translate/batch）はまさにこれのために作られています。最大100件のコンテンツを一度のリクエストで送信でき、それぞれ異なるフォーマットで、同じターゲット言語セットを共有します。数百ページのサイト移行には最適なツールです。

並べてまとめ

	PolyLingo	Polylang
WordPress なしで動作	はい	いいえ
フォーマット保持（JSON、Markdown、HTML）	はい	WordPress コンテンツのみ
1リクエストで全言語対応	はい	いいえ
REST API アクセス	はい	いいえ
コンテンツ管理 UI	翻訳者 UI（ノーコード）	フル WordPress 管理画面
コンテンツフォーマット自動検出	はい	該当なし
RTL 言語サポート	はい	はい
利用量ベースの課金	はい	無料プラグイン / Polylang Pro 固定料金

短縮版

WordPress を使っていて WordPress に留まるなら：Polylang を使いましょう。環境に合わせて作られていて優れています。

WordPress 以外、WordPress から離れる、または WordPress でないものを作るなら：PolyLingo は API を通じて同じ構造化された多言語ワークフローを提供します。どんな技術でも使えます。

両方のツールは共存も可能です。あるチームはメインのマーケティングサイト（WordPress 上）に Polylang を使い、ドキュメントサイトやウェブアプリの UI 文字列、メールテンプレートには PolyLingo を使っています。ワークフローは同じで、スタックは異なっても構いません。

試してみる

PolyLingo の無料プランは月に100,000トークンを含みます。これは10言語で複数のブログ投稿、または36言語で中規模のロケールファイルに十分です。クレジットカードは不要です。

curl -sS -X POST "https://api.usepolylingo.com/v1/translate" \
  -H "Authorization: Bearer $POLYLINGO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "# Welcome\n\nTranslate **any format** without breaking the structure.",
    "format": "markdown",
    "targets": ["es", "fr", "de", "ja"]
  }'

無料で翻訳を始める

PolyLingoとPolylangの違いは何ですか？それぞれいつ使うべきか