カスタム投稿タイプ設計で気をつけている3つのこと – NPC
カスタム投稿タイプ、なんとなくで作っていないか
WordPressでサイトを作っていると、「これ、固定ページでも投稿でもないな」という場面に必ず出くわす。実績、スタッフ紹介、商品、お知らせ……。そこで登場するのがカスタム投稿タイプ（Custom Post Type）だ。
※「カスタム投稿タイプ」とは、WordPressに標準で用意されている「投稿」や「固定ページ」以外に、自分で新しい投稿の種類を追加できる機能のこと。たとえば「実績」「スタッフ」など、用途に合わせた箱を作れます。
ただ、このカスタム投稿タイプ、作ること自体は簡単なのに「設計」を間違えるとあとから地獄を見る。スラッグを変えたらURLが全部変わってSEOに影響が出たり、リビジョンが効かなくて過去の状態に戻せなかったり。
自分はWordPress案件を2016年ごろからやっていて、カスタム投稿タイプの設計で何度か痛い目に遭ってきた。その経験から「最低限これだけは気をつけている」という3つのポイントを共有したい。
1. スラッグとラベルは最初に確定させる
カスタム投稿タイプを登録するとき、最初に決めるのがpost_typeのスラッグ（内部名）とラベル（管理画面での表示名）。ここを軽く考えると、あとで取り返しがつかなくなる。
スラッグは「短く」「英語で」「変えない前提で」
スラッグはURLの一部になる。たとえばworksというスラッグで登録すれば、個別ページのURLは/works/記事スラッグ/になる。これを途中でportfolioに変えたくなったら、全ページのURLが変わる。当然、検索エンジンに登録されたURLも無効になるので、301リダイレクトの設定が必要になる。
自分のルールはこう。
staff、works、newsなどラベルは「クライアントが迷わない名前」にする
ラベルは管理画面のサイドバーに表示される名前。開発者目線で「Works」としたくなるが、クライアントが使う管理画面なので「制作実績」のように日本語でわかりやすくする。labels配列でname、singular_name、add_newなどを丁寧に設定しておくと、管理画面の使い勝手がぐっと上がる。
2. supportsは「足りないもの」を意識して設定する
register_post_type()のsupports引数は、その投稿タイプでどの編集機能を使えるかを決めるパラメータ。ここが曲者で、書かなかった機能は使えない。
※「supports」とは、register_post_type()関数に渡すオプションのひとつで、タイトル・本文エディタ・アイキャッチ画像・リビジョンなど、その投稿タイプで有効にする機能を配列で指定します。
リビジョンを忘れると過去に戻れない
通常の「投稿」はデフォルトでリビジョン（編集履歴）が有効になっている。でもカスタム投稿タイプでは、supportsに'revisions'を明示的に入れないとリビジョンが保存されない。
自分はこれで実際に痛い目を見た。ある案件でカスタム投稿タイプの本文を更新したら表示が崩れて、「リビジョンで戻そう」と思ったら履歴が1件もなかった。結局、手作業で復旧する羽目になった。
カスタム投稿タイプを設計するときのsupportsのチェックリストはこれ。
- title — ほぼ必須
- タイトルが不要なケースはほぼない
- editor — 本文エディタ
- ACFだけで完結する場合は外すことも
- thumbnail — アイキャッチ画像
- 一覧ページで画像を出すなら必須
- revisions — リビジョン
- 忘れがち。必ず入れる
- excerpt — 抜粋
- 一覧ページの説明文に使うなら
- page-attributes — 並び順（menu_order）
- 手動で表示順を制御したい場合
既存のカスタム投稿タイプを触るときは、最初にREST APIで/wp-json/wp/v2/types/スラッグを叩いて、現在のsupportsを確認するようにしている。思い込みで作業を始めると、「あるはずの機能がない」で時間を溶かす。
3. ACFとの役割分担を最初に決める
WordPress案件でカスタム投稿タイプを使うなら、ほぼ確実にACF（Advanced Custom Fields）もセットで使う。ここで迷うのが「どの情報を本文エディタに入れて、どの情報をACFのカスタムフィールドに入れるか」という線引きだ。
※「ACF」とは、WordPressの管理画面にオリジナルの入力欄（カスタムフィールド）を追加できるプラグイン。テキスト、画像、セレクトボックスなど様々な入力形式を用意でき、投稿タイプごとに異なるフィールドを設定できます。
判断基準は「クライアントが自由に書くか、構造化されたデータか」
自由記述のコンテンツ（ブログ本文のような文章）は本文エディタ。決まった構造のデータ（価格、所在地、営業時間、スタッフの肩書きなど）はACFのカスタムフィールド。このシンプルな基準で分けている。
たとえば「スタッフ紹介」の投稿タイプなら、こんな設計になる。
- 自己紹介の自由記述
- ブログ的なコンテンツ
- 書き手によって長さ・内容が変わるもの
- 名前・肩書き・所属
- プロフィール写真
- SNSリンク
- 担当分野（セレクトボックス）
構造化されたデータをACFに切り出しておくと、テンプレート側での出力が安定する。本文エディタに全部入れると、クライアントがHTMLを壊してレイアウトが崩れる……というのはWordPress案件あるあるだ。
ACFフィールドグループの命名も統一する
フィールドグループ名やフィールド名はスネークケース（staff_position、staff_photoなど）で統一している。投稿タイプのスラッグをプレフィックスにすると、他の投稿タイプのフィールドと被らない。get_field('position')だと他と衝突するかもしれないが、get_field('staff_position')なら安全だ。
設計フローをまとめると
カスタム投稿タイプを新規に設計するとき、自分はだいたいこの順番で進めている。
2番目のステップがいちばん重要。ここで決めたスラッグやsupportsは、あとから変更するコストが高い。「とりあえず作って、あとで直そう」が通用しにくいのがカスタム投稿タイプの設計だ。
まとめ：「あとから変えにくいもの」を最初に固める
カスタム投稿タイプの設計で気をつけていることを3つ挙げた。
- スラッグとラベルは最初に確定させる。特にスラッグはURLに直結するので変更コストが高い
- supportsは「何を入れるか」より「何を入れ忘れていないか」を意識する。リビジョンは必須
- ACFとの役割分担を最初に決める。自由記述は本文エディタ、構造化データはACFフィールド
どれも派手なテクニックではないけれど、この3つを押さえておくだけで「あとから困る」ケースがかなり減る。カスタム投稿タイプは一度作るとサイトの骨格になるものなので、最初の設計に時間をかける価値は大きい。
※この記事はNPCの中の人の実務経験をもとに書いています。