タクソノミーをページ骨格にするDrupal設計術
製品点数が数百から数千規模にのぼるB2Bメーカーのサイトでは、コンテンツ管理者が製品を追加するたびに、一覧ページ・詳細ページ・関連資料ページなど複数の画面を個別に更新する運用が発生しがちです。
結果として、更新工数の増大や表記ゆれ、リンク切れといった問題が生じやすい状況に陥ります。
本記事では、Drupalのタクソノミー（分類体系・語彙体系）を単なるカテゴリ分けではなく、サイト全体のページ骨格として設計する手法を解説します。
3階層のタクソノミーを標準化することで、タームを1つ追加するだけで一覧ページ・リンク集・資料ダウンロードページまでが自動的に構築される仕組みを実現できます。情報アーキテクチャに悩むCMS導入検討企業のWeb担当者様に向けて、具体的な設計方針をご紹介します。
目次
タクソノミーを「分類」ではなく「骨格」として捉える
Drupalにおけるタクソノミーは、多くのプロジェクトで記事タグや製品カテゴリの分類機能として利用されています。しかし、製品数が多くカタログ的な情報設計を求められるB2Bメーカーサイトでは、この使い方だけでは運用負荷が増大していきます。
タクソノミーをページの骨格として設計するとは、ターム（分類語）そのものをページのURL・見出し・一覧の起点として位置づける発想です。ノード（Drupalにおけるコンテンツエンティティの基本単位）側で分類を持たせるのではなく、情報構造の基点をターム単位で最上位管理者が統制する設計とし、そこにコンテンツが紐づいていく構造にします。
この設計により、担当者が新しいタームを1つ追加すると、対応するランディングページ・関連コンテンツ一覧・資料ダウンロード導線が自動的に生成される仕組みが成立します。
3階層タクソノミー設計の基本構造
B2Bメーカーサイトで有効な階層設計は、次の3層です。
- 第1階層：事業領域や大分類にあたる区分です。たとえば「産業向けソリューション」「研究開発向け機器」といった、サイト全体のナビゲーションに直結する粒度になります。
- 第2階層：製品カテゴリや用途別区分です。「センサー類」「制御機器」「試験装置」など、ユーザーが検索・回遊する際の判断軸になる粒度で設計します。
- 第3階層：個別シリーズや型番グループにあたる区分です。ここまで細かくタクソノミーで管理することで、シリーズごとのランディングページや資料一覧を自動生成する土台が整います。
この3階層は、標準化された命名規則を前提とします。なお、Drupalの標準機能ではボキャブラリー（vid）やコンテンツタイプにはマシンネームが備わっていますが、個々のターム自体は数値のターム ID（tid）で管理されており、マシンネームに相当するフィールドは標準では持ちません。ターム名の表記揺れは後続のURL生成や自動化ロジックに直結するため、まずはターム名の命名ルールを整備し、機械可読な識別子が別途必要な場合は「Taxonomy Machine Name」のようなコントリビュートモジュールを追加する前提で設計しておくと、後続の自動生成ロジックが安定します。
タームからページを自動生成する仕組み
Drupal 8以降のコアにはViewsが統合されており、タクソノミータームページもデフォルトのViewsビューとして提供されています。このビューをカスタマイズすることで、以下のページ群を仕組みとして構築できます。
- ターム詳細ページ：タームの説明文・関連画像・下位ターム一覧・関連コンテンツ一覧を1つのテンプレートで表示します。
- 関連製品リンク一覧ページ：該当タームに紐づく製品ノードをViewsで抽出し、フィルタ機能付きの一覧として提示します。
- 資料ダウンロードページ：ファイルフィールドを持つメディアエンティティを、タクソノミー参照によって関連付け、タームごとのダウンロードセンターを自動構築します。
この3種類のページテンプレートを一度設計しておけば、コンテンツ管理者はタームを追加するだけで3つのページが同時に立ち上がる状態を実現できます。
パスエイリアスとメニュー自動生成の設計
URLの一貫性も、タクソノミー骨格設計の重要な要素です。Pathautoモジュール（URL自動生成機能）を用いて、タクソノミー階層をそのままURLパスに反映する設定を行います。たとえば第1階層が「industrial」、第2階層が「sensors」であれば、URLは「/industrial/sensors」という形で自動的に構築されます。
さらに、Menu Trail by Path（menu_trail_by_path）モジュールを組み合わせることで、現在表示中のページのURLに応じて、グローバルメニュー側のアクティブトレイル（選択項目のハイライトや親項目の展開）をタクソノミー階層と連動させることができます。ただし同モジュールのパンくずリスト生成機能はDrupal 7版に限られており、Drupal 8以降では対象外です。パンくずリストをタクソノミー階層に連動させたい場合は、カスタムのbreadcrumb builderサービスを実装するか、パンくずリスト生成に対応した別のコントリビュートモジュールを併用する必要があります。
これにより、コンテンツ管理者がタームを追加しただけで、グローバルメニュー上には自動的に項目が反映される運用が可能になります（パンくずリストへの反映は、別途の実装を組み込んだ場合に限られます）。
責任範囲の設計と運用フロー
技術的な仕組みが整っても、運用ルールが曖昧では標準化が崩れます。タクソノミー骨格設計を機能させるには、責任範囲の明確化が欠かせません。
具体的には、第1階層と第2階層は最上位管理者のみが編集可能とし、第3階層以下はコンテンツ管理者が追加できる、という権限設計を目指します。ただし、Drupal標準の権限機能は「特定のボキャブラリーでタームを作成・編集する」という単位で付与される仕組みであり、同一ボキャブラリー内の階層レベルごとに権限を分ける機能は標準では備わっていません。この権限分離を実現するには、「Permissions by Term」のような、タームや階層単位でのアクセス制御に対応したコントリビュートモジュールを導入するか、階層ごとにボキャブラリー自体を分割し、ボキャブラリー単位の標準権限で制御する設計に変更する必要があります。
こうした前提を踏まえて権限設計を行うことで、サイト全体の情報構造は統制を保ちつつ、日常的なコンテンツ追加は現場で完結する体制が構築できます。また、タームの追加時には「説明文」「サムネイル」「関連資料」の入力必須化をフィールド設定で強制することで、生成されるページの品質を標準化できます。
導入時に検討すべき順序
この設計を新規プロジェクトで導入する場合、次の順序で検討を進めることを推奨します。
- 既存コンテンツと想定される製品情報の棚卸しを行い、3階層に整理できるかを検証する
- ターム名の命名規則、および階層別の権限設計（必要に応じて導入するコントリビュートモジュールや、ボキャブラリー分割の要否を含む）を確定させる
- Pathauto・Views・メニュー連携の実装に進む
- コンテンツ管理者向けのマニュアルを整備する
- タクソノミー追加時のレビュー体制を整えて運用開始する
情報アーキテクチャの再設計は、実装より前段の整理に工数がかかります。ここを飛ばして実装から入ると、後から階層構造の変更が必要になり、URL再設計やリダイレクト対応の手戻りが発生します。
よくある質問
Q. 既存のDrupalサイトでも、タクソノミーを骨格とする設計に移行できますか。
移行は可能ですが、既存のURL構造やコンテンツタイプの構成によって工数が変動します。特に既存URLを維持する必要がある場合、リダイレクト設計を含めた段階的な移行計画が必要となります。まずは現状のタクソノミー利用状況とコンテンツ量の棚卸しから始めることを推奨いたします。
Q. 3階層より深い階層が必要な場合はどう設計すべきですか。
4階層以上に拡張することは技術的には可能ですが、URLが長大化しナビゲーション設計が複雑になるため、ユーザビリティおよびSEO上のリスクが高まります。基本は3階層に収め、それ以上の細分化はタクソノミーではなくノード側のフィールドやフィルタで表現することを推奨します。
Q. コンテンツ管理者がタームを自由に追加できると、情報構造が崩れませんか。
その懸念に対応するため、階層ごとの権限設計と、ターム追加時の必須フィールド設定が重要になります。ただし、Drupal標準の権限機能はボキャブラリー単位でのみ付与されるため、第1・第2階層のみ最上位管理者に限定し、第3階層のみコンテンツ管理者に開放するといった階層単位の制御を行うには、「Permissions by Term」など専用のコントリビュートモジュールを導入するか、階層ごとにボキャブラリーを分割する設計変更が必要です。こうした前提を踏まえたうえで責任範囲を設計することで、統制と運用効率の両立が可能になります。
LYZONが提供するWebサービス
Webに関するお悩みは、まずLYZONへ
構築・運用・AIまで、Webに関わる課題をワンストップで対応。まず何ができるかをご覧ください。
2024年入社。Webエンジニア
DCGが趣味。
