小売ECのコーポレートサイトで「事例紹介」や「サービス紹介」といったカスタム投稿タイプを設計する際、必ず突き当たるのが「この投稿タイプは階層構造にすべきか、それとも通常の投稿のようにフラットな構造にすべきか」という判断です。この判断を曖昧にしたまま実装を進めると、後からページ構成を大きく作り直す羽目になりがちです。
WordPressには、指定した投稿タイプが階層構造に対応しているかどうかを判定する is_post_type_hierarchical() という関数があります。この関数自体を単体でテンプレートに書く機会は多くありませんが、この関数が扱っている「投稿タイプの階層」という概念を理解することは、情報設計（IA）の判断において非常に重要です。
この記事では、is_post_type_hierarchical() の正確な仕様を確認したうえで、小売事業者向けのWordPressサイトにおいて、投稿タイプそのものを階層構造にすべきかどうかを判断するための考え方を解説します。なお、この記事で扱う「投稿タイプの階層」は、カテゴリやタグといったタクソノミーの階層とは別の概念です。この違いを最初に明確にしたうえで進めます。
投稿タイプの階層設計が小売ECの集客で重要になる理由
小売ECのサイトでは、商品カテゴリ、サービス紹介、導入事例、コラム記事など、複数の情報の塊を扱うことになります。これらをどのような構造でサイト内に配置するかは、ユーザーが情報にたどり着けるかどうか、検索エンジンがサイト構造をどう理解するかに直結します。
ここで見落とされやすいのが、「情報を分類するための階層（タクソノミーの階層）」と「投稿そのものが親子関係を持つ階層（投稿タイプの階層）」を混同してしまうことです。例えば、固定ページ（page）は投稿タイプ自体が階層型で、ページ同士に親子関係を持たせられます。一方、通常の投稿（post）は投稿タイプとしては非階層型で、代わりにカテゴリというタクソノミーの階層で分類します。
この違いを理解せずにカスタム投稿タイプを設計すると、「本来はタクソノミーで分類すべき情報を、無理に投稿の親子関係で表現しようとする」あるいは逆に「本来は投稿同士の親子関係で表現すべき構造を、タクソノミーでこじつけようとする」といった設計のねじれが発生します。これは後からURL構造やテンプレートの作り直しにつながる、コストの高い手戻りです。
- 投稿タイプの階層とタクソノミーの階層は別の概念である
- 混同した設計は後からの手戻りコストが大きい
- URL構造・パンくず・テンプレートの実装方針に直結する
- 情報設計の初期段階で判断しておくべき事項である
is_post_type_hierarchical()の役割を実務目線で理解する
is_post_type_hierarchical() は、指定した投稿タイプが階層構造に対応しているかどうかを判定する関数です。引数 $post_type には投稿タイプ名を文字列で指定します（必須）。戻り値は真偽値で、階層構造を持つ投稿タイプであれば true、持たない投稿タイプであれば false を返します。内部的には get_post_type_object() を使って投稿タイプの登録情報を取得し、その ‘hierarchical’ 属性を参照しています。
if ( is_post_type_hierarchical( 'post' ) ) {
echo '投稿は階層型です';
} else {
echo '投稿は階層型ではありません';
}
// 出力: 投稿は階層型ではありません
if ( is_post_type_hierarchical( 'page' ) ) {
echo '固定ページは階層型です';
} else {
echo '固定ページは階層型ではありません';
}
// 出力: 固定ページは階層型ですカスタム投稿タイプの場合、この階層性は register_post_type() を実行する際の引数 ‘hierarchical’ で決まります。true にすれば固定ページのような親子関係を持たせられ、false（デフォルト）にすれば通常の投稿のようにフラットな構造になります。
register_post_type( 'case_study', array(
'label' => '導入事例',
'public' => true,
'hierarchical' => true, // 事例カテゴリを親子関係で表現したい場合
'supports' => array( 'title', 'editor', 'thumbnail', 'page-attributes' ),
) );
if ( is_post_type_hierarchical( 'case_study' ) ) {
// 親ページ選択UIやパンくずの親子表示ロジックを有効にする
}ここで注意したいのは、’hierarchical’ を true にしただけで自動的にサイト設計として正しくなるわけではない点です。階層型にすると、投稿編集画面に親ページ選択のUIが表示され、URLも親子関係を反映したパス構造になりますが、これはあくまで「投稿同士が親子関係を持てる」という技術的な性質にすぎません。実際にその親子関係をどう使うか（カテゴリ分類として使うのか、シリーズ物のページとして使うのか）は別途設計する必要があります。安易に「階層型にしておけば柔軟性が高まるだろう」という理由だけで hierarchical を true にすると、タクソノミーで表現すべき分類と投稿の親子関係が混在し、かえって情報設計が複雑になるアンチパターンに陥りやすくなります。
運用イメージ（架空パターン）
理解を深めるために、あくまで仮のケースとして運用イメージを描いてみます。例えば、業務用什器を扱う仮のD社が、コーポレートサイトに「サービス紹介」と「導入事例」という2つのカスタム投稿タイプを新設しようとしていたとします。
当初、担当者は「サービスの中に事例をぶら下げれば分かりやすいのでは」と考え、サービス紹介・導入事例の両方を階層型（hierarchical: true）で設計しようとしていたとします。しかし整理を進める中で、導入事例は業種別・課題別に横断的に参照されることが多く、特定のサービス配下に固定的にぶら下げる構造には合わないことが分かってきたとします。
そこで方針を見直し、サービス紹介は階層型（各サービスの詳細ページを親子関係で管理）、導入事例は非階層型とし、代わりに「業種」「課題」というカスタムタクソノミーを新設して分類する設計に変更したとします。is_post_type_hierarchical()を使って、テンプレート側でもサービス紹介と導入事例のパンくず生成ロジックをそれぞれ出し分けたとします。
このような仮の設計変更を行った場合、導入事例が特定のサービスに縛られずに業種別・課題別に柔軟に参照できるようになり、サービス紹介側は詳細ページの階層構造が明確になる、という状態が期待できると考えられます。あくまで仮のシナリオですが、投稿タイプの階層性を最初に見極めることの重要性のイメージとして参考にしてください。
実装・運用の進め方
- 新規カスタム投稿タイプごとに、個々の投稿が親子関係を持つ実態があるかを洗い出す
- 分類が目的であればタクソノミー、親子ページ構造が目的であれば階層型投稿タイプを選ぶ
- register_post_type()のhierarchical属性を設計方針に基づいて設定する
- is_post_type_hierarchical()を使ってパンくず・テンプレートのロジックを出し分ける
- 既存のタクソノミー階層設計との役割重複がないか確認する
- URL構造への影響を踏まえ、将来的な親ページ変更のリスクを検討する
社内で持つべき判断軸
- その投稿タイプの個々のページに実質的な親子関係が存在するか
- 分類軸として必要なのはタクソノミーか、投稿の親子関係か
- 既存のタクソノミー階層設計と役割が重複しないか
- 将来的な親ページ変更・削除がURL構造に与える影響をどう見るか
成果測定で見るべき指標
- 階層型ページのURL変更に伴うリダイレクト・404の発生件数
- パンくずリストの表示が実際の情報構造と一致しているか
- 投稿タイプ別のアーカイブ・個別ページのクロール状況
- 情報構造変更後の内部リンク経由の回遊率
- 投稿タイプ別コンテンツからの問い合わせ・資料請求のCV数
よくある質問
is_post_type_hierarchicalとis_taxonomy_hierarchicalの違いは何ですか
is_post_type_hierarchical()は投稿タイプ自体が親子関係を持つ投稿タイプかどうかを判定します。is_taxonomy_hierarchical()はカテゴリのような分類項目（タクソノミーのターム）が親子関係を持つかどうかを判定します。判定対象が投稿タイプかタクソノミーかという点で明確に異なります。
カスタム投稿タイプを階層型にするかどうかは後から変更できますか
register_post_type()の設定を変更することは技術的に可能ですが、既に階層構造で運用しているページを非階層型に変更するとURL構造やパンくずのロジックに影響が及ぶため、慎重な移行作業が必要になります。設計初期に判断しておくのが望ましいです。
is_post_type_hierarchical()はどのような場面で実際に使いますか
単体で頻繁に使う関数ではありませんが、複数の投稿タイプを扱うテーマで、パンくず生成やテンプレート出し分けのロジックを投稿タイプの性質に応じて共通化したい場合に使います。wp_body_classフックと組み合わせて、階層型ページ特有のCSSクラスを付与する用途もあります。
固定ページ(page)以外に標準で階層型の投稿タイプはありますか
WordPress標準の投稿タイプでは、階層型はpage（固定ページ）のみです。post（投稿）、attachment（添付ファイル）などは非階層型です。カスタム投稿タイプの階層性はregister_post_type()の設定次第で自由に決められます。
階層型にすると自動的にパンくずリストは正しく表示されますか
自動的には表示されません。階層型投稿タイプであっても、パンくずリストを生成するロジック自体はテーマやプラグイン側で実装する必要があります。is_post_type_hierarchical()はその実装を出し分けるための判定材料として使います。
タクソノミーの階層設計と投稿タイプの階層設計はどちらを先に決めるべきですか
順序が厳密に決まっているわけではありませんが、まず商品や事例をどう分類したいか(タクソノミー設計)を整理し、そのうえで個々の投稿同士に親子関係を持たせる必要があるかを検討する流れが分かりやすい進め方です。
まとめ
is_post_type_hierarchical() は、投稿タイプそのものが親子関係を持つべきかどうかという、情報設計の根幹に関わる判断を映す関数です。タクソノミーの階層と混同せず、個々のページに実質的な親子関係があるかどうかを基準に、カスタム投稿タイプの設計を進めることが重要です。新しい投稿タイプを追加する前に、この観点で一度立ち止まって設計を見直してみてください。
コメント