Deveniaの多言語WordPressガイド

多言語対応の課題

多言語WordPressは、単なる翻訳ではありません。WPMLはこのサイトを破損させました。Polylangは今も私たちが推奨するプラグインであり、Deveniaは現在、URL、メニュー、リンク、hreflang、品質確認、レビューを管理する独自のAI支援型言語ワークフローを使用しています。
Generated editorial image for this article showing a multilingual WordPress publishing workflow with connected pages, language nodes, menus, and review checkpoints.

多言語WordPressは公開アーキテクチャです

多言語WordPressサイトを作りたいのですね。いいでしょう。かなり思い切った選択です。

多言語WordPressは非常にうまく機能します。しかし、言語レイヤーがコンテンツ、URL、メニュー、SEOシグナルを過度に制御すると、プラグインを中心にした落とし穴にもなり得ます。

あなたが決めること

言語ワークフローのどの部分にプラグインの支援が必要か。
どの部分に編集上の管理、品質確認、人の判断が必要か。
言語レイヤーが停止した場合、サイトはどの程度の運用リスクに耐えられるか。

2026年に私たちのワークフローが変わった点

これは実体験に基づく警告です。WPMLはこのサイトを破損させました。Polylangは、私たちが一般用途で最も推奨する多言語プラグインになりました。そして今、その教訓を基に独自のAI支援型言語ワークフローを構築しています。

基盤としてのPolylang

独自システムの外では、Polylangが今も私たちの推奨する多言語プラグインです。言語ごとに投稿を分けることで、確認、修復、コンテンツ構造の理解がしやすくなるためです。

AI支援型ワークフロー

Deveniaは現在、このサイトを複数の言語で公開・保守するための独自のAI支援型言語ワークフローを運用しています。翻訳ツールに文章を貼り付けて、うまくいくことを期待するのではなく、実際の運用に耐えるワークフローです。

最終判断は人が行います

市場への適合、トーンと用語、商業的な判断、根拠と事例、最終的な編集レビューには、今も人の関与が必要です。

WPMLがこのサイトを破損させたとき

これは仮定の話ではありません。WPMLはdevenia.comを破損させました。データベースのインデックスが消え、テーブルが壊れ、コンテンツも深刻に破損したため、復旧にはデータベース専門家の作業が必要でした。

私たちはMySQL管理者に対応を依頼せざるを得ませんでした。管理者は何日もかけて、破損した本番データベースとバックアップから復元できるものをつなぎ合わせました。バックアップにも同じ障害による損傷がありました。一部のコンテンツは復元できましたが、残りは永久に失われました。

発生したこと

DBインデックス：消失。
データベースのテーブル：破損。
コンテンツ：通常の方法では修復できないほど破損。
長年の作業成果：一部を永久に喪失。
サイトを支えるはずの言語レイヤーが、サイトを破損させました。

多言語アーキテクチャを意識して選ぶ

WordPressは標準状態では複数の言語を適切に扱えません。そのため、コンテンツ、URL、メニュー、メタデータ、検索シグナル、編集レビューについて計画が必要です。多くの人は「どのプラグインを使うか」から考えます。それは理解できます。しかし、問題もそこから始まります。

有力なプラグイン候補：

独自のワークフローを除けば、Polylangは今も私たちが一般用途で最も推奨する多言語プラグインです。厳密な編集構造より視覚的な翻訳作業を重視する場合は、TranslatePressが役立つことがあります。qTranslate-XTは構成によっては軽量な選択肢ですが、長期的な保守には注意が必要です。

運用リスク：

WPMLは広く使われていますが、人気と運用上の安全性は同じではありません。広く採用された技術的な判断が、時間の経過とともに悪い選択だったと分かることは少なくありません。

サイトを分ける選択肢：

規模が大きい、重要である、または法的に慎重な対応が必要な多言語プロジェクトでは、WordPress環境を分けることが今も安全な選択になり得ます。

Polylangが有効な理由：

明確なアーキテクチャ、低い運用リスク、優れた編集管理を実現できます。各言語に固有のタイトル、URL、文章、事例、根拠、行動喚起を設定できます。

Polylangだけでは解決しないこと：

メニュー、内部リンク、メタデータ、hreflang、古くなったページ、ローカライズした文章は、引き続き管理する必要があります。

多言語対応は単なる翻訳ではなく、公開設計です。Polylangが堅実な基盤を提供し、管理されたワークフローが公開作業全体の規律を保ちます。

省略できないSEO作業

どのアーキテクチャを選んでも、地味なSEOの基本作業をおろそかにしてはいけません。

言語とURLのシグナル

  • hreflangタグ：検索エンジンが、各ページの対象言語と地域を判断できるようにします。
  • ローカライズしたキーワード：市場が異なれば検索意図も異なり、直訳では対応できないことがほとんどです。
  • 一貫したURL：構造を決めたら、後から安易に変更しないようにします。

信頼とレビューのシグナル

  • ローカライズした根拠：事例、懸念への回答、信頼を生む要素は市場に合わせる必要があります。
  • 内部リンクの修正：翻訳済みページがある場合、翻訳ページからそのページへリンクします。
  • 編集レビュー：優れた多言語公開は文法だけの問題ではありません。その言語を話す実際の購入者がページを信頼できるかどうかが重要です。

サイトを分ける：分離が重要な場合はより安全

規模が大きい、重要である、または法的に慎重な対応が必要な多言語プロジェクトでは、WordPress環境を分けることが今も安全な選択になり得ます。保守作業は増えますが、同じ障害がすべてのサイトに及ぶリスクは下がります。

利点：多言語プラグインに依存しません。
利点：市場ごとに独立して最適化できます。
利点：単一障害点のリスクを下げ、市場ごとの責任範囲を明確にできます。
難点：保守作業と管理すべき更新が増えます。
難点：サイト間を手作業で調整し、hreflangとリダイレクトをより厳密に管理する必要があります。
サイトを分ければ自動的に簡単になるわけではありません。利便性より分離が重要な場合に、より安全な選択となります。

アーキテクチャは、多言語プロジェクトの事業上、法務上、編集上、運用上のリスクに合わせて選ぶべきです。

よくある質問

多言語WordPressは翻訳だけの問題ですか？

いいえ。多言語対応は公開設計です。URL、メニュー、内部リンク、hreflang、古くなったページ、品質確認、ローカライズした文章、編集レビューまでが作業に含まれます。

Deveniaが独自ワークフローの外で今もPolylangを推奨するのはなぜですか？

Polylangでは言語ごとに投稿やページを分けられるため、コンテンツ構造の確認、修復、理解、編集管理がしやすくなります。

AIは人による多言語レビューを代替できますか？

いいえ。AIは管理されたワークフロー内で支援できますが、市場への適合、トーン、用語、商業的な判断、根拠、事例、最終的な編集レビューには人が必要です。

要点

WPMLは避けてください。このサイトを深刻に破損させ、復旧にはデータベース専門家の作業が必要となり、一部のコンテンツは永久に失われました。

1

多言語プラグインが必要な場合はPolylangを使います。独自システムの外では、今も私たちが最も推奨するWordPress多言語プラグインです。

2

翻訳だけでなく、適切なワークフローを使います。URL、メニュー、内部リンク、hreflang、古くなったページ、品質確認、編集レビューまでが作業に含まれます。

3

利便性より分離が重要な場合は、サイトを分けます。

4

人によるレビューを含む管理された公開ワークフロー内で、AIを慎重に使います。

多言語WordPressシステムは、各言語のコンテンツを確認、修復、レビューしやすくし、信頼できる状態に保つべきです。