設計者視点で見る WordPress との現実的な付き合い方

はじめに

弊社で構築するウェブサイトの中には、WordPress をベースにしているものが多くあります。WordPress は長い歴史を持ち、国内外の多くの企業や個人サイトで採用されている代表的な CMS であり、誰でも使いやすい管理画面や豊富なプラグイン、テーマによる柔軟なデザイン変更など、非常に利用しやすいシステムです。

初期構築のしやすさや拡張性の高さという点では、今でも十分に有力な選択肢です。一方で、日々開発や運用に携わる立場から見ると、設計者や現代的なアプリケーション開発者にとって理想的なプラットフォームとは言えない側面も抱えています。

本記事では、改めて WordPress の便利さと不便さを整理します。

WordPress のメリット

WordPress が広く使われている理由のひとつは、最初から整った管理画面が備わっている点です。初期設定を済ませて導入さえ行えば、記事や固定ページの編集、メニューやウィジェットの設定などをブラウザ上で完結できます。これにより、非エンジニアであっても、ある程度の学習を経れば自力で更新作業を行えるようになります。

また、有名なテーマやプラグインを導入すれば、複雑な開発を行わなくても短期間でサイトの形を整えられます。これらの市場は活発で、選択肢や導入手順の資料も豊富であり、多くが高い完成度を持っています。結果として、初期構築のスピードを大きく高め、初期コストを抑えるうえで非常に効果的です。小規模なコーポレートサイトやキャンペーンページなど短期運用前提のサイト、あるいは WordPress 本来の用途であるブログ型のサイトでは特に強みを発揮します。

設計者として感じる WordPress のデメリット

WordPress は互換性を重視しており、根幹設計は大きく変わっていません。これは 2003 年の設計を基盤としており、現代のアプリケーション開発やインフラ設計が一般化する前の思想です。そのため、システム全体を俯瞰して制御したい設計者の立場からは扱いづらい部分があります。なお、根幹設計が大きく変わっていない一方で、REST API やブロックエディタ（Gutenberg）など周辺要素は進化している、という点は補足しておきます。

暗黙的な 301 リダイレクト

WordPress は、サイトの基準となる URL 設定（WP_HOME／WP_SITEURL を含む）と redirect_canonical の挙動により、想定と異なるドメインやパスでアクセスされた場合に 301 リダイレクトを返します。移行前の検証環境をコピーして作る、あるいは同一サイトの一部を別ドメインから確認するといった用途では、この挙動が障害になります。 また、恒久的リダイレクトである 301 はブラウザや CDN にキャッシュされやすく、一般利用者側にキャッシュされてしまった場合のリカバリに非常に苦労します。

検証用途では、redirect_canonical を無効化する、WP_HOME と WP_SITEURL を環境変数で適切に固定するなどで回避できる場合があります。ただし管理画面系（/wp-admin/）は WP_SITEURL の影響を強く受けるため、別途留意が必要です。あわせて 301 リダイレクトの危険性については、こちらの記事も参照してください。

リダイレクトに301を安易に使うべきではない理由

プログラムとデータの密結合

WordPress はテーマやプラグインの PHP ファイルを直接編集できる一方で、設定や投稿情報の多くはデータベースに格納されます。自動更新を行うと、内部の PHP プログラムと同時に内部データベースの状態も変化します。現代的な開発では Git でアプリケーション全体をバージョン管理し、CI/CD で再現性のあるデプロイを行うのが一般的ですが、WordPress の構造上、コードとデータの分離が難しく、厳密な再現性を保つ運用には工夫が必要です。

環境間で管理画面からデータ投入を行っても、スラッグの重複による自動採番、パーマリンクやカスタム投稿タイプの rewrite 設定差、階層やタクソノミの違いなどがあると、URL が一致しないことがあります。これらの事情から、WordPress は「特定の状態を複数環境で厳密に再現する」という思想と相性が悪い側面を持ちます。

この回避策も無いことは無いですが、フレームワークが標準で提供しているものではなく、それ専用の仕組みを自前で作成する必要があるため、コード単独で全状態を表現できるフレームワークほど容易ではありません。

プラグインの運用リスク

プラグインは短期的には効率的ですが、長期運用では保守の難所になり得ます。開発者に更新義務はなく、外部開発者への依存が前提となるため、更新停止や仕様変更がサイト全体のアップデート計画に影響します。WordPress 本体を更新したいのに、依存プラグイン側の更新が止まって対応できない状況は珍しくありません。

このため、採用段階からプラグインの有名性、ベンダーの信頼性などを評価し、バージョンのピン止めや適切なテスト体制を整えることが重要です。

実務上の折り合い

弊社ではこうしたメリットとデメリットを踏まえてWordPress を採用しています。 特に、管理機能や問い合わせフォームを再開発せずに活用できる点、導入を高速化できる点を評価しています。プラグインは必要最小限に留め、導入時のみ利用して不要になったものは無効化します。独自要件は独自プラグインに切り出し、影響範囲を明確にします。

ドメインの扱いについては、nginx でバックエンドへ流す前に Host を適切に中継し、必要に応じて sub_filter で出力ドメインを変換するなど、WordPress 本体には手を入れず整合を取る方法を組み合わせます。sub_filter は便利ですが、バイナリ応答や範囲要求との相性、Content-Length が外れる可能性、部分一致置換の限界があるため、sub_filter_types の限定や対象パスの明確化など運用上の注意を払います。 この点は以下の記事も参考にしてください。

nginx で sub_filter_types “*” を使う前に知っておくべき仕様

現代的な開発手法をWordPress全体に完全適用することは難しいため、適用範囲を見極め、管理可能な範囲を管理するという割り切りで運用します。 具体例としてはプラグインに切り出す部分です。 こうすることで、プラグイン全体のソースコード管理が可能になります。

まとめ

WordPress は今でも優れた CMS であり、適切な用途で使えば十分に力を発揮します。ただし、ノーカスタマイズのまま環境再現性、Infrastructure as Code、CI/CD、自動テストといった考え方をそのまま適用しようとすると、構造的な壁に突き当たります。結局のところ、どのようなサイトを作り、どのような体制で運用するかによって評価は変わります。システム開発的なアプローチを強く求める場合や、継続的アップデートや自動テストを組み込みたい場合には、別のフレームワークや Headless CMS の検討が現実的です。

WordPress は、便利でありながら設計思想の重心が互換性に置かれているフレームワークです。その特性を理解し、用途や要件に応じて適切な距離感で使いこなすことが、今の時代における WordPress との現実的な付き合い方だと考えます。