WordPressサイト制作の課題と解決策まーちゅう

前回の記事では、WordPressのブロックエディター（Gutenberg）がいかに従来の「HTMLのWordPress化」ワークフローを変革しようとしているかをお伝えしました。今回は、具体的な課題とその解決策を、現場の声とともに見ていきましょう。

Web制作の現場で毎日のように直面する課題がありますが、実はそれらの多くが「HTMLのWordPress化」という二段階のワークフローに起因していることに気づきましたか？それでは具体的に見ていきましょう。

課題① 和文行間調整の二重管理

制作会社の廊下で、佐々木さんと田中さんの会話が聞こえてきました。

「あのサイト、HTMLで見たときと、WordPressに入れた後で行間が全然違うんだよね」

「そうなんだよ。クライアントから『HTMLのときの見た目と違う』って言われて…」

この会話、あなたも一度は耳にしたことがあるのではないでしょうか？

「HTMLのWordPress化」ワークフローでの悩み

デザインカンプから静的HTMLを作る段階と、WordPressテーマに変換する段階で微妙な差異が生じがちです。特に和文タイポグラフィは繊細な調整が必要なため、CSS二重管理が発生し、一貫性維持が困難でした。

ある制作会社の事例を見てみましょう。デザイナーが「本文は行間1.8、見出しは行間1.5」と指定したデザインカンプを作成。HTMLコーダーは忠実にCSSを記述しました。

p { line-height: 1.8;}h2 { line-height: 1.5;}

しかし、WordPress化の段階で、テーマの基本CSSと競合し、思わぬ表示崩れが発生。

.entry-content p { line-height: 1.8 ; }.entry-content h2 { line-height: 1.5 ;  }

「HTMLでは完璧だったのに、WordPressにしたら行間が広がった」というクレームがクライアントから届き、急遽修正対応する羽目に。結局、WordPress用のCSSとHTML用のCSSを別々に管理することになり、後の修正時には二重の手間がかかってしまいました。

「最初からWordPress」での解決策

直接ブロックテーマを作成する場合はどうでしょう？theme.jsonという「デザイン設計書」で一括管理できるため、デザイン差分が削減されます。

田中さんが試した新しい方法は、プロジェクト開始時にtheme.jsonを設定するというもの。

まず、デザイナーから受け取った「本文は行間1.8、見出し行間1.5」という指示を、次のように一度設定します

{ "version": 2, "styles": { "typography": { "lineHeight": "1.8" }, "elements": { "heading": { "typography": { "lineHeight": "1.5"        }      }    }  }}

これだけで、サイト全体で一貫した行間が適用されます。クライアントから「やっぱり行間をもう少し広げたい」という要望があっても、theme.jsonの値を一カ所変更するだけで全体に反映。「HTMLとWordPressで見え方が違う」という問題も解消されます。

この方法は、料理で言えば「同じレシピで料理を作る」ようなもの。異なるシェフ（開発者）が調理しても、同じ味（デザイン）が再現できるのです。

課題② サーバー環境差異への対応

プロジェクト納品直前の夜。「ローカルではちゃんと動くのに、本番サーバーで表示が崩れる…」と徹夜で対応したことはありませんか？

「HTMLのWordPress化」ワークフローでの悩み

エックスサーバーやさくらインターネットなど主要レンタルサーバーとローカル開発環境の差異は、従来のフローでは大きな問題でした。ローカルで完璧に動くHTMLサイトを作っても、WordPress化してサーバーにアップした際に予期せぬ問題が発生することがよくありました。

山本さんのチームでは、ローカル環境（MAMP Pro）で完璧に動作していたサイトをエックスサーバーにアップロードしたところ、PHPバージョンの違いでカスタム関数が動作せず、トップページが真っ白になる事態に。納品直前のトラブルに開発者は徹夜での修正を余儀なくされました。

function get_custom_field($key) { return match($key) { 'title' => get_field('custom_title'), 'description' => get_field('custom_desc'), default => ''  };}

「ローカルではちゃんと動いていたのに…」というフレーズが社内に響き渡りました。

「最初からWordPress」での解決策

PHP最小構成のブロックテーマなら、どうでしょう？モダンなブロックテーマは依存関係が少なく、サーバー環境の差異に強いため、環境間の挙動の違いによるトラブルが減少します。

ブロックテーマを採用した別のプロジェクトでは、同じくエックスサーバーへのデプロイ時も問題なく動作。PHP関数への依存が少なく、ほとんどがHTMLとCSSで構成されているため、サーバー環境の違いによる影響を受けにくかったのです。

{ "version": 2, "settings": { "custom": { "siteName": "サンプルサイト", "siteDescription": "WordPress ブロックテーマ"    }  }}

まるで「どんなキッチンでも同じように調理できるシンプルなレシピ」のようなもの。特殊な調理器具（PHPの特定バージョン）に依存せず、基本的な道具（標準的なブラウザ機能）だけで美味しい料理（ウェブサイト）が作れるのです。

佐藤さんは言います。「サーバーによる動作差異を心配せずに済むのは精神的にも助かるね。納品前の徹夜が減って、休日にゆっくり過ごせるようになったよ」

課題③ 役割分担と教育コスト

「このサイト、どうやって更新するんですか？」というクライアントからの質問に、マニュアルを急遽作成した経験はありませんか？

「HTMLのWordPress化」ワークフローでの悩み

従来のフローでは、WordPress化の段階でAdvanced Custom Fields（ACF）などのカスタムフィールドを後付けする必要がありましたが、これには専門知識が必要で、属人化しやすい問題がありました。また、クライアントへの操作説明も複雑になりがちでした。

ある不動産会社のサイト制作では、物件情報をカスタムフィールド（ACF）で管理することになりました。

1. デザイン・コーディングが完了

2. WordPress担当者がACFの設定を実施

3. 「地図表示」や「物件詳細」の入力フィールドを作成

4. クライアントから「更新方法がわからない」という問い合わせが殺到

5. 制作会社は急遽30ページのマニュアルを作成

6. 1時間の電話レクチャーを実施

7. 想定外の工数が発生

担当者は「もっと直感的な編集画面にできなかったか」と後悔しました。まるでスマートフォンを初めて使う人に「設定アプリから開発者オプションを有効にして…」と説明するようなものでした。

「最初からWordPress」での解決策

ブロックエディターを中心としたフローでは、パターン共有によって教育コストを削減できます。ブロックは視覚的に編集できるため、技術背景が異なるチームメンバーでも共通言語として機能し、協業が容易になります。

同様の不動産サイトをブロックエディターで構築したケースでは

1. 「物件情報ブロック」をパターン化

2. クライアントへの説明は「このブロックを選んで、各項目を直接編集するだけです」

3. クライアントも「Word感覚で編集できる」と好評

4. デザイナーとコーダーも同じブロックパターンを見ながら作業可能

5. 「専門知識がなくても協力して作業できる」と好評

これは、「マニュアル不要の家電」のようなもの。複雑な設定手順を覚えなくても、誰でも直感的に使いこなせるインターフェースが提供されているのです。

課題④ 修正ラッシュと納期遅延

納期直前のクライアントからの「やっぱりこの部分を変更したい」というリクエストに、胃が痛くなった経験はありませんか？

「HTMLのWordPress化」ワークフローでの悩み

最も大きな違いは修正フェーズです。従来はHTMLとPHPの両方を修正する必要がありましたが、ブロックテーマならブロック単位で即時プレビューが可能になるため、工数を大幅に削減できるケースも少なくありません。

あるコーポレートサイトのリニューアルでは、納品直前にクライアントから「トップページのセクションの順序を入れ替えたい」という要望が。HTML版では全体の構造を変更する必要があり、それをWordPressテンプレートにも反映する必要があったため、想定外に2日の工数がかかってしまいました。

<!-- HTML修正前 --><section class="about">...</section><section class="service">...</section> <!-- HTML修正後 --><section class="service">...</section><section class="about">...</section>

get_template_part('template-parts/section', 'about');get_template_part('template-parts/section', 'service'); get_template_part('template-parts/section', 'service');get_template_part('template-parts/section', 'about');

修正担当者は「こんな単純な変更なのに、なぜこんなに時間がかかるんだろう」とストレスを感じていました。

「最初からWordPress」での解決策

ブロックテーマでは、サイトエディターでグローバルスタイルを調整するか、ブロック設定で直接変更するだけで済みます。さらに、変更はリアルタイムでプレビューできるため、クライアントとの認識合わせもスムーズになります。

ブロックエディターで構築した別のプロジェクトでは

1. 「セクションをドラッグして順序を入れ替えるだけ」という簡単な対応で完了

2. クライアントが目の前でリアルタイムに変更を確認

3. 「こういうイメージでした！」とその場で承認を獲得

4. クライアント自身も「自分たちでも簡単に更新できそう」と前向きな反応

担当者は「修正作業がストレスではなく、クリエイティブな提案の機会になった」と前向きに感じています。まるで「模型を動かして街づくりをシミュレーションする」ような感覚で、クライアントとクリエイティブな対話ができるようになったのです。

「最初からWordPress」のワークフロー実践方法

「HTMLのWordPress化」から「最初からWordPress」への移行は、手作業でパーツを組み立てる工場生産から、3Dプリンターで一気に造形する製造へと進化するようなものです。具体的に実践するための方法を見ていきましょう。

ステップ1：デザインカンプ→パターン設計

従来の方法
「このデザインをHTMLに起こしてください」と言われたら、全体をコーディングしていくことが一般的でした。

新しい方法
デザインカンプをいきなりHTMLに落とし込むのではなく、「このデザインはどんなブロックの組み合わせで表現できるか？」とブロックパターンに分解して考えます。

Figmaでコンポーネント名をつける段階から、そのままWordPressのパターン名として使用できるよう考慮することで、命名の齟齬を防ぎます。

例えば、「hero-main-visual」や「service-summary-cards」といった命名規則を統一し、デザイン側とコード側で同じ言語を使うことで、コミュニケーションロスを減らせます。

クライアントとのやりとり例
「トップページのこの大きな画像部分は『ヒーローブロック』、その下の3つの特徴紹介は『特徴カードブロック』と呼んでいます。もし更新したい部分があれば、『特徴カードブロックの画像を変えたい』というように伝えていただけると、すぐに対応できますよ。」

社内の役割分担
デザイナーは「hero-block」「feature-cards」といったコンポーネント名でデザインを整理し、コーダーはそれをブロックパターンとして実装。制作チーム全体で同じ用語を使うことで、コミュニケーションがスムーズになります。

これは「共通の設計図を見ながら家を建てる」ようなもの。大工さん（コーダー）も、インテリアデザイナー（デザイナー）も、施主（クライアント）も同じ言葉で会話できるため、認識のズレが少なくなります。

ステップ2：ブロックテーマ雛形生成

従来の方法
「_s（アンダースコア）」などのスターターテーマをダウンロードし、必要なテンプレートファイルを作成していました。

新しい方法
最新のWordPress環境では、複数の方法でブロックテーマの雛形を生成できます。

方法A：コマンドライン（上級者向け）

npx @wordpress/create-block-theme my-custom-theme

方法B：WordPress管理画面（初心者向け）

1. 管理画面から「プラグイン」→「新規追加」を選択

2. 検索欄に「Create Block Theme」と入力して検索

3. 「Create Block Theme」プラグインの「今すぐインストール」をクリック

4. 「有効化」ボタンをクリック

5. 「外観」→「テーマエディター」メニューの中に新しく現れた「Create Block Theme」を選択

6. 「Export Current Theme」または「Create New Theme」を選択

7. 必要な情報（テーマ名、説明、作者名など）を入力

8. 「Generate Theme」ボタンをクリック

これで、WordPressの管理画面から直接ブロックテーマを作成できます。プログラミングの知識がなくても、クリック操作だけでtheme.jsonが自動生成されるのです。

クライアントとのやりとり例
「御社のブランドカラーとフォントをシステムに登録しておきました。今後サイトを拡張する際も、同じ見た目を保ったまま簡単に増やせますよ。」

社内の役割分担
ブランド設定担当者がtheme.jsonの初期設定を行い、各ページ担当者はその設定を活用してコンテンツを作成。「ブランドの青色はどの色コードだっけ？」といった確認の手間が省け、作業効率が向上します。

これは「家の基礎工事や骨組みを一気に作る」ようなもの。最初にしっかりした土台を作っておけば、後の工程がスムーズに進みます。

ステップ3：ローカル開発環境構築

従来の方法
XAMPP、MAMPなどを使ってローカル環境を一から構築していました。

新しい方法
WordPressのローカル開発には、以下のような簡単なツールがおすすめです。

推奨ツール

1. Local by Flywheel（最も人気）

   • 無料でグラフィカルなインターフェース

   • SSL対応、メール確認機能内蔵

2. Docker Desktop + wp-env（上級者向け）

Localを使った環境構築手順

1. Local公式サイトからダウンロード＆インストール

2. 「Create a new site」ボタンをクリック

3. サイト名を入力（例：client-project-2024）

4. 環境設定を選択（推奨：Preferred、Nginx、PHP 8.1、MySQL 8.0）

5. WordPressのユーザー名・パスワードを設定

6. 「Add Site」ボタンをクリック

これだけで、数分以内にWordPress環境が立ち上がります。日本語環境での動作も安定しており、初心者にも扱いやすいのが特徴です。

クライアントとのやりとり例
「開発中のサイトを社内でご確認いただく環境を用意しました。実際のサーバーと同じ速度で動作しますので、完成イメージが掴みやすいと思います。」

社内の役割分担
環境構築担当者がテンプレート化したローカル環境を準備し、制作メンバーは簡単な操作で同一環境を複製して作業開始。「自分のPCでは動くけど、他のメンバーのPCでは動かない」といった問題を防げます。

これは「全員が同じ工具セットを使って作業する」ようなもの。同じ環境で作業することで、チーム全体の効率が上がり、思わぬトラブルを防ぐことができます。

「最初からWordPress」を定着させるコツ

「HTMLのWordPress化」から「最初からWordPress」への移行は、一朝一夕には完了しません。チーム全体の意識改革と継続的な学習が必要です。以下のポイントを押さえることで、新しいワークフローを定着させましょう。

1. 小さく始める

いきなり大規模プロジェクトで「最初からWordPress」を導入するのはリスクが高いかもしれません。まずは社内のブログやランディングページなど小規模なプロジェクトから始め、徐々にノウハウを蓄積していきましょう。

佐藤さんは言います。「最初は自社サイトのニュースページをブロックエディターで作り変えることから始めました。失敗しても影響が限定的なので、安心して実験できました。」

2. チーム全体での導入準備

ブロックエディターやテーマ開発の知識は、一人だけが持っていても効果は限定的です。導入初期は、まず基本的な操作を全員が習得できる環境を整えましょう。

「最初の1ヶ月は週1回のミニ勉強会を開催し、基本操作を全員で確認しました。また、よく使うブロックパターンを社内共有フォルダに保存することで、誰でも同じクオリティで作業できる体制を作りました。」と山田さんは語ります。

導入初期のポイント

• 基本操作の全員習得を最優先

• よく使うパターンの共有とライブラリ化

• 疑問点を気軽に聞ける雰囲気作り

3. クライアントへのワークフロー変更説明

クライアントの中には「HTMLのWordPress化」という従来の工程を前提としている方も多いでしょう。ワークフロー変更のメリットを伝えるための準備をしておくことで、理解を促進できます。

「最初は『従来の方法と何が違うんですか？』と戸惑われましたが、実際にブロックエディターでリアルタイムに変更できる様子を見せると、むしろ『これは便利ですね！』と喜んでいただけました。特に『修正が即座に反映される』という点は、クライアント側にとって大きなメリットなんです。」と佐々木さんは話します。

説明のポイント

• 修正サイクルの短縮による納期メリット

• リアルタイムプレビューでの安心感

• 将来的な更新作業の効率化

4. 継続的な学習を習慣に

WordPressのブロックエディターは急速に進化しています。公式ブログやコミュニティの情報をチェックし、最新の機能や手法を学び続けることが重要です。

「毎月最低1つは新しいブロックや機能を試すことを目標にしています。小さな実験の積み重ねが、大きな効率化につながるんです。」と田中さんは語ります。

5. エラーハンドリングと品質管理

新しいワークフローでも、問題は発生します。重要なのは、問題を早期に発見し、迅速に対応できる体制を整えることです。

• ローカル環境とステージング環境での十分なテスト

• クロスブラウザ検証の自動化

• パフォーマンス監視の導入

• バックアップとロールバック手順の整備

これらの準備により、「新しい方法だから問題が起きやすい」という不安を解消できます。

次の記事では、100% GPL準拠の日本語有料テーマの活用法と日本語サイト特有の最適化ポイントについて詳しく見ていきます。特に、これまで解説してきた「最初からWordPress」のアプローチを加速させる国産テーマの選び方と実践的な活用方法をお伝えします。