午後9時にクライアントからメール：「来四半期に日本語対応できる？」胸が締め付かられます。マルチサイトネットワークはすでに12言語で動作が遅い。先月、WPMLのアップデートでポーランド語レイアウトが壊れた。共有wp_optionsテーブルは840MBに肥大化し、ステージング環境のクローンに11分かかります。この構成は3回パッチを当てている。言語をローンチするたびに次の問題が難しくなる。私たちはこの正確なセットアップを実行していました — 91,000ページ以上、30言語、エンタープライズレベルの負荷 — そしてマルチサイトとWPMLの両方を完全に廃止しました。プラグインの更新なし。共有テーブルなし。言語間の干渉なし。新しいスタックはより速くデプロイでき、ホスティング費用は40%削減でき、懸念なくスケールします。実際にデプロイした構成、移行で何が破損したか、それを機能させた4つの決断をここに示します。

私たちはそのやり方をやめました。今日、本番システムはロケールあたり118ページ以上 — 合計91,000ページ以上の動的ページ — をWordPressマルチサイトなし、WPMLなし、どちらのライセンス更新の不安もなく30言語で提供しています。新しい言語を追加するには約45分かかり、APIトークンで約22ドルのコストがかかります。

この記事は完全な内訳です。構成、ツール、コスト、そして複数のエンタープライズプロジェクトで洗練された移行経路です。

目次

WordPressマルチサイトがスケールで崩壊する理由

WordPressマルチサイトは2010年に単一インストールで複数のブログを実行するために設計されました。真のマルチリンガルエンタープライズ展開を想定した構成ではありません。これをプッシュするとどうなるか：

共有データベース、共有の問題。 マルチサイトネットワーク内のすべてのサイトは、プレフィックス付きテーブル（wp_2_posts、wp_3_postsなど）を持つ同じwp_データベースを共有します。クロスサイトコンテンツ共有は脆弱です。1つのサイトのプラグイン更新は、ネットワーク全体で連鎖的な障害を引き起こす可能性があります。1つの不正な形式のマイグレーションスクリプトが12言語バリアント全体を同時にダウンさせるのを見てきました。

管理の複雑さが増します。 各サブサイトには独自の管理ダッシュボードがありますが、完全に分離されているわけではありません。スーパー管理者はすべてを見ます。サイト管理者は見ることが少なすぎます。カスタムロール管理なしで、ドイツ語のコンテンツチームに彼らのコンテンツだけへのアクセスを与えるきれいな方法はありません。それは主要なWordPress更新のたびに壊れます。

プラグイン互換性は地雷原です。 すべてのプラグインがマルチサイト互換ではありません。スペイン語サイトがマルチサイトと相性の悪いフォームプラグインが必要な場合、機能と安定性の間で選択することになります。これを10言語以上で乗算します。

実際のAPI-firstアーキテクチャはありません。 はい、WP REST APIが存在します。しかし、最新のマルチリンガルサイトが要求するロケール対応、エッジデプロイ、CDNキャッシュコンテンツ配信の種類のために設計されていません。キャッシングとカスタムエンドポイントのレイヤーをボルトオンで追加することになり、それ自体が保守上の負担になります。

WPMLとWordPressマルチリンガルプラグインの実際のコスト

数字を見てみましょう。WordPressマルチリンガルのストーリーがどこで不快になるかについて。

WPMLライセンス：年間199ドル マルチリンガルエージェンシープランの開始。これは真剣なマルチリンガル作業の開始点です。そしてサイトごと — またはマルチサイトのネットワークごと、これは良く聞こえるまで、あなたが永遠に彼らの更新サイクルにロックインされることに気づきます。

パフォーマンスへの影響：20～40%の低速ページロード。 複数のクライアントサイト全体でこれをベンチマークしました。WPMLは、すべてのページロードで追加のデータベースクエリを追加して、翻訳を解決し、言語を切り替え、文字列翻訳を管理します。コンテンツの多いページでは、それは数十の余分なクエリです。LCPスコアが低下します。ユーザーはそれに気づきます。

翻訳管理コストは実際のキラーです。 専門的な翻訳機関は単語あたり0.10～0.20ドルを請求します。10言語で約50,000語のコンテンツを持つエンタープライズサイトの場合：

  • 低い推定：50,000 × $0.10 × 10 = 年間50,000ドル
  • 高い推定：50,000 × $0.20 × 10 = 年間100,000ドル

そしてこれはただの初期翻訳です。コンテンツの更新、新しいページ、ブログ投稿 — すべてが翻訳パイプラインに戻る必要があります。

もっと良い方法があります。

モダンアーキテクチャ：Next.js + next-intl + ヘッドレスCMS

ここに、エンタープライズ展開全体で構築およびテストされたスタック：

┌─────────────────────────────────────────────┐
│              Edge / CDN Layer                │
│         (Vercel / Cloudflare)               │
├─────────────────────────────────────────────┤
│           Next.js Application               │
│    ┌─────────────────────────────────┐      │
│    │    next-intl (i18n routing)     │      │
│    │    /en/about  /de/ueber-uns    │      │
│    │    /ja/about  /ar/about        │      │
│    └─────────────────────────────────┘      │
├─────────────────────────────────────────────┤
│         Headless CMS / Supabase             │
│    ┌──────────┐  ┌──────────────────┐      │
│    │  Content  │  │  Translation     │      │
│    │  Models   │  │  Tables (i18n)   │      │
│    └──────────┘  └──────────────────┘      │
├─────────────────────────────────────────────┤
│        AI Translation Pipeline              │
│    (Claude API → Review → Publish)          │
└─────────────────────────────────────────────┘

重要な洞察：コンテンツ管理を翻訳管理からプレゼンテーションへ分離します。 各レイヤーは独立して進化できます。コンテンツに触れずにCMSをスワップアウト。コンテンツを移行せずにフロントエンドフレームワークを変更。コードに触れずに言語を追加します。

next-intl設定

ルーティングセットアップの実際の動作方法：

// src/i18n/routing.ts
import { defineRouting } from 'next-intl/routing';

export const routing = defineRouting({
  locales: [
    'en', 'es', 'fr', 'de', 'pt', 'it', 'nl', 'sv', 'no', 'da',
    'fi', 'pl', 'cs', 'ro', 'tr', 'ar', 'hi', 'ja', 'ko',
    'zh-CN', 'zh-TW', 'th', 'vi', 'id', 'ms', 'ru', 'uk'
  ],
  defaultLocale: 'en',
  localePrefix: 'as-needed'
});

// src/middleware.ts
import createMiddleware from 'next-intl/middleware';
import { routing } from './i18n/routing';

export default createMiddleware(routing);

export const config = {
  matcher: ['/', '/(de|es|fr|ja|...)/:path*']
};

これにより、きれいなURL構造が得られます：/en/services、/de/dienstleistungen、/ja/サービス。各ロケールは独自に静的生成されたページを取得し、エッジから提供されます。言語解決のランタイムでのデータベースクエリはありません。

Supabase翻訳テーブル

シンプルながら効果的なスキーマを持つSupabaseに翻訳を保存します：

CREATE TABLE translations (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  namespace TEXT NOT NULL,
  key TEXT NOT NULL,
  locale TEXT NOT NULL,
  value TEXT NOT NULL,
  updated_at TIMESTAMPTZ DEFAULT now(),
  UNIQUE(namespace, key, locale)
);

CREATE INDEX idx_translations_locale ON translations(locale);
CREATE INDEX idx_translations_namespace ON translations(namespace, locale);

このスキーマは、30言語×数千の翻訳キーをスイング状態なしで処理します。クエリはシンプルで、キャッシュ可能で、高速です。

翻訳パイプラインのセットアップ

翻訳パイプラインはこのアーキテクチャが本当に報酬を与える場所です。ワークフローは次のようになります：

  1. コンテンツはヘッドレスCMSで英語で作成されます
  2. ビルドスクリプトが抽出します JSONファイルにすべての翻訳可能な文字列
  3. Claude APIが翻訳します ターゲットロケールごとに各JSONファイル
  4. レビューステップ （オプション、重要なコンテンツの場合）人間の編集者が翻訳を承認できます
  5. 翻訳がコミットされます リポジトリに、またはSupabaseにプッシュされます
  6. Next.jsが再構築します ISRまたは完全な再構築を介して影響を受けたページ
// scripts/translate.ts
import Anthropic from '@anthropic-ai/sdk';
import { readFileSync, writeFileSync } from 'fs';

const anthropic = new Anthropic();

async function translateFile(sourcePath: string, targetLocale: string) {
  const source = JSON.parse(readFileSync(sourcePath, 'utf-8'));
  
  const message = await anthropic.messages.create({
    model: 'claude-sonnet-4-20250514',
    max_tokens: 4096,
    messages: [{
      role: 'user',
      content: `Translate the following JSON values (not keys) to ${targetLocale}. 
      Maintain the exact JSON structure. Use natural, professional language 
      appropriate for a corporate website. Preserve any HTML tags or 
      interpolation variables like {name}.
      
      ${JSON.stringify(source, null, 2)}`
    }]
  });
  
  const translated = JSON.parse(message.content[0].text);
  writeFileSync(
    sourcePath.replace('/en/', `/${targetLocale}/`),
    JSON.stringify(translated, null, 2)
  );
}

これは簡略化されていますが、コアの考え方をキャプチャしています。本番環境では、リクエストをバッチ処理し、レート制限を処理し、出力構造を検証し、自動品質チェックを実行します。

AI翻訳：すべてを変えた経済学

ここで数学は面白くなるところです。

本サイト（118ページ以上、言語ごとに約50,000単語）の従来の翻訳：

  • 言語ごと： $5,000-$10,000（代理店料金）
  • 30言語： $150,000-$300,000
  • 年間更新： $50,000-$100,000

Claudeを使用したAI翻訳：

  • 言語ごと： APIトークンで約22ドル
  • 言語ごとの時間： 約45分
  • 30言語： 合計約660ドル、約22.5時間
  • 新しい言語を追加： 45分、22ドル

これはタイプミスではありません。言語あたり22ドル。

ここで、2026年のAI翻訳が完璧ではないすべての使用例であることを正直に言いたいです。法的文書、医療コンテンツ、ニュアンスの多いマーケティングコピー — これらはまだ人間のレビューから利益を得ます。しかし、企業のウェブサイト、製品説明、ドキュメント、ブログコンテンツの場合？品質は著しく良いです。日本語、アラビア語、ドイツ語でAI翻訳コンテンツをレビューしたネイティブスピーカーを見てきました。フィードバックは一貫して「専門的な品質で時々のフレージングの好み」に着地します。

実際の利点は単なるコストではありません — それはスピードです。新しい英語ページを公開し、30言語で利用可能にしたい場合、数週間ではなく数時間を見ています。代理店調整なし。翻訳メモリ管理なし。用語に関する前後なし。

マルチリンガルコンテンツ向けヘッドレスCMSオプション

ここでは選択肢があり、正しい選択はチームとスケールに依存します。評価した内容は次のとおりです：

プラットフォーム i18nサポート セルフホスト 価格（2026年） 最適な用途
Sanity ネイティブフィールドレベル クラウド+セルフホスト 無料層、月額15ドル以上pro 構造化コンテンツ、リアルタイムコラボレーション
Payload CMS ネイティブ、TypeScript はい 無料 / OSS フルコントロールを望む開発チーム
Strapi プラグインベースi18n はい 無料 / OSS すでにStripiエコシステムにいるチーム
Storyblok ネイティブフィールドレベル クラウドのみ 月額106ドル以上 ビジュアル編集、マーケティングチーム
Supabase（raw） カスタムスキーマ はい 無料層、月額25ドル以上 最大柔軟性、開発者向けチーム

ヘッドレスCMS開発プロジェクトの場合、通常はコンテンツの多いサイトにはSanityまたはPayloadを推奨し、チームが翻訳パイプラインを最大限に制御したい場合は直接Supabaseを推奨します。

重要な区別：ヘッドレスアプローチでは、CMSがコンテンツストレージと編集ワークフローを処理します。翻訳管理はアプリケーションレイヤーに住んでいます。この分離は、CMSベンダーのマルチリンガルコンテンツが機能するべき方法の考えにロックインされることはないことを意味します。

ステップバイステップ：30言語サイトの構築

マルチリンガルウェブサイト開発のためにフォローする実際のプロセス：

ステップ1：ロケール戦略を定義

コードを書く前に、以下を決定してください：

  • 実際にどの言語が必要ですか？（分析をチェック）
  • ローカライズされたURL（/de/kontakt）またはサブドメイン（de.example.com）を使用しますか？
  • リージョンバリアント（en-US対en-GB）またはまだ言語コードが必要ですか？
  • どのコンテンツが翻訳される対ロケール固有のコンテンツですか？

パスベースルーティング（/de/、/ja/）をデフォルトにします。これはSEOが簡単で、単一ドメインにデプロイしやすく、Next.jsミドルウェアで自然に機能するためです。

ステップ2：next-intlで Next.jsをセットアップ

インストールして設定：

npm install next-intl

メッセージディレクトリを構成：

messages/
├── en.json
├── de.json
├── ja.json
├── ar.json
└── ... (30ロケールファイル)

各ファイルは名前空間付き翻訳を含みます：

{
  "navigation": {
    "home": "Home",
    "about": "About Us",
    "services": "Services",
    "contact": "Contact"
  },
  "hero": {
    "title": "Enterprise Web Development",
    "subtitle": "Built for performance, designed for scale"
  }
}

ステップ3：翻訳パイプラインをビルド

スクリプトを作成します：

  1. 英語のソースファイルを読む
  2. Claude APIに翻訳用に送信
  3. 出力JSON構造を検証
  4. ロケールファイルを書き込み
  5. 自動品質チェック（欠落キー、破損した補間変数）を実行

ステップ4：hlangとSEOを実装

これは多くのマルチリンガル実装が不足している場所です。すべてのページに適切なhreflangタグが必要です：

// src/components/LocaleHead.tsx
export function LocaleHead({ currentLocale, path }: Props) {
  const locales = routing.locales;
  
  return (
    <>
      {locales.map((locale) => (
        <link
          key={locale}
          rel="alternate"
          hrefLang={locale}
          href={`https://example.com/${locale}${path}`}
        />
      ))}
      <link
        rel="alternate"
        hrefLang="x-default"
        href={`https://example.com${path}`}
      />
    </>
  );
}

ステップ5：RTL言語を処理

アラビア語、ヘブライ語、またはその他のRTL言語（アラビア語をサポート）をサポートしている場合、方向性のあるCSSが必要です：

// src/app/[locale]/layout.tsx
export default function LocaleLayout({ children, params: { locale } }) {
  const direction = ['ar', 'he', 'fa'].includes(locale) ? 'rtl' : 'ltr';
  
  return (
    <html lang={locale} dir={direction}>
      <body className={direction === 'rtl' ? 'font-arabic' : 'font-sans'}>
        {children}
      </body>
    </html>
  );
}

Tailwind CSS v4はネイティブにrtl:バリアントをサポートしており、方向性スタイルを管理しやすくします。

ステップ6：デプロイしてモニター

Vercel上のNext.jsで、各ロケールのページは静的に生成され、ユーザーに最も近いエッジノードから提供されます。ドイツ語ユーザーが/de/dienstleistungenにヒットすると、フランクフルトのエッジノードから100ミリ秒以内で応答が得られます。データベースクエリなし。WPMLのルックアップなし。ただの静的HTML。

移行経路：WordPressからヘッドレスマルチリンガル

WordPress MultiサイトでWPMLを現在実行している場合、複数のクライアントプロジェクト全体で洗練された移行経路をここに示します。詳細については、WordPressからNext.js移行ガイドを参照してください。

週1-2：コンテンツエクスポートと監査

  • WP REST API経由ですべてのコンテンツをエクスポート（WPML翻訳を含む）
  • コンテンツタイプをヘッドレスCMSモデルにマップ
  • 孤立した翻訳とコンテンツギャップを特定
  • 301リダイレクトのすべてのURLパターンを文書化

週2-4：ヘッドレスCMSセットアップとコンテンツのインポート

  • 選択したヘッドレスCMSでコンテンツモデルを構成
  • 英語のソースコンテンツをインポート
  • Supabase翻訳テーブルをセットアップ
  • すべてのターゲット言語のAI翻訳パイプラインを実行

週4-6：フロントエンドビルド

  • next-intlを使用してNext.jsアプリケーションをビルド
  • すべてのページテンプレートを実装
  • hlangタグとサイトマップ生成を構成
  • 新しいコンテンツの自動翻訳パイプラインをセットアップ

週6-8：テスト、リダイレクト、ローンチ

  • ブラウザクロスとロケールクロステスト
  • 古いURLパターンから301リダイレクトを実装
  • 更新されたサイトマップをGoogle Search Consoleに送信
  • インデックス作成とローンチ後のトラフィックパターンを監視

総期間：コンテンツボリュームと複雑さに応じて4～8週間。TYPO3からNext.js移行も同様のパターンに従ったクライアントを処理してきました。

コスト比較：WordPressマルチサイト対ヘッドレスマルチリンガル

ここに10言語エンタープライズサイトの3年間の正直なコスト内訳：

コストカテゴリ WordPress Multisite + WPML Next.js + Headless + AI Translation
CMSライセンス（3年） $0（WPは無料） $0-$540（Sanity pro）または$0（Payload OSS）
WPMLライセンス（3年） $597 $0
専門翻訳（初期） $50,000-$100,000 $220（AI、10言語×22ドル）
翻訳更新（3年） $30,000-$60,000 $500（推定AIコスト）
ホスティング（3年） $3,600-$7,200（管理WP） $0-$720（Vercelフリーproティア）
開発（初期ビルド） $30,000-$60,000 $40,000-$70,000
メンテナンス（3年） $18,000-$36,000 $6,000-$12,000
3年間の総コスト $132,197-$263,797 $46,720-$83,460

ヘッドレスアプローチの開発コストは初期段階でわずかに高くなります — プラグインを構成する代わりにカスタムインフラストラクチャを構築しています。ただし、進行中の節約は劇的です。WPMLの更新なし。翻訳機関の請求書なし。マルチサイトメンテナンスの頭痛なし。

このアプローチの探索に興味のある組織では、マルチリンガルコーポレートウェブサイトソリューションをチェックアウトするか、ご連絡を取得して、特定の要件について議論してください。

パフォーマンスベンチマーク

本番マルチリンガルサイト全体でLighthouseオーディットを実行し、同等のWordPress Multisite + WPMLの実装と比較しました：

メトリック WordPress + WPML Next.js + next-intl
LCP（最大コンテンツフル塗料） 2.8-4.2秒 0.8-1.2秒
FID（最初の入力遅延） 120-280ミリ秒 10-40ミリ秒
CLS（累積レイアウト変位） 0.12-0.25 0.01-0.05
最初のバイトの時間（TTFB） 800-1,400ミリ秒 50-150ミリ秒
Lighthouse パフォーマンススコア 45-65 95-100
言語ごとのページ 約118 約118
インデックス付きページ合計 約1,180（10言語） 91,000以上（30言語）

TTFBの差だけで移行の価値があります。ページが静的に生成され、エッジCDNから提供される場合、WordPressのブートを待つ必要はありません。WPMLを読み込み、データベースをクエリし、翻訳を解決し、テンプレートをレンダリングします。HTMLは単に...そこです。

Astroで構築されたサイトの場合、ゼロJavaScriptバイデフォルトレンダリングのおかげで、数値はさらに積極的です。

FAQ

AI翻訳はエンタープライズウェブサイトに十分な品質ですか？

ほとんどの企業コンテンツの場合 — はい。2026年では、ClaudeとGPT-4は、ネイティブスピーカーが専門的な品質として評価する翻訳を、ビジネスコンテンツ、製品説明、ドキュメントに対して製造しています。日本語、アラビア語、韓国語、中国語（簡体字と繁体字の両方）を含む30言語でAI翻訳をデプロイし、ネイティブスピーカーのレビュアーからの肯定的なフィードバックをしてきました。法的、医療、または高度に規制されたコンテンツはまだ人間のレビューを保証するかもしれません。しかし、AI+人間のレビューでさえ、純粋な人間翻訳よりもはるかに安いです。

ヘッドレスマルチリンガルサイトに新しい言語を追加するコストはどのくらいですか？

パイプラインで、新しい言語を追加するのにClaudeAPIトークンで約22ドル、エンジニアリング時間で約45分かかります。これは、すべてのページコンテンツ、ナビゲーション、メタデータ、UI文字列を翻訳することをカバーしています。WPMLのサイトごとのライセンス加えて、典型的なエンタープライズサイトの専門翻訳費用$5,000-$10,000と比較してください。

マルチリンガルサイト向けの最高のWordPress Multisite代替案は何ですか？

エンタープライズデプロイの場合、ヘッドレスCMS（Sanity、Payload、またはStrapi）は、Next.jsとnext-intlとペアになっています。最も柔軟で高性能なアーキテクチャを提供しています。真のコンテンツ/プレゼンテーション分離を取得し、エッジ展開ページを取得し、CMSとは独立して翻訳を管理できます。50ページ以下のサイトの単純化については、Webflowのローカライズ機能がありますが、エンタープライズスケールで迅速に制限にヒットします。

30言語以上の言語バージョンのSEOをどう処理しますか？

すべてのページはすべての言語バリアントを指す適切なhreflangタグプラスx-defaultタグを生成します。ロケールごとのXML サイトマップを生成し、Google Search Consoleに送信します。各ロケールには独自のメタタイトル、説明、Open Graphタグが取得されます — すべてAIパイプラインを通じて翻訳されます。Googleは30言語バリアント全体で91,000ページ以上のインデックスを作成しています。

WordPress MultiサイトからヘッドレスへのSEOランキングを失うことなく移行できますか？

はい、ただし慎念深い計画が必要です。重要なステップは、古いURLから新しいロケール前置URLへの包括的な301リダイレクトマッピング、最初の日から適切なhlangの実装、ローンチ直後に更新されたサイトマップの送信です。通常、1～3週間のインデックス遷移期間が見られ、その後、より優れたCore Web Vitals スコアのためにランクの改善が続きます。WordPress to Next.js移行プロセスは、このために特別に設計されています。

2026年の最高のWPML代替案は何ですか？

Next.jsアプリケーション用のnext-intl、またはNuxtアプリケーション用のnuxt-i18n。両方とも、フレームワークレイヤーでロケールルーティング、メッセージフォーマット、SEOメタデータをネイティブに処理します — WordPressプラグインのパフォーマンスオーバーヘッドなし。WPMLとは異なり、年間ライセンス費用はありません。データベースのオーバーヘッドはありません。他のプラグインとの互換性の問題はありません。i18nロジックは、属する、アプリケーションコードに住んでいます。

30言語全体で翻訳品質をどう管理しますか？

多層アプローチを使用します：ベースレイヤーとしてのAI翻訳、自動化品質チェック（JSON構造検証、補間変数保存、長さ比較）、および高可視性コンテンツ（ホームページの見出しとCTAなど）の任意のオプション人間のレビュー。また、言語ごとの用語集を保守し、AIにコンテキストとして渡します。ブランド用語、製品名、技術語彙が一貫して処理されることを確認します。

頻繁なコンテンツ更新があるサイトに対してこのアプローチは実行可能ですか？

絶対に — それはWPMLよりも頻繁な更新に実際に良いです。英語ページを公開または更新すると、翻訳パイプラインはWebhook経由で自動的に実行できます。新しい翻訳は数分で生成されます。日ではなく。Next.jsのISR（増分静的再生成）では、更新されたページは完全なサイト再構築なしで上線に行きます。毎日ブログ投稿を公開し、1時間以内に30言語で表示され、同じ日に検索エンジンによって完全にインデックス付けされているクライアントがいます。