WordPressの更新画面を設計する方法｜カスタム投稿・入力項目・検収の決め方

WordPressの更新画面を設計するときは、先にプラグインを選ぶより「誰が、何を、一件として登録し、どこへ表示するか」を決めます。お知らせ、製品、店舗、制作事例で必要な入力は違います。すべてを自由な本文欄へ入れる方法も、細かな入力欄を大量に作る方法も、更新する人の仕事に合わなければ使いづらくなります。

この記事は、企業サイトを制作する会社と、公開後に情報を更新する担当者に向けた設計ガイドです。固定ページ・投稿・カスタム投稿、本文・カスタムフィールド・分類の役割を整理し、実装担当へ渡せる入力仕様票と検収項目を作ります。WordPress公式資料を参照しますが、そのコード例を本番へ貼り付ける手順ではありません。テーマ、追加機能、権限、既存データを調べたうえで方式を決めます。

1．更新する仕事を、一件の登録から公開確認まで書く

「社内で更新できるサイト」という要望だけでは、編集画面の仕様を決められません。まず更新対象を一つ選び、今の担当者が行っている仕事を聞きます。新しい内容を追加するのか、既存の文章や写真を変えるのか、公開を終了するのか。入力した後に誰が原稿と掲載許可を確認するかも含めて整理します。

更新対象・担当・表示先を同じ表にする

設計用の表には、情報の種類、一件の単位、追加と修正を行う人、頻度、承認者、表示先を記入します。たとえば架空の施工会社の事例なら、一件は「一つの工事」で、文章と写真を営業担当が集め、責任者が掲載を確認し、制作事例一覧と詳細へ表示する、という形です。これは説明用の例で、Acquaの顧客案件ではありません。

毎回決まった文章をコピーし、製品名だけ変えているなら共通項目を整理できます。一方、内容の構成が毎回違う読み物まで同じ小さな欄に分けると、説明しづらくなる場合があります。登録件数の多さだけで方式を選ばず、情報の関係と更新時の迷いを材料にします。

この段階では、最終画面を描く必要はありません。現在の原稿を一件用意し、更新に必要な材料と、公開される場所を紙や表へ並べてみます。写真の許諾待ちや仕様未確定など、入力だけでは解決できない待ちも見つかります。技術方式を決める前に、情報を確定する担当を明らかにしてください。

2．固定ページ・投稿・カスタム投稿を、情報の役割で選ぶ

会社概要や常設サービスなど、一つのページの内容を更新するなら固定ページが候補です。時系列のお知らせや記事には投稿が候補になります。製品や事例を独立した種類として管理し、種類ごとの入力・一覧・表示条件を持たせたい場合は、カスタム投稿を検討できます。名前だけで決めず、既存サイトの分類と表示の実装を確認します。

WordPress公式はカスタム投稿を、独自の情報の種類として登録できる仕組みと説明しています。また、テーマを変更しても情報を扱いやすくするため、投稿タイプの登録をテーマよりプラグインへ置くことを推奨しています。どこに登録するかと、公開画面をどこで表示するかは別の設計です。（WordPressのカスタム投稿登録ガイド）

「事例があるから必ずカスタム投稿」という決め方はしません。少数の常設ページで独立管理する必要がなく、既存方式で運用できる場合もあります。反対に、記事と製品を同じ一覧へ混ぜた結果、管理者が分類と表示条件を毎回調整しているなら、分ける理由があります。追加の実装・保守・移行の負担も含めて選びます。

カスタム投稿を追加しても、必要な一覧や検索、絞り込み、関連表示がすべて自動で完成するとは限りません。どの情報を公開し、一覧をどう並べ、詳細へどう移動するかを別に決めます。管理画面へ項目が現れたことだけで「WordPress化完了」と判断しないでください。

既存サイトの改修では、現在のデータを調べてから新しい種類へ移すかを判断します。投稿の種類やURLの設計を変えるなら、外部リンク、一覧、旧データ、運用手順への影響があります。新しい登録欄を作る仕事と、既存内容を移行・転送する仕事を同じ見積もりへ無説明で含めず、別の承認対象として扱います。

3．本文・入力項目・分類を分け、同じ情報を何度も入れない

ページごとに構成が違う説明は本文欄、一定の形式で使い回す情報は入力項目、複数の情報をまとめて探す軸は分類、という分け方が出発点になります。実装方法は複数あるため、この分け方が一つの製品を必須にするわけではありません。まず必要な情報を整理し、その後に方式を比較します。

カスタムフィールドは、投稿などに付随する情報を扱う仕組みです。独自の入力画面を設ける場合には、保存と公開表示も実装する必要があります。WordPress公式のメタボックス解説は入力欄の考え方を示し、掲載コードには本番で必要なセキュリティ処理等が省かれていると明示しています。例をコピーするだけで完成とは扱いません。（WordPressのCustom Meta Boxes）

一覧・詳細・関連表示へ使う項目を見つける

架空の製品紹介なら、製品名、短い説明、代表写真、用途の分類、詳しい本文を候補にできます。製品名を本文と一覧用の入力欄へ別々に書くと、改名時に不一致が出る場合があります。同じ情報を複数の表示で使うなら、正本となる欄と、表示へ取り出す方法を決めます。

分類も、地域・用途・製品種別などの軸が必要かを確認します。自由な文字列で毎回入力すると表記が揺れ、絞り込みの条件が揃わない場合があります。選択式にするなら、項目を追加・変更できる人、複数選択の可否、未分類の表示を決めます。分類が多いほど使いやすいわけではありません。

他の登録情報と関連付けたい場合は、会社名や製品名を再入力するより、対象を選ぶ方式が候補になります。ただし、元の情報が非公開になった場合や削除された場合の表示、並び順、権限も必要です。関連付けを追加する仕事を、単なるテキスト欄の追加と同じ工数だと考えないようにします。

資料や写真には、代表画像、本文用、一覧用、ダウンロード用といった役割があります。一つのファイルをあらゆる枠へ無理に当てはめるより、縦横比、見せたい部分、代替テキスト、許可を確認する場所を決めます。画像の項目を作ることと、公開可能な素材を用意することは別の仕事です。

4．入力仕様票で、空欄・例外・保存後の表示まで決める

項目名と「必須」の印だけでは、実装担当が期待する保存と表示を決められません。入力の型、例、文字数や書式の制約、空欄の扱い、エラー、表示先、修正者まで書きます。短い欄を一つ増やした場合も、その値が一覧やリンクへ出るなら公開側を含む検収が必要です。

たとえば日付欄では、日付が未定なら保存できるか、終了後は一覧から消すか、日付を表示するだけかを決めます。勝手に期限を判断して非公開へする機能と、文字として日付を載せる機能は違います。URL欄なら、未入力時のボタン、外部リンクの扱い、無効な値を入力したときの説明も確認します。

仮原稿でなく、例外を含む試験用データを作る

短い見出しと横長写真一枚だけでは、入力欄の使いやすさを評価しにくいことがあります。長いタイトル、画像なし、縦長画像、任意項目の空欄、複数の関連情報、公開終了の項目など、実際に起こり得る状態を選んで試験データを作ります。実在する顧客の個人情報や未許諾写真をテストに使う必要はありません。

エラーは、何をどう直すかが分かる説明にします。保存できないときに入力済みの本文を失わないか、未定を仮の数値で埋めさせていないかを見ます。入力のチェックと、サーバー側で安全に保存・表示する処理は別に必要です。画面に必須印があることだけで、処理が適切だとは判断しません。

仕様票には確定・仮・未決定を付け、未決定の確認者と期限を残します。制作途中で「やはり一覧にも載せたい」と変わった場合には、表示箇所、再確認、工数への影響を記録します。小さい変更に見えても、既存データへ値を追加する移行が必要なら、入力欄だけの変更ではありません。

5．一覧・詳細・プレビュー・公開状態を一組で設計する

登録した情報がどこに出るかを、画面ごとに確認します。新着一覧、カテゴリ別一覧、詳細、トップの紹介枠、関連記事などで、表示する項目と順番を決めます。「一覧へ自動反映」とだけ書かず、対象条件、並び順、件数、空の状態、次のページへの移動を仕様に含めます。

架空の事例一覧なら、公開済みだけを表示し、指定した順番で並べ、代表写真がない場合の見え方を用意する、といった条件があります。これは設計例で、共通の正解ではありません。担当者が変えたい並びと、制作側が実装する条件が一致しているかを確認します。閲覧者が探す軸を持たない絞り込みを増やしても、運用が複雑になるだけの場合があります。

下書き・プレビュー・予約・公開・訂正も分けます。独自入力項目を変えたとき、保存前のプレビューへ反映するか、承認者が何を見て判断するか、予約時刻後の公開を誰が確かめるか。使用する機能と実装で挙動が異なるため、実際の一件を通して確認します。ボタンがあることと、期待した状態になることは別です。

履歴と復元についても、本文とすべての独自項目が同じように戻ると推測しません。どの値を履歴へ残すか、誤入力をどの方法で訂正できるかを実装担当へ確認します。復元テストでは、写真、分類、関連情報、公開状態のどこまで戻ったかを記録します。バックアップと編集履歴の役割も分けて引き継ぎます。

PCとスマホで表示する枠が違う場合も、情報は同じ正本から扱う設計にできます。ただし、長い項目や画像のトリミング、空欄の省略が読者の判断に影響しないかを点検します。編集担当が更新したあとに確認する画面を、納品時の操作手順へ具体的に記載してください。

6．権限・既存データ・保守の担当を、方式と一緒に決める

更新担当へ管理者権限を渡せば運用が完成するわけではありません。入力、原稿承認、公開、分類追加、テーマやプラグインの設定では必要な操作が違います。独自の投稿タイプでも、誰がどこまで操作できるかを設計し、日常用のアカウントで確認します。役割名だけで権限を推定せず、追加機能も含めて実値を見ます。

独自入力の実装では、入力値の検証、保存時の権限、公開表示での出力などを確認します。WordPress公式のセキュリティ解説は、検証・無害化・適切な出力処理等を扱っています。特定のプラグインを入れたことだけで、独自コードとすべての保存・表示が安全と判断しないでください。（WordPressのSecurityガイド）

使うプラグインや独自実装については、ライセンス、利用条件、更新する人、設定の保管、停止したときの影響を確認します。入力欄の定義と表示処理を別の場所へ置いているなら、その関係を納品物へ残します。ソースだけ、設定ファイルだけ、画面の説明だけでは、別の担当者が再現できないことがあります。

既存データの移行では、元の項目と新しい項目の対応を一覧にします。写真、分類、関連付け、未入力値、公開状態をどのように扱うかを決め、別環境で少数のデータを先に検証します。値が移った件数と、一覧・詳細が正しく表示されたことは別の確認です。本番へ戻す範囲と、作業中の新しい更新をどう保持するかも必要です。

方式の変更を公開サイトへ反映するときは、対象、差分、復元点、影響、承認者を揃えます。本記事を読んだだけで既存の投稿タイプやURLを変更する必要はありません。まず現状を調べ、必要な入力と表示の不足だけを提案できる状態にするのが出発点です。

7．検収は、実際の更新担当者が一件を完成させて行う

検収では、実装担当の管理者アカウントだけでなく、公開後に使う役割で操作します。合意した試験用データを使い、登録、下書き保存、修正、プレビュー、承認、公開、一覧と詳細の確認まで通します。止めている機能は未確認と記録し、試験データを本番へ誤って移さないよう扱いを決めます。

操作できたことと、業務が楽になったことを分ける

登録機能が動いたことは、実装の確認です。更新にかかった時間、質問や差し戻し、外部への依頼回数は、その後の運用で確かめます。入力欄を増やした結果、項目を埋めるために未確認の情報を作っていないかも見ます。自動一覧ができた件数を、そのまま顧客の解決や工数削減と報告しないでください。

不具合は、対象欄、入力内容の種類、操作順、期待した表示、実際の表示を一件ずつ残します。新しい仕様の希望は不具合と分け、再見積もりや日程を確認します。確認した原稿と画面の版を記録すると、後から変更された状態を以前の合格として扱うことを避けられます。

納品には、情報の種類、入力仕様、一覧と詳細の条件、設定・コードの場所、使用する機能、権限、試験結果、残課題、問い合わせ先を含めます。更新担当へは、普段の一件の追加と、写真の差し替え、訂正、公開後確認の手順を渡します。すべてを専門的な設計資料だけで説明せず、担当者が実際に使える手順を用意してください。

8．制作会社へ渡す資料と、Acquaへ依頼する範囲を揃える

最初は、情報の種類と一件の原稿、編集する項目、表示先、担当と承認、既存環境、未決定事項をまとめます。プラグイン名を先に指定する必要はありません。既存方式を維持したい場合は、その理由と変更対象外の箇所を伝えます。着手前に設計が必要なのか、決まった仕様の実装を頼むのかも分けます。

依頼文の架空例なら、「製品紹介を営業担当が登録できるようにしたい。製品名・概要・写真・用途・本文を入力し、用途別一覧と詳細へ反映する。既存記事とURLは保持する。入力仕様票の不足を確認し、空欄・長文・写真なし・権限別の検収を含めて見積もってほしい」と書けます。価格や固定の作業日数をここで決めるものではありません。

外注全体の受け渡しは、制作会社向けWordPress実装の依頼資料と検収表を使えます。本稿の入力仕様票を、そのCMS要件へ添えてください。デザインの静止画だけで入力欄の動作を判断してもらうより、保存・表示・承認の条件が伝わります。

Acquaへは、制作会社向けの実装・保守案内で、支給資料、既存環境、実装範囲、検収と公開の担当を確認して相談できます。独自入力の設計・実装・既存改修を一律に受けられるという意味ではありません。必要な調査、使う方式、対応可否、納品物、保守と費用を案件ごとに合意します。

企業側で更新しづらさを感じている場合は、企業向けWeb制作・運用の案内から、現在の登録画面と困っている作業を整理できます。支援後の解決状態は、担当者が正しい情報を登録し、一覧と詳細を確認して更新を完了でき、例外や保守の窓口も分かることです。専門的な実務が残る場合は、お問い合わせへ対象サイトと更新内容をお知らせください。