PolylangサイトでのText to Speech：実際に動く方法

Polylangでの本格的なText to Speechとは、翻訳された投稿ごとに正しい言語とボイスで音声ファイルを1つ生成することを意味します。PolylangはすべてのE翻訳を固有のIDを持つ独立したWordPress投稿として保存するため、投稿単位の音声生成はそのまま機能します。問題になるのは音声自体ではなく、ボイスの選択・Cookieリダイレクト・ページキャッシュです。

これは多言語TTS連載の第4弾です。これまでにWPML、Weglot、GTranslate 3.3.0リリースを取り上げました。Polylangはアーキテクチャ的にWPMLに最も近いですが、独自の注意点もあります。本番サイトでのテスト結果と、テキスト読み上げ - TTSWPで実際に動く内容をまとめます。

PolylangとText to Speechの相性

Polylangは無料の多言語WordPressプラグインとして最も広く使われており、80万以上のアクティブインストール数を誇ります。2011年にリリースされて以来、現在も活発にメンテナンスされています。追加できる言語数に制限はなく、WordPress言語パックは自動でダウンロードされます。Polylangを選ぶサイトの多くは、ブログ・小規模メディア・コスト重視の制作会社です。コアが無料で、アーキテクチャがシンプルなためです。

その人気がTTSプラグインにとっての問題でもあります。Polylang対応を謳いながら、デフォルト言語だけでしかテストしていないプラグインが多く存在します。1つの音声ファイルを投稿に紐付け、すべての翻訳版に同じファイルを配信してしまうのです。スペイン語ページで英語音声が流れたり、ドイツ語ページで音声が無音になったりして、ユーザーが離脱します。

解決策は構造にあります。Polylangは独自のデータベーステーブルもショートコードも追加しません。カテゴリやタグと同じWordPressタクソノミーを基盤として使います。各翻訳は実際の投稿として保存されます。TTSWPが採用している投稿単位の音声生成は、Polylangのコンテンツ保存方法と完全に一致しています。

PolylangがWeglot・GTranslateと異なる点

Polylangは投稿を複製します。WeglotとGTranslateはレンダリング時に翻訳します。このたった1つの違いが、TTS対応のすべてを決定づけます。

Polylangサイトでは、「会社概要」のドイツ語翻訳は投稿ID 412、言語スラッグ「de」を持つ独立したWordPress投稿としてデータベースに保存されています。WordPressからも、REST APIからも、そしてsave_postやwp_insert_postにフックしているTTSプラグインからも認識されます。音声生成はその翻訳の言語で翻訳ごとに1回実行され、ファイルは投稿IDに紐付けてキャッシュされます。

WeglotとGTranslateは仕組みが異なります。翻訳されたテキストはユーザーがページを要求したときだけ存在します。音声を紐付ける第2の投稿がありません。WeglotとGTranslateの対処法は以前の記事で解説しました。WPMLはPolylangと同じ複製モデルを採用しているため、WPMLガイドが若干の調整で参考になります。

TTSにとって、これは朗報です。Polylangは必要なものをすべて提供しています。言語ごとに安定した投稿ID、既知の言語スラッグ、そしてレンダリング時に変わらないパーマリンクです。

Polylangの4つのURL構成とTTSへの影響

Polylangには4つのURLモードがあります。それぞれキャッシュ・CDN・言語検出コードがページをどう認識するかが変わります。誤ったモードを選ぶと、正しい音声ファイルが間違ったURLの背後に置かれることになります。

1. コンテンツのみで言語を判定（URLに言語コードなし）

最も扱いが難しいケースです。example.com/aboutというURLが、CookieまたはブラウザDetectionに基づいてあるユーザーには英語を、別のユーザーにはドイツ語を表示します。ページキャッシュは1つのURLを見て1つのバリアントを保存します。キャッシュが最初に取得した言語が優先されます。

音声ファイル自体はURLではなく投稿IDに紐付いているため問題ありません。問題はプレーヤーを埋め込んでいるページです。キャッシュされた英語ページにドイツ語音声の埋め込みが読み込まれると、プレーヤーはドイツ語を再生しますが、ユーザーは英語のテキストを読んでいます。このURLモードはキャッシュを使用するサイトには推奨しません。

2. ディレクトリURL（/en/、/de/）

デフォルト設定であり、推奨する構成です。各言語が独自のパスに配置されます。キャッシュは/en/aboutと/de/aboutを別々のキーとして扱います。正しいページが正しいプレーヤーと正しい音声ファイルで読み込まれます。Cookie処理は不要です。

「デフォルト言語のURL言語情報を非表示にする」オプションに注意してください。有効にすると、デフォルト言語からプレフィックスが消えます。/aboutが英語になり、/de/aboutはドイツ語のままです。デフォルト言語のパスにはスラッグが含まれないため、サードパーティのコードでURLベースの言語検出が失敗します。このオプションを使う場合は、URL解析ではなくpll_current_language()を使用してください。

3. サブドメイン（en.example.com、de.example.com）

サブドメインは各言語に独自のホストとキャッシュ名前空間を与えます。TTSプレーヤーは言語ごとにきれいに読み込まれます。代わりにDNS設定、サブドメインごとのSSL証明書、やや複雑なアナリティクス設定が必要です。大規模なサイトでも問題なく機能します。

4. 言語ごとに独立したドメイン

完全な分離構成です。英語はexample.com、ドイツ語はexample.deというように分けます。TTSは各WordPressインストール内の投稿IDに音声を紐付け、プレーヤーも同じように動作します。このモードはすでにccTLDを保有しているブランドに多く見られます。

Cookieリダイレクトの問題

Polylangはホームページへの最初のアクセス時にユーザーのブラウザ言語を検出できます。その後、pll_language Cookieをセットし、対応する言語バージョンにリダイレクトします。ページキャッシュと組み合わさると、ここで間違った言語の音声が表示されます。

実際に再現した失敗のシナリオを紹介します。フランス語ユーザーがホームページを開きます。Polylangがフランス語を検出し、pll_language CookieをセットしてE/fr/にリダイレクトします。キャッシュはそのリダイレクトレスポンスをホームページURLに保存します。次に英語ユーザーがホームページを開くと、キャッシュされたリダイレクトによって/fr/に飛ばされます。フランス語ページが表示され、フランス語音声が流れ、ユーザーは離脱します。

ディレクトリURLを使用していれば、他のページは言語ごとに別々のキャッシュキーを持つため、影響はホームページのみです。「コンテンツで言語判定」モードでは同じ問題がサイト全体のURLに広がります。

対処法は3つあります。最もシンプルなのは、キャッシュを使用するサイトではブラウザ言語検出をオフにして、ユーザーが言語スイッチャーで選択できるようにすることです。2つ目は、キャッシュプラグインにpll_language Cookieでバリエーションを作るか、バイパスするよう設定することです。3つ目は、ホームページをページキャッシュから除外して、検出リダイレクトが毎回ライブで実行されるようにすることです。

WP Rocket、W3 Total Cache、LiteSpeedを使用している場合は、Cookie設定についてキャッシュ連携ドキュメントを参照してください。Polylangはこれらのキャッシュプラグインと共存できますが、共存と言語対応は別の話です。キャッシュの設定は別途必要です。

フロントエンドでのAJAX動作

PolylangはフロントエンドのAJAXリクエストで現在の言語を自動検出し、その言語の文字列を読み込みます。特定の言語を強制するために、リクエストに明示的なlang変数を渡すこともできます。TTSでは、音声プレーヤーや関連投稿ウィジェットが別の投稿を取得するAJAX呼び出しを発行するときに重要です。

テストでは、Polylangはこれをきれいに処理しました。WPMLの記事で記録したAJAX言語の問題は見られませんでした。カスタム連携で現在とは異なる言語の投稿を取得する必要がある場合は、langを明示的に渡し、結果を読む前にfunction_exists('pll_current_language')を確認してください。

PolylangサイトへのText to Speech - TTSWPの設定

以下の手順は、Polylangがすでにインストールされ、少なくとも1つの翻訳が存在することを前提としています。

1. テキスト読み上げ - TTSWPをインストールします。WordPress.orgのプラグインページから入手できます。有効化後、権限エラーが出た場合はインストールドキュメントを確認してください。
2. プラグインをTTSWPに接続します。接続ガイドに従ってください。無料プランにはウェルカムクレジットが含まれており、有料プランを決める前にテストできます。
3. 元の言語の投稿を開いて音声を生成します。フロントエンドでプレーヤーが表示されることを確認します。
4. 翻訳版に切り替えます。投稿エディターのPolylang言語スイッチャーを使用します。再度音声を生成します。Polylangが別の投稿IDを読み込んでいるため、TTSWPはこれを新しい生成として扱い、別のファイルを保存します。
5. 各翻訳のボイスを選択します。ボイスの選択は投稿レベルで行います。投稿ごとの上書きについてはボイス選択ドキュメントを参照してください。
6. フロントエンドで確認します。/en/post-slugと/de/post-slugを別タブで開きます。それぞれ再生して、ボイスと言語が正しいことを確認します。

現在、TTSWPの言語別デフォルトボイスマッピングはWPMLとWeglotを優先してカバーしています。Polylangでは、ボイスの選択は投稿レベルで行い、言語別のデフォルトは後述する投稿言語の取得を通じて機能します。各翻訳が実際の投稿であり、ボイスは投稿ごとに1回設定すれば済むため、ほとんどのPolylangサイトではこれで十分です。現在の動作についてはPolylang連携ドキュメントを参照してください。

投稿の言語からボイスを取得する方法

Polylangで投稿の言語を読み取る正しいAPIはpll_get_post_language()です。Polylang自身の開発者向けガイドラインが推奨するように、呼び出す前に関数の存在を必ず確認してください。パターンは次のとおりです。

if ( function_exists( 'pll_get_post_language' ) ) {
    $lang = pll_get_post_language( $post_id, 'slug' );
    // $lang は 'en'、'de'、'fr' などになります
}

フロントエンドのコンテキストでは、pll_current_language()が現在のリクエスト言語を返します。どちらの関数も安定しており、長年PolylangのパブリックAPIとして提供されています。ボイスマッピングのロジックは常に投稿の言語から読み取り、サイトのデフォルトから読み取らないようにしてください。そうしないと翻訳版に誤ったボイスが引き継がれます。

Polylang無料版とPolylang ProのTTSへの影響

音声生成にPolylang Proは必要ありません。TTSWPに必要なものはすべてPolylangの無料版で揃います。投稿の複製・言語スラッグ・前述のパブリックAPI関数です。

Polylang ProはDeepL機械翻訳・REST APIサポート・翻訳されたURLスラッグ・外部翻訳作業用のXLIFFエクスポートを追加します。これらはいずれも、ブログ投稿やページのTTSには影響しません。WooCommerce向けPolylangはショップページ・商品カテゴリー・属性・取引メールを管理する別の有料アドオンです。商品説明に音声を追加したい場合は、WooCommerce TTSガイドを参照してください。

言語別音声によるSEOとAEO

Polylangはhreflangを自動的に処理するため、多言語サイトのSEO作業の大部分は不要です。言語バージョンごとにAudioObjectスキーマを追加し、それぞれをその翻訳のファイルに向ければ、検索エンジンに明確なシグナルを送れます。

自社のテストでは、音声とAudioObjectスキーマを持つ記事はAI検索エンジンから引用される頻度が高いことがわかっています。手法と結果はAEOと音声に関する記事で詳しく解説しました。要点をまとめると、翻訳ごとに1つの音声ファイルと翻訳ごとのスキーマがあれば、AEOの効果は自然についてきます。

よくある問題と解決策

アクセシビリティについて

言語ごとに音声を追加することはアクセシビリティの向上にもなります。母国語でのテキスト読書が得意でも音声で聞きたいユーザーの両方のニーズに応えられます。WCAG 2.2または欧州アクセシビリティ法の対象サイトには、適用される基準についてWCAG音声コンプライアンスガイドを参照してください。2026年のWordPressへのTTS追加についての全体的な解説は、メインチュートリアルが基礎をカバーしています。

よくある質問

PolylangはText to Speechと連携できますか？

はい。Polylangは各翻訳を固有のIDを持つ独立したWordPress投稿として保存します。これはTTSWPが投稿単位の音声生成に使用するアーキテクチャと同じです。各翻訳で音声を生成すれば、選択したボイスで言語ごとに1つのファイルが作成されます。Polylangの無料版で十分です。TTSWPの標準設定以外の特別な設定は必要ありません。

音声生成にPolylang Proは必要ですか？

いいえ。Polylangの無料版でTTSWPに必要なすべてのものが揃います。言語別の投稿複製・言語スラッグ・パブリックAPI関数pll_get_post_language()とpll_current_language()が利用できます。Polylang ProはDeepL機械翻訳・REST APIサポート・翻訳されたURLスラッグを追加しますが、これらは音声生成や再生には影響しません。

言語ごとに異なるボイスを使えますか？

はい。各翻訳が独立した投稿のため、ボイスの選択は投稿レベルで行います。ドイツ語翻訳にはドイツ語ボイス、スペイン語翻訳にはスペイン語ボイスを選択するといった具合です。TTSWPは選択内容を投稿ごとに保存し、再生成のたびに同じボイスを使用します。現在の動作については言語とボイスマッピングドキュメントを参照してください。

音声が間違った言語で再生されるのはなぜですか？

一般的な原因は、ページキャッシュとPolylangのブラウザ言語検出の組み合わせです。キャッシュがホームページのリダイレクトまたは単一の言語バリアントを保存し、すべてのユーザーに配信します。音声ファイル自体は投稿IDに対して正しいですが、それを読み込むページが間違っています。キャッシュを使用するサイトではブラウザ検出をオフにするか、pll_language CookieでキャッシュをバリエーションEするよう設定してください。ディレクトリURL（/en/、/de/）を使えば、他のすべてのページには別々のキャッシュキーがあるため、影響はホームページに限定されます。

TTSにおいてPolylangとWPMLはどう違いますか？

どちらも言語ごとに投稿を複製するため、投稿単位の音声生成は同じように動作します。違いはAJAL処理・Cookie動作・開発者向けAPI名にあります。Polylangはpll_プレフィックスの関数を使用し、全体的に軽量です。WPMLにはWooCommerce向けの機能が多く組み込まれていますが、プラグインのフットプリントが大きくなります。詳しくはWPML記事を参照してください。

音声プレーヤーのラベルを翻訳できますか？

はい。1つ追加の手順が必要です。Polylangはpll_register_string()を使ってUI文字列を登録したプラグインの文字列翻訳画面を提供します。再生ボタン・進行タイマーラベルなどのプレーヤーテキストを言語と一緒に切り替えたい場合は、子テーマまたは小さなサイト固有プラグインにこれらの文字列を登録してください。登録すると「言語」メニューの「文字列翻訳」に表示されます。

次のステップ

WordPressエディターで翻訳された投稿の1つを開き、音声パネルを確認してください。デフォルトで正しい言語が表示されていれば設定完了です。表示されない場合は、その翻訳のボイスを設定して再生成し、フロントエンドで確認してください。1つの翻訳がうまく動けば、残りも同じ手順で設定できます。

テキスト読み上げ - TTSWPをまだインストールしていない場合は、WordPress.orgから取得して無料のTTSWPアカウントに接続してください。1つの翻訳でテストして音声を確認し、残りの翻訳にも展開するかどうかを決めてください。