WordPress採用サイトのデータ設計｜求人・社員紹介・記事の分け方

求人が3件から30件に増えたとき、同じ固定ページを複製し続けるのか。社員が退職したとき、求人ページに残った紹介文を誰が直すのか。データ設計は、このような更新場面から考えると決めやすくなります。

採用サイトだからカスタム投稿タイプ（CPT）が必須、というわけではありません。内容が独立して更新・終了・移行される単位を確かめ、WordPressのどこで管理するかを選びます。

まず、独立して管理する単位を決める

求人、社員紹介、一般記事、固定情報は、名前だけでは管理方法を決められません。現在と1年後の件数を見積もり、1件ごとにURLが必要か、一覧や絞り込みがあるか、誰が公開を終えるかを確認します。

たとえば、社員紹介が2件だけでも、求人との関連表示や退職時の掲載停止を個別に扱うなら、独立した管理単位の候補です。反対に、毎年ほとんど変わらない制度説明を、更新頻度が低いという理由だけで専用の型へ分ける必要はありません。

要件とCMS化範囲を設計の入力にする

ページ名の一覧だけでは、保存方法を選べません。コンテンツ管理システム（CMS）で顧客が更新する範囲を先に確かめます。件数、URL規則、一覧、絞り込み、更新担当、公開期限、承認、外部システムから受け取る情報までが入力です。未決定の項目は、採用サイト制作の要件定義で決定・未決定・範囲外に分けます。

続いて、顧客が更新する内容、固定する内容、制作者が対応する内容を分けます。この境界は採用サイトで何をCMS化するかで決めます。ここまでの結果を受け取って、WordPress上の保存単位へ変換するのが本記事の範囲です。

標準投稿、固定ページ、カスタム投稿タイプを比べる

標準投稿と固定ページも、WordPressでは投稿タイプに含まれます。投稿タイプの公式解説を踏まえ、次の表で管理先を比較します。

選択肢	選ぶ条件	選択理由にならないもの	確認する責任
標準投稿	時系列、カテゴリー、配信、著者、一般記事の運用を共有したい	「記事」と呼んでいること	一覧、権限、URL規則を他の記事と共有できるか
固定ページ	階層の中で一枚ずつ編集し、独自の一覧や終了状態を持たない	更新頻度が低いこと	後から一覧、絞り込み、関連付けが必要にならないか
カスタム投稿タイプ	複数件を独立管理し、専用の一覧、項目、状態、権限、関係を持つ	求人や社員紹介という名前	URL、一覧ページ、検索、権限、終了、移行を誰が担うか
既存の型＋分類・項目	公開手順を共有でき、違いを分類や少数の項目で表せる	一時的に実装量を減らせること	件数が増えても一覧、権限、状態の責任が衝突しないか

カスタム投稿タイプは、公式に案内されたregister_post_type()を使う方法で追加できます。テーマを替えても管理対象へ到達できる必要があるなら、登録処理はテーマではなくプラグイン側へ置きます。

ただし、登録場所を変えても、新しいテーマで表示まで自動的に再現されるわけではありません。テンプレート、見た目、URL、検索条件、関連機能は別に移行確認が必要です。

一つの事実に、一つの保存場所を割り当てる

型を選んだら、情報の置き場所を決めます。仕事内容のように順序や表現が変わる長文は本文へ置きます。雇用形態や勤務地など、再利用、入力検証、並べ替えに使う値はカスタムフィールドの候補です。

メタデータの公式資料では、投稿タイプにキーと値の情報を持たせる仕組みが説明されています。文章を細切れにするためではなく、複数の表示で同じ値を使うときに採用します。

職種、拠点、部門のように、複数のデータを横断してまとめる語彙は分類の候補です。分類の公式解説にあるとおり、分類は内容をグループ化します。住所全文や給与説明など、1件だけに属する値とは分けます。

同じ勤務地を本文、項目、分類へ重複入力すると、どれを直せばよいか分からなくなります。表示に必要な箇所が複数あっても、保存上の正本は一つにします。

公開状態と募集状態を別々に持つ

WordPressのdraftやpublishは、閲覧・編集上の公開状態です。募集中、受付停止、募集終了、再募集準備は、採用業務の状態です。募集終了を理由に下書きへ戻すと、終了案内や再募集履歴まで見えなくなる場合があります。

公開状態の公式解説を基準に、標準の状態で足りるかを確かめます。公式資料は、独自の状態を登録しても管理画面へ自動追加されないと明記しています。一覧、絞り込み、REST API、通知は、案件で必要な動作を別に実装・検証します。採用業務の状態を検証可能な項目として持つ方法も比較します。

さらに、詳細、一覧、応募導線、JobPosting、サイトマップ、検索通知のどこへ反映するかを決めます。募集終了後の同期は、JobPostingの募集終了・期限切れ・再募集で具体化します。

求人と社員紹介は、複製せず参照でつなぐ

求人へ社員名、役職、URLを直接コピーすると、異動や退職の後も古い情報が残ります。代わりに相手の識別番号（ID）を保存し、表示時に公開可能な値を取得します。

関係を設計するときは、求人側と社員側のどちらから選ぶか、1件か複数かを決めます。相手が非公開・削除・募集終了になった場合の表示と、別環境へ移す場合の対応キーも必要です。

メタデータに保存した識別番号は、データベースの外部キー制約で自動保護されるものではありません。保存時の存在確認、表示時の公開可否確認、削除時の扱いまでを受け入れ条件に含めます。

4種類のデータ責任表を埋める

ここまでの判断を一枚にまとめます。次の表を案件の件数、権限、外部連携に合わせて直し、最後の列まで責任者を置きます。

内容	出発点となる型	単位・URL	本文・項目・分類	公開状態と業務状態	関係	情報源・責任者・終了・移行
求人	複数件を独立運用するならCPT。固有の一覧や状態がなければ固定ページも比較	1募集1URL。新卒・中途は運用差で判断	仕事内容は本文。雇用形態、勤務地、期限は項目。職種・拠点は分類候補	WordPressの公開状態と募集状態を分離	社員、記事、応募先を参照	採用担当またはATSを情報源とし、募集終了と書き出し方法を決める
社員紹介	一覧、絞り込み、関連表示があるならCPT。少数なら固定ページも比較	1人または1記事を1URLにするか決める	紹介文は本文。表示名、役職は項目。部門・職種は分類候補	公開可否と在籍・掲載同意の判断を分離	求人、部門、記事を参照	本人確認と更新担当を決め、異動・退職・同意変更時の処理を決める
一般記事	時系列、カテゴリー、著者、配信を共有するなら標準投稿	1記事1URL	本文を中心に、再利用値だけ項目へ置く	標準の公開状態を基本にし、掲載期限は別項目で検討	職種、求人、社員紹介を参照	編集担当を情報源とし、見直し、統合、転送の方法を決める
固定情報	固定ページから検討	会社情報、制度、選考案内などを1ページ1URLで管理	説明は本文。複数ページで使う事実だけ項目か別の正本から参照	標準の公開状態を基本にする	求人や記事から参照される	公式社内資料の責任者を決め、改定日と差し替え手順を残す

新卒と中途を別のカスタム投稿タイプにするかも、名称では決めません。入力項目、承認、状態、URL、権限、一覧がほぼ同じなら、一つの求人型と分類で責任を共有できます。別々の担当者が異なる手順で変更するなら、型を分ける案を比較します。

引き渡しは代表データで確かめる

設計書が整っていても、入力から移行まで動くとは限りません。実際に採用した型から代表データを選び、次の順で確かめます。

1. 必須・任意、入力形式、初期値、エラー表示が設計どおりか
2. 一覧、詳細、絞り込み、空欄、非公開の参照が設計どおりか
3. 公開状態と業務状態を変えたとき、対象の表示だけが変わるか
4. 関係先を更新・非公開・削除しても、古い複製値が残らないか
5. 担当者が必要な型と項目だけを操作できるか
6. 本文、項目、分類、関係、状態を書き出し、別環境で対応し直せるか

確認結果には、代表データ、操作した役割、確認したURLを残します。期待結果と実結果、書き出し・復元結果も記録します。

権限はWordPress採用サイトの権限設計へ、更新と終了の分担は人事・広報・Web担当の役割分担へ渡します。公開画面だけでなく、削除、書き出し、テーマ変更後の管理まで確認して完了です。

この確認だけで、特定のプラグイン、法的な保存要件、個人情報の扱いが十分だとは判断できません。案件の要件と組織の判断は別に確認します。

データ設計を制作方式の比較へ渡す

データ責任表が埋まると、テーマへ組み込む範囲、プラグインへ分離する範囲、既存構成を使う範囲を同じ条件で比べられます。方式名から選ばず、必要な型、項目、分類、状態、関係、移行条件を制作側へ渡してください。

WordPress採用サイト制作を標準化する5つの方法を比較する