WordPress・CMS設計についてよくある質問

カスタムフィールドを増やせば入力画面は整います。カスタム投稿タイプを分ければ管理画面も見やすくなります。ヘッドレス化すればフロントエンドの自由度も上がります。ただし、それぞれの施策には必ず別の負担が発生します。検索、プレビュー、SEO、権限管理、データ移行、保守。WordPressを単なる更新画面ではなく、プロダクトのデータ基盤として扱うなら、見た目より先にこの負担の行き先を設計しなければなりません。

WordPressは現在も全ウェブサイトの約40〜42.7％で利用され、CMS導入サイトに限れば約62.5％を占めるとされる巨大な基盤です。だからこそ、導入自体は簡単でも、設計の差が運用コストやコンバージョンに表れやすい。個人開発では、後から人員を増やして解決することが難しいぶん、初期の仮説と検証がそのまま成否を分けます。

カスタムフィールドは増やすほど便利になるのか

WordPressでサイトを作り始めると、まず検討するのがカスタムフィールドです。

記事タイトル、本文、アイキャッチ画像だけで足りない情報を、商品価格、対象地域、開催日、著者プロフィール、資料ダウンロードURLなどに分解できる。入力欄を整理すれば、編集者は自由記述に頼らず、一定のフォーマットで情報を登録できます。

この設計は、運用初期にはかなり強力です。コンテンツの揺れを抑えられますし、テンプレート側でも値を取り出しやすい。Advanced Custom Fields、いわゆるACFを使えば、従来のカスタムフィールドだけでなく、カスタム投稿タイプやカスタムタクソノミーの登録・管理までプラグイン単体で対応できます。2023年のアップデート以降、この領域の実装は以前より一段扱いやすくなりました。

ただ、便利だからといって入力欄を増やし続けると、CMSは徐々に複雑になります。

カスタムフィールドが増えたときに起きること

カスタムフィールドの問題は、項目数が多いことそのものではありません。データの意味が曖昧なまま増えることです。

たとえば、次のような項目があるとします。

• 商品の短い説明
• 商品の概要
• 商品の特徴
• 商品紹介文
• 商品のリード文
• 商品カード用テキスト

編集者から見ると、どれも似た入力欄に見えます。実装者は用途ごとに分けたつもりでも、運用側が使い分けられなければ、入力品質は安定しません。結局、同じ文章を複数項目に貼り付けたり、空欄のまま公開したりする。CMSの構造が整っているように見えて、ユーザーの痛みは減っていない状態です。

カスタムフィールドを追加する前に、私は次の順番で仮説を置くようにしています。

1. その情報は、通常の本文やタイトルでは管理できないのかを確認する

2. その情報を複数の画面や機能で再利用するのかを決める

3. 空欄が許されるのか、公開条件になるのかを定義する

4. 編集者が迷わず入力できる名称と説明を用意する

5. 将来、項目の統合や移行が必要になった場合の扱いを考える

ここで「とりあえず欄を作る」を選ぶと、後から削除するコストが高くなります。データがすでに登録されているからです。テンプレート、検索、CSV入出力、APIレスポンス、移行スクリプト。ひとつのフィールドを消すだけでも、複数の場所に影響します。

カスタムフィールドは入力欄ではなく、将来も残るデータ契約です。追加ボタンを押す前に、誰が、どこで、何のために使うのかを決めます。

フィールドの増加とパフォーマンス

WordPressのカスタムフィールドは、投稿メタとしてデータベースに保存されます。標準関数では get_post_meta()、update_post_meta()、add_post_meta() などを使って値を取得・更新します。ACFでは the_field() や get_field() がよく使われます。

ここで注意したいのは、カスタムフィールドを使った瞬間に遅くなるわけではないということです。問題になりやすいのは、一覧画面や検索結果で大量のメタ情報を何度も取得する設計です。

たとえば、商品一覧に次の情報を表示するとします。

• 価格
• エリア
• 広さ
• 最寄り駅
• 取扱状況
• ランキング用の数値
• 表示優先度

投稿を数件表示するだけなら、大きな問題にならないこともあります。しかし、複数の条件で絞り込み、並び替え、ページネーション、関連コンテンツ表示まで加えると、クエリの組み立てが複雑になります。メタクエリを重ねた結果、管理画面では普通に表示できるのに、検索画面だけ極端に遅いという状態も起きます。

設計段階では、各項目を次のように分類すると判断しやすくなります。

特に、分類情報をカスタムフィールドに保存する設計は慎重に考えたいところです。都道府県や商品カテゴリのように、複数の投稿で共通して使う値なら、タクソノミーのほうが運用しやすい場合があります。

一方で、タクソノミーに分ければ必ず正解というわけでもありません。入力画面が複雑になり、編集者が登録場所を間違えることもある。技術的な正しさだけではなく、公開までの導線全体で検証する必要があります。

ACFを使う場合の境界線

ACFはCMS設計を速く進めるための強い選択肢です。個人開発では、管理画面とテンプレートを短期間でつなげられる価値が大きい。問題は、ACFを使うことではなく、ACFにすべてを寄せることです。

次のような構造になると、後で見直しが必要になります。

• ひとつの投稿に大量の繰り返しフィールドを持たせる
• 同じ意味のフィールドを投稿タイプごとに複製する
• フィールド名だけで用途を判断できない
• テンプレート側に表示条件が集中している
• 空欄時の代替表示が各テンプレートに分散している
• フィールドの値を直接HTMLとして出力している

リピーターフィールドは、複数の要素を入力できるため便利です。しかし、ひとつの投稿に何十行もの情報を持たせると、編集画面もデータ取得も重くなります。繰り返し要素が独立したコンテンツとして検索されるなら、別のカスタム投稿タイプに分けるほうが適切かもしれません。

判断の軸は単純です。そのデータが「投稿の一部」なのか、「投稿とは別の管理対象」なのか。

この境界を曖昧にしたまま実装すると、最初は速く作れても、運用が始まってから構造の歪みが出ます。開発速度と保守性のトレードオフです。

Gutenbergでは入力自由度を残しすぎない

ブロックエディタ、いわゆるGutenbergは、WordPressの標準編集体験として定着しました。文章、画像、見出し、リスト、埋め込みなどをブロック単位で組み立てられるため、編集者がHTMLを直接書かなくてもページを作れます。

一方で、自由度が高いほど、公開されるページの品質は揺れます。

同じサイトなのに、ページごとに見出しの階層が違う。画像の比率が揃わない。ボタンの文言やリンク先の指定方法が担当者によって異なる。コンバージョンを追っているサイトでは、この揺れが単なる見た目の問題で終わらないことがあります。

標準ブロックとカスタムブロックの使い分け

Gutenbergの設計では、すべてをカスタムブロックにする必要はありません。むしろ、標準ブロックで十分な領域まで独自ブロックに置き換えると、編集体験と保守コストが悪化します。

標準ブロックを活かしやすいのは、次のようなコンテンツです。

• 通常の長文記事
• 見出しと段落が中心の読み物
• 編集者が柔軟に構成を変える必要があるページ
• 画像や引用を記事の流れに沿って配置するコンテンツ

逆に、次のような要素はカスタムブロックの候補になります。

• 商品カード
• 問い合わせへの誘導
• 料金プランの比較
• 導入事例の概要
• 関連記事の自動表示
• 複数ページで再利用する申込みパネル

カスタムブロックの価値は、見た目を豪華にすることではありません。ユーザーが取るべき行動を、ページごとの実装差分から守ることです。

たとえば、問い合わせボタンを通常のボタンブロックで作ると、文言やリンク先を自由に変更できます。その自由が必要な場合もありますが、事業上の重要な導線であれば、リンク先の選択肢を限定し、計測用の属性を自動で付与する設計も考えられます。

ここでは「編集者の自由」と「プロダクトの一貫性」が衝突します。どちらかを全面的に優先するのではなく、ユーザーの痛みに近い部分から制御します。

カスタムフィールドの入力欄が見えない問題

Gutenberg環境では、カスタムフィールドの入力欄が初期状態で表示されていない、または無効になっている場合があります。入力欄を用意したのに、編集者からは存在しないように見える。これは実装ミスというより、編集画面の表示設定に関する問題です。

管理画面の表示オプションやパネル設定から、必要な項目を有効化しなければならないことがあります。ただし、運用担当者に毎回設定を依頼する構成は避けたい。初期設定、権限、ユーザーごとの表示状態を含めて、公開までの導線を確認します。

実際の運用では、次のような確認が必要です。

• 管理者以外のユーザーでも入力欄が表示されるか
• 新規投稿と既存投稿で表示状態が変わらないか
• 必須項目が未入力でも下書き保存できるか
• プレビュー時に未入力の値がどう扱われるか
• 入力欄の説明文だけで編集者が判断できるか
• ブロック側の設定とカスタムフィールドの役割が重複していないか

入力欄を増やすと、管理画面は一見親切になります。しかし、情報の所在が分散すると、編集者はどこを直せばページに反映されるのか分からなくなります。

その状態では、入力ミスを責めても意味がありません。CMSの情報設計がユーザーの行動を支えられていないからです。

入力ミスの多くは、担当者の注意不足ではなく、管理画面が持つ情報設計の問題です。

編集者の操作を観測する

CMSは開発者が使いやすいかではなく、更新する人が迷わないかで評価します。

仮説を立てるときは、機能単位ではなく、公開までの行動単位で考えます。たとえば「導入事例を追加する」という作業なら、タイトル入力、企業情報登録、画像選択、本文編集、関連サービス設定、プレビュー、公開までをひとつの流れとして見る。

途中で別画面に移動する必要があるなら、その理由を確認します。仕様上必要なのか、データ構造が分離しすぎているのか。編集者が同じ内容を複数箇所に入力しているなら、フィールドの統合や自動参照を検討する価値があります。

画面を見ただけでは分からない問題もあります。厳しいフィードバックほど重要です。

• どの欄に何を書けばよいか分からない
• 保存したのに公開ページで変わらない
• プレビューと本番表示が違う
• 画像を差し替える場所が見つからない
• 関連記事の設定が毎回面倒
• 以前の入力内容を再利用できない

この反応を、単なる操作質問として処理しないこと。プロダクトの離脱率や更新頻度に影響する兆候として扱います。

ヘッドレスCMS化で失うものを先に洗い出す

WordPressをヘッドレスCMSとして使う構成は、フロントエンドの自由度を高められます。WordPressを管理画面とデータ管理に集中させ、REST APIやGraphQLを通じて、React、Next.js、Astro、Vue.jsなどのフロントエンドからコンテンツを取得する方式です。

表示部分をWordPressのテーマから切り離せるため、画面の設計や配信方法を柔軟に選べます。静的サイトジェネレーターと組み合わせたJAMstack構成も取りやすく、表示速度やデプロイフローを独立して改善できます。

ただし、ヘッドレス化はWordPressテーマを捨てて終わる話ではありません。テーマが暗黙に担っていた機能を、自分たちで再設計する必要があります。

プレビューは最初に設計する

ヘッドレス構成で最も後回しにされやすいのが、プレビューです。

従来型のWordPressでは、投稿を下書き保存してプレビューボタンを押せば、テーマを通じて公開前のページを確認できます。ヘッドレス化すると、管理画面と表示側が別アプリケーションになるため、下書きデータをどのように取得し、誰にだけ見せるかを決めなければなりません。

必要になるのは、たとえば次のような仕組みです。

• 下書きや予約投稿のデータを取得する認証処理
• 編集者専用のプレビューURL
• プレビュー用データと公開データの切り分け
• セッションやトークンの有効期限管理
• プレビュー画面から管理画面へ戻る導線
• 本番環境とステージング環境の表示差分の制御

プレビューが使いにくいと、編集者は公開してから確認するようになります。誤りを見つけるたびに公開と修正を繰り返す。公開通知が購読者や検索エンジンに届くサイトなら、コンテンツ品質だけでなく信頼性にも影響します。

ヘッドレス化の技術的なメリットを説明する前に、編集者が従来と同じ速度で確認できるかを検証する。ここを飛ばすと、開発者にとって美しい構成が、運用者にとって不便なCMSになります。

SEO機能は自動で引き継がれない

ヘッドレス化すればSEOが改善する、という主張は危険です。表示速度やフロントエンドの自由度が改善する可能性はありますが、SEOに必要な要素が自動で移行されるわけではありません。

少なくとも、次の設計が必要になります。

• titleとdescriptionの生成
• canonicalの設定
• OGPやSNS共有用メタデータ
• XMLサイトマップ
• 構造化データ
• noindexやrobots制御
• 404ページ
• リダイレクト
• パンくずリスト
• ページネーション
• 画像の代替テキスト
• 公開日・更新日の扱い

WordPress側でSEOプラグインを導入していても、その設定値をフロントエンドが取得し、正しいHTMLとして出力できなければ意味がありません。APIレスポンスにデータがあることと、検索エンジンが適切に解釈できることは別の問題です。

レンダリング方式も関係します。サーバーサイドレンダリング、静的生成、クライアント側での取得。どの方式を採用するかによって、初期HTML、更新反映のタイミング、キャッシュ、プレビューの実装が変わります。

ここでの検証軸は、検索順位の期待ではなく、公開ページに必要な情報が正しく存在するかです。ヘッドレス化はSEO施策ではなく、コンテンツ管理と表示基盤を分離するアーキテクチャ上の選択です。

検索と問い合わせフォームは別のプロダクトになる

WordPressのテーマを使っていると、サイト内検索や問い合わせフォームは既存プラグインで動かせます。しかし、フロントエンドを分離すると、それらの機能も再設計の対象になります。

検索では、次の要素が問題になります。

• WordPress標準検索をAPI経由で利用するか
• カスタム投稿タイプを検索対象に含めるか
• カスタムフィールドの値を検索対象にするか
• 前方一致や部分一致をどう扱うか
• ページネーションと並び順をどう設計するか
• 検索結果がない場合に何を表示するか

問い合わせフォームでは、入力値の検証、スパム対策、送信結果の表示、エラー処理、通知メール、個人情報の扱いが必要になります。フロントエンドにフォームを置いたからといって、WordPressのフォームプラグインがそのまま利用できるとは限りません。

機能をひとつ移すたびに、表示だけでなく、状態管理と失敗時の体験が増える。これがヘッドレスCMSの現実です。

ヘッドレス化を選びやすいケース

ヘッドレスが向いているかどうかは、技術トレンドではなく、事業上の制約で決めます。

複数のサービスやアプリに同じコンテンツを配信したい場合、ヘッドレスの価値は高まります。反対に、記事サイトや企業サイトをひとつの管理画面で運用し、編集者が少人数なら、従来型テーマのほうが合理的な場合があります。

私がヘッドレス化の仮説を検証するときは、まず「表示速度を上げたい」ではなく、「何を分離したいのか」を言語化します。テーマの制約なのか、デプロイの制約なのか、複数チャネル展開なのか。目的が曖昧なまま構成だけ先に決めると、再実装する機能が増えるだけです。

標準関数とACF関数を安全に使う

WordPressのテンプレート実装では、値を取得して表示するだけに見える箇所ほど、事故が起きます。

カスタムフィールドの値が常に存在するとは限りません。過去の記事には未入力の項目があるかもしれない。フィールド設定を変更したかもしれない。管理者が想定外の文字列を入力することもあります。

それにもかかわらず、取得した値をそのままHTMLへ出力すると、表示崩れや意図しないマークアップにつながります。

未入力を前提にテンプレートを組む

ACFの get_field() で値を取得した場合、値が存在しないケースを必ず想定します。画像、リンク、数値、テキスト、繰り返しフィールドでは、未入力時の扱いが異なります。

たとえば、次のような判断が必要です。

• 未入力なら項目自体を表示しない
• 未入力なら既定の文言を表示する
• 未入力なら公開できないようにする
• 未入力でもレイアウト上の空間を残す
• 値が不正なら管理者に警告する

リピーターフィールドを使う場合も、行が存在するかを確認せずに処理を進めないことが重要です。ACFの have_rows() や the_row() などを使う構成では、繰り返しデータがない場合にHTMLを出力しない分岐を用意します。

「入力されているはず」という前提は、公開直後には成立しても、数か月後には崩れます。CMSの寿命は、実装者が管理画面を触らなくなった後に始まります。

エスケープは最後に足す処理ではない

取得したデータを表示する際は、出力先に合わせたエスケープが必要です。テキストとして表示するのか、属性値として埋め込むのか、URLとして扱うのか、HTMLを許可するのかで、処理は変わります。

カスタムフィールドに入力された文字列を、そのままHTMLとして出力する設計は避けます。リンクURL、画像のalt属性、クラス名、data属性なども同様です。

ただし、すべてを機械的にエスケープすればよいわけではありません。リッチテキストのように許可するHTMLを含む値では、用途に応じたサニタイズと出力処理が必要です。テンプレートに値を渡す前に、データの責任範囲を決めておくことが大切です。

実装ルールを作るなら、最低限次のような形にします。

• 表示用テキストとHTML許可データを区別する
• URLはURLとして検証してから属性に出力する
• 数値は数値として扱い、文字列のまま比較しない
• 未入力時の分岐をテンプレートに持たせる
• 管理画面で入力制約を設けても、表示側で再確認する
• APIに出す値と画面に出す値を同じ扱いにしない

APIに出力する場合は、さらに公開範囲の設計が必要になります。管理画面だけで使う内部メモや、公開してはいけない情報までREST APIやGraphQLで取得できる状態にしない。ヘッドレス化する場合、この問題はより明確になります。

フィールド名は仕様書の代わりになる

カスタムフィールドの命名は、後から効いてきます。

text_1、sub_text、description_new のような名前は、作成直後なら意味が分かります。しかし、数か月後に別の開発者がテンプレートを修正するとき、用途を推測しなければなりません。

フィールド名には、表示場所ではなくデータの意味を反映させます。商品カード用の短文なら、どの画面で使うかだけでなく、文字量や目的が分かる名前にする。命名規則を決め、既存のフィールドと新規のフィールドで表記を揃える。

管理画面のラベルと内部名を分けて考えるのも有効です。編集者には理解しやすい日本語のラベルを見せ、開発者には一貫した内部名を提供する。小さな設計ですが、運用期間が長くなるほど差が出ます。

セキュリティとDB負荷は別々に考えない

CMS設計では、セキュリティとパフォーマンスを別の担当領域として扱いがちです。しかし、実際の運用では両者が同じ設計に影響します。

たとえば、APIで多くのデータを返す設計は、フロントエンドにとって便利です。一方で、不要なフィールドや下書き情報まで返せば、情報漏えいのリスクが増えます。取得するデータを絞り込めば安全性は高まりますが、画面側で追加リクエストが増え、表示速度や実装の複雑さに影響することがあります。

権限と公開範囲を設計する

WordPressでは、ユーザー権限と投稿タイプの権限を分けて考える必要があります。

編集者がすべてのカスタム投稿を編集できる必要はないかもしれません。公開前の情報を閲覧できる人と、公開操作までできる人も同じとは限りません。ACFで入力欄を整理しても、権限設計が曖昧なら、誤操作を防げません。

確認したいのは、機能の有無ではなく、操作の境界です。

• 誰が新規投稿を作成できるのか
• 誰が既存投稿を編集できるのか
• 誰が公開と非公開を切り替えられるのか
• 誰がカスタムフィールドの定義を変更できるのか
• 誰がプレビュー用の下書きを閲覧できるのか
• API経由でどのデータを公開するのか

特に、カスタム投稿タイプやタクソノミーを追加した後は、管理画面に表示されるだけでなく、REST APIへの公開状態も確認します。内部管理用の投稿タイプが、意図せず外部から取得できる構成になっていないか。公開対象を明確にすることが先です。

DB負荷を見えないままにしない

個人開発では、初期のアクセス数が少ないため、データベースの問題を後回しにしがちです。しかし、負荷はアクセス数だけで決まりません。

• 複雑なメタクエリ
• 大量のカスタムフィールド
• 関連投稿の多重取得
• APIでの過剰なデータ返却
• キャッシュされない検索
• 管理画面一覧での追加カラム表示
• 外部サービスとの同期処理

このような処理が重なると、規模が大きくなくてもレスポンスに影響することがあります。

まず、表示速度の数値だけを追わず、どの処理に時間がかかっているのかを分けます。フロントエンドのレンダリングなのか、WordPressのクエリなのか、外部APIなのか。原因を分けないままキャッシュを追加すると、問題を隠すだけになる場合があります。

一覧ページで使うデータと詳細ページで使うデータを分けることも効果的です。カード表示に必要な情報だけを取得し、詳細情報は詳細ページで取得する。APIレスポンスを用途ごとに設計し、毎回すべてのフィールドを返さない。

将来的に検索や集計が中心になるなら、WordPressの投稿メタだけで対応し続けることが適切かを早めに判断します。専用テーブルや外部検索サービスが候補になる場合もありますが、構成を増やすほど運用負担も増えます。ここでも万能な正解はありません。

設計を決める前に、公開後の運用をシミュレーションする

CMS設計で最も価値がある検証は、実装直後の表示確認ではありません。公開後に同じ作業を何度も繰り返せるかの確認です。

一件目の記事を公開できても、五十件目で入力が破綻するかもしれない。担当者が変わったときに、フィールドの意味が伝わらないかもしれない。検索流入が増えたとき、メタクエリがボトルネックになるかもしれない。

私は、設計のレビューで次のような運用シナリオを置きます。

1. 新しいコンテンツをゼロから登録する

2. 既存コンテンツを複製して一部だけ変更する

3. 任意の項目を空欄にして下書き保存する

4. 公開後に画像や分類情報を差し替える

5. URLやタイトルを変更し、リダイレクトを確認する

6. 関連する複数ページをまとめて更新する

7. 権限の異なるユーザーでプレビューする

8. APIや検索結果に意図しない情報が出ていないか確認する

このとき、開発者が迷わず操作できるかではなく、初見の編集者が次に何をすべきか判断できるかを見る。入力欄の説明、初期値、エラーメッセージ、プレビューへの導線。小さな摩擦の積み重ねが、更新率や公開スピードに影響します。

CMSは、作って終わる機能ではありません。投稿タイプやフィールドを追加するたびに、管理画面、テンプレート、検索、API、権限、バックアップ、移行のすべてが少しずつ変わります。

だからこそ、最初から大規模な設計書を作るより、変更される前提で境界線を明確にしておくほうが実践的です。

• このデータの所有者は誰か
• この値はどこで使うのか
• 空欄を許容するのか
• どの条件で公開されるのか
• 検索や並び替えの対象になるのか
• APIに出してよいのか
• 将来、別の表示先でも使うのか

この問いに答えられないフィールドは、まだ作る段階ではありません。

私たちが次に試したいこと

WordPress・CMS設計において、カスタムフィールドとACFは非常に強い道具です。Gutenbergも、編集者の自由度とサイト全体の一貫性を両立させる余地があります。ヘッドレスCMSも、複数の表示先や高度なフロントエンド要件があるなら有力な選択肢です。

ただし、どの技術も導入しただけでコンバージョンや運用効率が改善するわけではありません。仮説を置き、ユーザーの操作と反応を観測し、必要な範囲だけ構造を変える。その繰り返しがCMS設計の実務です。

従来型テーマとヘッドレスのどちらを選ぶかも、技術の新しさではなく、チームの人数、更新頻度、検索要件、プレビューの重要性、将来のチャネル展開で決めるべきです。カスタムフィールドを増やすかどうかも、入力欄の便利さではなく、データが長く使われるかで判断します。

次に試したいのは、CMSの変更を実装単位ではなく、運用指標と結びつけて検証することです。公開までにかかる時間、下書きから公開へ進む割合、入力エラーの発生箇所、プレビューから修正に戻る回数。取得できるデータは限られていても、編集者の行動には改善の手がかりがあります。

WordPressは、簡単に始められるからこそ、設計を後回しにできます。しかし、公開するコンテンツが増え、関係者が増え、表示先が増えた瞬間に、初期の判断が効いてきます。

小さく作る。数字と反応を見る。必要なら泥臭く直す。

個人開発者がCMSを扱うなら、この反復こそが最も現実的な設計手法だと考えています。