WordPressウェブサイトの多言語翻訳 総合ガイド
WordPressウェブサイトの翻訳は、慎重な計画と実行が求められる複雑なプロセスです。このガイドは、プラグイン Gato AI Translations for Polylang を使ったウェブサイト翻訳の豊富な経験に基づいて作成しました。
このガイドでは、初期の準備と設定から翻訳の実行、検証やトラブルシューティングまで、知っておくべきすべてを順を追って説明します。スムーズな翻訳体験を実現するために、ぜひ本ガイドに従ってください。
Polylangのインストールと設定
Gato AI Translations for Polylang は Polylang のインストールと有効化が必要です。Polylang は言語と翻訳の関係を管理する多言語フレームワークです。
インストール後、言語を設定するために Polylangを設定 してください。
- WordPressの管理メニューで Languages に移動します
- デフォルト言語(既存コンテンツの言語)を追加します
- 翻訳したいすべてのターゲット言語を追加します

有効なすべてのプラグインが Polylang と互換性があることを確認してください。一部のプラグインは多言語環境で正しく動作しない場合があります。
互換性のないプラグインが見つかった場合は、代替を探す、開発者にサポートを依頼する、または本当に必要かどうかを検討してください。
まず元のコンテンツを確認・修正する
翻訳を開始する前に、元のコンテンツが完璧な状態であることを確認することが重要です。元のコンテンツに問題があると、すべての翻訳にも複製されるため、同じ問題を複数回(各言語ごとに)修正する必要が生じます。
コンテンツ確認チェックリスト:
-
リンク切れの確認
- Broken Link Checkerのようなプラグインを使って、内部・外部のリンク切れを特定する
- 翻訳前にすべてのリンク切れを修正する
- 内部リンクが正しい投稿・ページを指していることを確認する
-
すべての画像の存在と最適化を確認
- すべての画像が正しく読み込まれることを確認する
- アクセシビリティとSEOのために、画像に適切なaltテキストがあることを確認する
- 画像ファイルサイズが適切であること(大きすぎない)を確認する
- プレースホルダー画像やリンク切れの画像参照を削除する
-
書式とスタイルの確認
- テキストの書式が一貫していることを確認する
- 見出しが適切に構造化されていること(H1、H2、H3など)を確認する
- リスト、表、その他の構造化コンテンツが正しく表示されることを確認する
- カスタムスタイルとCSSが期待どおりに動作することをテストする
-
コンテンツ構造の検証
- GutenbergブロックまたはページビルダーのElementの適切な使用を確認する
- カスタム投稿タイプとタクソノミーが正しく設定されていることを確認する
- メタデータ(カスタムフィールド、ACFフィールドなど)が完全であることを確認する
-
プレースホルダーコンテンツの確認
- 「Lorem ipsum」やプレースホルダーテキストを削除する
- 一時的なコンテンツを最終バージョンに置き換える
- すべてのコンテンツが公開できる状態にあることを確認する
-
SEOの考慮事項
- メタタイトルとディスクリプションが設定されていることを確認する
- URLがSEOフレンドリーであることを確認する
- SEO構造のために見出しが適切に使用されていることを確認する
内部リンク置換の設定
コンテンツを翻訳する際、内部リンクは翻訳バージョンを指すように更新する必要があります。Gato AI Translations for Polylang はこれを自動的に処理することができます。
プラグインでは、どのタイプの内部リンクを置換するかを設定できます。
- Custom Posts: 他の投稿、ページ、カスタム投稿タイプなどへのリンク
- Media: メディアアイテム(画像、動画など)へのリンク
- Tags: タグアーカイブページへのリンク
- Categories: カテゴリーアーカイブページへのリンク
- Users: 著者ページへのリンク
コンテンツ内の投稿リンクは元のコンテンツから自動的に抽出されて置換されます。他のリンクタイプ(media、tags、categories、users)は、置換を希望する場合は設定で有効にする必要があります。
設定方法:
- 設定ページの Plugin Configuration > Internal Links Replacement に移動します
- 実際にコンテンツで使用しているリンクタイプのみを有効にします
- 設定を保存します

すべてのリンクが正しいURLを使用していることを確認する
内部リンク置換機能が正しく動作するためには、コンテンツ内のすべてのリンクが適切なURL形式を使用している必要があります。これは以下のリンクに適用されます。
- 投稿・ページのコンテンツ(Gutenbergブロック、HTMLなど)
- Elementorウィジェットとメタフィールド
- Bricksビルダーの要素とメタフィールド
- カスタムフィールドとメタデータ
URLの要件:
-
URLはフルドメインを含む必要があります
- ✅ 正しい:
https://www.mysite.com/hello-world/ - ❌ 誤り:
/hello-world/(相対URL) - ❌ 誤り:
hello-world/(ドメインもプロトコルもない)
- ✅ 正しい:
-
URLは現在のスラッグを指す必要があります
- 投稿のスラッグを変更した場合は、新しいスラッグを使用するようにすべてのリンクを更新する
- WordPressはURLから投稿を取得できる必要がある
- リダイレクトされる古いスラッグはリンク置換では機能しない
-
URLは正しいドメインを使用する必要があります(リダイレクトなし)
- ✅ 正しい:
https://www.mysite.com/hello-world/ - ❌ 誤り:
https://mysite.com/hello-world/(サイトがwwwを使用している場合) - プラグインはリンクを正確にマッチングして置換するために正確なドメインが必要
- ✅ 正しい:
URLのドメインが誤っている場合は、Better Search Replace のようなプラグインを使ってデータベース内のURLを検索・置換できます。例えば https://mysite.com を https://www.mysite.com に置換します。
下書きまたは公開ステータスを選択する
翻訳が作成されたとき、即座に公開するか、まずレビューのために下書きとして保存するかを決める必要があります。
デフォルトでは、翻訳は下書きとして保存されます。翻訳を即座に公開するには、設定ページの Plugin Configuration > General Configuration に移動し、Status when translated オプションを Publish または Same as origin post(元の投稿がすでに公開されている場合)に設定してください。

右から左(RTL)言語のサポート
ヘブライ語、アラビア語、ファルシ語、ウルドゥー語などの右から左に書く言語に翻訳する場合は、テーマがRTLレイアウトを正しくサポートしていることを確認する必要があります。


RTLが影響する要素:
RTL言語はテキストの方向変更だけでは済みません。テーマは以下を処理する必要があります。
- レイアウトの方向: 要素が右から左に流れること
- テキストの配置: テキストがデフォルトで右揃えであること
- スペースの調整:
margin-leftはmargin-rightに、padding-leftはpadding-rightになるなど - ナビゲーション: メニューとナビゲーションがRTLで流れること
- フォーム: 入力フィールドとボタンが正しく配置されること
- アイコンと画像: ミラーリングまたは再配置が必要な場合がある
すでに処理されていること:
- Polylang は正しい言語方向(
dir="rtl"属性)を自動的に設定します - コンテンツ翻訳 はRTLとLTR言語で同一に機能します
- Gato AI Translations はテキストの方向に関係なくコンテンツを正しく翻訳します

確認すべき事項:
-
テーマのRTLサポート: RTL言語でテーマをテストして、正しく処理されるかを確認する
- 多くのモダンテーマにはRTLスタイルシートが含まれています
- RTLサポートについてはテーマのドキュメントを確認してください
- テーマ内の
rtl.cssや同様のファイルを探してください
-
カスタムCSS: 追加したカスタムCSSを確認する
- ハードコードされたleft/rightの値は調整が必要な場合があります
- 論理プロパティの使用を検討してください(
margin-leftの代わりにmargin-inline-start)
-
ページビルダーの互換性: Elementor、Bricks、その他のページビルダーを使用している場合
- RTLレイアウトをサポートしているか確認する
- 翻訳前にRTLモードでレイアウトをテストする
テーマがRTLをうまくサポートしていない場合は、RTL対応テーマへの切り替え、カスタムRTL CSSの追加、またはRTLサポートを追加するプラグインの使用が必要になるかもしれません。
翻訳が必要なサードパーティプラグインのコンテンツを特定する
多くのWordPressプラグインは、コンテンツを保存するために独自のカスタム投稿タイプ(CPT)を作成します(例: WooCommerceの商品、Events Calendarのイベント、LearnDashのコースなど)。
翻訳前に以下を行う必要があります:
-
翻訳が必要なコンテンツを含むCPTを特定する
- 有効なプラグインとそのCPTを確認する
- どれが翻訳を必要とするかを決定する(すべてが必要なわけではない)
-
関連するCPTとタクソノミーが翻訳可能であることを確認する
- Polylangの Languages > Settings > Custom post types and Taxonomies に移動する
- 関連するCPTとタクソノミーの翻訳を有効にする

CPTの翻訳エントリーを自動作成する
CPTがエントリーの作成に wp_insert_post メソッドを使用している場合、設定ページの Plugin Configuration > General Configuration に移動し、そのCPTの Automatic creation of translation entries オプションを有効にすることで、プラグインが翻訳エントリーを自動的に作成します。

CPTが wp_insert_post 以外のメソッドを使用している場合は、翻訳する前にPolylangのUIを使って翻訳エントリーを手動で作成する必要があります。
例えば、WooCommerceの商品の場合は、最初に翻訳エントリーを作成する必要があります。デモ動画についてはサードパーティカスタム投稿タイプの翻訳に関するドキュメントを確認してください。
SEOプラグインがサポートされていることを確認する
SEOメタデータ(メタタイトル、ディスクリプション、Open Graphタグなど)は多言語SEOにとって非常に重要です。Gato AI Translations for Polylang には最も人気のあるSEOプラグインのサポートが組み込まれており、SEO関連のメタデータをすべて自動的に翻訳します。
プラグインは8つの主要なSEOプラグインをサポートしています。
- All in One SEO
- Rank Math
- SEO Simple Pack
- SEOPress
- Slim SEO
- The SEO Framework
- WP Meta SEO
- Yoast SEO
上記に記載されていないSEOプラグインを使用している場合は、使用しているSEOプラグインに対応するメタキーを同期・翻訳するよう指定する必要があります。wp_postmeta テーブルにメタデータを保存するプラグインはいずれも対応しています。
AIプロバイダーとモデルを選択する
翻訳の品質は選択するAIサービスとモデルに依存します。
最新のAIサービス(ChatGPT、Claude、Gemini など)は、従来のサービス(Google Translate や DeepL)よりも大幅に優れた翻訳を生成します。その理由は、文脈・トーン・ニュアンスをより深く理解し、HTMLの構造と書式を正しく保持し、URLや相対リンクを誤って翻訳せず、翻訳全体を通じて文体と声を維持し、技術用語やドメイン固有の言語をより適切に処理するためです。
以下のAIサービスから選択できます。
- ChatGPT (OpenAI)
- Claude (Anthropic)
- DeepSeek
- Gemini (Google)
- Mistral AI
- OpenRouter(主要モデルすべてへのアクセスを提供するLLMアグリゲーター。Grok や Llama も含む)
- セルフホストLLM(自前のサーバーでホスト。例: Ollama 経由)
利用可能な最新のモデルバージョンを使用することをお勧めします(例: 5.0 より ChatGPT 5.2)。新しいモデルは常に優れた翻訳品質を提供します。
プロのヒント: 言語ごとに異なるAIサービスを設定できます。例えば、中国語にはDeepSeek(優れた品質でとても手頃)、ヨーロッパ言語にはChatGPT、複雑な技術コンテンツにはClaudeを使用します。これにより、品質とコストの両方を最適化できます。
OpenRouter を使用して、リリースされた直後から最新のAIモデルにアクセスすることができます。
AI翻訳プロンプトのカスタマイズを検討する
デフォルトの翻訳プロンプトはほとんどのコンテンツでうまく機能しますが、カスタマイズすることで特定のユースケースの翻訳品質を向上させることができます。
例:
旅行ブログでは、以下のような内容をプロンプトに追加してカスタマイズすることがあります。
Translate to a natural, flowing, easy-to-read, casual blog-style language. Keep original content structure, meaning, and styling (but do adjust sentence structure and style to be relevant to the target language).
Lightly improve boring parts - Add curiosity triggers, light humor, and light slang (as fits the target language), like a human travel blogger would write.デフォルトのプロンプトを変更するか、複数のカスタムAIプロンプトを作成して、設定でどれを使用するかを選択することができます。

Gutenbergブロックの確認
翻訳前に、使用しているブロックを特定し、翻訳がサポートされていることを確認する必要があります。
初期状態でサポートされる Gutenbergブロック:
- すべてのWordPressコアブロック: Paragraph、Heading、List、Quote、Image、Galleryなど
- サードパーティブロック: Yoast SEO、GenerateBlocks、Kadence、Greenshift などのプラグインのブロック
翻訳が必要な文字列を含むサポートされていないブロックを使用している場合は、以下のいずれかの方法を取れます。
- ブロックを翻訳するためのインテグレーションを追加する、または
- サポートされているブロックに置き換える(例えば、カスタムテスティモニアルブロックをサポートされている代替ブロックに置き換える)
お困りですか? カスタムブロックのインテグレーションをお手伝いします。インテグレーションを専門家に任せたい場合は、カスタムサービスをご覧ください。
注意: 翻訳できないブロックも存在します。
サポートされていないブロックを置き換える必要がある場合は、そのブロックを使用しているすべての投稿を見つけたいはずです。特定のブロックがどこで使用されているかを特定する方法については、特定のブロックを含む投稿を見つけるチュートリアルを確認してください。
Elementorウィジェットの確認
Elementor ページビルダーを使用している場合は、使用しているウィジェットを確認し、翻訳がサポートされていることを確認する必要があります。プロセスはGutenbergブロックの確認と似ていますが、Elementorウィジェット固有のものです。
すべての Elementor コアウィジェットは初期状態でサポートされています。
サポートされていないウィジェットがある場合は以下の方法を取れます。
- ウィジェットを翻訳するためのインテグレーションを追加する、または
- サポートされているウィジェットに置き換える
Bricksエレメントの確認
Bricks ページビルダーを使用している場合は、使用しているエレメントを確認し、翻訳がサポートされていることを確認する必要があります。プロセスはGutenbergブロックの確認と似ていますが、Bricksエレメント固有のものです。
すべての Bricks コアエレメントは初期状態でサポートされています。
サポートされていないエレメントがある場合は以下の方法を取れます。
- エレメントを翻訳するためのインテグレーションを追加する、または
- サポートされているエレメントに置き換える
テキストを含む画像の処理
ウェブサイトを翻訳する際によくある見落としは、画像に翻訳が必要なテキストが含まれていることを忘れることです。
投稿を翻訳すると、画像は翻訳バージョンにコピーされ、画像のメタデータ(タイトル、altテキスト、キャプション)は翻訳されますが、画像内のテキストは元の言語のままです。
画像を確認する最も簡単な方法は、WordPressのメディアライブラリを Grid レイアウトに切り替えることです。これにより、すべての画像を一覧で視覚的にスキャンし、誤った言語のテキストが埋め込まれた画像をすばやく見つけることができます。

例えば、この画像にはヘブライ語のテキストが含まれており、他の言語には適していません。

対処法:
-
埋め込みテキストをそのまま残す(その言語でも一般的に理解できる場合)
- テキストが広く理解されている言語または普遍的な記号・数字を使用している場合に適切
- 追加作業は不要
-
画像からテキストを削除する
- 埋め込みテキストのない画像を使用する
-
埋め込みテキストの代わりにテキストオーバーレイを使用する
- 埋め込みテキストのない画像を使用する
- 自動的に翻訳されるテキスト(Gutenbergブロック、Elementorウィジェット、BricksエレメントまたはCSSを使用)をオーバーレイする
-
翻訳バージョンの画像を作成する
- 各言語用に別々の画像ファイルを作成する
- 翻訳された投稿内の画像を手動で置き換える
追加ユーザーデータの翻訳処理
PolylangはWordPressユーザープロフィールの伝記フィールドを処理できますが、カスタムフィールド(ACF、Meta Box、その他の手段)に追加のユーザーデータが保存されている場合は、特別なアプローチが必要です。
翻訳が必要なユーザーデータ(役職、資格、説明など)がある場合は、各言語に別々のフィールドを作成する必要があります。
-
各言語に別々のフィールドを作成する
- ACFまたはMeta Boxを使用して、以下のようなフィールドを作成します。
Qualification ENQualification FRQualification DE- など
- ACFまたはMeta Boxを使用して、以下のようなフィールドを作成します。
-
正しいフィールドを表示するようにテーマを更新する
- 現在の言語を確認するようにテーマのテンプレートを変更する
- 有効な言語に基づいて適切なフィールドを表示する
- PHPコードの例:
$current_lang = pll_current_language(); $qualification = get_field("qualification_{$current_lang}", 'user_' . $user_id); echo $qualification;
-
フィールドを手動で入力する
- コンテンツを翻訳した後、ユーザープロフィールフィールドを手動で更新する
翻訳すべきでない用語の翻訳をスキップする
ブランド名、固有名詞、技術用語、ドメイン固有の専門用語など、翻訳してはいけない用語があります。
カスタムプロンプトに指示を追加することで、これらの用語の翻訳をスキップできます。例:
Do not translate the following types of terms:
- Hotel names (e.g., "Grand Hotel", "Beach Resort")
- Restaurant names
- Brand names
- Technical acronyms (API, SEO, CMS, etc.)
Keep these terms exactly as they appear in the original text.言語間での重複タグを避ける
コンテンツには、2つの異なる言語で同じ概念を表すタグが存在することがあります。これらのタグを翻訳すると、重複や競合が発生する場合があります。
例えば、中国語のウェブサイトを英語に翻訳する場合に、布宜诺斯艾利斯(中国語でBuenos Aires)というタグと英語の Buenos Aires タグの両方がある場合、英語に翻訳すると両方のタグが buenos-aires になります。これにより重複タグの状況が発生します。

翻訳前の修正方法:
-
タグの確認
- 元の言語のすべてのタグを確認する
- 他の言語のタグと重複している可能性があるタグを特定する
- 異なる言語で同じ概念を表すタグを探す
-
タグの統合
- 保持する言語バージョンを1つ選ぶ(通常は元の言語)
- 重複タグをマージまたは削除する
- 統合されたタグを使用するように投稿を更新する
-
翻訳前にクリーンアップする
- 元のコンテンツに元の言語のタグのみが含まれていることを確認する
- 元のコンテンツからターゲット言語のタグを削除する
- これにより翻訳中の競合を防ぐ
言語間での重複する地名を避ける
コンテンツがスクリプトが混在した見出しを使用している場合、このパターンが見られることがあります。タイトルが現地の地名から始まり、次に括弧内にラテン文字での同じ名前、そして残りの行が続きます。
典型的な元のパターン(例):
- 元 (例: ヘブライ語):
פוקט (Pouket) - מדריך לאי היפה— 現地名、次に英語または国際的なスペルが括弧内に、そしてサブタイトル - 翻訳後 (例: 英語):
Pouket (Pouket) - beautiful island guide
翻訳後、見出しはすでに1つの言語とスクリプトになっているため、モデルの直訳では同じ地名が2回繰り返されます(例: Pouket (Pouket))。
解決策: 翻訳プロンプトを改善する
括弧内が新しい情報を追加していない場合に、モデルが冗長な「名前 (同じ名前)」の冒頭を正規化するようにプロンプトをカスタマイズします。例えば、以下のような指示を追加します。
If a heading begins with a place name followed by the same translated name in parentheses, remove the duplicate and keep one natural version. Do not remove the parenthesis if the text inside uses a different script, a different spelling, or includes additional descriptive information.タグ・カテゴリーのスラッグに注意する
タグやカテゴリーのスラッグがすでにターゲット言語になっている場合、翻訳するものがないと思うかもしれません。

多くの場合それは問題ありませんが、Polylang free(非Pro版)には注意点があります。
Polylang Proでは、翻訳されたタームは言語間で同じスラッグを再利用できます。無料版では、WordPressがすべてのスラッグの一意性を強制するため、翻訳されたタームのスラッグには自動的に -2 サフィックスが追加されます。
例えば、ヘブライ語でスラッグが travels_and_attractions のカテゴリーは、英語に翻訳されると、同じスラッグが維持される代わりに travels_and_attractions-2 になります。
これがURLやSEOに影響する場合は、翻訳後にスラッグを手動で修正するか、Polylang Proにアップグレードして言語間でのスラッグ再利用を許可する必要があります。
埋め込みコンテンツが適切な言語であることを確認する
Google Maps、ソーシャルメディアウィジェット、その他のプラットフォームのiframeなどのサードパーティコンテンツを埋め込んでいる場合は、埋め込みがターゲット言語で表示されることを確認してください。
例えば、ヘブライ語用に設定されたGoogle Mapsの埋め込みは、ページの残りの部分を英語に翻訳した後でも、ヘブライ語のラベル、通り名、UIを表示し続けます。その場合は、言語に依存しない埋め込みを使用することを検討するとよいでしょう。

同じことは、言語固有の埋め込みを生成するプラットフォームやサービス(例: YouTubeのチャプター、レビューウィジェット、予約フォーム)にも当てはまります。翻訳後は必ず各埋め込みを確認してください。
元のコンテンツに言語固有のスタイルがないことを確認する
特定の言語(特にヘブライ語やアラビア語などのRTL言語)向けに書かれた投稿コンテンツには、HTML要素に直接適用されたインラインの方向や言語属性が含まれている場合があります。そのコンテンツを別の言語に翻訳すると、ハードコードされたスタイルが引き継がれてレイアウトが崩れます。
RTL元コンテンツでよく見られるもの:
<div dir="rtl" lang="he">— セクション全体にRTL方向を強制し、言語をヘブライ語としてマークする<p dir="rtl">— 個々の段落にRTL配置を強制する<h2 style="text-align: right;">— 見出しに右揃えをハードコードする
このコンテンツを英語(または他のLTR言語)に翻訳すると、テキストは英語になりますが、レイアウトは右から左にレンダリングされ続け、見出しのずれ、テキストフローの逆転、書式の崩れが生じます。
翻訳前に、元のコンテンツでこれらの属性を確認して削除してください。 テーマとWordPressの言語・ロケール設定に、個々のコンテンツブロックに埋め込む代わりに、方向と配置をグローバルに制御させてください。
ElementorのTheme Builderテンプレートの処理
ElementorのTheme Builderを使用してグローバルテンプレート(ヘッダー、フッター、シングル投稿テンプレート、アーカイブテンプレートなど)を作成している場合、翻訳中にこれらのテンプレートがどのように処理されるかを理解することが重要です。
翻訳されるもの:
- メニュー: メニューアイテムが翻訳されたメニューバージョンに置き換えられる
- ダイナミックコンテンツ: 投稿・ページから取得されたコンテンツが翻訳される(ソースコンテンツが翻訳されているため)
翻訳されないもの:
- ハードコードされたテキスト: テンプレートに直接追加されたテキスト(ダイナミックコンテンツからでないもの)は翻訳されない
- ウィジェットテキスト: 見出し、段落、ボタンなどのウィジェット内のテキストは元の言語のまま
- カスタムHTML: カスタムHTMLやコードブロックは翻訳されない
例:
このElementorヘッダーテンプレートにはハードコードされたテキスト("Our Phone Number:")が含まれています。

解決策:
テンプレートは以下のみを使用するように設計してください。
- メニュー(自動的に置き換えられる)
- 画像(言語に依存しない)
- ダイナミックコンテンツ(翻訳された投稿から来るもの)
- テンプレートにハードコードされたテキスト、見出し、ディスクリプションを直接追加することは避ける
これにより、サイトのグローバル要素(ヘッダー、フッターなど)がすべての言語で正しく機能します。
Advanced Custom Fields(ACF)の設定
**Advanced Custom Fields(ACF)**を使用している場合は、翻訳中に各フィールドがどのように処理されるかを設定する必要があります。ACFフィールドにはさまざまな種類のコンテンツが含まれる可能性があり、種類によって異なる処理が必要な場合があります。
Gato Translate セクションで、ACFフィールドを以下のオプションのいずれかに設定できます。
-
(Do nothing): フィールドが翻訳または同期からスキップされる
-
Translate: フィールドのコンテンツがターゲット言語に翻訳される
- 使用対象: テキストフィールド、テキストエリアフィールド、WYSIWYGフィールド、および翻訳可能なテキストを含む任意のフィールド
-
Copy: フィールドの値がそのまま翻訳にコピーされる(翻訳されない)
- 使用対象: 数値、日付、チェックボックス、true/falseフィールド、および翻訳すべきでないフィールド
-
Translate Reference: フィールドが別のエンティティ(投稿、ページ、ユーザーなど)を参照しており、参照が翻訳バージョンを指すように更新される
- 使用対象: Post Object、Page Link、Relationship、User、Taxonomyフィールド

フィールドグループは投稿やページだけでなく、以下にも適用できます。
- カテゴリー
- タグ
- メディアアイテム
- ユーザー
- カスタムタクソノミー
- カスタム投稿タイプ
これらのエンティティに適用されるフィールドグループの翻訳設定も必ず設定してください!
Polylang Pro を使用している場合は、Gato AI Translations が代わりに翻訳を処理できるように、PolylangのACF翻訳機能を無効にする必要もあります。
Meta Boxの設定
Meta Box を使用している場合(別の人気カスタムフィールドプラグイン)、設定プロセスはACFと似ています。Meta Boxフィールドも翻訳、コピー、または参照翻訳のために設定する必要があります。
Gato Translate セクションで、Meta Boxフィールドを以下のオプションのいずれかに設定できます。
- (Do nothing): フィールドが翻訳または同期からスキップされる
- Translate: フィールドのコンテンツが翻訳される
- Copy: フィールドの値がそのままコピーされる
- Translate Reference: フィールドの参照が翻訳されたエンティティを指すように更新される

Gato AI Translations が代わりに翻訳を処理できるように、PolylangのMeta Box翻訳機能を無効にする必要もあります。
カスタムメタフィールドの設定
ACF、Meta Box、SEOプラグイン以外に、サイトには以下からのカスタムメタフィールドが存在する場合があります。
- カスタムコード
- その他のプラグイン
- WordPressカスタムフィールド(基本的なCustom Fieldsメタボックス)
これらのメタフィールドは、プラグイン設定で手動設定する必要があります。
カスタムメタキーの特定:
-
コンテンツをエクスポートする
- WordPressの Tools > Export に移動する
- 翻訳する予定のすべてのコンテンツタイプをエクスポートする
- これにより、すべてのコンテンツとメタデータを含むXMLファイルが作成される
-
エクスポートファイルを分析する
- XMLファイルをテキストエディターで開く
<wp:postmeta>タグを検索する- すべての一意なメタキーをリストアップする
-
既知のフィールドを除外する
- ACFフィールドを削除する(通常はフィールドグループ名がプレフィックス)
- Meta Boxフィールドを削除する
- WordPressコアフィールドを削除する(例:
_edit_last、_wp_old_slug、_thumbnail_id) - SEOプラグインフィールドを削除する(サポートされているSEOプラグインを使用している場合)
-
残ったものを特定する
- これらがカスタムメタフィールドです
- 各フィールドに何が含まれ、どのように処理すべきかを決定する
翻訳の必要性を判断する:
各カスタムメタフィールドについて、以下を決定します。
- Translate: 翻訳可能なテキスト(タイトル、ディスクリプション、コンテンツ)が含まれている
- Copy: 翻訳すべきでないデータ(ID、数値、設定)が含まれている
- Translate Reference: 翻訳バージョンを指すべきエンティティIDが含まれている
プラグインでの設定:
- 設定の Meta Configuration タブに移動する
- 翻訳オプション(Translate/Copy/Translate Reference)を選択する
- カスタムメタキー名を追加する(完全一致またはregexパターンを使用)

翻訳プロセスを実行する
すべての準備が完了したので、翻訳を実行する時が来ました。
まずプロセスをテストする
ウェブサイト全体の翻訳に飛び込む前に、まず小規模でプロセスをテストすることが重要です。このアプローチにより、時間を節約し、すべてのコンテンツに問題が複製されることを防げます。
推奨されるテストワークフローは以下の通りです。
-
1つの投稿と1つの言語から始める
- さまざまなコンテンツタイプ(テキスト、画像、リンクなど)を含む代表的な投稿を選ぶ
- よく理解している1つのターゲット言語に翻訳する
- 翻訳を詳細に検証する: すべてのブロック、リンク、画像、メタデータをチェックする
- 問題が見つかった場合(例: ブロックが翻訳されなかった、リンクが置換されなかった、書式が崩れた)は、続行する前に修正する。今修正しないと、同じ問題がすべての言語に複製されます。
-
さらにいくつかの投稿に拡大する
- 最初の翻訳が完璧になったら、同じ言語にさらに3〜5個の投稿を翻訳する
- 各投稿を徹底的に検証する
- これにより、パターンや繰り返し発生する問題を特定できる
-
追加の言語でテストする
- 複数の言語に翻訳する場合は、異なる言語ペア間ですべてが機能することを確認するためにもう1つの言語でテストする
-
その後、一括翻訳に進む
- すべてが正しく機能することを確認できたら、ウェブサイトの残りを翻訳する
この段階的なアプローチにより、設定の問題やコンテンツの問題が早期に検出され、修正が簡単な段階で対処できます。
翻訳順序
異なるコンテンツタイプを翻訳する順序は重要です。特にコンテンツが他のコンテンツを参照している場合はなおさらです。
参照の問題を避けるために、以下の特定の順序でコンテンツを翻訳してください。
-
Users
- ユーザーの説明がブロックに含まれている場合がある
-
Taxonomies(タグ・カテゴリー)
- タグとカテゴリー(およびカスタムタクソノミー)は多くの場合投稿から参照されるため、投稿を翻訳する前に存在している必要がある
-
Media
- メディアアイテム(画像、動画、ドキュメント)は投稿からアイキャッチ画像やギャラリー画像として参照されるため、投稿の前に翻訳する
-
カスタム投稿タイプ
- 投稿、ページ、その他のCPTを翻訳する
- 重要: あるCPTが別のCPTを参照している場合は、依存関係の逆順に翻訳する
- 例: 投稿が再利用ブロックを使用している場合は、再利用ブロックを先に翻訳してから投稿を翻訳する
-
メニュー
- 投稿、ページ、カテゴリーを参照するため、メニューは最後に翻訳する
スラッグを翻訳するかどうかを決める
投稿とタクソノミーのスラッグをターゲット言語に翻訳することは、ラテン文字の言語(フランス語、ドイツ語、スペイン語など)では望ましいことが多いです。パスが読みやすく、URLにローカライズされたキーワードを反映できます。
ラテン文字以外のスクリプト(ヘブライ語、日本語、中国語など)では、ローカライズされたスラッグは混乱を招くことが多いです。ぎこちない音訳、非常に長いセグメント、パーセントエンコーディング、または共有・比較しにくいURLになる場合があります。多くのチームはそのような言語にはラテン文字(または元の言語)のスラッグを維持し、表示されるローカライズされた名前には翻訳されたタイトルに依存します。
スラッグの翻訳はターゲット言語ごとのポリシーとして扱い、サイト全体の単一のオン/オフスイッチとして扱わないでください。
- 言語をグループに分ける — 例: ラテン語ターゲットには「スラッグを翻訳する」、中国語、日本語、ヘブライ語などには「スラッグを翻訳しない」
- 翻訳バッチを分けて実行する — スラッグ翻訳を有効にして1つのグループに一括翻訳し、スラッグ翻訳をオフにして別のグループに別のバッチを実行する
- 各バッチを設定する — Gato Translate (Custom) 経由(以下の翻訳の実行方法で説明): スラッグを変更せずに維持したいバッチでは Translate custom post slugs? と Translate tag and category slugs? などのオプションを無効にする。設定が期待する結果と一致するように、1回の実行につき1つのポリシー(例: 1つの言語または同じルールを共有する言語グループ)を目指す。
スクリプト化された繰り返し可能なワークフローでは、WP-CLI が呼び出しごとに --translate-slugs=true または --translate-slugs=false をサポートしています。
2パス翻訳
内部リンク置換またはエンティティ参照翻訳を有効にしている場合、2パスで翻訳する必要があるかもしれません。
パス1: プロパティのみを翻訳する
- コンテンツとメタを除外するように翻訳を設定する。つまり、プロパティのみ(タイトル・名前とスラッグ)を翻訳する
- 翻訳を実行する

最初のパスを実行すると、翻訳された投稿が翻訳されたURLとIDで作成され、内部リンクURLとエンティティ参照IDをターゲット言語に解決できるようになります。
パス2: コンテンツとメタのみを翻訳する
- コンテンツとメタのみを翻訳するように翻訳を設定する(つまりプロパティを除外する)
- 再度翻訳を実行する

2番目のパスを実行すると、残りのコンテンツとメタが翻訳され、内部リンクURLとエンティティ参照IDが翻訳バージョンに置換されます。
翻訳の実行方法
オプション1: WordPress管理画面(一括操作)
- コンテンツリスト(投稿、ページ、メディアなど)に移動する
- 翻訳したいアイテムを選択する
- 一括操作ドロップダウンから Gato Translate を選択する
- 適用をクリックする

メニューは異なる方法で翻訳されます。メニューエディターで保存すると自動的に翻訳されます。
代替: Gato Translate (Custom)
より詳細なコントロールのために、特定の翻訳実行の設定をオーバーライドできる Gato Translate (Custom) を使用します。

これにより、その翻訳実行の特定のオプションを指定できるカスタム設定ページが開きます。

オプション2: WP-CLI(大規模バッチ向け)
数百または数千のアイテムを持つ大きなウェブサイトには、WP-CLI が便利な代替手段です。
コマンドラインでバッチ翻訳を実行して、他の作業をしながらバックグラウンドで翻訳を実行できます。

翻訳ログの確認
翻訳が失敗した場合(APIがオフラインになった、APIクレジットが不足したなど)または警告が生成された場合、プラグインメニューに通知バッジが表示されます。

何が起きたかを理解するために翻訳ログを確認してください。
- プラグインメニューの Logs メニュー項目に移動する
- エラーや警告を確認する
- 続行する前に問題を修正する


失敗した翻訳の再実行
翻訳が失敗した場合、そのエントリーと言語のみの翻訳を再トリガーすることができ、成功した翻訳のAPIクレジットを消費しなくて済みます。
失敗した翻訳はPolylang編集アイコンに黄色の背景で強調表示されます。

失敗した翻訳のあるエントリーのみを表示するようにフィルタリングできます。

失敗したエントリーのみを再翻訳するには、Process failed translations only オプションを付けた Gato Translate (Custom) 一括操作を使用します。


翻訳の品質と完全性を検証する
コンテンツを翻訳した後は、翻訳が成功し、品質が良いことを検証することが重要です。すべてが完璧に機能したと仮定しないでください。時間をかけて確認してください。
エディターでの検証:
WordPress エディターで翻訳済み投稿を開いて確認してください。
-
コンテンツの翻訳
- すべてのテキストが翻訳されているか?(タイトルだけでなく)
- すべてのブロック・ウィジェット・エレメントが翻訳されているか?
- Gutenbergブロック、Elementorウィジェット、Bricksエレメントを確認する
- 書式が維持されていることを確認する
-
カスタムフィールド
- ACFフィールドが正しく翻訳・コピー・参照されているか?
- Meta Boxフィールドが適切に処理されているか?
- カスタムメタフィールドが正しく設定されているか?
-
SEOメタデータ
- メタタイトルが翻訳されていることを確認する
- メタディスクリプションが翻訳されていることを確認する
- Open Graphタグが翻訳されていることを確認する
- その他のSEOプラグインフィールドを確認する
-
メディア
- アイキャッチ画像が正しく設定されているか?
- コンテンツ内の画像が翻訳バージョンを指しているか(該当する場合)?
- 画像のaltテキストが翻訳されているか?
-
リンク
- 内部リンクが翻訳バージョンを指しているか?
- 外部リンクが正しく維持されているか?
- カテゴリー・タグのリンクは機能するか?
フロントエンドでの検証:
ブラウザで翻訳済み投稿を表示して確認してください。
-
ビジュアルの外観
- ページは正しく表示されているか?
- レイアウトは維持されているか?
- 画像は正しく表示されているか?
- スタイリングは正しいか?
-
テンプレートの適用
- 正しいテンプレートが使用されているか?
- ヘッダー・フッターは正しく表示されているか?
- サイドバー・ウィジェットは表示されているか?
- メニューは翻訳バージョンを表示しているか?
-
機能性
- すべてのリンクは機能するか?
- フォームは機能しているか?
- インタラクティブな要素は機能するか?
- ナビゲーションは正しいか?
-
言語固有の要素
- RTL言語の場合、レイアウトは正しいか?
- フォントは正しくレンダリングされているか?
- テキストの方向は正しいか?
翻訳の品質:
最新のAI翻訳は一般的に非常に良質ですが、以下の点は引き続き確認してください。
-
理解できる言語
- 知っている言語の翻訳を読み通す
- 正確さ、トーン、スタイルを確認する
- 技術用語が正しいことを確認する
- ブランドの声が維持されていることを確認する
-
理解できない言語
- 話せない言語については、ネイティブスピーカーにレビューを依頼することを検討する
- これは自分の言語と大きく異なる言語(英語から韓国語、中国語、アラビア語など)にとって特に重要
- 簡単なレビューでも主要な問題を発見できる
- 重要なコンテンツには専門的な校正が推奨される
-
ドメイン固有のコンテンツ
- 技術的なコンテンツには専門家のレビューが必要な場合がある
- 法律・医療コンテンツはプロフェッショナルによるレビューが必要
- マーケティングコンテンツはブランドの声の調整が必要な場合がある
「無効なコンテンツ」ブロックの修復
多くのタグや属性を含む大きなHTMLブロックを翻訳する際、AIサービスがブロックの出力を壊すレスポンスを返すことがあります。
例えば、以下のような非常に大きなHTMLブロブを含む core/paragraph ブロックをChatGPT 5.0 miniで翻訳する場合:
<!-- wp:paragraph -->
<p>
Pédagogie:
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★★★
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">☆</mark></mark></mark></mark></mark></mark></mark><strong><br></strong>Support :
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★★★
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">☆</mark></mark></mark></mark></mark></mark></mark><br>Coûts :
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★★★
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">☆</mark></mark></mark></mark></mark></mark></mark><br>Débouchés :
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★★★
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">☆</mark></mark></mark></mark></mark>
</p>
<!-- /wp:paragraph -->...レスポンスが元のコンテンツになかった余分な <mark> タグを導入することがあります。
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">★★
+<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">
<mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-luminous-vivid-amber-color">WordPress エディターで投稿を編集する際、そのブロックがレンダリングに失敗し、「Block contains unexpected or invalid content」というメッセージが表示されることがあります。

Attempt recovery をクリックすると、ほとんどの場合問題が解決します。
可能であれば、HTMLブロックの使用は避けてください。HTMLブロック全体を単一のユニットとして翻訳する必要があります。
代わりにプロパティを持つカスタムブロックを使用すると、翻訳可能な文字列を特定・抽出・翻訳でき、書式を壊すことがありません。
破損データエラーのトラブルシューティング
翻訳中にコンテンツに破損したデータや古いデータが含まれているためにエラーが発生することがあります。これは通常以下の場合に起こります。
- 投稿タイプが以前は機能(親投稿など)をサポートしていたが、現在はサポートしていない
- コンテンツが存在しないエンティティを参照している
- 移行やプラグインの変更によるデータベースの不整合
- カスタムフィールドの孤立した関係
エラーの理解:
ログにこのようなエラーが表示された場合:
2025-10-25T03:40:38+00:00 Error [Query "create-missing-translation-media"] Execution with errors: 🔴 Object with ID '26061' (of type 'GenericCustomPost') cannot be loaded. Please check if referencing this ID is stale data (i.e. still stored on the WordPress database, but pointing to a non-existing object) and, if so, remove it or fix it.これが意味すること:
- コンテンツがID 26061のエンティティ(投稿、ページ、メディアなど)を参照している
- そのエンティティはもうデータベースに存在しない
- プラグインは参照を解決できないため翻訳できない
修正方法:
方法1: WordPressエディター(最も簡単)
- 翻訳に失敗している投稿・アイテムを開く
- 破損した参照を特定する(カスタムフィールド、リレーションシップなどを確認)
- 参照を削除または修正する
- 投稿を保存する
- 再度翻訳を試みる
方法2: データベースのクリーンアップ
エディターで修正できない場合:
- 不正な参照を含むフィールドを特定する
- データベースツールまたはプラグインを使用して古いデータを削除する
- 注意: データベースの変更を行う前に必ずバックアップを取ること
方法3: Gato GraphQL(上級者向け)
Gato AI Translations for Polylang は内部で Gato GraphQL を使用しているため、GraphQLクエリを実行して破損データをプログラム的に修正できます。
-
まず、GraphQLクエリを使用して問題のあるアイテムのIDを取得します。
-
次に、ミューテーションを使用して問題を修正します。例えば、メディアアイテムから親参照を削除するには:
mutation {
updateMediaItem( input: { id: 26066, customPostID: null } ) {
status
errors {
__typename
...on GenericErrorPayload {
message
}
}
}
}修正できない場合:
破損データをクリーンアップできない場合は、以下が必要になる場合があります。
- 投稿・アイテムをゼロから再作成する
- コンテンツをエクスポートし、クリーンアップして再インポートする
- 複雑なケースはサポートに連絡して支援を求める
翻訳されたエントリーを設定に統合する
コンテンツを翻訳した後、新しく作成された翻訳エントリーをウェブサイトの設定に統合する必要がある場合があります。
ACFフィールドグループの更新
ACFフィールドグループは特定の投稿、ページ、カテゴリー、タグ、その他のエンティティに割り当てることができます。コンテンツを翻訳すると、翻訳バージョンも同じフィールドグループに割り当てる必要がある場合があります。
翻訳後、ACFフィールドグループの割り当てを更新して翻訳バージョンを含めます。
- ACFプラグインメニューの Field Groups メニュー項目に移動する
- 特定のエンティティに適用するフィールドグループを編集する
- Location Rules で翻訳バージョンを追加する
- フィールドグループを保存する
例:
フィールドグループが元の言語の特定の投稿 「Hello World」 に適用されています。

投稿を翻訳した後、翻訳バージョン(スペイン語の 「Hola Mundo」 と中国語の 「你好世界」)も同じフィールドグループに割り当てる必要があります。

完了です!
翻訳プロセスが完了しました。おめでとうございます! 👏
まとめ
この総合ガイドにより、WordPressウェブサイトの翻訳を成功させることができるはずです。詳細については、Gato AI Translations for Polylang のドキュメントをご確認ください。