Polylang vs WPML vs TranslatePress: 2026年比較

多言語対応のWordPressサイトを構築しようとしています。Googleを開き、「WordPress 翻訳プラグイン おすすめ」と検索すると、10分もしないうちに、アフィリエイトレビュー、コピペされたような比較表、そしてPolylang、WPML、TranslatePressに関する矛盾したアドバイスの洪水に溺れてしまいます。どのレビューも都合よく「プラグインXが勝者」と結論付けられており、あなたのプロジェクトに実際にどれが適しているのか判断できません。

正直な答えを言えば、これら3つのプラグインは同じ表面的な問題（サイトを複数の言語で表示すること）を解決しますが、根本的に異なるアプローチを取っています。WPMLは翻訳を複製された投稿に保存します。Polylangも同様ですが、コアは無料で提供されています。TranslatePressはレンダリングされたHTMLをリアルタイムで翻訳します。それぞれのアーキテクチャには、パフォーマンス、SEO、コンテンツワークフロー、および長期的なメンテナンスにおいて実際のトレードオフがあります。

この比較では、アフィリエイトの喧騒を排し、2026年にあなたのサイトに実際に影響を与える詳細に焦点を当てます。今年の価格、各プラグインがCore Web Vitalsにどのように影響するか、プラグインを切り替えたときに何が壊れるか、そしてますます多くのチームがこれら3つのすべてをスキップし、.poファイルを直接翻訳している理由を明らかにします。

これらのプラグインが実際にすること（同じではありません）

機能を比較する前に、これらのプラグインが3つの異なるアーキテクチャを使用していることを理解する必要があります。誤ったアーキテクチャを選択すると、どれだけプラグインを設定しても救われることはありません。

WPML: 投稿複製モデル

WPMLは、すべての言語に対して、各投稿、ページ、タクソノミーターム、およびメニューアイテムの個別のコピーを作成します。postsテーブルは、言語の数に比例して増加します。500件の投稿と5つの言語を持つサイトでは、wp_postsに2,500行が生成され、それに加えて対応するpostmeta、term relationships、およびリビジョンも増加します。

これにより、クリーンなURL構造（/es/producto/、/fr/produit/）、ほとんどのプラグインとの完全な互換性、および言語ごとの独立した編集が可能になります。その代償は、データベースサイズとクエリの複雑さです。すべてのアーカイブクエリは言語でフィルタリングする必要があり、複雑なサイトでは10,000件以上の翻訳済み投稿がある場合、速度が低下し始めます。

Polylang: こちらも投稿複製モデル（無料コア付き）

PolylangはWPMLと同じ投稿複製アプローチを使用していますが、無料のコアプラグインと、プラグインの文字列翻訳やWooCommerceサポートなどの高度な機能用の有料Proアドオンが付属しています。内部的には、アーキテクチャはWPMLとほぼ同じであり、パフォーマンス特性とスケーリング動作も同様です。

TranslatePress: フロントエンドHTMLの書き換え

TranslatePressはまったく異なるアプローチを取ります。投稿を複製する代わりに、レンダリングされたHTMLをその場で翻訳します。フランス語でサイトにアクセスすると、TranslatePressが出力を傍受し、独自のテーブルで翻訳を検索し、応答をブラウザに送信する前に文字列を置き換えます。

これは、投稿を複製しないことを意味します。しかし、同時に、すべてのページレンダリングで翻訳された文字列を検索するための余分なクエリが実行されることも意味します。トラフィックの多いサイトでは、これは他のプラグインにはないパフォーマンス上の上限を生み出します。

価格とライセンスの内訳（2026年）

価格は事実確認が最も簡単であり、アフィリエイトレビューが正直であり続けることが最も難しい点です。以下は、各ベンダーのサイトで公開されている2026年の数字です。

比較表が通常隠しているいくつかのこと：

• 自動翻訳は追加費用がかかる。 WPMLのAdvanced Translation EditorはDeepLまたはGoogleを使用し、単語数で課金されます。PolylangはLingotekまたはDeepLと統合されており、こちらも単語数で課金されます。TranslatePressはライセンスとは別に「自動翻訳クレジット」を請求します。
• WooCommerceのサポートは制限されている。 PolylangはWooCommerceのためにBusinessティアが必要です。WPMLはMultilingual CMSティアが必要です。TranslatePress PersonalにはWooCommerceの文字列翻訳は含まれません。
• 更新価格が跳ね上がる。 一部のレビューでは初年度割引が引用されていますが、重要なのは複数年コストです。

これらの費用がフリーランサーの料金やクラウド翻訳に対してどのように積み重なるかの詳細については、WordPress翻訳費用比較をご覧ください。

パフォーマンスとサイト速度への影響

ここではアーキテクチャの違いが最も重要になります。Core Web VitalsはSEOに直接影響を与え、翻訳プラグインはLCPやINPスコアが低い隠れた原因の1つであることがよくあります。

WPMLとPolylang: データベースの負荷

両プラグインはほとんどのフロントエンドクエリに結合を追加します。WP_Queryは言語でフィルタリングする必要があるため、すべてのアーカイブページで余分なterm_taxonomyおよびterm_relationships結合が発生します。小規模サイトでは気づかないでしょうが、5つの言語で5,000件以上の投稿があるサイトでは、積極的なキャッシュなしではTTFBが200-500ms増加するのを目にするでしょう。

TranslatePress: リクエストごとの書き換え

TranslatePressは、レンダリングされるすべてのページで文字列検索を実行します。オブジェクトキャッシュを使用しても、プラグインはHTMLを傍受、解析、書き換え、再出力する必要があるため、サイトが応答できる速度に上限を設けます。当社の静的.moファイル対翻訳プラグインのベンチマークでこれを詳細に測定しましたが、フロントエンドの書き換えはすべてのテストシナリオで常に最も遅いアプローチとしてランク付けされました。

複合的な問題：プラグインスタック

翻訳プラグインを単独で実行することはめったにありません。WooCommerce、ページビルダー、SEOプラグイン、およびキャッシュレイヤーを追加すると、各翻訳プラグインには独自の互換性シムがあります。WPMLは何十ものプラグイン用アダプターを提供しています。Polylangはわずかに軽量です。TranslatePressは互換性のフットプリントが最も小さいですが、他のすべてのプラグインが完了した後にHTMLを書き換えるため、スタックの残りの部分からのキャッシュ最適化を無効にする可能性があります。

翻訳品質とワークフロー

自動翻訳の品質は、プラグイン自体ではなく、各プラグインが呼び出すエンジンに依存します。WPMLはDeepL、Google、またはMicrosoftを使用します。PolylangはDeepL、Google、またはLingotekを使用します。TranslatePressはDeepLまたはGoogleを使用します。

より重要なのは、翻訳がどのように提供され、保存されるかです。

• WPMLとPolylangは、翻訳を独自のテーブルに保存し、PHPから提供します。編集にはログインし、高度なエディタを開き、文字列ごとに保存する必要があります。
• TranslatePressはフロントエンドのビジュアルエディタを使用します。ページ上の文字列をクリックしてインラインで編集します。非技術系のユーザーには好評ですが、数百ページにはスケールしません。

これら3つのプラグインはいずれも、デフォルトではプレースホルダーやコードトークンを保護しません。文字列全体で自動翻訳を実行すると、生のAI翻訳を悩ませるのと同じ%sの破損、HTMLタグの崩壊、複数形のエラーが依然として発生します。WordPressにおける手動翻訳対AI翻訳に関する当社のガイドでは、安全性に関するトレードオフについて詳しく掘り下げています。

隠れた代替案：静的.moファイル（プラグインなし）

すべてのWordPressテーマとプラグインには、.potテンプレートファイルが付属しています。適切に翻訳された.poファイルを.moにコンパイルしてwp-content/languages/に配置すると、WordPressコアによってページロードごとに1回読み取られます。これには余分なデータベースクエリ、プラグインのオーバーヘッド、CDNの互換性もゼロです。

これは、WordPressコアコミュニティがWordPress自体を20年以上にわたって70以上の言語にローカライズしてきた方法です。高速で安定しており、どのベンダーのエコシステムにも縛られることはありません。

ほとんどのサイト所有者が代わりにプラグインを使用する唯一の理由は、.poファイルを手動で翻訳するのが面倒だからです。Poeditを開き、2,000の文字列を手作業で翻訳し、プレースホルダーを壊していないことを願うしかありません。クラウド翻訳ツールはその障壁を完全に排除します。.poをアップロードし、翻訳された.po + .moをダウンロードして、wp-content/languages/themes/your-theme-es_ES.moに配置すれば完了です。

プラグインライセンスは不要です。パフォーマンスのペナルティもありません。ベンダーロックインもありません。テーマが更新されて新しい文字列が追加された場合は、新しい.potを翻訳し、更新された.moファイルを再展開するだけです。

このアプローチは、コード内に存在するコンテンツ（テーマUI、プラグイン文字列、エラーメッセージ、ボタンラベル）に非常に有効です。データベース内に存在するコンテンツ（投稿、ページ、製品説明）については、依然としてプラグインまたは手動の投稿複製ワークフローが必要です。多くのチームは両方を組み合わせています。UIには静的.moファイル、コンテンツにはWPMLまたはPolylangを使用します。その結果は、単一のプラグインだけに頼るよりも、より高速で、安価で、保守しやすくなります。

どのアプローチを選択すべきか

プロジェクトタイプに基づくクイック決定ガイド：

• 小規模ブログ、2-3言語、主にUIコンテンツ: 静的.moファイル。プラグインは不要です。
• コンテンツ重視のサイト、編集チーム、多数の投稿: PolylangまたはWPML。無料の開始点と後でBusiness機能が必要な場合はPolylangを選択し、多言語カスタム投稿タイプとタクソノミーを大規模に展開する必要がある場合はWPMLを選択します。
• 非技術系ユーザー向けの視覚的編集ワークフロー: TranslatePress。ただし、パフォーマンスのトレードオフを受け入れ、トラフィックの多いWooCommerceストアでは避けてください。
• 大規模カタログのWooCommerceストア: WPML Multilingual CMSとテーマUI用の.moファイル。Polylang Businessも有効です。
• 20以上のクライアントサイトを管理するエージェンシー: 可能な限り多くの翻訳を.moファイルに移動します。完全なアーキテクチャについては、エージェンシー向けの理想的なローカライズワークフローをご覧ください。

まとめ

Polylang、WPML、TranslatePressはすべて正当なツールです。それぞれが、実際の多言語サイトを成功裏に提供している実際のユーザーを抱えています。間違いは、それらを互換性のある代替品として扱い、比較表に基づいて1つを選択することです。これらは根本的に異なるアーキテクチャであり、それぞれ異なるパフォーマンスの上限とコンテンツワークフローを持っています。

ほとんどのサイト所有者が決して問わないより深い問いは、そもそも翻訳プラグインが必要かどうかということです。これらのプラグインが翻訳する内容の大部分（ボタンラベル、エラーメッセージ、テーマUI、チェックアウト文字列など）は、WordPressコアがネイティブに読み取ることができる.poファイルに存在します。それらのファイルを一度翻訳し、コンパイルされた.moをwp-content/languages/に配置することで、プラグインのオーバーヘッド、ライセンスの更新、パフォーマンスの問題といったあらゆる種類の懸念が解消されます。

WordPressの.poファイルをスタックに別のプラグインを追加することなく翻訳する準備はできましたか？ SimplePoTranslateを無料で試す - クレジットカードは不要です。.poをアップロードし、翻訳された.po + .moをダウンロードしてデプロイしてください。