小売ECのコーポレートサイトで「事例紹介」や「サービス紹介」といったカスタム投稿タイプを設計する際、必ず突き当たるのが「この投稿タイプは階層構造にすべきか、それとも通常の投稿のようにフラットな構造にすべきか」という判断です。この判断を曖昧にしたまま実装を進めると、後からページ構成を大きく作り直す羽目になりがちです。
WordPressには、指定した投稿タイプが階層構造に対応しているかどうかを判定する is_post_type_hierarchical() という関数があります。この関数自体を単体でテンプレートに書く機会は多くありませんが、この関数が扱っている「投稿タイプの階層」という概念を理解することは、情報設計（IA）の判断において非常に重要です。
この記事では、is_post_type_hierarchical() の正確な仕様を確認したうえで、小売事業者向けのWordPressサイトにおいて、投稿タイプそのものを階層構造にすべきかどうかを判断するための考え方を解説します。なお、この記事で扱う「投稿タイプの階層」は、カテゴリやタグといったタクソノミーの階層とは別の概念です。この違いを最初に明確にしたうえで進めます。
この記事で分かること
- is_post_type_hierarchical() の正確な仕様
- 「投稿タイプの階層」と「タクソノミーの階層」の違い
- カスタム投稿タイプを階層型にすべきかの判断基準
- 階層型にした場合のURL構造・パンくずへの影響
- 情報設計(IA)としての実務的な進め方
投稿タイプの階層設計が小売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 にすると、タクソノミーで表現すべき分類と投稿の親子関係が混在し、かえって情報設計が複雑になるアンチパターンに陥りやすくなります。
小売事業者のインバウンド集客に落とし込む考え方
「投稿タイプの階層」と「タクソノミーの階層」の違いを明確にする
投稿タイプの階層は「個々の投稿（ページ）同士が親子関係を持つかどうか」を表します。一方、タクソノミーの階層（is_taxonomy_hierarchical() が扱う領域）は「カテゴリのような分類項目同士が親子関係を持つかどうか」を表します。両者は名前が似ていますが、扱う対象がまったく異なります。
例えば「サービス紹介」という投稿タイプを考えたとき、「サービスAの中に、サービスAの導入事例ページをぶら下げる」というのは投稿タイプの階層（親子ページ）の話です。一方、「サービスを業種別・課題別に分類する」というのはタクソノミーの階層（カテゴリの親子関係）の話です。同じ「階層」という言葉でも扱う対象が違うため、設計時にこの2つを明確に区別しておく必要があります。
- 投稿タイプの階層＝個々の投稿同士の親子関係
- タクソノミーの階層＝分類項目（カテゴリ等）同士の親子関係
- この2つを混同すると設計がねじれる
事例・サービス紹介などのCPTを階層型にすべきか判断する
事例紹介やサービス紹介といったカスタム投稿タイプを設計する際、「個々のページ同士に実質的な親子関係が存在するか」を基準に階層型にするかどうかを判断します。例えば「サービス概要ページの下に、そのサービスの詳細機能ページが複数ぶら下がる」という構造が実態としてあるなら、階層型（hierarchical: true）が適しています。
一方、「個々の事例は独立した1件ずつの情報で、分類だけが必要」という場合は、投稿タイプ自体は非階層型のままにして、カスタムタクソノミーで業種別・課題別などの分類軸を用意する方が、情報設計としてシンプルになります。多くの小売EC向けサイトでは、事例紹介は後者（非階層型＋タクソノミー分類）が適合しやすい傾向にあります。
- ページ同士に実質的な親子関係があるかを基準に判断する
- 分類だけが必要な場合はタクソノミーで表現する
- 事例紹介は非階層型＋タクソノミー分類が適合しやすい傾向がある
階層型にした場合のURL構造とパンくずへの影響を理解する
投稿タイプを階層型にすると、URLは親ページのスラッグを含む形（例: /service/parent-slug/child-slug/）になります。これはURL構造がそのままサイトの階層構造を表すというメリットがある一方、親ページを変更・削除した際に子ページのURLも変わってしまうというリスクを伴います。
パンくずリストの実装においても、階層型の投稿タイプでは get_post_ancestors() などで親ページをたどってパンくずを生成できますが、非階層型の投稿タイプではタクソノミーの階層（親カテゴリ・子カテゴリ）を基準にパンくずを生成するロジックが必要になります。is_post_type_hierarchical() で投稿タイプの性質を判定し、パンくず生成ロジックを出し分けることで、両方のケースに対応できます。
- 階層型はURLが親子関係を反映した構造になる
- 親ページの変更・削除がURL変更のリスクを伴う
- パンくず生成ロジックを投稿タイプの性質に応じて出し分ける
階層型と非階層型でのテンプレート実装の違いを把握する
階層型の投稿タイプでは、投稿編集画面に「ページ属性」（親ページ、テンプレート、並び順）のUIが表示されます。これを使って運用担当者が親子関係を管理できる一方、非階層型の投稿タイプでは、この管理はタクソノミーの割り当てとして行うことになります。
テンプレート実装においても、階層型では wp_list_pages() のような親子構造をたどる関数が使える一方、非階層型ではタクソノミーターム単位でのクエリ（tax_query）を使った一覧生成が中心になります。is_post_type_hierarchical() で投稿タイプの性質を確認し、どちらの実装パターンを採用するかを実装前に決めておくと、後からの手戻りを防げます。
- 階層型はページ属性UIで親子関係を管理する
- 非階層型はタクソノミー割り当てで分類を管理する
- 実装パターンを事前に決めることで手戻りを防ぐ
既存のタクソノミー階層設計との役割分担を明確にする
既に商品分類やサービスカテゴリでタクソノミーの階層構造（is_taxonomy_hierarchical() の対象領域）を運用している場合、新しいカスタム投稿タイプを設計する際は、その既存のタクソノミー階層と役割が重複しないように注意します。
例えば、商品分類の階層は既にタクソノミーで運用されているのに、新しく作る「特集ページ」投稿タイプまで階層型にして親子関係で分類を再現しようとすると、同じ情報が2つの階層構造で二重管理されることになりかねません。新しい投稿タイプを設計するたびに、既存の分類体系との役割分担を確認する習慣が重要です。
- 既存のタクソノミー階層と役割が重複しないか確認する
- 同じ分類情報を2つの階層構造で二重管理しない
- 新規投稿タイプ設計時は既存の分類体系を必ず参照する
運用イメージ（架空パターン）
理解を深めるために、あくまで仮のケースとして運用イメージを描いてみます。例えば、業務用什器を扱う仮のD社が、コーポレートサイトに「サービス紹介」と「導入事例」という2つのカスタム投稿タイプを新設しようとしていたとします。
当初、担当者は「サービスの中に事例をぶら下げれば分かりやすいのでは」と考え、サービス紹介・導入事例の両方を階層型（hierarchical: true）で設計しようとしていたとします。しかし整理を進める中で、導入事例は業種別・課題別に横断的に参照されることが多く、特定のサービス配下に固定的にぶら下げる構造には合わないことが分かってきたとします。
そこで方針を見直し、サービス紹介は階層型（各サービスの詳細ページを親子関係で管理）、導入事例は非階層型とし、代わりに「業種」「課題」というカスタムタクソノミーを新設して分類する設計に変更したとします。is_post_type_hierarchical()を使って、テンプレート側でもサービス紹介と導入事例のパンくず生成ロジックをそれぞれ出し分けたとします。
このような仮の設計変更を行った場合、導入事例が特定のサービスに縛られずに業種別・課題別に柔軟に参照できるようになり、サービス紹介側は詳細ページの階層構造が明確になる、という状態が期待できると考えられます。あくまで仮のシナリオですが、投稿タイプの階層性を最初に見極めることの重要性のイメージとして参考にしてください。
実装・運用の進め方
- 新規カスタム投稿タイプごとに、個々の投稿が親子関係を持つ実態があるかを洗い出す
- 分類が目的であればタクソノミー、親子ページ構造が目的であれば階層型投稿タイプを選ぶ
- register_post_type()のhierarchical属性を設計方針に基づいて設定する
- is_post_type_hierarchical()を使ってパンくず・テンプレートのロジックを出し分ける
- 既存のタクソノミー階層設計との役割重複がないか確認する
- URL構造への影響を踏まえ、将来的な親ページ変更のリスクを検討する
よくある失敗と回避策
- タクソノミーで表現すべき分類を投稿タイプの階層で無理に表現してしまう
- 投稿タイプの階層とタクソノミーの階層を混同して設計する
- 階層型にした結果、親ページ変更のたびにURLが変わってしまう
- 新規投稿タイプ設計時に既存のタクソノミー階層を確認せず、分類が二重管理になる
- hierarchical属性を「とりあえずtrue」で設定し、後から構造の見直しが必要になる
社内で持つべき判断軸
- その投稿タイプの個々のページに実質的な親子関係が存在するか
- 分類軸として必要なのはタクソノミーか、投稿の親子関係か
- 既存のタクソノミー階層設計と役割が重複しないか
- 将来的な親ページ変更・削除が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()はその実装を出し分けるための判定材料として使います。
タクソノミーの階層設計と投稿タイプの階層設計はどちらを先に決めるべきですか
順序が厳密に決まっているわけではありませんが、まず商品や事例をどう分類したいか(タクソノミー設計)を整理し、そのうえで個々の投稿同士に親子関係を持たせる必要があるかを検討する流れが分かりやすい進め方です。
EC制作・EC広告の相談先を探している小売事業者の方へ
ここまで解説した設計や実装は、単体の関数を知るだけでは十分ではありません。実際の集客成果につなげるには、商品データの持ち方、カテゴリやタグの設計、記事導線、内部リンク、コンバージョン導線、広告配信先の整合まで含めて一貫して設計する必要があります。
自社ECの制作、既存WordPressサイトの改善、Shopifyや基幹システムとの連携、広告運用と連動した特集ページ制作までまとめて整理したい場合は、事業構造に合わせた設計が重要です。運用負荷を抑えながら売上につながる情報設計を進めたい場合は、要件整理の段階から相談できる体制を持っておくと失敗を減らせます。
まとめ
is_post_type_hierarchical() は、投稿タイプそのものが親子関係を持つべきかどうかという、情報設計の根幹に関わる判断を映す関数です。タクソノミーの階層と混同せず、個々のページに実質的な親子関係があるかどうかを基準に、カスタム投稿タイプの設計を進めることが重要です。新しい投稿タイプを追加する前に、この観点で一度立ち止まって設計を見直してみてください。
コメント