WordPress 7.0リリース後の開発者情報まとめ（2026年6月版）
2026年5月20日にWordPress 7.0が正式リリースされた。その後1ヵ月の間に、メディア編集の刷新やクライアントサイドでの画像処理、テーマ向けスタイル機能の強化など、開発者にとって見逃せないアップデートが続いている。
本記事では、Developer WordPress News の「What’s new for developers? (June 2026)」を読み解きながら、6月に登場した主要トピックを整理する。プラグイン開発者、テーマ制作者、そしてサイト運営者が押さえておきたいポイントを中心に、実務への影響をわかりやすく解説する。
メディア編集モーダルがデフォルトに、画像処理の進化
画像の切り抜きがより直感的に
Gutenberg 23.3では、画像の切り抜き操作が専用のモーダルウィンドウで行われるようになった。これまでは編集画面内で直接操作していたが、今回の変更により、縦横比の指定や回転、反転、ズーム、メタデータの編集までひとつのモーダルに集約されている。
操作の入り口はこれまで通り「切り抜き」ボタンだが、編集体験は格段に整理された。プラグインで画像編集機能を独自に拡張している場合や、画像メタデータに依存する処理を組んでいる場合は、実際の画像を使ったキーボード操作やタッチ操作のテストが必要だ。
ブラウザ上で画像リサイズを行うクライアントサイド処理
もうひとつ注目したいのが、クライアントサイドメディア処理のテスト呼びかけだ。これは、可能な場合にはブラウザ上で VIPS/WASM パイプラインを使って画像のサブサイズを生成し、必要に応じてサーバーサイド処理にフォールバックする仕組みである。
対応形式はAVIFやWebP、HEIC、Ultra HDR、JPEG XL、GIFから動画への変換など多岐にわたる。ただし、現時点ではChromiumブラウザと最新のGutenbergプラグインの組み合わせに限られ、FirefoxやSafariでは無効、メモリが2GB以下のデバイスではスキップされる。通信速度が遅い場合やContent Security Policyの worker-src が制限的な場合も利用できない。
このデモでは、従来のようにサーバーがすべてのリサイズを担当する方法から、可能なときはブラウザが先に処理を引き受ける流れへの変化を示している。サーバーの負荷軽減とユーザー体験の向上が期待されるが、環境による制限があるため、フォールバックを含めたテストが欠かせない。
プラグインとツールを取り巻く重要な更新
React 19への移行は一時的に巻き戻されたが準備は続く
WordPress 7.0ではReact 19へのアップグレードが計画されていたが、Gutenbergでは一時的にこの変更が巻き戻された。理由は、複数のプラグインがReact 18のJSXランタイムヘルパーをバンドルしており、React 19と同時に読み込むとクラッシュする問題が発生したためだ。
コアチームはWordPress 7.1でのReact 19導入を目指し、より段階的な戦略で進める方針を示している。コンパイル済みのJSXを同梱しているプラグインや、@wordpress/element を使っている場合、またはエディターのプライベートAPIに触れている場合は、引き続きテスト環境で最新のGutenbergを試すことをおすすめする。
Abilities APIの拡充が進行中
Abilities APIはこれまでのラウンドアップでも取り上げられてきたが、6月も継続的に改良が進んだ。ライフサイクルフィルターや入出力のバリデーションフィルター、wp_get_abilities() へのフィルタリングサポート、サイトやユーザー、環境情報のレスポンス拡張、RESTスキーマの堅牢化などが行われている。
能力（アビリティ）を使った実験を始めている開発者は、以前の想定に頼りすぎず、トランクの最新の挙動を確認しておくとよい。
PHPサポートの明確化とUnicodeメールアドレス対応の提案
WordPress 6.9および7.0では、PHP 8.5を完全にサポートすることが正式に明文化された。これにより、古い「ベータサポート」ラベルは廃止され、WordPress 7.0時点での最低動作バージョンはPHP 7.4、推奨はPHP 8.3に整理されている。
一方で、メールアドレスやユーザー名、スラッグにおけるUnicode対応を拡張する提案も公開され、フィードバックが募られている。この提案は is_email() や sanitize_email() などの関数、フィルター、データベース格納、文字の正規化などに影響を及ぼす可能性があり、メールアドレスを扱うプラグインは早めに内容を確認しておく価値がある。
AI Clientを使った画像生成プラグインのチュートリアル
4月・5月のラウンドアップで紹介されたAI ClientとConnectors APIに関する実践的なチュートリアルが登場した。ここでは、画像生成プラグインを構築する方法が解説されており、特に機能検出パターンが参考になる。プラグインは、プロバイダーが設定済みかどうか、そして必要な機能をサポートしているかを確認したうえでUIを表示すべきであり、チュートリアルではメディアライブラリから画像を生成し、添付ファイルとして保存する一連の流れが実装されている。
テーマ開発者向けのスタイルとブロックの改善
単一ブロックインスタンスへの擬似状態スタイルの適用
Gutenberg 23.3では、個別のブロックインスタンスに対して :hover や :focus、:visited といった擬似状態のスタイルを設定できるようになった。これまではサイト全体のブロックすべてに影響するスタイルしか設定できなかったが、この変更により、特定のボタンだけホバー時の色を変えるといった細やかな制御が可能になる。
この機能は、Add supports for pseudo states on single block instances というPRで実装されており、長年課題となっていたインタラクティブな状態の標準化に向けた動きとして注目されている。ボタンやリンク、ナビゲーションのデザインにこだわるテーマ制作者は、Gutenbergでテストしてみるとよい。
レスポンシブ対応のスタイル状態がさらに拡張
レスポンシブかつ状態を考慮したスタイル設定は、Gutenberg 23.2と23.3で大きく前進した。23.2ではグローバルなブロックスタイルに状態付きのレスポンシブ設定が導入され、23.3ではレイアウトのレスポンシブスタイルや、状態選択時に一部のコントロールを隠すUI調整が加えられている。
まだGutenbergプラグインでのテスト段階だが、theme.jsonのプリセットや設定、レイアウトプリセット、ブロックサポート、カスタムレスポンシブコントロールに依存しているテーマにとっては影響が大きいため、Responsive style states for blocks 、 iteration for WP 7.1 のIssueを追いかけておくとよい。
その他テーマ向けのブロックアップデート
細かいが実務に効く変更もいくつか入った。グローバルスタイルのカラーパネルでスラッグベースの色選択が統合され、ホームリンクブロックに不足していたコントロールが追加された。パンくずブロックでは視覚的な区切り文字がスクリーンリーダー向けに非表示となり、ナビゲーションでは非推奨化された block_core_navigation_submenu_render_submenu_icon() 関数のシムが復活している。画像ブロックでは幅か高さの片方だけが設定された場合に出力が崩れる問題も修正された。
また、WordPress 7.0では著者アーカイブリンクのデフォルトの title 属性（「Posts by Author」）が削除されている。マークアップのわずかな変更だが、テーマの表示テストやスナップショットテストに影響する可能性があるため注意しておきたい。
WordPress Playgroundの最新動向
wp-nowが非推奨に、Playground CLIへの移行を
ローカル環境を手早く立ち上げるために wp-now を使っていた開発者は、Playground CLIへの移行が必要になる。Developer WordPress Newsの記事によると、2026年6月8日付でwp-nowが非推奨となり、今後の推奨パスはPlayground CLIに一本化された。
移行は比較的スムーズに行えるよう設計されており、テスト用サイトを素早く立ち上げたいプラグイン開発者やテーマ制作者は、早めに切り替えておくとよいだろう。
PRプレビューとPHPスニペットの公式ガイド
Playground関連では、2つの役立つガイドも公開された。ひとつは「PR Preview with WordPress Playground: What changes in version 3 of the GitHub Action」で、プルリクエストのプレビューを自動化するGitHub Actionの最新バージョンについて解説している。プロジェクトでPlaygroundプレビューを利用しているなら、一度目を通しておきたい内容だ。
もうひとつは「Run PHP examples anywhere with WordPress Playground」で、WordPressの開発者向けドキュメントやチュートリアルに、ブラウザ上で実行可能なPHPサンプルを埋め込む方法を紹介している。技術記事を書く立場の開発者にとって、この手法は読者の理解を大きく助ける強力な武器になる。
保存型Playgroundと古いWordPressバージョンの復元
Playground v3.1.35およびv3.1.36では、サイトの保存とSites APIの機能が大きく進んだ。保存したブラウザ上のWordPressサイトに何度も戻れる永続化の仕組み、自動保存からの復元UX、埋め込みPlaygroundでの不要な保存プロンプト回避などが実装されている。
さらに、WordPress 0.7 のような過去のバージョンを丸ごとロードできるようになり、Virtual WordPress Museum のようなデモも登場した。デモやテスト、教育目的の用途が一層広がる変更といえる。
PHP.wasmによる高度なデモやフレームワーク対応
PHP.wasm周辺の開発も活発だ。新しい「Running PHP Frameworks in Playground」ガイドでは、WordPress以外のPHPフレームワークをPlayground上で動かす方法が示されており、ブラウザベースのツール構築の可能性を大きく広げている。また、@php-wasm/compile-extension ワークフローにより、PHP拡張のコンパイルも以前より容易になった。高度なデモやドキュメント用のサンプルを作る開発者には、これらの進歩も見逃せない。
ユーザーインターフェースとアクセシビリティの改良
実験的なダッシュボードのカスタマイズ機能がウィジェットを追加
カスタマイズ可能なダッシュボードはまだ実験段階だが、Gutenberg 23.3では新たに5つのウィジェット（サイトヘルス、ニュース、イベント、クイックドラフト、サイトプレビュー/URLバー）が追加され、レイアウトの調整も進んだ。ゴーストウィジェットやサイズプリセット、コンテナブレークポイントによるグリッドカラムなど、徐々に実用性が高まっている。
管理者画面の拡張やプラグイン独自の管理パネルを開発しているなら、この実験がどこに向かっているのかを customizable dashboard overview issue で追いかけておくことをおすすめする。
エディターと管理画面でのアクセシビリティの磨き込み
GutenbergとCoreの両方でアクセシビリティ関連の改善が続いている。Gutenberg 23.3ではリビジョン機能が改善され、フォントライブラリのフォーカスナビゲーションも修正された。Core側では、管理画面のカラースキームのコントラスト強化、フロントエンドツールバーのフォーカスアウトライン修正、ハイコントラストモード時のボタンアクティブ状態の不具合対応などが行われている。
カスタム管理画面やエディターパネル、メディア操作UIを提供している場合は、キーボード操作、ハイコントラストモード、文字サイズの拡大設定、標準以外の管理画面カラースキームを組み合わせたテストを定期的に実施することが重要だ。
この記事のポイント
- メディア編集はモーダルに集約され、クライアントサイド画像処理の実験的テストも始まった。サーバー負荷の低減とUX向上が見込まれる
- React 19移行は一時停止中だが、WordPress 7.1に向けた準備は継続。プラグイン開発者は互換性を確認しておく
- テーマ開発では、単一ブロックへの擬似状態スタイル適用やレスポンシブスタイルの拡張など、表現力が高まる変更が多い
- PlaygroundはCLIへの一本化、保存型サイトの強化、過去バージョン対応などで開発者の実験環境が飛躍的に便利になった
- アクセシビリティの改良も着実に進行。カスタムUIを作るならテストにキーボード操作やハイコントラストモードを含める
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
会員制サイトSEOの7つの戦略、ティーザーで制限コンテンツを検索上位に
会員制サイトを運営していると、せっかく質の高いコンテンツを制作しても、Google検索にまったく表示されないという問題に直面しやすい。原因の多くは、価値のある記事やコースがログインページやペイウォールの奥に隠れていることにある。検索エンジンは会員専用エリアをクロールできず、サイト全体のテーマを正しく把握できないのだ。
しかし、コンテンツ保護とSEOはトレードオフではない。適切な設計を施せば、プレビュー部分を検索エンジンに読み取らせつつ、中核の有料コンテンツはしっかり守れる。WPBeginnerがまとめた「会員制サイトSEOの7つの戦略」をもとに、具体的な実装方法を解説する。
会員制サイトのSEO課題と「ティーザーコンテンツ」の考え方
会員制サイトには特有のSEOの壁がある。Googleは公開されている情報だけをインデックスするため、ログイン必須のレッスンやダウンロード資料、会員ダッシュボードの中身は一切読み取れない。一方で、完全に閉ざしてしまうと検索流入を失い、新規会員の獲得機会が減ってしまう。
検索エンジンはゲート付きコンテンツをどう扱うか
Googleは、ログイン前の訪問者にも表示される「公開プレビュー」部分をインデックス可能だ。一方、認証画面の奥にある会員専用ページはクローラーのアクセス対象外となる。この仕組みを逆手に取り、ティーザーコンテンツ（Teaser Content）と呼ばれる一部公開方式を採用するサイトが多い。WPBeginnerの著者も、これが会員制サイトのSEOにおいて最も効果的で安全な手法だと述べている。
ティーザーコンテンツが有効な理由
ティーザーとは、記事の導入部やレッスンの要約、キーポイントなどを会員以外にも公開し、続きはログイン後に読めるようにする仕組みだ。Googleはこの公開部分をもとにページの主題を理解し、検索結果に表示できるようになる。訪問者にとっては内容の魅力を事前に感じられるため、会員登録へのコンバージョン率も向上しやすい。WPBeginnerの実践では、無料の動画コース一覧を誰でも閲覧可能にし、レッスン本体は会員登録後に開放する形で、SEOと会員獲得を両立している。
このデモのように、Googleは公開部分のテキストからページの内容を把握し、ランキング評価に活用する。訪問者にとっては「続きも見たい」というモチベーションが生まれ、会員獲得の導線としても機能する。
ティーザーとコンテンツドリッピングを安全に運用する
ティーザー表示の設定ができたら、次は会員にコンテンツを段階的に提供する「コンテンツドリッピング」について理解しておきたい。これはオンラインコースなどでよく使われる手法で、SEOに悪影響を及ぼさないためにはいくつかの注意点がある。
MemberPressを使ったティーザー公開の設定手順
WordPressで会員制サイトを構築する場合、高い機能を持つプラグインとしてMemberPressが広く使われている。管理画面の「MemberPress」→「ルール」から新規ルールを追加し、保護したい投稿やカテゴリを選択する。その後「アクセス条件」で特定の会員レベルを指定し、「未認証時のアクション」で抜粋の表示を有効にすれば、公開ティーザーが実装できる。
抜粋の長さは200〜300語程度を目安に設定すると、検索エンジンがページ主題を理解するのに十分な情報量を提供できる。WPBeginnerのガイドでは、未認証時に表示されるメッセージに料金ページや登録ページへのリンクを埋め込むことで、コンバージョン向上を図る方法も推奨されている。
コンテンツドリッピングがSEOに与える影響と事前対策
ドリッピングとは、会員登録後の日数経過や特定の日付に合わせて、レッスンを少しずつ開放していく仕組みだ。未解放のコンテンツは検索エンジンからも見えないため、その期間はインデックスされない。しかし、事前にティーザーページやレッスン概要を用意しておけば、後日開放されたときにスムーズにクロールされる。
動画コースの場合は、各レッスンに短いプレビュー動画や書き起こしテキスト、キーポイントをまとめた公開ランディングページを設ける方法が有効だ。WPBeginnerの著者は、これによって開放前から検索エンジンに内容を認識させられると指摘している。
無料コンテンツを拡充して検索トラフィックを底上げする
会員制サイトの運営者の中には、コンテンツの大半をペイウォールの内側に置いてしまうケースがある。だが、それではGoogleがサイト全体の専門性を評価する材料が不足し、オーガニック流入が伸び悩む。実際に成果を上げているサイトは、無料コンテンツを充実させ、そこから有料会員プログラムへと誘導する設計をとっている。
無料と有料の境界線の引き方
無料コンテンツは、幅広い検索キーワードでアクセスを集める役割を担う。一方、有料コンテンツにはテンプレートやワークシート、詳細な実装ガイドなど、より深い価値を置く。WPBeginnerが提示する枠組みでは、初心者向けチュートリアルや統計レポート、業界の基礎知識は無料とし、高度なノウハウや会員限定のツールキットは有料会員向けに保護する。
- 無料コンテンツ：検索ボリュームの大きいキーワードを狙うブログ記事、初心者向け解説、バックリンクを獲得しやすいリソース
- 有料コンテンツ：テンプレート、ワークシート、オンラインコース、会員限定の実装ガイド
このように切り分けると、無料記事で集めた訪問者に「より深い学びを得たければ会員登録を」と自然に促せる。
E-E-A-Tシグナルとキーワード戦略で信頼を構築する
会員制サイトは、専門知識やトレーニングを販売する性質上、訪問者からの信頼獲得が欠かせない。Googleが評価するE-E-A-T（経験、専門性、権威性、信頼性）の観点からも、無料コンテンツを使って実績や実例を示すことが有効だ。WPBeginnerの著者は、実際に自分たちでツールを使い、結果やケーススタディを共有することで、サイトの専門性を高めている。
具体的には、著者プロフィールの充実、会員の声や成功事例の掲載、実際の運用画面の紹介などが信頼構築に役立つ。無料記事にこうしたシグナルを埋め込んでおくと、検索エンジンだけでなく、人間の読者にも「このサイトは信用できる」と感じてもらいやすい。
テクニカルSEOとnoindex設定でクローラーの集中力を高める
どれだけ優れたコンテンツ戦略を立てても、サイトの技術的な土台が整っていなければ、検索順位は伸びにくい。会員制サイトでは特に、ログインページやアカウントページといった「低価値ページ」が検索結果に紛れ込むのを防ぐことも重要になる。
サイトスピードやHTTPSなど基盤のチェックリスト
- HTTPSによるセキュリティ保護とランキングシグナルの確保
- キャッシュプラグインの導入と画像最適化によるサイトスピード改善
- モバイルフレンドリーなデザインの採用
- XMLサイトマップを生成し、検索エンジンにサイト構造を伝える
- リンク切れや404エラーを定期的に検出し修正する
これらの対策は会員制サイトに限らず重要だが、ペイウォールがあるぶん、クローラビリティの健全性を保つ意識がより求められる。
ログインページやアカウントページをnoindexに
会員ログインページやアカウント管理画面、決済完了後のサンキューページなどは、検索結果に表示されてもユーザーにとってほとんど価値がない。むしろ、これらのページがインデックスされると、サイトの評価につながる重要なコンテンツの存在が薄れてしまう可能性がある。
そのため、All in One SEO（AIOSEO）などのSEOプラグインを使って、該当ページの編集画面から「Robots Meta」設定で「No Index」を有効にすることを推奨する。WPBeginnerの著者も、会員向け機能ページはnoindexに設定し、ブログ記事やコースランディングページなどの集客に集中させる方針をとっている。
内部リンクとコンバージョン最適化で会員化を加速する
無料コンテンツで訪れたユーザーを会員登録へと導くためには、サイト内の動線設計が欠かせない。内部リンクを活用して無料記事から有料プランへつなぎ、さらにポップアップやスライドインなどの施策で後押しすれば、SEOで獲得したトラフィックを収益に結びつけられる。
無料記事から有料コンテンツへの自然な導線
ブログ記事で「会員制サイトの始め方」を解説しているなら、記事の途中や末尾に「さらに詳しいテンプレートは会員プログラムでダウンロード可能」といったリンクを設置する。リンクのアンカーテキストは「こちらをクリック」ではなく「会員限定テンプレートを入手する」のように具体的に書くと、クリック率とSEO評価の両面で効果が高い。
- ブログ記事 → 関連する有料コースのランディングページ
- 無料のチュートリアル → 会員限定の上級編トレーニング
- リソースガイド → プレミアムテンプレートのダウンロードページ
内部リンクを張り巡らせると、Googleがサイト構造を理解しやすくなるのに加え、訪問者を収益化ページへ自然に誘導できる。
OptinMonsterによるExit-Intentやスライドインの活用
WPBeginnerの著者が特に効果的だと評価しているのが、OptinMonsterを使った出口検知ポップアップやスクロール連動スライドインだ。MemberPressとの連携機能により、未会員の訪問者だけを対象にキャンペーンを表示できるため、無料トライアルや割引オファーを最適なタイミングで提示できる。
たとえば、記事を最後まで読んだユーザーに対して「続きは会員限定です。今なら初月無料」と表示するスライドインは、押しつけがましくなく自然に感じられる。実際に、WPBeginnerの運営する複数のサイトでも、こうした導線によってメールリストの拡大や会員登録数の増加を実現している。
効果測定の指標とMonsterInsightsでの追跡
会員制サイトのSEO施策が成果を上げているかは、アクセス数だけでなく会員登録数やコンバージョン率で判断する必要がある。MonsterInsightsを使えば、GoogleアナリティクスのデータをWordPress管理画面に取り込み、どの記事が最も会員登録につながっているかを直感的に把握できる。
- オーガニックトラフィックの推移
- ティーザーページへの流入と直帰率
- 会員登録完了ページへの到達数
- バックリンク獲得状況
定期的にこれらの指標を確認し、特に会員登録につながっているコンテンツを強化していくと、施策の費用対効果を最大化しやすい。
この記事のポイント
- 会員制サイトのSEOには、公開ティーザーで検索エンジンに内容を伝える手法が欠かせない
- MemberPressで抜粋表示を設定し、一部のコンテンツを誰でも見られるようにする
- コンテンツドリッピングは事前にティーザーページを用意すればSEO上のデメリットは最小限
- 無料コンテンツで集客し、内部リンクとコンバージョン施策で有料会員へ誘導する
- 会員向け機能ページはnoindexにして、クロールのリソースを重要なページに集中させる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPressドメイン移転後のSEOを完全検証する7ステップ
ドメイン名の変更は、WordPressサイト運営者にとって最も神経を使うSEO判断のひとつだ。適切に実行すれば検索順位のほとんどは維持される。しかし手順を間違えると、数カ月かけて積み上げた成果が一夜で消え去る。WP Beginnerの記事では、表面上は問題なさそうに見えて、実際にはリダイレクト漏れや古い正規URLが数週間にわたって順位を押し下げた事例が報告されている。
本記事では移転前のSEOベースライン取得から始め、リダイレクトの検証、正規URLとデータベース内リンクの修正、そして復旧状況の追跡までを体系的に解説する。大半のサイトは301リダイレクトを正しく設定することで、4〜8週間以内に検索順位の80〜100%を回復できるというデータがある。
このデモでは、ドメイン移転前後でのSEO評価の流れを概念的に示している。301リダイレクトがあれば左から右へ評価が転送されるが、リダイレクトがないと旧ドメインに評価が取り残されたままになる。
ドメイン移転がSEOにリスクをもたらす理由
ドメインを変更すると、Googleは新しいURLを発見し、301リダイレクトを処理し、既存のランキング評価を転送する前にコンテンツを再評価する。このプロセスには時間がかかり、いずれかの段階でエラーが発生すると、SEOの回復が遅れたり恒久的に低下したりする。
ほとんどの順位低下は、以下の3つの具体的な障害点から発生する。
- 301リダイレクトの破損または欠落。301がない場合、Googleは新ドメインを評価シグナルのないまったく新しいサイトとして扱う
- 古い正規URL（カノニカルURL）が残ったままの状態。正規タグが旧ドメインを指していると、Googleは新しいURLではなく古い方をランク付けしようとする
- サイトマップが旧ドメインを参照しているパターン。Googleはサイトマップを使ってページを発見するため、古いURLのままだと新ドメインのコンテンツ発見が遅れる
この3つはすべて修正可能だ。以降の手順では、移転前の準備から順に対処法を説明する。
ステップ1 移転前のSEOベースラインを構築する
サイトを移転する前に、現在のSEOパフォーマンスのスナップショットを取得しておく必要がある。ベースラインがなければ、移転後に順位が正常に回復しているのか、特定のページが密かに順位を落としているのかを判断できない。
キーワードランキングをエクスポートする
キーワードのベースラインは、移転後1週間、2週間、4週間の時点で比較する「変化前の記録」になる。サイトに手を加える前に、現在のキーワード順位、クリック数、表示回数をエクスポートする。
Googleサーチコンソールから無料でエクスポートできる。対象のサイトプロパティを選択し、左サイドバーの「パフォーマンス」から「検索結果」をクリックする。期間を過去3カ月に設定し、右上の「エクスポート」からCSVをダウンロードする。エクスポート前に「表示回数」または「クリック数」の多い順に並べ替えておくと、上位1,000キーワードが最も価値の高いものになる。
All in One SEO（AIOSEO）のEliteプランを利用していれば、WordPress管理画面から直接同じデータを取得できる。AIOSEOの検索統計機能はサーチコンソールのデータを自動的に取り込んでおり、キーワード順位、クリック数、表示回数をダッシュボード上で確認できる。
現在のURL一覧をクロールして文書化する
サイト上の全ページの完全なリストは、後でリダイレクトを設定する際のロードマップになる。このリストから漏れたページはリダイレクトが設定されず、古いアドレスが機能しなくなった瞬間に、そのページが築いた検索順位は永久に失われる。
現在のサイトをクロールするには、Screaming Frog SEO Spiderが使える。500URLまでは無料で、有料プランでは無制限にクロールできる。クロールが完了したら、ファイルメニューから全URLリストをCSVとしてエクスポートし、キーワードエクスポートと同じ移転専用フォルダに保存する。
ステップ2 サイトを安全に移転する
サイト移行に使う手法は、最初の大きなSEO判断になる。WP Beginnerの記事では、移行中のデータベース処理の安全性からDuplicatorの使用が推奨されている。Duplicatorのインストーラーは、展開時にWordPressデータベース内の全URLを新しいドメインに自動更新する。内部リンクや画像パスも自動修正されるため、後述する古い正規URLや混在コンテンツの問題を防げる。
移転が完了したら、新しいWordPress管理画面の「設定」→「一般」で、WordPressアドレスとサイトアドレスの両方が新しいドメインになっていることを確認する。
robots.txtが新サイトをブロックしていないか確認する
検索エンジンのクロールをブロックできるのは、WordPressの「検索エンジンがサイトをインデックスしないようにする」チェックボックスだけではない。robots.txtファイルも同様の影響を与える。ステージング環境から引き継がれた古いルールが残っていると、重要なコンテンツがブロックされる可能性がある。
新しいドメインのrobots.txtをブラウザで開き、DisallowルールやSitemap行が新しいドメインを指しているか確認する。AIOSEOを使っている場合は、ツールメニューから「カスタムrobots.txtを有効化」トグルをオンにし、古いルールを直接修正できる。
ステップ3 旧ドメインからの301リダイレクトを設定する
301リダイレクトは、Googleに対して「このURLは恒久的に新しいURLに移動した」と伝える仕組みだ。郵便局に転居届を出すようなもので、SEO評価を正しく転送するための必須手続きになる。301がないと、Googleは新旧ドメインをまったく別のサイトとして扱い、ランキングシグナルは古いドメインに残ったままになる。
AIOSEOのProプラン以上に含まれる「フルサイトリダイレクト」機能を使うと、旧ドメイン全体を一度の設定で新ドメインに転送できる。旧サイトのWordPress管理画面で「All in One SEO」→「リダイレクト」→「フルサイトリダイレクト」タブを開き、「サイトを移転する」トグルを有効化して新しいドメインURLを入力する。
重要な注意点として、この手法は旧サイトのWordPressが稼働し続けていることが前提になる。旧ドメインの登録を維持し、ホスティングも停止せず、AIOSEOプラグインも有効化したままにする必要がある。旧サイトを削除したりホスティングを解約すると、リダイレクトは即座に機能しなくなる。
Googleに通知する前にリダイレクトをテストする
壊れたリダイレクトを抱えたまま変更通知を送信すると、移行全体の回復が遅れる。外部ツールのhttpstatus.ioなどを使い、旧ドメインのトップページURLが301ステータスを返し、正しい新ドメインのURLに解決されることを確認する。このテストはアクセスの多い上位5記事と主要カテゴリページでも繰り返す。
302リダイレクトや複数ホップのチェーンが発生している場合は、AIOSEOのリダイレクト設定で競合する個別ルールがないか確認する。リダイレクトチェーンが発生すると、SEO評価の受け渡しが目減りし、訪問者の待ち時間も増える。すべての旧URLが新URLに直接1ホップで転送される状態を目指す。
この比較図はリダイレクトチェーンの問題を視覚化したものだ。中間ホップを除去して直接転送にすることで、Googleが処理すべき経路が単純になり、評価の受け渡し効率が上がる。
ステップ4 新ドメインをGoogleサーチコンソールに登録する
Googleは旧ドメインと新ドメインを完全に別のプロパティとして扱う。ランキングシグナルを転送するには、新ドメインをサーチコンソールで確認し、住所変更通知を送信し、サイトマップを再送信する必要がある。
新しいドメインを追加するには、サーチコンソールのプロパティドロップダウンから「プロパティを追加」を選び、確認手続きを進める。次に旧ドメインのプロパティに切り替え、「設定」→「住所変更」から新ドメインを選択して「検証して更新」をクリックする。このときGoogleが301リダイレクトを検証するため、事前にステップ3の設定が完了している必要がある。
サイトマップについては、AIOSEOがドメイン変更時に内部リンクを自動更新するが、新しいURLのサイトマップを手動で再送信することで、次の自動クロールを待たずに新URLのインデックス登録を開始させられる。
ステップ5 正規URLが正しいか検証する
正規URL（カノニカルURL）は、検索エンジンがインデックスしてランク付けすべき「正式版」のページを指す。ドメイン移転後に正規タグが旧ドメインを指したままだと、新しいページがGoogleに対して「古いURLをランク付けしてほしい」と伝えているのと同じ状態になる。これは順位回復が遅れる最も一般的な原因のひとつだ。
Duplicatorで移転した場合、データベース内の正規URLは展開時に自動更新される。ただし、個別の投稿レベルで手動設定された正規URLオーバーライドはDuplicatorが更新しない場合があるため、以下のスポットチェックは必ず実施する。
AIOSEOのグローバル正規設定を確認する
AIOSEOはサイトURLに基づいてサイト全体の正規タグを自動生成する。移転後に確認すべきは、重複コンテンツを防ぐ2つのリダイレクト設定だ。「検索の外観」→「詳細」タブにある「ページ送りフォーマット」が空白になっていないことを確認する。また「画像SEO」タブで「添付ファイルURLのリダイレクト」が無効になっていないかをチェックする。この設定は、コンテンツの薄いメディア添付ページを親投稿にリダイレクトし、Googleのインデックスから除外する役割を持つ。
重要ページを目視チェックする
アクセスの多い上位ページをブラウザで開き、ページのソースを表示して<link rel="canonical"を検索する。URLが新ドメインを指していることを確認する。もし旧ドメインのままになっているページがあれば、その投稿の編集画面でAIOSEO設定パネルの「詳細」タブを開き、正規URLフィールドを手動で更新する。
ステップ6 データベースURLと混在コンテンツを修正する
移転後、一部の画像やスクリプト、スタイルシートが旧ドメインを指したままだったり、安全でないHTTP接続で読み込まれていたりすることがある。これらの古いアセットは、旧ドメインがオフラインになった瞬間に画像の破損やセキュリティ警告を引き起こす。
データベース内のハードコードURLを置換する
Duplicatorは標準的なURL更新を処理するが、ページビルダーのレイアウトやテキストウィジェット、カスタムテーマオプションに埋め込まれたハードコードリンクは取り残されることがある。Search & Replace Everything by WPCodeプラグインを使うと、シリアル化データを破損させずにデータベース全体のURLを安全に置換できる。
WordPress管理画面の「ツール」→「WP Search & Replace」で、検索フィールドに旧ドメインURL、置換フィールドに新ドメインURLを入力し、すべてのデータベーステーブルを選択する。「検索と置換をプレビュー」で影響範囲を確認した後、「すべて置換」を実行する。
ElementorやDiviなどのページビルダーを使っている場合、Search & Replace実行後も背景画像が破損することがある。これはビルダーが静的CSSファイルにURLを保存しているためだ。この場合、Elementorなら「Elementor」→「ツール」→「ファイルとデータを再生成」を実行してキャッシュをクリアする。
SSL混在コンテンツエラーを修正する
旧ドメインが標準HTTPで新ドメインがHTTPSの場合、ブラウザのアドレスバーに壊れた鍵アイコンやセキュリティ警告が表示されることがある。これはサイト設定は安全でも、埋め込まれたスクリプトや画像が安全でない接続で読み込まれようとしている混在コンテンツエラーだ。まずは新ドメインに有効なSSL証明書がインストールされていることを確認し、その後WordPressの混在コンテンツ修正手順を実行する。
残存するリンク切れをスキャンする
データベースURLの置換が完了したら、AIOSEOのBroken Link Checkerを使って内部リンクが404エラーになっていないかスキャンする。このプラグインはバックグラウンドで自動スキャンを実行し、リンク切れを検出すると一覧表示する。各リンクに対してインラインの「URLを編集」で修正するか、「リンク解除」で削除できる。
ハード404エラーを特定して修正する
リンク切れスキャンがコンテンツ内のデッドリンクを見つけるのに対し、ハード404は「ページが移行されなかった」「URLが変更された」「リダイレクトが機能していない」などの理由で新サイト上で「見つかりません」と表示されるページだ。Screaming Frogで新ドメインをクロールし、レスポンスコードタブで4xxエラーを探す。Googleサーチコンソールの「インデックス作成」→「ページ」でも404として検出されたページを確認できる。各404について、ページを復元するか、新しいURLへの301リダイレクトを追加する。
価値の高い外部バックリンクを更新する
自サイト内のリンク修正だけでは不十分だ。他のウェブサイトが旧ドメインにリンクしている外部バックリンクは、最も強力なランキングシグナルのひとつである。301リダイレクトはその評価を新ドメインに転送するが、その受け渡しは永続的ではなく、時間経過とともに弱まる可能性がある。また旧ドメインを手放した時点で完全に停止する。
Googleサーチコンソールの「リンク」→「上位のリンク元サイト」で、最も多くリンクを送っているサイトを特定し、ゲスト投稿の著者プロフィールやプレス掲載、リソースページ掲載など、実際に更新を依頼できる高オーソリティのサイトから優先的に連絡する。すべてのリンクを変更できるわけではないが、上位の数十件を直接リンクに更新するだけでも、最も重要なランキングパワーを保護できる。
ステップ7 AIOSEOとMonsterInsightsで復旧を監視する
ドメイン移転後の順位回復には時間がかかる。この期間中に重要なのは、検索アルゴリズムによる通常の短期的な変動と、実際に対処が必要な技術的問題を区別することだ。
AIOSEO検索統計でキーワード順位を追跡する
AIOSEOの検索統計ダッシュボードは、GoogleサーチコンソールのデータをWordPress管理画面に直接取り込む。「勝ち負け」タブでは、移転後に最も可視性を失ったページを素早く特定できる。移転前のステップ1で保存したCSVと見比べることで、回復の進捗を定量的に評価できる。
MonsterInsightsでトラフィック傾向を比較する
キーワード監視が検索エンジン上の位置を示すのに対し、実際のトラフィック量はユーザーが新ドメインにどう反応しているかを確認する指標になる。MonsterInsightsはGoogle AnalyticsのデータをWordPressに取り込み、週次でのトラフィック比較を簡単にする。重要なのは、新しいGoogle Analyticsプロパティを作成せず、既存のプロパティを使い続けることだ。データストリームだけを新しいサイトURLに更新すれば、移転前のベースラインとの比較が途切れない。
MonsterInsightsのSite Notes機能（Proプラン以上）を使えば、移転日をアナリティクスのタイムラインに直接ピン留めできる。これにより、トラフィックがいつから回復し始めたかを折れ線グラフ上で視覚的に把握できる。
週次での回復タイムライン
ドメイン移転後に順位が大きく変動すると不安になるのは当然だ。しかし、正常な回復のパターンを知っておけば、パニックによるコンテンツ変更（回復を遅らせる原因になる）を避けられる。
- 第1週 発見と変動。Googleのクローラーがリダイレクトを発見し、ドメイン変更の処理を開始する。順位は大きく変動し、トラフィックはベースラインから30〜70%減少することが多い。これは想定内であり、移行の失敗を意味しない
- 第2週 シグナルの転送開始。ほとんどの301リダイレクトが処理され、ランキングシグナルが新ドメインに渡り始める。サーチコンソールでリダイレクトエラーやソフト404の通知がないか確認する
- 第4週以降 回復の評価。クリーンな301リダイレクトがあるサイトでは、4〜8週間以内に80〜100%の回復が見られることが多い。回復が遅れているページがあれば、リダイレクト、正規URL、インデックス状態の3点を再確認する
この記事のポイント
- ドメイン移転のSEOリスクは301リダイレクトの欠落、古い正規URL、旧ドメインを指すサイトマップの3つに集中する
- 移転前にキーワード順位とURL一覧のベースラインを取得し、回復度合いを測定できる状態にする
- リダイレクトは直接1ホップで完了させ、チェーンを発生させない
- 正規URLとデータベース内リンクは自動更新を過信せず、必ず手動でスポットチェックする
- 復旧状況はAIOSEOの検索統計とMonsterInsightsのトラフィック比較で定量的に追跡する
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress多言語プラグインを徹底比較〜TranslatePress・WPML・Universallyの最適解
WordPressサイトを多言語化することは、リーチの拡大やSEOトラフィックの増加、売上向上に直結する施策だ。だが、数ある翻訳プラグインの中からどれを選ぶべきか判断するのは容易ではない。TranslatePressとWPMLは長年の実績を持つ定番であり、Universallyはよりモダンな手法で翻訳を自動化する新興の選択肢だ。
この記事では、WP Beginnerのテストと分析に基づき、セットアップの容易さ、翻訳品質、多言語SEO、パフォーマンス、WooCommerce対応、サポート、価格の7つの観点から3つのプラグインを比較する。自社サイトに最適な翻訳プラグインを選ぶための判断材料を提供する。
結論から言えば、Universallyは最も簡単なセットアップとクラウドによる高速パフォーマンス、圧倒的な導入コストの低さが魅力だ。TranslatePressは直感的なビジュアル編集を求めるユーザーに適しており、WPMLは特に複雑なWooCommerceストア運用で真価を発揮する。
セットアップの容易さ
サイトを多言語化するプロセスは、可能な限り手間がかからないのが理想だ。TranslatePressとUniversallyは、10分以内に別言語版を公開できる。一方、WPMLは相応の設定作業が必要で、作業に入る前にその工数を理解しておく価値がある。
TranslatePressのセットアップ
TranslatePressの導入はWPMLよりシンプルだ。WordPress.orgからプラグインをインストールし、設定画面で言語を選択すると、APIキーなしで即座にフロントエンドの翻訳エディターが利用可能になる。管理バーの「サイトを翻訳」をクリックし、ライブページ上のテキスト要素を直接クリックして翻訳するだけだ。バックエンドのスプレッドシートや別ダッシュボードは一切存在しない。
注意点として、訪問者のブラウザ言語を自動検出して切り替えを促す機能は、Businessプラン（年間199ユーロ）のみの提供だ。Personalプランでは言語スイッチャーを設置できるが、訪問者自身が手動で言語を選択する必要がある。
WPMLのセットアップ
WPMLは、3つのプラグインの中で最も多くの初期設定を要求する。Multilingual CMSプランでは、最低でも2つのプラグインコンポーネント（WPML本体とString Translation）のインストールが必要だ。各コンポーネントに独自のセットアップウィザードがあり、翻訳は自動では開始されない。ページごとに手動でトリガーするか、「すべてを翻訳」モードを有効にして自動翻訳のクレジット消費を設定する。
WP Beginnerのテストによれば、シンプルなサイトの翻訳設定だけでも1時間近くかかったという。複雑なテーマやカスタム投稿タイプを使用する大規模サイトでは、さらに多くの時間を見込む必要がある。この複雑さには理由があり、WPMLはTranslatePressやUniversallyでは提供されないきめ細かな制御を可能にする。ただし、そのレベルの制御が不要であれば、オーバーヘッドに見合わない。
Universallyのセットアップ
Universallyは、その手軽さが際立つ。プラグインをインストールし、専用ダッシュボードからAPIキーを貼り付け、対象言語を選ぶだけだ。この3ステップで作業は完了する。言語スイッチャーが自動でサイトに表示され、ショートコードの設置やテンプレート編集、ページごとの翻訳トリガーは一切不要だ。
言語検出、SEO設定、スイッチャーの配置まですべてが自動化されており、大半のサイトは10分足らずで多言語化が完了する。WP Beginnerの著者も、その要求の少なさに驚いたと述べている。
セットアップの容易さでは、Universallyが最速であり、TranslatePressがそれに次ぐ。WPMLの複雑さは、提供する詳細な制御が本当に必要な場合にのみ正当化される。
翻訳品質
機械翻訳の品質は近年大幅に向上しており、3つのツールはいずれも多くの言語ペアで読みやすい翻訳を生成する。差が出るのは、誤りの修正方法と、最終結果に対する編集権限の大きさだ。
TranslatePressの翻訳品質
TranslatePressは、大規模言語モデルとニューラル機械翻訳エンジンを組み合わせ、言語ペアとコンテンツタイプごとに最適な手法を自動選択する。有料プランではTranslatePress AIが利用でき、プランごとに単語数の上限が設定されている。高精度のDeepL連携はBusinessプラン以上で利用可能だ。
TranslatePressの最大の強みは、全プランで利用できるフロントエンドのビジュアルエディターだ。ライブページ上のテキストをクリックするとサイドバーに翻訳が表示され、その場で修正できる。変更はリアルタイムでページに反映される。翻訳メモリ機能も全プランに含まれており、95%以上一致する既存の翻訳を新しい文字列に自動適用する。
WPMLの翻訳品質
WPMLは根本的に異なるアプローチを取る。デフォルトは手動翻訳であり、すべての文字列をユーザーが制御する。機械翻訳は有料アドオンで、DeepLやGoogle Translate、Microsoft Azure Translatorを利用できる。クレジットはCMSプランとAgencyプランに含まれており、ワークフローはAIによる翻訳結果をそのまま公開するのではなく、人間によるレビューを前提に設計されている。
高度な翻訳エディターは、プロの翻訳者向けにサイドバイサイドの編集画面を提供し、翻訳メモリと公開前の品質チェック用レビュアー権限も備える。法律文書や医療情報など、誤訳が重大な結果を招くコンテンツでは、この手動優先の設計が力を発揮する。
Universallyの翻訳品質
Universallyは、汎用の言語モデルではなくWebコンテンツ向けに特化してトレーニングされたカスタムAIモデルを使用する。この専門化により、単語単位の置き換えではなくブランドの声や文脈を維持した翻訳を実現する。同社の報告では、ほとんどの言語ペアで90〜95%の精度を達成している。
用語集機能（全有料プランで利用可能）では、ブランド名や製品名、特定のフレーズの訳し方を固定でき、そのルールがサイト全体に自動適用される。現時点では専用の編集ツール（ダッシュボードテキストエディターやライブビジュアルエディター）はロードマップ上の計画段階であり、まだ提供されていない。
翻訳品質では、UniversallyとTranslatePressがそれぞれ異なる理由で優れている。AI翻訳をそのまま公開し、ほとんど手を加えたくないならUniversallyが適している。一方、手動で細かく編集したい場合は、クリックして修正できるTranslatePressのビジュアルエディターが実務上の大きなアドバンテージとなる。WPMLはプロの翻訳パイプラインとミッションクリティカルなコンテンツ向けという別の領域にある。
多言語SEO
多言語での公開は、検索エンジンがそれらのページを正しく検出し、インデックスして初めて効果を発揮する。3つのツールはいずれも技術的なSEOの基本をカバーするが、何が自動で含まれ、何が上位プランに制限されているかには意味のある違いがある。
TranslatePressの多言語SEO
SEO Packアドオンはすべての有料プランに含まれ、hreflangタグや多言語XMLサイトマップ、翻訳されたメタタイトルとディスクリプション、画像のaltテキスト、Open Graphメタデータ、翻訳URLスラッグを処理する。URLスラッグの翻訳は全有料プランで利用可能であり、同じ機能に別途課金する競合ツールと比較してコストパフォーマンスに優れる。また、Yoast SEOやRank Math、AIOSEO、SEOPress、Slim SEOとの連携により多言語サイトマップを生成できる。
WPMLの多言語SEO
WPMLの専用SEOアドオンはCMSプランとAgencyプランに含まれる。hreflangタグ、x-default hreflangタグ、翻訳URLスラッグ、言語別のメタ情報をすべてカバーする。AIOSEOやYoast SEOとの深い互換性により、SEOプラグインの全フィールドが翻訳ワークフローに自動で組み込まれる。ただし、Yoast SEO Premiumのリダイレクト機能はWPMLと互換性がない点に注意が必要だ。
Universallyの多言語SEO
Universallyは、多言語SEOの全スタックを自動で処理する。hreflangタグ、翻訳メタ情報、多言語XMLサイトマップ、schema.org構造化データ、RTL言語サポートが、言語を追加した瞬間に有効化され、手動設定は一切不要だ。これはUniversallyの本物の強みであり、SEO設定ページを一度も開くことなく堅実な多言語SEOを実現できる。
多言語SEOではWPMLとTranslatePressが同点だ。いずれも有料プランでx-default hreflangと翻訳URLスラッグを含む完全なSEOスタックをカバーする。Universallyは国際SEOの基本を自動化するが、x-defaultタグやネイティブなURLスラッグ翻訳に関するきめ細かな制御は現時点では欠けている。
パフォーマンスと表示速度
サイト速度はSEOとコンバージョンの両方に影響する。複数言語の追加は、翻訳プラグインの実装が非効率だとサイトを遅くする要因になる。これら3つのツールは、翻訳コンテンツの保存と配信において根本的に異なるアーキテクチャを採用している。
TranslatePressのパフォーマンス
TranslatePressはWPMLと同様に、翻訳をWordPressデータベースに直接保存する。コンテンツが増えるにつれて同じデータベース肥大化の問題が発生する。実用的な利点として、翻訳メモリにより各文字列のAPI呼び出しは1回限りだ。新しい言語での初回訪問後、以降の訪問者はキャッシュされたデータベース版を受け取り、追加の処理は発生しない。翻訳が自社データベースに保存されるため、TranslatePressのサービスがオフラインになったりサブスクリプションを解約したりしてもサイトは機能し続ける。
WPMLのパフォーマンス
WPMLは翻訳を言語ごとの重複エントリとしてデータベースに保存する。WP Beginnerのテストでは、キャッシュなしのサイトで0.3〜0.5秒の追加遅延が確認された。質の高いキャッシュプラグインでほとんどを取り戻せるが、データベースの負荷は時間とともに増大する。数百の投稿を複数言語に翻訳したサイトでは、優れたキャッシュを導入していてもオーバーヘッドが無視できなくなる。多言語化の前にキャッシュプラグインを導入し、言語別に異なるキャッシュファイルを配信する設定を行うことが推奨される。
Universallyのパフォーマンス
Universallyは、200以上のエッジ拠点を持つグローバルCDNから翻訳コンテンツを配信し、WordPressデータベースには一切書き込まない。追加する言語数に関係なく、サイトのデータベースサイズは変わらない。キャッシュプラグインで言語別キャッシュを有効にする初期設定は推奨されるが、大半の人気キャッシュプラグインなら簡単なトグル操作で完了する。クラウドで動作するため翻訳はUniversallyのサーバーで保存・同期され、自社データベースを圧迫するものは何もない。
パフォーマンスではUniversallyが明らかにリードしている。グローバルCDN配信とデータベース書き込みゼロの組み合わせは、データベース肥大化が避けられないTranslatePressやWPMLに対して明確な優位性を持つ。
WooCommerce対応
WooCommerceストアの多言語化は、標準サイトの翻訳より複雑だ。動的なカートメッセージやチェックアウト時のエラー通知、自動送信される注文確認メールなど、すべてが顧客の言語で正しく表示されなければならない。顧客がスペイン語でストアを閲覧したのに自動配信レシートが英語だと、混乱を招きブランドの信頼を損なう。
TranslatePressのWooCommerce対応
TranslatePressは追加アドオン不要で、フロントエンドのビジュアルエディターを通じてWooCommerceを翻訳する。商品ページ、説明、カート、チェックアウトフローが自動でカバーされる。注文確認メールは顧客の閲覧言語で送信され、ログインユーザーには最後に使用した言語が記憶される。WPMLと比較した場合のギャップは多通貨対応で、TranslatePressには通貨切り替え機能が組み込まれていない。現地通貨で価格を表示したい場合は、専用のマルチカレンシープラグインが別途必要になる。
WPMLのWooCommerce対応
WPMLのWooCommerce Multilingualアドオン（Multilingual CMSプランに含まれる）は、WP Beginnerの著者が「これまで見た翻訳プラグインの中で最も徹底したWooCommerce統合」と評する出来だ。商品、カテゴリ、属性、バリエーション、カスタムフィールド、カートとチェックアウト、配送方法名、注文確認メールを自動でカバーする。
さらに、200以上の通貨に対応したネイティブのマルチカレンシー機能を内蔵する。為替レートベースの価格設定と、商品・通貨ごとの手動上書きが可能で、所在地に基づく通貨表示により訪問者は自動で現地通貨の価格を目にすることができる。
UniversallyのWooCommerce対応
UniversallyはWooCommerceの翻訳も他のコンテンツと同様に自動処理する。アドオン不要、商品ごとの設定も不要で、商品説明や画像altテキスト、カートとチェックアウトフローがカバーされる。ただしTranslatePressと同様に、ネイティブのマルチカレンシー機能は持たない。現地通貨表示が必要な場合は別途プラグインを用意する必要がある。
WooCommerce対応ではWPMLが圧勝だ。ネイティブのマルチカレンシー、翻訳された商品属性やバリエーションの細かい制御、言語別の注文メールは、他の2つとは明確に異なる次元にある。TranslatePressはほとんどのWooCommerce翻訳ニーズに十分応え、シンプルなストアに適している。Universallyは基本をカバーするが、複雑な多言語WooCommerceセットアップ向けには設計されていない。
カスタマーサポート
多言語サイトで何か問題が発生したとき、サポートの品質と可用性は実際の運用に差をもたらす。3つのツールはいずれもサポートを提供するが、対応時間、実績、応答の一貫性には大きな違いがある。
TranslatePressのサポート
TranslatePressは、大規模なユーザーベースに支えられた強力なサポート評価を得ている。WordPress.orgでは1,600件以上のレビューで4.7/5、Trustpilotでは4.6/5を獲得している。レビューではサポート担当者の名前が頻繁に挙げられ、明確で実践的な回答が迅速に得られたという声が多い。ただしサポートは平日のみで24時間対応ではない点に留意が必要だ。
WPMLのサポート
WPMLのサポート評価は際立っている。9言語で1日22時間対応し、G2とCapterraの両方で4.7/5を獲得している。多数の5つ星レビューにおいて、サポートこそがWPMLを使い続ける理由として挙げられている。「信じられないほど速く正確」「積極的」といった言葉が繰り返し登場する。全プランに直接チケットアクセスが含まれ、過去の解決済みチケットを検索できるフォーラムでは、返信を待たずに一般的な問題を自力解決できる。
Universallyのサポート
Universallyは新しいプラグインだが、WPFormsやAIOSEO、OptinMonsterなどの人気プラグインを手がけるAwesome Motive（WPBeginnerの運営元でもある）によって開発されている。数百万のWordPressサイトで動作する実績あるエンジニアリングとサポート体制を背景に持つ。日常的なサポートはチケット送信で対応し、Proプランユーザーには優先対応が提供される。
ドキュメントも新プラグインとしては充実しており、インストールや言語管理、トラブルシューティング、SEO、開発者API情報をカバーする。しかも開発者ではなくサイト運営者向けに書かれているため、返信を待たずに多くのセットアップ上の疑問を自力で解決できる。
サポートではWPMLが最も評価が高い。ほぼ24時間の多言語対応と、数多くのレビューで「乗り換えない理由」として真っ先に挙げられる強固な評価は、他を凌駕する。TranslatePressはそれに次ぐ位置にあり、平日限定という制約はあるが、評価スコアは高くユーザーベースも最大だ。Universallyは充実したドキュメントとAwesome Motiveのサポートチームを持つが、WPMLに迫るだけのライブサポートの実績はまだ構築途上である。
価格
3つのツールの価格差はこの比較の中で最も大きい。TranslatePressとWPMLは年間定額制を採用し、Universallyは月額の単語従量課金制（米ドル建て）を取る。どれが最もコスト効率が良いかは、コンテンツ量と公開頻度によって変わる。
TranslatePressの価格
TranslatePressにはWordPress.orgで無料のコアプラグインが用意されており、手動翻訳と追加1言語に対応する。有料プランではAI翻訳とSEO Pack、対応言語数が拡張される。Personalプランが年間99ユーロ（約115ドル）、Businessプランが年間199ユーロ（約230ドル）、Developerプランが年間349ユーロ（約405ドル）だ。サブスクリプションを解約しても、既存の翻訳はデータベースに残り、サイトの全言語が機能し続ける点が実務上のメリットとして見逃せない。
WPMLの価格
WPMLには無料版が存在しない。Blogプランが年間39ユーロ（約45ドル）だがWooCommerce非対応、Multilingual CMSプランが年間99ユーロ（約115ドル）で3サイトとWooCommerce対応、Agencyプランが年間199ユーロ（約230ドル）で無制限サイトだ。WPMLの定額制が真価を発揮するのは大規模サイトで、翻訳量に関係なく同じ価格で済む点にある。
Universallyの価格
Universallyは米ドル建てで、月額の単語従量課金制だ。無料プランでは1言語2,000単語まで利用できる。Starterプランが月額7.50ドル（1サイト、1言語、10,000単語）、Businessプランが月額15.80ドル（1サイト、3言語、50,000単語）、Proプランが月額40.80ドル（3サイト、5言語、200,000単語）だ。年間一括払いで約17%割引となり、全プランに14日間の返金保証が付く。
多くの単一サイト運営者にとって、Universallyが価格面で最も有利だ。月額15.80ドルのBusinessプランで50,000単語×3言語の余裕があり、導入障壁が低い。一方、複数サイトを管理する制作会社や、毎日数百ページを翻訳するような大規模運用では、単語数無制限のWPML定額制（年間99ユーロ）が最も高いコストパフォーマンスを発揮する。
この記事のポイント
- セットアップの速さと手軽さを最重視するならUniversallyが最適だ。
- ビジュアル編集と自社サーバー内での翻訳データ保持を求めるならTranslatePressを選ぶとよい。
- 本格的なWooCommerceストアやプロ翻訳ワークフローが必要な場合はWPMLが突出して強力だ。
- いずれのプラグインも多言語SEOの基本はカバーするが、WPMLとTranslatePressが細部まで制御可能だ。
- パフォーマンスへの影響を最小化したいなら、CDN配信でデータベース負荷ゼロのUniversallyが明確に有利だ。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPressの孤立ページをAIOSEOで見つけ内部リンクを修正する完全ガイド
WordPressサイトを運営していると、検索流入が伸び悩むページに遭遇することがある。タイトルを最適化し、被リンクも獲得しているのに、なぜか成果が出ない。そんなときは、サイトの内部構造に問題が潜んでいるかもしれない。具体的には、孤立ページ（オーファンページ）の存在がSEOパフォーマンスを大きく損ねているケースがある。
孤立ページとは、サイト内のどのページからも内部リンクが貼られていないページのことだ。訪問者はもちろん、検索エンジンのクローラーもたどり着けず、インデックスされないまま埋もれてしまう。WP Beginnerの記事によれば、これは見落とされがちなSEO課題だが、修正は想像以上にシンプルだという。
ここでは、All in One SEO（AIOSEO）プラグインのリンクアシスタント機能を使い、孤立ページを一掃する具体的な手順を解説する。サイトの内部リンク構造を可視化し、検索エンジンにとっても人にとっても価値ある導線を再設計しよう。
孤立ページとは何か
孤立ページは、サイト内に存在するにもかかわらず、他のどのページからも内部リンクで参照されていないページを指す。まるで廊下のない部屋のようなものだ。部屋自体は存在するが、そこに至る道が一切ないため、誰にも見つけられない。
WordPressでは、意図せずして孤立ページが生まれることが多い。たとえば、公開した記事をナビゲーションメニューやカテゴリーページに追加し忘れた場合だ。ほかにも、サイトの移行やリニューアル時に内部リンクが切れて発生することもある。また、キャンペーン用のランディングページのように意図的に孤立させるケースもあるが、それらも適切に管理しなければ検索エンジンに悪影響を及ぼす。
上のデモは、孤立ページがサイト内でどのように隔離されているか、そして適切な内部リンクがどれほどアクセス性を変えるかを視覚化したイメージだ。リンク一本で、不可視だったページがサイト全体の情報ネットワークに組み込まれる。
孤立ページがSEOに与える悪影響
Googleをはじめとする検索エンジンは、内部リンクをたどってサイトをクロールし、各ページの価値を評価する。孤立ページにはその入り口がなく、クローラーが存在を認識できない。結果として、インデックスされず検索結果に一切表示されないリスクがある。
また、内部リンクはページ間でリンクエクイティ（SEO評価の伝達）を分配する役割も担う。リンクを受け取れない孤立ページは、たとえ質の高いコンテンツであっても検索順位で不利になる。大規模サイトではクロールバジェットの浪費にもつながり、限られたクロール回数が無駄に消費される。
さらに、ChatGPTやPerplexityといったAI検索ツールは、インデックスされた信頼性の高いページを優先的に参照する。孤立ページはそもそもインデックスされにくいため、AIが回答を生成する際の情報源として選ばれる可能性が極めて低くなる。
この図のように、わずかな内部リンクの有無で検索エンジンからの可視性は大きく変わる。サイト全体の評価にも影響するため、孤立ページの放置は避けたい。
AIOSEOリンクアシスタントを使った孤立ページの検出手順
ここからは、WP Beginnerの記事でも推奨されているAll in One SEO（AIOSEO）プラグインのリンクアシスタント機能を用いた具体的な検出プロセスを見ていく。Pro版以上で利用できるが、まずは無料版でインターフェースを試すことも可能だ。
プラグインのインストールとリンクアシスタントの有効化
AIOSEOを公式サイトから入手し、WordPress管理画面の「プラグイン」→「新規追加」→「プラグインのアップロード」からzipファイルをインストールする。有効化後、AIOSEOの一般設定でライセンスキーを認証すれば準備完了だ。
次に、管理メニュー「AIOSEO」→「リンクアシスタント」へ移動し、「リンクアシスタントを有効化」ボタンをクリック。その後、表示されるポップアップで「今すぐスキャン」を実行する。これにより、サイト全体の内部リンク構造が分析され、各ページの被リンク状況がマッピングされる。初回スキャンはサイト規模によって数分かかることがあるため、完了まで待とう。
孤立ページ一覧の確認と分析
スキャンが完了したら、リンクアシスタント画面の「孤立した投稿」タブを開く。ここに、内部リンクが一切ないページが一覧表示される。各ページの公開日、内部リンク数（当然0）、アフィリエイトリンクや外部リンクの有無、そしてAIOSEOが提案する簡単な対処アドバイスも確認できる。
まずはこの一覧を眺め、量に圧倒されないことが大切だ。全てを修正する必要はなく、優先順位をつけて対応する。次のセクションでその判断基準を説明する。
孤立ページの優先順位付けと修正方法
見つかった孤立ページのすべてに内部リンクを追加すれば良いわけではない。薄いコンテンツや重複ページはむしろ削除やリダイレクト対象になる。ここでは、WP Beginnerの記事で紹介されている優先度の考え方を整理する。
どのページを救うべきか
まず、外部サイトから被リンクを獲得しているページは最優先だ。Google Search Consoleの「トップリンクサイト」レポートなどで確認し、既にリンクエクイティが流れ込んでいるページを内部リンクで再接続すれば、サイト全体にその価値を循環させられる。
次に、検索クエリでの表示回数やクリック数がわずかでもあるページも有望だ。Google Search Consoleの「検索パフォーマンス」レポートで、孤立ページがいくつかのインプレッションを得ているなら、内部リンクで後押しすれば順位が上昇する可能性が高い。
さらに、MonsterInsightsのような解析プラグインを使い、実際にサイト上でのページビューがあるかも確認しよう。ゼロに近いページはリダイレクトか削除を検討する。商品ページやサービスページなど、ビジネスに直結するページも積極的に救済したい。
リンクの追加とサイト構造への組み込み
修正対象を決めたら、AIOSEOのリンクアシスタントが自動提案する内部リンクを活用する。各孤立ページの詳細を開くと、「アウトバウンド提案」（このページから貼るべきリンク）と「インバウンド提案」（他のページからこのページへ貼るべきリンク）が表示される。アンカーテキストは自然な文脈で編集し、「リンクを追加」ボタンで即座に適用される。いちいち投稿編集画面を開く手間が省けるのが大きな利点だ。
特に重要なページは、ナビゲーションメニューやカテゴリーページにも追加すると、サイト全域からアクセス可能になる。一回の設定で、全ページからの強力な導線を確保できる。
このように、AIOSEOの提案を数クリックで反映するだけで、孤立ページがサイトのネットワークに組み込まれる。ただし、一つのページに内部リンクを詰め込みすぎると、かえってリンクエクイティが希薄になり不自然に見えるため、読者にとって本当に役立つリンクだけを選ぶことが肝心だ。
孤立ページ管理のベストプラクティスと監査チェックリスト
孤立ページ対策は一度きりの作業ではない。サイトの更新やリニューアルのたびに新たな孤立ページが生まれる可能性がある。定期的な監査を習慣化することで、SEOの土台を強固に保てる。
定期的な監査の流れ
WP Beginnerの記事が推奨するチェックリストは以下の通りだ。1〜2ヶ月に一度、あるいはサイト構造を大きく変えた直後に実行するとよい。
- AIOSEOリンクアシスタントで「孤立した投稿」タブを確認し、内部リンクがゼロのページを洗い出す。
- Google Search Consoleで被リンクと検索パフォーマンスをクロスチェックし、優先度を決める。
- MonsterInsightsやGoogle Analyticsで実際のページビューを確認し、トラフィックがあるページを救済対象とする。
- 各ページを「内部リンク追加」「リダイレクト」「noindex」「削除」のいずれかに分類する。
- 救済するページにはAIOSEOの提案リンクを追加し、重要なページはナビゲーションにも組み込む。
- 被リンクがある削除済みページは、関連ページへ301リダイレクトを設定してリンクエクイティを保全する（AIOSEO Proのリダイレクションマネージャーが使える）。
- 意図的な孤立ページ（広告用LPなど）にはnoindexタグを付与し、検索結果に出さないようにする。
このサイクルを回せば、孤立ページがサイトの評価を下げるリスクを大幅に減らせる。とくに大規模サイトではクロールバジェットの最適化にもつながり、重要なページが確実にインデックスされる環境を維持できる。
この記事のポイント
- 孤立ページは内部リンクがなく、検索エンジンにもユーザーにも発見されない。サイトのSEOにおいて深刻なマイナス要因となる。
- AIOSEOのリンクアシスタントを使えば、サイト全体をスキャンして孤立ページを簡単に特定できる。
- すべての孤立ページを修正する必要はなく、被リンクやトラフィック、ビジネス価値に応じて優先順位を付ける。
- 内部リンクの追加は、AIOSEOの自動提案を活用すれば編集画面を開かずに素早く実行可能。ナビゲーションへの追加も有効だ。
- 定期的な監査と適切なリダイレクト・noindex処理を含めた管理体制が、持続的なSEO改善の鍵となる。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPressコミュニティの魅力と現実。2026年WordCamp Canadaリードが語る
WordPressコミュニティは、技術者が集まるだけの場ではない。2026年のWordCamp Canadaでリードオーガナイザーを務めるCathy Mitchell氏は、WP Tavernのポッドキャスト「Jukebox」でコミュニティがもたらす帰属意識と充足感の重要性を語った。特に子育てが一段落した後の「エンプティネスター（空の巣症候群）」世代にとって、この場は単なる交流を超えた意味を持つ。
オープンで、障壁が少なく、誰でも重要な役割を任される文化。この特異な環境は、従来の企業社会や他のボランティア組織とは一線を画す。Mitchell氏の経験は、経済的な見返りだけでは測れない貢献の価値と、変化する時代の中でWordPressが直面する課題を浮き彫りにした。
「掃除だけ」では終わらない、圧倒的にオープンな門戸
WP TavernのポッドキャストでNathan Wrigley氏との対談に臨んだMitchell氏は、2007年からWordPressに関わるベテランだ。育児休暇中の個人的なプロジェクトから始まった活動は、2008年にWPBaristaとして事業化した。
彼女が強く印象に残っているのは、コミュニティに参加した際の障壁の低さだ。多くの企業組織では、意味のある仕事を任されるまでに長い下積み期間が必要となる。一方で、WordPressコミュニティの文化はまったく異なる。Mitchell氏は昨年、WordCamp Canadaの運営チームに参加した際の驚きをこう表現している。「企業の世界では、何か意味のあることを任されるまで、延々と掃除をさせられるようなものだ。でもここでは違った」。
この「イエスと言う」文化は、参加者の能力を信頼し、失敗しても周囲が支える構造の上に成り立っている。Mitchell氏も、その流れに乗って気づけばWordCamp Canadaのリードオーガナイザーに抜擢されていた。
「見返りゼロ」の貢献が事業の追い風になる仕組み
WordPressは長らく右肩上がりの市場シェア拡大を続けてきた。その間、企業によるイベントスポンサーやコミュニティ貢献は、必ずしも厳密な投資対効果を問われなかった面がある。上昇気流に乗っていれば、自然とビジネスも成長したからだ。
しかしMitchell氏は、現在の状況を「完璧な嵐」と表現する。経済の不透明感から企業の財布のひもは固くなり、代理店やプラグイン開発の競争は激化した。WP Tavernの対談で彼女が指摘したように、かつては広告すら打つ必要のなかったビジネスモデルは、もはや通用しなくなっている。
一方で、オープンソースプロジェクトへの貢献が間接的にビジネスを支える構造にも言及している。具体的なメリットは3つある。
- 採用の容易さ。貢献活動で名前が知られていれば、優秀な人材が応募しやすくなる。
- 人材の見極め。普段のコントリビューション（貢献活動）を通じて、スキルや人柄を事前に評価できる。
- エコシステム全体の健全化。WordPress自体が衰退すれば、自社ビジネスも立ち行かなくなる。
Mitchell氏は、経済的なROIだけでは説明できない利他的な価値と、それに伴う事業上の副次的利益を明確に区別していた。それがコミュニティスポンサーの継続を支える論理となっている。
「孤独の処方箋」としてのコミュニティ
今回のポッドキャストで特に印象的だったのは、Mitchell氏が「奉仕」を孤独への解毒剤と位置づけた点だ。
対談では、米国公衆衛生局長官が2023年に「孤独の流行」を宣言した統計が紹介された。週15箱の喫煙に匹敵する健康被害をもたらすとされ、特に18歳から24歳の若年層の79%が孤独を感じているというデータがある。技術の進化とこの数字の上昇は、無関係ではないというのが両者の共通認識だった。
Mitchell氏は、ボランティア活動がこの問題への強力な回答になり得ると語る。共通の目標に向かって他者と協力し、自分のスキルを誰かのために使う体験は、「役に立っている」という実感と強い連帯感を生む。WordPressコミュニティには、高い専門性を持つ技術者から、コーヒーを淹れるという気軽な貢献まで、あらゆる参加形態が用意されている。
技術者が自発的に集い、支え合う文化は、AIが浸透する時代にこそ希少価値を持つ。人間同士の直接的な交流が幸福感の基礎になるという考え方は、デジタルネイティブ世代にWordPressコミュニティの意義を伝える上で、強力なメッセージとなるだろう。
次世代をオープンソースに引き込むために
対談の終盤、Mitchell氏はWordCamp Canada 2026への意気込みを語る中で、Open Sourceの未来に向けた重要な視点を示した。それは「若者を巻き込まなければならない」という強い危機感だ。
彼女の考えは明快だ。かつてWordPressの成長期に恩恵を受けた世代には、今こそ次世代に扉を開く責任がある。具体的には、大学の単位取得と連携する「Campus Connect」や「WordPress Credits」といったプログラムをカナダ国内で拡大したいとしている。これにより、学生は卒業要件を満たしながら、オープンソースの文化や実務スキルに触れることができる。
Mitchell氏は、オープンソースとAIの組み合わせにこそ未来があると確信している。AIがクローズドな有料APIに囲い込まれれば、テクノロジーの進歩は限定的になる。オープンなコードベースと、それを支える人間のコミュニティがあってこそ、技術は広く社会に還元されるという信念だ。
ただし、この構想が簡単に実現するわけではない。人々の関心を引き、参加の重要性を伝えるのは、依然として難しい課題だ。しかし、今のうちに基礎を固めておかなければ、WordPressを取り巻く楽観的な未来は描けない。Mitchell氏が主導するWordCamp Canadaは、まさにそのための土台作りの場となる。
この記事のポイント
- WordPressコミュニティは「イエス」を基本とするオープンな文化で、未経験者にも門戸が開かれている。
- 企業によるコミュニティ貢献は、短期的なROI以上に採用や業界の健全化に寄与する。
- ボランティアによる共通目標へのコミットメントは、現代の孤独問題に対する有効な解毒剤となり得る。
- 次世代をOpen Sourceに引き込む教育連携が、WordPressエコシステムの長期的な存続には不可欠だ。
- 2026年のWordCamp Canadaは、経済的逆風下でもコミュニティの価値を再定義する試金石となる。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WPMU DEVがEmDash Hostingを発表、WordPressと同じ管理画面でTypeScript CMSを運用可能に
WordPress制作者の多くにとって、その手間こそが「EmDashを一度見てみたい」という思いを机の隅のTo-Doリストに留まらせる最大の壁だった。
WPMU DEVが発表したEmDash Hostingは、まさにその手間を取り除くために設計されたサービスだ。2026年6月の公式アナウンスにより、WordPressサイトと同じ管理画面からワンクリックでEmDashサイトを立ち上げられる環境が提供されている。
EmDash HostingがWordPress制作者にもたらすもの
EmDashそのものは、CloudflareがオープンソースのMITライセンスで公開したTypeScript製CMSだ。サーバーレスかつセキュリティ重視の設計思想を持ち、従来のCMSとは一線を画すアーキテクチャで注目を集めている。
WPMU DEVが提供するのは、そのEmDashを動かすためのホスティングと管理のレイヤーである。具体的には、同社のUnlimited Hostingプラットフォーム上でEmDashサイトを稼働させる仕組みだ。Unlimited Hostingは、多数のサイトを運用するエージェンシーやフリーランサー向けに構築されたマネージド環境で、3GHz以上のIntel XeonプロセッサとNVMe SSDを搭載した高性能サーバー上で50以上のサイトを月額15ドルから運用できる。
WordPressとEmDashの混在運用が現実に
今回の発表で重要なのは、EmDashサイトがこのUnlimited Hostingの枠組みに含まれるようになった点だ。サーバーのリソースが許す限り、WordPressのインストールと並行してEmDashサイトをいくつでも立ち上げられる。
このアプローチが最初に訴求するのは、EmDashに興味を持ちながらも、テスト用に別のインフラを用意することに二の足を踏んでいたエージェンシーやフリーランサーだろう。TypeScriptベースでAstroフレームワークを採用したCMSを、ローカル環境のセットアップなしで触れる点は、開発者にとっても低リスクな検証手段となる。
従来のCLIベースのセットアップでは、環境構築だけで数時間を要していた。EmDash Hostingではワンクリックでサイトが立ち上がり、即座に動作確認に移れる。
WordPressスタックにおけるEmDash Hostingの立ち位置
現状、EmDashを評価する人の多くは、それを独立したプロジェクトとして扱っている。専用のリポジトリ、デプロイ先、認証情報、そして運用の考え方も別々だ。サイトを維持すると決めた場合、WordPressの運用管理とEmDashの運用管理という2つの業務を並行して回すことになる。
WPMU DEVのEmDash Hostingは、この2つを1つに統合する。EmDashサイトはWordPressサイトと同じサーバー上に存在し、Hubと呼ばれる単一のダッシュボードから同じツールで管理される。
エージェンシーにとっての利点は明快だ。EmDashのクライアントサイトもWordPressのクライアントサイトも、同じ一覧に表示され、同じ方法でバックアップされ、同じログイン経路でアクセスできる。つまり、EmDashはワークフローの中で「特別扱い」する必要がなく、既存の運用に自然に溶け込む。
実験コストがゼロに近づく
WP Mayorの記事が指摘する通り、このサービスの本質的な価値は「EmDashがWordPressを置き換える」ことではなく、「EmDashが既存のワークフローで自動的に扱えるもう1つのサイト種別になる」点にある。実験にかかるコストは時間以外ほぼゼロになり、導入の敷居は極めて低くなる。
管理画面が統合されることで、EmDashサイトの追加が運用負荷の増大に直結しない。これは新技術の評価フェーズにおいて決定的な差となる。
EmDash Hostingの実際の動作
WPMU DEVの発表から、実運用面で注目すべきポイントを5つに整理する。
インストールは文字通りワンクリック
標準的なEmDashのセットアップはCLIツールを経由するが、EmDash HostingではHubの管理画面からボタン1つでサイトが作成される。構築の仕組みを知る前に、まず動く状態を確認したいというニーズに応える設計だ。
WPMU DEVは初期状態で使えるコンタクトフォームプラグインも同梱しており、今後さらにプラグインを追加する予定としている。プラグインはローカルで動作するため、Cloudflareのアカウントを別途取得する必要はない。
WordPressサイトとまったく同じ管理体験
サイトが公開されると、WPMU DEV HubからのSSOログイン、日次バックアップ、カスタムドメイン設定、無料SSL証明書、サーバーレベルのSSH/SFTPアクセス、ストレージ使用量を可視化するサーバー分析が利用できる。新興プラットフォームでは後回しにされがちな基盤機能が、WPMU DEVの既存ホスティングレイヤーからそのまま提供される点が特徴だ。
セキュリティとサポートがそのまま適用
EmDashサイトにはサーバーレベルでのWAF（Webアプリケーションファイアウォール）とAntiBot保護が適用され、Proメールおよび24時間365日のライブチャットサポートも付帯する。WP Mayorの記事が評価するのは、サポートに対するWPMU DEVの正直な姿勢だ。同社は「我々もまだ学習中である」と明言し、EmDashに関する問い合わせには最善を尽くすとしつつ、この新しいCMSに対する深い専門知識を誇示しない。初期段階のCMSを試す際、障害が発生しても自力で解決するしかない状況が多い中、少なくともホスティング環境を熟知したサポートチームが背後にいることは安心材料となる。
公開直後からページが正しく表示される
これは実際に遭遇するまで気づきにくい問題だ。デフォルトのEmDashテンプレートでは、新規ページやプロジェクトを作成して公開しても、公開URLにアクセスすると404エラーになるケースがあった。理由は、EmDashが内部でAstroフレームワークを使用しており、ルーティングがテンプレート側で処理されるためだ。WordPressのように公開コンテンツが自動的にルーティングされるわけではない。
WPMU DEVはホスティング用のテンプレートに修正を加え、公開したページやプロジェクトが即座に表示されるようにしている。書類上は小さな変更だが、新プラットフォームを触り始めて10分で「操作ミスなのかバグなのか」と困惑する事態を防ぐ効果は大きい。
メール設定が自動化されている
EmDashのメール処理はWordPressと異なる仕組みを持ち、この違いが様々な機能の動作不良を引き起こす原因になりやすい。WPMU DEVはUnlimited Hosting上のEmDashサイトにメール設定を自動構成するプラグインをバンドルしており、パスキーログインリンクやフォーム通知などのトランザクションメールが、手動の配信設定なしですぐに機能する。
新興CMSの導入時に障壁となる運用面の課題が、ホスティング側のレイヤーで吸収されている。
ユーザータイプ別に見るメリット
エージェンシー
現時点でEmDashをテストする可能性が最も高いのはエージェンシーだろう。クライアントからEmDashについて質問されたときに、運用体制を再構築することなく「対応できる」と答えられる点が最大の魅力だ。チームが日常的に使っているHubダッシュボードの中で、サイトの立ち上げ、評価、管理が完結する。
フリーランサーと開発者
現在注目を集めるTypeScript CMSを、環境構築に午後を費やすことなく実際に触れる手段となる。EmDashはAIエージェントを第一級のユーザーとして扱う設計思想を持ち、WordPress開発向けAIツールと同じ文脈で語られることが増えている。このホスティングを利用すれば、半日かけて環境を整える代わりに、すぐに自分の意見を形成できる。
ブロガーとコンテンツ制作担当者
より新しいパブリッシングスタックを試しつつ、WPMU DEVのマネージドバックアップやセキュリティ、サポートという安全網を維持できる点が訴求ポイントとなる。
WooCommerceストア運営者と大規模サイト管理者
WP Mayorの記事も指摘する通り、現時点では現実的かつ慎重な姿勢が求められる。EmDashそのものがまだ初期段階であり、本格的な移行対象として検討する段階ではない。このホスティングは「CloudflareのCMSがどこへ向かうのか、自分の手で感触を掴むための最も摩擦の少ない方法」と捉えるのが妥当だ。
制限事項とトレードオフ
最大の留保条件はホスティングそのものではなく、CMSとしてのEmDashの成熟度にある。プラグインマーケットプレイスも、サードパーティ製テーマのライブラリも、まだ充実しているとは言えない。現時点でEmDash上に構築できるものは、20年にわたるWordPressの開発が生み出した世界と比較すれば、明らかに限定的だ。
EmDash HostingはEmDashの運用を容易にするが、EmDashのエコシステムそのものを成熟させることはできない。本番サイトの大部分にとって、WordPressが依然として現実的な選択肢であることに変わりはない。
WooCommerceはさらに明確な例だ。ストアを運営している場合、ビジネスはWordPressとWooCommerceホスティングのエコシステムの中に存在しており、EmDashはその代替にはならない。ストア運営者にとっての正直な用途は、現段階では好奇心と実験に留まるだろう。
プラットフォームに関する制約もある。EmDash HostingはWPMU DEVのPremiumメンバーシップ限定で提供される。まだWPMU DEVのエコシステムに入っていない場合、EmDashを評価するということはWPMU DEVも同時に評価することを意味する。
機能面の現状
すべてのHubツールがEmDashに対応しているわけではない。現在EmDashで利用できる機能は以下の通りだ。
- ワンクリックインストール
- SSOログイン
- リセット
- リビルド/再起動
- ドメイン管理
- Proメール
- バックアップと復元
- WAF（Webアプリケーションファイアウォール）
- AntiBot保護
- サーバー分析
- SSH/SFTPアクセス
- 無料SSL証明書
- クライアント管理と請求
- サポートチケット
一方で、WordPress側では定番となっているステージング機能やクローン機能は、EmDash向けにはまだ提供されていない。SSH/SFTPはサーバーレベルでのアクセスとなり、1つのサーバーユーザーが同一サーバー上の全サイトにアクセスする形となる点にも注意が必要だ。
料金とライセンス
EmDash HostingはWPMU DEVのUnlimited Hostingに含まれるため、サーバー料金を支払えば、容量が許す限りWordPressサイトと並行してEmDashサイトを無制限に稼働させられる。サイト単位の追加料金は発生しない。
プランは以下の通り構成されている。
- Alpha MU（月額15ドル）: 1GB RAM、23GBストレージ
- Beta MU（月額23ドル）: エージェンシー向けの最も人気のあるプラン
- Eta MU（月額300ドル）: 32GB RAM、455GBストレージ
全プランで帯域幅は無制限、30日間の返金保証が付く。EmDash本体はMITライセンスのオープンソースであり、CMS自体にライセンス費用はかからないが、マネージドホスティングを利用するにはWPMU DEV Premiumメンバーシップへの加入が必要となる。
このサービスは、あくまでも「CloudflareのCMSがどの方向へ進むのか、最小の摩擦で自分の手で感触を掴む手段」として読むのが賢明だ。本業のサイトは今ある場所に置いたまま、未来の選択肢を検証できる点に価値がある。
この記事のポイント
- WPMU DEVのEmDash Hostingは、WordPressと同じHub管理画面からワンクリックでEmDashサイトを立ち上げられるマネージドホスティングである
- Unlimited Hostingプランに含まれ、追加料金なしでEmDashサイトをサーバー容量の許す限り稼働させられる
- 日次バックアップ、WAF、AntiBot、SSL、SSH/SFTPなど、新興CMSに不足しがちな運用基盤が最初から整備されている
- EmDashのエコシステムはまだ初期段階であり、本番サイトの移行先としては時期尚早だが、技術検証の手段としての価値は高い
- エージェンシーやフリーランサーにとって、運用フローを変えずに次世代CMSを評価できる点が最大の利点である
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
UXリサーチに認知的多様性を。課題発見率が1.8倍に向上した実証実験の全容
Webサイトの使いやすさは、すべてのユーザーにとって重要な要素だ。Smashing Magazineで公開された2026年の研究は、UXリサーチにおける決定的な盲点を浮き彫りにした。認知障がいを持つ参加者をテストに加えることで、一般的な参加者の1.8倍にあたるユーザビリティ課題と改善提案が得られたのだ。
認知障がいは記憶や集中、学習といった情報処理に影響を与える機能障がいの総称であり、アメリカでは人口の約14%に相当する最も一般的な障がいだ。Yale大学の調査でも、その割合は急速に増加している。そして誰もが加齢とともに、多かれ少なかれ認知的な衰えを経験する。このデータは、サイト制作者が長期的に無視できない数字である。
認知インクルーシブなリサーチが示した圧倒的な数値
Fable社の研究者がカリフォルニア大学アーバイン校と共同で実施した研究では、3つの異なるWebサイトを対象に30件のユーザーインタビューが行われた。参加者は「記憶・集中・学習に困難を感じるか」という設問を基に、認知障がい群と一般群に分けられた。
テスト対象には、AIプロトタイピングツールで生成されたレシピサイト、書店サイト、美容院サイトが用意された。単純な構造のものから、意図的に複雑な予約フローを備えたものまで、現実のWebサイトに近いグラデーションで設計されている。
この結果は、特定の業界やサイト種別に限ったものではない。単純なレシピサイトでも、認知参加者は平均3.4個多くの課題を発見した。複雑な予約システムを持つ美容院サイトでは、平均7個もの追加課題が浮上している。課題のカテゴリ別で見ても、コンテンツ、ボタン・リンクの機能性、アイコン・視覚要素、メディアの4領域で認知参加者の指摘が一般参加者を大きく上回った。
Smashing Magazineの記事では、Fable社の研究者が「認知参加者から得られるフィードバックは、単に障がい対応を超えて、すべてのユーザーの認知的負荷を下げる本質的な改善に直結する」と結論づけている。これはWordPressサイトの管理画面やフロントエンドの設計思想にも通じる重要な視点だ。
なぜWordPressサイト運用者がこの知見を重視すべきなのか
高齢化社会とユーザー層の変化
アメリカ国勢調査局の予測によれば、65歳以上の人口比率は現在の17%から2060年までに25%に達する見込みだ。これは4人に1人が高齢者になる社会を意味する。加齢に伴う認知機能の低下は、誰しもが経験するライフステージの変化であり、将来的にユーザーの大多数が多かれ少なかれ「認知的負荷に敏感なユーザー」になるということだ。
WordPressサイトを運用する企業や個人事業主にとって、今のうちから認知負荷の少ない設計を取り入れることは、単なるアクセシビリティ対応ではなく、市場適合性を維持するための先行投資になる。高齢者だけでなく、情報過多の環境で育ったZ世代、育児や仕事で常に注意散漫な多忙層にも、この種の配慮は届く。
「使えない」から「買わない」への直結
今回の研究で最も示唆的だったのは、美容院サイトのCrown & Combで発生した現象だ。このサイトは意図的に複雑な予約フローを持ち、「ブライダルパッケージを見つける」というタスクを極端に困難に設計していた。ここで認知参加者が指摘した「予約日選択がフローの後半にある」「支払い方法が不明確」「類似名称のサービスが区別できない」といった問題は、一般参加者も潜在的に感じていた障壁だった。
しかし一般参加者は「なんとなく進めてしまう」のに対し、認知参加者は明確に「離脱」または「強い不満の表明」という行動を示した。この差は、実店舗でいえば「不満を言わずに去る客」と「不満を口にしてから去る客」の違いに近い。不満を言わない客の方が多いからといって、その体験が良好だったわけではない。
EC機能を持つWordPressサイトであれば、チェックアウトフローの曖昧さはそのまま収益機会の損失につながる。認知参加者のフィードバックは、その損失リスクを可視化する早期警告システムとして機能する。
認知的負荷を下げる3つの具体的アプローチ
1. コンテンツの出典と文脈を明確化する
研究では、レシピサイトで「情報の出典が明示されていれば信頼度が上がる」という指摘が複数あった。ブログ記事の見出しに十分な文脈がないケースも「何についての記事か判断できない」と指摘されている。WordPressのブログ運営において、この問題は特に顕著だ。
具体的には、記事タイトルだけで内容の全体像が推測できるか、引用やデータの出典がリンクとして明示されているか、という2点を定期的に監査するだけで、認知負荷は大きく下がる。プラグイン「Yoast SEO」や「Rank Math」の可読性分析も、この観点で活用できる。
2. ボタンとナビゲーションの「予測可能性」を高める
書店サイトのTurning Pagesでは、「Add to book bag」ボタンの挙動が予測できないという指摘が相次いだ。クリック後のフィードバックがない、カートに入ったかどうかの確認が困難、といった問題だ。認知参加者は「サイトの反応が予測できないと、自信を持って操作できなくなる」と報告している。
WordPressのWooCommerceを例にとれば、「カートに追加」ボタンの押下後に視覚的フィードバック（カートアイコンのバッジ更新、簡易通知の表示）があるかどうかは、売上に直結する。また、ナビゲーションメニューの項目名が抽象的で、クリック後の遷移先が予測できない場合も同様の障壁となる。「サービス」より「Web制作の料金プラン」、「お問い合わせ」より「3分で完了する見積もり依頼」のように、具体性が認知負荷を下げる。
3. レイアウトと視覚要素の整理
レシピサイトのStrong Snacksでは、記事本文の途中にレシピカードが挿入されるレイアウトが「読書の流れを妨げる」と指摘された。また、連続的なアニメーションや広告が「内容に集中できない原因」として挙げられている。これらはWCAG（Web Content Accessibility Guidelines / ウェブコンテンツアクセシビリティガイドライン）の認知アクセシビリティに関する補足ガイダンスでも、回避すべきパターンとして明記されている。
WordPressテーマのカスタマイズでは、サイドバーと本文エリアの役割分担を明確にし、自動再生するスライダーやアニメーションには必ず一時停止機能を付ける。Gutenbergのブロックパターンを使う場合も、情報量の多いカラムレイアウトより、縦方向のシングルカラムを優先したほうが、認知負荷は低くなる。
認知インクルーシブなリサーチを始めるための現実的な手法
大規模なユーザーテストが難しいWordPressサイト運営者でも、小さな一歩から始めることはできる。研究チームが推奨するのは「タスク完了率だけでなく、主観的な負荷を尋ねる」というアプローチだ。具体的には、以下の3つの質問を既存のアンケートや簡易テストに追加するだけでも、認知負荷の検出感度が上がる。
- 「この操作のあと、どのくらい疲れを感じましたか（1〜5の5段階）」
- 「作業中、気が散る要素はありましたか（自由記述）」
- 「もう一度同じことをするとしたら、どの部分を省略したいですか（自由記述）」
研究では、ベルメディアのUXマネージャーが「認知ユーザーとの2回のセッションは、得られる洞察の量からすると200回分に感じる」とコメントしている。これは大げさな表現ではない。認知障がいを持つユーザーは、情報を取捨選択するフィルターが相対的に弱いため、サイトの問題点をありのままに報告する傾向がある。結果として、短時間で濃密なフィードバックが得られる。
昨今のアクセシビリティ対応の文脈では、スクリーンリーダーやキーボード操作といった物理的アクセスが注目されがちだ。もちろんそれらも重要だが、Smashing Magazineの記事が強調するのは、認知的アクセシビリティのほうが「すべてのアクセシビリティ対応への入り口として機能する」という点だ。認知的負荷、明瞭さ、予測可能性にまず焦点を当てることで、その後の支援技術対応の基盤が整うという順序の提案である。
この記事のポイント
- 認知障がいを持つユーザーをUXリサーチに含めることで、一般的な参加者の約1.8倍の課題を発見できた実証データがSmashing Magazineで公開された
- 加齢による認知機能低下は全ユーザーに共通する未来の課題であり、今のうちから設計に取り入れることが長期的なサイト価値を高める
- WordPressサイト運営者は「コンテンツの出典明示」「ボタン挙動の予測可能性」「レイアウトの整理」の3点から着手できる
- リサーチ手法として、タスク完了の有無だけでなく「操作後の疲労感」を尋ねることで、認知負荷の問題を可視化しやすくなる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
デザインシステムをAI対応にする実践手法
AIによるプロトタイプ生成は、技術的には可能でも、品質面で期待を下回ることが多い。根本原因はデザインシステムの小さな不整合にある。ハードコードされた値や未定義のルールが、AIの出力を不安定にしているのだ。
Smashing Magazineの記事によれば、AtlassianのHardik Pandya氏がこの問題に対する実践的な解決策を提示している。デザイン判断をインフラとして扱い、AIが読める形式で設計ルールを明文化する手法だ。本稿では、AI対応型デザインシステムを構築するための具体的なステップを解説する。
デザイン判断をソフトウェアインフラとして扱う発想
AIに優れた出力を期待するなら、人間側から明確な道筋を示す必要がある。どのコンポーネントを選ぶべきか、アクセシビリティをどう担保するか。そして、判断の優先順位と設計原則を提示する責任はデザイナーにある。
具体的には、デザイン上のあらゆる判断を「Specファイル」という形で構造化し、AIが常に最新の指示を参照できる状態を維持する。これはコードの依存関係管理と本質的に同じ考え方だ。口頭での合意やSlackの過去ログに埋もれた意思決定は、AIにとって存在しないに等しい。
FigmaLintが提供する監査の自動化
FigmaLintは、デザインシステムの監査を支援する無料のFigmaプラグインだ。トークンの一貫性、状態定義の有無、レイヤー命名規則、そしてハードコードされた値の検出を自動化する。デザインデータのクリーンアップを効率的に進められる点が最大の利点である。
このツールの実用的な価値は、監査スクリプトとしての役割にとどまらない。サードパーティから提供されたコンポーネントライブラリを精査する局面でも有効だ。外部ベンダーのデザインシステムが、自社のAI生成プロトタイプと整合するかどうかを定量的に確認できる。
ただし注意すべきは、FigmaLintで検出した問題を手動で修正し続けるだけでは、根本的な解決にならないという点だ。改善したルールをSpecファイルに落とし込み、AI自身が次回から同じミスをしないよう仕組み化することが重要になる。
AI品質を支える三層構造の設計
高品質なAIプロトタイプを継続的に得るには、「Specファイル」「トークン層」「監査スクリプト」の三層を整備する必要がある。この構造はソフトウェア開発における「ドキュメント、ライブラリ、CIテスト」の関係と相似形だ。
Specファイルは単なるガイドラインではない。スペーシング、配色、コンポーネントの適切な使い分けといった具体的な制約を、Markdown形式でAIに提供するテキストベースの仕様書である。AIがモックアップ画像を常に正しく解釈できるとは限らないため、テキストによる明示的な指示がコスト効率と精度の両面で優位に立つ。
トークン層はデザイントークンを変数として定義する層だ。AIが自由に「それらしい値」を捏造する余地を排除し、必ず定義済みの閉じたセットから値を選択させる。これにより、ブランドカラーやフォントサイズの意図しない逸脱を防ぐ。
監査スクリプトは、AIが生成した成果物を自動チェックする仕組みである。ハードコードされた値を検出し、Specファイルから逸脱した部分にフラグを立てる。AIが自分のミスを認識し、次回の生成時に改善するためのフィードバックループを形成するわけだ。
デザインシステムのアップデート時には、同期ルーチンがどのSpecファイルを更新すべきかを特定する。AIが古い仕様を参照したままコードを生成する事態を防ぐためだ。バージョン管理され、常に最新のSpecだけがAIに読まれる環境を維持しなければならない。
AI対応デザインシステムがもたらす現場の変化
この手法を導入した組織では、プロトタイプ生成の手戻りが減少し、人間のレビュー工数が大幅に最適化される。IBMのCarbonデザインシステムや、Atlassianの事例では、AIが初回から許容可能な品質のコードを出力する確率が明確に向上したと報告されている。
ただし、これはAIの性能が向上したというより、人間が指示の質を根本的に変えた結果だ。従来の「何百ページもあるPDFの仕様書」をAIに読ませる方法では、文脈の欠落と解釈のブレが避けられなかった。Specファイルはこの問題を、小さく分割され相互参照が明示されたテキストファイルとして解決する。
技術的負債やデザイン負債をAIが魔法のように解消することはない。明確な判断基準と構造化された指示がなければ、AIは単に混乱をコード化するだけである。デザイナーがどれだけ意図的かつ正確にAIを導けるかが、プロトタイプの最終品質を決定づける時代に入った。
この記事のポイント
- AI生成プロトタイプの品質低下は、デザインシステムの小さな不整合に起因する
- 口頭での意思決定をSpecファイルに落とし込み、AIが参照できるインフラとして扱う
- FigmaLintでトークンやハードコード値の監査を自動化し、デザインデータをクリーンに保つ
- Specファイル、トークン層、監査スクリプトの三層構造でAIの出力を継続的に改善する
- テキストベースの明示的指示が、AIのコンテキスト理解精度を劇的に向上させる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerceモノレポのビルドが大幅高速化、コールドビルド60%減。メモリ使用量84%削減
WooCommerceのモノレポ（単一リポジトリ）を使った開発において、ビルドにかかる時間とメモリ消費が大幅に改善された。2026年6月5日、Developer WooCommerce Blogで公開された記事によると、コールドビルド時間が60%削減、ウォッチ（ファイル監視）の準備完了時間が75%短縮、開発時ウォッチプロセスのメモリ使用量が84%削減されたという。
計測環境はM4 Maxプロセッサ（48GB RAM、macOS 26）で、ベースラインから顕著な低下を確認している。一連のプルリクエストによってビルドプロセスを再設計し、開発者体験を飛躍的に向上させた内容を解説しよう。
本記事では、実際に実施されたビルド最適化の技術的詳細と、今後のCIスループット向上計画を紹介する。
WooCommerceモノレポのビルドが抱えていた課題
WooCommerceのコードベースは多数のパッケージと連携しており、開発時のwatch:buildコマンドは最大128個のプロセスを起動していた。それぞれがESM（ECMAScript Modules）やCJS（CommonJS）、webpackによる監視を分担し、さらにwireitモニターとPNPMのランチャープロセスが重なり、24.4GBものメモリを消費する状態だった。
このままでは開発マシンのリソースを圧迫し、CI（継続的インテグレーション）実行時にもジョブの待機時間が増大する。ビルド速度の遅延はフィードバックサイクルを長びかせ、生産性に悪影響を及ぼしていた。その根本原因を取り除くため、重複作業の排除とツールチェーンの刷新に着手した。
上記の数値が示す通り、ビルド時間とメモリ消費の両面で大幅な改善が実現された。この結果をもたらした主要な施策は以下の3段階に分けられる。
重複ビルドの排除とTypeScriptコンパイラからの脱却
最初に取り組まれたのは、不必要なモジュール形式のビルド重複の解消だ。WooCommerceはESMとCJSの両方を配布しているが、内部のバンドラ（webpack）ではESMのみが消費されていた。にもかかわらず、開発フローでは常に両方を生成していたため、無駄なビルドコストがかかっていた。
PR #64876では、パブリッシング専用のプリパックビルドコマンドを新設し、普段の開発時にはESMのみを生成するよう分離した。これによりビルドプロセスがスリム化され、コールドビルドの短縮に寄与している。
続いて、TypeScriptのコンパイル基盤をtscからesbuildへ移行するための準備が行われた。型チェックは独立したLintステップに分離し、型定義ファイルの生成はパブリッシュ時のみ実行する方式に切り替えた。こうしてビルド本体からTypeScriptコンパイラを外し、高速なバンドラに置き換える土台が整った。
esbuildへの移行とビルド設定の一元化
型チェックとビルドの分離が完了したあと、全パッケージのビルドをesbuildへ切り替えた。esbuildはGo言語で実装されており、TypeScriptのトランスパイルにおいてtscやBabelよりもはるかに高速だ。この移行だけでウォームビルドの速度は顕著に向上した。
しかし、急いで移行した結果、各パッケージに似たようなbuild.mjsファイルが散在するという新たな課題が生まれた。これに対処するため、PR #65422ではビルド用の内部パッケージ@woocommerce/internal-buildを新設し、従来の設定パッケージ（internal-ts-configやinternal-style-build）を統合した。開発マシン上のスクリプトが整理され、今後の保守性も高まった。
Admin/Blocksによるパッケージビルド統合、メモリ大幅削減の鍵
一連の改善の集大成となったのが、PR #65254で実施されたAdminおよびBlocks向けのビルド統合だ。それまでwatch:buildコマンドが128プロセスも必要だった最大の要因は、Admin用webpackとBlocks用webpackがトランスパイル済みESMを外部パッケージとして消費していたことにある。
このPRでは、各パッケージのソースを直接AdminおよびBlocksのwebpackビルドに含める方式へと変更した。その結果、128プロセスが大幅に削減され、メモリ使用量が24.4GBから3.9GBへと激減した。ウォッチ準備時間も132秒から33秒へと4分の1に短縮されている。
トレードオフとして、パッケージのトランスパイルがesbuildではなくBabelで行われるため、コールドビルドの速度が一部でわずかに後退した（38秒）。しかし、webpackのファイルシステムキャッシュによって日常的な開発では体感されず、E2E（End-to-End）テストのCIジョブが約1分長くなる程度にとどまった。全体のメモリ削減と開発体験の向上に比べれば、十分に許容できる交換だったと言える。
次のターゲットはCIスループットの改善
ビルドプロセス自体の最適化が完了した現在、開発チームはCIのスループット向上に注力する方針だ。WooCommerceのCIはジョブをマトリクスシャーディングで分散実行しているが、GitHub Actionsのワーカーが枯渇しやすく、各ジョブの実行時間が短くなってもワーカー獲得に20分以上待たされる局面がある。
この問題を解消するため、同一ワーカー上で複数のタスクを並列実行する方式への移行が計画されている。ワーカー台数に依存しない設計に切り替えることで、CI全体のスループットを大幅に引き上げる狙いだ。さらに、E2Eテストスイートの高速化として、マルチサイト構成などを活用し、単一環境内でテストスイートを並列実行する手法も検討されている。
これらの施策が実装されれば、コードをプッシュしてからCIが完了するまでの時間がさらに短縮され、開発のスピードは一段と加速するだろう。
この記事のポイント
- WooCommerceモノレポの開発ビルドが全面的に見直され、コールドビルド60%減、メモリ使用量84%減を達成
- 重複ビルドの排除と
esbuild移行により、トランスパイル速度が大幅に向上 - Admin/Blocksへのパッケージ統合で128プロセスを一掃し、メモリ消費を劇的に低減
- 今後のCIスループット改善では、ワーカー枯渇問題の解決と並列化が焦点
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験